draft-ietf-lisp-map-versioning-03.txt		draft-ietf-lisp-map-versioning-04.txt
	Network Working Group L. Iannone		Network Working Group L. Iannone
	Internet-Draft TU Berlin - Deutsche Telekom		Internet-Draft TU Berlin - Deutsche Telekom
	Intended status: Experimental Laboratories AG		Intended status: Experimental Laboratories AG
	Expires: March 16, 2012 D. Saucez		Expires: March 23, 2012 D. Saucez
	O. Bonaventure		O. Bonaventure
	Universite catholique de Louvain		Universite catholique de Louvain
	September 13, 2011		September 20, 2011
	LISP Map-Versioning		LISP Map-Versioning
	draft-ietf-lisp-map-versioning-03.txt		draft-ietf-lisp-map-versioning-04.txt
	Abstract		Abstract
	This document describes the LISP (Locator/ID Separation Protocol)		This document describes the LISP (Locator/ID Separation Protocol)
	Map-Versioning mechanism, which provides in-packet information about		Map-Versioning mechanism, which provides in-packet information about
	Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to		Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to
	encapsulate LISP data packets. The proposed approach is based on		encapsulate LISP data packets. The proposed approach is based on
	associating a version number to EID-to-RLOC mappings and transport		associating a version number to EID-to-RLOC mappings and transport
	such a version number in the LISP specific header of LISP-		such a version number in the LISP specific header of LISP-
	encapsulated packets. LISP Map-Versioning is particularly useful to		encapsulated packets. LISP Map-Versioning is particularly useful to
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	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 March 16, 2012.		This Internet-Draft will expire on March 23, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 12		skipping to change at page 3, line 12
	Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19		Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document describes the Map-Versioning mechanism used to provide		This document describes the Map-Versioning mechanism used to provide
	information on changes in the EID-to-RLOC mappings used in the LISP		information on changes in the EID-to-RLOC mappings used in the LISP
	([I-D.ietf-lisp]) context to perform packet encapsulation. The		([I-D.ietf-lisp]) context to perform packet encapsulation. The
	mechanism is totally transparent to xTRs not supporting such		mechanism is totally transparent to xTRs not supporting such
	functionality. It is not meant to replace any existing LISP		functionality. It is not meant to replace any existing LISP
	mechanism, but rather to complete them providing new functionalities.		mechanism, but rather to extend them providing new functionalities.
	The basic mechanism is to associate a Map-Version number to each LISP		The basic mechanism is to associate a Map-Version number to each LISP
	EID-to-RLOC mapping and transport such a version number in the LISP-		EID-to-RLOC mapping and transport such a version number in the LISP-
	specific header. When a mapping changes, a new version number is		specific header. When a mapping changes, a new version number is
	assigned to the updated mapping. A change in an EID-to-RLOC mapping		assigned to the updated mapping. A change in an EID-to-RLOC mapping
	can be a change in the RLOCs set, by adding or removing one or more		can be a change in the RLOCs set, by adding or removing one or more
	RLOCs, but it can also be a change in the priority or weight of one		RLOCs, but it can also be a change in the priority or weight of one
	or more RLOCs.		or more RLOCs.
	When Map-Versioning is used, LISP-encapsulated data packets contain		When Map-Versioning is used, LISP-encapsulated data packets contain
	the version number of the two mappings used to select the RLOCs in		the version number of the two mappings used to select the RLOCs in
	skipping to change at page 4, line 35		skipping to change at page 4, line 35
	mapping used to select the source address (RLOC) of the outer IP		mapping used to select the source address (RLOC) of the outer IP
	header of LISP-encapsulated packets.		header of LISP-encapsulated packets.
	Destination Map-Version number: Map-Version number of the EID-to-		Destination Map-Version number: Map-Version number of the EID-to-
	RLOC mapping used to select the destination address (RLOC) of the		RLOC mapping used to select the destination address (RLOC) of the
	outer IP header of LISP-encapsulated packets.		outer IP header of LISP-encapsulated packets.
	4. EID-to-RLOC Map-Version number		4. EID-to-RLOC Map-Version number
	The EID-to-RLOC Map-Version number consists in an unsigned 12-bits		The EID-to-RLOC Map-Version number consists in an unsigned 12-bits
	integer. The version number is assigned in a per-mapping fashion,		integer. The version number is assigned on a per-mapping basis,
	meaning that different mappings will have assigned a different		meaning that different mappings have a different version number,
	version number, which is also updated independently. An update in		which is also updated independently. An update in the version number
	the version number (i.e., a newer version) consist in incrementing by		(i.e., a newer version) consists in incrementing by one the older
	one the older version number. Appendix A contains a rough estimation		version number. Appendix A contains a rough estimation of the wrap-
	of the wrap-around time for the Map-Version number.		around time for the Map-Version number.
	The space of version numbers has a circular order where half of the		The space of version numbers has a circular order where half of the
	version numbers is greater than the current Map-Version number and		version numbers is greater than the current Map-Version number and
	the other half is smaller than current Map-Version number. In a more		the other half is smaller than current Map-Version number. In a more
	formal way, assuming we have two version numbers V1 and V2 and that		formal way, assuming we have two version numbers V1 and V2 and that
	the numbers are expressed on N bits, the following three cases may		the numbers are expressed on N bits, the following three cases may
	happen:		happen:
	V1 = V2 : This is the exact match case.		V1 = V2 : This is the exact match case.
	skipping to change at page 6, line 13		skipping to change at page 6, line 13
	The fact that the 0 value has a special meaning for the Map-Version		The fact that the 0 value has a special meaning for the Map-Version
	number implies that, when updating a Map-Version number because of a		number implies that, when updating a Map-Version number because of a
	change in the mapping, if the next value is 0 then Map-Version number		change in the mapping, if the next value is 0 then Map-Version number
	MUST be incremented by 2 (i.e., set to 1, which is the next valid		MUST be incremented by 2 (i.e., set to 1, which is the next valid
	value).		value).
	5. Dealing with Map-Version numbers		5. Dealing with Map-Version numbers
	The main idea of using Map-Version numbers is that whenever there is		The main idea of using Map-Version numbers is that whenever there is
	a change in the mapping (e.g., adding/removing RLOCs, a change in the		a change in the mapping (e.g., adding/removing RLOCs, a change in the
	weights due to TE policies, or a change in the priorities) or an ISP		weights due to TE policies, or a change in the priorities) or a LISP
	realizes that one or more of its own RLOCs are not reachable anymore		site realizes that one or more of its own RLOCs are not reachable
	from a local perspective (e.g., through IGP, or policy changes) the		anymore from a local perspective (e.g., through IGP, or policy
	ISP updates the mapping also assigning a new Map-Version number.		changes) the LISP site updates the mapping also assigning a new Map-
			Version number.
	To each mapping, a version number is associated and changes each time		To each mapping, a version number is associated and changes each time
	the mapping is changed. Note that map-versioning does not introduce		the mapping is changed. Note that map-versioning does not introduce
	new problems concerning the coordination of different ETRs of a		new problems concerning the coordination of different ETRs of a
	domain. Indeed, ETRs belonging to the same LISP site must return for		domain. Indeed, ETRs belonging to the same LISP site must return for
	a specific EID-prefix the same mapping, including the same Map-		a specific EID-prefix the same mapping, including the same Map-
	Version number. In principle this is orthogonal to whether or not		Version number. In principle this is orthogonal to whether or not
	map-versioning is used. The synchronization problem is out of the		map-versioning is used. The synchronization problem is out of the
	scope of this document.		scope of this document.
	skipping to change at page 7, line 24		skipping to change at page 7, line 26
	to-date Destination Map-Version number. A check on this version		to-date Destination Map-Version number. A check on this version
	number can be done, where the following cases can arise:		number can be done, where the following cases can arise:
	1. The packets arrive with the same Destination Map-Version number		1. The packets arrive with the same Destination Map-Version number
	stored in the EID-to-RLOC Database. This is the regular case.		stored in the EID-to-RLOC Database. This is the regular case.
	The ITR sending the packet has in its EID-to-RLOC Cache an up-to-		The ITR sending the packet has in its EID-to-RLOC Cache an up-to-
	date mapping. No further actions are needed.		date mapping. No further actions are needed.
	2. The packet arrives with a Destination Map-Version number greater		2. The packet arrives with a Destination Map-Version number greater
	(i.e., newer) than the one stored in the EID-to-RLOC Database.		(i.e., newer) than the one stored in the EID-to-RLOC Database.
	Since the ETR is authoritative on the mapping, this means that		Since the ETR is authoritative on the mapping, meaning that the
	someone is not behaving correctly with respect to the		Map-Version number of its mapping is the correct one, this
	specifications, thus the packet carries a not valid version		implies that someone is not behaving correctly with respect to
	number and SHOULD be silently dropped.		the specifications. In this case the packet carries a version
			number that is not valid, otherwise the ETR would have the same,
			and SHOULD be silently dropped.
	3. The packets arrive with a Destination Map-Version number smaller		3. The packets arrive with a Destination Map-Version number smaller
	(i.e., older) than the one stored in the EID-to-RLOC Database.		(i.e., older) than the one stored in the EID-to-RLOC Database.
	This means that the ITR sending the packet has an old mapping in		This means that the ITR sending the packet has an old mapping in
	its EID-to-RLOC Cache containing stale information. The ITR		its EID-to-RLOC Cache containing stale information. The ITR
	sending the packet has to be informed that a newer mapping is		sending the packet has to be informed that a newer mapping is
	available. This is done with a Map-Request message sent back to		available. This is done with a Map-Request message sent back to
	the ITR. The Map-Request will either trigger a Map-Request back		the ITR. The Map-Request will either trigger a Map-Request back
	using the Solicit-Map-Request (SMR) bit or it will piggyback the		using the Solicit-Map-Request (SMR) bit or it will piggyback the
	newer mapping. These are not new mechanisms; how to SMR or		newer mapping. These are not new mechanisms; how to SMR or
	skipping to change at page 9, line 16		skipping to change at page 9, line 21
	specifications in [I-D.ietf-lisp], including rate limitation		specifications in [I-D.ietf-lisp], including rate limitation
	policies.		policies.
	3. The packet arrives with a Source Map-Version number smaller		3. The packet arrives with a Source Map-Version number smaller
	(i.e., older) than the one stored in the local EID-to-RLOC Cache.		(i.e., older) than the one stored in the local EID-to-RLOC Cache.
	Such a case is not valid with respect to the specifications.		Such a case is not valid with respect to the specifications.
	Indeed, if the mapping is already present in the EID-to-RLOC		Indeed, if the mapping is already present in the EID-to-RLOC
	Cache, this means that an explicit Map-Request has been sent and		Cache, this means that an explicit Map-Request has been sent and
	a Map-Reply has been received from an authoritative source.		a Map-Reply has been received from an authoritative source.
	Assuming that the mapping system is not corrupted anyhow, the		Assuming that the mapping system is not corrupted anyhow, the
	Map-Version in the EID-to-RLOC Cache is the correct one and the		Map-Version in the EID-to-RLOC Cache is the correct one, while
			the one carried by the packet is stale. In this situation the
	packet MAY be silently dropped.		packet MAY be silently dropped.
	If the ETR does not have an entry in the EID-to-RLOC Cache for the		If the ETR does not have an entry in the EID-to-RLOC Cache for the
	source EID (e.g., in case of unidirectional traffic) then the Source		source EID (e.g., in case of unidirectional traffic) then the Source
	Map-Version number can be safely ignored.		Map-Version number can be safely ignored.
	For LISP-encapsulated packets with the V-bit set, if the Source Map-		For LISP-encapsulated packets with the V-bit set, if the Source Map-
	Version number is the Null Map-Version value, it means that the		Version number is the Null Map-Version value, it means that the
	Source Map-Version number MUST be ignored.		Source Map-Version number MUST be ignored.
	6. LISP header and Map-Version numbers		6. LISP header and Map-Version numbers
	In order for the versioning approach to work, the LISP specific		In order for the versioning approach to work, the LISP specific
	header has to carry both Source Map-Version number and Destination		header has to carry both Source Map-Version number and Destination
	Map-Version number. This is done by setting the V-bit in the LISP		Map-Version number. This is done by setting the V-bit in the LISP
	specific header as defined in [I-D.ietf-lisp] Section 5.3. When the		specific header as defined in [I-D.ietf-lisp] Section 5.3. When the
	V-bit is set the low-order 24-bits of the first longword (which		V-bit is set the low-order 24-bits of the first longword are used to
	usually contains the nonce) are used to transport both source and		transport both source and destination Map-Version numbers. In
	destination Map-Version numbers. In particular the first 12 bits are		particular the first 12 bits are used for Source Map-Version number
	used for Source Map-Version number and the second 12 bits for the		and the second 12 bits for the Destination Map-Version number.
	Destination Map-Version number.
	Hereafter is the example of LISP header carrying version numbers in		Hereafter is the example of LISP header carrying version numbers in
	the case of IPv4-in-IPv4 encapsulation. The same setting can be used		the case of IPv4-in-IPv4 encapsulation. The same setting can be used
	for any other case (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6).		for any other case (IPv4-in-IPv6, IPv6-in-IPv4, and IPv6-in-IPv6).
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	/ |N|L|E|V|I|flags| Source Map-Version |Destination Map-Version|		/ |N|L|E|V|I|flags| Source Map-Version |Destination Map-Version|
	LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		LISP+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 10, line 30		skipping to change at page 10, line 38
	packets need to carry version numbers. When Map-Version numbers are		packets need to carry version numbers. When Map-Version numbers are
	carried the V-bit MUST be set to 1. All legal combinations of the		carried the V-bit MUST be set to 1. All legal combinations of the
	flags, when the V-bit is set to 1, are described in [I-D.ietf-lisp].		flags, when the V-bit is set to 1, are described in [I-D.ietf-lisp].
	7. Map Record and Map-Version		7. Map Record and Map-Version
	To accommodate the proposed mechanism, the Map Records that are		To accommodate the proposed mechanism, the Map Records that are
	transported on Map-Request/Map-Reply/Map-Register messages need to		transported on Map-Request/Map-Reply/Map-Register messages need to
	carry the Map-Version number as well. For this purpose the 12-bits		carry the Map-Version number as well. For this purpose the 12-bits
	before the EID-AFI field in the Record that describe a mapping is		before the EID-AFI field in the Record that describe a mapping is
	used. This is defined in [I-D.ietf-lisp] and reported here as		used. This is defined in Section 6.1.4 of [I-D.ietf-lisp] and
	example.		reported here as example.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Record TTL |		| | Record TTL |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	R | Locator Count | EID mask-len | ACT |A| Reserved |		R | Locator Count | EID mask-len | ACT |A| Reserved |
	e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	c | Rsvd | Map-Version Number | EID-AFI |		c | Rsvd | Map-Version Number | EID-prefix-AFI |
	o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	r | EID-prefix |		r | EID-prefix |
	d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| /| Priority | Weight | M Priority | M Weight |		| /| Priority | Weight | M Priority | M Weight |
	| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| o | Unused Flags |L|p|R| Loc-AFI |		| o | Unused Flags |L|p|R| Loc-AFI |
	| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| \| Locator |		| \| Locator |
	+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Map-Version Number: Map-Version of the mapping contained in the		Map-Version Number: Map-Version of the mapping contained in the
	Record. As explained in Section 4.1 this field can be zero (0),		Record. As explained in Section 4.1 this field can be zero (0),
	meaning that no Map-Version is associated to the mapping, hence		meaning that no Map-Version is associated to the mapping, hence
	packets that are LISP-encapsulated using this mapping MUST NOT		packets that are LISP-encapsulated using this mapping MUST NOT
	contain Map-Version numbers in the LISP specific header and the		contain Map-Version numbers in the LISP specific header and the
	V-bit MUST be set to 0.		V-bit MUST be set to 0.
	This packet format works perfectly with xTRs that do not support Map-		This packet format works perfectly with xTRs that do not support Map-
	Versioning, since they can simply ignore those bits.		Versioning, since they can simply ignore those bits.
	skipping to change at page 16, line 32		skipping to change at page 16, line 32
	10. Security Considerations		10. Security Considerations
	Map-Versioning does not introduce any security issue concerning both		Map-Versioning does not introduce any security issue concerning both
	the data-plane and the control-plane. On the contrary, as described		the data-plane and the control-plane. On the contrary, as described
	in the following, if Map-Versioning may be used also to update		in the following, if Map-Versioning may be used also to update
	mappings in case of change in the reachability information (i.e.,		mappings in case of change in the reachability information (i.e.,
	instead of the Locator Status Bits) it is possible to reduce the		instead of the Locator Status Bits) it is possible to reduce the
	effects of some DoS or spoofing attacks that can happen in an		effects of some DoS or spoofing attacks that can happen in an
	untrusted environment.		untrusted environment.
	Robusteness of the Map-Versioning mechanism leverages on a trusted		Robustness of the Map-Versioning mechanism leverages on a trusted
	Mapping Distribution System. A thorough security analysis of LISP is		Mapping Distribution System. A thorough security analysis of LISP is
	documented in [I-D.ietf-lisp-threats].		documented in [I-D.ietf-lisp-threats].
	10.1. Map-Versioning against traffic disruption		10.1. Map-Versioning against traffic disruption
	An attacker can try to disrupt ongoing communications by creating		An attacker can try to disrupt ongoing communications by creating
	LISP encapsulated packets with wrong Locator Status Bits. If the xTR		LISP encapsulated packets with wrong Locator Status Bits. If the xTR
	blindly trusts the Locator Status Bits it will change the		blindly trusts the Locator Status Bits it will change the
	encapsulation accordingly, which can result in traffic disruption.		encapsulation accordingly, which can result in traffic disruption.
	skipping to change at page 18, line 28		skipping to change at page 18, line 28
	13.2. Informative References		13.2. Informative References
	[I-D.iannone-openlisp-implementation]		[I-D.iannone-openlisp-implementation]
	Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP		Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
	Implementation Report",		Implementation Report",
	draft-iannone-openlisp-implementation-01 (work in		draft-iannone-openlisp-implementation-01 (work in
	progress), July 2008.		progress), July 2008.
	[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-08		Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09
	(work in progress), September 2011.		(work in progress), September 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-02 (work in progress),
	June 2011.		June 2011.
	[I-D.ietf-lisp-ms]		[I-D.ietf-lisp-ms]
	Fuller, V. and D. Farinacci, "LISP Map Server",		Fuller, V. and D. Farinacci, "LISP Map Server",
	skipping to change at page 19, line 41		skipping to change at page 19, line 41
	| 15 | 22 Days | 9 Hours |		| 15 | 22 Days | 9 Hours |
	| 14 | 11 Days | 4 Hours |		| 14 | 11 Days | 4 Hours |
	| 13 | 5.6 Days | 2.2 Hours |		| 13 | 5.6 Days | 2.2 Hours |
	| 12 | 2.8 Days | 1.1 Hours |		| 12 | 2.8 Days | 1.1 Hours |
	+---------------+---------------------+----------------------+		+---------------+---------------------+----------------------+
	Figure 5: Estimation of time before wrap-around		Figure 5: Estimation of time before wrap-around
	Appendix B. Document Change Log		Appendix B. Document Change Log
			o Version 04 Posted September 2011.
			* Added clarifications in Section 1, Section 4, Section 5.2, and
			Section 5.1 to address Stephen Farrell's comments.
			* Used the term LISP Site instead of ISP in Section 5 as
			suggested by Stephen Farrell.
			* Deleted "(usually contains the nonce)" from Section 6 because
			confusing, as suggested by Stephen Farrell.
			* Fixed several typos pointed out by Stephen Farrell.
	o Version 03 Posted September 2011.		o Version 03 Posted September 2011.
	* Added reference in Section 7 toward the main lisp documents		* Added reference in Section 7 toward the main lisp documents
	specifying the section, as requested by Jari Arkko.		specifying the section, as requested by Jari Arkko.
	* Fixed all typos and editorial issues pointed out by Jari Arkko.		* Fixed all typos and editorial issues pointed out by Jari Arkko.
	* Added clarification in Section 8.4 as requested by Jari Arkko.		* Added clarification in Section 8.4 as requested by Jari Arkko.
	* Extentend all acronyms in the abstract as requested by Jari		* Extentend all acronyms in the abstract as requested by Jari
End of changes. 16 change blocks.
	30 lines changed or deleted		47 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/