draft-ietf-lisp-eid-anonymity-00.txt		draft-ietf-lisp-eid-anonymity-01.txt
	Network Working Group D. Farinacci		Network Working Group D. Farinacci
	Internet-Draft lispers.net		Internet-Draft lispers.net
	Intended status: Experimental P. Pillay-Esnault		Intended status: Experimental P. Pillay-Esnault
	Expires: February 18, 2018 Huawei Technologies		Expires: May 3, 2018 Huawei Technologies
	W. Haddad		W. Haddad
	Ericsson		Ericsson
	August 17, 2017		October 30, 2017
	LISP EID Anonymity		LISP EID Anonymity
	draft-ietf-lisp-eid-anonymity-00		draft-ietf-lisp-eid-anonymity-01
	Abstract		Abstract
	This specification will describe how ephemeral LISP EIDs can be used		This specification will describe how ephemeral LISP EIDs can be used
	to create source anonymity. The idea makes use of frequently		to create source anonymity. The idea makes use of frequently
	changing EIDs much like how a credit-card system uses a different		changing EIDs much like how a credit-card system uses a different
	credit-card numbers for each transaction.		credit-card numbers for each transaction.
	Requirements Language		Requirements Language
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	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 https://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 February 18, 2018.		This Internet-Draft will expire on May 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	6. Interworking Considerations . . . . . . . . . . . . . . . . . 5		6. Interworking Considerations . . . . . . . . . . . . . . . . . 5
	7. Multicast Considerations . . . . . . . . . . . . . . . . . . 5		7. Multicast Considerations . . . . . . . . . . . . . . . . . . 5
	8. Performance Improvements . . . . . . . . . . . . . . . . . . 5		8. Performance Improvements . . . . . . . . . . . . . . . . . . 5
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 6		9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	11.1. Normative References . . . . . . . . . . . . . . . . . . 6		11.1. Normative References . . . . . . . . . . . . . . . . . . 6
	11.2. Informative References . . . . . . . . . . . . . . . . . 7		11.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8		Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8
	B.1. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 8		B.1. Changes to draft-ietf-lisp-eid-anonymity-01 . . . . . . . 8
	B.2. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 8		B.2. Changes to draft-ietf-lisp-eid-anonymity-00 . . . . . . . 8
	B.3. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 8		B.3. Changes to draft-farinacci-lisp-eid-anonymity-02 . . . . 8
	B.4. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 9		B.4. Changes to draft-farinacci-lisp-eid-anonymity-01 . . . . 9
			B.5. Changes to draft-farinacci-lisp-eid-anonymity-00 . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The LISP architecture [RFC6830] specifies two namespaces, End-Point		The LISP architecture [RFC6830] specifies two namespaces, End-Point
	IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in		IDs (EIDs) and Routing Locators (RLOCs). An EID identifies a node in
	the network and the RLOC indicates the EID's topological location.		the network and the RLOC indicates the EID's topological location.
	Typically EIDs are globally unique so a end-node system can connect		Typically EIDs are globally unique so a end-node system can connect
	to any other end-node system on the Internet. Privately used EIDs		to any other end-node system on the Internet. Privately used EIDs
	are allowed when scoped within a VPN but must always be unique within		are allowed when scoped within a VPN but must always be unique within
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	global address, or participate in DHCP to get assigned a leased		global address, or participate in DHCP to get assigned a leased
	address.		address.
	Note that the ephemeral-EID can be mobile just like any other EID so		Note that the ephemeral-EID can be mobile just like any other EID so
	if it is initially registered to the mapping system with one or more		if it is initially registered to the mapping system with one or more
	RLOCs, later the RLOC-set can change as the ephemeral-EID roams.		RLOCs, later the RLOC-set can change as the ephemeral-EID roams.
	4. Design Details		4. Design Details
	This specification proposes the use of the experimental LISP EID-		This specification proposes the use of the experimental LISP EID-
	block 2001:5::/32 when IPv6 is used. See IANA Considerations section		block 2001:5::/32 [RFC7954] when IPv6 is used. See IANA
	for a specific sub-block allocation request. When IPv4 is used, the		Considerations section for a specific sub-block allocation request.
	Class E block 240.0.0.0/4 is being proposed.		When IPv4 is used, the Class E block 240.0.0.0/4 is being proposed.
	The client end-node system will use the rest of the host bits to		The client end-node system will use the rest of the host bits to
	allocate a random number to be used as the ephemeral-EID. The EID		allocate a random number to be used as the ephemeral-EID. The EID
	can be created manually or via a programatic interface. When the EID		can be created manually or via a programatic interface. When the EID
	address is going to change frequently, it is suggested to use a		address is going to change frequently, it is suggested to use a
	programatic interface. The probability of address collision is		programatic interface. The probability of address collision is
	unlikely for IPv6 EIDs but could occur for IPv4 EIDs. A client end-		unlikely for IPv6 EIDs but could occur for IPv4 EIDs. A client end-
	node can create a ephemeral-EID and then look it up in the mapping		node can create a ephemeral-EID and then look it up in the mapping
	system to see if it exists. If the EID exists in the mapping system,		system to see if it exists. If the EID exists in the mapping system,
	the client end-node can attempt creation of a new random number for		the client end-node can attempt creation of a new random number for
	the ephemeral-EID. See Section 8 where ephemeral-EIDs can be		the ephemeral-EID. See Section 8 where ephemeral-EIDs can be
	preallocated and registered to the mapping system before use.		preallocated and registered to the mapping system before use.
	When the client end-node system is co-located with the RLOC and acts		When the client end-node system is co-located with the RLOC and acts
	as an xTR, it should register the binding before sending packets.		as an xTR, it should register the binding before sending packets.
	This eliminates a race condition for returning packets not knowing		This eliminates a race condition for returning packets not knowing
	where to encapsulate packets to the ephemeral-EID's RLOCs. See		where to encapsulate packets to the ephemeral-EID's RLOCs. See
	Section 8 for alternatives for fixing this race condition problem.		Section 8 for alternatives for fixing this race condition problem.
	When the client end-node system is not acting as an xTR, it should		When the client end-node system is not acting as an xTR, it should
	send some packets so its ephemeral-EID can be discovered by an xTR		send some packets so its ephemeral-EID can be discovered by an xTR
	which supports EID-mobility [I-D.portoles-lisp-eid-mobility] so		which supports EID-mobility [I-D.ietf-lisp-eid-mobility] so mapping
	mapping system registration can occur before the destination returns		system registration can occur before the destination returns packets.
	packets. When the end-node system is acting as an xTR, the EID and		When the end-node system is acting as an xTR, the EID and RLOC-set is
	RLOC-set is co-located in the same node. So when the EID is created,		co-located in the same node. So when the EID is created, the xTR can
	the xTR can register the mapping versus waiting for packet		register the mapping versus waiting for packet transmission.
	transmission.
	5. Other Types of Ephemeral-EIDs		5. Other Types of Ephemeral-EIDs
	When IPv6 Ephemeral-EIDs are used, an alternative to a random number		When IPv6 Ephemeral-EIDs are used, an alternative to a random number
	can be used. For example, the low-order bits of the IPv6 address		can be used. For example, the low-order bits of the IPv6 address
	could be a cryptographic hash of a public-key. Mechanisms from		could be a cryptographic hash of a public-key. Mechanisms from
	[RFC3972] could be used for EIDs. Using this approach allows the		[RFC3972] could be used for EIDs. Using this approach allows the
	sender with a hashed EID to be authenticated. So packet signatures		sender with a hashed EID to be authenticated. So packet signatures
	can be verified by the corresponding public-key. When hashed EIDs		can be verified by the corresponding public-key. When hashed EIDs
	are used, the EID can change frequently as rekeying may be required		are used, the EID can change frequently as rekeying may be required
	for enhanced security.		for enhanced security. LISP specific control message signature
			mechanims can be found in [I-D.farinacci-lisp-ecdsa-auth].
	6. Interworking Considerations		6. Interworking Considerations
	If a client end-node is communicating with a system that is not in a		If a client end-node is communicating with a system that is not in a
	LISP site, the procedures from [RFC6832] should be followed. The		LISP site, the procedures from [RFC6832] should be followed. The
	PITR will be required to originate route advertisements for the		PITR will be required to originate route advertisements for the
	ephemeral-EID sub-block [I-D.draft-ietf-lisp-eid-block] so it can		ephemeral-EID sub-block [RFC7954] so it can attract packets sourced
	attract packets sourced by non-LISP sites destined to ephemeral-EIDs.		by non-LISP sites destined to ephemeral-EIDs. However, in the
	However, in the general case, the coarse block from		general case, the coarse block from [RFC7954] will be advertised
	[I-D.draft-ietf-lisp-eid-block] will be advertised which would cover		which would cover the sub-block. For IPv4, the 240.0.0.0/4 must be
	the sub-block. For IPv4, the 240.0.0.0/4 must be advertised into the		advertised into the IPv4 routing system.
	IPv4 routing system.
	7. Multicast Considerations		7. Multicast Considerations
	A client end-node system can be a member of a multicast group fairly		A client end-node system can be a member of a multicast group fairly
	easily since its address is not used for multicast communication as a		easily since its address is not used for multicast communication as a
	receiver. This is due to the design characteristics of IGMP		receiver. This is due to the design characteristics of IGMP
	[RFC3376] [RFC2236] [RFC1112] and MLD [RFC2710] [RFC3810].		[RFC3376] [RFC2236] [RFC1112] and MLD [RFC2710] [RFC3810].
	When a client end-node system is a multicast source, there is		When a client end-node system is a multicast source, there is
	ephemeral (S,G) state that is created and maintained in the network		ephemeral (S,G) state that is created and maintained in the network
	via multicast routing protocols such as PIM [RFC4602] and when PIM is		via multicast routing protocols such as PIM [RFC4602] and when PIM is
	used with LISP [RFC6802]. In addition, when		used with LISP [RFC6802]. In addition, when
	[I-D.draft-ietf-lisp-signal-free-multicast] is used, ephemeral-EID		[I-D.ietf-lisp-signal-free-multicast] is used, ephemeral-EID state is
	state is created in the mapping database. This doesn't present any		created in the mapping database. This doesn't present any problems
	problems other than the amount of state that may exist in the network		other than the amount of state that may exist in the network if not
	if not timed out and removed promptly.		timed out and removed promptly.
	However, there exists a multicast source discovery problem when PIM-		However, there exists a multicast source discovery problem when PIM-
	SSM [RFC4607] is used. Members that join (S,G) channels via out of		SSM [RFC4607] is used. Members that join (S,G) channels via out of
	band mechanisms. These mechanisms need to support ephemeral-EIDs.		band mechanisms. These mechanisms need to support ephemeral-EIDs.
	Otherwise, PIM-ASM [RFC4602] or PIM-Bidir [RFC5015] will need to be		Otherwise, PIM-ASM [RFC4602] or PIM-Bidir [RFC5015] will need to be
	used.		used.
	8. Performance Improvements		8. Performance Improvements
	An optimization to reduce the race condition between registering		An optimization to reduce the race condition between registering
	ephemeral-EIDs and returning packets as well as reducing the		ephemeral-EIDs and returning packets as well as reducing the
	probability of ephemeral-EID address collision is to preload the		probability of ephemeral-EID address collision is to preload the
	mapping database with a list of ephemeral-EIDs before using them. It		mapping database with a list of ephemeral-EIDs before using them. It
	comes at a expense of rebinding all of registered ephemeral-EIDs when		comes at a expense of rebinding all of registered ephemeral-EIDs when
	there is an RLOC change. There is work in progress to consider		there is an RLOC change. There is work in progress to consider
	adding a level of indirection here so a single entry gets the RLOC		adding a level of indirection here so a single entry gets the RLOC
	update and the list of ephemeral-EIDs point to the single entry.		update and the list of ephemeral-EIDs point to the single entry.
	9. Security Considerations		9. Security Considerations
	When LISP-crypto [I-D.draft-ietf-lisp-crypto] is used the EID payload		When LISP-crypto [RFC8061] is used the EID payload is more secure
	is more secure through encryption providing EID obfuscation of the		through encryption providing EID obfuscation of the ephemeral-EID as
	ephemeral-EID as well as the global-EID it is communicating with.		well as the global-EID it is communicating with. But the obfuscation
	But the obfuscation only occurs between xTRs. So the randomness of a		only occurs between xTRs. So the randomness of a ephemeral-EID
	ephemeral-EID inside of LISP sites provide a new level of privacy.		inside of LISP sites provide a new level of privacy.
	10. IANA Considerations		10. IANA Considerations
	This specification is requesting the sub-block 2001:5:ffff::/48 for		This specification is requesting the sub-block 2001:5:ffff::/48 for
	ephemeral-EID usage.		ephemeral-EID usage.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,		[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, DOI 10.17487/RFC1112, August 1989,		RFC 1112, DOI 10.17487/RFC1112, August 1989,
	<https://www.rfc-editor.org/info/rfc1112>.		<https://www.rfc-editor.org/info/rfc1112>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2236] Fenner, W., "Internet Group Management Protocol, Version		[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
	2", RFC 2236, DOI 10.17487/RFC2236, November 1997,		2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
	<https://www.rfc-editor.org/info/rfc2236>.		<https://www.rfc-editor.org/info/rfc2236>.
	[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast		[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
	Listener Discovery (MLD) for IPv6", RFC 2710,		Listener Discovery (MLD) for IPv6", RFC 2710,
	DOI 10.17487/RFC2710, October 1999, <https://www.rfc-		DOI 10.17487/RFC2710, October 1999,
	editor.org/info/rfc2710>.		<https://www.rfc-editor.org/info/rfc2710>.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, DOI 10.17487/RFC3376, October 2002,		3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
	<https://www.rfc-editor.org/info/rfc3376>.		<https://www.rfc-editor.org/info/rfc3376>.
	[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener		[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
	Discovery Version 2 (MLDv2) for IPv6", RFC 3810,		Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
	DOI 10.17487/RFC3810, June 2004, <https://www.rfc-		DOI 10.17487/RFC3810, June 2004,
	editor.org/info/rfc3810>.		<https://www.rfc-editor.org/info/rfc3810>.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",		[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, DOI 10.17487/RFC3972, March 2005,		RFC 3972, DOI 10.17487/RFC3972, March 2005,
	<https://www.rfc-editor.org/info/rfc3972>.		<https://www.rfc-editor.org/info/rfc3972>.
	[RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse		[RFC4602] Pusateri, T., "Protocol Independent Multicast - Sparse
	Mode (PIM-SM) IETF Proposed Standard Requirements		Mode (PIM-SM) IETF Proposed Standard Requirements
	Analysis", RFC 4602, DOI 10.17487/RFC4602, August 2006,		Analysis", RFC 4602, DOI 10.17487/RFC4602, August 2006,
	<https://www.rfc-editor.org/info/rfc4602>.		<https://www.rfc-editor.org/info/rfc4602>.
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,		PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
	<https://www.rfc-editor.org/info/rfc5015>.		<https://www.rfc-editor.org/info/rfc5015>.
	[RFC6802] Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson		[RFC6802] Baillargeon, S., Flinta, C., and A. Johnsson, "Ericsson
	Two-Way Active Measurement Protocol (TWAMP) Value-Added		Two-Way Active Measurement Protocol (TWAMP) Value-Added
	Octets", RFC 6802, DOI 10.17487/RFC6802, November 2012,		Octets", RFC 6802, DOI 10.17487/RFC6802, November 2012,
	<https://www.rfc-editor.org/info/rfc6802>.		<https://www.rfc-editor.org/info/rfc6802>.
	[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,
	DOI 10.17487/RFC6830, January 2013, <https://www.rfc-		DOI 10.17487/RFC6830, January 2013,
	editor.org/info/rfc6830>.		<https://www.rfc-editor.org/info/rfc6830>.
	[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,		(LISP) and Non-LISP Sites", RFC 6832,
	DOI 10.17487/RFC6832, January 2013, <https://www.rfc-		DOI 10.17487/RFC6832, January 2013,
	editor.org/info/rfc6832>.		<https://www.rfc-editor.org/info/rfc6832>.
	11.2. Informative References
	[I-D.draft-ietf-lisp-crypto]		[RFC7954] Iannone, L., Lewis, D., Meyer, D., and V. Fuller,
	Farinacci, D. and B. Weis, "LISP Data-Plane		"Locator/ID Separation Protocol (LISP) Endpoint Identifier
	Confidentiality", draft-ietf-lisp-crypto-03 (work in		(EID) Block", RFC 7954, DOI 10.17487/RFC7954, September
	progress).		2016, <https://www.rfc-editor.org/info/rfc7954>.
	[I-D.draft-ietf-lisp-eid-block]		[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
	Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP		(LISP) Data-Plane Confidentiality", RFC 8061,
	EID Block", draft-ietf-lisp-eid-block-13.txt (work in		DOI 10.17487/RFC8061, February 2017,
	progress).		<https://www.rfc-editor.org/info/rfc8061>.
	[I-D.draft-ietf-lisp-signal-free-multicast]		11.2. Informative References
	Farinacci, D. and V. Moreno, "Signal-Free LISP Multicast",
	draft-ietf-lisp-signal-free-multicast-00.txt (work in
	progress).
	[I-D.meyer-lisp-mn]		[I-D.farinacci-lisp-ecdsa-auth]
	Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP		Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
	Mobile Node", draft-meyer-lisp-mn-16 (work in progress),		Authentication and Authorization", draft-farinacci-lisp-
	December 2016.		ecdsa-auth-01 (work in progress), October 2017.
	[I-D.portoles-lisp-eid-mobility]		[I-D.ietf-lisp-eid-mobility]
	Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,		Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
	F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a		F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
	Unified Control Plane", draft-portoles-lisp-eid-		Unified Control Plane", draft-ietf-lisp-eid-mobility-00
	mobility-02 (work in progress), April 2017.		(work in progress), May 2017.
			[I-D.ietf-lisp-signal-free-multicast]
			Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
			draft-ietf-lisp-signal-free-multicast-06 (work in
			progress), August 2017.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The author would like to thank the LISP WG for their review and		The author would like to thank the LISP WG for their review and
	acceptance of this draft.		acceptance of this draft.
	Appendix B. Document Change Log		Appendix B. Document Change Log
	[RFC Editor: Please delete this section on publication as RFC.]		[RFC Editor: Please delete this section on publication as RFC.]
	B.1. Changes to draft-ietf-lisp-eid-anonymity-00		B.1. Changes to draft-ietf-lisp-eid-anonymity-01
			o Posted October 2017.
			o Add to section 5 that PKI can be used to authenticate EIDs.
			o Update references.
			B.2. Changes to draft-ietf-lisp-eid-anonymity-00
	o Posted August 2017.		o Posted August 2017.
	o Made draft-farinacci-lisp-eid-anonymity-02 a LISP working group		o Made draft-farinacci-lisp-eid-anonymity-02 a LISP working group
	document.		document.
	B.2. Changes to draft-farinacci-lisp-eid-anonymity-02		B.3. Changes to draft-farinacci-lisp-eid-anonymity-02
	o Posted April 2017.		o Posted April 2017.
	o Added section describing how ephemeral-EIDs can use a public key		o Added section describing how ephemeral-EIDs can use a public key
	hash as an alternative to a random number.		hash as an alternative to a random number.
	o Indciate when an EID/RLOC co-located, that the xTR can register		o Indciate when an EID/RLOC co-located, that the xTR can register
	the EID when it is configured or changed versus waiting for a		the EID when it is configured or changed versus waiting for a
	packet to be sent as in the EID/RLOC separated case.		packet to be sent as in the EID/RLOC separated case.
	B.3. Changes to draft-farinacci-lisp-eid-anonymity-01		B.4. Changes to draft-farinacci-lisp-eid-anonymity-01
	o Posted October 2016.		o Posted October 2016.
	o Update document timer.		o Update document timer.
	B.4. Changes to draft-farinacci-lisp-eid-anonymity-00		B.5. Changes to draft-farinacci-lisp-eid-anonymity-00
	o Posted April 2016.		o Posted April 2016.
	o Initial posting.		o Initial posting.
	Authors' Addresses		Authors' Addresses
	Dino Farinacci		Dino Farinacci
	lispers.net		lispers.net
	San Jose, CA		San Jose, CA
End of changes. 28 change blocks.
	70 lines changed or deleted		78 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/