Alors, qui ici fait du NAT64 ?
http://www.bortzmeyer.org/7269.html
Auteur(s) du RFC: G. Chen, Z. Cao (China
Mobile), C. Xie (China
Telecom), D. Binet (France
Telecom-Orange)
L'épuisement des adresses IPv4
http://www.bortzmeyer.org/epuisement-adresses-ipv4.html étant allé
plus vite que le déploiement d'IPv6 (qui est freiné par la passivité de
nombreux acteurs), il y a de plus en plus souvent le problème de
connecter des réseaux modernes, entièrement en IPv6, à des machines
anciennes restées en IPv4. La solution de l'IETF à ce problème est le
déploiement de NAT64, normalisé dans le RFC 6144. Ce nouveau RFC
documente l'expérience concrète de trois gros opérateurs avec NAT64.
Qu'est-ce qui a marché, qu'est-ce qui a raté ?
Ces réseaux entièrement IPv6 ont l'avantage de ne pas avoir de problème
de manque d'adresses IP (même les préfixes du RFC 1918 peuvent être
insuffisants pour un grand réseau) et de permettre d'utiliser un plan
d'adressage propre dès le début (pas de contorsions pour faire durer
les adresses) et une architecture unique (un seul protocole à gérer).
Pour les réseaux mobiles, par exemple, cela signifie un seul contexte
PDP, ce qui simplifie les choses. Mais, comme vu plus haut, leur
inconvénient est qu'ils ne peuvent pas accéder aux services qui restent
archaïquement en IPv4 seul comme Twitter ou impots.gouv.fr. Et, même si
les professionnels sérieux ont compris depuis longtemps l'importance de
migrer vers IPv6, les résistances des plus attardés vont sans doute
durer longtemps et on peut penser que des réseaux uniquement IPv4
seront encore en fonctionnement pendant de longues années. Au lieu du
plan de transition envisagé au début (« tout le monde en IPv4 » -
« double-pile - IPv4 et IPv6 - déployée progressivement » - « tout le
monde en IPv6 »), il faut maintenant travailler dans le cadre d'un
nouveau plan, « tout le monde en IPv4 » - « certains réseaux en v4
seul et certains en v6 seul » - « tout le monde en IPv6 ». L'étape
intermédiaire a été décrite dans les RFC 6145 et RFC 6146 et son
composant le plus connu est nommé *NAT64*. NAT64 effectue une
traduction d'adresses de IPv6 vers IPv4 en sortie du réseau moderne
vers le réseau archaïque et l'inverse lorsque la réponse arrive.
NAT64 a donc une partie des inconvénients du NAT IPv4 traditionnel
(NAT44), comme le montre le compte-rendu d'expérience du RFC 6586 mais
il parait incontournable, sauf si le déploiement d'IPv6 s'accélérait
subitement dans l'Internet, ce qu'on ne voit pas venir.
30 % des opérateurs, selon un sondage signalé dans le RFC 6036
prévoient de déployer NAT64 ou un système équivalent. NAT64 est
également systématiquement présent lors des réunions des organismes de
normalisation ou de gestion des ressources réseau, comme l'IETF ou le
RIPE. À chaque réunion, un des résaux WiFi est « IPv6 seulement » et
bénéficie d'une passerelle NAT64 vers l'extérieur. De nombreux experts
peuvent ainsi tester en vrai les technologies modernes. Bref, NAT64 est
désormais une technique importante et il est donc nécessaire d'étudier
ses conséquences pratiques. C'est le rôle de ce nouveau RFC, qui ne
décrit pas un nouveau protocole mais offre simplement un retour
d'expérience.
À noter que NAT64 peut être déployé en deux endroits :
* Côté FAI, ce qu'on appelle le NAT64-CGN (pour Carrier-Grade NAT),
sous forme d'un gros traducteur NAT dans le réseau du FAI,
* Ou bien côté fournisseur de services/contenus, ce qu'on appelle le
NAT64-FE (pour Front End), sous forme d'un traducteur NAT dans le
data center, devant les serveurs.
Le premier cas est celui du FAI tout en IPv6 mais qui veut permettre à
ses clients d'accéder à des services IPv4. Le second est celui du
fournisseur de services ou de contenus dont l'infrastructure est
malheureusement entièrement ou partiellement en IPv4 mais qui veut
fournir un accès IPv6, en ne gérant qu'un traducteur, au lieu de mettre
à jour tous ses systèmes. (Le RFC ne discute pas la question de savoir
si c'est une idée intelligente ou pas...)
À noter que le cas d'un NAT64 chez l'utilisateur (le célèbre M. Michu),
dans son CPE, n'est pas mentionné. Un NAT64 dans le CPE imposerait un
réseau du FAI qui soit en IPv4 jusqu'au client, justement ce qu'on
voudrait éviter. Le RFC recommande plutôt de mettre les traducteurs
NAT64 près de la sortie du FAI, de façon à permettre à celui-ci de
conserver un réseau propre, entièrement IPv6 (section 3.1.3). Certes,
cela va concentrer une bonne partie du trafic dans ces traducteurs mais
NAT64 est fondé sur l'idée que la proportion de trafic IPv4 va diminuer
avec le temps : les traducteurs n'auront pas besoin de grossir.
Aujourd'hui, 43 % des cent plus gros sites Web (selon Alexa) ont déjà
un et court-circuitent donc complètement le NAT64.
Autre problème avec la centralisation, le risque de SPOF. Si le CPE de
M. Michu plante, cela n'affecte que M. Michu. Si un
