Indicating Link-Local Unicast Destinations are Off-Link

Certain link-layers limit reachability for one set of nodes, while permitting full reachability for a different set of nodes, for unicast, multicast and broadcast traffic. If IPv6 hosts are members of the first set of nodes, and IPv6 routers are members of the second, Link-Local traffic between IPv6 hosts will fail, due to the default on-link assumption for Link-Local destinations. This memo describes the use of a Link-Local Prefix Information Option to indicate to these hosts that Link-Local destinations are "off-link", and are reachable via their default router(s).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

A variety of multi-access link-layers operate or can be configured to constrain layer 2 reachability between attached nodes. Typically, one set of nodes can reach all other attached nodes, while a second disjoint set of nodes are only able to reach members of the first set. Members of the second set are isolated from each other. These constraints are applied to link-layer unicast, multicast and broadcast traffic. Examples of these types of links are Broadband Forum TR-101 VLANs following the N:1 forwarding model, IEEE 802.11 Wifi Networks with station isolation switched on, and "Private VLANs" . This memo uses the more general term "Constrained Broadcast Multi-Access" (CBMA) to describe these types of links. These types of links are distinct from Non-Broadcast Multi-Access (NBMA) links.

When IPv6 is operated over a CBMA link, one or more IPv6 routers would be selected as the link-layer nodes that can reach all other nodes, while IPv6 hosts would be selected as the link-layer nodes limited to only being able to reach the IPv6 routers. Unless informed otherwise via Router Advertisement Prefix Information Options (PIOs) with the L or on-link flag switched on , IPv6 hosts are to consider all non-Link-local destinations off-link, including destination addresses that fall within the prefix their own addresses are assigned from . Unicast destination addresses attached to the same link will be reached by hosts sending their packets towards one of their default routers, which will then forward the packets back over the same link towards the final destinations. This "hair-pin" or "trombone" forwarding between IPv6 hosts attached to the same link, via one or more default routers, allows the router(s) to be used to perform functions in addition to standard IPv6 forwarding, such as traffic inspection for security purposes or per-host traffic accounting. Security examples might be to prevent unauthorised nodes emitting Router Advertisements or acting as unauthorised DHCPv6 servers. Note that multicast IPv6 traffic is normally sent to all link-layer reachable nodes, possibly limited to interested hosts using MLD Snooping . On a CBMA link, IPv6 hosts' multicasts will be further limited to only reaching the IPv6 routers. These IPv6 routers may choose to drop this multicast traffic if they're not interested in it or perform proxy functions for other hosts attached to the link (e.g., DAD Proxy ). The author is not aware of a more general method of multicast forwarding that could be used by the routers to allow all hosts attached to the CBMA link to receive other CBMA link hosts' multicasts should they pass any multicast security policies applied by the CBMA router(s). (When hosts receive multicasts over an interface, do they check if the multicast source address is one of their own, and ignore the multicast if so (as distinct from multicasts looped back locally within the host, enabled by a socket API call)? If so, the CBMA routers could send multicasts back onto the CBMA link (after passing other security checks), and the originating host would ignore them. Perhaps hosts could perform this sort of source address checking if they receive the Link-Local Prefix Information Option, described below, while it remains valid. There isn't a forwarding loop in the link-layer, it is just that originating hosts would receive their own multicasts that need to be ignored. Only one of the routers on the CBMA link would send multicasts back onto the link; the router with the lowest value Link-Local address could be the one, using the set of routers' RA and RS Link-Local source addresses to choose (similar to a multicast router querier election)). The non-elected router would not forward multicast traffic it receives back onto the CBMA link.

Due to the on-link assumption for Link-Local unicast destinations , attempts to send Link-Local traffic to other hosts attached to the CBMA link will fail, as the inter-host reachability has been constrained by the CBMA link. The only Link-Local destinations reachable by the hosts are the Link-Local addresses of the default routers. This limited Link-Local reachability can be detrimental to the operation of IPv6 applications, as IPv6 applications are permitted to use Link-Local addresses for their connectivity , and if multiple scopes of addresses are available for the application to use, Link-Local addresses will be preferred over all others with exception to the loopback address, due to the general rule of preferring addresses with the smaller scopes . If hosts could be informed that Link-Local destinations are to also be considered "off-link", reachability to all Link-Local destinations on the CBMA link would be restored. Hosts would send traffic to all Link-Local destinations via their default router(s), with the chosen default router then forwarding the traffic back onto the CBMA link towards the final Link-Local destination.

To signal to hosts that they should consider Link-Local destinations "off-link", a router sends a Link-Local Prefix Information Option in its Router Advertisements , with the following PIO field values: Prefix Length: 10 L or On-Link Flag: 0 (Off) A or Autonomous Address-Configuration Flag: 0 (Off) Valid Lifetime: Length of time Link-Local destinations are to be considered off-link Preferred Lifetime: 0xffffffff (representing infinity) Prefix: fe80::

When a host receives a Link-Local Prefix Information Option, it MUST perform the following validation steps: Verifies the Prefix field value is fe80::. If not, this is not a LL PIO, and should be processed as a conventional PIO. Verifies the Prefix Length field value is 10. If not, ignores the LL PIO. Verifies the L or On-Link Flag value is 0. If not, ignores the LL PIO. Ignores the A or Autonomous Address-Configuration Flag value, as Link-Local addresses always use Autonomous Address-Configuration, and are formed when an interface becomes enabled . Verifies the Preferred Lifetime field value is Infinity (0xffffffff). If not, ignores the LL PIO. If any of the above validation steps fail, in addition to ignoring the LL PIO, an implementation MAY choose to log an informational or debugging severity level system message about the malformed LL PIO, appropriately rate limited.

Once the LL PIO has been successfully validated, the Link-Local prefix is removed from the host's Prefix List . A count down to zero timer is started with the LL PIO's Valid Lifetime value. While the timer is still running, the host sends all Link-Local destined traffic for the interface it received the LL PIO on to either the router it received the LL PIO from, or to any of the default routers on the link, achieving an amount of load-sharing . As Link-Local destinations are now being reached via the host's default router(s), Neighbor Cache entries for Link-Local destinations, excepting Link-Local entries with the IsRouter flag set , should be removed immediately, regardless of their resolution state. Any active related Neighbor Unreachability Detection procedures should also be terminated.

If Link-Local "Off-Link" information expires, as it has not been refreshed by receiving a LL PIO from any of the link's routers, the Link-Local prefix is returned to the host's Prefix List for the corresponding interface, meaning that Link-Local destinations return to being considered on-link. Subsequent transmissions to Link-Local destinations should trigger Neighbor Discovery , despite the link possibly continuing to be a CBMA-type link.

The following statement in Section 6.3.4 of Neighbor Discovery in IPv6 : "Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link." is replaced by "Note, however, that a Prefix Information option with the on-link flag set to zero conveys no information concerning on-link determination and MUST NOT be interpreted to mean that addresses covered by the prefix are off-link, with exception to a Prefix Information Option for the Link-Local prefix. The Link-Local prefix is considered on-link by default ." "The reception of a Prefix Information option for the Link-Local prefix, with the L-bit set to 0, MUST be interpreted by a host as meaning that Link-Local destinations are to considered off-link, and are to be reached by one of the host's available default routers, while the Prefix Information option information for the Link-Local prefix remains valid [draft-smith-6man-link-locals-off-link]." The following statement in Section 6.3.4 of Neighbor Discovery in IPv6 : "If the prefix is the link-local prefix, silently ignore the Prefix Information option." is removed.

The following statement in the Introduction of IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes : "In IPv6, by default, a host treats only the link-local prefix as on-link." is replaced by "In IPv6, by default, a host treats only the link-local prefix as on-link, unless updated by a Prefix Information option for the link-local prefix, indicating the link-local prefix is to be considered off-link [draft-smith-6man-link-locals-off-link]." The following statement in the Section 3 of IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes : "(The link-local prefix is effectively considered a permanent entry on the Prefix List.)" is deleted.

The security benefit of operating IPv6 over a CBMA link-layer is the insertion of an IPv6 traffic forwarding device between each host and all other possible destinations, including those attached to the same CBMA link. This allows the forwarding device to be used to perform security functions on all CBMA attached host originated traffic, in addition to performing normal IPv6 forwarding. Allowing Link-Local source and destination addresses to be used in an IPv6 over CBMA network does not reduce this security benefit.

Thanks to Chris Chaundy for asking the author about the on-link status of the Link-Local prefix when the author was describing the purpose of the L-bit in Prefix Information Options. Chris's question prompted the thinking behind and writing of this memo. Review and comments were provided by YOUR NAME HERE! This memo was prepared using the xml2rfc tool.

draft-smith-6man-link-locals-off-link-00, initial version, 2015-08-16