Voici un RFC qui s'adresse à
l'administrateur système plutôt qu'au
développeur. Il s'agit d'expliquer deux ou
trois choses sur l'affectation des adresses
IPv6 aux machines du réseau local, afin d'aider
à la création d'un plan d'adressage.
Les principes de base de l'adressage IP sont décrits dans le . Une adresse est composée de deux parties,
celle qui identifie le réseau et celle qui identifie l'interface
de la machine, l'interface ID.
La section 1 du RFC rappelle les principales différences avec
IPv4 :
- Il est plus courant d'avoir plusieurs adresses par
machine,
- La taille de l'espace d'adressage fait qu'il n'est typiquement
pas nécessaire de faire des économies.
La section 2 s'attaque ensuite à l'adressage de la partie
réseau (le préfixe), que ce soit pour les adresses uniques
mondialement (section 2.1) ou bien pour les adresses de site du (section 2.2). Le gros morceau est en 2.4, qui détaille les bénéfices qu'on
peut tirer du vaste espace d'adressage IPv6. Des schémas d'adressage
« créatifs », par exemple
où le préfixe est dérivé du numéro du VLAN sont
désormais possibles. La croissance future du réseau peut être permise
en laissant des trous dans l'allocation comme l'explique un
excellent document, le .
La taille des préfixes est à étudier : le posait
comme principe l'affectation d'un /48 à chaque site, quel que soit sa
taille, notamment pour éviter les problèmes en cas de
rénumérotation. Mais la section
2.4.2 parle des problèmes d'économie d'adresses v6 (cf. ). Et le ne fait plus de
recommandation unique.
La section 3 est dédiée à la question de la taille du
préfixe d'un lien donné. Contrairement à IPv4 où on dispose d'une
liberté complète, IPv6 suppose un préfixe de lien de /64 (, section 2.5.4). Choisir une
autre valeur est théoriquement possible, mais casserait plusieurs
protocoles importants comme SEND ou comme les
adresses temporaires du . Pire, cela
pourrait limiter le déploiement de futurs protocoles qui auraient
eux-aussi besoin de 64 bits pour les adresses des machines. (Voir
aussi l'annexe B.1 et B.2 ; on y trouve une exception pour les liens
point-à-point entre deux routeurs, où un /126 est acceptable, mais pas
un /127.)
Ensuite, les adresses des machines sur le lien peuvent être
attribuées par plusieurs méthodes (section 4) :
- Auto-configuration sans état (), section 4.1
- Adresses anti-traçage du , section
4.2
- Adresses attribuées manuellement, section 4.3. Dans ce cas, il
faut veuiller à ce que les adresses n'entrent pas en conflit avec des
adresses bien connues, comme par exemple l'adresse « tout à zéro » qui
identifie normalement les routeurs du lien (annexe B.2.5.1). Il faut
également veiller à ce que le bit 'u' de l'adresse, le 71ème bit, soit
à 0 et le bit 'g', le 72ème, également. En pratique, à l'heure
actuelle, se tromper sur ces deux bits n'a pas de conséquences mais
cela pourrait en avoir dans le futur (cf. annexe B.2.4). Donc,
2001:DB8:CAFE:1::1 est correct (les deux bits
sont à zéro) mais pas 2001:DB8:CAFE:1:0200::1 (le
bit 'u' est à un, dans le groupe 0200).
Deux études de cas concrètes, en annexe A, rendent ce RFC un peu plus facile
à lire.