J'avais d'abord fait une réponse de 2 lignes, mais je réalise que le sujet est important et les confusions profondes, donc je reviens en détail sur ces protocoles de transition d'IPv4 vers IPv6.
Au passage la solution de Free est également provisoire
J'espère bien :
RD = "Rapid Deployment" = Déploiement Rapide Pas "Déploiement Parfait et Définitif"!
Free fait du "Freebox 6rd", la variante la plus simple du "6rd", ou "6to4rd" décrit dans le draft puis la RFC.
C'est une approche extrêmement simpliste. C'est assez astucieux de s'être appuyé sur l'encapsulation existante
SIT (
6in4) et d'avoir modifié légèrement un protocole de transition vers la connectivité Internet IPv6 à partir de connectivité Internet IPv4, le protocole
6to4 : d'où le nom
6to4rd.
C'est un bricolage primitif et extrêmement léger : la "logique" spécifique de Freebox 6rd est tout entière contenue dans un seul écran de code (une quarantaine de lignes). Même avec les soudures et la doc, on doit arriver à 2 écrans de code noyau.
+/* Returns the embedded IPv4 address if the IPv6 address comes from
+ Freebox 6to4 rule */
+static inline __be32 try_fbx6to4(struct in6_addr *fbx6to4_zone,
+ u8 fbx6to4_prefix, struct in6_addr *v6dst)
+{
+ __be32 dst = 0;
+
+ /* isolate zone according to mask */
+ if (ipv6_prefix_equal(v6dst, fbx6to4_zone, fbx6to4_prefix)) {
+ unsigned int d32_off, bits;
+
+ d32_off = fbx6to4_prefix >> 5;
+ bits = (fbx6to4_prefix & 0x1f);
+
+ dst = (ntohl(v6dst->s6_addr32[d32_off]) << bits);
+ if (bits)
+ dst |= ntohl(v6dst->s6_addr32[d32_off + 1]) >>
+ (32 - bits);
+ dst = htonl(dst);
+ }
+ return dst;
+}
+#ifdef CONFIG_IPV6_SIT_FBX6TO4
+ if (!dst && tunnel->parms.fbx6to4_prefix)
+ dst = try_fbx6to4(&tunnel->parms.fbx6to4_zone,
+ tunnel->parms.fbx6to4_prefix,
+ &iph6->daddr);
+ else
+#endif
if (!dst)
dst = try_6rd(&iph6->daddr, tunnel);
Oui, c'est vraiment tout. Vous avez là toute la logique spécifique au routage 6rd des Freebox. (J'ai juste omis les déclarations, la gestion des ioctl pour configurer une interface SIT en 6rd et la doc Kconfig.)
par de 6rd sans IPv4.
Le protocole IPv4 ne va pas disparaître!!!
La solution de Free ne permet pas d'attribuer uniquement un bloc IPv6 à un abonné (sans IPv4, ce qui arrivera un jour)
Encore une fois, c'est faux.
Le 6to4rd
n'est pas du 6to4, c'est un autre protocole basé sur les mêmes idées :
- encapsulation simpliste sans connexion : 6in4
- relais sans état IPv4/IPv6 pour la dés-encapsulation et l'encapsulation
- adresses anycast pour trouver les relais (avec une différence quand même, voir plus bas)
mais ces protocoles ont des buts totalement différents :
- le
6to4 propose une connectivité globale Internet IPv6 à une personne (ou un FAI)
qui a déjà une connectivité globale IPv4- le 6to4rd propose à un FAI
qui a déjà une connectivité globale Internet IPv6 de
collecter le trafic IPv6 via un réseau IPv4-only (le FAI n'a pas du tout besoin d'avoir une connectivité globale IPv4)
Techniquement, les architectures 6to4 et 6to4rd sont très différentes :
En 6to4 :
-
attribution d'adresses IPv6 spécifiques : adresses 6to4 (2002:a.b.c.d:...)
- la plage d'adresses 6to4 correspondant à une plage d'adresse IPv4 (2002:a.b.c.0/44 pour la plage IPv4 a.b.c.0/24) ne DOIVENT JAMAIS apparaître dans les routes IPv6 échangées par BGP
- les adresses 6to4 ne sont à aucun gestionnaire d'adresses, elle n'apparaissent dans aucune route spécifique : elles
ne sont "nulle part" (pseudo-adresses anycast)- par définition,
les paquets 6in4 émis sortent du réseau de l'organisation/du FAI (puisque pas de connectivité globale IPv6)
- les paquets 6in4 aller vont rechercher un relais 6to4 (sens 6in4->IPv6) assez proche : adresse anycast 192.88.99.1
- les paquets IPv6 retours passeront pas un relais 6to4 (sens IPv6->6in4) assez proche du serveur IPv6 contacté : route "pseudo-anycast" 2002::/16
- le relais 6to4 (sens IPv6->6in4) reçoit un paquet destiné à l'adresse 2002:a.b.c.d:... et envoie un paquet destiné à a.b.c.d, donc a.b.c.d
doit être une adresse IPv4 globalement unique- le relayage dans le sens 6in4->IPv6 et dans le sens IPv6->6in4 n'est pas effectué par la même entité
- les relais 6to4 participent à un "service public", le routage 6to4 : qui est responsable de la qualité de service 6to4?
- les relais 6to4 sont des relais ouverts : comment dimensionner la capacité des relais?
En 6to4rd :
-
attribution d'adresses IPv6 ordinaires aux utilisateurs (mais inefficacité de l'usage d'espace d'adressage IPv6)
- ces adresses IPv6 sont normales, donc elles doivent être affectées par un gestionnaire d'adresses (ARIN, APNIC...); elles sont "quelque part"
- le relais 6to4rd (sens 6in4->IPv6) du FAI a une adresse IPv4 anycast gérée par le FAI lui-même, donc les paquets 6in4 émis ne sortent jamais du FAI
- les paquets IPv6 retours
arrivent en IPv6 chez le FAI (qui a une connectivité globale IPv6), puis sont encapsulés en 6in4 par le relais 6to4rd (sens IPv6->6in4); les paquets 6in4 retours sont générés chez le FAI
-
les paquets 6in4 sont toujours à l'intérieur du FAI,
donc une adresse IPv4 globalement unique n'est pas nécessaire- le relayage dans le sens 6in4->IPv6 et dans le sens IPv6->6in4 est assuré par la même entité : le FAI, qui est responsable de la qualité de service; il peut restreindre le service 6rd à ses abonnés; il peut dimensionner la capacité de relayage en fonction du nombre de ses abonnés.
Comme expliqué dans les épisodes précédents, la gestion 6to4 peut être définie comme un cas particulier de la gestion du 6to4rd, et le code linux qui implèmente 6to4rd sert aussi à gérer 6to4 (quand le 6to4rd est activé, sinon c'est l'ancien code 6to4 plus simple qui est utilisé).
La solution de Free ne permet pas d'attribuer uniquement un bloc IPv6 à un abonné (sans IPv4, ce qui arrivera un jour)
N'importe quoi : on pourra toujours attribuer des IP privées.
Le 6rd serait parfaitement utilisable par un hypothétique FAI IPv6-only qui aurait récupéré un réseau de collecte IPv4. Bon, ça parait tiré par les cheveux, mais avec les rachats-cessions d'actifs, on ne sait jamais!