Pour rappel, le fait que le trafic IPv4 passe dans IPv6 serait corroboré par les données rapportées jusqu'à là par cyberjuls :
Sortie IPv4 :1. 91-160-5-***.subs.proxad.net [Abonné, Montpellier]
2. 194.149.164.0 [CG-NAT ou A+P, Île-de-France]
3. cbv-crs8-1-be1005.routers.proxad.net [Backbone, Courbevoie]Sortie IPv6 :1. 2a01:***:*:****::* [Abonné, Montpellier]
2. ???
3. 2a01:e02:7:1715::ffff [Inconnu, proche 1ms]
4. 2a01:e02:3::1 [Inconnu, proche 3ms]
5. ???
6. 2a01:e00:18::2 [Backbone, Île-de-France]
Peut-être que la technologie employée pourrait être 4rd (IPv4 Residual Deployment), une technologie développée par Rémi Després (l'auteur de 6rd, la techno IPv6 que Free a été le premier à déployer) dont la
RFC expérimentale a été publiée en juin dernier, et qui propose la translation ou encapsulation d'IPv4 dans IPv6 avec partage des numéros de ports entre clients ?
https://en.wikipedia.org/wiki/IPv4_Residual_DeploymentIPv4 Residual Deployment has three main features:
• Mesh topology: between two endpoints, IPv4 packets take the same direct routes as IPv6 packets
• Shared IPv4 addresses: to deal with the unavoidable IPv4-address shortage, several customers can be assigned a common IPv4 address, with disjoint TCP/UDP port sets assigned to each (an application of the general A+P model of RFC 6346).
• Stateless operation: conversions of IPv4 packets into IPv6 packets at domain entry, and the reverse at domain exit, are stateless (i.e., one where no per-customer state is needed in domain edge nodes).Différents mécanismes à travers l'histoire de la norme :
The first "4rd" specification, unlike the current one of RFC 7600, used IPv4 encapsulation in IPv6 packets, the only known tunneling approach at that time to ensure complete IPv4 preservation across IPv6-only domains. It was the first proposal that combined stateless address mapping, mesh topology, and A+P.
Another sateless-mesh-A+P approach was next proposed, called dIVI. Instead of encapsulation, it used two successive translations (from IPv4 to IPv6 and then conversely), based on the existing SIIT one-way translations of RFC 2765. Compared to encapsulation, it had the advantage of making IPv6 packet inspections applicable to translated UDP and TCP IPv4 packets, but, due to limitations of SIIT, lacked full compatibility with IPv4 fragmentation (and consequently, as mentioned above, compatibility with path MTU Discovery recommended in RFC 6349).
A+P model :http://www.bortzmeyer.org/6346.html (août 2011)
Donc, quels sont les principes d'A+P ? Comme les miracles n'existent pas, l'idée de base est un compromis. On va sacrifier quelques bits du numéro de port pour les donner à l'adresse IP. Ce faisant, on réduit la capacité des applications à allouer beaucoup de connexions ouvertes (chacune nécessitant un port) mais il n'y a plus guère le choix. Comme le note le RFC, « the need for addresses is stronger than the need to be able to address thousands of applications on a single host » ou, en termes plus brutaux, « en cas de famine, on ne réclame pas d'assaisonnement sur tous les plats ».
Cette famine fait que le partage d'adresses IPv4, déjà largement réalisé au sein d'une même maison ou entreprise, va forcèment s'étendre et que des clients différents, sans lieu entre eux, partageront la même adresse IP. L'idée d'A+P est que, même si l'adresse ne sera plus unique, le couple {adresse, partie du port} restera unique par client. Avec 65536 ports possibles, on peut mettre 65536 clients sur une même adresse IP (si chacun se contente d'un seul port), 256 (avec 256 ports chacun), ou un seul (avec le système actuel où le client a 65536 ports)... L'un des intérêts d'A+P est qu'il limite (sans toutefois le supprimer) le recours au NAT et à tous ses inconvénients.
En effet, une alternative à A+P serait de déployer des gros routeurs NAT (CGN, pour Carrier-grade NAT) dans les réseaux des FAI, routeurs qui traduiraient pour plusieurs clients (au contraire du routeur NAT typique d'aujourd'hui, qui n'opère que pour un seul client). La section 1.1 explique pourquoi c'est une mauvaise idée : le CGN ne maintient pas la connectivité de bout en bout, qui est au cœur d'Internet. Par exemple, le déploiement d'une nouvelle application qui échange des adresses serait bloqué tant que le routeur CGN (qui est sous le contrôle du FAI) n'est pas mis à jour avec un nouvel ALG. Les techniques qui permettent de rendre les routeurs NAT actuels un peu moins insupportables (configuration manuelle de la redirection de port, UPnP) ne marchent en effet pas sur un CGN. Enfin, les routeurs CGN stockent un état considérable (des centaines ou des milliers de clients) et sont donc un point de faiblesse du réseau : si un routeur CGN redémarre, tout est perdu.
(Illustration Wikipédia)
http://c2.touta.in/?p=461 (juillet 2011, peut-être pas à jour !)
(je suis tombé sur cet article fortuitement en faisant des recherches sur des préfixes d'adresses Free
)
Une proposition alternative à CGN est en débat à l’IETF, elle garde la même architecture à base de tunnels sur un réseaux IPv6. Mais au lieu de placer le NAT dans un équipement central dans le cœur du réseau, 4rd conserve le NAT dans les box des utilisateurs, et restreint l’utilisation des ports publics à une plage déterminée. Plusieurs utilisateurs peuvent donc se partager la même adresse IPv4 sans risque de conflit. L’équipement central ne gère que l’encapsulation/décapsulation des paquets IPv4 en ajoutant/retirant un en-tête IPv6.
Le document 4rd décrit comment une adresse IPv4 (et un ensemble de port) peut être dérivé d’une adresse IPv6. La box est préalablement configurée avec un préfixe IPv4 publique et une longueur indiquant la partie index CE (Customer Edge) qui correspond aux bits les moins significatifs (ceux de droite) du préfixe global.
Les bits de poids fort de l’index CE va servir à la fois à compléter le préfixe IPv4 pour former une adresse IPv4 et les bits restants vont servir a restreindre les numéros de ports que le NAT de l’utilisateur peut utiliser en imposant les bits de poids fort (représentés xxxx sur le schéma suivant).