6man Working Group                                             T. Jinmei
Internet-Draft                                                  Infoblox
Intended status: Informational                            March 13, 2017
Expires: September 14, 2017


           Clarifications on On-link and Subnet IPv6 Prefixes
                  draft-jinmei-6man-prefix-clarify-00

Abstract

   The IPv6 Neighbor Discovery and Stateless Address Autoconfiguration
   protocols intentionally separate the handling of prefixes for their
   purposes: these prefixes can be different for the same link even if
   it may be uncommon in practice; validation for these purposes is
   expected to be performed separately and independently.  Despite the
   revised text of the latest versions of these protocol specifications,
   it appears that the idea of this separation can still be easily
   misunderstood.  This document clarifies the idea even more explicitly
   in order to set the common understanding of the intent of the current
   specifications.

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 September 14, 2017.

Copyright Notice

   Copyright (c) 2017 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



Jinmei                 Expires September 14, 2017               [Page 1]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   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
   2.  Requirements Language and Terminology . . . . . . . . . . . .   3
   3.  Clarifications  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Implementation Status . . . . . . . . . . . . . . . . . . . .   7
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC4861] defines the Prefix Information option (PIO) of the Neighbor
   Discovery Router Advertisement (RA) message.  It is used by receiving
   hosts for on-link determination, that is, determining which prefixes
   are to be considered on-link in the link through which the RA is
   delivered.  [RFC4862] also uses the PIO for the purpose of stateless
   address autoconfiguration (SLAAC).  While a single PIO is often used
   for both purposes, the corresponding specifications intend to handle
   them separately and independently.  In particular, the prefix in a
   PIO is not expected to be considered to be invalid for on-link
   determination simply because the prefix fails to validate in SLAAC,
   or vice versa.

   The idea of separating these two purposes had often been
   misunderstood in prior specifications of [RFC4861] and [RFC4862], so
   these successor RFCs tried to clarify the intent with additional
   text.  According to a recent discussion at the 6man working group in
   the context of advancing [RFC4291], however, it turned out that it
   may still not be uncommon that the separation is misunderstood.
   There are even reportedly implementations that invalidate a prefix
   for on-link determination when it is invalid for SLAAC.  Although
   this misunderstanding would normally not cause troubles in practical
   deployments, it can be a source of operational surprise or
   interoperability problems once an administrator wants to exploit the
   idea of this separation more "creatively".





Jinmei                 Expires September 14, 2017               [Page 2]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   This document clarifies the idea of separating on-link prefixes and
   SLAAC prefixes according to the original intent of the RFCs with some
   background history and implementation and testing status so that
   everyone can have the common understanding of the intent of the
   current protocol specifications.  Even if the separation is not
   explicitly enforced with normative keywords, the circumstantial
   evidences discussed in this document hopefully help set the
   consistent expectation.

   It would be worth noting that this document simply and redundantly
   repeats a point already described in [RFC5942] in a sense: "an IPv6
   address isn't automatically associated with an IPv6 on-link prefix."
   However, this document specifically focuses on the fact that the
   prefix in a PIO has two independent meaning, while [RFC5942] seems to
   be more interested in cases like how a host is expected to consider a
   particular prefix as on-link, especially when the host configures the
   address through some other way than SLAAC.  In particular, it would
   not be straightforward just from [RFC5942] that a host must not
   ignore a prefix for on-link determination due to prefix validation
   for SLAAC.  This document specifically addresses such issues.

   This document does not update any existing standards.  It merely
   clarifies the intent of some standard documents.  This document also
   does not intend to state the current intent of the standards is good
   or bad.  Instead, it tries to set the accurate understanding of the
   current specifications in case the working group sees the need for
   revisiting them.

2.  Requirements Language and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] when they appear in ALL CAPS.  When these words are not in
   ALL CAPS (such as "should" or "Should"), they have their usual
   English meanings, and are not to be interpreted as [RFC2119] key
   words.

   For the purpose of clarification, this document introduces the
   following terminology to clearly distinguish two different types of
   prefixes that are the main subject of this document:

   On-link prefix  A prefix advertised in an RA PIO with the L flag
      being set.

   SLAAC subnet prefix  A prefix advertised in an RA PIO with the A flag
      being set.




Jinmei                 Expires September 14, 2017               [Page 3]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   Note that a single RA PIO can specify an on-link prefix and an SLAAC
   subnet prefix at the same time, i.e., when both the L and A flags are
   set.  In fact, this is a typical configuration of prefixes advertised
   via RA messages.

   It may also be worth noting that an SLAAC subnet prefix is not
   directly related to the "subnet prefix" as defined in Section 2.5 of
   [RFC4291], even if they are actually the same prefix in the end: both
   define some leading bits of IPv6 addresses followed by a specific
   length of interface identifier.  From the perspective of [RFC4862],
   however, an SLAAC subnet prefix is just a prefix advertised via an RA
   PIO with the A flag being set.  [RFC4862] does not directly refer to
   [RFC4291] to introduce the concept of the SLAAC subnet prefix.  It
   would therefore make sense to explicitly call it an "SLAAC" subnet
   prefix.

   For brevity, this document focuses on global unicast prefixes.
   Discussions on any other types of prefixes, including unicast link-
   local prefixes, are out of scope of this document.

3.  Clarifications

   [RFC4861] and [RFC4862] intentionally separate the concept and
   handling of on-link prefixes and SLAAC subnet prefixes, even when
   they are specified in the same single PIO.

   [RFC4862] requires that the sum of the length of SLAAC subnet prefix
   and the length of the interface identifier be 128 (Section 5.5.3,
   bullet d), whatever the latter length is according to the link-type
   specification.  This means that, for example, if the length of
   interface identifiers for the link is specified as 63, 64, or 65,
   then the SLAAC subnet prefix length must be 65, 64, or 63,
   respectively; otherwise the PIO is ignored for the purpose of SLAAC.

   Note that [RFC4862] itself does not specify a particular prefix
   length of an SLAAC subnet prefix (which is determined as "128 -
   length-of-interface-identifier").  [RFC4862] only states in its
   Section 2 that the length of interface identifiers is defined in a
   specific link-type document and that it assumes the link-type
   specification is consistent with the IPv6 addressing architecture.
   If a link-type specification defines the interface identifier length
   to be 64 bits, the SLAAC subnet prefix must be 128 - 64 = 64 bits.
   But this is just logically derived from the link-type specification
   and the constraint of Section 5.5.3, bullet d; [RFC4862] itself does
   not directly specify the length of an SLAAC subnet prefix or an
   interface identifier.





Jinmei                 Expires September 14, 2017               [Page 4]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   [RFC4861] does not impose any restriction on the length of on-link
   prefixes.  It can be any value between 0 and 128, inclusive.  One of
   the original co-authors of the Neighbor Discovery specification
   confirmed that an on-link prefix can be different from an SLAAC
   subnet prefix [rfc2461bis], when the working group discussed a
   revision of the spec, which subsequently resulted in [RFC4861].

   [RFC4861] added the following text to Section 6.3.4 in an attempt of
   clarifying the separation:

      [...] Similarly, [ADDRCONF] may impose certain restrictions on the
      prefix length for address configuration purposes.  Therefore, the
      prefix might be rejected by [ADDRCONF] implementation in the host.
      However, the prefix length is still valid for on-link
      determination when combined with other flags in the prefix option.

   where [ADDRCONF] means [RFC4862].  Along with the specific discussion
   at that time [rfc2461bis], this added text intends to note that a
   compliant implementation of [RFC4861] must not ignore an on-link
   prefix simply because it has an invalid length as an SLAAC subnet
   prefix per [RFC4862].

   Similarly, [RFC4862] introduced the following paragraph in
   Section 5.5.3 by revising the prior version of it with additional
   sentences:

      It is the responsibility of the system administrator to ensure
      that the lengths of prefixes contained in Router Advertisements
      are consistent with the length of interface identifiers for that
      link type.  It should be noted, however, that this does not mean
      the advertised prefix length is meaningless.  In fact, the
      advertised length has non-trivial meaning for on-link
      determination in [RFC4861] where the sum of the prefix length and
      the interface identifier length may not be equal to 128.  Thus, it
      should be safe to validate the advertised prefix length here, in
      order to detect and avoid a configuration error specifying an
      invalid prefix length in the context of address autoconfiguration.

   The primary purpose of the added text was to clarify why the SLAAC
   subnet prefix is needed to be provided with its length and why it has
   to be validated at all even if it can be derived from the length of
   the interface identifier.  But it also gives another circumstantial
   evidence that on-link and SLAAC subnet prefixes are independent.  In
   fact, if an invalid length for an SLAAC subnet prefix made it also
   invalid as an on-link prefix, it would not have to note there is a
   case where the sum is not equal to 128.





Jinmei                 Expires September 14, 2017               [Page 5]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   In practice, the same prefix is often used for both on-link and SLAAC
   subnet purposes.  In that case, RAs in that link would be configured
   to include a single PIO for that prefix with both the L and A flags
   set.

   An on-link prefix could be longer than an SLAAC subnet prefix.  For
   example, when the latter is 2001:db8:1:2::/64, the former could be
   2001:db8:1:2:3:4::/80.  Perhaps the administrator of the link wanted
   to force most of on-link communication to 2001:db8:1:2::/64 to be
   first sent to a default router, while allowing a particular set of
   hosts (those using the address that match the on-link prefix) to
   communicate directly.  In this case, RAs in that link would have two
   PIOs, one for the /64 SLLAC subnet prefix with the A flag set but L
   flag cleared, and the /80 on-link prefix with the L flag set but A
   flag cleared.

   An on-link prefix could also be shorter than an SLAAC subnet prefix.
   For example, when the latter is 2001:db8:1:2::/64, the former could
   be 2001:db8:1::/48.  Perhaps the administrator of the link configured
   hosts from multiple /64 SLAAC subnet prefixes that match the /48 on-
   link prefix (2001:db8:1:1::/64, 2001:db8:1:2::/64, etc), presumably
   using unicast RAs, but wanted these hosts to communicate directly
   rather than via a default router.  In this case, each of RAs in that
   link would have two PIOs, one for (one of) the /64 SLLAC subnet
   prefix with the A flag set but L flag cleared, and the /48 on-link
   prefix with the L flag set but A flag cleared.

   Admittedly, the last two cases are imaginary examples.  The author of
   this document does not know of actual deployments of these
   configurations.  But the point is that the current protocol
   specifications intentionally allow such configurations.

   Another, even more peculiar, example would be that a PIO with both
   the L and A flags set but its length is different from the length of
   SLAAC subnet prefix derived from the length of interface identifiers
   of the link defined in the link-specific documentation.  In this
   case, a receiving host is expected to ignore the prefix as an SLAAC
   subnet prefix, as clearly described in Section 5.5.3 of [RFC4862].
   In that sense this is most likely some kind of operational error: the
   administrator should either correct the prefix length or clear the A
   flag.  However, the host is still expected to treat it as a valid on-
   link prefix.  In a prior working group discussion it was explicitly
   confirmed that this is the intent of the protocol specification
   [rfc2461bis].

   Finally, it may also be noteworthy that the fact that an on-link
   prefix can be of any length between 0 and 128 has nothing to do with
   how strictly or loosely the subnet prefix length is fixed in the IPv6



Jinmei                 Expires September 14, 2017               [Page 6]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   addressing architecture [RFC4291].  For example, the fact that the
   length of an on-link prefix can be 48, 80 or other bits is not
   contradictory to the fact that [RFC4291] states the interface
   identifiers (and therefore subnet) of a particular set of addresses
   are 64 bits in length.  Only SLAAC subnet prefixes have an indirect
   implication with the addressing architecture as noted in Section 2.

4.  Implementation Status

   The separation of on-link prefixes and SLAAC subnet prefixes seems to
   be widely interpreted and implemented as clarified in this document.
   The author knows at least three (if not all) broadly used BSD
   variants, Free/Net/OpenBSDs, have supported the described behavior
   and they still do.  Test 2.2.9 of the widely adopted "IPv6 Ready"
   test [v6ready] confirms that a compliant host does not ignore an on-
   link prefix simply because its length is different from the SLAAC
   subnet prefix length for the link.  From these facts it should be
   safe to say the intent of the specification is generally well
   understood.

   However, a recent discussion reveals that there is a different
   interpretation of [RFC4862], and there are reportedly implementations
   of that interpretation.  This interpretation applies Section 5.5.3 of
   [RFC4862] to validation of on-link prefixes simply because the RFC
   does not explicitly say the restrictions are only applicable to SLAAC
   subnet prefixes.  In particular, those implementations ignore a PIO
   as both on-link and SLAAC subnet prefix, and do so regardless of the
   A or L flag values, according to a working discussion [lwip].

   As clarified in Section 3, this behavior is clearly against the
   intent of the specification, if not explicitly violating a statement
   marked with an [RFC2119] keyword.  Besides, it does not make much
   sense to use the fact that [RFC4862] does not explicitly note
   Section 5.5.3 is only applicable to SLAAC purposes as the rationale
   for this behavior.  This section also states: "If the Autonomous flag
   is not set, silently ignore the Prefix Information option."  If we
   allowed the rationale, this restriction would mean any PIO with the L
   flag set must be ignored unless the A flag is also set.  Obviously
   this does not make sense, which should also mean this section should
   read in the context of SLAAC only.

   In practice, though, the "non-compliant" behavior may not be that
   harmful in practice.  As noted in Section 3, it would be quite
   unlikely to see an on-link prefix whose length is not equal to the
   length of SLAAC subnet prefix (or 128 - interface-identifier-length
   if SLAAC is not used).  Unless and until the administrator really
   wants to employ the unusual length of on-link prefixes, the
   difference of the behavior will not cause a problem.  However, it



Jinmei                 Expires September 14, 2017               [Page 7]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


   should be noted that once an administrator wants to use such an
   operation, it will be the implementation that is to be blamed, not
   the administrator.

5.  Conclusions

   [RFC4861] and [RFC4862] separate the concept and validation of on-
   link and SLAAC subnet prefixes.  While these prefixes are often the
   same in a link, they can also be different.  The RFCs do not intend
   to allow rejecting an on-link prefix due to a restriction on SLAAC
   subnet prefixes, or vice versa.  Whether liked or hated, this is the
   fact, and the intent has been explicitly discussed and confirmed, and
   is widely implemented today.  There are still reportedly some
   implementations that misunderstand the intent.  While technically
   they would be considered non-compliant to the current specification,
   the effect of the violation would be limited in practice.

   This document does not take a position about whether the intended
   concept and behavior described in [RFC4861] and [RFC4862] as
   clarified in this document is good or bad.  It merely clarifies the
   original intent that seems to be sometimes misunderstood.  The
   working group is free to revisit the original intent if it reaches a
   consensus as such, but it should be based on the correct
   understanding of the current specification; otherwise they would not
   even be able to agree that it is an update to the current
   specification or a clarification on things implemented incorrectly.
   This document hopefully helps set such a base understanding for any
   future discussions.

6.  Security Considerations

   This document only clarifies the intent of some existing standard
   documents, and does not make updates to them.  The clarifications are
   not security issues.  It is therefore not expected to introduce any
   new security considerations.

7.  Acknowledgements

   Kevin Lahey reviewed the initial draft of this document and provided
   feedback.

   This document was produced using the xml2rfc tool [RFC2629].

8.  References







Jinmei                 Expires September 14, 2017               [Page 8]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


8.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>.

   [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>.

8.2.  Informative References

   [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>.

   [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>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.

   [rfc2461bis]
              Nordmark, E., "Reception of prefix option with prefix
              length > 64", February 2004, <https://www.ietf.org/mail-
              archive/web/ipv6/current/msg01801.html>.

   [v6ready]  IPv6 Forum, "IPv6 Ready Phase-1/Phase 2 Test Specification
              Core Protocols", April 2010,
              <https://www.ipv6ready.org/docs/
              Core_Conformance_Latest.pdf>.

   [lwip]     Woodyatt, J., "A proposal for draft-ietf-6man-rfc4291bis-
              07", March 2017, <https://www.ietf.org/mail-
              archive/web/ipv6/current/msg26519.html>.






Jinmei                 Expires September 14, 2017               [Page 9]


Internet-Draft      On-link and Subnet IPv6 Prefixes          March 2017


Author's Address

   Tatuya Jinmei
   Infoblox















































Jinmei                 Expires September 14, 2017              [Page 10]