draft-ietf-lisp-rfc6830bis-03.txt		draft-ietf-lisp-rfc6830bis-04.txt
	Network Working Group D. Farinacci		Network Working Group D. Farinacci
	Internet-Draft V. Fuller		Internet-Draft V. Fuller
	Intended status: Standards Track D. Meyer		Intended status: Standards Track D. Meyer
	Expires: November 3, 2017 D. Lewis		Expires: January 18, 2018 D. Lewis
	Cisco Systems		Cisco Systems
	A. Cabellos (Ed.)		A. Cabellos (Ed.)
	UPC/BarcelonaTech		UPC/BarcelonaTech
	May 2, 2017		July 17, 2017
	The Locator/ID Separation Protocol (LISP)		The Locator/ID Separation Protocol (LISP)
	draft-ietf-lisp-rfc6830bis-03		draft-ietf-lisp-rfc6830bis-04
	Abstract		Abstract
	This document describes the data-plane protocol for the Locator/ID		This document describes the data-plane protocol for the Locator/ID
	Separation Protocol (LISP). LISP defines two namespaces, End-point		Separation Protocol (LISP). LISP defines two namespaces, End-point
	Identifiers (EIDs) that identify end-hosts and Routing Locators		Identifiers (EIDs) that identify end-hosts and Routing Locators
	(RLOCs) that identify network attachment points. With this, LISP		(RLOCs) that identify network attachment points. With this, LISP
	effectively separates control from data, and allows routers to create		effectively separates control from data, and allows routers to create
	overlay networks. LISP-capable routers exchange encapsulated packets		overlay networks. LISP-capable routers exchange encapsulated packets
	according to EID-to-RLOC mappings stored in a local map-cache. The		according to EID-to-RLOC mappings stored in a local map-cache. The
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 November 3, 2017.		This Internet-Draft will expire on January 18, 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		(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
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43		18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43
	19. Security Considerations . . . . . . . . . . . . . . . . . . . 43		19. Security Considerations . . . . . . . . . . . . . . . . . . . 43
	20. Network Management Considerations . . . . . . . . . . . . . . 44		20. Network Management Considerations . . . . . . . . . . . . . . 44
	21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
	21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44		21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44
	22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44		22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
	22.1. Normative References . . . . . . . . . . . . . . . . . . 44		22.1. Normative References . . . . . . . . . . . . . . . . . . 44
	22.2. Informative References . . . . . . . . . . . . . . . . . 47		22.2. Informative References . . . . . . . . . . . . . . . . . 47
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51		Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51
	B.1. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52		B.1. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52
	B.2. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52		B.2. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52
	B.3. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52		B.3. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 52
	B.4. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52		B.4. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 52
			B.5. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
	This document describes the Locator/Identifier Separation Protocol		This document describes the Locator/Identifier Separation Protocol
	(LISP). LISP is an encapsulation protocol built around the		(LISP). LISP is an encapsulation protocol built around the
	fundamental idea of separating the topological location of a network		fundamental idea of separating the topological location of a network
	attachment point from the node's identity [CHIAPPA]. As a result		attachment point from the node's identity [CHIAPPA]. As a result
	LISP creates two namespaces: Endpoint Identifiers (EIDs), that are		LISP creates two namespaces: Endpoint Identifiers (EIDs), that are
	used to identify end-hosts (e.g., nodes or Virtual Machines) and		used to identify end-hosts (e.g., nodes or Virtual Machines) and
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 47 ¶
	connects. Typically, each block is a sub-block of a service		connects. Typically, each block is a sub-block of a service
	provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and		provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
	is aggregated into the larger block before being advertised into		is aggregated into the larger block before being advertised into
	the global Internet. Traditionally, IP multihoming has been		the global Internet. Traditionally, IP multihoming has been
	implemented by each multihomed site acquiring its own globally		implemented by each multihomed site acquiring its own globally
	visible prefix. LISP uses only topologically assigned and		visible prefix. LISP uses only topologically assigned and
	aggregatable address blocks for RLOCs, eliminating this		aggregatable address blocks for RLOCs, eliminating this
	demonstrably non-scalable practice.		demonstrably non-scalable practice.
	Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6		Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6
	[RFC2460] address of an Egress Tunnel Router (ETR). An RLOC is		[RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is
	the output of an EID-to-RLOC mapping lookup. An EID maps to one		the output of an EID-to-RLOC mapping lookup. An EID maps to one
	or more RLOCs. Typically, RLOCs are numbered from topologically		or more RLOCs. Typically, RLOCs are numbered from topologically
	aggregatable blocks that are assigned to a site at each point to		aggregatable blocks that are assigned to a site at each point to
	which it attaches to the global Internet; where the topology is		which it attaches to the global Internet; where the topology is
	defined by the connectivity of provider networks, RLOCs can be		defined by the connectivity of provider networks, RLOCs can be
	thought of as PA addresses. Multiple RLOCs can be assigned to the		thought of as PA addresses. Multiple RLOCs can be assigned to the
	same ETR device or to multiple ETR devices at a site.		same ETR device or to multiple ETR devices at a site.
	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 16, line 15 ¶		skipping to change at page 16, line 15 ¶
	^ + Destination EID +		^ + Destination EID +
	\ | |		\ | |
	\ + +		\ + +
	\ | |		\ | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.3. Tunnel Header Field Descriptions		5.3. Tunnel Header Field Descriptions
	Inner Header (IH): The inner header is the header on the datagram		Inner Header (IH): The inner header is the header on the datagram
	received from the originating host. The source and destination IP		received from the originating host. The source and destination IP
	addresses are EIDs [RFC0791] [RFC2460].		addresses are EIDs [RFC0791] [RFC8200].
	Outer Header: (OH) The outer header is a new header prepended by an		Outer Header: (OH) The outer header is a new header prepended by an
	ITR. The address fields contain RLOCs obtained from the ingress		ITR. The address fields contain RLOCs obtained from the ingress
	router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)"		router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)"
	from [RFC0768]. The setting of the Don't Fragment (DF) bit		from [RFC0768]. The setting of the Don't Fragment (DF) bit
	'Flags' field is according to rules listed in Sections 7.1 and		'Flags' field is according to rules listed in Sections 7.1 and
	7.2.		7.2.
	UDP Header: The UDP header contains an ITR selected source port when		UDP Header: The UDP header contains an ITR selected source port when
	encapsulating a packet. See Section 12 for details on the hash		encapsulating a packet. See Section 12 for details on the hash
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 42 ¶
	[RFC6935] [RFC6936]. When a packet with a zero UDP checksum is		[RFC6935] [RFC6936]. When a packet with a zero UDP checksum is
	received by an ETR, the ETR MUST accept the packet for		received by an ETR, the ETR MUST accept the packet for
	decapsulation. When an ITR transmits a non-zero value for the UDP		decapsulation. When an ITR transmits a non-zero value for the UDP
	checksum, it MUST send a correctly computed value in this field.		checksum, it MUST send a correctly computed value in this field.
	When an ETR receives a packet with a non-zero UDP checksum, it MAY		When an ETR receives a packet with a non-zero UDP checksum, it MAY
	choose to verify the checksum value. If it chooses to perform		choose to verify the checksum value. If it chooses to perform
	such verification, and the verification fails, the packet MUST be		such verification, and the verification fails, the packet MUST be
	silently dropped. If the ETR chooses not to perform the		silently dropped. If the ETR chooses not to perform the
	verification, or performs the verification successfully, the		verification, or performs the verification successfully, the
	packet MUST be accepted for decapsulation. The handling of UDP		packet MUST be accepted for decapsulation. The handling of UDP
	checksums for all tunneling protocols, including LISP, is under		zero checksums over IPv6 for all tunneling protocols, including
	active discussion within the IETF. When that discussion		LISP, is subject to the applicability statement in [RFC6936].
	concludes, any necessary changes will be made to align LISP with
	the outcome of the broader discussion.
	UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated		UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated
	packet to be the sum of the inner-header IPv4 Total Length plus		packet to be the sum of the inner-header IPv4 Total Length plus
	the UDP and LISP header lengths. For an IPv6-encapsulated packet,		the UDP and LISP header lengths. For an IPv6-encapsulated packet,
	the 'UDP Length' field is the sum of the inner-header IPv6 Payload		the 'UDP Length' field is the sum of the inner-header IPv6 Payload
	Length, the size of the IPv6 header (40 octets), and the size of		Length, the size of the IPv6 header (40 octets), and the size of
	the UDP and LISP headers.		the UDP and LISP headers.
	N: The N-bit is the nonce-present bit. When this bit is set to 1,		N: The N-bit is the nonce-present bit. When this bit is set to 1,
	the low-order 24 bits of the first 32 bits of the LISP header		the low-order 24 bits of the first 32 bits of the LISP header
	skipping to change at page 45, line 14 ¶		skipping to change at page 45, line 14 ¶
	[I-D.ietf-lisp-introduction]		[I-D.ietf-lisp-introduction]
	Cabellos-Aparicio, A. and D. Saucez, "An Architectural		Cabellos-Aparicio, A. and D. Saucez, "An Architectural
	Introduction to the Locator/ID Separation Protocol		Introduction to the Locator/ID Separation Protocol
	(LISP)", draft-ietf-lisp-introduction-13 (work in		(LISP)", draft-ietf-lisp-introduction-13 (work in
	progress), April 2015.		progress), April 2015.
	[I-D.ietf-lisp-rfc6833bis]		[I-D.ietf-lisp-rfc6833bis]
	Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,		Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
	"Locator/ID Separation Protocol (LISP) Control-Plane",		"Locator/ID Separation Protocol (LISP) Control-Plane",
	draft-ietf-lisp-rfc6833bis-03 (work in progress), April		draft-ietf-lisp-rfc6833bis-05 (work in progress), May
	2017.		2017.
	[I-D.ietf-lisp-sec]		[I-D.ietf-lisp-sec]
	Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.		Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
	Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12		Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
	(work in progress), November 2016.		(work in progress), November 2016.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<http://www.rfc-editor.org/info/rfc768>.		<http://www.rfc-editor.org/info/rfc768>.
	skipping to change at page 45, line 44 ¶		skipping to change at page 45, line 44 ¶
	[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,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within		[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
	ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November		ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
	1998, <http://www.rfc-editor.org/info/rfc2404>.		1998, <http://www.rfc-editor.org/info/rfc2404>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<http://www.rfc-editor.org/info/rfc3168>.		<http://www.rfc-editor.org/info/rfc3168>.
	[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced		[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
	by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,		by an On-line Database", RFC 3232, DOI 10.17487/RFC3232,
	January 2002, <http://www.rfc-editor.org/info/rfc3232>.		January 2002, <http://www.rfc-editor.org/info/rfc3232>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	skipping to change at page 46, line 25 ¶		skipping to change at page 46, line 21 ¶
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August		Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
	2006, <http://www.rfc-editor.org/info/rfc4632>.		2006, <http://www.rfc-editor.org/info/rfc4632>.
	[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-		[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
	384, and HMAC-SHA-512 with IPsec", RFC 4868,		384, and HMAC-SHA-512 with IPsec", RFC 4868,
	DOI 10.17487/RFC4868, May 2007,		DOI 10.17487/RFC4868, May 2007,
	<http://www.rfc-editor.org/info/rfc4868>.		<http://www.rfc-editor.org/info/rfc4868>.
	[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", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path		[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
	Forwarding (RPF) Vector TLV", RFC 5496,		Forwarding (RPF) Vector TLV", RFC 5496,
	DOI 10.17487/RFC5496, March 2009,		DOI 10.17487/RFC5496, March 2009,
	<http://www.rfc-editor.org/info/rfc5496>.		<http://www.rfc-editor.org/info/rfc5496>.
	[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",		[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
	RFC 5944, DOI 10.17487/RFC5944, November 2010,		RFC 5944, DOI 10.17487/RFC5944, November 2010,
	skipping to change at page 47, line 43 ¶		skipping to change at page 47, line 38 ¶
	[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID		[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
	Separation Protocol (LISP) Threat Analysis", RFC 7835,		Separation Protocol (LISP) Threat Analysis", RFC 7835,
	DOI 10.17487/RFC7835, April 2016,		DOI 10.17487/RFC7835, April 2016,
	<http://www.rfc-editor.org/info/rfc7835>.		<http://www.rfc-editor.org/info/rfc7835>.
	[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol		[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
	(LISP) Data-Plane Confidentiality", RFC 8061,		(LISP) Data-Plane Confidentiality", RFC 8061,
	DOI 10.17487/RFC8061, February 2017,		DOI 10.17487/RFC8061, February 2017,
	<http://www.rfc-editor.org/info/rfc8061>.		<http://www.rfc-editor.org/info/rfc8061>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<http://www.rfc-editor.org/info/rfc8200>.
	22.2. Informative References		22.2. Informative References
	[AFN] IANA, "Address Family Numbers", August 2016,		[AFN] IANA, "Address Family Numbers", August 2016,
	<http://www.iana.org/assignments/address-family-numbers>.		<http://www.iana.org/assignments/address-family-numbers>.
	[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed",		[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed",
	1999,		1999,
	<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.		<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
	[I-D.farinacci-lisp-predictive-rlocs]		[I-D.farinacci-lisp-predictive-rlocs]
	Farinacci, D. and P. Pillay-Esnault, "LISP Predictive		Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
	RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in		RLOCs", draft-farinacci-lisp-predictive-rlocs-02 (work in
	progress), November 2016.		progress), May 2017.
	[I-D.ietf-lisp-mn]		[I-D.ietf-lisp-mn]
	Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP		Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
	Mobile Node", draft-ietf-lisp-mn-00 (work in progress),		Mobile Node", draft-ietf-lisp-mn-00 (work in progress),
	April 2017.		April 2017.
	[I-D.ietf-lisp-signal-free-multicast]		[I-D.ietf-lisp-signal-free-multicast]
	Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",		Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
	draft-ietf-lisp-signal-free-multicast-03 (work in		draft-ietf-lisp-signal-free-multicast-04 (work in
	progress), April 2017.		progress), May 2017.
	[I-D.meyer-loc-id-implications]		[I-D.meyer-loc-id-implications]
	Meyer, D. and D. Lewis, "Architectural Implications of		Meyer, D. and D. Lewis, "Architectural Implications of
	Locator/ID Separation", draft-meyer-loc-id-implications-01		Locator/ID Separation", draft-meyer-loc-id-implications-01
	(work in progress), January 2009.		(work in progress), January 2009.
	[I-D.portoles-lisp-eid-mobility]		[I-D.portoles-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-portoles-lisp-eid-
	skipping to change at page 52, line 5 ¶		skipping to change at page 52, line 5 ¶
	The LISP working group would like to give a special thanks to Jari		The LISP working group would like to give a special thanks to Jari
	Arkko, the Internet Area AD at the time that the set of LISP		Arkko, the Internet Area AD at the time that the set of LISP
	documents were being prepared for IESG last call, and for his		documents were being prepared for IESG last call, and for his
	meticulous reviews and detailed commentaries on the 7 working group		meticulous reviews and detailed commentaries on the 7 working group
	last call documents progressing toward standards-track RFCs.		last call documents progressing toward standards-track RFCs.
	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-rfc6830bis-03		B.1. Changes to draft-ietf-lisp-rfc6830bis-04
			o Posted July 2017.
			o Changed reference of IPv6 RFC2460 to RFC8200.
			o Indicate that the applicability statement for UDP zero checksums
			over IPv6 adheres to RFC6936.
			B.2. Changes to draft-ietf-lisp-rfc6830bis-03
	o Posted May 2017.		o Posted May 2017.
	o Move the control-plane related codepoints in the IANA		o Move the control-plane related codepoints in the IANA
	Considerations section to RFC6833bis.		Considerations section to RFC6833bis.
	B.2. Changes to draft-ietf-lisp-rfc6830bis-02		B.3. Changes to draft-ietf-lisp-rfc6830bis-02
	o Posted April 2017.		o Posted April 2017.
	o Reflect some editorial comments from Damien Sausez.		o Reflect some editorial comments from Damien Sausez.
	B.3. Changes to draft-ietf-lisp-rfc6830bis-01		B.4. Changes to draft-ietf-lisp-rfc6830bis-01
	o Posted March 2017.		o Posted March 2017.
	o Include references to new RFCs published.		o Include references to new RFCs published.
	o Change references from RFC6833 to RFC6833bis.		o Change references from RFC6833 to RFC6833bis.
	o Clarified LCAF text in the IANA section.		o Clarified LCAF text in the IANA section.
	o Remove references to "experimental".		o Remove references to "experimental".
	B.4. Changes to draft-ietf-lisp-rfc6830bis-00		B.5. Changes to draft-ietf-lisp-rfc6830bis-00
	o Posted December 2016.		o Posted December 2016.
	o Created working group document from draft-farinacci-lisp		o Created working group document from draft-farinacci-lisp
	-rfc6830-00 individual submission. No other changes made.		-rfc6830-00 individual submission. No other changes made.
	Authors' Addresses		Authors' Addresses
	Dino Farinacci		Dino Farinacci
	Cisco Systems		Cisco Systems
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	EMail: farinacci@gmail.com		EMail: farinacci@gmail.com
	Vince Fuller		Vince Fuller
	Cisco Systems		Cisco Systems
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	EMail: vince.fuller@gmail.com		EMail: vince.fuller@gmail.com
	Dave Meyer		Dave Meyer
	Cisco Systems		Cisco Systems
End of changes. 20 change blocks.
	29 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/