Tag Archives: DHCP

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.

IPv6 Part 4: SLAAC history

Posted on by
Reply

As I explained in the last post, IPv6 SLAAC addressing derives the host portion of the routeable address from the interface MAC address, and discovers the network portion from the network itself. Those of you who have been in the IT business long enough will find this familiar: it’s similar to the way that Novell’s IPX protocol worked. In fact, IPX was based on Xerox’s XNS protocol, which goes back to the late 1970s. In both cases, the host portion of the address was 48 bits long, the length of the MAC address: MAC addresses are globally unique, thus ensuring no local address clashes.

Novell introduced the Service Advertising Protocol (SAP), whereby servers advertised their services via broadcasts to routers. By querying their local router, clients could then choose which service to connect to from a dynamically compiled list. Thus service discovery was decentralised, in a way that was consistent with the decentralised way that clients obtained their addresses. When NetWare 5 moved to running over TCP/IP, Novell migrated to the open Service Location Protocol. Microsoft’s networking had similar distributed methods of advertising resources.

DHCP was already in existence when SLAAC was developed. SLAAC’s big advantage over DHCP was its simplicity: it didn’t require the administrative overhead of DHCP. SLAAC as originally conceived did one job and it did it very well: it assigned an address in a simple, scalable way. However what if you weren’t using a network protocol like NetWare or Microsoft that advertised the available resources? Specifically, how did clients configure their DNS servers and DNS search domains? The answer was to use a combination of SLAAC for address assignment and (stateless) DHCP for the other parameters. So you still needed to set up DHCP servers; however the configuration information that they distributed was relatively static.

So you couldn’t avoid DHCP completely. However, it’s difficult to manage addresses from DHCP servers in a way that’s scalable and resilient. Microsoft’s DHCP server was (and is) probably the most widely used DHCP server for IPv4, and to provide load-balancing and redundancy the typical method was to configure “split scopes” on multiple DHCP servers. Each server would assign addresses from a different chunk of the same subnet’s address range. Clients would receive their address from whichever DHCP server responded first. Clients would continue to renew their address leases from the same server, until or unless it became unavailable; they would take a while to realise that a server was unavailable, and wouldn’t use it again once recovered until they were forced to release their addresses and begin the whole address assignment process again.

Things got really messy if you used DHCP address reservations. There was no automatic replication of reservations across the servers, so each reservation had to be copied from server to server manually. Inevitably this was error-prone: if you needed specific hosts to always get the same address, for example for firewall rules, then things could often get broken.

Microsoft’s DHCP implementation has gradually improved. Windows Server 2012 introduced DHCP failover for IPv4, with dynamic replication of DHCP address state. However, this won’t manage IPv6 addresses: the assumption is that you will use SLAAC for that. In addition, DNS, DHCP and IP Address Management (DDI) systems like Infoblox and Efficient IP have emerged that dynamically replicate DHCP address state, for IPv6 as well as IPv4, in an effective and resilient way. The DDI systems come with a price tag however, as opposed to Microsoft DHCP which comes bundled with Windows Server. So why would you use DHCP to manage IPv6 addresses? In the next post, I’ll take a look at why you might want to.