Internet DRAFT - draft-smith-6man-link-locals-off-link

draft-smith-6man-link-locals-off-link







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,
              <http://www.rfc-editor.org/info/rfc2119>.

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,
              <http://www.rfc-editor.org/info/rfc4007>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <http://www.rfc-editor.org/info/rfc4291>.





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,
              <http://www.rfc-editor.org/info/rfc4311>.

   [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,
              <http://www.rfc-editor.org/info/rfc4541>.

   [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,
              <http://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <http://www.rfc-editor.org/info/rfc4862>.

   [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,
              <http://www.rfc-editor.org/info/rfc5517>.

   [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,
              <http://www.rfc-editor.org/info/rfc5942>.

   [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,
              <http://www.rfc-editor.org/info/rfc6724>.

   [RFC6957]  Costa, F., Combes, J-M., Ed., Pougnard, X., and H. Li,
              "Duplicate Address Detection Proxy", RFC 6957,
              DOI 10.17487/RFC6957, June 2013,
              <http://www.rfc-editor.org/info/rfc6957>.

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]