La Fibre
Télécom => Réseau => 
IPv6 => Discussion démarrée par: corrector le 06 mars 2012 à 16:56:26
-
Bonjour,
Est-ce que les abonnés Free qui ont activé l'IPv6 peuvent aller sur Test your IPv6 connectivity (http://test-ipv6.com/) et poster les résultats? (Le test est ultra-rapide.)
Si la note n'est pas de 10/10, merci de poster aussi le résultat détaillé (Technical Info).
Le post équivalent pour SFR est ici : https://lafibre.info/sfr-les-news/sfr-test-ipv6/ (https://lafibre.info/sfr-les-news/sfr-test-ipv6/)
-
voici un test avec une connexion free:
(https://lafibre.info/images/ipv6/201203_test-ipv6_avec_free.jpg)
-
Pourquoi pas 10/10 ?
C'est lié au DNS ?
-
Si la note n'est pas de 10/10, merci de poster aussi le résultat détaillé (Technical Info)
-
Voilà voilà Mr
How this test works: Your browser will be instructed to reach a series of URLs. The combination of successes and failures tells a story about how ready you are for when publishers start offering their web sites on IPv6.
Test with IPv4 DNS record
ok (1.336s) using ipv4
http://ipv4.test-ipv6.com/ip/?callback=? (http://ipv4.test-ipv6.com/ip/?callback=?)
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.
Test with IPv6 DNS record
ok (1.133s) using ipv6
http://ipv6.test-ipv6.com/ip/?callback=? (http://ipv6.test-ipv6.com/ip/?callback=?)
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.
Test with Dual Stack DNS record
ok (1.250s) using ipv6
http://ds.test-ipv6.com/ip/?callback=? (http://ds.test-ipv6.com/ip/?callback=?)
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).
If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.
Test for Dual Stack DNS and large packet
ok (1.164s) using ipv6
http://ds.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx (http://ds.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx)
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.
Test IPv4 without DNS
ok (0.419s) using ipv4
http://216.218.228.114/ip/?callback=? (http://216.218.228.114/ip/?callback=?)
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.
Test IPv6 without DNS
ok (0.387s) using ipv6
http://[2001:470:1:18::114]:80/ip/?callback=?
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.
Test IPv6 large packet
ok (1.069s) using ipv6
http://ipv6.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx (http://ipv6.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx)
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels.
Test if your ISP's DNS server uses IPv6
bad (1.053s)
http://ds.v6ns.test-ipv6.com/ip/?callback=? (http://ds.v6ns.test-ipv6.com/ip/?callback=?)
(This is bonus credit)
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.
-
C'est quel récurseur DNS?
-
Par pas de dns paramétré j'entends que j'utilise celui de mon FAI par défaut je pense (celui paramétré dans ma V6)!!
-
C'est à dire, ceux de Proxad?
Tu peux vérifier sur ton PC?
netsh int ipv4 show dns
netsh int ipv6 show dns
-
Si je comprends bien la réponse c'est que là c'est un DNS interrogé en IPv4 qui répond aux requêtes AAAA et non un DNS IPv6.
Free ne possède pas de DNS IPv6 il me semble mais des serveurs DNS IPv4 qui répondent aux requêtes A (IPv4) et AAAA (IPv6)
-
Heu... chez moi ça marche (10/10).
D'où ma question sur les DNS paramétrés!
-
J'ai vider le cache dns de mon ordinateur, mis les dns de google. Et là au test j'obtiens 10/10 !!!
J'ai mis dans ma freebox les dns de free :
212.27.40.241 212.27.40.240
et là j'obtiens 9/10
-
J'ai vider le cache dns de mon ordinateur, mis les dns de google. Et là au test j'obtiens 10/10 !!!
Ça non, il n'en est pas question. Ça ne DOIT pas marcher. Je ne te permets pas!!!
Does Google Public DNS support IPv6? (http://code.google.com/intl/fr-FR/speed/public-dns/faq.html#ipv6)
[...] However, it cannot talk to IPv6-only authoritative nameservers.
-
Ha les misters de l'informatique. Dit moi comment tu es paramétré pour avoir 10/10 pour que j'essaie chez moi !
-
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 ...)
-
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 :
-
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 (https://lafibre.info/testdebit/Debit_IP.pdf)
Les fichiers sont sur https://testdebit.info/ (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.
-
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?
-
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 (https://www.google.com/intl/en/ipv6/)
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 :
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.
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!
-
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.
-
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.
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 (http://www.commentcamarche.net/contents/internet/ipv6.php3)
-
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?
-
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.
-
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?
-
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).
-
Chez Free, j'ai 10/10 :
-
Voilà mon résultat perso: windows 7
(http://img2.ipv6-test.com/speedtest/result/2012/04/21/ca87a37d1c8ad1b41a55ba33c36a113f.png)
-
C'est plus le résultat attendu : un débit IPv4 meilleur!
Ou alors, Free se livre à une expérimentation juste sur ma Freebox afin d'encapsuler l'IPv4 dans l'IPv6, avec l'IPv6 natif.
-
Ben je me le demande car personnellement j'ai encore fait le test d'ipv6 et j'ai toujours 9/10 car problème avec les dns !!!
-
Ben je me le demande car personnellement j'ai encore fait le test d'ipv6 et j'ai toujours 9/10 car problème avec les dns !!!
> ds.v6ns.test-ipv6.com
Serveur : dns1.proxad.fr
Address: 212.27.40.240
Réponse ne faisant pas autorité :
Nom : ds.v6ns.test-ipv6.com
Address: 216.218.228.114
Et toi?
Est-ce quelqu'un peut confirmer qu'une adresse IP Free (notamment 212.27.40.240) correspond bien une localisation réseau unique - à part bien sûr les pseudo anycast des adresses *.freebox.fr)?
Je vois 212.27.40.240 à coté de bzn-49m-6-v940.intf.routers.proxad.net.
-
j'ai pas compris ta demande sur les dns Corrector?
j'ai beau mettre les dns de free dans la freebox je reste a 9/10
-
Essaie de voir où se trouvent les DNS de Free avec traceroute.
-
voilà le traceroute !!
1 <1 ms <1 ms <1 ms FREEBOX [192.168.0.254]
2 24 ms 23 ms 24 ms 82.246.189.254
3 24 ms * 22 ms grenoble-6k-1-a5.routers.proxad.net [213.228.10.62]
4 24 ms 23 ms 23 ms lyon-crs16-1-be1002.intf.routers.proxad.net [212.27.59.45]
5 24 ms 23 ms 24 ms 78.254.250.85
6 24 ms 25 ms 25 ms lyon-6k-1-po1.intf.routers.proxad.net [212.27.59.130]
7 24 ms 24 ms 24 ms dns1.proxad.net [212.27.40.240]
je le vois pas à bezon moi le serveur dns de free. C'est peut être là la différence !!
-
CQFD!
Tu te trompes sur la localisation du serveur DNS depuis le début!
dns1.proxad.net est à Bezon et pas à Lyon!
Quelle idée aussi d'habiter en province!
Viens donc à Paris pour obtenir 10/10!
-
Je ne comprend toujours pas pourquoi.
Tu veux dire que dns1.proxad.net que j'accède par lyon-6k-1-po1.intf.routers.proxad.net [212.27.59.130] a un miroir sur lyon?
Mais ce miroir n'a pas la connexion ipv6?
-
Il me semble clair qu'il y a plusieurs dns1.proxad.net, et que le tien ne parle pas IPv6.
-
Bon je comprend mieux alors !!!
Un simple oubli tu penses? Attendons la journée IPV6 de Juin à laquelle participe Free pour voir l'évolution !!! (de SFR ;D)
-
Je pense que c'est parmi les derniers soucis de Free que le DNS parle IPv6!
Comme l'IPv6 semble le dernier souci de tout le monde!
Et ça me gonfle!
Ça doit se voir!
-
J'ai posté la question des dns de free sur les newsgroups. Je te ferai par de la réponse quand il y en aura une !!!
-
Pour confirmer ça, tu peux faire :
nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
-
J'ai eu cette réponse.
C:\Users\Nao>nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
Serveur : dns1.proxad.net
Address: 212.27.40.240
Réponse ne faisant pas autorité :
porttest.dns-oarc.net canonical name = porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net text =
"213.228.56.17 is GREAT: 80 queries in 6.3 seconds from 79 ports with std dev 17955"
y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net nameserver = ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net internet address = 149.20.58.125
Peux tu m'aider à la déchiffrer?
-
Bonsoir,
Je tiens à apporter ma pierre à l'édifice, je suis aussi abonné Free ADSL et j'ai voulu faire quelques tests pour voir ce que ça donnait ici (Drôme). Sous Linux, j'obtiens bien un résultat de 10/10 (précision, je passe aussi par Lyon) ;D
Par simple curiosité, j'ai décidé de rebooter mon PC et d'aller tester sous Windows ... et là, exactement pareil qu'Optrolight, pas moyen d'obtenir 10/10, "seulement" un 9/10 au test ... j'ai un peu de mal à expliquer ça, mais bon ...
Ça ne viendrait pas de là par hasard ?
-
Le traceroute vers 212.27.40.240 est le même que celui de Optrolight?
Tu as testé ton DNS avec porttest.dns-oarc.net.?
Pour mémoire : nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
-
Le traceroute n'est pas vraiment le même :
traceroute to 212.27.40.240 (212.27.40.240), 30 hops max, 52 byte packets
1 192.168.1.254 (192.168.1.254) 0.318 ms 0.178 ms 0.212 ms
2 78.242.116.254 (78.242.116.254) 6.919 ms 6.156 ms 6.122 ms
3 213.228.33.126 (213.228.33.126) 7.179 ms 6.913 ms 6.883 ms
4 andancette-4k-1-v802.intf.routers.proxad.net (212.27.51.1) 8.182 ms 7.731 ms 7.800 ms
5 lyon-6k-1-v812.intf.routers.proxad.net (212.27.51.177) 8.704 ms 8.679 ms 8.140 ms
6 lyon-crs16-1-be1012.intf.routers.proxad.net (78.254.250.85) 8.880 ms 8.066 ms 8.115 ms
7 lyon-6k-1-po1.intf.routers.proxad.net (212.27.59.130) 8.634 ms * 8.624 ms
8 dns1.proxad.net (212.27.40.240) 8.346 ms 8.358 ms 8.625 ms
Et pour le nslookup, ça me retourne ça :
[matthias@matthias ~]$ nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
Server: 2a01:e00::1
Address: 2a01:e00::1#53
Non-authoritative answer:
porttest.dns-oarc.net canonical name = porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net text = "213.228.63.11 is UNKNOWN: Only received 1 queries. Please try again in 60 seconds"
Authoritative answers can be found from:
y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net nameserver = ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net internet address = 149.20.58.125
-
Le traceroute n'est pas vraiment le même :
traceroute to 212.27.40.240 (212.27.40.240), 30 hops max, 52 byte packets
1 192.168.1.254 (192.168.1.254) 0.318 ms 0.178 ms 0.212 ms
2 78.242.116.254 (78.242.116.254) 6.919 ms 6.156 ms 6.122 ms
3 213.228.33.126 (213.228.33.126) 7.179 ms 6.913 ms 6.883 ms
4 andancette-4k-1-v802.intf.routers.proxad.net (212.27.51.1) 8.182 ms 7.731 ms 7.800 ms
5 lyon-6k-1-v812.intf.routers.proxad.net (212.27.51.177) 8.704 ms 8.679 ms 8.140 ms
6 lyon-crs16-1-be1012.intf.routers.proxad.net (78.254.250.85) 8.880 ms 8.066 ms 8.115 ms
7 lyon-6k-1-po1.intf.routers.proxad.net (212.27.59.130) 8.634 ms * 8.624 ms
8 dns1.proxad.net (212.27.40.240) 8.346 ms 8.358 ms 8.625 ms
Si si, tout pareil :
212.27.59.45 > 78.254.250.85 > 212.27.59.130 > 212.27.40.240
Mais c'est surtout la route vers ton DNS qu'il faudrait : 2a01:e00::1
Et pour le nslookup, ça me retourne ça :
[matthias@matthias ~]$ nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
Server: 2a01:e00::1
Address: 2a01:e00::1#53
Non-authoritative answer:
porttest.dns-oarc.net canonical name = porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net text = "213.228.63.11 is UNKNOWN: Only received 1 queries. Please try again in 60 seconds"
Authoritative answers can be found from:
y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net nameserver = ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net internet address = 149.20.58.125
Ah, je n'avais jamais vu ça. Tu peux réessayer?
-
Avec plaisir ;)
Les 2-3 premières fois j'ai eu pareil, mais pour x raison c'est passé d'un coup à cela :
[matthias@matthias ~]$ nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
porttest.dns-oarc.net canonical name = porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net text = "213.228.57.20 is GREAT: 78 queries in 4.8 seconds from 78 ports with std dev 17754"
Authoritative answers can be found from:
y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net nameserver = ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net internet address = 149.20.58.125
Je tiens à préciser qu'entre les tests de tout à l'heure et ceux-ci, j'ai mis à jour mon noyau Linux ...
-
Les 2-3 premières fois j'ai eu pareil, mais
j'ai mis à jour mon noyau Linux ...
c'est passé d'un coup à cela :
Je tiens à préciser qu'entre les tests de tout à l'heure et ceux-ci, j'ai mis à jour mon noyau Linux ...
Du coup ça doit marcher uniformèment (aussi mal), cette fois, non?
Alors, 9/10?
-
Et bien, avec Linux, j'ai toujours 10/10 aux résultats, par contre j'ai un joli (ou pas) 9/10 sur Windows...
[...]Sous Linux, j'obtiens bien un résultat de 10/10 (précision, je passe aussi par Lyon) ;D
Par simple curiosité, j'ai décidé de rebooter mon PC et d'aller tester sous Windows ... et là, exactement pareil qu'Optrolight, pas moyen d'obtenir 10/10, "seulement" un 9/10 au test ... j'ai un peu de mal à expliquer ça, mais bon ...
-
Qu'indique porttest.dns-oarc.net. sous Windows?
-
Alors :
(http://img708.imageshack.us/img708/8449/lookupgc.png)
Au passage, le test IPv6 :
(http://img809.imageshack.us/img809/8391/ipv6test.png)
L'erreur:
Test if your ISP's DNS server uses IPv6
bad (0.285s)
http://ds.v6ns.test-ipv6.com/ip/?callback=? (http://ds.v6ns.test-ipv6.com/ip/?callback=?)
(This is bonus credit)
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.
-
tu utilises bien le même serveur DNS sous linux et sous windows ?
- Sous linux : cat /etc/resolv.conf
- Sous Windows : ipconfig /all
-
Oui, je viens de retourner vérifier, ce sont bien les mêmes.
PS : (http://img718.imageshack.us/img718/1565/maintitlej.png) j'espère que personne n'est hexakosioihexekontahexaphobe ici ! (http://img204.imageshack.us/img204/2122/angew.gif)
-
tu utilisesbien le même serveur DNS sous linux et sous windows ?
Manifestement le DNS utilisé par matt73300 a changé en cours de route. ;)
- Sous linux : cat /etc/resolv.conf
- Sous Windows : ipconfig /all
nslookup tout simplement.
PS : (http://img718.imageshack.us/img718/1565/maintitlej.png) j'espère que personne n'est hexakosioihexekontahexaphobe ici ! (http://img204.imageshack.us/img204/2122/angew.gif)
Le chiffre du diable! Bouh!
-
Manifestement le DNS utilisé par matt73300 a changé en cours de route. ;)
En fait, il y a une seconde chose devant laquelle je reste perplexe ...
http://img801.imageshack.us/img801/2066/capturedu20120430131034.png (http://img801.imageshack.us/img801/2066/capturedu20120430131034.png)
J'en ai fait plusieurs à la suite, c'est aléatoire ... parfois 192.168.1.254, parfois 2a01:e00::2 ...
-
Humm étrange quand même non?
-
C:\Users\Nao>nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
Serveur : dns1.proxad.net
Address: 212.27.40.240
Réponse ne faisant pas autorité :
porttest.dns-oarc.net canonical name = porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net text =
"213.228.56.17 is GREAT: 80 queries in 6.3 seconds from 79 ports with std dev 17955"
y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net nameserver = ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net
ns.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net internet address = 149.20.58.125
Peux tu m'aider à la déchiffrer?
Comme l'explique vivien (https://iperf.fr/configurer-le-reseau/dns/msg26062/#msg26062), porttest.dns-oarc.net est un outil de sécurité afin de connaitre la qualité de choix aléatoire du port source d'un DNS récursif; porttest.dns-oarc.net est un raccourci pour porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net; pour résoudre ce nom de domaine grotesque, il faut notamment déterminer le NS de pt.dns-oarc.net, de a.pt.dns-oarc.net ... jusqu'à porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
Il faut donc beaucoup de requêtes DNS.
Le système porttest note toutes ces requêtes et à la fin génère un diagnostique :
80 queries in 6.3 seconds from 79 ports with std dev 17955
On voit ici les ports sources sont diversifiés, les DNS de Proxad sont sûrs, on le sait depuis bien longtemps, pas de problème de ce coté.
Mais il y l'information que je cherchais : l'IP source des requêtes DNS vues par porttest :
"213.228.56.17 is ....
-
[matthias@matthias ~]$ nslookup -querytype=TXT -timeout=10 porttest.dns-oarc.net.
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
porttest.dns-oarc.net canonical name = porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net text = "213.228.57.20
12 28 ms 28 ms 31 ms lyon-crs16-1-be2000.intf.routers.proxad.net [212.27.59.30]
13 28 ms 32 ms 53 ms lyon-6k-1-po1.intf.routers.proxad.net [212.27.59.130]
14 27 ms 32 ms 44 ms lyon-49m-i12-1-v910.intf.routers.proxad.net [78.254.250.6]
15 28 ms 28 ms 29 ms 213.228.57.20donc ton DNS 192.168.1.254#53 est à Lyon, comme attendu.
-
En fait, il y a une seconde chose devant laquelle je reste perplexe ...
http://img801.imageshack.us/img801/2066/capturedu20120430131034.png (http://img801.imageshack.us/img801/2066/capturedu20120430131034.png)
J'en ai fait plusieurs à la suite, c'est aléatoire ... parfois 192.168.1.254, parfois 2a01:e00::2 ...
Donc : ne fais aucun test avec le navigateur tout seul, tu ne saurais pas quel serveur a été interrogé.
En résumé pour faire les tests :
Utiliser les outils spécialisés nslookup et co. qui ont le bon gout d'indiquer le DNS utilisé.
ou bien
Utiliser le navigateur et faire une capture tcpdump/WireShark en même temps.
-
Salut,
Merci pour toutes les infos, je ferai 2-3 tests à l'occasion pour voir ce que ça donne :)
-
Salut en ce jour mondiale de lancement de l'ipv6 dont free est un des principaux partenaires est ce que les personnes qui ont des 9/10 sur testipv6.com ont aujourd'hui un 10/10? Si oui cela veut dire que free a fait le tour de ses dns pour avoir la passerelle ipv6 de partout.
personnellement je testerai ce soir chez moi!!!!
EDIT: Je viens de faire le test et mon score est toujours de 9/10 !! :-\
-
Salut,
pas de changement pour moi, toujours 10/10 sous Linux et 9/10 sous Windows ... ;)
-
pas de changement pour moi, toujours 10/10 sous Linux et 9/10 sous Windows ... ;)
Parce que linux peut utiliser le DNS en IPv6 et pas Windows.
Mais ça doit être aléatoire, linux utilisant soit les DNS IPv4 soit les DNS IPv6.
-
J'ai refait un test sur http://test-ipv6.com/ (http://test-ipv6.com/l):
- si je mets les DNS google ipv6: 10/10 au test!!
- si je mets les DNS ipv6 de Free: 9/10 au test !!
Bref pas d'évolution !!
-
Je viens de passer de Free ADSL à OVH ADSL, j'ai activé l'IPv6 et fait 2/3 tests.
J'ai les mêmes résultats :
- 9/10 sur Windows 7 et 8
- 10/10 sur Linux
j'ai donc la même chose que lorsque j'étais chez Free
-
Quel DNS?
-
Ceux d'origine, je n'ai pas touché aux DNS
-
C'est à dire?
Ils sont ouverts?
-
Pour ma part que ce soit sous windows ou linux :
en connexion direct à la freebox :
10/10 for your IPv4 stability and readiness, when publishers offer both IPv4 and IPv6
10/10 for your IPv6 stability and readiness, when publishers are forced to go IPv6 only
en connexion direct sur un routeur (IPV6 ready) derrière la freebox :
10/10 for your IPv4 stability and readiness, when publishers offer both IPv4 and IPv6
0/10 for your IPv6 stability and readiness, when publishers are forced to go IPv6 only
Mais bon pour ce dernier test le problème vient du routeur derrière la freebox.
-
Tu ne peux pas mettre un routeur derrière la Freebox.
La Freebox n'est pas conçue pour ça, tout simplement!
-
Je ne vois pas pourquoi, ça fait des années que je fonctionne comme cela et je n'ai jamais eu de problème en IPV4 et d'ailleurs avec ce routeur je n'ai pas de problème non plus en IPV4, c'est juste en IPV6 que cela coince et le problème vient probablement de l'implèmentation de la couche IPV6 au niveau du routeur.
Pour le moment ce dernier ne récupérant qu'une adresse IPV6 locale fournie par la freebox et non pas une adresse IPV6 globale.
-
Parce qu'aucune box n'est conçue pour être branchée à un routeur, c'est comme ça. Ce n'est juste pas possible.
-
Pourtant beaucoup d'autres personnes utilisent un routeur derrière leur freebox, il y a d'ailleurs de nombreux tuto là dessus, mais n'étant pas le sujet de ce poste j'en restererai là.
-
Non. C'est impossible d'avoir un routeur derrière une box, simplement parce que l'abonnement ne propose qu'UNE SEULE adresse IPv4.
Apparemment tu n'as pas du tout compris l'intérêt d'IPv6!
-
Si si rassures toi, j'ai bien compris l'intérêt de l'IPV6, plus de nattage à gérer et une @IPV6 publique par équipement.
-
Je pense corrector qu'il faut que tu sois plus explicite pour que tout le monde comprenne la limitation.
je pense que certain pense à cela!!!
http://www.freenews.fr/spip.php?article10675 (http://www.freenews.fr/spip.php?article10675)
-
Pour ma part, je pensais plutot à quelque chose comme cela, ce qui évite les limitations bien connues du mode bridge :
http://forum.zebulon.fr/installer-un-routeur-avec-une-freebox-en-mode-routeur-b380-entry994.html (http://forum.zebulon.fr/installer-un-routeur-avec-une-freebox-en-mode-routeur-b380-entry994.html)
-
9/10 sous Windows 7 en laissant la connexion en automatique.
10/10 en renseignant manuellement les dns ipv6 Free dans les paramètres ipv6 de la connexion.
Si j'ai bien compris, le problème vient de Windows qui ne sait pas prendre en compte les DNS ipv6 dans la réponse du dhcp ?
-
Le fait d'avoir les DNS récursifs en IPv6 n'est important que si tu désactives IPv4.
Tu penses qu'il est temps, déjà?
-
J'ai bien 10/10, sans les récurseurs DNS IPv6 de Proxad.
Slaash, tu peux faire un traceroute dns2.proxad.net et poster les derniers sauts?
-
Mon traceroute passe par Lyon si c'est ce que tu veux savoir.
-
Je veux savoir où se trouve dns2.proxad.net : à Lyon?
-
J'ai pas accès à ma machine là, mais oui, il se trouvait à Lyon la dernière fois que j'ai fait un traceroute. :(
-
Voilà ce qui ne va pas dans ta configuration.
-
Ça non, il n'en est pas question. Ça ne DOIT pas marcher. Je ne te permets pas!!!
Does Google Public DNS support IPv6? (http://code.google.com/intl/fr-FR/speed/public-dns/faq.html#ipv6)
Google Public DNS listens for incoming requests on IPv6 addresses from clients with IPv6 connectivity, responds to all requests for IPv6 addresses, returns AAAA records if they exist, and talks to IPv6-only authoritative nameservers.