draft-ietf-lisp-rfc6830bis-09.txt   draft-ietf-lisp-rfc6830bis-10.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Standards Track D. Meyer Intended status: Standards Track D. Meyer
Expires: August 17, 2018 D. Lewis Expires: September 5, 2018 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
February 13, 2018 March 4, 2018
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-09 draft-ietf-lisp-rfc6830bis-10
Abstract Abstract
This document describes the data-plane protocol for the Locator/ID This document describes the data-plane protocol for the Locator/ID
Separation Protocol (LISP). LISP defines two namespaces, End-point Separation Protocol (LISP). LISP defines two namespaces, End-point
Identifiers (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and Routing Locators
(RLOCs) that identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. With this, LISP
effectively separates control from data, and allows routers to create effectively separates control from data, and allows routers to create
overlay networks. LISP-capable routers exchange encapsulated packets overlay networks. LISP-capable routers exchange encapsulated packets
according to EID-to-RLOC mappings stored in a local map-cache. according to EID-to-RLOC mappings stored in a local map-cache.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 17, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 38 skipping to change at page 2, line 38
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19
7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 20
7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21
8. Using Virtualization and Segmentation with LISP . . . . . . . 22 8. Using Virtualization and Segmentation with LISP . . . . . . . 22
9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25
10.2. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 28 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 28 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 29 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 30
13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 31 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30
13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 15. Router Performance Considerations . . . . . . . . . . . . . . 31
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 32
15. Router Performance Considerations . . . . . . . . . . . . . . 34 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 32
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 35 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 32
16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 35 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 33
16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 35 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 33
16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 36 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 35
17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 35
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 36
17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 38 17.4. LISP Functionality with Conventional NATs . . . . . . . 36
17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 37
17.4. LISP Functionality with Conventional NATs . . . . . . . 39 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 37
17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 38
18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 40 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 38
18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 41 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 39
18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 41 19. Security Considerations . . . . . . . . . . . . . . . . . . . 39
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42 20. Network Management Considerations . . . . . . . . . . . . . . 40
19. Security Considerations . . . . . . . . . . . . . . . . . . . 42 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
20. Network Management Considerations . . . . . . . . . . . . . . 43 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 40
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 43 22.1. Normative References . . . . . . . . . . . . . . . . . . 40
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 22.2. Informative References . . . . . . . . . . . . . . . . . 41
22.1. Normative References . . . . . . . . . . . . . . . . . . 43 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46
22.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 49 B.1. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 47
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 49 B.2. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 47
B.1. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 50 B.3. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 47
B.2. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 50 B.4. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 48
B.3. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 50 B.5. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 48
B.4. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 50 B.6. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 48
B.5. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 51 B.7. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 48
B.6. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 51 B.8. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 49
B.7. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 51 B.9. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 49
B.8. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 51 B.10. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 49
B.9. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 51 B.11. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 49
B.10. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
(LISP). LISP is an encapsulation protocol built around the (LISP). LISP is an encapsulation protocol built around the
fundamental idea of separating the topological location of a network fundamental idea of separating the topological location of a network
attachment point from the node's identity [CHIAPPA]. As a result attachment point from the node's identity [CHIAPPA]. As a result
LISP creates two namespaces: Endpoint Identifiers (EIDs), that are LISP creates two namespaces: Endpoint Identifiers (EIDs), that are
used to identify end-hosts (e.g., nodes or Virtual Machines) and used to identify end-hosts (e.g., nodes or Virtual Machines) and
routable Routing Locators (RLOCs), used to identify network routable Routing Locators (RLOCs), used to identify network
skipping to change at page 16, line 31 skipping to change at page 16, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored
and has no meaning when the N-bit is set to 0. When the N-bit is and has no meaning when the N-bit is set to 0. When the N-bit is
set to 1 and this bit is set to 1, an ITR is requesting that the set to 1 and this bit is set to 1, an ITR is requesting that the
nonce value in the 'Nonce' field be echoed back in LISP- nonce value in the 'Nonce' field be echoed back in LISP-
encapsulated packets when the ITR is also an ETR. See encapsulated packets when the ITR is also an ETR. See
Section 10.1 for details. Section 10.1 for details.
V: The V-bit is the Map-Version present bit. When this bit is set to V: The V-bit is the Map-Version present bit. When this bit is set to
1, the N-bit MUST be 0. Refer to Section 13.3 for more details. 1, the N-bit MUST be 0. Refer to Section 13.2 for more details.
This bit indicates that the LISP header is encoded in this This bit indicates that the LISP header is encoded in this
case as: case as:
0 x 0 1 x x x x 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits | | Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 39 skipping to change at page 22, line 39
details. details.
The Instance ID that is stored in the mapping database when LISP-DDT The Instance ID that is stored in the mapping database when LISP-DDT
[RFC8111] is used is 32 bits in length. That means the control-plane [RFC8111] is used is 32 bits in length. That means the control-plane
can store more instances than a given data-plane can use. Multiple can store more instances than a given data-plane can use. Multiple
data-planes can use the same 32-bit space as long as the low-order 24 data-planes can use the same 32-bit space as long as the low-order 24
bits don't overlap among xTRs. bits don't overlap among xTRs.
9. Routing Locator Selection 9. Routing Locator Selection
Both the client-side and server-side MAY need control over the The map-cache contains the state used by ITRs and PITRs to
selection of RLOCs for conversations between them. This control is encapsulate packets. When an ITR/PITR receives a packet from inside
achieved by manipulating the 'Priority' and 'Weight' fields in EID- the LISP site to a destination outside of the site a longest-prefix
to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be match lookup of the EID is done to the map-cache (see Section 6).
gleaned from received tunneled packets or EID-to-RLOC Map-Request The lookup returns a single Locator-Set containing a list of RLOCs
messages. corresponding to the EID's topological location. Each RLOC in the
Locator-Set is associated with a 'Priority' and 'Weight', this
information is used to select the RLOC to encapsulate.
The RLOC with the lowest 'Priority' is selected. An RLOC with
'Priority' 255 means that MUST NOT be used for forwarding. When
multiple RLOC have the same 'Priority' then the 'Weight' states how
to load balance traffic among them. The value of the 'Weight'
represents the relative weight of the total packets that match the
maping entry.
The following are different scenarios for choosing RLOCs and the The following are different scenarios for choosing RLOCs and the
controls that are available: controls that are available:
o The server-side returns one RLOC. The client-side can only use o The server-side returns one RLOC. The client-side can only use
one RLOC. The server-side has complete control of the selection. one RLOC. The server-side has complete control of the selection.
o The server-side returns a list of RLOCs where a subset of the list o The server-side returns a list of RLOCs where a subset of the list
has the same best Priority. The client can only use the subset has the same best Priority. The client can only use the subset
list according to the weighting assigned by the server-side. In list according to the weighting assigned by the server-side. In
skipping to change at page 23, line 40 skipping to change at page 23, line 48
outer-header source RLOC of received packets. The client-side ITR outer-header source RLOC of received packets. The client-side ITR
controls how traffic is returned and can alternate using an outer- controls how traffic is returned and can alternate using an outer-
header source RLOC, which then can be added to the list the header source RLOC, which then can be added to the list the
server-side ETR uses to return traffic. Since no Priority or server-side ETR uses to return traffic. Since no Priority or
Weights are provided using this method, the server-side ETR MUST Weights are provided using this method, the server-side ETR MUST
assume that each client-side ITR RLOC uses the same best Priority assume that each client-side ITR RLOC uses the same best Priority
with a Weight of zero. In addition, since EID-Prefix encoding with a Weight of zero. In addition, since EID-Prefix encoding
cannot be conveyed in data packets, the EID-to-RLOC Cache on cannot be conveyed in data packets, the EID-to-RLOC Cache on
Tunnel Routers can grow to be very large. Tunnel Routers can grow to be very large.
o A "gleaned" Map-Cache entry, one learned from the source RLOC of a Alternatively, RLOC information MAY be gleaned from received tunneled
received encapsulated packet, is only stored and used for a few packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache
seconds, pending verification. Verification is performed by entry, one learned from the source RLOC of a received encapsulated
sending a Map-Request to the source EID (the inner-header IP packet, is only stored and used for a few seconds, pending
source address) of the received encapsulated packet. A reply to verification. Verification is performed by sending a Map-Request to
this "verifying Map-Request" is used to fully populate the Map- the source EID (the inner-header IP source address) of the received
Cache entry for the "gleaned" EID and is stored and used for the encapsulated packet. A reply to this "verifying Map-Request" is used
time indicated from the 'TTL' field of a received Map-Reply. When to fully populate the Map-Cache entry for the "gleaned" EID and is
a verified Map-Cache entry is stored, data gleaning no longer stored and used for the time indicated from the 'TTL' field of a
occurs for subsequent packets that have a source EID that matches received Map-Reply. When a verified Map-Cache entry is stored, data
the EID-Prefix of the verified entry. This "gleaning" mechanism gleaning no longer occurs for subsequent packets that have a source
is OPTIONAL. EID that matches the EID-Prefix of the verified entry. This
"gleaning" mechanism is OPTIONAL, refer to Section 19 for security
issues regarding this mechanism.
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
reachable when the R-bit for the Locator record is set to 1. When reachable when the R-bit for the Locator record is set to 1. When
the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the
RLOC. Neither the information contained in a Map-Reply nor that RLOC. Neither the information contained in a Map-Reply nor that
stored in the mapping database system provides reachability stored in the mapping database system provides reachability
information for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not part of the
mapping system and is determined using one or more of the Routing mapping system and is determined using one or more of the Routing
Locator reachability algorithms described in the next section. Locator reachability algorithms described in the next section.
10. Routing Locator Reachability 10. Routing Locator Reachability
Several mechanisms for determining RLOC reachability are currently Several data-plane mechanisms for determining RLOC reachability are
defined: currently defined. Please note that additional control-plane based
reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis].
1. An ETR MAY examine the Locator-Status-Bits in the LISP header of 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of
an encapsulated data packet received from an ITR. If the ETR is an encapsulated data packet received from an ITR. If the ETR is
also acting as an ITR and has traffic to return to the original also acting as an ITR and has traffic to return to the original
ITR site, it can use this status information to help select an ITR site, it can use this status information to help select an
RLOC. RLOC.
2. An ITR MAY receive an ICMP Network Unreachable or Host 2. When an ETR receives an encapsulated packet from an ITR, the
Unreachable message for an RLOC it is using. This indicates that
the RLOC is likely down. Note that trusting ICMP messages may
not be desirable, but neither is ignoring them completely.
Implementations are encouraged to follow current best practices
in treating these conditions [I-D.ietf-opsec-icmp-filtering].
3. When an ITR participates in the routing protocol that operates in
the underlay routing system, it can determine that an RLOC is
down when no Routing Information Base (RIB) entry exists that
matches the RLOC IP address.
4. An ITR MAY receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use
interworking [RFC6832] and LISP-encapsulated data is sent to a
non-LISP-capable site.
5. An ITR MAY receive a Map-Reply from an ETR in response to a
previously sent Map-Request. The RLOC source of the Map-Reply is
likely up, since the ETR was able to send the Map-Reply to the
ITR.
6. When an ETR receives an encapsulated packet from an ITR, the
source RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet is likely up.
7. An ITR/ETR pair can use the Locator reachability algorithms 3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability
described in this section, namely Echo-Noncing or RLOC-Probing. algorithms described in this section.
When determining Locator up/down reachability by examining the When determining Locator up/down reachability by examining the
Locator-Status-Bits from the LISP-encapsulated data packet, an ETR Locator-Status-Bits from the LISP-encapsulated data packet, an ETR
will receive up-to-date status from an encapsulating ITR about will receive up-to-date status from an encapsulating ITR about
reachability for all ETRs at the site. CE-based ITRs at the source reachability for all ETRs at the site. CE-based ITRs at the source
site can determine reachability relative to each other using the site site can determine reachability relative to each other using the site
IGP as follows: IGP as follows:
o Under normal circumstances, each ITR will advertise a default o Under normal circumstances, each ITR will advertise a default
route into the site IGP. route into the site IGP.
o If an ITR fails or if the upstream link to its PE fails, its o If an ITR fails or if the upstream link to its PE fails, its
default route will either time out or be withdrawn. default route will either time out or be withdrawn.
Each ITR can thus observe the presence or lack of a default route Each ITR can thus observe the presence or lack of a default route
originated by the others to determine the Locator-Status-Bits it sets originated by the others to determine the Locator-Status-Bits it sets
for them. for them.
When ITRs at the site are not deployed in CE routers, the IGP can
still be used to determine the reachability of Locators, provided
they are injected into the IGP. This is typically done when a /32
address is configured on a loopback interface.
RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The
Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0
to n-1 starting with the least significant bit. For example, if an to n-1 starting with the least significant bit. For example, if an
RLOC listed in the 3rd position of the Map-Reply goes down (ordinal RLOC listed in the 3rd position of the Map-Reply goes down (ordinal
value 2), then all ITRs at the site will clear the 3rd least value 2), then all ITRs at the site will clear the 3rd least
significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for
the packets they encapsulate. the packets they encapsulate.
When an ETR decapsulates a packet, it will check for any change in When an ETR decapsulates a packet, it will check for any change in
the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the
ETR, if acting also as an ITR, will refrain from encapsulating ETR, if acting also as an ITR, will refrain from encapsulating
packets to an RLOC that is indicated as down. It will only resume packets to an RLOC that is indicated as down. It will only resume
using that RLOC if the corresponding Locator-Status-Bit returns to a using that RLOC if the corresponding Locator-Status-Bit returns to a
value of 1. Locator-Status-Bits are associated with a Locator-Set value of 1. Locator-Status-Bits are associated with a Locator-Set
per EID-Prefix. Therefore, when a Locator becomes unreachable, the per EID-Prefix. Therefore, when a Locator becomes unreachable, the
Locator-Status-Bit that corresponds to that Locator's position in the Locator-Status-Bit that corresponds to that Locator's position in the
list returned by the last Map-Reply will be set to zero for that list returned by the last Map-Reply will be set to zero for that
particular EID-Prefix. Refer to Section 19 for security related particular EID-Prefix. Refer to Section 19 for security related
issues regarding Locator-Status-Bits. issues regarding Locator-Status-Bits.
When ITRs at the site are not deployed in CE routers, the IGP can
still be used to determine the reachability of Locators, provided
they are injected into the IGP. This is typically done when a /32
address is configured on a loopback interface.
When ITRs receive ICMP Network Unreachable or Host Unreachable
messages as a method to determine unreachability, they will refrain
from using Locators that are described in Locator lists of Map-
Replies. However, using this approach is unreliable because many
network operators turn off generation of ICMP Destination Unreachable
messages.
If an ITR does receive an ICMP Network Unreachable or Host
Unreachable message, it MAY originate its own ICMP Destination
Unreachable message destined for the host that originated the data
packet the ITR encapsulated.
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
locator address from a Locator-Set in a mapping entry matches a
prefix. If it does not find one and BGP is running in the Default-
Free Zone (DFZ), it can decide to not use the Locator even though the
Locator-Status-Bits indicate that the Locator is up. In this case,
the path from the ITR to the ETR that is assigned the Locator is not
available. More details are in [I-D.meyer-loc-id-implications].
Optionally, an ITR can send a Map-Request to a Locator, and if a Map-
Reply is returned, reachability of the Locator has been determined.
Obviously, sending such probes increases the number of control
messages originated by Tunnel Routers for active flows, so Locators
are assumed to be reachable when they are advertised.
This assumption does create a dependency: Locator unreachability is
detected by the receipt of ICMP Host Unreachable messages. When a
Locator has been determined to be unreachable, it is not used for
active traffic; this is the same as if it were listed in a Map-Reply
with Priority 255.
The ITR can test the reachability of the unreachable Locator by
sending periodic Requests. Both Requests and Replies MUST be rate-
limited. Locator reachability testing is never done with data
packets, since that increases the risk of packet loss for end-to-end
sessions.
When an ETR decapsulates a packet, it knows that it is reachable from When an ETR decapsulates a packet, it knows that it is reachable from
the encapsulating ITR because that is how the packet arrived. In the encapsulating ITR because that is how the packet arrived. In
most cases, the ETR can also reach the ITR but cannot assume this to most cases, the ETR can also reach the ITR but cannot assume this to
be true, due to the possibility of path asymmetry. In the presence be true, due to the possibility of path asymmetry. In the presence
of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD
NOT use the lack of return traffic as an indication that the ETR is NOT use the lack of return traffic as an indication that the ETR is
unreachable. Instead, it MUST use an alternate mechanism to unreachable. Instead, it MUST use an alternate mechanism to
determine reachability. determine reachability.
10.1. Echo Nonce Algorithm 10.1. Echo Nonce Algorithm
skipping to change at page 27, line 48 skipping to change at page 27, line 5
unidirectional so there is no ITR returning traffic. unidirectional so there is no ITR returning traffic.
The echo-nonce algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if one side sets the
E-bit and the other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for echo-noncing, then the
echoing of the nonce does not occur and the requesting side may echoing of the nonce does not occur and the requesting side may
erroneously consider the Locator unreachable. An ITR SHOULD only set erroneously consider the Locator unreachable. An ITR SHOULD only set
the E-bit in an encapsulated data packet when it knows the ETR is the E-bit in an encapsulated data packet when it knows the ETR is
enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- enabled for echo-noncing. This is conveyed by the E-bit in the RLOC-
probe Map-Reply message. probe Map-Reply message.
Note other Locator Reachability mechanisms can be used to compliment
or even override the echo nonce algorithm. See the next section for
an example of control-plane probing.
10.2. RLOC-Probing Algorithm
RLOC-Probing is a method that an ITR or PITR can use to determine the
reachability status of one or more Locators that it has cached in a
Map-Cache entry. The probe-bit of the Map-Request and Map-Reply
messages is used for RLOC-Probing.
RLOC-Probing is done in the control plane on a timer basis, where an
ITR or PITR will originate a Map-Request destined to a locator
address from one of its own locator addresses. A Map-Request used as
an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to
the mapping database system as one would when soliciting mapping
data. The EID record encoded in the Map-Request is the EID-Prefix of
the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data record for its own database mapping information that
contains the local EID-Prefixes and RLOCs for its site. RLOC-probes
are sent periodically using a jittered timer interval.
When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set according to the procedure described in
[I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping
data for the EID-Prefix contained in the Map-Request. This provides
the opportunity for the ITR or PITR that sent the RLOC-probe to get
mapping updates if there were changes to the ETR's database mapping
entries.
There are advantages and disadvantages of RLOC-Probing. The greatest
benefit of RLOC-Probing is that it can handle many failure scenarios
allowing the ITR to determine when the path to a specific Locator is
reachable or has become unreachable, thus providing a robust
mechanism for switching to using another Locator from the cached
Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT)
estimates between a pair of Locators, which can be useful for network
management purposes as well as for selecting low delay paths. The
major disadvantage of RLOC-Probing is in the number of control
messages required and the amount of bandwidth used to obtain those
benefits, especially if the requirement for failure detection times
is very small.
11. EID Reachability within a LISP Site 11. EID Reachability within a LISP Site
A site MAY be multihomed using two or more ETRs. The hosts and A site MAY be multihomed using two or more ETRs. The hosts and
infrastructure within a site will be addressed using one or more EID- infrastructure within a site will be addressed using one or more EID-
Prefixes that are mapped to the RLOCs of the relevant ETRs in the Prefixes that are mapped to the RLOCs of the relevant ETRs in the
mapping system. One possible failure mode is for an ETR to lose mapping system. One possible failure mode is for an ETR to lose
reachability to one or more of the EID-Prefixes within its own site. reachability to one or more of the EID-Prefixes within its own site.
When this occurs when the ETR sends Map-Replies, it can clear the When this occurs when the ETR sends Map-Replies, it can clear the
R-bit associated with its own Locator. And when the ETR is also an R-bit associated with its own Locator. And when the ETR is also an
ITR, it can clear its Locator-Status-Bit in the encapsulation data ITR, it can clear its Locator-Status-Bit in the encapsulation data
skipping to change at page 30, line 25 skipping to change at page 28, line 33
Since the LISP architecture uses a caching scheme to retrieve and Since the LISP architecture uses a caching scheme to retrieve and
store EID-to-RLOC mappings, the only way an ITR can get a more up-to- store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
date mapping is to re-request the mapping. However, the ITRs do not date mapping is to re-request the mapping. However, the ITRs do not
know when the mappings change, and the ETRs do not keep track of know when the mappings change, and the ETRs do not keep track of
which ITRs requested its mappings. For scalability reasons, it is which ITRs requested its mappings. For scalability reasons, it is
desirable to maintain this approach but need to provide a way for desirable to maintain this approach but need to provide a way for
ETRs to change their mappings and inform the sites that are currently ETRs to change their mappings and inform the sites that are currently
communicating with the ETR site using such mappings. communicating with the ETR site using such mappings.
This section defines data-plane mechanisms for updating EID-to-RLOC
mappings. Additionally, the Solicit-Map Request (SMR) control-plane
updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis].
When adding a new Locator record in lexicographic order to the end of When adding a new Locator record in lexicographic order to the end of
a Locator-Set, it is easy to update mappings. We assume that new a Locator-Set, it is easy to update mappings. We assume that new
mappings will maintain the same Locator ordering as the old mapping mappings will maintain the same Locator ordering as the old mapping
but will just have new Locators appended to the end of the list. So, but will just have new Locators appended to the end of the list. So,
some ITRs can have a new mapping while other ITRs have only an old some ITRs can have a new mapping while other ITRs have only an old
mapping that is used until they time out. When an ITR has only an mapping that is used until they time out. When an ITR has only an
old mapping but detects bits set in the Locator-Status-Bits that old mapping but detects bits set in the Locator-Status-Bits that
correspond to Locators beyond the list it has cached, it simply correspond to Locators beyond the list it has cached, it simply
ignores them. However, this can only happen for locator addresses ignores them. However, this can only happen for locator addresses
that are lexicographically greater than the locator addresses in the that are lexicographically greater than the locator addresses in the
existing Locator-Set. existing Locator-Set.
When a Locator record is inserted in the middle of a Locator-Set, to When a Locator record is inserted in the middle of a Locator-Set, to
maintain lexicographic order, the SMR procedure in Section 13.2 is maintain lexicographic order, SMR procedure
used to inform ITRs and PITRs of the new Locator-Status-Bit mappings. [I-D.ietf-lisp-rfc6833bis] is used to inform ITRs and PITRs of the
new Locator-Status-Bit mappings.
When a Locator record is removed from a Locator-Set, ITRs that have When a Locator record is removed from a Locator-Set, ITRs that have
the mapping cached will not use the removed Locator because the xTRs the mapping cached will not use the removed Locator because the xTRs
will set the Locator-Status-Bit to 0. So, even if the Locator is in will set the Locator-Status-Bit to 0. So, even if the Locator is in
the list, it will not be used. For new mapping requests, the xTRs the list, it will not be used. For new mapping requests, the xTRs
can set the Locator AFI to 0 (indicating an unspecified address), as can set the Locator AFI to 0 (indicating an unspecified address), as
well as setting the corresponding Locator-Status-Bit to 0. This well as setting the corresponding Locator-Status-Bit to 0. This
forces ITRs with old or new mappings to avoid using the removed forces ITRs with old or new mappings to avoid using the removed
Locator. Locator.
If many changes occur to a mapping over a long period of time, one If many changes occur to a mapping over a long period of time, one
will find empty record slots in the middle of the Locator-Set and new will find empty record slots in the middle of the Locator-Set and new
records appended to the Locator-Set. At some point, it would be records appended to the Locator-Set. At some point, it would be
useful to compact the Locator-Set so the Locator-Status-Bit settings useful to compact the Locator-Set so the Locator-Status-Bit settings
can be efficiently packed. can be efficiently packed.
We propose here three approaches for Locator-Set compaction: one We propose here two approaches for Locator-Set compaction: one
operational mechanism and two protocol mechanisms. The operational operational mechanism (clock sweep) and one protocol mechanisms (Map-
approach uses a clock sweep method. The protocol approaches use the Versioning). Please note that in addition the Solicit-Map Request
concept of Solicit-Map-Requests and Map-Versioning. (specified in [I-D.ietf-lisp-rfc6833bis]) is a control-plane
mechanisms that can be used to update EID-to-RLOC mappings.
13.1. Clock Sweep 13.1. Clock Sweep
The clock sweep approach uses planning in advance and the use of The clock sweep approach uses planning in advance and the use of
count-down TTLs to time out mappings that have already been cached. count-down TTLs to time out mappings that have already been cached.
The default setting for an EID-to-RLOC mapping TTL is 24 hours. So, The default setting for an EID-to-RLOC mapping TTL is 24 hours. So,
there is a 24-hour window to time out old mappings. The following there is a 24-hour window to time out old mappings. The following
clock sweep procedure is used: clock sweep procedure is used:
1. 24 hours before a mapping change is to take effect, a network 1. 24 hours before a mapping change is to take effect, a network
skipping to change at page 31, line 41 skipping to change at page 30, line 5
this 1-hour window, the ETRs continue to send Map-Reply messages this 1-hour window, the ETRs continue to send Map-Reply messages
with the current (unchanged) mapping records with the TTL set to with the current (unchanged) mapping records with the TTL set to
1 minute. 1 minute.
4. At the end of the 1-hour window, the ETRs will send Map-Reply 4. At the end of the 1-hour window, the ETRs will send Map-Reply
messages with the new (changed) mapping records. So, any active messages with the new (changed) mapping records. So, any active
caches can get the new mapping contents right away if not cached, caches can get the new mapping contents right away if not cached,
or in 1 minute if they had the mapping cached. The new mappings or in 1 minute if they had the mapping cached. The new mappings
are cached with a TTL equal to the TTL in the Map-Reply. are cached with a TTL equal to the TTL in the Map-Reply.
13.2. Solicit-Map-Request (SMR) 13.2. Database Map-Versioning
Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached.
Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending
encapsulated data for the last minute. In particular, an ETR will
send an SMR to an ITR to which it has recently sent encapsulated
data. This can only occur when both ITR and ETR functionality reside
in the same router.
An SMR message is simply a bit set in a Map-Request message. An ITR
or PITR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder MUST rate-limit
these messages. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination.
The following procedure shows how an SMR exchange occurs when a site
is doing Locator-Set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each Locator
in each Map-Cache entry the ETR caches.
2. A remote ITR that receives the SMR message will schedule sending
a Map-Request message to the source locator address of the SMR
message or to the mapping database system. A newly allocated
random nonce is selected, and the EID-Prefix used is the one
copied from the SMR message. If the source Locator is the only
Locator in the cached Locator-Set, the remote ITR SHOULD send a
Map-Request to the database mapping system just in case the
single Locator has changed and may no longer be reachable to
accept the Map-Request.
3. The remote ITR MUST rate-limit the Map-Request until it gets a
Map-Reply while continuing to use the cached mapping. When
Map-Versioning as described in Section 13.3 is used, an SMR
sender can detect if an ITR is using the most up-to-date database
mapping.
4. The ETRs at the site with the changed mapping will reply to the
Map-Request with a Map-Reply message that has a nonce from the
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate-
limited. This is important to avoid Map-Reply implosion.
5. The ETRs at the site with the changed mapping record the fact
that the site that sent the Map-Request has received the new
mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR
messages.
For security reasons, an ITR MUST NOT process unsolicited Map-
Replies. To avoid Map-Cache entry corruption by a third party, a
sender of an SMR-based Map-Request MUST be verified. If an ITR
receives an SMR-based Map-Request and the source is not in the
Locator-Set for the stored Map-Cache entry, then the responding Map-
Request MUST be sent with an EID destination to the mapping database
system. Since the mapping database system is a more secure way to
reach an authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data.
When an ITR receives an SMR-based Map-Request for which it does not
have a cached mapping for the EID in the SMR message, it may not send
an SMR-invoked Map-Request. This scenario can occur when an ETR
sends SMR messages to all Locators in the Locator-Set it has stored
in its map-cache but the remote ITRs that receive the SMR may not be
sending packets to the site. There is no point in updating the ITRs
until they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry.
13.3. Database Map-Versioning
When there is unidirectional packet flow between an ITR and ETR, and When there is unidirectional packet flow between an ITR and ETR, and
the EID-to-RLOC mappings change on the ETR, it needs to inform the the EID-to-RLOC mappings change on the ETR, it needs to inform the
ITR so encapsulation to a removed Locator can stop and can instead be ITR so encapsulation to a removed Locator can stop and can instead be
started to a new Locator in the Locator-Set. started to a new Locator in the Locator-Set.
An ETR, when it sends Map-Reply messages, conveys its own Map-Version An ETR, when it sends Map-Reply messages, conveys its own Map-Version
Number. This is known as the Destination Map-Version Number. ITRs Number. This is known as the Destination Map-Version Number. ITRs
include the Destination Map-Version Number in packets they include the Destination Map-Version Number in packets they
encapsulate to the site. When an ETR decapsulates a packet and encapsulate to the site. When an ETR decapsulates a packet and
detects that the Destination Map-Version Number is less than the detects that the Destination Map-Version Number is less than the
current version for its mapping, the SMR procedure described in current version for its mapping, the SMR procedure described in
Section 13.2 occurs. [I-D.ietf-lisp-rfc6833bis] occurs.
An ITR, when it encapsulates packets to ETRs, can convey its own Map- An ITR, when it encapsulates packets to ETRs, can convey its own Map-
Version Number. This is known as the Source Map-Version Number. Version Number. This is known as the Source Map-Version Number.
When an ETR decapsulates a packet and detects that the Source Map- When an ETR decapsulates a packet and detects that the Source Map-
Version Number is greater than the last Map-Version Number sent in a Version Number is greater than the last Map-Version Number sent in a
Map-Reply from the ITR's site, the ETR will send a Map-Request to one Map-Reply from the ITR's site, the ETR will send a Map-Request to one
of the ETRs for the source site. of the ETRs for the source site.
A Map-Version Number is used as a sequence number per EID-Prefix, so A Map-Version Number is used as a sequence number per EID-Prefix, so
values that are greater are considered to be more recent. A value of values that are greater are considered to be more recent. A value of
skipping to change at page 44, line 19 skipping to change at page 41, line 5
2017. 2017.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
22.2. Informative References 22.2. Informative References
[AFN] IANA, "Address Family Numbers", August 2016, [AFN] IANA, "Address Family Numbers", August 2016,
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
skipping to change at page 46, line 17 skipping to change at page 42, line 22
RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in RLOCs", draft-ietf-lisp-predictive-rlocs-01 (work in
progress), November 2017. progress), November 2017.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), October 2017. (work in progress), October 2017.
[I-D.ietf-lisp-signal-free-multicast] [I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-07 (work in draft-ietf-lisp-signal-free-multicast-08 (work in
progress), November 2017. progress), February 2018.
[I-D.ietf-lisp-vpn] [I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in Networks (VPNs)", draft-ietf-lisp-vpn-01 (work in
progress), November 2017. progress), November 2017.
[I-D.ietf-opsec-icmp-filtering]
Gont, F., Gont, G., and C. Pignataro, "Recommendations for
filtering ICMP messages", draft-ietf-opsec-icmp-
filtering-04 (work in progress), July 2013.
[I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009.
[LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin, [LISA96] Lear, E., Tharp, D., Katinsky, J., and J. Coffin,
"Renumbering: Threat or Menace?", Usenix Tenth System "Renumbering: Threat or Menace?", Usenix Tenth System
Administration Conference (LISA 96), October 1996. Administration Conference (LISA 96), October 1996.
[OPENLISP] [OPENLISP]
Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP
Implementation Report", Work in Progress, July 2008. Implementation Report", Work in Progress, July 2008.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
skipping to change at page 47, line 24 skipping to change at page 43, line 29
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005, DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, Optimization for Mobile IPv6", RFC 4866,
DOI 10.17487/RFC4866, May 2007, DOI 10.17487/RFC4866, May 2007,
<https://www.rfc-editor.org/info/rfc4866>. <https://www.rfc-editor.org/info/rfc4866>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>. <https://www.rfc-editor.org/info/rfc4984>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised",
RFC 5944, DOI 10.17487/RFC5944, November 2010,
<https://www.rfc-editor.org/info/rfc5944>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
skipping to change at page 48, line 31 skipping to change at page 44, line 42
Separation Protocol (LISP) MIB", RFC 7052, Separation Protocol (LISP) MIB", RFC 7052,
DOI 10.17487/RFC7052, October 2013, DOI 10.17487/RFC7052, October 2013,
<https://www.rfc-editor.org/info/rfc7052>. <https://www.rfc-editor.org/info/rfc7052>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>. 2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>. <https://www.rfc-editor.org/info/rfc7835>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>. February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017, DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>. <https://www.rfc-editor.org/info/rfc8061>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed reviews of the LISP of location and identity, as well as detailed reviews of the LISP
architecture and documents, coupled with enthusiasm for making LISP a architecture and documents, coupled with enthusiasm for making LISP a
skipping to change at page 50, line 5 skipping to change at page 47, line 5
The LISP working group would like to give a special thanks to Jari The LISP working group would like to give a special thanks to Jari
Arkko, the Internet Area AD at the time that the set of LISP Arkko, the Internet Area AD at the time that the set of LISP
documents were being prepared for IESG last call, and for his documents were being prepared for IESG last call, and for his
meticulous reviews and detailed commentaries on the 7 working group meticulous reviews and detailed commentaries on the 7 working group
last call documents progressing toward standards-track RFCs. last call documents progressing toward standards-track RFCs.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6830bis-09 B.1. Changes to draft-ietf-lisp-rfc6830bis-10
o Posted March 2018.
o Updated section 'Router Locator Selection' stating that the data-
plane MUST follow what's stored in the map-cache (priorities and
weights).
o Section 'Routing Locator Reachability': Removed bullet point 2
(ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port
Unreachable),5 (receive a Map-Reply as a response) and RLOC
probing
o Removed 'Solicit-Map Request'.
B.2. Changes to draft-ietf-lisp-rfc6830bis-09
o Posted January 2018. o Posted January 2018.
o Add more details in section 5.3 about DSCP processing during o Add more details in section 5.3 about DSCP processing during
encapsulation and decapsulation. encapsulation and decapsulation.
o Added clarity to definitions in the Definition of Terms section o Added clarity to definitions in the Definition of Terms section
from various commenters. from various commenters.
o Removed PA and PI definitions from Definition of Terms section. o Removed PA and PI definitions from Definition of Terms section.
o More editorial changes. o More editorial changes.
o Removed 4342 from IANA section and move to RFC6833 IANA section. o Removed 4342 from IANA section and move to RFC6833 IANA section.
B.2. Changes to draft-ietf-lisp-rfc6830bis-08 B.3. Changes to draft-ietf-lisp-rfc6830bis-08
o Posted January 2018. o Posted January 2018.
o Remove references to research work for any protocol mechanisms. o Remove references to research work for any protocol mechanisms.
o Document scanned to make sure it is RFC 2119 compliant. o Document scanned to make sure it is RFC 2119 compliant.
o Made changes to reflect comments from document WG shepherd Luigi o Made changes to reflect comments from document WG shepherd Luigi
Iannone. Iannone.
o Ran IDNITs on the document. o Ran IDNITs on the document.
B.3. Changes to draft-ietf-lisp-rfc6830bis-07 B.4. Changes to draft-ietf-lisp-rfc6830bis-07
o Posted November 2017. o Posted November 2017.
o Rephrase how Instance-IDs are used and don't refer to [RFC1918] o Rephrase how Instance-IDs are used and don't refer to [RFC1918]
addresses. addresses.
B.4. Changes to draft-ietf-lisp-rfc6830bis-06 B.5. Changes to draft-ietf-lisp-rfc6830bis-06
o Posted October 2017. o Posted October 2017.
o Put RTR definition before it is used. o Put RTR definition before it is used.
o Rename references that are now working group drafts. o Rename references that are now working group drafts.
o Remove "EIDs MUST NOT be used as used by a host to refer to other o Remove "EIDs MUST NOT be used as used by a host to refer to other
hosts. Note that EID blocks MAY LISP RLOCs". hosts. Note that EID blocks MAY LISP RLOCs".
skipping to change at page 51, line 15 skipping to change at page 48, line 35
o ETRs may, rather than will, be the ones to send Map-Replies. o ETRs may, rather than will, be the ones to send Map-Replies.
o Recommend, rather than mandate, max encapsulation headers to 2. o Recommend, rather than mandate, max encapsulation headers to 2.
o Reference VPN draft when introducing Instance-ID. o Reference VPN draft when introducing Instance-ID.
o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Indicate that SMRs can be sent when ITR/ETR are in the same node.
o Clarify when private addreses can be used. o Clarify when private addreses can be used.
B.5. Changes to draft-ietf-lisp-rfc6830bis-05 B.6. Changes to draft-ietf-lisp-rfc6830bis-05
o Posted August 2017. o Posted August 2017.
o Make it clear that a Reencapsulating Tunnel Router is an RTR. o Make it clear that a Reencapsulating Tunnel Router is an RTR.
B.6. Changes to draft-ietf-lisp-rfc6830bis-04 B.7. Changes to draft-ietf-lisp-rfc6830bis-04
o Posted July 2017. o Posted July 2017.
o Changed reference of IPv6 RFC2460 to RFC8200. o Changed reference of IPv6 RFC2460 to RFC8200.
o Indicate that the applicability statement for UDP zero checksums o Indicate that the applicability statement for UDP zero checksums
over IPv6 adheres to RFC6936. over IPv6 adheres to RFC6936.
B.7. Changes to draft-ietf-lisp-rfc6830bis-03 B.8. Changes to draft-ietf-lisp-rfc6830bis-03
o Posted May 2017. o Posted May 2017.
o Move the control-plane related codepoints in the IANA o Move the control-plane related codepoints in the IANA
Considerations section to RFC6833bis. Considerations section to RFC6833bis.
B.8. Changes to draft-ietf-lisp-rfc6830bis-02 B.9. Changes to draft-ietf-lisp-rfc6830bis-02
o Posted April 2017. o Posted April 2017.
o Reflect some editorial comments from Damien Sausez. o Reflect some editorial comments from Damien Sausez.
B.9. Changes to draft-ietf-lisp-rfc6830bis-01 B.10. Changes to draft-ietf-lisp-rfc6830bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Change references from RFC6833 to RFC6833bis. o Change references from RFC6833 to RFC6833bis.
o Clarified LCAF text in the IANA section. o Clarified LCAF text in the IANA section.
o Remove references to "experimental". o Remove references to "experimental".
B.10. Changes to draft-ietf-lisp-rfc6830bis-00 B.11. Changes to draft-ietf-lisp-rfc6830bis-00
o Posted December 2016. o Posted December 2016.
o Created working group document from draft-farinacci-lisp o Created working group document from draft-farinacci-lisp
-rfc6830-00 individual submission. No other changes made. -rfc6830-00 individual submission. No other changes made.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
Cisco Systems Cisco Systems
 End of changes. 39 change blocks. 
318 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/