Resumo

  • No acesso PPP, IPv6CP vem depois de LCP, enquanto a autenticação e autorização RADIUS podem terminar antes da atribuição de endereço. Assim, o NAS talvez ainda não saiba se o host usará IPv4, IPv6 ou ambos.
  • A RFC 3162 permite atributos das duas famílias na mesma mensagem RADIUS e deixa o NAS aplicar somente o que o cliente pode usar. Um valor autorizado não prova que um endereço, prefixo, rota ou serviço funcional já exista.

A resposta chegava antes da pergunta

Um servidor de acesso precisa de uma decisão de política antes de abrir a sessão de um assinante. Mas, quando pergunta a um servidor RADIUS se deve admitir o usuário, a configuração de camada de rede que o host acabará usando pode continuar indefinida. Esse intervalo é a parte mais reveladora da RFC 3162, “RADIUS and IPv6”, publicada em agosto de 2001.

O documento aborda duas funções relacionadas, porém diferentes. O RADIUS pode rodar sobre IPv6; separadamente, as mensagens RADIUS podem transportar atributos que dão suporte ao acesso IPv6 de um usuário. Usar um endereço IPv6 para transportar RADIUS não significa que o assinante recebeu um prefixo IPv6. A norma trata dos dois casos, mas o problema de ordem diz respeito ao segundo.

A RFC 3162 usa o acesso por Point-to-Point Protocol para explicar a sequência. Link Control Protocol (LCP) acontece antes do IPv6 Control Protocol (IPv6CP). A autenticação e autorização RADIUS podem terminar antes da atribuição de endereço. Portanto, quando o Network Access Server (NAS) envia um Access-Request, talvez ainda não saiba se o host usará IPv4, IPv6 ou ambos.

Isso inviabiliza uma solução simples: primeiro perguntar qual família o cliente usará, depois devolver apenas os atributos correspondentes. O NAS precisa da decisão antes de a negociação posterior fornecer a resposta. A RFC 3162 não manda adivinhar. Ela permite atributos IPv4 e IPv6 na mesma mensagem RADIUS e deixa o NAS escolher os aplicáveis. O NAS deve atribuir somente endereços e prefixos que o cliente realmente possa usar.

Autorizar não é configurar

Os próprios atributos mantêm essas funções distintas. NAS-IPv6-Address identifica o equipamento que pede autenticação. Framed-Interface-Id trata de um identificador de interface IPv6. Framed-IPv6-Prefix fornece um prefixo e a rota correspondente a configurar para o usuário. Framed-IPv6-Route traz informações de roteamento, e Framed-IPv6-Pool nomeia um conjunto configurado do qual um prefixo pode ser atribuído. São pontos de controle diferentes, não evidências intercambiáveis de conectividade.

Alguns valores são explicitamente sugestões. Se o IPv6CP negociar com sucesso a opção Interface-Identifier, o NAS inclui no Access-Request o identificador que prefere. Recomenda-se que o servidor RADIUS aceite a preferência, mas ele não é obrigado a isso. O NAS também pode sugerir um prefixo IPv6, que o servidor pode ignorar. Um Access-Accept é uma resposta de política, não um registro de que a interface do cliente aceitou a preferência ou de que os pacotes alcançam a Internet.

A RFC 3162 também limita o uso dos dados retornados. Não é necessário reservar um endereço IPv4 para um host que só dá suporte a IPv6, nem um prefixo IPv6 para um host que usa apenas IPv4 ou 6to4. O conselho é restrito, mas situa as responsabilidades: o servidor RADIUS fornece atributos de política; o NAS conhece a sessão negociada e deve evitar configurar uma família que o cliente não pode usar.

A troca de autorização tolera a incerteza ao permitir uma resposta mais ampla, e depois restringe o uso efetivo no ponto com melhor contexto da sessão. Não é apenas uma escolha de formato de pacote. É uma fronteira entre o que um servidor central pode autorizar antecipadamente e o que o equipamento de acesso só consegue saber depois da negociação do protocolo.

As camadas continuam separadas

Ainda há etapas posteriores. A solicitação pode trazer uma preferência do NAS; a resposta pode autorizar ou devolver um prefixo; o IPv6CP pode negociar o identificador da interface; e o NAS pode configurar um endereço ou rota. Só um teste de ponta a ponta pode então indicar se o serviço é alcançável. A RFC 3162 define atributos e seu lugar na troca, mas não relata uma sessão real nem certifica o resultado dessas etapas.

Essa distinção importa porque autenticação, autorização e contabilização costumam virar uma única palavra: “acesso”. Mas uma resposta de autenticação bem-sucedida não é um endereço configurado, e um prefixo instalado não significa conectividade funcional. Quem analisa os registros precisa saber que camada a evidência realmente cobre.

A RFC 3162 reservou seis números de atributos RADIUS, de 95 a 100, para informações de IPv6. Normas posteriores acrescentaram mais vocabulário: a RFC 4818 define um atributo de prefixo delegado; a RFC 6911 adiciona outros atributos de acesso IPv6; e a RFC 8044 atualiza orientações sobre tipos de dados RADIUS. O documento de 2001 não é, portanto, um inventário completo do provisionamento atual. Sua contribuição histórica é mais precisa: permitir autorização para as duas famílias antes que se conhecesse qual delas a sessão usaria.

A Nota 20 de Lu Heng oferece uma lente editorial: descrição formal e estado observável do sistema são camadas diferentes. Aplicada a esta RFC, um atributo registra o que o servidor pediu, preferiu ou autorizou; não prova, por si, o que o NAS instalou nem o que o usuário podia acessar. É uma interpretação editorial, não uma afirmação dos autores da RFC.

Fontes

  1. RFC 3162 — RADIUS and IPv6
  2. Registro da RFC 3162 no RFC Editor
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
  4. RFC 2866 — RADIUS Accounting
  5. RFC 2868 — RADIUS Attributes for Tunnel Protocol Support
  6. RFC 2472 — IP Version 6 over PPP
  7. RFC 2460 — Internet Protocol, Version 6 Specification
  8. RFC 3056 — Connection of IPv6 Domains via IPv4 Clouds
  9. RFC 4818 — RADIUS Delegated-IPv6-Prefix Attribute
  10. RFC 6911 — RADIUS Attributes for IPv6 Access Networks
  11. RFC 8044 — Data Types in RADIUS
  12. RFC 2044 — UTF-8, a Transformation Format of Unicode and ISO 10646
  13. Lu Heng, Nota 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile