Autonomous Link Local Address Generation

Before an IPv6 compliant interface even attempts SLAAC, and whether or not SLAAC is even enabled on that interface, it will (upon power up or network enabling) immediately and autonomously generate a Link-Local IPv6 Unicast address. This address is guaranteed to be unique within its subnet. Most interfaces will also have other IPv6 addresses manually assigned or obtained automatically via SLAAC and/or DHCPv6.

Here, “autonomous” means completely on its own, without any outside help. In reality, the Duplicate Address Detection process requires interaction with other nodes. However, if there are no other nodes, it will generate the link-local address and not detect any address conflicts.

This article uses the Sixscape SixConf app to help you understand this mechanism. If you haven’t installed it yet, please do so now (assuming you have a node running Windows 7 or later). The only relevant setting for this article is the Randomize Identifiers option on the IPv6 Settings tab. Regardless of what the other settings are, your interface will autonomously configure a Link-Local IPv6 address, and it will appear on the IPv6 Unicast Addresses tab. Note that you can add, delete or modify Link-Local addresses with SixConf, just like any other unicast address. You cannot do this with the default Windows GUI controls. Be careful not to create multiple Link-Local addresses on one node.

A network interface on a Windows node must at least have an Ethernet “carrier” present before it can be enabled. This can be provided by connecting the NIC to a switch. It is not necessary for any other nodes to be connected to that switch, let alone a DHCP server or source of Router Advertisements. As long as the network interface is enabled, and the NIC has a carrier, the node will autonomously configure a Link-Local Unicast address (and very quickly after the interface is enabled – just a few milliseconds). In Windows (since Vista/WS2008) IPv6 has been enabled by default. So, many people have seen a Link-Local IPv6 address appear in ipconfig, and wondered what the heck that was. Now you know. To get any global IPv6 addresses, you either must manually configure them, or the node must be connected to external infrastructure, such as a router with Router Advertisement messages, and/or a stateful DHCPv6 server.

IPv4 interfaces (for the most part) can have only one node address at any given time. They normally can’t have both a “link-local” APIPA address (from 169.254/16) and a normal IPv4 address (private or public). They can have one or the other. In comparison, IPv6 interfaces  almost always have multiple IPv6 node addresses (often in addition to one IPv4 node address). A typical interface will have one Link-Local IPv6 Unicast address (generated autonomously), plus one (or two if Privacy is enabled) Global Unicast IPv6 addresses, for each prefix received in Router Advertisement messages. If there is a stateful DHCPv6 server, and the Router Advertisement message says it is available, you will get yet another global IPv6 address from that. It is possible to reserve a DHCPv6 assigned global address for a node, but it is more difficult to create the reservation than it is in DHCPv4. For details, see DHCPv6 article.

The 64-bit prefix (most significant 64 bits) of the autonomously generated link-local address is fe80::/64. All subnets use this same prefix for link-local addresses. A link-local address in one subnet can never conflict with link-local addresses in other subnets, even if it happens to use the same 64 bit suffix (e.g. ::1). Packets sent to a link-local address cannot cross routers – they are strictly limited to their own subnet. Unlike IPv4 private addresses, this does not depend on the correct configuration of your gateway router. In fact, with IPv4 private addresses, you can create a multi-subnet private Internet (even quite a large one), with IPv4 private addresses being routed bidirectionally between subnets. A private Internet is connected to the real IPv4 (public) Internet via a NAT gateway, and (assuming the router is correctly configured) no packets with private addresses should cross that border router to or from the real Internet. In comparison, no IPv6 compliant router will ever forward a link local address into or out of the local subnet. This is hard wired into IPv6 routers – no configuration is needed. This is part of having a fully developed address scope concept in IPv6.

EUI-64 vs. Random Suffix

The 64-bit suffix (least significant 64 bits) of the autonomously generated link-local address can be created one of two ways: “EUI-64” (derived from the interface’s MAC address) or “Random” (randomly chosen). This behavior is specified in RFC 4941, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, September 2007.

The “EUI-64” method maps the interface’s 48 bit MAC address into a globally unique 64 bit suffix:

Step 1: Obtain the interface’s 48-bit MAC address:  50-46-5d-6b-7a-54

Step 2: Split it into two 24 bit groups:            50465d 6b7a54

Step 3: Insert the value 0xfffe in the middle:      50465d fffe 6b7a54

Step 4: Set the 7th bit of the first byte to 1:     52465d fffe 6b7a54

Step 5: Represent it as a 64 bit IPv6 suffix:       ::5246:5dff:fe6b:7a54

Assuming that the MAC address is globally unique (and with physical interfaces this is usually the case), the EUI-64 suffix will also be globally unique. If you clone a virtual machine, it may have the same MAC address as the original virtual machine. This would prevent the original and the clone from working on the same subnet anyway (MAC addressees must be unique on a subnet for Ethernet to work), so VMWare and VirtualBox both have ways to generate a new random MAC address for any virtual machine. This guarantees that any EUI-64 suffix on each box is unique on the subnet as well.

The “Random” method randomly chooses a 64 bit value from the 264 (18 quintillion) possible values. The probability of this suffix already existing on the subnet is quite remote. If there are 1000 nodes in the subnet, the odds of a conflict would be about 1 in 18 quadrillion (a million times less likely than you winning a national lottery). Just to be certain, the node will briefly put the address in a tentative state and use Duplicate Address Detection (DAD) to check for a conflict before changing the state to preferred (and using it).

With SixConf, you can create additional link-local addresses, or change the suffix of the autonomously generated one, but usually there is little benefit to doing so. For example, to change your link local address to fe80::2:1, go to the IPv6 Unicast tab, right click on the existing Link Local address and select Edit Address. In the Edit IPv6 Address dialog, choose Suffix type as Manual (default), and enter the suffix ::2:1 in the suffix box. Click Add. This will change your Link Local address to fe80::2:1. Your node will briefly put this address into the Tentative state and perform DAD. Assuming there is no other node using that link-local address in your subnet, the address will go to the Preferred state. By default, link-local addresses have infinite preferred and valid lifetimes.

If you add a new link-local address or manually set the suffix of your existing address, then later trigger autonomous link-local address generation (e.g. by changing Randomize Identifiers setting), it will not affect any manually configured (or modified) link-local address – it will create another “Automatic” address, and you will have two link-local addresses (both will appear in the ipconfig output). Nodes will handle this fine, but there is no way to tell which link-local address will be used as the source address when sending link-local packets. To delete a link-local address, right click on the address and select Delete Address (as with any IPv6 address). If you delete all of your link-local addresses, certain functions (like neighbor discovery) will not work on your node. If you have done this by mistake, you can manually add a new link-local address, or change the Randomize Identifiers setting (which will cause a new link-local address to be generated with either EUI-64 or random suffix).

Controlling How Link-Local Addresses are Generated

An IPv6 node can be configured to use either EUI-64 or Random suffix generation. This controls how the autonomously generated link-local address is created (in addition to how Global Addresses are generated later in SLAAC).

In SixConf click on the IPv6 Settings tab. This setting is controlled with the Randomize Identifiers control. If it is enabled (default for Windows), the address suffix will be chosen randomly. If it is disabled, the address suffix will be generated using EUI-64. First enable Randomize Identifiers and then go to the IPv6 Unicast tab, right click on the Link Local address and select Show Address Details to see the details for the autonomously generated link-local address (you should get a random suffix). Then, disable Randomize Identifiers and check the details of the Link Local address again (you should get an EUI-64 suffix).

Using a Node That Has Only the Autonomous Link-Local Address

Network applications running on an IPv6 node can begin sending and receiving unicast traffic (UDP or TCP) immediately (without doing any further configuration), using the autonomous link-local address as source, and any scope unicast address as destination. The node can also send traffic to any on-link multicast address. It can accept link-local multicast packets as usual, with a UDP socket bound to the autonomous link-local address that has joined the link-local multicast group. If the destination node is off-link (which would require a global or ULA address), you will get an error (destination unreachable, code 2 = “beyond scope of source address”). This is because the off-link node will not be able to reply to your node using your link-local address (found as the source address of a packet). If you send to a destination node that is on-link, using a global or ULA address, there is no problem (such a node can reply to your node with no problem).

There is nothing corresponding to this behavior in IPv4. It is key to fully automated network configuration over IPv6 (as used in the Sixscape Distributed Network Management System).