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 Abstract 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). Status of This Memo 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 Notice 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 Smith Expires February 17, 2016 [Page 1] Internet-Draft Indicating Link-Locals are Off-Link August 2015 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Constrained Broadcast Multi-Access (CBMA) Links . . . . . . . 3 3. IPv6 over CBMA Links . . . . . . . . . . . . . . . . . . . . 3 4. Link-Local traffic over CBMA Links . . . . . . . . . . . . . 4 5. Indicating Link-Local Destinations are Off-Link . . . . . . . 5 5.1. Link-Local Router Advertisement Prefix Information Option 5 5.2. Host Link-Local Prefix Information Option Processing . . 5 5.2.1. Upon Receipt of a Link-Local PIO . . . . . . . . . . 5 5.2.1.1. Validation . . . . . . . . . . . . . . . . . . . 5 5.2.1.2. Processing . . . . . . . . . . . . . . . . . . . 6 5.2.2. Upon Expiry of Link-Local Off-Link Information . . . 6 6. Updates to RFC4861 . . . . . . . . . . . . . . . . . . . . . 6 7. Updates to RFC5942 . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. Change Log [RFC Editor please remove] . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction 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). 1.1. Requirements Language 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]. Smith Expires February 17, 2016 [Page 2] Internet-Draft Indicating Link-Locals are Off-Link August 2015 2. Constrained Broadcast Multi-Access (CBMA) Links 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. 3. IPv6 over CBMA 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 Smith Expires February 17, 2016 [Page 3] Internet-Draft Indicating Link-Locals are Off-Link August 2015 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. 4. Link-Local traffic over CBMA Links 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 Smith Expires February 17, 2016 [Page 4] Internet-Draft Indicating Link-Locals are Off-Link August 2015 default router then forwarding the traffic back onto the CBMA link [RFC4007] towards the final Link-Local destination. 5. Indicating Link-Local Destinations are Off-Link 5.1. Link-Local Router Advertisement Prefix Information Option 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: o Prefix Length: 10 [RFC4291] o L or On-Link Flag: 0 (Off) o A or Autonomous Address-Configuration Flag: 0 (Off) o Valid Lifetime: Length of time Link-Local destinations are to be considered off-link o Preferred Lifetime: 0xffffffff (representing infinity) [RFC4862] o Prefix: fe80:: [RFC4291] 5.2. Host Link-Local Prefix Information Option Processing 5.2.1. Upon Receipt of a Link-Local PIO 5.2.1.1. Validation When a host receives a Link-Local Prefix Information Option, it MUST perform the following validation steps: 1. Verifies the Prefix field value is fe80::. If not, this is not a LL PIO, and should be processed as a conventional PIO. 2. Verifies the Prefix Length field value is 10. If not, ignores the LL PIO. 3. Verifies the L or On-Link Flag value is 0. If not, ignores the LL PIO. 4. 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 [RFC4862]. Smith Expires February 17, 2016 [Page 5] Internet-Draft Indicating Link-Locals are Off-Link August 2015 5. 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. 5.2.1.2. Processing 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. 5.2.2. Upon Expiry of Link-Local Off-Link Information 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. 6. Updates to RFC4861 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 Smith Expires February 17, 2016 [Page 6] Internet-Draft Indicating Link-Locals are Off-Link August 2015 "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. 7. Updates to RFC5942 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. Smith Expires February 17, 2016 [Page 7] Internet-Draft Indicating Link-Locals are Off-Link August 2015 8. Security Considerations 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. 9. Acknowledgements 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. 10. Change Log [RFC Editor please remove] draft-smith-6man-link-locals-off-link-00, initial version, 2015-08-16 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 11.2. Informative References [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . Smith Expires February 17, 2016 [Page 8] Internet-Draft Indicating Link-Locals are Off-Link August 2015 [RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005, . [RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC5517] HomChaudhuri, S. and M. Foschiano, "Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", RFC 5517, DOI 10.17487/RFC5517, February 2010, . [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC6957] Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li, "Duplicate Address Detection Proxy", RFC 6957, DOI 10.17487/RFC6957, June 2013, . Author's Address Smith Expires February 17, 2016 [Page 9] Internet-Draft Indicating Link-Locals are Off-Link August 2015 Mark Smith In My Own Time PO BOX 521 HEIDELBERG, VIC 3084 AU Email: markzzzsmith@gmail.com Smith Expires February 17, 2016 [Page 10]