Resumo

  • A RFC 3074 transformava o identificador do cliente ou endereço de hardware em um de 256 valores e consultava um mapa compartilhado para definir qual servidor DHCP deveria atender.
  • Ela também previa servidor designado indisponível ou sem endereços, buckets sem dono, tempo de cliente incorreto e mapa adulterado. O hash comprovava uma atribuição configurada, não capacidade ao vivo.

Como DHCPDISCOVER é difundido, vários servidores podem recebê-lo e responder. Um relay BOOTP pode repetir a mesma ineficiência ao encaminhar o pedido a todos os destinos. Em fevereiro de 2001, B. Volz, S. Gonczi, T. Lemon e R. Stevens publicaram a RFC 3074 com uma alternativa: depois da configuração inicial, cada participante calcularia sozinho a mesma decisão de servir ou não servir.

O cálculo começava pelo Service Transaction ID. Havendo Client Identifier, ele era obrigatório; sem ele, hlen definia o tamanho e chaddr fornecia no máximo dezesseis bytes. A função de Pearson especificada devolvia um valor entre 0 e 255. Cada servidor recebia um Hash Bucket Assignment de 32 octetos, no qual um bit ligado obrigava o destinatário a atender os pedidos daquele bucket.

O acordo era útil. Mesma entrada, tabela de mistura e HBA produziam o mesmo responsável sem conversa contínua. Um relay podia usar pares Server-ID/bucket para escolher destinos. Assim se dividia uma população de clientes sem modificar o software deles.

Mas a função não consultava o estado atual. Ela não sabia se o processo estava ativo, se a rota chegava, se as bases de leases concordavam ou se o pool conservava um endereço adequado. STID representava uma transação; HBA declarava uma responsabilidade administrativa. Nenhum era um sensor de prontidão.

A própria RFC descreve o servidor que deveria responder, mas está indisponível ou sem endereços. O Delayed Service opcional permite que um servidor normalmente excluído pelo hash responda S segundos após a primeira tentativa. A exceção não torna a conta errada; ela abre outra oportunidade quando o responsável inicial não produziu serviço.

Até o relógio é qualificado. O servidor deveria usar secs quando o cliente envia valor diferente de zero, mas o texto reconhece implementações incorretas. Em alternativa, pode lembrar o primeiro pedido recusado e medir o intervalo até uma repetição com o mesmo transaction ID. Uma fonte é declarada pelo cliente; a outra liga duas observações locais. Nenhuma revela sozinha por que houve silêncio.

Sem Delayed Service, o HBA impõe uma regra estrita. Buckets não atribuídos fazem algumas transações serem inteiramente ignoradas, algo que pode ser desejado. Portanto, cobertura é um recibo independente: um programa impecável pode calcular com exatidão um bucket que ninguém serve.

Os percentuais também não são medição instantânea. Em períodos curtos a parcela real pode desviar da configurada; com mais pedidos deve se aproximar. O hash não pesa CPU, fila, latência ou endereços livres. Ele distribui identificadores e depende de variedade suficiente nos STID, não de unicidade garantida.

Configuração integra a execução. HBAs podem vir de arquivo, registro do Windows NT, EEPROM ou algoritmo acordado, e podem viajar em outro protocolo. A RFC não fornece segurança. Se o mapa for transmitido, a mensagem precisa resistir a adulteração, pois buckets alterados podem negar serviço a alguns ou todos. Código idêntico não detecta mapas divergentes nem corrige uma instrução comum maliciosa.

A RFC 2131 completa o quadro: clientes devem aceitar a possibilidade de múltiplas respostas e DHCP opera sob política administrativa local. Depois de DISCOVER ainda vêm OFFER, escolha, REQUEST, ACK e uso efetivo. A RFC 3074 organiza quem pode começar, sem garantir o restante. A RFC 1542 explica o relay BOOTP, não a adoção correta do hash por um equipamento específico.

Muito depois, a RFC 7031 chamou configuração incompatível entre parceiros de problema frequente e manteve balanceamento fora do núcleo do failover DHCPv6. Ela não comprova um passado de implantação da RFC 3074. Ajuda apenas a distinguir distribuição de pedidos, sincronização de estado e recuperação de falha.

Running-Code Primacy ordena os recibos: origem do STID, bucket, cobertura, servidor, alcance, endereço, tomada tardia, OFFER, escolha, REQUEST, ACK e configuração utilizável. Reality Layers impede que a certeza simbólica de um dono calculado vire certeza operacional. São lentes posteriores, não argumentos dos autores ou da IETF.

A RFC 3074 resolveu uma pergunta estreita e importante: quem tenta primeiro. Sua honestidade está também no que não prometeu. Um bucket pode atribuir responsabilidade; presença, capacidade, integridade e resultado continuam sendo fatos a observar.

Fontes