IPv6 - Définition

Fonctionnement d'IPv6

Le fonctionnement d'IPv6 est très similaire à celui d'IPv4. Les protocoles TCP et UDP sont pratiquement inchangés. Ceci est résumé par la formule « 96 bits de plus, rien de magique ».

Adresses IPv6

Une adresse IPv6 est longue de 128 bits, soit 16 octets, contre 32 bits pour IPv4. La notation décimale pointée employée pour les adresses IPv4 (par exemple 172.31.128.1) est abandonnée au profit d'une écriture hexadécimale, où les 8 groupes de 2 octets (16 bits par groupe) sont séparés par un signe deux-points :

2001:0db8:0000:85a3:0000:0000:ac1f:8001

On peut omettre les zéros à gauche dans chaque groupe, et remplacer une seule séquence de zéros par un signe « :: ». L'adresse peut être abrégée en :

2001:db8:0:85a3::ac1f:8001

Les réseaux sont notés en utilisant la notation CIDR : la première adresse du réseau est suivie par une barre oblique et un nombre qui indique la taille en bits du réseau. La partie commune des adresses est appelée préfixe. Par exemple :

• Le préfixe 2001:db8:85a3::/48 représente l'ensemble des adresses qui commence à 2001:db8:85a3:0:0:0:0:0 et finit à 2001:db8:85a3:ffff:ffff:ffff:ffff:ffff.
• Le préfixe fc00::/7 représente les adresses de fc00:0:0:0:0:0:0:0 à fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Certains préfixes d'adresses IPv6 jouent des rôles particuliers :

Type d'adresses IPv6

Préfixe	Description
::/8	Adresses réservées
2000::/3	Adresses unicast routables sur Internet
fc00::/7	Adresses locales uniques
fe80::/10	Adresses locales lien
ff00::/8	Adresses multicast

Parmi les adresses réservées :

•  ::/128 est l'adresse non spécifiée. On peut la trouver comme adresse source dans une phase d'acquisition de l'adresse réseau.
•  ::1/128 est l'adresse localhost, semblable à 127.0.0.1 en IPv4

Parmi les adresses de 2000::/3 sont distinguées :

• Les adresses permanentes (2001::/16) ouvertes à la réservation depuis 1999 ;
  • 2001::/32 est utilisé pour Teredo ;
  • 2001:db8::/32 est réservé pour la documentation par la RFC 3849 ;
• Les adresses 6to4 (2002::/16) permettant d'acheminer le trafic IPv6 via un ou plusieurs réseaux IPv4 ;
• Toutes les autres adresses routables (plus des trois quarts) sont actuellement réservées pour usage ultérieur.

Structure de l'adresse IPv6 unicast globale

Structure des adresses unicast globales

champ	préfixe	sous-réseau	interface
bits	48	16	64

Le préfixe représente la topologie publique de l'adresse, autrement dit celle qui est vue à l'extérieur d'un site. La partie sous-réseau constitue la topologie privée (RFC 3587).

Scope

Le scope d'une adresse IPv6 consiste en son domaine de validité et d'unicité.

On distingue :

• Les adresses unicast :
  • l'adresse loopback ::1/128 a une validité limitée à l'hôte,
  • les adresses link-local, uniques sur un lien donné,
  • les autres adresses, y compris les adresses locales uniques, ont un scope global, c'est-à-dire qu'elles sont uniques dans le monde et peuvent être utilisées pour communiquer avec d'autres adresses globalement uniques, ou des adresses link-local sur des liens directement connectés,
• Les adresses anycast, dont le scope est identique aux adresses unicast,
• Les adresses multicast ff00::/8, pour lesquels les bits 13 à 16 déterminent le scope : local, lien, organisation ou global.

Toutes les interfaces où IPv6 est actif ont au moins une adresse de scope link-local (fe80::/10).

Indice de zone

Il peut exister plusieurs adresses link-local sur des liaisons différentes d'une même machine, on lève les ambiguïtés en fournissant un indice de zone (RFC 4007) qu'on ajoute à l'adresse après un signe pourcent : fe80::3%eth0 correspondra à l'adresse link-local fe80::3 sur l'interface eth0 par exemple.

Attribution des adresses IPv6

Dans l'espace d'adresse unicast global (2000::/3), l'IANA assigne des blocs /23 au registres Internet régionaux, comme le RIPE NCC en Europe. Ces derniers distribuent des préfixes /32 aux registres Internet locaux (FAI) qui les assignent ensuite sous forme de bloc /48 ou /64 à leurs clients.

Chaque client se voit attribuer soit un bloc /64 (un seul sous-réseau), soit un bloc /48 (65 536 sous-réseaux), chacun des sous-réseaux pouvant accueillir un nombre d'hôtes virtuellement illimité (2⁶⁴). Dans le bloc 2000::/3 qui représente 1/8^e de l'espace d'adressage disponible en IPv6, on peut donc créer 2²⁹, soit 500 millions de blocs /32 pour des fournisseurs d'accès à Internet, et 2⁴⁵, soit 35 milliards de réseaux d'entreprise.

En-tête IPv6

L'en-tête du packet IPv6 est de taille fixe à 40 octets, tandis qu'en IPv4 la taille minimale est de 20 octets, des options pouvant la porter jusqu'à 60 octets, ces options demeurant rares en pratique.

La signification des champs est la suivante :

• Version (4 bits) : fixé à la valeur du numéro de protocole internet, 6
• Traffic Class (8 bits) : utilisé dans la qualité de service.
• Flow Label (20 bits) : permet le marquage d'un flux pour un traitement différencié dans le réseau.
• Payload length (16 bits) : taille de la charge utile en octets.
• Next Header (8 bits) : identifie le type de header qui suit immédiatement selon la même convention qu'IPv4.
• Hop Limit (8 bits) : décrémenté de 1 par chaque routeur, le paquet est détruit si ce champ atteint 0 en transit.
• Source Address (128 bits) : adresse source
• Destination Address (128 bits) : adresse destination.

Il est possible qu'un ou plusieurs en-têtes d'extension suivent l'en-tête IPv6. L'en-tête de routage permet par exemple à la source de spécifier un chemin déterminé à suivre.

Comparaison avec IPv4 

• la taille de l'en-tête est fixe, le champ IHL (IP Header Length) est donc inutile,
• il n'y a pas de somme de contrôle sur l'en-tête. En IPv4, cette somme de contrôle inclut le champ TTL et oblige les routeurs à le recalculer dans la mesure ou le TTL est décrémenté. Ceci simplifie le traitement des paquets par les routeurs.
• les éventuelles informations relatives à la fragmentation sont repoussées dans un en-tête qui suit.
• le champ Time to Live est renommé en Hop Limit, reflétant la pratique (la RFC 791 prévoyait en effet que le champ TTL reflétait le temps en secondes).

Fragmentation et option jumbo

En IPv4, les routeurs qui doivent transmettre un paquet dont la taille dépasse le MTU du lien de destination ont la tâche de le fragmenter, c'est-à-dire de le segmenter en plusieurs paquets IP plus petits. Cette opération complexe est coûteuse en termes de CPU pour le routeur ainsi que pour le système de destination et nuit à la performance des transferts, d'autre part les paquets fragmentés sont plus sensibles aux pertes : si un seul des fragments est perdu, l'ensemble du paquet initial doit être retransmis.

En IPv6, les routeurs intermédiaires ne fragmentent plus les paquets et renvoient un paquet ICMPv6 Packet Too Big en lieu et place, c'est alors la machine émettrice qui est responsable de fragmenter le paquet. L'utilisation du Path MTU discovery est cependant recommandé pour éviter toute fragmentation.

Ce changement permet de simplifier la tâche des routeurs, leur demandant moins de puissance de traitement.

La MTU minimale autorisée pour les liens a également été portée à 1 280 octets (contre 576 pour l'IPv4). Si des liens ne peuvent pas soutenir ce MTU minimal, il doit exister une couche de convergence chargée de fragmenter et de réassembler les paquets.

Comme pour IPv4, la taille maximale d'un paquet IPv6 hors en-tête est de 65535 octets. IPv6 dispose cependant d'une option jumbo (RFC 2675) permettant de porter la taille maximale d'un paquet à 4 Go et profiter ainsi des réseaux avec un MTU plus élevé.

En-têtes d'extension

L'en-tête IPv6 peut être suivi d'un certain nombre d'en-tête d'extensions. Ceux-ci se succèdent, chaque en-tête indiquant la nature du suivant. Quand ils sont présents, leur ordre est le suivant :

En-têtes d'extension IPv6

Nom	Type	Taille	Description	RFC
Options Hop-By-Hop	0	variable	Contient les options qui doivent être honorées par tous les routeurs de transit, par exemple l'option jumbogram.	RFC 2460, RFC 2675
Routage	43	variable	Permet de modifier le routage à partir de la source, qui est utilisé notamment par Mobile IPv6	RFC 2460, RFC 3775, RFC 5095
Fragment	44	64 bits	Contient les informations relatives à la fragmentation.	RFC 2460
Authentication Header (AH)	51	variable	Contient les informations nécessaires à l'authentification de l'en-tête, voir IPsec.	RFC 4302
Encapsulating Security Payload (ESP)	50	variable	Contient les information relatives au chiffrement du contenu, voir IPsec.	RFC 4303
Options de destination	60	variable	Options qui doivent être traitées par la destination finale.	RFC 2460
No Next Header	59	vide	Indique qu'il n'y a aucune charge utile qui suit.	RFC 2460

Les autres valeurs possibles suivent la même convention que le champ Protocol dans l'en-tête IPv4.

Neighbor Discovery Protocol

Le Neighbor Discovery Protocol (ND, RFC 2461) associe les adresses IPv6 a des adresses MAC sur un segment comme ARP pour IPv4. Il permet également de découvrir les routeurs et les préfixes routés, le MTU, de détecter les adresses dupliquées, les hôtes devenus inaccessibles et l'autoconfiguration des adresses et éventuellement les adresses des serveurs DNS récursifs (RDNSS, RFC 5006). Il est basé sur ICMPv6.

Assignation des adresses IPv6

Dans un sous-réseau, il existe plusieurs méthodes d'assigner des adresses :

Configuration manuelle 

l'administrateur fixe l'adresse. Les adresses constituées entièrement de 0 ou de 1 ne jouent pas de rôle particulier en IPv6.

Configuration automatique 

• autoconfiguration sans état (Stateless Address Autoconfiguration, SLAAC) basée sur l'adresse MAC qui utilise le Neighbor Discovery Protocol (NDP) (RFC 4862).
• autoconfiguration avec tirage pseudo aléatoire (RFC 4941),
• assignation par un serveur DHCPv6 (RFC 3315).

L'utilisation de l'adresse MAC d'une carte réseau pour construire une adresse IPv6 a suscité des inquiétudes quant à la protection des données personnelles dans la mesure où l'adresse MAC permet d'identifier de façon unique le matériel. Pour pallier cet inconvénient, il est possible d'utiliser des adresses temporaires générées de façon pseudo-aléatoire et modifiées régulièrement (RFC 4941) ou bien d'utiliser un service d'attribution automatique des adresses IPv6 par un serveur, de façon similaire à ce qui existe pour IPv4, avec DHCPv6.

Multicast

Le multicast, qui permet de diffuser un paquet à un groupe, fait partie des spécifications initiales d'IPv6. Cette fonctionnalité existe également en IPv4 où il a été ajouté par la RFC 988 en 1986.

Il n'y a plus d'adresse broadcast en IPv6, celle-ci étant remplacée par une adresse multicast spécifique à l'application désirée. Par exemple, l'adresse ff02::101 permet de contacter les serveurs NTP sur un lien. Les hôtes peuvent ainsi filtrer les paquets destinés à des protocoles ou des applications qu'ils n'utilisent pas, et ce sans devoir examiner le contenu du paquet.

Au niveau ethernet, une série de préfixes OUI est réservée aux adresses IPv6 multicast (33:33:xx). L'adresse MAC du groupe multicast consistera en ces 16 bits que l'on fait suivre par les 32 derniers bits de l'adresse IPv6 muticast. Par exemple, l'adresse ff02::3:2 correspondra à l'adresse MAC 33:33:00:03:00:02. Bien que de nombreux groupes multicast partagent la même adresse MAC, ceci permet déjà un filtrage efficace au niveau de la carte réseau.

Bien que la prise en charge de multicast au niveau des liens soit obligatoire pour IPv6, le routage des paquets multicast au-delà du segment requiert l'utilisation de protocoles de routage comme PIM, à la discrétion du fournisseur d'accès à Internet.

Le protocole Multicast Listener Discovery permet d'identifier les groupes actifs sur un segment, à l'instar d'IGMP pour IPv4.

Les commutateurs ethernet les plus simples traitent les trames multicast en les diffusant comme des trames broadcast. Ce comportement est amélioré avec MLD snooping qui limite la diffusion aux seuls hôtes manifestant un intérêt pour le groupe, à l'instar d'IGMP snooping pour IPv4.

Alors qu'en IPv4 il est difficile de réserver des adresses multicast globales, la RFC 3306 associe un bloc d'adresses multicast /96 pour chaque préfixe routable sur Internet, c'est-à-dire que chaque organisation dispose automatiquement de 4 milliards d'adresses multicast publiques. La RFC 3956 simplifie également la réalisation de points de rendez-vous pour les interconnexions multicast.

DNS

Dans le Domain Name System, les noms d'hôtes sont associés à des adresses IPv6 grâce à l'enregistrement AAAA.

      www.ipv6.ripe.net.                                                        IN   AAAA   2001:610:240:22::c100:68b      

L'enregistrement inverse est réalisé sous ip6.arpa en inversant l'adresse écrite sous forme canonique (RFC 3596) :

      b.8.6.0.0.0.1.c.0.0.0.0.0.0.0.0.2.2.0.0.0.4.2.0.0.1.6.0.1.0.0.2.ip6.arpa. IN   PTR    www.ipv6.ripe.net.      

La première mouture de la norme prévoyait d'utiliser le suffixe ip6.int.

Le mécanisme utilisé pour construire le nom de domaine inverse est similaire à celui employé en IPv4, à la différence que les points sont utilisés entre chaque nibble (groupe de 4 bits), ce qui allonge le domaine.

Les plus complexes bitlabels (RFC 2673), DNAME et A6 (RFC 2874), qui permettent de s'affranchir de la contrainte de la délégation sur une frontière de nibble, sont considérés comme expérimentaux et leur support est rare (RFC 3363).

La résolution inverse peut être utilisée par des systèmes de contrôle d'accès ainsi que par des outils de diagnostic comme traceroute.

Traduction d'adresse

Le recours à la traduction d'adresse est découragé en IPv6 pour préserver la transparence du réseau, son utilisation n'est plus nécessaire pour économiser des adresses.

IPv6 et mobilité

IPv6 prévoit des mécanismes pour conserver une même adresse IPv6 pour une machine pouvant être connectée à des réseaux différents, tout en évitant autant que possible le routage triangulaire.

Technologies de transition pour l'accès à l'Internet IPv6

Les adresses IPv4 et IPv6 ne sont pas compatibles, la communication entre un hôte ne disposant que d'adresses IPv6 et un hôte ne disposant que d'adresse IPv4 constitue donc un problème. La transition consiste à doter les hôtes IPv4 d'une double pile, c'est-à-dire à la fois d'adresses IPv6 et IPv4.

La manière la plus simple d'accéder à IPv6 est lors de l'abonnement de choisir un FAI qui offre de l'IPv6 nativement, c'est-à-dire sans recours à des tunnels.

À défaut, et pendant une phase de transition, il est possible d'obtenir une connectivité IPv6 via un tunnel. Les paquets IPv6 sont alors encapsulés dans des paquets IPv4, qui peuvent traverser le réseau du FAI jusqu'à un serveur qui prend en charge IPv6 et IPv4, et où ils sont décapsulés. Le recours à des tunnels, et donc à un réseau overlay, est de nature à nuire aux performances.

Tunnels statiques 

Plusieurs services du type « tunnel broker » sont disponibles, nécessitant en général une inscription. On peut citer SixXS, Freenet6, Hurricane Electric ou encore Renater.

Les protocoles utilisés peuvent être :

• 6in4 (RFC 4213) fait usage du numéro de protocole 41 d'IP et est donc parfois bloqué par des pare-feux et les NAT.
• AYIYA permet le transport sur UDP ou TCP et gère le changement d'adresse IP.
• GRE utilise le numéro de protocole 47.

Le Tunnel Setup Protocol (RFC 5572) facilite la création des tunnels et permet la mobilité et l'authentification. Le Tunnel Information and Control protocol, utilisé par AICCU (en), automatise la création des tunnels.

Tunnels automatiques 

• 6to4 (RFC 3056) si une adresse IPv4 publique (de préférence fixe) est disponible, 6to4 est simple à mettre en place. Pour l'accès aux adresses IPv6 hors du préfixe 2002::/16 (réservé pour 6to4), une adresse relais anycast est réservée, 192.88.99.1.
• 6rd (RFC 5569) est similaire au précédent. Il ne fait pas usage du préfixe 2002::/16 mais d'un préfixe spécifique au fournisseur d'accès.
• 6over4 (en) (RFC 2529) permet la connexion à travers un réseau IPv4 qui prend en charge multicast
• ISATAP (RFC 5214), une amélioration du précédent qui ne requiert pas le support multicast.
• Teredo (RFC 4380) utilisable dans un réseau d'adresses IPv4 privées, relié à Internet via un routeur assurant une traduction d'adresses. Une implémentation de Teredo fait partie de la pile IPv6 des systèmes Windows, et une implémentation pour Linux et les systèmes BSD est miredo.

Passerelles applicatives 

Il est possible de faire usage de serveurs qui disposent d'une double pile et qui font office de passerelle applicative (Application-Level gateway, ALG), un serveur proxy web par exemple.

NAT-PT combine la traduction d'adresse réseau et un serveur DNS pour permettre la communication entre des systèmes IPv4 et des systèmes IPv6. Il est défini dans la RFC 2766 mais a été rendu obsolète par la RFC 4966 en raison de problèmes causés.

Multihoming

Le multihoming consiste, pour un réseau, à disposer de plusieurs fournisseurs de transit dans le but d'augmenter la fiabilité de l'accès Internet. En IPv4, ceci est généralement accompli en disposant d'un numéro d'AS propre, d'une plage d'adresse IP de type Provider Independent (PI) et en utilisant BGP pour échanger des routes de façon dynamique avec chacun des fournisseurs d'accès.

Cette façon de réaliser le multihoming consomme des numéros d'AS et augmente la taille de la table de routage Internet en raison de préfixes PI qu'il n'est pas possible d'agréger.

La standardisation du multihoming en IPv6 a tardé, une des ambitions initiales de l'architecture IPv6 étant de n'utiliser que des adresses de type Provider Aggregatable (PA) pour réduire la taille de la table de routage Internet. Dans cette optique, le multihoming était réalisé en assignant autant d'adresses PA qu'il y a de fournisseurs, les mécanismes d'IPv6 comme l'assignation automatique et la durée de vie limitée des adresses facilitant les changements d'adresses liées aux changements de fournisseurs. Par conséquent, les registres Internet régionaux ne distribuaient pas de bloc PI pour IPv6 jusqu'à récemment.

En 2009, les RIR, comme le RIPE NCC, ont modifié leur politique en acceptant d'attribuer des blocs PI aux entreprises qui veulent se connecter à plusieurs fournisseurs, la taille minimale du bloc PI est de /48, alors que la taille des blocs PA est /32. Ceci permet de réaliser le multihoming de la même façon qu'en IPv4.

D'autre approches possibles sont basées sur la séparation de l'identificateur et du localisateur (Identifier / Locator Separation) :

• SHIM6 (en) (RFC 5533)
• Host Identity Protocol (en) (RFC 4423, RFC 5102)
• Stream Control Transmission Protocol
• GSE/8+8.
• Locator/Identifier Separation Protocol (LISP)

Ceci est un sujet de recherche confié au groupe de travail Routing Research de l'Internet Research Task Force (en).