Aller au contenu principal

13. Considérations IANA (IANA Considerations)

Cette section décrit les enregistrements et considérations IANA (Internet Assigned Numbers Authority) liés à Neighbor Discovery pour IPv6.

13.1. Enregistrements de Type et Code ICMPv6

Neighbor Discovery utilise plusieurs types de messages ICMPv6 enregistrés auprès de l'IANA. Les types ICMPv6 suivants sont définis dans cette spécification :

Type ICMPv6NomRéférence
133Router SolicitationRFC 4861, Section 4.1
134Router AdvertisementRFC 4861, Section 4.2
135Neighbor SolicitationRFC 4861, Section 4.3
136Neighbor AdvertisementRFC 4861, Section 4.4
137Redirect MessageRFC 4861, Section 4.5

Tous ces types de messages utilisent le Code 0, et aucune autre valeur de Code n'est actuellement définie pour ces types.

13.2. Registre des Types d'Option Neighbor Discovery

L'IANA maintient un registre pour les types d'option Neighbor Discovery. Les types d'option suivants sont définis dans cette spécification :

Type d'OptionNomRéférence
1Source Link-Layer AddressRFC 4861, Section 4.6.1
2Target Link-Layer AddressRFC 4861, Section 4.6.1
3Prefix InformationRFC 4861, Section 4.6.2
4Redirected HeaderRFC 4861, Section 4.6.3
5MTURFC 4861, Section 4.6.4

13.2.1. Procédure d'Enregistrement

Les nouveaux types d'option Neighbor Discovery sont alloués selon la procédure suivante :

  • Valeurs 0-255 : IETF Review ou IESG Approval requis (tel que défini dans RFC 8126)
  • Les nouvelles options DOIVENT (MUST) être documentées dans une RFC ou une autre référence permanente et publiquement accessible
  • L'enregistrement DOIT (MUST) inclure :
    • Valeur du Type d'Option
    • Nom de l'Option
    • Brève description de l'option
    • Référence au document définissant

13.2.2. Format du Type d'Option

Les valeurs de Type d'Option sont des identificateurs sur 8 bits. Les deux bits de poids fort du champ Type d'Option sont utilisés pour spécifier l'action à entreprendre si le type d'option n'est pas reconnu :

  • 00 : Ignorer cette option et continuer le traitement du message
  • 01 : Rejeter le message
  • 10 : Rejeter le message et envoyer un message ICMP Parameter Problem
  • 11 : Rejeter le message et envoyer un message ICMP Parameter Problem uniquement si l'adresse de destination n'est pas une adresse multicast

Cet encodage permet une gestion flexible des options inconnues et facilite le déploiement fluide de nouveaux types d'options.

13.3. Constantes du Protocole IPv6 Neighbor Discovery

Bien que non directement gérées par l'IANA, cette spécification définit plusieurs constantes de protocole (documentées dans la Section 10) que les implémenteurs DOIVENT (MUST) utiliser. Ces constantes incluent des valeurs de temporisation, des limites de réessai et d'autres paramètres essentiels à l'interopérabilité.

13.4. Drapeaux de Router Advertisement

L'IANA maintient un registre pour les drapeaux de Router Advertisement. Les drapeaux suivants sont définis dans cette spécification :

BitNom du DrapeauRéférence
0M (Managed Address Configuration)RFC 4861, Section 4.2
1O (Other Configuration)RFC 4861, Section 4.2
2-7RéservéRFC 4861

Des drapeaux supplémentaires peuvent être définis dans des spécifications futures suivant les procédures IETF Review.

13.5. Drapeaux de l'Option Prefix Information

L'IANA maintient un registre pour les drapeaux de l'option Prefix Information. Les drapeaux suivants sont définis dans cette spécification :

BitNom du DrapeauRéférence
0L (On-Link)RFC 4861, Section 4.6.2
1A (Autonomous Address Configuration)RFC 4861, Section 4.6.2
2R (Router Address)RFC 6275
3-7RéservéRFC 4861

Note : Le drapeau R a été ajouté par RFC 6275 (Mobile IPv6) et est inclus ici pour être complet.

13.6. Drapeaux de Neighbor Advertisement

L'IANA maintient un registre pour les drapeaux de Neighbor Advertisement. Les drapeaux suivants sont définis dans cette spécification :

BitNom du DrapeauRéférence
0R (Router)RFC 4861, Section 4.4
1S (Solicited)RFC 4861, Section 4.4
2O (Override)RFC 4861, Section 4.4
3-31RéservéRFC 4861

13.7. Mises à Jour des Enregistrements Précédents

Ce document (RFC 4861) rend obsolète RFC 2461. Tous les enregistrements IANA qui référençaient RFC 2461 ont été mis à jour pour référencer RFC 4861 à la place.

13.8. Considérations pour les Extensions Futures

Lors de la définition de nouveaux messages, options ou drapeaux Neighbor Discovery :

  1. Compatibilité Ascendante : Assurez-vous que les nouvelles fonctionnalités peuvent coexister avec les implémentations existantes. Les options inconnues DOIVENT (MUST) être ignorées silencieusement comme spécifié dans la Section 9.

  2. Implications de Sécurité : Considérez comment les nouvelles fonctionnalités interagissent avec les mécanismes de sécurité tels que SEcure Neighbor Discovery (SEND) [RFC3971].

  3. Exigences de Documentation : Documentez complètement la nouvelle fonctionnalité dans une RFC ou une autre référence permanente et publiquement accessible.

  4. Enregistrement IANA : Suivez les procédures appropriées d'enregistrement IANA comme spécifié dans RFC 8126.

  5. Expérience d'Implémentation : Lorsque possible, acquérez une expérience d'implémentation et de déploiement avant la standardisation.

13.9. Références aux Registres IANA

Les registres IANA actuels liés à Neighbor Discovery peuvent être trouvés à :

Les implémenteurs et concepteurs de protocoles doivent consulter ces registres pour obtenir les informations les plus à jour sur les valeurs enregistrées.