Mon blog

Contrairement à ce que prétendent certains ignorants, 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 « RD », décrit dans ce RFC 5569, est un de ces mécanismes, modifiant le 6to4 du RFC 3056 pour garantir un chemin de retour symétrique aux paquets IP. RD 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.

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. RD 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 »).

La section 1 du RFC décrit ainsi comment Free a migré vers 6RD fin 2007 (un autre compte-rendu a été fait par Alexandre Cassen à la réunion RIPE-58 à Amsterdam). Il a fallu mettre à jour le logiciel de la Freebox et ajouter des serveurs relais 6RD en sortie mais il n'a pas été nécessaire de toucher aux DSLAM (qui ne gérent malheureusement pas IPv6).

La section 2 revient plus en détail sur le cahier des charges : casser le cercle vicieux courant avec IPv6 où les FAI n'installent pas IPv6 parce que leurs clients ne le demandent pas et où les clients ne se mettent pas à IPv6 parce que peu de FAI le transmettent. 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. RD 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).

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).

Une fois ce principe posé, la section 3 spécifie le protocole, très proche du 6to4 du RFC 3056. Les acteurs 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 (la Freebox, chez Free), qui doivent parler 6RD pour traduire dans les deux sens,
• Les relais 6RD, en bordure du réseau du FAI. Chez Free, ce sont des PC Unix (qui devraient être remplacés par des Cisco fin 2010).

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 5, et effectue les vérifications demandées, mais l'usurpation d'adresse IP demeure relativement facile.

Le déploiement de 6RD chez Free a permis à la France de faire un bond dans les statistiques IPv6 comme l'a montré le rapport de Lorenzo Colitti (Google), Global IPv6 Statistics - Measuring the Current State of IPv6 for Ordinary Users.

Mais la normalisation de 6RD est aussi l'occasion de voir le processus IETF en action, lorsque l'auteur de la proposition n'est pas un habitué de l'IETF et n'a pas la culture « maison », ce qui était le cas de Rémi Després, un des concepteurs de Transpac, et qui a eu le courage de se plonger dans un monde bien différent, ce qui est toujours plus difficile que de rester seul dans son coin à expliquer qu'on a raison. Comme avec n'importe quelle organisation humaine, l'intégration du « petit nouveau » ne s'est pas fait sans mal mais, finalement, le RFC a été publié.

(Petite note au passage: ce RFC n'a que le statut de « Pour information » et la « vraie » norme IETF sur ce protocole n'apparaitra que plus tard. Notre RFC 5569 décrit le déploiement actuel, un « meilleur » protocole a été ensuite spécifié dans le RFC 5969.)

Il est resté de nombreux mois dans la file d'attente du RFC Editor, en raison de son statut de « soumission indépendante », dont les droits n'ont pas été définis avant le RFC 5744. Mais l'approbation technique était ancienne, datant d'avril 2009. Comme l'avait signalé l'auteur, dans son coup de gueule en séance plénière de l'IETF à Hiroshima en novembre 2009, « Ce RFC décrit comment déployer IPv6 en cinq semaines et voilà cinq mois qu'il attend, pour des raisons non-techniques. »