Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

RFC 6177: IPv6 Address Assignment to End Sites

Date de publication du RFC : Mars 2011
Auteur(s) du RFC : Thomas Narten (IBM), Geoff Huston (APNIC), Lea Roberts (Stanford University)
Réalisé dans le cadre du groupe de travail IETF v6ops
Première rédaction de cet article le 27 mars 2011


Ce RFC vient remplacer le RFC 3177 et modifier assez sérieusement les recommandations en matière d'allocation d'adresses IPv6 aux sites situés aux extrémités du réseau (entreprises, universités, particuliers, à l'exclusion des FAI et des opérateurs). Le RFC 3177 recommandait, en gros, de donner un préfixe de même longueur, un /48, à tout le monde. Ce nouveau RFC 6177 met un sérieux bémol à cette recommandation.

Le RFC 3177 avait été publié en 2001 et mis en œuvre par les RIR dans leurs politiques d'allocation d'adresses (celle du RIPE-NCC est en http://www.ripe.net/ripe/docs/ipv6policy.html). À partir de 2005, plusieurs critiques se sont fait jour (voir par exemple la proposition 2005-08), menant à une révision de ces politiques et à ce nouveau RFC 6177. Les critiques portaient aussi bien sur la technique (un /48 n'est-il pas excessif ?) que sur la politique (est-ce vraiment le rôle de l'IAB et de l'IETF de recommander des politiques d'allocation ?). Résultat, le « /48 pour tous » n'est plus la politique officielle.

La section 1 de notre nouveau RFC rappele les principaux changements par rapport au RFC 3177 :

  • La possibilité de distribuer des /128 (une seule adresse IPv6) est retirée, un site comprend forcément plusieurs machines,
  • Les valeurs numériques explicitement indiquées par le RFC 3177, /48, /64 et /128, ne sont plus mentionnées, de crainte qu'elles ne deviennent « sacrées » et soient, par exemple, codées en dur dans certaines mises en œuvre d'IPv6, ce qui n'avait pas été prévu,
  • Et, la plus spectaculaire, le retrait de la recommendation d'un /48 pour tous les sites. Il n'y a désormais plus de recommandation officielle de l'IETF, la taille des allocations devant être décidée par les RIR. (On notera que c'est un changement de gouvernance : les RIR, émanation des opérateurs réseau, sont moins favorables que l'IETF aux demandes des utilisateurs.) À titre d'exemple, voici la politique d'APNIC.

Mais alors, que reste-t-il du RFC 3177 ? Le principe comme quoi un site ne devrait pas avoir à geindre et à supplier pour avoir suffisamment d'adresses. En IPv4, la rareté des adresses justifiait les obstacles mis devant les utilisateurs mais, en IPv6, cet argument ne joue plus. Les sites devraient donc toujours avoir les adresses dont ils ont besoin, et ne jamais être contraints à utiliser des techniques comme le NAT pour économiser des adresses, ces économies étant tout à fait inutiles avec IPv6.

La question de l'allocation d'un /48 aux sites d'extrémité est discutée dans la section 2. La recommandation du RFC 3177 était fondée sur trois motivations :

  • Garantir que ces sites auraient suffisamment d'adresses et donc décourager fortement les pratiques malthusiennes de certains FAI comme par exemple, celle de ne donner qu'une seule adresse IPv4, ce qui est compréhensible vue la pénurie mais gêne les sites qui ont plusieurs machines, ce qui est pourtant banal aujourd'hui, même chez le particulier. La plupart du temps, obtenir autant d'adresses IPv4 qu'on a de machines nécessite de passer à un abonnement beaucoup plus cher, sans que cela soit justifié par le coût de ces adresses.
  • La seconde motivation, et qui était souvent oublié par les adversaires du « /48 pour tous », était de faciliter le changement de FAI. Si certains FAI fournissent un /56 à un site et d'autres un /60, le passage du premier au second nécessitera de refaire les plans d'adressage (puisqu'il y a moins de sous-réseaux disponibles) alors que, si tout le monde propose un /48, le changement de fournisseur ne nécessite qu'un changement de préfixe (ce qui est en général très simple avec IPv6). Même chose pour l'administration du DNS, les zones dans ip6.arpa seront plus simples à gérer si on change juste de préfixe, sans avoir à réorganiser ses sous-réseaux. L'idée d'une même taille d'allocation pour tous (de la grande université au particulier) est donc une mesure de protection du client, de garantie qu'il n'y aura pas d'obstacle artificiel à un changement de fournisseur.
  • La troisième motivation de la recommandation du RFC 3177 était de faciliter la croissance des réseaux. Ceux-ci peuvent souvent dépasser les prévisions (une école connecte le bureau du directeur, puis une salle de classe, puis finalement on connecte tout) et les plans d'adressage prudents d'IPv4, conçus pour ne demander que le nombre d'adresses strictement nécessaire, ont souvent gêné la croissance d'un réseau.

Mais, alors, quels sont les problèmes perçus avec cette recommandation du « /48 pour tous » ? D'abord, certains trouvent qu'elle mène au gaspillage. (Je pense personnellement que c'est un argument subjectif, sans base scientifique : il existe 280 billions de /48 disponibles, ce qui fait qu'on n'épuisera pas IPv6 en en donnant un à chacun.) Les partisans de cet argument disent souvent qu'on pourrait ne donner qu'un /64 aux particuliers (ce que fait aujourd'hui un FAI comme Free), oubliant qu'une maison bien dotée en appareils numériques peut avoir besoin de plusieurs réseaux, pas seulement d'adresses, et que, avec l'auto-configuration des adresses IPv6, il faut un /64 par réseau. Notre RFC 6177 demande donc qu'on donne à tous davantage qu'un /64 (un /56 est cité comme possibilité).

Notons que notre RFC 6177 ne traite pas explicitement le cas des hébergeurs de serveurs dédiés comme Gandi ou OVH. Par exemple, Gandi ne permet apparemment qu'une seule adresse IPv6 par machine, rendant ainsi difficile d'y faire tourner plusieurs serveurs. (Pour OVH, l'information est en ligne, avec l'orthographe habituelle de ce fournisseur.)

Le RFC 3177 contenait d'autres points (section 3). Par exemple, il rappelait explicitement que la règle d'un /48 pour tous limitait le pouvoir des intermédiaires : sans avoir à demander, sans remplir de paperasserie, l'utilisateur avait droit à une quantité d'adresses suffisante. C'est hélas quelque chose qui sera différent désormais, l'utilisateur devra à nouveau affronter un bureau insensible pour avoir la quantité d'adresses nécessaire.


Téléchargez le RFC 6177

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)