--- 1/draft-ietf-6man-ipv6-subnet-model-09.txt 2010-03-25 17:10:57.000000000 +0100 +++ 2/draft-ietf-6man-ipv6-subnet-model-10.txt 2010-03-25 17:10:57.000000000 +0100 @@ -1,27 +1,27 @@ Network Working Group H. Singh Internet-Draft W. Beebee Updates: 4861 (if approved) Cisco Systems, Inc. Intended status: Standards Track E. Nordmark -Expires: September 10, 2010 Sun Microsystems - March 9, 2010 +Expires: September 26, 2010 Oracle, Inc. + March 25, 2010 IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes - draft-ietf-6man-ipv6-subnet-model-09 + draft-ietf-6man-ipv6-subnet-model-10 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 + 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 [RFC4861]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering @@ -33,21 +33,21 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on September 10, 2010. + This Internet-Draft will expire on September 26, 2010. 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 @@ -69,29 +69,29 @@ it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9 - 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 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]. 2. Introduction IPv4 implementations typically associate a netmask with an address @@ -105,45 +105,45 @@ 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 [RFC4861] is quite different. The on-link determination is separate from the address assignment. A host can have IPv6 addresses without any - related on-link prefixes or has 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]. + 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., have - not yet timed out, are considered to be on-link by that host. + in the Prefix List. All prefixes on a host's Prefix List (i.e., 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 where 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 Rules section. (Note that [RFC4861] changed the + Behavior and Host Rules sections. (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 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 @@ -358,33 +358,20 @@ 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. Hosts MUST verify that on-link information is still valid after - IPv6 interface re-initialization. Failure to do so may lead to - lack of IPv6 network connectivity. For example, a host receives - an RA from a router with on-link prefix A. The host powers down. - During the power off, the router sends out prefix A with on-link - bit set and a zero lifetime to indicate a renumbering. The host - misses the renumbering. The host powers on and comes online. - Then, the router sends an RA with no PIO. The host uses cached - on-link prefix A and issues NS's instead of sending traffic to a - default router. The "Observed Incorrect Implementation Behavior" - section below describes how this can result in lack of IPv6 - connectivity. - 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. 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 API as a "default" prefix length when a length isn't specified. This @@ -501,17 +488,17 @@ 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 - Sun Microsystems + Oracle, Inc. 17 Network Circle Menlo Park, CA 94025 USA Phone: +1 650 786 2921 Email: erik.nordmark@sun.com