draft-ietf-6man-reserved-iids-01.txt		draft-ietf-6man-reserved-iids-02.txt
	Network Working Group S. Krishnan		Network Working Group S. Krishnan
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track July 14, 2008		Intended status: Standards Track December 2, 2008
	Expires: January 15, 2009		Expires: June 5, 2009
	Reserved IPv6 Interface Identifiers		Reserved IPv6 Interface Identifiers
	draft-ietf-6man-reserved-iids-01		draft-ietf-6man-reserved-iids-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 34		skipping to change at page 1, line 34
	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 January 15, 2009.		This Internet-Draft will expire on June 5, 2009.
	Abstract		Abstract
	Interface Identifiers in IPv6 unicast addresses are used to identify		Interface Identifiers in IPv6 unicast addresses are used to identify
	interfaces on a link. They are required to be unique within a		interfaces on a link. They are required to be unique within a
	subnet. Several RFCs have specified interface identifiers or		subnet. Several RFCs have specified interface identifiers or
	identifier ranges that have a special meaning attached to them. An		identifier ranges that have a special meaning attached to them. An
	IPv6 node autoconfiguring an interface identifier in these ranges		IPv6 node autoconfiguring an interface identifier in these ranges
	will encounter unexpected consequences. Since there is no		will encounter unexpected consequences. Since there is no
	centralized repository for such reserved identifiers, this document		centralized repository for such reserved identifiers, this document
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Issues with reusing reserved Interface Identifiers . . . . . . 5		3. Issues with reusing reserved Interface Identifiers . . . . . . 5
	3.1. Possible solutions . . . . . . . . . . . . . . . . . . . . 5		3.1. Possible solutions . . . . . . . . . . . . . . . . . . . . 5
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 9		7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. List of potentially affected RFCs . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
			Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Requirements notation		1. Requirements notation
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	An IPv6 unicast address is composed of two parts : A subnet prefix		An IPv6 unicast address is composed of two parts : A subnet prefix
	and an interface identifier (IID) that identifies an unique interface		and an interface identifier (IID) that identifies an unique interface
	within the subnet prefix. The structure of an IPv6 unicast address		within the subnet prefix. The structure of an IPv6 unicast address
	is depicted in the IPv6 Addressing Architecture [RFC4291] and is		is depicted in the IPv6 Addressing Architecture [RFC4291] and is
	replicated here for clarity.		replicated here for clarity.
	| n bits | 128-n bits |		| n bits | 128-n bits |
	+------------------------------------------------+----------------+		+-------------------------------+---------------------------------+
	| subnet prefix | interface ID |		| subnet prefix | interface ID |
	+------------------------------------------------+----------------+		+-------------------------------+---------------------------------+
	Figure 1: IPv6 Unicast Address Format		Figure 1: IPv6 Unicast Address Format
	For all unicast addresses, except those that start with binary value		For all unicast addresses, except those that start with the binary
	000, interface identifiers are required to be 64 bits long (i.e.		value 000, Interface IDs are required to be 64 bits long and to be
	n==64) . If the interface identifiers are generated from an unique		constructed in Modified EUI-64 format. If the interface identifiers
	token like an ethernet MAC address, they need to set bit 6 of the		are generated from an unique token like an ethernet MAC address, they
	first octet to one. If they are not generated from an unique token		need to set bit 6 of the first octet to one. If they are not
	they need to set bit 6 to zero. Examples of mechanisms that generate		generated from an unique token they need to set bit 6 to zero.
	interface identifiers without an unique token include		Examples of mechanisms that generate interface identifiers without an
	Cryptographically Generated Addresses [RFC3972], Privacy Addresses		unique token include Cryptographically Generated Addresses [RFC3972],
	[RFC4941], Hash Based Addresses [HBA] etc. Non-unique interface		Privacy Addresses [RFC4941], Hash Based Addresses [HBA] etc. Non-
	identifiers can also be allocated using managed address assignment		unique interface identifiers can also be allocated using managed
	mechanisms like DHCPv6 [RFC3315].		address assignment mechanisms like DHCPv6 [RFC3315].
	3. Issues with reusing reserved Interface Identifiers		3. Issues with reusing reserved Interface Identifiers
	Let us assume a node comes up with an interface identifier that has		Let us assume a node comes up with an interface identifier that has
	been reserved for use in some other capacity. e.g. An IPv6 node that		been reserved for use in some other capacity. e.g. An IPv6 node that
	uses temporary IPv6 addresses [RFC4941] comes up with an IID of fdff:		uses temporary IPv6 addresses [RFC4941] comes up with an IID of fdff:
	ffff:ffff:fff . This node will receive requests from all nodes that		ffff:ffff:fff . This node will receive requests from all nodes that
	are requesting a service from a MobileIPv6 home agent since the above		are requesting a service from a MobileIPv6 home agent since the above
	mentioned interface identifier has been reserved in [RFC2526] to		mentioned interface identifier has been reserved in [RFC2526] to
	serve as a MIPv6 home agents anycast address. At best this is an		serve as a MIPv6 home agents anycast address. At best this is an
	skipping to change at page 5, line 28		skipping to change at page 5, line 28
	configuration or for managed address configuration.		configuration or for managed address configuration.
	3.1. Possible solutions		3.1. Possible solutions
	There are two possible ways to go about avoiding usage of these		There are two possible ways to go about avoiding usage of these
	reserved interface identifiers. One of them would be to add		reserved interface identifiers. One of them would be to add
	normative reference to each specification that reserves an interface		normative reference to each specification that reserves an interface
	identifier. The other one would be to create an IANA registry for		identifier. The other one would be to create an IANA registry for
	such interface identifiers. There are two disadvantages to the		such interface identifiers. There are two disadvantages to the
	normative reference approach. Firstly, this approach does not scale		normative reference approach. Firstly, this approach does not scale
	well. This is because the number of such specifications can need to		well. This is because the number of such specifications that need to
	be updated is large. Secondly, the maturity level of the document		be updated is large. Secondly, the maturity level of the document
	reserving the IID might be lower than the one prohibited from using		reserving the IID might be lower than the one prohibited from using
	it. This will cause a downward reference problem. Therefore the		it. This will cause a downward reference problem. Therefore the
	better solution is to create an IANA registry for this purpose. e.g.		better solution is to create an IANA registry for this purpose.
	Reserving certain identifiers may be useful in certain protocols such
	as PMIP in order to avoid duplicate address detection on point to
	point links, but PMIP will be at a lower standardization level than
	the address sutoconfiguration standards and hence not referable from
	them.
	4. IANA Considerations		4. IANA Considerations
	This document requests the creation of an IANA registry for reserved		This document requests the creation of an IANA registry for reserved
	IPv6 Interface Identifiers. Initial values for the reserved IPv6		IPv6 Interface Identifiers. Initial values for the reserved IPv6
	Interface Identifiers are given below.		Interface Identifiers are given below.
	+-----------------------------------------+-------------------------+		+-----------------------------------------+-------------------------+
	| Interface Identifier Range | Description |		| Interface Identifier Range | Description |
	+-----------------------------------------+-------------------------+		+-----------------------------------------+-------------------------+
	| 0000:0000:0000:0000-0000:0000:0000:0000 | Subnet-Router Anycast |		| 0000:0000:0000:0000-0000:0000:0000:0000 | Subnet-Router Anycast |
	| | [RFC4291] |		| | [RFC4291] |
	| | |		| | |
	| fdff:ffff:ffff:ff80-fdff:ffff:ffff:fffd | Reserved Subnet Anycast |		| FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
	| | [RFC2526] |		| | Addresses[RFC2526] |
	| | |
	| fdff:ffff:ffff:fffe-fdff:ffff:ffff:fffe | MobileIPv6 Home Agents |
	| | Anycast [RFC2526] |
	| | |
	| fdff:ffff:ffff:ffff-fdff:ffff:ffff:ffff | Reserved Subnet Anycast |
	| | [RFC2526] |
	+-----------------------------------------+-------------------------+		+-----------------------------------------+-------------------------+
	Table 1: Current Assignments		Table 1: Current Assignments
	It is possible that implementations might predate a specific		It is possible that implementations might predate a specific
	assignment from this registry and hence not be cognizant of the		assignment from this registry and hence not be cognizant of the
	reserved nature of the interface identifier. Hence. future		reserved nature of the interface identifier. Hence. future
	assignments from this registry are discouraged but in exceptional		assignments from this registry are discouraged but in exceptional
	circumstances are to be made through Standards Action [RFC5226].		circumstances are to be made through Standards Action [RFC5226].
	Assignments consist of a single interface identifier or a range of		Assignments consist of a single interface identifier or a range of
	interface identifiers.		interface identifiers.
	NOTE: Please note that the address ::/128 (all zeros in the interface		NOTE: Please note that the address :: (all zeros in the interface
	identifier field) is used as an unspecified address and ::/0 (again		identifier field) is used as the unspecified address. In addition,
	all zeros in the interface identifier field) is used as a default		many IETF protocols and data formats prescribe that the unused bits
	route indicator as specified in [RFC5156]. These do not necessarily		in prefixes be set to 0. Hence, prefixes with prefix lengths up to
	conflict with the reserved interface identifiers defined here, since		64 are usually stored and transmitted with an interface identifier
	the reserved identifiers defined in this document are used for		part of all zeros. This includes ::/0, used as a default route
	avoiding conflicts with stateless address autoconfiguration that uses		indicator, as specified in [RFC5156]. These uses do not conflict
	a 64 bit prefix length.		with the reserved interface identifiers defined here, since the
			reserved identifiers defined in this document are used for avoiding
			conflicts with stateless address autoconfiguration that utilizes a 64
			bit prefix length.
	5. Acknowledgements		5. Acknowledgements
	The author would like to thank Alain Durand, Alex Petrescu, Bernie		The author would like to thank Alain Durand, Alex Petrescu, Bernie
	Volz, Bob Hinden, Christian Huitema, Fred Templin, Jordi Palet		Volz, Bob Hinden, Christian Huitema, Fred Templin, Jordi Palet
	Martinez, Pekka Savola, Remi Denis-Courmount, Tim Enos, Alex		Martinez, Pekka Savola, Remi Denis-Courmount, Tim Enos, Alex
	Petrescu, Ed Jankiewicz and Brian Carpenter for reviewing this		Petrescu, Ed Jankiewicz, Brian Carpenter, Alfred Hoenes, Jari Arkko,
	document and suggesting changes.		Pasi Eronen, Tim Polk, Lars Eggert, Derek Atkins and Robert Sparks
			for reviewing this document and suggesting changes.
	6. Security Considerations		6. Security Considerations
	Information that creates or updates a registration needs to be		By utilizing one of the reserved interface identifiers, an IPv6 node
	authenticated and authorized. By utilizing one of the reserved		might receive requests that it is not authorized to receive.
	interface identifiers an IPv6 node might receive requests that it is		Information that creates or updates a registration in this registry
	not authorized to receive.		needs to be authenticated and authorized by the IANA based on the
			instructions set forth by [RFC5226].
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast		[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
	Addresses", RFC 2526, March 1999.		Addresses", RFC 2526, March 1999.
	skipping to change at page 9, line 25		skipping to change at page 9, line 25
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	7.2. Informative References		7.2. Informative References
	[HBA] Bagnulo, M., "Hash Based Addresses (HBA)",		[HBA] Bagnulo, M., "Hash Based Addresses (HBA)",
	draft-ietf-shim6-hba-02 (work in progress), October 2006.		draft-ietf-shim6-hba-05 (work in progress), October 2006.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, March 2005.		RFC 3972, March 2005.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, September 2007.		IPv6", RFC 4941, September 2007.
	[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,		[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
	April 2008.		April 2008.
			Appendix A. List of potentially affected RFCs
			The following RFCs that generate interface identifiers need to be
			updated if they wish to avoid conflicts with the reserved interface
			identifier ranges.
			o RFC2590 - Transmission of IPv6 Packets over Frame Relay Networks
			o RFC3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
			o RFC3972 - Cryptographically Generated Addresses (CGA)
			o RFC4489 - A Method for Generating Link-Scoped IPv6 Multicast
			Addresses
			o RFC4862 - IPv6 Stateless Address Autoconfiguration
			o RFC4941 - Privacy Extensions for Stateless Address
			Autoconfiguration in IPv6
			o RFC5072 - IP Version 6 over PPP
			o RFC4982 - Support for Multiple Hash Algorithms in CGAs
	Author's Address		Author's Address
	Suresh Krishnan		Suresh Krishnan
	Ericsson		Ericsson
	8400 Decarie Blvd.		8400 Decarie Blvd.
	Town of Mount Royal, QC		Town of Mount Royal, QC
	Canada		Canada
	Phone: +1 514 345 7900 x42871		Phone: +1 514 345 7900 x42871
	Email: suresh.krishnan@ericsson.com		Email: suresh.krishnan@ericsson.com
End of changes. 15 change blocks.
	49 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/