IPv6 Internet Is Broken

152 views
Skip to first unread message

Petr Nachtmann

unread,
Dec 11, 2022, 4:59:14 AM12/11/22
to g...@sh.cvut.cz
Jak to nyní vypadá s IPv6 peeringem u nás?

IPv6 Internet Is Broken

The Internet is made up of a bunch of smaller networks. All these small networks connect to one another is some manner. Some of them buy IP transit from other networks, some of then peer with one another for free. Whatever the case may be, everyone on the Internet should be able to reach everyone else connected to the Internet. This is true when it comes to IPv4. This is currently not true when it comes to IPv6.

IPv6 is a newer Internet protocol which is slowly being adopted to make up for some of the IPv4 shortcomings. Mainly the fact that IPv4 address space has largely run out.

At this moment everyone still uses IPv4 and a lot of people also use IPv6 simultaneously. Many networks use both IPv4 and IPv6 at the same time. This is called a dual stack. This is great because it allows a nice gradual transition from IPv4 to IPv6 without breaking anything.

The problem is that the IPv6 Internet is currently broken. Two of the largest IPv6 Internet providers do not peer with one another.

Cogent (AS174) and Hurricane Electric (AS6939) do not peer with one another over IPv6. Both of these networks provide a large chunk of the IPv6 Internet and neither of them pays a third network for IPv6 transit. This means a customer of Cogent can not reach Hurricane Electric over IPv6, and vice versa. This has been true for a number of years.

If two networks do not directly peer with one another one or both of the networks will buy IP transit from a third network. This third network connects to both of the first networks, allowing them to communicate indirectly through the third network. This is true of all IPv4 Internet. This is also true for Cogent and Hurricane Electric for IPv4.

However, neither network buys IPv6 transit, so there is no third party network connecting them over IPv6.

To see what is going on take a look at Cogent's looking glass and see how an IPv4 ping to he.net compares to a IPv6 ping to he.net. It doesn't matter which Cogent router is chosen, as all of them will have the same result.

First IPv4 from Cogent to Hurricane Electric:

PING he.net (216.218.186.2) 56(84) bytes of data. 64 bytes from he.net (216.218.186.2): icmp_seq=1 ttl=57 time=2.34 ms 64 bytes from he.net (216.218.186.2): icmp_seq=2 ttl=57 time=2.41 ms 64 bytes from he.net (216.218.186.2): icmp_seq=3 ttl=57 time=2.40 ms 64 bytes from he.net (216.218.186.2): icmp_seq=4 ttl=57 time=2.42 ms 64 bytes from he.net (216.218.186.2): icmp_seq=5 ttl=57 time=2.40 ms --- he.net ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 2.349/2.400/2.425/0.051 ms

No problems at all over IPv4. Now IPv6:

PING he.net(he.net) 56 data bytes From 2001:550:1:321::1 icmp_seq=1 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=2 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=3 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=4 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=5 Destination unreachable: No route --- he.net ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4008ms

"No route" means that this Cogent router has no idea where to even send the ping packets. It's not that there is a problem in the path to he.net, it's that the router doesn't have a path to he.net over Ipv6.

You can run the same test from Hurricane Electric's looking glass testing to cogentco.com. You will see that IPv4 works but IPv6 does not.

Recently Cogent also stopped IPv6 peering with Google (AS15169). Most large Internet companies such as Google have their own networks. The lack of peering between Google and Cogent means that users who have Cogent as their only ISP cannot reach Google over IPv6.

Again, from Cogent's looking glass to google.com over IPv4 works fine:

PING google.com (216.58.192.46) 56(84) bytes of data. 64 bytes from nuq04s30-in-f14.1e100.net (216.58.192.46): icmp_seq=1 ttl=46 time=52.3 ms 64 bytes from nuq04s30-in-f14.1e100.net (216.58.192.46): icmp_seq=2 ttl=46 time=52.3 ms 64 bytes from nuq04s30-in-f14.1e100.net (216.58.192.46): icmp_seq=3 ttl=46 time=52.3 ms 64 bytes from nuq04s30-in-f14.1e100.net (216.58.192.46): icmp_seq=4 ttl=46 time=52.3 ms 64 bytes from nuq04s30-in-f14.1e100.net (216.58.192.46): icmp_seq=5 ttl=46 time=52.3 ms --- google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4057ms rtt min/avg/max/mdev = 52.332/52.358/52.383/0.251 ms

But IPv6 is broken:

PING google.com(nuq04s30-in-x0e.1e100.net) 56 data bytes From 2001:550:1:321::1 icmp_seq=1 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=2 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=3 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=4 Destination unreachable: No route From 2001:550:1:321::1 icmp_seq=5 Destination unreachable: No route --- google.com ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4009ms

IPv4 still works to connect all three of the above, so most end-users should not notice the problem with the IPv6 Internet.

These networks have a disagreement over peering policy. In this case Cogent expects Google and Hurricane Electric to pay Cogent money for their IPv6 routes. Google and Hurricane Electric have stated they are happy to peer for free with Cogent, but refuse to pay Cogent money.

This hurts the customers of all three networks. All the parties involved know that it is hurting their customers but they are playing a game of chicken with one another to see who blinks first.

If Cogent blinks first they will accept settlement-free peering with the other two companies. If Google or Hurricane Electric blink first then they will pay Cogent to peer with them. Until one of these happens, then the IPv6 Internet will remain broken.

Because IPv4 is still the main Internet protocol, this is IPv6 peering conflict is likely not hurting anyone enough for the game of chicken to end anytime soon.

As bad as all this seems, there is a silver lining. IPv6 peering disputes mean that networks are beginning to take IPv6 more seriously and are starting to see the value in IPv6 traffic. cogent believes the IPv6 traffic it provides is valuable enough that other companies must pay for it. Google and Hurricane Electric both believe that their IPv6 traffic is valuable enough that Cogent should establish settlement-free peering with them. So while the IPv6 Internet is broken, this might just be a necessary step in creating a more robust IPv6 Internet.

Pavel Troller

unread,
Dec 21, 2022, 3:30:32 PM12/21/22
to GSM conference at Silicon Hill
Zdravím,
no jak to vypadá konkrétně u mě ?

Všechny v článku zmíněné pingnu:
patrol@log:~$ ping 2001:550:1:321::1
PING 2001:550:1:321::1(2001:550:1:321::1) 56 data bytes
64 bytes from 2001:550:1:321::1: icmp_seq=1 ttl=49 time=209 ms
64 bytes from 2001:550:1:321::1: icmp_seq=2 ttl=49 time=197 ms
64 bytes from 2001:550:1:321::1: icmp_seq=3 ttl=49 time=192 ms
64 bytes from 2001:550:1:321::1: icmp_seq=4 ttl=49 time=197 ms
64 bytes from 2001:550:1:321::1: icmp_seq=5 ttl=49 time=198 ms
^C
--- 2001:550:1:321::1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 192.411/199.104/209.730/5.716 ms
patrol@log:~$ ping he.net
PING he.net(he.net (2001:470:0:503::2)) 56 data bytes
64 bytes from he.net (2001:470:0:503::2): icmp_seq=1 ttl=45 time=181 ms
64 bytes from he.net (2001:470:0:503::2): icmp_seq=2 ttl=45 time=170 ms
64 bytes from he.net (2001:470:0:503::2): icmp_seq=3 ttl=45 time=169 ms
64 bytes from he.net (2001:470:0:503::2): icmp_seq=4 ttl=45 time=172 ms
64 bytes from he.net (2001:470:0:503::2): icmp_seq=5 ttl=45 time=176 ms
^C
--- he.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 169.676/174.143/181.486/4.456 ms
patrol@log:~$ ping google.com
PING google.com(prg03s12-in-x0e.1e100.net (2a00:1450:4014:80e::200e)) 56 data bytes
64 bytes from prg03s12-in-x0e.1e100.net (2a00:1450:4014:80e::200e): icmp_seq=1 ttl=56 time=21.2 ms
64 bytes from prg03s12-in-x0e.1e100.net (2a00:1450:4014:80e::200e): icmp_seq=2 ttl=56 time=20.2 ms
64 bytes from prg03s12-in-x0e.1e100.net (2a00:1450:4014:80e::200e): icmp_seq=3 ttl=56 time=19.7 ms
64 bytes from prg03s12-in-x0e.1e100.net (2a00:1450:4014:80e::200e): icmp_seq=4 ttl=56 time=95.4 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms

U těch prvních dvou amerických je tedy ten rtt mizerný, ale Google, nejspíše dle hostname český, pingá slušně.
Nebezi.cz pingnu taky slusne, a je v jine siti:
patrol@log:~$ ping nebezi.cz
PING nebezi.cz(www.nebezi.cz (2001:1528:132:70::ebe2)) 56 data bytes
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=1 ttl=54 time=26.1 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=2 ttl=54 time=44.7 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=3 ttl=54 time=24.3 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=4 ttl=54 time=22.4 ms
64 bytes from www.nebezi.cz (2001:1528:132:70::ebe2): icmp_seq=5 ttl=54 time=30.6 ms
^C
--- nebezi.cz ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 22.457/29.671/44.717/7.999 ms

Už mne nenapadá, co dále pingat, ale z mého pohledu je IPv6 network jakž-takž v cajku :-).

Pavel

Michal Gust

unread,
Dec 21, 2022, 11:57:58 PM12/21/22
to GSM conference at Silicon Hill
Zdravím,

to se dalo čekat, že problém mají v podstatě jen ti dva kohouti a
prakticky z jakékoli jiné sítě budou dostupní oba.
Každý tier2 provider má minimálně 2 nezávislé upstream, nižší tear totéž
a byla by asi extrémní smůla, kdyby na jednoho z těch dvou nevedl ani
jeden provider v upstream "stromu"... A protože k tier1 se pravděpodobně
nebude připojovat žádný malý - single home zákazník, tak škodí v podstat
jen sobě plus zákazníkům, co mají servery u nich v DC (minimálně tím, že
se snižuje redundance jejich spojení k uživatelům), což může vést k
nižší poptávce po jejich DC...

Pokud jde o Google, tak to mi už přijde úplně postavené na hlavu -
Google je content provider a při jeho síle by si spíš sám mohl účtovat
za konektivitu k jeho službám. Ale Google je naopak velmi vstřícný,
staví DC v každé díře jakou je CZ a má otevřenou peering policy (peeruje
s každým, kdo má zájem). Na tom fakticky vydělávají provideři, zejména
místní (národní), protože za upstrean ušetří majlant...
O to spíš, že je Google přítomen a otevřeně peeruje skoro všude, nevidím
důvod, aby někomu platil za konektivitu, kterou by ten, komu by Goole
platil, de facto připojil jen své vlastní zákazníky ke Googlu (žádný IP
tranzit někoho další de facto není třeba).

Celkem zajímavé je to, že Hurricane Electric je podobně vstřícný - také
je přítomen a má otevřenou peering policy v mnoha malých peering
pointech, což není u teer1 providerů příliš obvyklé. Mohlo by se zdát,
že je to u teer1 dokonce hloupost, protože tím poskytují lokálním
providerům upstream v podstatě jen tak zdarma a okrádají se o příjmy.
Ale ono to zase není takový nesmysl/hloupost. Dnes, kdy jsou k dispozici
400Gb interfacy a 100Gb jsou za celkem přijatelnou cenu, není kapacita
na většině páteřních linek skutečně zásadní problém (pochybuji, že by z
CZ nějaký tear1 naplnil 100Gb, natož 400Gb). HE tak jen obětuje část
kapacity, která ho tak moc nestojí. Přitom ale o zisky nepřipravuje ani
tak sebe jako konkurenci, ke které je ten tear2+ provider připojen,
protože přes peering nejde tranzit, jen provoz do vlastní sítě HE, který
by tam s větší pravděpodobností došel v nějakém významnějším peeringovém
bodě, než že by byl součást nějakého agregovaného upstreamu. Zároveň to,
že se traffic dostane k uživatelům providerů v každé "díře" nejkratší
cestou po vlastní vysokorychlostní síti, může HE lehce prodat zákazníkům
jeho DC, protože s RTT v jednotkách ms pro mezistátní linky opravdu není
nezbytně nutné mít server v DC v každé zemi, ale stačí mít pokryté 3-4
DC a můžete mít velmi rychlé odezvy po celé Evropě.

Nicméně je celkem zajímavé pozorovat na traceroutech, jak na tu IPv6
stejně všichni dost kašlou, i když spolu zrovna neodmítají peerovat zcela.

U HE toho až tak moc vidět není, protože HE má servery pro svůj web až
někde v Caliornii (asi Fremont) a většina tranzitních routerů neposílá
ICMP pro expired TTL. Jedinou zajímavostí je snad to, že ani IPv4 nejde
přes peering Cesnet-HE v NIX, ale jde přes Geant do nějakého jiného IX.

Z Cogentu ta neochota k IPv6 peerinu přímo sálá - servery mají zjevně ve
Frankfurtu, na IPv4 paket z Cesnetu jde v Praze upstream do Seabone, po
ní do Frankurtu a tam rovnou do Cogentu s RTT 7,5ms. Kdežto na IPv6 se
někde poměrně hodně dlouho (30ms) fláká po Seabone, aby se do Cogentu
dostal až v Bulharské Sofii s dalšími 5ms a nakonec do Frankurtu s
celkovým RTT 57ms (vs 7,5 na IPv4). To už samozřejmě dokáže odezvy webu
ovlivnit viditelně a gameři by z toho měli osypky.

Ale co mě překvapuje asi nejvíc, že ani Google s Cesnetem nejsou
"svatí", i když se oba léta tváří jako velcí průkopníci IPv6. V NIXu je
IPv6 peering, jak Cesnet, tak Google deklarují IPv6 peering s open
policy, přesto IPv4 jede přes NIX a na 2 hopy je v pražském DC Google s
RTT pouhých 0.6ms, kdežto IPv6 jde přes Geant do Frankurtu, aby skončila
v nějakém tamnějším DC s RTT 7,8ms.
Je však nutné podotknout, že reverzní DNS IPv6 začíná prg03s11, cože je
shodné s IPv4 v Praze a zřejmě to značí služby určené pro CZ, takže to
máslo na hlavě je primárně Googlu, že v Praze má nejspíš jen IPv4
serverovou infrastrukturu a IPv6 až ve Frankurtu.

MG.
Reply all
Reply to author
Forward
0 new messages