IPv6 Part 14: Provider-independent addressing

IP addresses can be divided into two categories depending on who assigns them. Most users will get their addresses from their Internet service provider (ISP): these are Provider-Assigned or Provider-Aggregatable (PA) addresses. As anyone who has been through a switch of ISP knows (I’ve been through two) it’s a painful process if you have PA addresses. With IPv4 and NAPT, your internal hosts will be using private addressing so you only need to readdress your public-facing systems, but IPv6 assumes that all hosts are addressed with global unique addresses (GUAs), so a switch of ISP means readdressing every interface in your enterprise. This is a huge operational problem; there are IPv6 features that make this process a bit easier, but it would still be very disruptive.

One solution to this is to obtain your own IP addresses that are independent of any ISP, so-called Provider-Independent (PI) addresses; you thus become an Autonomous System (AS) in your own right. The main disadvantage of this is that your address range can’t be conveniently aggregated into an ISP’s allocation, and so routes to your PI address block have to be advertised separately across the Internet using Border Gateway Protocol (BGP, the Internet’s global routeing protocol). One of the main goals of IPv6 was to manage address allocation more efficiently in order to limit the size of the global routeing tables, so this cuts across that. In fact, many providers will not accept routes to small PI address blocks and so in practice PI addressing is mainly confined to large enterprises.

RFC 4193 introduced Unique Local Addresses (ULAs) for IPv6. These can be assigned in parallel with global unique addresses (GUAs), so that connections within your site use ULAs, and only connections to or from the global Internet use GUAs. Your internal DNS should serve ULAs to internal queries. An important detail is that ULAs are “global” in scope just like GUAs, so rules in the IPv6 stack on each host need to be configured to handle selection of the appropriate source address [UPDATE: the default source address selection rules should handle this without modification]. Migration from one ISP’s PA addressing to another’s is still painful, but at least your local traffic should be uninterrupted during the process.

ULAs begin with the prefix fd00::/8 (in principle the prefix is fc00::/7 but in practice the eighth (“L”) bit is always set to 1). Forty additional bits (e.g. 2f e8 b7 61 3f) should be randomly generated to make a /48 prefix suitable for a site (e.g. fd2f:e8b7:613f::/48). You can generate five random bytes in hex for this purpose at https://www.random.org/bytes/. Generating them randomly makes it almost certain that you will never share a ULA prefix with another site, which could cause problems if for example you merge two organisations. It’s tempting to choose something easy to remember like fd00:cafe:f00d::/48 but this is not recommended as it’s much more likely to produce a collision.

ULAs are often described as being the equivalent of IPv4 private addresses, but they’re not quite the same, at least not as originally intended. IPv4 private addresses are combined with NAPT to enable communication with the Internet. However, an IPv6-enabled host might have both a ULA and a GUA, using them for local and global communication respectively. An approach that’s much closer to IPv4+NAPT is Network Prefix Translation for IPv6 (NPTv6), defined in RFC 6296. With NPTv6 you use only ULAs internally; at your boundary an NPTv6 gateway translates between your ULA prefix and your globally-routeable prefix, in a way that is one-to-one and stateless. By some clever maths it also succeeds in avoiding the modification of transport-layer checksums.

One of the most important benefits of NPTv6 is that it enables multi-homing for smaller enterprises. Multi-homing means connecting to the Internet via two or more ISPs, for resilience and load-balancing. Conventional multi-homing requires you to become an AS and deploy BGP routes to your networks, which as we have seen is impractical for smaller sites. With IPv4, NAPT provides a separation between internal and external addressing that makes it possible to multi-home using PA addressing; NPTv6 plays the same rôle for IPv6.

NPTv6, like any form of NAT, has limitations: it can cause problems for applications and for IPsec (see my previous posts on NAT and applications and NAT and IPsec). It is also limited in practice to /48 global prefixes because this is always the length of ULA prefixes. Nevertheless it does offer a solution to those smaller sites that want provider independence and multi-homing and can’t operate as an AS.

In my next post (the last in my series) I’ll sum up my thoughts on IPv6.

2 thoughts on “IPv6 Part 14: Provider-independent addressing

  1. Very very interesting article!

    IMO this is the biggest challenge, having ULA and GUA working together and with multi-homing, with proper load balancing working.

    Currently I have 2 ISPs at home, I’m in the process of configuring OpenWRT and its mwan3 to do load balancing. I’m unable to make my modems delegate global prefix when they are in router mode, it only works if set to bridge, and I have only set one of them yet, so I haven’t yet handled dual global prefix delegation and distribution.

    My ISPs are providing me fixed /64 global prefixes, but I can’t be sure if they will remain doing so. I guess they are keeping them fixed because they weren’t still able to make them dynamically change and didn’t bother, but I guess in the future they will enable dynamic changing so they can charge for fixed global prefix.

    I wonder how mwan3 will handle dual balancing dual global prefix and dynamic global prefix. IPv4 NAPT is simply easier to handle, as it’s all centralized on the router. If the router crashes, the full internet providing will be down anyway, so having it centralized isn’t an issue.

    My concern is if DHCPv6 server (I guess it’s dnsmasq) distributes both global prefixes too all devices, and each device tries to choose which route to use, and ignore/break mwan3 prioritization. This might get even worse when global prefixes start changing, and devices don’t be aware of that and try to use outdated prefixes that don’t work anymore, until their lease expire and their IPv6 addresses are updated.

    ATM, OpenWRT successfully and elegantly let me choose a fixed ULA prefix for the full network (not for each VLAN… and I have only 1 VLAN anyway) and a fixed suffix for each device. Then it concatenates ULA prefix and global prefix to device’s fixed suffix and attributes them their addresses. ipv6-test.com reports this address as device’s public IPv6 address.

    For multi-homing (when I get the second modem into bridge mode, or find a way for it to DHCP-PD delegate its global prefix in router mode), I suppose the best and most elegant solution would indeed to use NPTv6. Then devices would only receive an ULA address, and OpenWRT/mwan3 would translate ULA into prefered GUA. But I suppose it doesn’t support doing that ATM.

    Thanks a lot for your articles, they are helping me a lot on understand how IPv6 works.

    • Hi Hikari! I’m glad that you found my articles useful. I’m not familiar with OpenWRT so I don’t know if it supports NPTv6 but it ought to.

Leave a Reply