IPv6 and the DNS: missed opportunities

▼ A few days ago I ran into this blog post from 2012: Deprecate, Deprecate, Deprecate, which lists a bunch of IPv6 stuff that's been "deprecated" by the IETF. That means: we changed our minds about this protocol or feature, stop using it.

The list (the blog post obviously has more information):

• IPv4-compatible IPv6 Addresses. Status: Deprecated.
• Site-Local Addresses. Status: Deprecated.
• The 6bone. Status: Deprecated.
• ipv6.exe (Windows XP). Status: Deprecated.
• NAT-PT and NAPT-PT. Status: Deprecated.
• The Type 0 Routing Header. Status: Deprecated.
• Your valid yet older SLAAC IPv6 addresses. Status: Valid (but deprecated).

But what, no IPv6/DNS-related deprecations?

Perhaps the most annoying one of those was the change from ip6.int to ip6.arpa. Originally, the idea was to have reverse mapping of IPv6 addresses under the ip6.int domain name. So for instance, the IPv6 address of this server is 2a01:7c8:aaaa:1fb::2. In the reverse DNS that would then become the following, with a PTR record pointing to the server's name:

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.f.1.0.a.a.a.a.8.c.7.0.1.0.a.2.ip6.int

Then, around 2003/2005 they decided to change this to:

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.f.1.0.a.a.a.a.8.c.7.0.1.0.a.2.ip6.arpa

Which of course led to the situation where you'd get inconsistent results for years as people made the change at various times. So annoying, especially because it's just a cosmetic change, but an invisible one!

There were also some more substantial IPv6/DNS-related deprecations: A6 records and bitlabels. The idea behind those is that IPv6 should make it simple to renumber. For this purpose, a system was designed where a DNS record wouldn't hold the entire IPv6 address, but parts of it. So if you move a bunch of systems to a different subnet, you just change the record that has these subnet bits, and all the other partial address records remain the same. Unfortunately, this proved too ambitious. Not only did we move to AAAA records, which are four times as big as A records, only four times as big, but support for A6 records and bitlabels was swiftly removed from BIND. This actually caused me some trouble as the zone file with my A6/bitlabel experiments in it suddenly wasn't recognized by other servers anymore.

Moral of the story: measure twice, cut once.

Permalink - posted 2020-01-13

❝Beating BGP is harder than we thought❞

▼ In a paper for the HotNets'19, seven researchers admit that "beating BGP is harder than we thought". (Discovered through Aaron '0x88cc' Glenn.) The researchers looked at techniques used by big content delivery networks, including Google, Microsoft and Facebook, to deliver content to users as quickly as possible. This varies from using DNS redirects to PoPs (points of presence) close to the user, using BGP anycast to route requests to a PoP closeby and keeping data within the CDN's network as long as possible ("late exit" or "colt potato" routing).

Turns out, all this extra effort only manages to beat BGP as deployed on the public internet a small fraction of the time. So it's probably not really worth the effort. Also interesting: when BGP is worse, that's usually consistent over relatively long timescales, and when things deteriorate over one path, they tend to also get worse over alternative paths.

That seems strange, as the authors observe that "BGP, the Internet’s inter-domain routing protocol, is oblivious to performance and performance changes." However, BGP isn't deployed in a vacuum. People either install capacity where BGP is going to use it, or they tune BGP parameters to use capacity that's installed.

So having automated traffic management doesn't seem to help much—or does it? Maybe all paths deteriorate together because the automated traffic management solutions do their job and distribute the traffic equally over the available paths, keeping performance the same.

However, there are some cases when one of the options (regular BGP, anycast, late exit, DNS redirect) performs a lot poorer than the alternative(s). So it's probably more important to focus on avoiding really bad paths rather than trying to pick really good ones.

Also interesting: apparently ISPs rarely include the EDNS client subnet option, which DNS redirect really needs to work well. However, the Google and OpenDNS/Cisco public DNS services seem to do support it (but not CloudFlare), so if you're experiencing poor performance towards a CDN, you may want to try using the Google or OpenDNS DNS servers.

Download the paper here.

Permalink - posted 2019-12-30

Bluesky: Twitter wants a federated Twitter

▼ Twitter's Jack Dorsey, in (of course) a Twitter thread:

Twitter is funding a small independent team of up to five open source architects, engineers, and designers to develop an open and decentralized standard for social media. The goal is for Twitter to ultimately be a client of this standard.

This is interesting on several levels. I'll mostly talk about the protocol design part of this, but before I do that: when has a business that's pretty much in a monopolist position ever voluntarily given up that position? They must really be feeling the pushback against "content and conversation that sparks controversy and outrage", and see this as a way out.

The monopoly aspect is even more noteworthy when considering what happened with instant messaging. Back in the day, we all used IRC and then ICQ. Then there were Yahoo, AIM and MSN (and a few more, I'm sure). At some point, the IETF came up with an open standard that allows everyone to run their own server, similar to how everyone can run their own mail or web server: Jabber or XMPP. But as quickly as networks merged and interconnected, new closed ones such as Whatsapp and Apple's iMessage. Unless I'm mistaken, iMessage, as well as Facetime, actually run on XMPP but don't interconnect with other networks. So we're still left with walled gardens owned by huge corporations.

Very relevant here is Metcalfe's Law:

a network's impact is the square of the number of nodes in the network.

In a network with ten people, there's (roughly) 100 possible conversations that can happen. In a network with 100 people, that's 10,000 conversations. With instant messaging, the network effect is very strong. Then again, most people predominately IM with people in their own country. The effect is that in each country, there's one clear winner in the IM space:

For "microblogging" such as Twitter it's even worse. For IM it's just about possible to use different apps to talk to different people, but the point about a service like Twitter is that everyone can react to everyone else. So you really need one unified network for it to work well.

So the challenge for the bluesky initiative is to come up with a way where everyone can run their own service independently, but they all talk to each other, similar to how you can run your own mail server and still mail everyone else who has email. (Although in practice, most people use Gmail or Outlook webmail.)

At first glance, this looks a lot like the existing XMPP protocol, that works exactly this way. However, XMPP solves a much simpler problem: one-to-one communication. In networking we call this unicast. But when you post something to Twitter, it doesn't just go to one recipient, but to all your followers—possibly millions of them. So what we have here is multicast communication: one sender, multiple receivers.

In principle, this is a relatively simple problem to solve. We have multicast routing protocols that work relatively well, so just bolt that logic onto XMPP and call it a day. However, the big problem will be to make it scale. On the one hand, you have people with millions of followers. That's a lot of work, but it's simple: Donald Trump's messages pretty much go anywhere. But what about the hundreds of millions of users who are followed by a handful of others and only post a message once a month? Just keeping track of all these relationships so the messages can flow in real time creates enormous overhead.

And then there's the issue of spam and unwanted content. How do you control those issues across domains running on servers that belong to different organizations with different use policies?

An interesting problem to think about, and I'm looking forward to seeing what bluesky comes up with.

Permalink - posted 2019-12-17

Valid address space, bogons and martians

▼ There are some advantages to filtering out packets with invalid addresses in them. That would be a packet with a private source or destination address, for instance. Those never have any business traveling across the internet. (Not to be confused with BCP 38 filtering.) For instance, there have been instances where spammers grab an unused prefix, start announcing it in BGP, do a spam run and then drop the prefix. When packets with private addresses enter your network, bad things may happen if you use those addresses yourself. And these invalid "martian" packets are just an annoyance, using up traffic and generating log entries.

The term martian refers to packets that seem to come from Mars, as they can't come from any place here on earth. The BGP announcements for invalid address ranges are often called "bogons". I'm not sure if everyone makes that distinction, but I'll use martian for any address or address block that has a specific purpose, and that purpose means it shouldn't appear in the global routing table. IANA maintains registries of the IPv4 special purpose addresses and the IPv6 special purpose addresses. Note that some addresses are special purpose, but also globally reachable/routable. This is made explicit on the lists.

Bogons include the martians, but also any address space that is currently unused. These are the IPv4 and IPv6 full bogons lists that Team Cymru distributes. The regular, non-full bogons list has only the martians.

If you're considering filtering martians and/or bogons, it's important to realize that these lists change over time. However, martian lists are quite stable, so if you fail to update filters based on the martian lists at regular intervals, that's unlikely to result in problems. However, the full bogons lists changes daily, so it's absolutely crucial to have a solid update mechanism in place if you decide to do full bogon filtering. And note that for IPv4, the full bogons list is quite short as we're pretty much out of IPv4 space, while for IPv6 it's very long as we've barely put a dent into the IPv6 address space.

Last but not least, it's important to realize what part of the IPv4 and IPv6 address space is set aside for global unicast (= regular) use. The IPv4 address space consists of five classes:

• Class A: 0.0.0.0/1 (0.0.0.0/8 - 127.0.0.0/8), global unicast
• Class B: 128.0.0.0/2 (128.0.0.0/16 - 191.255.0.0/16), global unicast
• Class C: 192.0.0.0/3 (192.0.0.0/24 - 223.255.255.0/24), global unicast
• Class D: 224.0.0.0/4, multicast
• Class E: 240.0.0.0/4, reserved for future use

The bogons and martian lists will filter out classes D and E.

With IPv4 class E space we had the unfortunate situation that because many systems considered 240.0.0.0/4 "invalid", it was impossible to repurpose it as regular address space when we started running out of IPv4 address space. So currently, people are paying good money to obtain IPv4 address space because the RIRs don't have any anymore, but 268 million IPv4 addresses remain unused. That's $5 billion worth of IPv4 at $20 per address!

For IPv6, the situation is a bit more complex. Currently, only 2000::/3 is actually used for global unicast. So any valid (non-multicast) packet you'll see traveling across the internet starts with 2xxx: or 3xxx:. However, to avoid repeating the IPv4 class E debacle, the standards documents explicitly designate all IPv6 address space that isn't set aside for a specific different use as global unicast. From RFC 4291:

• Unspecified: ::/128
• Loopback: ::1/128
• Multicast: FF00::/8
• Link-Local unicast: FE80::/10
• Global Unicast: (everything else)

The bogons and martian lists will filter out all the non-global unicast space.

Permalink - posted 2019-11-28