rfc7954v2.txt		rfc7954.txt
	Internet Engineering Task Force (IETF) L. Iannone		Internet Engineering Task Force (IETF) L. Iannone
	Request for Comments: 7954 Telecom ParisTech		Request for Comments: 7954 Telecom ParisTech
	Category: Experimental D. Lewis		Category: Experimental D. Lewis
	ISSN: 2070-1721 Cisco Systems, Inc.		ISSN: 2070-1721 Cisco Systems, Inc.
	D. Meyer		D. Meyer
	Brocade		Brocade
	V. Fuller		V. Fuller
	August 2016		September 2016
	Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block		Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
	Abstract		Abstract
	This document directs IANA to allocate a /32 IPv6 prefix for use with		This document directs IANA to allocate a /32 IPv6 prefix for use with
	the Locator/ID Separation Protocol (LISP). The prefix will be used		the Locator/ID Separation Protocol (LISP). The prefix will be used
	for local intra-domain routing and global endpoint identification, by		for local intra-domain routing and global endpoint identification, by
	sites deploying LISP as Endpoint Identifier (EID) addressing space.		sites deploying LISP as Endpoint Identifier (EID) addressing space.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	This document is not an Internet Standards Track specification; it is		This document is not an Internet Standards Track specification; it is
	published for examination, experimental implementation, and		published for examination, experimental implementation, and
	evaluation.		evaluation.
	This document defines an Experimental Protocol for the Internet		This document defines an Experimental Protocol for the Internet
	community. This document is a product of the Internet Engineering		community. This document is a product of the Internet Engineering
	Task Force (IETF). It represents the consensus of the IETF		Task Force (IETF). It represents the consensus of the IETF
	community. It has received public review and has been approved for		community. It has received public review and has been approved for
	publication by the Internet Engineering Steering Group (IESG). Not		publication by the Internet Engineering Steering Group (IESG). Not
	all documents approved by the IESG are a candidate for any level of		all documents approved by the IESG are a candidate for any level of
	Internet Standard; see Section 2 of RFC 5741.		Internet Standard; see Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	http://www.rfc-editor.org/info/rfc7954.		http://www.rfc-editor.org/info/rfc7954.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	skipping to change at page 2, line 10		skipping to change at page 2, line 22
	(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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 2		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . 2		3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . 3
	4. Expected Use . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Expected Use . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5		5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5
	6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 5		6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6
	7. Allocation Lifetime . . . . . . . . . . . . . . . . . . . . . 6		7. Allocation Lifetime . . . . . . . . . . . . . . . . . . . . . 7
	8. Routing Considerations . . . . . . . . . . . . . . . . . . . 6		8. Routing Considerations . . . . . . . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 7		9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 10
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	This document directs the IANA to allocate a /32 IPv6 prefix for use		This document directs the IANA to allocate a /32 IPv6 prefix for use
	with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map-		with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map-
	Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836])		Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836])
	(or other) mapping systems, and LISP Interworking ([RFC6832]).		(or other) mapping systems, and LISP Interworking ([RFC6832]).
	This block will be used as global Endpoint Identifier (EID) space.		This block will be used as global Endpoint Identifier (EID) space.
	skipping to change at page 5, line 41		skipping to change at page 6, line 24
	but may as well boost LISP experimentation and deployment.		but may as well boost LISP experimentation and deployment.
	o The use of a /32 prefix is in line with previous similar prefix		o The use of a /32 prefix is in line with previous similar prefix
	allocation for tunneling protocols ([RFC3056]).		allocation for tunneling protocols ([RFC3056]).
	6. 3+3 Allocation Plan		6. 3+3 Allocation Plan
	Per this document, IANA has initially assigned a /32 prefix out of		Per this document, IANA has initially assigned a /32 prefix out of
	the IPv6 addressing space for use as EID in LISP.		the IPv6 addressing space for use as EID in LISP.
	IANA allocated the requested address space in August 2016 for a		IANA allocated the requested address space in September 2016 for a
	duration of 3 (three) years (through August 2019), with an option to		duration of 3 (three) years (through September 2019), with an option
	extend this period by 3 (three) more years (until August 2022). By		to extend this period by 3 (three) more years (until September 2022).
	the end of the first period, the IETF will provide a decision on		By the end of the first period, the IETF will provide a decision on
	whether to transform the prefix into a permanent assignment or to put		whether to transform the prefix into a permanent assignment or to put
	it back in the free pool (see Section 7 for more information).		it back in the free pool (see Section 7 for more information).
	In the first case, i.e., if the IETF decides to transform the block		In the first case, i.e., if the IETF decides to transform the block
	into a permanent allocation, the EID block allocation period will be		into a permanent allocation, the EID block allocation period will be
	extended for three years (until August 2022) to give the IETF time to		extended for three years (until September 2022) to give the IETF time
	define the final size of the EID block and create a transition plan.		to define the final size of the EID block and create a transition
			plan. The transition of the EID block into a permanent allocation
	The transition of the EID block into a permanent allocation might		might pose policy issues (as recognized in [RFC2860], Section 4.3);
	pose policy issues (as recognized in [RFC2860], Section 4.3);
	therefore, discussion with the IANA, the RIR communities, and the		therefore, discussion with the IANA, the RIR communities, and the
	IETF community will be necessary to determine the appropriate policy		IETF community will be necessary to determine the appropriate policy
	for permanent EID-block allocation and management. Note as well that		for permanent EID-block allocation and management. Note as well that
	the final permanent allocation may differ from the initial		the final permanent allocation may differ from the initial
	experimental assignment; hence, it is recommended not to hard-code		experimental assignment; hence, it is recommended not to hard-code
	the experimental EID block on LISP-capable devices in any way.		the experimental EID block on LISP-capable devices in any way.
	In the latter case, i.e., if the IETF decides to terminate the		In the latter case, i.e., if the IETF decides to terminate the
	experimental-use EID block, all temporary prefix allocations in this		experimental-use EID block, all temporary prefix allocations in this
	address range must expire and be released by August 2019, so that the		address range must expire and be released by September 2019, so that
	entire /32 is returned to the free pool.		the entire /32 is returned to the free pool.
	The allocation and management of the EID block for the initial 3-year		The allocation and management of the EID block for the initial 3-year
	period (and the optional 3 more years) is detailed in [RFC7955].		period (and the optional 3 more years) is detailed in [RFC7955].
	7. Allocation Lifetime		7. Allocation Lifetime
	If no explicit action is carried out by the end of the experiment (by		If no explicit action is carried out by the end of the experiment (by
	August 2019), it is automatically considered that there was not		September 2019), it is automatically considered that there was not
	sufficient interest in having a permanent allocation; therefore, the		sufficient interest in having a permanent allocation; therefore, the
	address block will be returned to the free pool.		address block will be returned to the free pool.
	Otherwise, if the LISP working group recognizes that there is value		Otherwise, if the LISP working group recognizes that there is value
	in having a permanent allocation, then explicit action is needed.		in having a permanent allocation, then explicit action is needed.
	In order to trigger the process for a permanent allocation, a		In order to trigger the process for a permanent allocation, a
	document is required. Such a document has to articulate the		document is required. Such a document has to articulate the
	rationale for why a permanent allocation would be beneficial. More		rationale for why a permanent allocation would be beneficial. More
	specifically, the document has to detail the experience gained during		specifically, the document has to detail the experience gained during
	skipping to change at page 8, line 12		skipping to change at page 8, line 28
	[RFC6491]), because the global EID space is be used for routing		[RFC6491]), because the global EID space is be used for routing
	purposes.		purposes.
	+----------------------+--------------------+		+----------------------+--------------------+
	| Attribute | Value |		| Attribute | Value |
	+----------------------+--------------------+		+----------------------+--------------------+
	| Address Block | 2001:5::/32 |		| Address Block | 2001:5::/32 |
	| Name | EID Space for LISP |		| Name | EID Space for LISP |
	| RFC | RFC 7954 |		| RFC | RFC 7954 |
	| Allocation Date | 2015 |		| Allocation Date | 2015 |
	| Termination Date | August 2019 [1] |		| Termination Date | September 2019 [1] |
	| Source | True [2] |		| Source | True [2] |
	| Destination | True |		| Destination | True |
	| Forwardable | True |		| Forwardable | True |
	| Global | True |		| Global | True |
	| Reserved-by-protocol | True [3] |		| Reserved-by-protocol | True [3] |
	+----------------------+--------------------+		+----------------------+--------------------+
	[1] According to the 3+3 Plan outlined in this document, the		[1] According to the 3+3 Plan outlined in this document, the
	termination date can be postponed to August 2022. [2] Can be used as		termination date can be postponed to September 2022.
	a multicast source as well. [3] To be used as EID space by routers		[2] Can be used as a multicast source as well.
	enabled by LISP [RFC6830].		[3] To be used as EID space by routers enabled by LISP [RFC6830].
	Table 1: Global EID Space		Table 1: Global EID Space
	The reserved address space is requested for an initial 3-year period		The reserved address space is requested for an initial 3-year period
	starting in August 2016 (until August 2019), with an option to extend		starting in September 2016 (until September 2019), with an option to
	it by three years (until August 2022) upon the decision of the IETF		extend it by three years (until September 2022) upon the decision of
	(see Sections 6 and 7). Following the policies outlined in		the IETF (see Sections 6 and 7). Following the policies outlined in
	[RFC5226], upon IETF Review, the decision should be made on whether		[RFC5226], upon IETF Review, the decision should be made on whether
	to have a permanent EID block assignment by August 2019. If no		to have a permanent EID block assignment by September 2019. If no
	explicit action is taken or, if the IETF Review outcome is that it is		explicit action is taken or, if the IETF Review outcome is that it is
	not worth having a reserved prefix as a global EID space, the whole		not worth having a reserved prefix as a global EID space, the whole
	/32 will be taken out from the "IANA IPv6 Special-Purpose Address		/32 will be taken out from the "IANA IPv6 Special-Purpose Address
	Registry" and put back in the free pool managed by IANA.		Registry" and put back in the free pool managed by IANA.
	Allocation and management of the global EID space is detailed in		Allocation and management of the global EID space is detailed in
	[RFC7955]. Nevertheless, all prefix allocations out of this space		[RFC7955]. Nevertheless, all prefix allocations out of this space
	must be temporary and no allocation must go beyond August 2019 unless		must be temporary and no allocation must go beyond September 2019
	the IETF Review decides for a permanent global EID space assignment.		unless the IETF Review decides for a permanent global EID space
			assignment.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of		[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
	Understanding Concerning the Technical Work of the		Understanding Concerning the Technical Work of the
	Internet Assigned Numbers Authority", RFC 2860,		Internet Assigned Numbers Authority", RFC 2860,
	DOI 10.17487/RFC2860, June 2000,		DOI 10.17487/RFC2860, June 2000,
	<http://www.rfc-editor.org/info/rfc2860>.		<http://www.rfc-editor.org/info/rfc2860>.
	skipping to change at page 10, line 13		skipping to change at page 10, line 28
	January 2013, <http://www.rfc-editor.org/info/rfc6836>.		January 2013, <http://www.rfc-editor.org/info/rfc6836>.
	[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to		[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
	Routing Locator (RLOC) Database", RFC 6837,		Routing Locator (RLOC) Database", RFC 6837,
	DOI 10.17487/RFC6837, January 2013,		DOI 10.17487/RFC6837, January 2013,
	<http://www.rfc-editor.org/info/rfc6837>.		<http://www.rfc-editor.org/info/rfc6837>.
	[RFC7955] Iannone, L., Jorgensen, R., Conrad, D., and G. Huston,		[RFC7955] Iannone, L., Jorgensen, R., Conrad, D., and G. Huston,
	"Locator/ID Separation Protocol (LISP) Endpoint Identifier		"Locator/ID Separation Protocol (LISP) Endpoint Identifier
	(EID) Block Management Guidelines", RFC 7955,		(EID) Block Management Guidelines", RFC 7955,
	DOI 10.17487/RFC7955, August 2016,		DOI 10.17487/RFC7955, September 2016,
	<http://www.rfc-editor.org/info/rfc7955>.		<http://www.rfc-editor.org/info/rfc7955>.
	11.2. Informative References		11.2. Informative References
	[BETA] LISP Beta Network, "Locator/ID Separation Protocol",		[BETA] LISP Beta Network, "Locator/ID Separation Protocol",
	<http://www.lisp4.net>.		<http://www.lisp4.net>.
	[FIABook2010]		[FIABook2010]
	Iannone, L. and T. Leva, "Modeling the economics of Loc/ID		Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
	Separation for the Future Internet", Towards the Future		Separation for the Future Internet", Towards the Future
	skipping to change at page 11, line 22		skipping to change at page 11, line 39
	Special thanks to Roque Gagliano for his suggestions and pointers.		Special thanks to Roque Gagliano for his suggestions and pointers.
	Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez,		Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez,
	David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston,		David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston,
	Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger		Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger
	Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job		Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job
	Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for		Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for
	their insightful comments. Thanks as well to all participants for		their insightful comments. Thanks as well to all participants for
	the fruitful discussions on the IETF mailing list.		the fruitful discussions on the IETF mailing list.
	The work of Luigi Iannone has been partially supported by the ANR-		The work of Luigi Iannone has been partially supported by the
	13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC ICT-		ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC
	Labs SOFNETS Project.		ICT-Labs SOFNETS Project.
	Authors' Addresses		Authors' Addresses
	Luigi Iannone		Luigi Iannone
	Telecom ParisTech		Telecom ParisTech
	Email: ggx@gigix.net		Email: ggx@gigix.net
	Darrel Lewis		Darrel Lewis
	Cisco Systems, Inc.		Cisco Systems, Inc.
End of changes. 17 change blocks.
	42 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/