Aller au contenu principal

5. Protocol Specification (Spécification du protocole)

L'autoconfiguration s'exécute sur une base par interface sur les interfaces prenant en charge le multicast. Pour les machines multihébergées, l'autoconfiguration s'exécute indépendamment sur chaque interface. L'autoconfiguration s'applique principalement aux hôtes, avec deux exceptions. Les routeurs sont censés générer une adresse link-local en utilisant la procédure décrite ci-dessous. De plus, les routeurs effectuent la détection d'adresse dupliquée sur toutes les adresses avant de les assigner à une interface.

5.1. Node Configuration Variables (Variables de configuration de nœud)​

Un nœud doit (MUST) permettre la configuration par l'administration système des variables liées à l'autoconfiguration suivantes pour chaque interface prenant en charge le multicast:

DupAddrDetectTransmits - Le nombre de messages de sollicitation de voisin consécutifs envoyés lors de l'exécution de la détection d'adresse dupliquée sur une adresse provisoire. Une valeur de zéro indique que la détection d'adresse dupliquée n'est pas effectuée sur les adresses provisoires. Une valeur de un indique une seule transmission sans retransmission ultérieure.

Valeur par défaut: 1, mais peut être remplacée par une valeur spécifique au type de liaison dans un document spécifique au type de liaison qui couvre les problèmes liés à la transmission d'IP sur un type de liaison particulier (par exemple, [RFC2464]).

L'autoconfiguration suppose également l'existence de la variable RetransTimer définie dans [RFC4861]. Aux fins de l'autoconfiguration, RetransTimer spécifie le délai entre les transmissions consécutives de sollicitations de voisin effectuées pendant la détection d'adresse dupliquée (si DupAddrDetectTransmits est supérieur à un), ainsi que le temps qu'un nœud attend après avoir envoyé la dernière sollicitation de voisin avant de terminer le processus de détection d'adresse dupliquée.

Au-delà de la formation d'une adresse link-local et de l'utilisation de la détection d'adresse dupliquée, la façon dont les routeurs (auto)configurent leurs interfaces est en dehors du champ d'application de ce document.

Les hôtes maintiennent une liste d'adresses et leurs durées de vie correspondantes. La liste d'adresses contient à la fois des adresses autoconfigurées et configurées manuellement.

Un nœud forme une adresse link-local chaque fois qu'une interface est activée. Une interface peut être activée après l'un des événements suivants:

  • L'interface est initialisée au démarrage du système.
  • L'interface est réinitialisée après une panne temporaire de l'interface ou après avoir été temporairement désactivée par l'administration système.
  • L'interface est attachée à un lien pour la première fois. Cela comprend les cas où le lien attaché change dynamiquement en raison d'un changement de point d'accès réseau sans fil.
  • L'interface est activée par l'administration système après avoir été administrativement désactivée.

L'adresse link-local est formée en combinant le préfixe link-local bien connu FE80::0 [RFC4291] (de longueur appropriée) avec un identifiant d'interface comme suit:

  1. Les bits les plus à gauche 'longueur de préfixe' de l'adresse sont les bits du préfixe link-local.
  2. Les bits de l'adresse à droite du préfixe link-local sont tous mis à zéro.
  3. Si la longueur de l'identifiant d'interface est de N bits, les N bits les plus à droite de l'adresse sont remplacés par l'identifiant d'interface.

Si la somme de la longueur du préfixe link-local et de N est supérieure à 128, l'autoconfiguration échoue et une configuration manuelle est requise. La longueur de l'identifiant d'interface est définie dans un document séparé spécifique au type de liaison, qui doit également être cohérent avec l'architecture d'adressage [RFC4291] (voir Section 2). Ces documents définiront soigneusement les longueurs afin qu'une adresse link-local puisse être autoconfigurée sur un lien.

Une adresse link-local a une durée de vie préférée et valide infinie; elle ne expire jamais.

5.4. Duplicate Address Detection (Détection d'adresse dupliquée)​

La détection d'adresse dupliquée doit (MUST) être effectuée sur toutes les adresses unicast avant de les assigner à une interface, qu'elles soient obtenues par autoconfiguration sans état, DHCPv6 ou configuration manuelle, avec les exceptions suivantes:

  • Les interfaces où la variable DupAddrDetectTransmits est définie sur zéro n'effectuent pas de détection d'adresse dupliquée.

  • Une adresse unicast dont on sait qu'elle est unique (par exemple, une adresse obtenue par configuration manuelle avec état ou DHCPv6 en utilisant un mécanisme suffisant pour prévenir la duplication) peut (MAY) effectuer la détection d'adresse dupliquée (mais ce n'est pas obligatoire (MUST NOT)).

  • La détection d'adresse dupliquée ne doit pas (MUST NOT) être effectuée sur les adresses anycast (notez qu'une adresse anycast ne peut pas être syntaxiquement distinguée d'une adresse unicast).

  • Chaque adresse unicast individuelle devrait (SHOULD) être testée pour son unicité. Notez que les implémentations déployées effectuent uniquement la détection d'adresse dupliquée pour les adresses link-local et sautent le test pour les adresses globales qui utilisent le même identifiant d'interface que l'adresse link-local. Bien que ce document n'invalide pas ces implémentations, cette "optimisation" n'est pas recommandée (NOT RECOMMENDED), et les nouvelles implémentations ne doivent pas (MUST NOT) effectuer cette optimisation. Cette optimisation provient de l'hypothèse selon laquelle toutes les adresses d'interface sont générées à partir du même identifiant. Cependant, cette hypothèse n'est en fait pas vraie; de nouveaux types d'adresses ont été introduits où les identifiants d'interface pour toutes les adresses unicast sur une seule interface ne sont pas nécessairement les mêmes [RFC4941] [RFC3972]. L'exigence d'effectuer la détection d'adresse dupliquée pour toutes les adresses unicast rendra l'algorithme robuste pour les identifiants d'interface spéciaux actuels et futurs.

La procédure de détection des adresses dupliquées utilise les messages de sollicitation et d'annonce de voisin, comme décrit ci-dessous. Si une adresse dupliquée est découverte pendant la procédure, l'adresse ne peut pas être assignée à l'interface. Si l'adresse est dérivée d'un identifiant d'interface, un nouvel identifiant doit être assigné à l'interface, ou toutes les adresses IP pour l'interface doivent être configurées manuellement. Notez que la procédure de détection des adresses dupliquées n'est pas complètement fiable, et il est toujours possible que des adresses dupliquées existent (par exemple, si le lien a été partitionné pendant l'exécution de la détection d'adresse dupliquée).

Une adresse sur laquelle la procédure de détection d'adresse dupliquée est appliquée est dite provisoire jusqu'à ce que la procédure soit terminée avec succès. Une adresse provisoire n'est pas considérée comme "assignée à une interface" au sens traditionnel. C'est-à-dire que l'interface doit accepter les messages de sollicitation et d'annonce de voisin contenant l'adresse provisoire dans le champ adresse cible, mais le traitement de ces paquets est différent de celui des paquets dont l'adresse cible correspond à une adresse assignée à l'interface. Les autres paquets dirigés vers l'adresse provisoire devraient être jetés silencieusement. Notez que les "autres paquets" incluent les messages de sollicitation et d'annonce de voisin qui ont l'adresse provisoire (c'est-à-dire, unicast) comme adresse de destination IP et l'adresse provisoire dans le champ adresse cible. Cependant, ces messages ne devraient pas se produire dans une opération normale parce que ces messages sont multicast dans la procédure de détection d'adresse dupliquée.

Il convient également de noter que la détection d'adresse dupliquée doit être effectuée avant d'assigner l'adresse à l'interface afin d'éviter que plusieurs nœuds n'utilisent la même adresse simultanément. Si un nœud commence à utiliser une adresse en parallèle avec l'exécution de la détection d'adresse dupliquée, et qu'un autre nœud est déjà en train d'utiliser l'adresse, le nœud effectuant la détection d'adresse dupliquée traiterait incorrectement le trafic adressé à l'autre nœud, ce qui entraînerait des conséquences négatives possibles telles que la réinitialisation des connexions TCP ouvertes.

Les sous-sections suivantes décrivent les tests spécifiques qu'un nœud effectue pour vérifier l'unicité d'une adresse. Si aucun des tests n'indique la présence d'une adresse dupliquée dans les RetransTimer millisecondes après l'envoi de DupAddrDetectTransmits sollicitations de voisin, l'adresse est considérée comme unique. Une fois que l'adresse est déterminée comme étant unique, elle peut être assignée à l'interface.

5.4.1. Message Validation (Validation de message)​

Un nœud doit (MUST) jeter silencieusement tout message de sollicitation ou d'annonce de voisin qui ne passe pas les vérifications de validité spécifiées dans [RFC4861]. Un message de sollicitation ou d'annonce de voisin qui passe ces vérifications de validité est appelé respectivement une sollicitation valide ou une annonce valide.

5.4.2. Sending Neighbor Solicitation Messages (Envoi de messages de sollicitation de voisin)​

Avant d'envoyer une sollicitation de voisin, une interface doit (MUST) rejoindre l'adresse multicast all-nodes et l'adresse multicast solicited-node de l'adresse provisoire. La première assure que le nœud reçoit les annonces de voisin des autres nœuds déjà en train d'utiliser l'adresse; la seconde assure que deux nœuds tentant simultanément d'utiliser la même adresse devraient détecter la présence l'un de l'autre.

Pour vérifier une adresse, un nœud envoie DupAddrDetectTransmits sollicitations de voisin, chacune séparée par RetransTimer millisecondes. L'adresse cible de la sollicitation est définie sur l'adresse en cours de vérification, l'adresse source IP est définie sur l'adresse non spécifiée et l'adresse de destination IP est définie sur l'adresse multicast solicited-node de l'adresse cible.

Si la sollicitation de voisin devait être le premier paquet envoyé depuis l'interface après (ré)initialisation de l'interface, le nœud devrait (SHOULD) retarder la jonction de l'adresse multicast solicited-node par un délai aléatoire entre 0 et MAX_RTR_SOLICITATION_DELAY tel que spécifié dans [RFC4861]. Cela aide à atténuer la congestion lorsque de nombreux nœuds démarrent sur un lien simultanément (par exemple, après une panne de courant) et peut aider à éviter les conditions de concurrence lorsque plusieurs nœuds tentent de solliciter la même adresse simultanément.

Même si la sollicitation de voisin n'est pas le premier paquet à envoyer, le nœud devrait (SHOULD) retarder la jonction de l'adresse multicast solicited-node par un délai aléatoire entre 0 et MAX_RTR_SOLICITATION_DELAY si l'adresse en cours de vérification est configurée par un message d'annonce de routeur envoyé à une adresse multicast. Le délai évitera une congestion similaire lorsque plusieurs nœuds configurent des adresses en recevant la même annonce de routeur multicast unique.

Notez que lorsqu'un nœud rejoint une adresse multicast, il envoie généralement un message de rapport Multicast Listener Discovery (MLD) [RFC2710] [RFC3810] pour l'adresse multicast. Dans le cas de la détection d'adresse dupliquée, le rapport MLD est nécessaire pour informer les commutateurs écoutant MLD (plutôt que les routeurs) de transférer les paquets multicast. Dans la description ci-dessus, le retard de jonction de l'adresse multicast implique donc de retarder la transmission du message de rapport MLD correspondant. Étant donné que la spécification MLD ne nécessite pas de délai aléatoire pour éviter les conditions de concurrence, retarder uniquement la sollicitation de voisin entraînerait une congestion des messages de rapport MLD. La congestion empêcherait alors les commutateurs écoutant MLD de fonctionner correctement, empêchant ainsi la détection d'adresse dupliquée de fonctionner. L'exigence d'inclure le retard du rapport MLD dans ce cas évite cette situation. [RFC3590] discute également de certains problèmes d'interaction entre la détection d'adresse dupliquée et MLD et spécifie quelle adresse source devrait être utilisée pour les rapports MLD dans ce cas.

Pour améliorer la robustesse de l'algorithme de détection d'adresse dupliquée, une interface doit (MUST) recevoir et traiter les datagrammes envoyés à l'adresse multicast all-nodes ou à l'adresse multicast solicited-node de l'adresse provisoire pendant la période de retard. Cela n'est pas nécessairement en conflit avec l'exigence de retarder la jonction du groupe multicast. En effet, dans certains cas, un nœud peut commencer à écouter le groupe pendant la période de retard avant la transmission du rapport MLD. Cependant, il convient de noter que dans certains environnements de couche liaison, en particulier avec les commutateurs écoutant MLD, il ne sera pas possible de recevoir le multicast avant d'envoyer le rapport MLD.

5.4.3. Receiving Neighbor Solicitation Messages (Réception de messages de sollicitation de voisin)​

En réception, un nœud doit (MUST) vérifier si l'adresse cible ou l'adresse source d'une sollicitation de voisin correspond à une adresse provisoire. S'il y a correspondance, la sollicitation de voisin concerne une adresse pour laquelle la détection d'adresse dupliquée est en cours. Le traitement diffère selon que l'adresse cible ou l'adresse source correspond.

Si l'adresse cible correspond à l'adresse provisoire:

L'adresse source de la sollicitation de voisin fait référence à l'adresse source IP de l'expéditeur. Si l'adresse source IP de la sollicitation de voisin est l'adresse non spécifiée (0:0:0:0:0:0:0:0), la source effectue une détection d'adresse dupliquée pour cette adresse, donc la sollicitation de voisin a été envoyée par la détection d'adresse dupliquée. Sinon, la source utilise l'adresse comme une adresse unicast. Dans les deux cas, la sollicitation de voisin indique que l'adresse provisoire du nœud est dupliquée. La sollicitation de voisin indique que l'expéditeur de la sollicitation de voisin tentant de vérifier que l'adresse provisoire du nœud n'est pas dupliquée ne le fera pas. La sollicitation de voisin indique que l'adresse est dupliquée.

Un nœud qui reçoit une telle sollicitation de voisin ne doit pas (MUST NOT) envoyer une annonce de voisin (sinon, l'adresse est provisoire et ne devrait pas encore (SHOULD NOT) être utilisée). Au lieu de cela, la réception d'une telle sollicitation de voisin indique que l'adresse provisoire en cours de vérification est dupliquée, donc le nœud doit (MUST) arrêter immédiatement le processus d'envoi de sollicitations de voisin.

Si l'adresse source correspond à l'adresse provisoire:

Cela indique qu'un autre nœud utilise également la même adresse comme provisoire et effectue simultanément la détection d'adresse dupliquée. C'est un phénomène attendu lorsque plusieurs interfaces sont initialisées simultanément (par exemple, au démarrage du système). Cependant, la réception de cette sollicitation de voisin indique que l'adresse est dupliquée, donc le nœud doit (MUST) arrêter immédiatement l'envoi de sollicitations de voisin.

Un nœud peut recevoir une sollicitation de voisin pendant que la détection de voisin est en cours, mais après avoir déjà arrêté l'envoi avant que la duplication ne soit détectée. Dans ce cas, la sollicitation de voisin devrait (SHOULD) être ignorée (à l'exception du cas de la Section 5.4.4).

5.4.4. Receiving Neighbor Advertisement Messages (Réception de messages d'annonce de voisin)​

Pour la détection d'adresse dupliquée (DAD), un nœud doit (MUST) vérifier si l'adresse cible de la sollicitation de voisin correspond à une adresse provisoire et si l'adresse cible de l'annonce de voisin correspond à l'adresse provisoire. Si elle correspond, l'annonce de voisin indique que l'adresse est dupliquée. Si elle ne correspond pas, l'annonce n'est pas pertinente.

Lors de la réception d'une annonce de voisin avec une adresse cible correspondant à une adresse provisoire, un nœud doit (MUST) arrêter l'envoi de sollicitations de voisin et détecte que l'adresse est utilisée sur le lien.

5.4.5. When Duplicate Address Detection Fails (Lorsque la détection d'adresse dupliquée échoue)​

Une adresse provisoire déterminée comme dupliquée comme décrit ci-dessus ne doit pas (MUST NOT) être assignée à une interface, et le nœud devrait (SHOULD) enregistrer une erreur d'administration système.

Si l'adresse est une adresse link-local formée à partir d'un identifiant d'interface basé sur une adresse matérielle qui devrait être assignée de manière unique (par exemple, un EUI-64 pour une interface Ethernet), les opérations IP sur l'interface devraient (SHOULD) être désactivées. En désactivant les opérations IP, le nœud:

  • N'enverra aucun paquet IP depuis l'interface,
  • Jettera silencieusement tous les paquets IP reçus sur l'interface, et
  • Ne transmettra aucun paquet IP vers l'interface (lorsqu'il agit comme routeur ou traite des paquets avec un en-tête de routage).

Dans ce cas, la duplication d'adresse IP peut signifier qu'une adresse matérielle dupliquée est utilisée, et tenter de récupérer en configurant une autre adresse IP ne conduira pas à un réseau utilisable. En fait, cela peut aggraver la situation en créant des problèmes plus difficiles à diagnostiquer que la simple désactivation des opérations réseau sur l'interface; l'utilisateur verra un réseau partiellement fonctionnel où certaines choses fonctionnent et d'autres non.

D'autre part, si l'adresse link-local dupliquée n'est pas formée à partir d'un identifiant d'interface basé sur une adresse matérielle qui devrait être assignée de manière unique, les opérations IP peuvent (MAY) continuer sur l'interface.

Note: Comme indiqué à la Section 2, "IP" dans la description ci-dessus signifie "IPv6". Bien que le raisonnement de fond concernant les adresses matérielles soit indépendant d'un protocole réseau spécifique, ses implications pour d'autres protocoles sont en dehors du champ d'application de ce document.

5.5. Creation of Global Addresses (Création d'adresses globales)​

Les adresses globales sont formées en ajoutant un identifiant d'interface à un préfixe de longueur appropriée. Les préfixes sont obtenus à partir des options d'information de préfixe contenues dans les annonces de routeur. La création d'adresses globales décrite dans cette section devrait (SHOULD) être configurable localement. Cependant, le traitement décrit ci-dessous doit (MUST) être activé par défaut.

5.5.1. Soliciting Router Advertisements (Sollicitation d'annonces de routeur)​

Les annonces de routeur sont envoyées périodiquement à l'adresse multicast all-nodes. Pour obtenir rapidement une annonce, un hôte envoie une sollicitation de routeur, comme décrit dans [RFC4861].

5.5.2. Absence of Router Advertisements (Absence d'annonces de routeur)​

Même s'il n'y a pas de routeurs sur le lien, un service DHCPv6 pour obtenir des adresses peut toujours être disponible, et un hôte peut souhaiter utiliser ce service. Du point de vue de l'autoconfiguration, si aucune annonce de routeur n'est reçue après avoir envoyé quelques sollicitations de routeur (comme décrit dans [RFC4861]), il n'y a pas de routeurs sur le lien.

Notez que, dans ce sens, il peut ne pas y avoir de routeurs sur le lien, mais qu'il y ait un nœud avec la capacité de transférer des paquets. Dans ce cas, l'adresse du nœud de transfert doit être configurée manuellement dans l'hôte pour envoyer des paquets hors lien, car le seul mécanisme pour autoconfigurer l'adresse du routeur par défaut est le mécanisme des annonces de routeur.

5.5.3. Router Advertisement Processing (Traitement des annonces de routeur)​

Pour chaque option d'information de préfixe dans une annonce de routeur:

a) Si le drapeau autonome n'est pas défini, ignorer silencieusement l'option d'information de préfixe.

b) Si le préfixe est le préfixe link-local, ignorer silencieusement l'option d'information de préfixe.

c) Si la durée de vie préférée est supérieure à la durée de vie valide, ignorer silencieusement l'option d'information de préfixe. Dans ce cas, un nœud peut (MAY) vouloir enregistrer une erreur d'administration système.

d) Si le préfixe annoncé n'est pas égal au préfixe d'une adresse autoconfigurée sans état déjà dans la liste associée à l'interface (où "égal" signifie que les deux longueurs de préfixe sont les mêmes et que les bits de longueur de préfixe du préfixe sont identiques), et si la durée de vie valide n'est pas zéro, former une adresse (et l'ajouter à la liste) en combinant le préfixe annoncé avec l'identifiant d'interface du lien comme suit:

|            128 - N bits               |       N bits           |
+---------------------------------------+------------------------+
|            link prefix                |  interface identifier  |
+----------------------------------------------------------------+

Si la somme de la longueur du préfixe et de la longueur de l'identifiant d'interface n'est pas égale à 128 bits, l'option d'information de préfixe doit (MUST) être ignorée. Dans ce cas, une implémentation peut (MAY) vouloir enregistrer une erreur d'administration système. La longueur de l'identifiant d'interface est définie dans un document séparé spécifique au type de liaison, qui doit également être cohérent avec l'architecture d'adressage [RFC4291] (voir Section 2).

Il incombe à l'administrateur système de s'assurer que la longueur des préfixes contenus dans les annonces de routeur est cohérente avec la longueur de l'identifiant d'interface pour ce type de liaison. Cependant, il convient de noter que cela ne signifie pas que la longueur du préfixe annoncé est sans signification. En fait, la longueur annoncée a une signification non triviale pour la détermination on-link dans [RFC4861], où la somme de la longueur du préfixe et de la longueur de l'identifiant d'interface peut ne pas être égale à 128. Par conséquent, il devrait être sûr de valider ici la longueur du préfixe annoncé pour détecter et éviter les erreurs de configuration spécifiant des longueurs de préfixe non valides dans le contexte de l'autoconfiguration d'adresse.

Notez que les versions futures de l'architecture d'adressage [RFC4291] et les futurs documents spécifiques au type de liaison (qui seront toujours cohérents les uns avec les autres) peuvent permettre des identifiants d'interface de longueurs autres que les valeurs définies dans les documents actuels. Par conséquent, les implémentations ne devraient pas (SHOULD NOT) supposer une constante particulière. Au lieu de cela, elles devraient s'attendre à des identifiants d'interface de n'importe quelle longueur.

Si l'adresse est formée avec succès et qu'elle n'est pas déjà dans la liste, l'hôte l'ajoute à la liste des adresses assignées à l'interface, en initialisant ses valeurs de durée de vie préférée et valide à partir de l'option d'information de préfixe. Notez que la vérification effectuée sur le préfixe au début de cette étape ne détecte pas toujours les conflits d'adresse dans la liste. Il est possible qu'une adresse qui existe déjà dans la liste (via une configuration manuelle ou DHCPv6) se trouve être identique à l'adresse nouvellement créée, et cela devrait être une situation atypique.

e) Si le préfixe annoncé est égal au préfixe d'une adresse dans la liste qui a été configurée par autoconfiguration sans état, la durée de vie préférée de l'adresse est réinitialisée à la durée de vie préférée dans l'annonce reçue. L'opération spécifique effectuée sur la durée de vie valide de l'adresse dépend de la durée de vie valide dans l'annonce reçue et du temps restant jusqu'à ce que la durée de vie valide de l'adresse autoconfigurée précédemment n'expire. Dans la discussion suivante, nous appellerons le temps restant "RemainingLifetime":

  1. Si la durée de vie valide reçue est supérieure à 2 heures ou supérieure à RemainingLifetime, définir la durée de vie valide de l'adresse correspondante sur la durée de vie valide annoncée.
  2. Si RemainingLifetime est inférieur ou égal à 2 heures, ignorer l'option d'information de préfixe concernant la durée de vie valide, à moins que l'annonce de routeur dont cette option a été obtenue n'ait été authentifiée (par exemple, via Secure Neighbor Discovery [RFC3971]). Si l'annonce de routeur a été authentifiée, la durée de vie valide de l'adresse correspondante devrait (SHOULD) être définie sur la durée de vie valide dans l'option reçue.
  3. Sinon, réinitialiser la durée de vie valide de l'adresse correspondante à 2 heures.

Les règles ci-dessus traitent d'une attaque par déni de service spécifique où des annonces forgées pourraient contenir des préfixes avec de très courtes durées de vie valides. Sans les règles ci-dessus, une seule annonce non authentifiée contenant une option d'information de préfixe forgée avec une courte durée de vie valide pourrait faire expirer prématurément toutes les adresses d'un nœud. Les règles ci-dessus garantissent que les annonces légitimes (qui sont envoyées périodiquement) les "annuleront" avant que la courte durée de vie valide ne prenne réellement effet.

Notez que la durée de vie préférée de l'adresse correspondante est toujours réinitialisée à la durée de vie préférée dans l'option d'information de préfixe reçue, que la durée de vie valide soit réinitialisée ou ignorée. La différence provient du fait que les attaques possibles sur la durée de vie préférée sont relativement mineures. De plus, ignorer la durée de vie préférée n'est même pas souhaitable lorsqu'un administrateur légitime souhaite déprécier une adresse particulière en envoyant une courte durée de vie préférée (et que la durée de vie valide est accidentellement ignorée).

5.5.4. Address Lifetime Expiry (Expiration de la durée de vie de l'adresse)​

Lorsque la durée de vie préférée d'une adresse préférée expire, l'adresse préférée devient dépréciée. Une adresse dépréciée devrait (SHOULD) continuer à être utilisée comme adresse source dans les communications existantes, mais ne devrait pas (SHOULD NOT) être utilisée pour initier de nouvelles communications si une adresse alternative (non dépréciée) de portée suffisante peut être facilement utilisée.

Notez que la faisabilité d'utiliser une adresse non dépréciée pour initier de nouvelles communications peut être une décision spécifique à l'application, car seule l'application peut savoir si l'adresse (maintenant) dépréciée est (ou est toujours) utilisée par l'application. Par exemple, si une application spécifie explicitement à la pile de protocoles d'utiliser l'adresse dépréciée comme adresse source, la pile de protocoles doit l'accepter; l'application peut le demander parce que cette adresse IP est utilisée dans la communication de niveau supérieur et peut exiger que plusieurs connexions dans de tels paquets utilisent la même paire d'adresses IP.

IP et les couches supérieures (par exemple, TCP, UDP) doivent (MUST) continuer à accepter et traiter les datagrammes envoyés à une adresse dépréciée, car une adresse dépréciée est toujours une adresse valide pour l'interface. Dans le cas de TCP, cela signifie répondre à un segment TCP SYN envoyé à une adresse dépréciée en utilisant l'adresse dépréciée comme adresse source dans le SYN-ACK correspondant (si cette connexion sera permise).

Les implémentations peuvent (MAY) empêcher toute nouvelle communication d'utiliser une adresse dépréciée, mais l'administration système doit (MUST) avoir la capacité de désactiver une telle installation, et cette installation doit (MUST) être désactivée par défaut.

Il convient également de noter d'autres cas subtils de sélection d'adresse source. Par exemple, la description ci-dessus ne clarifie pas quelle adresse devrait être utilisée entre une adresse dépréciée de portée plus petite et une adresse non dépréciée de portée suffisante. Les détails de la sélection d'adresse incluant ce cas sont décrits dans [RFC3484] et sont en dehors du champ d'application de ce document.

Lorsque la durée de vie valide d'une adresse (et son association avec une interface) expire, l'adresse devient invalide. Une adresse invalide ne doit pas (MUST NOT) être utilisée comme adresse source dans les communications sortantes et ne doit pas (MUST NOT) être reconnue comme destination sur l'interface de réception.

5.6. Configuration Consistency (Cohérence de la configuration)​

Un hôte peut utiliser simultanément l'autoconfiguration sans état et DHCPv6 pour obtenir des informations d'adresse, car les deux peuvent être activés en même temps. Les valeurs d'autres paramètres de configuration (comme la taille MTU et la limite de sauts) peuvent également être apprises à partir des annonces de routeur et de DHCPv6. Si les mêmes informations de configuration sont fournies par plusieurs sources, les valeurs de cette information devraient être cohérentes. Cependant, si les informations reçues de plusieurs sources ne sont pas cohérentes, ce n'est pas considéré comme une erreur fatale. Un hôte accepte l'union de toutes les informations reçues via la découverte de voisins et DHCPv6.

Si des informations incohérentes sont apprises de différentes sources, les implémentations peuvent souhaiter privilégier les informations apprises de manière sécurisée plutôt que celles apprises sans protection. Par exemple, la Section 8 de [RFC3971] discute de la façon de traiter les conflits entre les informations apprises via Secure Neighbor Discovery et celles apprises via la découverte de voisins ordinaire. La même discussion peut s'appliquer à la préférence entre les informations apprises via la découverte de voisins ordinaire et celles apprises via DHCPv6 sécurisé, etc.

Dans tous les cas, en l'absence de différence de sécurité, les valeurs obtenues récemment devraient (SHOULD) être préférées aux informations apprises plus tôt.

5.7. Retaining Configured Addresses for Stability (Conservation des adresses configurées pour la stabilité)​

Les implémentations avec stockage stable peuvent souhaiter conserver les adresses dans le stockage lors de l'obtention d'adresses via l'autoconfiguration d'adresse sans état. En supposant que les durées de vie utilisées sont raisonnables, cette technique signifie qu'une interruption temporaire des routeurs (de moins que la durée de vie valide) ne causera jamais la perte de l'adresse globale d'un nœud, même si le nœud devait redémarrer. Lors de l'utilisation de cette technique, il convient également de noter que les délais d'expiration des durées de vie préférée et valide doivent être conservés pour empêcher l'utilisation de l'adresse après que l'adresse soit devenue dépréciée ou invalide.

Plus de détails sur cette extension sont en dehors du champ d'application de ce document.

Dernière mise à jour le