Résumé

  • En accès PPP, IPv6CP suit LCP, tandis que l’authentification et l’autorisation RADIUS peuvent se terminer avant l’attribution d’adresse. Le NAS ne sait donc pas nécessairement si l’hôte utilisera IPv4, IPv6 ou les deux.
  • RFC 3162 autorise la présence d’attributs des deux familles dans un même message RADIUS et laisse au NAS le soin de n’appliquer que ceux que le client peut utiliser. Une valeur d’autorisation ne prouve pas qu’une adresse, un préfixe, une route ou un service fonctionnel existe déjà.

La réponse arrivait avant la question

Un serveur d’accès a besoin d’une décision de politique avant d’ouvrir la session d’un abonné. Mais au moment où il demande à un serveur RADIUS s’il doit admettre l’utilisateur, la configuration réseau finale de l’hôte peut encore être inconnue. C’est le décalage le plus révélateur de RFC 3162, « RADIUS and IPv6 », publié en août 2001.

Le document traite deux fonctions liées mais distinctes. RADIUS peut fonctionner sur IPv6 ; séparément, les messages RADIUS peuvent transporter des attributs permettant de fournir un accès réseau IPv6 à un utilisateur. Une adresse IPv6 pour le transport RADIUS ne signifie pas qu’un préfixe IPv6 a été attribué à l’abonné. La norme traite les deux cas, mais le problème de temporalité concerne le second.

RFC 3162 rend le problème concret avec le protocole PPP. Le Link Control Protocol (LCP) précède le IPv6 Control Protocol (IPv6CP). L’authentification et l’autorisation RADIUS peuvent donc s’achever avant l’attribution d’une adresse. Lorsque le Network Access Server (NAS) envoie un Access-Request, il peut ignorer si l’hôte utilisera IPv4, IPv6 ou les deux.

Une conception simple devient alors impossible : demander d’abord quelle famille l’utilisateur emploiera, puis ne renvoyer que les attributs correspondants. Le NAS doit obtenir la décision avant que la négociation ultérieure ne fournisse la réponse. La solution de RFC 3162 n’est pas de deviner : les attributs IPv4 et IPv6 peuvent coexister dans le même message, et le NAS choisit ceux qui s’appliquent. Il devrait seulement attribuer des adresses et des préfixes que le client peut effectivement utiliser.

Autoriser ne signifie pas configurer

Les attributs eux-mêmes maintiennent cette distinction. NAS-IPv6-Address identifie le dispositif qui demande l’authentification. Framed-Interface-Id concerne un identifiant d’interface IPv6. Framed-IPv6-Prefix fournit un préfixe et la route correspondante à configurer pour l’utilisateur. Framed-IPv6-Route apporte des informations de routage, tandis que Framed-IPv6-Pool nomme un pool configuré à partir duquel un préfixe peut être attribué. Ce sont des points de contrôle différents, pas des preuves interchangeables de connectivité.

Certaines valeurs sont explicitement des indications. Si IPv6CP négocie avec succès l’option Interface-Identifier, le NAS place dans son Access-Request la valeur qu’il préfère. Le serveur RADIUS devrait la respecter, mais n’y est pas obligé. Le NAS peut également proposer un préfixe IPv6 ; le serveur peut ignorer cette préférence. Un Access-Accept est une réponse de politique, non la transcription de l’acceptation par l’interface ni la preuve que les paquets atteignent Internet.

Le texte limite également l’usage des données retournées. Il n’est pas nécessaire de réserver une adresse IPv4 à un hôte uniquement IPv6, ni un préfixe IPv6 à un hôte utilisant uniquement IPv4 ou 6to4. Ce conseil situe les responsabilités : le serveur RADIUS transmet des attributs de politique ; le NAS voit la session négociée et devrait éviter de configurer une famille que le client ne peut utiliser.

L’échange d’autorisation tolère donc l’incertitude en acceptant une réponse plus large, puis en limitant l’usage effectif au point qui possède un meilleur contexte de session. Ce n’est pas seulement un choix de format. C’est la frontière entre ce qu’un serveur central peut autoriser à l’avance et ce qu’un équipement d’accès n’apprend qu’après la négociation du protocole.

Les couches restent distinctes

Plusieurs étapes suivent encore : une requête peut contenir une préférence du NAS ; une réponse peut autoriser ou fournir un préfixe ; IPv6CP peut négocier un identifiant d’interface ; le NAS peut installer une adresse ou une route. Seul un test de bout en bout peut ensuite montrer si le service est joignable. RFC 3162 définit des attributs et leur place dans l’échange, sans rapporter une session réelle ni certifier le résultat de ces étapes.

La différence compte, car authentification, autorisation et comptabilisation sont souvent condensées dans le mot « accès ». Pourtant, une réponse d’authentification n’est pas une adresse configurée, et un préfixe installé n’équivaut pas à une connectivité fonctionnelle. L’opérateur qui examine les journaux doit savoir quelle couche les éléments observés documentent réellement.

RFC 3162 réserve six numéros d’attribut RADIUS, de 95 à 100, aux informations IPv6. Des normes ultérieures ont ajouté d’autres éléments : RFC 4818 définit un attribut de préfixe délégué, RFC 6911 d’autres attributs d’accès IPv6 et RFC 8044 actualise les règles de types de données RADIUS. Le texte de 2001 n’est donc pas un inventaire complet du provisionnement moderne. Son apport historique est plus précis : rendre possible une autorisation à double famille avant que la famille de la session ne soit connue.

La Note 20 de Lu Heng fournit ici une grille de lecture éditoriale : la description formelle et l’état observable d’un système sont deux couches différentes. Appliqué à cette RFC, un attribut enregistre ce qu’un serveur a demandé, préféré ou autorisé ; il ne prouve pas à lui seul ce que le NAS a installé ni ce que l’utilisateur pouvait joindre. Cette interprétation n’est pas une affirmation des auteurs de RFC 3162.

Sources

  1. RFC 3162 — RADIUS and IPv6
  2. Notice RFC Editor de RFC 3162
  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, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile