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

Time to turn off IPv4 (just a little)

▼ Another month, and we'll be living in the 2020s. And yet, 70% of the internet is still IPv4-only. (I'll be writing a story looking back on IPv6 progress the past decade in January.) So I thought: maybe I should draw a line in the sand and turn off IPv4 for my website. But then how will those 70% find me, and all the links to older content will be dead to much of the internet.

So instead, I decided to host some of the images on my old website muada.com and the new home of my blog illjitsch.com on an IPv6-only domain name. This means that browsers running on a system with only IPv4 connectivity will find that they can't load the image at the top of this page. There's no tricks involved: the browser encounters a cold hard error.

However, I didn't want to have a broken image show up on the page, because people might just think it's my HTML skills that are the problem, rather than them being stuck in the past IP-version wise. So the browser is instructed that when it can't load the image, it should load another. That has a nice big warning in neon colors. I also use an image map to let people click on the word "IPv6" to get to a page that explains what's going on. If javascript is turned off, there's just a line of text saying there is no IPv6 connectivity.

Note that browsers will cache images, so you may still see the correct skyline image even if you currently don't have IPv6 connectivity.

This is the HTML code. You can click on the images to try if they load manually.

<img src="http://images.iljitsch.com/images/skylinedenhaag2.jpg" width=1920 height=180 style="max-width: 1920px" alt="Image couldn't load - you don't seem to have IPv6 connectivity" onerror="this.onerror=null;this.src='/images/warn-img-no-ipv6.png';" usemap="#nov6link">

<map name="nov6link" id="nov6link">
  <area shape="rect" coords="425,110,500,150" title="Click here for an explanation" href="http://iljitsch.com/ipv6-warning.php" />
</map>

I hope that more people will do the same so people start to actually notice that they're behind the times by having just IPv4 connectivity.

Permalink - posted 2019-12-03 - 🇳🇱 Nederlandse versie

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

Europe runs out of IPv4 addresses even further, what now?

▼ Less than three months ago I wrote about how the uptake of the remaining IPv4 addresses at RIPE was accelerating, with the RIPE NCC likely to run out of the addresses set aside in the "last /8" before the end of the year. And so they did, two days ago. So as of this week, it's no longer possible to request address space in the RIPE service region (Europe, former Soviet Union, Middle East) and get them within a somewhat predictable period.

In September, a million IPv4 addresses were given out every six weeks, and that rate seems to have continued. That's about a thousand /22s (blocks of 1024 IPv4 addresses), where each LIR ("RIPE member") can only get one of those. Thus, most of these blocks must have gone to new LIRs, at a rate of nearly a thousand every 30 business days, so the RIPE NCC must have been processing a new LIR, or at least a /22, every 15 minutes or so!

So what if you're in the RIPE region and you need IPv4 addresses in order to talk to the part of the internet that hasn't adopted IPv6 yet?

The RIPE NCC is not completely out of the game, so one option is to go on the waiting list.

LIRs "that have never received an IPv4 allocation from the RIPE NCC can make a request via the waiting list". So: sign up to be an LIR, put in a request, and wait for address space to become available. At that point you'll get a /24. Note that the NCC does in fact get back IPv4 address space at some rate, and there's currently nearly half a million addresses (about 2000 /24s) in quarantine, which lasts for six months if I'm informed correctly. So presumably, on average 75 /24s should become available every week over the next six months.

So it seems the game where a single organization would just sign up multiple RIPE memberships to qualify for a small block of IPv4 space multiple times can continue. However, you'll only get a quarter of the address space and there will be an unpredictable delay. So I'm thinking that the people who wanted to play that game were trying to take advantage of the /22-per-LIR policy and we're going to see less of this.

ARIN (North America) didn't have a final /8 policy, and has had a waiting list in operation for some years now. Currently, there are 160 requests on the list, and the next in line has been waiting for about six months.

The alternative is to buy IPv4 addresses on the open market. The going rate seems to be around $20 per address right now.

All of this puts a lot of pressure on IPv4 addresses for those organizations that weren't around when it was easy to get IPv4. So those organizations need to deploy address sharing techniques such as "carrier grade NAT" (CGN/CGNAT), "large scale NAT" (LSN) or stateful NAT64.

But what about IPv6? IPv6 addresses are for all intents and purposes free. However, you can't use IPv6 to communicate with a system that only has IPv4. But it makes sense to do as much as possible over IPv6 and only use translators to share IPv4 addresses when necessary. This limits the amount of address space required as well as the equipment that has to do all the NATing.

Permalink - posted 2019-11-27