EDPnet IPv6

[datakiller]

Ik heb zojuist mijn IPv6 werkend gekregen, maar als ik nu een traceroute doe naar cloudflare.com (IPv6) dan word ik geroute naar Israel, andere IP's zoals jinglepings, serverius doen het wel gewoon zoals het hoort.

Heeft iemand hier nog last van? (tracert -6 cloudflare.com)

Screenshot traceroute:

[CCatalyst]

Vreemde route, eerst naar Londen en dan via de Juniper LAN de Bezeq backbone op en backtracken naar Israel.

Maar zoals ik al zei, die databases zijn niet accuraat, hier zeker niet want ze geven de ganse netblock dezelfde locatie, wat onmogelijk is voor een backbone. Die eerste twee Bezeq routers - waaronder de router die je met je pijltje aanduidt - staan bv al zeker in Londen ipv Israel, maar dan gaat het nog via 2 locaties waarvan ik niet weet waar het is. Het kan dus ook zijn dat je via de Bezeq backbone gaat maar niet helemaal tot in Israel.

Voor de zekerheid, ga naar https://www.cloudflare.com/cdn-cgi/trace over IPv6 en de colo parameter zal zeggen in welk CF datacenter je effectief terecht komt.

Indien dat effectief TLV is, welke DNSv6 servers gebruik je dan wel die cloudflare resolven naar Israel? IP's geven aub.

[datakiller]

Indien dat effectief TLV is, welke DNSv6 servers gebruik je dan wel die cloudflare resolven naar Israel? IP's geven aub.

Code: Selecteer alles

uag=Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
colo=TLV
http=h2
loc=BE
tls=TLSv1.3
sni=plaintext

DNS: Zowel google (dns servers van google site gehaald) als cloudflare https://1.1.1.1 (de IPv6 servers op die pagina) getest.

Toen mijn IPv6 adres door een fout een soort van over mijn telenet lijn liep was de latency naar cloudflare 15 - 25ms (IPv6)

[CCatalyst]

Toen mijn IPv6 adres door een fout een soort van over mijn telenet lijn liep was de latency naar cloudflare 15 - 25ms (IPv6)

Ja want je komt dus idd in Israel aan met een zeer bizarre routing via Londen.

Wat als je de DNSv6 servers van EDPnet zelf configureert?

Hou wel rekening dat de TTL van de AAAA records op 5 minuten staat. Eventuele vorige opzoekingen blijven dus 5 minuten in de cache staan tenzij je de cache wist.

Ik krijg wel de indruk dat het niet de DNS is maar dat het probleem eerder bij de IPv6 routing/peering van EDPnet zit. Volgens hun looking glass, die helaas nog geen IPv6 ondersteunt, is de IPv4 routing wel in orde en gaat het dan via Cogent naar Brussel, maar ze peeren niet met Cogent op IPv6, dus mogelijks is het daar minder optimaal geconfigureerd.

[datakiller]

Ik krijg wel de indruk dat het niet de DNS is maar dat het probleem eerder bij de IPv6 routing/peering van EDPnet zit. Volgens hun looking glass, die helaas nog geen IPv6 ondersteunt, is de IPv4 routing wel in orde en gaat het dan via Cogent naar Brussel, maar ze peeren niet met Cogent op IPv6, dus mogelijks is het daar minder optimaal geconfigureerd.

Inderdaad, IPv4 is hier ook compleet normaal (de snelste / 1 van de snelste dns servers)

De DNS van EDPnet zal ik zometeen eens testen ik zal dit bericht editen (als het dan nog gaat).

Edit: getest helaas nog steeds hetzelfde. (Deze IPv6 DNS servers)

[CCatalyst]

Je zal dit bij EDPnet zelf moeten aankaarten. Jij kan hier niets aan doen.

Ofwel zit er een fout in de configuratie van de routing, ofwel hebben ze op dit ogenblik gewoon echt geen betere IPv6 peering met CloudFlare dan dit (omwille van economische, technische, juridische, politieke, ... redenen).

Als je geen of een weinig bevredigend antwoord krijgt van EDPnet mag je gerust ook melden aan CloudFlare dat er IPv6 verkeer van Belgie over Londen naar hun TLV datacenter sluipt met latencies van 75ms. Wellicht zal CloudFlare dan ook wel contact opnemen met EDPnet en kijken of een oplossing mogelijk is.

Mooie vangst wel! Ik denk dat er maar weinig klanten zijn die dit zouden kunnen ontdekken.

[wisentje]

Overlaats ging de ipv4 routering van edpnet naar telenet via london, rusland en nederland.
de routing terug ging wel direct via bnix. ik heb toen een ticket aangemaakt om dit te melden
en een uur later was hadden ze het opgelost. vermoedelijk is het op ipv6 nu ook zoiets...

[datakiller]

Overlaats ging de ipv4 routering van edpnet naar telenet via london, rusland en nederland.

Hier had ik ook zoiets maar dan BE - UK - FR - DE - NL

Je zal dit bij EDPnet zelf moeten aankaarten. Jij kan hier niets aan doen.

Zal ik doen, hopelijk wordt het opgelost.

[CCatalyst]

Hier had ik ook zoiets maar dan BE - UK - FR - DE - NL

Ze sturen hun data precies wel graag naar Londen.

De normen zijn 100ms volgens de livechat (naar NL)

100 ms naar NL Latency 100 ms is vandaag de norm naar "Datacenter Alley" in Ashburn VA, het drukste internetknooppunt ter wereld. Dat ligt net ten noorden van de internationale luchthaven van Washington/Dulles, hier 6000 km vandaan.

Soit, hou ons zeker op de hoogte van wat EDPnet zegt over die IPv6 routering.

[datakiller]

Soit, hou ons zeker op de hoogte van wat EDPnet zegt over die IPv6 routering.

Zal ik doen.

[lithion]

Toevallig aan het testen over een wifiverbinding of met een lopende upload? Het feit dat je bij hop 2 al 2 timeouts hebt geeft toch ook wel rare dingen aan met je eigen netwerk. Mijn test ziet er toch al beter uit dan die van jij.

Code: Selecteer alles

traceroute6 to 2001:4cd0:32:7004::1 (2001:4cd0:32:7004::1) from 2a02:578:85a2:3a0:5507:d902:5102:e623, 64 hops max, 12 byte packets
 1  fritz.box  2.353 ms  1.318 ms  3.179 ms
 2  2a02:578:1000:5::2  14.749 ms  14.226 ms  14.412 ms
 3  2a02:578:1:4d::1  10.552 ms  9.780 ms  10.736 ms
 4  router01.ldn.uk.edpnet.net  15.763 ms  15.371 ms  15.576 ms
 5  2001:4cd0:32:7004::1  17.464 ms
    2001:7f8:4::2167:2  16.879 ms  17.024 ms

[CCatalyst]

De routering naar Israel gebeurde pas na Londen (langs waar jij ook gaat), dus zal niet aan zo'n zaken liggen.

Probleem is wellicht opgelost dan. Blijkbaar is het ook de bedoeling dat je naar Londen ipv Brussel gaat voor CF over IPv6 bij EDPnet.

Ofwel heeft OP EDPnet gecontacteerd, of ze hebben deze topic gelezen of het was gewoon iets tijdelijks (de gebruikelijke peering met CloudFlare was misschien tijdelijk niet beschikbaar vanaf EDPnet router in Londen).

[datakiller]

Toevallig aan het testen over een wifiverbinding of met een lopende upload? Het feit dat je bij hop 2 al 2 timeouts hebt geeft toch ook wel rare dingen aan met je eigen netwerk. Mijn test ziet er toch al beter uit dan die van jij.

Nee, bedraad, geen upload/download.
Ook kan ik zelf (denk ik) niet cloudflare naar Israel doorsturen.
Met mijn thuisnetwerk is niets mis, er zit wat packet loss op de traceroute maar als dit mijn netwerk is zou de bestemming (cloudflare) ook packet loss hebben.

Probleem is wellicht opgelost dan. Blijkbaar is het ook de bedoeling dat je naar Londen ipv Brussel gaat voor CF over IPv6 bij EDPnet.

Nog steeds Israel hier
Zou het aan mijn static IPv6 range kunnen liggen?

Ofwel heeft OP EDPnet gecontacteerd, of ze hebben deze topic gelezen of het was gewoon iets tijdelijks (peering met CloudFlare was misschien tijdelijk niet beschikbaar vanaf EDPnet router in Londen).

Nog geen antwoord gehad.

[datakiller]

Update:

Edpnet: "We gaan hen vragen om deze peering via AMS-IX (Amsterdam) te laten lopen om te zien of dit een verbetering geeft op de connectie."

Afwachten dus

[datakiller]

Update 2: Opgelost, Omdat AMS te lang duurde hebben ze Londen gepakt.

[TheCeet]

Als ik ipv6 inschakel, kan ik het dan achteraf ook terug uitschakelen?
En is ipv4 dan nog steeds actief of vervangt ipv6 het ipv4 adres?

[WalterB1]

Op niveau van de Fritzbox kun je IPv6 inschakelen of terug uitschakelen, voor zover het actief is op uw EDpnet-lijn.

Dat moet je eerst inschakelen bij EDPnet;
https://www.edpnet.be/nl/support/instal ... -ipv6.html

Als dat actief is heb je nog steeds IPv4 beschikbaar. Je hebt gewoon IPv4 en ook tegelijk IPv6 beschikbaar. Indien gewenst kun je dan IPv6 ondersteuning terug uitschakelen op de Fritzbox en dan heb je terug enkel IPv4.

Aanvulling; ik heb geen Fiber van EDPnet maar VDSL. Mogelijk anders voor u.

[liegebeestig]

Maar is er een direct voordeel? Ik snap het nut als klant op dit moment niet.

[WalterB1]

Wel, zoals ik het begrijp heb je met ook IPv6 toegang tot 'meer internet'. Er zouden stukken internet zijn die enkel op IPv6 draaien, vooral in Azië.

Maar dat in praktijk zolang je niet in obscure plekken zit te neuzen van het internet dat in praktijk niets uitmaakt. Natuurlijk globaal, als het de bedoeling is uiteindelijk volledig over te stappen op IPv6 dan moeten eerst zoveel mogelijk mensen daarvoor ondersteuning hebben. Of dat nu voor die gebruikers een verschil maakt of niet.

[GuntherDW]

Maar is er een direct voordeel?

Je krijgt toegang tot een /64 voor je WAN prefix en afhankelijk van je abbo een /48 of een /56 als LAN prefix.
Allemaal extern te routeren ipv je enige IPv4 IP.

Alsook is er minder geblokkeerd uitgaand dan op IPv4.

Maar inderdaad, je kan het uitzetten, je blijft gewoon een (extern) IPv4 adres houden etc.
Toekomstgewijs blijft IPv6 iets waar we heen moeten inderdaad, en het aantal aansluitingen met IPv6 connectivity stijgt constant. Wij stonden als Belgie met ons klein landje een tijdje bovenaan aan de top zelfs!

Een jaar of 10 geleden waren er nog issues met sites welke lastig of amper werkten als je het enabled had staan (lees: sites die het aan hadden staan, ook in de DNS maar dan uiteindelijk toch enkel antwoorden over IPv4 wat voor timeouts zorgde), maar tegenwoordig merk je daar amper meer van eigenlijk.

[WalterB1]

Interessant;
https://www.facebook.com/ipv6/?tab=ipv6_country

Facebook heeft een tool op de IPv6 adoptatie te raadplegen. Facebook is zeer goed geplaatst om daar data over te verzamelen. België zit op 52%.

Aanvulling; China zit op 6,88%. Maar zowat iedereen die in China op Facebook zit zal wel via een VPN verbonden zijn. Die cijfers zeggen natuurlijk niet alles.

[GuntherDW]

Nuja, voor mij zijn de grootste voordelen natuurlijk dat je geen NAT meer hebt. En dus die hele hoop IP's ter beschikking.

Je kan natuurlijk (er zijn "sommigen" hier welke erbij zweren ) wel nog altijd NAT6 gebruiken maar voor de meeste use cases is het niet echt nodig.

Hetgeen je wel gaat moeten weten is dat, gezien alle devices ineens een extern routeerbaar uniek IP krijgen een goed ingestelde firewall meer van belang is.
Je kan je dus niet zomaar meer "beschermen" achter het idee van "NAT", al is NAT geen firewall natuurlijk.

Nuja, de meeste default instellingen van de ISP geleverde modems is dat je ook poorten moet "open" zetten, dus dat niet zomaar elk adres open staat, maar het blijft iets wat je in je achterhoofd moet houden. Vooral als je een "huis/tuin/keuken" routertje gebruikt of wat meer "professioneler" apparaten als een Unify of Mikrotik router.

[driesp]

Het voordeel van ook IPv6 te activeren is dat je internet verbinding gewoon stabieler is.

Elke recente browser doet aan 'happy eyebals'.
Dat is een algoritme dat automatisch het snelste protocol gebruikt om de website te bezoeken.
Als het ene protocol iets sneller is zal de communicatie verder lopen over dat protocol.
Verder is IPv6 meestal het geprefereerd protocol boven v4.

Daarnaast merk ik ook vaker dat de latency van v6 routes beter zijn tov v4.
Er kan evengoed ook een probleem zijn op de route over v4.
Wanneer je beide protocollen ter beschikking hebt, ben je dus in het algemeen beter af.

[GuntherDW]

Spijtig genoeg wel nog altijd bedrijven en guides online welke bij het minste probleem "probeer eens IPv6 uit te zetten" gaan.
Waarna het als het daarna opgelost is compleet vergeten of gewoon zo laten en voor de rest jarenlang (deliberately in het geval van bedrijven, zelfs mensen die weten hoe/wat/waar doen dit spijtig genoeg) het uitzetten.

Als je enkel naar "de groten" surft of gebruikt als cloudflare, google (dus ook youtube etc), facebook (dus ook instagram etc) ga je het probleem minder hebben maar het is er nog wel spijtig genoeg.

Latency die minder is over IPv6 dan over IPv4 ben ik nog niet tegengekomen eigenlijk. Eerder het tegenovergestelde als je van een tunnel als HE.net of sixxs indertijd gebruikmaakt.
Nudat ik edpnet heb en native ipv6 merk ik eigenlijk geen verschil tussen IPv6 of IPv4 latencies. Al moet ik eerlijk zijn dat ik het nooit echt "in depth" ben gaan nakijken.
Heb wel een smokeping draaien maar merk daar geen verschil tussen v4 en v6 voor de meeste hosts.

In effect kan IPv6 zelfs minder netto bandbreedte geven als je veel connections hebt gezien de grotere packet headers e.d. eigenlijk (lees: P2P situaties).

Maar de makkelijkste manier om te kijken of IPv6 werkt voor je IMO blijft https://ipv6-test.com/
edpnet doet niet aan RDNS over hun v6 subnets spijtig genoeg (of toch niet voor consumentenlijnen), maar voor de meeste dingen maakt dat ook niet veel uit tenzij je servers draait.