Revision as of 16:33, 8 April 2016

Activité 12  : La notation des adresses IPv6

Notation

IPv6 a abandonné la notation décimale pointée, en usage pour les adresses IPv4 (sur 32 bits, soit 4 octets, on indique la valeur décimale de chaque octet séparée par un point décimal. Exemple : l'adresse IPv4 192.168.0.1). Cette notation est en effet inadaptée pour des chaînes binaires de 16 octets. IPv6 a adopté la notation hexadécimale (*) couramment utilisée dans le monde informatique pour représenter des octets par des couples de nombres hexadécimaux.

(*) Le lecteur peu familier avec le système de numération hexadécimal pourra consulter avec intérêt les ressources complémentaires indiquées à la fin de cette séquence^[1].

Notation des adresses par l'exemple

Les 16 octets (128 bits) de l'adresse IPv6 suivante se notent en binaire :

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

et s'écrivent en hexadécimal sous la forme suivante :

couramment notés (le préfixe 0x indiquant que la chaine qui suit est en notation hexadécimale) :

La représentation "textuelle" des adresses IPv6 se fait en segmentant le mot de 128 bits en 8 champs de 16 bits (2 octets) séparés par le caractère ":". Chacun de ces champs est transcrit en 4 chiffres hexadécimaux. L'adresse précédente se note donc :

Par convention, il n'est pas nécessaire d'écrire les zéros de poids fort placés en tête de champ (dans chaque mot de 16 bits, les zéros de poids fort sont non significatifs). L'adresse peut donc prendre une notation plus compacte :

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 !

Notation canonique pour l'affichage

Les adresses IPv6 peuvent donc avoir plusieurs représentations valides possibles. Le RFC 5952 fournit les recommandations pour une forme de représentation canonique des adresses. Cette forme est destinée aux procédures d'affichage (par les programmes, les appels systèmes inscrivant des événements dans les fichiers journaux (logs)...). Cette recommandation ne porte donc que sur les sorties d'adresses (affichage). En entrée (configuration d'équipement, passage de paramètres...), un logiciel devrait toujours accepter les différentes formes valides. La saisie reste donc libre.

Concrètement, selon ce RFC 5952, 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. Plus de détails en fin de chapitre.

Notation des préfixes

La notation des préfixes définie par CIDR [RFC 1519] pour IPv4 est conservée pour IPv6. Le préfixe indique le nombre de bits de poids fort de l'adresse (la partie haute de l'adresse ; c'est-à-dire, dans le sens de lecture occidentale, les chiffres à gauche de l'adresse) utilisés par la fonction de routage d'un équipement pour prendre sa décision de routage (vers quelle interface de sortie il doit réémettre le datagramme, cf. notion de routage du MOOC "Principes des Réseaux de Données").

La notation du préfixe d'adresse se fait en séparant l'adresse du nombre de bits du préfixe par un caractère « / » (le caractère « diviseur » du pavé numérique de votre clavier).

Exemple : les trois notations suivantes de préfixe sont équivalentes car le préfixe ne concerne que les 60 bits de poids fort de l'adresse.

Dans l'affichage ci-dessous, les chiffres hexadécimaux portant les bits de préfixe ont été mis en caractères gras pour une meilleure lisibilité :

On peut combiner l'adresse d'une interface et la longueur du préfixe réseau associé (1^er exemple ci-dessus) ou ne représenter que le préfixe (dernier exemple ci-dessus) lorsque l'on donne explicitement sa valeur.

Concrètement :

On notera une petite difficulté dans cette convention de notation pour les préfixes qui ne sont pas alignés sur une frontière de mots de 16 bits, d'octet ou de demi-octet,

Notation des URL : cas de la spécification du numéro de port

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 (les adresses de niveau transport sont des numéros de port TCP ou UDP, cf MOOC Principes des Réseaux de Données).

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 service 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). Ainsi

• dans le premier cas l'URL serait http://[2001:db8:12::1:8000]/
• et dans le second http://[2001:db8:12::1]:8000/

Références bibliographiques

1. ↑ Le système hexadécimal https://fr.wikipedia.org/wiki/Syst%C3%A8me_hexad%C3%A9cimal

Pour aller plus loin

RFC et leur analyse par S. Bortzmeyer :

• RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (Analyse)
• RFC 3986 Uniform Resource Identifier (URI): Generic Syntax
• RFC 5952 A Recommendation for IPv6 Address Text Representation (Analyse)