Appendix C. Changes since RFC 2462 (Modifications depuis RFC 2462)

Changements majeurs susceptibles d'affecter les implémentations existantes :

• Spécification que les nœuds effectuant la détection d'adresse dupliquée retardent leur adhésion au groupe multicast de nœud sollicité, plutôt que de simplement retarder l'envoi de la sollicitation de voisin, et explication des raisons détaillées.

• Ajout de l'exigence d'un délai aléatoire avant d'envoyer des sollicitations de voisin pour la détection d'adresse dupliquée si l'adresse vérifiée est configurée par une annonce de routeur multicast.

• Clarification que lorsque la détection d'adresse dupliquée échoue, l'opération du réseau IP devrait être désactivée, et que cette règle devrait s'appliquer dans les cas où les adresses matérielles devraient être uniques.

Clarifications majeures :

• Clarification de la manière de déterminer la longueur de l'identifiant d'interface, description de la relation avec la longueur de préfixe annoncée dans les annonces de routeur, et évitement du codage en dur de longueurs spécifiques dans ce document.

• Clarification du traitement des annonces de voisin reçues lors de l'exécution de la détection d'adresse dupliquée.

• Suppression du texte sur les drapeaux M et O, compte tenu de la maturité de l'implémentation et de l'expérience opérationnelle. Suppression correspondante de ManagedFlag et OtherConfigFlag. (Notez que ce changement ne signifie pas que l'utilisation de ces drapeaux est dépréciée.)

• Évitement de l'utilisation de la formulation « configuration avec état (Stateful Configuration) » qui est notoirement très confuse, et utilisation simplement de « DHCPv6 » aux endroits appropriés.

• Recommandation plus forte d'effectuer la détection d'adresse dupliquée sur toutes les adresses unicast, compte tenu de divers identifiants d'interface différents, tout en notant les implémentations existantes.

• Clarification de la formulation dans la section 5.5.4 pour rendre explicite que les adresses dépréciées spécifiées par une application peuvent être utilisées pour toute communication.

• Clarification de la vérification de préfixe décrite dans la section 5.5.3 en utilisant une terminologie plus appropriée, et clarification que cette vérification concerne les préfixes des adresses configurées via la configuration automatique sans état.

• Changement de la référence à l'en-tête d'authentification de sécurité IP en une référence à RFC 3971 (découverte de voisinage sécurisée). Révision également de la section sur les considérations de sécurité en utilisant une référence à RFC 3756.

• Ajout d'une note sur les cas où les implémentations utilisent un stockage stable pour les adresses de configuration automatique.

• Ajout de considérations sur la préférence d'informations incohérentes entre un ensemble d'informations provenant d'une source sécurisée et un autre appris sans protection.

Autres clarifications diverses :

• Suppression des références à site-local (Site-Local) et révision de la formulation autour de ce mot-clé.

• Suppression du code redondant de protection contre le déni de service dans la section 5.5.3.

• Clarification que les sollicitations ou annonces de voisin unicast devraient être jetées lors de l'exécution de la détection d'adresse dupliquée.

• Indication dans la section 5.3 qu'une interface peut être considérée comme devenue activée lorsque le point d'accès sans fil change.

---