RFC 5375: IPv6 Unicast Address Assignment Considerations
Date de publication du RFC : Décembre 2008
Auteur(s) du RFC : G. Van de Velde, C. Popoviciu
(Cisco), T. Chown (University of
Southampton), O. Bonness, C. Hahn
(T-Systems)
Pour information
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 4 décembre 2008
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 RFC 4291. 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 RFC 4193 (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 RFC 3531.
La taille des préfixes est à étudier : le RFC 3177 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. RFC 3194). Et le RFC 6177 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 (RFC 4291, 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 RFC 8981. 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 (RFC 4862), section 4.1
- Adresses anti-traçage du RFC 8981, 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::1est correct (les deux bits sont à zéro) mais pas2001:DB8:CAFE:1:0200::1(le bit 'u' est à un, dans le groupe0200).
Deux études de cas concrètes, en annexe A, rendent ce RFC un peu plus facile à lire.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)
