summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5942.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5942.txt')
-rw-r--r--doc/rfc/rfc5942.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5942.txt b/doc/rfc/rfc5942.txt
new file mode 100644
index 0000000..94177cb
--- /dev/null
+++ b/doc/rfc/rfc5942.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) H. Singh
+Request for Comments: 5942 W. Beebee
+Updates: 4861 Cisco Systems, Inc.
+Category: Standards Track E. Nordmark
+ISSN: 2070-1721 Oracle, Inc.
+ July 2010
+
+
+ IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
+
+Abstract
+
+ IPv6 specifies a model of a subnet that is different than the IPv4
+ subnet model. The subtlety of the differences has resulted in
+ incorrect implementations that do not interoperate. This document
+ spells out the most important difference: that an IPv6 address isn't
+ automatically associated with an IPv6 on-link prefix. This document
+ also updates (partially due to security concerns caused by incorrect
+ implementations) a part of the definition of "on-link" from RFC 4861.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5942.
+
+Copyright Notice
+
+ Copyright (c) 2010 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.
+
+
+
+Singh, et al. Standards Track [Page 1]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ This document may contain material from IETF Documents or IETF
+ Contributions published or made publicly available before November
+ 10, 2008. The person(s) controlling the copyright in some of this
+ material may not have granted the IETF Trust the right to allow
+ modifications of such material outside the IETF Standards Process.
+ Without obtaining an adequate license from the person(s) controlling
+ the copyright in such materials, this document may not be modified
+ outside the IETF Standards Process, and derivative works of it may
+ not be created outside the IETF Standards Process, except to format
+ it for publication as an RFC or to translate it into languages other
+ than English.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Requirements Language ...........................................4
+ 3. Host Behavior ...................................................4
+ 4. Host Rules ......................................................7
+ 5. Observed Incorrect Implementation Behavior ......................8
+ 6. Updates to RFC 4861 .............................................9
+ 7. Conclusion ......................................................9
+ 8. Security Considerations .........................................9
+ 9. Contributors ....................................................9
+ 10. Acknowledgements ...............................................9
+ 11. References ....................................................10
+ 11.1. Normative References .....................................10
+ 11.2. Informative References ...................................10
+
+1. Introduction
+
+ IPv4 implementations typically associate a netmask with an address
+ when an IPv4 address is assigned to an interface. That netmask
+ together with the IPv4 address designates an on-link prefix. Nodes
+ consider addresses covered by an on-link prefix to be directly
+ attached to the same link as the sending node, i.e., they send
+ traffic for such addresses directly rather than to a router. See
+ Section 3.3.1 of [RFC1122]. Prior to the development of subnetting
+ [RFC0950] and Classless Inter-Domain Routing (CIDR) [RFC4632], an
+ address's netmask could be derived directly from the address simply
+ by determining whether it was a Class A, B, or C address. Today,
+ assigning an address to an interface also requires specifying a
+ netmask to use. In the absence of specifying a specific netmask when
+ assigning an address, some implementations would fall back to
+ deriving the netmask from the class of the address.
+
+ The behavior of IPv6 as specified in Neighbor Discovery (ND)
+ [RFC4861] is quite different. The on-link determination is separate
+ from the address assignment. A host can have IPv6 addresses without
+
+
+
+Singh, et al. Standards Track [Page 2]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ any related on-link prefixes or can have on-link prefixes that are
+ not related to any IPv6 addresses that are assigned to the host. Any
+ assigned address on an interface should initially be considered as
+ having no internal structure as shown in [RFC4291].
+
+ In IPv6, by default, a host treats only the link-local prefix as
+ on-link.
+
+ The reception of a Prefix Information Option (PIO) with the L-bit set
+ [RFC4861] and a non-zero valid lifetime creates (or updates) an entry
+ in the Prefix List. All prefixes on a host's Prefix List (i.e.,
+ those prefixes that have not yet timed out) are considered to be
+ on-link by that host.
+
+ The on-link definition in the Terminology section of [RFC4861], as
+ modified by this document, defines the complete list of cases in
+ which a host considers an address to be on-link. Individual address
+ entries can be expired by the Neighbor Unreachability Detection
+ mechanism.
+
+ IPv6 packets sent using the Conceptual Sending Algorithm as described
+ in [RFC4861] only trigger address resolution for IPv6 addresses that
+ the sender considers to be on-link. Packets to any other address are
+ sent to a default router. If there is no default router, then the
+ node should send an ICMPv6 Destination Unreachable indication as
+ specified in [RFC4861] -- more details are provided in the "Host
+ Behavior" and "Host Rules" sections of this document. (Note that
+ [RFC4861] changed the behavior when the Default Router List is empty.
+
+ In the old version of Neighbor Discovery [RFC2461], if the Default
+ Router List is empty, rather than sending the ICMPv6 Destination
+ Unreachable indication, the [RFC2461] node assumed that the
+ destination was on-link.) Note that ND is scoped to a single link.
+ All Neighbor Solicitation (NS) responses are assumed to be sent out
+ the same interface on which the corresponding query was received
+ without using the Conceptual Sending Algorithm.
+
+ Failure of host implementations to correctly implement the IPv6
+ subnet model can result in lack of IPv6 connectivity. See the
+ "Observed Incorrect Implementation Behavior" section for details.
+
+ This document deprecates the last two bullets from the definition of
+ "on-link" in [RFC4861] to address security concerns arising from
+ particular ND implementations.
+
+ Host behavior is clarified in the "Host Behavior" and "Host Rules"
+ sections.
+
+
+
+
+Singh, et al. Standards Track [Page 3]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+2. 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].
+
+3. Host Behavior
+
+ 1. The original Neighbor Discovery (ND) specification [RFC4861] was
+ unclear in its usage of the term "on-link" in a few places. In
+ IPv6, an address is on-link (with respect to a specific link), if
+ the address has been assigned to an interface attached to that
+ link. Any node attached to the link can send a datagram directly
+ to an on-link address without forwarding the datagram through a
+ router. However, in order for a node to know that a destination
+ is on-link, it must obtain configuration information to that
+ effect. In IPv6, there are two main ways of maintaining
+ information about on-link destinations. First, a host maintains
+ a Prefix List that identifies ranges of addresses that are to be
+ considered on-link. Second, Redirects can identify individual
+ destinations that are on-link; such Redirects update the
+ Destination Cache.
+
+ The Prefix List is populated via the following means:
+
+ * Receipt of a valid Router Advertisement (RA) that specifies a
+ prefix with the L-bit set. Such a prefix is considered
+ on-link for a period specified in the Valid Lifetime and is
+ added to the Prefix List. (The link-local prefix is
+ effectively considered a permanent entry on the Prefix List.)
+
+ * Indication of an on-link prefix (which may be a /128) via
+ manual configuration, or some other yet-to-be-specified
+ configuration mechanism.
+
+ A Redirect can also signal whether an address is on-link. If a
+ host originates a packet, but the first-hop router routes the
+ received packet back out onto the same link, the router also
+ sends the host a Redirect. If the Target and Destination Address
+ of the Redirect are the same, the Target Address is to be treated
+ as on-link as specified in Section 8 of [RFC4861]. That is, the
+ host updates its Destination Cache (but not its Prefix List --
+ though the impact is similar).
+
+ 2. It should be noted that ND does not have a way to indicate a
+ destination is "off-link". Rather, a destination is assumed to
+ be off-link, unless there is explicit information indicating that
+ it is on-link. Such information may later expire or be changed,
+
+
+
+Singh, et al. Standards Track [Page 4]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ in which case a destination may revert back to being considered
+ off-link, but that is different than there being an explicit
+ mechanism for signaling that a destination is off-link. Redirect
+ messages do not contain sufficient information to signal that an
+ address is off-link. Instead, Redirect messages indicate a
+ preferred next hop that is a more appropriate choice to use than
+ the originator of the Redirect.
+
+ 3. IPv6 also defines the term "neighbor" to refer to nodes attached
+ to the same link and that can send packets directly to each
+ other. Received ND packets that pass the required validation
+ tests can only come from a neighbor attached to the link on which
+ the ND packet was received. Unfortunately, [RFC4861] is
+ imprecise in its definition of "on-link" and states that a node
+ considers an address to be on-link if:
+
+ * a Neighbor Advertisement (NA) message is received for the
+ (target) address, or
+
+ * any Neighbor Discovery message is received from the address.
+
+ Neither of these tests are acceptable definitions for an address
+ to be considered as on-link as defined above, and this document
+ deprecates and removes both of them from the formal definition of
+ "on-link". Neither of these tests should be used as
+ justification for modifying the Prefix List or Destination Cache
+ for an address.
+
+ The conceptual sending algorithm of [RFC4861] defines a Prefix
+ List, Destination Cache, and Default Router List. The
+ combination of Prefix List, Destination Cache, and Default Router
+ List form what many implementations consider to be the IP data
+ forwarding table for a host. Note that the Neighbor Cache is a
+ separate data structure referenced by the Destination Cache, but
+ entries in the Neighbor Cache are not necessarily in the
+ Destination Cache. It is quite possible (and intentional) that
+ entries be added to the Neighbor Cache for addresses that would
+ not be considered on-link as defined above. For example, upon
+ receipt of a valid NS, Section 7.2.3 of [RFC4861] states:
+
+ If an entry does not already exist, the node SHOULD create a
+ new one and set its reachability state to STALE as specified
+ in Section 7.3.3. If an entry already exists, and the cached
+ link-layer address differs from the one in the received Source
+ Link-Layer option, the cached address should be replaced by
+ the received address, and the entry's reachability state MUST
+ be set to STALE.
+
+
+
+
+Singh, et al. Standards Track [Page 5]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ The intention of the above feature is to add an address to the
+ Neighbor Cache, even though it might not be considered on-link
+ per the Prefix List. The benefit of such a step is to have the
+ receiver populate the Neighbor Cache with an address it will
+ almost certainly be sending packets to shortly, thus avoiding the
+ need for an additional round of ND to perform address resolution.
+ But because there is no validation of the address being added to
+ the Neighbor Cache, an intruder could spoof the address and cause
+ a receiver to add an address for a remote site to its Neighbor
+ Cache. This vulnerability is a specific instance of the broad
+ set of attacks that are possible by an on-link neighbor
+ [RFC3756]. This causes no problems in practice, so long as the
+ entry only exists in the Neighbor Cache and the address is not
+ considered to be on-link by the IP forwarding code (i.e., the
+ address is not added to the Prefix List and is not marked as
+ on-link in the Destination Cache).
+
+ 4. After the update to the on-link definition in [RFC4861], certain
+ text from Section 7.2.3 of [RFC4861] may appear, upon a cursory
+ examination, to be inconsistent with the updated definition of
+ "on-link" because the text does not ensure that the source
+ address is already deemed on-link through other methods:
+
+ If the Source Address is not the unspecified address and, on
+ link layers that have addresses, the solicitation includes a
+ Source Link-Layer Address option, then the recipient SHOULD
+ create or update the Neighbor Cache entry for the IP Source
+ Address of the solicitation.
+
+ Similarly, the following text from Section 6.2.6 of [RFC4861] may
+ also seem inconsistent:
+
+ If there is no existing Neighbor Cache entry for the
+ solicitation's sender, the router creates one, installs the
+ link-layer address and sets its reachability state to STALE as
+ specified in Section 7.3.3.
+
+ However, the text in the aforementioned sections of [RFC4861],
+ upon closer inspection, is actually consistent with the
+ deprecation of the last two bullets of the on-link definition
+ because there are two different ways in which on-link
+ determination can affect the state of ND: through updating the
+ Prefix List or updating the Destination Cache. Through
+ deprecating the last two bullets of the on-link definition, the
+ Prefix List is explicitly not to be changed when a node receives
+ an NS, NA, or Router Solicitation (RS). The Neighbor Cache can
+ still be updated through receipt of an NS, NA, or RS.
+
+
+
+
+Singh, et al. Standards Track [Page 6]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ 5. [RFC4861] is written from the perspective of a host with a single
+ interface on which Neighbor Discovery is run. All ND traffic
+ (whether sent or received) traverses the single interface. On
+ hosts with multiple interfaces, care must be taken to ensure that
+ the scope of ND processing from one link stays local to that
+ link. That is, when responding to an NS, the NA would be sent
+ out on the same link on which it was received. Likewise, a host
+ would not respond to a received NS for an address only assigned
+ to an interface on a different link. Although implementations
+ may choose to implement Neighbor Discovery using a single data
+ structure that merges the Neighbor Caches of all interfaces, an
+ implementation's behavior must be consistent with the above
+ model.
+
+4. Host Rules
+
+ A correctly implemented IPv6 host MUST adhere to the following rules:
+
+ 1. The assignment of an IPv6 address -- whether through IPv6
+ stateless address autoconfiguration [RFC4862], DHCPv6 [RFC3315],
+ or manual configuration -- MUST NOT implicitly cause a prefix
+ derived from that address to be treated as on-link and added to
+ the Prefix List. A host considers a prefix to be on-link only
+ through explicit means, such as those specified in the on-link
+ definition in the Terminology section of [RFC4861] (as modified
+ by this document) or via manual configuration. Note that the
+ requirement for manually configured addresses is not explicitly
+ mentioned in [RFC4861].
+
+ 2. In the absence of other sources of on-link information, including
+ Redirects, if the RA advertises a prefix with the on-link (L) bit
+ set and later the Valid Lifetime expires, the host MUST then
+ consider addresses of the prefix to be off-link, as specified by
+ the PIO paragraph of Section 6.3.4 of [RFC4861].
+
+ 3. In the absence of other sources of on-link information, including
+ Redirects, if the RA advertises a prefix with the on-link (L) bit
+ set and later the Valid Lifetime expires, the host MUST then
+ update its Prefix List with respect to the entry. In most cases,
+ this will result in the addresses covered by the prefix
+ defaulting back to being considered off-link, as specified by the
+ PIO paragraph of Section 6.3.4 of [RFC4861]. However, there are
+ cases where an address could be covered by multiple entries in
+ the Prefix List, where expiration of one prefix would result in
+ destinations then being covered by a different entry.
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 7]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ 4. Implementations compliant with [RFC4861] MUST adhere to the
+ following rules. If the Default Router List is empty and there
+ is no other source of on-link information about any address or
+ prefix:
+
+ a. The host MUST NOT assume that all destinations are on-link.
+
+ b. The host MUST NOT perform address resolution for non-link-
+ local addresses.
+
+ c. Since the host cannot assume the destination is on-link, and
+ off-link traffic cannot be sent to a default router (since
+ the Default Router List is empty), address resolution cannot
+ be performed. This case is specified in the last paragraph
+ of Section 4 of [RFC4943]: when there is no route to the
+ destination, the host should send an ICMPv6 Destination
+ Unreachable indication (for example, a locally delivered
+ error message) as specified in the Terminology section of
+ [RFC4861].
+
+ On-link information concerning particular addresses and prefixes
+ can make those specific addresses and prefixes on-link, but does
+ not change the default behavior mentioned above for addresses and
+ prefixes not specified. [RFC4943] provides justification for
+ these rules.
+
+5. Observed Incorrect Implementation Behavior
+
+ One incorrect implementation behavior illustrates the severe
+ consequences when the IPv6 subnet model is not understood by the
+ implementers of several popular host operating systems. In an access
+ concentrator network ([RFC4388]), a host receives a Router
+ Advertisement message with no on-link prefix advertised. An address
+ could be acquired through the DHCPv6 identity association for non-
+ temporary addresses (IA_NA) option from [RFC3315] (which does not
+ include a prefix length), or through manual configuration (if no
+ prefix length is specified). The host incorrectly assumes an
+ invented prefix is on-link. This invented prefix typically is a /64
+ that was written by the developer of the operating system network
+ module API to any IPv6 application as a "default" prefix length when
+ a length isn't specified. This may cause the API to seem to work in
+ the case of a network interface initiating stateless address
+ autoconfiguration (SLAAC); however, it can cause connectivity
+ problems in Non-Broadcast Multi-Access (NBMA) networks. Having
+ incorrectly assumed an invented prefix, the host performs address
+ resolution when the host should send all non-link-local traffic to a
+
+
+
+
+
+Singh, et al. Standards Track [Page 8]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ default router. Neither the router nor any other host will respond
+ to the address resolution, preventing this host from sending IPv6
+ traffic.
+
+6. Updates to RFC 4861
+
+ This document deprecates the following two bullets from the on-link
+ definition in Section 2.1 of [RFC4861]:
+
+ o a Neighbor Advertisement message is received for the (target)
+ address, or
+
+ o any Neighbor Discovery message is received from the address.
+
+7. Conclusion
+
+ This document clarifies and summarizes the relationship between links
+ and subnet prefixes described in [RFC4861]. Configuration of an IPv6
+ address does not imply the existence of corresponding on-link
+ prefixes. One should also look at API considerations for prefix
+ length as described in the last paragraph of Section 4.2 of
+ [RFC4903]. This document also updates the definition of "on-link"
+ from [RFC4861] by deprecating the last two bullets.
+
+8. Security Considerations
+
+ This document addresses a security concern present in [RFC4861]. As
+ a result, the last two bullets of the on-link definition in [RFC4861]
+ have been deprecated. US-CERT Vulnerability Note VU#472363 lists the
+ implementations affected.
+
+9. Contributors
+
+ Thomas Narten contributed significant text and provided substantial
+ guidance to the production of this document.
+
+10. Acknowledgements
+
+ Thanks (in alphabetical order) to Adeel Ahmed, Jari Arkko, Ralph
+ Droms, Alun Evans, Dave Forster, Prashanth Krishnamurthy, Suresh
+ Krishnan, Josh Littlefield, Bert Manfredi, David Miles, Madhu Sudan,
+ Jinmei Tatuya, Dave Thaler, Bernie Volz, and Vlad Yasevich for their
+ consistent input, ideas, and review during the production of this
+ document. The security problem related to an NS message that
+ provides one reason for invalidating a part of the on-link definition
+ was found by David Miles. Jinmei Tatuya found the security problem
+ to also exist with an RS message.
+
+
+
+
+Singh, et al. Standards Track [Page 9]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+ September 2007.
+
+11.2. Informative References
+
+ [RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting
+ Procedure", STD 5, RFC 950, August 1985.
+
+ [RFC1122] Braden, R., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+ Discovery for IP Version 6 (IPv6)", RFC 2461,
+ December 1998.
+
+ [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
+ and M. Carney, "Dynamic Host Configuration Protocol for
+ IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+ [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
+ Discovery (ND) Trust Models and Threats", RFC 3756,
+ May 2004.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+ [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
+ Protocol (DHCP) Leasequery", RFC 4388, February 2006.
+
+ [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
+ (CIDR): The Internet Address Assignment and Aggregation
+ Plan", BCP 122, RFC 4632, August 2006.
+
+ [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+ Address Autoconfiguration", RFC 4862, September 2007.
+
+ [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
+ June 2007.
+
+
+
+
+
+Singh, et al. Standards Track [Page 10]
+
+RFC 5942 IPv6 Subnet Model July 2010
+
+
+ [RFC4943] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor
+ Discovery On-Link Assumption Considered Harmful",
+ RFC 4943, September 2007.
+
+Authors' Addresses
+
+ Hemant Singh
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ Phone: +1 978 936 1622
+ EMail: shemant@cisco.com
+ URI: http://www.cisco.com/
+
+
+ Wes Beebee
+ Cisco Systems, Inc.
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ Phone: +1 978 936 2030
+ EMail: wbeebee@cisco.com
+ URI: http://www.cisco.com/
+
+ Erik Nordmark
+ Oracle, Inc.
+ 17 Network Circle
+ Menlo Park, CA 94025
+ USA
+
+ Phone: +1 650 786 2921
+ EMail: erik.nordmark@oracle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et al. Standards Track [Page 11]
+