draft-ietf-6man-ipv6-subnet-model-09.txt		draft-ietf-6man-ipv6-subnet-model-10.txt
	Network Working Group H. Singh		Network Working Group H. Singh
	Internet-Draft W. Beebee		Internet-Draft W. Beebee
	Updates: 4861 (if approved) Cisco Systems, Inc.		Updates: 4861 (if approved) Cisco Systems, Inc.
	Intended status: Standards Track E. Nordmark		Intended status: Standards Track E. Nordmark
	Expires: September 10, 2010 Sun Microsystems		Expires: September 26, 2010 Oracle, Inc.
	March 9, 2010		March 25, 2010
	IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes		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		Abstract
	IPv6 specifies a model of a subnet that is different than the IPv4		IPv6 specifies a model of a subnet that is different than the IPv4
	subnet model. The subtlety of the differences has resulted in		subnet model. The subtlety of the differences has resulted in
	incorrect implementations that do not interoperate. This document		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		automatically associated with an IPv6 on-link prefix. This document
	also updates (partially due to security concerns caused by incorrect		also updates (partially due to security concerns caused by incorrect
	implementations) a part of the definition of on-link from [RFC4861].		implementations) a part of the definition of on-link from [RFC4861].
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 1, line 44		skipping to change at page 1, line 44
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		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 Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 12		skipping to change at page 3, line 12
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Host Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9		5. Observed Incorrect Implementation Behavior . . . . . . . . . . 9
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	11.1. Normative References . . . . . . . . . . . . . . . . . . 11		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11.2. Informative References . . . . . . . . . . . . . . . . . 11		11.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Requirements Language		1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Introduction		2. Introduction
	IPv4 implementations typically associate a netmask with an address		IPv4 implementations typically associate a netmask with an address
	skipping to change at page 4, line 31		skipping to change at page 4, line 31
	address's netmask could be derived directly from the address simply		address's netmask could be derived directly from the address simply
	by determining whether it was a Class A, B or C address. Today,		by determining whether it was a Class A, B or C address. Today,
	assigning an address to an interface also requires specifying a		assigning an address to an interface also requires specifying a
	netmask to use. In the absence of specifying a specific netmask when		netmask to use. In the absence of specifying a specific netmask when
	assigning an address, some implementations would fall back to		assigning an address, some implementations would fall back to
	deriving the netmask from the class of the address.		deriving the netmask from the class of the address.
	The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is		The behavior of IPv6 as specified in Neighbor Discovery [RFC4861] is
	quite different. The on-link determination is separate from the		quite different. The on-link determination is separate from the
	address assignment. A host can have IPv6 addresses without any		address assignment. A host can have IPv6 addresses without any
	related on-link prefixes or has on-link prefixes that are not related		related on-link prefixes or can have on-link prefixes that are not
	to any IPv6 addresses that are assigned to the host. Any assigned		related to any IPv6 addresses that are assigned to the host. Any
	address on an interface should initially be considered as having no		assigned address on an interface should initially be considered as
	internal structure as shown in [RFC4291].		having no internal structure as shown in [RFC4291].
	In IPv6, by default, a host treats only the link-local prefix as on-		In IPv6, by default, a host treats only the link-local prefix as on-
	link.		link.
	The reception of a Prefix Information Option (PIO) with the L-bit set		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		[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		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.		not yet timed out) are considered to be on-link by that host.
	The on-link definition in the Terminology section of [RFC4861], as		The on-link definition in the Terminology section of [RFC4861], as
	modified by this document, defines the complete list of cases where a		modified by this document, defines the complete list of cases where a
	host considers an address to be on-link. Individual address entries		host considers an address to be on-link. Individual address entries
	can be expired by the Neighbor Unreachability Detection mechanism.		can be expired by the Neighbor Unreachability Detection mechanism.
	IPv6 packets sent using the Conceptual Sending Algorithm as described		IPv6 packets sent using the Conceptual Sending Algorithm as described
	in [RFC4861] only trigger address resolution for IPv6 addresses that		in [RFC4861] only trigger address resolution for IPv6 addresses that
	the sender considers to be on-link. Packets to any other address are		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		sent to a default router. If there is no default router, then the
	node should send an ICMPv6 Destination Unreachable indication as		node should send an ICMPv6 Destination Unreachable indication as
	specified in [RFC4861] - more details are provided in the Host		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		behavior when the Default Router List is empty. In the old version
	of Neighbor Discovery [RFC2461], if the Default router List is empty,		of Neighbor Discovery [RFC2461], if the Default router List is empty,
	rather than sending the ICMPv6 Destination Unreachable indication,		rather than sending the ICMPv6 Destination Unreachable indication,
	the [RFC2461] node assumed that the destination was on-link.") Note		the [RFC2461] node assumed that the destination was on-link.") Note
	that ND is scoped to a single link. All Neighbor Solicitation		that ND is scoped to a single link. All Neighbor Solicitation
	responses are assumed to be sent out the same interface on which the		responses are assumed to be sent out the same interface on which the
	corresponding query was received without using the Conceptual Sending		corresponding query was received without using the Conceptual Sending
	Algorithm.		Algorithm.
	Failure of host implementations to correctly implement the IPv6		Failure of host implementations to correctly implement the IPv6
	skipping to change at page 10, line 26		skipping to change at page 10, line 26
	Unreachable indication (for example, a locally delivered		Unreachable indication (for example, a locally delivered
	error message) as specified in the Terminology section of		error message) as specified in the Terminology section of
	[RFC4861].		[RFC4861].
	On-link information concerning particular addresses and prefixes		On-link information concerning particular addresses and prefixes
	can make those specific addresses and prefixes on-link, but does		can make those specific addresses and prefixes on-link, but does
	not change the default behavior mentioned above for addresses and		not change the default behavior mentioned above for addresses and
	prefixes not specified. [RFC4943] provides justification for		prefixes not specified. [RFC4943] provides justification for
	these rules.		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		5. Observed Incorrect Implementation Behavior
	One incorrect implementation behavior illustrates the severe		One incorrect implementation behavior illustrates the severe
	consequences when the IPv6 subnet model is not understood by the		consequences when the IPv6 subnet model is not understood by the
	implementers of several popular host operating systems. In an access		implementers of several popular host operating systems. In an access
	concentrator network ([RFC4388]), a host receives a Router		concentrator network ([RFC4388]), a host receives a Router
	Advertisement Message with no on-link prefix advertised. The host		Advertisement Message with no on-link prefix advertised. The host
	incorrectly assumes an invented prefix is on-link. This invented		incorrectly assumes an invented prefix is on-link. This invented
	prefix typically is a /64 that was written by the developer of the		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		API as a "default" prefix length when a length isn't specified. This
	skipping to change at page 13, line 33		skipping to change at page 13, line 28
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Ave.		1414 Massachusetts Ave.
	Boxborough, MA 01719		Boxborough, MA 01719
	USA		USA
	Phone: +1 978 936 2030		Phone: +1 978 936 2030
	Email: wbeebee@cisco.com		Email: wbeebee@cisco.com
	URI: http://www.cisco.com/		URI: http://www.cisco.com/
	Erik Nordmark		Erik Nordmark
	Sun Microsystems		Oracle, Inc.
	17 Network Circle		17 Network Circle
	Menlo Park, CA 94025		Menlo Park, CA 94025
	USA		USA
	Phone: +1 650 786 2921		Phone: +1 650 786 2921
	Email: erik.nordmark@sun.com		Email: erik.nordmark@sun.com
End of changes. 12 change blocks.
	30 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/