In a recent article, I wrote about some of the common questions that IPv6 novices sometimes ask. We then asked the question, “What are the typical questions you get when teaching an IPv6 class?” Frequently, IPv6 instructors field questions from their students about IPv6 link-local addresses and how they work. This article builds upon the IPv6 newbie questions theme and covers a couple of the IPv6 addressing nuances that are often surprising to IPv6 neophytes (and sometimes IPv6 veterans, too!).
Frequently Unicast, Sometimes Multicast, but Never Broadcast
It is relatively easy to grasp the concept that unicast addresses are used for one-to-one communications. Public IPv4 addresses are familiar to most, so grasping IPv6’s global unicast addresses (GUA) (2000::/3) is straightforward. Regardless of whether your organization’s public IPv4 or global IPv6 addresses are provided by an RIR or your upstream ISP, they are free to be used to source and receive Internet communications.
Most enterprise organizations use private IPv4 addresses (e.g., 192.168.0.0/16, 172.16.0.0/12, or 10.0.0.0/8) for their internal networks. However, with IPv6, beginners discover that FD00::/8 Unique Local Addresses (ULAs) exist for private network addressing, although their use is not generally recommended. You are encouraged to read RFC 4864, Local Network Protection for IPv6, to learn about why you do not need private addresses for your internal networks and why you subsequently do not need NAT for IPv6. Please also read Tom Coffeen’s eloquent blogs (part 1 and part 2) on “3 Ways to Ruin Your Future Network with IPv6 Unique Local Addresses”. This is also a topic that we discuss in our IPv6 COE Podcast #3.
Many people are familiar with how multicast addresses are used for one-to-many communications. IPv4 multicast addresses (historically referred to as Class D addresses) are within the 224.0.0.0/4 range. IPv6 multicast addresses start with the two most-significant hex digits “FF” and have the format FF00::/8. After the “FF”, the next 4 bits of the address represents the flag value, and the following 4 bits of the address is the scope of the range of the multicast message. IPv6 multicast addresses can be used for link-local LAN communications or they can be scoped for site-specific communications or even global use. An IPv6 multicast address for well-known link-local messages would start with “FF02” and you may recognize that FF02::1 is the all-nodes link-local multicast group address.
Only IPv4 has broadcast as a method of sending one packet to ALL nodes on the current LAN. Whether the packet’s destination address is 255.255.255.255 and intended for all hosts in the entire broadcast domain or a broadcast address limited to a specific subnet (e.g., 192.168.1.255), both are converted to an “all-ones” layer-2 MAC address FF:FF:FF:FF:FF:FF. Broadcast packets are sent out all Ethernet switch ports, regardless of whether or not there are any hosts on the attached segments that need or want the broadcasted messages. On the other hand, IPv6 doesn’t use the broadcast method of packet delivery so there is no equivalent IPv6 address type. IPv6 networks will never use broadcasts on a LAN. However, sending an IPv6 packet to the all-nodes link-local multicast group address (FF02::1) comes close to that functionality.
Link-Local Addresses and Automatic Private IP Addressing (APIPA)
The concepts of unicast, multicast, and broadcast and their accompanying addresses are familiar to IPv4 experts. However, there is one less-popular address type that can be used for unicast communications on a confined LAN segment. The caveat with these addresses is that they are only locally-significant (i.e., restricted to a single LAN broadcast domain) and are never used to source or receive communications across a layer-3 gateway.
When first learning about IPv6, students are often surprised by the fact that IPv6 has another address type that is much different from the IPv4 address types that they are already familiar with: the link-local address. Typically, link-local IPv6 addresses have “FE80” as the hexadecimal representation of the first 10 bits of the 128-bit IPv6 address, then the least-significant 64-bits of the address are the Interface Identifier (IID). Depending on the IID algorithm the node’s operating system is using, the IID may use either modified EUI-64 with SLAAC, the privacy addressing method (RFC 4941), or the newly published Stable SLAAC IID method (RFC 8064).
When a host boots up, it automatically assigns an FE80::/10 IPv6 address to its interface. You can see the format of the link-local address below. It starts with FE80 and is followed by 54 bits of zeros. Lastly, the final 64-bits provide the unique Interface Identifier.
FE80:0000:0000:0000:abcd:abcd:abcd:abcd
If you want to learn more about link-local IPv6 addresses and their usage on a LAN, please read the latest edition of Rick Graziani’s book “IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6”.
Many people get confused about IPv6 link-local addresses when they are first learning about IPv6 because there isn’t really any IPv4 equivalent of this type of IPv6 address. However, the only thing that comes close to IPv6 link-local addresses is the IPv4 Automatic Private IP Addressing (APIPA) method. When a host fails to obtain an IPv4 address with DHCP, it resigns itself to its fate of being incommunicado, and assigns its interface an APIPA address. You have surely witnessed (likely in a moment of exasperated troubleshooting!) a host with an IPv4 address in the 169.254.0.0/16 range (see RFC 3927). Like IPv6 link-local addresses, these APIPA addresses are usable addresses for unicast communications within a single broadcast domain on the LAN.
Link-Local Address as Default Gateway
Link-local IPv6 addresses are on every interface of every IPv6-enabled host and router. They are essential for LAN-based Neighbor Discovery communication. After the host has gone through the Duplicate Address Detection (DAD) process ensuring that its link-local address (and associated IID) is unique on the LAN segment, it then proceeds to sending an ICMPv6 Router Solicitation (RS) message sourced from that address.
Even routers use link-local addresses on each of their own interfaces. When the router receives the host’s Router Solicitation (RS) message (sent in the attempt to find any router available on the link and to reach the rest of the network), the router immediately replies with an ICMPv6 Router Advertisement (RA) message. That RA message is also sourced from the router’s own link-local address. When the host receives the RA message, it reads the contents, follows the address configuration method indicated in the packet, and, in the case where SLAAC is the address configuration method, uses the RA-included IPv6 /64 prefix to configure a globally-scoped address. The host will then use the router’s link-local address (and MAC contained in the RA) as its default gateway.
At this point, that host would have used this router’s link-local IPv6 address as the next-hop address for the 0::/0 IPv6 default route. After inspecting the host’s routing table, IPv6 greenhorns are often surprised to find that a link-local address is the next-hop address for that route. They then might exclaim “How can that be?!” The retort is “Keep Calm and Learn Link-Local.”
The link-local address might be understood as an address used as a kind of stand-in address – one that indicates the link that should be used to reach the next hop. The host will still send packets sourced from its own global address and destined for the global address of the target. However, the link-local address in the routing table is used to map to the next-hop’s MAC address in the neighbor cache. The link-local address is not used as a destination address of any of the host’s off-net packets, but rather, is just a way for the host to learn the MAC address of the next-hop router that will forward the host’s IPv6 packets onward to the destination address. The host just needs to get the packet started on its hop-by-hop journey toward its destination (and getting the packet to the default gateway is the first step).
Fledgling IPv6 engineers might be initially alarmed by the fact that the router’s link-local address is a perfectly valid next-hop address. But over time, an understanding of the neighbor discovery cache solidifies and this configuration becomes an accepted norm. This fact is also reinforced when you observe the IPv6 unicast routing table on any router, and you immediately see the link-local addresses of its next-hop routers. Routers do not modify the source or destination global unicast address in the packets, but they do use the next-hop link-local addresses as a way to get the packet forwarded across a link onward to the packet’s ultimate destination.
Locally-Administered Link-Local Addresses
The other surprising fact that IPv6 rookies may discover is that the same link-local address can be used on a node’s multiple interfaces. This is because, typically, each node’s interface is presumably connected to a different “link.” Therefore, the local-significance rule of the addresses means that, so long at the IID of the link-local address is unique on that segment, all is right with the world.
IPv6 nodes use either EUI-64, privacy addressing, or stable-SLAAC to derive the IID (i.e., the last 64 bits) of the link-local address. In either case, the IID is not easy to remember and may require cutting and pasting if used in a static configuration. The same link-local IID dilemma exists for routers and other middle-boxes like firewalls and load-balancers. In these situations, we may need to statically configure the next-hop IPv6 address for a static route or for the default gateway on a host. Therefore, we want a way to make things easy on ourselves when it comes to the configuration we choose to use.
One method to make things easier is to manually assign the link-local address to the upstream router’s interfaces. If you assign the link-local address FE80::1 on each of its interfaces and if that link-local address is unique on each of those LAN segments, then this becomes the default gateway for the hosts on those LANs. Therefore, each host, no matter on which LAN, will see FE80::1 as the next-hop IPv6 address for the default route in its routing table. The picture below illustrates this idea of using locally-administered link-local addresses. In the case of servers with statically assigned IPv6 addresses and default gateways, this can make things simpler for the system administrator.
Summary
Link-local IPv6 addresses may be initially confusing when you’re first learning about IPv6. But you will quickly become familiar with how they work and appreciate their functionality. At first, it may seem strange to use a link-local IPv6 address as a next-hop address for a static route or as a default gateway router in a host’s routing table. However, there are methods such as locally-administered link-local addresses that can dramatically simplify this static configuration. It’s just another way in which IPv6 can be simpler than the legacy IPv4 protocol.
This post originally appeared on Infoblox community: https://community.infoblox.com/t5/IPv6-CoE-Blog/FE80-1-is-a-Perfectly-Valid-IPv6-Default-Gateway-Address/ba-p/10706
Scott Hogg is the Chief Technology Officer (CTO) for GTRI.
