ipv6 tunnel gaat schijnbaar sneller?

[davidm]

Mijn he ipv6 tunnel lijkt voor vele sites een kleinere latency te geven dan rechtstreeks via ipv4 te gaan:

Code: Selecteer alles

$ ping google.be
PING google.be (173.194.41.223) 56(84) bytes of data.
64 bytes from lis01s05-in-f31.1e100.net (173.194.41.223): icmp_req=1 ttl=43 time=55.1 ms
64 bytes from lis01s05-in-f31.1e100.net (173.194.41.223): icmp_req=2 ttl=43 time=56.2 ms
64 bytes from lis01s05-in-f31.1e100.net (173.194.41.223): icmp_req=3 ttl=43 time=58.9 ms

$ ping6 google.be
PING google.be(lis01s05-in-x17.1e100.net) 56 data bytes
64 bytes from lis01s05-in-x17.1e100.net: icmp_seq=1 ttl=57 time=46.5 ms
64 bytes from lis01s05-in-x17.1e100.net: icmp_seq=2 ttl=57 time=49.5 ms
64 bytes from lis01s05-in-x17.1e100.net: icmp_seq=3 ttl=57 time=48.1 ms

Code: Selecteer alles

$ ping6 youtube.com
PING youtube.com(de-in-x5d.1e100.net) 56 data bytes
64 bytes from de-in-x5d.1e100.net: icmp_seq=1 ttl=56 time=27.9 ms
64 bytes from de-in-x5d.1e100.net: icmp_seq=2 ttl=56 time=27.7 ms
64 bytes from de-in-x5d.1e100.net: icmp_seq=3 ttl=56 time=28.2 ms

$ ping youtube.com
PING youtube.com (173.194.41.200) 56(84) bytes of data.
64 bytes from lis01s05-in-f8.1e100.net (173.194.41.200): icmp_req=1 ttl=43 time=54.9 ms
64 bytes from lis01s05-in-f8.1e100.net (173.194.41.200): icmp_req=2 ttl=43 time=54.6 ms
64 bytes from lis01s05-in-f8.1e100.net (173.194.41.200): icmp_req=3 ttl=43 time=52.9 ms

Code: Selecteer alles

$ ping6 d-lang.net
PING d-lang.net(pherkad.ispgateway.de) 56 data bytes
64 bytes from pherkad.ispgateway.de: icmp_seq=1 ttl=59 time=30.9 ms
64 bytes from pherkad.ispgateway.de: icmp_seq=2 ttl=59 time=29.1 ms
64 bytes from pherkad.ispgateway.de: icmp_seq=3 ttl=59 time=29.9 ms

$ ping d-lang.net
PING d-lang.net (80.67.28.32) 56(84) bytes of data.
64 bytes from pherkad.ispgateway.de (80.67.28.32): icmp_req=1 ttl=54 time=35.2 ms
64 bytes from pherkad.ispgateway.de (80.67.28.32): icmp_req=2 ttl=54 time=33.8 ms
64 bytes from pherkad.ispgateway.de (80.67.28.32): icmp_req=3 ttl=54 time=35.6 ms

Het fenomeen lijkt zich voor te doen zowel voor europese als voor transatlantische sites (behalve dan sites binnen de benelux).
Is er iemand die hier een plausibele verklaring voor kan geven? Ik zou juist gezworen hebben dat het trager ging gaan.

[ubremoved_539]

Code: Selecteer alles

>ping -4 google.be

Pinging google.be [74.125.136.94] with 32 bytes of data:
Reply from 74.125.136.94: bytes=32 time=18ms TTL=44
Reply from 74.125.136.94: bytes=32 time=20ms TTL=44
Reply from 74.125.136.94: bytes=32 time=18ms TTL=44
Reply from 74.125.136.94: bytes=32 time=20ms TTL=44

Ping statistics for 74.125.136.94:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 20ms, Average =19ms

>ping -6 google.be

Pinging google.be [2a00:1450:4013:c01::5e] with 32 bytes of data:
Reply from 2a00:1450:4013:c01::5e: time=24ms
Reply from 2a00:1450:4013:c01::5e: time=22ms
Reply from 2a00:1450:4013:c01::5e: time=20ms
Reply from 2a00:1450:4013:c01::5e: time=19ms

Ping statistics for 2a00:1450:4013:c01::5e:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 24ms, Average = 21ms

Echt veel verschil is er niet... maar de tunnel is toch iets trager. Je hebt wel een ander IPv6 adres voor Google.be ?

[davidm]

Voor google.be krijg ik als ip:
google.be. 300 IN AAAA 2a004004:802::1018
google.be. 300 IN A 173.194.41.223
google.be. 300 IN A 173.194.41.216
google.be. 300 IN A 173.194.41.215

Een bijna-halvering in latency (zoals bij youtube het geval is) vind ik toch al aanzienlijk.

[ubremoved_539]

Code: Selecteer alles

>ping -4 youtube.com

Pinging youtube.com [74.125.136.136] with 32 bytes of data:
Reply from 74.125.136.136: bytes=32 time=19ms TTL=44
Reply from 74.125.136.136: bytes=32 time=19ms TTL=44
Reply from 74.125.136.136: bytes=32 time=25ms TTL=44
Reply from 74.125.136.136: bytes=32 time=18ms TTL=44

Ping statistics for 74.125.136.136:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 25ms, Average = 20ms

>ping -6 youtube.com

Pinging youtube.com [2a00:1450:4013:c01::be] with 32 bytes of data:
Reply from 2a00:1450:4013:c01::be: time=21ms
Reply from 2a00:1450:4013:c01::be: time=20ms
Reply from 2a00:1450:4013:c01::be: time=21ms
Reply from 2a00:1450:4013:c01::be: time=20ms

Ping statistics for 2a00:1450:4013:c01::be:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 20ms, Maximum = 21ms, Average = 20ms

Je hebt dan ook een slechte ping voor Youtube op IPv4... bij welke provider zit je ?

Hoe tunnel je trouwens... op je eigen PC of via je router, en via welke exit ?

[davidm]

Tunnel is opgebouwd vanop mijn computer zelf (blijkbaar ondersteunt mijn NAT router dit zonder modificatie).
Mijn isp is Telenet.
De tunnel endpoint is 216.66.84.46 (tserv1.ams1.he.net, located in U.S.)

[Tomsworld]

Tunnel endpoint bevind zich echt wel in amsterdam als je kijkt naar de reverse dns in de routing / hostname & latency. He is wel een amerikaans bedrijf.

Theoretisch kan het als HE veel betere ipv6 routing heeft naar de sites + de routing tussen de TS en jouw pc is wel optimaal in v4.

Het is wel grappig want in de praktijk zie je altijd het omgekeerde. tunnel = meer latency.

[ubremoved_539]

Raar dat je bij Telenet zo'n hoge pings hebt op IPv4... mijn resultaten zijn ook van Telenet (al gebruik ik wel niet de TN DNS servers).

De tunnel endpoint is 216.66.84.46 (tserv1.ams1.he.net, located in U.S.)

Dat is in Amsterdam (net zoals die ik gebruik).

[davidm]

Tunnel endpoint bevind zich echt wel in amsterdam als je kijkt naar de reverse dns in de routing / hostname & latency. He is wel een amerikaans bedrijf.

My bad, ik keek naar de eigenaar van het IP whois record.. Inderdaad, deze lijkt in Amsterdam te staan volgens de ptr record.

(al gebruik ik wel niet de TN DNS servers).

Ik gebruikte de Google public DNS servers (ook de ipv6 versie ervan).

[ubremoved_539]

Ik gebruik eveneens 8.8.8.8 en 8.8.4.4... maar heb dus veel lagere prings;

>ping -4 youtube.com

Pinging youtube.com [74.125.136.190] with 32 bytes of data:
Reply from 74.125.136.190: bytes=32 time=17ms TTL=44
Reply from 74.125.136.190: bytes=32 time=16ms TTL=44
Reply from 74.125.136.190: bytes=32 time=16ms TTL=44
Reply from 74.125.136.190: bytes=32 time=16ms TTL=44

Ping statistics for 74.125.136.190:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 17ms, Average = 16ms

... ping ik echter naar het IPv4 adres dat ik in jou posting zie staan dan heb ik ook dergelijke grote pings;

>ping -4 173.194.41.200

Pinging 173.194.41.200 with 32 bytes of data:
Reply from 173.194.41.200: bytes=32 time=55ms TTL=41
Reply from 173.194.41.200: bytes=32 time=55ms TTL=41
Reply from 173.194.41.200: bytes=32 time=54ms TTL=41
Reply from 173.194.41.200: bytes=32 time=55ms TTL=41

Ping statistics for 173.194.41.200:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 54ms, Maximum = 55ms, Average = 54ms

Je probleem zit hem dus bij het resolven van youtube.com ... geen idee waarom je daar een veel slechtere server krijgt ?

[davidm]

Code: Selecteer alles

$ dig A @2001:4860:4860::8888 youtube.com

;; ANSWER SECTION:
youtube.com.		264	IN	A	173.194.41.201
youtube.com.		264	IN	A	173.194.41.193
youtube.com.		264	IN	A	173.194.41.206
youtube.com.		264	IN	A	173.194.41.197
youtube.com.		264	IN	A	173.194.41.198
youtube.com.		264	IN	A	173.194.41.194
youtube.com.		264	IN	A	173.194.41.199
youtube.com.		264	IN	A	173.194.41.200
youtube.com.		264	IN	A	173.194.41.195
youtube.com.		264	IN	A	173.194.41.196
youtube.com.		264	IN	A	173.194.41.192

$ ping 173.194.41.201
PING 173.194.41.201 (173.194.41.201) 56(84) bytes of data.
64 bytes from 173.194.41.201: icmp_req=1 ttl=43 time=53.5 ms
64 bytes from 173.194.41.201: icmp_req=2 ttl=43 time=53.5 ms

Code: Selecteer alles

$ dig A @8.8.8.8 youtube.com

;; ANSWER SECTION:
youtube.com.		245	IN	A	74.125.136.190
youtube.com.		245	IN	A	74.125.136.136
youtube.com.		245	IN	A	74.125.136.93
youtube.com.		245	IN	A	74.125.136.91

$ ping 74.125.136.190
PING 74.125.136.190 (74.125.136.190) 56(84) bytes of data.
64 bytes from 74.125.136.190: icmp_req=1 ttl=46 time=18.6 ms
64 bytes from 74.125.136.190: icmp_req=2 ttl=46 time=18.5 ms

Blijkbaar geven de ipv6 dns servers een ander resultaat dan de ipv4 versies.

[ubremoved_539]

Ik zie niet in waarom je een IPv6 DNS server zou gebruiken... die moet je aanspreken over je tunnel en is dus trager dan een IPv4 server (welke ook gewoon AAAA records geeft).

[davidm]

Omdat ipv6 "cool" is natuurlijk
Nee, maar de bedoeling was om dan op termijn als mijn contract met telenet afloop over te stappen naar edpnet. Dan hoef ik minder te herconfigureren.

[ubremoved_539]

Omdat ipv6 "cool" is natuurlijk

Experimenteren moet hé... al zijn er ook mensen die het enkel doen omdat het cool is (al ga ik geen nieuwe rant starten over modem only's ).

Nee, maar de bedoeling was om dan op termijn als mijn contract met telenet afloop over te stappen naar edpnet. Dan hoef ik minder te herconfigureren.

Over dat minder configureren zou ik nog niet zo zeker zijn... bij IPv4 moet je eigenlijk niets configureren omdat je achter een NAT zit, bij IPv6 heb je geen NAT meer maar allemaal publieke adressen en dat ligt toch wel helemaal anders dan.

[davidm]

Awel ja, maar nu heb ik intussen mijn dns resolv, iptables, server bindings, dns records, etc. wel juist gezet. Dat scheelt toch al wat werk later (temeer omdat ik niet zo computervaardig ben, dat geef ik graag toe).

[ubremoved_539]

op termijn als mijn contract met telenet afloop

Je contract loopt af als jij dat wenst... de opzegtermijnen zijn tegenwoordig heel wat korter dan vroeger.

Awel ja, maar nu heb ik intussen mijn dns resolv, iptables, server bindings, etc. wel juist gezet. Dat scheelt toch al wat werk later

Indien EDPnet op dezelfde manier werkt wat betreft het toekennen van een IPv6 range als je vandaag gebruikt via je tunnel.

Maar ook ik moet bekennen dat m'n IPv6 praktijk ervaring nog ver onder niveau zit om alle consequenties te begrijpen.

[davidm]

Je contract loopt af als jij dat wenst... de opzegtermijnen zijn tegenwoordig heel wat korter dan vroeger.

Zo'n vaart zal het ook nog niet lopen. Ik moet eerst nog kijken door wat en hoe ik de vaste lijn en televisie ga vervangen. Ben momenteel nog aan het vergelijken.

Indien EDPnet op dezelfde manier werkt wat betreft het toekennen van een IPv6 range als je vandaag gebruikt via je tunnel.

Voor zover ik de wiki van edpnet mag geloven kun je rechtstreeks een ipv6 PPPoE verbinding opzetten. Dan zou ik gewoon de 6in4 tunnel moeten vervangen door een pppoe tunnel (desnoods doe ik dat dan op de router zelf).

[krisken]

Klopt : je krijgt een /64 ipv6 range bij edpnet

[ITnetadmin]

Omdat ipv6 "cool" is natuurlijk

Experimenteren moet hé... al zijn er ook mensen die het enkel doen omdat het cool is (al ga ik geen nieuwe rant starten over modem only's ).

Nee, maar de bedoeling was om dan op termijn als mijn contract met telenet afloop over te stappen naar edpnet. Dan hoef ik minder te herconfigureren.

Over dat minder configureren zou ik nog niet zo zeker zijn... bij IPv4 moet je eigenlijk niets configureren omdat je achter een NAT zit, bij IPv6 heb je geen NAT meer maar allemaal publieke adressen en dat ligt toch wel helemaal anders dan.

Ik ben benieuwd hoelang dat NAT-less zal blijven duren, eerlijk gezegd. Want als er genoeg mensen en bedrijven achter zagen komt dat er mss ooit nog eens van. Er zullen nog wel ITers/bedrijven zijn die liever hun netwerk volledig afzonderen van buitenaf.

Ik ga daar dringend eens mee moeten prullen, want ik vraag me toch af hoe je fixed IPs kan instellen op je toestellen zonder risico op lange termijn dat er iets verandert.

[ Post made via mobile device ]

[lithion]

Bij mij zijn de IPv6 pings naar google veel slechter (dual stack connected)


Pingen naar www.google.com [173.194.66.103] met 32 bytes aan gegevens:
Antwoord van 173.194.66.103: bytes=32 tijd=11 ms TTL=47
Antwoord van 173.194.66.103: bytes=32 tijd=11 ms TTL=47
Antwoord van 173.194.66.103: bytes=32 tijd=12 ms TTL=47
Antwoord van 173.194.66.103: bytes=32 tijd=12 ms TTL=47


Pingen naar www.google.com [2a004007:807::1014] met 32 bytes aan gegevens:

Antwoord van 2a004007:807: tijd=43 ms
Antwoord van 2a004007:807: tijd=43 ms
Antwoord van 2a004007:807: tijd=43 ms
Antwoord van 2a004007:807: tijd=43 ms

[ubremoved_539]

Ik ben benieuwd hoelang dat NAT-less zal blijven duren, eerlijk gezegd. Want als er genoeg mensen en bedrijven achter zagen komt dat er mss ooit nog eens van. Er zullen nog wel ITers/bedrijven zijn die liever hun netwerk volledig afzonderen van buitenaf.

Oh maar IPv6 NAT bestaat hoor... alléén is er geen enkele (logische) reden om het te gebruiken.

Ik ga daar dringend eens mee moeten prullen, want ik vraag me toch af hoe je fixed IPs kan instellen op je toestellen zonder risico op lange termijn dat er iets verandert.

Op zich heb je de fe80 reeks die je intern kan gebruiken... maar heb ook geen idee of dat dat de aanbevolen oplossing is.

[ITnetadmin]

Ik kan "totale en absolute controle over het netwerk" al direct als argument gebruikt horen worden.

En inderdaad, als je al mogelijk geen fixed IPs kan instellen die onafhankelijk van enige invloed van buitenaf bestaan en constant blijven, dan zie ik genoeg ITers die desnoods met zo'n NAT aan het werk zullen gaan, kwestie van zelf alle controle over de IPs enzo te behouden.

Maar kom, niet te veel paniekzaaierij, we zullen wel zien...

Also, ik word gek van die hex waarden, waarom konden we dat niet gewoon in dec zetten, zoals we ook met ipv4 gedaan hebben?

[ Post made via mobile device ]

[davidm]

Op zich heb je de fe80 reeks die je intern kan gebruiken... maar heb ook geen idee of dat dat de aanbevolen oplossing is.

Probleem met de fe80::/10 range is dat iedere nic verplicht zo'n nummer heeft, en dus by default er geen entries in de routeringstabel voor deze range worden toegevoegd. Standaard tools zoals ping6, ndisc6, ssh etc. vereisen dus altijd ook de nic (als extra argument of in de vorm [adres]%ethX ). Ik ben niet zeker, maar ik vermoed dat het niet de bedoeling is om die addressen na de set-up fase nog te gebruiken.
Voor mijn LAN routering heb ik de fec0::/10 range gebruikt. Werkt perfect, en net zoals we met NAT gewoon zijn.
Het idee dat één computer slechts één ip heeft is ook maar een IPv4 concept hé. Dat die externe adressen kunnen veranderen doet er dan eigenlijk niet meer toe (wat trouwens onwaarschijnlijk lijkt, als je ISP je een vast 64-blok toekent).

Also, ik word gek van die hex waarden, waarom konden we dat niet gewoon in dec zetten, zoals we ook met ipv4 gedaan hebben?

Ha neen, 't is zo al genoeg typwerk erbij (bovendien heb je nu leuke adressen zoals FACE:B00C::, kan je gemakkelijk content filteren ). Wat wel vervelender is is dat je nu ook altijd [ ] haken moet gebruiken als er een poort bij moet.

[ubremoved_539]

Mmm... het zijn daar inderdaad grapjassen, al heb ik nogal funny adressen gezien.

Code: Selecteer alles

>ping www.facebook.com

Pinging star.c10r.facebook.com [2a03:2880:2110:3f07:face:b00c:0:1] with 32 bytes
 of data:
Reply from 2a03:2880:2110:3f07:face:b00c:0:1: time=119ms
Reply from 2a03:2880:2110:3f07:face:b00c:0:1: time=119ms
Reply from 2a03:2880:2110:3f07:face:b00c:0:1: time=117ms
Reply from 2a03:2880:2110:3f07:face:b00c:0:1: time=119ms

Ping statistics for 2a03:2880:2110:3f07:face:b00c:0:1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 117ms, Maximum = 119ms, Average = 118ms

Al hebben ze wel hoge ping waardes op IPv6.

[davidm]

Al hebben ze wel hoge ping waardes op IPv6.

Moeten we daar rouwig om zijn?

[ubremoved_539]

Nope... ik heb toch geen facebook account... en wil dat ook zo houden.