Auteur Sujet: SFR ADSL propose l'IPv6/PPP/L2TP/UDP/IPv4/PPP/L2TP/ATM, pas de préfixe IPv6 fixe  (Lu 12210 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Comparaison entre Freenet6 et l'IPv6 de SFR sur sa Neufbox (échec total de SFR et Cisco !)
Quelques extraits :
Citer
Je viens de trouver ce qui a été déployé par SFR pour activer IPv6:
http://newsroom.cisco.com/press-release-content?type=webcontent&...
Ceci explique cela: les BAS n'ont pas été modifiés pour encapsuler IPv6 dans le tunnel PPP existant (c'est toujours une liaison native IPv4 uniquement). Au lieu de cela, c'est bien un tunnel (de type L2TPv2) qui est construit au dessus de la liaison IPv4 existante (qui doit donc d'abord être connectée). Pour se connecter plus loin que le BAS, sur un serveur relai quelquepart au niveau national chez SFR.
On a donc la config suivante:
IPv6 -> PPP#2 (vers le serveur relai national) -> L2TPv2 -> UDP -> IPv4 (connexion Internet existante) -> PPP (existant vers le BAS régional) -> L2TPv1 -> ATM -> DSL...
Pfff.... comment ne pas s'étonner de la latence finalement assez mauvaise (hop! on prend 20 à 30 millisecondes de latence en plus par rapport à IPv4)
Je ne comprends pas du tout ce choix complexe, lourd, et coûteux, alors que le 6rd permet un passage très facile et surtout que Free a démontré qu'il passe à l'échelle!

Pour info chez Free le ping google.com :
Réponse de 173.194.67.139 : octets=32 temps=31 ms TTL=43
Réponse de 173.194.67.139 : octets=32 temps=31 ms TTL=43
Réponse de 173.194.67.139 : octets=32 temps=30 ms TTL=43
Réponse de 173.194.67.139 : octets=32 temps=31 ms TTL=43
Réponse de 2a00:1450:400c:c01::65 : temps=28 ms
Réponse de 2a00:1450:400c:c01::65 : temps=27 ms
Réponse de 2a00:1450:400c:c01::65 : temps=28 ms
Réponse de 2a00:1450:400c:c01::65 : temps=28 ms
est très légèrement meilleur en IPv6!

Citer
(...)quand le tunnel PPP/L2TPv2 tombe et doit se reconnecter (même si on n'a pas perdu la session IPv4/PPP/L2TPv1/ATM/DSL), on a une nouvelle adresse de bloc/64 sur IPv6, car le système ne mémorise pas l'attribution déjà faite, qui a pourtant vocation à être stable (et même indépendante de tout changement d'adresse IPv4 sur la connexion Internet v1 sous-jascente).
Je suis consterné.

Citer
Les tests montrent que cette latence franchit largement les 70-80ms aux heures pleines, alors même que très peu de monde est connecté avec IPv6 activé chez SFR (puisque le protocole n'est pas activé par défaut avec le nouveau firmware, de sorte que la plupart des box qui l'ont n'ont aucun tunnel L2TPv2 ouvert sur leur session Internet IPv4).

Citer
LE but de SFR était seulement de continuer à utiliser pendant un certain temps son infrastructure IPv4 sans grande modification, mais on voit déjà les limites de compatibilité (la latence accrue, la gigue ou "jitter" aux heures pleines, la fragmentation due à la baisse de MTU, les pertes de trames en UDP sur IPv6, la nécessité pour les OS d'activer le "Path MTU discovery", au delà de la seule découverte par la synchronisation TCP non prise en charge car invisible sur un tunnel intermédiaire... et surtout l'instabilité des tunnels L2TP quant à la négociation d'adresses IPV6 et la découverte des routeurs voisins: un gros problème actuellement, similaire à l'instabilité qu'on constate partout sur les réseaux mobiles 3G dont les tunnels pris en charge sur des serveurs partagés ne tiennent pas plus de 30 secondes et fonctionnent très mal sur les applis interactives pour smartphones...)

Citer
Un dernier test de comparaison: au lieu d'utiliser l'adresse IPv6 source fournie par SFR, et sans même désactiver ce routage L2TPv2, j'obtiens 10/10 en connectivité sur http://test-ipv6.com/ avec un tunnel-broken tiers GRATUIT, et même un meilleur débit, en dépit d'une latence un peu plus élevée, en créant un tunnel IPv6 avec l'utilitaire Freenet6 (de gogo6.net) connecté à Amsterdam en mode authentifié.

Citer
(le tunnel IPv6 de Freenet6 était à ce moment là établi au Canada, bref plus rapide de faire le chemin de France via le Canada et retourner en France vers OVH, que d'utiliser l'IPv6 de SFR de France à France vers le même serveur français OVH.

Citer
J'ai aussi une connection IPv6 encore meilleure (en latence comme en MTU, mais un débit à peu près similaire) si je connecte un client Teredo sur mon PC à un fournisseur IPv6 tiers (par exemple Nerim, le premier fournisseur en France à avoir offert la connexion IPv6 native à tous ses clients depuis... 2002 déjà).
Pourquoi avoir attendu tout ce temps pour proposer un truc aussi nul?

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
La solution mise en place par SFR est temporaire (aujourd'hui tout passe dans le tunnel PPP IPv4 avec donc un tunel IPv6 encapsulé dans le tunel IPv4)

Demain (enfin dans quelques mois), il y aura deux tunnel PPP : un IPv4 et un IPv6 montés simultanèment et indépendants l'un de l'autre.

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
 :o :o :o :o :o :o
est ce vraiment rentable de mettre une solution temporaire puis une solution plus pérenne??

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Au passage la solution de Free est également provisoire : par de 6rd sans IPv4.

La solution de Free ne permet pas d'attribuer uniquement un bloc IPv6 à un abonné (sans IPv4, ce qui arrivera un jour)

corrector

  • Invité
:o :o :o :o :o :o
est ce vraiment rentable de mettre une solution temporaire puis une solution plus pérenne??
Tout dépend.

Mettre en place une solution imparfaite mais "qui tient la route" ;) à peu de frais (Free avec le 6rd), c'est une bonne chose.

Mettre en place une solution merdique qui va dégoûter les utilisateurs d'IPv6 et qui a l'air d'être très chère (SFR avec la solution Cisco), je ne vois pas l'intérêt.  :o

corrector

  • Invité
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!

corrector

  • Invité
La solution mise en place par SFR est temporaire (aujourd'hui tout passe dans le tunnel PPP IPv4 avec donc un tunel IPv6 encapsulé dans le tunel IPv4)
Pourquoi mettre en place un bricolage foireux alors?

Tout ce que SFR fait c'est (à supposer que l'expérience ne reste pas confidentielle, parce que sinon...) :
- dégrader l'image d'IPv6 auprès du public
- causer des difficultés aux fournisseurs de service : si un site décide de passer en dual-stack, les utilisateurs constateront une nette dégradation de la qualité, ne sauront pas pourquoi
- justifier l'approche restrictive de Google "pas de AAAA pour les gueux de l'IPv6"
- dégrader encore l'image que j'ai de SFR (image d'une bande de rigolos qui fait passer Free pour un fournisseur très sérieux, hyper fiable et très professionnel)

Sur le dernier point, je ne pensais pas du tout que c'était possible.

corrector

  • Invité
- les paquets 6in4 aller vont rechercher un relais 6to4 (sens 6in4->IPv6) assez proche : adresse anycast 192.88.99.1
Très proche en effet :
12    22 ms    22 ms    22 ms  bzn-6k-1-po20.intf.routers.proxad.net [212.27.57.9]
 13   105 ms   103 ms   103 ms  yankee-6k-1.po2.intf.routers.proxad.net [212.27.58.26]
 14   104 ms   110 ms   104 ms  10gigabitethernet2-2.core1.ash1.he.net [206.223.115.37]
 15   104 ms   104 ms   104 ms  192.88.99.1
Je croyais que Rani avait installé un relais 6to4? :o

Réponse :
Re: [FRnOG] Free, ou commen   t répondre vite a une demande
Citer
En l'occurrence si. Je suis en 6to4 depuis un certain temps, et l'adresse
anycast 192.88.99.1 est atteinte dans le réseau de free ou juste à sa sortie:

corsac <at> molly: mtr -r --no-dns 192.88.99.1
HOST: molly                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.0.254                 0.0%    10    0.7   0.7   0.7   1.1   0.1
  2. 81.57.48.254                  0.0%    10   33.1  33.4  32.3  35.6   0.9
  3. 213.228.5.254                50.0%    10   33.1  35.3  33.1  43.7   4.7
  4. 212.27.50.13                 40.0%    10   34.7  34.5  33.6  35.9   0.8
  5. 192.88.99.1                  50.0%    10   33.4  41.9  33.2  56.1  11.5

Le 6to4 « standard » marche vraiment très bien chez free depuis pas mal de
temps.
Donc ça eu bien marché.

lplp

  • Expert
  • Abonné SFR adsl
  • *
  • Messages: 161
Tout dépend.

Mettre en place une solution imparfaite mais "qui tient la route" ;) à peu de frais (Free avec le 6rd), c'est une bonne chose.

Mettre en place une solution merdique qui va dégoûter les utilisateurs d'IPv6 et qui a l'air d'être très chère (SFR avec la solution Cisco), je ne vois pas l'intérêt.  :o

Ou peut être tout simplement que ça n'est pas aussi simple que celà...

corrector

  • Invité
Mais encore?

corrector

  • Invité
La solution mise en place par SFR est temporaire (aujourd'hui tout passe dans le tunnel PPP IPv4 avec donc un tunel IPv6 encapsulé dans le tunel IPv4)

Demain (enfin dans quelques mois), il y aura deux tunnel PPP : un IPv4 et un IPv6 montés simultanèment et indépendants l'un de l'autre.
Aujourd'hui, quelles sont les performances comparées IPv6/IPv4 chez SFR?

vivien

  • Administrateur
  • *
  • Messages: 47 086
    • Twitter LaFibre.info
Catastrophique pour la Neufbox v4 => Lenteur IPv6 chez SFR

Par contre j'ai un début d’explication : le chips broadcom de la Neufbox v4 ne gère que IPv4 en hard et donc on est obligé de passer en logiciel pour IPv6 ce qui entraîne des débits lent.
IPv6 sur cette box devrait être abandonné.

Je n'ai pas fais de tests avec la neufbox v6. Je le ferais début mai. La semaine prochaine, je suis chez ma grand mère, je peux réaliser des test IPv6 sur Neufbox v4.

Par contre je tiens a corriger : l'IPv6 chez SFR me semble des plages d'IP fixe. Je n'ai pas noté de changement d'IPv6 après plusieurs jours et plusieurs reboot.

Il est probable que les problèmes de performances soient la raison du retard d'IPv6 pour le FTTH. Je suppose qu'il faut passer en IPv6 natif pour avoir de bonnes performances sur la Neufbox v6 en FTTH.