IPv6 Cours UREC_1999 | I Pv6 | Adresse IP\nEnregistrerEnregistrer IPv6 Cours UREC_1999 pour plus tard\nA. Représentation des adresses\nB. Les types d'adresses\nC. Les adresses individuelles ou adresses unicast\n1. Exemples d'adresses unicast\n2. Adresse unicast opérateur\n3. Adresses NSAP\n4. Adresse unicast locale\n5. Adresse unspecified\n6. Adresse de bouclage\n7. Les adresses qui encapsulent les adresses IPv4\nD. Adresses cluster\n1. Format des adresses multicast\n2. Adresses multicast pré-définies\nF. Les types d'adresses reconnus par les nœuds\nA. Format d’en-tête IPv6\nB. Les extensions IPv6\n1. Proche en proche\n6. En-tête de confidentialité\nConfiguration automatique et contrôle\nA. Découverte des voisins (RFC 1970)\nB. Configuration automatique\n1. Détection d’adresse double\n2. Création de l’adresse lien-local\n3. Auto-Configuration sans état\n4. Auto-Configuration avec état : DHCPv6\nC. Renumérotation automatique des routeurs\nD. Mécanisme de découverte du PMTU (RFC 1981)\nA. Réseau à diffusion\n1. Ethernet (RFC 1972)\n2. FDDI (RFC 2019)\n4. Anneau à jeton — Token-Ring\nC. Lien point à point, PPP (RFC 2023)\nRéseau IPv6 expérimental\n1. Le réseau 6bone\n2. Le G6bone\nVI. La sécurité [RFC 1752]\nB. Les mécanismes de sécurité dans IPv6\n1. Le mécanisme de l'en-tête d'authentification (Authentication Header)\n2. La technique ESP (Encapsulating Security Payload)\n3. La combinaison des mécanismes de sécurité\nC. La gestion des clés (Key Management)\n1. La distribution d'une clé manuelle\n2. La distribution d'une clé automatique\nD. L'utilisation des mécanismes de sécurité dans IPv6\n1. Les « Firewalls »\n2. La protection de la Qualité de Service (QoS)\n3. Des réseaux compartimentés ou à niveau multiple (Multi-level)\nE. La prise en compte des autres éléments relatifs à la sécurité\nVII. Mobilité dans IPv6\nB. Les formats d'en-tête pour l'option de mobilité\n1. L'option de mobilité pour les données utilisateur\n2. L'option de mobilité pour le contrôle\nC. Le format d'entrée AMT\nD. Les méthodes d'authentification\nE. La connexion à un réseau\n1. Les procédures utilisées sur le nœud mobile\n2. Les procédures utilisées sur un noeud intermédiaire\n3. Les procédures utilisées sur un nœud situé à la frontière (Boundary Node) du réseau\nF. La communication des données\n1. Les procédures appliquées au noeud source\n2. Les procédures appliquées au nœud intermédiaire\n3. Les procédures appliquées au nœud de destination\nL’explosion de l'Internet (dont la taille double environ tous les 12 mois) a deux conséquences :\n- la consommation des adresses s'est fortement accélérée ces dernières années, et l'on commence à parler d'épuisement des adresses IPv4 (la " fin du monde IPv4 " est estimée aux environs de 2010 !)\n- la taille des tables de routage des équipements qui doivent connaître toutes les routes mondiales (full routing) est devenue gigantesque et n'est pas sans poser quelques problèmes aux opérateurs de services IP.\nPour pallier ces difficultés inhérentes à la version actuelle du protocole (IPv4), un nouveau protocole a été spécifié, le protocole IP version 6. Il doit permettre d'adresser un espace beaucoup plus grand et fournir des techniques de routage plus efficaces (en lien avec un adressage hiérarchique).\nLe rôle de l'IETF (Internet Engineering Task Force) a été prépondérant dans le processus d'élaboration des spécifications du nouveau protocole. Il a d'abord fait publier un livre blanc (RFC 1550) pour définir les fonctionnalités du nouvel IP. A l'issue d'un long travail d'analyse et de débats, " les critères techniques pour choisir le nouvel IP " (RFC 1726) ont été publiés. Trois propositions ont été retenues (sur les 21 recueillies), comme proches des critères imposés. Il s'agit de CATNIP (Common Architecture for The Internet Protocol), SIPP (Simple Internet Protocol Plus) et TUBA (TCP and UDP with Bigger Addresses).\nFinalement, SIPP (moyennant un certain nombre de modifications) a été retenu. Le processus aura duré 4ans ! (sans parler de la phase de développement et d'implantation dans les équipements, où nous sommes aujourd'hui\nIpv6 est donc une nouvelle version d'IP qui s'inscrit comme l'évolution naturelle et normale d’IPv4. Il est conçu pour fonctionner aussi bien sur des réseaux à très hauts débits comme ATM que sur des réseaux à faible bande passante tels que les réseaux sans fils.\nLes principales fonctionnalités d'IPv4 sont conservées dans IPv6 excepté certaines fonctions peu ou pas utilisées qui ont été supprimées ou rendues optionnelles. En outre, quelques priorités ainsi que de nouvelles fonctionnalités qui faisaient défaut à son prédécesseur (la\nsécurité, le support du temps réel et du multipoint,\n) ont été ajoutées.\nNous verrons qu’IPv6 possède huit grandes caractéristiques :\n- des possibilités étendues d'adressage et de routage,\n- un format d'en-tête simplifié,\n- des possibilités d'extension des en-têtes et des options,\n- le « Source Routing » ou routage en fonction de l’adresse de la source,\n- le multipoint,\n- l'auto-configuration des équipements,\n- la sécurité (authentification, confidentialité et intégrité),\n- une transition d'IPv4 à IPv6 simple et flexible.\nL'adressage est de la toute première importance dans le réseau Internet. L'intérêt des utilisateurs est de pouvoir se connecter au réseau Internet pour avoir accès à des données ou pour pouvoir se connecter sur n'importe quelle machine.\nLes adresses IPv6 sont des identifiants de 128 bits pour des nœuds ou un ensemble de nœuds. La taille d’une adresse IPv6 est donc le quadruple de celle d’une adresse IPv4. En prenant en compte les estimations les plus pessimistes et les plus optimistes, on obtient l’encadrement suivant où l’unité est le nombre d’adresses par m 2 de surface terrestre (océans compris) :\nnombre d’adresses disponibles\nCe calcul est bien entendu complètement arbitraire. Il est difficile de prévoir l’utilisation des adresses dans les années futures. Ainsi, par exemple, le plan d’adressage actuellement mis en œuvre utilise un identifiant d’équipement sur 64 bits. En fait ce genre de calcul sert de justification aux partisans des adresses de taille fixe (ce qui simplifie le traitement des paquets) en montrant que le nombre d’équipements adressables est colossal.\nOn peut distinguer trois types d'adresses:\n- Unicast : employé pour envoyer un datagramme à un unique nœud.\n- Cluster : employé pour identifier un groupe de nœuds qui ont en commun un préfixe d'adresse. Un datagramme envoyé à une adresse cluster sera délivré à un membre du groupe.\n- Multicast : employé pour envoyer un datagramme à tous les membres d'un groupe de nœuds.\nIl n'y a pas d'adresses de broadcast dans la version d'IPv6, les adresses multicast assurent leurs fonctions. Comme dans IPv4, un sous-réseau IPv6 est associé à une seule liaison. Mais Ipv6 permet aussi d'associer plusieurs sous-réseaux à une même liaison. Dans la suite de notre rapport, les champs des adresses ont des noms particuliers, prenons l'exemple de "subscriber". Lorsqu'il est utilisé avec le terme "ID" pour identifieur, après le nom ("subscriber ID"), on se réfère au contenu du champ nommé. Alors que s'il est utilisé avec "prefix" ("subscriber prefix"), le terme se rapporte à tous les bits de poids fort de l'adresse en incluant ce champ.\nIl y a trois formes conventionnelles de représentation d'adresses Ipv6 :\n1- La forme la plus appréciée est x:x:x:x:x:x:x:x, où les 'x' sont les valeurs hexadécimales des huit blocs de 2 octets chacun.\nOn remarquera qu'il n'est pas nécessaire d'écrire tous les zéros devant un chiffre hexadécimal dans un champ individuel, mais il doit y avoir au moins un chiffre dans chaque champ.\n2- La méthode d'allocation des adresses IPv6 montre qu'il est commode de "mettre" des bits à 0 dans le milieu des adresses. Pour avoir une écriture facilitée, une syntaxe adéquate sera de supprimer les zéros. L'expression de deux "::" indiquera un ou de multiple groupes de 16 bits à 0.\nPar exemple l'adresse multicast suivante :\nsera représentée de la manière suivante :\nles "::" ne peuvent apparaître qu'une seule fois dans l'adresse.\n3- Une autre forme alternative est quelquefois plus commode lorsque l'on est dans un environnement mixte de nœuds IPv6 et IPv4. Elle est x:x:x:x:x:x:d.d.d.d, où les 'x' sont des valeurs hexadécimales (6 groupements de 16 bits) et les 'd' des valeurs décimales (4 groupements de 8 bits de la représentation standard d'IPv4).\nou dans le format compressé :\nB. Les types d’adresses\nLes types d'adresses d'Ipv6 sont décrites par les bits de poids fort de l'adresse. Nous appelons ce champ de longueur variable le préfixe du format (Format Prefix - FP). Donnons l'attribution des adresses suivant le préfixe :\nAdresse Unicast définie par fournisseur de service\nRéservé pour les adresses géographiques\nPour les nœuds utilisant le protocole IPv4, les adresses unicast IPv6 ont pour préfixe 0000\nCette allocation supporte l'allocation directe des adresses fournisseurs (provider), adresses NSAP [NSAP-USE], adresses IPX, adresses d'usage local, et les adresses multicast. De l'espace est réservé pour les adresses géographiques. Les espaces adresses "Réservé" (85% du total adressable) seront attribués pour de futures utilisations. Elles pourront être utilisées pour étendre les adresses existantes (e.g. adresses de fournisseurs supplémentaires, adresses IPX, etc.) ou pour de nouveaux emplois.\nOn distingue les adresses unicast des adresses multicast par la valeur des octets de poids fort de ces adresses. Une valeur de FF (1111 1111) identifie une adresse multicast, toutes les autres sont des adresses unicast.\nL'adresse unicast d'IPv6 est basée sur le même principe de l'adresse de la version 4 d'IP sous le protocole de routage Internet sans classes (Classless Internet Domain Routing, CIDR). C'est-à-dire que les adresses sont allouées de manière contiguë et ont en commun les mêmes bits de poids fort, les mêmes préfixes.\nIl existe plusieurs formes d'adresse unicast dans Ipv6 : adresse unicast hiérarchique opérateur, adresse hiérarchique géographique, adresse hiérarchique NSAP, adresse hiérarchique IPX, adresse locale, et adresse unique de station. Les nœuds peuvent avoir une connaissance plus ou moins étendue de la structure interne des adresses Ipv6, cela dépend du rôle "joué" par le nœud. Par exemple les fonctions d'une station sont différentes de celles d'un routeur. Au minimum, un nœud peut "voir" les adresses unicast (y compris la sienne) sans structure interne :\nUne station légèrement plus perfectionnée (mais restant encore assez simple) peut avoir connaissance du ou des préfixes de sous-réseaux et donc des liaisons qui leur sont attachés. La valeur de n est variable suivant les adresses:\nBien qu'un très simple routeur puisse n'avoir aucune connaissance de la structure interne des adresses unicast IPv6, les routeurs devront généralement avoir connaissance d'un ou de quelques niveaux hiérarchiques pour les protocoles de routage. La connaissance des domaines différera de chaque routeur, celle-ci dépendra des positions hiérarchiques des routeurs.\n1. Exemples d’adresses unicast\nVoici un exemple de format d'adresse unicast qui sera probablement commun à tous les LAN et autres environnements dont les adresses MAC IEEE-802 sont disponibles :\nLes 48 bits du Node ID représentent l'adresse MAC. Dans d'autres environnements, où les adresses IEEE-802 ne sont pas disponibles, d'autres adresses de la couche liaison peuvent être utilisées, comme les adresses E.164. L'utilisation d'un unique node identifier, comme nous l'avons vu précédemment, rend possible et de manière assez simple l'auto configuration des adresses. Un nœud peut ainsi relever le subnet ID en "écoutant" les messages "Advertisement" du routeur auquel il est rattaché, et donc fabriquer sa propre adresse IPv6 en y ajoutant son adresse IEEE MAC comme node ID dans ce sous-réseau. Les détails d'auto configuration de station seront vus dans le chapitre suivant. Un autre exemple de format d'adresse unicast est donné pour un site ou une organisation qui a besoin de couches supplémentaires de hiérarchie. Son format est :\nIci, la zone (area) et le sous-réseau (subnet) définissent N niveaux hiérarchiques locaux, permettant d'utiliser le style de masquage de CIDR.\n125-n-m bits -p\nLa partie haute de l'adresse est attribuée aux opérateurs (fournisseurs), qui attribuent des portions d'espace d'adresse aux souscripteurs (subscribers). Le terme "préfixe opérateur" fait référence à la partie haute de l'adresse, provider ID compris. On est alors dans le même schéma que les adresses IP sous le protocole CIDR.\nLe subscriber ID permet de distinguer un souscripteur (ou abonné) parmi d'autres attachés au même fournisseur repéré par le provider ID. Le terme de "préfixe du souscripteur" fait référence à la partie haute de l'adresse, subscriber compris. Le subnet ID identifie une liaison physique spécifique. Il peut y avoir plusieurs sous-réseaux rattachés à la même liaison physique. Tandis qu'un sous-réseau ne peut pas être raccordé à de multiples liaisons physiques. Le terme de "préfixe sous-réseau" se rapporte à la partie haute de l'adresse, subnet ID compris. Le groupe de nœuds identifiés par un subnet ID doivent être attachés à la même liaison. Le node ID identifie un unique nœud parmi le groupe de nœuds déterminé par un préfixe de sous-réseau.\nL'adresse NSAP a pour format dans la nouvelle version IP,\nLa nouvelle version d'IP "supporte" les adresses NSAP (Network Service Access Point) d'une manière transparente (sans conversion) et celles-ci sont totalement compatibles avec l'en-tête étendu de noeud-par-noeud. Ipv6 est totalement "compatible" avec le plan d'adressage NSAP existant qui a été défini par l'ISO et ITU-T, incluant des adresses utilisant la longueur totale maximale de 20 octets. Ceci est principalement adressé aux personnes qui ont déjà planifié ou déployé un plan d'adressage NSAP pour l'usage "du protocole réseau sans connexion" (Connectionless Network Protocol - CLNP) selon le plan d'adressage de la couche réseau OSI. On trouvera dans la draft "OSI NSA usage in IPv6" les recommandations pour continuer à dresser le plan d'adressage NSAP coexistant avec IPv6 et faire la transition pour IPv6.\nLes adresses "d'emploi local" sont des adresses utilisées à l'intérieur d'un site d'un souscripteur donné. Elles sont formatées de la manière suivante :\nLes adresses locales sont employées pour des sites ou des organisations qui ne sont pas (encore) connectés au monde Internet. Pour accéder à ce dernier, il n'est pas besoin d'en faire la demande ou de "voler" un préfixe d'adresse depuis le monde Internet. L'adresse locale suffit, lorsque l'organisation veut se connecter au monde Internet, elle forme ses adresses globales en remplaçant le préfixe local par un préfixe souscripteur.\nL’adresse 0:0:0:0:0:0:0:0 est appelée adresse unspecified. Elle ne doit être affectée à aucun nœud. Elle indique l'absence d'adresse. Par exemple, on peut la trouver dans le champ d'une adresse source de n'importe quels datagrammes envoyés par une station "initialisée" avant que cette dernière n'est réussie à constituer sa propre adresse. L'adresse unspecified ne doit pas être employée comme adresse destination des datagrammes ou dans les en-têtes de routage d'IPv6.\nL'adresse unicast FE00:0:0:0:0:0:0:1 est appelée adresse de bouclage. Elle est utilisée par un nœud pour envoyer un datagramme à lui-même. Elle n'est affectée à aucune interface. L'adresse de bouclage ne doit pas être utilisée comme adresse source de datagrammes envoyés à l'extérieur du nœud.\nLa transition simple à IPv6 (Simple IPv6 Transition - SIT) utilise deux formes d'adresses unicast IPv6, conçus spécialement pour faciliter l'évolution de l'Internet passant d'IPv4 à IPv6. Dans les deux cas, l'adresse IPv4 est inclue dans la partie basse de l'adresse Ipv6 (32 derniers bits). La première forme d'adresse est conçue pour représenter les adresses IPv4 des nœuds IPv4 (les nœuds ne peuvent pas comprendre le protocole IPv6) en adresses Ipv6. Elle est de la forme suivante :\nLa seconde forme d'adresse est conçue pour être utilisée par les nœuds IPv6 qui ont besoin de "dialoguer" avec des nœuds IPv4. On dira que ces adresses IPv4 sont compatibles IPv6.\nLes adresses cluster sont des adresses unicast, employées pour atteindre le "plus proche" nœud (selon une notion de routage unicast du plus proche nœud) d'un ensemble de routeurs "frontières" d'un groupe de nœuds, ces derniers étant identifiés par un préfixe commun. Un routeur frontière d'un groupe C possède au moins une adresse avec le préfixe C et au moins une liaison avec un autre nœud de préfixe différent de C. Les adresses cluster sont de la forme générale :\nPar exemple, pour atteindre le plus proche routeur frontière pour le domaine de routage défini par un opérateur D, un datagramme doit être envoyé avec l'adresse cluster :\nProvider = D\nPour atteindre le routeur frontière de souscripteur S d'un opérateur D, un datagramme doit être émis de la façon suivante,\nSubscriber = S\nDe même, pour atteindre le routeur frontière de sous-réseau T d'un souscripteur S, d'un opérateur D, un datagramme doit être émis de la façon suivante,\nSubnet = T\nles groupes de routeurs frontières ont besoin de savoir, d'une part qu'ils sont des routeurs de frontière et d'autre part "accepter" les datagrammes adressés à l'adresse cluster correspondante comme s'ils leur étaient destinés. Les adresses cluster sont plus communément utilisées comme des adresses intermédiaires dans l'en-tête IPv6 de routage. Ceci afin de router un datagramme à un ou plusieurs "clusters" en chemin jusqu'à la destination finale. La valeur 0 est réservée à chaque niveau hiérarchique de l'adresse unicast pour former des adresses cluster. Les adresses cluster ne doivent pas être utilisées comme adresses sources dans le datagramme\nUne adresse multicast (de diffusion de groupe) IPv6 est un identifiant pour un groupe de nœuds. Un nœud peut appartenir à n'importe quel nombre de groupes multicast. Son format est le suivant :\nles 1111 1111 du début de l'adresse caractérise l'adresse comme une adresse multicast.\nLes drapeaux (flags) sont au nombre de 4 :\nLes trois bits de poids fort sont réservés, et doivent être positionnés à 0.\nT=0 indique que l'adresse est multicast de façon permanente, allouée par l'autorité d'adressage de l'Internet.\nT=1 indique que l'adresse est une adresse multicast provisoirement (de transition).\nscope est une valeur de 4 bits, de portée du champ multicast. Elle est utilisée pour limitée l'étendue du groupe multicast. Les valeurs sont les suivantes :\n8 intra-organization scope\nB intra-community scope\ngroup ID identifie le groupe multicast, qu'il soit permanent ou provisoire, à l'intérieur du domaine donné.\nDonnons un exemple. Si le groupe de serveurs est assigné à une adresse permanente multicast avec un groupe ID de 43 en hexadécimal, alors :\nFF01:0:0:0:0:0:0:43 signifie tous les serveurs NTP du même nœud que l'émetteur.\nFF05:0:0:0:0:0:0:43 signifie tous les serveurs NTP du même site que l'émetteur.\nFF0E:0:0:0:0:0:0:43 signifie tous les serveurs NTP du monde Internet.\nLes adresses multicast provisoires ne sont significatives qu'à l'intérieur d'un domaine donné. Par exemple, un groupe identifié par une adresse multicast intra-site provisoire, FF15:0:0:0:0:0:0:43 d'un site donné, n'a aucun rapport avec un groupe utilisant la même adresse sur un site différent, ou un groupe provisoire utilisant le même group ID mais une valeur de scope différente, ou qu'un groupe permanent avec le même groupe ID.\nReserved Multicast Address: FF0s:0:0:0:0:0:0:0. Ces adresses multicast (avec une valeur de scope, s) sont réservées, et ne devront être assignées à aucun groupe multicast.\nAll Nodes Adresses:\nCes adresses multicast identifient le groupe de tous les nœuds IPv6, à l'intérieur d'une étendue intra-nœud (scope=1) ou intra-liaison (scope=2).\nAll Hosts Adresses:\nCes adresses multicast identifient le groupe de toutes les stations IPv6, à l'intérieur d'une étendue intra-nœud (scope=1) ou intra-liaison (scope=2).\nAll Routers Adresses:\nCes adresses multicast identifient le groupe de tous les routeurs IPv6, à l'intérieur d'une étendue intra-nœud (scope=1) ou intra-liaison (scope=2).\n* Adresses unicast allouées.\n* Adresse de bouclage.\n* Adresse multicast All Nodes.\n* Adresse multicast All Hosts\n* Toutes les autres adresses multicast auxquelles la station appartient.\nPour un routeur:\n* Adresses cluster de tous les groupements qui considèrent le routeur comme un routeur frontière.\n* Toutes les autres adresses multicast auxquelles le routeur appartient.\nII. Protocole réseau\nHormis la modification de la taille des adresses, ce qui conduit à une taille d’en-tête de 40 octets (le double de l’en-tête IPv4 sans les options), le protocole IP a subi un toilettage reprenant l’expérience acquise au fil des ans avec IPv4. Le format des entêtes IPv6 est simplifié et permet aux routeurs de meilleures performances dans leurs traitements :\n— L’en-tête ne contient plus de champ checksum qui devait être ajusté par chaque routeur en\nraison de la décrémentation du champ durée de vie. Par contre, pour éviter qu’un paquet dont le contenu est erroné, en particulier sur l’adresse de destination, ne se glisse dans une autre communication, tous les protocoles de niveau supérieur doivent mettre en oeuvre un mécanisme de checksum de bout en bout incluant le pseudo-en-tête. Le checksum d’UDP facultatif pour IPv4, devient ainsi obligatoire. Pour ICMPv6, le checksum intègre le pseudo- en-tête, alors que pour ICMPv4, il ne portait que sur le message ICMP.\n— La taille des en-têtes est fixe. Le routeur peut facilement déterminer où commence la zone de données utiles.\n— Les options ont été retirées de l’en-tête et remplacées par de nouveaux en-têtes appelés extensions qui peuvent être facilement ignorées par les routeurs intermédiaires.\n— Les champs sont alignés sur des mots de 64 bits, ce qui optimise leur traitement surtout avec les nouvelles architectures à 64 bits.\n— La taille minimale des MTU Maximum Transmission Unit est de 576 octets 1 . Il est question d’augmenter la taille minimale des MTU à 1280 octets.\n— La fonction de fragmentation a été retirée des routeurs. Les champs qui s’y reportent\n(identification, drapeau, place du fragment) ont été supprimés. Normalement les algorithmes\nde découverte du PMTU Path MTU évitent d’avoir recours à la fragmentation. Si celle-ci s’avère nécessaire, une extension est prévue.\n— Le champ type de service (ToS : Type of Service) des datagrammes IPv4 a été supprimé au\nprofit d’un champ classe. La fonction de ce champ dans le data-gramme IPv4 a été réaffectée par le RFC 1349. Il est utilisé par l’émetteur pour indiquer si le routage doit favoriser le délai,\nle débit, la fiabilité ou le coût. Mais il n’a jamais été exploité à grande échelle. Il peut conduire à des boucles de routage et implique la nécessité de construire un plan de routage par type de service. Le champ type de service n’est plus présent dans la version actuelle d’IPv6. Un champ classe a été défini, mais son utilisation à grande échelle pose autant de problèmes. Des propositions de réaffectation de ce champ sont discutées dans le groupe de travail intserv.\nLe format d’en-tête d’un paquet IPv6 est donné par le RFC 1883 (cf. schéma ci-dessous). Si le format du paquet est universellement admis, l’affectation de certains champs indiqués dans le\n1 En IPv4 le MTU minimal est de 68 octets, 576 octets est la taille minimale garantie pour un paquet IPv4. Le choix de 576 comme MTU minimal en IPv6 a été fait pour des raisons de compatibilité avec certains supports de transmission.\nnb de sauts\nVersion : le champ version est le seul champ qui occupe la même place dans le paquet IPv6 et dans le paquet IPv4. Sa valeur est 6.\nPriorité ou classe : le premier mot de 32 bits étant exclu du calcul du checksum avec les pseudo-en-tête, il est plus facile de le faire évoluer. La version actuelle du standard IPv6 définit un champ priorité sur 4 bits suivi d’un champ d’identificateur de flux sur 24 bits. Dans de nouvelles propositions, en cours d’étude, le champ priorité est remplacé par un champ classe étendu de 4 bits pris sur l’identificateur de flux. Ceci pour permettre aux équipes de recherche de tester des nouvelles fonctionnalités comme la gestion de flux multimédias ou la différenciation de services.\n- Priorité : les valeurs comprises entre 0 et 7 sont allouées aux trafics mettant en oeuvre un contrôle de flux, c’est-à-dire, principalement, utilisant le protocole TCP ; les valeurs supérieures à 7 sont réservées pour des trafics supportant des pertes mais ayant de fortes contraintes temporelles comme les données multimédias.\n- Classe : Le champ classe est un champ expérimental qui permet à une source de caractériser son trafic. Il peut être pris en compte par les routeurs intermédiaires. Pour le récepteur, le champ classe n’a aucune signification.\nCe champ est divisé en trois parties :\n• Un bit D sert à marquer (bit à 1) un trafic interactif pour lequel la contrainte en délai est plus importante que la contrainte en débit. Ce bit correspond au bit du champ ToS d’IPv4 minimisant le délai.\n• Les 3 bits suivants du champ classe servent à une source de trafic pour indiquer la priorité de remise de ces paquets. La priorité est relative aux autres paquets émis par la source et est définie par des valeurs comprises entre 0 et 7.\n• Les quatre bits restants (ceux pris sur le champ identificateur de flux) ne sont actuellement pas définis. Ils pourront être utilisés à des fins expérimentales.\nIdentificateur de flux : ce champ contient un numéro unique choisi par la source qui a pour but de faciliter le travail des routeurs et la mise en œuvre des fonctions de qualité de service. Cet indicateur peut être considéré comme une marque à un contexte dans le routeur. Le routeur peut alors faire un traitement particulier : choix d’une route, traitement en « temps- réel » de l’information.\nLongueur des données utiles (payload) : contrairement à IPv4, ce champ, sur deux octets, ne contient que la taille des données utiles, sans prendre en compte la longueur de l’en-tête. Pour des paquets dont la taille des données serait supérieure à 65536 ce champ vaut 0 et l’option jumbogramme de l’extension de « proche-en-proche » est utilisée.\nEn-tête suivant : ce champ a une fonction similaire au champ protocole du paquet IPv4. Il identifie le prochain en-tête. Il peut s’agir d’un protocole (de niveau supérieur ICMP, UDP, TCP…) ou de la désignation d’extensions. Les extensions contiennent aussi ce champ pour permettre un chaînage.\nNombre de sauts : il est décrémenté à chaque nœud traversé. Un datagramme retransmis par un routeur est rejeté avec l’émission d’un message d’erreur ICMPv6 vers la source si la valeur après décrémentation atteint 0. Dans IPv4 ce champ est appelé durée de vie (ou TTL Time To Live). Sa vocation initiale est d’indiquer, en secondes, la durée maximale durant laquelle un paquet peut rester dans le réseau. En pratique, les paquets ne restent que quelques millisecondes dans les routeurs, et donc la décrémentation est arrondie à 1. Par contre, pour une liaison plus lente la décrémentation de ce champ peut être supérieure à 1. Dans IPv6, comme il s’agit d’un nombre de sauts, la décrémentation est toujours de 1. La valeur n’est pas encore officiellement attribuée, mais certaines implantations prennent actuellement la valeur 64. La valeur par défaut peut être dynamiquement attribuée aux équipements du réseau, une modification de ce paramètre sera donc relativement simple quand la limite actuelle sera atteinte. On peut noter une limitation, puisque ce champ codé sur 8 bits n’autorise la traversée que de 255 routeurs. En réalité, dans l’Internet actuel, le nombre maximal de routeurs traversés est d’une quarantaine, ce qui laisse une bonne marge pour l’évolution du réseau.\nAdresse de la source : (128 bits) champ adresse de l'émetteur du datagramme.\nAdresse de la destination : (128 bits) champ adresse du destinataire du paquet. Il est possible que l'adresse ne soit pas celle du destinataire final si une option de routage est présente.\nLes paquets IPv6 suivants ont été capturés au cours d’une connexion FTP :\nLe paquet commence par 6 qui indique la version du protocole. Le second 6 donne la classe réservée au trafic de commande FTP (un trafic de données aurait la priorité 4) 2 . L’identificateur de flot n’a pas été défini par la source 00 00 00. La longueur du paquet est de 0x0028 octets. Le paquet ne contient pas d’extension puisque la valeur de l’entête suivant, 0x06, correspond au protocole de niveau 4 TCP. Le nombre maximal de routeurs que le paquet pourra traverser est de 64 (0x40). Les adresses source et destination sont des adresses de test appartenant au plan d’adressage fournisseur.\nLes extensions d’IPv6 peuvent être vues comme un prolongement de l’encapsulation d’IP dans IP. Ces informations complémentaires sont codées dans des en-têtes qui doivent être placés entre l'en-tête IPv6 et l'en-tête de la couche transport.\nUne extension a une longueur multiple de 8 octets. Elle commence par un champ en-tête suivant (Next Header) d’un octet qui définit le type de données qui suit l’extension : une autre extension ou un protocole de niveau 4. Pour les extensions à longueur variable, l’octet suivant contient la longueur de l’extension en mots de 8 octets, le premier n’étant pas compté (une extension de 16 octets a un champ longueur de 1).\nComme illustré dans les exemples suivants, un paquet IPv6 peut comporter aucun, un ou plusieurs en-têtes supplémentaires,\n2 Il s’agit de la notation définie dans le RFC 1883.\nÀ part l’extension de proche en proche traitée par tous les routeurs intermédiaires, les autres extensions ne sont prises en compte que par les équipements destinataires du paquet. Lorsqu'il y a plus d'un en-tête supplémentaire utilisé dans le même paquet, le RFC 1883 recommande l’ordre suivant :\n- Proche en proche (doit toujours être en première position)\n- Destination (sera aussi traité par les routeurs listés dans l’extension de routage par la source)\n- Routage par la source (type 0)\n- Destination (traité uniquement par l’équipement terminal)\nChaque type d'en-tête ne doit apparaître qu'une seule fois dans le paquet (excepter dans le cas d'une encapsulation IPv6 dans IPv6, où chaque en-tête IPv6 encapsulé doit être suivi par son propre en-tête supplémentaire).\nCette extension (en anglais : hop-by-hop) se situe toujours en première position et est traitée par tous les routeurs que le paquet traverse. Le type associé (contenu dans le champ d’en-tête en-tête suivant de l’en-tête précédent) est 0 et le champ longueur de l’extension contient le nombre de mots de 64 bits moins 1.\nL’extension est composée d’options. Pour l’instant, seules quatre options, dont deux de bourrage, sont définies. Chaque option est une suite d’octets. Le premier octet est un type, le deuxième (sauf pour l’option 0) contient la longueur de l’option moins 2. Les deux premiers bits de poids fort du type définissent le comportement du routeur quand il rencontre une option inconnue :\nle routeur ignore l’option ;\nle routeur rejette le paquet ;\nle routeur rejette le paquet et retourne un message ICMPv6 d’inaccessibilité;\nle routeur rejette le paquet et retourne un message ICMPv6 d’inaccessibilité si l’adresse de destination n’est pas multicast.\nLes quatre options de proche en proche sont :\n— Pad1 (type 0). Cette option est utilisée pour introduire un octet de bourrage ;\n— Padn (type 1). Cette option est utilisée pour introduire plus de 2 octets de bourrage. Le\nchamp longueur indique le nombre d’octets qui suivent. Les options de bourrage peuvent sembler inutiles avec IPv6 puisqu’un champ longueur pourrait en donner la longueur exacte. En fait les options de bourrage servent à optimiser le traitement des paquets en alignant les champs sur des mots de 32, voire 64 bits.\n— Jumbogramme (type 194 ou 0xc2). Cette option est utilisée quand le champ longueur des\ndonnées du paquet IPv6 n’est pas suffisant pour coder la taille du paquet. Cette option est essentiellement prévue pour la transmission à grand débit entre deux équipements. Si l’option jumbogramme est utilisée, le champ longueur des données utiles dans l’en-tête IPv6 vaut 0.\n— L’option Router Alert a aussi été définie récemment dans IPv4 (RFC 2113). L’émetteur\nenvoie les données à la destination, mais s’il précise l’option Router Alert, les routeurs intermédiaires vont analyser les données, voire modifier leur contenu avant de relayer le paquet. Ce mécanisme est efficace puisque les routeurs n’ont pas à analyser le contenu de tous les paquets d’un flux.\nLe type de l’option n’est pas encore attribuée, mais il devra commencer par la séquence binaire , puisqu’un routeur qui ne connaît pas cette option doit relayer le paquet sans le modifier. Le champ valeur de l’option contient :\n0 : pour les messages ICMPv6 de gestion des groupes multicast ;\n1 : pour les messages RSVP ; les autres valeurs sont réservées.\nCette extension, dont le format est identique à l’extension de proche en proche, contient des options qui sont traitées par l’équipement destinataire. Pour l’instant, à part les options de bourrage (voir Pad1 et Padn, page précédente) et de mobilité, aucune autre option n’est définie.\nCette extension permet d’imposer à un paquet une route différente de celle offerte par les politiques de routage présentes sur le réseau. Pour l’instant seul le routage par la source (type = 0), similaire aux options Strict Source Routing et Loose Source Routing d’IPv4, est défini.\nLe routage peut être strict (le routeur suivant présent dans la liste doit être un voisin directement accessible) 3 ou libéral (loose) (un routeur peut utiliser les tables de routage pour joindre le routeur suivant servant de relais).\nLe principe du routage par la source ou Source Routing pour IPv6 est le même que pour IPv4. L’émetteur met dans le champ destination du paquet IPv6, l’adresse du premier routeur servant de relais, l’extension contient la suite de la liste des autres routeurs relais et le destinataire. Quand un routeur reçoit un paquet qui lui est adressé comportant une extension de routage par la source, il permute son adresse avec l’adresse du prochain routeur et réémet le paquet vers cette adresse suivante.\nLe schéma suivant donne le format de l’extension de routage par la source :\nadresse du routeur 1\nadresse du routeur n\nLongueur de l’en-tête : ce champ indique le nombre de mots de 64 bits qui composent l’extension. Pour l’extension de type 0, cela correspond au nombre d’adresses présentes dans la liste, multiplié par 2.\nType de routage : ce champ indique la nature du routage. Pour l’instant, seul le routage par la source, de type 0 est spécifié. La suite de l’en-tête correspond à ce type.\nSegments restants : le nombre de segments restants est décrémenté après la traversée d’un routeur. Il indique le nombre d’équipements qui doivent encore être traversés. Il permet de trouver l’adresse qui devra être substituée. Pour le type 0, la valeur maximale est de 23.\nBitmap strict/loose : les 24 bits de la bitmap indiquent (de la gauche vers la droite), pour chaque équipement de la liste, s’il s’agit d’un routage strict (valeur à 1) ou libéral (valeur à 0).\n3 Cette possibilité est controversée et devrait disparaître à court terme.\nAdresse du routeur : la liste comprenant les routeurs à traverser et le destinataire est fournie. Ces adresses ne peuvent pas être multicast.\nL'en-tête de fragmentation est utilisé par la source pour envoyer des paquets plus grands que ne peut acheminer le réseau à leurs destinataires. A la différence d'IPv4, la fragmentation est exécutée seulement par les nœuds source et non plus par les routeurs qui acheminent les paquets le long du chemin. L'en-tête de fragmentation est repéré par une valeur de En-tête suivant égale à 44 juste après le précédent en-tête. Le format est le suivant :\nLa signification des champs est identique à celle d’IPv4 :\nPlace du fragment : ce champ indique lors du réassemblage où les données doivent être insérées. Ceci permet de parer les problèmes dus au déséquencement dans les réseaux orientés datagrammes. Comme ce champ est sur 13 bits, la taille de tous les segments, sauf du dernier, doit être multiple de 8 octets.\nLe bit M s’il vaut 1 indique qu’il y aura d’autres fragments émis.\nRemarque : le bit DF (don’t fragment) d’IPv4 n’est plus nécessaire puisque, si l’extension n’est pas présente, il y aura rejet du paquet par le routeur.\nDans IPv4, la valeur d’une option était codée de manière à indiquer au routeur effectuant la fragmentation, si elle devait être copiée dans les fragments. Dans IPv6, l’en-tête et les extensions qui concernent les routeurs intermédiaires (pour l’instant proche en proche, routage par la source) sont recopiées dans chaque fragment.\nL'en-tête d'authentification est utilisé pour authentifier et assurer l'intégrité des paquets. La non-répudiation est obtenue par un algorithme d'authentification exécuté sur l'en-tête d'authentification. Mais elle n'est pas obtenue par tous les algorithmes d'authentification exécutés sur cet en-tête. L'en-tête d'authentification est déterminé par la valeur 51 du champ En-tête suivant, et a le format suivant :\nindice des paramètres de sécurité\ndonnées d’authentification (nombre variable de mots de 32 bits)\nEn-tête suivant (8 bits) : identifie le type d'en-tête suivant immédiatement l'en-tête d'authentification. Les valeurs sont identiques à celles du champ de protocole de IPv4.\nLongueur extension (8 bits) : c'est la longueur du champ de données d’authentification, multiple de 8 octets.\nRéservé (16 bits ) : initialisé à 0 à l'émission, ignoré à la réception.\nIndice des paramètres de sécurité : Security Association ID (SAID - 32 bits) ; lorsqu'il est combiné avec l'adresse source, il identifie au(x) destinataire(s) le type de sécurité établi, associé aux paquets concernés.\nDonnées d’authentification (longueur variable) : information sur l'algorithme spécifique nécessaire à authentifier la source du paquet et à assurer son intégrité conformément à la sécurité associée. La longueur de ce champ est variable et est un multiple de 8 octets.\nL’en-tête privé cherche à donner une confidentialité et une intégrité en cryptant les données à protéger et en les plaçant dans la section « données » de l’en-tête de confidentialité (Privacy Header). Suivant les exigences de sécurité de l'utilisateur, soit la trame de couche transport (e.g. UDP ou TCP) est cryptée, soit le datagramme entier d'IPv6 l'est. Cette approche par encapsulation est nécessaire pour assurer une confidentialité du datagramme complet original. S'il est présent, l'en-tête de confidentialité est toujours le dernier champ non-crypté dans un paquet.\nL'en-tête de confidentialité travaille entre stations, entre une station et un gateway (passerelle) de sécurité, ou entre des gateways de sécurité. Ceci permet sans d'importants coûts financiers et de performance d'assurer un réseau digne de confiance en transitant du trafic sécurisé sur des segments du réseau qui ne le sont pas.\ndonnées de synchronisation (longueur variable)\ndonnées protégées (longueur variable)\nIndice des paramètres de sécurité (SAID - 32 bits) : identifie le type de sécurité au datagramme. Si aucune association de sécurité n'a été établie, la valeur de ce champ est 0x0000. Une association de sécurité est unilatérale. Une communication sécurisée entre deux stations doit avoir normalement deux SAID (un pour chaque sens des échanges). La station destinataire utilise la combinaison de la valeur du SAID et de l'adresse origine pour distinguer la correcte association.\nDonnées de synchronisation (longueur dépendant du SAID) : ce champ est optionnel et sa valeur dépend du SAID utilisé. Par exemple, le champ peut contenir des données de synchronisation de cryptographie pour un algorithme de codage. Il peut aussi contenir un vecteur d'initialisation cryptographique. L'implantation d'un en-tête de confidentialité utilisera une valeur de SAID pour déterminer si le champ n'est pas vide, et si c'est le cas, évalue la longueur du champ et l'utilise.\nEn-tête suivant (8 bits), crypté : identifie le type d'en-tête suivant immédiatement l'en-tête de confidentialité. Les valeurs sont identiques à celles du champ de protocole de IPv4.\nRéservé (17 bits), crypté : ignoré à la réception.\nLongueur (8 bits), crypté : longueur de l'en-tête privé, à l'exclusion des 8 premiers octets, donnée en un multiple de 8 octets.\nDonnées protégées (longueur variable), crypté : ce champ peut contenir un datagramme complet encapsulé IPv6, une séquence d'option(s) IPv6 ou pas, et enfin le paquet de la couche transport. Ou bien, il est constitué du paquet de la couche transport précédé ou pas d'une série d'option(s).\nAlgorithme-dependant Trailer (trailer - longueur variable suivant SAID), crypté : ce champ est utilisé pour faire du bourrage (nécessité de certains algorithmes) ou pour enregistrer des données d'authentification à utiliser avec un algorithme de cryptographie qui fournit la confidentialité sans l'authentification. Ce champ n'est présent que si l'algorithme utilisé le nécessite.\nIII. Configuration automatique et contrôle\nLe protocole de découverte des voisins (neighbor discovery) permet à un équipement de s’intégrer dans l’environnement local, c’est-à-dire le lien sur lequel sont physiquement transmis les paquets IPv6. Il permet de dialoguer avec les équipements connectés au même support (stations et routeurs).\nLe champ nombre de sauts de l’en-tête IPv6 contient la valeur 255 — il peut sembler paradoxal d’utiliser une valeur aussi grande pour des datagrammes qui ne doivent pas être routés hors du lien physique ; en fait si un équipement reçoit un datagramme avec une valeur plus petite, cela signifie que l’information provient d’un autre réseau et que le datagramme doit être rejeté.\nLe champ priorité vaut 15 4 .\nLe protocole réalise les différentes fonctions suivantes :\n— Résolution d’adresses. Comme pour IPv4, ce protocole construit des tables de mise en correspondance entre les adresses IPv6 et physiques.\n— Détection d’inaccessibilité des voisins ou NUD (Neighbor Unreachability Detection).\nCette fonction n’existe pas en IPv4. Elle permet d’effacer des tables de configuration d’un\néquipement les voisins qui sont devenus inaccessibles (panne, changement d’adresse,\nun routeur devient inaccessible la table de routage peut être modifiée pour prendre en compte une autre route.\n— Configuration. La configuration automatique des équipements est l’un des attraits\nprincipaux d’IPv6. Plusieurs fonctionnalités du protocole de découverte des voisins sont mises en œuvre :\n- Découverte des routeurs : ce protocole permet aux équipements de déterminer les routeurs qui sont sur leur lien physique. Dans IPv4, ces fonctionnalités sont remplies par le protocole ICMP Router Discovery.\n- Découverte des préfixes : l’équipement apprend le ou les préfixes du réseau en fonction des annonces faites par les routeurs. En y ajoutant l’identifiant d’interface de l’équipement, celui-ci construit son ou ses adresses IPv6. Il n’existe pas d’équivalent pour le protocole IPv4 puisque les adresses sont trop courtes pour faire de l’auto-configuration.\n- Détection des adresses dupliquées : comme les adresses sont construites automati- quement, il existe des risques d’erreurs en cas d’identité de deux identifiants. Ce protocole teste qu’aucun autre équipement sur le lien ne possède la même adresse\nCette fonctionnalité est une évolution de l’ARP gratuit d’IPv4 émis à l’initialisation de\n- Découverte des paramètres. Ce protocole permet aux équipements d’apprendre les différents paramètres du lien physique, par exemple, la taille du MTU, le nombre de\n4 Valeur définie dans le RFC 1883. Cette exigence devrait bientôt disparaître.\nsauts maximal autorisé (valeur initiale du champ nombre de sauts), si la configuration automatique avec état (comme DHCPv6) est active Il n’existe pas d’équivalent en IPv4.\nLes différentes fonctionnalités de découverte des voisins utilisent 5 types de messages ICMPv6 :\n— Message de sollicitation d’un routeur : il est émis par un équipement au démarrage pour recevoir plus rapidement des informations du routeur. Ce message est émis à l’adresse IPv6 de multicast réservée aux routeurs sur le même lien.\n— Annonce du routeur : ce message est émis périodiquement par les routeurs ou en réponse à un message de sollicitation d’un routeur par un équipement.\n— Sollicitation d’un voisin : ce message permet d’obtenir des informations d’un voisin,\nc’est-à-dire situé sur le même lien physique (ou via des ponts). Le message peut lui être explicitement envoyé ou émis sur une adresse de diffusion. Dans le cas de la détermination de l’adresse physique, il correspond à la requête ARP du protocole IPv4.\n— Annonce d’un voisin : ce message est émis en réponse à une sollicitation, mais il peut\naussi être émis spontanément pour propager plus rapidement une information. Dans le cas de la détermination d’adresse physique, il correspond à la réponse ARP pour le protocole IPv4.\n— Indication de redirection : la technique de redirection est la même que dans IPv4. Un\néquipement ne connaît que les préfixes des réseaux auxquels il est directement attaché et l’adresse d’un routeur par défaut. Si la route peut être optimisée, le routeur par défaut envoie ce message pour indiquer qu’une route plus courte existe. En effet, avec IPv6, comme le routeur par défaut est appris automatiquement, la route n’est pas forcément la meilleure. Un autre cas d’utilisation particulier à IPv6 concerne des stations situées sur un même lien physique mais ayant des préfixes différents. Ces machines passent dans un premier temps par le routeur par défaut. Ce dernier les avertit qu’une route directe existe.\nChacun de ces messages peut contenir des options qui sont au nombre de 4 (adresse physique de la source/cible, information sur le préfixe, en-tête redirigé, MTU).\nTraditionnellement, la configuration d’une interface réseau d’une machine demande une configuration manuelle. C’est un travail souvent long et fastidieux. Avec IPv6, cette configuration est automatisée donnant par là-même des caractéristiques de fonctionnement immédiat (« plug and play ») à l’interface réseau. La configuration automatique signifie qu’une machine obtient toutes les informations nécessaires à sa connexion à un réseau local IP sans aucune intervention humaine. Dans le cas idéal, un utilisateur quelconque déballe son nouvel ordinateur, le connecte au réseau local et le voit fonctionner sans devoir y introduire des informations de « spécialiste ».\nL’auto-configuration a pour objectif :\n- l’acquisition d’une adresse quand une machine est attachée à un réseau pour la première fois ;\n- l’obtention de la nouvelle adresse suite à la renumérotation des machines du site après un changement d’opérateur. L’opération de re-numérotage revient concrètement à changer la partie haute de l’adresse. L’auto-configuration d’adresse va servir de vecteur dans l’attribution du nouveau préfixe.\nLe rôle du routeur est important dans l’auto-configuration. Il dicte à la machine, par les bits et du message d’annonce de routeurs, la méthode à retenir et fournit éventuellement les informations nécessaires à sa configuration. La valeur de ces bits est donnée par l’administrateur. La mise à la valeur 1 indique à la machine de retenir la méthode d’auto- configuration avec état. L’algorithme de la procédure d’auto-configuration d’adresse se décompose de la manière suivante :\n— La toute première étape consiste à créer l’adresse lien-local.\n— Une fois l’unicité de cette adresse vérifiée, la machine est en mesure de communiquer avec les autres machines du lien.\n— Maintenant, la machine doit chercher à acquérir un message d’annonce du routeur pour déterminer la méthode d’obtention de l’adresse unicast globale.\n— S’il y a un routeur sur le lien, la machine doit appliquer la méthode indiquée par le\nmessage d’annonce de routeurs, à savoir :\n- l’auto-configuration sans état (stateless autoconfiguration), utilisée quand la gestion administrative des adresses attribuées n’est pas nécessaire au sein d’un site.\n- l’auto-configuration avec état (stateful autoconfiguration), retenue lorsqu’un site demande un contrôle strict de l’attribution des adresses.\n— En l’absence de routeur sur le lien, la machine doit essayer d’acquérir l’adresse unicast\nglobale par la méthode d’auto-configuration avec état. Si la tentative échoue, c’est terminé. Les communications se feront uniquement sur le lien avec l’adresse lien-local. La machine n’a pas une adresse avec une portée qui l’autorise à communiquer avec des machines autres que celles du lien.\nPour vérifier l’unicité des adresses unicast, les machines doivent exécuter un algorithme de Détection d’Adresse Double (DAD) avant de les utiliser. L’algorithme utilise les messages ICMPv6 « sollicitation d’un voisin » et « annonce d’un voisin ». Si une adresse double est découverte, elle ne pourra être attribuée à l’interface. L’auto-configuration s’arrête et une intervention humaine devient obligatoire. Une adresse est qualifiée de « provisoire » pendant l’exécution de l’algorithme DAD et ce jusqu’à la confirmation de son unicité. Une adresse provisoire est assignée à une interface uniquement pour recevoir les messages de sollicitation et d’annonce d’un voisin. Les autres messages reçus sont ignorés. L’algorithme DAD consiste à envoyer un message sollicitation d’un voisin avec comme adresse cible l’adresse provisoire.\n— Un message annonce d’un voisin est reçu ; l’adresse provisoire est utilisée comme adresse\nvalide par une autre machine. L’adresse provisoire n’est pas unique et ne peut être retenue.\n— Un message sollicitation d’un voisin est reçu ; l’adresse provisoire est également une\nadresse provisoire pour une autre machine qui est en train d’exécuter l’algorithme DAD. L’adresse provisoire ne peut être utilisée par aucune des machines.\n— Rien n’est reçu au bout d’une seconde (valeur par défaut) ; l’adresse provisoire est unique, elle passe de l’état de provisoire à celle de valide et elle est assignée à l’interface.\nÀ l’initialisation de son interface, la machine construit un identifiant pour l’interface qui doit être unique au lien. Cet identifiant a été dans sa première version l’adresse MAC de la machine ; actuellement il est sous le format de l’identifiant EUI-64. Le principe de base de la création d’adresse IPv6 est de marier un préfixe avec l’identifiant. L’adresse lien-local est créée en prenant le préfixe lien-local ( ) qui est fixé. L’adresse ainsi constituée est encore interdite d’usage. Elle possède un état provisoire car la machine doit encore vérifier l’unicité de cette adresse sur le lien au moyen de la procédure de détection d’adresse double. Si la machine détermine que sa création d’adresse lien-local a échoué (c’est-à-dire qu’elle n’est pas unique), l’auto-configuration s’arrête et une intervention manuelle est nécessaire. Une fois que l’ambiguïté sur l’unicité de l’adresse lien-local a été levée, l’adresse provisoire devient une adresse valide pour l’interface. La première phase de l’auto-configuration consistant à créer une adresse lien-local est achevée.\nL’auto-configuration sans état ne demande aucune configuration manuelle des machines, une configuration minimum pour les routeurs et aucun serveur supplémentaire. Elle se sert du protocole ICMPv6 et peut fonctionner sans la présence de routeurs. Elle nécessite cependant un sous-réseau à diffusion. Cette méthode ne s’applique que pour les machines et ne peut être retenue pour la configuration des routeurs. Le principe de base de l’auto-configuration sans état est qu’une machine génère son adresse IPv6 à partir d’informations locales et d’informations fournies par un routeur. En fait le routeur fournit à la machine les informations sur le sous-réseau associé au lien, il donne le préfixe ou le localisateur de l’adresse. Comme pour la création de l’adresse lien-local, l’adresse unicast globale est obtenue en concaténant le préfixe avec l’identifiant de l’interface. Le préfixe provient du message d’annonce de routeurs et plus précisément de l’option « information sur le préfixe ». Bien qu’il faille vérifier l’unicité de toutes les adresses unicast, dans le cas d’une adresse unicast obtenue par auto- configuration sans état cela n’est pas nécessaire. En effet, l’identifiant de l’interface a déjà été contrôlé dans l’étape de création de l’adresse lien-local. L’identifiant étant le même, il n’y a plus aucune ambiguïté sur son unicité. L’adresse unicast globale constituée est aussi unique que celle lien-local. La re-numérotation des machines d’un lien s’effectue au moyen des routeurs qui passent les adresses utilisées dans un état déprécié et annoncent par la suite le nouveau préfixe. Les machines pourront recréer une adresse préférée.\nAvec l’auto-configuration avec état, une machine IPv6 obtient les adresses et/ou d’autres informations de configuration par l’intermédiaire d’un serveur. Tout le mécanisme d’auto- configuration avec état est bâti sur le modèle du client-serveur et repose sur l’utilisation du protocole DHCPv6 (Dynamic Host Configuration Protocol for IPv6). Le protocole DHCPv6 sert à remettre des paramètres de configuration d’un serveur DHCP à un client IPv6. Un paramètre de configuration est une information utile à la machine pour configurer son interface réseau de manière qu’elle puisse communiquer sur son lien ou sur l’Internet. Ceci comprend notamment les adresses pour le client, le serveur de nom, le nom de domaine etc. Pour les adresses, par exemple, le serveur maintient une table pour lui permettre de savoir quelles sont les adresses allouées et celles qui ne le sont pas. L’ensemble des adresses gérées par le serveur est créé par l’administrateur du site. Le serveur DHCP ne se trouve pas forcément sur le même lien que le client et dans ce cas, les échanges DHCPv6 passent par un relais. Grâce à ces relais, le serveur peut maintenir la configuration des machines situées sur plusieurs liens différents. Conformément au modèle client-serveur, les échanges se composent de requêtes et de réponses. Une transaction est pratiquement toujours entamée sur l’initiative d’un client par une requête DHCP. La fiabilité de la transaction est assurée par le client, qui répète sa requête DHCP jusqu’à recevoir une réponse ou obtenir la certitude que le serveur DHCP est indisponible. DHCPv6 est un protocole d’application qui se sert du protocole de transport UDP au-dessus de IPv6. Un client envoie les requêtes sur le port 547 du serveur et recevra les réponses par le port 546.\nLe protocole DHCPv6 se compose de 6 types de messages :\n— Sollicitation DHCP, message émis vers un serveur ou un relais DHCP. Un client émet un tel message pour obtenir l’adresse d’un serveur DHCP.\n— Annonce DHCP, message émis en réponse à un message Sollicitation DHCP. Il donne l’adresse IPv6 d’un serveur DHCP.\n— Requête DHCP, message émis d’un client vers un serveur pour demander des paramètres de configuration.\n— Réponse DHCP, message émis par le serveur suite à une demande du client.\n— Libération DHCP, demande du client de libérer des ressources allouées par le serveur.\n— Reconfiguration DHCP, message émis par le serveur pour informer le client qu’il a de nouvelles informations de configuration. Le client doit alors commencer une nouvelle transaction pour acquérir ces informations.\nLe protocole de découverte de voisin permet la configuration initiale et la reconfiguration des équipements terminaux de manière automatique. Il ne s’applique pas aux routeurs, pour des raisons de sécurité et parce que la configuration d’un routeur est plus complexe. C’est une des critiques sur IPv6 en l’état actuel : un site qui change de fournisseur d’accès doit reconfigurer\ntous ses routeurs à la main. Un des buts du plan d’adressage GSE était de supprimer ce problème. Une autre approche est de concevoir un protocole spécifique pour la reconfiguration automatique des routeurs. Un tel protocole est en cours de discussion.\nCe protocole est basé sur un message ICMPv6 spécial, dont le type n’a pas encore été précisé. Ce message contient un préfixe de test, une opération, et des nouveaux préfixes. Lorsqu’un\nrouteur reçoit un tel message, il regarde si le message concerne un des préfixes associés à une de ses interfaces : pour cela il regarde si le préfixe de test est un préfixe de ce préfixe d’interface. Si c’est le cas, on applique l’opération contenue dans le message à l’interface ; l’opération peut être :\n- ajouter : on ajoute à l’interface les nouveaux préfixes contenus dans le message,\n- remplacer : on remplace le préfixe sélectionné de l’interface par les nouveaux préfixes contenus dans le message,\n- affecter : on remplace tous les préfixes associés à l’interface par les nouveaux préfixes contenus dans le message.\nEn fait, chaque préfixe ajouté (ou de remplacement) est formé en concaténant un nouveau préfixe et un champ de bits pris dans l’ancien préfixe d’interface (champ longueur à conserver du message). Ceci permet de changer la partie haute de plusieurs préfixes en un seul message.\nLe protocole comprend aussi des mécanismes de détection de messages perdus ou dupliqués, et un mécanisme de signature pour sécuriser la reconfiguration. Avec un tel protocole il est possible, lors d’un changement de fournisseur d’accès, de reconfigurer tous les routeurs du site en quelques messages. Une fois les routeurs reconfigurés, les protocoles de configuration automatique (avec ou sans état) permettent de reconfigurer tous les équipements du site.\nPour des considérations d’efficacité, il est généralement préférable que les informations échangées entre équipements soient contenues dans des datagrammes de taille maximale. Cette taille dépend du chemin suivi par les datagrammes et est égale à la plus grande taille autorisée par l’ensemble des liens traversés.\nElle est de ce fait appelée PMTU, ou Path Maximum Transmission Unit (unité de transfert de taille maximale sur le chemin).\nInitialement, l’équipement émetteur fait l’hypothèse que le PMTU d’un certain chemin est égal au MTU du lien auquel il est directement attaché. S’il s’avère que les paquets transmis sur ce chemin excédent la taille maximale autorisée par un lien intermédiaire, alors le routeur associé détruit ces paquets et retourne un message d’erreur ICMPv6 de type « paquet trop grand », en y indiquant le MTU accepté. Fort de ces informations, l’équipement émetteur réduit le PMTU supposé pour ce chemin.\nPlusieurs itérations peuvent être nécessaires avant d’obtenir un PMTU permettant à tout paquet d’arriver à l’équipement destinataire sans jamais excéder le MTU de chaque lien traversé. Le protocole IPv6 garantit que le MTU de tout lien ne peut descendre en dessous de 576 octets, valeur qui constitue ainsi une borne inférieure pour le PMTU. Ce protocole\nreposant sur la perte de paquets, il est laissé le soin aux couches supérieures de gérer la fiabilité de la communication en retransmettant si nécessaire.\nL’émetteur vérifie aussi que le PMTU n’a pas augmenté en envoyant de temps en temps un paquet plus grand. Si celui-ci traverse le réseau sans problème, la valeur du PMTU est augmentée.\nSignalons enfin que l’algorithme de découverte du PMTU fonctionne indifféremment avec des échanges point-à-point ou multipoints. Dans ce dernier cas, le PMTU sera le PMTU minimal permis par l’ensemble des chemins vers chaque site destinataire du groupe de diffusion.\nL’exploitation de l’information de PMTU se fait de plusieurs façons suivant l’endroit où les données à transmettre sont segmentées :\n- si un protocole de type TCP est utilisé, celui-ci assurera la segmentation de façon transparente pour les applications, en fonction des informations de PMTU que pourra lui communiquer la couche IPv6.\n- si un protocole de type UDP est utilisé, alors cette segmentation devra être assurée par une couche supérieure, éventuellement l’application. Il faut donc que celle ci (1) puisse être informée du PMTU autorisé, même dans le cas où celui-ci change par la suite, et (2) puisse segmenter ses données en conséquence.\nParce que ces deux conditions ne sont pas toujours réunies, IPv6 a conservé un mécanisme de fragmentation.\nUn deuxième aspect concerne l’identification des chemins afin de pouvoir y associer les informations de PMTU. Plusieurs possibilités, laissées à l’implémenteur, sont possibles. Un chemin peut être identifié par l’adresse destination, ou par l’identificateur de flux si celui-ci est utilisé, ou par la route suivie dans le cas où elle est imposée.\nEnfin, s’il est fortement recommandé que chaque équipement supporte le mécanisme de recherche du PMTU, ce n’est pas obligatoire. Ainsi, un équipement qui n’en dispose pas (par exemple une ROM de boot) devra restreindre la taille de tout paquet transmis au MTU minimal que doit supporter tout lien soit 576 octets.\nIV. Supports de transmission\nLe principe du transport d’un datagramme IPv6 entre deux machines directement reliées entre elles est le même que pour IPv4. Il est tout d’abord routé vers une interface d’émission qui l’encapsule dans une trame (PDU de niveau 2 dans le modèle de référence de l’OSI), elle- même transmise sur un lien physique. La machine destination reçoit la trame sur son interface, la décapsule et la traite. Une adresse sur un lien sera appelée Adresse MAC.\nLe protocole de transport de datagrammes IPv6, reposant sur des supports permettant le multicast, autorise l’utilisation du protocole de découverte de voisins pour faire la correspondance entre adresse IPv6 et adresse MAC.\nLes datagrammes IPv6 utilisent l’encapsulation standard dans des trames Ethernet, chaque trame contenant un seul datagramme. L’en-tête de la trame Ethernet contient les adresses Ethernet source et destination, et le champ type vaut (pour IPv4 le champ type valait ).\nLa structure d’une trame est :\nLa taille maximale d’un datagramme pouvant être transmis directement par une interface Ethernet (MTU) est normalement de 1500 octets. Une valeur plus faible peut être forcée par configuration manuelle ou en utilisant l’option MTU des annonces de routeurs.\nSi un datagramme est plus grand que le MTU prévu, l’interface le rejette. La couche supérieure de transport doit soit changer la taille des paquets, soit utiliser l’extension de fragmentation.\nPour les adresses de multicast, le protocole de découverte des voisins n’est pas utilisable. L’adresse Ethernet est calculée en concaténant le préfixe et les 4 octets de poids faible de l’adresse IPv6.\nPour la construction des adresses lien-local et des adresses auto-configurées, l’identifiant d’interface est celui dérivé de l’adresse MAC IEEE 802 constructeur de l’interface Ethernet.\nPour les messages ICMPv6 de découverte de voisins, le format des options « adresse physique Source/Destination » est :\nType : type de l’option « Neighbor Discovery » Long : 1 (i.e. 8 octets)\nLa taille maximum d’une trame FDDI est de 4500 octets, ce qui autoriserait un MTU\nmaximum de 4470 octets. Pour permettre des extensions, le MTU IPv6 par défaut pour FDDI\na été fixé à 4352 octets. Toutefois, à cause de la présence possible de ponts IEEE 802.1d\nle MTU effectif peut être plus faible (par exemple en présence de ponts\nEthernet/FDDI, le MTU doit être de 1 500 octets). La valeur par défaut du MTU peut donc\nêtre modifiée, soit par configuration manuelle, soit en utilisant l’option MTU des paquets\n« Annonce du routeur ».\nLes datagrammes IPv6 sont transmis dans des trames FDDI asynchrones avec jeton simple, chaque trame contenant un datagramme. L’encapsulation utilisée est l’encapsulation LLC/SNAP avec adresses 48 bits et un champ type protocole valant 0x86DD.\nDSAP, SSAP Valeur , indiquant une encapsulation SNAP.\n« Frame Code». Doit être dans l’intervalle - .\nValeur , indiquant une information non numérotée.\nValeur (« Qrganizationally Unique Identifier »).\n< 4500 octets\nLe principe régissant le calcul de l’identifiant d’interface et celui de l’adresse MAC à partir d’une adresse IPv6 de multicast est le même que pour Ethernet. L’option « adresse physique Source/Destination » est aussi décrite dans le chapitre consacré à Ethernet.\nA priori, un des obstacles à l’utilisation directe du protocole IEEE 802.3 semble levé avec IPv6. Avec IPv4, comme il n’existe pas de numéro de SAP attribué au protocole ARP, l’encapsulation SNAP est obligatoirement utilisée.\nAvec IPv6, le protocole ARP est remplacé par le protocole de découverte des voisins qui utilise les messages ICMPv6. Techniquement, IPv6 peut être utilisé au-dessus du protocole IEEE 802.3. Reste le problème de l’alignement des champs. Un soin tout particulier a été apporté dans la conception des en-têtes pour les aligner sur des mots de 64 bits. Or l’en-tête IEEE 802.2, obligatoire, fait 3 octets. L’encapsulation SNAP est toujours nécessaire, car avec ses 5 octets, elle aligne le début du paquet IPv6 au début d’un mot de 64 bits.\nL’encapsulation est la même que pour FDDI.\nIl n’y a pas actuellement de RFC pour le transport de IPv6 sur les autres supports de type IEEE 802, comme l’anneau à jeton. En s’inspirant du STD 43 (RFC 1042) qui définit l’encapsulation pour IPv4, ainsi que des sections précédentes, il serait aisé de définir un protocole de transport adéquat. Une proposition encore à l’état de draft [NCT-id] a été faite pour l’anneau à jeton (IEEE 802.5) :\n— La taille maximale possible pour un paquet est très variable à cause de la possibilité du\n« source routing » qui ajoute des informations pour indiquer le chemin à travers les ponts. La valeur du MTU est donc configurable, avec une valeur défaut de 1500, mais les valeurs de longueur de trame indiquées dans les trames de « source routing » peuvent être prise en compte.\n— Le format des trames est celui d’une encapsulation LLC/SNAP avec un champ type\n. Le format est analogue à celui de FDDI. Le format de l’identifiant d’interface et de l’option « adresse physique Source/Cible » suit les même règles que pour Ethernet ou FDDI.\n— La correspondance entre adresse multicast et adresse physique n’est pas aussi simple\nqu’avec Ethernet ou FDDI. En effet les composants pour l’anneau à jeton ne permettent de positionner qu’un seul bit dans l’adresse. Il en résulte 10 classes d’adresses MAC pour le multicast dans lesquelles sont rangées plusieurs adresses IPv6 de multicast.\nLes réseaux à destinataires multiples (donc pas point à point) mais sans diffusion, les NBMA (Non Broadcast Multiple Access) posent des problèmes particuliers car la découverte des voisins s’appuie fortement sur les services de multicast.\nLe principal exemple aujourd’hui de réseau NBMA est l’ATM (le mode de transfert asynchrone) qui adresse les problèmes de qualités de services dont il serait intéressant de disposer aussi au niveau IPv6.\nLe problème qui se pose aujourd’hui est de savoir comment traduire les qualités de service qu’offre ATM en des qualités de services Internet. La notion de qualité de service n’étant toujours pas claire dans le monde IP, le groupe « IntServ » de l’IETF s’est chargé de définir les différents services à intégrer dans l’Internet.\nParallèlement, le groupe ISSLL (Integrated Services on Specific Link Layers) de l’IETF étudie actuellement la manière de réaliser la mise en correspondance des deux types de qualités de service.\nSoulignons que le problème des qualités de service n’est pas propre à IPv6. Cependant, IPv6 a plus de chance de s’adapter aux solutions qui seront proposées, grâce à la structure de l’en- tête IPv6. En effet, les chercheurs sont en train d’explorer les possibilités d’exploiter les champs « priorité » et « identificateur de flux » pour parvenir à la mise en correspondance des deux types de qualités de service (IP/ATM).\nPar ailleurs, la mise en oeuvre du protocole IPv6 au-dessus d’une infrastructure ATM est toujours un domaine de recherches très actif. Une solution semble se dessiner au tour des propositions de Grenville Armitage qui s’appuie sur MARS (Multicast Address Resolution\nServers, RFC 2022), la redirection externe de la découverte des voisins (voir plus loin) et NHRP (NBMA Next Hop Resolution Protocol).\nLe système MARS permet d’obtenir un service multicast pour IPv4 au-dessus d’ATM au sein d’un petit réseau (typiquement de la taille d’un LIS de classical IP ou d’un réseau virtuel :\nVLAN de LANE (LAN Emulation). Il est facilement extensible à IPv6 et peut être défini pour d’autres architectures NBMA (surtout pour un trafic restreint) et permet donc de récupérer les fonctionnalités multicast nécessaires pour la découverte des voisins sur un petit réseau nommé « lien logique ».\nLa redirection externe permet de déterminer si un nœud dans un même préfixe non entièrement sur le lien physique est directement accessible en donnant au passage son adresse physique. De tels voisins sont qualifiés de « temporaires » et peuvent appartenir dans ce cadre à d’autres liens logiques (ce mécanisme est donc une optimisation du routage inter-liens logiques).\nLe protocole NHRP (NBMA Next Hop Resolution Protocol) permet de détecter et de construire des raccourcis dans une infrastructure NBMA découpée en petites entités. Pour IPv6 sur ATM il est utilisé entre routeurs inter-liens logiques pour détecter les raccourcis, la redirection externe construisant les raccourcis quand l’une des extrémités au moins n’est pas un routeur.\nLes datagrammes IPv6 sont transportés dans des trames AAL5 (ATM Adaptation Layer 5) et conformément au RFC 1483 (Multiprotocol Encapsulation over ATM Adaptation Layer 5). Deux méthodes sont possibles pour transporter les trames AAL5 dans les VC (circuits virtuels) suivant les possibilités offertes par l’environnement :\n- Circuits dédiés\n- Encapsulation LLC/SNAP\nLa taille maximale d’un datagramme pouvant être transmis directement par une interface ATM (IP-MTU) est normalement de 9180 octets, la MTU de l’interface étant 9188 octets (8 octets pour l’en-tête LLC/SNAP).\nL’encapsulation est faite dans une trame « PPP Data Link Layer ». Chaque datagramme IPv6 forme une trame séparée. Le champ protocole de la trame doit être .\nLe protocole de contrôle de PPP pour IPv6 s’appelle IPV6CP. Il permet la configuration, la validation et l’invalidation des modules IPv6 de PPP. Chaque datagramme IPV6CP est transmis dans une trame « PPP Data Link Layer » de champ protocole . Le protocole IPV6CP permet de négocier deux options, la valeur de l’identifiant d’interface et la compression.\nComme il n’existe pas d’adresse MAC IEEE 802 ou EUI-64 pour les interfaces PPP, il n’y a pas de valeur par défaut standard. Si la machine (ou une autre interface) possède un EUI-64 ou une adresse MAC IEEE 802, on utilise l’identifiant associé. Sinon il faut fournir une valeur (non universelle) à partir d’un numéro de série, ou même d’un générateur aléatoire.\nDans tous les cas, la négociation d’identifiant d’interface de IPV6CP doit être utilisée pour forcer l’unicité de l’identifiant.\nLe MTU est variable car déterminé par la connexion PPP sous-jacente. Il doit être au moins égal à 576.\nIl faut remarquer que PPP n’a pas de notion d’adresse physique, donc l’option « adresse physique Source/Cible » du protocole de découverte de voisin n’est pas utilisée. De même, il n’est pas nécessaire de définir un traitement particulier pour les paquets multicast : comme sur tout lien point à point, le multicast IPv6 est supporté sans action particulière.\nUne méthode de compression des en-têtes IPv6 du même type que celle utilisée par IPv4 a été proposée. Elle est optionnelle et son utilisation est négociée par IPV6CP.\nUn tunnel est un moyen de transporter des paquets IP directement entre deux points connectés par IP. L’extrémité émettrice du tunnel encapsule le datagramme IP dans un autre datagramme IP et l’envoie vers l’autre extrémité du tunnel. L’extrémité réceptrice reçoit le message, décapsule le datagramme IP et le traite. On peut voir ce mécanisme comme un lien point à point ou un lien NBMA, selon qu’on considère des relations 2 à 2 ou un émetteur en face du réseau Internet.\nIl existe de nombreux formats de tunnels en IPv4 : celui utilisé en mobilité, celui utilisé par le Mbone pour le multicast, le format GRE [RFC 1701]\nEn IPv6, l’utilisation des en-têtes d’extension et le support du multicast en natif font que la plupart des utilisations de tunnels par IPv4 n’ont plus de raison d’être.\nIl existe cependant un usage important des tunnels dans la phase de déploiement de IPv6, tant que la connectivité mondiale n’est pas assurée : c’est l’utilisation des tunnels IPv6 dans IPv4, permettant de relier des réseaux IPv6 isolés à travers l’Internet IPv4. Cette approche est utilisée de manière intensive pour réaliser le réseau 6bone.\nTransport de IPv6 sur IPv4 :\nLe transport des paquets IPv6 à l’intérieur de paquets IPv4 est décrit dans [RFC 1933]. Il existe deux modes de tunnel, point à point (ou configuré) qui établit une liaison fixe entre deux machines (en général des routeurs), et NBMA (ou automatique), qui permet à une machine isolée d’accéder à toutes les autres machines à l’aide des adresses IPv4 compatibles. Le MTU est variable. Une valeur possible pour un tunnel point à point est PTMU —20 où PTMU est le « Path MTU » IPv4 entre les deux extrémités du tunnel. Il doit être au moins égal à 576. L’encapsulation est faite dans un paquet IPv4 de type protocole 41 (0x29). Chaque datagramme IPv6 forme un paquet séparé. Ce paquet peut être fragmenté par IPv4.\nproto = 0x29\nadr. de la source tunnel IPv4\nadr de destination tunnel IPv4\nEn-tête et données IPv6\nLe choix de l’identifiant d’interface n’est pas défini dans le RFC 1933. On peut par exemple le dériver de l’adresse IPv4 de l’extrémité du tunnel.\nIl n’y a pas d’autre paramètre à définir pour un tunnel point à point. Pour un tunnel NBMA, le RFC 1933 ne définit pas l’option « adresse physique Source/Cible » ni le support du multicast.\nA. Protocoles de routage\nLes principes des protocoles de routage n’ont pas changé avec IPv6. Les travaux en cours consistent uniquement à les adapter aux nouveaux formats d’adresse. Ces protocoles de routage profitent des propriétés maintenant incluses dans la nouvelle version du protocole IPv6 comme l’authentification ou le multicast. Comme dans IPv4, il faut faire la distinction entre deux grandes familles de protocoles de routage : le routage interne et externe.\nB. Routage interne\nLes protocoles dits de routage interne permettent une configuration automatique des tables de routage. Les routeurs découvrent automatiquement la topologie du réseau et déterminent le plus cours chemin pour atteindre un réseau distant. Les protocoles de routage interne nécessitent une configuration minimale du routeur. Celui-ci doit connaître les réseaux auxquels il est attaché. Pour IPv4, en plus de protocoles développés par les constructeurs de routeurs, il existe deux grandes catégories de protocoles de routage conçus par l’IETF.\nLes algorithmes appelés « distant vector », sont utilisés par les protocoles de routage RIP [RFC 1058] et RIPv2 [RFC 1723].\nIls sont basés sur l’algorithme de Bellman-Ford et figurent parmi les premiers algorithmes de routage interne utilisés dans l’Internet.\nLes routeurs diffusent leurs tables de routage sur les liens auxquels ils sont connectés. Les autres routeurs modifient une route dans leur table si la métrique reçue (dans ce cas le nombre de routeurs à traverser pour atteindre une destination) est plus petite que celle déjà stockée dans la table. Si une annonce de route n’est pas présente dans la table, le routeur la rajoute. Ces modifications sont à leur tour diffusées sur les autres réseaux auxquels sont connectés les routeurs. Elles se propagent donc sur l’ensemble du réseau. On montre que cet algorithme converge et qu’en condition stable, aucune boucle n’est créée sur le réseau (c’est-à-dire qu’un paquet ne sera pas transmis indéfiniment de routeur en routeur sans jamais pouvoir atteindre sa destination).\nLes tables sont émises périodiquement. Si un routeur tombe en panne ou si le lien est coupé, les autres routeurs ne recevant plus l’information suppriment l’entrée correspondante de leur table de routage.\nRIPng est le premier protocole de routage dynamique proposé pour IPv6 [RFC 2080]. RIPng est une simple extension à IPv6 du protocole RIPv2 d’IPv4. Il en hérite les mêmes limitations d’utilisation. De plus, l’agrégation des routes en IPv6 pose de nouveaux problèmes qui nécessitent de configurer précisément les routeurs.\nUtiliser RIPng peut sembler être un retour en arrière puisque l’IETF déconseille l’utilisation de RIP au profit d’OSPF dans les réseaux IPv4. Pour l’instant les réseaux IPv6 ont encore une topologie relativement simple, sur laquelle RIP est relativement bien adaptée. De plus la très grande simplicité du protocole a permis une mise en œuvre et un déploiement rapide de RIPng. Il permet d’attendre la définition et les mises en œuvre de protocoles de routage intérieur plus élaborés tels OSPFng ou IS-IS. Il s’applique donc à de petits réseaux expérimentaux. Il est fortement déconseillé de trop généraliser son utilisation.\nLe format générique des paquets RIPng est très proche de celui des paquets du protocole RIPv2. Seule la fonction d’authentification a disparu. Elle est en effet inutile car RIPng peut s’appuyer sur les mécanismes de sécurité IPSec disponibles en IPv6.\n1 pour une requête de table de routages\n2 pour une réponse à une requête ou une émission périodique.\nVersion : ce champ est aujourd’hui défini à la valeur 1.\nEntrée : ce champ contient l’information de routage. Le nombre d’informations de routage contenues dans un paquet RIPng dépend directement du MTU des liens utilisés. Si RIPng doit annoncer un grand nombre de réseaux, plusieurs paquets RIPng seront nécessaires. La structure de ce champ est la suivante :\nmarque de routage\nLe champ métrique comptabilise le nombre de routeurs traversés. Pour résoudre les problèmes de convergence (« comptage jusqu’à l’infini »), la valeur maximale de métrique (« infini ») est 16. Cette valeur est largement suffisante pour le domaine d’application du protocole. Le champ métrique peut donc prendre toutes les valeurs comprises entre 0 et 16.\nSi le champ métrique vaut , le champ préfixe donne l’adresse d’un routeur (prochain saut). Une telle entrée indique que les destinations des entrées suivantes sont accessibles par le routeur explicitement indiqué, et non par celui envoyant le paquet RIPng (utilisation en mode « proxy »). Dans ce cas, les champs « marque de routage » et « longueur du préfixe » sont mis à 0.\nDans RIPv2, cette possibilité était indiquée dans chaque information de routage. Vu la longueur des adresses IPv6, dans RIPng l’indication du prochain saut est valable pour toutes les routes qui suivent jusqu’à la fin du paquet ou jusqu’à la prochaine entrée de ce type. Ainsi, bien que les adresses soient quatre fois plus grandes qu’en IPv4, la taille des informations de routage est la même que dans RIPv2.\nLes paquets RIPng sont émis vers l’adresse de multicast all-rip-router et encapsulés dans un paquet UDP avec le numéro de port 521.\nLe deuxième protocole de routage internet, basé sur l’algorithme du plus court chemin, s’appelle OSPF (Open Shortest Path First).\nRelativement plus difficile à mettre en œuvre, il est beaucoup plus efficace dans les détections et la suppression des boucles dans les phases transitoires. Ce protocole est basé sur plusieurs sous-protocoles. Le premier permet une inondation fiable du réseau. Chacun des routeurs possède alors une copie des configurations de tous les autres routeurs présents sur le réseau. Ils peuvent simultanément calculer le plus court chemin pour aller vers l’ensemble de destinations.\nPour réduire la durée des calculs et surtout pour éviter un recalcul complet des routes à chaque changement de configuration, OSPF offre la possibilité de découper le réseau en aires. Une aire principale appelée backbone doit pouvoir relier toutes les autres aires. Les réseaux trouvés dans les aires données sont envoyés aux autres routeurs en frontière d’aires.\nOSPFng a été adapté à IPv6 en remplaçant la notion de sous-réseau par celle de liens. Les informations d’adressages ont été retirées des formats de paquets et de LSA (Link State Advertisements) afin de rendre le cœur d’OSPF indépendant du protocole réseau et de le\nrestreindre au transport d’informations sur la topologie. Dans le reste d’OSPF le format des\nadresses a été changé pour accepter des adresses IPv6. La notion de portée (lien, aire, utilise le mécanisme de portée d’IPv6.\nUn lien supporte plusieurs instances du protocole OSPFng ce qui permet de l’utiliser plus facilement sur des liens partagés entre plusieurs domaines de routage. OSPFng utilise des adresses lien-locales pour l’échange de paquets OSPFng sur les liens. Le mécanisme de sécurité a été remplacé par les facilités d’authentification et de confidentialité d’IPv6.\nC. Routage externe\nLa seconde famille de routage concerne le routage externe. Le terme externe vient du fait qu’il s’agit d’un échange de tables de routage entre deux domaines d’administration distincts, généralement entre un client et son fournisseur, un fournisseur et son transporteur international ou entre fournisseurs ou transporteurs internationaux.\nEn IPv4 cette notion de domaine d’administration est représenté par un numéro de système autonome (AS : Autonomous System)\nIl n’est pas clair que cette notion soit encore utile en IPv6 puisque dans un plan d’adressage hiérarchique, le préfixe peut jouer une notion équivalente au numéro d’AS.\nAvec un protocole de routage externe, il ne s’agit plus de trouver la topologie du réseau, mais d’échanger des informations d’accessibilité explicite entre routeurs configurés pour le faire. Ceux-ci traitent les informations reçues pour éliminer celles qui ne sont pas pertinentes ou contraires à la politique de routage définie pour le site. En effet, toute annonce de réseau par un domaine implique qu’il accepte de router les paquets vers cette destination.\nBGP-4 est le protocole de routage externe actuellement utilisé pour IPv4 (la version 4, identique pour BGP et IP, est pure coïncidence). Dans le cas d’IPv6, deux extensions de BGP4 ont été proposées : BGP4+ qui est un clone de BGP4 utilisant un transport TCP sur IPv6 et des nouveaux attributs pour coder les préfixes, et BGP5 qui, de plus, permet d’avoir des numéros de système autonome (AS) de taille variable.\nDans l’immédiat, BGP4+ s’est imposé. Peu de nouvelles possibilités ont été introduites. Les numéros d’AS utilisés pour IPv4 servent aussi à IPv6.\nIl semble que BGP4+ soit plutôt une solution à court terme pour résoudre les problèmes pratiques de routage sur le 6bone et qu’une solution à long terme, peut-être basée sur IDRP, reste à développer.\nBGP4+ introduit deux nouveaux attributs pour transporter des informations de routages autres que les routes unicasts IPv4, en particulier des routes multicasts (BGP4+ peut ainsi servir de base à un routage multicast inter-domaines) et des routes pour d’autres protocoles, dont IPv6 qui est le seul réellement envisagé dans les premières propositions.\nCes nouveaux attributs permettent d’annoncer l’accessibilité ou la non-accessibilité de préfixes (NLRI Network Layer Reachability Informations dans la terminologie des protocoles inter-domaines). À un ensemble de NLRI est associé des attributs standard de BGP (comme le chemin d’AS Autonomous Systems), la famille d’adresses, une sous-famille (unicast et/ou multicast), une information sur le routeur à utiliser (next-hop) avec son adresse, éventuellement son adresse locale au lien et une ou plusieurs adresses physiques.\nD. Réseau IPv6 expérimental\nLe 6bone est un réseau expérimental destiné à tester les protocoles IPv6 et leur mise en œuvre. Il a démarré officiellement le 15 juillet 1996 entre les groupes suivants : UNI-C au Danemark, WIDE au Japon et le G6 en France. Les premières connexions se sont faites à travers des tunnels IPv6 sur IPv4 utilisant les liaisons Internet classiques. Depuis, certains liens IPv6 natifs ont vu le jour, mais la majorité du trafic emprunte encore ces tunnels. Le modèle d’architecture de site choisi le plus souvent est bâti sur un réseau local IPv6 natif relié au 6bone par un routeur/tunnelier. Aujourd’hui, près de 200 sites sont interconnectés dans les 30 pays suivants :\nEn tant que réseau de test, le 6bone n’offre aucune garantie de service. Ce n’est en aucun cas un réseau de production. Il est, par contre, d’une grande souplesse et peut être reconfiguré assez facilement.\nUn certain nombre de leçons ont déjà été tirées de ces expériences. Au début, les différents sites s’interconnectaient de façon anarchique. Très rapidement, un besoin d’organisation s’est fait sentir pour essayer de maintenir l’accessibilité et le routage entre sites. Tant que le 6bone n’excédait pas une dizaine de sites, un routage statique était suffisant. Les choses sont vite devenues ingérables et la nécessité d’un protocole de routage dynamique s’est fait sentir. En décembre 1996 on a déployé les premières versions de RIPng. Cela a permis d’étendre le 6bone jusqu’à une centaine de sites. Cependant, RIPng est un protocole de routage intérieur et souffre des mêmes problèmes de convergence que RIP pour IPv4. Dès avril 1997, le 6bone s’est rendu à la nécessité d’avoir un protocole de routage externe. BGP4+ s’est vite imposé et plusieurs implémentations ont rapidement été disponibles. En août 1997, la décision a été prise d’imposer BGP4+ pour les nœuds principaux du 6bone chargés d’assurer le routage global.\nLa notion d’adressage s’est révélée très importante. Les adresses de type IPv4-compatible se sont vite montrées d’un intérêt très limité et leur utilisation a été restreinte aux seuls tunnels. Le plan d’adressage prestataire décrit dans le RFC 1897 a été testé dès le début et a vite montré ses limites. Depuis le 1er octobre 1997, le plan d’adressage agrégé est progressivement mis en place. Une tâche importante est désormais de le tester et d’essayer d’en découvrir les cas limites pour le valider. À cette fin, un seul préfixe TLA, , est attribué pour l’ensemble du 6bone de façon à ne pas gaspiller trop d’espace d’adressage. Ce TLA est découpé une première fois en NLA1, préfixes de longueur 24 ( ) pour simuler l’attribution de TLA. Ces préfixes sont appelés pTLA (pour « pseudo-TLA »). Ils sont attribués aux sites qui en font la demande et qui s’engagent à agréger ensuite derrière eux d’autres sites en leur délégant à leur tour des pNLA1s (en fait, des NLA2s) à l’intérieur de leur pTLA.\nLe G6bone, réseau IPv6 du G6, est un exemple de mise en œuvre de la politique d’adressage du 6bone. Il s’est vu attribué le pTLA . Le G6 a proposé un plan d’adressage national basé sur un certain nombre de points d’interconnexion appelés hubs. On distingue trois types de hubs : les hubs régionaux, les hubs d’organisation et le hub national.\nLes hubs régionaux interconnectent les sites expérimentaux « proches » d’eux. Cette notion de proximité peut être variable d’un hub à l’autre, elle est définie dans la charte de chacun d’entre eux. Les hubs d’organisation sont prévus pour permettre à des organismes multi-sites tels l’INRIA ou le CNET de partager un préfixe commun entre leurs différents sites. Le hub national abrite les liaisons internationales et connecte les sites distants n’ayant pu s’interconnecter directement ailleurs. L’ensemble des hubs régionaux et d’organisation sont connectés au hub national.\nChaque hub a reçu une délégation de pNLA1 de 32 bits, c’est-à-dire qu’il gère un préfixe de type ; par exemple, le hub Grenoblois gère le préfixe et le hub Ile de France . Chaque hub a ensuite la charge de définir un redécoupage de son pNLA1 comme il l’estime nécessaire, par exemple en allouant un pNLA2 avec un préfixe de longueur 40 à un sous-hub ou en allouant un préfixe de longueur 48 à un site. Il faut noter que ces délégations successives ne sont pas nécessairement faites sur des frontières d’octets : on peut très bien décider d’allouer des préfixes de longueur 37, 38 ou 39.\nLes sites feuilles se connectent au hub de leur choix et obtiennent un préfixe de longueur 48 de celui-ci.\nLes interconnexions sont en 1997 réalisées par des tunnels IPv6 sur IPv4 qui utilisent dans la majorité des cas les infrastructures du réseau de la recherche Rénater. L’un des projets du G6 pour 1998 est de faire évoluer ce réseau G6bone en utilisant des liens IPv6 natifs.\nDans le domaine de la sécurité, IPv6 doit arriver à rendre deux services :\n- Intégrer un système d'authentification de l'utilisateur et garantir l'intégrité des données.\n- Offrir un système de cryptage applicable soit à la totalité du datagramme IP, soit à l'unité des données du niveau 4 transport.\nCes systèmes, nous le verrons, doivent être suffisamment décorrélés des algorithmes employés, afin que l'armée ou l'industrie puisse les mettre en œuvre facilement.\nIl semble que les groupes de travail se soient accordés sur un certain nombre de points tels que la séparation du moyen d'authentification de celui du cryptage des informations. Clairement, une infrastructure de gestion des clés est requise afin de rendre possible l'utilisation d'en-têtes d'authentification et de cryptage. Cependant, cet aspect n'est pas encore réellement au point d'autant plus que l'effet pervers de ces techniques de sécurité est l'ajout de coûts supplémentaires et la baisse des performances du système.\nAvant d'étudier les différents mécanismes de sécurité mis en œuvre, il convient de définir un certain nombre de concepts.\nL’authentification : Elle permet de savoir si la donnée reçue est la même que celle envoyée et, de la même façon, si le demandeur désiré est bien identifié.\nL'intégrité : Elle assure la bonne transmission de la donnée, de sa source à sa destination sans aucune altération intermédiaire.\nparticipants puissent identifier ce qui a bien été envoyé.\nLe cryptage : Il s'agit d'un mécanisme communément utilisé pour permettre la confidentialité des informations.\nSAID : ou encore « Security Association Identifier »\nSecurity Association : L'ensemble des informations de sécurité relatives à la connexion d'un réseau donné ou à un ensemble de connexions ; ce qui inclue des clés de cryptage, des clés de durée de vie, des algorithmes, des degrés de sensibilité (non-classé, secret, propriétaire), mais aussi des services de sécurité (authentication-only, Transport-Mode Encryption, IP-Mode Encryption) ou toutes les autres possibilités envisageables.\nL'analyse du trafic : Elle correspond à une sorte d'attaque du réseau où l'adversaire est capable de faire des déductions sur le réseau lui-même grâce à l'analyse des données repérées sur le trafic (telles que la fréquence de transmission, qui parle à qui, la taille des paquets, le Flow IDentifier utilisé, etc.).\nLe premier objectif est d'obtenir des mécanismes de sécurité sûrs et disponibles pour tous les utilisateurs qui le désirent. Les algorithmes développés pour ces fonctionnalités ne doivent, bien entendu, pas affecter les autres aspects de l'implémentation IP. Il existe deux mécanismes de sécurité dans IPv6. Le premier est le mécanisme de l'en-tête d'authentification (Authentication Header) ; le second, une technique d'encapsulation affectée à la sécurité appelée ESP (Encapsulating Security Payload) permettant l'intégrité, l'authentification et la confidentialité. Cependant, les mécanismes de sécurité IPv6 ne sont pas efficaces face à des attaques de type analyse du trafic, pour le moment.\nL’en-tête d'authentification IPv6 cherche à rendre possibles l'intégrité et l'authentification des datagrammes IPv6. Ceci est obtenu par la mise en place d'une fonction d'authentification du cryptage sur le datagramme IPv6 ainsi que l'utilisation d'une clé secrète d'authentification. L'utilisateur qui émet inclut des données d'authentification dans les paquets IPv6 à traiter ; quant à l'usager qui les reçoit, il vérifie la justesse des données d'authentification. Certains champs de l'en-tête, qui évoluent lors de la transition (cas du champ Hop Limit), sont omis lors de l'authentification. Cependant, cette omission n'a pas de véritables conséquences sur la sécurité elle-même. La non-répudiation peut devenir nécessaire pour certains algorithmes d'authentification utilisant l'en-tête d'authentification (par exemple, les algorithmes asymétriques lorsque les clés de l'émetteur et du récepteur sont utilisées lors de la procédure de calcul de l'authentification). La confidentialité et la protection de l'analyse du trafic ne sont pas traitées par le mécanisme de l'en-tête d'authentification. Ainsi, les informations d'authentification sont analysées à partir des champs du datagramme IPv6 qui n'évoluent pas durant son transfert de la source à la destination. Tous les éléments (en-têtes, données, etc.) sont intégrés à l'analyse. La seule exception concerne certains champs comme le « nombre de saut » (en-tête IPv6) ou l’« adresse suivante » (en-tête de routage IPv6) qui sont omis. En outre, il est fort probable que le mécanisme de l'en-tête d'authentification risque d'accroître les coûts du processus IPv6 ainsi que l'attente de la communication. Enfin, le mécanisme de l'en-tête d'authentification apporte une véritable sécurité dans l'Internet sans affecter l'exportabilité des données ni augmenter trop significativement les coûts d'implémentation. Il est, bien entendu, fortement recommandé d'utiliser ce mécanisme de sécurité de l'origine à la destination finale. Toutes les stations de travail IPv6-only doivent implémenter la technique de l'en-tête d'authentification avec au minimum l'algorithme MD5 utilisant une clé de 128 bits sachant que d'autres algorithmes pourront être implémentés. Nous ne développerons pas davantage cette technique du fait de l'absence actuelle d'une documentation publique et détaillée sur ce problème. En outre, nous avons présenté l'en-tête d'authentification précédemment (cf. V.F). Un autre mécanisme de sécurité est proposé avec le système ESP.\nESP (ou l’en-tête de confidentialité) pour IPv6 permet d'apporter l'intégrité, l'authentification et la confidentialité dans les datagrammes IPv6. Ceci s'obtient soit par l'encapsulation d'un datagramme IPv6 dans son intégralité, soit par le cryptage de la majorité des composants ESP au niveau de l'en-tête IPv6 sachant que la partie non codée de l'en-tête est utilisée afin de transporter les données protégées à travers le réseau. Le destinataire du datagramme enlève, se débarrasse de l'en-tête et des options IPv6 non codées, décrypte les éléments ESP, traite puis retire les en-têtes ESP ; enfin, il obtient le datagramme IPv6 d'origine décodé ou la donnée de spécification normale du protocole IPv6.\nDescription des modèles ESP :\nIl existe deux modèles ESP. Le premier, connu comme un modèle IP (IP-mode), encapsule le datagramme IP au sein de l'en-tête ESP. Le second modèle ou Transport-mode, encapsule généralement une structure UDP ou TCP dans IP et non l'en-tête IPv6.\nUtilisation d’ESP :\nESP évolue soit entre deux stations de travail, soit entre une station et un gateway (passerelle) de sécurité, soit encore entre deux gateways de sécurité. Les gateways de sécurité permettent à des réseaux correctement reliés à ces derniers de ne pas se préoccuper du cryptage et d'éviter ainsi l'accroissement des coûts monétaires et la baisse des performances dus au cryptage tout en bénéficiant de la fonction de confidentialité. Lorsque les stations de travail implémentent directement ESP sans l'intermédiaire des gateways de sécurité, il leur est alors possible d'utiliser le Transport-mode. Ce mode réduit à la fois la largeur de bande consommée et le coût du protocole pour l'utilisateur qui n'a pas besoin de garder confidentielle l'intégralité du datagramme IPv6.\nLes impacts d’ESP sur la performance :\nLe mécanisme ESP a des impacts notables sur les performances du réseau. En effet, la mise en œuvre du protocole s'avère plus complexe si la technique ESP est utilisée dans la mesure où elle requiert davantage de temps et de puissance de la part processus. L'accroissement du retard est dû au cryptage et au décryptage de chaque datagramme IPv6 contenant ESP. Les conséquences relatives au coût sont variables selon les spécificités de l'implémentation telles que l'algorithme de cryptage utilisé, la taille de la clé, etc. Pour ces deux raisons, il est probable que les utilisateurs préféreront utiliser le mécanisme de l'en-tête d'authentification (Header Authentication) à la place de la technique ESP. En outre, afin d'assurer l'interopérabilité au sein du monde Internet, toutes les implémentations ESP pour IPv6 doivent accepter l'utilisation de Data Encryption Standard (DES) dans le mode Clipher-Block Chaining (CBC) ; cependant, d'autres modes et algorithmes peuvent être rajoutés. Nous avons proposé une présentation de l'en-tête de confidentialité (technique ESP) précédemment (cf. V.G)\nIl est possible de combiner à la fois les mécanismes Authentication Header IPv6 et ESP pour IPv6 afin d'obtenir le niveau de sécurité désiré. La technique de l'en-tête d'authentification permet toujours l'intégrité et l'authentification ainsi que la non-répudiation en utilisant certains algorithmes (RSA). Le mécanisme ESP fournit toujours l'intégrité et la confidentialité mais aussi l'authentification via des algorithmes spécifiques de cryptage.\nAinsi, le mélange des deux mécanismes permet de profiter véritablement de tous les éléments de sécurité : intégrité, authentification, non-répudiation et confidentialité. D'autres mécanismes de sécurité permettent aussi de se protéger contre l'analyse de trafic, il faut les implémenter au niveau de la couche IP.\nLe protocole de gestion des clés couplé à d'autres mécanismes de sécurité via SAID peut être utilisé pour IPv6. IPv6 n'est pas destiné à fournir une gestion des clés de type « in-band », où les données de gestion des clés sont portées par un en-tête IPv6 spécifique. En revanche, IPv6 utilisera dans un premier temps une gestion des clés de type « out-of-band » où les données de gestion des clés sont portées par un protocole de couche supérieure tel que UDP ou TCP sur un numéro de port spécifique. De manière générale, ceci permet le découpage du mécanisme de gestion des clés pour d'autres systèmes de sécurité ainsi que la substitution de nouvelles méthodes de gestion des clés (à la place des anciennes) sans avoir à modifier tous les autres outils de sécurité. Nous allons brièvement explorer les techniques de gestion des clés.\nLa forme la plus simple de gestion des clés est la gestion manuelle des clés où un individu configure manuellement chaque système avec sa propre clé mais aussi les clés des autres systèmes de communication. Ceci s'avère relativement pratique dans un environnement statique et de petite taille. En prenant l'exemple d'un environnement réseau de type LAN, au sein d'un simple domaine administratif, il est pratique de configurer les clés de chaque routeur de telle sorte que les données routées puissent être protégées et qu'il soit possible de réduire le risque d'intrusions étrangères au sein d'un routeur. Cependant, ce n'est pas une approche viable à moyen ou long terme.\nLe déploiement et l'utilisation des fonctions de sécurité dans IPv6 nécessitent un protocole de gestion des clés au standard Internet. A l'origine, un tel protocole devait proposer une gamme de services dans le monde Internet et pas seulement se réserver à la sécurité dans IPv6. Il existe des travaux en cours afin d'ajouter des clés signées sur des stations de travail via DNS ; les clés DNS permettant d'authentifier les messages de gestion des clés par rapport aux autres éléments de la gestion des clés utilisant un algorithme asymétrique. Il existe deux approches de la technique de clé (keying) pour IPv6. La première approche appelée « host-to-host keying » autorise tous les utilisateurs de la station 1 puissent partager la même clé sur le trafic destiné à tous les utilisateurs de la station 2. La seconde, appelée « user- to-user keying », laisse la possibilité à l'utilisateur A sur la station 1 d'avoir une clé de session unique avec l'utilisateur B sur la station 2 qui ne soit pas partagée avec les autres utilisateurs de station 1. Lorsque l'approche « host-to-host keying » est utilisée et que des utilisateurs mutuellement suspicieux sont présents, alors il est possible pour l'utilisateur A de déterminer la clé « host- to-host » via des méthodes comme l'attaque Chosen Plaintext. Si un utilisateur A a obtenu une clé « impropre » alors il peut lire le trafic crypté de l'utilisateur B voire le falsifier. Dans le cas\noù l'approche « user-to-user keying » est appliquée, le type d'attaque précédent est impossible. C'est donc cette dernière technique qu'il convient d'implémenter sur IPv6. Enfin, il convient de signaler qu'une « Multicast Key Distribution » est en cours d'élaboration pour IPv6. A l'heure actuelle, de nombreux travaux sur IPv6 sont en cours d'élaboration, nous pouvons cependant déjà signaler la présence de trois notions présentes dans IPv6 et pour lesquelles leur normalisation et admission définitives ne font aucun doute, à savoir : Authentication Header, Encapsulating Security Payload, Key Management.\nCet aspect sur la sécurité a pour principal objectif de donner un aperçu des différents mécanismes assurant la réduction des risques dans IPv6.\nLes Firewalls, absents dans la version actuelle d'Internet mais utilisés dans IPv6, vont permettre de corriger les suites d'en-têtes et de déterminer le protocole de transport (UDP ou TCP) ainsi que le numéro de port de ce protocole. La performance des Firewalls dans IPv6 ne devrait pas en être trop affectée dans la mesure où le format des en-têtes IPv6 facilite la procédure de correction. Les Firewalls utilisent le mécanisme de l'Authentication Header pour s'assurer l'authentification et la justesse des données utilisées pour les décisions de contrôle d'accès à savoir la source, la destination, le protocole de transport, le numéro de port. Cette authentification est impossible dans IPv4. Les organisations disposant de plusieurs sites interconnectés utilisant les services commerciaux proposés par IP peuvent sélectionner un Firewall crypté. Par exemple, si un Firewall crypté est placé entre la Société A et le fournisseur du service commercial IP, le Firewall fournit alors un tunnel crypté au sein de tous les sites de la Société A. Il lui est ainsi possible de crypter tout le trafic entre elle et ses fournisseurs, ses clients ou des tiers. Une telle pratique permet de protéger facilement le trafic d'un grand nombre d'organisations de type gouvernemental par exemple qui peuvent même mettre en œuvre un mécanisme de « fully encrypting Firewall » autorisant aussi bien un filtrage du trafic décrypté qu'un cryptage des paquets IP.\nLe mécanisme de l'Authentication Header, utilisé avec la méthode de gestion des clés appropriée, permet d'authentifier les paquets, comme nous l'avons évoqué précédemment. Le champ Flow Identifier dans IPv6 peut agir comme un Low-Level Identifier (LLID) ; par conséquent, la classification du paquet au sein des routeurs devient simple si le routeur est fourni avec la clé appropriée. Pour des raisons de performance, les routeurs authentifient des groupes de paquets. Ainsi, la qualité de service fournie est obtenue par l'utilisation du champ Flow ID conjointe à celle d'un protocole de réservation de ressources (tel que RSVP). Ainsi, la classification des paquets authentifiés s'obtient en s'assurant que chaque paquet reçoive bien la manipulation appropriée et correcte au sein des routeurs concernés.\nUn réseau « multi-level secure » (MLS) est un réseau unique utilisé pour communiquer des données selon différents degrés (non-classifié ou secret). De nombreux gouvernements trouvent beaucoup d'intérêt dans l'architecture réseau MLS. IPv6 devrait supporter ce type de structure. MLS nécessite l'utilisation des Mandatory Access Controls (MAC) que des utilisateurs normaux sont incapables de contrôler ou de violer. Le mécanisme de l'Authentication Header peut être utilisé aussi bien pour authentifier plusieurs stations de travail dans un niveau unique du réseau que pour garantir les décisions MAC dans un réseau à niveau multiple. Si les étiquettes IP sont utilisées et la confidentialité considérée comme non obligatoire au sein d'un environnement opérationnel particulier, le mécanisme de l'Authentication Header permet l'authentification du paquet dans son intégralité, incluant un cryptage obligatoire du degré de sensibilité (non-classifié ou secret) de l'en-tête IPv6 et des données de l'utilisateur. La technique ESP peut être combinée avec des politiques de clé appropriées pour garantir un réseau « multi-level secure » complet ainsi qu'un ensemble d'algorithmes appropriés. Dans ce cas, chaque clé doit être utilisée pour un degré de sensibilité et un compartiment précis. Par exemple, la clé A peut être utilisée pour des paquets non-classifiés ; la clé B, pour des paquets secrets pour un trafic sans compartiment, etc. Le cryptage est une technique très pratique et souhaitable même dans un environnement bien protégé. L'algorithme de cryptage au standard Internet devrait être utilisable via une gestion des clés appropriée, afin de fournir de véritables Discretionary Access Controls (DAC) corrélés au degré de sensibilité des étiquettes, au-delà des seules possibilités MAC offertes pour le moment. Le développement d'un mécanisme de cryptage complet devrait être disponible pour toutes les communications futures. Cet exposé concernant la sécurité dans IPv6 est incomplet dans la mesure où cet aspect fait encore l'objet de travaux en cours.\nDe manière générale, il faut retenir pour l'instant que la qualité de service fournie par les nouveaux mécanismes développés dans IPv6 dépend totalement de l'efficacité des algorithmes de cryptage implémentés, de la justesse de l'implémentation de ces algorithmes, des clés à utiliser, de la sécurité du protocole de gestion des clés, de l'implémentation d'IPv6 et particulièrement de ses mécanismes de sécurité.\nEn outre, certains aspects propres à la sécurité (comme la protection contre l'analyse du trafic) ne sont pas encore fournis par les mécaniques abordés précédemment. L'utilisateur doit donc faire preuve d'une extrême vigilance.\nEnfin, quelques applications (comme le courrier électronique) nécessitent des applications de protection et de sécurité spécifiques qui ne sont pas du ressort des techniques de sécurité propres à IPv6 mais pour lesquels des RFC seront entièrement consacrées. Il nous semble désormais intéressant de nous préoccuper d'un aspect tout autant novateur dans IPv6 que la sécurité, à savoir la mobilité.\nLe concept de mobilité signifie, dans le cas présent, la séparation des identificateurs et des adresses, ces deux éléments possédant un format similaire. L'identificateur d'un nœud mobile ne change jamais quelque soit ses déplacements tandis que son adresse est spécifique à son point de rattachement à Internet. L'adresse est seulement utilisée pour le routage des paquets et non pour l'identification du nœud à l'inverse de l'identificateur qui peut même éventuellement servir d'adresse par défaut.\nDeux options ont été rajoutées dans les options de l'en-tête de type Hop-by-Hop afin de rendre possible la mobilité. L'une est utilisée pour la communication de données et l'autre pour le contrôle.\nTCP/UDP identifie un nœud par son identificateur et non son adresse. Afin d'optimiser le routage, chaque nœud dispose d'une partie cachée ou Address Mapping Table (AMT). IPv6 résout le problème de l'identificateur et de l'adresse en utilisant AMT, puis en renvoyant le paquet avec la prise en compte de son adresse complète.\nLes entrées AMT sont créées puis mises à jour en fonction de la réception ou de l'envoi de paquets selon les options de mobilité choisies après, bien entendu, l'authentification du paquet.\nCependant, avant d'aborder les différentes techniques développées pour la mobilité, il convient de définir un certain nombre de concepts.\nUn nœud : Il s'agit d'un terme général utilisé pour évoquer à la fois une station de travail et/ou un routeur.\nUn nœud mobile : C'est un nœud qui a la possibilité de changer de point de rattachement sur l'Internet.\nUne adresse : C'est un numéro qui spécifie le point de rattachement à l'Internet. Une adresse est attribuée à chaque interface réseau d'un nœud. Nous avons vu que, pour IPv6, la taille d'une adresse est de 128 bits. L'adresse d'une interface change lorsque le nœud se déplace sur un autre réseau.\nUn identificateur : C'est un numéro attribué à un nœud unique. Chaque nœud dispose de son propre identificateur indépendamment du nombre d'interfaces réseaux dont il bénéficie. Non seulement un identificateur est unique et définitif quel que soit le nœud de rattachement à l'Internet, mais il bénéficie du même format qu'une adresse classique ce qui lui permet éventuellement de se substituer à une adresse.\nUn réseau maison (home subnet) : Il s'agit du réseau indiqué par l'identificateur d'un nœud mobile.\nUne résolution d'adresse (address resolution) : C'est une fonction qui oriente l'identificateur vers l'adresse correspondante.\nUn « résolveur » d'adresse (address resolver) : C'est nœud qui utilise une résolution d'adresse. Il existe deux types de résolveurs d'adresses pour un nœud mobile.\n- le résolveur primaire : un résolveur d'adresse est connecté au réseau maison d'un nœud mobile. Un nœud mobile indique périodiquement le(s) résolveur(s) primaire(s) de son identificateur ainsi que son adresse courante.\n- le résolveur temporaire : dans le cas d'un résolveur d'adresse non connecté au réseau maison d'un nœud mobile, un résolveur temporaire crée et met à jour ses paquets AMT reçus ou envoyés (avec l'option mobile dans l'en-tête).\nAddress Mapping Table (AMT) : Une table constituée d'entrées pour chacune desquelles il y a l'information de routage entre l'identificateur et l'adresse. Chaque nœud doit disposer d'une AMT pour la résolution d'adresse.\nAprès ce développement sur la terminologie spécifique à la mobilité, nous sommes en mesure d'aborder la description des formats spécifiques à la mobilité.\nB. Les formats d’en-tête pour l'option de mobilité\nDeux options pour la mobilité sont possibles via les propriétés de l'en-tête IPv6 Hop-by-Hop. La raison principale pour laquelle ces options sont inclues dans l'en-tête IPv6 Hop-by-Hop est la possibilité de créer et de mettre à jour des entrées AMT sur chaque nœud le long du chemin suivi par le paquet envoyé.\nOption Type : Ce champ prend pour valeur 0x2?, ce qui signifie que cette option ne relève pas de la propriété d'évaluation de l'intégrité obtenue via l'en-tête d'authentification dans la mesure où les données de l'option peuvent évoluer.\nOption Data Length : La longueur est de 64 octets.\nSource Identifier : Ce champ dont la taille est de 128 bits identifie uniquement le nœud source sans considérer sa localisation (c'est-à-dire en-dehors de l'adresse source de l'en-tête\nSource Address Version : Ce champ dont la taille est de 32 bits signale le numéro de version des identificateurs et adresses sources. Cette information doit être invariablement incrémentée à chaque nouvelle adresse attribuée.\nHolding Time : Ce champ dont la taille est de 32 bits signale le temps nécessaire, en secondes, durant lequel un nœud conserve l'entrée AMT du nœud source du paquet considéré.\nTimestamp : Ce champ dont la taille est de 32 bits signale le temps nécessaire au nœud, en\nsecondes, pour transmettre un paquet.\nAuthentication Data : Ce champ dont la taille est de 128 bits authentifie, en fournissant le\nrésultat de l'évaluation de l'algorithme MD5, le nœud source du paquet et garantie l'intégrité\nde l'option de mobilité pour les données.\nDestination Identifier : Ce champ dont la taille est de 128 bits identifie uniquement le nœud\nde destination final sans se préoccuper de sa localisation (c'est-à-dire en-dehors de l'adresse\ndestination de l'en-tête IPv6).\nDestination Address Version : Ce champ dont la taille est de 32 bits signale le numéro de\nversion des identificateurs et adresses destinations.\nOption Type : Ce champ prend pour valeur 0x0?, ce qui signifie que cette option relève de\nla propriété d'évaluation de l'intégrité obtenue via l'en-tête d'authentification.\nOption Data Length : La longueur est de 108 octets.\nIdentifier : Ce champ dont la taille est de 128 bits identifie uniquement le nœud pour lequel l'entrée AMT doit être créée ou mise à jour.\nAddress : Ce champ identifie le nœud pour lequel l'entrée AMT doit être créée ou mise à jour.\nAddress Version : Ce champ dont la taille est de 32 bits signale le numéro de version des identificateurs et adresses.\nHolding Time : Ce champ dont la taille est de 32 bits signale le temps nécessaire, en secondes, durant lequel un nœud conserve l'entrée AMT du nœud désigné par le champ identificateur (Identifier).\nTimestamp : Ce champ dont la taille est de 32 bits signale le temps nécessaire, en secondes, au nœud source pour transmettre un paquet. Ce champ permet aussi de prévenir les attaques récidivistes.\nAuthentication Data : Ce champ authentifie, en fournissant le résultat de l'évaluation de l'algorithme MD5 et/ou la signature digitale RSA, et garantie l'intégrité de l'option de mobilité pour les données.\nQuelques explications s'avèrent utiles afin de mieux appréhender le mécanisme AMT.\nStatus : Il s'agit des drapeaux que montre le statut de l'entrée AMT. Les trois drapeaux sont les suivants :\n- invalid : l'entrée AMT est invalide si le drapeau est activé « on », la raison pour laquelle cette entrée AMT est invalide est de détecter d'une entrée AMT sur un autre nœud ;\n- home : le nœud qui permet l'entrée AMT est connecté au réseau maison du nœud désigné par cette entrée AMT.\n- local : le nœud désigné par l'entrée AMT est connecté au même réseau si le drapeau est activé « on ».\nIdentifier : Ce champ représente la clé de l'entrée.\nAddress : L'adresse courante du nœud désigné par le champ Identifier.\nAddress Version : Le numéro de version de l'identificateur et de l'adresse.\nHolding Time : La valeur de ce champ est périodiquement décrémentée. L'entrée est détruite lorsque la valeur arrive à zéro.\nTimestamp : Ce champ permet de mesurer le temps nécessaire à l'option de mobilité qui crée et met à jour l'entrée.\nAuthentification Data : Ce champ permet d'authentifier les données de l'option de mobilité qui crée et de met à jour l'entrée.\nLes options de mobilité utilisent deux méthodes d'authentification, « keyed MD5 » et « RSA digital signature ».\nKeyed MD5 est utilisée dans le cadre de l'authentification end-to-end d'un paquet via l'option de mobilité pour les données utilisateurs ce qui nécessite de partager une clé secrète commune entre le nœud authentifiant et le nœud authentifié. La taille de la clé est de 128 bits, les calculs couvrent les champs suivants : Source Address (dans l'en-tête IPv6), Source Identifier, Source Address Version, Holding Time et Timestamp.\nLa méthode RSA digital signature est utilisée pour l'authentification de nœuds intermédiaires utilisés pour l'envoi de paquets avec l'option de mobilité pour le contrôle. La taille de la clé est de 512 bits, les calculs couvrent les champs suivants : Identifier, Address, Address Version, Holding Time et Timestamp.\nLorsqu'un nœud est connecté à un réseau, il lui est attribué une adresse IPv6 temporaire dans le sous réseau par le mécanisme d'auto-configuration d'adresses. A l'inverse, l'identificateur du nœud mobile ne change pas. Le nœud mobile transfert un paquet IPv6 via l'option de mobilité pour le contrôle située dans son réseau maison. Lors de toute cette procédure, les entrées AMT pour le nœud mobile sont créées et mises à jour à la fois sur les nœuds intermédiaires et ceux du réseau maison.\nLorsqu'un nœud mobile est connecté à un réseau, il transmet un paquet IPv6 via l'option de mobilité pour le contrôle à son réseau maison. Chaque champ de ce réseau est rempli de la manière suivante.\nIdentifier : l'identificateur du nœud mobile. Address : l'adresse temporaire IPv6 de l'interface utilisée. Address Version : le numéro de version de l'adresse et de l'identificateur IPv6 temporaires. Holding Time : le temps, en secondes, pour lequel l'entrée AMT du nœud mobile doit être conservé. Timestamp : l'instant auquel le paquet est transmis. Authentication Data : la signature digitale RSA qui couvre les cinq champs précédents.\nLorsqu'un nœud intermédiaire reçoit un paquet via l'option de mobilité pour le contrôle, il peut exécuter les procédures suivantes après ou avant l'envoi des paquets.\nAuthentification : le nœud intermédiaire authentifie le paquet s'il connaît la clé publique du nœud mobile spécifié par le champ Identifier de l'option de mobilité. Si l'authentification réussit alors la modification AMT est exécutée.\nModification AMT : le nœud intermédiaire crée une entrée AMT pour le nœud mobile spécifié par le champ Identifier de l'option de mobilité s'il ne la connaît pas déjà ; ou bien, il met à jour l'entrée AMT existante à condition qu'elle ne soit pas obsolète (le numéro de l'option de mobilité ne doit jamais être plus grand que celui de l'entrée AMT).\nDans le cas où l'entrée AMT est obsolète, le nœud intermédiaire peut diffuser le paquet reçu à toutes ses interfaces.\n3. Les procédures utilisées sur un nœud situé à la frontière (Boundary Node)\ndu réseau maison\nLorsqu'un paquet avec une option de mobilité pour le contrôle est reçu, un nœud situé à la frontière du réseau maison du nœud mobile désigné par le champ Identifier de l'option exécute les procédures d'authentification et de modification AMT, puis diffuse le paquet dans le réseau maison s'il s'agit d'un réseau de type diffusion. Si le nœud situé à la frontière dispose d'une entrée AMT obsolète, il transmet alors le paquet à l'adresse désignée par le champ Address de l'entrée AMT obsolète.\nDans les données de communication, l'option de mobilité pour les données des utilisateurs est intégrée dans chaque paquet IPv6. TCP/UDP désigne le nœud de destination avec l'identificateur. La résolution d'adresse pour le nœud de destination est exécutée soit au niveau du nœud source, soit au niveau du nœud intermédiaire, ou bien au niveau d'un nœud localisé au sein du réseau maison du nœud de destination, puis le paquet est routé vers le nœud de destination.\nLe nœud source crée un paquet IPv6 via l'option de mobilité pour les données des utilisateurs. Dans l'option, les champs relatifs au nœud source (Source Identifier, Source Address Version, Holding Time et Timestamp) sont remplis avec les valeurs appropriées, puis les données d'authentification sont calculées et attribuées au champ Authentication Data.\nUne requête de transmission de la couche supérieure précise le nœud de destination et son identificateur (champ Destination Identifier) mais pas l'adresse. Le nœud source essaie de résoudre la correspondance de l'identificateur et de l'adresse grâce à la technique AMT. Si l'entrée AMT pour le nœud de destination existe, l'adresse et son numéro de version sont attribués respectivement au champ de destination de l'en-tête IPv6 ainsi qu'au champ du numéro de version de l'adresse de destination de l'option.\nIl existe deux procédures dans le cas d'un nœud intermédiaire avec l'option de mobilité des données des utilisateurs, à savoir la modification AMT et la résolution d'adresse.\nLors de la modification AMT, l'entrée AMT pour le nœud mobile désigné par le champ Source Identifier de l'option peut être créée ou modifiée. Dans un premier temps, le nœud intermédiaire authentifie le paquet si ce dernier connaît la clé commune du nœud source. Si l'authentification réussit, les procédures suivantes sont exécutées. Si une entrée AMT pour le nœud mobile désigné par le champ Source Identifier de l'option n'existe pas, elle est alors créée. S'il n'y a pas d'entrée AMT (information obsolète), alors des modifications sont réalisées en accord avec les valeurs de l'option.\nDans le cas de la résolution d'adresse, l'adresse de destination dans l'en-tête IPv6 et le numéro de version de l'adresse de destination de l'option peuvent être modifiés. Si l'entrée AMT pour le nœud de destination du paquet existe, alors il faut comparer le numéro de version de l'adresse de destination du paquet avec le numéro de version de l'adresse de l'entrée. Si l'entrée AMT dispose d'informations plus récentes, alors le champ Destination Address de l'en-tête IPv6 et le numéro de version de l'adresse de destination de l'option sont modifiés conformément à l'entrée.\nLe nœud de destination exécute la procédure de modification AMT décrite ci-dessus puis la signale à la couche supérieure de réception du paquet avec l'identificateur du nœud source mais pas son adresse.\nLors de sa conception, IPv6 devait logiquement être considéré comme l'évolution normale de l'Internet facilitée par son entière compatibilité avec IPv4 et, par conséquent connaître un déploiement stratégique très rapide. Or, la transition vers IPv6 sera vraisemblablement longue.\nEn effet, si dans les organismes de recherche, les travaux sur IPv6 semblent très convaincants, il convient de bénéficier d'un autre soutien et non des moindres, à savoir celui des grands constructeurs, qui restent encore prudents.\nDès lors la question qui émerge est de savoir qui doit migrer vers IPv6 et quand. La réponse est naturellement liée aux priorités de chacun, mais aussi aux possibilités nouvelles offertes par IPv6 et qui pour certaines d'entre elles au moins vont probablement devenir essentielles aux applications courantes de demain : applications de vidéoconférences ou de temps réel, nécessitant une qualité de service garantie, la configuration automatique des équipements, la sécurité des données transportées…\nAdresse (address) : un identifiant de la couche Ipv6 pour une interface ou un groupe d'interfaces.\nICMPv6 : (Internet Message Control Protocol, ICMP) le protocole de contrôle d’IP revu pour IPv6 (détection d’erreurs, test, configuration automatique des équipements).\nIAB : (Internet Architecture Board) l’IAB fournit une supervision de l’architecture de l’Internet et de ses protocoles.\nIETF : (Internet Engineering Task Force) l’organisme de standardisation de l’Internet.\nInterface : un attachement d'un nœud à une liaison.\nLiaison (link) : un moyen de communication ou médium sur lequel les nœuds peuvent communiquer avec la couche liaison (la couche immédiatement sous IPv6).\nMTU de liaison (link MTU) : l'unité de transmission maximale (Maximum Transmission Unit - MTU), c'est à dire la taille maximale du paquet en octets, qui peut être acheminé en un seul "morceau" sur une liaison (un paquet étant composé d'un en-ête IPv6 et de son "payload").\nMTU de chemin (path MTU) : le plus petit MTU de liaison de toutes les liaisons que compose un chemin entre un nœud source et un nœud de destination.\nNœud (node) : un module protocolaire qui implémente IPv6.\nRFC : (Request For Comments) ce sont les documents officiels de l’Internet ; ils sont disponibles gratuitement sur le réseau. En France, ils sont notamment disponibles sur le site miroir officiel primaire ftp://www.imag.fr/pub/archive/IETF/rfc/.\nRouter (routeur) : un nœud qui transmet des paquets IPv6 non explicitement adressés à lui- même.\nStation (host) : tout nœud qui n'est pas un routeur.\nVoisins (neighbors) : nœuds rattachés à la même liaison.\nIPv6 (Théorie et pratique) par Gisèle CIZAULT (Ed. O’REILLY)\nIPv6 par Bernard TUY (cours de l'UREC) :\nDocuments similaires à IPv6 Cours UREC_1999\nConf Intf Lan\nCorrige QCM materiel