Resumo
- A RFC 3011 permitiu que um solicitante DHCP indicasse uma sub-rede de alocação diferente daquela pela qual seu pacote chegou ao servidor, separando origem observada de destino do recurso.
- A cópia idêntica da opção 118 na resposta era um recibo limitado de processamento; não provava identidade, autorização sobre o pool, rota, ausência de conflito ou serviço entregue.
Antes de escolher um endereço, o servidor precisa escolher um conjunto de endereços. O procedimento comum de RFC 2131 aproveitava o que a rede já mostrava. Com relay, giaddr indicava a sub-rede do cliente. Sem ele, a interface local que recebera o pacote servia de referência. Na maior parte das redes, o lugar de chegada era um bom substituto para o lugar da alocação.
Um concentrador de acesso remoto quebrava essa equivalência. Sua comunicação com o servidor DHCP passava por uma rede interna. Seus assinantes, porém, precisavam de endereços em uma ou mais redes externas. O plano interno podia nem ter rota IP para essas redes. O pedido tinha de sair por dentro; o recurso tinha de ser retirado de fora.
A RFC 3011, publicada em novembro de 2000, criou a IPv4 Subnet Selection Option. O valor contém quatro octetos: um endereço da sub-rede pretendida com os bits de host zerados pela máscara. O registro BOOTP/DHCP da IANA ainda registra o código 118 com comprimento quatro.
Quando o servidor estava configurado para aceitar a opção, ela tinha precedência sobre a inferência por giaddr ou pela interface receptora. O endereço oferecido devia pertencer à sub-rede indicada ou a outra sub-rede no mesmo segmento. O servidor não podia selecionar um pool fora desse perímetro.
O pacote, portanto, passou a carregar uma afirmação diferente da observação produzida pela rede. A interface interna continuava sendo o ponto real de chegada. A opção 118 dizia onde a alocação deveria ocorrer. A configuração do servidor decidia se o pedido merecia ser obedecido.
O caminho de resposta formava uma terceira camada. Em uma renovação, o servidor poderia enviar DHCPACK ao endereço alocado, mas esse endereço externo talvez não fosse roteável desde o plano interno. Assim, toda mensagem com a opção 118 precisava preencher giaddr com um endereço em que o solicitante aceitasse pacotes DHCP. O pool escolhido não substituía o endereço de retorno.
A RFC também definiu um recibo de compatibilidade. Um servidor habilitado devia devolver uma cópia idêntica da opção, mesmo sem ela constar na Parameter Request List. O cliente que utilizasse o mecanismo tinha de descartar DHCPOFFER ou DHCPACK sem essa cópia.
Isso tornava visível a diferença entre sintaxe e capacidade. Um servidor antigo poderia ignorar o código e oferecer um endereço da rede interna. Um servidor novo, mas administrativamente configurado para não atender a opção, faria o mesmo. A mensagem seria um DHCP válido, mas não executaria a seleção especial. Sem o eco, o cliente não podia aceitá-la como equivalente.
O eco, contudo, tinha alcance limitado. Ele demonstrava que o valor passara por uma regra específica do servidor. Não autenticava o concentrador, não concedia direito de consumir a sub-rede externa, não instalava rota e não provava que o endereço estivesse livre ou que o assinante tivesse recebido conectividade. Um recibo de decisão não é recibo de resultado.
Essa distinção aparece com força na segurança. O DHCP daquele momento não oferecia autenticação por si só. Um solicitante que pudesse indicar pools remotos ampliava um ataque de esgotamento: em vez de pressionar apenas o conjunto associado à sua origem local, poderia alcançar muitos conjuntos.
Por isso o recurso deveria vir desabilitado. Sua ativação exigia configuração explícita, e o servidor deveria permitir restrições por client-id, origem do pedido ou lista de sub-redes que cada solicitante pudesse indicar. A padronização tornava a instrução interoperável; não tornava o emissor soberano sobre os pools.
A RFC 2132 havia definido a gramática de opções. Código, comprimento e valor tornavam o campo analisável. A RFC 3011 acrescentou semântica comum. A autorização continuava fora dos seis bytes, na política local.
Documentos posteriores moveram uma declaração semelhante para o relay controlado pelo operador. A RFC 3046 criou Relay Agent Information, com identificadores locais de circuito e de terminal. A RFC 3527 criou Link Selection para o caso em que o link de alocação fosse diferente do endereço usado para falar com o relay.
Se a opção 118 do cliente e a subopção do relay aparecessem juntas, Link Selection prevaleceria. A prioridade refletia posição no modelo de confiança: o relay podia estar sob controle administrativo da rede, enquanto o campo do cliente vinha de uma borda mais ampla.
Mesmo assim, não se deveria tratar toda cópia em uma resposta como prova de compreensão. Um recipiente Relay Agent Information podia ser replicado. A RFC 3527 exigia conhecimento administrativo de compatibilidade. A RFC 3118 definiu autenticação DHCP, mas a existência de um padrão não demonstra sua implantação em um caso específico.
A RFC 7969 depois organizou mecanismos de personalização conforme a topologia. Subnet Selection, Link Selection e Virtual Subnet Selection respondem a divisões diferentes. Eles mostram que origem, relay, segmento, VPN, pool e retorno não cabiam mais em uma única noção de localização.
Uma trilha de evidência precisa manter separados a interface de entrada, a fonte observada, giaddr, client-id, opção 118, regra de autorização, pool, oferta, eco e destino da resposta. Depois vêm o lease, a rota, a vizinhança, a sessão do usuário e o resultado da aplicação.
Sob a lente de Lu Heng, a força da RFC 3011 está na especificação inicial mínima. Ela alterou uma decisão delimitada do servidor e deixou adoção e restrições no nível local. O número público permitiu que implementações falassem a mesma língua; o código em execução e a configuração mostravam quem realmente podia influenciar a alocação.
O pedido era interno. O endereço era externo. A resposta precisava de um caminho próprio. A RFC 3011 não apagou a topologia; ela impediu que um único vestígio topológico fingisse responder às três perguntas.
Sources
- RFC 3011, The IPv4 Subnet Selection Option for DHCP
- RFC Editor information page for RFC 3011
- RFC 2131, Dynamic Host Configuration Protocol
- RFC 2132, DHCP Options and BOOTP Vendor Extensions
- RFC 3046, DHCP Relay Agent Information Option
- RFC 3118, Authentication for DHCP Messages
- RFC 3527, Link Selection sub-option for DHCPv4
- RFC 7969, Customizing DHCP Configuration on the Basis of Network Topology
- IANA BOOTP/DHCP Parameters
- Lu Heng, Running-Code Primacy
- Lu Heng, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Lu Heng, On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
