Groupe de travail Réseau	A. Patel, Cisco Systems	
Request for Comments : 4064	K. Leung, Cisco Systems	
Catégorie : Sur la voie de la normalisation	mai 2005	
Traduction Claude Brière de L'Isle		

Message, extensions, et codes d'erreur expérimentaux pour IPv4 mobile

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.

Notice de Copyright
Copyright (C) The Internet Society (2005).

Résumé
La gamme des types de message IPv4 mobile va de 0 à 255. Le présent document réserve un type de message à l'usage d'un individu, société, ou organisation à des fins expérimentales, pour évaleurr des améliorations aux messages IPv4 mobile avant de produire une proposition formelle de norme.
Table des matières
1. Introduction	1
2. Terminologie	2
3. Message expérimental	2
4. Extensions expérimentales	3
4.1 Extension expérimentale IPv4 mobile non sautable	3
4.2 Extension expérimentale découverte de routeur ICMP non sautable	4
4.3 Extension expérimentale IPv4 mobile sautable	4
4.4 Extension expérimentale découverte de routeur ICMP sautable	4
5. Codes d'erreur expérimentaux	5
6. Considérations d'entité de mobilité	5
7. Considérations relatives à l'IANA	5
7.1 Nouveau type de message	5
7.2 Nouvelles valeurs d'extension	5
7.3 Nouveaux codes d'erreur	5
8. Considérations sur la sécurité	6
9. Considérations de rétro compatibilité	6
10. Remerciements	6
11. Références	6
11.1 Références normatives	6
11.2 Références pour information	6
Adresse des auteurs	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction

La gamme des types de message IPv4 mobile (MIPv4 , Mobile IPv4) va de 0 à 255. Le présent document réserve un type de message à des fins expérimentales, pour évaluer des améliorations aux messages IPv4 mobile avant de produire une proposition formelle de norme.

Sans une capacité de message expérimental, on devrait choisir une valeur de type dans la gamme définie pour les allocations de l'IANA, ce qui pourrait résulter en des collisions.

Dans un message, IP mobile définit un mécanisme général d'extension permettant à des informations facultatives d'être portées dans les messages de contrôle IP mobile. Les extensions ne sont pas sautables si elles sont définies dans la gamme [0 à 127] sont sautables si elles sont définies dans la gamme [128 à 255]. Le présent document réserve les types d'extension dans les deux gammes sautable et non sautable pour usage expérimental.

IPv4 mobile définit des codes d'erreur à l'usage des agents étrangers (FA, Foreign Agent) [64 à 127] et des agents de rattachement (HA, Home Agent) [128 à 192]. Le présent document réserve un code d'erreur dans ces deux gammes pour usage expérimental.

La définition des numéros expérimentaux dans le présent document est faite conformément à la recommandation du paragraphe 2.2 du BCP 82, [RFC3692].

 	2.	Terminologie

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].

De plus, le présent document utilise fréquemment les termes suivants :

EXP-MSG-TYPE : numéro de message IPv4 mobile alloué pour usage expérimental. L'IANA lui a alloué le numéro de message 255.

EXP-SKIP-EXT-TYPE : numéro d'extension d'annonce d'agent de découverte de routeur IPv4 mobile et ICMP alloué pour usage expérimental. L'IANA lui a alloué le numéro de message 255.

EXP-NONSKIP-EXT-TYPE : numéro d'extension d'annonce d'agent de découverte de routeur IPv4 mobile et ICMP alloué pour usage expérimental. L'IANA lui a alloué le numéro de message 127.

EXP-HA-ERROR-CODE : code d'erreur IPv4 mobile à utiliser par le HA dans les messages de réponse MIPv4 pour indiquer une condition d'erreur. L'IANA lui a alloué le code d'erreur 192.

EXP-FA-ERROR-CODE : code d'erreur IPv4 mobile à utiliser par le FA dans les messages de réponse pour indiquer une condition d'erreur. L'IANA lui a alloué le code d'erreur 127.

Entité de mobilité : entités définies dans la [RFC3344] (agent de rattachement, agent étranger, et nœud mobile (MN, Mobile Node).

 	3.	Message expérimental

Comme la nature et l'objet d'un message expérimental ne peut pas être connue à l'avance, la structure est définie comme ayant une charge utile opaque. Les entités qui mettent en œuvre le message peuvent interpréter le message selon leur mise en œuvre. L'interprétation sur la base des extensions présentes dans le message est une suggestion.

Ces messages peuvent être utilisés entre les entités de mobilité (Agent de rattachement, Agent étranger, et nœud mobile). Les messages expérimentaux DOIVENT être authentifiés en utilisant un des mécanismes d'authentification définis pour IP mobile ([RFC3344], [RFC3012]).

Ce message PEUT contenir des extensions définies dans IP mobile, incluant des extensions spécifiques de fabricant [RFC3115].

Champs IP :
Adresse de source : normalement, l'adresse de interface d'où le message est envoyé.
Adresse de destination : adresse de l'agent ou du nœud mobile.

Champs UDP :
Accès de source : réglé conformément à la RFC 768 (variable)
Accès de destination : réglé à la valeur 434

Les champs IP mobile montrés ci-dessous suivent l'en-tête UDP.

 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      |                 Opaque. . .
+---------------+---------------+---------------+---------------+

Type : 255 (EXP-MSG-TYPE)

Opaque : zéro, un ou plusieurs octets de données, avec la structure définie seulement par l'expérience particulière pour laquelle elle est utilisée.

Une fois qu'un message expérimental a été vérifié et prouvé utile, un numéro permanent devrait être obtenu par les procédures normales d'allocation de numéro de l'IANA.

Un seul type de message expérimental est défini. Ce message peut contenir des extensions sur la base desquelles le message peut être interprété.

Les valeurs à jour pour les types de message pour les mgeneral essages de contrôle IP mobile sont spécifiées actuellement dans le répertoire en ligne de l'IANA à www.iana.org.

 	4.	Extensions expérimentales

Le présent document réserve les extensions IPv4 mobile dans les deux gammes sautables et non sautables pour les besoins expérimentaux. Le format d'extension long (pour les extensions non sautables) et le format d'extension court (pour les extensions sautables) comme défini par la [RFC3344] sont utilisés pour les extensions IPv4 mobile expérimentales.

Aussi, les numéros d'extension de découverte de routeur ICMP dans les deux gammes sautables et non sautables sont réservés pour usage expérimental.

 	4.1	Extension expérimentale IPv4 mobile non sautable
Ce format est applicable pour les extensions non sautables et peut porter des informations de plus de 256 octets.

 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      |  Sous type     |          Longueur            |
+---------------+---------------+---------------+---------------+
|                           Opaque. . .
+---------------+---------------+---------------+---------------+

Type : 127 (EXP-NONSKIP-EXT-TYPE) est le type, qui décrit une extension expérimentale.

Sous-type : numéro unique donné à chaque membre dans le type agrégé.

Longueur : indique la longueur (en octets) du champ de données au sein de cette extension. Il n'inclut PAS les champs Type, Sous-type, et Longueur.

Opaque : zéro, un ou plusieurs octets de données, avec la structure définie seulement par l'expérience particulière pour laquelle elles sont utilisées.

Comme le champ Longueur fait 16 bits, les données d'extension peuvent excéder 256 octets.

 	4.2	Extension expérimentale découverte de routeur ICMP non sautable
Ce format est applicable pour les extensions non sautables.

 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      |    Longueur   |           Opaque . . .
+---------------+---------------+---------------+---------------+

Type : 127 (EXP-NONSKIP-EXT-TYPE) est le type, qui décrit une extension expérimentale de découverte de routeur ICMP.

Longueur : indique la longueur (en octets) du champ de données dans cette extension. Elle N'inclut PAS les champs Type et Longueur.

Opaque : zéro, un ou plusieurs octets de données, avec la structure définie seulement par l'expérience particulière pour laquelle elles sont utilisées.

Un nœud qui reçoit une annonce de routeur avec cette extension devrait ignorer l'extension si il ne la reconnaît pas.

Une entité de mobilité qui comprend cette extension mais ne la reconnaît pas devrait éliminer (ignorer) l'annonce de routeur.

 	4.3	Extension expérimentale IPv4 mobile sautable
Ce format est applicable aux extensions sautables, qui portent des informations de moins de 256 octets.

 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      |    Longueur   |   Sous Type   |  Opaque. . .
+---------------+---------------+---------------+---------------+

Type : 255 (EXP-SKIP-EXT-TYPE) est le type, qui décrit une extension expérimentale.

Longueur : indique la longueur (en octets) du champ de données au sein de cette extension. Elle N'inclut PAS les champs Type et Longueur.

Sous type : numéro unique donné à chaque membre dans le type agrégé.

Opaque : zéro, un ou plusieurs octets de données, avec la structure définie seulement par l'expérience particulière pour laquelle elles sont utilisées.

Comme le champ Longueur fait 8 bits, les données d'extension ne peuvent pas excéder 256 octets.

 	4.4	Extension expérimentale découverte de routeur ICMP sautable
Ce format est applicable pour les extensions de découverte de routeur ICMP sautable. Cette extension devrait être ignorée si une mise en œuvre ne la comprend pas.

 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      |   Longueur    |   Opaque. . .
+---------------+---------------+---------------+---------------+

Type : 255 (EXP-SKIP-EXT-TYPE) est le type, qui décrit une extension expérimentale.

Longueur : indique la longueur (en octets) du champ de données au sein de cette extension. Elle N'inclut PAS les champs Type et Longueur.

Opaque : zéro, un ou plusieurs octets de données, avec la structure définie seulement par l'expérience particulière pour laquelle elles sont utilisées.

 	5.	Codes d'erreur expérimentaux
Le présent document réserve le code de réponse d'erreur EXP-FA-ERROR-CODE pour l'utilisation par le FA. Le présent document réserve aussi le code de réponse d'erreur EXP-HA- ERROR-CODE pour l'utilisation par le HA.

Ces codes d'erreur expérimentaux peuvent être utilisés dans les messages de réponse d'enregistrement.

Il est recommandé que les codes d'erreur expérimentaux soient utilisés avec les messages expérimentaux et extensions expérimentales chaque fois qu'aucun des codes d'erreur normalisés n'est applicable.

 	6.	Considérations d'entité de mobilité

Les entités de mobilité peuvent envoyer et recevoir des messages expérimentaux. Les mises en œuvre qui ne comprennent pas le type de message DEVRAIENT éliminer en silence le message.

Les extensions expérimentales peuvent être portées dans des messages expérimentaux et des messages normalisés définis. Dans ce dernier cas, il est suggéré que les extensions expérimentales NE DOIVENT PAS être utilisées dans des produits déployés et que leur usage se restreigne aux seules expériences.

 	7.	Considérations relatives à l'IANA

Le présent document définit un message de contrôle à utiliser entre les entités de mobilité, deux nouveaux formats d'extension, et deux nouveaux codes d'erreur. Pour assurer une interopération correcte sur la base de la présente spécification, l'IANA a réservé des valeurs dans l'espace de numéros de IPv4 mobile, comme défini dans la [RFC3344], pour un nouveau type de message, deux nouvelles extensions, et deux codes d'erreur.

 	7.1	Nouveau type de message
Un nouveau message de contrôle IPv4 mobile utilisant l'accès UDP 434, type 255 (EXP-MSG-TYPE), a été défini par l'IANA. Cette valeur a été prise dans le même espace de numéros que la demande d'enregistrement IP mobile (Type = 1) et la réponse d'enregistrement IP mobile (Type = 3).

 	7.2	Nouvelles valeurs d'extension
Les types d'extension suivants sont introduits par la présente spécification :

Extension expérimentale non sautable : la valeur 127 (EXP-NONSKIP-EXT-TYPE) a été allouée dans l'espace de numérotation pour les extensions non sautables, qui peuvent apparaître dans les messages de contrôle IPv4 mobile.

Aussi, le même numéro, 127 (EXP-NONSKIP-EXT-TYPE), a été alloué dans l'espace de numérotation pour les extensions non sautables, qui peuvent apparaître dans les messages de découverte de routeur ICMP.

Extension expérimentale sautable : la valeur 255 (EXP-SKIP-EXT-TYPE) a été allouée dans l'espace de numérotation pour les extensions sautables, qui peuvent apparaître dans les messages de contrôle IPv4 mobile.

Aussi, le même numéro, 255 (EXP-SKIP-EXT-TYPE) a été alloué dans l'espace de numérotation pour les extensions sautables, qui peuvent apparaître dans les messages de découverte de routeur ICMP.

 	7.3	Nouveaux codes d'erreur
La valeur 192 (EXP-HA-ERROR-CODE) a été définie par l'IANA pour être utilisée comme champ Code dans les messages générés par le HA.

Aussi, la valeur 127 (EXP-FA-ERROR-CODE) a été définie par l'IANA pour être utilisée comme champ Code dans les messages générés par le FA.

 	8.	Considérations sur la sécurité

Comme tous les messages de contrôle IP mobile, les messages expérimentaux DOIVENT être authentifiés selon les exigences spécifiées dans la [RFC3344] ou la [RFC3012]. Les messages expérimentaux sans une authentification valide DEVRAIENT être éliminés.

 	9.	Considérations de rétro compatibilité

Les entités de mobilité qui ne comprennent pas le message expérimental DOIVENT l'éliminer en silence.

Les entités de mobilité qui ne comprennent pas les extensions expérimentales sautables DOIVENT les ignorer. Les entités de mobilité qui ne comprennent pas les extensions expérimentales non sautables DOIVENT éliminer en silence le message qui les contient. Ce comportement est cohérent avec le paragraphe 1.8 de la [RFC3344].

Les agents étrangers et agents de rattachement DEVRAIENT inclure un code d'erreur expérimental dans un message de réponse seulement si ils ont une indication générale que l'entité receveuse va être capable de l'analyser. Cela est indiqué si le message de demande était du type EXP-MSG-TYPE ou contenait au moins une extension expérimentale.

 	10.	Remerciements

Les auteurs tiennent à remercier Henrik Levkowetz de sa relecture détaillée du document et de sa suggestion d'incorporer les extensions expérimentales à ce projet.

Les auteurs tiennent aussi à remercier Thomas Narten de sa relecture initiale du document et de la référence à la [RFC3692] pour les lignes directrices générales.

 	11.	Références
 	11.1	Références normatives

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

[RFC3232]	J. Reynolds, "Numéros alloués : la RFC 1700 est remplacée par une base de données en ligne", janvier 2002.

[RFC3344]	C. Perkins, éd., "Prise en charge de la mobilité IP pour IPv4", août 2002. (Obsolète, voir RFC5944) (P.S.)

 	11.2	Références pour information

[RFC3012]	C. Perkins, P. Calhoun, "Extensions de mise en cause/réponse pour IPv4 mobile", novembre 2000. (Obs., voir RFC4721) (P.S.)

[RFC3115]	G. Dommety et K. Leung, "Extensions spécifiques de l'organisation/fabricant à IP pour les mobiles", avril 2001. (PS)

[RFC3692]	T. Narten, "L'allocation de numéros expérimentaux et d'essai est considérée comme utile", janvier 2004. (BCP0082)

 	Adresse des auteurs
Les questions et commentaires sur le présent document devraient être adressées au groupe de travail IPv4 Mobile à mip4@ietf.org 

Les questions et commentaires sur le présent document peuvent aussi être adressées aux auteurs :

Alpesh Patel	Kent Leung	
Cisco Systems	Cisco Systems	
170 W. Tasman Drive,170 W. Tasman Drive,	170 W. Tasman Drive,	
San Jose, CA 95134 	San Jose, CA 95134 	
USA	USA	
téléphone : +1 408-853-9580	téléphone : +1 408-526-5030	
mél : alpesh@cisco.com 	mél : kleung@cisco.com 	

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

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, 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 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 pourrait ê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 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 fourni par l'activité de soutien administratif (IASA) de l'IETF.