Resumo

  • A RFC 4014 permitiu que o servidor de acesso à rede preservasse alguns atributos de um Access-Accept RADIUS e os anexasse depois à mensagem DHCP encaminhada pelo relay.
  • O servidor DHCP usava esses atributos para escolher parâmetros de configuração. Autorização, transporte pelo relay e concessão de endereço continuavam sendo responsabilidades distintas.

O acesso foi aceito; o endereço ainda não

Um notebook passa pela autenticação 802.1X em uma rede corporativa. O ponto de acesso ou switch libera a sessão. Isso resolve a pergunta sobre entrada na rede, mas não configura a comunicação IP. Para isso, o cliente ainda precisa conversar com DHCP. Entre a autorização e o endereço existe uma passagem de contexto entre serviços que podem estar em equipamentos diferentes.

RADIUS e DHCP não respondem à mesma pergunta. RADIUS autentica e retorna atributos associados à autorização do serviço. DHCP escolhe os parâmetros que serão oferecidos ao cliente. A RFC 3580 é clara: o IEEE 802.1X não fornece mecanismo de atribuição de endereço IP. Atributos como Framed-Pool só podem ser usados por autenticadores que tenham capacidade de participar da atribuição.

Essa divisão combinava com a arquitetura de muitas redes. A autenticação podia ficar centralizada, enquanto a infraestrutura de DHCP mantinha seus próprios pools. O NAS na borda conhecia a sessão recém-autorizada e também podia atuar como relay DHCP. Se o servidor de endereços não recebesse o contexto necessário, teria de reconstruí-lo por outra via ou depender de uma integração proprietária entre as equipes.

Ralph Droms e John Schnizlein publicaram a RFC 4014 em fevereiro de 2005 para formalizar esse transporte. Depois de um Access-Accept bem-sucedido, o NAS guardava localmente os atributos recebidos. Quando a solicitação DHCP chegava, o mesmo equipamento podia incluir uma seleção desses atributos ao retransmiti-la ao servidor. A RFC criou uma ponte entre os protocolos, mas não transformou a decisão RADIUS em um lease.

O relay já levava informações da borda

A ponte usava a opção Relay Agent Information definida pela RFC 3046 e conhecida como Option 82. Ela funciona como um envelope para dados que o relay conhece: por qual circuito a solicitação entrou ou qual equipamento remoto está associado à linha, por exemplo. O servidor DHCP pode usar essas informações ao escolher endereços ou outros parâmetros.

A resposta também preserva esse modelo. O servidor devolve a opção ao relay, e o relay a remove antes de encaminhar a resposta ao cliente. O dispositivo final não precisa interpretar identificadores internos da rede de acesso.

A RFC 4014 acrescentou nesse envelope a subopção 7, “RADIUS Attributes”. Ela transporta os octetos codificados dos atributos recebidos no Access-Accept. Ao receber a mensagem, o servidor DHCP extrai o conteúdo e o usa na seleção da configuração. Quem transporta não decide o lease; quem decide o lease não precisa assumir a função de autenticação.

O mecanismo não se limitava a uma sessão IEEE 802.1X. A RFC permitia que um relay transportasse atributos RADIUS obtidos por outros motivos, desde que respeitassem a semântica do serviço. Mas a promessa de interoperabilidade robusta era local: RADIUS e DHCP deveriam operar no mesmo domínio administrativo localizado. Não havia garantia de interpretação comum entre organizações independentes em escala global.

Uma lista curta limitava o acoplamento

A RFC fixou uma regra de cardinalidade: uma mensagem não pode carregar mais de uma subopção RADIUS Attributes. Se disponíveis, User-Name e Framed-Pool devem ser incluídos; os demais são opcionais. Para impedir que a alocação de endereços dependa de estados separados mantidos pelo servidor RADIUS, o relay deveria se restringir a seis atributos: User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool e Framed-IPv6-Pool.

O servidor DHCP usa essas informações na escolha de parâmetros e deve ignorar valores fora da lista indicada. Um nome de pool pode orientar a política, mas não obriga o servidor a fornecer um endereço de um pool que não administra. O contexto da autorização influencia a seleção; a política e os recursos de DHCP continuam do lado do servidor.

O espaço também é limitado por bytes. A RFC 4014 determina que o relay trunque os atributos para que caibam na subopção. Ela não define uma política universal para escolher o que será cortado. Portanto, o atributo presente no Access-Accept pode não chegar inteiro ao DHCP. Operadores precisam observar o conteúdo efetivamente encaminhado e saber como cada implementação trata o limite.

O NAS passa a carregar uma responsabilidade de estado: associar os atributos preservados à sessão correta quando a solicitação DHCP chegar. A RFC não define uma tabela de sessão nem diz como renovar esse estado após reautenticação ou alteração de política. Essa lacuna não é necessariamente um defeito do padrão; é a fronteira entre o que ele especifica e a implementação local que precisa funcionar.

Confiança faz parte do caminho de controle

Como o servidor DHCP pode usar os valores do relay para selecionar configuração, a relação entre relay e servidor é parte do mecanismo de controle. A RFC 4014 herda a confiança descrita na RFC 3046. Além de aceitar Option 82 apenas de relays confiáveis, recomenda proteção mais forte, como autenticação das opções de relay ou IPsec.

O cliente normalmente não vê Option 82. Isso reduz o que precisa processar, mas não autentica o conteúdo. O servidor ainda precisa saber quem enviou a informação e como o caminho foi protegido. Uma informação forjada ou antiga pode influenciar uma decisão de política se a fronteira falhar. É uma possibilidade decorrente do desenho, não um relato de incidente conhecido.

Por isso, “quem escolheu o endereço?” tem uma resposta distribuída. RADIUS autorizou a sessão e forneceu contexto; o NAS decidiu carregá-lo; o servidor DHCP escolheu a configuração e controla seus pools. A RFC define a passagem, mas não prova que o estado esteja atualizado, que o relay seja confiável ou que a política local esteja correta. O que vale no fim é o comportamento dos equipamentos em operação.

A evolução de 2023 manteve caminhos diferentes

A RFC 9445 voltou a essa fronteira em 2023, quando serviços novos precisaram de parâmetros que a lista fixa da RFC 4014 não contemplava. Ela atualizou a RFC 4014 ao transferir os atributos RADIUS permitidos para um registro mantido pela IANA, sujeito a avaliação especializada. A mudança estende a lista da subopção 7 sem remover a estrutura existente.

A RFC 9445 também definiu outros dois atributos RADIUS, DHCPv6-Options (245.3) e DHCPv4-Options (245.4), para transportar opções DHCP. Um exemplo de DNS criptografado ilustra como parâmetros de serviço podem atravessar essa via; o exemplo não mede adoção. Esses atributos não são a subopção 7. O registro atual da IANA documenta o que é permitido, não o que os operadores implantaram.

A história, então, não é a de RADIUS substituindo DHCP. É a de duas funções que precisaram trocar contexto sem perder seus limites. A autorização pode influenciar a seleção; o servidor de endereços continua responsável pelo que oferece. Quando novos serviços exigem mais flexibilidade, a extensão precisa manter claro quem decide, quem transporta e quem aplica a política.

Como lente posterior, a Nota 64 de Lu Heng pergunta se a especificação comum pode continuar mínima e deixar as escolhas seguintes no domínio que opera os sistemas. A Nota 65 lembra que a publicação de uma regra não demonstra seu funcionamento no código em execução. Essas notas não causaram a RFC 4014 nem são fontes da sua história. A pergunta prática permanece nos equipamentos que rodam hoje: o relay passou o contexto certo e o DHCP aplicou a política esperada?

Fontes