Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

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 4941. 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 4941, 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.


Téléchargez le RFC 5375

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)