draft-ietf-lisp-eid-block-01.txt		draft-ietf-lisp-eid-block-02.txt
	Network Working Group L. Iannone		Network Working Group L. Iannone
	Internet-Draft Telekom Innovation Laboratories		Internet-Draft Telecom ParisTech
	Intended status: Informational D. Lewis		Intended status: Informational D. Lewis
	Expires: May 3, 2012 D. Meyer		Expires: October 26, 2012 D. Meyer
	V. Fuller		V. Fuller
	Cisco Systems, Inc.		Cisco Systems, Inc.
	October 31, 2011		April 24, 2012
	LISP EID Block		LISP EID Block
	draft-ietf-lisp-eid-block-01.txt		draft-ietf-lisp-eid-block-02.txt
	Abstract		Abstract
	This is a direction to IANA to allocate a /16 IPv6 prefix for use		This is a direction to IANA to allocate a /16 IPv6 prefix for use
	with the Locator/ID Separation Protocol (LISP). The prefix will be		with the Locator/ID Separation Protocol (LISP). The prefix will be
	used by sites deploying LISP as EID (Endpoint IDentifier) addressing		used for local intra-domain routing and global endpoint
	space for local intra-domain routing and global endpoint		identification, by sites deploying LISP as EID (Endpoint IDentifier)
	identification.		addressing space.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted 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
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on May 3, 2012.		This Internet-Draft will expire on October 26, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . . 3
	4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5		4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5
	5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6		6. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . . 6
	7. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7		8. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	12.1. Normative References . . . . . . . . . . . . . . . . . . 8		12.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	12.2. Informative References . . . . . . . . . . . . . . . . . 9		12.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9		Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	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
	This document directs the IANA to allocate a /16 IPv6 prefix for use		This document directs the IANA to allocate a /16 IPv6 prefix for use
	skipping to change at page 3, line 31		skipping to change at page 3, line 31
	3. Definition of Terms		3. Definition of Terms
	LISP operates on two name spaces and introduces several new network		LISP operates on two name spaces and introduces several new network
	elements. This section provides high-level definitions of the LISP		elements. This section provides high-level definitions of the LISP
	name spaces and network elements and as such, it MUST NOT be		name spaces and network elements and as such, it MUST NOT be
	considered as an authoritative source. The reference to the		considered as an authoritative source. The reference to the
	authoritative document for each term is included in every term		authoritative document for each term is included in every term
	description.		description.
	Legacy Internet: The portion of the Internet which does not run LISP		Legacy Internet: The portion of the Internet that does not run LISP
	and does not participate in LISP+ALT or any other mapping system.		and does not participate in LISP+ALT or any other mapping system.
	LISP site: A LISP site is a set of routers in an edge network that		LISP site: A LISP site is a set of routers in an edge network that
	are under a single technical administration. LISP routers that		are under a single technical administration. LISP routers that
	reside in the edge network are the demarcation points to separate		reside in the edge network are the demarcation points to separate
	the edge network from the core network. See [I-D.ietf-lisp] for		the edge network from the core network. See [I-D.ietf-lisp] for
	more details.		more details.
	Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for		Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for
	IPv6) value used in the source and destination address fields of		IPv6) value used in the source and destination address fields of
	skipping to change at page 4, line 12		skipping to change at page 4, line 12
	prefix block associated with the site where the host is located.		prefix block associated with the site where the host is located.
	See [I-D.ietf-lisp] for more details.		See [I-D.ietf-lisp] for more details.
	EID-prefix: A power-of-two block of EIDs that are allocated to a		EID-prefix: A power-of-two block of EIDs that are allocated to a
	site by an address allocation authority. See [I-D.ietf-lisp] for		site by an address allocation authority. See [I-D.ietf-lisp] for
	more details.		more details.
	EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable		EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable
	in the [RFC4632] sense. That is, an EID-Prefix aggregate is		in the [RFC4632] sense. That is, an EID-Prefix aggregate is
	defined to be a single contiguous power-of-two EID-prefix block.		defined to be a single contiguous power-of-two EID-prefix block.
	Such a block is characterized by a prefix and a length. See		A prefix and a length characterize such a block. See
	[I-D.ietf-lisp] for more details.		[I-D.ietf-lisp] for more details.
	Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an		Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an
	egress tunnel router (ETR). A RLOC is the output of an EID-to-		egress tunnel router (ETR). A RLOC is the output of an EID-to-
	RLOC mapping lookup. An EID maps to one or more RLOCs.		RLOC mapping lookup. An EID maps to one or more RLOCs.
	Typically, RLOCs are numbered from topologically aggregatable		Typically, RLOCs are numbered from topologically aggregatable
	blocks that are assigned to a site at each point to which it		blocks that are assigned to a site at each point to which it
	attaches to the global Internet; where the topology is defined by		attaches to the global Internet; where the topology is defined by
	the connectivity of provider networks, RLOCs can be thought of as		the connectivity of provider networks, RLOCs can be thought of as
	Provider Aggregatable (PA) addresses. See [I-D.ietf-lisp] for		Provider Aggregatable (PA) addresses. See [I-D.ietf-lisp] for
	skipping to change at page 4, line 36		skipping to change at page 4, line 36
	set that can be used to reach the EID-Prefix. The general term		set that can be used to reach the EID-Prefix. The general term
	"mapping" always refers to an EID-to-RLOC mapping. See		"mapping" always refers to an EID-to-RLOC mapping. See
	[I-D.ietf-lisp] for more details.		[I-D.ietf-lisp] for more details.
	Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a		Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a
	router that accepts receives IP packets from site end-systems on		router that accepts receives IP packets from site end-systems on
	one side and sends LISP-encapsulated IP packets toward the		one side and sends LISP-encapsulated IP packets toward the
	Internet on the other side. The router treats the "inner" IP		Internet on the other side. The router treats the "inner" IP
	destination address as an EID and performs an EID-to-RLOC mapping		destination address as an EID and performs an EID-to-RLOC mapping
	lookup. The router then prepends an "outer" IP header with one of		lookup. The router then prepends an "outer" IP header with one of
	its globally-routable RLOCs in the source address field and the		its globally routable RLOCs in the source address field and the
	result of the mapping lookup in the destination address field.		result of the mapping lookup in the destination address field.
	See [I-D.ietf-lisp] for more details.		See [I-D.ietf-lisp] for more details.
	Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives		Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives
	LISP-encapsulated IP packets from the Internet on one side and		LISP-encapsulated IP packets from the Internet on one side and
	sends decapsulated IP packets to site end-systems on the other		sends decapsulated IP packets to site end-systems on the other
	side. An ETR router accepts an IP packet where the destination		side. An ETR router accepts an IP packet where the destination
	address in the "outer" IP header is one of its own RLOCs. The		address in the "outer" IP header is one of its own RLOCs. The
	router strips the "outer" header and forwards the packet based on		router strips the "outer" header and forwards the packet based on
	the next IP header found. See [I-D.ietf-lisp] for more details.		the next IP header found. See [I-D.ietf-lisp] for more details.
	skipping to change at page 6, line 17		skipping to change at page 6, line 17
	dropped.		dropped.
	By defining an IPv6 EID Block is possible to configure the router so		By defining an IPv6 EID Block is possible to configure the router so
	to natively forward all packets that have not a destination address		to natively forward all packets that have not a destination address
	in the block, without performing any lookup whatsoever. This will		in the block, without performing any lookup whatsoever. This will
	give a tighter control over the traffic in the initial experimental		give a tighter control over the traffic in the initial experimental
	phase, while facilitating its large-scale deployment.		phase, while facilitating its large-scale deployment.
	The EID Block will be used only at configuration level, it is		The EID Block will be used only at configuration level, it is
	RECOMMENDED not to hard-code in any way the IPv6 EID Block in the		RECOMMENDED not to hard-code in any way the IPv6 EID Block in the
	router hardware. This allows to avoid locking out sites that may		router hardware. This allows avoiding locking out sites that may
	want to switch to LISP while keeping their own IPv6 prefix, which is		want to switch to LISP while keeping their own IPv6 prefix, which is
	not in the IPv6 EID Block.		not in the IPv6 EID Block.
	5. Expected use		5. Expected use
	Sites planning to deploy LISP may request a prefix in the IPv6 EID		Sites planning to deploy LISP may request a prefix in the IPv6 EID
	Block. Such prefix will be used for routing and endpoint		Block. Such prefix will be used for routing and endpoint
	identification inside the site requesting it. Mappings related to		identification inside the site requesting it. Mappings related to
	such prefix, or part of it, will be made available through the		such prefix, or part of it, will be made available through the
	mapping system in use or registered to one or more Map-Server(s).		mapping system in use or registered to one or more Map-Server(s).
	Too guarantee reachability from the Legacy Internet the prefix could		Too guarantee reachability from the Legacy Internet the prefix could
	be announced in the BGP routing infrastructure by one or more		be announced in the BGP routing infrastructure by one or more
	PITR(s), possibly as part of a larger prefix, aggregating several		PITR(s), possibly as part of a larger prefix, aggregating several
	prefixes of several sites.		prefixes of several sites.
	6. Block Dimension		6. Block Dimension
	The working group reached consensus on an initial allocation of a /16		The working group reached consensus on an initial allocation of a /16
	prefix out of a /12 block which is asked to remain reserved for		prefix out of a /12 block which is asked to remain reserved for
	future use as EID b space. The reason of such consensus is manifold:		future use as EID space. The reason of such consensus is manifold:
	o A /16 prefix is suffiently large to cover initial allocation and		o A /16 prefix is sufficiently large to cover initial allocation and
	requests for prefoxes in the EID space in the next few years for		requests for prefixes in the EID space in the next few years for
	very large scale experimentation and deployment. As a comparison		very large-scale experimentation and deployment. As a comparison
	is worth to mention that the current LISP Beta Network ([BETA]) is		is worth to mention that the current LISP Beta Network ([BETA]) is
	using a /32 prefix, hence a /16 should be sufficiently large to		using a /32 prefix, hence a /16 should be sufficiently large to
	accomodate growth in the near future.		accommodate growth in the near future.
	o The request to reserve the /12 prefix covering the initial /16
	allocation is in line with IANA policies that fix to /12 the
	minimum IPv6 allocation.
	o The proposed alignment provides as well a natural support for DNS.		o The proposed alignment provides as well a natural support for DNS.
	In particular, reverse DNS for IPv6 in the special ip6.arpa domain		In particular, reverse DNS for IPv6 in the special ip6.arpa domain
	is represented as sequence of nibbles. A different alignment		is represented as sequence of nibbles. A different alignment
	would force to a binary representation.		would force to a binary representation.
	7. Action Plan		7. Action Plan
	This document requests IANA to initially allocate a /16 prefix out of		This document requests IANA to initially allocate a /16 prefix out of
	the IPv6 addressing space for use as EID in LISP (Locator/ID		the IPv6 addressing space for use as EID in LISP (Locator/ID
	skipping to change at page 8, line 12		skipping to change at page 8, line 7
	between the Legacy Internet and LISP sites or even break local intra-		between the Legacy Internet and LISP sites or even break local intra-
	domain connectivity.		domain connectivity.
	9. Security Considerations		9. Security Considerations
	This document does not introduce new security threats in the LISP		This document does not introduce new security threats in the LISP
	architecture nor in the Legacy Internet architecture.		architecture nor in the Legacy Internet architecture.
	10. Acknowledgments		10. Acknowledgments
	Special thanks to Roque Gagliano for his suggestions and pointers to		Special thanks to Roque Gagliano for his suggestions and pointers.
	the IANA allocation policies. Thanks to Marla Azinger, Chris Morrow,		Thanks to Marla Azinger, Chris Morrow, and Peter Schoenmaker, all
	and Peter Schoenmaker, all made insightful comments on early versions		made insightful comments on early versions of this draft.
	of this draft.
	11. IANA Considerations		11. IANA Considerations
	This document instructs the IANA to assign a /16 IPv6 prefix for use		This document instructs the IANA to assign a /16 IPv6 prefix for use
	as the global LISP EID space using an hierarchical allocation as		as the global LISP EID space using a hierarchical allocation as
	outlined in [RFC2434]. During the discussion related to this		outlined in [RFC5226]. During the discussion related to this
	document, the LISP Working Group agreed in suggesting to IANA to		document, the LISP Working Group agreed in suggesting to IANA to
	reserve adjacent addressing space for future use as EID space if		reserve adjacent addressing space for future use as EID space if
	needs come. Following the policies outlined in [RFC2434], such space		needs come. Following the policies outlined in [RFC5226], such space
	will be assigned only upon IETF Consensus. This document does not		will be assigned only upon IETF Consensus. This document does not
	specify any specific value for the requested address block.		specify any specific value for the requested address block.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-lisp]		[I-D.ietf-lisp]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-15 (work in progress), July 2011.		draft-ietf-lisp-22 (work in progress), February 2012.
	[I-D.ietf-lisp-alt]		[I-D.ietf-lisp-alt]
	Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP		Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
	Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06		Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10
	(work in progress), March 2011.		(work in progress), December 2011.
	[I-D.ietf-lisp-interworking]		[I-D.ietf-lisp-interworking]
	Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking LISP with IPv4 and IPv6",		"Interworking LISP with IPv4 and IPv6",
	draft-ietf-lisp-interworking-02 (work in progress),		draft-ietf-lisp-interworking-06 (work in progress),
	June 2011.		March 2012.
	[I-D.ietf-lisp-ms]		[I-D.ietf-lisp-ms]
	Fuller, V. and D. Farinacci, "LISP Map Server Interface",		Fuller, V. and D. Farinacci, "LISP Map Server Interface",
	draft-ietf-lisp-ms-12 (work in progress), October 2011.		draft-ietf-lisp-ms-16 (work in progress), March 2012.
	[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.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 2006.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	12.2. Informative References		12.2. Informative References
	[BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011.		[BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011.
	Appendix A. Document Change Log		Appendix A. Document Change Log
			Version 02 Posted April 2012.
			o Fixed typos, nits, references.
			o Deleted reference to IANA allocation policies.
	Version 01 Posted October 2011.		Version 01 Posted October 2011.
	o Added Section 6.		o Added Section 6.
	Version 00 Posted July 2011.		Version 00 Posted July 2011.
	o Updated section "IANA Considerations"		o Updated section "IANA Considerations"
	o Added section "Rationale and Intent" explaining why the EID block		o Added section "Rationale and Intent" explaining why the EID block
	allocation is useful.		allocation is useful.
	skipping to change at page 10, line 8		skipping to change at page 10, line 8
	o Added section "Routing Consideration" describing how routers not		o Added section "Routing Consideration" describing how routers not
	running LISP deal with the requested address block.		running LISP deal with the requested address block.
	o Added the present section to keep track of changes.		o Added the present section to keep track of changes.
	o Rename of draft-meyer-lisp-eid-block-02.txt.		o Rename of draft-meyer-lisp-eid-block-02.txt.
	Authors' Addresses		Authors' Addresses
	Luigi Iannone		Luigi Iannone
	Telekom Innovation Laboratories		Telecom ParisTech
	Email: luigi@net.t-labs.tu-berlin.de		Email: ggx@gigix.net
	Darrel Lewis		Darrel Lewis
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: darlewis@cisco.com		Email: darlewis@cisco.com
	David Meyer		David Meyer
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: dmm@cisco.com		Email: dmm@cisco.com
End of changes. 27 change blocks.
	57 lines changed or deleted		58 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/