1 Déc

IP V6

Ou en est-on en 2019 https://lafibre.info/ipv6/ipv6-barometre-2019/

Intro

Si vous êtes sur ce site, vous faites du réseau et vous avez les bases en adressage IPV4. Sinon vous pouvez toujours vous rendre ici.

Vous savez donc aussi qu’il n’y a plus d’adresses IPV4 et que nous passons -lentement- à IP V6, un protocole né dans les années 80 !

Le problème du passage fut la compatibilité des matériels actifs, des STA (PC et SE, périphériques et autres outils connectés), mais aujourd’hui la plupart des matériels sont compatibles.

Reste l’infrastructure en place en V4, mais rien n’empêche un passage progressif. Les habitudes aussi sont un frein car personne ne veut taper un ping en V6, mais personne ne voit que cette pratique n’a plus de raison d’être en V6. Et pour ça il faut des compétences et ce n’est pas vraiment le cas encore.

Afin de vous familiariser avec ce concept, nous allons voir 3 points principaux :

L’adressage, le protocole et les mécanismes de gestion.

Pour des informations plus détaillées

Adressage

L’adresse est un élément essentiel dans un réseau de communication. L’adresse se doit d’être unique. Elle identifie un nœud dans le réseau. Dans le cas de l’Internet, elle a une fonction supplémentaire, elle sert à le localiser. La localisation est utilisée pour décider de la remise directe ou de la recherche d’un intermédiaire qui saura délivrer les datagrammes, selon le principe du routage en « saut par saut ». En fait, elle ne varie qu’en cas de changement de prestataire IP ou de réorganisation de site.

L’usage de divers masques de taille «élastique» permet

  • d’une part, une certaine souplesse dans la définition et l’attribution des préfixes, une optimisation de l’espace d’adressage limitant le gaspillage des larges portions d’adresses, comparativement à IPv4;
  • et d’autre part, une optimisation du routage en facilitant sa hiérarchisation: les équipements des opérateurs de coeur de l’internet prennent leur décision de routage sur des préfixes courts, les «grandes directions». Les équipements de routage des opérateurs de distribution, en périphérie du réseau, routent sur des préfixes plus longs, ce qui a pour effet de contenir la taille des tables de routage de cœur du réseau dans des proportions raisonnables.

Durée de vie d’une adresse

IPv6 généralisant le plan d’adressage CIDR, les préfixes restent dans tous les cas la propriété des opérateurs. Il ne peuvent plus être attribués « à vie » aux équipements. Les adresses IPv6 sont donc « prêtées » aux interfaces des équipements. L’attribution d’une adresse globale à une interface
est faite temporairement. La durée du prêt est de 30 jours par défaut, mais modifiable bien sur. Une adresse de lien local a une durée de vie illimitée par contre.

Ecriture

Une adresse IPv6, écriture hexadécimale est longue de 128 bits, soit 16 octets,

  • 00100000 00000001 00001101 10111000 00000000 00000000 00000000 00000000 00000000 00001000 00001000 00000000 00100000 00001100 01000001 01111010

S’écrit en hexadécimal sous la forme suivante :

  • 20 01 0d b8 00 00 00 00 00 08 08 00 20 0C 41 7A
  • Ou 0x20010db80000000000080800200C417A

 Où les 8 groupes de 2 octets (16 bits par groupe) sont séparés par un signe deux-points :

  • 2001:0db8:0000:0000:0008:0800:200C:417A

Plusieurs champs nuls consécutifs peuvent être « abrégés » par l’abréviation  » ::  » (2 caractères ‘:’ successifs, sans espace).

Attention : pour éviter toute ambiguïté, cette abréviation ne peut être utilisée qu’une seule fois par adresse !

Exemple l’adresse peut également s’écrire
Une adresse unicast 2001:0db8:0:0:0:800:200c:417a 2001:db8::800:200c:417a
Une adresse multicast ff01:0:0:0:0:0:0:101 ff01::101
Adresse de bouclage (loopback address) 0:0:0:0:0:0:0:1 ::1
Adresse non spécifiée (unspecified address) 0:0:0:0:0:0:0:0 ::

Une même adresse IPv6 peut être représentée de plusieurs façons différentes,

  • 2001:db8::1:0:0:1
  •              2001:db8:0:0:1::1.

La RFC 5952 recommande une représentation canonique, concrètement, une adresse devrait être affichée selon la forme suivante :

  • Les zéros initiaux (non significatifs) doivent être supprimés.
  • L’indication d’une suite de champs nuls consécutifs « :: » doit être utilisée au maximum (sur la série nulle la plus longue). En cas d’égalité, on l’applique sur la première. Exemples :
    • 2001:db8:0:42:0:0:0:1 → 2001:db8:0:42::1
    • 2001:db8:0:0:42:0:0:1 → 2001:db8::42:0:0:1
  • Les chiffres hexadécimaux doivent être en minuscules.
  • Si le numéro de port (TCP ou UDP) doit être indiqué, l’usage de crochets encadrant l’adresse devient obligatoire. Auparavant, cet usage ne l’était que pour les URL.

Composition et préfixes

Les réseaux sont identifiés en utilisant la notation CIDR : la première adresse du réseau est suivie par une barre oblique « / » puis par un entier compris entre 0 et 128, lequel indique la longueur en bits du préfixe du réseau, à savoir de la partie commune des adresses déterminées par ledit réseau.

Par exemple :

Attention aux préfixes qui ne sont pas alignés sur une frontière de mots de 16 bits, d’octet ou de demi-octet

Dans le bloc 2000::/3 qui représente ⅛e de l’espace d’adressage disponible en IPv6, on peut donc créer 229, soit 500 millions de blocs /32 pour des fournisseurs d’accès à Internet, et 245, soit 35 000 milliards de réseaux d’entreprise typiques (/48).

Une autre difficulté provient du fait que le caractère « : » est significatif dans certains contextes, ce qui peut créer des ambiguïtés. C’est le cas des URL où il est utilisé comme séparateur entre l’adresse et le numéro de port :

Exemple: l’URL suivante est ambiguë: http://2001:db8:12::1:8000/ ; en effet, elle peut être interprétée de deux manières:

• le service web à l’écoute sur le port http par défaut (le port TCP 80 est le port implicite d’écoute du protocole HTTP) sur la machine d’adresse 2001:db8:12::1:8000
• les services web (protocole HTTP) à l’écoute sur le port TCP 8000 de la machine d’adresse 2001:db8:12::1

Pour lever cette ambiguïté, le RFC 3986 propose d’inclure l’adresse IPv6 entre [ ] (crochets ouvrant et fermant).

Portée

La portée (en anglais, le scope) d’une adresse IPv6 consiste en son domaine de validité et d’unicité, d’après la RFC 4007 .

On distingue :

  • Les adresses d’envoi individuel (unicast)
    • L’adresse loopback ::1/128 a une validité limitée à l’hôte; c’est l’adresse de bouclage (loopback en anglais);
    • Les adresses link-local, uniques sur un lien donné ;
    • Les autres adresses, y compris les adresses locales uniques, ont une portée globale, 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 d’envoi à la cantonade (anycast), dont la portée est identique aux adresses unicast ;
  • Les adresses d’envoi en diffusion groupée (multicast) ff00::/8, pour lesquels les bits 13 à 16 déterminent la portée : local, lien, organisation ou global.

Toutes les interfaces où IPv6 est actif ont au moins une adresse de portée link-local (fe80::/10); l’adresse notée fe80::/10 désigne l’envoi individuel sur liaison locale.

Type d’adresses IPv6  
Préfixe Description  
::/8 Adresses réservées  ::/128 est l’adresse non spécifiée.
On peut la trouver comme adresse source initiale, à l’instar de 0.0.0.0 en IPv4, dans une phase d’acquisition de l’adresse réseau ;  ::1/128 est l’adresse de boucle locale (dite aussi localhost).
Elle est semblable à 127.0.0.1 en IPv424.
2000::/3 Adresses unicast routables sur Internet de 2000:0:0:0:0:0:0:0 à 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
fc00::/7 Adresses locales uniques De fc00:0:0:0:0:0:0:0 à fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
fe80::/10 Adresses locales lien  Envoi individuel sur liaison locale de fe80:0:0:0:0:0:0:0 à febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff
ff00::/8 Adresses multicast Diffusion groupée.

Attribution des blocs d’adresses IPv6 – Hiérarchie

Dans l’espace d’adresse unicast global (2000::/3), l’IANA attribue des blocs dont la taille varie de /12 à /23 aux registres Internet régionaux, comme le RIPE NCC en Europe.

Ces derniers distribuent des préfixes /32 aux registres Internet locaux qui les attribuent ensuite sous forme de bloc /48 à /64 aux utilisateurs finaux (RFC 6177).

Structure de l’adresse IPv6 unicast globale

Le préfixe de routage global, de taille variable, représente la topologie publique de l’adresse, autrement dit celle qui est vue à l’extérieur d’un site.

Chaque utilisateur final se voit attribuer un bloc dont la taille varie de /64 (un seul sous-réseau) à /48 – pour les entreprises (65 536 sous-réseaux)

 chacun des sous-réseaux peut accueillir un nombre d’hôtes virtuellement illimité (264).

La partie sous-réseau constitue la topologie privée.

Pour les liens point-à-point, il est cependant possible d’utiliser un /127 (RFC 6164).

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.

Configuration des adresses IPv6

Construction d’une adresse d’interface EUI-64 modifiée à partir d’une adresse MAC.

https://upload.wikimedia.org/wikipedia/commons/thumb/c/ce/Ipv6_eui64.svg/290px-Ipv6_eui64.svg.png

Dans un sous-réseau, il existe plusieurs méthodes d’attribution 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

Sans état (Stateless Address Autoconfiguration, SLAAC) :

  • autoconfiguration avec tirage pseudo aléatoire, l’adresse change dans le temps (RFC 4941),
  • autoconfiguration basée sur une clé secrète et sur le préfixe réseau cette adresse sera nommée stable private, RFC 7217. Elle ne dévoile pas l’adresse MAC et est stable pour chaque préfixe réseau, c’est l’usage recommandé pour une adresse fixe
  • autoconfiguration basée sur l’adresse MAC (EUI-64), adresse stable mais machine facilement identifiable, usage déconseillé
  • utilisation d’adresses générées cryptographiquement, qui lient l’adresse à la clé publique du client et qui peuvent être utilisées par SEND.

Avec état :

  • attribution par un serveur DHCPv6 (RFC 3315).

En-tête

En-tête IPv6

https://upload.wikimedia.org/wikipedia/commons/thumb/a/ab/Ipv6_header.svg/290px-Ipv6_header.svg.png

En-tête IPv4

L’en-tête du paquet 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 demeurantes 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.
  • Le champ Durée de vie34[source insuffisante], Time to Live (TTL) est renommé en Hop Limit, reflétant la pratique, la RFC 79135 prévoyait en effet que le champ TTL reflétait le temps en secondes.
  • 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 où le TTL est décrémenté. Ceci simplifie le traitement des paquets par les routeurs.
  • Le champ Payload length n’inclut pas la taille de l’en-tête standard, contrairement au champ Total length d’IPv4. Tous les en-têtes optionnels sont inclus dans la payload length tel que définit dans la RFC 24601 dont la version française indique « Certains champs de l’en-tête IPv4 ont été enlevés ou rendus optionnels, pour réduire dans les situations classiques le coût (en ressources de traitement) de la gestion des paquets et pour limiter le surcoût en bande passante de l’en-tête IPv6. »36.
  • Les éventuelles informations relatives à la fragmentation sont repoussées dans un en-tête qui suit.
  • Les en-têtes optionnels IPv6 doivent tous être analysés un par un pour en déterminer la fin et savoir où commence la charge utile (payload) de niveau 4 dans le paquet IPv6 ; en conséquence, les décisions de routage basées sur le contenu des en-têtes de paquets au niveau 4 (par exemple l’identification du numéro de port TCP, UDP, ou type de requête ICMPv6) ne peut se faire sans avoir analysé la chaîne complète des en-têtes optionnels (même seulement pour ne pas en tenir compte) ; ceci inclut notamment les options de fragmentation qui pourraient avoir été insérées par l’émetteur du paquet. Cela pose des difficultés de mise en œuvre dans certains routeurs ou pare-feux pouvant notamment conduire à des problèmes de performance37,38.
  • Le protocole de résolution de niveau 2 (ARP) de type broadcast est remplacé par NDP qui est en fait une utilisation d’ICMPv6 en multicast, avec quasiment un groupe multicast distinct par host39 ; cela peut entrainer des dysfonctionnements liés à des filtrages40 d’une part, à des problèmes de performances sur certains équipements41 d’autre part.

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ée 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 68 pour l’IPv442). 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 65 535 octets. IPv6 dispose cependant d’une option jumbogramme permettant de porter la taille maximale d’un paquet à 4 Go et profiter ainsi des réseaux avec un MTU plus élevé.

Neighbor Discovery Protocol

Le protocole de «Découverte de voisin pour IP version 6» (Neighbor Discovery Protocol ou ND, RFC 486152) associe les adresses IPv6 à 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 s’appuie sur ICMPv6.

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 multicast. 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 du 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.

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 359665): le quartet de moindre poids est codé le premier:

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.

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 quartet66 de bits (ou nibble de 4 bits), ce qui allonge le domaine.

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éseau71, son utilisation n’est plus nécessaire pour économiser des adresses.

IPv6 et mobilité

Article détaillé : Mobile IPv6

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.