RFC2290 Option Configuration IPv4 mobile Solomon & Glass

Groupe de travail Réseau

J. Solomon, Motorola

Request for Comments : 2290

S. Glasss, FTP Software

Catégorie : En cours de normalisation

février 1998

RFC mise à jour : 2002

Traduction Claude Brière de L'Isle



Option Configuration IPv4 mobile pour IPCP PPP



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 (1998). Tous droits réservés.


Résumé

IP mobile [RFC2002] définit des procédures indépendantes du support par lesquelles un nœud mobile peut conserver les connexions existantes de couche transport et application en dépit des changements de son point de rattachement à l’Internet et sans changer son adresse IP. PPP [RFC1661] fournit une méthode standard pour transporter des paquets multi protocoles sur des liaisons point à point. Comme actuellement spécifiés, les agents étrangers IP mobile qui prennent en charge les connexions de nœud mobile via PPP ne peuvent le faire qu’en allouant d’abord des adresses uniques à ces nœuds mobiles, annulant un des principaux avantages des agents étrangers. Le présent document corrige ce problème en définissant l’option Configuration IPv4 mobile au protocole de contrôle du protocole Internet (IPCP, Internet Protocol Control Protocol) [RFC1332]. En utilisant cette option, deux homologues peuvent communiquer leur prise en charge de IP mobile durant la phase IPCP de PPP. On suppose que le lecteur est familiarisé avec IP mobile [RFC2002], IPCP [RFC1332], et PPP [RFC1661].


Table des Matières

1. Introduction 1

1.1 Langage de spécification 2

1.2 Terminologie 2

1.3 Position du problème 2

1.4 Exigences 3

2. Option Configuration IPv4 mobile 3

2.1 Format de l’option 4

2.2 Vue d’ensemble 4

2.3 Exigences de haut niveau pour nœuds non mobiles 4

2.4 Exigences de haut niveau pour nœuds mobiles 5

2.5 Description détaillée 5

2.6 Exemples de scénarios 7

3. Exigences supplémentaires 8

3.1 Autres options IPCP 8

3.2 Détection de mouvement 8

4. Considérations sur la sécurité 9

5. Références 9

6. Remerciements 9

7. Adresse des auteurs 9

8. Déclaration complète de droits de reproduction 10


1. Introduction


IP mobile [RFC2002] définit des protocoles et des procédures par lesquelles des paquets peuvent être acheminés à un nœud mobile, sans considération de son point de rattachement actuel à l’Internet, et sans changer son adresse IP. IP mobile est conçu pour fonctionner sur tout type de support et tout type de couche de liaison des données. Cependant, l’interaction entre IP mobile et PPP est actuellement sous spécifiée et il en résulte généralement une application inappropriée de IP mobile lorsque les nœuds mobiles se connectent à l’Internet via PPP.


Le présent document définit une interaction appropriée entre un nœud mobile [RFC2002] et un homologue à travers laquelle le nœud mobile se connecte à l’Internet en utilisant PPP. Cela exige la définition d’une nouvelle option pour IPCP [RFC1332], appelée option de configuration "IPv4 mobile", qui est définie dans le présent document. Le nœud mobile et l’homologue utilisent cette option pour négocier l’utilisation appropriée de IP mobile sur la liaison PPP.


L’option IPv4 mobile définie dans le présent document est destinée à fonctionner en conjonction avec l’option Adresse IP existante [RFC1332].


1.1 Langage de spécification


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


1.2 Terminologie


Le présent document utilise les termes suivants comme définis dans la [RFC2002]:


Nœud mobile : hôte ou routeur qui change son point de rattachement d’une liaison à une autre. Un nœud mobile peut changer sa localisation sans changer son adresse IP ; il peut continuer de communiquer avec d’autres nœuds Internet à toute localisation en utilisant son adresse IP de rattachement (permanente) en supposant que la connexité de couche liaison est disponible à sa localisation actuelle.


Agent de rattachement : routeur avec au moins une interface sur la liaison de rattachement d’un nœud mobile. Un agent de rattachement intercepte les paquets destinés à l’adresse de rattachement d’un nœud mobile et les tunnelle à l’adresse d’entretien du nœud mobile lorsque le nœud mobile est connecté à une liaison étrangère. Un nœud mobile informe son agent de rattachement de son adresse d’entretien actuelle au moyen d’un protocole d’enregistrement authentifié défini par IP mobile.


Agent étranger : routeur avec au moins une interface sur la liaison étrangère (actuelle) du nœud mobile. Lorsque un nœud mobile utilise l’adresse d’entretien d’un agent étranger, l’agent étranger détunnelle et livre au nœud mobile les paquets qui ont été tunnelés par l’agent de rattachement du nœud mobile. Un agent étranger peut aussi servir de routeur par défaut pour les paquets envoyés par un nœud mobile enregistré.


Homologue : homologue PPP d’un nœud mobile. L’homologue du nœud mobile peut prendre en charge la fonction d’agent de rattachement, d’agent étranger, les deux, ou ni l’une ni l’autre.


1.3 Position du problème


Dans IP mobile, les paquets envoyés à l’adresse de rattachement d’un nœud mobile sont d’abord acheminés à l’agent de rattachement du nœud mobile, un routeur sur la liaison de rattachement du nœud mobile qui intercepte les paquets envoyés à l’adresse de rattachement. L’agent de rattachement tunnelle alors de tels paquets à l’adresse d’entretien du nœud mobile, où les paquets sont extraits du tunnel et livrés au nœud mobile. Il y a deux types d’adresses d’entretien:


Adresse d’entretien colocalisée

C’est une adresse temporairement allouée à un nœud mobile lui-même. Dans ce cas, le nœud mobile est le point de sortie du tunnel et il désencapsule les paquets encapsulés pour livraison par son agent de rattachement. Une adresse d’entretien colocalisée peut être utilisée par exactement un nœud mobile à un moment donné.


Adresse d’entretien d’agent étranger

C’est l’adresse d’un agent étranger qui a au moins une interface sur une liaison étrangère visitée du nœud mobile. Dans ce cas, l’agent étranger désencapsule les paquets qui ont été tunnelés par l’agent de rattachement et les livre au nœud mobile sur la liaison visitée. Une adresse d’entretien d’agent étranger peut être utilisée simultanément par de nombreux nœuds mobiles à tout moment.


Dans son Appendice B, IP mobile [RFC2002] ne spécifie actuellement que ce qui suit par rapport à PPP :


"Le protocole point à point (PPP) [RFC1661] et son protocole de contrôle du protocole Internet (IPCP) [RFC1332], négocie (sic) l’utilisation des adresses IP.


"Le nœud mobile DEVRAIT d’abord tenter de spécifier son adresse de rattachement, afin que si le nœud mobile est rattaché à sa (liaison) de rattachement, la liaison non acheminée fonctionne correctement. Lorsque l’adresse de rattachement n’est pas acceptée par l’homologue, mais qu’une adresse IP transitoire est allouée dynamiquement au nœud mobile, et que le nœud mobile est capable de prendre en charge une adresse d’entretien colocalisée, le nœud mobile PEUT enregistrer cette adresse comme adresse d’entretien colocalisée. Lorsque l’homologue spécifie sa propre adresse IP, on NE DOIT PAS supposer que cette adresse est une adresse d’entretien d’agent étranger ni l’adresse IP d’un agent de rattachement."


L’examen de ce texte révèle qu’il n’y a actuellement aucun moyen pour que le nœud mobile utilise une adresse d’entretien d’agent étranger, sans d’abord allouer une adresse IP univoque, même si l’homologue prend aussi en charge la fonction d’agent étranger. On peut en voir la raison en parcourant les étapes de la négociation IPCP :


1. Un nœud mobile se connecte à un homologue via PPP et propose son adresse de rattachement dans une demande Configure IPCP contenant l’option Adresse IP. Dans ce scénario, on suppose que le nœud mobile se connecte à une liaison étrangère.


2. L’homologue n’a aucun moyen de savoir si cette demande Configure a été reçue de : (a) un nœud mobile proposant son adresse de rattachement, ou (b) un nœud conventionnel proposant une adresse topologiquement non acheminable. Dans ce cas, l’homologue doit (prudemment) envoyer un accusé de réception négatif de Configure de l’option Adresse IP fournissant une adresse topologiquement appropriée à utiliser par le nœud à l’autre extrémité de la liaison PPP.


3. Le nœud mobile, à son tour, n’a aucun moyen de savoir si ce Configure-Nak a été reçu parce que l’homologue est un agent étranger prudent, ou parce que l’homologue ne met pas en œuvre du tout IP mobile. Donc, le nœud mobile doit (prudemment) supposer que l’homologue ne met pas en œuvre IP mobile et continuer la négociation d’une adresse IP dans IPCP, après quoi le nœud mobile peut utiliser l’adresse allouée comme adresse d’entretien colocalisée.


On observe ici que, même si l’homologue du nœud mobile est un agent étranger et envoie une annonce d’agent au nœud mobile après que IPCP atteint l’état Ouvert, le nœud mobile va quand même avoir négocié une adresse acheminable dans l’étape 3, qu’il utilise probablement déjà comme adresse d’entretien colocalisée. Cela détruit l’objet des adresses d’entretien d’agent étranger, qui sont conçues pour être partagées par plusieurs nœuds mobiles et pour éliminer le besoin d’allouer une adresse univoque à chaque nœud mobile.


1.4 Exigences


L’objet du présent document est de spécifier le comportement des deux extrémités de la liaison PPP lorsque un ou plusieurs des homologues PPP prennent en charge IP mobile. Spécifiquement, le concept de l’option et du protocole définis dans le présent document se fonde sur les exigences suivantes :


1. L’option et le protocole décrits dans ce document doivent être rétro compatibles avec les nœuds conventionnels et leurs homologues potentiels qui ne mettent pas en œuvre cette option ni aucune fonction IP mobile.


2. L’option et le protocole décrits dans ce document doivent s’accommoder de divers scénarios, au minimum ceux fournis dans les exemples du paragraphe 2.6.


3. L’option et le protocole décrits dans ce document ne doivent pas dupliquer de fonctionnalité déjà définie dans d’autres options IPCP ; en particulier, l’option Adresse IP.


  1. Une adresse unique ne doit pas être allouée à un nœud mobile sauf absolue nécessité. Précisément, aucune adresse de cette sorte n’est allouée à un nœud mobile qui se connecte via PPP à sa liaison de rattachement ou à un nœud mobile qui se connecte via PPP à un agent étranger (et utilise l’adresse d’entretien de cet agent étranger).


2. Option Configuration IPv4 mobile


Cette section définit l’option Configuration IPv4 mobile et fournit plusieurs exemples de son utilisation.


2.1 Format de l’option


L’option Configuration IPv4 mobile pour IPCP est définie comme suit :


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 | Adresse de rattachement ...

+---------------+---------------+---------------+---------------+

... du nœud mobile |

+---------------+---------------+


Type : 4 (IPv4 mobile)


Longueur : 6 (Longueur de cette extension entière en octets)


Adresse de rattachement du nœud mobile

Dans une demande Configuration, l’adresse de rattachement IP du nœud mobile qui envoie cette option Configuration, et autrement, l’adresse de rattachement IP (non modifiée) du nœud mobile lorsque elle est envoyée dans un accusé de réception de Configuration ou un rejet de Configuration. L’accusé de réception négatif (Configure-Nak) de cette option est indéfini et NE DOIT PAS être envoyé par les mises en œuvre qui se conforment à la présente version de la spécification. Ce champ NE DOIT PAS être zéro.


Valeur par défaut : L’option Configuration IPv4 mobile prend par défaut l’envoi de l’adresse de rattachement du nœud mobile.


Pour décrire le fonctionnement de l’option Configuration IPv4 mobile (en conjonction avec l’option Configuration d’adresse IP) on utilise les abréviations suivantes :


Types de message PPP :

Request = Demande de configuration

Rejet = Rejet de configuration

Ack = Accusé de réception de configuration

Nak = Accusé de réception négatif de configuration


Options de configuration IPCP :

MIPv4 = IPv4 mobile

IP = Adresse IP


Adresses IP :

a.b.c.d = une adresse IP différente de zéro

w.x.y.z = une adresse IP différente de zéro autre que a.b.c.d

home = adresse de rattachement IP du nœud mobile

coa = adresse IP d’entretien

0 = l’adresse IP toute à zéro (0.0.0.0)


2.2 Vue d’ensemble


L’option Configuration IPv4 mobile est conçue pour être utilisée en conjonction avec l’option Configuration d’adresse IP. Pour en faciliter la mise en œuvre, la description détaillée du paragraphe 2.5 inclut toutes les combinaisons possibles de ces deux options qui peuvent être envoyées par un homologue PPP durant IPCP. Avec chaque possibilité se trouve une description de la façon dont le receveur devrait interpréter le contenu ainsi qu’un comportement suggéré.


2.3 Exigences de haut niveau pour nœuds non mobiles


Un nœud qui n’effectue pas la fonction de nœud mobile (comme les nœuds sans capacité IP mobile ainsi que les nœuds qui n’effectuent que la fonction d’agent de rattachement, que la fonction d’agent étranger, ou les deux) NE DOIT PAS inclure une option Configuration IPv4 mobile dans un message Demande de configuration. Selon la [RFC1332], un tel nœud DEVRAIT envoyer une demande de configuration contenant une option Configuration d’adresse IP dans laquelle le champ Adresse IP est réglé à une adresse IP non à zéro que le nœud a alloué à une de ses interfaces. Si une adresse IP explicite a été allouée à l’interface PPP du nœud, alors, cette adresse DEVRAIT être envoyée de préférence à toute autre adresse du nœud.


Un nœud NE DOIT PAS envoyer un Configure-Nak contenant une option Configuration IPv4 mobile. Le faire est actuellement "indéfini" et pourrait causer des problèmes d’interopérabilité lorsque une signification utile pour Configure-Nak sera finalement définie pour l’option Configuration IPv4 mobile. Un nœud qui envoie un Configure-Ack contenant une option Configuration IPv4 mobile DEVRAIT envoyer une annonce d’agent [RFC2002] immédiatement après IPCP pour que cette liaison entre dans l’état Ouvert.


2.4 Exigences de haut niveau pour nœuds mobiles


Un nœud mobile DEVRAIT commencer sa négociation IPCP par l’envoi de la demande de configuration décrite dans le point n° 1 ou le point n° 4 du paragraphe 2.5. Le nœud mobile PEUT commencer sa négociation par l’un ou l’autre des points numérotés du paragraphe 2.5 dans certaines circonstances.


Un nœud mobile qui reçoit un Configure-Ack contenant une option Configuration IPv4 mobile DOIT recevoir une annonce d’agent, éventuellement en réponse à une sollicitation d’agent, avant d’envoyer une demande d’enregistrement [RFC2002] si ce nœud mobile se connecte à une liaison étrangère. C’est parce que l’homologue pourrait être un agent étranger mettant en application une politique qui exige qu’un nœud mobile s’enregistre auprès de cet agent étranger même si le nœud mobile utilise une adresse d’entretien colocalisée. Un nœud mobile n’a pas besoin d’attendre une telle annonce si il se connecte à sa liaison de rattachement. Voir au point 7a du paragraphe 2.5 une façon dont un nœud mobile peut déterminer si il s’est connecté à sa liaison de rattachement. Une autre façon est en recevant une notification explicite de ce fait de la part de l’homologue, comme la réception des messages dans les points 1b, 2c, et 3a du paragraphe 2.5.


Un nœud mobile qui reçoit un rejet de configuration contenant une option Configuration IPv4 mobile DEVRAIT revenir à la négociation IPCP en utilisant l’option Adresse IP de la [RFC1332]. Un nœud mobile DEVRAIT commencer cette négociation avec, respectivement, Request(IP=home) ou Request(IP=0), selon que le nœud mobile se connecte ou non à sa liaison de rattachement. Un nœud mobile PEUT faire cette détermination en inspectant l’option Adresse IP contenue au sein d’une demande de configuration envoyée par son homologue. Si le préfixe de l’adresse IP déclarée par l’homologue est égal au préfixe de l’adresse de rattachement du nœud mobile, le nœud mobile PEUT alors conclure qu’il se connecte à sa liaison de rattachement. Autrement, si le nœud mobile se connecte à une liaison étrangère, le nœud mobile DEVRAIT alors envoyer Request(IP=0) car son homologue pourrait n’avoir aucun moyen autre que IPCP d’allouer des adresses. Cette spécification met donc à jour ce comportement comme décrit dans la [RFC2002], cette dernière recommande qu’un nœud mobile commence la négociation d’adresse IP avec Request(IP=Home) dans toutes les circonstances.


Un homologue qui n’effectue les fonctions ni d’agent de rattachement ni d’agent étranger DEVRAIT envoyer un Rejet en réponse à toute demande reçue de son homologue si elle contient une option Configuration IPv4 mobile.


2.5 Description détaillée


Les points numérotés ci-dessous montrent toutes les combinaisons possibles des options Configuration IPv4 mobile et Adresse IP qu’un nœud mobile (ou un nœud conventionnel) pourrait envoyer à son homologue. Les nœuds mobiles DEVRAIENT commencer leur négociation IPCP avec le point n° 1 ou le point n° 4 selon qu’ils préfèrent une adresse d’entretien respectivement colocalisée ou d’agent étranger. La liste de points marqués d’une lettre donne les réponses légales possibles qu’un homologue pourrait envoyer au nœud mobile (ou au nœud conventionnel) en réponse aux demandes numérotées.


Dans chaque cas, une interprétation est définie et une suite d’actions est suggérée. Finalement, on pense que la présentation ci-dessous offre les avantages de la concision et de la précision par rapport à une présentation équivalente "en prose".


1. Request(IP=0,MIPv4=home) signifie "Je préfère une adresse d’entretien colocalisée à une adresse d’entretien d’agent étranger". La réponse de l’homologue DOIT être une des suivantes :

a. Nak(IP=coa) signifie "utiliser coa comme adresse d’entretien colocalisée". Passer à 2.

b. Nak(IP=home) signifie "vous êtes chez vous et n’avez pas besoin d’une adresse d’entretien". Passer en 3.

c. Reject(IP=0) signifie "Je ne peut pas allouer une adresse d’entretien colocalisée mais vous pouvez m’utiliser comme agent étranger". Passer en 4.

d. Reject(MIPv4=home) signifie "Je ne met pas en œuvre l’option IPv4 mobile". Si l’homologue a aussi envoyé Request(IP=address) et si le préfixe de l’adresse allouée à l’homologue est égal à celui de l’adresse de rattachement du nœud mobile, passer alors en 6 avec a.b.c.d=home ; autrement, passer en 5.

e. Reject(IP=0,MIPv4=home) signifie "utiliser le comportement par défaut". Passer en 7.


=> Ack(IP=0, ...), Nak(MIPv4=any, ...) NE DOIT PAS être envoyé.


2. Request(IP=coa,MIPv4=home) signifie "Je veux utiliser coa comme adresse d’entretien colocalisée". La réponse de l’homologue DOIT être une des suivantes :

a. Ack(IP=coa,MIPv4=home) signifie "d’accord, utiliser coa comme adresse d’entretien colocalisée ; s’assurer d’attendre une annonce". Ouvert.

b. Nak(IP=alternate-coa) signifie "non, utiliser une autre coa comme adresse d’entretien colocalisée". Passer en 2.

c. Nak(IP=home) signifie "vous êtes chez vous et n’avez pas besoin d’une adresse d’entretien colocalisée". Passer en 3.

d. Reject(IP=coa) signifie "une coa n’est pas une valeur utile pour une adresse d’entretien colocalisée sur cette liaison et je ne peux pas en allouer une qui soit utile (ou je ne vais pas négocier l’option Adresse IP) – vous pouvez m’utiliser comme agent étranger". Passer en 4.

e. Reject(MIPv4=home) signifie "je ne met pas en œuvre l’option IPv4 mobile". Si l’homologue envoie aussi une Request(IP=address) et si le préfixe de l’adresse de l’homologue est égal à celui de l’adresse de rattachement du nœud mobile, passer alors en 6 avec a.b.c.d=home ; autrement, passer en 5.

f. Reject(IP=coa,MIPv4=home) signifie "utiliser le comportement par défaut". Passer en 7.


=> Nak(MIPv4=any, ...) NE DOIT PAS être envoyé.


3. Request(IP=home,MIPv4=home) signifie "Je pense que je suis chez moi mais si je me trompe, je préfère alors une adresse d’entretien colocalisée à une adresse d’entretien d’agent étranger". La réponse de l’homologue DOIT être l’une des suivantes :

a. Ack(IP=home,MIPv4=home) signifie "oui, vous êtes chez vous". Ouvert.

b. Nak(IP=coa) signifie "vous n’êtes pas chez vous, utilisez coa comme adresse d’entretien colocalisée". Passer en 2.

c. Reject(IP=home) signifie "vous n’êtes pas chez vous et je ne peux pas allouer une adresse d’entretien colocalisée (ou je ne veux pas négocier l’option Adresse IP) – vous pouvez m’utiliser comme agent étranger". Passer en 4.

d. Reject(MIPv4=home) signifie "je ne met pas en œuvre l’option IPv4 mobile". Si l’homologue envoie aussi Request(IP=address) et si le préfixe de l'adresse de l’homologue est égal à celui de l’adresse de rattachement du nœud mobile, aller alors en 6 avec a.b.c.d=home ; autrement, passer en 5.

e. Reject(IP=home,MIPv4=home) signifie "utiliser le comportement par défaut". Passer en 7.


=> Nak(MIPv4=any, ...) NE DOIT PAS être envoyé.


4. Request(MIPv4=home) signifie "je veux utiliser IP mobile sur cette liaison et je ne veux pas d’adresse d’entretien colocalisée". La réponse de l’homologue DOIT être une des suivantes :

a. Ack(MIPv4=home) signifie "d'accord, attendez une annonce pour comprendre où vous êtes". Ouvert.

b. Reject(MIPv4=home) signifie "je ne met pas en œuvre l’option IPv4 mobile". Si l’homologue a aussi envoyé Request(IP=address) et si le préfixe de l’adresse de l’homologue est égal à celui de l’adresse de rattachement du nœud mobile, passer alors en 6 avec a.b.c.d=home ; autrement, passer en 5.


=> Nak(MIPv4=any, ...) NE DOIT PAS être envoyé.


5. Request(IP=0) signifie "Prière d’allouer une adresse colocalisée/d’entretien". La réponse de l’homologue DOIT être une des suivantes :

a. Nak(IP=a.b.c.d) signifie "utiliser a.b.c.d comme adresse colocalisée/d’entretien". Passer en 6.

b. Reject(IP=0) signifie "je ne peux pas allouer d’adresse (pour que le nœud mobile l’utilise comme adresse colocalisée/d’entretien) ou je ne met pas en œuvre l’option Adresse IP". Passer en 7.


=> Ack(IP=0) NE DOIT PAS être envoyé et signifie historiquement "je ne connais pas non plus votre adresse". Ouvert.

Une mise en œuvre NE DOIT PAS utiliser 0 comme adresse IP à réception de Ack(IP=0) mais PEUT utiliser une autre adresse d’interface, non zéro, pour les paquets envoyés sur son interface PPP.


6. Request(IP=a.b.c.d) signifie "Je veux utiliser a.b.c.d comme adresse de rattachement/colocalisée/d’entretien". La réponse de l’homologue DOIT être une des suivantes :

a. Ack(IP=a.b.c.d) signifie "d’accord, a.b.c.d est votre adresse de rattachement/colocalisée/d’entretien". Ouvert.

b. Nak(IP=w.x.y.z) signifie "non, utilisez w.x.y.z comme adresse de rattachement/colocalisée/d’entretien". Passer en 6.

c. Reject(IP=a.b.c.d) signifie "a.b.c.d est une mauvaise adresse, mais je ne peux pas vous en donner de meilleure" ou "Je ne met pas en œuvre l’option Adresse IP. Passer en 7.


7. Request() signifie "Je veux utiliser le comportement par défaut". La réponse de l’homologue DOIT être la suivante :

a. Ack() signifie "d’accord, utiliser le comportement par défaut". Ouvert.


Dans ce cas, le nœud mobile va utiliser les valeurs de "défaut" de l’option Adresse IP (pas d’adresse configurée par IPCP) et de l’option IPv4 mobile (l’adresse IP de rattachement du nœud mobile). Le nœud mobile DEVRAIT envoyer des sollicitations d’agent pour voir si il y a des agents présents sur la liaison actuelle. (Noter que la "liaison" actuelle pourrait aussi inclure un support partagé si l’homologue PPP du nœud mobile est un pont.) Si un agent est présent et si le nœud mobile reçoit une annonce d’agent, le nœud mobile emploie alors son ou ses algorithmes de détection de mouvement et s’enregistre en conséquence.


Dans tous les cas, si l’homologue du nœud mobile a fourni une option Adresse IP contenant une valeur non zéro au sein d’une demande de configuration IPCP, le nœud mobile PEUT utiliser cette adresse pour déterminer si il est connecté ou non à sa liaison de rattachement. Cela peut être réalisé en comparant l’adresse IP déclarée avec l’adresse de rattachement du nœud mobile sur la longueur de préfixe associé à la liaison de rattachement. Si le nœud mobile est connecté à sa liaison de rattachement, il DEVRAIT alors se désenregistrer auprès de son agent de rattachement.


Autrement, le nœud mobile PEUT tenter d’obtenir une adresse topologiquement acheminable à travers un des supports qu’il prend en charge (par exemple, DHCP, configuration manuelle, etc.) pour l’utiliser comme adresse d’entretien colocalisée. Si le nœud mobile réussit à obtenir une telle adresse, il DEVRAIT alors enregistrer cette adresse auprès de son agent de rattachement.

=> Nak(IP=0) NE DOIT PAS être envoyé. Passer en 6.

=> Nak() NE DOIT PAS être envoyé.

=> Reject() NE DOIT PAS être envoyé.


2.6 Exemples de scénarios


Ce paragraphe illustre l’utilisation de l’option et du protocole définis au paragraphe précédent. Dans les exemples qui suivent, une demande de configuration envoyée par un nœud mobile et la réponse générée par l’homologue sont montrées sur la même ligne. Le numéro et la lettre à gauche de chaque demande/réponse se réfère aux points numérotés et aux lettres du paragraphe 2.5.


A. Un nœud mobile préfère une adresse d’entretien colocalisée et l’homologue est un agent étranger qui est capable d’allouer une telle adresse:

(1)(a) Request(IP=0,MIPv4=Home) / Nak(IP=coa)

(2)(a) Request(IP=coa,MIPv4=Home) / Ack(IP=coa,MIPv4=Home)

- Le nœud mobile attend de recevoir une annonce d’agent.

- Si l’annonce a le bit R établi, alors le nœud mobile s’enregistre en utilisant l’adresse d’entretien colocalisée via l’agent étranger ; autrement, le nœud mobile s’enregistre en utilisant l’adresse d’entretien colocalisée directement auprès de son agent de rattachement.


B. Un nœud mobile préfère une adresse d’entretien colocalisée et l’homologue est un agent étranger qui ne peut pas allouer une adresse d’entretien colocalisée (par exemple, il n’a pas de réservoir d’adresses à partir duquel allouer pour ces besoins) :

(1)(c) Request(IP=0,MIPv4=Home) / Reject(IP=0)

(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)

- IPCP s’achève.

- Le nœud mobile attend de recevoir une annonce d’agent.

- Le nœud mobile s’enregistre en utilisant l’adresse d’entretien d’agent étranger de l’homologue auprès de son agent de rattachement.


C. Un nœud mobile préfère une adresse d’entretien colocalisée et l’homologue détermine que l’adresse de rattachement du nœud mobile est telle que le nœud mobile se connecte à sa liaison de rattachement :

(1)(b) Request(IP=0,MIPv4=Home) / Nak(IP=Home)

(3)(a) Request(IP=Home,MIPv4=Home) / Ack(IP=Home,MIPv4=Home)

- IPCP s’achève.

- Le nœud mobile se désenregistre auprès de son agent de rattachement.

D. Un nœud mobile préfère une adresse d’entretien d’agent étranger et l’homologue est un agent étranger qui trouve cet état des affaires satisfaisant :

(4)(a) Request(MIPv4=Home) / Ack(MIPv4=Home)

- IPCP s’achève.

- Le nœud mobile attend de recevoir une annonce d’agent.

- Le nœud mobile s’enregistre en utilisant l’adresse d’entretien d’agent étranger de l’homologue ou se désenregistre de la liaison de rattachement, selon les valeurs dans l’annonce d’agent.


E. Un nœud mobile préfère une adresse d’entretien colocalisée et l’homologue ne met pas en œuvre l’option Configuration IPv4 mobile. L’homologue est cependant capable d’allouer dynamiquement des adresses :

(1)(d) Request(IP=0,MIPv4=Home) / Reject(MIPv4=Home)

(5)(a) Request(IP=0) / Nak(IP=a.b.c.d)

(6)(a) Request(IP=a.b.c.d) / Ack(IP=a.b.c.d)

- IPCP s’achève.

- Le nœud mobile s’enregistre en utilisant a.b.c.d comme adresse d’entretien colocalisée auprès de son agent de rattachement.


F. Un nœud mobile préfère une adresse d’entretien colocalisée et l’homologue ne met pas en œuvre l’option Configuration IPv4 mobile. L’homologue n’est pas capable d’allouer dynamiquement des adresses :

(1)(e) Request(IP=0,MIPv4=Home) / Reject(IP=0,MIPv4=Home)

(7)(a) Request() / Ack()

- IPCP s’achève.

- Le nœud mobile envoie une sollicitation d’agent et/ou tente d’obtenir une adresse d’entretien colocalisée via des moyens hors de IPCP (par exemple, DHCP ou configuration manuelle) ou il abandonne.


3. Exigences supplémentaires

3.1 Autres options IPCP


Un nœud mobile NE DOIT PAS inclure l’option Adresses IP déconseillée dans une demande de configuration qui contient une option IPv4 mobile, une option Adresse IP, ou les deux.


À l’inverse, le nœud mobile PEUT inclure une option Protocole de compression IP et toutes autres options qui n’impliquent pas la négociation d’adresses IP.


Si un nœud mobile et un agent étranger ou un agent de rattachement s’accordent dans IPCP pour utiliser la compression d’en-tête de Van Jacobson [RFC1144], le nœud mobile NE DOIT PAS alors établir le bit 'V' dans la demande d’enregistrement IP mobile [RFC2002] qui s’ensuit. Si des entités PPP homologues utilisent la compression d’en-tête de la RFC1144, il n’y a pas de gain pour les entités IP mobiles et demander cette option va vraisemblablement causer une certaine confusion.


3.2 Détection de mouvement


Les nœuds mobiles qui se connectent via PPP DOIVENT mettre correctement en œuvre l’IPCP de PPP, car un mouvement du nœud mobile va probablement changer son homologue PPP. Précisément, les nœuds mobiles DOIVENT être prêts à renégocier IPCP à tout moment, y compris la renégociation de l’option Configuration d’adresse IP et l’option Configuration IPv4 mobile décrite dans le présent document. Selon la [RFC1661], un nœud mobile dans l’état Ouvert DOIT renégocier IPCP à réception d’une demande IPCP de configuration de la part de son homologue.


Noter aussi que certaines liaisons sans fils peuvent employer des mécanismes de relais et de mandataire qui n’exigent pas nécessairement de ponter une liaison PPP mais vont quand même exiger d’un nœud mobile qu’il s’enregistre auprès d’un nouvel agent étranger. Donc, les nœuds mobiles qui se connectent à un agent via PPP DOIVENT employer leur algorithme de détection de mouvement (voir le paragraphe 2.4.2 de la [RFC2002]) et s’enregistrer chaque fois qu’ils détectent un changement de connexité.


Spécifiquement, un nœud mobile qui échoue à recevoir une annonce d’agent dans le délai de la durée de vie annoncée par son agent étranger actuel, DOIT supposer qu’il a perdu le contact avec cet agent étranger (voir le paragraphe 2.4.2.1 de la [RFC2002]). Si dans le même temps, le nœud mobile a reçu des annonces d’agent d’un autre agent étranger, le nœud mobile DEVRAIT immédiatement s’enregistrer auprès de cet agent étranger à l’expiration de la temporisation de son agent étranger actuel.


De même, un nœud mobile qui met en œuvre la détection de mouvement sur la base de l’extension Longueur de préfixe DOIT comparer le préfixe de tous les agents annonceurs avec celui de son agent étranger actuel (voir le paragraphe 2.4.2.2 de la [RFC2002]). Si un tel nœud mobile reçoit une annonce d’agent d’un agent étranger qui spécifie un préfixe différent de celui de son agent étranger actuel, le nœud mobile qui emploie cette méthode de détection de mouvement DOIT alors s’enregistrer auprès de ce nouvel agent étranger.


Un nœud mobile PEUT traiter l’établissement d’une liaison PPP comme une raison suffisante pour procéder à un nouvel enregistrement IP mobile. La Section 2 définit les circonstances dans lesquelles les nœuds mobiles DOIVENT attendre une annonce d’agent avant de s’enregistrer. En conséquence, les agents étrangers et les agents de rattachements DEVRAIENT envoyer une annonce d’agent sur une liaison PPP immédiatement après IPCP pour que cette liaison entre dans l’état Ouvert.


4. Considérations sur la sécurité


Le présent document n’introduit aucune menace connue pour la sécurité au delà de celles auxquelles doivent faire face les nœuds qui se connectent à l’Internet via PPP ou qui mettent en œuvre IP mobile, ou les deux. Précisément, les fournisseurs de service devraient utiliser une authentification cryptographiquement forte (par exemple, CHAP [RFC1994]) pour empêcher le vol de service. De plus, les usagers qui exigent la confidentialité devraient utiliser le chiffrement de la liaison PPP [RFC1968], le chiffrement de couche IP [RFC1827], ou le chiffrement de couche d’application, selon leurs exigences individuelles. Finalement, l’authentification IP mobile [RFC2002] protège contre les attaques triviales de déni de service qui pourraient autrement être lancées contre un nœud mobile et son agent de rattachement.


5. Références


[RFC1144] V. Jacobson, "Compression des en-têtes TCP/IP pour les liaisons série à faible débit", février 1990.


[RFC1332] G. McGregor, "Protocole de contrôle de protocole Internet point à point (IPCP)", mai 1992. (MàJ par 3241)


[RFC1661] W. Simpson, éditeur, "Protocole point à point (PPP)", STD 51, juillet 1994. (MàJ par la RFC2153)


[RFC1827] R. Atkinson, "Encapsulation dans IP de charge utile de sécurité (ESP)", août 1995. (Obsolète, voir RFC2406)


[RFC1968] G. Meyer, "Protocole de contrôle de chiffrement en PPP (ECP)", juin 1996. (P.S.)


[RFC1994] W. Simpson, "Protocole d'authentification par mise en cause de la prise de contact en PPP (CHAP)", août 1996.


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


6. Remerciements


La conception de ce protocole et de l’option a été inspirée par une soumission antérieure de B. Patel et C. Perkins, alors chez IBM, dans un projet Internet maintenant périmé. Du texte de William Simpson a été aussi copié mot à mot de la [RFC1661] afin d’assurer la cohérence de la terminologie et de la spécification. Il en va de même pour certaines définitions et autre texte s’y rapportant provenant de la [RFC2002] de Charlie Perkins.


Tim Wilson et Chris Stanaway (Motorola) ont contribué de façon significative à la conception de cette option Configuration et à la spécification du protocole. Des remerciements particuliers à Vernon Schryver (SGI), Craig Fox (Cisco), Karl Fox (Ascend), et John Bray (FTP) pour leurs utiles suggestions et commentaires, et leur patience.


7. Adresse des auteurs


Jim Solomon

Steven Glass

Motorola, Inc.

FTP Software, Inc.

1301 E. Algonquin Rd. - Rm 2240

2 High Street

Schaumburg, IL 60196

North Andover, MA 01845

USA

USA

téléphone : +1-847-576-2753

téléphone : +1-508-685-4000

Fax: +1-847-576-3240

Fax: +1-508-684-6105

mél : solomon@comm.mot.com

mél : glass@ftp.com


8. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (1998). 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 - 10 -