Auteur Sujet: Free : test IPv6  (Lu 42265 fois)

0 Membres et 1 Invité sur ce sujet

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
Free: test IPv6
« Réponse #12 le: 08 mars 2012 à 08:42:59 »
Ha les misters de l'informatique. Dit moi comment tu es paramétré pour avoir 10/10 pour que j'essaie chez moi !

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
Free: test IPv6
« Réponse #13 le: 09 mars 2012 à 20:58:13 »
Question, bête ! J'ai fait le test de comparaison de débit entre IPV4 et IPV6 et j'ai aussi un moins bon débit en IPV6.

Est ce que les serveurs, et autres routeurs sont pas responsable de cette différence? Il me semblait qu'en IPV6 internet devrait aller plus vite!! (entête moins longues etc ...)

corrector

  • Invité
Free: test IPv6
« Réponse #14 le: 10 mars 2012 à 06:25:31 »
Question, bête ! J'ai fait le test de comparaison de débit entre IPV4 et IPV6 et j'ai aussi un moins bon débit en IPV6.
Comme moi, comme attendu.

Est ce que les serveurs, et autres routeurs sont pas responsable de cette différence?
Possible, poste les résultats, ainsi qu'un traceroute.

Il me semblait qu'en IPV6 internet devrait aller plus vite!! (entête moins longues etc ...)
Au contraire!

En IPv6 :
- adresses de 128 bits au lieu de 32 bits (16 octets au lieu de 4)
- donc en-tête IP automatiquement légèrement plus important : 40 octets au lieu de 20
- donc la taille disponible pour le SDU (service data unit) IP est inférieur, toutes choses étant égales par ailleurs (à MTU constant) : pour le MTU Ethernet de 1500, la taille SDU max est de 1460 au lieu de 1480
- donc il faut plus de segments TCP, donc plus paquets pour transférer les mêmes données

Je t'invite à comparer dans WireShark la même requête DNS faite en IPv4 et en IPv6 :
« Modifié: 10 mars 2012 à 06:59:22 par corrector »

vivien

  • Administrateur
  • *
  • Messages: 47 283
    • Twitter LaFibre.info
Free: test IPv6
« Réponse #15 le: 10 mars 2012 à 07:12:20 »
J'ai fait un tableau comparatif du débit en fonction du temps de téléchargement d'un fichier en IPv4 ou en IPv6 : https://lafibre.info/testdebit/Debit_IP.pdf

Les fichiers sont sur https://testdebit.info/

Pour un temps de téléchargement de 106 secondes d'un fichier de 10 000 000 bits (environ 1,2 Gio), on à un débit applicatif de 11,25 Mio/s soit 98,64 Mb/s au niveau Ethernet avec IPv4 et 100,02 Mb/s au niveau Ethernet avec IPv6.

Pour un même débit, on mettra donc un peu plus de temps à télécharger un fichier en IPv6 qu'en IPv4.

corrector

  • Invité
Free: test IPv6
« Réponse #16 le: 10 mars 2012 à 07:42:27 »
Optrolight, nous sommes tous les deux sur Freebox ADSL.

- donc la taille disponible pour le SDU (service data unit) IP est inférieur, toutes choses étant égales par ailleurs (à MTU constant)
Mais les choses ne sont pas égales par ailleurs : nous en avons déjà parlé, la Freebox utilise le protocole 6rd pour joindre le premier routeur IPv6 de Free qui est actuellement pour moi th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1] (bizarrement, th2-crs16-1.intf.routers.proxad.net n'existe pas dans le DNS en IPv6).

La collecte reste en IPv4, compare ces commandes
tracert th2-crs16-1.intf.routers.proxad.net
tracert [2a01:e00:2:e::1]

Autrement dit, l'IPv6 voyage dans l'IPv4, c'est du ferroutage et non du fret par containers : on embarque des camions complet (surcharge inutile) au lieu d'embarquer des colis (charge utile). En effet, les camions (paquets IPv6) ne peuvent pas emprunter voie ferrée (réseau IPv4). Le rapport charge utile/poids total est moins bon en ferroutage, et le gabarit des containers posés sur des camions placés sur un train est inférieur au gabarit des containers posés sur un train.

Plus précisèment, l'encapsulation utilisée 6in4 est des plus simples : on met directement le paquet IPv6 dans un paquet IPv4. La surcharge est donc minimale par rapport à des tunnels qui accumulent d'autres couches protocolaires, et elle est facile à calculer : un en-tête IPv4 par paquet IPv6.

Exercice :
Sur Freebox ADSL :
- quel est le MTU IPv6?
- quel est le rapport entre la taille max du SDU en IPv6 et en IPv4?

corrector

  • Invité
Free: test IPv6
« Réponse #17 le: 10 mars 2012 à 08:07:17 »
Normalement le choix se porte toujours sur IPv6 si il est disponible sauf que Google a vu des impacts avec certains FAI en terme de performance et n'active l'IPv6 que sur les FAI qui ont IPv6 natif.

Visiblement chez SFR Google n'est pas encore ouvert en IPv6 directement (il faut préciser ipv6.google.com pour forcer l'IPv6). Je pense que cela devrait arriver dans les prochains mois, la connectivité SFR étant bonne (le ping est a peine supérieur en IPv6)
L'explication de la politique IPv6 de Google :

Google over IPv6
Citer
How it works

Google over IPv6 uses the IPv4 address of your DNS resolver to determine whether a network is IPv6-capable. If you enable Google over IPv6 for your resolver, IPv6 users of that resolver will receive AAAA records for IPv6-enabled Google services.
Le DNS des sites de Google pratique une discrimination entre :
- les manants => pas d'IPv6
- les récurseurs DNS des FAI qui ont démontré qu'ils proposent un service IPv6 de qualité => de l'IPv6

Les critères de Google sont hyper-stricts. En particulier :
Citer
Separate DNS servers for your IPv6 users (not shared with IPv4-only users)
Je ne crois pas que cette condition soit remplie pour les non-dégroupés (ils n'ont pas d'IPv6 natif au cul de la Freebox), ni de ceux qui n'utilisent pas la Freebox mais un simple modem ADSL, car il faudrait qu'ils aient des DNS différents.

Citer
Users who have opted in to IPv6 services and know how to opt out if they experience problems with Google services
C'était le cas au début, mais maintenant l'option IPv6 est activée par défaut chez Free.

Prises à la lettre, ces deux conditions voudraient dire que la Freebox devrait envoyer des récurseurs DNS différents par DHCP selon que l'option IPv6 est activée ou non!

corrector

  • Invité
Free: test IPv6
« Réponse #18 le: 10 mars 2012 à 08:19:33 »
Le DNS des sites de Google pratique une discrimination entre :
- les manants => pas d'IPv6
- les récurseurs DNS des FAI qui ont démontré qu'ils proposent un service IPv6 de qualité => de l'IPv6
Ce qui veux dire que si tu passes par Google Public DNS, les DNS de Google ne donnent pas les IPv6 puisque a priori les utilisateurs de Google Public DNS sont des manants :
> set type=AAAA
> google.com
Serveur :  dns1.proxad.net
Address:  212.27.40.240:53

Réponse ne faisant pas autorité :
Nom :    google.com
Address:  2a00:1450:4007:803::100e

> google.com google-public-dns-b.google.com
Serveur :  google-public-dns-b.google.com
Address:  8.8.4.4

Nom :    google.com
> set debug
> google.com 8.8.4.4
Serveur :  [8.8.4.4]
Address:  8.8.4.4

------------
Got answer:
    HEADER:
        opcode = QUERY, id = 14, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        google.com, type = AAAA, class = IN
    AUTHORITY RECORDS:
    ->  google.com
        ttl = 516 (8 mins 36 secs)
        primary name server = ns1.google.com
        responsible mail addr = dns-admin.google.com
        serial  = 1479292
        refresh = 7200 (2 hours)
        retry   = 1800 (30 mins)
        expire  = 1209600 (14 days)
        default TTL = 300 (5 mins)

------------
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 15, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 0,  authority records = 1,  additional = 0

    QUESTIONS:
        google.com, type = AAAA, class = IN
    AUTHORITY RECORDS:
    ->  google.com
        ttl = 516 (8 mins 36 secs)
        primary name server = ns1.google.com
        responsible mail addr = dns-admin.google.com
        serial  = 1479292
        refresh = 7200 (2 hours)
        retry   = 1800 (30 mins)
        expire  = 1209600 (14 days)
        default TTL = 300 (5 mins)

------------
Nom :    google.com
Voilà :
- en passant par le résolveur de Proxad, j'obtiens les adresses IPv6 de Google;
- en passant par le résolveur de Google, je n'obtiens rien du tout.

Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
Free: test IPv6
« Réponse #19 le: 10 mars 2012 à 10:32:23 »
Merci Corrector pour cette étude détaillé.

Pour en revenir sur le débit IPV6 vs débit IPV4. Ton explication est claire. PAr contre quand on regarde la réactivité d'internet (traitement des serveurs) (pour peu que la connexion des protocoles IPV6 soit bonne) , cela devrait aller plus vite grâce à la simplification des entêtes en IPV6.

Citer
L'amélioration majeure d'IPv6 est la simplification de l'en-tête des datagrammes. L'en-tête du datagramme de base IPv6 ne comprend que 7 champs (contre 14 pour IPv4). Ce changement permet aux routeurs de traiter les datagrammes plus rapidement et améliore globalement leur débit.
source: http://www.commentcamarche.net/contents/internet/ipv6.php3



Optrolight

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 673
  • Grenoble (38) @Optrolight
    • Optroastro
Free: test IPv6
« Réponse #20 le: 10 mars 2012 à 10:43:03 »
J'ai fait les traceroute dont tu parlais:
tracert th2-crs16-1.intf.routers.proxad.net
tracert [2a01:e00:2:e::1]

Autant le premier j'ai la description de tout les serveurs:
 1    <1 ms    <1 ms    <1 ms  FREEBOX [192.168.0.254]
 2    22 ms    23 ms    23 ms  82.246.189.254
 3    23 ms     *       38 ms  grenoble-6k-1-a5.routers.proxad.net [213.228.10.62]
 4    25 ms    24 ms    24 ms  lyon-crs16-1-be1002.intf.routers.proxad.net [212.27.59.45]
 5    25 ms    24 ms    24 ms  lyon-crs16-1-be1012.intf.routers.proxad.net [78.254.250.85]
 6    31 ms    30 ms    31 ms  78.254.250.21


Autant le deuxième c'est un direct:
1    <1 ms    <1 ms    <1 ms  2a01:e35:2f6b:d3c0::
2     *        *        *     Délai d'attente de la demande dépassé.
3    31 ms    31 ms    31 ms  th2-crs16-1.intf.routers.proxad.net [2a01:e00:2:e::1]


Si j'interprète correctement c'est que les passerelles du premier test ne sont pas vues car non référencées en ipV6?

vivien

  • Administrateur
  • *
  • Messages: 47 283
    • Twitter LaFibre.info
Free: test IPv6
« Réponse #21 le: 10 mars 2012 à 11:58:26 »
L'IPv6 étant encapsulé dans de l'IPv4, tu passe par les mêmes routeurs mais sans les voir.

La latence est d'ailleurs presque identique.

corrector

  • Invité
Free: test IPv6
« Réponse #22 le: 11 mars 2012 à 03:48:00 »
Soyons rigoureux "passerelle référencée en IPvX" ça ne veut rien dire! Ce que tu dois vouloir dire, c'est que les passerelles IPv4 n'ont pas d'adresse IPv6 à afficher. Si c'est bien ça, alors non, cela n'a rien à voir avec ça.

Tu observes le principe même du tunnel : pour la couche qui utilise le tunnel (ici : IPv6) le tunnel apparait comme un lien direct, donc il compte pour un saut.

Un tunnel c'est très facile à comprendre : imagine que tu envoies les papiers, chacun dans une enveloppe (collée, timbrée, avec adresse destination, adresse expéditeur ... une lettre normale). Si les adresses sont en IPv4, ça représente un paquet IPv4. Si les adresses sont en IPv6... Conceptuellement, le TTL c'est un timbre qui paye l'envoi d'un paquet. Un TTL de 3 veut dire : je ne paye que pour le travail de 3 routeurs.

Bon, maintenant rien ne t'empêches de mettre non pas un papier dans l'enveloppe, mais une autre enveloppe (plus petite évidemment). Tu vois le truc? Quand tu postes une enveloppe, celle l'adresse sur l'enveloppe extérieure est prise en compte. La Poste ne s'amuse pas à ouvrir l'enveloppe pour voir si il n'y a pas une autre enveloppe avec une autre adresse à l'intérieur! Donc seule l'enveloppe extérieur reçoit le cachet de la Poste. Si tu envoies ton enveloppe à un pote qui accepte d'ouvrir les courriers et de re-poster l'enveloppe intérieure, tu peux atteindre des destinations que la Poste de ton pote connait mais que ta Poste ne connait pas.

Ce qui est important de retenir :
- jamais l'enveloppe intérieure n'est prise en compte par la Poste, c'est toujours l'enveloppe extérieure, et c'est uniquement le timbre extérieur qui est pris en compte;
- quand tu mets la petite enveloppe dans la grande, tu ne décolles par le timbre de la petite pour le recoller : il faut payer un nouveau timbre pour la grande enveloppe;
- il faut suffisamment timbrer chaque enveloppe en fonction de la destination indiquée;
- le prix du timbrage de la grande enveloppe est indépendant de celui de la petite, les destinations sont différentes donc le prix peut être différent;
- si tu attends une réponse par la même voie, il faut que le pote accepte de relayer dans l'autre sens : pour cela il devra lui aussi suffisamment timbrer les enveloppes retour.

Pour les paquets c'est la même chose :
- jamais un routeur ne va regarder si dans un paquet IPvX il n'y aurait pas un autre paquet IPvY. Seul le TTL du paquet extérieur est décrèmenté.
- le budget TTL du paquet extérieur doit être prévu est indépendant du budget TTL du paquet encapsulé;
- pour le retour, le relais doit aussi prévoir un TTL suffisant indépendamment du TTL du paquet intérieur.

Dans un mécanisme de transition vers IPv6 à partir d'IPv4, évidemment le protocole encapsulé c'est IPv6 et le protocole extérieur c'est IPv4, mais le principe serait strictement le même dans l'autre sens, ou pour encapsuler de l'IPv4 dans de l'IPv4 (on appelle ça le protocole IPIP)...

Le fait que le protocole intérieur soit connu/compris par la passerelle qui n'est pas destinatrice du message n'a aucune importance. Mais au bout, tu dois arriver sur un relais qui regarde le paquet IPvY à l'intérieur du paquet IPvX : seul le relais a besoin de comprendre le protocole extérieur et l'intérieur. Bien sûr, ça peut être le même protocole.

Exercices :
- Décrivez à quoi peut servir IPIP (= IPv4 dans IPv4 = "4in4") en pratique.
- Avec quelles modifications du protocole d'encapsulation pourrait-on obtenir un traceroute avec les mêmes informations en IPv6 qu'en IPv4?

corrector

  • Invité
Free: test IPv6
« Réponse #23 le: 11 mars 2012 à 16:17:39 »
imagine que tu envoies les papiers, chacun dans une enveloppe (collée, timbrée, avec adresse destination, adresse expéditeur ... une lettre normale). Si les adresses sont en IPv4, ça représente un paquet IPv4. Si les adresses sont en IPv6... Conceptuellement, le TTL c'est un timbre qui paye l'envoi d'un paquet. Un TTL de 3 veut dire : je ne paye que pour le travail de 3 routeurs.
Traceroute envoie des lettres qui ne sont pas suffisamment affranchies, et attend qu'elles lui soient retournées pour cette raison. À chaque retour, il affiche le bureau de Poste qui a retourné le courrier. Il ne s'arrête que quand il obtient une réponse qui n'est pas un refus pour défaut d'affranchissement. Si le destinataire ne répond pas (ne serait-ce que pas un "courrier refusé"), le processus va continuer indéfiniment.

Le contenu de la lettre est sans aucune importance pour les "refus pour défaut d'affranchissement", mais il a intérêt à provoquer une réponse quelconque quand la lettre arrive à destination.

Les différents programmes traceroute utilisent des messages différents :
- ICMP echo-request (= ping) pour tracert sur Windows (la trace s'arrête ordinairement quand un echo-reply (= pong) est reçu);
- UDP avec un port rarement utilisé pour traceroute sur Unix/linux (la trace s'arrête ordinairement quand un message d'erreur ICMP destination injoignable de type port injoignable;
- n'importe quel paquet ICMP, UDP, TCP, SCTP avec l'outil nping --traceroute du logiciel nmap (Unix/linux/Windows).