RFC2464 Transmission IPv6 sur Ethernet Crawford

Groupe de travail Réseau

M. Crawford, Fermilab

Request for Comments : 2464


RFC rendue obsolète : 1972

décembre 1998

Catégorie : En cours de normalisation

Traduction Claude Brière de L’Isle



Transmission des paquets IPv6 sur les réseaux Ethernet



Statut du présent mémoire

Le présent document spécifie un protocole de l’Internet en cours de 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 "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.


1. Introduction


Le présent document spécifie le format de trame pour la transmission de paquets IPv6 et la méthode de formation des adresses IPv6 de liaison locale et des adresses autoconfigurées sans état sur les réseaux Ethernet. Il spécifie aussi le contenu de l’option Adresse de couche liaison de source/cible utilisée dans les messages Sollicitation de routeur, Annonce de routeur, Sollicitation de voisin, Annonce de voisin et Redirection lorsque ces messages sont transmis sur un Ethernet.


Le présent document remplace la RFC1972, "Méthode de transmission des paquets IPv6 sur les réseaux Ethernet", qui devient historique


Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" dans ce document sont à interpréter comme décrit dans la [RFC2119].


2. Unité maximum de transmission


La taille de la MTU par défaut pour les paquets IPv6 [RFC2460] sur un Ethernet est 1500 octets. Cette taille peut être réduite par une annonce de routeur [RFC2461] contenant une option de MTU qui spécifie une MTU plus petite, ou par configuration manuelle de chaque nœud. Si une annonce de routeur reçue sur une interface Ethernet a une option MTU qui spécifie une MTU de plus de 1500, ou plus grande qu’une valeur configurée manuellement, cette option MTU peut être signalée à la gestion système mais doit être ignorée par ailleurs.


Pour les besoins du présent document, les informations reçues de DHCP sont considérées comme "configurées manuellement" et le terme Ethernet inclut les sous-réseaux CSMA/CD et bidirectionnels fondés sur la norme ISO/CEI 8802-3, avec divers débits de données.


3. Format de trame


Les paquets IPv6 sont transmis dans des trames Ethernet standard. L’en-tête Ethernet contient les adresses Ethernet de destination et de source et le code de type Ethernet, qui doit contenir la valeur hexadécimale 86DD. Le champ Données contient l’en-tête IPv6 suivi immédiatement par la charge utile, et éventuellement des octets de bourrage pour satisfaire à la taille minimum de trame de la liaison Ethernet.


0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

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

| Adresse |

+- -+

| Ethernet |

+- -+

| de destination |

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

| Adresse |

+- -+

| Ethernet |

+- -+

| de source |

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

|1 0 0 0 0 1 1 0 1 1 0 1 1 1 0 1|

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

| En-tête |

+- -+

| IPv6 |

+- -+

| et |

+- -+

/ charge utile. /

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


(Chaque cran représente un bit.)


4. Autoconfiguration sans état


L’identifiant d’interface [RFC2373] pour une interface Ethernet se fonde sur l’identifiant EUI-64 [EUI64] déduit de l’adresse IEEE 802 de 48 bits incorporée dans l’interface. Le EUI-64 est formé comme suit. (L’ordre canonique des bits est supposé dans tout le document.)


Le OUI de l’adresse Ethernet (les trois premiers octets) devient l’identifiant de compagnie 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 hexadécimale FFFE fixée. Les trois derniers octets de l’adresse Ethernet 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 0 en 1, car l’adresse incorporée d’une interface est supposée tirée d’un espace d’administration universelle et avoir donc une valeur unique au monde. Une adresse IEEE 802 d’administration universelle ou un EUI-64 est signifié 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. Pour en savoir plus sur ce point, voir la [RFC2373].


Par exemple, l’identifiant d’interface d’une interface Ethernet dont l’adresse incorporée est, en hexadécimal, 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 un 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’autoconfiguration sans état de la [RFC2462] d’une interface Ethernet doit avoir une longueur de 64 bits.


5. Adresses de liaison locale


L’adresse IPv6 de liaison locale de la [RFC2373] pour une interface Ethernet 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 d’envoi individuel


La procédure de transposition des adresses IPv6 en envoi individuel en adresses Ethernet de couche liaison est décrite dans la [RFC2461]. L’option Adresse de source/cible de couche liaison a la forme suivante lorsque la couche liaison est Ethernet.


0 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

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

| Type | Longueur |

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

| |

+- Adresse -+

| Ethernet |

+- -+

| |

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


Champs d’option :


Type : 1 pour l’adresse de couche liaison de source.

2 pour l’adresse de couche liaison de cible.


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


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


7. Transposition d’adresse de diffusion groupée


Un paquet IPv6 avec une adresse de destination de diffusion groupée DST, consistant en les seize octets de DST[1] à DST[16], est transmis à l’adresse de diffusion groupée Ethernet dont les deux premiers octets sont la valeur hexadécimale 3333 et dont les quatre derniers octets sont les quatre derniers octets de DST.


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

|0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1|

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

| DST[13] | DST[14] |

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

| DST[15] | DST[16] |

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


8. Différences avec la RFC1972


Voici les différences fonctionnelles entre la présente spécification et la RFC 1972.


Le jeton Adresse, qui était l’adresse MAC de 48 bis d’un nœud, est remplacé par l’identifiant d’interface, qui fait 64 bits et se fonde sur le format EUI-64 [EUI64]. Il existe une transposition définie par l’IEEE des adresses MAC de 48 bits en format EUI-64.


Un préfixe utilisé pour l’autoconfiguration sans état doit maintenant faire 64 bits plutôt que 80. Le préfixe de liaison locale est raccourci à 64 bits.


9. Considérations pour la sécurité


La méthode de déduction des identifiants d’interface à partir des adresses MAC est destinée à préserver lorsque possible l’unicité mondiale. Cependant, il n’y a pas de protection contre la duplication accidentelle ou frauduleuse.


10. Références


[EUI64] "Guidelines For 64-bit Global Identifier (EUI-64)", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html


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


[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 RFC5095, 6564) (D.S)


[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, "Autoconfiguration d'adresse IPv6 sans état", décembre 1998. (Obsolète, voir RFC4862) (D.S.)


11. Adresse de l’auteur


Matt Crawford

Fermilab MS 368

PO Box 500

Batavia, IL 60510

USA

téléphone : +1 630 840-3461

mél : crawdad@fnal.gov


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


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


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

page - 4 -