draft-ietf-lisp-rfc6830bis-00.txt   draft-ietf-lisp-rfc6830bis-01.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: June 9, 2017 D. Lewis Expires: September 27, 2017 D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
December 6, 2016 March 26, 2017
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-00 draft-ietf-lisp-rfc6830bis-01
Abstract Abstract
This document describes the Locator/ID Separation Protocol (LISP) This document describes the Locator/ID Separation Protocol (LISP)
data-plane encapsulation protocol. LISP defines two namespaces, End- data-plane encapsulation protocol. LISP defines two namespaces, End-
point Identifiers (EIDs) that identify end-hosts and Routing Locators point 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. The according to EID-to-RLOC mappings stored in a local map-cache. The
map-cache is populated by the LISP Control-Plane protocol map-cache is populated by the LISP Control-Plane protocol
[REF_TO_RFC6833bis]. [I-D.ietf-lisp-rfc6833bis].
LISP requires no change to either host protocol stacks or to underlay LISP requires no change to either host protocol stacks or to underlay
routers and offers Traffic Engineering, multihoming and mobility, routers and offers Traffic Engineering, multihoming and mobility,
among other features. among other features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2017. This Internet-Draft will expire on September 27, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 4 skipping to change at page 3, line 4
13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31 13.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . . 31
13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32 13.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . 32
13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33 13.3. Database Map-Versioning . . . . . . . . . . . . . . . . 33
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 34
15. Router Performance Considerations . . . . . . . . . . . . . . 35 15. Router Performance Considerations . . . . . . . . . . . . . . 35
16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 16. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36
16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.1. Slow Mobility . . . . . . . . . . . . . . . . . . . . . 36
16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36 16.2. Fast Mobility . . . . . . . . . . . . . . . . . . . . . 36
16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37 16.3. LISP Mobile Node Mobility . . . . . . . . . . . . . . . 37
17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37 17. LISP xTR Placement and Encapsulation Methods . . . . . . . . 37
17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 39 17.1. First-Hop/Last-Hop xTRs . . . . . . . . . . . . . . . . 38
17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39 17.2. Border/Edge xTRs . . . . . . . . . . . . . . . . . . . . 39
17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 40 17.3. ISP Provider Edge (PE) xTRs . . . . . . . . . . . . . . 39
17.4. LISP Functionality with Conventional NATs . . . . . . . 40 17.4. LISP Functionality with Conventional NATs . . . . . . . 40
17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40 17.5. Packets Egressing a LISP Site . . . . . . . . . . . . . 40
18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41 18. Traceroute Considerations . . . . . . . . . . . . . . . . . . 41
18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . 42
18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42 18.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . 42
18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 43 18.3. Traceroute Using Mixed Locators . . . . . . . . . . . . 42
19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43
20. Network Management Considerations . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 44
21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
21.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 21.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44
21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 44 21.2. LISP Address Type Codes . . . . . . . . . . . . . . . . 44
21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 21.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 45
21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 44 21.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . 45
22. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
22.1. Normative References . . . . . . . . . . . . . . . . . . 45 22.1. Normative References . . . . . . . . . . . . . . . . . . 45
22.2. Informative References . . . . . . . . . . . . . . . . . 47 22.2. Informative References . . . . . . . . . . . . . . . . . 48
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 52
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 52
B.1. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 52 B.1. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 B.2. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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
attachment points. LISP then defines functions for mapping between attachment points. LISP then defines functions for mapping between
the two numbering spaces and for encapsulating traffic originated by the two numbering spaces and for encapsulating traffic originated by
devices using non-routable EIDs for transport across a network devices using non-routable EIDs for transport across a network
infrastructure that routes and forwards using RLOCs. infrastructure that routes and forwards using RLOCs.
LISP is an overlay protocol that separates control from data-plane, LISP is an overlay protocol that separates control from data-plane,
this document specifies the data-plane, how LISP-capable routers this document specifies the data-plane, how LISP-capable routers
(Tunnel Routers) exchange packets by encapsulating them to the (Tunnel Routers) exchange packets by encapsulating them to the
appropriate location. Tunnel routers are equipped with a cache, appropriate location. Tunnel routers are equipped with a cache,
called map-cache, that contains EID-to-RLOC mappings. The map-cache called map-cache, that contains EID-to-RLOC mappings. The map-cache
is populated using the LISP Control-Plane protocol [REF_to_6833bis]. is populated using the LISP Control-Plane protocol
[I-D.ietf-lisp-rfc6833bis].
LISP does not require changes to either host protocol stack or to LISP does not require changes to either host protocol stack or to
underlay routers. By separating the EID from the RLOC space, LISP underlay routers. By separating the EID from the RLOC space, LISP
offers native Traffic Engineering, multihoming and mobility, among offers native Traffic Engineering, multihoming and mobility, among
other features. other features.
Creation of LISP was initially motivated by discussions during the Creation of LISP was initially motivated by discussions during the
IAB-sponsored Routing and Addressing Workshop held in Amsterdam in IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
October 2006 (see [RFC4984]) October 2006 (see [RFC4984])
This document specifies the LISP data-plane encapsulation and other This document specifies the LISP data-plane encapsulation and other
xTR functionality while [REF_to_6833bis] specifies the LISP control xTR functionality while [I-D.ietf-lisp-rfc6833bis] specifies the LISP
plane. LISP deployment guidelines can be found in [RFC7215] and control plane. LISP deployment guidelines can be found in [RFC7215]
[RFC6835] describes considerations for network operational and [RFC6835] describes considerations for network operational
management. Finally, [LISP-INTRO] describes the LISP architecture. management. Finally, [I-D.ietf-lisp-introduction] describes the LISP
architecture.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definition of Terms 3. Definition of Terms
Provider-Independent (PI) Addresses: PI addresses are an address Provider-Independent (PI) Addresses: PI addresses are an address
skipping to change at page 8, line 9 skipping to change at page 8, line 14
must be taken to not create re-encapsulation loops through must be taken to not create re-encapsulation loops through
misconfiguration. misconfiguration.
LISP Header: LISP header is a term used in this document to refer LISP Header: LISP header is a term used in this document to refer
to the outer IPv4 or IPv6 header, a UDP header, and a LISP- to the outer IPv4 or IPv6 header, a UDP header, and a LISP-
specific 8-octet header that follow the UDP header and that an ITR specific 8-octet header that follow the UDP header and that an ITR
prepends or an ETR strips. prepends or an ETR strips.
Address Family Identifier (AFI): AFI is a term used to describe an Address Family Identifier (AFI): AFI is a term used to describe an
address encoding in a packet. An address family currently address encoding in a packet. An address family currently
pertains to an IPv4 or IPv6 address. See [AFI] and [RFC3232] for pertains to an IPv4 or IPv6 address. See [AFN] and [RFC3232] for
details. An AFI value of 0 used in this specification indicates details. An AFI value of 0 used in this specification indicates
an unspecified encoded address where the length of the address is an unspecified encoded address where the length of the address is
0 octets following the 16-bit AFI value of 0. 0 octets following the 16-bit AFI value of 0.
Negative Mapping Entry: A negative mapping entry, also known as a Negative Mapping Entry: A negative mapping entry, also known as a
negative cache entry, is an EID-to-RLOC entry where an EID-Prefix negative cache entry, is an EID-to-RLOC entry where an EID-Prefix
is advertised or stored with no RLOCs. That is, the Locator-Set is advertised or stored with no RLOCs. That is, the Locator-Set
for the EID-to-RLOC entry is empty or has an encoded Locator count for the EID-to-RLOC entry is empty or has an encoded Locator count
of 0. This type of entry could be used to describe a prefix from of 0. This type of entry could be used to describe a prefix from
a non-LISP site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the mapping database.
skipping to change at page 10, line 28 skipping to change at page 10, line 31
o End-systems only send to addresses that are EIDs. They don't know o End-systems only send to addresses that are EIDs. They don't know
that addresses are EIDs versus RLOCs but assume that packets get that addresses are EIDs versus RLOCs but assume that packets get
to their intended destinations. In a system where LISP is to their intended destinations. In a system where LISP is
deployed, LISP routers intercept EID-addressed packets and assist deployed, LISP routers intercept EID-addressed packets and assist
in delivering them across the network core where EIDs cannot be in delivering them across the network core where EIDs cannot be
routed. The procedure a host uses to send IP packets does not routed. The procedure a host uses to send IP packets does not
change. change.
o EIDs are typically IP addresses assigned to hosts. o EIDs are typically IP addresses assigned to hosts.
o Other types of EID are supported by LISP, see [LCAF] for further o Other types of EID are supported by LISP, see [RFC8060] for
information. further information.
o LISP routers mostly deal with Routing Locator addresses. See o LISP routers mostly deal with Routing Locator addresses. See
details in Section 4.1 to clarify what is meant by "mostly". details in Section 4.1 to clarify what is meant by "mostly".
o RLOCs are always IP addresses assigned to routers, preferably o RLOCs are always IP addresses assigned to routers, preferably
topologically oriented addresses from provider CIDR (Classless topologically oriented addresses from provider CIDR (Classless
Inter-Domain Routing) blocks. Inter-Domain Routing) blocks.
o When a router originates packets, it may use as a source address o When a router originates packets, it may use as a source address
either an EID or RLOC. When acting as a host (e.g., when either an EID or RLOC. When acting as a host (e.g., when
skipping to change at page 11, line 48 skipping to change at page 11, line 51
connected to the destination host. Another example, perhaps for a connected to the destination host. Another example, perhaps for a
VPN service outsourced to an ISP by a site, the ITR could be the VPN service outsourced to an ISP by a site, the ITR could be the
site's border router at the service provider attachment point. site's border router at the service provider attachment point.
Mixing and matching of site-operated, ISP-operated, and other Tunnel Mixing and matching of site-operated, ISP-operated, and other Tunnel
Routers is allowed for maximum flexibility. Routers is allowed for maximum flexibility.
4.1. Packet Flow Sequence 4.1. Packet Flow Sequence
This section provides an example of the unicast packet flow, This section provides an example of the unicast packet flow,
including also control-plane information as specified in including also control-plane information as specified in
[REF_TO_RFC6833bis]. The example also assumes the following [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following
conditions: conditions:
o Source host "host1.abc.example.com" is sending a packet to o Source host "host1.abc.example.com" is sending a packet to
"host2.xyz.example.com", exactly what host1 would do if the site "host2.xyz.example.com", exactly what host1 would do if the site
was not using LISP. was not using LISP.
o Each site is multihomed, so each Tunnel Router has an address o Each site is multihomed, so each Tunnel Router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular Tunnel Router is attached. provider to which that particular Tunnel Router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively, but the source and destination can be destination, respectively, but the source and destination can be
located anywhere in the LISP site. located anywhere in the LISP site.
o Map-Requests are sent to the mapping database system by using the o Map-Requests are sent to the mapping database system by using the
LISP control-plane protocol documented in [REF_to_RFC6833bis]. A LISP control-plane protocol documented in
Map-Request is sent for an external destination when the [I-D.ietf-lisp-rfc6833bis]. A Map-Request is sent for an external
destination is not found in the forwarding table or matches a destination when the destination is not found in the forwarding
default route. table or matches a default route.
o Map-Replies are sent on the underlying routing system topology o Map-Replies are sent on the underlying routing system topology
using the [REF_TO_RFC6833bis] control-plane protocol. using the [I-D.ietf-lisp-rfc6833bis] control-plane protocol.
Client host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate with server
host2.xyz.example.com: host2.xyz.example.com:
1. host1.abc.example.com wants to open a TCP connection to 1. host1.abc.example.com wants to open a TCP connection to
host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally assigned address of address is the destination EID. The locally assigned address of
host1.abc.example.com is used as the source EID. An IPv4 or IPv6 host1.abc.example.com is used as the source EID. An IPv4 or IPv6
packet is built and forwarded through the LISP site as a normal packet is built and forwarded through the LISP site as a normal
IP packet until it reaches a LISP ITR. IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the destination EID to an RLOC 2. The LISP ITR must be able to map the destination EID to an RLOC
of one of the ETRs at the destination site. The specific method of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See used to do this is not described in this example. See
[REF_to_RFC6833bis] for further information. [I-D.ietf-lisp-rfc6833bis] for further information.
3. The ITR sends a LISP Map-Request as specified in 3. The ITR sends a LISP Map-Request as specified in
[REF_TO_RFC6833bis]. Map-Requests SHOULD be rate-limited. [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited.
4. The mapping system helps forwarding the Map-Request to the 4. The mapping system helps forwarding the Map-Request to the
corresponding ETR. When the Map-Request arrives at one of the corresponding ETR. When the Map-Request arrives at one of the
ETRs at the destination site, it will process the packet as a ETRs at the destination site, it will process the packet as a
control message. control message.
5. The ETR looks at the destination EID of the Map-Request and 5. The ETR looks at the destination EID of the Map-Request and
matches it against the prefixes in the ETR's configured EID-to- matches it against the prefixes in the ETR's configured EID-to-
RLOC mapping database. This is the list of EID-Prefixes the ETR RLOC mapping database. This is the list of EID-Prefixes the ETR
is supporting for the site it resides in. If there is no match, is supporting for the site it resides in. If there is no match,
skipping to change at page 14, line 10 skipping to change at page 14, line 10
existing schemes are detailed in Section 7. existing schemes are detailed in Section 7.
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the outer header is in IPv6 header is in IPv4 packet format and the outer header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the outer header is in IPv4 packet is in IPv6 packet format and the outer header is in IPv4 packet
format). The next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet formats for the
homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4
combinations MUST be supported. Additional types of EIDs are defined combinations MUST be supported. Additional types of EIDs are defined
in [LCAF]. in [RFC8060].
5.1. LISP IPv4-in-IPv4 Header Format 5.1. LISP IPv4-in-IPv4 Header Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 32 skipping to change at page 16, line 32
7.2. 7.2.
UDP Header: The UDP header contains an ITR selected source port when UDP Header: The UDP header contains an ITR selected source port when
encapsulating a packet. See Section 12 for details on the hash encapsulating a packet. See Section 12 for details on the hash
algorithm used to select a source port based on the 5-tuple of the algorithm used to select a source port based on the 5-tuple of the
inner header. The destination port MUST be set to the well-known inner header. The destination port MUST be set to the well-known
IANA-assigned port value 4341. IANA-assigned port value 4341.
UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero
by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
[UDP-TUNNELS] [UDP-ZERO]. When a packet with a zero UDP checksum [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is
is received by an ETR, the ETR MUST accept the packet for received by an ETR, the ETR MUST accept the packet for
decapsulation. When an ITR transmits a non-zero value for the UDP decapsulation. When an ITR transmits a non-zero value for the UDP
checksum, it MUST send a correctly computed value in this field. checksum, it MUST send a correctly computed value in this field.
When an ETR receives a packet with a non-zero UDP checksum, it MAY When an ETR receives a packet with a non-zero UDP checksum, it MAY
choose to verify the checksum value. If it chooses to perform choose to verify the checksum value. If it chooses to perform
such verification, and the verification fails, the packet MUST be such verification, and the verification fails, the packet MUST be
silently dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to perform the
verification, or performs the verification successfully, the verification, or performs the verification successfully, the
packet MUST be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The handling of UDP
checksums for all tunneling protocols, including LISP, is under checksums for all tunneling protocols, including LISP, is under
active discussion within the IETF. When that discussion active discussion within the IETF. When that discussion
skipping to change at page 18, line 17 skipping to change at page 18, line 17
|N|L|E|V|I|R|K|K| Nonce/Map-Version | |N|L|E|V|I|R|K|K| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs | | Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R: The R-bit is a Reserved bit for future use. It MUST be set to 0 R: The R-bit is a Reserved bit for future use. It MUST be set to 0
on transmit and MUST be ignored on receipt. on transmit and MUST be ignored on receipt.
KK: The KK-bits are a 2-bit field used when encapsualted packets are KK: The KK-bits are a 2-bit field used when encapsualted packets are
encrypted. The field is set to 00 when the packet is not encrypted. The field is set to 00 when the packet is not
encrypted. See [I.D-ietf-lisp-crypto] for further information. encrypted. See [RFC8061] for further information.
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is
randomly generated by an ITR when the N-bit is set to 1. Nonce randomly generated by an ITR when the N-bit is set to 1. Nonce
generation algorithms are an implementation matter but are generation algorithms are an implementation matter but are
required to generate different nonces when sending to different required to generate different nonces when sending to different
destinations. However, the same nonce can be used for a period of destinations. However, the same nonce can be used for a period of
time to the same destination. The nonce is also used when the time to the same destination. The nonce is also used when the
E-bit is set to request the nonce value to be echoed by the other E-bit is set to request the nonce value to be echoed by the other
side when packets are returned. When the E-bit is clear but the side when packets are returned. When the E-bit is clear but the
N-bit is set, a remote ITR is either echoing a previously N-bit is set, a remote ITR is either echoing a previously
skipping to change at page 20, line 22 skipping to change at page 20, line 22
the corresponding RLOC network attachment point. the corresponding RLOC network attachment point.
When an ITR/PITR receives a packet from inside of the LISP site to When an ITR/PITR receives a packet from inside of the LISP site to
destinations outside of the site a longest-prefix match lookup of the destinations outside of the site a longest-prefix match lookup of the
EID is done to the map-cache. EID is done to the map-cache.
When the lookup succeeds, the locator-set retrieved from the map- When the lookup succeeds, the locator-set retrieved from the map-
cache is used to send the packet to the EID's topological location. cache is used to send the packet to the EID's topological location.
If the lookup fails, the ITR/PITR needs to retrieve the mapping using If the lookup fails, the ITR/PITR needs to retrieve the mapping using
the LISP control-plane protocol [REF_TO_RFC6833bis]. The mapping is the LISP control-plane protocol [I-D.ietf-lisp-rfc6833bis]. The
then stored in the local map-cache to forward subsequent packets mapping is then stored in the local map-cache to forward subsequent
addressed to the same EID-prefix. packets addressed to the same EID-prefix.
The map-cache is a local cache of mappings, entries are expired based The map-cache is a local cache of mappings, entries are expired based
on the associated Time to live. In addition, entries can be updated on the associated Time to live. In addition, entries can be updated
with more current information, see Section 13 for further information with more current information, see Section 13 for further information
on this. Finally, the map-cache also contains reachability on this. Finally, the map-cache also contains reachability
information about EIDs and RLOCs, and uses LISP reachability information about EIDs and RLOCs, and uses LISP reachability
information mechanisms to determine the reachability of RLOCs, see information mechanisms to determine the reachability of RLOCs, see
Section 10 for the specific mechanisms. Section 10 for the specific mechanisms.
7. Dealing with Large Encapsulated Packets 7. Dealing with Large Encapsulated Packets
skipping to change at page 22, line 36 skipping to change at page 22, line 36
back to the source. The packet size advertised by the ITR in the back to the source. The packet size advertised by the ITR in the
ICMP Too Big message is the effective MTU minus the LISP ICMP Too Big message is the effective MTU minus the LISP
encapsulation length. encapsulation length.
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
8. Using Virtualization and Segmentation with LISP 8. Using Virtualization and Segmentation with LISP
FIXME: Indicate how the instance-ID is 32 bits in control-plane and
24-bits in the data-plane.
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI-based address the address encoding can aid in making the entire AFI-based address
unique. See IANA Considerations (Section 21.2) for details on unique. See IANA Considerations (Section 21.2) for details on
possible address encodings. possible address encodings.
An Instance ID can be carried in a LISP-encapsulated packet. An ITR An Instance ID can be carried in a LISP-encapsulated packet. An ITR
that prepends a LISP header will copy a 24-bit value used by the LISP that prepends a LISP header will copy a 24-bit value used by the LISP
router to uniquely identify the address space. The value is copied router to uniquely identify the address space. The value is copied
to the 'Instance ID' field of the LISP header, and the I-bit is set to the 'Instance ID' field of the LISP header, and the I-bit is set
to 1. to 1.
When an ETR decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup. to use for the inner destination EID lookup.
For example, an 802.1Q VLAN tag or VPN identifier could be used as a For example, an 802.1Q VLAN tag or VPN identifier could be used as a
24-bit Instance ID. 24-bit Instance ID.
The Instance ID that is stored in the mapping database when LISP-DDT
[I-D.ietf-lisp-ddt] is used is 32 bits in length. That means the
control-plane 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 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 Both the client-side and server-side may need control over the
selection of RLOCs for conversations between them. This control is selection of RLOCs for conversations between them. This control is
achieved by manipulating the 'Priority' and 'Weight' fields in EID- achieved by manipulating the 'Priority' and 'Weight' fields in EID-
to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be to-RLOC Map-Reply messages. Alternatively, RLOC information MAY be
gleaned from received tunneled packets or EID-to-RLOC Map-Request gleaned from received tunneled packets or EID-to-RLOC Map-Request
messages. messages.
The following are different scenarios for choosing RLOCs and the The following are different scenarios for choosing RLOCs and the
skipping to change at page 26, line 35 skipping to change at page 26, line 39
Unreachable message, it MAY originate its own ICMP Destination Unreachable message, it MAY originate its own ICMP Destination
Unreachable message destined for the host that originated the data Unreachable message destined for the host that originated the data
packet the ITR encapsulated. packet the ITR encapsulated.
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a 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 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- 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 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, 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 the path from the ITR to the ETR that is assigned the Locator is not
available. More details are in [LOC-ID-ARCH]. 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- 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. Reply is returned, reachability of the Locator has been determined.
Obviously, sending such probes increases the number of control Obviously, sending such probes increases the number of control
messages originated by Tunnel Routers for active flows, so Locators messages originated by Tunnel Routers for active flows, so Locators
are assumed to be reachable when they are advertised. are assumed to be reachable when they are advertised.
This assumption does create a dependency: Locator unreachability is This assumption does create a dependency: Locator unreachability is
detected by the receipt of ICMP Host Unreachable messages. When a detected by the receipt of ICMP Host Unreachable messages. When a
Locator has been determined to be unreachable, it is not used for Locator has been determined to be unreachable, it is not used for
skipping to change at page 28, line 47 skipping to change at page 28, line 49
the mapping database system as one would when soliciting mapping the mapping database system as one would when soliciting mapping
data. The EID record encoded in the Map-Request is the EID-Prefix of 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 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 mapping data record for its own database mapping information that
contains the local EID-Prefixes and RLOCs for its site. RLOC-probes contains the local EID-Prefixes and RLOCs for its site. RLOC-probes
are sent periodically using a jittered timer interval. are sent periodically using a jittered timer interval.
When an ETR receives a Map-Request message with the probe-bit set, it 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 returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set according to the procedure described in the Map-Reply is set according to the procedure described in
[REF_TO_RFC6833bis]. The Map-Reply SHOULD contain mapping data for [I-D.ietf-lisp-rfc6833bis]. The Map-Reply SHOULD contain mapping
the EID-Prefix contained in the Map-Request. This provides the data for the EID-Prefix contained in the Map-Request. This provides
opportunity for the ITR or PITR that sent the RLOC-probe to get 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 mapping updates if there were changes to the ETR's database mapping
entries. entries.
There are advantages and disadvantages of RLOC-Probing. The greatest There are advantages and disadvantages of RLOC-Probing. The greatest
benefit of RLOC-Probing is that it can handle many failure scenarios 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 allowing the ITR to determine when the path to a specific Locator is
reachable or has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a robust
mechanism for switching to using another Locator from the cached mechanism for switching to using another Locator from the cached
Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT)
estimates between a pair of Locators, which can be useful for network estimates between a pair of Locators, which can be useful for network
skipping to change at page 33, line 25 skipping to change at page 33, line 28
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate-
limited. This is important to avoid Map-Reply implosion. limited. This is important to avoid Map-Reply implosion.
5. The ETRs at the site with the changed mapping record the fact 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 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 mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops sending SMR
messages. messages.
Experimentation is in progress to determine the appropriate rate-
limit parameters.
For security reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process unsolicited Map-
Replies. To avoid Map-Cache entry corruption by a third party, a 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 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 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- Locator-Set for the stored Map-Cache entry, then the responding Map-
Request MUST be sent with an EID destination to the mapping database Request MUST be sent with an EID destination to the mapping database
system. Since the mapping database system is a more secure way to system. Since the mapping database system is a more secure way to
reach an authoritative ETR, it will deliver the Map-Request to the reach an authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data. authoritative source of the mapping data.
skipping to change at page 35, line 18 skipping to change at page 35, line 18
With respect to the source Routing Locator address, the ITR prepends With respect to the source Routing Locator address, the ITR prepends
its own IP address as the source address of the outer IP header. its own IP address as the source address of the outer IP header.
Just like it would if the destination EID was a unicast address. Just like it would if the destination EID was a unicast address.
This source Routing Locator address, like any other Routing Locator This source Routing Locator address, like any other Routing Locator
address, MUST be globally routable. address, MUST be globally routable.
There are two approaches for LISP-Multicast, one that uses native There are two approaches for LISP-Multicast, one that uses native
multicast routing in the underlay with no support from the Mapping multicast routing in the underlay with no support from the Mapping
System and the other that uses only unicast routing in the underlay System and the other that uses only unicast routing in the underlay
with support from the Mapping System. See [RFC6831] and with support from the Mapping System. See [RFC6831] and
[I.D-ietf-lisp-signal-free-multicast], respectively, for details. [I-D.ietf-lisp-signal-free-multicast], respectively, for details.
Details for LISP-Multicast and interworking with non-LISP sites are Details for LISP-Multicast and interworking with non-LISP sites are
described in [RFC6831] and [RFC6832]. described in [RFC6831] and [RFC6832].
15. Router Performance Considerations 15. Router Performance Considerations
LISP is designed to be very "hardware-based forwarding friendly". A LISP is designed to be very "hardware-based forwarding friendly". A
few implementation techniques can be used to incrementally implement few implementation techniques can be used to incrementally implement
LISP: LISP:
o When a tunnel-encapsulated packet is received by an ETR, the outer o When a tunnel-encapsulated packet is received by an ETR, the outer
skipping to change at page 37, line 21 skipping to change at page 37, line 21
for any endpoint will return a binding for the entire mobile prefix. for any endpoint will return a binding for the entire mobile prefix.
If mobile networks become a more common occurrence, it may be useful If mobile networks become a more common occurrence, it may be useful
to revisit the design of the mapping service and allow for dynamic to revisit the design of the mapping service and allow for dynamic
updates of the database. updates of the database.
The issue of interactions between mobility and LISP needs to be The issue of interactions between mobility and LISP needs to be
explored further. Specific improvements to the entire system will explored further. Specific improvements to the entire system will
depend on the details of mapping mechanisms. Mapping mechanisms depend on the details of mapping mechanisms. Mapping mechanisms
should be evaluated on how well they support session continuity for should be evaluated on how well they support session continuity for
mobile nodes. See [REF_TO_I-D.farinacci-lisp-predictive-rlocs] for mobile nodes. See [I-D.farinacci-lisp-predictive-rlocs] for more
more recent mechanisms which can provide near-zero packet loss during recent mechanisms which can provide near-zero packet loss during
handoffs. handoffs.
16.3. LISP Mobile Node Mobility 16.3. LISP Mobile Node Mobility
A mobile device can use the LISP infrastructure to achieve mobility A mobile device can use the LISP infrastructure to achieve mobility
by implementing the LISP encapsulation and decapsulation functions by implementing the LISP encapsulation and decapsulation functions
and acting as a simple ITR/ETR. By doing this, such a "LISP mobile 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 node" can use topologically independent EID IP addresses that are not
advertised into and do not impose a cost on the global routing advertised into and do not impose a cost on the global routing
system. These EIDs are maintained at the edges of the mapping system 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 in LISP Map-Servers and Map-Resolvers) and are provided on demand to
only the correspondents of the LISP mobile node. only the correspondents of the LISP mobile node.
Refer to [LISP-MN] for more details for when the EID and RLOC are co- Refer to [I-D.meyer-lisp-mn] for more details for when the EID and
located in the roaming node. RLOC are co-located in the roaming node.
17. LISP xTR Placement and Encapsulation Methods 17. LISP xTR Placement and Encapsulation Methods
[FIXME: The Authors/Ed. agree on adding further scenarios.]
This section will explore how and where ITRs and ETRs can be placed This section will explore how and where ITRs and ETRs can be placed
in the networkand will discuss the pros and cons of each scenario. in the network and will discuss the pros and cons of each scenario.
For a more detailed networkd design deployment recommendation, refer For a more detailed networkd design deployment recommendation, refer
to [RFC7215]. to [RFC7215].
There are two basic deployment tradeoffs to consider: centralized There are two basic deployment tradeoffs to consider: centralized
versus distributed caches; and flat, Recursive, or Re-encapsulating versus distributed caches; and flat, Recursive, or Re-encapsulating
Tunneling. When deciding on centralized versus distributed caching, Tunneling. When deciding on centralized versus distributed caching,
the following issues should be considered: the following issues should be considered:
o Are the xTRs spread out so that the caches are spread across all 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 the memories of each router? A centralized cache is when an ITR
skipping to change at page 41, line 7 skipping to change at page 41, line 4
17.5. Packets Egressing a LISP Site 17.5. Packets Egressing a LISP Site
When a LISP site is using two ITRs for redundancy, the failure of one 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 will likely shift outbound traffic to the second. This second
ITR's cache may not be populated with the same EID-to-RLOC mapping 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 entries as the first. If this second ITR does not have these
mappings, traffic will be dropped while the mappings are retrieved mappings, traffic will be dropped while the mappings are retrieved
from the mapping system. The retrieval of these messages may from the mapping system. The retrieval of these messages may
increase the load of requests being sent into the mapping system. increase the load of requests being sent into the mapping system.
Deployment and experimentation will determine whether this issue
requires more attention.
18. Traceroute Considerations 18. Traceroute Considerations
When a source host in a LISP site initiates a traceroute to a 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 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 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 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 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 user can see 3 distinct segments of the path from a source LISP host
to a destination LISP host: to a destination LISP host:
skipping to change at page 43, line 21 skipping to change at page 43, line 15
expecting addresses from intermediate hops in the same address format expecting addresses from intermediate hops in the same address format
for the type of traceroute it originated. Therefore, in this case, 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 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, 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 encapsulating header's TTL when a traceroute packet is encapsulated
using an RLOC from a different address family. This will cause no 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. TTL decrement to 0 to occur in core routers between the ITR and ETR.
19. Security Considerations 19. Security Considerations
FIXME: ToDo Security considerations for LISP are discussed in [RFC7833], in
addition [I-D.ietf-lisp-sec] provides authentication and integrity to
LISP mappings.
Security considerations for LISP are discussed in [LISP-THREATS], in A complete LISP threat analysis can be found in [RFC7835], in what
addition [LISP-SEC] provides authentication and integrity to LISP follows we provide a summary.
mappings.
The optional mechanisms of gleaning is offered to directly obtain a
mapping from the LISP encapsulated packets. Specifically, an xTR can
learn the EID-to-RLOC mapping by inspecting the source RLOC and
source EID of an encapsulated packet, and insert this new mapping
into its map-cache. An off-path attacker can spoof the source EID
address to divert the traffic sent to the victim's spoofed EID. If
the attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim;s RLOC, potentially
overloading it.
The LISP Data-Plane defines several mechanisms to monitor RLOC data-
plane reachability, in this context Locator-Status Bits, Nonce-
Present and Echo-Nonce bits of the LISP encapsulation header can be
manipulated by an attacker to mount a DoS attack. An off-path
attacker able to spoof the RLOC of a victim's xTR can manipulate such
mechanisms to declare a set of RLOCs unreachable. This can be used
also, for instance, to declare only one RLOC reachable with the aim
of overload it.
Map-Versioning is a data-plane mechanism used to signal a peering xTR
that a local EID-to-RLOC mapping has been updated, so that the
peering xTR uses LISP Control-Plane signaling message to retrieve a
fresh mapping. This can be used by an attacker to forge the map-
versioning field of a LISP encapsulated header and force an excessive
amount of signaling between xTRs that may overload them.
Most of the attack vectors can be mitigated with careful deployment
and configuration, information learned opportunistically (such as LSB
or gleaning) should be verified with other reachability mechanisms.
In addition, systematic rate-limitation and filtering is an effective
technique to mitigate attacks that aim to overload the control-plane.
20. Network Management Considerations 20. 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 [LISP-MIB] and [RFC6835]. found in [RFC7052] and [RFC6835].
21. IANA Considerations 21. 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 the LISP Authority (IANA) regarding registration of values related to the LISP
specification, in accordance with BCP 26 [RFC5226]. specification, in accordance with BCP 26 [RFC5226].
There are four namespaces (listed in the sub-sections below) in LISP There are four namespaces (listed in the sub-sections below) in LISP
that have been registered. that have been registered.
o LISP IANA registry allocations should not be made for purposes o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols. unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", "Experimental
Use", and "First Come First Served". Use", and "First Come First Served".
21.1. LISP ACT and Flag Fields 21.1. LISP ACT and Flag Fields
New ACT values [REF_TO_RFC6833bis] can be allocated through IETF New ACT values [I-D.ietf-lisp-rfc6833bis] can be allocated through
review or IESG approval. Four values have already been allocated by IETF review or IESG approval. Four values have already been
this specification ([REF_TO_RFC6833bis]. allocated by this specification [I-D.ietf-lisp-rfc6833bis].
In addition, LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and reserved fields,
such as the LISP header flags field (Section 5.3). New bits for such as the LISP header flags field (Section 5.3). New bits for
flags in these fields can be implemented after IETF review or IESG flags in these fields can be implemented after IETF review or IESG
approval, but these need not be managed by IANA. approval, but these need not be managed by IANA.
21.2. LISP Address Type Codes 21.2. LISP Address Type Codes
LISP Address [LCAF] type codes have a range from 0 to 255. New type LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
codes MUST be allocated consecutively, starting at 0. Type Codes defines LISP-specific encodings for AFI value 16387. LCAF encodings
0-127 are to be assigned by IETF review or IESG approval. are used for specific use-cases where different address types for
EID-records and RLOC-records are required.
Type Codes 128-255 are available according to the [RFC5226] First
Come First Served policy.
This registry, initially empty, is constructed for future use in The IANA registry "LISP Canonical Address Format (LCAF) Types" is
experimental work related to LISP Canonical Address Format (LCAF) used for LCAF types, the registry for LCAF types use the
values. See [LCAF] for details of other possible unapproved address Specification Required policy [RFC5226]. Initial values for the
encodings. The unapproved LCAF encodings are an area for further registry as well as further information can be found in [RFC8060].
study and experimentation.
21.3. LISP UDP Port Numbers 21.3. LISP UDP Port Numbers
The IANA registry has allocated UDP port numbers 4341 and 4342 for The IANA registry has allocated UDP port numbers 4341 and 4342 for
lisp-data and lisp-control operation, respectively. IANA has updated lisp-data and lisp-control operation, respectively. IANA has updated
the description for UDP ports 4341 and 4342 as follows: the description for UDP ports 4341 and 4342 as follows:
lisp-data 4341 udp LISP Data Packets lisp-data 4341 udp LISP Data Packets
lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control Packets
skipping to change at page 45, line 9 skipping to change at page 45, line 32
HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 65535. The allocation of Number values are in the range of 0 to 65535. The allocation of
values is on a first come first served basis. values is on a first come first served basis.
22. References 22. References
22.1. Normative References 22.1. Normative References
[I.D-ietf-lisp-crypto] [I-D.ietf-lisp-ddt]
Farinacci, D. and B. Weiss, "LISP Data-Plane Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Confidentiality", October 2016. Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp-
ddt-09 (work in progress), January 2017.
[I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015.
[I-D.ietf-lisp-rfc6833bis]
Fuller, V., Farinacci, D., and A. Cabellos-Aparicio,
"Locator/ID Separation Protocol (LISP) Control-Plane",
draft-ietf-lisp-rfc6833bis-00 (work in progress), December
2016.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-12
(work in progress), November 2016.
[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,
<http://www.rfc-editor.org/info/rfc768>. <http://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,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
skipping to change at page 46, line 37 skipping to change at page 47, line 32
<http://www.rfc-editor.org/info/rfc5944>. <http://www.rfc-editor.org/info/rfc5944>.
[RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture", [RFC6115] Li, T., Ed., "Recommendation for a Routing Architecture",
RFC 6115, DOI 10.17487/RFC6115, February 2011, RFC 6115, DOI 10.17487/RFC6115, February 2011,
<http://www.rfc-editor.org/info/rfc6115>. <http://www.rfc-editor.org/info/rfc6115>.
[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, <http://www.rfc-editor.org/info/rfc6275>. 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January
2013.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. DOI 10.17487/RFC6834, January 2013,
<http://www.rfc-editor.org/info/rfc6834>.
[RFC6836] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC7215] Jakab, L., Cabellos, A., Coras, F., Domingo-Pascual, J., [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID
and D. Lewis, "Locator/Identifier Separation Protocol Separation Protocol (LISP) MIB", RFC 7052,
(LISP) Network Element Deployment Considerations", DOI 10.17487/RFC7052, October 2013,
RFC 6834, April 2014. <http://www.rfc-editor.org/info/rfc7052>.
[RFC7214] Andersson, L. and C. Pignataro, "Moving Generic Associated
Channel (G-ACh) IANA Registries to a New Registry",
RFC 7214, DOI 10.17487/RFC7214, May 2014,
<http://www.rfc-editor.org/info/rfc7214>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <http://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,
<http://www.rfc-editor.org/info/rfc7833>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016,
<http://www.rfc-editor.org/info/rfc7835>.
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017,
<http://www.rfc-editor.org/info/rfc8061>.
22.2. Informative References 22.2. Informative References
[AFI] IANA, "Address Family Numbers", November 2007, [AFN] IANA, "Address Family Numbers", August 2016,
<http://www.iana.org/assignments/address-family-numbers>. <http://www.iana.org/assignments/address-family-numbers>.
[BGP-SEC] Lepinski, M. and S. Turner, "An Overview of BGPSEC", Work [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed",
in Progress, May 2012. 1999,
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed
Enhancement to the Internet Architecture", 1999,
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[CONS] Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, [I-D.farinacci-lisp-predictive-rlocs]
D., and D. Meyer, "LISP-CONS: A Content distribution Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
Overlay Network Service for LISP", Work in Progress, April RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in
2008. progress), November 2016.
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID [I-D.ietf-lisp-signal-free-multicast]
Mappings Multicast Across Cooperating Systems for LISP", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
Work in Progress, November 2007. draft-ietf-lisp-signal-free-multicast-02 (work in
progress), October 2016.
[I-D.portoles-lisp-eid-mobility] [I-D.meyer-lisp-mn]
Portoles, M., Ashtaputre, V., Moreno, V., Maino, F., and Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified Mobile Node", draft-meyer-lisp-mn-16 (work in progress),
Control Plane", Work in Progress, April 2016. December 2016.
[I.D-ietf-lisp-signal-free-multicast] [I-D.meyer-loc-id-implications]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Meyer, D. and D. Lewis, "Architectural Implications of
Work in Progress, October 2016. Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [I-D.portoles-lisp-eid-mobility]
Address Format (LCAF)", Work in Progress, January 2013. Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-01 (work in progress), October 2016.
[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.
[LISP-DDT]
Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "LISP Delegated Database Tree", Work in Progress,
April 2015.
[LISP-INTRO]
Cabellos, A. and D. Saucez, "An Architectural Introduction
to the Locator/ID Separation Protocol (LISP)", Work
in Progress, April 2015.
[LISP-MIB]
Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Work
in Progress, January 2013.
[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", Work in Progress, October 2012.
[LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Saucez, D., and O.
Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress,
October 2012.
[LISP-THREATS]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", Work in Progress, January 2016.
[LOC-ID-ARCH]
Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Work in Progress, January 2009.
[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.
[RADIR] Narten, T., "On the Scalability of Internet Routing", Work
in Progress, February 2010.
[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,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[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,
<http://www.rfc-editor.org/info/rfc2784>. <http://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
skipping to change at page 49, line 35 skipping to change at page 50, line 26
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>. February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012, DOI 10.17487/RFC6518, February 2012,
<http://www.rfc-editor.org/info/rfc6518>. <http://www.rfc-editor.org/info/rfc6518>.
[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, January 2013. Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <http://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, January 2013. (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013,
<http://www.rfc-editor.org/info/rfc6832>.
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
Protocol Internet Groper (LIG)", RFC 6835, January 2013. Protocol Internet Groper (LIG)", RFC 6835,
DOI 10.17487/RFC6835, January 2013,
<http://www.rfc-editor.org/info/rfc6835>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013. Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013,
<http://www.rfc-editor.org/info/rfc6837>.
[UDP-TUNNELS] [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935,
UDP Checksums for Tunneled Packets", Work in Progress, DOI 10.17487/RFC6935, April 2013,
January 2013. <http://www.rfc-editor.org/info/rfc6935>.
[UDP-ZERO] [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums",
for the use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013,
Work in Progress, December 2012. <http://www.rfc-editor.org/info/rfc6936>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <http://www.rfc-editor.org/info/rfc8060>.
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
skipping to change at page 51, line 44 skipping to change at page 52, line 44
Alia Atlas, Florin Coras and Alberto Rodriguez. Alia Atlas, Florin Coras and Alberto Rodriguez.
This work originated in the Routing Research Group (RRG) of the IRTF. This work originated in the Routing Research Group (RRG) of the IRTF.
An individual submission was converted into the IETF LISP working An individual submission was converted into the IETF LISP working
group document that became this RFC. group document that became this RFC.
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 experimental 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-00 B.1. Changes to draft-ietf-lisp-rfc6830bis-01
o Posted March 2017.
o Include references to new RFCs published.
o Change references from RFC6833 to RFC6833bis.
o Clarified LCAF text in the IANA section.
o Remove references to "experimental".
B.2. 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
skipping to change at page 52, line 28 skipping to change at page 53, line 40
USA USA
EMail: farinacci@gmail.com EMail: farinacci@gmail.com
Vince Fuller Vince Fuller
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: vaf@vaf.net EMail: vince.fuller@gmail.com
Dave Meyer Dave Meyer
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA San Jose, CA
USA USA
EMail: dmm@1-4-5.net EMail: dmm@1-4-5.net
Darrel Lewis Darrel Lewis
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, CA San Jose, CA
USA USA
EMail: darlewis@cisco.com EMail: darlewis@cisco.com
Albert Cabellos Albert Cabellos
UPC/BarcelonaTech UPC/BarcelonaTech
Campus Nord, C. Jordi Girona 1-3 Campus Nord, C. Jordi Girona 1-3
Barcelona, Catalunya Barcelona, Catalunya
Spain Spain
EMail: acabello@ac.upc.edu EMail: acabello@ac.upc.edu
 End of changes. 69 change blocks. 
166 lines changed or deleted 232 lines changed or added

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