draft-ietf-lisp-eid-block-mgmnt-02.txt		draft-ietf-lisp-eid-block-mgmnt-03.txt
	Network Working Group L. Iannone		Network Working Group L. Iannone
	Internet-Draft Telecom ParisTech		Internet-Draft Telecom ParisTech
	Intended status: Informational R. Jorgensen		Intended status: Informational R. Jorgensen
	Expires: January 2, 2015 Bredbandsfylket Troms		Expires: April 27, 2015 Bredbandsfylket Troms
	D. Conrad		D. Conrad
	Virtualized, LLC		Virtualized, LLC
	July 1, 2014		G. Huston
			APNIC - Asia Pacific Network Information Center
			October 24, 2014
	LISP EID Block Management Guidelines		LISP EID Block Management Guidelines
	draft-ietf-lisp-eid-block-mgmnt-02.txt		draft-ietf-lisp-eid-block-mgmnt-03.txt
	Abstract		Abstract
	This document proposes an allocation framework for the management of		This document proposes a framework for the management of the LISP EID
	the LISP EID address prefix. The framework described relies on		Prefix. The framework described relies on hierarchical distribution
	hierarchical distribution of the address space with sub-prefixes		of the address space, granting temporary usage of sub-prefixes of
	allocated on a temporary basis to requesting organizations.		such space to requesting organizations.
	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 January 2, 2015.		This Internet-Draft will expire on April 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3		4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3
	5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5		5. EID Prefixes Registration Requirements . . . . . . . . . . . 4
	6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5		6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4
	7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 7		7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 7		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	11.1. Normative References . . . . . . . . . . . . . . . . . . 8		11.1. Normative References . . . . . . . . . . . . . . . . . . 7
	11.2. Informative References . . . . . . . . . . . . . . . . . 9		11.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 8
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12		Appendix B. Document Change Log . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	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
	The Locator/ID Separation Protocol (LISP - [RFC6830]) and related		The Locator/ID Separation Protocol (LISP - [RFC6830]) and related
	mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835],		mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835],
	[RFC6836], [RFC6837]) separates the IP addressing space into two		[RFC6836], [RFC6837]) separates the IP addressing space into two
	logical spaces, the End-point IDentifier (EID) space and the Routing		logical spaces, the End-point IDentifier (EID) space and the Routing
	LOCator (RLOC) space. The first space is used to identify		LOCator (RLOC) space. The first space is used to identify
	communication end-points, while the second is used to locate EIDs in		communication end-points, while the second is used to locate EIDs in
	the Internet routing infrastructure topology.		the Internet routing infrastructure topology.
	The document [I-D.ietf-lisp-eid-block] requested an IPv6 address		The document [I-D.ietf-lisp-eid-block] requested an IPv6 address
	block reservation exclusively for the allocation and assignment of		block reservation exclusively for use as EID prefixes in the LISP
	EID prefixes. The rationale, intent, size, and usage of the EID		experiment. The rationale, intent, size, and usage of the EID
	address block are described in [I-D.ietf-lisp-eid-block].		address block are described in [I-D.ietf-lisp-eid-block].
	This document proposes a management framework for the allocation and		This document proposes a management framework for the registration of
	assignment of EID addresses from that block based on temporary		EID prefixes from that block, allowing the requesting organisation
	allocation of portions of the block to different requesting		exclusive use of those EID prefixes limited to the duration of the
	organizations.		LISP experiment.
	3. Definition of Terms		3. Definition of Terms
	This document does not introduce any new terms related to the set of		This document does not introduce any new terms related to the set of
	LISP Specifications ( [RFC6830], [RFC6831], [RFC6832], [RFC6833],		LISP Specifications ( [RFC6830], [RFC6831], [RFC6832], [RFC6833],
	[RFC6834], [RFC6835], [RFC6836], [RFC6837]). To help the reading of		[RFC6834], [RFC6835], [RFC6836], [RFC6837]). To help the reading of
	this document the terminology introduced by LISP is summarized in		this document the terminology introduced by LISP is summarized in
	Appendix A.		Appendix A.
	4. EID Prefix Allocation Policy		4. EID Prefix Registration Policy
	The allocation of EID prefixes MUST be done under the following		The request registration of EID prefixes MUST be done under the
	policies:		following policies:
	1. EID addressing prefixes are made available in the reserved space		1. EID prefixes are made available in the reserved space on a
	on a temporary basis and for experimental uses. The requester of		temporary basis and for experimental uses. The requester of an
	an experimental prefix MUST provide a short description of the		experimental prefix MUST provide a short description of the
	intended use or experiment that will be carried out (see		intended use or experiment that will be carried out (see
	Section 6). If the prefix will be used for activities not		Section 6). If the prefix will be used for activities not
	documented in the original description, the renewal of the		documented in the original description, the renewal of the
	allocation may be denied or withdrawn (see Section 5).		registration may be denied.
	2. EID prefixes are allocated on a lease/license basis for a limited
	period of time (which can be renewed). The lease/license period
	SHOULD NOT be longer than one year in order to ensure the leases
	and registration information about those leases is kept
	reasonably up to date.
	3. Exception to the previous rule may be granted in cases in which
	the prefix has been delegated to an organization that will act as
	a registry for further sub-allocations. Sub-allocations MUST
	abide by these policies as well as the allocation requirements
	outlined in Section 5. Requests for a prefix delegation that
	will be used for further sub-allocations MUST clearly state such
	intent in the short description of the intended use document.
	4. All of the allocations (renewed or not, including delegations and
	sub-allocations) MUST be returned by 31 December 2017, in
	accordance with the 3+3 years experimental allocation plan
	outlined in [I-D.ietf-lisp-eid-block].
	5. Upon IETF review before 31 December 2017, the EID prefix space
	may become a permanent allocation. In this case existing
	allocations CAN be renewed and new allocations granted (still on
	a yearly temporary basis). All allocations (renewed or not,
	including delegations and sub-allocations) MUST be returned by 31
	December 2020, in accordance to the 3+3 years plan outlined in
	[I-D.ietf-lisp-eid-block]. During the second 3 years phase of
	the experiment, following the policies outlined in [RFC5226], the
	IETF will decide the final EID prefix block size and elaborate
	the allocation and management policies that will be applied
	starting 1 January 2021.
	6. When an allocation is freed because of non-renewal or the
	termination of an experiment, the address space is returned to
	the global pool of free EID prefixes. This freed allocation MUST
	NOT be announced through registration on Map Servers in the LISP
	mapping system for at least 72 hours to ensure expiration of all
	cached map entries in the global LISP infrastructure.
	7. The EID prefix of an allocation that is not renewed (or whose		2. EID prefix registrations SHOULD be renewed on a regular basis to
	renewal has been denied) can be re-used after no less than one		ensure their use by active participants in the experiment. The
	week from the date when the EID prefix is freed. This delay will		registration period is proposed to be 12 months. Registration
	provide sufficient time for all cached map entries in the global		renewal SHOULD NOT cause a change in the registered EID prefix.
	LISP infrastructure to expire and will allow any management		The conditions of registration renewal should no different to the
	process for re-allocation to be dealt with.		conditions of registration.
	8. EID prefix allocations can be revoked as a result of abuse,		3. When an EID prefix registration is removed from the registry,
	unjustified usage (e.g., not conforming the intended use provided		then the reuse of the EID prefix in a subsequent registration on
	at request time), failure to pay maintenance fees, legal court		behalf of a different end user should be avoided where possible.
	orders, etc. Withdrawal can be enforced by filtering on Map		If the considerations of overall usage of the EID block prefix
	Servers so to prevent map registration.		requires reuse of a previously registered EID prefix, then a
			minimum delay of at least one week between removal and subsequent
			registration SHOULD be applied by the registry operator.
	5. EID Prefixes Allocation Requirements		4. All registrations of EID prefixes cease at the time of the
			expiration of the reserved experimental LISP EID Block. The
			further disposition of these prefixes and the associated registry
			entries is to be specified in the announcement of the cessation
			of this experiment.
	All EID prefix allocations (and delegations) MUST respect the		5. EID Prefixes Registration Requirements
	following requirements:
	1. Allocations MUST be globally unique.		All EID prefix registrations MUST respect the following requirements:
	2. Requirements for allocation MUST be the same globally. No		1. All EID prefix registrations MUST use a globally unique EID
	regional/national/local variations are permitted.		prefix.
	3. The registration information MUST be maintained and made publicly		2. If there is more than one registry operator, all operators MUST
	available through a searchable interface, preferably RDAP		use the same registry management policies and practices.
	([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or
	similar access methods.
	4. The registration information service should be reasonably		3. The EID Prefix registration information as specified in
	reliable so to make such information readily available. The		Section 6, MUST be collected upon initial registration and
	allocation service SHOULD be provided during regular business		renewal, and made publicly available though interfaces allowing
	hours in venue in which the allocation service is housed.		both retrieval of specific registration details (search) and
			enumeration of the entire registry contents (e.g.,
			[I-D.ietf-weirds-rdap-sec], whois, http, or similar access
			methods).
	5. Facilities SHOULD exist to allow for the delegation of the		4. The registry operator MUST permit the delegation of EID prefixes
	reverse DNS for EID address prefixes. Reverse DNS delegation is		in the reverse DNS space to holders of registered EID prefixes.
	not required, and may not be provided from the beginning of the
	use of the EID Block. However it may be made available on a
	later stage if operational requirements necessitate it or IETF
	decides it should be available.
	6. Anyone, private persons, companies, or other entities can request		5. Anyone can obtain an entry in the EID prefix registry, on the
	EID space and those requests MUST be granted, provided that they		understanding that the prefix so registered is for the exclusive
	can show a clear intent in carrying out LISP experimentation.		use in the LISP experimental network, and that their registration
			details (as specified in Section 6) are openly published in the
			EID prefix registry.
	6. EID Prefix Request Template		6. EID Prefix Request Template
	The following is a basic request template for prefix allocation (and		The following is a basic request template for prefix registration so
	delegation) so to ensure a uniform process. Such a template is		to ensure a uniform process. Such a template is inspired by the IANA
	inspired by the IANA Private Enterprise Number online request form		Private Enterprise Number online request form
	(http://pen.iana.org/pen/PenApplication.page).		(http://pen.iana.org/pen/PenApplication.page).
			Note that all details in this registration become part of the
			registry, and will be published in the LISP EID Prefix Registry.
	The EID Prefix Request template MUST at minimum contain:		The EID Prefix Request template MUST at minimum contain:
	1. Organization (In case of individuals requesting an EID prefix		1. Organization (In case of individuals requesting an EID prefix
	this section can be left empty)		this section can be left empty)
	(a) Organization Name		(a) Organization Name
	(b) Organization Address		(b) Organization Address
	(c) Organization Phone		(c) Organization Phone
	skipping to change at page 6, line 34		skipping to change at page 5, line 25
	(e) Email		(e) Email
	3. EID Prefix Request (Mandatory)		3. EID Prefix Request (Mandatory)
	(a) Prefix Size		(a) Prefix Size
	(b) Prefix Size Rationale		(b) Prefix Size Rationale
	(c) Lease Period		(c) Lease Period
	+ Start Date		+ Note Well: All EID Prefix registrations will be valid until
			the earlier date of 12 months from the date of registration
			or 31 December 2017.
	+ End Date		+ All registrations may be renewed by the applicant for
			further 12 month periods, ending on 31 December 2017.
	Note that according to the 3+3 year allocation plan, defined		+ According to the 3+3 year experimentation plan, defined in
	in [I-D.ietf-lisp-eid-block], all allocations (and		[I-D.ietf-lisp-eid-block], all registrations MUST end by 31
	delegations) MUST end by 31 December 2017, unless the IETF		December 2017, unless the IETF community decides to grant a
	community decides to grant a permanent LISP EID address		permanent LISP EID address block. In the latter case,
	block. In the latter case, allocations (and delegations)		registrations following the present document policy MUST end
	following the present document policy MUST end by 31		by 31 December 2020 and a new policy (to be decided - see
	December 2020 and a new policy (to be decided see Section 7)		Section 7) will apply starting 1 January 2021.
	will apply starting 1 January 2021.
	4. Experiment Description		4. Experiment Description
	(a) Experiment and Deployment Description		(a) Experiment and Deployment Description
	(b) Interoperability with existing LISP deployments		(b) Interoperability with existing LISP deployments
	(c) Interoperability with Legacy Internet		(c) Interoperability with Legacy Internet
	5. Reverse DNS Servers (Optional)		5. Reverse DNS Servers (Optional)
	(a) Name server name:		(a) Name server name:
	(b) Name server address:		(b) Name server address:
	skipping to change at page 7, line 22		skipping to change at page 6, line 13
	(b) Name server address:		(b) Name server address:
	(c) Name server name:		(c) Name server name:
	(d) Name server address:		(d) Name server address:
	(Repeat if necessary)		(Repeat if necessary)
	7. Policy Validity Period		7. Policy Validity Period
	Policy outlined in the present document is tight to the existence of		Policy outlined in the present document is tied to the existence of
	the experimental LISP EID block requested in		the experimental LISP EID block requested in
	[I-D.ietf-lisp-eid-block] and valid until 31 December 2017.		[I-D.ietf-lisp-eid-block] and valid until 31 December 2017.
	If the IETF decides to transform the block in a permanent allocation,		If the IETF decides to transform the block in a permanent allocation,
	the LISP EID block allocation period will be extended for three years		the LISP EID block reserved usage period will be extended for three
	(until 31 December 2020) so to give time to the IETF to define the		years (until 31 December 2020) so to give time to the IETF to define,
	final size of the EID block and create a transition plan, while the		following the policies outlined in [RFC5226], the final size of the
	policy in the present document will still apply.		EID block and create a transition plan, while the policy in the
			present document will still apply.
	Note that, as stated in [I-D.ietf-lisp-eid-block], the transition of		Note that, as stated in [I-D.ietf-lisp-eid-block], the transition of
	the EID block into a permanent allocation has the potential to pose		the EID block into a permanent allocation, has the potential to pose
	policy issues (as recognized in [RFC2860], section 4.3) and hence		policy issues (as recognized in [RFC2860], section 4.3) and hence
	discussion with the IANA, the RIR communities, and the IETF community		discussion with the IANA, the RIR communities, and the IETF community
	will be necessary to determine appropriate policy for permanent EID		will be necessary to determine appropriate policy for permanent EID
	prefix allocation and management, which will be effective starting 1		prefix management, which will be effective starting 1 January 2021.
	January 2021.
	8. Security Considerations		8. 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.
	For accountability reasons, and in line with the security		For accountability reasons, and in line with the security
	considerations in [RFC7020], each allocation request MUST contain		considerations in [RFC7020], each registration request MUST contain
	accurate information on the requesting entity (company, institution,		accurate information on the requesting entity (company, institution,
	individual, etc.) and valid and accurate contact information of a		individual, etc.) and valid and accurate contact information of a
	referral person (see Section 6).		referral person (see Section 6).
	9. Acknowledgments		9. Acknowledgments
	Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis,		Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D.
	D. Farinacci, for their helpful comments.		Lewis, D. Farinacci, M. Binderberger, for their helpful comments.
	The work of Luigi Iannone has been partially supported by the ANR-13-		The work of Luigi Iannone has been partially supported by the ANR-
	INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-		13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
	Labs SOFNETS Project.		Labs SOFNETS Project.
	10. IANA Considerations		10. IANA Considerations
	This document provides only management guidelines for the reserved		This document provides only management guidelines for the reserved
	LISP EID prefix requested and allocated in [I-D.ietf-lisp-eid-block].		LISP EID prefix requested in [I-D.ietf-lisp-eid-block].
	There is an operational requirement for an EID allocation service		There is an operational requirement for an EID registration service
	that ensures uniqueness of EIDs allocated according to the		that ensures uniqueness of EIDs according to the requirements
	requirements described in Section 5. Furthermore, there is an		described in Section 5. Furthermore, there is an operational
	operational requirement for EID registration service that allows a		requirement for EID registration service that allows a lookup of the
	lookup of the contact information of the entity to which the EID was		contact information of the entity that registered the EID.
	allocated.
	IANA must ensure both of these services are provided, for the space		IANA is to ensure both of these services are provided in a globally
	directly allocated by IANA, in a globally uniform fashion for the		uniform fashion for the duration of the experiment.
	duration of the experiment.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-lisp-eid-block]		[I-D.ietf-lisp-eid-block]
	Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP		Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP
	EID Block", draft-ietf-lisp-eid-block-09 (work in		EID Block", draft-ietf-lisp-eid-block-09 (work in
	progress), July 2014.		progress), July 2014.
	skipping to change at page 9, line 9		skipping to change at page 7, line 43
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 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.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-weirds-rdap-sec]		[I-D.ietf-weirds-rdap-sec]
	Hollenbeck, S. and N. Kong, "Security Services for the		Hollenbeck, S. and N. Kong, "Security Services for the
	Registration Data Access Protocol",		Registration Data Access Protocol", draft-ietf-weirds-
	draft-ietf-weirds-rdap-sec-06 (work in progress),		rdap-sec-06 (work in progress), February 2014.
	February 2014.
	[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, June 2000.		Internet Assigned Numbers Authority", RFC 2860, June 2000.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The		[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830,		Locator/ID Separation Protocol (LISP)", RFC 6830, January
	January 2013.		2013.
	[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The		[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
	Locator/ID Separation Protocol (LISP) for Multicast		Locator/ID Separation Protocol (LISP) for Multicast
	Environments", RFC 6831, January 2013.		Environments", RFC 6831, January 2013.
	[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,		[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
	"Interworking between Locator/ID Separation Protocol		"Interworking between Locator/ID Separation Protocol
	(LISP) and Non-LISP Sites", RFC 6832, January 2013.		(LISP) and Non-LISP Sites", RFC 6832, January 2013.
	[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation		[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
	Protocol (LISP) Map-Server Interface", RFC 6833,		Protocol (LISP) Map-Server Interface", RFC 6833, January
	January 2013.		2013.
	[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID		[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
	Separation Protocol (LISP) Map-Versioning", RFC 6834,		Separation Protocol (LISP) Map-Versioning", RFC 6834,
	January 2013.		January 2013.
	[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation		[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
	Protocol Internet Groper (LIG)", RFC 6835, January 2013.		Protocol Internet Groper (LIG)", RFC 6835, January 2013.
	[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,		[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol Alternative Logical		"Locator/ID Separation Protocol Alternative Logical
	skipping to change at page 12, line 27		skipping to change at page 11, line 10
	logical next-hop on the overlay network. The primary function of		logical next-hop on the overlay network. The primary function of
	LISP+ALT routers is to provide a lightweight forwarding		LISP+ALT routers is to provide a lightweight forwarding
	infrastructure for LISP control-plane messages (Map-Request and		infrastructure for LISP control-plane messages (Map-Request and
	Map-Reply), and to transport data packets when the packet has the		Map-Reply), and to transport data packets when the packet has the
	same destination address in both the inner (encapsulating)		same destination address in both the inner (encapsulating)
	destination and outer destination addresses ((i.e., a Data Probe		destination and outer destination addresses ((i.e., a Data Probe
	packet). See [RFC6830] for more details.		packet). See [RFC6830] for more details.
	Appendix B. Document Change Log		Appendix B. Document Change Log
			Version 03 Posted October 2014.
			o Re-worded the document so to avoid confusion on "allocation" and
			"assignement". The document now reffers to "registration". As
			for comments by G. Huston and M. Binderberger.
	Version 02 Posted July 2014.		Version 02 Posted July 2014.
	o Deleted the trailing paragraph of Section 4, as for discussion in		o Deleted the trailing paragraph of Section 4, as for discussion in
	the mailing list.		the mailing list.
	o Deleted the fees policy as of suggestion of G. Huston and		o Deleted the fees policy as of suggestion of G. Huston and
	discussion during 89th IETF.		discussion during 89th IETF.
	o Re-phrased the availability of the registration information		o Re-phrased the availability of the registration information
	requirement avoiding putting specific numbers (previously		requirement avoiding putting specific numbers (previously
	requiring 99% up time), as of suggestion of G. Huston and		requiring 99% up time), as of suggestion of G. Huston and
	discussion during 89th IETF.		discussion during 89th IETF.
	Version 01 Posted February 2014.		Version 01 Posted February 2014.
	o Dropped the reverse DNS requirement as for discussion during the		o Dropped the reverse DNS requirement as for discussion during the
	88th IETF meeting.		88th IETF meeting.
	o Dropped the minimum allocation requirement as for discussion		o Dropped the minimum allocation requirement as for discussion
	during the 88th IETF meeting.		during the 88th IETF meeting.
	o Changed Section 7 from "General Consideration" to "Policy Validity		o Changed Section 7 from "General Consideration" to "Policy Validity
	Period", according to J. Curran feedback. The purpose of the		Period", according to J. Curran feedback. The purpose of the
	section is just to clearly state the period during which the		section is just to clearly state the period during which the
	policy applies.		policy applies.
	Version 00 Posted December 2013.		Version 00 Posted December 2013.
	o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.		o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.
	Authors' Addresses		Authors' Addresses
	Luigi Iannone		Luigi Iannone
	skipping to change at page 13, line 16		skipping to change at page 12, line 4
	Version 00 Posted December 2013.		Version 00 Posted December 2013.
	o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.		o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt.
	Authors' Addresses		Authors' Addresses
	Luigi Iannone		Luigi Iannone
	Telecom ParisTech		Telecom ParisTech
	Email: ggx@gigix.net		Email: ggx@gigix.net
	Roger Jorgensen		Roger Jorgensen
	Bredbandsfylket Troms		Bredbandsfylket Troms
	Email: rogerj@gmail.com		Email: rogerj@gmail.com
	David Conrad		David Conrad
	Virtualized, LLC		Virtualized, LLC
	Email: drc@virtualized.org		Email: drc@virtualized.org
			Geoff Huston
			APNIC - Asia Pacific Network Information Center
			Email: gih@apnic.net
End of changes. 48 change blocks.
	157 lines changed or deleted		133 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/