Tag Archives: SLAAC

IPv6 Part 15: To sum up

Posted on by
2

While I’ve been working on this series on IPv6, my thinking has evolved. It’s clear from reading RFC 7421 that the fixed 64-bit length of the interface ID is now so baked into IPv6 that there’s no point in debating it. If sixteen bits (or rather four nibbles) isn’t enough to encompass a site’s topology, then I accept the assurances (for example in Tom Coffeen’s IPv6 Address Planning) that a global prefix that’s shorter than the standard /48 can be obtained (I still think that the size of the IPv6 address space is over-hyped).

IPv6 has two ways of automating addressing and configuration: DHCPv6 and SLAAC. In practice neither are complete solutions, and they have to be combined in various ways; the standards are still evolving. Something as straightforward as mapping an IP address to a MAC address becomes much harder with IPv6. Such a complex and messy environment is not conducive to good security.

However, the biggest problem I have with IPv6 is the assumption that it means a return to end-to-end addressing. The original purpose of Network Address Port Translation (NAPT) was to stretch the IPv4 address space, and the massively increased address space of IPv6 makes that no longer necessary. The crude one-way filter effect of NAPT needs to be replaced with a proper firewall. Nevertheless, NAPT has had other benefits too, such as:

  • Host identity hiding
  • Network identity hiding
  • Topology hiding
  • Simplification of provider change when using provider-assigned addresses
  • Simplification of multi-homing when using provider-assigned addresses

Various attempts have been made to try and replicate these benefits in IPv6: temporary addresses, “local network protection” (using host routes or Mobile IP), ULAs, NPTv6 and multi-homing via DHCPv6. In chasing the end-to-end addressing dream these have all added complexity to the endpoint device (difficult to manage on an enterprise scale); all, that is, apart from NPTv6, which is a form of NAT.

IPv6 enthusiasts often express a desire to return to the time in the early days of the Internet when end-to-end addressing was feasible. I think that the world has moved on since then: the Internet is no longer as simple or as safe, and we need to adapt our architectures accordingly. We should not assume that end-to-end addressing is always the end goal. When applying the end-to-end principle to the enterprise, it makes more sense to think of the endpoint as lying at the enterprise boundary, where complexity can be more easily handled.

IPv6 Part 12: Privacy Extensions

Posted on by
Reply

As we have seen, the IPv6 address space is actually two universal address spaces side by side, the 64-bit network address space and the 64-bit modified EUI (MAC) address space. By design, conventional SLAAC will always assign the same interface identifier to an interface whatever network it is connected to. This makes it possible to correlate different connections coming from the same host, and track a laptop or other mobile device as it moves between networks. This raises concerns about privacy, and to alleviate these concerns Privacy Extensions were developed. This generates temporary Interface IDs (IIDs) using an MD5 hash of the conventional SLAAC IID combined with 64 bits from the previous run (or a random number if this is the first time). See the diagram for the process (note that DAD is carried out on the resultant temporary addresses as described in a previous post but I have omitted this from the diagram for simplicity).

Temporary addresses are re-generated at a regular interval, and once a new address has been generated then the old one is deprecated and will only be kept open to allow existing connections to finish. Temporary addresses are also re-generated when connecting to another network. Note that these temporary addresses are to be used for client connections only: the “public” (server) address to which other hosts connect is still generated using the conventional SLAAC method.

Temporary addresses can cause real problems for troubleshooting on an enterprise network (hunting for infected hosts, for example), as the RFC recognises. Temporary addresses also frustrate lawful intercept, to my mind one of the strongest arguments against NAPT (see for example Tom Coffeen’s IP Address Planning, chapter 2). By default, Privacy Extensions should be off. However, Microsoft’s implementation sets temporary addresses on by default, and enterprises have to disable this on a machine-by-machine basis (there’s no group policy object that could do this centrally). As mentioned, Privacy Extensions don’t modify the public address, so that the interface is still displaying its manufacturer to any other host that connects to it; Microsoft’s implementation extends Privacy Extensions by generating a random IID for the public address as well. A more recent RFC proposes an open standard for this, in a way that severs the link between the hardware address and the IID.

As we saw when looking at the history of SLAAC, the concept of deriving the interface ID from the MAC address goes back 40 years, to a more innocent time. It’s no longer suitable now that we are concerned about leaking unnecessary information out onto an untrusted Internet. Most of the attention has focussed on the security of the interface ID; in the next post I’ll look at tackling the leakage of topology information caused by end-to-end subnet addressing.

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 5: Stateful DHCPv6

Posted on by
1

Using DHCP to manage IPv6 addresses is known as stateful DHCPv6, because the DHCP server maintains the state of IP address leases centrally. In the last post we looked at its limitations, as opposed to SLAAC. Why would you use DHCPv6 to manage IPv6 addresses? Well the main reason is accountability. One of the most important aspects of this is host DNS registration: having your hosts registered in DNS and available for reverse DNS lookup is the most basic way of tracking them. If you use DHCPv6 for address assignment then the DHCP server will register the host with DNS (typically the two services run on the same server). If you are using SLAAC then hosts themselves are responsible for registering themselves in DNS : this is inherently less reliable.

In fact DHCPv6 has made DNS registration more robust than under IPv4. With IPv4, it’s a simple model: each MAC address is a separate entity, and each interface makes its own independent registration in DHCP. This can cause problems with DNS registration when a host has multiple interfaces, as is increasingly the case where laptops are connected both to the office wired LAN and to a wireless network. If the host is registered in DNS under one interface, then depending on how things are configured the second interface may not be registered in DNS at all. Alternatively the second interface may supersede the DNS registration of the first interface.

DHCPv6 introduces the concept of the DHCP Unique Identifier (DUID). The DUID is a persistent identifier of the host rather than any specific interface. IP addresses are actually assigned to Interface Associations (IAs) which identify the individual interfaces. Thus DHCPv6 understands that hosts can have multiple interfaces and DNS hostname registrations can be done according to the DUID rather than the IA.

Another reason that you might want to use DHCP to manage addresses is to make it easier to find out an interface’s MAC address from its IP address. Take the example of a security alert you receive from your intrusion prevention system or DNS firewall: an IP address is trying to contact a known botnet command and control (C2) server. You want to disconnect that IP address from the network as quickly as possible, preferably automatically. Under DHCPv4 it’s possible by looking up the IP address in the DHCP server and extracting the MAC address, and then using whatever tools your network may provide to track down the specific network port that that MAC address is connected to. You can then disable the port.

Sadly, the way that DHCPv6 works makes this much harder. Although the DUID of a host usually contains a MAC address, it is typically generated at install time from the MAC address of any interface on the system. That interface can in fact be removed from the host after the DUID has been generated and the DUID will stay the same. The Interface Association Identifier (IAID) is generated in an arbitrary way by the host, and may have no relation to the physical MAC address of the interface. If the DHCP server is not on the same subnet as the client, and is receiving the DHCP request via a relay, then the server has no visibility of the client’s MAC address. Thus there can be no way of building a centralised mapping of IP addresses to MAC addresses. RFC 6939 does provide a mechanism for DHCP relays to forward the client’s MAC address to the DHCPv6 server, but this is quite a recent proposal. So, one step forward, one step back.

Next post I’ll summarise the SLAAC vs stateful DHCPv6 debate.

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.

IPv6 Part 3: Address auto-configuration

Posted on by
1

In the previous post I explained that network prefixes in IPv6 are nearly always a fixed 64 bits in length, with a few exceptions. Strictly speaking, it’s actually the interface ID that’s fixed at 64 bits, which means that because IPv6 addresses are 128 bits long the network prefix has to be 64 bits too. The reason for this is to meet the needs of address auto-configuration, which is a new feature of IPv6 that supports:

  • link-local address auto-configuration (so-called plug-and-play)
  • stateless address auto-configuration (SLAAC, for global addresses)

Link-local addressing is pretty fundamental to IPv6. It enables a host to communicate with other nodes on the same network without the need for manual configuration or a DHCP server. The process is as follows:

  1. In the conventional method the host generates a 64-bit identifier for the interface by taking its 48-bit MAC address and inserting the string fffe into the middle. Then it “flips” bit 7 of the address from 0 to 1, so that the MAC address:

    00:cd:fe:12:34:56

    generates the interface ID:

    2cd:feff:fe12:3456.

    This is what’s known as a Modified EUI-64 identifier (there are other methods but I will cover those in a later post).

  2. The host prefixes this identifier with the link-local network prefix fe80::/64, so that our example MAC address generates the link-local address:

    fe80::2cd:feff:fe12:3456.

  3. The host then tests this address for uniqueness on the local subnet by sending a Neighbor Solicitation message (ICMPv6 type 135) to the generated address. If it gets a Neighbor Advertisement message (ICMPv6 type 136) in reply then the process halts.
  4. If there is no response then the link-local address is assigned to the interface.

IPv6 link-local addressing

You can find more detail on this at Packetlife.

Once the link-local address is configured, the host sends a Router Solicitation message (ICMPv6 type 133) to the All Local Routers multicast address ff02::2. If there’s a local IPv6 router it will respond with a Router Advertisement message (ICMPv6 type 134). If that tells the host that it should auto-configure a global address then:

  1. The host will take the 64-bit global prefix advertised by the router and combine it with the 64-bit interface identifier previously generated to create a global address, so if the prefix is:

    2001:db8:1234:5678

    then our example interface ID generates the global address:

    2001:db8:1234:5678:2cd:feff:fe12:3456.

  2. It will test for uniqueness on the local subnet as for the link-local address
  3. If there is no response then the global address is assigned to the interface.

IPv6 SLAAC

The whole set of messages and processes, together with other ancilliary messages and processes, is known as Neighbor Discovery. In principle other methods of global addressing (manual, DHCP) could use a variable-length prefix. However the address architecture RFC (RFC 4291) stipulates a 64-bit interface ID regardless of the configuration method. RFC 5375 warns against straying from the /64 prefix:

Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast – Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others.

In fact it’s specifically the SLAAC component of Neighbor Discovery that would be broken by a global network prefix other than /64, because of the way that the interface ID is generated.

In the next post, I’ll delve more into the background of SLAAC.