En ce qui concerne les questions d'auto-configuration et de mobilité, Il a été décidé d'utiliser les 64 bits inférieurs de la partie hôte de l'adresse pour la plupart des types d'adresse actuels. Conséquemment, chaque sous-réseau détient une grande quantité d'adresses.
Cette partie hôte peut être différemment considérée:
Avec l'auto-configuration, la partie hôte de l'adresse est calculée en convertissant l'adresse MAC d'une interface (si disponible), avec la méthode EUI-64, en une adresse IPv6 unique. Si aucune adresse MAC n'est disponible pour le périphérique en question (ce qui arrive par exemple sur les périphériques virtuels), quelque chose d'autre (comme l'adresse IPv4 ou l'adresse MAC d'une interface physique) est utilisée à la place.
Considérons à nouveau le premier exemple:
3ffe:ffff:100:f101:210:a4ff:fee3:9566 |
ici,
210:a4ff:fee3:9566 |
est la partie hôte calculée à partir de l'adresse MAC de la NIC
00:10:A4:E3:95:66 |
en utilisant IEEE EUI-64 conçue pour les identifiants EUI-48.
Parce que la partie hôte "automatiquement calculée” est globalement unique (sauf lorsqu'un fabriquant de NIC utilise la même adresse MAC sur plus d'une NIC), la traque grâce à un client (client tracking) est possible sur l'hôte, dès lors qu'aucun proxy d'aucune sorte n'est utilisé.
C'est un problème connu, et une solution a été apportée: l'extension ”sphère privée”, définie dans le RFC 3041 (RFC 3041 / Privacy Extensions for Stateless Address; il y a déjà aussi un brouillon plus récent disponible: draft-ietf-ipngwg-temp-addresses-*.txt). Le principe est d'utiliser une valeur aléatoire et une valeur statique à partir desquelles un nouveau suffixe est généré à intervalle régulier. Note: ce n'est raisonnable que pour des connexions client sortantes, et n'est pas vraiment utile pour des machines réputées être des serveurs.
Pour les serveurs, il est probablement plus aisé de se rappeler d'adresses plus simples; cela peut aussi se faire. Il est possible d'assigner une adresse IPv6 additionnelle à une interface, par exemple
3ffe:ffff:100:f101::1 |
Pour les suffixes tels que ”::1”, montré dans l'exemple ci-dessus, il est requis que le septième bit le plus significatif soit positionné à 0 (le bit universel/local d'un identifiant automatiquement généré). Certaines autres (à part celles qui n'ont pas étaient choisies) combinaisons de bits sont réservées aux adresses anycast.
| Précédent | Sommaire | Suivant |
| La partie réseau, aussi appelée préfixe | Niveau supérieur | La longueur de préfixe nécessaire au routage |