Tag Archives: subnet ID

IPv6 Part 6: SLAAC vs DHCPv6

Posted on by
2

Address auto-configuration was important to IPv6 right from the start. The original proposal was for a 64-bit address space, but 128 bits was chosen to enable address auto-configuration based on MAC address, in the style of XNS/IPX. It was always intended that address assignment via DHCPv6 would also be supported for those sites that preferred it. [UPDATE: I would argue that there’s an architectural issue here. DNS is the key to accessing any network resources, especially local ones. If you are an enterprise running a highly available IPAM system for your DNS, then adding DHCPv6 to that has more pros than cons. After all, if the DHCP is down and hosts can’t get an address, then the DNS is probably down as well, and you’re not going anywhere anyway. If you’re a smaller enterprise, then decentralised addressing using SLAAC is a better fit, if only because of the limitations of Microsoft’s DHCP implementation.]

However I can see that there might be some hardliners who see SLAAC as the “real” address configuration method for IPv6, and DHCP as a hangover from IPv4. Google’s lead IPv6 developer for Android has set his face against DHCPv6, and so there’s no DHCPv6 support in Android. I don’t have much patience with such “religious” beliefs (in technical matters I’m an atheist): I think users should be given the choice as to which address configuration method they use.

It’s the needs of auto-configuration that impose the fixed 64-bit length of the interface ID. Ironically this fixed length network prefix represents a kind of return to the very earliest days of IPv4, when addresses were made up of an 8-bit network address and a 24-bit host address. The shift to classful addressing, which provided three (later four) classes of addresses with 8- 16- and 24-bit network parts, gave much more flexibility; the later move to classless addressing gave more flexibility still. Even though there is a massive address space (64 bits) in each half of an IPv6 address, it still doesn’t feel like a good idea to me to have a fixed structure like that.

Whether that fixed structure is sustainable in the long run is open to question. As we’ve seen the address space available to sites for subnetting is not that generous. If enterprises require more subnetting in the future, for example for security reasons or to accommodate the Internet of Things, then pressure may grow on the /64 network prefix boundary. My concern is that the /64 structure will have been coded so deeply into many IPv6 implementations that changing it in the future may be very painful.

In the next post, I’ll look at another big cultural shift that IPv6 introduces.

Yes it’s a lot of bits but…

Posted on by
4

Let’s take a look at the structure of an IPv6 Global Unicast address (GUA), a globally-routeable address:

IPv6 addresses, like IPv4 addresses, are Big Endian, that is, the most significant bits come first. That’s similar to decimal numbers, where thousands come before hundreds and so on. The most significant bits (the “high-order” bits) at the beginning of a GUA form the global routeing prefix. This is used by Internet Service Providers (ISPs) to route traffic through the global Internet.

The standard IPv6 global routeing prefix assigned to a single-site enterprise is a /48. RFC 3177 specified /48 as the standard prefix for all sites, even home users, but subsequently RFC 6177 recommended longer prefixes for small enterprises and home users. With IPv4 an enterprise may only be assigned a /24, if that. That means that ISPs have (very) roughly 16 million times the address space to work with (248 versus 224); in fact 48 bits provides about 280 trillion prefixes, or roughly 38,000 prefixes for every human on the planet.

It’s the structure at the local end of an IPv6 address that’s surprising for someone like me who has worked with IPv4 all through their career. The network prefix (what in IPv4 is called the subnet mask) is a fixed /64 in length, as opposed to the variable-length subnet masking (VLSM) of IPv4. That means that the interface ID (broadly the IPv6 equivalent of the host ID) is also 64 bits long. In other words there’s enough address space on each subnet for 264 hosts, i.e. 18446744073709551616, or enough M&Ms to fill the Great Lakes.

Now that’s a huge number. With current networking technology it’s difficult to imagine it being practical to have more than, say, 10000 hosts on a single subnet. That only requires 14 bits, so the other (most significant) 50 bits are effectively redundant, in other words 18446744073709535232 addresses or 99.99999999999991%. In practice there is likely to be parallel running of IPv4 and IPv6 on the same subnets for some time, and IPv4 subnets are typically much smaller, say, 256 hosts, so the redundancy will be greater still.

The consequence of this fixed /64 network prefix is that the subnet ID, which is the local part of the network prefix, is typically only sixteen bits. For IPv4, most enterprises use private RFC 1918 addressing combined with Network Address Translation. They often utilise the 10/8 private prefix subnetted down to a /24 for individual subnets, which also provides a 16-bit subnet addressing space. So in practice IPv6 doesn’t provide any additional subnet address space for many enterprises compared to IPv4.

Sixteen bits is still a large number, equivalent to 65536 addresses, and it would be very generous if enterprises used those sixteen bits as a completely flat address space. However they usually structure the local subnet space hierarchically, in order to aggregate routes efficiently and minimise internal routeing tables (just as the global routeing address space is structured). IPv6 does have the advantage for network administrators that addresses are represented in hex rather than IPv4’s decimal; each hex character represents four bits (a “nibble”) as opposed to the 8-bit components of an IPv4 address (an “octet”). This means that the subnet space can be divided conveniently into 4-bit chunks in a way that’s easy to read, and so less prone to error. It is generally recommended (by Coffeen 2014 for example) to follow this practice when designing your IPv6 subnetting structure.

Nevertheless creating a hierarchical structure in this way means that there will be inevitably some inefficiency in the use of the address space. For example, take a site that has 20 buildings with 20 subnets per building. Each nibble can encompass only 16 objects, so you would need to assign two nibbles to the site level of the hierarchy and two to the building level of the hierarchy, thus using up the available subnet space, with quite a lot of redundancy. This is almost a worse-case scenario, but it shows how the address space for local subnetting is not that generous, and looks positively stingy compared to the address space for interfaces.

In summary, IPv6 uses a roughly 48-bit address space for global routeing, That’s a huge amount of prefixes, and to be fair it does deliver the original goal of IPv6, which was to increase the global address space. However, the way that the local part of IPv6 addresses is structured means that there is no useable expansion of address space at the local end. That stuff about galaxies and light-years is (mostly) hype.

In the next post I’ll take a look at why IPv6 addresses are structured in this way.