Annexe B. Changements depuis RFC 3484

Certains changements ont été apportés à la table de politique par défaut qui ont été jugés universellement utiles et ne causant aucun dommage dans tout environnement réseau raisonnable. Ce faisant, soin a été pris d'utiliser les mêmes valeurs de précédence et d'étiquette que dans le RFC 3484 chaque fois que possible et pour les nouvelles lignes d'utiliser des valeurs d'étiquette moins susceptibles d'entrer en collision avec des valeurs qui pourraient déjà être utilisées dans des lignes supplémentaires sur certains hôtes. Ces changements sont:

1. Ajout du préfixe Teredo [RFC4380] (2001::/32), avec les valeurs de précédence et d'étiquette déjà largement utilisées dans les implémentations populaires.

2. Ajout d'une ligne pour les ULA (fc00::/7) sous IPv6 natif car elles ne sont pas globalement joignables, comme discuté dans la Section 10.6.

3. Ajout d'une ligne pour les adresses site-local (fec0::/10) afin de les déprécier, pour cohérence avec l'exemple dans la Section 10.3, car elles sont dépréciées [RFC3879].

4. Dépréciation de 6to4 (2002::/32) sous IPv4 natif car la connectivité 6to4 est moins fiable aujourd'hui (et est attendue être progressivement éliminée avec le temps, plutôt que de devenir plus fiable). Elle reste au-dessus de Teredo car 6to4 est plus efficace en termes de temps d'établissement de connexion, de bande passante et de charge serveur.

5. Dépréciation des adresses compatibles IPv4 (::/96) car elles sont maintenant dépréciées [RFC4291] et ne sont pas couramment utilisées.

6. Ajout d'une ligne pour les adresses de test 6bone (3ffe::/16) afin de les déprécier car elles ont également été progressivement éliminées [RFC3701].

7. Ajout de la capacité optionnelle pour une implémentation d'ajouter des lignes automatiques à la table pour les préfixes ULA spécifiques au site et les préfixes 6to4 natifs spécifiques au site.

De même, certains changements ont été apportés aux règles, comme suit:

1. Changement de la définition de CommonPrefixLen() pour comparer uniquement les bits jusqu'à la longueur de préfixe de l'adresse source. La définition précédente utilisait l'adresse source entière, plutôt que seulement son préfixe. En conséquence, lorsqu'une adresse source et une adresse de destination avaient le même préfixe, les bits communs dans l'identifiant d'interface auraient précédemment résulté en un remplacement de l'équilibrage de charge DNS [RFC1794] en forçant l'adresse de destination avec le plus de bits en commun à être toujours choisie. La définition mise à jour permet à l'équilibrage de charge DNS de continuer à être utilisé comme départage.

2. Ajout de la règle 5.5 pour permettre de choisir une adresse source d'un préfixe annoncé par le prochain saut choisi pour une destination donnée. Cela permet une meilleure connectivité en présence de filtrage d'entrée BCP 38 [RFC2827] et de filtrage de sortie. Précédemment, le RFC 3484 avait des problèmes avec plusieurs réseaux de sortie atteints via la même interface, comme discuté dans [RFC5220].

3. Suppression de la restriction contre les adresses anycast dans l'ensemble candidat d'adresses source, car la restriction contre l'utilisation d'adresses anycast IPv6 comme adresses source a été supprimée dans la Section 2.6 du RFC 4291 [RFC4291].

4. Changement du mappage des adresses RFC 1918 [RFC1918] à la portée globale dans la Section 3.2. Précédemment, elles étaient mappées à la portée site-local. Cependant, l'expérience a résulté en des implémentations actuelles utilisant déjà la portée globale à la place. Lorsqu'elles étaient mappées à site-local, la règle 2 de sélection d'adresse de destination (Préférer la portée correspondante) causerait qu'IPv6 soit préféré dans des scénarios tels que celui décrit dans la Section 10.7. Le changement à la portée globale permet la configurabilité via la table de politique de préfixe.

5. Changement de la recommandation par défaut pour la règle 7 de sélection d'adresse source pour préférer les adresses temporaires plutôt que les adresses publiques, tout en fournissant un remplacement administratif (en plus du remplacement spécifique à l'application qui était déjà spécifié). Ce changement a été effectué en raison de l'importance croissante des considérations de confidentialité, ainsi que du fait que des implémentations largement déployées ont préféré les adresses temporaires pendant de nombreuses années sans problèmes d'application majeurs.

Enfin, certains changements éditoriaux ont été effectués, incluant:

1. Changement des adresses IP globales dans les exemples pour utiliser des plages réservées pour la documentation.

2. Ajout d'exemples supplémentaires dans les Sections 10.6 et 10.7.

3. Ajout de la Section 10.3.1 sur IPv6 "défaillant".

4. Mise à jour des références.