As a follow up to “The Odd History of Provisioning an IPv6 Address on a Host” blog post, I wanted to tackle some additional provisioning options that are available to you (along with why you might want to consider using them). You may recall that in IPv6 you can use the following methods to provision an address on a host:
- Manual assignment (i.e., statically configure it on the host)
- Stateless Address Autoconfiguration (SLAAC) (RFC 4862)
- Dynamic Host Configuration Protocol version 6 (DHCPv6) (RFC 8415)
IPv6 utilizes ICMPv6 Router Advertisement (RA) messages to tell the host operating system which method to use for address provisioning. But there are also some additional options we can set inside the RA packet. Remember that the router shares this sort of information by using Router Advertisement flags. In the previous post we covered the M and O flags. These flags allow us to specify whether hosts should use DHCPv6 in the provisioning of an address, and if so, which method (i.e., Stateful or Stateless). There is also an A flag in the router prefix information option header. This flag is used to tell hosts if they should utilize SLAAC to auto-provision an address using the prefix that the router is providing.
A flag that we didn’t cover in the previous blog, but one that is critical to understand for proper host configuration, is the On-Link, or (L) flag. The L flag lets the host OS know what prefixes are “local” to the host and those that are off-link (or beyond the router/default gateway). Effectively it is a flag the router uses to say “send the traffic to me” or “don’t bother—you can do a Neighbor Discovery to find your neighbors address because it is local to you.” (For more technical detail, see RFC 4861 section 4.6.2, Prefix Information, which covers both the L and the A flags.)
This may seem like an odd flag–wouldn’t it be obvious that a prefix is local to me if the router is telling me to provision an IPv6 address with it? Actually, because we can assign multiple prefixes via the RA and via DHCPv6 it is possible we may be providing a prefix that is not shared to all the hosts on a given subnet or Layer 2 domain. Optionally, we may want to force all traffic back to the router for other reasons. In summary, the L flag will only impact SLAAC and DHCPv6 hosts if enabled, assuming you are setting all the next hop parameters in the manual configuration. So, you can add on the L flag to the table from our previous blog post to get:
| Flag Type | Name | Message | Manual | SLAAC | DHCPv6 |
| A | Autonomous | Prefix Information | No | Yes | Maybe |
| M | Managed | ICMPv6 134 RA | No | No | Yes |
| O | Other | ICMPv6 134 RA | No | Maybe | Yes |
| L | On-Link | Prefix Information | No | Yes | Yes |
Let’s examine some use cases where the L flag might be useful to enable. The first is forcing all traffic through the router for security reasons. You might want to do this because the network is a shared resource for guests, and you do not want hosts on the same Layer 2 subnet to discover and communicate with each other directly. Instead, you want to have all that traffic go through the router to make sure it only goes to the desired location. Think of it as a least-effort access control policy to reduce neighbor-to-neighbor traffic. It has the benefit of reducing exploitation via viruses, worms and other malicious methods that attempt to infect hosts on the same network segment. Of course, things aren’t bulletproof, because hosts may still discover each other via link-local addresses and multicast name resolution, but it significantly reduces the attack surface. There are other methods that can be used in conjunction to make this approach even more secure (perhaps leveraging Private VLANs).
Second, you may need to enable the L flag on non-broadcast multiple access (NBMA) networks. An example could be an older frame-relay hub-and-spoke configurations where a shared subnet might be used for the WAN interfaces but spoke-to-spoke traffic must go through the hub. While not as common a deployment architecture anymore, it still needs to support IPv6 too.
Third, and I think the most common use case of utilizing the L flag for operational advantages, is with Wi-Fi or wireless LAN deployments. In a wireless configuration utilizing a central controller, you likely want client sessions to always go through the controller, especially for guest networks. There is no reason for a wireless client to talk to another wireless client on the same Layer 2 domain, so telling the host to send all traffic through the router is not an awful strategy. It looks similar to the first, but the main objective is that the network traffic behavior more closely align with the Layer 1 shared radio medium requirements of Wi-Fi. Reducing the amount of multicast to broadcast traffic is important in wireless as this will cause fewer interruptions of all the hosts on a given network. This conserves the radio spectrum and increases performance of the Wi-Fi network overall.
When you consider the L flag operational use cases you typically end up with the following:
- Guest Wi-Fi network having the L flag enabled.
- Corporate Wi-Fi network having the L flag enabled.
- IoT networks (Wi-Fi and wired) having the L flag enabled if the IoT devices don’t need peer-to-peer capabilities.
That wraps up the year with my recommendations for RA flag configurations. Here is to deploying lots of IPv6 in 2020!
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
Ed Horley (@ehorley) is CEO of HexaBuild.io, an IPv6 consulting and training company. Ed is Co-chair of the California IPv6 Task Force (CAv6TF) and authored the Apress Press book on Practical IPv6 for Windows Administrators. Follow HexaBuild on Twitter and LinkedIn.
