Groupe de travail Réseau	R. Wakikawa, éditeur, Toyota ITC	
Request for Comments: 5648	V. Devarapalli, Wichorus	
Catégorie : Sur la voie de la normalisation	G. Tsirtsis, Qualcomm	
ISSN: 2070-1721	T. Ernst, INRIA	
	K. Nagami, INTEC NetCore	
Traduction Claude Brière de L'Isle	octobre 2009	

Enregistrement d'adresses d'entretien multiples

Résumé
Selon la spécification IPv6 mobile actuelle, un nœud mobile peut avoir plusieurs adresses d'entretien mais seulement une, appelée l'adresse d'entretien principale, peut être enregistrée auprès de son agent de rattachement et des nœuds correspondants. Cependant, pour des questions de coût, de bande passante, de délai, etc, il est utile que le nœud mobile obtienne l'accès Internet par de multiples accès simultanés, cas dans lequel le nœud mobile serait configuré avec plusieurs adresses d'entretien IPv6 actives. Le présent document propose des extensions au protocole IPv6 mobile pour enregistrer et utiliser plusieurs adresses d'entretien. Les extensions proposées dans le présent document peuvent être utilisées par les routeurs mobiles en utilisant aussi le protocole de prise en charge basique de la mobilité de réseau (NEMO, Network Mobility).

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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 licence et de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.
Table des matières
1. Introduction	2
2. Terminologie	2
3. Vue d'ensemble du protocole	3
4. Extensions IPv6 mobile	6
4.1 Structure d'antémémoire de liens et liste de mise à jour de liens	6
4.2 Message de mise à jour de lien	6
4.3 Option Mobilité d'identifiant de lien	6
4.4 Nouvelles valeurs d'état pour l'accusé de réception de lien	7
5. Fonctionnement du nœud mobile	8
5.1 Gestion de la ou des adresses d'entretien et des identifiants de lien	8
5.2. Enregistrement de lien	9
5.3 Enregistrement en vrac	9
5.4 Désenregistrement de lien	10
5.5 Retour au réseau de rattachement avec un désenregistrement de lien complet : sur une seule interface	10
5.6 Retour au réseau de rattachement : fonctionnement simultané de la liaison de rattachement et visitée	10
5.7 Réception d'un accusé de réception de lien	12
5.8 Réception d'une demande de rafraîchissement de lien	13
5.9 Amorçage	13
6. Fonctionnement de l'agent de rattachement et du nœud correspondant	13
6.1 Recherche dans l'antémémoire de liens avec un identifiant de lien	13
6.2 Traitement de la mise à jour de lien	14
6.3 Envoi d'un accusé de réception de lien pour l'enregistrement de la liaison de rattachement	15
6.4 Envoi d'une demande de rafraîchissement de lien	16
6.5 Réception de paquets provenant du nœud mobile	16
7. Applicabilité de la mobilité de réseau	16
8. Applicabilité de DSMIPv6	16
8.1 Enregistrement d'adresse d'entretien IPv4	16
8.2 Gestion d'adresse de rattachement IPv4	17
9. Interaction IPsec et IKEv2 	17
9.1 Utilisation de l'adresse d'entretien dans l'échange IKEv2	18
9.2 Messages protégés par IPsec en mode transport	18
9.3 Messages protégés par IPsec en mode tunnel	18
10. Considérations sur la sécurité	19
11. Considérations relatives à l'IANA	20
12. Remerciements	20
13. Références	20
13.1 Références normatives	20
13.2 Références pour information	21
Adresse des auteurs	21
 	1.	Introduction

Un nœud mobile peut utiliser divers types d'interfaces réseau pour obtenir une connexité réseau durable et de large zone. Ceci devient de plus en plus vrai avec les nœuds mobiles qui ont plusieurs interfaces, comme 802.2, 802.11, 802.16, radios cellulaires, etc. Les motivations et les avantages d'utiliser plusieurs points de rattachement sont discutés dans [MOTIV]. Quand un nœud mobile avec plusieurs interfaces utilise IPv6 mobile [RFC3775] pour la gestion de la mobilité, il ne peut pas utiliser ses multiples interfaces pour envoyer et recevoir les paquets tout en tirant parti de la continuité de session fournie par IPv6 mobile. C'est parce que IPv6 mobile permet au nœud mobile de lier seulement une adresse d'entretien à la fois à son adresse de rattachement. Voir dans [MIP6ANA] une analyse plus approfondie de l'utilisation de plusieurs interfaces et adresses avec IPv6 mobile.

Le présent document propose des extensions à IPv6 mobile pour permettre à un nœud mobile d'enregistrer plusieurs adresses d'entretien pour une adresse de rattachement et crée plusieurs entrées d'antémémoire de lien. Un nouveau numéro d'identification de lien (BID, Binding Identification) est créé pour chaque lien que le nœud mobile veut créer et est envoyé dans la mise à jour de lien. L'agent de rattachement qui reçoit cette mise à jour de lien crée un lien séparé pour chaque BID. L'information de BID est mémorisée dans l'entrée correspondante d'antémémoire de lien. L'information de BID peut maintenant être utilisée pour identifier les liens individuels. Les mêmes extensions peuvent aussi être utilisées dans les mises à jour de lien envoyées aux nœuds correspondants.

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

Les termes utilisés dans le présent document sont définis dans les [RFC3775], [RFC3753], et [RFC4885]. En plus ou à la place de ceux-ci, les termes suivants sont définis ou redéfinis :

Numéro d'identification de lien (BID, Binding Identification Number) : le BID est un numéro d'identification utilisé pour distinguer plusieurs liens enregistrés par le nœud mobile. L'allocation de BID distincts permet à un nœud mobile d'enregistrer plusieurs entrées d'antémémoire de lien pour une adresse de rattachement donnée. Les BID alloués à la même adresse de rattachement ne doivent pas être dupliqués au même moment. La valeur zéro est réservée pour de futures extensions. Chaque BID est généré et géré par un nœud mobile. Le BID est mémorisé dans la liste de mises à jour de lien et est envoyé par le nœud mobile dans la mise à jour de lien. Un nœud mobile peut changer la valeur d'un BID à tout moment en accord avec sa politique administrative -- par exemple, pour protéger sa confidentialité. Une mise en œuvre doit allouer soigneusement le BID de façon à garder le même BID pour le même lien même quand l'état du lien est changé. On trouvera plus de détails au paragraphe 5.1.

Option de mobilité Identifiant de lien : l'option de mobilité Identifiant de lien est utilisée pour porter les informations de BID.

Enregistrement en vrac : un nœud mobile peut enregistrer plusieurs liens en une seule fois en envoyant une seule mise à jour de lien. Un nœud mobile peut aussi remplacer certains ou tous les liens disponibles chez l'agent de rattachement par de nouveaux liens en utilisant l'enregistrement en vrac. L'enregistrement en vrac est pris seulement en charge pour l'enregistrement de rattachement (c'est-à-dire, avec l'agent de rattachement) comme expliqué au paragraphe 5.3. Un nœud mobile ne doit pas effectuer le mécanisme d'enregistrement en vrac décrit dans cette spécification avec un nœud correspondant.

 	3.	Vue d'ensemble du protocole

Une nouvelle extension appelée le numéro d'identification de lien (BID) est introduite pour distinguer entre plusieurs liens relevant de la même adresse de rattachement. Si un nœud mobile configure plusieurs adresses IPv6 mondiales sur une ou plusieurs de ses interfaces, il peut enregistrer ces adresses avec son agent de rattachement comme des adresses d'entretien. Si le nœud mobile veut enregistrer plusieurs liens, il DOIT générer un BID pour chaque adresse d'entretien et mémoriser le BID dans la liste de mises à jour de lien. Un nœud mobile peut manipuler chaque lien indépendamment en utilisant les BID. Le nœud mobile enregistre alors ses adresses d'entretien en envoyant une mise à jour de lien avec une option de mobilité Identifiant de lien.

Le BID est inclus dans l'option de mobilité Identifiant de lien. Après réception de la mise à jour de lien avec une option de mobilité Identifiant de lien, l'agent de rattachement DOIT copier le BID provenant de l'option de mobilité Identifiant de lien au champ correspondant dans l'entrée d'antémémoire de lien. Si il existe une entrée d'antémémoire de lien pour le nœud mobile, et si le BID dans la mise à jour de lien ne correspond pas à celui de l'entrée existante, l'agent de rattachement DOIT créer une nouvelle entrée d'antémémoire de lien pour la nouvelle adresse d'entretien et le BID. Le nœud mobile peut enregistrer soit plusieurs adresses d'entretien en une fois dans une seule mise à jour de lien, soit indépendamment dans des mises à jour de lien individuelles.

Si l'hôte mobile souhaite enregistrer son lien avec un nœud correspondant, il doit effectuer les opérations de vérification de l'acheminement de retour décrites dans la [RFC3775]. Cela inclut de gérer un jeton Keygen (de génération de clé) d'entretien par adresse d'entretien et d'échanger les messages Initiation d'essai d'entretien et Essai d'entretien avec le nœud correspondant pour chaque adresse d'entretien. Le nœud mobile PEUT utiliser le même BID qu'avec l'agent de rattachement pour une adresse d'entretien particulière. Pour la simplicité du protocole, l'enregistrement en vrac aux nœuds correspondants n'est pas pris en charge dans le présent document. C'est parce que le mécanisme de vérification de l'acheminement de retour introduit dans la [RFC3775] ne peut pas être facilement étendu pour vérifier plusieurs adresses d'entretien mémorisées dans une seule mise à jour de lien.

La Figure 1 illustre la configuration où le nœud mobile obtient plusieurs adresses d'entretien aux liaisons étrangères. Le nœud mobile peut utiliser toutes les adresses d'entretien. Dans la Figure 1, l'adresse de rattachement du nœud mobile (MN, Mobile Node) est 2001:db8::EUI. Le nœud mobile a trois interfaces différentes et peut acquérir les adresses d'entretien 1 à 3 (CoA1, CoA2, CoA3). Le nœud mobile alloue BID1, BID2, et BID3 à chaque adresse d'entretien.

                       +----+
                       | CN | (Nœud correspondant)
                       +--+-+
                          |
                      +---+------+          +----+
               +------+ Internet |----------+ HA | (Agent de rattachement)
               |      +----+---+-+          +--+-+
           CoA2|           |   |               |   Liaison de rattachement
            +--+--+        |   |         ------+------
            |  MN +--------+   |
            +--+--+ CoA1       |
           CoA3|               |
               +---------------+

Base de données d'antémémoire de liens :
Liens de l'agent de rattachement (l'annonce de voisin mandataire est active)
   lien [2001:db8::EUI  BID1 adresse d'entretien1]
   lien [2001:db8::EUI  BID2 adresse d'entretien2]
   lien [2001:db8::EUI  BID3 adresse d'entretien3]
Lien du nœud correspondant 
   lien [2001:db8::EUI  BID1 adresse d'entretien1]
   lien [2001:db8::EUI  BID2 adresse d'entretien2]
   lien [2001:db8::EUI  BID3 adresse d'entretien3]

Figure 1 : Enregistrement d'adresses d'entretien multiples

Si le nœud mobile décide d'agir comme un nœud mobile régulier conforme à la [RFC3775], il envoie une mise à jour de lien sans option de mobilité Identifiant de lien. Le receveur de la mise à jour de lien supprime tous les liens enregistrés avec un BID et enregistre seulement un lien pour le nœud mobile. Noter que le nœud mobile peut continuer à utiliser le BID même si il a seulement un lien actif.

La recherche d'antémémoire de lien est faite sur la base de l'adresse de rattachement et des informations de BID si un BID est disponible. Ceci est différent de la RFC 3775, où seule l'adresse de rattachement est utilisée pour la recherche dans l'antémémoire de liens. La recherche dans l'antémémoire de liens est faite pour la signalisation de protocole ou de paquets de données. Pour la signalisation de protocole comme une mise à jour de lien, le BID devrait être toujours porté par une sous option BID dans une signalisation de protocole. Donc, une antémémoire de liens correspondante qui satisfait au BID spécifié DOIT être trouvée dans la base de données d'antémémoire de liens. Par ailleurs, pour les paquets de données, aucune information de BID n'est portée dans un paquet. La recherche dans l'antémémoire de liens peut invoquer la politique ou des filtres de flux pour restituer un BID correspondant par paquet dans les cas où une politique ou des filtres de flux sont utilisés pour diriger un certain paquet ou flux sur une adresse d'entretien particulière. Cependant, la recherche dans l'antémémoire de liens en utilisant une politique ou des filtres de flux sort du domaine d'application du présent document. Si un tel mécanisme n'est pas disponible et si aucun BID n'est trouvé pour un paquet, un nœud DEVRAIT utiliser le lien qui a été vérifié en dernier en recevant des paquets de données ou de signalisation provenant du nœud mobile. Dans le cas où la recherche dans l'antémémoire de liens pour des paquets de données, en utilisant la combinaison d'adresse de rattachement et de BID, ne retourne pas une entrée d'antémémoire de lien valide, l'agent de rattachement DEVRAIT effectuer la recherche sur la base de la seule adresse de rattachement comme décrit dans la [RFC3775].

En tous cas, pour éviter des problèmes avec les protocoles de couche supérieure et TCP en particulier, un seul flux de paquets tel qu'identifié par le quintuplet DEVRAIT seulement être envoyé à une adresse d'entretien à la fois.

Le nœud mobile peut retourner à la liaison de rattachement par une de ses interfaces. Il y a deux options possibles pour le nœud mobile quand il revient chez lui. Les paragraphes 5.5.1 et 5.6 décrivent plus en détails les procédures de retour au réseau de rattachement.

1.	Le nœud mobile utilise seulement l'interface avec laquelle il se rattache à la liaison de rattachement et reprend la pleine possession de son adresse de rattachement (HoA, Home Address) sur la liaison de rattachement. Ceci est illustré à la Figure 2. Il désenregistre d'avec l'agent de rattachement tous les liens relatifs à toutes les adresses d'entretien. Les interfaces encore rattachées à la ou aux liaisons visitées ne vont plus recevoir de trafic encapsulé provenant de l'agent de rattachement. Par ailleurs, le nœud mobile peut continuer de communiquer avec les nœuds correspondants des autres interfaces rattachées à des liaisons étrangères en utilisant l'optimisation de chemin. Même si le nœud mobile est attaché à la liaison de rattachement, il peut encore envoyer des mises à jour de lien pour les autres adresses d'entretien actives (CoA1 et CoA2) aux nœuds correspondants. Comme le nœud correspondant a des liens, les paquets sont acheminés de et vers chaque adresse d'entretien directement.

                       +----+
                       | CN |
                       +--+-+
                          |
                      +---+------+          +----+
               +------+ Internet |----------+ HA |
               |      +----+-----+          +--+-+
           CoA2|           |                   |   Liaison de rattachement
            +--+--+        |             --+---+------
            |  MN +--------+               |
            +--+--+ CoA1                   |
               |                           |
               +---------------------------+

Base de données d'antémémoire de liens :
    Liens de l'agent de rattachement : aucun
    Liens du nœud correspondant :
       lien [2001:db8::EUI  BID1 adresse d'entretien1]
       lien [2001:db8::EUI  BID2 adresse d'entretien2]

Figure 2 : Utilisation d'une seule interface attachée à la liaison de rattachement

2.	Le nœud mobile peut simultanément utiliser à la fois l'interface rattachée à la liaison de rattachement et les interfaces encore attachées à la ou aux liaisons visitées comme le montre la Figure 3. Il y a deux topologies possibles, selon que l'agent de rattachement est ou non le seul routeur sur la liaison de rattachement. L'opération de découverte de voisin de la [RFC4861] est différente dans les deux topologies. On trouvera plus de détails au paragraphe 5.6. L'agent de rattachement (HA, Home Agent) et le nœud correspondant (CN) ont les entrées de liens mentionnées à la Figure 3 dans leur base de données d'antémémoire de liens dans les deux topologies. L'agent de rattachement sait aussi que le nœud mobile est attaché à la liaison de rattachement. Tout le trafic provenant de l'Internet est intercepté d'abord par l'agent de rattachement et acheminé soit à l'interface rattachée à la liaison de rattachement soit à une des liaisons étrangères. Comment l'agent de rattachement décide d'acheminer un flux particulier à l'interface rattaché à la liaison de rattachement ou à la liaison étrangère sort du domaine d'application du présent document.

      Topologie a)
                       +----+
                       | CN |
                       +--+-+
                          |
                      +---+------+          +----+
               +------+ Internet |----------+ HA |
               |      +----+-----+          +--+-+
           CoA2|           |                   |   Liaison de rattachement
            +--+--+        |             --+---+------
            |  MN +--------+               |
            +--+--+ CoA1                   |
               |                           |
               +---------------------------+

      Topologie b)
                       +----+
                       | CN |
                       +--+-+
                          |
                      +---+------+    Routeur   +----+
               +------+ Internet |-------R      | HA |
               |      +----+-----+       |      +--+-+
           CoA2|           |             |         |   Liaison de rattachement
            +--+--+        |           --+-+-------+------
            |  MN +--------+               |
            +--+--+ CoA1                   |
               |                           |
               +---------------------------+

Base de données d'antémémoire de liens :
    Liens de l'agent de rattachement : 
       lien [2001:db8::EUI  BID1 adresse d'entretien1]
       lien [2001:db8::EUI  BID2 adresse d'entretien2]
    Liens du nœud correspondant :
        lien [2001:db8::EUI  BID1 adresse d'entretien1]
        lien [2001:db8::EUI  BID2 adresse d'entretien2]

Figure 3 : Fonctionnement simultané de la liaison de rattachement et le la liaison visitée

La présente spécification conserve la rétro compatibilité avec la [RFC3775]. Si un receveur (agent de rattachement ou nœud correspondant) ne prend pas en charge la présente spécification, il ne comprend pas l'option de mobilité Identifiant de lien. Le receveur saute l'option de mobilité inconnue (c'est-à-dire, l'option de mobilité Identifiant de lien) et traite la mise à jour de lien comme défini dans la [RFC3775]. Afin de conserver la rétro compatibilité avec la [RFC3775], quand un nœud mobile envoie un message de mise à jour de lien avec les extensions décrites dans le présent document, le receveur a besoin de refléter l'option de mobilité Identifiant de lien dans l'accusé de réception de lien. Si le nœud mobile ne trouve pas d'option de mobilité Identifiant de lien dans l'accusé de réception de lien reçu, il suppose que l'autre nœud d'extrémité ne prend pas en charge la présente spécification. Dans ce cas, le nœud mobile a besoin de revenir à la conformité traditionnelle à la [RFC3775]. Si c'est l'enregistrement de rattachement, le nœud mobile PEUT essayer de découvrir un autre agent de rattachement qui prend en charge l'option de mobilité Identifiant de lien pour l'enregistrement de rattachement.

 	4.	Extensions IPv6 mobile

Cette Section résume les extensions à IPv6 mobile qui sont nécessaires pour gérer plusieurs liens.

 	4.1	Structure d'antémémoire de liens et liste de mise à jour de liens
Il est exigé que le BID soit mémorisé dans l'antémémoire de liens et la structure de liste de mise à jour de lien.

La valeur du numéro de séquence DOIT être partagée par toutes les entrées de liste de mise à jour de lien relatives aux mises à jour de lien envoyées à un agent de rattachement ou nœud correspondant particulier. Chaque fois qu'un nœud mobile envoie une mise à jour de lien individuelle ou en vrac, le numéro de séquence est incrémenté. Quand un agent de rattachement reçoit une mise à jour de lien individuelle, il devrait mettre à jour le numéro de séquence pour tous les liens pour un nœud mobile particulier, avec le numéro de séquence dans la mise à jour de lien reçue.

 	4.2	Message de mise à jour de lien
La présente spécification étend le message Mise à jour de lien avec un nouveau fanion. Le fanion est montré et décrit ci-dessous.

                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T|O| Réservé   |        Durée de vie           |
+-+-+-+-+-+-+-+-+-+-+-----------+---------------+---------------+
|                                                               |
.                                                               .
.                       Options de mobilité                     .
.                                                               .
|                                                               |
+---------------+---------------+---------------+---------------+

Figure 4 : Message Mise à jour de lien

Fanion Outrepasser (O) : quand ce fanion est établi, toutes les entrées d'antémémoire de lien pour un nœud mobile sont remplacées par de nouvelles entrées enregistrées avec ce message Mise à jour de lien. Ce fanion est seulement utilisé quand l'option de mobilité BID est portée avec la mise à jour de lien.

Réservé : champ de 6 bits réservés.

 	4.3	Option Mobilité d'identifiant de lien
L'option de mobilité Identifiant de lien est incluse dans les messages Mise à jour de lien, Accusé de réception de lien, Demande de rafraîchissement de lien, Initiation d'essai d'entretien et Essai d'entretien. L'option de mobilité Identifiant de lien a une exigence d'alignement de 2n si le champ Adresse d'entretien n'est pas présent. Autrement, il a une exigence d'alignement de 8n + 2.

                     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 = 35   |   Longueur    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
|   Identifiant de lien (BID)   |     État      |H|   Réservé   |
+---------------+---------------+---------------+-+-------------+
+                                                               +
:                Adresse d'entretien IPv4 ou IPv6 (CoA)         :
+                                                               +
+---------------+---------------+---------------+---------------+

Figure 5 : Option de mobilité BID

Type : la valeur du type pour l'identifiant de lien est 35.

Longueur : entier non signé de 8 bits. Longueur de l'option, en octets, à l'exclusion des champs Type et Longueur. Il DOIT être réglé à 4, 8, ou 20 selon le champ Adresse d'entretien. Quand l'adresse d'entretien n'est pas portée dans cette option, la valeur de longueur DOIT être réglée à 4. Si l'adresse d'entretien IPv4 est mémorisée dans le champ Adresse d'entretien, la longueur DOIT être 8. Autrement, la valeur de longueur DOIT être réglé à 20 pour les adresses d'entretien IPv6.

Identifiant de lien (BID) : le BID qui est alloué au lien indiqué par l'adresse d'entretien dans la Mise à jour de lien ou l'option de mobilité Identifiant de lien. Le BID est un entier non signé de 16 bits. La valeur de zéro est réservée et NE DEVRAIT PAS être utilisée.

État : le champ État est un entier non signé de 8 bits. Quand l'option de mobilité Identifiant de lien est incluse dans un Accusé de réception de lien, ce champ écrase le champ État dans l'accusé de réception de lien seulement pour ce BID. Si ce champ est réglé à zéro, le receveur ignore ce champ et utilise l'état d'enregistrement mémorisé dans le message Accusé de réception de lien. Le receveur DOIT ignorer ce champ si l'option de mobilité Identifiant de lien n'est pas portée dans les messages Accusé de réception de lien ou Essai d'entretien. Les codes d'état possibles sont les mêmes que les codes d'état de l'Accusé de réception de lien. Ce champ État est aussi utilisé pour porter les informations d'erreur relatives à l'essai d'adresse d'entretien dans le message Essai d'entretien.

Fanion Lien simultané de rattachement et étranger (H) : ce fanion indique que le nœud mobile enregistre plusieurs liens à l'agent de rattachement tandis qu'il est rattaché à la liaison de rattachement. Ce fanion est valide seulement pour une Mise à jour de lien envoyée à l'agent de rattachement.

Réservé  : champ de 7 bits réservés. La valeur DOIT être initialisée à zéro par l'envoyeur, et DEVRAIT être ignorée par le receveur.

Adresse d'entretien : si une option de mobilité Identifiant de lien est incluse dans une Mise à jour de lien pour l'enregistrement de rattachement, des adresses d'entretien IPv4 ou IPv6 pour le BID correspondant peuvent être mémorisées dans ce champ. Pour l'enregistrement de lien aux nœuds correspondants (c'est-à-dire, l'optimisation de chemin) seules des adresses d'entretien IPv6 peuvent être mémorisées dans ce champ. Si aucune adresse n'est spécifiée dans ce champ, la longueur de ce champ DOIT être zéro (c'est-à-dire, ne pas apparaître dans l'option). Si l'option est incluse dans un message autre que de mise à jour de lien, la longueur de ce champ DOIT aussi être zéro.

 	4.4	Nouvelles valeurs d'état pour l'accusé de réception de lien
De nouvelles valeurs d'état pour le champ État dans un Accusé de réception de lien sont définies pour traiter plusieurs enregistrements d'adresses d'entretien :

MCOA INCOMPLETE (4) (adresse d'entretien mobile non complète) : Dans l'enregistrement en vrac, toutes les options de mobilité Identifiant de lien n'ont pas été enregistrées avec succès. Certaines ont été rejetées. La valeur d'état d'erreur de l'option de mobilité défaillante est mémorisée individuellement dans le champ État de l'option de mobilité Identifiant de lien.

MCOA RETURNHOME WO/NDP (5) (NDP interdit pour adresse d'entretien mobile de retour chez elle) : Quand un nœud mobile retourne à son réseau de rattachement, il NE DOIT PAS utiliser le protocole de découverte de voisin (NDP, Neighbor Discovery Protocol) pour l'adresse de rattachement sur la liaison de rattachement. Ceci est expliqué plus en détails au paragraphe 5.6.

MCOA MALFORMED (164) (adresse d'entretien mobile mal formée) : L'enregistrement a échoué parce que l'option de mobilité Identifiant de lien n'était pas formatée correctement. Cette valeur est utilisée dans les cas suivants :
*	quand une mauvaise valeur de longueur est spécifiée (ni 4, 8, ni 20) dans le champ Longueur de l'option de mobilité Identifiant de lien,
*	quand une adresse acheminable en envoi individuel n'est pas spécifiée dans le champ Adresse d'entretien de l'option de mobilité Identifiant de lien,
*	quand une adresse d'entretien n'apparaît pas dans le champ Adresse d'entretien de l'option de mobilité Identifiant de lien mémorisée dans une mise à jour de lien protégée par une charge utile de sécurité encapsulante (ESP, Encapsulating Security Payload) IPsec.

MCOA NON-MCOA BINDING EXISTS (165) (il existe un lien adresse d'entretien mobile non adresse d'entretien mobile) : Indique qu'un enregistrement d'amorçage de plusieurs adresses d'entretien a été effectué sans que le fanion "O" soit établi.

MCOA UNKOWN COA (167) : Indique qu'une option de mobilité Identifiant de lien n'incluait pas de champs Adresse d'entretien et que le receveur n'a pas d'enregistrement pour l'identifiant de lien indiqué dans la même option.

MCOA PROHIBITED (166) (adresse d'entretien mobile interdite) : Implique que plusieurs enregistrements d'adresses d'entretien est administrativement interdit.

MCOA BULK REGISTRATION PROHIBITED (168) (enregistrement en vrac d'adresse d'entretien mobile interdit)  : l'enregistrement de lien en vrac est soit interdit, soit non pris en charge. Noter que l'enregistrement en vrac est une procédure facultative et pourrait n'être pas disponible sur un agent de rattachement.

MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169) (adresse d'entretien mobile de rattachement et étrangère simultanée interdite) : le rattachement simultané au réseau de rattachement et à un réseau étranger n'est ni pris en charge ni permis.

 	5.	Fonctionnement du nœud mobile
 	5.1	Gestion de la ou des adresses d'entretien et des identifiants de lien
Il y a deux cas où un nœud mobile pourrait acquérir plusieurs adresses d'entretien. Un mélange des deux cas est aussi possible. Noter qu'un nœud mobile peut utiliser un BID sans considération du nombre d'interfaces et adresses d'entretien. Si un nœud mobile utilise ou non le BID est déterminé par une configuration locale.

1.	Un nœud mobile utilise plusieurs interfaces réseau physiques et acquiert une adresse d'entretien sur chacune de ses interfaces.

2.	Un nœud mobile utilise une seule réseau interface physique mais reçoit des annonces pour plusieurs préfixes sur la liaison à laquelle l'interface est rattachée. Il va en résulter que le nœud mobile configure plusieurs adresses mondiales sur l'interface à partir de chaque préfixe annoncé.

La différence entre les deux cas ci-dessus est seulement dans le nombre des interfaces réseau physiques et est donc sans importance dans le présent document. Ce qui est significatif est le fait que le nœud mobile a plusieurs adresses qu'il peut utiliser comme adresses d'entretien.

Un nœud mobile alloue un BID à chaque adresse d'entretien quand il veut les enregistrer simultanément avec son adresse de rattachement. Le BID DOIT être unique pour une adresse de rattachement donnée. La valeur est un entier entre 1 et 65535. Une valeur de zéro NE DEVRAIT PAS être utilisée comme BID. Si un nœud mobile a seulement une adresse d'entretien, l'allocation d'un BID n'est pas nécessaire jusqu'à ce qu'il ait plusieurs adresses d'entretien avec lesquelles s'enregistrer, moment auquel toutes les adresses d'entretien DOIVENT être transposées en des BID.

Quand un nœud mobile enregistre un BID donné pour la première fois, il DOIT inclure le champ Adresse d'entretien dans l'option de mobilité Identifiant de lien. Pour tous les enregistrements suivants qui ré-enregistrent ou désenregistrent le même BID, le MN n'a pas besoin d'inclure de champ Adresse d'entretien dans l'option de mobilité Identifiant de lien.

 	5.2.	Enregistrement de lien
Pour l'enregistrement de plusieurs adresses d'entretien, le nœud mobile DOIT inclure une ou des options de mobilité Identifiant de lien dans la mise à jour de lien comme montré à la Figure 6.

Quand IPsec ESP est utilisé pour protéger la mise à jour de lien, une adresse d'entretien DOIT être portée dans une autre option de mobilité Adresse d'entretien comme décrit dans la [RFC4877]. Cependant, dans la présente spécification, l'adresse d'entretien DOIT être portée dans le champ Adresse d'entretien de l'option de mobilité Identifiant de lien. Afin d'économiser les bits de la mise à jour de lien, l'autre option Adresse d'entretien NE DOIT PAS être incluse.

Pour l'enregistrement de lien à un nœud correspondant, le nœud mobile DOIT avoir les deux jetons Keygen de rattachement et d'entretien actifs pour la clé de gestion de lien (Kbm, binding management key ; voir au paragraphe 5.2.5 de la [RFC3775]) avant d'envoyer la mise à jour de lien. Les jetons Keygen d'entretien DOIVENT être maintenus pour chaque adresse d'entretien que le nœud mobile veut enregistrer au nœud correspondant. La mise à jour de lien au nœud correspondant est protégée par l'option de mobilité Données d'autorisation de lien qui est placée après l'option de mobilité Identifiant de lien.

             IPv6 en-tête (src=Adresse d'entretien, dst=Adresse de l'agent de rattachement)
                 Option Adresse de rattachement IPv6
                  En-tête ESP *	(*) si nécessaire, pour l'enregistrement de rattachement
                  En-tête de mobilité
                      Mise à jour de lien
                     Options de mobilité
                        option de mobilité Identifiant de lien
                        option de mobilité Autorisation de lien+	(+) si nécessaire, pour l'optimisation de chemin

Figure 6 : Mise à jour de lien pour enregistrement de lien

Si le nœud mobile veut remplacer les liens enregistrés existants sur l'agent de rattachement avec le seul lien de la mise à jour de lien envoyée, il établit le fanion "O". Si le fanion "O" n'est pas établi, alors le lien va être ajouté aux liens existants chez l'agent de rattachement. Le seul lien va être enregistré avec le BID alloué. Le paragraphe 6.2 décrit cette procédure d'enregistrement en détail.

 	5.3	Enregistrement en vrac
L'enregistrement en vrac est une optimisation pour lier plusieurs adresses d'entretien à une adresse de rattachement en utilisant une seule mise à jour de lien. Ceci est très utile si le nœud mobile, par exemple, ne veut pas envoyer beaucoup de messages de signalisation à travers une interface où la bande passante est rare. Le présent document spécifie l'enregistrement en vrac seulement pour l'enregistrement de rattachement du nœud mobile. Un nœud mobile qui effectue un enregistrement en vrac avec un nœud correspondant sort du domaine d'application du présent mémoire.

Pour utiliser l'enregistrement en vrac, le nœud mobile inclut une option de mobilité Identifiant de lien pour chaque BID qu'il veut enregistrer dans le même message Mise à jour de lien. Comme avec les enregistrements seuls (voir le paragraphe 5.1) le champ Adresse d'entretien est inclus pour chaque BID enregistré pour la première fois. Ceci est montré à la Figure  7. Le reste des champs et options dans la mise à jour de lien (comme la durée de vie, le numéro de séquence, et les fanions dans la mise à jour de lien) sont communs à toutes les adresses d'entretien.

           En-tête IPv6 (src=Adresse d'entretien, dst=Adresse d'agent de rattachement)
                Option Adresse de rattachement IPv6
                En-tête ESP
                En-tête de mobilité
                    Mise à jour de lien
                   Options de mobilité
                      Identifiant de lien1 (incluant l'adresse d'entretien)
                      Identifiant de lien2 (incluant l'adresse d'entretien)
                      Identifiant de lien3 (pas d'adresse d'entretien)
                      Identifiant de lienN (pas d'adresse d'entretien)
                              :

Figure 7 : Mise à jour de lien pour enregistrement en vrac

Comme avec les enregistrements réguliers, si le nœud mobile veut remplacer les liens enregistrés existants sur l'agent de rattachement par plusieurs liens dans la mise à jour de lien envoyée, il établit le fanion "O" dans la mise à jour de lien ; autrement, les liens sont ajoutés aux liens existants dans l'agent de rattachement.

 	5.4	Désenregistrement de lien
Quand un nœud mobile décide de supprimer les liens pour son adresse de rattachement, il envoie une mise à jour de lien régulière de désenregistrement avec la durée de vie réglée à zéro comme défini dans la [RFC3775]. L'option de mobilité Identifiant de lien n'est pas exigée.

Si un nœud mobile veut supprimer un ou des liens particuliers de son agent de rattachement et des nœuds correspondants, le nœud mobile envoie une mise à jour de lien avec la durée de vie réglée à zéro et inclut une ou des options de mobilité Identifiant de lien avec le ou les BID qu'il veut désenregistrer. Le receveur va supprimer seulement la ou les adresses d'entretien qui correspondent aux BID spécifiés. Comme les tentatives de désenregistrement pour supprimer un BID qui existe déjà, le champ Adresse d'entretien dans chaque option Identifiant de lien peut être omis par l'envoyeur comme défini au paragraphe 5.1.

 	5.5	Retour au réseau de rattachement avec un désenregistrement de lien complet : sur une seule interface
Le nœud mobile peut retourner à la liaison de rattachement en s'attachant à la liaison de rattachement par une de ses interfaces. Quand le nœud mobile veut retourner à son réseau de rattachement, il devrait être configuré avec des informations sur l'interface qu'il a besoin d'utiliser.

 	5.5.1	Utilisation seulement de l'interface attachée à la liaison de rattachement
Le nœud mobile retourne à son réseau de rattachement et se désenregistre de tous les liens qu'il a avec l'agent de rattachement, comme montré à la Figure 2 et comme défini dans la [RFC3775]. Après l'étape de désenregistrement, tous les paquets acheminés par l'agent de rattachement sont seulement transmis à l'interface rattachée à la liaison de rattachement, même si il y a d'autres interfaces actives rattachées à la ou les liaisons visitées. Pendant que le nœud mobile se désenregistre de tous les liens provenant de l'agent de rattachement, il peut continuer d'enregistrer au nœud correspondant les liens pour les interfaces attachées aux liaisons visitées comme montré à la Figure 2.

 	5.5.2	Utilisation seulement de l'interface attachée à la liaison visitée
Le nœud mobile retourne physiquement au réseau de rattachement mais ferme l'interface attachée à la liaison de rattachement. Par suite, un nœud mobile ne retourne pas à son réseau de rattachement même si il se rattache à la liaison de rattachement par une des interfaces. Avant de fermer l'interface, tout lien pour l'adresse d'entretien précédemment associée à l'interface devrait être supprimée comme défini au paragraphe 5.4.

Dans ce scénario, en dépit du fait que le nœud mobile est connecté à sa liaison de rattachement, tout son trafic est envoyé et reçu via l'agent de rattachement et ses liaisons étrangères.

 	5.6	Retour au réseau de rattachement : fonctionnement simultané de la liaison de rattachement et visitée
 	5.6.1	Problèmes des rattachements simultanés local et étranger
Le nœud mobile retourne à son réseau de rattachement et continue en utilisant toutes les interfaces attachées à la fois aux liaisons étrangères et de rattachement comme montré à la Figure 3.

Dans la [RFC3775], l'agent de rattachement intercepte les paquets destinés au nœud mobile en utilisant  la découverte de voisin mandataire [RFC4861] tandis que le nœud mobile est éloigné de la liaison de rattachement. Quand le nœud mobile retourne au réseau de rattachement, l'agent de rattachement supprime l'antémémoire de liens et cesse de relayer l'adresse de rattachement afin qu'un nœud mobile puisse configurer son adresse de rattachement sur l'interface attachée à la liaison de rattachement. Dans la présente spécification, un nœud mobile peut retourner à son réseau de rattachement et configurer l'adresse de rattachement sur l'interface attachée à la liaison de rattachement, mais utiliser encore les interfaces attachées aux liaisons étrangères. Dans ce cas, un conflit possible survient quand l'agent de rattachement et le nœud mobile essayent tous deux de défendre l'adresse de rattachement. Si l'agent de rattachement cesse de relayer l'adresse de rattachement, les paquets sont toujours acheminés à l'interface attachée à la liaison de rattachement et ne sont jamais acheminés aux interfaces attachées aux liaisons visitées. Les déploiements qui utilisent plusieurs adresses d'entretien sont obligés d'éviter des conflits de configuration entre l'agent de rattachement et le nœud mobile, tout en permettant quand même l'utilisation simultanée des liaisons étrangères et de rattachement. On décrit ensuite le mécanisme pour le faire.

 	5.6.2	Vue d'ensemble et approche
L'agent de rattachement DOIT intercepter tous les paquets destinés au nœud mobile, que le nœud mobile soit ou non rattaché à la liaison de rattachement, et décider si il envoie le trafic directement à l'adresse de rattachement sur la liaison ou le tunneler à l'adresse d'entretien.

Deux scénarios sont illustrés à la Figure 3, selon que l'agent de rattachement est ou non le seul routeur à la liaison de rattachement. La différence est qui défend l'adresse de rattachement par la découverte de voisin (mandataire) sur la liaison de rattachement.

1.	Le nœud mobile défend l'adresse de rattachement par le protocole régulier de découverte de voisin (illustré comme topologie a) dans la Figure 3). L'agent de rattachement est le seul routeur sur la liaison de rattachement. Donc, l'agent de rattachement est capable d'intercepter les paquets sans s'appuyer sur le protocole de découverte de voisin mandataire, et le nœud mobile peut gérer l'entrée d'antémémoire de voisin de l'adresse de rattachement sur la liaison de rattachement comme un nœud IPv6 régulier. Cependant, il y a une limitation à ce scénario. Si un nœud correspondant est situé à la liaison de rattachement, l'agent de rattachement ne peut pas intercepter les paquets destinés au nœud mobile. Ces paquets sont acheminés seulement via la liaison de rattachement, mais c'est le chemin optimal pour que le nœud mobile communique avec les nœuds sur la liaison de rattachement.

2.	Si il y a des routeurs autres que l'agent de rattachement sur la liaison de rattachement, alors il ne peut pas être garanti que tous les paquets destinés au nœud mobile soient acheminés à l'agent de rattachement. Dans ce cas, le nœud mobile NE DOIT PAS utiliser le protocole de découverte de voisin pour l'adresse de rattachement sur la liaison de rattachement. Cela permet à l'agent de rattachement de continuer d'utiliser la découverte de voisin mandataire, et donc il continue de recevoir tous les paquets envoyés à l'adresse de rattachement du nœud mobile. Si l'agent de rattachement, en accord avec sa politique locale, a besoin de livrer des paquets au nœud mobile sur la liaison de rattachement, un problème se pose par rapport à la façon dont l'agent de rattachement découvre l'adresse de liaison locale du nœud mobile. La présente spécification utilise l'option Adresse de couche de liaison d'en-tête de mobilité définie dans la [RFC5568] afin de porter l'adresse de couche de liaison du nœud mobile dans la mise à jour de lien. De même, le nœud mobile va aussi connaître l'adresse de couche de liaison de l'adresse du routeur par défaut où envoyer les paquets provenant de la liaison de rattachement sans découverte de voisin. L'adresse de couche de liaison est utilisée pour transmettre les paquets de et vers le nœud mobile sur la liaison de rattachement. Les paquets sont transmis sans le protocole de découverte de voisin en construisant manuellement l'en-tête de couche de liaison. Cette opération est similaire à celle de IPv6 mobile [RFC3775] quand un nœud mobile envoie une mise à jour de lien de désenregistrement à l'adresse de couche de liaison de l'agent de rattachement dans l'opération pour le retour au réseau de rattachement.

 	5.6.3	Prise en charge du lien de ratttachement
Quand le lien de rattachement est utilisé, le nœud mobile DOIT envoyer une mise à jour de lien d'enregistrement avec une option de mobilité Identifiant de lien avec le fanion "H" établi. La durée de vie DOIT être réglée à une valeur non zéro du lien de rattachement, et le champ Adresse d'entretien DOIT être réglé à l'adresse de rattachement. Le nœud mobile enregistre seulement un lien de rattachement à la fois, même si il s'attache à la liaison de rattachement par plusieurs interfaces.

Le nœud mobile DEVRAIT aussi inclure l'option Adresse de couche de liaison d'en-tête de mobilité [RFC5568] pour notifier l'adresse de couche de liaison du nœud mobile à l'agent de rattachement. Le code d'option de l'option Adresse de couche de liaison d'en-tête de mobilité DOIT être réglé à "2" (adresse de couche de liaison du nœud mobile). Cette adresse de couche de liaison est exigée pour que l'agent de rattachement envoie l'accusé de réception de lien et transmette le paquet du nœud mobile.

Selon la [RFC3775], le nœud mobile DOIT commencer à répondre à une sollicitation de voisin pour son adresse de rattachement juste après qu'il envoie la mise à jour de désenregistrement de lien à l'agent de rattachement. Cependant, dans la présente spécification, le nœud mobile NE DOIT PAS répondre à une sollicitation de voisin avant de recevoir un accusé de réception de lien, car l'agent de rattachement peut continuer de relayer pour l'adresse de rattachement. Si le nœud mobile reçoit la valeur d'état [MCOA RETURNHOME WO/NDP (5)] dans l'accusé de réception de lien reçu, il NE DOIT PAS répondre à la sollicitation de voisin même après l'accusé de réception de lien.

La gestion du lien de rattachement est la même que la gestion de lien décrite dans la présente spécification. Le lien de rattachement peut être inclus dans un enregistrement en vrac de liens (paragraphe 5.3). Le MN DEVRAIT rafraîchir la durée de vie du lien de rattachement en envoyant des mises à jour de lien appropriées avec tous les autres liens

 	5.6.4	Envoi de paquets depuis la liaison de rattachement
o	Quand le nœud mobile reçoit l'accusé de réception de lien avec la valeur d'état "Mise à jour de lien acceptée" et l'option BID, il peut configurer son adresse de rattachement à l'interface attachée à la liaison de rattachement et commencer d'effectuer la découverte de voisin pour l'adresse de rattachement sur la liaison de rattachement. Les paquets peuvent être transmis de et vers le nœud mobile comme si le nœud mobile était un nœud régulier IPv6.

o	Si le nœud mobile reçoit l'état [MCOA RETURNHOME WO/NDP] dans l'accusé de réception de lien, il NE DOIT PAS effectuer la découverte de voisin pour l'adresse de rattachement. Quand le nœud mobile envoie des paquets de l'interface attachée à la liaison de rattachement, il DOIT apprendre l'adresse de couche de liaison du prochain bond (c'est-à-dire, le routeur par défaut du nœud mobile). Un nœud mobile apprend l'adresse de couche de liaison du routeur par défaut d'une option Adresse de couche de liaison de source dans les annonces de routeur. Le nœud mobile envoie les paquets directement à l'adresse de couche de liaison du routeur par défaut. Ceci est fait en construisant le paquet comme incluant l'en-tête de couche de liaison avec l'adresse de couche de liaison apprise du routeur par défaut. L'agent de rattachement transmet aussi le paquet au nœud mobile sur la liaison de rattachement en utilisant l'adresse de couche de liaison du nœud mobile. L'adresse de couche de liaison DEVRAIT être mise en antémémoire quand l'agent de rattachement reçoit le messages de mise à jour de lien de désenregistrement. Noter que le routeur par défaut NE DOIT PAS mettre en antémémoire l'adresse de couche de liaison du nœud mobile dans l'antémémoire de voisins quand il transmet le paquet du nœud mobile à l'agent de rattachement.

 	5.6.5	Départ de la liaison de rattachement
Quand le nœud mobile se détache de la liaison de rattachement, il DEVRAIT immédiatement envoyer une mise à jour de lien pour une des adresses d'entretien actives avec le fanion "H" à zéro. Quand le fanion "H" de l'option BID est à zéro dans une mise à jour de lien, l'agent de rattachement cesse de transmettre les paquets du nœud mobile à la liaison de rattachement.

 	5.7	Réception d'un accusé de réception de lien
La vérification d'un accusé de réception de lien est la même que dans IPv6 mobile (paragraphe 11.7.3 de la [RFC3775]). L'opération d'envoi d'un accusé de réception de lien est décrite au paragraphe 6.2.

Si un nœud mobile inclut une option de mobilité Identifiant de lien dans une mise à jour de lien avec le fanion "A" établi, un accusé de réception de lien DEVRAIT porter une option de mobilité Identifiant de lien. En accord avec la [RFC3775], le receveur de la mise à jour de lien ignore les options de mobilité inconnues et traite la mise à jour de lien sans l'option de mobilité inconnue. Donc, si aucune option de mobilité n'est incluse dans l'accusé de réception de lien en réponse à une mise à jour de lien pour un enregistrement de plusieurs adresses d'entretien, cela indique que le nœud d'origine de l'accusé de réception de lien ne prend pas en charge le traitement de l'option de mobilité Identifiant de lien sans considération de la valeur d'état. Dans ce cas, le receveur de la mise à jour de lien peut créer un lien régulier. Le nœud mobile DEVRAIT alors ne plus tenter un enregistrement de plusieurs adresses d'entretien avec ce nœud. Si cela se produit avec l'enregistrement de rattachement, le nœud mobile PEUT tenter de découvrir un autre agent de rattachement qui prend en charge l'option de mobilité Identifiant de lien pour l'enregistrement de rattachement.

Si une option de mobilité Identifiant de lien est présente dans l'accusé de réception de lien reçu, le nœud mobile vérifie le champ État dans l'option. Si la valeur d'état dans l'option de mobilité Identifiant de lien est zéro, le nœud mobile utilise la valeur dans le champ État de l'accusé de réception de lien. Autrement, il utilise la valeur dans le champ État de l'option de mobilité Identifiant de lien.

Si le code d'état est supérieur ou égal à 128, le nœud mobile commence les opérations pertinentes en accord avec le code d'erreur. Autrement, le nœud mobile suppose que l'origine (agent de rattachement ou nœud correspondant) a réussi à enregistrer les informations de lien et le BID pour le nœud mobile.

o	Si la valeur d'état est [MCOA PROHIBITED] (adresse d'entretien mobile interdite) le nœud mobile DOIT cesser d'enregistrer plusieurs liens avec le nœud qui a envoyé l'accusé de réception de lien.

o	Si la valeur d'état est [MCOA BULK REGISTRATION PROHIBITED] (enregistrement en vrac d'adresse d'entretien mobile interdit) le nœud mobile doit arrêter d'utiliser des enregistrements en vrac avec le nœud qui a envoyé l'accusé de réception de lien. Il devrait supposer qu'aucune des tentatives d'enregistrement n'a réussi.

o	Si [MCOA MALFORMED] est spécifié, cela indique que l'option de mobilité Identifiant de lien est mal formatée, probablement à cause d'une erreur de programmation ou d'une corruption majeure de paquet.

o	Si [MCOA NON-MCOA BINDING EXISTS] est spécifié, cela signifie qu'il y a une entrée de lien non MCoA chez le receveur. Le nœud mobile DOIT établir le fanion "O" afin que tous les liens enregistrés soient remplacés par un des enregistrements de MCoA comme décrit au paragraphe 5.9.

o	Si [MCOA UNKNOWN COA] est spécifié, cela signifie que le nœud mobile a envoyé une option de mobilité Identifiant de lien sans champ Adresse d'entretien, mais le receveur pourrait ne pas trouver d'entrée pour le BID indiqué. Si le nœud mobile essaye de désenregistrer un BID, il n'a pas besoin de faire autre chose. Si le nœud mobile essaye de rafraîchir un lien, il DEVRAIT envoyer une option de mobilité Identifiant de lien incluant le champ Adresse d'entretien.

 	5.8	Réception d'une demande de rafraîchissement de lien
La vérification d'une demande de rafraîchissement de lien est la même que dans IPv6 mobile (paragraphe 11.7.4 de la [RFC3775]). L'opération d'envoi d'une demande de rafraîchissement de lien est décrite au paragraphe 6.4.

Si un nœud mobile reçoit une demande de rafraîchissement de lien avec une option de mobilité Identifiant de lien, cela indique que le nœud qui envoie le message Demande de rafraîchissement de lien demande que le nœud mobile envoie une nouvelle mise à jour de lien pour le BID. Le nœud mobile DEVRAIT alors envoyer une mise à jour de lien au moins pour les liens respectifs, comme décrit aux paragraphes 5.2 et 5.3.

 	5.9	Amorçage
Quand un nœud mobile s'amorce et enregistre plusieurs liens pour la première fois, il DOIT établir le fanion "O" dans le message Mise à jour de lien. Si de vieux liens existent encore chez l'agent de rattachement, le nœud mobile n'a pas connaissance de quels liens existent encore chez l'agent de rattachement. Ce scénario arrive quand un nœud mobile se réamorce et perd l'état concernant les enregistrements. Si le fanion "O" est établi, tous les liens sont remplacés par les nouveaux liens.

 	6.	Fonctionnement de l'agent de rattachement et du nœud correspondant
 	6.1	Recherche dans l'antémémoire de liens avec un identifiant de lien
Si un nœud correspondant ou un agent de rattachement a plusieurs liens pour un nœud mobile dans sa base de données d'antémémoire de liens, il peut utiliser un des liens pour communiquer avec le nœud mobile. Cette section explique comment restituer le lien désiré pour la gestion de liens. Le présent document ne fournit aucun mécanisme pour choisir le lien convenable pour transmettre les paquets de données.

Un nœud qui est un nœud correspondant ou un agent de rattachement DEVRAIT utiliser l'adresse de rattachement et le BID comme clés de recherche dans l'antémémoire de liens si il connaît le BID correspondant (par exemple, quand il traite des messages de signalisation). Dans l'exemple ci-dessous, si un nœud cherche le lien avec l'adresse de rattachement et BID2, il obtient le lien2 pour ce nœud mobile.

lien1 [2001:db8::EUI,  adresse d'entretien1,  BID1]
lien2 [2001:db8::EUI,  adresse d'entretien2,  BID2]
lien3 [2001:db8::EUI,  adresse d'entretien3,  BID3]

Figure 8 : Recherche dans l'antémémoire de liens

Le nœud apprend le BID quand il reçoit une option de mobilité Identifiant de lien. À ce moment, le nœud DOIT examine sa  base de données d'antémémoire de liens avec l'adresse de rattachement et le BID restitué de la mise à jour de lien. Si le nœud ne connaît pas le BID, il cherche un lien avec seulement l'adresse de rattachement. Dans ce cas, le premier lien qui correspond est trouvé. Si le nœud ne désire pas utiliser plusieurs liens pour un nœud mobile, il peut simplement ignorer le BID.

 	6.2	Traitement de la mise à jour de lien
Si une mise à jour de lien ne contient pas d'option de mobilité Identifiant de lien, son traitement est le même que dans la [RFC3775]. Si le receveur a déjà plusieurs liens pour l'adresse de rattachement, il DOIT remplacer tous les liens existants par le lien reçu. Si la mise à jour de lien est pour un désenregistrement, le receveur DOIT supprimer tous les liens existants de son antémémoire de liens.

Si la mise à jour de lien contient une option de mobilité Identifiant de lien, elle est d'abord validée selon le paragraphe 9.5.1 de la [RFC3775]. Ensuite le receveur traite l'option de mobilité Identifiant de lien comme décrit dans les étapes suivantes.

o	La valeur de longueur est examinée. La valeur de longueur DOIT être 4, 8, ou 20 selon le champ Adresse d'entretien. Si la longueur est incorrecte, le receveur DOIT rejeter la mise à jour de lien et retourner la valeur d'état réglée à [MCOA MALFORMED].

o	Quand la valeur de longueur est 8 ou 20, l'adresse d'entretien DOIT être présente dans l'option de mobilité Identifiant de lien. Si l'adresse d'envoi individuel acheminable [RFC3775] n'est pas présente dans le champ Adresse d'entretien, le receveur DOIT rejeter l'option de mobilité Identifiant de lien et retourner la valeur d'état réglée à [MCOA MALFORMED].

o	Quand plusieurs options de mobilité Identifiant de lien sont présentes dans la mise à jour de lien, elle est traitée comme un enregistrement en vrac. Si le nœud receveur est un nœud correspondant, il DOIT rejeter la mise à jour de lien et retourner la valeur d'état réglée à [MCOA BULK REGISTRATION PROHIBITED] dans l'accusé de réception de lien.

o	Si le champ Durée de vie dans la mise à jour de lien est réglé à zero, le nœud receveur supprime l'entrée de lien qui correspond au BID dans l'option de mobilité Identifiant de lien. Si le nœud receveur n'a pas de lien approprié pour le BID, il DOIT rejeter la mise à jour de lien et envoyer un accusé de réception de lien avec l'état réglé à 133 [pas d'agent de rattachement pour ce nœud mobile].

o	Si le fanion "O" est établi dans la mise à jour de lien de désenregistrement, il est ignoré. Si le fanion "H" est établi, l'agent de rattachement mémorise une adresse de rattachement dans le champ Adresse d'entretien de l'entrée d'antémémoire de lien. L'agent de rattachement DOIT suivre les descriptions du paragraphe 5.6.

o	Si le champ Durée de vie n'est pas réglé à zéro, le nœud receveur enregistre un lien avec le BID spécifié comme lien d'un nœud mobile. L'adresse d'entretien est obtenue du paquet de mise à jour de lien comme suit :
*	Si la valeur de longueur de l'option de mobilité Identifiant de lien est 20, l'adresse d'entretien est l'adresse IPv6 copiée du champ Adresse d'entretien dans l'option de mobilité Identifiant de lien.
*	Quand la valeur de longueur est 8, l'adresse DOIT être l'adresse IPv4 valide. Comment obtenir une adresse d'entretien IPv4 est décrit à la Section 8.
*	Quand la valeur de longueur est 4 et que l'identifiant de lien est présent dans l'antémémoire de liens, le nœud receveur DOIT mettre à jour l'entrée de lien associée. Autrement, le nœud receveur DOIT rejeter cette option de mobilité Identifiant de lien et envoyer un accusé de réception de lien avec l'état pour cette option de mobilité Identifiant de lien réglé à [MCOA INCONNU].

o	Une fois que la ou les adresses d'entretien ont été restituées de la mise à jour de lien, les nœuds receveurs créent de nouveaux liens.
*	Si le fanion "O" est établi dans la mise à jour de lien, le nœud receveur supprime tous les liens existants et enregistre le ou les liens reçus.
*	Si le fanion "O" est à zéro dans la mise à jour de lien et si le receveur a un lien régulier qui n'a pas de BID pour le nœud mobile, il ne doit pas traiter la mise à jour de lien. Le receveur devrait envoyer un accusé de réception de lien avec l'état réglé à [MCOA NON-MCOA BINDING EXISTS].
*	Si le receveur a déjà un lien avec le même BID mais une adresse d'entretien différente, il DOIT mettre à jour le lien et répondre avec un accusé de réception de lien dont l'état est réglé à 0 [Mise à jour de lien acceptée].
*	Si le receveur n'a pas d'entrée de lien pour le BID, il enregistre un nouveau lien pour le BID et répond avec un accusé de réception de lien dont l'état est réglé à 0 [Mise à jour de lien acceptée].

Si toutes les opérations ci-dessus sont accomplies avec succès et si le fanion "A" est établi dans la mise à jour de ln, un accusé de réception de lien contenant les options de mobilité Identifiant de lien DOIT être envoyé au nœud mobile. Chaque fois qu'un accusé de réception de lien est envoyé, toutes les options de mobilité Identifiant de lien mémorisées dans la mise à jour de lien DOIVENT être copiées dans l'accusé de réception de lien sauf le champ État. Le champ Adresse d'entretien dans chaque option de mobilité Identifiant de lien PEUT cependant être omis, parce que le nœud mobile peut correspondre à une entrée de liste de mises à jour de lien en utilisant le BID.

Quand un nœud correspondant envoie un accusé de réception de lien, la valeur d'état DOIT toujours être mémorisée dans le champ État de l'accusé de réception de lien et le champ État de l'option de mobilité Identifiant de lien DOIT toujours être réglé à zero.

Quand l'agent de rattachement envoie un accusé de réception de lien, la valeur d'état peut être mémorisée dans le champ État d'un accusé de réception de lien ou d'une option de mobilité Identifiant de lien. Si la valeur d'état est spécifique d'un des liens dans l'enregistrement en vrac, la valeur d'état DOIT être mémorisée dans le champ État dans l'option de mobilité Identifiant de lien correspondante. Dans ce cas, le champ État de l'accusé de réception de lien DOIT être réglé à [MCOA INCOMPLETE], de sorte que le receveur peut examiner le champ État de chaque option de mobilité Identifiant de lien pour les opérations ultérieures. Autrement, le champ État de l'option de mobilité Identifiant de lien DOIT être réglé à zéro et le champ État de l'agent de rattachement de l'accusé de réception de lien est utilisé.

 	6.3	Envoi d'un accusé de réception de lien pour l'enregistrement de la liaison de rattachement
Les opérations décrites dans ce paragraphe se rapportent au retour au réseau de rattachement avec l'utilisation simultanée de liaisons de rattachement et étrangères.

o	Quand l'agent de rattachement envoie l'accusé de réception de lien après la réussite de traitement de l'enregistrement du lien de rattachement, il DOIT régler la valeur d'état à 0 [Mise à jour de lien Acceptée] ou à [MCOA RETURNHOME WO/NDP (5)] dans le champ État de l'accusé de réception de lien, selon la configuration de l'agent de rattachement à la liaison de rattachement. Les nouvelles valeurs sont :
*	Mise à jour de lien acceptée (0) : le protocole de découverte de voisin est permis pour l'adresse de rattachement à la liaison de rattachement. C'est l'opération régulière de retour au réseau de rattachement de la [RFC3775].
*	MCOA RETURNHOME WO/NDP (5) : le protocole de découverte de voisin est interdit pour l'adresse de rattachement à la liaison de rattachement.

Les options respectives de mobilité Identifiant de lien doivent être incluses dans l'accusé de réception de lien.

o	Si la mise à jour de lien est rejetée, la valeur d'erreur appropriée DOIT être réglée dans le champ État. Dans ce cas, l'opération de l'agent de rattachement est la même que dans la [RFC3775].

o	C'est seulement si l'agent de rattachement est le seul routeur dans la liaison de rattachement qu'il PEUT désactiver la découverte de voisin pour l'adresse de rattachement demandée et répondre avec la valeur d'état [Mise à jour de lien acceptée] au nœud mobile. Comme le nœud mobile ne va pas répondre à la sollicitation de voisin pour l'adresse de rattachement avant de recevoir l'accusé de réception de lien, l'agent de rattachement DEVRAIT utiliser l'adresse de couche de liaison portée par l'option Adresse de couche de liaison d'en-tête de mobilité [RFC5568] dans la mise à jour de lien reçue. Après l'achèvement de l'enregistrement du lien de rattachement, le nœud mobile commence les opérations  régulières de découverte de voisin pour l'adresse de rattachement sur la liaison de rattachement. L'entrée d'antémémoire de voisin pour l'adresse de rattachement est créée par l'échange régulier de sollicitation de voisin et annonce de voisin.

o	Si l'agent de rattachement n'est pas le seul routeur dans la liaison de rattachement, l'agent de rattachement retourne la valeur d'état [MCOA RETURNHOME WO/NDP] dans le champ État de l'option de mobilité Identifiant de lien. L'agent de rattachement apprend l'adresse de couche de liaison du nœud mobile en recevant l'option Adresse de couche de liaison d'en-tête de mobilité portée par la mise à jour de lien. Il mémorise l'adresse de couche de liaison comme entrée d'antémémoire de voisin pour le nœud mobile afin qu'il puisse envoyer les paquets à l'adresse de couche de liaison du nœud mobile.

o	Noter que l'utilisation de la découverte de voisin mandataire est une façon plus aisée d'intercepter les paquets des nœuds  mobiles au lieu de l'acheminement IP dans certains scénarios de déploiement. Donc, même si un agent de rattachement est le seul routeur, c'est un choix de mise en œuvre et de fonctionnement que l'agent de rattachement retourne [Mise à jour de lien acceptée] ou [MCOA RETURNHOME WO/NDP].

o	Si l'option BID n'est pas incluse dans l'accusé de réception de lien, l'agent de rattachement pourrait ne pas reconnaître l'enregistrement de rattachement. L'agent de rattachement pourrait avoir traité l'enregistrement de mise à jour de lien de rattachement comme un désenregistrement régulier, comme décrit dans la [RFC3775], et supprimé toutes les entrées d'antémémoire de lien enregistrées pour le nœud mobile. Donc, le nœud mobile DEVRAIT cesser d'utiliser l'interface attachée à la liaison étrangère et utiliser seulement l'interface attachée à la liaison de rattachement.

 	6.4	Envoi d'une demande de rafraîchissement de lien
Quand un nœud (agent de rattachement ou nœud correspondant) envoie une demande de rafraîchissement de lien pour un lien particulier créé avec le BID, le nœud DEVRAIT inclure l'option de mobilité Identifiant de lien dans la demande de rafraîchissement de lien. Le nœud PEUT inclure plusieurs options de mobilité Identifiant de lien si il y a plusieurs liens qui ont besoin d'être rafraîchis.

 	6.5	Réception de paquets provenant du nœud mobile
Quand un nœud reçoit des paquets avec une option Adresse de rattachement de destination provenant d'un nœud mobile, il DOIT vérifier que l'adresse d'entretien qui apparaît dans le champ Adresse de source de l'en-tête IPv6 est égale à celle des adresses d'entretien dans l'entrée d'antémémoire de lien. Si aucun lien n'est trouvé, les paquets DOIVENT être éliminés. Le nœud DOIT aussi envoyer un message Erreur de lien comme spécifié dans la [RFC3775]. Cette vérification NE DOIT PAS être faite pour une mise à jour de lien.

 	7.	Applicabilité de la mobilité de réseau

Les mécanismes de gestion de lien sont les mêmes pour un hôte mobile qui utilise IPv6 mobile et pour un routeur mobile qui utilise le protocole de prise en charge de base NEMO [RFC3963]. Donc, les extensions décrites dans le présent document peuvent aussi être utilisées pour prendre en charge un routeur mobile avec plusieurs adresses d'entretien. La [RFC4980] contient une analyse du multi-rattachements NEMO.

 	8.	Applicabilité de DSMIPv6

IPv6 mobile double pile (DSMIPv6, Dual Stack Mobile IPv6) [RFC5555] étend IPv6 mobile pour enregistrer une adresse d'entretien IPv4 au lieu d'une adresse d'entretien IPv6 quand le nœud mobile est rattaché à un réseau d'accès IPv4 seulement. Il permet aussi au nœud mobile d'acquérir une adresse de rattachement IPv4 en plus d'une adresse de rattachement IPv6 à utiliser avec les nœuds correspondants IPv4 seulement. Cette section décrit comment plusieurs enregistrements d'adresses d'entretien fonctionnent avec des adresses d'entretien et de rattachement IPv4.

 	8.1	Enregistrement d'adresse d'entretien IPv4
Le nœud mobile peut utiliser les extensions décrites dans ce document pour enregistrer plusieurs adresses d'entretien, même si certaines des adresses d'entretien sont des adresses IPv4.
L'enregistrement en vrac NE DOIT PAS être utilisé pour l'enregistrement initial de lien d'une adresse d'entretien IPv4. C'est parce que l'échange Mise à jour de lien et Accusé de réception de lien est utilisé pour détecter des NAT sur le chemin entre le nœud mobile et l'agent de rattachement. Donc le nœud mobile a besoin de vérifier si il y a un NAT entre chaque adresse d'entretien IPv4 et l'agent de rattachement.
La mise à jour de lien DOIT être envoyée à l'adresse IPv4 de l'agent de rattachement en utilisant les en-têtes UDP et IPv4 comme montré à la Figure 9. C'est similaire à la [RFC5555] sauf que l'option Adresse d'entretien IPv4 NE DOIT PAS être utilisée quand l'option de mobilité BID est utilisée.

              En-tête IPv4 (src=V4ADDR, dst=HA_V4ADDR)
                En-tête UDP
                  En-tête IPv6 (src=V6HoA, dst=HAADDR)
                       En-tête ESP
                       En-tête de mobilité
                           - Mise à jour de lien
                          Options de mobilité
                            - Identifiant de lien (CoA IPv4)
          *V4ADDR, HA_V4ADDR, V6HOA, HAADDR sont définis dans la [RFC5555]

Figure 9 : Mise à jour de lien initiale pour adresse d'entretien IPv4

Si aucun NAT n'est détecté, le nœud mobile peut mettre à jour l'adresse d'entretien IPv4 en utilisant l'enregistrement en vrac. Le nœud mobile peut enregistrer l'adresse d'entretien IPv4 avec d'autres adresses d'entretien IPv4 et IPv6. La Figure 10 montre le format de mise à jour de lien quand le nœud mobile envoie une mise à jour de lien d'une de ses adresses d'entretien IPv6. Si le nœud mobile envoie une mise à jour de lien à partir d'une adresse d'entretien IPv4, il DOIT suivre le format décrit à la Figure 9. Noter que l'adresse d'entretien IPv4 doit être enregistrée par un enregistrement de lien non en vrac chaque fois qu'elle est changée.

Comme le montre la Figure 9, l'adresse d'entretien IPv4 va apparaître dans l'option de mobilité Identifiant de lien. L'option de mobilité Adresse d'entretien IPv4 définie dans la [RFC5555] DOIT toujours être omise. Le receveur du message de mise à jour de lien pour une adresse d'entretien IPv4 DOIT traiter l'adresse IPv4 mémorisée dans l'option de mobilité Identifiant de lien comme celle dans l'option de mobilité Adresse d'entretien IPv4 de la [RFC5555]. Si l'adresse IPv4 dans l'option de mobilité Identifiant de lien est différente de celle dans le champ Adresse de source dans l'en-tête IPv4 de la mise à jour de lien (c'est-à-dire, V4ADDR dans la Figure 9) l'adresse de source est utilisée comme une adresse d'entretien IPv4. Autrement, l'adresse IPv4 dans l'option de mobilité Identifiant de lien est utilisée comme une adresse d'entretien IPv4.

          En-tête IPv6 (src=Adresse d'entretien, dst=Adresse d'agent de rattachement)
               Option Adresse de rattachement IPv6
               En-tête ESP
               En-tête de mobilité
                   - Mise à jour de lien
                  Options de mobilité
                     - Identifiant de lien (CoA IPv6/v4)
                     - Identifiant de lien (CoA IPv6/v4)
                     - ...

Figure 10 : Enregistrement de lien en vrac pour une adresse d'entretien IPv4

Quand l'agent de rattachement retourne un accusé de réception de lien pour l'enregistrement d'adresse d'entretien IPv4, il NE DEVRAIT PAS utiliser l'option de mobilité Accusé de réception d'adresse IPv4 et DEVRAIT utiliser seulement l'option de mobilité Identifiant de lien. L'état d'enregistrement pour l'adresse d'entretien IPv4 est mémorisé dans le champ État de l'option de mobilité Identifiant de lien. Cependant, si l'agent de rattachement a besoin de mémoriser la valeur d'état spécialement définie pour l'option de mobilité Accusé de réception d'adresse IPv4, il DOIT mémoriser la valeur d'état dans l'option de mobilité Accusé de réception d'adresse IPv4 et NE DOIT PAS la mémoriser dans l'option de mobilité Identifiant de lien. Dans ce cas, l'agent de rattachement DOIT inclure les deux options de mobilité Accusé de réception d'adresse IPv4 et Identifiant de lien.

 	8.2	Gestion d'adresse de rattachement IPv4
Quand le nœud mobile veut configurer une adresse de rattachement IPv4 en plus de l'adresse de rattachement IPv6, il peut en demander une en utilisant l'option Adresse de rattachement IPv4 dans la mise à jour de lien. Si l'agent de rattachement accepte la mise à jour de lien, le nœud mobile peut alors enregistrer plusieurs adresses d'entretien pour l'adresse de rattachement IPv4 en plus de l'adresse de rattachement IPv6. Le nœud mobile DOIT toujours utiliser l'option de mobilité Adresse de rattachement IPv4 pour toute question de gestion de l'adresse de rattachement IPv4. Le même ensemble d'adresses d'entretien va être enregistré pour les adresses de rattachement IPv6 et IPv4. Le nœud mobile ne peut pas lier un ensemble différent d'adresses d'entretien à chaque adresse de rattachement.

Selon la [RFC5555], l'agent de rattachement inclut l'option Accusé de réception d'adresse IPv4 dans l'accusé de réception de lien seulement si le nœud mobile a demandé une adresse de rattachement IPv4 dans la mise à jour de lien correspondante. L'option Accusé de réception d'adresse IPv4 DOIT être présente avant toute option de mobilité Identifiant de lien. Le champ État de l'option Accusé de réception d'adresse IPv4 contient seulement le code d'erreur défini au paragraphe 3.2.1 de la [RFC5555]. L'agent de rattachement DOIT toujours inclure l'option de mobilité Accusé de réception d'adresse IPv4 dans l'accusé de réception de lien pour l'enregistrement d'adresse de rattachement IPv4.

 	9.	Interaction IPsec et IKEv2 

IPv6 mobile [RFC3775] et le protocole NEMO [RFC3963] exigent l'utilisation de IPsec pour protéger les messages de signalisation, y compris les messages de mise à jour de lien, d'accusé de réception de lien, et d'acheminement de retour. IPsec peut aussi être utilisé pour protéger tout le trafic de données tunnelé. La spécification de IKEv2 pour IPv6 mobile [RFC4877] spécifie comment IKEv2 peut être utilisé pour établir les associations de sécurité IPsec exigées. Les hypothèses suivantes ont été faites dans les [RFC3775], [RFC3963], et [RFC4877] à l'égard de l'utilisation de IKEv2 et IPsec :
o	Il y a seulement une adresse d'entretien principale par nœud mobile.
o	L'adresse d'entretien principale est mémorisée dans la base de données IPsec pour l'encapsulation et la désencapsulation de tunnel.
o	Quand l'agent de rattachement reçoit un paquet du nœud mobile, l'adresse de source est vérifiée par rapport à l'adresse d'entretien dans l'entrée d'antémémoire de lien correspondante. Si le paquet est un paquet en tunnelage inverse provenant du nœud mobile, la vérification de l'adresse d'entretien est faite sur l'adresse de source sur l'en-tête IPv6 externe. Le paquet en tunnelage inverse pourrait être un message d'initiation d'essai de rattachement tunnelé ou du trafic de données tunnelé au nœud correspondant.
o	Le nœud mobile se sert de IKEv2 (ou IKEv1) avec l'agent de rattachement en utilisant l'adresse d'entretien. La SA IKE est fondée sur l'adresse d'entretien du nœud mobile.

Les hypothèses ci-dessus peuvent n'être pas valides quand plusieurs adresses d'entretien sont utilisées par le nœud mobile. Dans les paragraphes qui suivent, les principales questions de l'utilisation de plusieurs adresses d'entretien avec IPsec sont traitées.

 	9.1	Utilisation de l'adresse d'entretien dans l'échange IKEv2
Pour chaque adresse de rattachement pour laquelle le nœud mobile établit des associations de sécurité avec l'agent de rattachement, le nœud mobile doit prendre une adresse d'entretien et l'utiliser comme adresse de source pour tous les messages IKEv2 échangés pour créer et maintenir les associations de sécurité IPsec associées à l'adresse de rattachement. Les associations de sécurité IKEv2 résultantes sont créées sur la base de cette adresse d'entretien.

Si le nœud mobile a besoin de changer l'adresse d'entretien, il envoie juste une mise à jour de lien avec l'adresse d'entretien qu'il veut utiliser, avec l'option de mobilité Identifiant de lien correspondante, et avec le bit "K" établi. Cela va forcer l'agent de rattachement à mettre à jour l'association de sécurité IKEv2 pour utiliser la nouvelle adresse d'entretien. Si le bit "K" n'est pas pris en charge sur le nœud mobile ou l'agent de rattachement, le nœud mobile DOIT rétablir l'association de sécurité IKEv2 avec la nouvelle adresse d'entretien. Cela va aussi résulter en l'établissement de nouvelles associations de sécurité IPsec pour l'adresse de rattachement.

 	9.2	Messages protégés par IPsec en mode transport
Pour les messages de signalisation IPv6 mobile protégés en utilisant IPsec en mode transport, l'utilisation d'une adresse d'entretien particulière parmi plusieurs adresses d'entretien n'a pas d'importance pour le traitement IPsec.

L'agent de rattachement traite les messages de découverte de préfixe mobile avec les mêmes règles de paquets de données décrites au paragraphe 6.5.

 	9.3	Messages protégés par IPsec en mode tunnel
L'utilisation de IPsec en mode tunnel avec plusieurs adresses d'entretien introduit quelques problèmes qui exigent des changements à la façon dont le nœud mobile et l'agent de rattachement envoient et reçoivent le trafic tunnelé. Le mécanisme d'optimisation de chemin décrit dans la [RFC3775] rend obligatoire l'utilisation de la protection IPsec en mode tunnel pour les messages Initiation d'essai de rattachement et Essai de rattachement. Le nœud mobile et l'agent de rattachement peuvent aussi choisir de protéger tout le trafic de charge utile en tunnelage inverse avec IPsec en mode tunnel.  Les paragraphes qui suivent traitent de la prise en charge de plusieurs adresses d'entretien pour ces deux types de messages.

 	9.3.1	Messages tunnelés Initiation d'essai de rattachement et essai de rattachement
Le nœud mobile PEUT utiliser la même adresse d'entretien pour tous les messages Initiation d'essai de rattachement envoyés en tunnelage inverse à travers l'agent de rattachement. Le nœud mobile peut utiliser la même adresse d'entretien sans considération du nœud correspondant auquel le message Initiation d'essai de rattachement est envoyé. La RFC 3775 exige que l'agent de rattachement vérifie que le nœud mobile utilise l'adresse d'entretien qui est dans l'entrée d'antémémoire de lien quand il reçoit un message Initiation d'essai de rattachement en tunnelage inverse. Si une adresse différente est utilisée comme adresse de source, le message est éliminé en silence par l'agent de rattachement. Le présent document exige que la mise en œuvre d'agent de rattachement désencapsule et transmette le message Initiation d'essai de rattachement pour autant que l'adresse de source soit une des adresses d'entretien dans l'entrée d'antémémoire de lien pour le nœud mobile.

Quand l'agent de rattachement tunnelle un message Essai de rattachement au nœud mobile, l'adresse d'entretien utilisée dans l'en tête IPv6 externe n'est pas pertinente pour le message Essai de rattachement. De sorte que l'encapsulation régulière de tunnel IPsec avec l'adresse d'entretien connue de la mise en œuvre IPsec sur l'agent de rattachement est suffisante.

 	9.3.2	Trafic de charge utile tunnelé
Quand le nœud mobile envoie et reçoit plusieurs flux de trafic protégés par IPsec pour différentes adresses d'entretien, l'utilisation de l'adresse d'entretien correcte pour chaque flux devient importante. La prise en charge de cela impose la prise en compte des deux considérations suivantes sur l'agent de rattachement.

o	Quand l'agent de rattachement reçoit un message de charge utile en tunnelage inverse protégé par IPsec en mode tunnel, l'adresse de source utilisée dans l'en-tête IPv6 externe n'est pas pertinente pour IPsec, car l'association de sécurité en mode tunnel est fondée sur les adresses dans l'en-tête IPv6 interne. Donc, la même association de sécurité IPsec peut être utilisée pour le trafic de charge utile tunnelé à partir de n'importe laquelle des adresses d'entretien. Noter que l'adresse d'entretien utilisée dans le trafic en tunnelage inverse peut être différente de l'adresse d'entretien utilisée comme adresse de source dans l'échange IKEv2. Cependant, ceci n'est pas un problème pour les raisons sus-mentionnées.

o	Pour le trafic IPsec tunnelé de l'agent de rattachement au nœud mobile, la mise en œuvre IPsec sur l'agent de rattachement ne va pas savoir quelle adresse d'entretien utiliser quand elle effectue l'encapsulation de tunnel IPsec. La pile IP mobile sur l'agent de rattachement, fondée sur les entrées d'antémémoire de lien créées par le nœud mobile, sait à quelle adresse d'entretien le paquet appartenant à un flux particulier doit être tunnelé. L'adresse de destination pour l'en-tête IP externe doit être porté dynamiquement par paquet à la pile IPsec quand elle effectue l'encapsulation ou bien la pile IPv6 mobile doit obtenir l'accès au paquet après la fin du traitement IPsec et modifier l'adresse de destination. La première option exige des changements à la mise en œuvre IPsec. Dans la seconde option, il y a besoin d'un traitement spécial dans la fonction de transmission pour remplacer l'adresse de destination sur l'en-tête externe par l'adresse d'entretien correcte. La technique exacte pour réaliser cela est spécifique de la mise en œuvre.

 	10.	Considérations sur la sécurité

Les considérations sur la sécurité pour sécuriser les messages Mise à jour de lien et Accusé de réception de lien avec plusieurs adresses d'entretien sont très similaires aux considérations sur la sécurité pour sécuriser la mise à jour de lien et l'accusé de réception de lien. Voir plus d'informations dans la [RFC3775]. Les messages Mise à jour de lien et Accusé de réception de lien avec plusieurs adresses d'entretien sont échangés en toute sécurité comme décrit dans les [RFC3775], [RFC4877], et à la Section 9 du présent document. Des considérations supplémentaires sur la sécurité sont décrites ci-dessous.

Avec la prise en charge simultanée de liens, il est possible à un nœud mobile malveillant de réussir à lier des adresses d'un certain nombre de victimes comme adresses d'entretien valides pour le nœud mobile avec son agent de rattachement. Une fois que ces adresses ont été liées, le nœud mobile malveillant peut effectuer une attaque de redirection en donnant pour instruction à l'agent de rattachement (par exemple, en établissant des règles de filtrage pour diriger un grand transfert de fichier) de tunneler les paquets aux adresses des victimes. Ce risque est souligné dans [MIP6ANALYSIS]. Ces attaques sont possibles parce que les adresses d'entretien envoyées par le nœud mobile dans les messages Mise à jour de lien ne sont pas vérifiées par l'agent de rattachement, c'est-à-dire, l'agent de rattachement ne vérifie pas si le nœud mobile est à l'adresse d'entretien à laquelle il prétend être. Le modèle de sécurité pour IPv6 mobile suppose qu'il y a une relation de confiance entre le nœud mobile et son agent de rattachement. Toute attaque malveillante par le nœud mobile est traçable par l'agent de rattachement. Cela agit comme dissuasion pour empêcher que le nœud mobile lance de telles attaques.

Bien que ce risque existe dans IPv6 mobile, le niveau de risque est augmenté quand plusieurs liens simultanés d'adresse d'entretien sont effectués. Dans IPv6 mobile, un nœud mobile peut seulement avoir un lien d'adresse d'entretien par adresse de rattachement à un instant donné. Cependant, pour plusieurs liens simultanés d'adresse d'entretien, un nœud mobile peut avoir plus d'un lien d'adresse d'entretien par adresse de rattachement à un moment donné. Cela implique qu'un nœud mobile utilisant la prise en charge de liens simultanés peut effectivement lier plus d'une seule adresse de victimes. Une autre différence est le degré de risque impliqué. Dans le cas d'un lien d'une seule adresse d'entretien, une fois l'attaque de redirection initiée, un nœud mobile malveillant serait incapable d'utiliser son adresse de rattachement pour les communications (comme de recevoir des paquets de contrôle relevant du transfert de fichier). Cependant, dans le cas de la prise en charge de liens simultanés, un nœud mobile malveillant pourrait lier une adresse d'entretien valide en plus de plusieurs adresses de victimes. Cette adresse d'entretien valide pourrait alors être utilisée par le nœud mobile malveillant pour établir des règles de filtrage à son agent de rattachement, contrôlant et/ou lançant par là de nouvelles attaques de redirection.

Donc, en vue de tels risques, il est conseillé qu'un agent de rattachement emploie une forme de mécanisme de vérification d'adresse d'entretien avant d'utiliser les adresses d'entretien comme un chemin valide vers un nœud mobile. Ces mécanismes sortent du domaine d'application du présent document.

Dans l'enregistrement de lien d'IPv6 mobile, l'accessibilité d'une adresse d'entretien est toujours vérifiée par un agent de rattachement. Cet essai d'accessibilité peut diminuer les risques. Cependant, quand l'enregistrement en vrac est utilisé, un agent de rattachement ne peut pas vérifier l'accessibilité des adresses d'entretien portées dans une option de mobilité Identifiant de lien. Donc, l'agent de rattachement peut choisir de rejeter l'enregistrement en vrac en utilisant [MCOA BULK REGISTRATION PROHIBITED] dans un accusé de réception de lien. Autrement, quand un nœud mobile enregistre pour la première fois une adresse d'entretien, il utilise les mises à jour de lien individuelles pour la première adresse d'entretien qui apparaît. Durant l'enregistrement de lien initial, un agent de rattachement peut vérifier l'accessibilité de l'adresse pour cette adresse d'entretien donnée. Après cela, le nœud mobile utilise l'enregistrement en vrac pour rafraîchir l'adresse d'entretien.

 	11.	Considérations relatives à l'IANA

Les types d'extension suivants ont été alloués par l'IANA :

o	Type d'option de mobilité Identifiant de lien : (35) a été alloué dans le même espace que l'option de mobilité dans la [RFC3775].

o	Nouvel état réussi d'accusé de réception de lien : ces codes d'état ont été alloués dans le même espace que les codes d'état d'accusé de réception de lien dans la [RFC3775] :
*  MCOA INCOMPLETE (4)
*  MCOA RETURNHOME WO/NDP (5)

o	Nouvel état non réussi d'accusé de réception de lien : ces codes d'état ont aussi été alloués dans le même espace que les codes d'état d'accusé de réception de lien dans la [RFC3775] :
*  MCOA MALFORMED (164)
*  MCOA NON-MCOA BINDING EXISTS (165)
*  MCOA PROHIBITED (166)
*  MCOA UNKNOWN COA (167)
*  MCOA BULK REGISTRATION PROHIBITED (168)
*  MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)

 	12.	Remerciements

Ryuji Wakikawa et Thierry Ernst remercient l'Université Keio de son soutien initial à la présente spécification au moment où ils y travaillaient. De plus, les auteurs tiennent à remercier Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Martti Kuparinen, Romain Kuntz, Benjamin Lim, Heikki Mahkonen, Nicolas Montavont, et Chan-Wah Ng pour leurs discussions et apports. Merci à Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi Watari, et Jun Murai pour leurs premiers travaux sur ce sujet.

 	13.	Références
 	13.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. DOI 10.17487/RFC2119, (MàJ par RFC8174)

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

[RFC3963]	V. Devarapalli et autres, "Protocole de base de prise en charge de la mobilité sur le réseau (NEMO)", janvier 2005. (P.S.)

[RFC4861]	T. Narten et autres, "Découverte du voisin pour IP version 6 (IPv6)", septembre 2007. (Remplace RFC2461) (D.S. ; MàJ par RFC8028, RFC8319, RFC8425, 9131) 

[RFC4877]	V. Devarapalli, F. Dupont, "Fonctionnement de IPv6 mobile avec IKEv2 et l'architecture IPsec révisée", avril 2007. (MàJ RFC3776) (P.S.)

[RFC5555]	H. Soliman, éd., "Prise en charge de IPv6 mobile pour hôtes et routeurs à double pile de protocoles", juin 2009. (P. S.)

[RFC5568]	R. Koodli, "Transferts inter cellulaires rapides pour IPv6 mobile", juillet 2009. (Remplace RFC5268) (P.S.)

 	13.2	Références pour information

[MOTIV]	Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Travail en cours, mai 2008.

[MIP6ANA]	Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Travail en cours, mai 2008.

[RFC3753]	J. Manner et M. Kojo, éd., "Terminologie de la mobilité", juin 2004. (Information)

[RFC4885]	T. Ernst, H-Y. Lach, "Terminologie pour la prise en charge de la mobilité sur le réseau", juillet 2007. (Information)

[RFC4980]	C. Ng et autres, "Analyses du rattachement multiple dans la mobilité du réseau", octobre 2007. (Information)

 	Adresse des auteurs

Ryuji Wakikawa (éditeur)
TOYOTA InfoTechnology Center Co., Ltd.
mél : ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)

Vijay Devarapalli	George Tsirtsis	Thierry Ernst	Kenichi Nagami	
Wichorus	Qualcomm	INRIA	INTEC NetCore Inc.	
mél : vijay@wichorus.com	mél : Tsirtsis@gmail.com	mél : thierry.ernst@inria.fr	mél : nagami@inetcore.com