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

Finally: native IPv6 at home!

▼ It took a while, but I finally got native IPv6 at home from Ziggo, my cable ISP a few months ago. All it took was a new cable modem / home router, because they don't support IPv6 on the one I've had since I signed up with them six years ago. And lo and behold: I got myself some IPv6:

$ ifconfig en0
en0: flags=8863 mtu 1500
  ether xx:xx:xx:xx:xx:xx 
  inet6 fe80::8d:5a:e4d:176f%en0 prefixlen 64 secured scopeid 0x8 
  inet 192.168.78.24 netmask 0xffffff00 broadcast 192.168.78.255
  inet6 2001:1c00:d00:7300:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf secured 
  inet6 2001:1c00:d00:7300:75bf:1d31:ac76:d080 prefixlen 64 autoconf temporary 
  nd6 options=201
  media: autoselect
  status: active

Although it doesn't say so anywhere on the management interface of the cable modem, it looks like I got a /56 prefix (2001:1c00:d00:7300::/56) from Ziggo.

My understanding is that Ziggo only supports IPv6 with the modem in router mode, so the cable modem acts as a NAT router.

So I wondered: what if I also let my Apple Time Machine act as a router, behind Ziggo's modem/router? I told the Time Machine to configure IPv6 automatically and IPv6 mode native, and this is what happened:

(By the way, does anyone know what "Enable IPv6 Connection Sharing" does? I get the same IPv6 addresses on my computer, it's just that the Airport Utility shows a little less information. In any event, on my Mac I get:

$ ifconfig en0
en0: flags=8863 mtu 1500
  ether xx:xx:xx:xx:xx:xx 
  inet6 fe80::8d:5a:e4d:176f%en0 prefixlen 64 secured scopeid 0x8 
  inet 192.168.78.24 netmask 0xffffff00 broadcast 192.168.78.255
  inet6 2001:1c00:d00:73f0:xxxx:xxxx:xxxx:xxxx prefixlen 64 autoconf secured 
  inet6 2001:1c00:d00:73f0:7ccf:266b:8f69:4f46 prefixlen 64 autoconf temporary 
  nd6 options=201
  media: autoselect
  status: active

So either Ziggo / the Ziggo modem delegated a /60 out of the /56 given to the modem. On my regular network, the Time Capsule used the first /64 out of that /60. On the guest network, it uses the second /64:

vlan0: flags=8843 mtu 1500
  options=23
  ether xx:xx:xx:xx:xx:xx
  inet6 fe80::21b:63ff:fe95:7d9b%vlan0 prefixlen 64 scopeid 0x7 
  inet 172.16.42.23 netmask 0xffffff00 broadcast 172.16.42.255
  inet6 2001:1c00:d00:73f1:xxxx:xxff:fexx:xxxx prefixlen 64 autoconf 
  inet6 2001:1c00:d00:73f1:2c25:ea92:9deb:d27f prefixlen 64 autoconf temporary 
  nd6 options=1
  vlan: 1003 parent interface: en0
  media: autoselect (1000baseT )
  status: active

It's a little known fact that Apple's Airport base stations actually run the guest network on VLAN 1003, so if you have multiple Airports (including Time Machines) hooked up to the same wired LAN, the additional base stations can forward packets that arrive over Wi-Fi on the guest network to the base station that acts as the home router.

With both the Ziggo modem and the Apple Time Machine set up as routers with a guest network, that means I have no less than four /64s in use:

Ziggo main network: ...00/64 Ziggo guest network: ...03/64 Time Machine main network: ...f0/64 Time machine guest network: ...f1/64

Pretty sweet!

I also finally ran cat 6 UTP from the living room where the cable modem resides to my home office, so I no longer need to wirelessly extend my network from one end of my apartment to the other, which was neither fast nor reliable, or use the tp-link powerline networking adapters, which are rated for 1200 Mbps but only ran at about 60 Mbps in my setup. They would also hang once a month or so.

Now the only thing I need is some 5 Gbps Ethernet USB dongles.

Permalink - posted 2018-11-11