iljitsch.com - ipv6

Can't ping your Mac? Make this change

Tue, 27 Dec 2022 16:06:39 GMT

Having trouble pinging or tracerouting your Mac?

That's because Apple's default is now to have the firewall "stealth mode" activated. That means your Mac doesn't respond to stuff like pings. If that's not what you want, simply uncheck that box in the firewall pane of the System Settings:

Letting your Mac respond to pings and traceroutes should not cause any trouble. But if in doubt, just keep the box checked.

Heeft echt maar 9% van de Nederlandse Google-gebruikers IPv6?

Thu, 01 Dec 2022 09:22:35 GMT

Al heel wat jaren kijk ik af en toe naar deze grafiek waar we kunnen zien hoeveel Google-gebruikers de beschikking hebben over IPv6:

Langzaam maar zeker gaat het wereldgemiddelde richting de 50%. In Europa bereikte België die mijlpaal al een aantal jaren geleden, en ook bijvoorbeeld Duitsland en Frankrijk zijn over de helft. Maar een klein ~~dorpje~~ landje blijft dapper weerstand bieden tegen de oprukkende nieuwe versie van het Internet Protocol:

Twee weken geleden scoorde Nederland 14% en inmiddels is dit afgenomen tot 9%. Maar kan dat wel kloppen? Uit de statistieken voor IPv6-gebruik in Nederland van Facebook, Akamai en APNIC komt toch een heel ander beeld naar voren. Ik heb ze hier gecombineerd:

Met zo'n 37% doet Nederland het nog steeds aanmerkelijk slechter dan de buurlanden. De grafieken laten wel duidelijk verschillen zien, maar het verschil met Google is wel van een andere orde. Het lijkt erop dat er toch iets bijzonders aan de hand is met Google's IPv6-metingen in Nederland.

En wat zou kunnen verklaren dat Nederland het qua IPv6 slechter doet dan de buurlanden? Ik begrijp dat zowel Ziggo/Vodafone als KPN, de twee grote consumenten-ISPs in het land, IPv6 nu wel standaard aan zetten op hun laatste generatie modems, maar niet op de oudere modems die veel klanten nog gebruiken. Het is goed mogelijk dat in onze buurlanden de breedband-revolutie wat later op gang kwam zodat gebruikers daar gemiddeld nieuwere modems hebben. En waarschijnlijk voelen ISPs in Nederland de druk minder omdat Nederland relatief veel IPv4-adressen heeft. Een kleine vergelijking:

US: 1617.10 M = 4.85 IPv4-adressen per inwoner
DE:  123.73 M = 1.47 IPv4-adressen per inwoner
FR:   82.34 M = 1.21 IPv4-adressen per inwoner
NL:   49.96 M = 2.81 IPv4-adressen per inwoner
BE:   12.36 M = 1.06 IPv4-adressen per inwoner

Ik ben benieuwd hoe dit zich de komende tijd gaat ontwikkelen.

Free Range Routing vs Quagga/Cisco

Wed, 02 Nov 2022 17:56:41 GMT

Back in the 1990s, I used Cisco routers. Mostly rather underpowered ones such as the Cisco 2500 series. I later started using the Zebra and then Quagga routing software for the lab part of my training courses.

However, like Zebra before it, Quagga also ran out of steam but was forked by people (and companies) who saw value in the software. The Quagga fork is Free Range Routing a.k.a. FRRouting a.k.a. FRR.

As I was writing my new BGP book, I made configuration examples using Quagga. But about two thirds in, I decided to switch to FRRouting. This had the huge advantage that I could include RPKI examples. But on the other hand, I now had to revisit all my earlier configuration examples to see if they still worked under FRR. And too often, the answer was "no".

So let me list some differences between Quagga or even old school Cisco routers and FRRouting.

A really annoying change is that in FRR, it's no longer "ip as-path ..." but "bgp as-path ..." to define AS path access lists. Yes, it makes more sense. But this change immediately makes it impossible to have a configuration file that works on both Cisco/Quagga and FRR. Same thing for "ip community ..." vs "bgp community ...".

I think the solution here would have been to accept the "ip ..." syntax and translate that into "bgp ..." syntax. That way, an FRR BGP daemon could still read Quagga BGP daemon configurations and work as expected.

Another change is that with FRR, there's no way to get around "address-family ipv4".

Way, way, way back in the day, we didn't have IPv6. Actually, it took quite a while for 1990s routers like the 2500 series to gain IPv6 capability. So there was no reason to differentiate between BGP configuration commands that both apply to IPv4 and IPv6 and configuration commands that only apply to either IPv4 or IPv6.

With Cisco routers, you could always just pretend like IPv6 didn't exist and enter configurations like:

!
router bgp 65086
 no synchronization
 network 10.86.0.0 mask 255.255.0.0
 neighbor 203.0.113.83 remote-as 65083
 no auto-summary
!

On FRR, you can still paste that configuration snippet. But if you then issue "show running-config", this is what you get back:

!
router bgp 65086
 neighbor 203.0.113.83 remote-as 65083
 !
 address-family ipv4 unicast
  network 10.86.0.0/16
 exit-address-family
exit
!

Yes, it boils down to the same thing, but it looks rather different. Especially as the configuration gets longer and the non address family part and the IPv4 address family part don't fit on the screen at the same time.

Bottom line: FRR is moving away from the traditional Cisco configuration language relatively quickly, white Quagga, for BGP at least, stayed pretty close to that. So moving from Quagga to FRR is a bigger step than you might think.

Also, as much as we may be unhappy with Cisco for some of their high profile software bugs, more minor software bugs happen much more frequently in these software implementations such as Quagga and FRR. For instance, I find myself not being able to use ^(64496_)+$ to match one or more instances of AS 64496 in an AS path but nothing else. However, ^(_64496)+$ does work as expected.

Will the IPv6 BGP table overtake the IPv4 table before the decade is out?

Thu, 30 Jun 2022 12:34:51 GMT

For my training courses, I always check the current size of the IPv4 and IPv6 BGP tables over at the CIDR Report so I can tell the participants what table size capacity to look for when shopping for routers.

Currently, the IPv4 table is at 925k, readying itself for scaling the 1M summit late next year. The IPv6 table is 160k prefixes.

The IPv4 table grew at about 10% per year in the 2010s and 6% last year. At this rate, it'll be at 1.43 million at the beginning of 2030.

The IPv6 table, on the other hand, had been growing at some 31% per year between 2015 and 2020, but last year it grew 37%. At that rate, the IPv6 table will reach 1.7 million prefixes by 2030! Even at a somewhat slower growth rate of 34% the IPv6 table will overtake the IPv4 table before the decade is out.

Of course it's hard to predict 7.5 years into the future, but stranger things have happened.

Also, at this rate, you'll need a router that can handle more than 2 million prefixes five years from now. Which pretty much means that if you are buying a router today that has to be able to hold the full global IPv4 and IPv6 tables, it should already be able to handle more than 2M prefixes in order to have a five year economic lifespan.

6-6-2012: World IPv6 Launch — the future is forever

Tue, 07 Jun 2022 16:58:09 GMT

Ten years ago, on 6 June 2012, the Internet Society organized World IPv6 Launch. A year earlier, we'd had World IPv6 Day, where many (large) organizations added IPv6 addresses for their websites to the DNS for 24 hours, in order to see if that would create problems. That went mostly smoothly, with a few surprises, so a year later it was time to turn on IPv6 for real. Time for a blog post looking back on worldipv6launch.org.

I thought this would be a good excuse to do what I've done with some regularity over the years: see how well things work when I turn off IPv4 on my home network.

The IETF tried this at is meeting in March of 2008 for an hour on its meeting network, with interesting results. Back then, Windows XP was still the most widely used operating system, and although Windows XP does support IPv6, it doesn't support DNS lookups over IPv6. So the Windows XP users were left out in the cold or had to apply complex workarounds.

By the early 2010s, all operating systems had mature IPv6 implementations, but very few websites and other online services were IPv6-enabled. So with IPv4 turned off, you couldn't do much. Since then, that's gotten a lot better. And it took a while, but many (most?) ISPs now routinely provide IPv6 connectivity along with IPv4.

I initially tried to turn off IPv4 on my home router, but no dice: you can turn off IPv6, but not IPv4. So I replaced the home router that came with my FTTH service with a Mikrotik, which has no such limitations.

The good news is that my main networked devices all had no issue using IPv6: my Macs, iPhone, iPad, AppleTV 4K and LG TV. Not sure about my Onkyo receiver, but I never use any networked services on that anyway. My Sony UHD blu-ray player wouldn't run its Netflix app or software update check over IPv6, but the IPv6 version of the built-in network connectivity checker was happy with the connectivity. In the settings it said IPv4 had priority over IPv6, but no way to change that. Strange.

On the LG TV and the AppleTV most of the video streaming apps work fine over IPv6. Not Amazon Prime or the Dutch public broadcasting apps, though. Podcasts are pretty bad. I found four IPv6-related podcasts, and only two of them would load over IPv6. And of all the others I tried, just one.

Websites are hit and miss. It seems especially the big ones served up by content delivery networks work over IPv6, while web based applications often don't work over IPv6. Annoying examples are Twitter and Fastmail. Third party iPhone and iPad apps are also somewhat underperforming. Podcast player Pocket Casts will sync over IPv6, but as noted, most podcasts won't load over IPv6. Overcast doesn't sync over IPv6. Dutch public transport planning apps also didn't work.

Although most of Apple's stuff has supported IPv6 for years, controlling smart home devices through Homekit remotely (over the internet) doesn't work with just IPv6. And Siri doesn't work over IPv6.

Right now, if you're an IPv4-only user (or content provider) that doesn't cause any problems. It's up to the IPv6-only users to figure out a way to reach the IPv4 world. It will be interesting to see how long it takes before we reach the tipping point where this flips and important services are only available over IPv6, so IPv4 users have to find a way to talk to the IPv6 world. I'm guessing not very soon.

Ok, time to turn IPv4 back on so I can listen to some podcasts.