Activité 13 : Les adresses unicast

Types d'adresse

IPv6 définit trois types d'adresses : unicast, multicast, anycast.

• Le type unicast est le plus simple et désigne une interface unique. Le datagramme sera remis à l'interface identifiée de manière unique par son adresse. La portée d'une adresse unicast peut être
  

- globale : unicité de l'identifiant sur l'ensemble de l'Internet (Global Unicast)
- localement restreinte,: unicité de l'identifiant étendue à un espace privatif limité à un site ou un campus (Unicast Local)
- restreinte à un lien ou domaine de diffusion de type VLAN (Link-Local Unicast).Une adresse de portée locale (site ou lien) ne sera pas routée sur l'internet.

• Une adresse de type multicast désigne un groupe d'interfaces appartenant à différents nœuds pouvant être situés n'importe où sur le réseau. Lorsqu'un datagramme a pour adresse de destination une adresse de multicast, il est acheminé par le réseau à toutes les interfaces appartenant au groupe. IPv6 ne dispose pas d'adresse spécifique de diffusion générale (broadcast) au sens reconnu par IPv4, où le datagramme et reçu par toutes les interfaces du réseau ou du sous réseau et non pas toutes les interfaces de l'interconnexion. Le broadcast IPv4 est toujours restreint (confiné) à un réseau ou sous réseau. En IPv4 le broadcast est "général" et toutes les interfaces sont à l'écoute. En IPv6 la diffusion est beaucoup plus sélective, on peut s'adresser uniquement aux routeurs ou aux serveurs DHCP par exemple. Au niveau local (lien ou site) un groupe IPv6 permet de s'adresser à l'ensemble des interfaces, offrant par là la même fonction que le broadcast restreint d'IPv4.

• Une adresse de type anycast officialise la proposition faite pour IPv4 dans la RFC1546. Comme pour le multicast, une adresse anycast désigne un groupe d'interfaces. La différence est que le réseau va remettre le datagramme anycast à un membre du groupe et non pas à tous comme pour le multicast. La sélection du membre qui réceptionnera le datagramme est à la charge du réseau. Cela peut être le "plus proche" au sens du routage (nombre de sauts, RTD minimal…). Ce type d'adressage est encore l'objet de recherches, et reste pour l'instant essentiellement expérimental.

Identification des types d'adresse

Le type d'une adresse IPv6 est identifié par ses bits de poids fort.

Type	Préfixe binaire	Notation IPv6
Non spécifié	00...0	/128
Adresse de bouclage (Loopback)	00...1	::1/128
Multicast	1111 1111	FF00::/8
Unicast lien local	1111 1110 10	FE80::/10
Unique Local unicat Address (ULA)	1111 1101	FD00::/8
Unicast globale Plan d'adressage agrégé actuellement déployé	Tout le reste 0010	2000::/3 soit toute adresse commençant par 2 ou 3

Certains types d'adresses sont caractérisés par leur préfixe RFC 3513. Le tableau suivant (source : [[1]]) donne la liste de ces préfixes. La plage «réservée» du préfixe 0::/8 est utilisée pour les adresses spéciales (adresse indéterminée, de bouclage, mappée, compatible). On notera que plus de 70% de l'espace disponible n'a pas été alloué, ce qui permet de conserver toute latitude pour l'avenir.

Préfixe IPv6	Allocation	Référence
0000::/8	Réservé pour la transition et loopback	RFC 3513
0100::/8	Réservé	RFC 3513
0200::/7	Réservé (ex NSAP)	RFC 4048
0400::/6	Réservé (ex IPX)	RFC 3513
0800::/5	Réservé	RFC 3513
1000::/4	Réservé	RFC 3513
2000::/3	Unicast Global	RFC 3513
4000::/3	Réservé	RFC 3513
6000::/3	Réservé	RFC 3513
8000::/3	Réservé	RFC 3513
A000::/3	Réservé	RFC 3513
C000::/3	Réservé	RFC 3513
E000::/4	Réservé	RFC 3513
F000::/5	Réservé	RFC 3513
F800::/6	Réservé	RFC 3513
FC00::/7	Unique Local Unicast soit les adresses commençant par FC00 ::/8 ou FD00 ::/8	RFC 4193
FE00::/9	Réservé	RFC 3513
FE80::/10	Lien-local	RFC 3513
FEC0::/10	Réservé	RFC 3879
FF00::/8	Multicast	RFC 3513

Une interface possèdera généralement plusieurs adresses IPv6. En IPv4 ce comportement est exceptionnel, il est banalisé en IPv6.

Les adresses anycast ne sont pas distinguées des adresses unicast de quelque portée (globale, locale, lien) que ce soit.

Structure de l'adresse unicast

Le plan d'adressage agrégé actuellement en vigueur est défini dans la RFC3587. Il s'inspire des recommandations de la politique d'allocation d'adresse des autorités régionales (RIR Régional Internet Registry), définie dans le documents ripe-267 et de la RFC3177 qui est un plaidoyer pour un préfixe de taille fixe de 48 bits.

Les adresses IPv6 peuvent être agrégées avec des préfixes de longueur quelconque, de manière similaire aux mécanismes mis en oeuvre dans les architectures CIDR (Classeless InterDomain Routing) d'IPv4.

Un noeud peut avoir une connaissance minimale de la structuration interne de l'adresse, en fonction de son rôle dans l'interconnexion. Un hôte ou un routeur n'a ainsi pas la même vision de la structure de l'adresse. Au minimum un noeud peut considérer l'adresse unicast comme un simple mot binaire de 128 bits sans aucune structure particulière.

Un premier niveau de hiérarchisation découpe l'adresse en deux parties logiques, un préfixe réseau/sous-réseau, qui sera utilisé pour acheminer le datagramme à travers le réseau, et un identifiant d'interface qui sera utilisé sur le dernier saut pour remettre le datagramme à l'interface de destination.

Identifiant d'interface

Les identifiants d'interface des adresses unicast sont utilisés pour identifier de manière unique les interfaces des équipements sur un lien ou un domaine de diffusion de niveau 2 (VLAN). Ils doivent absolument être uniques pour le domaine couvert par un sous réseau. Toutefois l'unicité d'un identifiant d'interface peut être de portée beaucoup plus large, voire globale, à l'image des adresses MAC dont l'unicité est mondiale. Dans certains cas l'identifiant d'interface sera dérivé directement de l'adresse de niveau liaison de données (adresse MAC de la carte ethernet par exemple).

Pour les adresses unicast, à l'exception des adresses non spécifiées ou de l'adresse de bouclage (loopback) (celles commençant par 000), l'identifiant d'interface doit avoir une longueur de 64 bits. La taille de 64 bits permet d'approcher une probabilité de conflit quasi nulle.

Si initialement pour des raisons d'auto-configuration, l'identifiant d'interface devait toujours être dérivé de l'adresse de niveau 2, c'est de moins en moins le cas. Il existe plusieurs méthodes pour construire cette valeur de 64 bits:

• manuelle,
• basée sur l'adresse de niveau 2 de l'interface,
• aléatoire,
• cryptographique.

Manuel

Pour les serveurs les plus utilisés, il est préférable d'assigner manuellement des adresses aux interfaces, car dans ce cas l'adresse IPv6 est facilement mémorisable, et le serveur peut être accessible même si le DNS n'est pas actif.

Nota : Le résolveur DNS est le cas le plus flagrant; chaque machine sur le réseau doit être configurée avec l'adresse IPv6 du serveur DNS. En cas de changement de carte réseau, l'ensemble des machines du domaine devront être reconfigurées. Si l'on ne souhaite pas utiliser des protocoles de configuration automatique de type DHCPv6, il est préférable d'attribuer au résolveur DNS une adresse manuelle.

Il existe plusieurs techniques plus ou moins mnémotechniques

• incrémenter l'identifiant d'interface à chaque nouveau serveur créé

2001:DB8:1234:1::1
2001:DB8:1234:1::2

• reprendre le dernier octet de l'adresse IPv4 comme identifiant d'interface. Par exemple si un serveur a comme adresse IPv4 192.0.2.123, son adresse IPv6 sera :

2001:DB8:1234:1::7B
ou plus simplement
2001:DB8:1234:1::123

• reprendre l'adresse IPv4 comme identifiant d'interface, bien que cela ait l'inconvénient de conduire à des adresses plus longues à taper :

2001:DB8:1234:1::192.0.2.123

Dérivé de l'adresse matérielle de l'interface

L'avantage d'utiliser une adresse de niveau 2 pour construire un identifiant d'interface est que l'unicité de cette valeur est presque toujours assurée. En plus, cette valeur est stable tant que la carte réseau de la machine n'est pas changée. Par contre, ces valeurs sont difficilement mémorisables.

Les adresses lien-local sont construites en utilisant ce type d'identifiant. Par contre pour les adresses globales, il est conseillé de ne les utiliser que pour les machines client et de préférer les identifiants d'interface manuels pour les serveurs.

Ces identifiants d'interface étant stables dans le temps, à chaque fois qu'un individu change de réseau, il change de préfixe, mais garde le même identifiant d'interface. Ce dernier pourrait donc servir à tracer les déplacements d'un individu. Le risque est faible, car les cookies mis en place par les serveurs web sont bien plus efficaces, mais ils ne s'agit plus d'un problème réseau. Autre désavantage, comme les adresses MAC contiennent l'identification du matériel, il est possible d'indiquer à l'exterieur du réseau quel type de materiel est utilisé et donner des indications.

Si ces inconvénients sont jugés importants par l'entreprise, l'identifiant d'interface pour les adresses globales peut être généré aléatoirement.

EUI-64

L'IEEE a défini un identificateur global à 64 bits (format EUI-64) pour les réseaux IEEE 1394 (firewire) ou IEEE 802.15.4 (réseau de capteurs) qui vise une utilisation dans le domaine de la domotique. L'IEEE décrit les règles qui permettent de passer d'un identifiant MAC codé sur 48 bits à un EUI-64.

Il existe plusieurs méthodes pour construire l'identifiant :

• Si une machine ou une interface possède un identificateur global IEEE EUI-64, celui-ci a la structure décrite figure Identificateur global IEEE EUI-64. (schema)

Les 24 premiers bits de l'EUI-64, comme pour les adresses MAC IEEE 802, identifient le constructeur et les 40 autres bits identifient le numéro de série (les adresses MAC IEEE 802 n'en utilisaient que 24). Les 2 bits u (septième bit du premier octet) et g (huitième bit du premier octet) ont une signification spéciale :

- u (Universel) vaut 0 si l'identifiant EUI-64 est universel,

- g (Groupe) indique si l'adresse est individuelle (g = 0), c'est-à-dire désigne un seul équipement sur le réseau, ou de groupe (g = 1), par exemple une adresse de multicast.

L'identifiant d'interface à 64 bits est dérivé de l'EUI-64 en inversant le bit u (cf. figure Identificateur d'interface dérivé d'une EUI-64). En effet, pour la construction des adresses IPv6, on a préféré utiliser 1 pour marquer l'unicité mondiale. Cette inversion de la sémantique du bit permet de garder la valeur 0 pour une numérotation manuelle, autorisant à numéroter simplement les interfaces locales à partir de 1.

MAC-48

Si une interface possède une adresse MAC IEEE 802 à 48 bits universelle (cas des interfaces Ethernet ou Wi-Fi). L'adresse est tout d'abord convertie en EUI-64, par l'insertion de 16 bits à la valeur 0xfffe, puis le bit u est mis à 1 comme dans le cas précédent. La figure ci-contre illustre ce processus.

Cas Particuliers

Si une interface ne possède aucune adresse (par exemple l'interface utilisée pour les liaisons PPP), et si la machine n'a pas d'identifiant EUI-64, il n'y a pas de méthode unique pour créer un identifiant d'interface. La méthode conseillée est d'utiliser l'identifiant d'une autre interface si c'est possible (cas d'une autre interface qui a une adresse MAC), ou une configuration manuelle ou bien une génération aléatoire, avec le bit u positionné à 0. S'il y a conflit (les deux extrémités ont choisi la même valeur), il sera détecté lors de l'initialisation de l'adresse lien-local de l'interface, et devra être résolu manuellement.

Valeur aléatoire

L'identifiant d'interface basé sur des adresses MAC, comme indiqué précédemment, pourrait poser des problèmes pour la vie privée. Il identifie fortement la machine d'un utilisateur, qui même s'il se déplace de réseau en réseau garde ce même identifiant. Il serait alors possible de traquer un individu utilisant un portable, chez lui, au bureau, lors de ses déplacements. Ce problème est similaire à l'identificateur placé dans les processeurs Pentium III.

Pour couper court à toute menace de boycott d'un protocole qui « menacerait la vie privée », il a été proposé d'autres algorithmes de construction d'un identifiant d'interface basé sur des tirages aléatoires (voir RFC 3041). Un utilisateur particulièrement méfiant pourrait valider ces mécanismes. L'identifiant d'interface est soit choisi aléatoirement, soit construit par un algorithme comme MD5 à partir des valeurs précédentes, soit tiré au hasard si l'équipement ne peut pas mémoriser d'information entre deux démarrages. Périodiquement l'adresse est mise dans l'état « déprécié » et un nouvel identifiant d'interface est choisi. Les connexions déjà établies continuent d'utiliser l'ancienne valeur tandis que les nouvelles connexions utilisent la nouvelle adresse.

Cette solution a été adoptée par Microsoft. Dans Windows XP, l'interface possède deux adresses IPv6 globale. La première a un identifiant d'interface dérivé de l'adresse MAC. Elle sert aux applications attendant des connexions sur la machine (i.e. les applications serveur). Cette adresse est stable et peut être publiée dans le DNS. La seconde possède un identifiant d'interface tiré aléatoirement. Elle est changée tous les jours et sert aux applications client. Dans Windows 7, ce comportement est généralisé car l'identifiant d'interface de l'adresse permanente est également issu d'un tirage aléatoire. Cela permet d'éviter de donner la marque de la machine ou le type de carte contenu dans les premiers octets de l'identifiant d'interface. Elle est également présente, mais de manière optionnelle, sur Linux et les système d'exploitation BSD comme Mac OS.

Bien entendu pour que ces mécanismes aient un sens, il faut que l'équipement ne s'enregistre pas sous un même nom dans un serveur DNS inverse ou que l'enregistrement de cookies dans un navigateur Web pour identifier l'utilisateur soit impossible.

En contre partie, il est plus difficile à un administrateur réseau de filtrer les machines puisque celles-ci changent périodiquement d'adresses.

File:Livre-G6-Windows7-IIDalea.png

Cryptographique

Si un identifiant aléatoire permet de rendre beaucoup plus anonyme la source du paquet, des propositions sont faites à l'IETF pour lier l'identifiant d'interface à la clé publique de l'émetteur du paquet. Le RFC 3972 définit le principe de création de l'identifiant d'interface (CGA : Cryptographic Generated Addresses) à partir de la clé publique de la machine. Elles pourraient servir pour sécuriser les protocoles de découverte de voisins ou pour la gestion de la multi-domiciliation.

Différents types d'adresse unicast

L'adresse non spécifiée

L'adresse 0:0:0:0:0:0:0:0 ou ::/128 est définie comme l'adresse non spécifiée. Elle ne doit jamais être affectée à un noeud. Elle indique l'absence d'adresse. Elle est utilisée comme adresse source par les paquets d'initialisation lors de l'auto-configuration d'une station. Elle ne doit jamais être utilisée comme adresse de destination d'un paquet.

L'adresse de bouclage (loopback)

l'adresse unicast 0:0:0:0:0:0:0:1 ou ::1/128 est appelée adresse de bouclage (loopback) et correspond à l'adresse 127.0.0.1 d'IPv4. Elle est utilisée par un noeud pour s'envoyer des paquets à lui même. Elle ne doit jamais être affectée à une interface. Elle est considérée comme ayant une étendue de type lien local et doit être vue comme une adresse unicast de lien local de l'interface virtuelle de bouclage (loopback interface). Elle ne doit jamais être utilisée comme adresse source, ou destination d'un paquet circulant sur le réseau, ou plus exactement un paquet circulant hors de la machine. Un paquet reçu sur une interface avec telle adresse de destination doit être détruit.

Les adresses unicast globales

Il s'agit des adresses globalement routables sur l'Internet V6, elles sont communément qualifiées « d'adresses publiques ». Les adresses unicast globales sont issues du plan d'adressage agrégé, proposée dans le RFC 3587. Elles sont identifiées par le préfixe binaire 0b0010, soit 2000::/3 en notation IPv6; toute adresse IPv6 commençant 2xxx :: ou 3xxx:: est donc une adresse unicast globale.

Le RFC3587 définit la structure d'adressage IPv6 définie dans le RFC 3513 en précisant les tailles de chacun des blocs. Il est géré hiérarchiquement de la même manière que CIDR en IPv4. Une adresse intègre trois niveaux de hiérarchie :

• une topologie publique (appelée Global Prefix) codée sur 48 bits, allouée par le fournisseur d'accès;
• une topologie de site codée sur 16 bits (appelée Subnet ID). Ce champ permet de coder les numéros de sous réseau du site;
• un identifiant d'interface sur 64 bits (appelé Interface ID) distinguant les différentes machines sur le lien.

A part le préfixe 2002::/16 qui est est réservé au mécanisme de transition 6to4, cet espace est géré hiérarchiquement comme pour IPv4. L'IANA délègue aux 5 autorités régionales (RIR) des préfixes actuellement de longueur 12 (cf. [[2]]) qui les redistribuent aux ISP de leur région. Suivant leur taille, les opérateurs reçoivent un préfixe plus ou moins long. Le site [[3]] donne en temps réel les allocations de préfixes par région, opérateur et pays.

Il est maintenant admis que le préfixe attribué par un opérateur à ses clients peut également être un /56. En effet, si l'on garde l'attribution de préfixe de longueur 48 pour les sites terminaux, et que l'on intègre les réseaux domotiques, les opérateurs peuvent justifier d'un besoin important d'adresses que les autorités régionales ne peuvent leur refuser.

Nota : quelques préfixes du plan d'adressage agrégé du RFC 3587 ont un usage réservé.

• préfixe 2002::/16 qui est est réservé au mécanisme de transition 6to4 ;
• préfixe 2001:db8::/32 est réservé pour la documentation. Ces adresses ne sont théoriquement pas routés par les opérateurs sur l'Internet public ;
• préfixe 3ffe ::/16 était les adresses du réseau expérimental 6bone qui a symboliquement été stoppé le 6 juin 2006 (06/06/06). ces adresses sont donc aujourd'hui dépréciées.

Le plan agrégé 2000::/3, a été découpé en plusieurs plages d'adresses qui sont allouées par l'IANA aux différents RIR (registres Internet régionaux). Les RIR gèrent les ressources d'adressage IPv4 et IPv6 dans leur région (au niveau mondial). L'IANA alloue des blocs de taille /23 à /12 dans l'espace unicast global (2000::/3) aux cinq RIR. Ces derniers les allouent à leur tour aux LIR (fournisseur d'accès à internet) sous forme de blocs de taille minimale de /48. Les RIR peuvent choisir de subdiviser leur bloc /23 en 512 blocs /32, typiquement un par LIR. Le LIR peut à son tour assigner 65536 blocs /48 à ses clients, qui disposent alors chacun de 65536 réseaux /64. La plage 2001 ::/16 du plan 0x2::/3 (001) avait été initialement attribuée pour l'adressage agrégé des RIR (Regional Internet Register). Cette plage a ensuite été étendue au fur et à mesure des besoins.

La version actualisée du découpage du plan d'adressage agrégé est disponible auprès de l'IANA ([[4]] )

Exemple concret le plan d'adressage IPv6 de Renater (le réseau national de l'enseignement et de la recherches, fournisseur d'accès de l'enseignement supérieur français) :

Les adresses unicast locales

Il y a deux types d'adresse unicast qui sont utilisées localement.

• Les adresses locales de lien, dites « lien local » (Link Local Address), sont utilisées sur un lien ou sur un même domaine de diffusion de niveau 2 (domaine de « broadcast », c'est à dire VLAN) ;
• les adresses unicast locales uniques (ULA Unique Local unicast Address). sont restreintes à un site unique. (analogues aux adresses privées Ipv4 de la RFC1918). Elles sont couramment appelées adresses privées (à l'inverse des adresses unicast globales dites publiques). Elles sont routables à l'intérieur d'un espace privatif (réseau local de campus, réseau d'entreprise, réseau domestique, ...) mais ne peuvent pas en sortir. Elles sont filtrées par les fournisseurs d'accès et ne peuvent donc pas être routées sur l'Internet public.

Les adresses locales de lien (link local address fe80::/64)

Les adresses lien-local, sont des adresses dont l'étendue de validité est restreinte au lien ou au domaine de diffusion de niveau 2 (domaine de broadcast, VLAN), c'est à dire l'ensemble des interfaces directement connectées (visibles entre elles) sans routeur intermédiaire : par exemple les deux extrémités d'une liaison PPP ou d'un tunnel, ou les machines connectées sur un même domaine de diffusion ethernet. Les adresses lien-local sont automatiquement configurées à l'initialisation de l'interface et permettent la communication entre nœuds voisins. Elles sont utilisées par les protocoles de configuration d'adresse globale, de découverte de voisins et de découvertes de routeurs. Elles doivent être uniques sur leur étendue, un protocole de détection de duplication d'adresse permet de s'en assurer. Par contre la duplication d'une adresse lien-local entre deux liens différents est autorisée.

Un routeur ne doit en aucun cas retransmettre un paquet ayant pour adresse source ou destination une adresse de type lien-local.

La portée restreinte de ces adresses les limite, dans la pratique, à un usage de démarrage automatique (boostrap) et aux mécanismes de configuration automatique. Leur usage ne devrait pas être généralisé dans les applications.

Le préfixe d'identification est fe80 ::/10. L'adresse lien-local a le format suivant : préfixe FE80::/64 accolé au 64 bits de l'identifiant d'interface, généralement dérivée de l'adresse MAC de l'interface ethernet. Cela ne pose pas de problème de respect de le vie privée car, contrairement aux adresses globales, les adresses lien-local ne sortent jamais du réseau où elles sont utilisées.

Nota : Une adresse lien-local (ou multicast) n'indique pas intrinsèquement l'interface de sortie, puisque toutes les interfaces partagent le même préfixe fe80::/10. Il faut donc indiquer de manière explicite sur quelle interface doivent être émis les paquets. Sur certains systèmes d'exploitation (BSD, Mac OS, Windows), il est possible de la spécifier en ajoutant à la fin de l'adresse le nom de l'interface voulue, précédé du caractère "%". Sous Linux, un argument, généralement -I permet de la désigner.

Les adresses locales uniques (Unique Local unicast Addresse, ULA fc00 ::/7)

Le RFC 4193 définit un nouveau format d'adresse unicast : les adresses uniques locales (ULA : Unique Local Address). Ces adresses sont destinées à une utilisation locale. Elles ne sont pas définies pour être routées dans l'Internet public, mais seulement au sein d'une zone limitée (topologie privative) telle qu'un site ou entre un nombre limité de sites. La longueur du préfixe étant de 48 bits, elles peuvent se manipuler comme des adresses globales, avec un identifiant de sous-réseau (SID) sur 16 bits et un identifiant d'interface (IID) sur 64 bits

Les adresses uniques locales sont créées en utilisant un identifiant global (Global ID) généré pseudo-aléatoirement, selon l'algorithme défini dans le RFC. Ces adresses suivent le format suivant :

• Prefix (7 bits) : FC00::/7 préfixe identifiant les adresses IPv6 locales (ULA) ;
• L (1 bit) : Positionné à 1, le préfixe est assigné localement. La valeur 0 est réservée pour une utilisation future ; (dans la pratique les adresses ULA en usage actuellement sont donc identifiées par le préfixe fd00::/8 ;
• Global ID (40 bits) : Identifiant global utilisé pour la création d'un préfixe unique (Globally Unique Prefix) ;
• Subnet ID (16 bits) : Identifiant d'un sous réseau à l'intérieur du site ;
• Interface ID (64 bits) : L'indentifiant d'interface tel que défini dans Identifiant d'interface.

Ce type d'adresse permet d'isoler la numérotation externe et interne. En IPv4, l'utilisation d'un préfixe privé (comme 10/8) évite à un site de renuméroter son réseau s'il change de fournisseur d'accès. Un NAT (que nous appellerons NAT44 dans la suite de ce document) permet de passer de l'adressage privé vers l'adressage public.

Avec les adresses de type ULA, il est possible de reproduire ce comportement en IPv6. Un dispositif en bordure de réseau va convertir le préfixe privé en préfixe public. Cet équipement, initialement appelé NAT66 a été renommé NPTv6 {Network Prefix Translation) car il ne possède pas les mêmes limitations que le NAT d'IPv4.

Comme pour la RFC1918, l'objectif est de permettre un adressage à usage privatif non routé sur l'infrastructure publique. Mais à la différence de la RFC1918, où le risque de collision élevé est problématique en cas de connexion de deux sites utilisant ces adresses (lors de fusions d'entreprises par exemple), il s'agit de générer des préfixes quasi uniques. Dans un espace réservé, FC00::/7, le site qui souhaite des adresses quasi uniques tire un préfixe de 48 bits au hasard, suivant l'algorithme décrit dans le RFC en se basant sur l'heure et une adresse MAC d'une de ses interfaces. La probabilité de collision est donc très faible, vue la taile de l'espace d'adressage d'IPv6.

Ces adresses sont dites locales et ne devraient pas être routées sur l'Internet global. Elles sont routables sur un espace limité tel un site, elles peuvent également être routées entre un nombre limité de sites (sur la même aire interne d'un IGP comme OSPF, ou au travers de tunnels point à point reliant les sites). Elles ont les caractéristiques suivantes

• préfixe globalement unique ( très forte probabilité d'unicité) ;
• un préfixe bien connu FC00::/7 facilitant le filtrage aux frontières du sites ;
• limitation des conflits ou des opérations de réadressage lors de la fusion de sites où l'interconnexion privée de sites ;
• indépendance des préfixes vis à vis des fournisseurs d'accès ou des opérateurs ;
• indépendance vis à vis des applications, elles s'utilisent de la même manière que les adresses unicast globales ;
• en cas de débordement géographique accidentel (mauvaise configuration de l'annonce des routeurs ou des filtres, affichage accidentel dans un DNS public) l'unicité garantit l'absence de conflit avec d'autres adresses.

L'identifiant global de 40 bits ne doit pas être choisi de manière séquentielle ou selon un algorithme permettant de déduire un préfixe en fonction des autres préfixes du site. Il ne doit pas, non plus être choisi par facilité mnémotechnique en « hexspeak » (amusement consistant a générer des jeux de mots pour les codes hexadécimaux en mixant les lettres héxadécimales [a..f] et le chiffres les chiffres 1 (pour 'i' ou 'l') 0(pour 'o') 5(pour 's') 6 ou 9 (pour 'g') 7 (pour 't'). Les plus connus étant BAD:F00D: « bad food », 600D:CAFE « good cafe », DEAD:BEEF « dead beef », ou encore DEFE:CATE:D « ... » et bien d'autres (source [[5]])

Le préfixe de l'adresse Ipv6 locale unique est créée en s'appuyant sur un mécanisme pseudo aléatoire. La RFC4193 propose l'algorithme suivant.

1. Prendre l'heure courante dans le format 64 bits du protocole NTP ;
2. prendre un identifiant EUI-64, au besoin dérivé de l'adresse MAC, de l'une des interfaces de l'équipement générant le préfixe ;
3. concaténer l'heure et l'identifiant d'interface pour créer une clé ;
4. calculer l'empreinte SHA-1 (digest) de 160 bits de cette clé ;
5. prendre les 40 bits de poids faible de l'empreinte comme identifiant global de 40 bits ;
6. préfixer l'identifiant global avec le préfixe fc00::/7, et positionner le bit L (8 ième bit de poids fort) à 1. dans la pratique les préfixes ULA débutent donc par « fd ».

Le script, sous licence libre GPL, développé par Hartmut Goebel, disponible à l'URL [[6]], peut vous générer une série de préfixes conforme en utilisant une des adresses MAC ethernet de votre poste de travail.

Ces préfixes ne devraient pas pouvoir être agrégés. Afin de renforcer la non « routabilité » globale sur l'Internet. Par défaut, l'étendue de ces adresses est globale. Ce qui signifie qu'elles ne souffrent pas de l'ambiguité lévée par l'adresse site-local (qu'est ce qu'un site ?). La limite de « routabilité » est fixée au site et à toutes les routes explicitement définies avec d'autres sites privés (soit dans la même aire d'IGP, soit au travers de tunnels). Pour les protocoles de routage extérieur (EGP Exterior Gateway Protocol, tel BGP) mis en oeuvre par les fournisseurs d'accès, la consigne est d'ignorer la réception et l'annonce de préfixes FC00::/7.