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/