draft-ietf-lisp-map-versioning-02.txt   draft-ietf-lisp-map-versioning-03.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: January 6, 2012 D. Saucez Expires: March 16, 2012 D. Saucez
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
July 5, 2011 September 13, 2011
LISP Map-Versioning LISP Map-Versioning
draft-ietf-lisp-map-versioning-02.txt draft-ietf-lisp-map-versioning-03.txt
Abstract Abstract
This document describes the LISP Map-Versioning mechanism, which This document describes the LISP (Locator/ID Separation Protocol)
provides in-packet information about EID-to-RLOC mappings used to Map-Versioning mechanism, which provides in-packet information about
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
inform communicating xTRs about modifications of the mappings used to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel
Routers (ETRs) about modifications of the mappings used to
encapsulate packets. The mechanism is transparent to legacy encapsulate packets. The mechanism is transparent to legacy
implementations, since in the LISP-specific header and in the Map implementations, since in the LISP-specific header and in the Map
Records, bits used for Map-Versioning can be safely ignored by xTRs Records, bits used for Map-Versioning can be safely ignored by ITRs
that do not support the mechanism. and ETRs that do not support the mechanism.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 6, 2012. This Internet-Draft will expire on March 16, 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 2, line 30 skipping to change at page 2, line 31
4. EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . . 4 4. EID-to-RLOC Map-Version number . . . . . . . . . . . . . . . . 4
4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . . 5 4.1. The Null Map-Version . . . . . . . . . . . . . . . . . . . 5
5. Dealing with Map-Version numbers . . . . . . . . . . . . . . . 6 5. Dealing with Map-Version numbers . . . . . . . . . . . . . . . 6
5.1. Handling Destination Map-Version number . . . . . . . . . 7 5.1. Handling Destination Map-Version number . . . . . . . . . 7
5.2. Handling Source Map-Version number . . . . . . . . . . . . 8 5.2. Handling Source Map-Version number . . . . . . . . . . . . 8
6. LISP header and Map-Version numbers . . . . . . . . . . . . . 9 6. LISP header and Map-Version numbers . . . . . . . . . . . . . 9
7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10 7. Map Record and Map-Version . . . . . . . . . . . . . . . . . . 10
8. Benefits and case studies for Map-Versioning . . . . . . . . . 11 8. Benefits and case studies for Map-Versioning . . . . . . . . . 11
8.1. Synchronization of different xTRs . . . . . . . . . . . . 11 8.1. Synchronization of different xTRs . . . . . . . . . . . . 11
8.2. Map-Versioning and unidirectional traffic . . . . . . . . 12 8.2. Map-Versioning and unidirectional traffic . . . . . . . . 12
8.3. Map-Versioning and interworking . . . . . . . . . . . . . 12 8.3. Map-Versioning and interworking . . . . . . . . . . . . . 13
8.3.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13 8.3.1. Map-Versioning and Proxy-ITRs . . . . . . . . . . . . 13
8.3.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 13 8.3.2. Map-Versioning and LISP-NAT . . . . . . . . . . . . . 14
8.3.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 13 8.3.3. Map-Versioning and Proxy-ETRs . . . . . . . . . . . . 14
8.4. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 14 8.4. RLOC shutdown/withdraw . . . . . . . . . . . . . . . . . . 15
8.5. Map-Version for lightweight LISP implementation . . . . . 14 8.5. Map-Version for lightweight LISP implementation . . . . . 15
9. Incremental deployment and implementation status . . . . . . . 15 9. Incremental deployment and implementation status . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10.1. Map-Versioning against traffic disruption . . . . . . . . 16 10.1. Map-Versioning against traffic disruption . . . . . . . . 16
10.2. Map-Versioning against reachability information DoS . . . 16 10.2. Map-Versioning against reachability information DoS . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17 13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . . 17 13.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Estimation of time before Map-Version wrap-around . . 18 Appendix A. Estimation of time before Map-Version wrap-around . . 18
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 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 complete 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
skipping to change at page 3, line 48 skipping to change at page 3, line 48
This operation is two-fold. On the one hand, it enables the ETR This operation is two-fold. On the one hand, it enables the ETR
receiving the packet to know if the ITR has the latest version number receiving the packet to know if the ITR has the latest version number
that any ETR at the destination EID site has provided to the ITR in a that any ETR at the destination EID site has provided to the ITR in a
Map-Reply. If it is not the case the ETR can send to the ITR a Map- Map-Reply. If it is not the case the ETR can send to the ITR a Map-
Request containing the updated mapping or soliciting a Map-Request Request containing the updated mapping or soliciting a Map-Request
from the ITR (both cases are already defined in [I-D.ietf-lisp]). In from the ITR (both cases are already defined in [I-D.ietf-lisp]). In
this way the ITR can update its cache. On the other hand, it enables this way the ITR can update its cache. On the other hand, it enables
an ETR receiving such a packet to know if it has in its EID-to-RLOC an ETR receiving such a packet to know if it has in its EID-to-RLOC
Cache the latest mapping for the source EID (in case of bidirectional Cache the latest mapping for the source EID (in case of bidirectional
traffic). If it is not the case a Map-Request can be send. traffic). If it is not the case a Map-Request can be sent.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions of Terms 3. Definitions of Terms
The present document uses terms already defined in main LISP The present document uses terms already defined in main LISP
skipping to change at page 6, line 20 skipping to change at page 6, line 20
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 an ISP
realizes that one or more of its own RLOCs are not reachable anymore realizes that one or more of its own RLOCs are not reachable anymore
from a local perspective (e.g., through IGP, or policy changes) the from a local perspective (e.g., through IGP, or policy changes) the
ISP updates the mapping also assigning a new Map-Version number. ISP 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
any new problem 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. In principle this is a specific EID-prefix the same mapping, including the same Map-
orthogonal to whether or not map-versioning is used. The ETR's Version number. In principle this is orthogonal to whether or not
synchronization problem is out of the scope of this document. map-versioning is used. The synchronization problem is out of the
scope of this document.
In order to announce in a data-driven fashion that the mapping has In order to announce in a data-driven fashion that the mapping has
been updated, Map-Version numbers used to create the outer IP header been updated, Map-Version numbers used to create the outer IP header
of the LISP-encapsulated packet are embedded in the LISP-specific of the LISP-encapsulated packet are embedded in the LISP-specific
header. This means that the header needs to contain two Map-Version header. This means that the header needs to contain two Map-Version
numbers: numbers:
o The Source Map-Version number of the EID-to-RLOC mapping in the o The Source Map-Version number of the EID-to-RLOC mapping in the
EID-to-RLOC Database used to select the source RLOC. EID-to-RLOC Database used to select the source RLOC.
skipping to change at page 7, line 24 skipping to change at page 7, line 25
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, this means that
someone is not behaving correctly w.r.t. the specifications, thus someone is not behaving correctly with respect to the
the packet carries a not valid version number and SHOULD be specifications, thus the packet carries a not valid version
silently dropped. number 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 SMR bit or it will piggyback the newer mapping. These using the Solicit-Map-Request (SMR) bit or it will piggyback the
are not new mechanisms; how to SMR or piggyback mappings in Map- newer mapping. These are not new mechanisms; how to SMR or
Request messages is already described in [I-D.ietf-lisp], while piggyback mappings in Map-Request messages is already described
their security is discussed in [I-D.ietf-lisp-threats]. These in [I-D.ietf-lisp], while their security is discussed in
Map-Request messages should be rate limited (rate limitation [I-D.ietf-lisp-threats]. These Map-Request messages should be
policies are also described in [I-D.ietf-lisp]). The feature rate limited (rate limitation policies are also described in
introduced by Map-Version numbers is the possibility of blocking [I-D.ietf-lisp]). The feature introduced by Map-Version numbers
traffic from ITRs not using the latest mapping. Indeed, after a is the possibility of blocking traffic not using the latest
certain number of retries, if the Destination Map-Version number mapping. Indeed, after a certain number of retries, if the
in the packets is not updated, the ETR MAY silently drop packets Destination Map-Version number in the packets is not updated, the
with a stale Map-Version number. This because either the ITR is ETR MAY drop packets with a stale Map-Version number while
refusing to use the mapping for which the ETR is authoritative or strongly reducing the rate of Map-Request messages. This because
(worse) it might be some form of attack. either the ITR is refusing to use the mapping for which the ETR
is authoritative or (worse) it might be some form of attack.
Another case might be that the control-plane is experiencing
transient failures so the Map-Requests cannot reach that ITR. By
keeping sending Map-Requests at very low rate it is possible to
recover from this situation.
The rule in the third case MAY be more restrictive. If the mapping The rule in the third case MAY be more restrictive. If the mapping
has been the same for a period of time as long as the TTL (defined in has been the same for a period of time as long as the TTL (defined in
[I-D.ietf-lisp]) of the previous version of the mapping, all packets [I-D.ietf-lisp]) of the previous version of the mapping, all packets
arriving with an old Map-Version SHOULD be silently dropped right arriving with an old Map-Version SHOULD be silently dropped right
away without issuing any Map-Request. The reason that allows such away without issuing any Map-Request. The reason that allows such
action is the fact that if the new mapping with the updated version action is the fact that if the new mapping with the updated version
number has been unchanged for at least the same time as the TTL of number has been unchanged for at least the same time as the TTL of
the older mapping, all the entries in the caches of ITRs must have the older mapping, all the entries in the caches of ITRs must have
expired. Hence, all ITRs sending traffic should have refreshed the expired. Hence, all ITRs sending traffic should have refreshed the
mapping according to [I-D.ietf-lisp]. If packets with old Map- mapping according to [I-D.ietf-lisp]. If packets with old Map-
Version number are still received, then either someone has not Version number are still received, then either someone has not
respected the TTL, or it is a form of spoof/attack. In both cases respected the TTL, or it is a form of spoof/attack. In both cases
this is not valid behavior w.r.t. the specifications and the packet this is not valid behavior with respect to the specifications and the
SHOULD be silently dropped. packet SHOULD be silently dropped.
LISP-encapsulated packets with the V-bit set, when the original LISP-encapsulated packets with the V-bit set, when the original
mapping in the EID-to-RLOC Database has version number set to the mapping in the EID-to-RLOC Database has version number set to the
Null Map-Version value, MAY be silently dropped. As explained in Null Map-Version value, MAY be silently dropped. As explained in
Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it Section 4.1, if an EID-to-RLOC mapping has a Null Map-Version, it
means that ITRs, using the mapping for encapsulation, MUST NOT use means that ITRs, using the mapping for encapsulation, MUST NOT use
Map-Version number in the LISP-specific header. Map-Version number in the LISP-specific header.
For LISP-encapsulated packets with the V-bit set, when the original For LISP-encapsulated packets with the V-bit set, when the original
mapping in the EID-to-RLOC Database has version number set to a value mapping in the EID-to-RLOC Database has version number set to a value
skipping to change at page 9, line 7 skipping to change at page 9, line 11
(i.e., newer) than the one stored in the local EID-to-RLOC Cache. (i.e., newer) than the one stored in the local EID-to-RLOC Cache.
This means that ETR has in its cache a mapping that is stale and This means that ETR has in its cache a mapping that is stale and
needs to be updated. A Map-Request SHOULD be sent to get the new needs to be updated. A Map-Request SHOULD be sent to get the new
mapping for the source EID. This is a normal Map-Request message mapping for the source EID. This is a normal Map-Request message
sent through the mapping system and MUST respect the sent through the mapping system and MUST respect the
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 w.r.t. the specifications. Indeed, if Such a case is not valid with respect to the specifications.
the mapping is already present in the EID-to-RLOC Cache, this Indeed, if the mapping is already present in the EID-to-RLOC
means that an explicit Map-Request has been sent and a Map-Reply Cache, this means that an explicit Map-Request has been sent and
has been received from an authoritative source. Assuming that a Map-Reply has been received from an authoritative source.
the mapping system is not corrupted anyhow, the Map-Version in Assuming that the mapping system is not corrupted anyhow, the
the EID-to-RLOC Cache is the correct one and the packet MAY be Map-Version in the EID-to-RLOC Cache is the correct one and the
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. When the V-bit is set the low-order 24-bits of the specific header as defined in [I-D.ietf-lisp] Section 5.3. When the
first longword (which usually contains the nonce) are used to V-bit is set the low-order 24-bits of the first longword (which
transport both source and destination Map-Version numbers. In usually contains the nonce) are used to transport both source and
particular the first 12 bits are used for Source Map-Version number destination Map-Version numbers. In particular the first 12 bits are
and the second 12 bits for the Destination Map-Version number. used for Source Map-Version number and the second 12 bits for the
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 14, line 16 skipping to change at page 14, line 39
| LISP | | non-LISP | | LISP | | non-LISP |
| Domain A | | Domain B | | Domain A | | Domain B |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | ITR A |------->| Proxy ETR |------->| | | | ITR A |------->| Proxy ETR |------->| |
| +-------+ +-----------+ | | | +-------+ +-----------+ | |
| | | | | | | |
+----------+ +-------------+ +----------+ +-------------+
Figure 4 Figure 4
A Proxy-ETR does not have any mapping, since it just decapsulate A Proxy-ETR does not have any mapping, since it just decapsulates
packets arriving from LISP site. In this case, the ITR will just put packets arriving from LISP site. In this case, the ITR will just put
the Null Map-Version value as Destination Map-Version number, while the Null Map-Version value as Destination Map-Version number, while
the receiving Proxy-ETR will ignore the field. the receiving Proxy-ETR will ignore the field.
With this setup the Proxy-ETR is able to check whether or not the With this setup the Proxy-ETR is able to check whether or not the
mapping has changed. If this is the case the mapping for LISP Domain mapping has changed. If this is the case the mapping for LISP Domain
A on the PETR can be updated using one of the mechanisms defined in A on the PETR can be updated using one of the mechanisms defined in
[I-D.ietf-lisp] and [I-D.ietf-lisp-interworking]. [I-D.ietf-lisp] and [I-D.ietf-lisp-interworking].
8.4. RLOC shutdown/withdraw 8.4. RLOC shutdown/withdraw
Map-Versioning can be even used to perform a graceful shutdown or Map-Versioning can be even used to perform a graceful shutdown or
withdraw of a specific RLOC. This is achieved by simply issuing a withdraw of a specific RLOC. This is achieved by simply issuing a
new mapping, with an updated Map-Version number, where the specific new mapping, with an updated Map-Version number, where the specific
RLOC to be shut down is withdrawn or announced as unreachable (R bit RLOC to be shut down is withdrawn or announced as unreachable (R bit
in the Map Record, see [I-D.ietf-lisp]), but without actually turning in the Map Record, see [I-D.ietf-lisp]), but without actually turning
it off. it off.
Once no more traffic is received by the RLOC, because all sites have Once no more traffic is received by the RLOC, it can be shut down
updated the mapping, it can be shut down safely. gracefully, because at least all sites actively using the mapping
have updated it.
It should be pointed out that for frequent up/down changes such a It should be pointed out that for frequent up/down changes such a
mechanism should not be used since this can generate excessive load mechanism should not be used since this can generate excessive load
on the Mapping System. on the Mapping System.
8.5. Map-Version for lightweight LISP implementation 8.5. Map-Version for lightweight LISP implementation
The use of Map-Versioning can help in developing a lightweight The use of Map-Versioning can help in developing a lightweight
implementation of LISP. This comes with the price of not supporting implementation of LISP. This comes with the price of not supporting
Loc-Status-Bit, which are useful in some contexts. Loc-Status-Bit, which are useful in some contexts.
skipping to change at page 15, line 44 skipping to change at page 16, line 24
information is already included in the Map Record. information is already included in the Map Record.
Map-Versioning is currently implemented in OpenLISP Map-Versioning is currently implemented in OpenLISP
[I-D.iannone-openlisp-implementation]. [I-D.iannone-openlisp-implementation].
Note that the reference document for LISP implementation and Note that the reference document for LISP implementation and
interoperability tests remains [I-D.ietf-lisp]. interoperability tests remains [I-D.ietf-lisp].
10. Security Considerations 10. Security Considerations
Map-Versioning does not introduce any new security issue concerning Map-Versioning does not introduce any security issue concerning both
both the data-plane and the control-plane. On the contrary, as the data-plane and the control-plane. On the contrary, as described
described in the following, if Map-Versioning may be used also to in the following, if Map-Versioning may be used also to update
update mappings in case of change in the reachability information mappings in case of change in the reachability information (i.e.,
(i.e., instead of the Locator Status Bits) it is possible to reduce instead of the Locator Status Bits) it is possible to reduce the
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.
A thorough security analysis of LISP is documented in Robusteness of the Map-Versioning mechanism leverages on a trusted
[I-D.ietf-lisp-threats]. Mapping Distribution System. A thorough security analysis of LISP is
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.
This does not happen in the case of Map-Versioning. As described in This does not happen in the case of Map-Versioning. As described in
Section 5, upon a version number change the xTR first issues a Map- Section 5, upon a version number change the xTR first issues a Map-
skipping to change at page 17, line 30 skipping to change at page 18, line 13
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-14 (work in progress), June 2011. draft-ietf-lisp-15 (work in progress), July 2011.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
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-07 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-08
(work in progress), June 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",
draft-ietf-lisp-ms-09 (work in progress), June 2011. draft-ietf-lisp-ms-11 (work in progress), August 2011.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-00 (work in progress), Analysis", draft-ietf-lisp-threats-00 (work in progress),
July 2011. July 2011.
Appendix A. Estimation of time before Map-Version wrap-around Appendix A. Estimation of time before Map-Version wrap-around
The present section proposes an estimation of the wrap-around time The present section proposes an estimation of the wrap-around time
for the proposed 12 bits size for the Map-Version number. Using a for the proposed 12 bits size for the Map-Version number. Using a
skipping to change at page 19, line 26 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 03 Posted September 2011.
* Added reference in Section 7 toward the main lisp documents
specifying the section, as requested 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.
* Extentend all acronyms in the abstract as requested by Jari
Arkko.
* Clarified silent drop polocy in Section 5.2 as requested by
both Richard Barnes and Jari Arkko.
* Fixed typos pointed out by Richard Barnes.
o Version 02 Posted July 2011. o Version 02 Posted July 2011.
* Added text in Section 5 about ETR synchronization, as suggested * Added text in Section 5 about ETR synchronization, as suggested
by Alia Atlas. by Alia Atlas.
* Modified text in Section 8.5 concerning lightweight LISP * Modified text in Section 8.5 concerning lightweight LISP
implementation, as suggested by Alia Atlas. implementation, as suggested by Alia Atlas.
* Deleted text concerning old versions of [I-D.ietf-lisp-ms] and * Deleted text concerning old versions of [I-D.ietf-lisp-ms] and
[I-D.ietf-lisp-alt] in Section 7, as pointed out by Alia Atlas. [I-D.ietf-lisp-alt] in Section 7, as pointed out by Alia Atlas.
 End of changes. 28 change blocks. 
71 lines changed or deleted 99 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/