Groupe de travail Réseau	G. Armitage, Lucent Technologies
Request for Comments : 2492	P. Schulter, BrightTiger Technologies
Catégorie : Sur la voie de la normalisation	M. Jork, Digital Equipment GmbH
Traduction Claude Brière de L'Isle	janvier 1999

IPv6 sur réseaux ATM

Statut de ce mémoire
Le présent document spécifie un protocole en cours de normalisation de l’Internet 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 "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright 
Copyright (C) The Internet Society (1999). Tous droits réservés.

Résumé
Le présent document accompagne le document d'architecture du groupe de travail ION, "IPv6 sur réseaux d'accès multiple sans diffusion (NBMA)". Il fournit des détails spécifiques sur la façon d'appliquer l'architecture IPv6 sur NBMA aux réseaux ATM. Cette architecture permet le fonctionnement conventionnel côté hôte du protocole de découverte de voisin IPv6, tout en prenant en charge l'établissement de chemins "raccourcis" de transmission ATM (quand on utilise des SVC). Le fonctionnement sur des PVC point à point configurés administrativement est aussi pris en charge.
Table des matières
1. Introduction.	1
2. Terminologie de spécification	2
3. Environnements de PVC	2
3.1 Encapsulation de paquet par défaut	2
3.2 Encapsulation nulle facultative	2
3.3 Encapsulation PPP	2
3.4 MTU pour environnements de PVC	3
3.5 Formats de jetons d'interface dans des environnements de PVC	3
4. Environnements de SVC	3
4.1 Codets spécifiques de SVC	3
4.2 Questions de signalisation UNI 3.0/3.1 (mode SVC)	5
5. Jetons d'interface	5
5.1 Jetons d'interface fondés sur des valeurs de ESI	5
5.2 Jetons d'interface fondés sur des valeurs de MAC de 48 bits	5
5.3 Jetons d'interface fondés sur des valeurs EUI-64	5
5.4 Jetons d'interface fondés sur des adresses natives E.164	5
5.5 Nœuds sans identifiants uniques	6
5.6 Plusieurs liaisons logiques sur une seule interface	6
6. Conclusion et questions ouvertes	6
7. Considérations sur la sécurité	6
Remerciements	6
Adresse des auteurs	7
Références	7
Déclaration complète de droits de reproduction	7

 	1.	Introduction.

Le présent document est un document d'accompagnement spécifique de ATM de la spécification du groupe de travail ION sur "IPv6 sur réseaux d'accès multiple sans diffusion (NBMA)" [RFC2491]. La terminologie et les descriptions architecturales ne sont pas répétées ici.

L'utilisation de ATM pour fournir le service de PVC en point à point, ou le service flexible de SVC en point à point et point à multipoint, est traitée par le présent document.

Une mise en œuvre de pilote IPv6/ATM conforme DEVRA au minimum prendre en charge le mode de fonctionnement de PVC. Une mise en œuvre de pilote IPv6/ATM qui prend en charge le mode SVC complet DEVRA aussi prendre en charge le mode de fonctionnement PVC.

 	2.	Terminologie de spécification

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

 	3.	Environnements de PVC

Quand le réseau ATM est utilisé en mode PVC, chaque PVC va connecter exactement deux nœuds et l'utilisation de la découverte de voisin et autres caractéristiques IPv6 est limitée. Les interfaces IPv6/ATM ont seulement un voisin sur chaque liaison. Les protocoles MARS et NHRP NE sont PAS nécessaires, car les opérations de diffusion et diffusion groupée retombent au niveau ATM en une opération d'envoi individuel. Les raccourcis découverts dynamiquement ne sont pas pris en charge.

Les sections qui suivent donnent les détails réels des encapsulations, de la MTU, et de la génération de jeton de liaison.

Cette utilisation de liaisons PVC ne rend pas obligatoire, ni n'interdit, l'utilisation d'extensions au protocole de découverte de voisin qui peuvent être développées pour un usage général dans les connexions PVC (par exemple, la découverte inverse de voisin).

Comme les liaisons PVC ATM n'utilisent pas d'adresses de couche de liaison, les options d'adresse de couche de liaison NE DEVRAIENT PAS être incluses dans un message de découverte de voisin [RFC2461]. Si une option d'adresse de couche de liaison est présente dans un message de découverte de voisin, l'option DEVRAIT être ignorée.

Une mise en œuvre de pilote IPv6/ATM conforme DEVRA au minimum prendre en charge le mode de fonctionnement de PVC. Les mises en œuvre seulement de PVC ne sont pas obligées de prendre en charge un mode de focntionnement de SVC.

 	3.1	Encapsulation de paquet par défaut
Suivant le modèle de la [RFC1483], AAL5 DEVRA être le service de couche d'adaptation par défaut, et l'encapsulation (LLC/SNAP) DEVRA être l'encapsulation par défaut utilisée par les paquets en envoi individuel et en diffusion groupée à travers les liaisons PVC en point à point. Comme défini dans la [RFC2491], l'encapsulation de paquet IPv6 par défaut DEVRA être :

[0xAA-AA-03][0x00-00-00][0x86-DD][paquet IPv6]
             (LLC)             (OUI)          (PID)

 	3.2	Encapsulation nulle facultative
Les pilotes IPv6/ATM PEUVENT aussi prendre en charge l'encapsulation nulle comme option configurable. Quand l'encapsulation nulle est activée, le paquet IPv6 est passé directement à la couche AAL5. Les deux extrémités du PVC DOIVENT être configurées à utiliser l'encapsulation nulle. Le PVC ne va pas être disponible pour des protocoles autres que IPv6.

 	3.3	Encapsulation PPP
L'enchaînement de PVC IPv6 sur PPP avec des PVC PPP sur AAL5 n'est pas couvert par cette spécification.

 	3.4	MTU pour environnements de PVC
La taille de MTU IP par défaut pour les liaison differents PVC est de 9180 octets comme spécifié dans la [RFC1626]. D'autres valeurs de MTU IP PEUVENT être utilisées.

 	3.5	Formats de jetons d'interface dans des environnements de PVC
Quand le réseau ATM est utilisé en mode PVC, les jetons d'interface DEVRONT être générés en utilisant une des méthodes décrites à la Section 5. Les jetons d'interface ont seulement besoin d'être uniques entre les deux nœuds sur la liaison PVC.

 	4.	Environnements de SVC
 	4.1	Codets spécifiques de SVC
 	4.1.1	Encapsulation de couche d'adaptation ATM pour environnements de SVC
Suivant le modèle de la [RFC1483], AAL5 DEVRA être le service de couche d'adaptation par défaut, et l'encapsulation (LLC/SNAP) DEVRA être l'encapsulation par défaut utilisée par les paquets en envoi individuel et en diffusion groupée à travers les liaisons SVC.

 	4.1.2	Encapsulation de paquet en envoi individuel
Comme défini dans la [RFC2491], l'encapsulation de paquet IPv6 en envoi individuel par défaut DEVRA être :

[0xAA-AA-03][0x00-00-00][0x86-DD][paquet IPv6]
             (LLC)             (OUI)           (PID)

 	4.1.3	Encapsulation de paquet en diffusion groupée
Comme défini dans la [RFC2491], l'encapsulation de paquet IPv6 en diffusion groupée par défaut DEVRA être :

[0xAA-AA-03][0x00-00-5E][0x00-01][pkt$cmi][0x86DD][IPv6 packet]
             (LLC)             (OUI)         (PID)     (encapsulation mars)

L'identifiant de membre de grappe du pilote ATM/IPv6 DEVRA être copiée dans le champ de deux octets "pkt$cmi" avant la transmission.

 	4.1.4	Encapsulation nulle facultative
Les pilotes IPv6/ATM PEUVENT aussi prendre en charge l'encapsulation nulle comme option configurable. L'encapsulation nulle DEVRA n'être utilisée que pour passer les paquets IPv6 d'un pilote ATM/IPv6 à un autre. L'encapsulation nulle NE DEVRA PAS être utilisée sur le SVC en point à point entre le pilote IPv6/ATM et son MARS local.

Si l'encapsulation nulle est activée, le paquet IPv6 est passé directement à la couche AAL5. Les deux extrémités du SVC DOIVENT s'accorder pour utiliser l'encapsulation nulle durant la phase SETUP. Le SVC ne va pas être disponible pour des protocoles autres que IPv6.

Si l'encapsulation nulle est activée sur des SVC de données entre des routeurs, le trafic NHRP inter routeurrs DEVRA utiliser un SVC séparé en parallèle.

L'utilisation de l'encapsulation nulle n'est pas encouragée quand IPv6/ATM est utilisé avec MARS/NHRP/ND comme décrit dans la [RFC2491].

 	4.1.5	Messages de contrôle MARS
L'encapsulation des messages de contrôle MARS (entre MARS et les clients MARS) reste la même que ce qui est montré dans la [RFC2022] :

[0xAA-AA-03][0x00-00-5E][0x00-03][message de contrôle MARS]
           (LLC)               (OUI)         (PID)

Les valeurs clés de champ de contrôle sont :
Le champ mar$afn reste 0x0F (adresse ATM)
Le champ mar$pro DEVRA être 0x86DD (IPv6)
Le champ mar$op.version reste 0x00 (MARS)
Les champs mar$spln et mar$tpln (lorsque pertinent) sont soit 0 (pour des informations nulles ou non existantes) soit 16 (pour l'adresse de protocole IPv6 complète)
La façon dont les adresses ATM sont mémorisées reste la même que ce qui est montré dans la [RFC2022]

 	4.1.6	Messages de contrôle NHRP
L'encapsulation des messages de contrôle NHRP reste la même que ce qui est montré dans la [RFC2332] :

[0xAA-AA-03][0x00-00-5E][0x00-03][message de contrôle NHRP]
         (LLC)          (OUI)          (PID)

Les valeurs clés de champ de contrôle sont :
Le champ ar$afn reste 0x0F (adresses ATM)
Le champ ar$pro DEVRA être 0x86DD (IPv6)
Le champ ar$op.version reste 0x01 (NHRP)
Les champs ar$spln et ar$tpln (lorsque pertinent) sont soit 0 (pour des informations nulles ou non existantes) soit 16 (pour l'adresse de protocole IPv6 complète)
La façon dont les adresses ATM sont mémorisées reste la même que ce qui est montré dans la [RFC2022]

 	4.1.7	Messages de contrôle de découverte de voisin
Le paragraphe 5.2 de la [RFC2491] décrit l'option Adresse de couche de liaison de découverte de voisin. Pour les pilotes IPv6/ATM, les sous champs DEVRONT être codés de la manière suivante :

[NTL] définit le type et la longueur du numéro ATM qui suit immédiatement le champ [STL]. Le format est le suivant :

 7 6 5 4 3 2 1 0
+-+-+-+-+-+-+-+-+
|0|x| longueur  |
+-+-+-+-+-+-+-+-+

Le bit de poids fort est réservé et DOIT être réglé à zéro. Le second bit de poids fort (x) est un fanion qui indique si le numéro ATM est en format :
AESA ATM Forum (x = 0)
natif E.164                (x = 1).

Les six bits suivants représentent une valeur d'entier non signé pour indiquer la longueur du champ d'adresse ATM associé en octets.

Le format de [STL] est le même que celui du champ [NTL]. Il définit la longueur du champ de sous adresse, si il existe. Si il n'existe pas, ce champ d'octet entier DOIT être à zéro. Si la sous adresse existe, elle va être en format AESA, de sorte que le fanion x DEVRA être à zéro.

[Numéro NBMA] est un champ de longueur variable qui contient l'adresse ATM de la cible de couche de liaison. Il est toujours présent.

[Sous adresse NBMA] est un champ de longueur variable qui contient la sous adresse ATM de la cible de couche de liaison. Il peut être ou non présent. Quand il ne l'est pas, l'option se termine après le [Numéro NBMA] (ou tout bourrage supplémentaire pour l'alignement sur huit octets).

L'ordre des octets des champs [Numéro NBMA] et [Sous adresse NBMA] DEVRA être le même que celui utilisé dans les messages de contrôle MARS et NHRP.

 	4.2	Questions de signalisation UNI 3.0/3.1 (mode SVC)
Quand un nœud IPv6 passe un appel à un autre nœud IPv6, il DEVRAIT suivre les procédures des [RFC1755] et [RFC1626] pour la signalisation des SVC UNI 3.0/3.1 [ATM-UNI] et négocier la MTU. La taille de MTU IP par défaut sur la couche de liaison est 9180 octets comme spécifié dans la [RFC1626].

Noter qu'alors que les procédures de la [RFC1626] s'appliquent encore à IPv6 sur ATM, la découverte de la MTU de chemin IPv6 [RFC1981] est utilisée par les nœuds et routeurs plutôt que la découverte de la MTU IPv4. De plus, alors que les nœuds IPv6 ne sont pas obligés de mettre en œuvre la découverte de la MTU de chemin, les nœuds IPv6/ATM DEVRAIENT la mettre en œuvre. Aussi, comme les nœuds IPv6 vont négocier une MTU appropriée pour chaque VC, la MTU de chemin ne devrait jamais être déclenchée car aucun d'eux ne devrait jamais recevoir de message Paquet trop gros qui déclenche la découverte de MTU de chemin. Quand des nœuds communiquent via un ou plusieurs routeurs la découverte de la MTU de chemin va être utilisée tout comme elle l'est pour les réseaux traditionnels.

 	5.	Jetons d'interface

Pour les deux modes de fonctionnement PVC et SVC, une des méthodes suivantes DEVRA être utilisée pour générer des jetons d'interface comme exigé par le paragraphe 5.1 de la [RFC2491].

 	5.1	Jetons d'interface fondés sur des valeurs de ESI
Quand l'interface ATM sous-jacente est identifiée par une adresse de système d'extrémité ATM (AESA, ATM End System Address (anciennement appelée NSAPA)) le jeton d'interface PEUT être formé à partir des valeurs de ESI et SEL dans la AESA comme suit : [0x00][ESI][SEL]

[0x00] est un champ d'un octet qui est toujours réglé à 0. Noter que le bit qui correspond au bit EUI-64 Global/Local [TUTO] est toujours remis à indiquer que cette adresse n'est pas un jeton d'interface IPv6 unique au monde.

[ESI] est un champ de six octets. Ce champ contient toujours la valeur d'ESI de six octets pour la AESA utilisée pour l'adresse de l'instance spécifique d'interface IPv6/ATM.

[SEL] est un champ de un octet. Ce champ contient toujours la valeur de SEL provenant de la AESA utilisée pour l'adresse de l'instance spécifique d'interface IPv6/ATM.

 	5.2	Jetons d'interface fondés sur des valeurs de MAC de 48 bits
Lorsque le pilote NIC ATM sous-jacent a accès à un ensemble d'une ou plusieurs valeurs de MAC uniques de 48 bits au NIC ATM (par exemple des adresses MAC configurées dans la ROM du NIC) l'interface IPv6/ATM PEUT utiliser une de ces valeurs pour créer un jeton d'interface unique comme décrit dans la [RFC2373].

 	5.3	Jetons d'interface fondés sur des valeurs EUI-64
Lorsque le pilote NIC ATM sous-jacent a accès à un ensemble de une ou plusieurs valeurs EUI-64 uniques de 64 bits au NIC ATM (par exemple des adresses EUI-64 configurées dans la ROM du NIC) l'interface IPv6/ATM DEVRAIT utiliser une de ces valeurs pour créer un jeton d'interface unique, après inversion du bit d'identifiant Global/Local [RFC2373]. (Toute relation entre ces valeurs et le ou les ESI enregistrés auprès du commutateur local ATM par le pilote ATM sortent du domaine d'application du présent document.)

Quand des valeurs EUI-64 sont utilisées pour des jetons d'interface IPv6, la seule modification permise à la chaîne d'octets lue du NIC est l'inversion du bit Identifiant Global/Local.

 	5.4	Jetons d'interface fondés sur des adresses natives E.164
Quand une interface utilise les adresses E.164 natives, alors des valeurs E.164 PEUVENT être utilisées pour générer un jeton d'interface comme suit :

[D14][D13D12][D11D10][D9D8][D9D6][D5D4][D3D2][D1D0]

[D14] : un seul octet contenant le demi octet représentant le chiffre E.164 de poids fort décalé à gauche de quatre bits sur les quatre bits de poids fort de l'octet. Les quatre bits de moindre poids DOIVENT être réglés à 0. Noter que l'indicateur Global/Local EUI-64 est réglé à 0 pour indiquer que ce n'est pas un jeton d'interface IPv6 mondialement unique.

[D13D12] : un seul octet contenant le demi octet représentant le second chiffre de plus fort poids E.164 [D13] décalé à gauche de quatre places sur les bits de plus fort poids de l'octet, et le troisième demi octet de plus fort poids dans les quatre bits de moindre poids de l'octet.

[D11D10] - [D1D0] : octets contenant chacun deux chiffres E.164, un dans les quatre bits de plus fort poids, et un dans les quatre bits de moindre poids comme indiqué.

 	5.5	Nœuds sans identifiants uniques
Si aucune valeur MAC, EUI-64, AESA, ou E.164 n'est disponible pour générer un jeton d'interface, le jeton d'interface DEVRA alors être généré comme décrit dans l'Appendice A de la [RFC2373].

 	5.6	Plusieurs liaisons logiques sur une seule interface
Une interface logique ATM pourrait être associée à un champ SEL différent d'un préfixe AESA commun, ou un ensemble de ESI entièrement séparé pourrait avoir été enregistré auprès du commutateur local ATM pour créer une gamme de AESA uniques.

Les informations minimum requises pour identifier de façon univoque chaque interface logique ATM sont (dans le contexte de l'accès de commutateur local) leur combinaison ESI+SEL.

Pour le cas de vhost décrit au paragraphe 5.1.2 de la [RFC2491], vhost DEVRA choisir un jeton d'interface différent de la gamme de valeurs de 64 bits disponible au NIC ATM (comme décrit au paragraphe 4.1). Chaque vhost DEVRA mettre en œuvre des interfaces IPv6/ATM d'une façon telle que deux vhost ou plus n'annoncent pas le même jeton d'interface sur la même LL. (La conformité à cette exigence peut être réalisée en choisissant des valeurs différentes de SEL, de ESI, ou les deux.)

 	6.	Conclusion et questions ouvertes

Le présent document spécifique d'ATM accompagne la spécification "IPv6 sur réseaux en accès multiple sans diffusion (NBMA)" [RFC2491] du groupe de travail ION. Il spécifie les codets pour les modes de fonctionnement de PVC configurés administrativement, et de SVC établis dynamiquement,.

Il n'y a pas de problème majeur pendant. Les commentaires sont sollicités sur la liste de diffusion ION (ion@nexen.com).

 	7.	Considérations sur la sécurité

Bien que la présente proposition n'introduise aucun nouveau mécanisme de sécurité, tous les mécanismes de sécurité IPv6 actuels vont fonctionner sans modification pour ATM. Cela inclut l'authentification et le chiffrement pour les protocoles de découverte de voisin ainsi que l'échange de paquets de données IPv6.

 	Remerciements

Le travail original sur IPv6/ATM par G. Armitage a été fait lorsqu'il était employé par Bellcore. Des éléments de la Section  4 ont été empruntés au mémoire de Matt Crawford sur IPv6 sur Ethernet.

Les auteurs remercient Kazuhiko Yamamoto, Kenjiro Cho, Yoshinobu Inoue, Hiroshi Esaki, Yoshifumi Atarashi, et Atsushi Hagiwara de leurs contributions fondées sur les mises en œuvre réelles de PVC.

 	Adresse des auteurs

Grenville Armitage	Peter Schulter	Markus Jork	
Bell Laboratories, Lucent Technologies	BrightTiger Technologies	Digital Equipment GmbH	
101 Crawfords Corner Road	125 Nagog Park	Vincenz-Priessnitz-Str. 1	
Holmdel, NJ 07733	Acton, MA 01720	D-76131 Karlsruhe	
USA	USA	Germany	
mél : gja@lucent.com 	mél : paschulter@acm.org 	mél : jork@kar.dec.com 	

 	Références

[ATM-UNI]	ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, juin 1995.

[RFC1483]	Juha Heinanen, "Encapsulation multiprotocole sur couche 5 d'adaptation ATM", juillet 1993. (remplacée par 2684)

[RFC1626]	R. Atkinson, "MTU IP par défaut à utiliser sur AAL5 en ATM", mai 1994. (P.S., remplacée par 2225)

[RFC1755]	M. Perez et autres, "Prise en charge de la signalisation ATM pour IP sur ATM", février 1995. (P.S.)

[RFC1981]	J. McCann, S. Deering, J. Mogul, "Découverte de la MTU de chemin pour IP version 6", août 1996. (D.S. ; Remplacé par [RFC8201], STD87)

[RFC2022]	G. Armitage, "Prise en charge de la diffusion groupée sur réseaux ATM fondés sur UNI 3.0/3.1", novembre 1996. (P.S.)

[RFC2332]	J. Luciani et autres, "Protocole de résolution du prochain bond NBMA (NHRP)", avril 1998. (P.S.)

[RFC2373]	R. Hinden, S. Deering, "Architecture d'adressage IP version 6", juillet 1998. (Obsolète, voir RFC4291) (PS) 

[RFC2461]	T. Narten, E. Nordmark, W. Simpson, "Découverte de voisins pour IP version 6 (IPv6)", décembre 1998. (Obsolète, voir RFC4861) (D.S.)

[RFC2491]	G. Armitage et autres, "IPv6 sur réseaux en accès multiple sans diffusion (NBMA)", janvier 1999. (P.S. ; MàJ par RFC8064)

[TUTO] "64-Bit Global Identifier Format Tutorial", http://standards.ieee.org/db/oui/tutorials/EUI64.html. 

 	Déclaration complète de droits de reproduction

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

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

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

Le présent document et les informations contenues sont fournis sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.