iljitsch.com - ipv6 (en)

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.

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.

OSPF: time to get rid of the totally not so stubby legacy

Thu, 12 May 2022 10:50:45 GMT

Recently, I was looking through some networking certification material. A very large part of it was about OSPF. That's fair, OSPF is probably the most widely used routing protocol in IP networks. But the poor students were submitted to a relentless sequence of increasingly baroquely named features: stub areas, not-so-stubby-areas, totally stubby areas, culminating in totally not-so-stubby areas.

Can we please get rid of some of that legacy? And if not from the standard documents or the router implementations, then at least from the certification requirements and training materials?

Shortest path first, but not so fast

The Open Shortest Path First routing protocol (OSPF, Internet Standard 54) was first defined in RFC 1131 in 1989. So in internet time, OSPF is truly ancient. The base OSPFv2 specification is over 200 pages, with additional extensions in separate documents spanning the early 1990s to the late 2010s.

OSPF is powered by Edsgar Dijkstra's shortest path first algorithm. SPF is a relatively efficient algorithm for finding the shortest path between two places, in the real world or in a network. Still, in a large network there's a lot of paths to check until you can be sure you've found the shortest one. The problem here is that for a network that's 10 times larger, SPF needs 60 times as long to run. So if a router in a network with, say, 100 routers, needs a second to do its SPF calculations after an update, in a network with 1000 routers that takes a minute, and in a network with 10,000 routers an hour.

So in order to make OSPF useful in large networks, you can split your network into different areas. The SPF calculations are then contained to the routers within each area. So rather than calculate SPF over a 10,000-router network, you could have 100 areas with 100 routers each. Then routers that connect two areas would have to calculate SPF over 100 routers for two areas, so 2 seconds rather than an hour worth of SPF calculations.

But if each of those 10,000 routers still injects two, three or four address blocks into OSPF, that means the OSPF database will have something like 30,000 entries. So now updating and remembering all those address blocks becomes a bottleneck. Solution: summarize link advertisements. So if routers in area 35 advertise address blocks 10.35.1.x, 10.35.2.x, … 10.35.95.x, rather than push out all that information to all 10,000 routers throughout the network, the area border routers for area 35 simply say “10.35.x.x” to the rest of the network.

Even better: if an area only connects to the “backbone” area (area 0) and doesn't learn any routing information from other areas or from outside OSPF, it's a stub area that really doesn't even need to know anything that's happening in the rest of the network, so let's give it a default route to reach the rest of the world.

Variations on a stubby theme

Stub areas still have some OSPF routing information from other areas. We can get rid of that too, and then we have a totally stubby area.

On the other hand, maybe we want to import external routing information into OSPF even in our stub area, and then propagate that external information to other areas. This makes for a not-so-stubby area.

And who said you can't have your cake and eat it: let's make our totally stubby area not-so-stubby, and we'll have a totally not-so-stubby area, guaranteeing certification income for years to come. (See Wikipedia's page on OSPF for more details.)

Spring cleaning

As protocol designers, we're really good at adding more capabilities, more options. As network architects and engineers, we're really good at adding complexity to make our networks do something they won't do out of the box. But we can't just keep adding options and complexity without ever taking any of it away. At least not if we want to have a fighting chance at teaching our craft to the next generation so we can retire at some point.

Our routers/computers are now 1000 times as fast and have 1000 times the memory as the 68030-based routers/computers back in 1990. OSPF implementations support incremental SPF.

10,000 routers in one area will melt the network operations center long before the SPF calculations melt the router CPUs. I've personally worked on a network with 600 routers in area 0 back in 1999. SPF performance was the least of our concerns.

So I'm calling it: OSPF areas and summarization are now legacy. New and current OSPF networks should just use a flat area 0 rather than try to micromanage the information flow between areas. Students should no longer have to learn how areas work, and only be informed about the various flavors of stubbiness as an example of humorous naming that doesn't age well.