| Internet Engineering Task Force | M. Smith |
| Internet-Draft | IMOT |
| Updates: 4861, 5942 (if approved) | August 16, 2015 |
| Intended status: Standards Track | |
| Expires: February 17, 2016 |
Indicating Link-Local Unicast Destinations are Off-Link
draft-smith-6man-link-locals-off-link-00
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).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2016.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119].
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" [RFC5517].
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 [RFC4861], 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 [RFC5942]. 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 [RFC4541]. 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 [RFC6957]).
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 [RFC5942], 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 [RFC4007], 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 [RFC6724].
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 [RFC4007] 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 [RFC4861], with the following PIO field values:
When a host receives a Link-Local Prefix Information Option, it MUST perform the following validation steps:
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 [RFC5942]. 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 [RFC4311].
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 [RFC4861], 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 [RFC4861], despite the link possibly continuing to be a CBMA-type link.
The following statement in Section 6.3.4 of Neighbor Discovery in IPv6 [RFC4861]:
"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 [RFC5942]."
"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 [RFC4861]:
"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 [RFC5942]:
"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 [RFC5942]:
"(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
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |