Groupe de travail Réseau	J. Korhonen, éditeur, Nokia Siemens Networks
Request for Comments : 5447	J. Bournelle, Orange Labs
Catégorie : Sur la voie de la normalisation	H. Tschofenig, Nokia Siemens Networks
	C. Perkins, WiChorus
	K. Chowdhury, Starent Networks
Traduction Claude Brière de L'Isle	février 2009

Diameter IPv6 mobile : prise en charge de l'interaction de serveur d'accès réseau et de serveur Diameter

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

Résumé
Un nœud IPv6 mobile exige une adresse d'agent de rattachement, une adresse de rattachement, et une association de sécurité avec son agent de rattachement avant qu'il puisse commencer à utiliser IPv6 mobile. La RFC 3775 exige que certains ou tous ces paramètres soient configurés de façon statique. L'amorçage IPv6 mobile fonctionne de façon à rendre ces informations disponibles de façon dynamique pour le nœud mobile. Un important aspect de la solution d'amorçage IPv6 mobile est de prendre en charge l'interfonctionnement avec les infrastructures existantes d'authentification, d'autorisation et de comptabilité (AAA, Authentication, Authorization, and Accounting). Le présent document décrit l'amorçage MIPv6 en utilisant l'interface de serveur d'accès de réseau Diameter au serveur AAA de rattachement.
Table des matières
1. Introduction	1
2. Terminologie et abréviations	2
3. Vue d'ensemble	2
4. Commandes, paires d'attribut-valeur, et prise en charge d'application d'annonce	3
4.1 Prise en charge d'application d'annonce	3
4.2 Définitions des paires d'attribut-valeur	4
5. Exemples	6
5.1 Allocation d'agent de rattachement par le NAS	6
5.2 Allocation d'agent de rattachement par le serveur Diameter	6
5.3 Allocation d'agent de rattachement par le NAS ou le serveur Diameter	7
6. Tableaux d'occurrence de paire d'attribut-valeur	8
7. Considérations relatives à l’IANA	8
7.1 Enregistrement  de nouveaux AVP	8
7.2 Nouveau registre : capacité de mobilité	8
8. Considérations sur la sécurité	8
9. Remerciements	9
10. Références	9
10.1 Références normatives	9
10.2 Références pour information	9
Adresse des auteurs	10

 	1.	Introduction

La spécification IPv6 mobile (MIPv6) [RFC3775] exige d'un nœud mobile (MN, Mobile Node) qu'il effectue un enregistrement auprès d'un agent de rattachement (HA, Home Agent) avec des informations sur son point de rattachement actuel (adresse d'entretien). Le HA crée et maintient le lien entre l'adresse de rattachement du MN' et l'adresse d'entretien du MN.

Afin de s'enregistrer auprès d'un HA, le MN a besoin de connaître des informations, comme le préfixe de liaison de rattachement, l'adresse du HA, la ou les adresses de rattachement, la longueur du préfixe de la liaison de rattachement, et les informations relatives à l'association de sécurité.

Les informations sus-mentionnées peuvent être configurées statiquement. Cependant, le provisionnement statique devient une charge administrative pour un opérateur. De plus, il ne traite pas l'équilibrage de charge, la reprise sur défaillance, l'allocation opportuniste de liaison de rattachement, ou l'allocation de HA locales dans la proximité du MN. Aussi, la capacité de réagir à de soudains changements environnementaux ou topologiques est minimale. Le provisionnement statique peut n'être pas désirable, à la lumière de ces limitations.

L'allocation dynamique des informations d'enregistrement de rattachement MIPv6 est une caractéristique désirable pour faciliter le déploiement et la maintenance du réseau. À cette fin, l'infrastructure AAA, qui est utilisée pour l'authentification d'accès, peut être utilisée pour allouer certains ou tous les paramètres nécessaires. Le serveur Diameter dans le réseau du fournisseur de service d'accès (ASP, Access Service Provider) ou du fournisseur de service de mobilité (MSP, Mobility Service Provider) peut retourner ces paramètres au client AAA. Concernant les procédures d'amorçage, le client AAA pourrait être le serveur d'accès réseau, dans le cas du scénario intégré, ou le HA, dans le cas du scénario partagé [RFC5026]. Les termes "intégré" et "partagé" sont décrits dans le paragraphe de terminologie suivant et ont été introduits dans les [RFC4640] et [RFC5637].

 	2.	Terminologie et abréviations

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

La terminologie générale de la mobilité se trouve dans la [RFC3753]. Les termes supplémentaires suivants sont empruntés aux [RFC4640] ou [RFC5026] ou sont introduits dans le présent document:

Autorisateur de service d'accès (ASA, Access Service Authorizer) : opérateur de réseau qui authentifie un MN et établit l'autorisation du MN à recevoir le service Internet.

Fournisseur de service d'accès (ASP, Access Service Provider) : opérateur de réseau qui fournit la transmission de paquet IP directe de et vers le MN.

Autorisateur de service de mobilité (MSA, Mobility Service Authorizer) : fournisseur de service qui autorise le service MIPv6.

Fournisseur de service de mobilité (MSP, Mobility Service Provider) : fournisseur de service qui fournit le service MIPv6. Afin d'obtenir un tel service, le MN doit être authentifié et autorisé à le faire.

Scénario partagé : scénario où le service de mobilité et le service d'accès au réseau sont autorisés par des entités différentes.

Scénario intégré : scénario où le service de mobilité et le service d'accès au réseau sont autorisés par la même entité.

Serveur d'accès réseau (NAS, Network Access Server) : appareil qui fournit un service d'accès à un réseau pour un utilisateur.

Serveur AAA de rattachement (HAAA, Home AAA) : serveur d'authentification, autorisation, et comptabilité situé dans le réseau de rattachement de l'utilisateur, c'est-à-dire, dans le domaine de rattachement.

Mandataire AAA local (LAAA, Local AAA) : mandataire d'authentification, autorisation, et comptabilité situé dans le réseau local (de l'ASP).

AAA visité (VAAA, Visited AAA) : mandataire d'authentification, autorisation, et comptabilité situé dans un réseau visité, c'est-à-dire, dans le domaine visité. Dans un cas d'itinérance, le mandataire Diameter local a le rôle de VAAA (voir la Figure 1).

 	3.	Vue d'ensemble

Le présent document vise la fonction d'authentification, autorisation, et comptabilité (AAA) exigée pour les solutions d'amorçage MIPv6 mentionnées dans la [RFC4640], et se concentre sur la fonction AAA fondée sur Diameter pour la communication de serveur de NAS à HAAA.

Dans le scénario intégré, l'amorçage MIPv6 est fourni au titre de la procédure d'authentification de l'accès au réseau. La Figure 1 montre les entités participantes.

                   +------------------------------+  +-----------------+
                   |Fournisseur service d'accès   |  |ASA/MSA/(MSP)    |
                   |(Fournisseur service mobilité)|  |                 |
                   |                              |  |                 |
                   |    +----------+              |  |    +--------+   |
                   |    |Mandataire|      Diameter|  |    |Serveur |   |
                   |    |Diameter  |<-------------------->|Diameter|   |
                   |    |local     |         (*)  |  |    |de ratt.|   |
                   |    +----------+              |  |    +--------+   |
                   |        ^ ^                   |  |        ^        |
                   |        | |                   |  |        |(+)     |
                   |        | |                   |  |        |        |
                   |      Diameter                |  |        v        |
                   |        | |(+)      +-------+ |  |    +-------+    |
                   |        | |         |Agent  | |  |    |Agent  |    |
                   |        | +-------->|rattach| |  |    |rattach|    |
                   |     (*)|           |de ASP | |  |    |de MSP |    |
                   |        v           +-------+ |  |    +-------+    |
   +-------+ IEEE  |    +-----------+   +-------+ |  +-----------------+
   |Nœud   | 802.1X|    |Client     |   |Serveur| |
   |mobile |------------|Diameter   |---|DHCPv6 | |
   |       | PANA, |    |NAS/relais |(+)|       | |
   +-------+ IKEv2,|    +-----------+   +-------+ |
             DHCP,.+------------------------------+
             (+)

Légende :
(*) : Fonction dans la portée de la présente spécification.
(+) : Extensions décrites dans d'autres documents.

Figure 1 : Amorçage IPv6 mobile dans le scénario intégré

Dans un scénario typique d'accès MIPv6, un MN est rattaché au réseau d'un ASP. Durant la procédure de rattachement au réseau, le MN interagit avec le client NAS/Diameter. Ensuite, le client NAS/Diameter interagit avec le serveur Diameter sur l'interface NAS à HAAA 

Quand le serveur Diameter effectue l'authentification et l'autorisation pour l'accès au réseau, il détermine aussi si l'utilisateur est autorisé pour le service MIPv6. Sur la base de l'autorisation de service MIPv6 et du profil de politique de l'utilisateur, le serveur Diameter peut retourner plusieurs paramètres relatifs à l'amorçage MIPv6 aau NAS. L'interface de NAS à HAAA décrite dans le présent document n'est pas liée au protocole de configuration dynamique d'hôte pour IPv6 (DHCPv6, Dynamic Host Configuration Protocol for IPv6) comme seul mécanisme pour porter les paramètres de configuration relatifs à MIPv6 du client NAS/Diameter au nœud mobile.

Bien que la présente spécification vise l'amorçage des informations de HA MIPv6 et éventuellement l'allocation du préfixe de la liaison de rattachement, elle ne traite pas comment l'association de sécurité (SA, Security Association) entre le MN et le HA est créée pour les besoins de MIPv6. La création ou l'utilisation de la SA entre le MN et le HA a lieu après les procédures décrites dans la présente spécification, et sortent donc de son domaine d'application.

 	4.	Commandes, paires d'attribut-valeur, et prise en charge d'application d'annonce
 	4.1	Prise en charge d'application d'annonce
Ce document ne définit pas une nouvelle application. Par ailleurs, il définit un certain nombre de paires d'attribut-valeur (AVP) utilisées à l'interface entre NAS à HAAA pour le scénario intégré d'amorçage MIPv6. Ces AVP peuvent être utilisées avec toute application présente et future de Diameter, lorsque permis par la commande ABNF. Les exemples qui utilisent des applications existantes et leurs commandes dans les paragraphes suivants sont seulement à des fins d'information. Les exemples de ce document réutilisent l'application du protocole extensible d'authentification (EAP, Extensible Authentication Protocol) [RFC4072] et ses commandes respectives.

 	4.2	Définitions des paires d'attribut-valeur
 	4.2.1	AVP MIP6-Agent-Info
L'AVP MIP6-Agent-Info (code d'AVP 486) est de type Groupée et contient les informations nécessaires pour allouer un HA au MN. Quand l'AVP MIP6-Agent-Info est présente dans un message, elle DOIT contenir l'AVP MIP-Home-Agent-Address, l'AVP MIP-Home-Agent-Host, ou les deux. L'AVP groupée a l'ABNF modifié suivant (comme défini dans la [RFC3588]) :

MIP6-Agent-Info ::= < AVP-Header: 486 > *2[ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host ]
                                   [ MIP6-Home-Link-Prefix ] * [ AVP ]

Si les deux AVP MIP-Home-Agent-Address et MIP-Home-Agent-Host sont présentes dans MIP6-Agent-Info, MIP-Home-Agent-Address DEVRAIT avoir la préséance sur MIP-Home-Agent-Host. La raison de cette recommandation est que la MIP-Home-Agent-Address pointe sur un agent de rattachement spécifique, tandis que la MIP-Home-Agent-Host peut pointer sur un groupe de HA situés dans le même domaine. Un client ou agent Diameter peut utiliser l'AVP MIP-Home-Agent-Hos, par exemple, pour trouver dans quel domaine est situé le HA.

L'ABNF permet de retourner jusqu'à deux adresses de HA MIPv6. C'est une caractéristique utile pour les déploiements où le HA a à la fois des adresses IPv6 et IPv4, et particulièrement dans des scénarios de déploiement d'adresses de double pile IPv6 mobile (DSMIPv6) [DSMIPv6].

L'AVP MIP6-Agent-Info PEUT aussi être rattachée par le NAS ou par des mandataires Diameter intermédiaires dans un message de demande quand il est envoyé au serveur Diameter comme indication d'un HA alloué en local. Cette AVP PEUT aussi être rattachée par des mandataires Diameter intermédiaires dans un message de réponse du serveur Diameter, si les HA alloués en local sont autorisés par le serveur Diameter. Il PEUT y avoir plusieurs instances d'AVP MIP6-Agent-Info dans les messages Diameter, par exemple, dans les cas où le NAS reçoit des informations de HA d'in réseau de rattachement du MN et des informations de HA alloué en local provenant du réseau visité. Voir au paragraphe 4.2.5 la discussion sur les scénarios possibles.

 	4.2.2	AVP MIP-Home-Agent-Address
L'AVP MIP-Home-Agent-Address (code d'AVP 334 [RFC4004]) est du type Adresse et contient l'adresse IPv6 ou IPv4 du HA MIPv6. Le serveur Diameter PEUT décider d'allouer un HA au MN qui est à proximité du point de rattachement (par exemple, déterminé par l'AVP NAS-Identifier). Il peut y avoir d'autres raisons pour une allocation dynamique des HA au MN, par exemple, pour partager la charge de trafic.

 	4.2.3	AVP MIP-Home-Agent-Host
L'AVP MIP-Home-Agent-Host (code d'AVP 348 [RFC4004]) est du type Groupée et contient l'identité du HA MIPv6 alloué. Les deux AVP Destination-Realm et Destination-Host du HA sont incluses dans l'AVP groupée. L'usage de l'AVP MIP-Home-Agent-Host est équivalent à celui de l'AVP MIP-Home-Agent-Address mais offre un niveau supplémentaire d'indication en utilisant l'infrastructure du DNS. L'AVP Destination-Host est utilisée pour identifier un HA, et l'AVP Destination-Realm est utilisée pour identifier le domaine où est situé le HA.

Selon le déploiement réel et la configuration du DNS, l'AVP Destination-Host PEUT représenter un ou plusieurs agents de rattachement. Il est RECOMMANDÉ que l'AVP Destination-Host identifie exactement un HA.

Il est RECOMMANDÉ que l'AVP MIP-Home-Agent-Host soit toujours incluse dans l'AVP MIP6-Agent-Info. De cette façon, le HA peut être associé au domaine correspondant de l'entité Diameter qui a ajouté l'AVP MIP6-Agent-Info en utilisant l'AVP Destination-Realm, qui est incluse dans l'AVP MIP-Home-Agent-Host.

 	4.2.4	AVP MIP6-Home-Link-Prefix
L'AVP MIP6-Home-Link-Prefix (code d'AVP 125) est de type OctetString et contient les informations de préfixe de réseau de rattachement IPv6 mobile dans l'ordre des octets du réseau. Le préfixe de réseau de rattachement DOIT être codé comme les informations de longueur de préfixe de 8 bits (un octet) suivi par le champ de 128 bits (16 octets) pour le préfixe de réseau de rattachement disponible. Les bits de queue du préfixe IPv6 après les bits de longueur de préfixe DOIVENT être réglés à zéro (par exemple, si la longueur de préfixe est 60, les 68 bits restants DOIVENT alors être réglés à zéro).

Le HAAA PEUT agir comme entité centrale de gestion des préfixes pour les MN. Dans ce cas, le HAAA retourne au NAS le préfixe alloué au MN. Le NAS/ASP livre alors le préfixe de liaison de rattachement au MN en utilisant, par exemple, les mécanismes décrits dans la [RFC6611]. Le NAS/ASP PEUT proposer au HAAA un préfixe spécifique à allouer au MN en incluant l'AVP MIP6-Home-Link-Prefix dans le message de demande. Cependant, le HAAA PEUT outrepasser le conseil d'allocation de préfixe proposé par le NAS/ASP et retourner un préfixe différent dans le message de réponse.

 	4.2.5	AVP MIP6-Feature-Vector
L'AVP MIP6-Feature-Vector (code d'AVP 124) est de type Unsigned64 et contient un champ de fanions de 64 bits des capacités prises en charge par le NAS/ASP. L'envoi et la réception de l'AVP MIP6-Feature-Vector de valeur 0 DOIT être accepté, bien que cela ne donne pas beaucoup d'indications sur les besoins spécifiques de l'amorçage.

Le NAS PEUT inclure cette AVP pour indiquer les capacités du NAS/ASP au serveur Diameter. Par exemple, le NAS peut indiquer qu'un HA local peut être fourni. De même, le serveur Diameter PEUT inclure cette AVP pour informer le NAS/ASP quelles capacités indiquées par le NAS/ASP le ASA/MSA(/MSP) prend en charge ou autorise.

Les capacités suivantes sont définies dans le présent document :

MIP6_INTEGRATED (0x0000000000000001) : Quand ce fanion est établi par le NAS, il signifie que la fonction d'amorçage du scénario intégré IPv6 mobile est prise en charge par le NAS. Quand ce fanion est établi par le serveur Diameter, l'amorçage du scénario intégré IPv6 mobile est alors pris en charge par le serveur Diameter.

LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000002) : Quand ce fanion est établi dans le message de demande, un agent de rattachement local en dehors du domaine de rattachement est demandé et peut être alloué au MN. Quand ce fanion est établi par le serveur Diameter dans le message de réponse, l'allocation de HA locaux est alors autorisée par le serveur Diameter.

Un HA local peut être alloué par le NAS, le LAAA, ou le VAAA selon l'architecture et le déploiement du réseau.

Les exemples suivants montrent comment la capacité LOCAL_HOME_AGENT_ASSIGNMENT (appelée LOCAL-bit dans les exemples) et l'AVP MIP-Agent-Info (appelée HA-Info dans les exemples) sont utilisées pour allouer des HA --HA local (L-HA) ou HA de réseau de rattachement (H-HA). Voici des exemples de combinaisons de message de demande telles que vues par le HAAA :

LOCAL-bit	HA-Info	Signification
      0	-	L'ASP ou [LV]AAA n'est pas capable d'allouer un L-HA.
      0	L-HA	Comme ci-dessus. HA-Info doit être ignoré.
      1	-	L'ASP ou [LV]AAA peut/souhaite allouer un L-HA.
      1	L-HA	Comme ci-dessus mais l'ASP ou [LV]AAA donne aussi un conseil sur le L-HA alloué.

Les mêmes que ci-dessus mais pour les combinaisons de message de réponse telles que vues pas le NAS :

LOCAL-bit	HA-Info	Signification
    0	-	Aucune allocation de HA permise pour HAAA ou [LV]AAA.
    0	H-HA	L-HA n'est pas permis. HAAA alloue un H-HA.
    1	-	L-HA est permis. Pas de HA alloué par HAAA- ou [LV]AAA.
    1	L-HA	L-HA est permis. [LV]AAA alloue aussi un L-HA.
    1	H-HA	L-HA est permis. HAAA alloue aussi un HA.
    1	H-HA + L-HA	L-HA est permis. HAAA alloué un H-HA et [LV]AAA alloue aussi un L-HA.

Un NAS devrait s'attendre à recevoir plusieurs AVP MIP6-Agent-Info.

 	5.	Exemples
 	5.1	Allocation d'agent de rattachement par le NAS
Dans ce scénario, on considère le cas où le NAS souhaite allouer un HA local au MN. Le NAS va aussi informer le serveur Diameter de l'adresse de HA qu'il a allouée au MN visiteur (par exemple, 2001:db8:1:c020::1). Le message Diameter-EAP-Request a donc les fanions MIP6-Feature-Vector avec le LOCAL_HOME_AGENT_ASSIGNMENT et le MIP6_INTEGRATED établis. L'AVP MIP6-Agent-Info contient l'AVP MIP-Home-Agent-Address avec l'adresse du HA proposé.

NAS/VAAA	Serveur Diameter
    |                                                                                                                                                                              |
    |  Diameter-EAP-Request                                                                                                                                      |
    |  MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | MIP6_INTEGRATED)                       |
    |  MIP6-Agent-Info{                                                                                                                                              |
    |       MIP-Home-Agent-Address(2001:db8:1:c020::1)}                                                                                       |
    |  }                                                                                                                                                                          |
    |  Auth-Request-Type=AUTHORIZE_AUTHENTICATE                                                                                  |
    |  EAP-Payload(début EAP)                                                                                                                                  |
    |--------------------------------------------------------------------------------------------------------------------------------->|
    |                                                                                                                                                                              |
    :                                                   ...plus de paires de demande/réponse EAP...                                                    :
    |                                                                                                                                                                              |
    |                                            Diameter-EAP-Answer                                                                                             |
    |               MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | MIP6_INTEGRATED)          |
    |                                   Result-Code=DIAMETER_SUCCESS                                                                             |
    |                                       EAP-Payload(réussite EAP)                                                                                          |
    |                                         EAP-Master-Session-Key                                                                                            |
    |                                           (AVP d'autorisation)                                                                                                  |
    |                                                                 ...                                                                                                          |
    |<---------------------------------------------------------------------------------------------------------------------------------|
    |                                                                                                                                                                              |

Figure 2 : Allocation d'agent de rattachement par le NAS

Selon la configuration du serveur Diameter et le profil d'abonnement de l'utilisateur, le serveur Diameter accepte ou rejette le HA local alloué par le NAS. Dans notre exemple, le serveur Diameter accepte la proposition, et l'AVP MIP6-Feature-Vector avec le fanion LOCAL_HOME_AGENT_ASSIGNMENT (ainsi que le fanion MIP6_INTEGRATED) établi est retourné au NAS.

 	5.2	Allocation d'agent de rattachement par le serveur Diameter
Dans ce scénario, on considère le cas où le NAS prend en charge le scénario intégré Diameter MIPv6 comme défini dans le présent document, mais n'offre pas d'allocation locale de HA. Donc, l'AVP MIP6-Feature-Vector a seulement le fanion MIP6_INTEGRATED établi. Le serveur Diameter alloue un HA au nœud mobile et porte l'adresse dans l'AVP MIP-Home-Agent-Address qui est encapsulée dans l'AVP MIP6-Agent-Info. De plus, l'AVP MIP6-Feature-Vector a le fanion MIP6_INTEGRATED établi.

   NAS                                                                                                                                      Serveur Diameter
    |  Diameter-EAP-Request 	|
    |  MIP6-Feature-Vector=(MIP6_INTEGRATED)	|
    |  Auth-Request-Type=AUTHORIZE_AUTHENTICATE	|
    |  EAP-Payload(début EAP)	|
    |----------------------------------------------------------------------------------------------------------------------->|
    |	|
    :                                ...plus de paires de demande/réponse EAP ...	:
    |	|
    |                                            Diameter-EAP-Answer	|
    |                                               MIP6-Agent-Info{ 	|
    |            MIP-Home-Agent-Address(2001:db8:6000:302::1)	|
    |                                                              }	|
    |                          MIP6-Feature-Vector=(MIP6_INTEGRATED)	|
    |                                   Result-Code=DIAMETER_SUCCESS	|
    |                                       EAP-Payload(réussite EAP)	|
    |                                         EAP-Master-Session-Key	|
    |                                           (AVP d'autorisation)	|
    |                                                           ...	|
    |<-----------------------------------------------------------------------------------------------------------------------|
    | 	|

Figure 3 : Allocation d'agent de rattachement par le serveur Diameter

 	5.3	Allocation d'agent de rattachement par le NAS ou le serveur Diameter
Ce paragraphe montre un autre flux de messages pour le scénario intégré d''amorçage MIPv6 où le NAS informe le serveur Diameter qu'il est capable d'allouer en local un HA au MN. Le serveur Diameter est capable de fournir un HA au MN mais aussi autorise l'allocation du HA local. Le serveur Diameter répond alors au NAS avec des informations d'amorçage relatives au HA.

Si le NAS/ASP offre alors un HA alloué localement ou si le HA alloué par le serveur Diameter au MN est, dans cet exemple, fondé sur la politique locale de l'ASP.

   NAS/VAAA	Serveur Diameter
    |  Diameter-EAP-Request 	|
    |  MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | | MIP6_INTEGRATED)	|
    |  MIP6-Agent-Info{ 	|
    |       MIP-Home-Agent-Address(2001:db8:1:c020::1)}  	|
    |  } 	|
    |  Auth-Request-Type=AUTHORIZE_AUTHENTICATE 	|
    |  EAP-Payload(début EAP)	|
    |-------------------------------------------------------------------------------------------------------------------->|
    |                                                                 |
    :                                ...plus de paires de demande/réponse EAP ...	:
    | 	|
    |                                            Diameter-EAP-Answer	 |
    |                                               MIP6-Agent-Info{	|
    |                  MIP-Home-Agent-Address(2001:db8:6000:302::1)}	|
    |     MIP6-Feature-Vector=(LOCAL_HOME_AGENT_ASSIGNMENT | MIP6_INTEGRATED)	|
    |                                   Result-Code=DIAMETER_SUCCESS 	|
    |                                       EAP-Payload(EAP Success)  	|
    |                                         EAP-Master-Session-Key 	|
    |                                           (AVP d'autorisation)	|
    |                                                           ...	|
    |<--------------------------------------------------------------------------------------------------------------------|

Figure 4 : Allocation d'agent de rattachement par le NAS ou le serveur Diameter

Si le serveur Diameter ne permet pas au MN d'utiliser un HA alloué en local, le serveur Diameter retourne au MN l'AVP MIP6-Feature-Vector avec le bit LOCAL_HOME_AGENT_ASSIGNMENT non établi et l'adresse de HA qu'il a allouée.

 	6.	Tableaux d'occurrence de paire d'attribut-valeur

La Figure 5 fait la liste des AVP d'interface NAS à HAAA d'amorçage MIPv6 avec une spécification déterminant combien de nouvelles AVP peuvent être incluses dans une commande Diameter. Elles peuvent être présentes dans toute demande d'application Diameter et commandes de réponse, lorsque c'est permis par l'ABNF de commande.

	Commande
Nom d'attribut	Demande	Réponse
MIP6-Agent-Info 	0+	0+
MIP6-Feature-Vector	0-1	0-1

Figure 5 : Tableau des AVP génériques de demande et réponse

 	7.	Considérations relatives à l’IANA
 	7.1	Enregistrement  de nouveaux AVP
La présente spécification définit les AVP suivantes qui ont été allouées dans l'espace de code normal d'AVP Diameter (valeurs ≥ 256) :

MIP6-Agent-Info est réglé à 486

Les nouvelles AVP suivantes sont à allouer dans l'espace de type d'attribut RADIUS [RFC2865] afin qu'elles soient rétro compatibles avec RADIUS (valeurs de code d'AVP entre 0 et 255) :

MIP6-Feature-Vector est réglé à 124
MIP6-Home-Link-Prefix est réglé à 125

 	7.2	Nouveau registre : capacité de mobilité
L'IANA a créé un nouveau registre pour la capacité de mobilité comme décrit au paragraphe 4.2.5.

Jeton	Valeur	Description
MIP6_INTEGRATED	0x0000000000000001	[RFC5447]
LOCAL_HOME_AGENT_ASSIGNMENT	0x0000000000000002	[RFC5447]
Disponible pour allocation par l'IANA	2^x	

Règle d'allocation : seules les valeurs numériques qui sont 2^x (puissances de deux, où x ≥ 2) sont permises, sur la base de la politique d'allocation décrite ci-dessous.

Suivant les exemples de politiques décrits dans la [RFC5226], les nouvelles valeurs pour le registre des capacités de mobilité vont être allouées sur la base de la politique de "Spécification exigée". Aucun mécanisme pour marquer des entrées comme "déconseillées" n'est envisagé.

 	8.	Considérations sur la sécurité

Les considérations sur la sécurité pour l'interaction Diameter requise pour accomplir le scénario intégré sont décrites dans la [RFC6611]. De plus, les considérations sur la sécurité pour le protocole de base Diameter [RFC3588], l'application  Diameter NASREQ [RFC4005], et l'application Diameter EAP (par rapport à l'authentification d'accès au réseau et au transport du matériel de chiffrement) [RFC4072] sont applicables au présent document. Les développeurs devraient porter une attention particulière à la configuration des associations de sécurité qui protègent les messages permettant le positionnement global et l'allocation des agents de rattachement, par exemple, comme souligné à la Section 5.

De plus, les messages Diameter peuvent être transportés entre le NAS et le serveur Diameter via un ou plusieurs courtiers AAA ou agents Diameter (comme des mandataires). Dans ce cas, la communication AAA du NAS au serveur Diameter repose sur les propriétés de sécurité des courtiers AAA intermédiaires et des agents Diameter.

 	9.	Remerciements

Ce document est largement fondé sur le travail en cours pour l'interaction RADIUS MIPv6.  Donc, son crédit va aux auteurs respectifs pour les travaux sur la "Prise en charge de RADIUS IPv6 mobile" (novembre 2008). De plus, les auteurs de ce document tiennent à remercier les auteurs de "Application Diameter IPv6 mobile" (novembre 2004) -- Franck Le, Basavaraj Patil, Charles E. Perkins, et Stefano Faccin -- pour leur travail dans le contexte de l'interfonctionnement MIPv6 Diameter. Ce travail a influencé le présent document. Jouni Korhonen tient à remercier l'Academie de Finlande et le projet TEKES MERCoNe pour la fourniture du financement du présent document pendant qu'il était à TeliaSonera. Julien Bournelle remercie GET/INT car il a commencé à travailler sur le présent document pendant qu'il y était employé. Les auteurs remercient Raymond Hsu de ses précieux retours sur l'allocation de HA local, et Wolfgang Fritsche pour sa relecture attentive. De plus, nous remercions Domagoj Premec de ses commentaires.

Finalement, nous voudrions remercier Alper Yegin, Robert Marks, et David Frascone de leurs commentaires au second dernier appel au groupe de travail.

 	10.	Références
 	10.1	Références normatives

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

[RFC2865]	C. Rigney et autres, "Service d'authentification à distance de l'utilisateur appelant (RADIUS)", juin 2000. (MàJ par RFC2868, RFC3575, RFC5080, RFC8044) (D.S.)

[RFC3588]	P. Calhoun et autres, "Protocole fondé sur Diameter", septembre 2003. (Remplacée par la RFC6733) (P.S.)

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

[RFC4004]	P. Calhoun et autres, "Application IPv4 mobile Diameter", août 2005. (P.S.)

[RFC4005]	P. Calhoun et autres, "Application de serveur d'accès au réseau Diameter", août 2005. (P.S.) (Remplacée par RFC7155)

[RFC4072]	P. Eronen et autres,  "Application Diameter du protocole d'authentification extensible (EAP)", août 2005. (P.S. ; MàJ par RFC8044)

 	10.2	Références pour information

[DSMIPv6]	Solimand, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6)", Travail en cours, décembre 2008.

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

[RFC4640]	A. Patel et G. Giaretta, éd., "Position du problème de l'amorçage d'IPv6 mobile (MIPv6)", septembre 2006. (Info.)

[RFC5026]	G. Giaretta et autres, "Amorçage IPv6 mobile dans un scénario de partage", octobre 2007. (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5637]	G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez, "Objectifs d'authentification, d'autorisation et de comptabilité (AAA) pour IPv6 Mobile" septembre 2009. (Information)

[RFC6611]	K. Chowdhury, A. Yegin, "Amorçage de IPv6 mobile (MIPv6) pour le scénario intégré", mai 2012. (P.S.)

 	Adresse des auteurs

Jouni Korhonen	Julien Bournelle	Hannes Tschofenig	
Nokia Siemens Networks	Orange Labs	Nokia Siemens Networks	
Linnoitustie 6	38-40 rue du general Leclerc	Linnoitustie 6	
Espoo  FIN-02600	Issy-Les-Moulineaux  92794	Espoo  02600	
Finland	France	Finland	
mél : jouni.nospam@gmail.com	mél : julien.bournelle@orange-ftgroup.com	mél : Hannes.Tschofenig@nsn.com	

Charles E. Perkins	Kuntal Chowdhury	
WiChorus Inc.	Starent Networks	
3590 North First St., Suite 300	30 International Place	
San Jose, CA  95134	Tewksbury, MA  01876	
US	US	
mél : charliep@wichorus.com	mél : kchowdhury@starentnetworks.com