Groupe de travail Réseau	M. Crawford, Fermilab
Request for Comments : 2470 	T. Narten, IBM
Catégorie : Sur la voie de la normalisation	S. Thomas, TransNexus
Traduction Claude Brière de L'Isle	décembre 1998

Transmission de paquets IPv6 sur réseaux d'anneau à jetons

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 (1998). Tous droits réservés.
Table des matières
1. Introduction	1
2. Unité de transmission maximum	1
3. Format de trame	2
4. Auto configuration sans état	4
5. Adresse de liaison locale	4
6. Transposition d'adresse – envoi individuel	4
7. Transposition d'adresse – diffusion groupée	5
8. Considérations sur la sécurité	6
9. Remerciements	6
10. Références	6
11. Adresse des auteurs	6
Déclaration complète de droits de reproduction	7

 	1.	Introduction

Le présent mémoire spécifie la MTU et le format de trame pour la transmission des paquets IPv6 sur les réseaux en anneau à jetons (Token Ring networks). Il spécifie aussi la méthode de formation des adresses IPv6 de liaison locale sur les réseaux en anneau à jetons et le contenu de l'option Adresse de source/cible de couche de liaison utilisée dans les messages Sollicitation de routeur, Annonce de routeur, Redirection, Sollicitation de voisin et Annonce de voisin quand ces messages sont transmis sur un réseau en anneau à jetons.

Les développeurs devraient noter que les adaptateurs d'anneaux à jetons supposent que les adresses sont en format non canonique plutôt que canonique, ce qui exige une attention particulière pour s'assurer que les adresses sont traitées correctement. Voir les détails dans le [RFC2469].

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

 	2.	Unité de transmission maximum

Les réseaux IEEE 802.5 ont une taille de trame maximum fondée sur le temps maximum qu'un nœud peut conserver le jeton. Ce temps dépend de nombreux facteurs incluant le taux de signalisation des données et du nombre de nœuds dans l'anneau. Parce que la taille maximum de trame varie, les mises en œuvre doivent s'appuyer sur une configuration manuelle ou des annonces de routeur [RFC2461] pour déterminer les tailles réelles de MTU. Les valeurs par défaut courantes incluent approximativement 2000, 4000, et 8000 octets.

En l'absence d'autres informations, une mise en œuvre devraient utiliser une MTU par défaut de 1500 octets. Cette taille offre la compatibilité avec toutes les valeurs 802.5 par défaut courantes, ainsi qu'avec les LAN Ethernet dans un environnement qui utilise le pontage transparent.

Dans un environnement qui utilise le pontage d'acheminement de source, le processus de découverte de chemin de niveau MAC avec un voisin peut donner la MTU pour le chemin vers ce voisin. Les informations sont contenues dans le plus grand sous champ de trame (LF, Largest Frame) du champ Informations d'acheminement. Ce champ limite la taille du champ Informations des trames pour cette destination, et ce champ Informations inclut à la fois l'en-tête de LLC [8802-2] et le datagramme IPv6. Comme, pour IPv6, l'en-tête de LLC fait toujours 8 octets, la MTU IPv6 peut être trouvée en soustrayant 8 de la taille maximum de trame définie par le sous champ LF. Si une mise en œuvre utilise ces informations pour déterminer les tailles de MTU, elle doit conserver des valeurs de MTU séparées pour chaque voisin.

Une liste détaillée des valeurs de LF et la taille résultante de trame maximum se trouve dans [10038]. Pour illustrer le calcul de MTU IPv6, le tableau suivant fait la liste de plusieurs valeurs communes. Noter que certaines des valeurs de LF de 802.1D vont résulter en une MTU IP de moins de 1280 octets. Cette taille est inférieure au minimum IPv6, et la communication à travers les chemins avec ces MTU n'est généralement pas possible en utilisant IPv6.

LF (base)	LF (extension)	MTU MAC	MTU IP
001	000	  1470	  1462
010	000	  2052	  2044
011	000	  4399	  4391
100	000	  8130	  8122
101	000	11407	11399
110	000	17749	17741
111	000	41600	41592

En présence de valeurs de MTU en conflit provenant de plusieurs sources, une mise en œuvre devraient choisir entre ces sources en accord avec les priorités suivantes :
1.	Les plus grandes valeurs de trame provenant de pont d'acheminement de source (seulement pour les destinations spécifiques d'envoi individuel) mais seulement si elles ne sont pas supérieures à la valeur d'une annonce de routeur.
2.	Les annonces de routeur, mais seulement si elles ne sont pas supérieures à une configuration manuelle (incluant DHCP).
3.	Une configuration manuelle (incluant DHCP).
4.	La valeur par défaut de 1500.

 	3.	Format de trame

Les paquets IPv6 sont transmis dans des trames LLC/SNAP. Le champ Données contient l'en-tête IPv6 et la charge utile. La figure suivante montre une trame 802.5 complète contenant un datagramme IPv6.

+-------+-------+-------+-------+
|  SD   |  AC   |  FC   |       |
+-----------------------+       |
|     Adresse de destination    |
|       +-----------------------+
|       |   Adresse de          |
+-------+    source     +-------+
|                       | DSAP  |
+-------+-------+-------+-------+
| SSAP  |  CTL  |      OUI      |
+-------+-------+-------+-------+
|  OUI  |   EtherType   |       |
+-------+---------------+       |
|                               |
~ En-tête IPv6 et charge utile  ~
|                               |
+-------------------------------+
|              FCS              |
+-------+-------+---------------+
|  ED   |  FS   |
+-------+-------+

Champs d'en-tête d'anneau à jetons :

SD (Starting Delimiter) : délimiteur de début

AC (Access Control) : contrôle d'accès

FC (Frame Control) : contrôle de trame

Adresse de destination : adresse IEEE de 48 bits de la station de destination

Adresse de source : adresse IEEE de 48 bits de la station de source

DSAP (Destination Service Access Point) : point d'accès de service de destination (pour le format LLC/SNAP, devra toujours contenir la valeur 0xAA)

SSAP (Source Service Access Point) : point d'accès de service de source (pour le format LLC/SNAP, devra toujours contenir la valeur 0xAA)

CTL : champ Contrôle (pour Informations non numérotées, devra toujours contenir la valeur 0x03)

OUI (Organizationally Unique Identifier) : identifiant unique d'organisation (pour le codage EtherType, devra toujours contenir la valeur 0x000000)

EtherType : type de protocole de la charge utile encapsulée (pour IPv6, devra toujours contenir la valeur 0x86DD)

FCS (Frame Check Sequence) : séquence de vérification de trame

ED (Ending Delimiter) : délimiteur de fin

FS (Frame Status) : statut de trame

En présence de ponts d'acheminement de source, un champ Informations d'acheminement (RIF, routing information field) peut apparaître immédiatement après l'adresse de source. Un RIF est présent dans les trames quand le bit de poids fort de l'adresse de source est réglé à un. (C'est le bit dont la position correspond à celle du bit Individuel/Groupe dans l'adresse de destination.)

Le RIF est un champ de longueur variable qui (quand il est présent) contient un en-tête de deux octets de contrôle d'acheminement (RC, Routing Control) suivi de zéro, un ou plusieurs champs Désignation de chemin de deux octets :

                           0                   1
                           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Contrôle d'acheminement   |Diff.| Longueur|D|  LF   |rsvé |
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Désignation de chemin 1  :|    Segment 1          | Pont 1|
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                          ~              ...              ~
                          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Désignation de chemin N : |    Segment N          | Pont N|
  (0 <= N <= 7)           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champs de Désignation de chemin :

Diff. : Indicateur de diffusion, les valeurs définies sont :
10x : Explorateur Tous-les-chemins
11x : Explorateur d'arborescence d'expansion
0xx : Trame acheminée spécifiquement

Longueur : longueur totale du champ RIF en octets

D : Direction du chemin de source. Une valeur de 0 signifie que la séquence de gauche à droite des désignations de chemin donne le chemin de l'envoyeur au receveur. Une valeur de 0 indique que la séquence va du receveur à l'envoyeur.

LF (Largest Frame) : plus grande trame

rsvé : réservé

À l'émission, le champ Désignation de chemin donne la séquence de nombre de (pont, segment de LAN) que le paquet va traverser. Il est de la responsabilité de l'envoyeur de fournir cette séquence pour les trames acheminées spécifiquement, c'est-à-dire, les datagrammes IP en envoi individuel.

 	4.	Auto configuration sans état

L'identifiant d'interface [RFC2373] pour une interface d'anneau à jetons se fonde sur l'identifiant EUI-64 [EUI64] déduit de l'adresse IEEE 802 incorporée de 48 bits de l'interface. Le OUI de l'adresse d'anneau à jetons (les trois premiers octets) deviennent l'identifiant d'entreprise de l'EUI-64 (les trois premiers octets). Le quatrième et le cinquième octet de l'EUI sont réglés à la valeur FFFE hexadécimale fixée. Les trois derniers octets de l'adresse d'anneau à jetons deviennent les trois derniers octets de l'EUI-64.

L'identifiant d'interface est alors formé à partir de l'EUI-64 en complétant le bit "Universel/Local" (U/L) qui est le second bit de moindre poids du premier octet de l'EUI-64. Compléter ce bit va généralement changer une valeur de 0 en 1, car une adresse incorporée d'interface est supposée être d'un espace d'adresses d'administration universelle et donc avec une valeur unique au monde. Une adresse IEEE 802 d'administration universelle ou un EUI-64 est signifiée par un 0 dans la position de bit U/L, tandis qu'un identifiant d'interface IPv6 unique au monde est signifié par un 1 dans la position correspondante. Voir dans la [RFC2373] plus d'explications sur ce point.

Par exemple, l'identifiant d'interface pour une interface d'anneau à jetons dont l'adresse incorporée est, en hexadécimal et en ordre canonique des bits, 34-56-78-9A-BC-DE, serait 36-56-78-FF-FE-9A-BC-DE.

Une adresse MAC différente réglée manuellement ou par le logiciel ne devrait pas être utilisée pour déduire l'identifiant d'interface. Si une telle adresse MAC doit être utilisée, sa propriété d'unicité mondiale devrait être reflétée dans la valeur du bit U/L.

Un préfixe d'adresse IPv6 utilisé pour l'auto configuration sans état d'une interface d'anneau à jetons doit avoir une longueur de 64 bits.

 	5.	Adresse de liaison locale

L'adresse IPv6 de liaison locale [RFC2373] pour une interface d'anneau à jeton est formée en ajoutant l'identifiant d'interface, comme défini ci-dessus, au préfixe FE80::/64.

  10 bits            54 bits                  64 bits
+----------+-----------------------+----------------------------+
|1111111010|         (zéros)       |  Identifiant d'interface   |
+----------+-----------------------+----------------------------+

 	6.	Transposition d'adresse – envoi individuel

La procédure pour transposer des adresses IPv6 d'envoi individuel en adresses de couche de liaison d'anneaux à jetons est décrite dans la [RFC2461]. L'option Adresse de couche de liaison de source/cible a le format suivant quand la couche de liaison est un anneau à jeton .

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Longueur   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-         Adresse d'anneau    -+
|            à jetons           |
+-                             -+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Champs d'options :

Type : 1 pour l'adresse de couche de liaison de source ; 2 pour l'adresse de couche de liaison de cible.

Longueur : 1 (en unités de 8 octets).

Adresse d'anneau à jeton : adresse IEEE 802 de 48 bits d'anneau à jeton, dans l'ordre canonique des bits. C'est l'adresse à laquelle l'interface répond actuellement, et peut être différente de l'adresse incorporée utilisée pour déduire l'identifiant d'interface.

Quand des ponts d'acheminement de source sont utilisés, le chemin de source pour une destination peut être extrait du champ RIF des messages d'annonce de voisin reçus. Noter que le champ RIF des paquets reçus peut être inversé dans un chemin de source convenable pour transmettre le trafic de retour en basculant la valeur du bit 'D' et en s'assurant que le champ Diff. est réglé à indiquer une trame à acheminement spécifique.

 	7.	Transposition d'adresse – diffusion groupée

Tous les paquets IPv6 avec des adresses de destination de diffusion groupée sont transmises aux adresses fonctionnelles d'anneau à jetons. Le tableau suivant montre les transpositions spécifiques entre les adresses IPv6 et et les adresses fonctionnelles d'anneau à jetons (en forme canonique). Noter que les protocoles autres que IPv6 peuvent utiliser ces mêmes adresses fonctionnelles, de sorte que toutes les trames d'anneau à jetons destinées à ces adresses fonctionnelles ne sont pas garanties d'être des datagrammes IPv6.

Adresse MAC (canonique)	Adresses IPv6 de diffusion groupée	
03-00-80-00-00-00	Adr. Tous-les-nœuds (FF01::1 et FF02::1) et nœud sollicité (FF02:0:0:0:0:1:FFXX:XXXX)	
03-00-40-00-00-00	Adresses Tous-les-routeurs (FF0X::2)	
03-00-00-80-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 000	
03-00-00-40-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 001	
03-00-00-20-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 010	
03-00-00-10-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 011	
03-00-00-08-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 100	
03-00-00-04-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 101	
03-00-00-02-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 110	
03-00-00-01-00-00	Toute autre adresse de diffusion groupée avec les trois bits de moindre poids = 111	

Dans un réseau d'anneau à jetons ponté, tous les paquets de diffusion groupée devraient être envoyés avec un en-tête RIF spécifiant l'utilisation de l'explorateur d'arborescence d'expansion.

Note : on estime que certaines (très) anciennes mises en œuvre de pont ne prennent pas en charge de façon correcte le mécanisme d'explorateur d'arborescence d'expansion. Dans un tel environnement, le trafic de diffusion groupée envoyé à travers les ponts doit utiliser un RIF avec l'explorateur Tous-les-chemins. Par conséquent, une mise en œuvre PEUT souhaiter permettre l'envoi du trafic de diffusion groupée IP en utilisant l'explorateur Tous-les-chemins. Cependant, une telle capacité doit être configurable par un administrateur de système et le réglage par défaut du commutateur DOIT être d'utiliser l'explorateur d'arborescence d'expansion.

 	8.	Considérations sur la sécurité

Les anneaux à jetons, comme la plupart des technologies de LAN en diffusion, ont des vulnérabilités inhérentes de sécurité. Par exemple, tout envoyeur peut prétendre avoir l'identité d'un autre et falsifier le trafic. Il est de la responsabilité des couches supérieures de prendre les mesures appropriées dans les environnements où de telles vulnérabilités sont inacceptables.

 	9.	Remerciements

Plusieurs membres du groupe de travail IEEE 802.5 ont contribué par leurs connaissances et leur expérience à la rédaction de cette spécification, dont Jim, Andrew Draper, George Lin, John Messenger, Kirk Preiss, et Trevor Warwick. Les auteurs tiennent aussi à remercier les nombreux membres du groupe de travail IPng de leurs avis et suggestions, dont Ran Atkinson, Scott Bradner, Steve Deering, Francis Dupont, Robert Elz, et Matt Thomas. Des remerciements particuliers sont dus à Steve Wise, qui a donné les avis les plus pertinents en essayant de mettre en œuvre cette spécification alors qu'elle était encore en cours d'élaboration.

 	10.	Références

[10038]	Norme ISO/CEI 10038: 1993 "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes – réseaux de zone locale – Ponts de contrôle d'accès au support (MAC)", (ANSI/IEEE Std 802.1D, édition1993).

[802.5]	Norme ISO/CEI 8802-5 : 1995 "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes-- réseaux locaux et de zone métropolitaine – Exigences spécifiques -- Partie 5: Méthode d'accès par anneau à jeton et spécification de la couche physique", (ANSI/IEEE 802.5, édition 1995).

[8802-2]	Norme ISO/CEI 8802-2 : 1994, "Technologie de l'information - Télécommunications et échanges d'informations entre systèmes-- réseaux locaux et de zone métropolitaine – Exigences spécifiques -- Partie 2 : Contrôle de liaison logique", (ANSI/IEEE 802.2, édition 1994).

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

[RFC1971]	S. Thomson, T. Narten, "Auto configuration d'adresse sans état dans IPv6", août 1996. (Obsolète, voir RFC2462) (P.S.)

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

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

[RFC2460]	S. Deering et R. Hinden, "Spécification du protocole Internet, version 6 (IPv6)", décembre 1998. (MàJ par 5095, 6564   ; D.S ; Remplacée par RFC8200, STD 86) 

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

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

[RFC2469]	T. Narten, C. Burton, "Avertissement sur l'ordre canonique des adresses de couche Liaison", décembre 1998. (Info.)

 	11.	Adresse des auteurs

Matt Crawford	Thomas Narten	Stephen Thomas	
Fermilab MS 368	IBM Corporation	TransNexus	
PO Box 500	P.O. Box 12195	430 Tenth Street NW Suite N204	
Batavia, IL 60510 	Research Triangle Park, NC 27709-2195	Atlanta, GA 30318 	
USA	USA	USA	
téléphone : +1 630 840 3461	téléphone : +1 919 254 7798	téléphone : +1 404 872 4745	
mél : crawdad@fnal.gov 	mél : narten@raleigh.ibm.com 	mél : stephen.thomas@transnexus.com 	

 	Déclaration complète de droits de reproduction

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

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

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

Le présent document et les informations 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.