Algorithme de traduction IP/ICMP sans état (SIIT)

Déclaration de copyright

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

Résumé

Le présent document spécifie un algorithme de mécanisme de transition qui s'ajoute aux mécanismes déjà spécifiés dans la [RFC1933]. L'algorithme fait la traduction entre les en-têtes de paquet IPv4 et IPv6 (y compris les en-têtes ICMP) dans des "boîtes" de traducteur séparées dans le réseau sans exiger aucun état par connexion dans ces "boîtes". Ce nouvel algorithme peut être utilisé au titre d'une solution qui permet aux hôtes IPv6, qui n'ont pas d'adresse IPv4 allouée en permanence, de communiquer avec des hôtes seulement IPv4. Le document ne spécifie ni les allocations d'adresse ni l'acheminement de et vers les hôtes IPv6 lorsque ils communiquent avec les hôtes seulement IPv4.

Remerciements

Le présent document a été produit par le groupe de travail NGTRANS. Certaines parties du texte ont été extraites d'un vieux projet Internet intitulé "IPAE : Interopérabilité SIPP et mécanisme de transition" rédigé par R. Gilligan, E. Nordmark et B. Hinden. George Tsirtsis a fourni les figures pour la Section 1. Keith Moore a relu attentivement le document.

Table des Matières

1.   Introduction et motivation

1.1   Applicabilité et limitations

1.2   Hypothèses

1.3   Impact en dehors de la couche réseau

2.   Terminologie

2.1   Adresses

2.2   Exigences

3.   Traduction de IPv4 en IPv6

3.1   Traduction des en-têtes IPv4 en en-têtes IPv6

3.2   Traduire UDP sur IPv4

3.3   Traduire les en-têtes ICMPv4 en en-têtes ICMPv6

3.4   Traduire les messages d'erreur ICMPv4 en ICMPv6

3.5   Savoir quand traduire

4.   Traduire d'IPv6 en IPv4

4.1   Traduire des en-têtes IPv6 en en-têtes IPv4

4.2   Traduire des en-têtes ICMPv6 en en-têtes ICMPv4

4.3   Traduire les messages d'erreur ICMPv6 en ICMPv4

4.4   Savoir quand traduire

5.   Implications pour les nœuds IPv6 seul

6.   Considérations pour la sécurité

Références

Adresse de l'auteur

Déclaration complète de droits de reproduction

1.   Introduction et motivation

Les mécanismes de transition spécifiés dans la [RFC1933] traitent le cas des hôtes duels IPv4/IPv6 qui interopèrent à la fois avec les hôtes duels et les hôtes IPv4 seul, ce qui est nécessaire tôt dans la transition vers IPv6. Les hôtes duels ont une allocation à la fois d'une adresse IPv4 et d'une ou plusieurs adresses IPv6. Comme le nombre d'adresses IPv4 uniques au monde disponibles devient de plus en plus petit à mesure de la croissance de l'Internet, on désire tirer parti de la grande adresse IPv6 et ne pas exiger de tout nouveau nœud Internet qu'il ait une adresse IPv4 allouée en permanence.

Il y a plusieurs scénarios différents où il peut y avoir des hôtes IPv6 seul qui ont besoin de communiquer avec des hôtes IPv4 seul. Ces hôtes IPv6 peuvent être à capacité IPv4, c'est-à-dire inclure une mise en œuvre IPv4 mais n'avoir pas d'adresse IPv4 allouée, ou ils peuvent même ne pas comporter de mise en œuvre de IPv4.

-   Un réseau complètement nouveau avec de nouveaux appareils qui prennent tous en charge IPv6. Dans ce cas, il peut être avantageux de ne pas avoir à configurer les routeurs au sein du nouveau réseau à acheminer IPv4 car aucun des hôtes dans le nouveau réseau n'est configuré avec des adresses IPv4. Mais ces nouveaux appareils IPv6 peuvent à l'occasion avoir besoin de communiquer avec des nœuds IPv4 ailleurs sur l'Internet.

-   Un réseau existant où sont ajoutés de nombreux appareils IPv6. Les appareils IPv6 peuvent avoir les deux piles de protocole IPv4 et IPv6 mais il n'y a pas assez d'espace d'adresse IPv4 global pour donner à chacun d'eux une adresse IPv4 permanente. Dans ce cas, il est très vraisemblable que les routeurs dans le réseau acheminent déjà IPv4 et soient mis à niveau comme routeurs duels

Cependant, il y a d'autres solutions potentielles dans ce domaine :

-   Si il n'y a pas d'acheminement IPv4 à l'intérieur du réseau, c'est-à-dire, dans le nuage qui contient les nouveaux appareils, des solutions possibles sont d'utiliser les traducteurs spécifiés dans le présent document à la frontière du nuage, ou d'utiliser des passerelles de couche application (ALG, Application Layer Gateways) sur des nœuds duels à la frontière du nuage. La solution ALG est moins flexible en ce qu'elle est spécifique du protocole d'application et ce qu'elle est aussi moins robuste car une boîte ALG va vraisemblablement être le point faible pour la connexion qui utilise cette boîte.

-   Autrement, si l'acheminement IPv4 est pris en charge dans le nuage et si les mises en œuvre acceptent à la fois IPv6 et IPv4, il peut suffire d'avoir un mécanisme d'allocation d'adresse IPv4 temporaire et d'utiliser IPv4 de bout en bout lors des communications avec les nœuds IPv4 seul. Cependant, il semblerait qu'une telle solution exigerait que le pôle d'adresses IPv4 temporaires soit partagé entre tous les sous-réseaux du nuage ce qui pourrait exiger un plus grand pôle d'adresses IPv4 ou aboutir à des cas où la communication échouerait du fait du manque d'adresses IPv4 disponibles pour le sous-réseau du nœud.

Le présent document spécifie un algorithme qui est un des composants nécessaires pour faire interopérer les nœuds IPv6 seul avec les nœuds IPv4 seul. Les autres composants, non spécifiés dans ce document, sont un mécanisme pour que le nœud IPv6 seul acquière en quelque sorte une adresse temporaire IPv4, et un mécanisme pour fournir l'acheminement (peut-être en utilisant le tunnelage) de et vers l'adresse IPv4 temporaire allouée au nœud.

L'adresse IPv4 temporaire sera utilisée comme une adresse IPv6 traduite en IPv4 et les paquets vont voyager à travers un traducteur IP/ICMP sans état qui va traduire les en-tête du paquet entre IPv4 et IPv6 et traduire les adresses dans ces en-têtes entre adresses IPv4 d'un côté et en adresses traduites en IPv4 ou IPv6 transposées en IPv4 de l'autre côté.

La présente spécification ne traite pas de la façon dont un nœud IPv6 peut acquérir une adresse IPv4 temporaire et dont une telle adresse temporaire est enregistrée dans le DNS. Le protocole DHCP, peut-être avec certaines extensions, pourrait probablement être utilisé pour acquérir des adresses temporaires prêtées à court terme mais cela sort du domaine d'application du présent document. Le mécanisme pour acheminer cette adresse IPv6 traduite en IPv4 sur le site n'est également pas spécifié dans ce document.

Les figures ci-dessous montrent comment l'algorithme de traduction IP/ICMP sans état (SIIT, Stateless IP/ICMP Translation) peut être utilisé initialement pour de petits réseaux (par exemple, un seul sous-réseau) et plus tard pour un site qui a des hôtes IPv6 seul dans un réseau IPv4/IPv6 dual. Cette utilisation suppose un mécanisme pour que les nœuds IPv6 acquièrent une adresse temporaire du pôle d'adresses IPv4. Noter que SIIT ne sera vraisemblablement pas utile plus tard dans la transition lorsque la plus grande partie de l'Internet sera IPv6 et qu'il y aura seulement des îlots de nœuds IPv4, car une telle utilisation exigerait que les nœuds IPv6 acquièrent des adresses IPv4 temporaires d'une boîte SIIT "distante" gérée par une administration différente, ou exigerait que l'acheminement IPv6 contienne des routes pour les adresses transposées en IPv6. (Cette dernière idée est réputée très mauvaise à cause de la taille du tableau d'acheminement IPv4 qui devrait éventuellement être injecté dans l'acheminement IPv6 sous la forme d'adresse transposées en IPv4.)

                                                                           ___________

                                                                          /           \

                                            [Hôte IPv6]---[SIIT]---------< réseau IPv4 >--[Hôte IPv4]

                                                             |            \___________/

                                                      (pôle d'adresses IPv4)

                                            Traduisible en IPv4 ->          IPv4->adresseur IPv4

                                            Transposé en IPv4

Figure 1. Utiliser SIIT pour un seul sous-réseau IPv6 seul.

                                                         ___________              ___________

                                                        /           \            /           \

                                          [Hôte IPv6]--< Réseau dual >--[SIIT]--< réseau IPv4 >--[Hôte IPv4]

                                                        \___________/      |     \___________/

                                                                    (pôle d'adresses IPv4)

                                            Traduisible en IPv4 ->            IPv4->adresseur IPv4

                                            Transposé en IPv4

Figure 2. Utiliser SIIT pour un nuage IPv6 seul ou dual (par exemple, un site) qui contient des hôtes IPv6 seul ainsi que des hôtes IPv4.

Les traducteurs de protocole sont supposés se coller à un élément topologique qui comporte des nœuds IPv6 seul et qui peut aussi comporter des nœuds IPv4 ainsi que des nœuds duels Il doit y avoir un traducteur sur chaque chemin utilisé par l'acheminement des paquets "traduisibles" dans et hors de ce nuage pour garantir que de tels paquets sont toujours traduits. Cela n'exige pas un traducteur à chaque connexion physique entre le nuage et le reste de l'Internet car l'acheminement peut être utilisé pour livrer les paquets au traducteur.

Le nœud IPv6 seul communiquant avec un nœud IPv4 à travers un traducteur va voir une adresse transposée en IPv4 pour l'homologue et va utiliser une adresse traduisible en IPv4 comme adresse locale pour cette communication. Lorsque le nœud IPv6 seul envoie des paquets, l'adresse transposée en IPv4 indique que le traducteur doit traduire les paquets. Lorsque le nœud IPv4 envoie des paquets, ceux-ci vont les traduire pour avoir l'adresse traduisible en IPv4 comme destination ; il n'est pas possible d'utiliser une adresse transposée en IPv4 ou une adresse compatible IPv4 comme destination car soit cela acheminerait le paquet en retour au traducteur (pour l'adresse transposée en IPv4) soit cela devrait encapsuler le paquer en IPv4 (pour l'adresse compatible IPv4). Et donc, la présente spécification introduit la nouvelle notion d'adresse traduisible en IPv4.

1.1   Applicabilité et limitations

L'utilisation de cet algorithme de traduction suppose que le réseau IPv6 est assez bien connecté c'est-à-dire que quand un nœud IPv6 veut communiquer avec un autre nœud IPv6 il y a un chemin IPv6 entre eux. Divers schémas de tunnelage existent qui peuvent fournir un tel chemin, mais ces mécanismes et leur utilisation sortent du domaine d'application de ce document.

Le protocole IPv6 [RFC2460] a été conçu de telle sorte que les sommes de contrôle de pseudo en-tête TCP et UDP ne soient pas affectées par les traductions spécifiées dans ce document, et donc le traducteur n'a pas besoin de modifier les en-têtes TCP et UDP normaux. Les seules exceptions sont les paquets UDP IPv4 non fragmentés qui ont besoin d'avoir une somme de contrôle UDP calculée car une somme de contrôle de pseudo en-tête est exigée pour UDP dans IPv6. Aussi, ICMPv6 inclut une somme de contrôle de pseudo en-tête mais elle n'est pas présente dans ICMPv4 et donc la somme de contrôle dans les messages ICMP doit être modifiée par le traducteur. De plus, les messages d'erreur ICMP contiennent un en-tête IP au titre de la charge utile et donc le traducteur a besoin de réécrire ces parties des paquets pour rendre le receveur capable de comprendre l'en-tête IP inclus. Cependant, toutes les opérations du traducteur, y compris la découverte de la MTU du chemin, sont sans état au sens où le traducteur opère indépendamment sur chaque paquet et ne conserve aucun état d'un paquet à l'autre. Cela permet des boîtes de traducteur redondantes sans aucune coordination et une connexion TCP donnée peut avoir les deux directions de paquets qui passent par des boîtes de traducteur différentes.

La fonction de traduction telle que spécifiée dans le présent document ne traduit aucune option IPv4 et ne traduit aucun en-tête d'acheminement IPv6, aucun en-tête d'extension bond par bond, ni d'en-tête d'option de destination. Il serait possible de définir une traduction entre acheminement de source dans IPv4 et IPv6. Cependant une telle traduction ne serait pas sémantiquement correcte du fait des légères différences entre l'acheminement de source IPv4 et IPv6. Et aussi, l'utilité de l'acheminement de source lors du passage à travers un traducteur d'en-tête pourrait être limité car tous les routeurs IPv6-seul auraient besoin d'avoir une adresse IPv6 traduite en IPv4 car le nœud IPv4-seul va envoyer une option route de source contenant seulement des adresses IPv4.

À première vue, il pourrait paraître que la fonctionnalité IPsec [RFC2401, RFC2406, RFC2402] ne peut pas être portée à travers le traducteur. Cependant, comme le traducteur ne modifie aucun en-tête au dessus de la couche IP logique (en-têtes IP, en-têtes de fragment IPv6, et messages ICMP) les paquets chiffrés en utilisant ESP en mode transport peuvent être portés à travers le traducteur. [Noter que cela suppose que la gestion de clés peut fonctionner entre le nœud IPv6 seul et le nœud IPv4-seul.] Le calcul d'en-tête d'authentification (AH) couvre des parties des champs d'en-tête IPv4 tels que les adresses IP, et les champs d'identification (les champs qui sont soit intangibles soit prévisibles par l'envoyeur) [RFC2402]. Alors que l'algorithme SIIT est spécifié de telle sorte que ces champs IPv4 puissent être prédits par l'envoyeur IPv6, il n'est pas possible au receveur IPv6 de déterminer la valeur du champ Identification de IPv4 dans les paquets envoyés par le nœud IPv4. Et donc, comme l'algorithme de traduction est spécifié dans ce document, il n'est pas possible d'utiliser l'AH de bout en bout à travers le traducteur.

Pour que ESP en mode tunnel fonctionne à travers le traducteur le nœud IPv6 devrait être capable à la fois d'analyser et de générer un en-tête IPv4 "interne" car l'IP interne sera chiffré avec le protocole de transport.

Donc en pratique, seul le mode transport ESP est relativement facile à faire fonctionner à travers un traducteur.

Les adresses de diffusion groupée IPv4 ne peuvent pas être transposées en adresses de diffusion groupée IPv6. Par exemple, ::ffff:224.1.2.3 est une adresse IPv6 transposée en IPv6 avec une adresse de classe D, cependant, ce n'est pas une adresse de diffusion groupée IPv6. Bien que l'aspect traduction d'en-tête IP/ICMP du présent mémoire fonctionne en théorie pour les paquets en diffusion groupée, cette limitation de la transposition d'adresse rend impossible d'appliquer les techniques de ce mémoire au trafic en diffusion groupée.

1.2   Hypothèses

Les nœuds IPv6 qui utilisent le traducteur doivent avoir une adresse IPv6 traduite en IPv4 lorsque ils communiquent avec des nœuds IPv4 seul.

L'utilisation de l'algorithme suppose qu'il y a un pôle d'adresses IPv4 qui est utilisé pour générer des adresses traduites en IPv4. L'acheminement doit être capable d'acheminer tous les paquets IPv4, qu'ils soient générés "en dehors" ou "à l'intérieur" du traducteur, destinés aux adresses dans ce pôle pour le traducteur. Cela implique que le pôle d'adresses ne puisse pas être alloué aux sous-réseaux mais qu'il doit être séparé des sous-réseaux IPv4 utilisés sur "l'intérieur" du traducteur.

Les paquets UDP IPv4 fragmentés qui ne contiennent pas de somme de contrôle UDP (c'est-à-dire que le champ de somme de contrôle UDP est zéro) ne sont pas d'une utilisation significative dans les larges zones sur l'Internet et ne seront pas traduits par le traducteur. Une recherche informelle [MILLER] dans le cœur de réseau a montré que sur 34 984 468 paquets IP il y avait 769 paquets UDP fragmentés avec une somme de contrôle de zéro. Cependant, tous résultaient d'un comportement malveillant ou défectueux ; un accès examine les premiers fragments de paquets IP qui ne sont pas un multiple de 8 octets.

1.3   Impact en dehors de la couche réseau

L'existence potentielle de traducteurs IP/ICMP sans états est déjà prise en compte du point de vue d'un protocole dans la [RFC2460]. Cependant, un nœud IPv6 qui veut être capable d'utiliser des traducteurs a besoin d'un supplément de logique dans la couche réseau.

La couche réseau dans un nœud IPv6 seul, lorsque elle est présentée par l'application soit avec une adresse de destination IPv4 soit avec une adresse de destination IPv6 transposée en IPv4, va vraisemblablement abandonner le paquet et retourner un message d'erreur à l'application. Afin de tirer parti des traducteurs, un tel nœud devrait plutôt envoyer un paquet IPv6 lorsque l'adresse de destination est l'adresse transposée en IPv4 et que l'adresse de source est l'adresse traduite en IPv4 temporairement allouée au nœud. Si le nœud n'a pas d'adresse traduite en IPv4 temporairement allouée, il devrait en acquérir une en utilisant des mécanismes qui ne sont pas exposés dans le présent document.

Noter que ce qui précède s'applique aussi à un nœud qui met en œuvre le IPv4/IPv6 duel et qui n'est pas configuré avec une adresse IPv4.

Il n'est pas nécessaire d'apporter d'autres modifications aux applications pour qu'elles fonctionnent à travers un traducteur en plus de ce dont les applications ont déjà besoin pour fonctionner sur un nœud duel. Les applications qui ont été modifiées pour fonctionner sur un nœud duel ont déjà les mécanismes pour déterminer si elles communiquent avec un homologue IPv4 ou IPv6. Et donc, si les applications ont besoin de modifier leur comportement selon le type de l'homologue, comme FTP qui détermine de se replier sur l'utilisation de la commande PORT/PASV lorsque EPRT/EPSV échoue (comme spécifié dans la [RFC2428]), elles ont d'ores et déjà besoin de le faire lorsque elles fonctionnent sur des nœuds duels et la présence des traducteurs n'ajoute rien. Par exemple, lorsque on utilise la prise API [RFC2553], les applications savent que l'homologue est IPv6 si elles obtiennent une adresse AF_INET6 du service de noms et si l'adresse n'est pas une adresse transposée en IPv4 (c'est-à-dire, si IN6_IS_ADDR_V4MAPPED retourne "faux"). Si ce n'est pas le cas, c'est-à-dire, si l'adresse est AF_INET ou une adresse IPv6 transposée en IPv4, l'homologue est IPv4.

Une façon de voir le traducteur, qui peut aider à préciser pourquoi les applications n'ont pas besoin de savoir qu'un traducteur est utilisé, est de regarder les informations qui son passées de la couche transport à la couche réseau. Si le transport passe une adresse IPv4 (qu'elle soit ou non dans le codage transposé en IPv4) cela signifie que des paquets IPv4 sont générés à un certain point. Dans un nœud dual, la génération des paquets IPv4 a lieu dans le nœud d'envoi. Dans un nœud IPv6 seul la seule différence conceptuelle est que le paquet IPv4 est généré par le traducteur – toutes les informations que la couche transport a passé à la couche réseau va être convoyée au traducteur dans une forme ou une autre. Cette forme se trouve justement être celle d'un en-tête IPv6.

2.   Terminologie

Le présent document utilise la terminologie définie dans la [RFC2460] et dans la [RFC1933] avec les précisions suivantes :

nœud à capacité IPv4 :

Nœud qui a une pile de protocole IPv4. Pour que la pile soit utilisable le nœud doit avoir une ou plusieurs adresses IPv4 allouées.

nœud à capacité IPv4 activée :

Nœud qui a une pile de protocole IPv4 et auquel sont allouées une ou plusieurs adresses IPv4. Les nœuds IPv4-seul et les nœuds IPv4/IPv6 sont tous deux à capacité IPv4 activée.

nœud à capacité IPv6 :

Nœud qui a une pile de protocole IPv6. Pour que la pile soit utilisable le nœud doit avoir une ou plusieurs adresses IPv6 allouées.

nœud à capacité IPv6 activée :

Nœud qui a une pile de protocole IPv6 et auquel sont allouées une ou plusieurs adresses IPv6. Les nœuds IPv6-seul et les nœuds IPv4/IPv6 sont tous deux à capacité IPv4 activée.

2.1   Adresses

En plus des formes d'adresse définies dans la [RFC2373], le présent document introduit aussi la nouvelle forme d'adresse traduite en IPv4. Ceci est nécessaire pour éviter d(utiliser des adresses compatibles IPv4 en dehors de l'utilisation prévue de tunnelage automatique. Donc les formes d'adresse sont :

transposée en IPv4 :

Une adresse de la forme 0::ffff:a.b.c.d qui se réfère à un nœud qui n'est pas à capacité IPv6. En plus de son utilisation dans l'API le présent protocole utilise des adresses transposées en IPv4 dans des paquets IPv6 pour se référer à un nœud IPv4.

compatible IPv4 :

Une adresse de la forme 0::0:a.b.c.d qui se réfère à un nœud IPv6/IPv4 qui prend en charge le tunnelage automatique. De telles adresses ne sont pas utilisées dans ce protocole.

traduite en IPv4 :

Une adresse de la forme 0::ffff:0:a.b.c.d qui se réfère à un nœud à capacité IPv6 activée. Noter que le préfixe 0::ffff:0:0:0/96 est choisi pour avoir une somme de contrôle de zéro pour éviter tout changement de la somme de contrôle de pseudo en-tête du protocole de transport.

2.2   Exigences

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

3.   Traduction de IPv4 en IPv6

Lorsque un traducteur d'IPv4 en IPv6 reçoit un datagramme IPv4 adressé à une destination en dehors de l'île IPv4 rattachée, il traduit l'en-tête IPv4 de ce paquet en un en-tête IPv6. Il transmet ensuite le paquet sur la base de l'adresse de destination IPv6. L'en-tête original IPv4 du paquet est retiré et remplacé par un en-tête IPv6. Sauf pour les paquets ICMP, l'en-tête de couche transport et la portion de données du paquet restent inchangés.

Traduction d'IPv4 en IPv6

Une des différences entre IPv4 et IPv6 est que dans IPv6 une découverte de MTU de chemin est obligatoire alors qu'elle est facultative dans IPv4. Cela implique que les routeurs IPv6 ne vont jamais fragmenter un paquet – seul l'envoyeur peut faire la fragmentation.

Lorsque le nœud IPv4 effectue la découverte de MTU du chemin (en réglant le bit DF dans l'en-tête) la découverte de la MTU de chemin peut fonctionner de bout en bout, c'est-à-dire à travers le traducteur. Dans ce cas, les routeurs IPv4 aussi bien qu'IPv6 peuvent renvoyer des messages ICMP "paquet trop gros" à l'envoyeur. Lorsque ces erreurs ICMP sont envoyées par les routeurs IPv6, ils vont passer à travers un traducteur qui va traduire l'erreur ICMP en une forme que puisse comprendre l'envoyeur IPv4. Dans ce cas, un en-tête de fragment IPv6 n'est inclus que si le paquet IPv4 est déjà fragmenté.

Cependant, lorsque l'envoyeur IPv4 n'effectue pas la découverte de MTU du chemin, le traducteur doit s'assurer que le paquet n'excède pas la MTU du chemin sur le côté IPv6. Cela est fait en fragmentant le paquet IPv4 de telle sorte qu'il tienne dans un paquet IPv6 de 1280 octets puisque IPv6 garantit que les paquets de 1280 octets n'ont jamais besoin d'être fragmentés. Aussi, lorsque l'envoyeur IPv4 n'effectue pas la découverte de la MTU de chemin , le traducteur DOIT toujours inclure un en-tête de fragment IPv6 pour indiquer que l'envoyeur permet la fragmentation. C'est nécessaire pour si le paquet devait passer par un traducteur IPv6 à IPv4.

Les règles ci-dessus assurent que lorsque des paquets sont fragmentés soit par l'envoyeur soit par les routeurs IPv4, les 16 bits de moindre poids de l'identification de fragment sont portés de bout en bout pour assurer que les paquets sont correctement réassemblés. De plus, les règles utilisent la présence d'un en-tête de fragment IPv6 pour indiquer que l'envoyeur pourrait ne pas utiliser la découverte de la MTU de chemin, c'est-à-dire que le paquet ne devrait pas avoir le fanion DF établi pour si il devait ultérieurement être retraduit en IPv4.

À part les règles particulières pour le traitement des fragments et de la découverte de MTU, la traduction réelle de l'en-tête de paquet consiste en une simple transposition définie ci-dessous. Noter que le paquet ICMP exige un traitement particulier afin de traduire le contenu du message d'erreur ICMP et aussi d'ajouter la somme de contrôle du pseudo en-tête ICMP.

3.1   Traduction des en-têtes IPv4 en en-têtes IPv6

Si le fanion DF n'est pas mis dans le paquet IPv4, il en résultera qu'un paquet IPv6 de plus de 1280 octets dans le paquet IPv4 DOIT être fragmenté avant de le traduire. Comme les paquets IPv4 avec le fanion DF non établi résulte toujours en ce qu'un en-tête de fragment sera ajouté au paquet, les paquet IPv4 doivent être fragmentés de sorte que leur longueur, à l'exclusion de l'en-tête IPv4, est au plus de 1232 octets (1280 moins 40 pour l'en-tête IPv6 et 8 pour l'en-tête de fragment). Les fragments résultants sont alors traduits indépendamment en utilisant la logique décrite ci-dessous.

Si le bit DF est mis et si le paquet n'est pas un fragment (c'est-à-dire, si le fanion MF n'est pas mis et si le décalage de fragment est zéro) il n'est alors pas besoin d'ajouter un en-tête de fragment au paquet. Les champs d'en-tête IPv6 sont réglés comme suit :

Version : 6

Classe de trafic :

Par défaut, elle est copiée du Type de service IP et du champ Préséance (tous les 8 bits sont copiés). Selon la [RFC2474] la sémantique des bits est identique dans IPv4 et IPv6. Cependant, dans certains environnements IPv4, ces champs peuvent être utilisés avec l'ancienne sémantique de "Type de service et Préséance". Une mise en œuvre de traducteur DEVRAIT donner la capacité d'ignorer le "TOS" IPv4 et de toujours régler la classe de trafic IPv6 à zéro.

Étiquette de flux : 0 (tous les bits à zéro)

Longueur de charge utile :

C'est la valeur de longueur totale de l'en-tête IPv4, moins la taille de l'en-tête IPv4 et des options IPv4, si présentes.

En-tête suivant :

Champ Protocole copié de l'en-tête IPv4

Limite de bond :

C'est la valeur du TTL copiée de l'en-tête IPv4. Comme le traducteur est un routeur, il a besoin au titre de la transmission du paquet de décrémenter soit le TTL IPv4 (avant la traduction) soit la Limite de bond IPv6 (après la traduction). Au titre de la diminution du TTL ou de la Limite de bond, le traducteur (comme tout routeur) a besoin de vérifier les zéros et d'envoyer l'erreur ICMPv4 ou ICMPv6 "TTL dépassé".

Adresse de source :

Les 32 bits de moindre poids sont l'adresse de source IPv4.

Les 96 bits de poids fort sont le préfixe transposé en IPv4 (::ffff:0:0/96)

Adresse de destination :

Les 32 bits de poids faible sont l'adresse de destination IPv4. Les 96 bits de poids fort sont le préfixe traduit en IPv4 (0::ffff:0:0:0/96)

Si les options IPv4 sont présentes dans le paquet IPv4, ils sont ignorés, c'est-à-dire, il n'y a pas de tentative pour les traduire. Cependant, si une route de source non expirée est présente , le paquet DOIT alors être éliminé, et un message d'erreur ICMPv4 "destination injoignable/échec de route de source" (Type 3/Code 5) DEVRAIT être retourné à l'envoyeur.

Si il est nécessaire d'ajouter un en-tête de fragment (le bit DF n'est pas mis ou le paquet est un fragment) les champs d'en-tête sont réglés comme ci-dessus avec les exceptions suivantes :

Champs IPv6 :

Longueur de charge utile :

La valeur de la longueur totale d'après l'en-tête IPv4, plus 8 pour l'en-tête de fragment, moins la taille de l'en-tête IPv4 et des options IPv4, si il en est de présentes.

Prochain en-tête : En-tête de fragment (44).

Champs d'en-tête de fragment :

Prochain en-tête : Champ Protocole copié de l'en-tête IPv4.

Décalage de fragment : Décalage de fragment copié de l'en-tête IPv4.

Fanion M : Le bit Fragments à venir copié de l'en-tête IPv4.

Identification :    Les 16 bits de moindre poids copiés du champ Identification dans l'en-tête IPv4. Les 16 bits de poids fort sont mis à zéro.

3.2   Traduire UDP sur IPv4

Si un paquet UDP a une somme de contrôle UDP de zéro UDP, une somme de contrôle valide doit alors être calculée afin de traduire le paquet. Un traducteur sans état ne peut pas faire cela pour les paquets fragmentés mais [MILLER] indique que les paquets UDP fragmentés avec une somme de contrôle de zéro paraissent n'être utilisés que pour des usages malveillants. Et donc cela n'est pas estimé être une limitation notable.

Lorsque un traducteur reçoit le premier fragment d'un paquet UDP IPv4 fragmenté et que le champ de somme de contrôle est zéro, le traducteur DEVRAIT abandonner le paquet et générer un événement de gestion système spécifiant au moins les adresses IP et numéros d'accès contenus dans le paquet. Lorsque il reçoit des fragments autres que le premier, il DEVRAIT abandonner le paquet en silence, car il n'y a pas d'information d'accès à enregistrer.

Lorsque un traducteur reçoit un paquet UDP IOv4 non fragmenté et que le champ de somme de contrôle est à zéro, le traducteur DOIT calculer la somme de contrôle UDP manquante au titre de la traduction du paquet. Le traducteur DEVRAIT aussi tenir un compteur du nombre de sommes de contrôle UDP qui sont générées de cette manière.

3.3   Traduire les en-têtes ICMPv4 en en-têtes ICMPv6

Tous les messages ICMP qui sont à traduire exigent que le champ de somme de contrôle ICMP soit mis à jour au titre de la traduction car ICMPv6, à la différence de ICMPv4, a une somme de contrôle de pseudo en-tête tout comme UDP et TCP.

De plus, tous les paquets ICMP ont besoin que la valeur de Type soit traduite et pour les messages d'erreur ICMP, l'en-tête IP inclus a aussi besoin d'être traduit.

Les actions nécessaires pour traduire divers messages ICMPv4 sont :

Messages d'interrogation ICMPv4 :

Écho et Réponse d'écho (Type 8 et Type 0)

Ajuster le type à 128 et 129, respectivement, et ajuster la somme de contrôle ICMP à la fois pour prendre en compte le changement de type et pour inclure le pseudo en-tête ICMPv6.

Demande/Réponse d'information (Type 15 et Type 16)

Obsolète dans ICMPv4. Abandon en silence.

Horodatage et Réponse d'horodatage (Type 13 et Type 14)

Obsolète dans ICMPv6. Abandon en silence.

Demande/Réponse de gabarit d'adresse (Type 17 et Type 18)

Obsolète dans ICMPv6. Abandon en silence.

Annonce de routeur ICMP (Type 9)

Message d'un seul bond. Abandon en silence.

Sollicitation de routeur ICMP (Type 10)

Message d'un seul bond. Abandon en silence.

Types ICMPv4 inconnus

Abandon en silence.

Messages IGMP :

Alors que les messages MLD [RFC2710] sont la contrepartie IPv6 logique des messages IGMP IPv4, tous les messages IGMP "normaux" sont des messages d'un seul bond et devraient être abandonnés en silence par le traducteur. Les autres messages IGMP peuvent être utilisés par les protocoles d'acheminement de diffusion groupée, car ce serait une erreur de configuration d'essayer d'avoir des adjacences de routeurs à travers des traducteurs IPv4/IPv6 et ces paquets devraient aussi être éliminés en silence.

Messages d'erreur ICMPv4 :

Destination injoignable (Type 3)

Pour tous ceux qui ne sont pas explicitement cités ci-dessous, régler le Type à 1.

Traduire le champ de code comme suit :

Code 0, 1 (réseau, hôte injoignable) :

Régler Code à0 (pas de route pour la destination).

Code 2 (protocole injoignable) :

Traduire en Problème de paramètre ICMPv6 (Type 4, Code 1) et faire pointer le pointeur sur le champ IPv6 Prochain en-tête.

Code 3 (accès injoignable) :

Régler Code à 4 (accès injoignable).

Code 4 (fragmentation nécessaire et DF établi) :

Traduire en un message ICMPv6 Paquet trop gros (Type 2) avec le code 0. Le champ MTU doit être ajusté de la différence entre les tailles d'en-tête IPv4 et IPv6. Noter que si le routeur IPv4 n'a pas réglé le champ MTU, c'est-à-dire si le routeur ne met pas en œuvre la [RFC1191], le traducteur doit alors utiliser la valeur plateau spécifiée dans la [RFC1191] pour déterminer une MTU de chemin vraisemblable et inclure cette MTU de chemin dans le paquet ICMPv6. (Utiliser la plus forte valeur plateau qui soit inférieure au champ Longueur totale retourné.)

Code 5 (échec de route de source) :

Régler Code à 0 (pas de route pour la destination). Noter que cette erreur est peu vraisemblable car les routes de source ne sont pas traduites.

Code 6,7 :

Régler Code à 0 (pas de route pour la destination).

Code 8 :

Régler Code à 0 (pas de route pour la destination).

Code 9, 10 (communication avec l'hôte de destination interdite administrativement) :

Régler Code à 1 (communication avec la destination interdite administrativement).

Code 11, 12:

Régler Code à 0 (pas de route pour la destination).

Redirection (Type 5)

Message d'un seul bond. Éliminer en silence.

Extinction de source (Type 4)

Obsolète dans ICMPv6. Éliminer en silence.

Temps dépassé (Type 11)

Régler le champ Type à 3. Le champ Code reste inchangé.

Problème de paramètre (Type 12)

Régler le champ Type à 4. Le pointeur doit être mis à jour pour pointer sur le champ correspondant dans l'en-tête IP traduit inclus.

3.4   Traduire les messages d'erreur ICMPv4 en ICMPv6

Il y a quelques différences entre les formats de message d'erreur ICMP IPv4 et IPv6 comme précisé ci-dessus. De plus, les messages d'erreur ICMP contiennent l'en-tête IP pour le paquet erroné qui doivent être traduits tout comme un en-tête IP normal. La traduction de ce "paquet erroné" va vraisemblablement changer la longueur du datagramme et donc le champ Longueur de charge utile dans l'en-tête IPv6 externe peut devoir être mis à jour.

Traduction d'erreur ICMP IPv4 en IPv6

La traduction de l'en-tête IP interne peut être faite en invoquant de façon récurrente la fonction qui a traduit les en-têtes IP externes.

3.5   Savoir quand traduire

Le traducteur est supposé connaître le ou les pôles d'adresses IPv4 qui sont utilisés pour représenter les nœuds Ipv6 seul internes. Et donc, si le champ destination IPv4 contient une adresse qui échoue dans ces ensembles configurés de préfixes, le paquet a besoin d'être traduit en IPv6.

4.   Traduire d'IPv6 en IPv4

Lorsque an traducteur d'IPv6 en IPv4 reçoit un datagramme IPv6 destiné à une adresse IPv6 transposée en IPv4, il traduit l'en-tête IPv6 de ce paquet en en-tête IPv4. Il transmet alors le paquet sur la base de l'adresse de destination IPv4. L'en-tête IPv6 original du paquet est retiré et remplacé par un en-tête IPv4. Excepté pour les paquets ICMP, l'en-tête de couche transport et la portion données du paquet restent inchangés.

Traduction d'IPv6 en IPv4

Il y a quelques différences entre IPv6 et IPv4 sur les questions de fragmentation et MTU de liaison qui ont un effet sur la traduction. Une liaison IPv6 doit avoir une MTU de 1280 octets ou plus. La limite correspondante pour IPv4 est 68 octets. Et donc, sauf dispositions spéciales, il ne serait pas possible de faire une découverte de MTU de chemin de bout en bout lorsque le chemin comporte un traducteur IPv6 à IPv4 car le nœud IPv6 recevrait des messages ICMP "paquet trop gros" générés par un routeur IPv4 qui rapporte une MTU inférieure à 1280. Cependant, la [RFC2460] exiges que les nœuds IPv6 traitent un tel message ICMP "paquet trop gros" en réduisant la MTU du chemin de 1280 et en incluant un fragment d'en-tête IPv6 avec chaque paquet. Cela permet la découverte de la MTU de chemin de bout en bout à travers le traducteur tant que la MTU du chemin est de 1280 octets ou plus. Lorsque la MTU du chemin tombe en dessous de la limite de 1280, l'envoyeur IPv6 va générer des paquets de 1280 octets qui seront fragmentés par les routeurs IPv4 le long du chemin après avoir été traduits en IPv4.

Le seul inconvénient de ce schéma est qu'il n'est pas possible d'utiliser la PMTU pour faire une fragmentation UDP optimale (par opposition à éviter complètement la fragmentation) chez l'envoyeur car la présence d'un fragment d'en-tête IPv6 est interprétée comme un accord pour fragmenter le paquet du côté IPv4. Et donc si une application UDP veut envoyer de grands paquets indépendamment de la PMTU, l'envoyeur va seulement être capable de déterminer la MTU du chemin du côté IPv6 du traducteur. Si la MTU de chemin du côté IPv4 du traducteur est inférieure, l'envoyeur IPv6 ne va alors recevoir aucune erreur ICMP "paquet trop gros" et ne pourra pas ajuster la taille des fragments qu'il envoie.

En dehors des règles particulières pour le traitement des fragments et la découverte de la MTU du chemin, la traduction réelle de l'en-tête de paquet consiste en une simple transposition comme défini ci-dessous. Noter que les paquets ICMP exigent un traitement particulier afin de traduire le contenu du message d'erreur ICMP et aussi d'ajouter la somme de contrôle de pseudo-en-tête ICMP.

4.1   Traduire des en-têtes IPv6 en en-têtes IPv4

Si il n'y a pas d'en-tête de fragment IPv6, les champs d'en-tête IPv4 sont réglés comme suit :

Version : 4

Longueur d'en-tête Internet : 5 (pas d'options IPv4)

Type de service et Préséance : Par défaut, copiés du champ Classe de trafic IPv6 (tous les 8 bits). Conformément à la [RFC2474] la sémantique des bits est identique dans IPv4 et IPv6. Cependant, dans certains environnements IPv4, ces bits peuvent être utilisés avec l'ancienne sémantique de "Type de service et Préséance". Une mise en œuvre de traducteur DEVRAIT donner las capacité d'ignorer la classe de trafic IPv6 et de toujours régler le "TOS" IPv4 à zéro.

Longueur totale : Valeur de la longueur de la charge utile d'après l'en-tête IPv6, plus la taille de l'en-tête IPv4.

Identification : Tout à zéro.

Fanions : Le fanion Fragments à venir est réglé à zéro. Le fanion Ne pas fragmenter est mis à un.

Décalage de fragment : Tout à zéro.

Durée de vie (TTL) : Valeur de Limite de bonds copiée de l'en-tête IPv6. Comme le traducteur est un routeur, au titre de la transmission du paquet, il doit décrémenter Limite de bonds IPv6 (avant la traduction) ou le TTL IPv4 (après la traduction). En décrémentant le TTL ou la Limite de bonds, le traducteur (comme tout routeur) doit vérifier les zéro et envoyer l'erreur ICMPv4 ou ICMPv6 "ttl excédé".

Protocole : Champ Prochain en-tête copié de l'en-tête IPv6.

Somme de contrôle d'en-tête : Calculée après la création de l'en-tête IPv4.

Adresse de source : Si l'adresse de source IPv6 est une adresse traduite en IPv4, les 32 bits de moindre poids de l'adresse de source IPv6 sont copiés sur l'adresse de source IPv4. Autrement, l'adresse de source est réglée à 0.0.0.0. L'utilisation de 0.0.0.0 permet d'éviter complètement l'élimination (par exemple les messages d'erreur ICMPv6 envoyés par les routeurs IPv6 seul qui, par exemple, font que traceroute présente quelque chose pour les bonds IPv6 seul).

Adresse de destination : Les paquets IPv6 qui sont traduits ont une adresse de destination transposée en IPv4. Et donc les 32 bits de moindre poids de l'adresse de destination IPv6 sont copiés dans l'adresse de destination IPv4.

Si un en-tête d'options bond par bond IPv6, un en-tête d'options de destination, ou un en-tête d'acheminement avec le champ Segments restants égal à zéro est présent dans le paquet IPv6, il est ignoré, c'est-à-dire qu'il n'est pas tenté de le traduire. Cependant, le champ Longueur totale et le champ Protocole devraient être ajustés pour "sauter" ces en-têtes d'extension.

Si un en-tête d'acheminement avec un champ Segments restants différent de zéro est présent, le paquet NE DOIT PAS alors être traduit, et un message d'erreur ICMPv6 "Problème de paramètre / champ d'en-tête erroné rencontré" (Type 4/Code 0) avec le champ Pointeur indiquant le premier octet du champ Segments restants, DEVRAIT être retourné à l'envoyeur.

Si le paquet IPv6 contient un en-tête Fragment, les champs d'en-tête sont réglés comme ci-dessus avec les exceptions suivantes :

Longueur totale : La valeur de la longueur de charge utile d'après l'en-tête IPv6, moins 8 pour l'en-tête Fragment, plus la taille de l'en-tête IPv4.

Identification : Copiée des 16 bits de moindre poids du champ Identification dans l'en-tête de fragment.

Fanions : Le fanion Fragments à venir est copié du fanion M dans l'en-tête Fragment. Le fanion Ne pas fragmenter est mis à zéro pour permettre à ce paquet d'être fragmenté par les routeurs IPv4.

Décalage de fragment : Copié du champ Décalage de fragment dans l'en-tête Fragment.

Protocole : Valeur de Prochain en-tête copiée de l'en-tête Fragment.

4.2   Traduire des en-têtes ICMPv6 en en-têtes ICMPv4

Tous les messages ICMP qui sont à traduire exigent que le champ Somme de contrôle ICMP soit mis à jour au titre de la traduction car ICMPv6, à la différence de ICMPv4, a une somme de contrôle de pseudo en-tête tout comme UDP et TCP.

De plus, tous les paquets ICMP ont besoin d'avoir la valeur de Type traduite, et pour les messages d'erreur ICMP, l'en-tête IP inclus doit aussi être traduit.

Les actions nécessaires pour traduire divers messages ICMPv6 sont :

Messages d'information ICMPv6 :

Demande/Réponse d'écho (Types 128 et 129)

Ajuster le type à 0 et 8, respectivement, et ajuster la somme de contrôle ICMP à la fois pour tenir compte du changement de type et pour exclure le pseudo en-tête ICMPv6.

Interrogation/Rapport/Acquittement MLD d'écouteur de diffusion groupée (Types 130, 131, 132)

Message d'un seul bond. Éliminer en silence.

Message de découverte de voisins (Types 133 à 137)

Message d'un seul bond. Éliminer en silence.

Message d'information inconnus : Éliminer en silence.

Messages d'erreur ICMPv6 :

Destination injoignable (Type 1)

Régler le champ Type à 3. Traduire le champ Code comme suit :

Code 0 (pas de chemin pour la destination) :

Régler Code à 1 (hôte injoignable).

Code 1 (communication avec la destination interdite administrativement) :

Régler Code à 10 (communication avec l'hôte destination interdite administrativement).

Code 2 (au delà de la portée de l'adresse de source) :

Régler Code à 1 (hôte injoignable). Noter que cette erreur est très peu vraisemblable car l'adresse de source traduisible en IPv4 est considérée comme ayant une portée mondiale.

Code 3 (adresse injoignable) :

Régler Code à 1 (hôte injoignable).

Code 4 (accès injoignable) :

Régler Code à 3 (accès injoignable).

Paquet trop gros (Type 2)

Traduire en un message ICMPv4 Destination injoignable avec le code 4. Le champ MTU doit être ajusté de la différence entre les tailles d'en-tête IPv4 et IPv6 en tenant compte de ce que le paquet erroné comporte ou non un en-tête de fragment.

Temps excédé (Type 3)

Régler Type à 11. Le champ Code reste inchangé.

Problème de paramètre (Type 4)

Si le Code est 1, le traduire en un Protocole injoignable ICMPv4 (Type 3, Code 2). Autrement régler Type à 12 et Code à zéro. Le pointeur doit être mis à jour pour pointer sur le champ correspondant dans l'en-tête IP traduit inclus.

Messages d'erreur inconnus : Éliminer en silence.

4.3   Traduire les messages d'erreur ICMPv6 en ICMPv4

Il y a quelques différences entre les formats de message d'erreur ICMP dans IPv4 et IPv6 comme précisé ci-dessus. De plus, les messages d'erreur ICMP contiennent l'en-tête IP pour le paquet erroné qui doit être traduit exactement comme un en-tête IP normal. La traduction de ce "paquet erroné" va vraisemblablement changer la longueur du datagramme, et donc le champ Longueur totale dans l'en-tête IPv4 externe peut devoir être mis à jour.

Traduction d'erreur ICMP d'IPv6 en IPv4

La traduction de l'en-tête IP interne peut être faite en invoquant de façon récurrente la fonction qui a traduit les en-têtes IP externes.

4.4   Savoir quand traduire

Lorsque le traducteur reçoit un paquet IPv6 avec une adresse de destination transposée en IPv4, le paquet sera traduit en IPv4.

5.   Implications pour les nœuds IPv6 seul

Un nœud IPv6 seul qui fonctionne à travers des traducteurs SIIT a besoin de certaines modifications qui vont au delà d'un nœud IOv6 seul normal.

Comme spécifié au paragraphe 1.3, les protocoles d'application ont besoin de traiter l'opération sur un nœud disposant des deux piles de protocoles. De plus, la pile de protocoles doit être capable de :

o   Déterminer quand une adresse traduisible en IPv4 doit être allouée et si l'allocation doit être rafraîchie/renouvelée. Cela peut vraisemblablement être fait sans impliquer les applications, par exemple en traitant cela sous la prise d'API. Par exemple, quand les appels de prise "connect" ou "sendto" sont invoqués, ils pourraient vérifier si la destination est une adresse transposée en IPv4 et dans ce cas allouer/rafraîchir l'adresse traduisible en IPv4.

o   S'assurer, au titre du mécanisme de sélection d'adresse de source, que lorsque l'adresse de destination est une adresse transposée en IPv4, l'adresse de source DOIT être une adresse traduisible en IPv4. Et une adresse traduisible en IPv4 NE DOIT PAS être utilisée avec d'autres formes d'adresses de destination IPv6.

o   Si l'homologue a des enregistrements d'adresse AAAA/A6, l'application (ou le résolveur) NE DEVRAIT PAS se replier sur une recherche d'enregistrements d'adresse A même si la communication échoue en utilisant les enregistrements AAAA/A6 disponibles. La raison de cette restriction est d'empêcher le trafic entre deux nœuds IPv6 (qui enregistrent AAAA/A6 dans le DNS) de passer accidentellement deux fois par des traducteurs SIIT ; de IPv6 à IPv4 puis de nouveau à IPv6. Il est considéré préférable de signaler plutôt une défaillance à communiquer à l'application.

6.   Considérations pour la sécurité

L'utilisation de traducteurs IP/ICMP sans état n'introduit aucune nouvelle menace pour la sécurité au delà des problèmes de sécurité qui sont déjà présents dans les protocoles IPv4 et IPv6 et dans les protocoles d'acheminement qui sont utilisés pour faire que les paquets atteignent le traducteur.

Comme l'en-tête d'authentification (AH, Authentication Header) [RFC2402] est spécifié comme incluant le champ IPv4 Identification et que la fonction de traduction n'est pas toujours capable de préserver le champ Identification, il n'est pas possible à un point d'extrémité IPv6 de calculer AH sur les paquets reçus qui ont été traduits de paquets IPv4. Et donc, AH ne fonctionne pas à travers un traducteur.

Les paquets avec ESP peuvent être traduits car ESP ne dépend pas des champs d'en-tête avant l'en-tête ESP. Noter que ESP en mode transport est plus facile à traiter que ESP en mode tunnel ; afin d'utiliser ESP en mode tunnel, le nœud IPv6 doit être capable de générer un en-tête IP interne lors de la transmission de paquets et de retirer un tel en-tête IPv4 lors de la réception de paquets.

Références

(Les liens sur les numéros de RFC pointent sur le texte anglais, ceux des titres pointent sur la version française)

[RFC0791]   J. Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981.

[RFC0792]   J. Postel, "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", STD 5, septembre 1981.

[RFC1112]   S. Deering, "Extensions d'hôte pour diffusion groupée sur IP", STD 5, août 1989. (MàJ parRFC2236)

[RFC1191]   J. Mogul et S. Deering, "Découverte de la MTU de chemin", novembre 1990.

[RFC1933]   R. Gilligan, E. Nordmark, "Mécanismes de transition pour hôtes et routeurs IPv6", avril 1996. (Obs., voirRFC2893) (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.)

[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, voirRFC3513) (P.S.)

[RFC2401]   S. Kent et R. Atkinson, "Architecture de sécurité pour le protocole Internet", novembre 1998. (Obsolète, voirRFC4301)

[RFC2402]   S. Kent et R. Atkinson, "En-tête d'authentification IP", novembre 1998. (Obsolète, voir RFC4302, 4305)

[RFC2406]   S. Kent et R. Atkinson, "Encapsulation de charge utile de sécurité IP (ESP)", novembre 1998. (Obsolète, voir la RFC4303)

[RFC2428]   M. Allman, S. Ostermann, C. Metz, "Extensions de FTP pour IPv6 et les NAT", septembre 1998. (P.S.)

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

[RFC2463]   A. Conta, S. Deering, "Protocole de message de contrôle Internet (ICMPv6) pour le protocole Internet version 6 (IPv6)", décembre 1998. (Obsolète, voirRFC4443) (D.S.)

[RFC2474]   K. Nichols, S. Blake, F. Baker et D. Black, "Définition du champ Services différenciés (DS Field) dans les en-têtes IPv4 et IPv6", décembre 1998. (MàJ parRFC3168, RFC3260) (P.S.)

[RFC2553]   R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Extensions de base d'interface de prise pour IPv6", mars 1999. (Obsolète, voirRFC3493) (MàJ parRFC3152) (Information)

[RFC2710]   S. Deering, W. Fenner et B. Haberman, "Découverte d'écouteur de diffusion groupée (MLD) pour IPv6", octobre 1999. (MàJ parRFC3590, RFC3810)

[MILLER]   G. Miller, mél à la liste de diffusion ngtrans du 26 mars 1999.

Adresse de l'auteur

Erik Nordmark

Sun Microsystems, Inc.

901 San Antonio Road

Palo Alto, CA 94303

USA

téléphone : +1 650 786 5166

Fax : +1 650 786 5896

mél : nordmark@sun.com

Déclaration complète de droits de reproduction

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

Le présent document et les informations contenues sont fournies 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 ci encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.