RFC2794 Extension d’identifiant d’accès IP mobile Calhoun & Perkins

Groupe de travail Réseau P. Calhoun, Sun Microsystems Laboratories

Request for Comments : 2794 C. Perkins, Nokia Research Center
Catégorie : En cours de normalisation mars 2000
RFC mise à jour : 2290 Traduction Claude Brière de L'Isle

Extension d’identifiant d’accès de réseau IP mobile pour IPv4

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle
à des discussions et des suggestions d’amélioration. Prière de se référer à l’édition en cours des "Normes officielles des
protocoles de l’Internet" (STD 1) pour connaître l’état de normalisation et le statut de ce protocole. La distribution du
présent mémoire n’est soumise à aucune restriction.

Copyright
Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé
Les serveurs d’authentification, autorisation et comptabilité (AAA, Authentication, Authorisation and Accounting) sont
aujourd’hui utilisés dans l’Internet pour fournir des services d’authentification et d’autorisation pour les ordinateurs
accessibles par numérotation. De tels services seront probablement précieux pour les nœuds mobiles qui utilisent IP mobile
lorsque le nœud essaye de se connecter à des domaines étrangers avec des serveurs AAA. Les serveurs AAA identifient
aujourd’hui les clients en utilisant l’identifiant d’accès réseau (NAI, Network Access Identifier). Notre proposition définit
un moyen pour que le nœud mobile s’identifie, en incluant le NAI avec la demande d’enregistrement IP mobile. Le présent
mémoire met aussi à jour la [RFC2290] qui spécifie l’option de configuration IPv4 mobile pour IPCP, en permettant au
champ Adresse de rattachement du nœud mobile de cette option d’être à zéro.

1. Introduction

Les serveurs AAA sont utilisés aujourd’hui dans l’Internet pour fournir des services d’authentification et d’autorisation
pour les ordinateurs accessibles par numérotation. De tels services seront probablement également précieux pour les nœuds
mobiles qui utilisent IP mobile lorsque les nœuds tentent de se connecter à des domaines étrangers avec des serveurs AAA.
Les serveurs AAA identifient aujourd’hui les clients en utilisant l’identifiant d’accès réseau (NAI, Network Access
Identifier) [RFC2486]. Le présent document spécifie l’extension NAI de nœud mobile au message de demande
d’enregistrement IP mobile [RFC2002] provenant du nœud mobile.

Comme le NAI est normalement utilisé pour identifier de façon univoque le nœud mobile, l’adresse de rattachement du
nœud mobile n'est pas toujours nécessaire pour assurer cette fonction. Donc, il est possible qu’un nœud mobile s’authentifie
lui-même, et soit autorisé à se connecter au domaine étranger, sans même avoir d’adresse de rattachement. Un message qui
contient l’extension NAI de nœud mobile PEUT établir le champ Adresse de rattachement à zéro (0) dans la demande
d’enregistrement, pour demander que soit allouée une adresse de rattachement.

L’option "Configuration IPv4 mobile" de IPCP a été spécifiée dans la [RFC2290] pour une interaction appropriée entre un
nœud mobile et un homologue, à travers lequel le nœud mobile se connecte au réseau en utilisant PPP. Selon cette
spécification, le champ Adresse de rattachement de nœud mobile de l’option NE DOIT PAS être à zéro. Cependant, dans le
contexte du présent mémoire qui permet à un mobile d’être identifié par son NAI et d’obtenir une adresse après la phase
d’établissement de la connexion, il est permis au champ Adresse de rattachement d’être à zéro tout en maintenant tous les
autres aspects de la RFC2290. L’interprétation des divers scénarios d’après la RFC2290 est donnée à la section 4.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS",
"RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].

2. Extension NAI de nœud mobile

L’extension NAI de nœud mobile, montrée à la figure 1, contient le nom d’utilisateur en utilisant le format défini dans la
[RFC2486]. Lorsque il est présent dans la demande d’enregistrement, le champ Adresse de rattachement PEUT être réglé à
zéro (0). L’extension NAI de nœud mobile DOIT apparaître dans la demande d’enregistrement avant les deux extensions
Authentification de rattachement mobile et Authentification de mobile étranger, si elles sont présentes.

page - 1 -
RFC2794 Extension d’identifiant d’accès IP mobile Calhoun & Perkins

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 | MN-NAI ...
+---------------+---------------+---------------+---------------+

Figure 1 : extension NAI de nœud mobile

Type : 131 (peut être sauté) [RFC2002]

Longueur : Longueur en octets du champ MN-NAI

MN-NAI : Chaîne en format de NAI définie dans la [RFC2486].

3. Considérations d’agent étranger

Si l’adresse de rattachement est zéro dans la demande d’enregistrement, l’agent étranger DOIT utiliser le NAI à sa place
dans ses enregistrements de demande d’enregistrement en instance, avec le champ Identification usuel. Si l’agent étranger
ne peut pas gérer de cette façon les enregistrements de demande d’enregistrement en instance, il DOIT retourner une
Réponse d’enregistrement avec le code qui indique NONZERO_HOMEADDR_REQD (voir la section 5).

Si le nœud mobile inclut l’extension NAI de nœud mobile dans sa demande d’enregistrement, la réponse d’enregistrement
provenant de l’agent de rattachement DOIT inclure l’extension NAI de nœud mobile. Sinon, l’agent étranger DEVRAIT
envoyer la réponse d’enregistrement au nœud mobile, en changeant le code pour la valeur MISSING_NAI (voir la
section 5). La réponse d’enregistrement DOIT inclure une adresse d’agent de rattachement non à zéro et l’adresse de
rattachement du nœud mobile. Sinon, l’agent étranger DEVRAIT envoyer la réponse d’enregistrement au nœud mobile, en
changeant le code en la valeur, respectivemen, MISSING_HOME_AGENT, ou MISSING_HOMEADDRt (voir section 5).

4. Interactions avec l’option Configuration IPv4 mobile à IPCP

Dans l’option Configuration IPv4 mobile à IPCP [RFC2290], le champ Adresse de rattachement du nœud mobile peut être
zéro. Dans cette section, on spécifie l’action à entreprendre dans ce cas, lorsque le nœud mobile utilise l’extension NAI de
nœud mobile dans la demande d’enregistrement IP mobile. Que l’option Configuration d’adresse IP contienne ou non une
adresse IP non à zéro, le nœud mobile va ensuite tenter d’obtenir une adresse de rattachement de la réponse
d’enregistrement IP mobile.

Si l’option Configuration d’adresse IP pour IPCP a une adresse IP égale à zéro, l’homologue PPP est supposé allouer et
affecter une adresse d’entretien colocalisée au nœud mobile. Si, d’un autre côté, l’option Configuration d’adresse IP pour
IPCP a une adresse IP différente de zéro, l’homologue PPP est supposé allouer cette adresse au nœud mobile comme
adresse d’entretien colocalisée.

Finalement, si l’option Configuration d’adresse IP est laissée en dehors de la demande de configuration IPCP, aucune
adresse d’entretien colocalisée n’est allouée durant IPCP. Le nœud mobile va acquérir une adresse d’entretien colocalisée
durant une étape de configuration ultérieure ou va utiliser une adresse d’entretien localisée chez l’agent étranger.

5. Valeurs d’erreur

Chaque entrée du tableau qui suit contient le nom et la valeur du code [RFC2002] à retourner dans une réponse
d’enregistrement, et la section dans laquelle le code d’erreur est mentionné pour la première fois dans cette spécification.

Nom de l’erreur Valeur Section du document

NONZERO_HOMEADDR_REQD 96 3
MISSING_NAI 97 3
MISSING_HOME_AGENT 98 3
MISSING_HOMEADDR 99 3

page - 2 -
RFC2794 Extension d’identifiant d’accès IP mobile Calhoun & Perkins

6. Considérations relatives à l’IANA

L’extension NAI de nœud mobile définie à la Section 2 est une extension d’enregistrement IP mobile comme définie dans
la [RFC2002] et étendue dans la [RFC2356]. L’IANA devrait allouer une valeur de 131 à cette fin.

Les valeurs de code définie à la Section 5 sont des codes d’erreur, comme défini dans la [RFC2002] et étendu dans la
[RFC2344] et la [RFC2356]. Elles correspondent aux valeurs d’erreur conventionnellement associées au rejet par l’agent
étranger (c’est-à-dire, des valeurs dans la gamme 64-127). L’IANA devrait enregistrer les valeurs comme défini dans la
Section 5.

7. Considérations sur la sécurité

Les messages d’enregistrement IP mobile sont authentifiés, et l’authentification est vérifiée par le receveur. Cette
proposition n’interdit pas au nœud mobile d’envoyer son NAI en clair sur le réseau, mais cela n’est pas supposé constituer
un problème de sécurité.

8. Considérations relatives à IPv6

La prise en charge des enregistrements fondés sur le NAI pour IPv6 mobile [RFC3775] sort du domaine d’application du
présent document. Cette section contient quelques idées sur la façon dont l’autoconfiguration d’adresse sans état
[RFC2462] et DHCPv6 [RFC3315] peuvent être étendus pour prendre en charge les enregistrements IPv6 mobile fondés
sur le NAI.

Pour les nœuds mobiles qui utilisent IPv6, il n’y a pas de mécanisme actuellement développé qui permette à un nœud
mobile de présenter ses accréditifs, comme il en existe aujourd’hui avec IPv4. Néanmoins, un nœud mobile qui utilise la
mobilité IPv6 peut souhaiter spécifier le domaine dans lequel ses accréditifs peuvent être vérifiés, en utilisant un NAI tout
comme le propose la présente spécification pour IPv4. Dans le cas de IPv6, cependant, il n’y a pas d’agent étranger en
place pour gérer la connexité du nœud mobile, et donc pour gérer la vérification des accréditifs offerts par le nœud mobile.
Pour identifier que la HDAF (voir l’Appendice A) a la relation attendue avec le nœud mobile, le NAI devra avoir été
transmis à un AAA local par l’agent local impliqué dans la configuration de l’adresse d’entretien du nœud mobile.

Cet agent peut être un routeur qui envoie des annonces de routeur [RFC2462], ou un serveur DHCPv6. Dans le premier cas,
le routeur pourrait signaler sa capacité à traiter le NAI en joignant une option (qui reste à définir) à l’annonce de routeur.
Dans le second cas, pour les liaisons gérées, le nœud mobile pourrait inclure une extension NAI (non encore définie) dans
son message de sollicitation DHCP. Une telle extension de NAI et l’authentification appropriée seraient aussi exigées sur la
demande DHCP ultérieure envoyée par le nœud mobile au serveur DHCP choisi sur la base des annonces DHCP reçues.
Une fois qu’a été obtenue une adresse d’entretien sur le réseau étranger, le nœud mobile peut utiliser le MIPv6 régulier
[RFC3775].

9. Remerciements

Les auteurs tiennent à remercier Gabriel Montenegro et Vipul Gupta pour leurs utiles discussions. Merci à Basaravaj Patil
et Pete McCann pour le texte de description des actions à entreprendre lorsque l’adresse de rattachement est zéro mais que
le nœud mobile souhaite utiliser l’option Configuration IPv4 mobile à IPCP définie dans la [RFC2290].

Références

[RFC2002] C. Perkins, éd., "Prise en charge de la mobilité sur IP", octobre 1996. (Obsolète, voir RFC3220) (P.S.)

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

[RFC2290] J. Solomon, S. Glass, "Option de configuration IPv4 mobile pour IPCP PPP", février 1998. (MàJ par
RFC2794) (P.S.)

[RFC2344] G. Montenegro, éd., "Tunnelage inverse pour IP mobile", mai 1998. (Obsolète, voir RFC3024) (P.S.)

page - 3 -
RFC2794 Extension d’identifiant d’accès IP mobile Calhoun & Perkins

[RFC2356] G. Montenegro, V. Gupta, "Traversée de pare-feu SKIP de Sun pour IP mobile", juin 1998. (Information)

[RFC2462] S. Thomson, T. Narten, "Autoconfiguration d'adresse IPv6 sans état", décembre 1998. (Obsolète, voir
RFC4862) (D.S.)

[RFC2486] B. Aboba, M. Beadles, "Identifiant d'accès réseau", janvier 1999. (Obsolète, voir RFC4282) (P.S.)

[RFC3315] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins et M. Carney, "Protocole de configuration dynamique
d'hôte pour IPv6 (DHCPv6)", juillet 2003. (MàJ par RFC6422 et RFC6644, RFC7227)

[RFC3775] D. Johnson, C. Perkins, J. Arkko, "Prise en charge de la mobilité dans IPv6", juin 2004. (P.S.) (Obs., voir
RFC6275)

Appendice A. Fonction d’allocation de domaine de rattachement (HDAF)

Cet Appendice introduit une nouvelle fonction appelée fonction d’allocation de domaine de rattachement (HDAF, Home
Domain Allocation Function) qui peut allouer de façon dynamique une adresse de rattachement au nœud mobile.

La Figure 2 illustre la HDAF, qui reçoit des messages des agents étrangers (par exemple, FA) et alloue une adresse de
rattachement au sein du domaine de rattachement. La HDAF n’effectue aucun traitement IP mobile sur la demande
d’enregistrement, mais transmet simplement la demande à un agent de rattachement (HA, Home Agent) au sein du réseau
qui est capable de traiter la demande.

+------+
| |
+---+ HA-1 |
+------+ +------+ +------+ | | |
| | | | | | | +------+
| MN |-------| FA |-------| HDAF +---+ ...
| | | | | | | +------+
+------+ +------+ +------+ | | |
+---+ HA-n |
| |
+------+

Figure 2 : Fonction d’allocation de domaine de rattachement (HDAF)

À réception de la demande d’enregistrement du nœud mobile (MN, mobile node), FA extrait le NAI et trouve le nom de
domaine qui lui est associé. FA trouve alors la HDAF qui traite les demandes pour le domaine du nœud mobile. Le
protocole de découverte sort du domaine d’application de la présente spécification. Par exemple, FA pourrait cependant
déléguer la tâche de trouver une HDAF à un serveur AAA local. Le serveur AAA local peut aussi aider FA dans le
processus de vérification des accréditifs du nœud mobile, utilisant des protocoles non spécifiés dans ce document.

Adresses

Le groupe de travail peut être contacté via les présidents actuels :

Basavaraj Patil Phil Roberts

Nokia Corporation Motorola
6000 Connection Drive 1501 West Shure Drive
M/S M8-540 Arlington Heights, IL 60004
Irving, TX 75039 USA
USA téléphone : +1 847-632-3148
téléphone : +1 972-894-6709 mél : QA3445@[Link]
Fax : +1 972-894-5349
mél : [Link]@[Link]

Les questions sur le présent mémoire peuvent être adressées à :

page - 4 -
RFC2794 Extension d’identifiant d’accès IP mobile Calhoun & Perkins

Charles E. Perkins Pat R. Calhoun

Nokia Research Center Sun Microsystems Laboratories
313 Fairchild Drive 15 Network Circle
Mountain View, California 94043 Menlo Park, California 94025
USA USA
téléphone : +1-650 625-2986 téléphone : +1 650-786-7733
Fax: +1 650 625-2502 Fax: +1 650-786-6445
mél : charliep@[Link] mél : pcalhoun@[Link]

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou
les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans
restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient
inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune
façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres
organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas
les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les
besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses
successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies 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 ci encloses ne violent aucun droit ou aucune garantie implicite de
commercialisation ou d’aptitude à un objet particulier.

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

page - 5 -