Groupe de travail Réseau	R. Bonica, Juniper Networks
Request for Comments : 4884	D. Gan, Consultant
RFC mises à jour : 0792, 4443	D. Tappan, Consultant
Catégorie : Sur la voie de la normalisation	C. Pignataro, Cisco Systems, Inc.
Traduction Claude Brière de L'Isle	avril 2007

Extensions à ICMP pour la prise en charge des messages multi parties

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.
(La présente traduction incorpore l'errata 3.)

Notice de Copyright
Copyright (C) The IETF Trust (2007).

Résumé
Le présent document redéfinit les messages ICMP choisis pour prendre en charge le fonctionnement multi parties. Un message ICMP multi parties porte toutes les information que les messages ICMP portaient précédemment, ainsi que des informations supplémentaires que les applications peuvent exiger.

Les messages multi parties sont pris en charge par une structure d'extension ICMP. La structure d'extension est située à la fin du message ICMP. Elle inclut un en-tête d'extension suivi par un ou plusieurs objets d'extension. Chaque objet d'extension contient un en-tête d'objet et une charge utile d'objet. Tous les en-têtes d'objet ont un format commun.

Le présent document redéfinit de plus les messages ICMP sus-mentionnés en spécifiant un attribut de longueur. Tous les messages ICMP actuellement définis auxquels une structure d'extension peut être ajoutée incluent un champ "Datagramme original". Le champ "Datagramme original" contient les octets initiaux du datagramme qui a provoqué le message d'erreur ICMP. Bien que le champ Datagramme original soit de longueur variable, le message ICMP n'inclut pas de champ qui spécifie sa longueur. Donc, afin de faciliter l'analyse de message, le présent document alloue huit bits précédemment réservés pour refléter la longueur du champ "Datagramme original".

Les modifications proposées changent les exigences pour la conformité à ICMP. L'impact de ces changements sur la conformité des mises en œuvre est discutée, et de nouvelles exigences pour des futures mises en œuvre sont présentées.

Le présent mémoire met à jour les RFC 792 et 4443.
Table des matières
1. Introduction	2
2. Conventions utilisées dans le document	2
3. Résumé des changements à ICMP	2
4. Extensibilité de ICMP	3
4.1 ICMPv4 Destination injoignable	4
4.2 ICMPv4 Temps expiré	5
4.3 ICMPv4 Problème de paramètre	5
4.4 ICMPv6 Destination injoignable	6
4.5 ICMPv6 Temps expiré	6
4.6 Messages ICMP qui peuvent être étendus	6
5. Rétro compatibilité	6
5.1 Les applications classiques reçoivent les message ICMP avec extensions	7
5.2 Les applications non conformes reçoivent les messages ICMP sans extension	8
5.3 Les application non conformes reçoivent les messages ICMP avec des extensions conformes	8
5.4 Les application conformes reçoivent les messages ICMP sans extension	8
5.5 Les application conformes reçoivent les messages ICMP avec des extensions non conformes	8
6. Interaction avec la traduction d'adresse réseau	9
7. Structure d'extension ICMP 	9
8. Objets d'extension ICMP	9
9. Considérations sur la sécurité	10
10. Considérations relatives à l'IANA 	10
11. Remerciements	10
12. Références	10
12.1 Références normatives	10
12.2 Références pour information	11
Adresse des auteurs	11
Déclaration complète de droits de reproduction	11
 	1.	Introduction

Le présent document redéfinit les messages ICMPv4 [RFC0792] et ICMPv6 [RFC4443] choisis pour inclure une structure d'extension et un attribut de longueur. La structure d'extension prend en charge le fonctionnement multi parties ICMP. Les concepteurs de protocoles peuvent faire qu'un message ICMP porte des informations supplémentaires en codant ces informations dans la structure d'extension.

Le présent document traite aussi un problème fondamental de l'extensibilité ICMP. Tous les messages ICMP visés par le présent mémoire incluent un champ "Datagramme original". Le champ "Datagramme original" contient les octets initiaux du datagramme qui a provoqué le message d'erreur ICMP. Bien que le champ "Datagramme original" soit de longueur variable, le message ICMP n'inclut pas de champ qui spécifie sa longueur.

Le logiciel d'application déduit la longueur du champ "Datagramme original" de la longueur totale du message ICMP. Si une structure d'extension est ajoutée au message sans ajouter d'attribut de longueur pour le champ "Datagramme original", le message sera inanalysable. Précisément, le logiciel d'application ne sera pas capable de déterminer où se termine le champ "Datagramme original" et où commence la structure d'extension. Donc, le présent document propose un attribut Longueur ainsi qu'une structure d'extension qui est ajoutée au message ICMP.

Le présent mémoire traite aussi de la rétro compatibilité avec les mises en œuvre existantes de ICMP qui soit ne mettent pas en œuvre les extensions définies ici, soit les mettent en œuvre sans ajouter les attributs Longueur requis. En particulier, le présent document traite de la rétro compatibilité avec certaines mises en œuvre largement déployées de ICMPv4 à capacité MPLS qui envoient les extensions définies ici sans ajouter l'attribut Longueur requis.

Le présent mémoire ne définit aucun objet d'extension ICMP. Il définit seulement l'en-tête d'extension et un en-tête commun à tous les objets d'extension. Les [RFC5837], [ROUTING], et [RFC4950] fournissent un échantillon d'applications de l'objet Extension ICMP.

Les documents sus-mentionnés partagent une caractéristique. Ils ajoutent tous des informations au message ICMP Temps expiré à l'usage de TRACEROUTE. Dans ce cas, comme dans beaucoup d'autres, ajouter des informations au message ICMP Temps expiré existant est préférable à définir un nouveau message et émettre deux messages chaque fois qu'un paquet est éliminé à cause de l'expiration du TTL.

 	2.	Conventions utilisées dans le document
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	3.	Résumé des changements à ICMP

Voici un résumé des changements à ICMP introduits par le présent mémoire :

Une structure Extension ICMP PEUT être ajoutée aux messages ICMPv4 Destination injoignable, Temps expiré, et Problème de paramètre.

Une structure Extension ICMP PEUT être ajoutée aux messages Destination ICMPv6 injoignable, et Temps expiré.

Les messages sus mentionnés incluent un champ "Datagramme original", et les formats de message sont mis à jour pour spécifier un attribut Longueur au champ "Datagramme original".

Quand la structure Extension ICMP est ajoutée à un message ICMP et que le message ICMP contient un champ "Datagramme original", le champ "Datagramme original" DOIT contenir au moins 128 octets.

Quand la structure Extension ICMP est ajoutée à un message ICMP et que ce message ICMPv4 contient un champ "Datagramme original", le champ "Datagramme original" DOIT être bourré de zéros jusqu'à la plus proche limite de 32  bits.

Quand la structure Extension ICMP est ajoutée à un message ICMPv6 et que ce message ICMPv6 contient un champ "Datagramme original", le champ "Datagramme original" DOIT être bourré de zéros jusqu'à la plus proche limite de 64  bits.

Les messages ICMP définis à l'avenir DEVRAIENT indiquer si ils prennent ou non en charge le mécanisme d'extension défini dans la présente spécification. Il est recommandé que tous les nouveaux messages prennent en charge les extensions.

 	4.	Extensibilité de ICMP

La [RFC0792] définit les types de message ICMPv4 suivants :
- Destination injoignable
- Temps expiré
- Problème de paramètre
- Extinction de source
- Redirection
- Demande/Réponse d'écho
- Horodatage/Réponse d'horodatage
- Demande/Réponse d'informations

La [RFC1191] réserve des bits pour le champ "MTU du prochain bond" dans le message Destination injoignable.

La [RFC4443] définit les types suivants de message ICMPv6 :
- Destination injoignable
- Paquet trop gros
- Temps expiré
- Problème de paramètre
- Demande/Réponse d'écho

De nombreux messages ICMP sont extensibles tels qu'actuellement définis. Les concepteurs de protocoles peuvent étendre les messages ICMP en leur ajoutant simplement des champs ou des structures de données.

Cependant, les messages ICMP suivants ne sont pas extensibles tels qu'ils sont actuellement définis :
- Destination injoignable ICMPv4 (type = 3)
- Temps expiré ICMPv4 (type = 11)
- Problème de paramètre ICMPv4 (type = 12)
- Destination injoignable ICMPv6 (type = 1)
- Paquet trop gros ICMPv6 (type = 2)
- Temps expiré ICMPv6 (type = 3)
- Problème de paramètre ICMPv6 (type = 4)

Ces messages contiennent un champ "Datagramme original" qui représente les octets de tête du datagramme auquel le message ICMP est une réponse. La [RFC0792] définit le champ "Datagramme original" pour les messages ICMPv4. Dans la RFC 792, le champ "Datagramme original" inclut l'en-tête IP plus les huit prochains octets du datagramme original. La [RFC1812] étend le champ "Datagramme original" pour qu'il contienne autant d'octets que possible sans causer le dépassement par le message ICMP de la taille minimum de mémoire tampon de réassemblage IPv4 (c'est-à-dire, 576  octets).La [RFC4443] définit le champ "Datagramme original" pour les messages ICMPv6. Dans la RFC 4443, le champ "Datagramme original" contenait toujours autant d'octets que possible sans causer le dépassement par le message ICMP de la MTU minimum IPv6 (c'est-à-dire, 1280 octets).

Malheureusement, il manque au champ "Datagramme original" un attribut de longueur. Le logiciel d'application déduit la longueur de ce champ de la longueur totale du message ICMP. Si une structure d'extension était ajoutée au message sans ajouter d'attribut de longueur pour le champ "Datagramme original", le message deviendrait inanalysable. Précisément, le logiciel d'application ne serait pas capable de déterminer où se termine le champ "Datagramme original" et où commence la structure d'extension.

Afin de résoudre ce problème, le présent mémoire introduit un attribut Longueur de 8 bits aux messages ICMPv4 suivants.
- Destination injoignable (type = 3)
- Temps expiré (type = 11)
- Problème de paramètre (type = 12)

Il introduit aussi un attribut Longueur de 8 bits aux messages ICMPv6 suivants.
- Destination injoignable (type = 1)
- Temps expiré (type = 3)

L'attribut Longueur DOIT être spécifié quand la structure ICMP Extension est ajoutée aux messages ICMP sus-mentionnés.

L'attribut Longueur représente la longueur du champ "Datagramme original". L'espace pour l'attribut Longueur est prélevé sur les octets réservés dont il était précédement exigé que leur valeur soit zéro.

Pour les messages ICMPv4, l'attribut Longueur représente des mots de 32 bits. Quand l'attribut Longueur est spécifié, le champ "Datagramme original" DOIT être bourré de zéros jusqu'à la plus proche limite de 32 bits. Parce que le sixième octet de chacun des messages ICMPv4 impactés était réservé pour une utilisation future, cet octet a été choisi comme localisation de l'attribut Longueur dans ICMPv4.

Pour les messages ICMPv6, l'attribut Longueur représente des mots de 64 bits. Quand l'attribut Longueur est spécifié, le champ "Datagramme original" DOIT être bourré de zéros jusqu'à la plus proche limite de 64 bits. Parce que le cinquième octet de chacun des messages ICMPv6 impactés était réservé pour une utilisation future, cet octet a été choisi comme localisation de l'attribut Longueur dans ICMPv6.

Afin de réaliser la rétro compatibilité, quand la structure ICMP Extension est ajoutée à un message ICMP et que ce message ICMP contient un champ "Datagramme original", le champ "Datagramme original" DOIT contenir au moins 128  octets. Si le datagramme original ne contenait pas 128 octets, le champ "Datagramme original" DOIT être bourré de zéros sur 128 octets (voir la raison au paragraphe 5.1).

Les paragraphes qui suivent décrivent l'attribut Longueur comme il a été introduit dans les messages ICMP retenus.

 	4.1	ICMPv4 Destination injoignable
La Figure 1 décrit le message ICMPv4 Destination injoignable.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |      Somme de contrôle        |
+---------------+---------------+---------------+---------------+
|  non utilisé  |    Longueur   |      MTU du prochain bond*    |
+---------------+---------------+---------------+---------------+
|   En-tête Internet + octets de tête du datagramme original    |
|                                                               |
|                           //                                  |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 1 : ICMPv4 Destination injoignable

La syntaxe et la sémantique de tous les champs sont inchangées par rapport à la [RFC0792]. Cependant, un attribut Longueur est ajouté au second mot. L'attribut Longueur représente la longueur du champ "Datagramme original" avec bourrage, mesuré en mots de 32 bits.

*	Le champ MTU du prochain bond n'est pas exigé dans tous les cas. Il n'est décrit que pour montrer que ces bits ne sont pas disponibles pour être alloués dans le présent mémoire.

 	4.2	ICMPv4 Temps expiré
La Figure 2 décrit le message ICMPv4 Temps expiré.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |      Somme de contrôle        |
+---------------+---------------+---------------+---------------+
|   non utilisé |   Longueur    |         non utilisé           |
+---------------+---------------+---------------+---------------+
|   En-tête Internet + octets de tête du datagramme original    |
|                                                               |
|                           //                                  |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 2 : ICMPv4 Temps expiré

La syntaxe et la sémantique de tous les champs sont inchangées par rapport à la [RFC0792], sauf qu'un attribut Longueur est ajouté au second mot. L'attribut Longueur représente la longueur du champ "Datagramme original" avec bourrage, mesuré en mots de 32 bits.

 	4.3	ICMPv4 Problème de paramètre
La Figure 3 décrit le message ICMPv4 Problème de paramètre.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |      Somme de contrôle        |
+---------------+---------------+---------------+---------------+
|    Pointeur   |    Longueur   |       non utilisé             |
+---------------+---------------+---------------+---------------+
|   En-tête Internet + octets de tête du datagramme original    |
|                                                               |
|                           //                                  |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 3 : ICMPv4 Problème de paramètre

La syntaxe et la sémantique de tous les champs sont inchangées par rapport à la [RFC0792], sauf qu'un attribut Longueur est ajouté au second mot. L'attribut Longueur représente la longueur du champ "Datagramme original" avec bourrage, mesurée en mots de 32 bits.

 	4.4	ICMPv6 Destination injoignable
La Figure 4 décrit le message ICMPv6 Destination injoignable.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |      Somme de contrôle        |
+---------------+---------------+---------------+---------------+
|    Longueur   |                 Non utilisé                   |
+---------------+---------------+---------------+---------------+
|                    Autant du paquet invocateur que            |
+                possible sans que le paquet ICMPv6             +
|                excède la MTU IPv6 minimum [RFC4443]           |

Figure 4 : ICMPv6 Destination injoignable

La syntaxe et la sémantique de tous les champs sont inchangées par rapport à la [RFC4443]. Cependant, un attribut Longueur est ajouté au second mot. L'attribut Longueur représente la longueur du champ "Datagramme original" avec bourrage, mesurée en mots de 64 bits.

 	4.5	ICMPv6 Temps expiré
La Figure 5 décrit le message ICMPv6 Temps expiré.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |      Somme de contrôle        |
+---------------+---------------+---------------+---------------+
|    Longueur   |                Non utilisé                    |
+---------------+---------------+---------------+---------------+
|                    Autant du paquet invocateur que            |
+                possible sans que le paquet ICMPv6             +
|                excède la MTU IPv6 minimum [RFC4443]           |

Figure 5 : ICMPv6 Temps expiré

La syntaxe et la sémantique de tous les champs sont inchangées par rapport à la [RFC4443], sauf qu'un attribut Longueur est ajouté au second mot. L'attribut Longueur représente la longueur du champ "Datagramme original" avec bourrage, mesurée en mots de 64 bits.

 	4.6	Messages ICMP qui peuvent être étendus
La structure Extension ICMP PEUT être ajoutée aux messages des types suivants :
- ICMPv4 Destination injoignable
- ICMPv4 Temps expiré
- ICMPv4 Problème de paramètre
- ICMPv6 Destination injoignable
- ICMPv6 Temps expiré

La structure Extension ICMP NE DOIT PAS être ajoutée à d'autres messages ICMP mentionnés à la Section 4. Les extensions n'ont pas été définies pour les messages ICMPv6 "Paquet trop gros" et "Problème de paramètre" parce que ces messages manquent d'espace pour un attribut Longueur.

 	5.	Rétro compatibilité

Les messages ICMP peuvent être catégorisés comme suit :
- Messages qui n'incluent aucune extension ICMP
- Messages qui incluent des extensions conformes à ICMP.

Toute mise en œuvre de ICMP peut envoyer un message qui ne comporte pas d'extensions. Les mises en œuvre de ICMP créées avant 1999 ne sont pas connues pour envoyer des extensions ICMP.

Certaines mises en œuvre ICMP, produites entre 1999 et le moment de la présente publication, peuvent envoyer une version non conforme des extensions ICMP décrites dans le présent mémoire. Précisément, ces mises en œuvre peuvent ajouter la structure Extension ICMP aux messages Temps expiré et Destination injoignable. Quand elles le font, elles envoient exactement 128 octets représentant le datagramme original, et un bourrage de zéros si nécessaire. Elles calculent aussi les sommes de contrôle comme décrit dans le présent document. Cependant, elles ne spécifient pas d'attribut Longueur à associer au champ "Datagramme original".

Il est supposé que les mises en œuvre ICMP produites à l'avenir vont envoyer des extensions ICMP conformes à la présente spécification.

De même, les applications qui consomment des messages ICMP peuvent être catégorisées comme suit :
- applications classiques
- applications non conformes
- applications conformes

Les applications classiques n'analysent pas les extensions définies dans le présent mémoire. Elles ne sont pas sensibles à l'attribut Longueur qui est associé au champ "Datagramme original".

Les mises en œuvre non conformes analysent les extensions définies dans ce mémoire, mais seulement en conjonction avec les messages Temps expiré et Destination injoignable. Elles exigent que le champ "Datagramme original" contienne exactement 128 octets et sont insensibles à l'attribut Longueur qui est associé au champ "Datagramme original". Les applications non conformes ont été produites entre 1999 et le moment de la publication de ce mémoire.

Les applications conformes se conforment entièrement aux spécifications du présent document.

Pour montrer la rétro compatibilite, le Tableau 1 décrit comment les membres de chaque catégorie d'application vont analyser chaque catégorie de message ICMP.

	Pas d'extension	Extensions non conformes	Extensions conformes
Application classique	-	paragraphe 5.1	paragraphe 5.1
Application non conforme	paragraphe 5.2	-	paragraphe 5.3
Application conforme	paragraphe 5.4	paragraphe 5.5	-

Tableau 1

Dans le tableau ci-dessus, les cellules qui contiennent un tiret représentent le cas nominal et n'exigent pas d'explication. Dans les paragraphes qui suivent, on suppose que le type de message ICMP est "Temps expiré".

 	5.1	Les applications classiques reçoivent les message ICMP avec extensions
Quand une application classique reçoit un message ICMP qui inclut des extensions, elle va interpréter ces extensions de façon incorrecte comme faisant partie du champ "Datagramme original". Heureusement, il est garanti que les extensions commencent au moins 128 octets au delà du début du champ "Datagramme original". Ainsi, seules les applications ICMP qui traitent le 129ième octet du champ "Datagramme original" vont être affectées de façon négative. Aujourd'hui, seules deux applications entrant dans cette catégorie ont été identifiées, et le degré auquel elles sont affectées est minimal.

Certaines piles TCP, quand elles reçoivent un message ICMP, vérifient la somme de contrôle dans le champ Datagramme original [RFC5927]. Si la somme de contrôle est incorrecte, la pile TCP élimine le message ICMP pour des raisons de sécurité. Si les octets de queue du champ Datagramme original sont écrasés par les extensions ICMP, la pile TCP va éliminer un message ICMP qu'elle n'aurait autrement pas éliminé. L'impact de ce problème est considéré comme minimal parce que de nombreux messages ICMP sont éliminées pour d'autres raisons (par exemple, le filtrage ICMP, l'encombrement du réseau, la somme de contrôle était incorrecte parce que le champ Datagramme original était tronqué.)

Un autre scénario théoriquement possible, mais très improbable, se produit quand les extensions ICMP écrasent la portion du champ Datagramme original qui représente l'en-tête TCP, causant le fonctionnement de la pile TCP sur la mauvaise connexion TCP. Ce scénario est très improbable parce que il ne se produit que quand l'en-tête TCP apparaît au 128ième octet du champ Datagramme original ou au delà et alors seulement quand les extensions ressemblent à un en-tête TCP valide.

 	5.2	Les applications non conformes reçoivent les messages ICMP sans extension
Quand une application ICMPv4 non conforme reçoit un message qui ne contient pas d'extension, l'application examine la longueur totale du message ICMPv4. Si la longueur totale du message ICMPv4 est inférieure à la longueur de son en-tête IP plus 144 octets, l'application détermine correctement que le message ne contient pas d'extensions.

La somme de 144 octets est déduite des 8 octets pour les deux premiers mots du message ICMPv4 Temps expiré, des 128  octets pour le champ "Datagramme original", des 4 octets pour l'en-tête d'extension ICMP, et des 4 octets pour un seul en-tête d'objet ICMP. Tous ces octets vont être exigés si des extensions sont présentes.

Si la charge utile ICMPv4 contient 144 octets ou plus, l'application doit examiner le 137ième octet pour déterminer si il représente un en-tête Extension ICMPv4 valide. Afin de représenter un en-tête Extension valide, elle doit contenir un numéro de version et une somme de contrôle valides. Si elle ne contient pas un numéro de version et une somme de contrôle valides, l'application détermine à juste titre que le message ne contient aucune extension.

Les applications non conformes supposent que la structure Extension ICMPv4 commence sur le 137ième octet du message Temps expiré, après un champ de 128 octets représentant le message "Datagramme original" avec bourrage.

Il est possible qu'une application non conforme analyse incorrectement un message ICMPv4 dans les conditions suivantes :
- le message ne contient pas d'extensions,
- le champ Datagramme original contient 144 octets ou plus,
- les octets choisis du champ Datagramme original représentent les valeurs correctes pour un numéro de version et somme de contrôle d'en-tête d'extension.
Bien que ce soit possible, c'est très improbable.

Une analyse similaire peut être effectuée pour ICMPv6, cependant, les constantes numériques vont changer en conséquence.

 	5.3	Les application non conformes reçoivent les messages ICMP avec des extensions conformes
Quand une application non conforme reçoit un message qui contient des extensions ICMP conformes, elle ne va analyser correctement ces extensions que si le champ "Datagramme original" contient exactement 128 octets. C'est parce que les applications non conformes ne sont pas sensibles à l'attribut Longueur qui est associé au champ "Datagramme original". (Elles supposent que sa valeur est 128.)

Pourvu que le message ICMP entier n'excède pas la taille minimum de mémoire tampon de réassemblage (576 octets pour ICMPv4 ou 1280 octets pour ICMPv6) il n'y a pas de limite supérieure à la longueur du champ "Datagramme original". Cependant, chaque mise en œuvre va décider combien d'octets inclure. Celles qui souhaitent être rétro compatibles avec les mises en œuvre TRACEROUTE non conformes vont inclure exactement 128 octets. Celles qui n'exigent pas la compatibilité avec les applications TRACEROUTE non conformes peuvent inclure plus d'octets.

 	5.4	Les application conformes reçoivent les messages ICMP sans extension
Quand une application conforme reçoit un message ICMP, elle examine l'attribut Longueur associé au champ "Datagramme original". Si l'attribut Longueur est zéro, l'application conforme DOIT déterminer que le message ne contient pas d'extensions.

 	5.5	Les application conformes reçoivent les messages ICMP avec des extensions non conformes
Quand une application conforme reçoit un message ICMP, elle examine l'attribut Longueur associé au champ "Datagramme original". Si l'attribut Longueur est zéro, l'application conforme DOIT déterminer que le message ne contient pas d'extensions. Dans ce cas, cette détermination est techniquement correcte, mais n'est pas rétro compatible avec la mise en œuvre non conforme qui a généré le message ICMP.

Donc, pour faciliter la transition et encourager à la mise en œuvre conforme, les mises en œuvre conformes à TRACEROUTE DOIVENT inclure un mode de fonctionnement non par défaut pour interpréter aussi les réponses non conformes. Précisément, quand une application TRACEROUTE fonctionnant dans un mode non conforme reçoit un message ICMP suffisamment long qui ne spécifie pas un attribut Longueur, elle va l'analyser à la recherche d'un en-tête d'extension valide à une localisation fixée, en supposant un champ "Datagramme original" de 128 octets. Si l'application détecte une version et une somme de contrôle valides, elle va traiter les octets qui suivent comme une structure d'extension.

 	6.	Interaction avec la traduction d'adresse réseau

Les extensions ICMP définies dans le présent mémoire n'interfèrent pas avec la traduction d'adresse réseau (NAT, Network Address Translation). La [RFC3022] permet aux appareils de NAT traditionels de modifier les champs sélectionnés dans les messages ICMP. Ces champs incluent le champ "Datagramme original" mentionné ci-dessus. Cependant, si un appareil de NAT modifie le champ "Datagramme original", il devrait modifier seulement les octets de tête de ce champ, qui représentent l'en-tête IP le plus externe. Parce qu'il est garanti que l'en-tête IP le plus externe est contenu dans les 128 premiers octets du champ "Datagramme original", les extensions ICMP et le NAT ne vont pas interférer ensemble.

Il est concevable qu'une mise en œuvre de NAT puisse outrepasser les restrictions de la RFC 3022 et outrepasser l'attribut Longueur spécifié dans ce mémoire. Si une mise en œuvre de NAT devait outrepasser l'attribut Longueur avec des zéros, le paquet résultant serait indistinguable d'un paquet généré par une mise en œuvre ICMP non conforme. Voir au paragraphe 5.5 les détails du paquet et la discussion de la rétro compatibilité.

 	7.	Structure d'extension ICMP 

Le présent mémoire propose une structure Extension ICMP facultative qui peut être ajoutée aux messages ICMP référencés au paragraphe 4.6 de ce document.

La structure Extension contient exactement un en-tête Extension suivi par un ou plusieurs objets. Ayant reçu un message ICMP avec des extensions, le logiciel d'application PEUT traiter les objets sélectionnées tout en ignorant les autres. La présence d'un objet non reconnu n'implique pas qu'un message ICMP soit mal formé.

Comme mentionné ci-dessus, la longueur totale du message ICMP, incluant les extensions, NE DOIT PAS excéder la taille minimum de mémoire tampon de réassemblage. La Figure 6 décrit l'en-tête d'extension ICMP.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|       (Réservé)       |       Somme de contrôle       |
+-------+-------+---------------+---------------+---------------+

Figure 6 : en-tête d'extension ICMP

Les champs de l'en-tête d'extension ICMP sont comme suit :

Version : 4 bits. numéro de version d'extension ICMP. C'est la version 2.

Réservé : 12 bits. Doit être réglé à 0.

Somme de contrôle : 16 bits. Le complément à un de la somme des compléments à un de la structure Extension ICMP, avec le champ Somme de contrôle remplacé par zéro pour les besoins du calcul de la somme de contrôle. Une valeur toute de zéros signifie qu'aucune somme de contrôle n'a été transmise. Voir au paragraphe 5.2 la description de la façon d'utiliser de champ.

 	8.	Objets d'extension ICMP

Chaque objet d'extension contient un ou plusieurs mots de 32 bits, représentant un en-tête et une charge utile d'objet. Tous les en-têtes d'objet ont un format commun. La Figure 7 décrit l'en-tête et la charge utile d'objet.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Longueur            |   Class-Num   |   C-Type      |
+---------------+---------------+---------------+---------------+
|                                                               |
|                   // (Charge utile d'objet) //                |
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 7: En-tête et charge utile d'objet

Un en-tête d'objet a les champs suivants :

Longueur : 16 bits. Longueur de l'objet, mesurée en octets, incluant l'en-tête d'objet et la charge utile d'objet.

Class-Num : 8 bits. Identifie la classe d'objet.

C-Type : 8 bits. Identifie le sous type d'objet.

 	9.	Considérations sur la sécurité

À réception d'un message ICMP, le logiciel d'application doit vérifier sa correction syntaxique. L'extension Somme de contrôle doit être vérifiée. Une spécification inappropriée des attributs Longueur et autres problèmes de syntaxe peuvent résulter en dépassements de capacité de mémoire tampon.

Le présent mémoire ne définit pas les conditions dans lesquelles un routeur envoie un message ICMP. Donc, il n'expose pas les routeurs à de nouvelles attaques de déni de service. Les routeurs peuvent devoir limiter le taux d'envoi des messages ICMP.

 	10.	Considérations relatives à l'IANA 

L'en-tête Objet d'extension ICMP contient deux champs de 8 bits : Class-Num identifie la classe d'objet, et C-Type identifie le sous type de classe. Les valeurs de sous type sont définies par rapport à une valeur spécifique de classe d'objet, et sont définies par classe.

L'IANA a établi un registre des classes et sous types de classe d'objets d'extension ICMP. Il n'y a pas de valeur allouée dans le présent document. Les classes d'objet 0xF7 à 0xFF sont réservées pour utilisation privée. Les valeurs de classe d'objet sont allouées selon le principe du premier arrivé premier servi. La politique pour allouer les valeurs de sous type devrait être définie dans le document qui définit les valeurs de la nouvelle classe.

 	11.	Remerciements

Merci à Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt, et Sharon Chrisholm pour leurs commentaires sur le présent document.

 	12.	Références
 	12.1	Références normatives

[RFC0792]	J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981. (MàJ par la RFC6633) 

[RFC1191]	J. Mogul et S. Deering, "Découverte de la MTU de chemin", novembre 1990.

[RFC1812]	F. Baker, "Exigences pour les routeurs IP version 4", juin 1995. (MàJ par les RFC2644, RFC6633)

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC4443]	A. Conta et autres, "Spécification du protocole de message de contrôle Internet (ICMPv6) pour la version 6 du protocole Internet (IPv6)", mars 2006. (Remplace RFC2463) (MàJ RFC2780) (MàJ par RFC4884) (D.S.)

 	12.2	Références pour information

[RFC3022]	P. Srisuresh, K. Egevang, "Traducteur d'adresse réseau IP traditionnel", janvier 2001. (Information)

[RFC4950]	R. Bonica et autres, "Extensions à ICMP pour la commutation d'étiquettes multiprotocoles", août 2007. (P.S.)

[RFC5837]	A. Atlas, R. Bonica, C. Pignataro, N. Shen, JR. Rivers, "Extension à ICMP pour l'identification d'interface et du prochain bond", avril 2010. (P. S.)

[RFC5927]	F. Gont, "Attaques ICMP contre TCP", juillet 2010. (Information)

[ROUTING]	Shen, N. et E. Chen, "ICMP Extensions for Routing Instances", Travail en cours, novembre 2006.

 	Adresse des auteurs

Ronald P. Bonica	Der-Hwa Gan	Daniel C. Tappan	Carlos Pignataro	
Juniper Networks	Consultant	Consultant	Cisco Systems, Inc.	
rbonica@juniper.net 	derhwagan@yahoo.com 	Dan.Tappan@gmail.com 	7025 Kit Creek Road	
			Research Triangle Park, NC 27709	
			mél : cpignata@cisco.com 	

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2007)

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY, le IETF TRUST et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle
L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP  78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur le répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Remerciement
Le financement de la fonction d'édition des RFC est actuellement fourni par la Internet Society.