Mon blog

La délicate question de la période de transition entre IPv4 et IPv6 n'a jamais été négligée à l'IETF. Bien au contraire, plusieurs mécanismes ont été normalisés pour assurer le passage d'un protocole à l'autre. Le mécanisme « 6rd », initialement décrit dans le RFC 5569, est un de ces mécanismes. 6rd modifie le 6to4 du RFC 3056 pour garantir un chemin de retour symétrique aux paquets IP (section 1 du RFC). 6rd permet à un FAI de vendre un service IPv6 alors que son réseau interne est essentiellement IPv4. Il est surtout connu pour être la technologie déployée par Free à partir de décembre 2007. Ce RFC 5969 prend la spécification originale de 6rd, dans le RFC 5569, l'étend pour des cas comme celui où les adresses sont distribuées par DHCP et le fait passer sur le chemin des normes IETF (le RFC 5569 avait uniquement le statut « pour information »).

S'il existe plusieurs mécanismes de coexistence d'IPv4 et d'IPv6, c'est parce que les besoins sont différents. Certains FAI ont un réseau interne entièrement IPv6 depuis de nombreuses années comme Nerim. D'autres n'ont pas encore commencé le déploiement. Parfois, le FAI est en avance sur ses clients, parfois c'est le contraire comme c'était le cas pour Free où de nombreux utilisateurs réclamaient IPv6 depuis longtemps. Il existe donc une variété de techniques de coexistence v4/v6. 6rd se positionne pour le cas où le FAI :

• n'a toujours pas migré la totalité de son réseau interne en IPv6,
• a une connectivité IPv6 externe, et des adresses IPv6 allouées par un RIR,
• a certains clients qui réclament une connectivité IPv6,
• et, de préférence, contrôle le routeur situé chez les clients (cas des « boxes », nommées CE pour « Customer Edge » dans le RFC).

À l'origine, le protocole « idéal » semblait être 6to4 du RFC 3056. Simple, déjà mis en œuvre, y compris en logiciel libre et sans état (chaque paquet est traité indépendamment) donc passe bien à l'échelle. Mais il a des limites, notamment le fait le retour du paquet n'est pas garanti : la machine avec laquelle on communique va chercher son propre relais 6to4 et ne va pas forcément en trouver un. 6rd est une modification de 6to4 pour utiliser comme préfixe, non plus le préfixe 6to4 commun à tous de 2002::/16 mais un préfixe par FAI. Ainsi, le FAI doit désormais lui-même installer des relais, il ne peut plus se reposer sur les relais existants mais, en contre partie, il contrôle complètement le routage, y compris sur le chemin du retour et se retrouve ainsi dans un cas plus classique où ses routeurs servent ses clients (alors que, avec 6to4, tout le monde sert tout le monde, ce qui est très bien lorsque cela marche).

La section 4 décrit la fabrication du préfixe 6rd pour les adresses IP. Ce préfixe combine un préfixe IPv6 choisi par le FAI et tout ou partie de l'adresse IPv4 du CE. Notons que, 6rd étant un bricolage purement local au FAI, la norme n'impose pas, par exemple, le nombre de bits IPv4 conservé (ce point était déjà dans le RFC 5569, voir aussi les sections 7 et 11). Il faut juste garder 64 bits pour le réseau local, pour permettre l'autoconfiguration sans état. On peut garder moins de 32 bits de l'adresse IPv4 car certains octets sont souvent fixés sur le réseau du FAI. Par exemple, un FAI qui consacre le préfixe 2001:DB8::/32 à ses clients 6rd, pour un CE d'adresse 192.0.2.137, et dont tous les CE sont sous 192.0.0.0/8, peut garder les trois quarts de l'adresse IPv4. Le FAI aura alors un préfixe 6rd de 32 + 24 = 56 bits (ce qui laissera 72 bits pour le réseau local, permettant 256 réseaux de longueur /64), le 2001:db8:0002:8900::/56.

Chez Free (qui a un /26), en septembre 2010, les adresses IP de mon réseau sont 2a01:e35:8bd9:8bb0::/64. À partir du 29ème bit commence l'adresse IPv4. Dans mon cas, l'adresse IPv6 s'écrit en binaire 10101000000001000011100011010110001011110110011000101110110000 ou, si on retire les 28 premiers bits, 10110001011110110011000101110110000 qui donne en décimal 88.189.152.187 qui est bien mon adresse v4. Un client Free pourrait donc recevoir en théorie un /60. (Merci à Yvon @ Okazoo pour ses calculs et explications.)

Les acteurs du protocole sont :

• Les machines sur le réseau local du client, elles parlent IPv6 nativement sur ce réseau local (si elles utilisent l'auto-configuration sans état, la Freebox leur a envoyé le préfixe par RA),
• Les CPE (CE dans le RFC, pour « Customer Edge », comme la Freebox chez Free), qui doivent parler 6rd pour traduire dans les deux sens,
• Les relais 6rd, en bordure du réseau du FAI (BR dans le RFC pour « Border Relays »). Chez Free, ce sont des PC Unix (qui devraient être remplacés par des Cisco fin 2010). À noter que 6rd est sans état et que chaque paquet IP peut donc être traité indépendamment des autres. Les BR peuvent donc être joints, par exemple, par l'anycast.

On peut se poser la question de savoir s'il s'agit vraiment d'IPv6 « natif ». Sans doute pas (le paquet circule dans le réseau de Free encapsulé IPv4, ce qui réduit la MTU à 1480 octets).

Pour faciliter le débogage, la section 5 du RFC recommande que CE et BR répondent à l'adresse anycast subnet router du RFC 4291 (section 2.6.1).

La section 7 couvre les mécanismes par lesquels le CE peut être configuré pour faire du 6rd proprement. Ils sont multiples mais on notera en section 7.1.1 l'arrivée d'un nouveau : une option DHCP (numéro 212) pour configurer tous les paramètres 6rd du CE (préfixe IPv6, adresse(s) des BR, nombre de bits de l'adresse v4 à conserver, etc).

La question de la longueur idéale du masque v4 est couverte en section 11. Il s'agit de voir combien de bits de l'adresse v4 doivent être gardés dans le préfixe v6. Si on utilise les 32 bits, et qu'on veut allouer un /56 à chaque client, il faut un /24 pour les servir tous. Ce n'est pas si effrayant que cela, même si tous les AS actuellement actifs le faisaient, cela ne consommerait qu'un /9. Et si ces AS n'allouaient au client qu'un /60, la consommation totale ne serait qu'un /13. À noter que Free n'allloue aujourd'hui qu'un /64 à ses clients, ce qui ne leur permet pas d'avoir plusieurs réseaux chez eux (sauf à renoncer à l'autoconfiguration sans état) et annule donc une partie de l'intérêt de IPv6.

Mais la solution la plus courante sera sans doute de ne pas utiliser les 32 bits de l'adresse IPv4 mais seulement une partie. Par exemple, si tous les CE sont dans le même /12 IPv4, 20 bits suffisent pour les distinguer et on peut alors allouer un /56 à chaque client en ne consommant en tout qu'un /36.

6to4 soulève traditionnellement des gros problèmes de sécurité, documentés dans le RFC 3964. 6rd en supprime certains, si l'implémentation suit les recommandations de la section 12, et effectue les vérifications demandées, mais l'usurpation d'adresse IP demeure relativement facile.

Quelles sont les principales nouveautés de ce RFC 5969 par rapport au RFC 5569 original ? Thibault Muchery les résume en disant que ce nouveau RFC est plus général : la solution mise en œuvre pour Free prenait avantage de certaines particularités de Free (addresses IP fixes, maitrise des logiciels de la CE - la Freebox - et des BR). La solution nouvelle reprend tout à fait le même principe, en généralisant, en standardisant (nouvelle option DHCP, etc.), en présentant plus la solution comme inscrite dans une lignée d'autres solutions, en ajoutant des contrôles plus fins pour la sécurité mais au fond c'est exactement la même solution généralisée.

Et Rémi Desprès, concepteur de la solution originale, note que l'apport majeur du RFC 5969 est la spécification d'une option DHCP pour transmettre aux CPEs (ou "CEs") les paramètres 6rd de leur domaine. (Free n'en avait pas besoin, mais c'est indispensable si les CPE sont acquis indépendamment du FAI.) Il ajoute qu'il y a par contre une régression, mais limitée, dans la section 8. La nouvelle norme envisage une l'utilisation de NUD (Neighbor Unreachability Detection) sur le lien virtuel que constitue un domaine 6rd (tout en le décrivant comme sous-optimal), une complexité à son avis superflue. Le RFC 5969, et propose une technique différente pour tester l'accessibilité des BR, à son avis superflue également. La philosophie KISS du RFC 5569 en est à son avis amoindrie, mais avoir un RFC spécifiant l'option DHCP est plus important que ces points mineurs.

On imagine que la suite des opérations sera une implémentation par Cisco, étant donnée que le RFC est rédigé par des gens travaillant pour Cisco.