draft-ietf-lisp-rfc6830bis-10.txt   draft-ietf-lisp-rfc6830bis-11.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: September 5, 2018 D. Lewis Expires: September 6, 2018 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
March 4, 2018 March 5, 2018
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-10 draft-ietf-lisp-rfc6830bis-11
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 September 5, 2018. This Internet-Draft will expire on September 6, 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 8 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 10 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 10
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 12 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 12
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 12
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 13
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 14
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 . . . . . . . . . . . 19
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 . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . 25 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 26
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 29 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 29
13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 30 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30
15. Router Performance Considerations . . . . . . . . . . . . . . 31 15. Router Performance Considerations . . . . . . . . . . . . . . 31
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31
16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 32 17. Network Management Considerations . . . . . . . . . . . . . . 32
16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 32 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 33 18.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 33
17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 33 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 35 19.1. Normative References . . . . . . . . . . . . . . . . . . 33
17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 35 19.2. Informative References . . . . . . . . . . . . . . . . . 34
17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 36
17.4. LISP Functionality with Conventional NATs . . . . . . . 36 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 37 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39
18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 37 B.1. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 40
18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 38 B.2. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 40
18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 38 B.3. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 40
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 39 B.4. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 40
19. Security Considerations . . . . . . . . . . . . . . . . . . . 39 B.5. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 41
20. Network Management Considerations . . . . . . . . . . . . . . 40 B.6. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 41
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 B.7. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 41
21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 40 B.8. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 41
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.9. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 42
22.1. Normative References . . . . . . . . . . . . . . . . . . 40 B.10. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 42
22.2. Informative References . . . . . . . . . . . . . . . . . 41 B.11. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 42
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46 B.12. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 42
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
B.1. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 47
B.2. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 47
B.3. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 47
B.4. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 48
B.5. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 48
B.6. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 48
B.7. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 48
B.8. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 49
B.9. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 49
B.10. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 49
B.11. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
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 19, line 11 skipping to change at page 18, line 44
Note that if an ETR/PETR is also an ITR/PITR and chooses to re- Note that if an ETR/PETR is also an ITR/PITR and chooses to re-
encapsulate after decapsulating, the net effect of this is that the encapsulate after decapsulating, the net effect of this is that the
new outer header will carry the same Time to Live as the old outer new outer header will carry the same Time to Live as the old outer
header minus 1. header minus 1.
Copying the Time to Live (TTL) serves two purposes: first, it Copying the Time to Live (TTL) serves two purposes: first, it
preserves the distance the host intended the packet to travel; preserves the distance the host intended the packet to travel;
second, and more importantly, it provides for suppression of looping second, and more importantly, it provides for suppression of looping
packets in the event there is a loop of concatenated tunnels due to packets in the event there is a loop of concatenated tunnels due to
misconfiguration. See Section 18.3 for TTL exception handling for misconfiguration.
traceroute packets.
The Explicit Congestion Notification ('ECN') field occupies bits 6 The Explicit Congestion Notification ('ECN') field occupies bits 6
and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic
Class' field [RFC3168]. The 'ECN' field requires special treatment Class' field [RFC3168]. The 'ECN' field requires special treatment
in order to avoid discarding indications of congestion [RFC3168]. An in order to avoid discarding indications of congestion [RFC3168]. An
ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
header to the outer header. Re-encapsulation MUST copy the 2-bit header to the outer header. Re-encapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the new outer header. 'ECN' field from the stripped outer header to the new outer header.
If the 'ECN' field contains a congestion indication codepoint (the If the 'ECN' field contains a congestion indication codepoint (the
value is '11', the Congestion Experienced (CE) codepoint), then ETR/ value is '11', the Congestion Experienced (CE) codepoint), then ETR/
skipping to change at page 24, line 12 skipping to change at page 23, line 44
entry, one learned from the source RLOC of a received encapsulated entry, one learned from the source RLOC of a received encapsulated
packet, is only stored and used for a few seconds, pending packet, is only stored and used for a few seconds, pending
verification. Verification is performed by sending a Map-Request to verification. Verification is performed by sending a Map-Request to
the source EID (the inner-header IP source address) of the received the source EID (the inner-header IP source address) of the received
encapsulated packet. A reply to this "verifying Map-Request" is used encapsulated packet. A reply to this "verifying Map-Request" is used
to fully populate the Map-Cache entry for the "gleaned" EID and is to fully populate the Map-Cache entry for the "gleaned" EID and is
stored and used for the time indicated from the 'TTL' field of a stored and used for the time indicated from the 'TTL' field of a
received Map-Reply. When a verified Map-Cache entry is stored, data received Map-Reply. When a verified Map-Cache entry is stored, data
gleaning no longer occurs for subsequent packets that have a source gleaning no longer occurs for subsequent packets that have a source
EID that matches the EID-Prefix of the verified entry. This EID that matches the EID-Prefix of the verified entry. This
"gleaning" mechanism is OPTIONAL, refer to Section 19 for security "gleaning" mechanism is OPTIONAL, refer to Section 16 for security
issues regarding this mechanism. 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.
skipping to change at page 25, line 34 skipping to change at page 25, line 17
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 16 for security related
issues regarding Locator-Status-Bits. issues regarding Locator-Status-Bits.
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.
skipping to change at page 32, line 10 skipping to change at page 31, line 43
octets to a MAC rewrite string and prepending the string as part octets to a MAC rewrite string and prepending the string as part
of the outgoing encapsulation procedure. Routers that support of the outgoing encapsulation procedure. Routers that support
Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4
tunneling [RFC3056] may already support this action. tunneling [RFC3056] may already support this action.
o A packet's source address or interface the packet was received on o A packet's source address or interface the packet was received on
can be used to select VRF (Virtual Routing/Forwarding). The VRF's can be used to select VRF (Virtual Routing/Forwarding). The VRF's
routing table can be used to find EID-to-RLOC mappings. routing table can be used to find EID-to-RLOC mappings.
For performance issues related to map-cache management, see For performance issues related to map-cache management, see
Section 19. Section 16.
16. Mobility Considerations
There are several kinds of mobility, of which only some might be of
concern to LISP. Essentially, they are as follows.
16.1. Slow Mobility
A site wishes to change its attachment points to the Internet, and
its LISP Tunnel Routers will have new RLOCs when it changes upstream
providers. Changes in EID-to-RLOC mappings for sites are expected to
be handled by configuration, outside of LISP.
An individual endpoint wishes to move but is not concerned about
maintaining session continuity. Renumbering is involved. LISP can
help with the issues surrounding renumbering [RFC4192] [LISA96] by
decoupling the address space used by a site from the address spaces
used by its ISPs [RFC4984].
16.2. Fast Mobility
Fast endpoint mobility occurs when an endpoint moves relatively
rapidly, changing its IP-layer network attachment point. Maintenance
of session continuity is a goal. This is where the Mobile IPv4
[RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used and
primarily where interactions with LISP need to be explored, such as
the mechanisms in [I-D.ietf-lisp-eid-mobility] when the EID moves but
the RLOC is in the network infrastructure.
In LISP, one possibility is to "glean" information. When a packet
arrives, the ETR could examine the EID-to-RLOC mapping and use that
mapping for all outgoing traffic to that EID. It can do this after
performing a route-returnability check, to ensure that the new
network location does have an internal route to that endpoint.
However, this does not cover the case where an ITR (the node assigned
the RLOC) at the mobile-node location has been compromised.
Mobile IP packet exchange is designed for an environment in which all
routing information is disseminated before packets can be forwarded.
In order to allow the Internet to grow to support expected future
use, we are moving to an environment where some information may have
to be obtained after packets are in flight. Modifications to IP
mobility should be considered in order to optimize the behavior of
the overall system. Anything that decreases the number of new EID-
to-RLOC mappings needed when a node moves, or maintains the validity
of an EID-to-RLOC mapping for a longer time, is useful.
In addition to endpoints, a network can be mobile, possibly changing
xTRs. A "network" can be as small as a single router and as large as
a whole site. This is different from site mobility in that it is
fast and possibly short-lived, but different from endpoint mobility
in that a whole prefix is changing RLOCs. However, the mechanisms
are the same, and there is no new overhead in LISP. A map request
for any endpoint will return a binding for the entire mobile prefix.
If mobile networks become a more common occurrence, it may be useful
to revisit the design of the mapping service and allow for dynamic
updates of the database.
The issue of interactions between mobility and LISP needs to be
explored further. Specific improvements to the entire system will
depend on the details of mapping mechanisms. Mapping mechanisms
should be evaluated on how well they support session continuity for
mobile nodes. See [I-D.ietf-lisp-predictive-rlocs] for more recent
mechanisms which can provide near-zero packet loss during handoffs.
16.3. LISP Mobile Node Mobility
A mobile device can use the LISP infrastructure to achieve mobility
by implementing the LISP encapsulation and decapsulation functions
and acting as a simple ITR/ETR. By doing this, such a "LISP mobile
node" can use topologically independent EID IP addresses that are not
advertised into and do not impose a cost on the global routing
system. These EIDs are maintained at the edges of the mapping system
in LISP Map-Servers and Map-Resolvers) and are provided on demand to
only the correspondents of the LISP mobile node.
Refer to [I-D.ietf-lisp-mn] for more details for when the EID and
RLOC are co-located in the roaming node.
17. LISP xTR Placement and Encapsulation Methods
This section will explore how and where ITRs and ETRs can be placed
in the network and will discuss the pros and cons of each scenario.
For a more detailed network design deployment recommendation, refer
to [RFC7215].
There are two basic deployment tradeoffs to consider: centralized
versus distributed caches; and flat, Recursive, or Re-encapsulating
Tunneling. When deciding on centralized versus distributed caching,
the following issues SHOULD be considered:
o Are the xTRs spread out so that the caches are spread across all
the memories of each router? A centralized cache is when an ITR
keeps a cache for all the EIDs it is encapsulating to. The packet
takes a direct path to the destination Locator. A distributed
cache is when an ITR needs help from other Re-Encapsulating Tunnel
Routers (RTRs) because it does not store all the cache entries for
the EIDs it is encapsulating to. So, the packet takes a path
through RTRs that have a different set of cache entries.
o Should management "touch points" be minimized by only choosing a
few xTRs, just enough for redundancy?
o In general, using more ITRs doesn't increase management load,
since caches are built and stored dynamically. On the other hand,
using more ETRs does require more management, since EID-Prefix-to-
RLOC mappings need to be explicitly configured.
When deciding on flat, Recursive, or Re-Encapsulating Tunneling, the
following issues SHOULD be considered:
o Flat tunneling implements a single encapsulation path between the
source site and destination site. This generally offers better
paths between sources and destinations with a single encapsulation
path.
o Recursive Tunneling is when encapsulated traffic is again further
encapsulated in another tunnel, either to implement VPNs or to
perform Traffic Engineering. When doing VPN-based tunneling, the
site has some control, since the site is prepending a new
encapsulation header. In the case of TE-based tunneling, the site
MAY have control if it is prepending a new tunnel header, but if
the site's ISP is doing the TE, then the site has no control.
Recursive Tunneling generally will result in suboptimal paths but
with the benefit of steering traffic to parts of the network that
have more resources available.
o The technique of Re-Encapsulation ensures that packets only
require one encapsulation header. So, if a packet needs to be re-
routed, it is first decapsulated by the RTR and then Re-
Encapsulated with a new encapsulation header using a new RLOC.
The next sub-sections will examine where xTRs and RTRs can reside in
the network.
17.1. First-Hop/Last-Hop xTRs
By locating xTRs close to hosts, the EID-Prefix set is at the
granularity of an IP subnet. So, at the expense of more EID-Prefix-
to-RLOC sets for the site, the caches in each xTR can remain
relatively small. But caches always depend on the number of non-
aggregated EID destination flows active through these xTRs.
With more xTRs doing encapsulation, the increase in control traffic
grows as well: since the EID granularity is greater, more Map-
Requests and Map-Replies are traveling between more routers.
The advantage of placing the caches and databases at these stub
routers is that the products deployed in this part of the network
have better price-memory ratios than their core router counterparts.
Memory is typically less expensive in these devices, and fewer routes
are stored (only IGP routes). These devices tend to have excess
capacity, both for forwarding and routing states.
LISP functionality can also be deployed in edge switches. These
devices generally have layer-2 ports facing hosts and layer-3 ports
facing the Internet. Spare capacity is also often available in these
devices.
17.2. Border/Edge xTRs
Using Customer Edge (CE) routers for xTR placement allows the EID
space associated with a site to be reachable via a small set of RLOCs
assigned to the CE-based xTRs for that site.
This offers the opposite benefit of the first-hop/last-hop xTR
scenario: the number of mapping entries and network management touch
points is reduced, allowing better scaling.
One disadvantage is that fewer network resources are used to reach
host endpoints, thereby centralizing the point-of-failure domain and
creating network choke points at the CE xTR.
Note that more than one CE xTR at a site can be configured with the
same IP address. In this case, an RLOC is an anycast address. This
allows resilience between the CE xTRs. That is, if a CE xTR fails,
traffic is automatically routed to the other xTRs using the same
anycast address. However, this comes with the disadvantage where the
site cannot control the entrance point when the anycast route is
advertised out from all border routers. Another disadvantage of
using anycast Locators is the limited advertisement scope of /32 (or
/128 for IPv6) routes.
17.3. ISP Provider Edge (PE) xTRs
The use of ISP PE routers as xTRs is not the typical deployment
scenario envisioned in this specification. This section attempts to
capture some of the reasoning behind this preference for implementing
LISP on CE routers.
The use of ISP PE routers for xTR placement gives an ISP, rather than
a site, control over the location of the ETRs. That is, the ISP can
decide whether the xTRs are in the destination site (in either CE
xTRs or last-hop xTRs within a site) or at other PE edges. The
advantage of this case is that two encapsulation headers can be
avoided. By having the PE be the first router on the path to
encapsulate, it can choose a TE path first, and the ETR can
decapsulate and Re-Encapsulate for a new encapsulation path to the
destination end site.
An obvious disadvantage is that the end site has no control over
where its packets flow or over the RLOCs used. Other disadvantages
include difficulty in synchronizing path liveness updates between CE
and PE routers.
As mentioned in earlier sections, a combination of these scenarios is
possible at the expense of extra packet header overhead; if both site
and provider want control, then Recursive or Re-Encapsulating Tunnels
are used.
17.4. LISP Functionality with Conventional NATs
LISP routers can be deployed behind Network Address Translator (NAT)
devices to provide the same set of packet services hosts have today
when they are addressed out of private address space.
It is important to note that a locator address in any LISP control
message MUST be a routable address and therefore [RFC1918] addresses
SHOULD only be presence when running in a local environment. When a
LISP xTR is configured with private RLOC addresses and resides behind
a NAT device and desires to communicate on the Internet, the private
addresses MUST be used only in the outer IP header so the NAT device
can translate properly. Otherwise, EID addresses MUST be translated
before encapsulation is performed when LISP VPNs are not in use.
Both NAT translation and LISP encapsulation functions could be co-
located in the same device.
17.5. Packets Egressing a LISP Site
When a LISP site is using two ITRs for redundancy, the failure of one
ITR will likely shift outbound traffic to the second. This second
ITR's cache MAY not be populated with the same EID-to-RLOC mapping
entries as the first. If this second ITR does not have these
mappings, traffic will be dropped while the mappings are retrieved
from the mapping system. The retrieval of these messages may
increase the load of requests being sent into the mapping system.
18. Traceroute Considerations
When a source host in a LISP site initiates a traceroute to a
destination host in another LISP site, it is highly desirable for it
to see the entire path. Since packets are encapsulated from the ITR
to the ETR, the hop across the tunnel could be viewed as a single
hop. However, LISP traceroute will provide the entire path so the
user can see 3 distinct segments of the path from a source LISP host
to a destination LISP host:
Segment 1 (in source LISP site based on EIDs):
source host ---> first hop ... next hop ---> ITR
Segment 2 (in the core network based on RLOCs):
ITR ---> next hop ... next hop ---> ETR
Segment 3 (in the destination LISP site based on EIDs):
ETR ---> next hop ... last hop ---> destination host
For segment 1 of the path, ICMP Time Exceeded messages are returned
in the normal manner as they are today. The ITR performs a TTL
decrement and tests for 0 before encapsulating. Therefore, the ITR's
hop is seen by the traceroute source as having an EID address (the
address of the site-facing interface).
For segment 2 of the path, ICMP Time Exceeded messages are returned
to the ITR because the TTL decrement to 0 is done on the outer
header, so the destinations of the ICMP messages are the ITR RLOC
address and the source RLOC address of the encapsulated traceroute
packet. The ITR looks inside of the ICMP payload to inspect the
traceroute source so it can return the ICMP message to the address of
the traceroute client and also retain the core router IP address in
the ICMP message. This is so the traceroute client can display the
core router address (the RLOC address) in the traceroute output. The
ETR returns its RLOC address and responds to the TTL decrement to 0,
as the previous core routers did.
For segment 3, the next-hop router downstream from the ETR will be
decrementing the TTL for the packet that was encapsulated, sent into
the core, decapsulated by the ETR, and forwarded because it isn't the
final destination. If the TTL is decremented to 0, any router on the
path to the destination of the traceroute, including the next-hop
router or destination, will send an ICMP Time Exceeded message to the
source EID of the traceroute client. The ICMP message will be
encapsulated by the local ITR and sent back to the ETR in the
originated traceroute source site, where the packet will be delivered
to the host.
18.1. IPv6 Traceroute
IPv6 traceroute follows the procedure described above, since the
entire traceroute data packet is included in the ICMP Time Exceeded
message payload. Therefore, only the ITR needs to pay special
attention to forwarding ICMP messages back to the traceroute source.
18.2. IPv4 Traceroute
For IPv4 traceroute, we cannot follow the above procedure, since IPv4
ICMP Time Exceeded messages only include the invoking IP header and
8 octets that follow the IP header. Therefore, when a core router
sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the
ICMP payload is the encapsulated header it prepended, followed by a
UDP header. The original invoking IP header, and therefore the
identity of the traceroute source, is lost.
The solution we propose to solve this problem is to cache traceroute
IPv4 headers in the ITR and to match them up with corresponding IPv4
Time Exceeded messages received from core routers and the ETR. The
ITR will use a circular buffer for caching the IPv4 and UDP headers
of traceroute packets. It will select a 16-bit number as a key to
find them later when the IPv4 Time Exceeded messages are received.
When an ITR encapsulates an IPv4 traceroute packet, it will use the
16-bit number as the UDP source port in the encapsulating header.
When the ICMP Time Exceeded message is returned to the ITR, the UDP
header of the encapsulating header is present in the ICMP payload,
thereby allowing the ITR to find the cached headers for the
traceroute source. The ITR puts the cached headers in the payload
and sends the ICMP Time Exceeded message to the traceroute source
retaining the source address of the original ICMP Time Exceeded
message (a core router or the ETR of the site of the traceroute
destination).
The signature of a traceroute packet comes in two forms. The first
form is encoded as a UDP message where the destination port is
inspected for a range of values. The second form is encoded as an
ICMP message where the IP identification field is inspected for a
well-known value.
18.3. Traceroute Using Mixed Locators
When either an IPv4 traceroute or IPv6 traceroute is originated and
the ITR encapsulates it in the other address family header, one
cannot get all 3 segments of the traceroute. Segment 2 of the
traceroute cannot be conveyed to the traceroute source, since it is
expecting addresses from intermediate hops in the same address format
for the type of traceroute it originated. Therefore, in this case,
segment 2 will make the tunnel look like one hop. All the ITR has to
do to make this work is to not copy the inner TTL to the outer,
encapsulating header's TTL when a traceroute packet is encapsulated
using an RLOC from a different address family. This will cause no
TTL decrement to 0 to occur in core routers between the ITR and ETR.
19. Security Considerations 16. Security Considerations
Security considerations for LISP are discussed in [RFC7833]. Security considerations for LISP are discussed in [RFC7833].
A complete LISP threat analysis can be found in [RFC7835], in what A complete LISP threat analysis can be found in [RFC7835], in what
follows we provide a summary. follows we provide a summary.
The optional mechanisms of gleaning is offered to directly obtain a The optional mechanisms of gleaning is offered to directly obtain a
mapping from the LISP encapsulated packets. Specifically, an xTR can mapping from the LISP encapsulated packets. Specifically, an xTR can
learn the EID-to-RLOC mapping by inspecting the source RLOC and learn the EID-to-RLOC mapping by inspecting the source RLOC and
source EID of an encapsulated packet, and insert this new mapping source EID of an encapsulated packet, and insert this new mapping
skipping to change at page 40, line 15 skipping to change at page 32, line 37
fresh mapping. This can be used by an attacker to forge the map- fresh mapping. This can be used by an attacker to forge the map-
versioning field of a LISP encapsulated header and force an excessive versioning field of a LISP encapsulated header and force an excessive
amount of signaling between xTRs that may overload them. amount of signaling between xTRs that may overload them.
Most of the attack vectors can be mitigated with careful deployment Most of the attack vectors can be mitigated with careful deployment
and configuration, information learned opportunistically (such as LSB and configuration, information learned opportunistically (such as LSB
or gleaning) SHOULD be verified with other reachability mechanisms. or gleaning) SHOULD be verified with other reachability mechanisms.
In addition, systematic rate-limitation and filtering is an effective In addition, systematic rate-limitation and filtering is an effective
technique to mitigate attacks that aim to overload the control-plane. technique to mitigate attacks that aim to overload the control-plane.
20. Network Management Considerations 17. Network Management Considerations
Considerations for network management tools exist so the LISP Considerations for network management tools exist so the LISP
protocol suite can be operationally managed. These mechanisms can be protocol suite can be operationally managed. These mechanisms can be
found in [RFC7052] and [RFC6835]. found in [RFC7052] and [RFC6835].
21. IANA Considerations 18. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
data-plane LISP specification, in accordance with BCP 26 [RFC8126]. data-plane LISP specification, in accordance with BCP 26 [RFC8126].
21.1. LISP UDP Port Numbers 18.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port number 4341 for the LISP The IANA registry has allocated UDP port number 4341 for the LISP
data-plane. IANA has updated the description for UDP port 4341 as data-plane. IANA has updated the description for UDP port 4341 as
follows: follows:
lisp-data 4341 udp LISP Data Packets lisp-data 4341 udp LISP Data Packets
22. References 19. References
22.1. Normative References 19.1. Normative References
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane", "Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-07 (work in progress), December draft-ietf-lisp-rfc6833bis-07 (work in progress), December
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>.
skipping to change at page 41, line 30 skipping to change at page 34, line 10
[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>.
[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 19.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>.
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed",
1999, 1999,
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[I-D.ietf-lisp-eid-mobility] [I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
skipping to change at page 47, line 5 skipping to change at page 40, 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-10 B.1. Changes to draft-ietf-lisp-rfc6830bis-11
o Posted March 2018.
o Removed sections 16, 17 and 18 (Mobility, Deployment and
Traceroute considerations). This text must be placed in a new OAM
document.
B.2. Changes to draft-ietf-lisp-rfc6830bis-10
o Posted March 2018. o Posted March 2018.
o Updated section 'Router Locator Selection' stating that the data- o Updated section 'Router Locator Selection' stating that the data-
plane MUST follow what's stored in the map-cache (priorities and plane MUST follow what's stored in the map-cache (priorities and
weights). weights).
o Section 'Routing Locator Reachability': Removed bullet point 2 o Section 'Routing Locator Reachability': Removed bullet point 2
(ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port
Unreachable),5 (receive a Map-Reply as a response) and RLOC Unreachable),5 (receive a Map-Reply as a response) and RLOC
probing probing
o Removed 'Solicit-Map Request'. o Removed 'Solicit-Map Request'.
B.2. Changes to draft-ietf-lisp-rfc6830bis-09 B.3. 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.3. Changes to draft-ietf-lisp-rfc6830bis-08 B.4. 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.4. Changes to draft-ietf-lisp-rfc6830bis-07 B.5. 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.5. Changes to draft-ietf-lisp-rfc6830bis-06 B.6. 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 48, line 35 skipping to change at page 41, line 40
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.6. Changes to draft-ietf-lisp-rfc6830bis-05 B.7. 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.7. Changes to draft-ietf-lisp-rfc6830bis-04 B.8. 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.8. Changes to draft-ietf-lisp-rfc6830bis-03 B.9. 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.9. Changes to draft-ietf-lisp-rfc6830bis-02 B.10. 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.10. Changes to draft-ietf-lisp-rfc6830bis-01 B.11. 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.11. Changes to draft-ietf-lisp-rfc6830bis-00 B.12. 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. 32 change blocks. 
411 lines changed or deleted 64 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/