--- 1/draft-ietf-lisp-map-versioning-08.txt 2012-03-01 22:13:58.006671627 +0100 +++ 2/draft-ietf-lisp-map-versioning-09.txt 2012-03-01 22:13:58.050670830 +0100 @@ -1,21 +1,21 @@ Network Working Group L. Iannone Internet-Draft Telekom Innovation Laboratories Intended status: Experimental D. Saucez -Expires: August 17, 2012 INRIA Sophia Antipolis +Expires: September 2, 2012 INRIA Sophia Antipolis O. Bonaventure Universite catholique de Louvain - February 14, 2012 + March 1, 2012 LISP Map-Versioning - draft-ietf-lisp-map-versioning-08.txt + draft-ietf-lisp-map-versioning-09.txt Abstract This document describes the LISP (Locator/ID Separation Protocol) 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 associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to @@ -34,21 +34,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 17, 2012. + This Internet-Draft will expire on September 2, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -329,42 +329,43 @@ Since the ETR is authoritative on the mapping, meaning that the Map-Version number of its mapping is the correct one, this implies that someone is not behaving correctly with respect to 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 (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 - its EID-to-RLOC Cache containing stale information. The ITR - sending the packet has to be informed that a newer mapping is - available. This is done with a Map-Request message sent back to - the ITR. The Map-Request will either trigger a Map-Request back - using the Solicit-Map-Request (SMR) bit or it will piggyback the - newer mapping. These are not new mechanisms; how to SMR or - piggyback mappings in Map-Request messages is already described - in [I-D.ietf-lisp], while their security is discussed in - [I-D.ietf-lisp-threats]. These Map-Request messages should be - rate limited (rate limitation policies are also described in - [I-D.ietf-lisp]). The feature introduced by Map-Version numbers - is the possibility of blocking traffic not using the latest - mapping. Indeed, after a certain number of retries, if the - Destination Map-Version number in the packets is not updated, the - ETR MAY drop packets with a stale Map-Version number while - strongly reducing the rate of Map-Request messages. This because - 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. + its EID-to-RLOC Cache containing stale information. The ETR MAY + choose to normally process the encapsulated datagram according to + [I-D.ietf-lisp], however, the ITR sending the packet has to be + informed that a newer mapping is available. This is done with a + Map-Request message sent back to the ITR. The Map-Request will + either trigger a Map-Request back using the Solicit-Map-Request + (SMR) bit or it will piggyback the newer mapping. These are not + new mechanisms; how to SMR or piggyback mappings in Map-Request + messages is already described in [I-D.ietf-lisp], while their + security is discussed in [I-D.ietf-lisp-threats]. These Map- + Request messages should be rate limited (rate limitation policies + are also described in [I-D.ietf-lisp]). The feature introduced + by Map-Version numbers is the possibility of blocking traffic not + using the latest mapping. Indeed, after a certain number of + retries, if the Destination Map-Version number in the packets is + not updated, the ETR MAY drop packets with a stale Map-Version + number while strongly reducing the rate of Map-Request messages. + This because 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 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 arriving with an old Map-Version SHOULD be silently dropped right away without issuing any Map-Request. The reason that allows such 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 the older mapping, all the entries in the EID-to-RLOC Caches of ITRs must have expired. Hence, all ITRs sending traffic should have @@ -848,21 +849,21 @@ 14.1. Normative References [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-22 (work in progress), February 2012. [I-D.ietf-lisp-interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", - draft-ietf-lisp-interworking-03 (work in progress), + draft-ietf-lisp-interworking-05 (work in progress), February 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 14.2. Informative References [I-D.iannone-openlisp-implementation] Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Implementation Report", @@ -923,20 +924,26 @@ | 16 | 45 Days | 18 Hours | | 15 | 22 Days | 9 Hours | | 14 | 11 Days | 4 Hours | | 13 | 5.6 Days | 2.2 Hours | | 12 | 2.8 Days | 1.1 Hours | +---------------+---------------------+----------------------+ Figure 5: Estimation of time before wrap-around Appendix B. Document Change Log + o Version 09 Posted March 2012. + + * Text in Section 5.1 made more explicit in the case of smaller + (i.e., older) Destination Map-Version Number, as pointed out by + Ralph E. Droms. + o Version 08 Posted Ferbruary 2012. * Clarifications added to Appendix A as requested by S. Bryant. o Version 07 Posted January 2012. * Moved Subsection 8.1 in Section 12 as requested by R. Bonica. * Added explicit reference to the discussion about ETR synchronization at the end of the Introduction, as requested by