{"id":4321,"date":"2019-12-31T08:00:29","date_gmt":"2019-12-31T16:00:29","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=4321"},"modified":"2025-04-02T11:53:57","modified_gmt":"2025-04-02T18:53:57","slug":"the-ipv6-prefix-information-option-or-fun-with-the-l-flag","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/the-ipv6-prefix-information-option-or-fun-with-the-l-flag\/","title":{"rendered":"The IPv6 Prefix Information Option or Fun with the L Flag"},"content":{"rendered":"

As a follow up to \u201cThe Odd History of Provisioning an IPv6 Address on a Host<\/a>\u201d 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:<\/p>\n

    \n
  1. Manual assignment (i.e., statically configure it on the host)<\/li>\n
  2. Stateless Address Autoconfiguration (SLAAC<\/a>) (RFC 4862<\/a>)<\/li>\n
  3. Dynamic Host Configuration Protocol version 6 (DHCPv6<\/a>) (RFC 8415<\/a>)<\/li>\n<\/ol>\n

    IPv6<\/strong><\/a> 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<\/a>. In the previous post, we covered the M and O flags, which are crucial for achieving IPV6 Readiness<\/strong><\/a> by configuring hosts to handle address provisioning dynamically. 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.<\/p>\n

    A flag that we didn\u2019t 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 \u201clocal\u201d 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 \u201csend the traffic to me\u201d or \u201cdon\u2019t bother\u00ad\u2014you can do a Neighbor Discovery to find your neighbors address because it is local to you.\u201d (For more technical detail, see RFC 4861 section 4.6.2<\/a>, Prefix Information, which covers both the L and the A flags.)<\/p>\n

    This may seem like an odd flag–wouldn\u2019t 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<\/em> 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:<\/p>\n\n\n\n\n\n\n\n
    Flag Type<\/td>\nName<\/td>\nMessage<\/td>\nManual<\/td>\nSLAAC<\/td>\nDHCPv6<\/td>\n<\/tr>\n
    A<\/td>\nAutonomous<\/td>\nPrefix Information<\/td>\nNo<\/td>\nYes<\/td>\nMaybe<\/td>\n<\/tr>\n
    M<\/td>\nManaged<\/td>\nICMPv6 134 RA<\/td>\nNo<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
    O<\/td>\nOther<\/td>\nICMPv6 134 RA<\/td>\nNo<\/td>\nMaybe<\/td>\nYes<\/td>\n<\/tr>\n
    L<\/strong><\/td>\nOn-Link<\/strong><\/td>\nPrefix Information<\/strong><\/td>\nNo<\/strong><\/td>\nYes<\/strong><\/td>\nYes<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Let\u2019s 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\u2019t 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<\/a>).<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    When you consider the L flag operational use cases you typically end up with the following:<\/p>\n