June2011S. JiangD. Guo (Huawei)B. Carpenter (University of Auckland)2011-06-14
Verra-t-on un jour la fin des RFC sur les
plans de transition d'IPv4 vers
IPv6 ? Sans doute pas tant que la transition
traîne. En effet, la lenteur imprévue du déploiement d'IPv6 remet en
cause les plans initiaux (qui reposaient sur l'idée qu'il resterait
des adresses IPv4 pendant toute la phase de transition) et nécessite
le développement de nouveaux plans, pour répondre à une situation
différente.
Le plan présenté ici est une variante des plans reposant sur l'idée
de CGN (Carrier-Grade NAT), ces routeurs NAT
installés, non pas dans la
box de M. Michu, pour son
usage et celui de sa famille, mais installés chez le
FAI, pour l'usage partagé de plusieurs clients
du FAI. Le CGN a l'avantage de nécessiter zéro logiciel ou
configuration chez l'utilisateur (qui n'a probablement pas le temps et
l'envie de maîtriser ces mécanismes). Ces solutions reposant
uniquement sur le travail du FAI sont donc tentantes pour répondre au
problème de la trop lente migration chez les utilisateurs. (Toutefois,
mon
impression personnelle est que beaucoup de réseaux de M. Michu, plein
de gadgets récents, sont plus avancés vers IPv6 que pas mal de réseaux
de FAI, conçus il y a des années.)
La nouveauté par rapport aux autres plans reposant sur le CGN
est l'introduction de mécanismes pour éviter que ce CGN ne se
transforme en impasse, et pour le faire évoluer vers de l'IPv6 natif
complet. En effet, dans la plupart des cas, le terme de CGN fait
penser à un mécanisme pour retarder la
transition, le NAT444, qui permet au FAI
paresseux de continuer à utiliser IPv4 même alors qu'il ne peut plus
distribuer ne serait-ce qu'une
seule adresse IPv4 publique à ses clients. Ce CGN-là ne fait
pas progresser vers IPv6 (section 1 du RFC).
D'où cette idée de proposer un plan de migration reposant sur le
CGN mais prévoyant dès le début les moyens d'en sortir. Ce RFC ne
contient pas de nouveaux protocoles, il ne fait que combiner les
protocoles existants.
Dans un certain nombre de FAI, la situation est actuellement la
suivante (section 2) :
Plus d'adresses IPv4 publiques,Un réseau interne purement IPv4, par manque de proactivité du
FAI (qui aurait dû déployer IPv6 depuis longtemps), et qu'on ne peut
pas migrer en cinq minutes,La prise de conscience qu'IPv6 est nécessaire, et à relativement
court terme.
Dans d'autre cas, FAI ayant fait son travail à l'avance et ayant
déployé IPv6 depuis longtemps, ou bien FAI tout récent et préférant
l'approche radicale de déployer un réseau purement IPv6, avec
NAT64 (, et
section 2.6 de notre RFC) pour
assurer la liaison avec le vieux protocole, ces hypothèses ne sont
plus vraies et l'approche de ce RFC ne s'applique donc pas. Comme
toujours avec la transition vers IPv6, il faut analyser son réseau et
déterminer la ou les meilleures stratégies de transition : chacune
s'applique à un cas bien particulier.
Le dessin n° 1 en section 2.1 résume bien l'approche « CGN
progressif » (Incremental Carrier-Grade NAT). En
partant de chez M. Michu (ou plutôt M. Li car le cas décrit est plus
proche de ce que vivent les FAI asiatiques), on a :
Les machines de M. Li, certaines en IPv6 mais pas toutes,Un nouveau composant, le HG (Home Gateway),
une box capable d'assurer
certaines fonctions comme de tunneler le trafic IPv6 vers le routeur NAT
situé plus loin dans le réseau du FAI,Le tunnel IPv6-sur-IPv4 qui commence à la HG et se termine au
routeur CGN,Le réseau purement IPv4 du FAI,Le CGN, une très grosse boîte,Des serveurs restés purement v4 sur le réseau du FAI (serveur
Web du portail, par exemple),L'accès à l'Internet, en IPv4 et en IPv6.
Les deux composants nouveaux, que n'a pas forcément le FAI
aujourd'hui, sont le HG et le CGN. Le HG doit obéir au . Autrement, tous les équipements (routeurs classiques
et machines terminales) ne changent pas (cf. section 2.5).
Quelle technique de tunnel choisir entre le
HG et le CGN ? La section 2.2 rappelle les possibilités. Les tunnels
configurés manuellement du paraissent peu
pratiques. Ceux du peuvent ne pas être très
utilisables par l'utilisateur résidentiel. Cela laisse
6rd () et
peut-être GRE (). Si le FAI a
déjà une infrastructure MPLS, il peut aussi
considérer , mais cela suppose que MPLS aille
jusqu'au HG, ce qui est peu probable. Bref, le RFC recommande 6rd.
La section 2.3 peut alors décrire en détail le fonctionnement de la
HG (Home Gateway, la
box). Lorsqu'elle reçoit un paquet de l'intérieur :
Si c'est un paquet IPv4, elle le fait suivre sur
l'infrastructure v4 normale du FAI (peut-être après traduction), jusqu'au CGN qui fera alors une
traduction v4-v4 (il aura donc pu y avoir deux traductions),Si c'est un paquet IPv6, elle l'encapsule pour l'envoyer, via le
tunnel, jusqu'au CGN (le gros routeur/traducteur situé plus loin dans
l'infrastructure du FAI).
Et le CGN (Carrier-Grade NAT, un routeur NAT qui
sert plusieurs clients) ? La section 2.4 lui est consacrée. Lorsqu'il
reçoit un paquet IPv4 venu d'une HG (rappelons que tout ce RFC est
consacré au cas où l'infrastructure du FAI est purement IPv4), deux
cas :
C'est un paquet v4 normal, et on le transmet après traduction
(puisque le FAI n'a pas assez d'adresses IPv4 publiques, le paquet a
certainement une adresse source privée) ; comme tout routeur
NAT, le CGN mémorise la correspondance
port<->adresse,C'est un paquet IPv6 encapsulé dans du v4. Le CGN le décapsule,
et le transmet.
Voilà, sur le papier, c'est tout simple. Quelles sont les
conséquences pratiques ? La section 2.7 discute divers
points. D'abord, comme toute solution à base de NAT, notre schéma a
tous les inconvénients du partage d'adresses. Pire, comme le CGN est
situé loin de l'utilisateur, et que celui-ci ne peut pas le
configurer, des techniques permettant d'avoir des connexions entrantes
comme les correspondances statiques ou comme
UPnP ne fonctionnent plus. D'autre part, le
tunnel v6-sur-v4 entre le HG et le CGN posera les habituels problèmes
de MTU (dont le RFC se débarasse avec une
pirouette).
L'originalité de l'approche de ce RFC est la possibilité de migrer
de cette solution NAT complexe et fragile vers une solution IPv6
propre. Comment ? C'est ce que décrit la section 3, qui prévoit plusieurs étapes, en supposant :
On installe un CGN pour faire du NAT444. À court terme, cela
réduit la demande en adresses IPv4 publiques. Mais cela n'aide pas en
soi à migrer vers IPv6. Le HG doit être mis à jour pour utiliser le CGN.On déploie 6rd (nouvelle mise à jour du logiciel du CGN),On déploie alors tranquillement IPv6 sur le réseau du FAI. Dès
que la zone desservie a un routage IPv6, on peut couper 6rd dans le
HG, supprimant ainsi le tunnel v6-sur-v4 (IPv4 continuant à être
envoyé au CGN). Cette coupure du tunnel peut
se faire automatiquement, si le HG a été programmé pour détecter les
RA (Router Advertisment) ou réponses
DHCP IPv6.Cette dernière possibilité suppose une forme de double-pile (v4
et v6) sur le réseau du FAI pendant un temps. Si celui-ci préfère
n'avoir qu'un seul protocole à gérer, l'approche est au contraire de
basculer du routage purement v4 du début à un routage purement
v6. C'est alors IPv4 qui sera tunnelé, via
DS-Lite. Le FAI sera alors arrivé jusqu'au
bout, il sera purement IPv6.
Comme indiqué, le passage d'une étape à une autre peut être détecté
automatiquement par le HG, la box, qui peut par
exemple interroger le CGN pour noter les nouvelles fonctions
disponibles. Cela éviterait une action explicite sur la HG.
Il reste à étudier les conséquences de ce schéma en terme de
sécurité (section 4). Le NAT en général pose de nombreux problèmes de
sécurité ( et ). Le partage massif
d'adresses, par exemple dans un CGN, crée des failles expliquées dans
le projet de RFC draft-ietf-intarea-shared-addressing-issues. Les
protocoles spécifiques utilisés ont également leurs propres questions
de sécurité, documentées dans leur norme respective (par exemple, pour
6rd, dans la section 12 du ).
Toutefois, le fait que ce schéma concerne uniquement des mécanismes
utilisés à l'intérieur du réseau d'un FAI, la
sécurité est simplifiée. On peut certes sécuriser les tunnels avec le
mais ce n'est peut-être pas nécessaire, à
l'intérieur d'un réseau unique et géré.
Par construction, il n'y a pas d'implémentation complète de ce RFC,
mais des implémentations de certaines des fonctions. Par exemple,
DS-Lite est mis en œuvre dans AFTR.