Annexe A - Modifications depuis RFC 2463 (Changes since RFC 2463)

Les modifications suivantes ont été apportées par rapport à RFC 2463 :

• Édition du résumé pour le rendre un peu plus élaboré.

• Correction de fautes de frappe dans la Section 2.4, où les références au sous-point e.2 étaient censées être des références à e.3.

• Suppression des méthodes basées sur le temps et basées sur la bande passante de l'exemple de mécanisme de limitation du taux pour les messages d'erreur ICMP. Ajout de la méthode basée sur le seau à jetons (Token-bucket).

• Ajout d'une spécification selon laquelle tous les messages d'erreur ICMP doivent avoir exactement 32 bits de données spécifiques au type, afin que les récepteurs puissent trouver de manière fiable le paquet invoquant intégré même lorsqu'ils ne reconnaissent pas le type de message ICMP.

• Dans la description des messages Destination Unreachable, Code 3, ajout d'une règle interdisant le transfert de paquets sur les liens point à point à partir desquels ils ont été reçus, si leurs adresses de destination appartiennent au lien lui-même (règle "anti-ping-pong").

• Ajout d'une description de Time Exceeded Code 1 (dépassement du délai de réassemblage des fragments).

• Ajout des messages "beyond scope of source address", "source address failed ingress/egress policy", et "reject route to destination" à la famille des messages d'erreur ICMP de type "unreachable destination" (Section 3.1).

• Réservation de certaines valeurs de type ICMP pour l'expérimentation.

• Ajout d'une NOTE dans la Section 2.4 qui spécifie la priorité des règles de traitement des messages ICMP.

• Ajout d'ICMP REDIRECT à la liste dans la Section 2.4, (e) des cas dans lesquels les messages d'erreur ICMP ne doivent pas être générés.

• Apport de modifications éditoriales mineures dans la Section 2.3 sur le calcul de la somme de contrôle, et dans la Section 5.2.

• Clarification dans la Section 4.2, concernant le message Echo Reply ; l'adresse source d'une réponse d'écho à une demande d'écho anycast devrait être une adresse unicast, comme dans le cas du multicast.

• Révision de la section Considérations de sécurité. Ajout de l'utilisation de l'en-tête de charge utile de sécurité encapsulante pour l'authentification. Modification de l'exigence d'une option "ne pas autoriser les messages ICMP non authentifiés" de SHOULD à MAY.

• Ajout d'une nouvelle attaque dans la liste des attaques ICMP possibles dans la Section 5.2.

• Séparation des références en références normatives et informatives.

• Ajout d'une référence au RFC 2780 "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers". Ajout également d'une note indiquant que ce document met à jour le RFC 2780.

• Ajout d'une procédure pour les nouvelles attributions de valeurs de type et de code ICMPv6 dans la section Considérations IANA.

• Remplacement du mot "send" par "originate" pour clarifier que les paquets ICMP en cours de transfert sont hors de la portée de cette spécification.

• Modification des références ESP et AH pour les documents ESP et AH mis à jour.

• Ajout d'une référence au document mis à jour sur l'architecture de sécurité IPsec.

• Ajout d'une exigence SHOULD pour permettre de désactiver l'envoi de messages ICMP destination unreachable.

• Simplification de la sélection de l'adresse source du paquet ICMPv6.

• Réorganisation du format général des messages (Section 2.1).

• Suppression du format de paquet général de la Section 2.1. Il fait référence à RFC 2460 pour plus de détails.

---