draft-ietf-lisp-rfc6833bis-06.txt   draft-ietf-lisp-rfc6833bis-07.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: April 8, 2018 A. Cabellos (Ed.) Expires: June 18, 2018 A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
October 5, 2017 December 15, 2017
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-06 draft-ietf-lisp-rfc6833bis-07
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this control-plane service interface and communicating with By using this control-plane service interface and communicating with
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 April 8, 2018. This Internet-Draft will expire on June 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(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
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
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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7
4.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9
4.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10
4.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13
4.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15
4.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19
4.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22
4.8. Encapsulated Control Message Format . . . . . . . . . . . 26 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25
5. Interactions with Other LISP Components . . . . . . . . . . . 28 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26
5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 28 6. Interactions with Other LISP Components . . . . . . . . . . . 28
5.2. EID-Prefix Configuration and ETR Registration . . . . . . 29 6.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 28
5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 31 6.2. EID-Prefix Configuration and ETR Registration . . . . . . 29
5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 31 6.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 31
5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 32 6.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
7.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 33 8.1. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 33
7.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 34 8.2. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 33
7.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 34 8.3. LISP Address Type Codes . . . . . . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.4. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 36 9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 36
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 39
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 39
B.1. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 39 B.1. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 39
B.2. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 39 B.2. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 39
B.3. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 39 B.3. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 40
B.4. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 40 B.4. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 40
B.5. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 40 B.5. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 40
B.6. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 40 B.6. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 40
B.7. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 40 B.7. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 41
B.8. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41 B.8. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 B.9. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism
for replacing the addresses currently used by IP with two separate for replacing the addresses currently used by IP with two separate
name spaces: Endpoint IDs (EIDs), used within sites; and Routing name spaces: Endpoint IDs (EIDs), used within sites; and Routing
Locators (RLOCs), used on the transit networks that make up the Locators (RLOCs), used on the transit networks that make up the
Internet infrastructure. To achieve this separation, LISP defines Internet infrastructure. To achieve this separation, LISP defines
protocol mechanisms for mapping from EIDs to RLOCs. In addition, protocol mechanisms for mapping from EIDs to RLOCs. In addition,
skipping to change at page 4, line 11 skipping to change at page 4, line 12
Note that while this document assumes a LISP+ALT database mapping Note that while this document assumes a LISP+ALT database mapping
infrastructure to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of Map-Server and Map-
Resolver operation, the Mapping Service interface can (and likely Resolver operation, the Mapping Service interface can (and likely
will) be used by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other mapping database
systems as the LISP infrastructure evolves. systems as the LISP infrastructure evolves.
The LISP Mapping Service is an important component of the LISP The LISP Mapping Service is an important component of the LISP
toolset. Issues and concerns about the deployment of LISP for toolset. Issues and concerns about the deployment of LISP for
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis]. Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis].
2. Definition of Terms 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Definition of Terms
Map-Server: A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that learns of EID-
Prefix mapping entries from an ETR, via the registration mechanism Prefix mapping entries from an ETR, via the registration mechanism
described below, or some other authoritative source if one exists. described below, or some other authoritative source if one exists.
A Map-Server publishes these EID-Prefixes in a mapping database. A Map-Server publishes these EID-Prefixes in a mapping database.
Map-Request: A LISP Map-Request is a control-plane message to query
the mapping system to resolve an EID. A LISP Map-Request can also
be sent to an RLOC to test for reachability and to exchange
security keys between an encapsulator and a decapsulator. This
type of Map-Request is also known as an RLOC-Probe Request.
Map-Reply: A LISP Map-Reply is a control-plane message returned in
response to a Map-Request sent to the mapping system when
resolving an EID. A LISP Map-Reply can also be returned by a
decapsulator in response to a Map-Request sent by an encapsulator
to test for reachability. This type of Map-Reply is known as a
RLOC-Probe Reply.
Encapsulated Map-Request: A LISP Map-Request carried within an
Encapsulated Control Message (ECM), which has an additional LISP
header prepended. Sent to UDP destination port 4342. The "outer"
addresses are routable IP addresses, also known as RLOCs. Used by
an ITR when sending to a Map-Resolver and by a Map-Server when
forwarding a Map-Request to an ETR.
Map-Resolver: A network infrastructure component that accepts LISP Map-Resolver: A network infrastructure component that accepts LISP
Encapsulated Map-Requests, typically from an ITR, and determines Encapsulated (ECM) Map-Requests, typically from an ITR, and
whether or not the destination IP address is part of the EID determines whether or not the destination IP address is part of
namespace; if it is not, a Negative Map-Reply is returned. the EID namespace; if it is not, a Negative Map-Reply is returned.
Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC
mapping by consulting a mapping database system. mapping by consulting a mapping database system.
Encapsulated Map-Request: A LISP Map-Request carried within an
Encapsulated Control Message, which has an additional LISP header
prepended. Sent to UDP destination port 4342. The "outer"
addresses are globally routable IP addresses, also known as RLOCs.
Used by an ITR when sending to a Map-Resolver and by a Map-Server
when forwarding a Map-Request to an ETR.
Negative Map-Reply: A LISP Map-Reply that contains an empty Negative Map-Reply: A LISP Map-Reply that contains an empty
Locator-Set. Returned in response to a Map-Request if the Locator-Set. Returned in response to a Map-Request if the
destination EID does not exist in the mapping database. destination EID does not exist in the mapping database.
Typically, this means that the "EID" being requested is an IP Typically, this means that the "EID" being requested is an IP
address connected to a non-LISP site. address connected to a non-LISP site.
Map-Register message: A LISP message sent by an ETR to a Map-Server Map-Register message: A LISP message sent by an ETR to a Map-Server
to register its associated EID-Prefixes. In addition to the set to register its associated EID-Prefixes. In addition to the set
of EID-Prefixes to register, the message includes one or more of EID-Prefixes to register, the message includes one or more
RLOCs to be used by the Map-Server when forwarding Map-Requests RLOCs to reach ETR(s). The Map-Server uses these RLOCs when
(re-formatted as Encapsulated Map-Requests) received through the forwarding Map-Requests (re-formatted as Encapsulated Map-
database mapping system. An ETR may request that the Map-Server Requests). An ETR MAY request that the Map-Server answer Map-
answer Map-Requests on its behalf by setting the "proxy Map-Reply" Requests on its behalf by setting the "proxy Map-Reply" flag
flag (P-bit) in the message. (P-bit) in the message.
Map-Notify message: A LISP message sent by a Map-Server to an ETR Map-Notify message: A LISP message sent by a Map-Server to an ETR
to confirm that a Map-Register has been received and processed. to confirm that a Map-Register has been received and processed.
An ETR requests that a Map-Notify be returned by setting the An ETR requests that a Map-Notify be returned by setting the
"want-map-notify" flag (M-bit) in the Map-Register message. "want-map-notify" flag (M-bit) in the Map-Register message.
Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both
source and destination. source and destination. Map-Notify messages are also sent to ITRs
by Map-Servers when there are RLOC-set changes.
For definitions of other terms -- notably Map-Request, Map-Reply, For definitions of other terms, notably Ingress Tunnel Router (ITR),
Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR),
consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. refer to the LISP Data-Plane specification
[I-D.ietf-lisp-rfc6830bis].
3. Basic Overview 4. Basic Overview
A Map-Server is a device that publishes EID-Prefixes in a LISP A Map-Server is a device that publishes EID-Prefixes in a LISP
mapping database on behalf of a set of ETRs. When it receives a Map mapping database on behalf of a set of ETRs. When it receives a Map
Request (typically from an ITR), it consults the mapping database to Request (typically from an ITR), it consults the mapping database to
find an ETR that can answer with the set of RLOCs for an EID-Prefix. find an ETR that can answer with the set of RLOCs for an EID-Prefix.
To publish its EID-Prefixes, an ETR periodically sends Map-Register To publish its EID-Prefixes, an ETR periodically sends Map-Register
messages to the Map-Server. A Map-Register message contains a list messages to the Map-Server. A Map-Register message contains a list
of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR of EID-Prefixes plus a set of RLOCs that can be used to reach the
when a Map-Server needs to forward a Map-Request to it. ETRs.
When LISP+ALT is used as the mapping database, a Map-Server connects When LISP+ALT is used as the mapping database, a Map-Server connects
to the ALT network and acts as a "last-hop" ALT-Router. Intermediate to the ALT network and acts as a "last-hop" ALT-Router. Intermediate
ALT-Routers forward Map-Requests to the Map-Server that advertises a ALT-Routers forward Map-Requests to the Map-Server that advertises a
particular EID-Prefix, and the Map-Server forwards them to the owning particular EID-Prefix, and the Map-Server forwards them to the owning
ETR, which responds with Map-Reply messages. ETR, which responds with Map-Reply messages.
When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server When LISP-DDT [RFC8111] is used as the mapping database, a Map-Server
sends the final Map-Referral messages from the Delegated Database sends the final Map-Referral messages from the Delegated Database
Tree. Tree.
skipping to change at page 5, line 45 skipping to change at page 6, line 17
to answer those requests. On a LISP+ALT network, a Map-Resolver acts to answer those requests. On a LISP+ALT network, a Map-Resolver acts
as a "first-hop" ALT-Router. It has Generic Routing Encapsulation as a "first-hop" ALT-Router. It has Generic Routing Encapsulation
(GRE) tunnels configured to other ALT-Routers and uses BGP to learn (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
paths to ETRs for different prefixes in the LISP+ALT database. The paths to ETRs for different prefixes in the LISP+ALT database. The
Map-Resolver uses this path information to forward Map-Requests over Map-Resolver uses this path information to forward Map-Requests over
the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map-
Resolver maintains a referral-cache and acts as a "first-hop" DDT- Resolver maintains a referral-cache and acts as a "first-hop" DDT-
node. The Map-Resolver uses the referral information to forward Map- node. The Map-Resolver uses the referral information to forward Map-
Requests. Requests.
Note that while it is conceivable that a non-LISP-DDT Map-Resolver Note that while it is conceivable that a Map-Resolver could cache
could cache responses to improve performance, issues surrounding responses to improve performance, issues surrounding cache management
cache management will need to be resolved so that doing so will be will need to be resolved so that doing so will be reliable and
reliable and practical. As initially deployed, Map-Resolvers will practical. As initially deployed, Map-Resolvers will operate only in
operate only in a non-caching mode, decapsulating and forwarding a non-caching mode, decapsulating and forwarding Encapsulated Map
Encapsulated Map Requests received from ITRs. Any specification of Requests received from ITRs. Any specification of caching
caching functionality is left for future work. functionality is left for future work.
Note that a single device can implement the functions of both a Map- Note that a single device can implement the functions of both a Map-
Server and a Map-Resolver, and in many cases the functions will be Server and a Map-Resolver, and in many cases the functions will be
co-located in that way. Also, there can be ALT-only nodes and DDT- co-located in that way. Also, there can be ALT-only nodes and DDT-
only nodes, when LISP+ALT and LISP-DDT are used, respectively, to only nodes, when LISP+ALT and LISP-DDT are used, respectively, to
connect Map-Resolvers and Map-Servers together to make up the Mapping connect Map-Resolvers and Map-Servers together to make up the Mapping
System. System.
Detailed descriptions of the LISP packet types referenced by this Detailed descriptions of the LISP packet types referenced by this
document may be found in [I-D.ietf-lisp-rfc6830bis]. document may be found in [I-D.ietf-lisp-rfc6830bis].
4. LISP IPv4 and IPv6 Control-Plane Packet Formats 5. LISP IPv4 and IPv6 Control-Plane Packet Formats
The following UDP packet formats are used by the LISP control plane. The following UDP packet formats are used by the LISP control plane.
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 8, line 15 skipping to change at page 8, line 15
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port | / | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LISP UDP-based messages are the Map-Request and Map-Reply When a UDP Map-Request, Map-Register, or Map-Notify (when used as a
messages. When a UDP Map-Request is sent, the UDP source port is notification message) are sent, the UDP source port is chosen by the
chosen by the sender and the destination UDP port number is set to sender and the destination UDP port number is set to 4342. When a
4342. When a UDP Map-Reply is sent, the source UDP port number is UDP Map-Reply Map-Notify (when used as an acknowledgement to a Map-
Register), or Map-Notify-Ack are sent, the source UDP port number is
set to 4342 and the destination UDP port number is copied from the set to 4342 and the destination UDP port number is copied from the
source port of either the Map-Request or the invoking data packet. source port of either the Map-Request or the invoking data packet.
Implementations MUST be prepared to accept packets when either the Implementations MUST be prepared to accept packets when either the
source port or destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 due to NATs
changing port number values. changing port number values.
The 'UDP Length' field will reflect the length of the UDP header and The 'UDP Length' field will reflect the length of the UDP header and
the LISP Message payload. the LISP Message payload.
The UDP checksum is computed and set to non-zero for Map-Request, The UDP checksum is computed and set to non-zero for all messages
Map-Reply, Map-Register, and Encapsulated Control Message (ECM) sent to or from port 4342. It MUST be checked on receipt, and if the
control messages. It MUST be checked on receipt, and if the checksum checksum fails, the control message MUST be dropped.
fails, the packet MUST be dropped.
The format of control messages includes the UDP header so the The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit message checksum and length fields can be used to protect and delimit message
boundaries. boundaries.
4.1. LISP Control Packet Type Allocations 5.1. LISP Control Packet Type Allocations
This section defines the LISP control message formats and summarizes This section defines the LISP control message formats and summarizes
for IANA the LISP Type codes assigned by this document. For for IANA the LISP Type codes assigned by this document. For
completeness, this document references the LISP Shared Extension completeness, this document references the LISP Shared Extension
Message assigned by [RFC8113]. Message type definitions are: Message assigned by [RFC8113]. Message type definitions are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110' LISP Map-Referral: 6 b'0110'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
Not Assigned 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- b'1110'
LISP Shared Extension Message: 15 b'1111' [RFC8113] LISP Shared Extension Message: 15 b'1111' [RFC8113]
Values in the "Not Assigned" range can be assigned according to Values in the "Not Assigned" range can be assigned according to
procedures in [RFC5226]. Documents that request for a new LISP procedures in [RFC8126]. Documents that request for a new LISP
packet type may indicate a preferred value in Section 7.3. packet type MAY indicate a preferred value in Section 8.3.
Protocol designers experimenting with new message formats should use Protocol designers experimenting with new message formats SHOULD use
the LISP Shared Extension Message Type and request a [RFC8113] sub- the LISP Shared Extension Message Type and request a [RFC8113] sub-
type assignment. type assignment.
All LISP control-plane messages use Address Family Identifiers (AFI) All LISP control-plane messages use Address Family Identifiers (AFI)
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
encode either fixed or variable length addresses. This includes encode either fixed or variable length addresses. This includes
explicit fields in each control message or part of EID-records or explicit fields in each control message or part of EID-records or
RLOC-records in commonly formatted messages. RLOC-records in commonly formatted messages.
The LISP control-plane describes how other data-planes can encode The LISP control-plane describes how other data-planes can encode
messages to support the SMR and RLOC-probing procedures of the LISP messages to support the SMR and RLOC-probing procedures of the LISP
data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane data-plane defined in [I-D.ietf-lisp-rfc6830bis]. This control-plane
specification itself does not offer such functionality and other specification itself does not offer such functionality and other
data-planes can use their own mechanisms that do not rely on the LISP data-planes can use their own mechanisms that do not rely on the LISP
control-plane. control-plane.
4.2. Map-Request Message Format 5.2. Map-Request Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 32 skipping to change at page 12, line 32
selecting the destination address from any address family for the selecting the destination address from any address family for the
Map-Reply message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a routable RLOC address
of the sender of the Map-Request message. of the sender of the Map-Request message.
EID mask-len: This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the EID-Prefix.
EID-Prefix-AFI: This is the address family of the EID-Prefix EID-Prefix-AFI: This is the address family of the EID-Prefix
according to [AFI] and [RFC8060]. according to [AFI] and [RFC8060].
EID-Prefix: This prefix is 4 octets for an IPv4 address family and EID-Prefix: This prefix is 4 octets for an IPv4 address family and
16 octets for an IPv6 address family. When a Map-Request is sent 16 octets for an IPv6 address family when the EID-Prefix-AFI is 1
by an ITR because a data packet is received for a destination or 2, respectively. For other AFIs [AFI], the length varies and
where there is no mapping entry, the EID-Prefix is set to the for the LCAF AFI the format is defined in [RFC8060]. When a Map-
destination IP address of the data packet, and the 'EID mask-len' Request is sent by an ITR because a data packet is received for a
is set to 32 or 128 for IPv4 or IPv6, respectively. When an xTR destination where there is no mapping entry, the EID-Prefix is set
wants to query a site about the status of a mapping it already has to the destination IP address of the data packet, and the 'EID
cached, the EID-Prefix used in the Map-Request has the same mask mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively.
length as the EID-Prefix returned from the site when it sent a When an xTR wants to query a site about the status of a mapping it
Map-Reply message. already has cached, the EID-Prefix used in the Map-Request has the
same mask length as the EID-Prefix returned from the site when it
sent a Map-Reply message.
Map-Reply Record: When the M-bit is set, this field is the size of a Map-Reply Record: When the M-bit is set, this field is the size of a
single "Record" in the Map-Reply format. This Map-Reply record single "Record" in the Map-Reply format. This Map-Reply record
contains the EID-to-RLOC mapping entry associated with the Source contains the EID-to-RLOC mapping entry associated with the Source
EID. This allows the ETR that will receive this Map-Request to EID. This allows the ETR that will receive this Map-Request to
cache the data if it chooses to do so. cache the data if it chooses to do so.
4.3. EID-to-RLOC UDP Map-Request Message 5.3. EID-to-RLOC UDP Map-Request Message
A Map-Request is sent from an ITR when it needs a mapping for an EID, A Map-Request is sent from an ITR when it needs a mapping for an EID,
wants to test an RLOC for reachability, or wants to refresh a mapping wants to test an RLOC for reachability, or wants to refresh a mapping
before TTL expiration. For the initial case, the destination IP before TTL expiration. For the initial case, the destination IP
address used for the Map-Request is the data packet's destination address used for the Map-Request is the data packet's destination
address (i.e., the destination EID) that had a mapping cache lookup address (i.e., the destination EID) that had a mapping cache lookup
failure. For the latter two cases, the destination IP address used failure. For the latter two cases, the destination IP address used
for the Map-Request is one of the RLOC addresses from the Locator-Set for the Map-Request is one of the RLOC addresses from the Locator-Set
of the Map-Cache entry. The source address is either an IPv4 or IPv6 of the Map-Cache entry. The source address is either an IPv4 or IPv6
RLOC address, depending on whether the Map-Request is using an IPv4 RLOC address, depending on whether the Map-Request is using an IPv4
skipping to change at page 13, line 37 skipping to change at page 13, line 37
configured Locators in this list or just provide one locator address configured Locators in this list or just provide one locator address
from each address family it supports. If the ITR erroneously from each address family it supports. If the ITR erroneously
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request. Request.
Map-Requests can also be LISP encapsulated using UDP destination Map-Requests can also be LISP encapsulated using UDP destination
port 4342 with a LISP Type value set to "Encapsulated Control port 4342 with a LISP Type value set to "Encapsulated Control
Message", when sent from an ITR to a Map-Resolver. Likewise, Map- Message", when sent from an ITR to a Map-Resolver. Likewise, Map-
Requests are LISP encapsulated the same way from a Map-Server to an Requests are LISP encapsulated the same way from a Map-Server to an
ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be
found in Section 4.8. found in Section 5.8.
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-
Request for the same EID-Prefix be sent no more than once per second. Request for the same EID-Prefix be sent no more than once per second.
An ITR that is configured with mapping database information (i.e., it An ITR that is configured with mapping database information (i.e., it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the map-cache, it MAY originate a "verifying not have this mapping in the map-cache, it MAY originate a "verifying
Map-Request", addressed to the map-requesting ITR and the ETR MAY add Map-Request", addressed to the map-requesting ITR and the ETR MAY add
a Map-Cache entry. If the ETR has a Map-Cache entry that matches the a Map-Cache entry. If the ETR has a Map-Cache entry that matches the
"piggybacked" EID and the RLOC is in the Locator-Set for the entry, "piggybacked" EID and the RLOC is in the Locator-Set for the entry,
then it may send the "verifying Map-Request" directly to the then it MAY send the "verifying Map-Request" directly to the
originating Map-Request source. If the RLOC is not in the Locator- originating Map-Request source. If the RLOC is not in the Locator-
Set, then the ETR MUST send the "verifying Map-Request" to the Set, then the ETR MUST send the "verifying Map-Request" to the
"piggybacked" EID. Doing this forces the "verifying Map-Request" to "piggybacked" EID. Doing this forces the "verifying Map-Request" to
go through the mapping database system to reach the authoritative go through the mapping database system to reach the authoritative
source of information about that EID, guarding against RLOC-spoofing source of information about that EID, guarding against RLOC-spoofing
in the "piggybacked" mapping data. in the "piggybacked" mapping data.
4.4. Map-Reply Message Format 5.4. Map-Reply Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count | |Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 43 skipping to change at page 16, line 43
Prefix. Prefix.
EID mask-len: This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the EID-Prefix.
ACT: This 3-bit field describes Negative Map-Reply actions. In any ACT: This 3-bit field describes Negative Map-Reply actions. In any
other message type, these bits are set to 0 and ignored on other message type, these bits are set to 0 and ignored on
receipt. These bits are used only when the 'Locator Count' field receipt. These bits are used only when the 'Locator Count' field
is set to 0. The action bits are encoded only in Map-Reply is set to 0. The action bits are encoded only in Map-Reply
messages. The actions defined are used by an ITR or PITR when a messages. The actions defined are used by an ITR or PITR when a
destination EID matches a negative Map-Cache entry. Unassigned destination EID matches a negative Map-Cache entry. Unassigned
values should cause a Map-Cache entry to be created, and when values SHOULD cause a Map-Cache entry to be created, and when
packets match this negative cache entry, they will be dropped. packets match this negative cache entry, they will be dropped.
The current assigned values are: The current assigned values are:
(0) No-Action: The map-cache is kept alive, and no packet (0) No-Action: The map-cache is kept alive, and no packet
encapsulation occurs. encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
skipping to change at page 18, line 49 skipping to change at page 18, line 49
probed and MAY be different from the source address of the Map- probed and MAY be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular Locator MUST use this Reply. An ITR that RLOC-probes a particular Locator MUST use this
Locator for retrieving the data structure used to store the fact Locator for retrieving the data structure used to store the fact
that the Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set for a single
Locator in the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an implementation sets more
than one p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the Map-Reply MUST
select the first Locator. The p-bit MUST NOT be set for Locator- select the first Locator. The p-bit MUST NOT be set for Locator-
Set records sent in Map-Request and Map-Register messages. Set records sent in Map-Request and Map-Register messages.
R: This is set when the sender of a Map-Reply has a route to the R: This is set when the sender of a Map-Reply has a route to the
Locator in the Locator data record. This receiver may find this Locator in the Locator data record. This receiver MAY find this
useful to know if the Locator is up but not necessarily reachable useful to know if the Locator is up but not necessarily reachable
from the receiver's point of view. See also EID-Reachability from the receiver's point of view. See also EID-Reachability
[I-D.ietf-lisp-rfc6830bis] for another way the R-bit may be used. [I-D.ietf-lisp-rfc6830bis] for another way the R-bit MAY be used.
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-
AFI' field) assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR. Note that the destination RLOC
address MAY be an anycast address. A source RLOC can be an address MAY be an anycast address. A source RLOC can be an
anycast address as well. The source or destination RLOC MUST NOT anycast address as well. The source or destination RLOC MUST NOT
be the broadcast address (255.255.255.255 or any subnet broadcast be the broadcast address (255.255.255.255 or any subnet broadcast
address known to the router) and MUST NOT be a link-local address known to the router) and MUST NOT be a link-local
multicast address. The source RLOC MUST NOT be a multicast multicast address. The source RLOC MUST NOT be a multicast
address. The destination RLOC SHOULD be a multicast address if it address. The destination RLOC SHOULD be a multicast address if it
is being mapped from a multicast destination EID. is being mapped from a multicast destination EID.
4.5. EID-to-RLOC UDP Map-Reply Message 5.5. EID-to-RLOC UDP Map-Reply Message
A Map-Reply returns an EID-Prefix with a prefix length that is less A Map-Reply returns an EID-Prefix with a prefix length that is less
than or equal to the EID being requested. The EID being requested is than or equal to the EID being requested. The EID being requested is
either from the destination field of an IP header of a Data-Probe or either from the destination field of an IP header of a Data-Probe or
the EID record of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the Map-Reply are
globally routable IP addresses of all ETRs for the LISP site. Each routable IP addresses of all ETRs for the LISP site. Each RLOC
RLOC conveys status reachability but does not convey path conveys status reachability but does not convey path reachability
reachability from a requester's perspective. Separate testing of from a requester's perspective. Separate testing of path
path reachability is required. See RLOC-reachability reachability is required. See RLOC-reachability
[I-D.ietf-lisp-rfc6830bis] for details. [I-D.ietf-lisp-rfc6830bis] for details.
Note that a Map-Reply may contain different EID-Prefix granularity Note that a Map-Reply MAY contain different EID-Prefix granularity
(prefix + length) than the Map-Request that triggers it. This might (prefix + length) than the Map-Request that triggers it. This might
occur if a Map-Request were for a prefix that had been returned by an occur if a Map-Request were for a prefix that had been returned by an
earlier Map-Reply. In such a case, the requester updates its cache earlier Map-Reply. In such a case, the requester updates its cache
with the new prefix information and granularity. For example, a with the new prefix information and granularity. For example, a
requester with two cached EID-Prefixes that are covered by a Map- requester with two cached EID-Prefixes that are covered by a Map-
Reply containing one less-specific prefix replaces the entry with the Reply containing one less-specific prefix replaces the entry with the
less-specific EID-Prefix. Note that the reverse, replacement of one less-specific EID-Prefix. Note that the reverse, replacement of one
less-specific prefix with multiple more-specific prefixes, can also less-specific prefix with multiple more-specific prefixes, can also
occur, not by removing the less-specific prefix but rather by adding occur, not by removing the less-specific prefix but rather by adding
the more-specific prefixes that, during a lookup, will override the the more-specific prefixes that, during a lookup, will override the
less-specific prefix. less-specific prefix.
When an ETR is configured with overlapping EID-Prefixes, a Map- When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility],
Request with an EID that best matches any EID-Prefix MUST be returned the database mapping system may have overlapping EID-prefixes. Or
in a single Map-Reply message. For instance, if an ETR had database when a LISP site is configured with multiple sets of ETRs that
mapping entries for EID-Prefixes: support different EID-prefix lengths, the database mapping system may
have overlapping EID-prefixes. When overlapping EID-prefixes exist,
a Map-Request with an EID that best matches any EID-Prefix MUST be
returned in a single Map-Reply message. For instance, if an ETR had
database mapping entries for EID-Prefixes:
10.0.0.0/8 10.0.0.0/8
10.1.0.0/16 10.1.0.0/16
10.1.1.0/24 10.1.1.0/24
10.1.2.0/24 10.1.2.0/24
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record
count of 1 to be returned with a mapping record EID-Prefix of count of 1 to be returned with a mapping record EID-Prefix of
10.1.1.0/24. 10.1.1.0/24.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
choose a locator address from one of the address families it choose a locator address from one of the address families it
supports. For Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address of the Map-Reply
is copied from the source address of the Data-Probe message that is is copied from the source address of the Data-Probe message that is
invoking the reply. The source address of the Map-Reply is one of invoking the reply. The source address of the Map-Reply is one of
the local IP addresses chosen to allow Unicast Reverse Path the local IP addresses chosen to allow Unicast Reverse Path
Forwarding (uRPF) checks to succeed in the upstream service provider. Forwarding (uRPF) checks to succeed in the upstream service provider.
The destination port of a Map-Reply message is copied from the source The destination port of a Map-Reply message is copied from the source
port of the Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source port of the
Map-Reply message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port 4342.
4.6. Map-Register Message Format 5.6. Map-Register Message Format
This section specifies the encoding format for the Map-Register This section specifies the encoding format for the Map-Register
message. The message is sent in UDP with a destination UDP port of message. The message is sent in UDP with a destination UDP port of
4342 and a randomly selected UDP source port number. 4342 and a randomly selected UDP source port number.
The Map-Register message format is: The Map-Register message format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 44 skipping to change at page 23, line 44
sending a Map-Register message. The Map-Notify message sent by a sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to acknowledge receipt of a Map-Register Map-Server is used to acknowledge receipt of a Map-Register
message. message.
Record Count: This is the number of records in this Map-Register Record Count: This is the number of records in this Map-Register
message. A record is comprised of that portion of the packet message. A record is comprised of that portion of the packet
labeled 'Record' above and occurs the number of times equal to labeled 'Record' above and occurs the number of times equal to
Record Count. Record Count.
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register
messages. Since the Map-Register message is authenticated, the messages if no Map-Notify message is expected to acknowledge it.
'Nonce' field is not currently used for any security function but Since the Map-Register message is authenticated, the 'Nonce' field
may be in the future as part of an anti-replay solution. is not currently used for any security function but MAY be in the
future as part of an anti-replay solution.
Key ID: This is a configured key-id value that corresponds to a Key ID: This is a configured key-id value that corresponds to a
shared-secret password that is used to authenticate the sender. shared-secret password that is used to authenticate the sender.
Multiple shared-secrets can be used to roll over keys in a non- Multiple shared-secrets can be used to roll over keys in a non-
disruptive way. disruptive way.
Algorithm ID: This is the configured Message Authentication Code Algorithm ID: This is the configured Message Authentication Code
(MAC) algorithm value used for the authentication function. See (MAC) algorithm value used for the authentication function. See
Algorithm ID Numbers in the Section 7.3 for codepoint assignments. Algorithm ID Numbers in the Section 8.3 for codepoint assignments.
Authentication Data Length: This is the length in octets of the Authentication Data Length: This is the length in octets of the
'Authentication Data' field that follows this field. The length 'Authentication Data' field that follows this field. The length
of the 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on the MAC
algorithm used. The length field allows a device that doesn't algorithm used. The length field allows a device that doesn't
know the MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the packet.
Authentication Data: This is the message digest used from the output Authentication Data: This is the message digest used from the output
of the MAC algorithm. The entire Map-Register payload is of the MAC algorithm. The entire Map-Register payload is
authenticated with this field preset to 0. After the MAC is authenticated with this field preset to 0. After the MAC is
computed, it is placed in this field. Implementations of this computed, it is placed in this field. Implementations of this
specification MUST include support for HMAC-SHA-1-96 [RFC2404], specification MUST include support for HMAC-SHA-1-96 [RFC2404],
and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED.
The definition of the rest of the Map-Register can be found in The definition of the rest of the Map-Register can be found in
Section 4.4. Section 5.4.
4.7. Map-Notify/Map-Notify-Ack Message Format 5.7. Map-Notify/Map-Notify-Ack Message Format
This section specifies the encoding format for the Map-Notify and This section specifies the encoding format for the Map-Notify and
Map-Notify-Ack messages. The messages are sent inside a UDP packet Map-Notify-Ack messages. The messages are sent inside a UDP packet
with source and destination UDP ports equal to 4342. with source and destination UDP ports equal to 4342.
The Map-Notify and Map-Notify-Ack message formats are: The Map-Notify and Map-Notify-Ack message formats are:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 5 skipping to change at page 26, line 5
Type: 4/5 (Map-Notify/Map-Notify-Ack) Type: 4/5 (Map-Notify/Map-Notify-Ack)
The Map-Notify message has the same contents as a Map-Register The Map-Notify message has the same contents as a Map-Register
message. See the Map-Register section for field descriptions. message. See the Map-Register section for field descriptions.
The Map-Notify-Ack message has the same contents as a Map-Notify The Map-Notify-Ack message has the same contents as a Map-Notify
message. It is used to acknowledge the receipt of a Map-Notify and message. It is used to acknowledge the receipt of a Map-Notify and
for the sender to stop retransmitting a Map-Notify with the same for the sender to stop retransmitting a Map-Notify with the same
nonce. nonce.
4.8. Encapsulated Control Message Format 5.8. Encapsulated Control Message Format
An Encapsulated Control Message (ECM) is used to encapsulate control An Encapsulated Control Message (ECM) is used to encapsulate control
packets sent between xTRs and the mapping database system. packets sent between xTRs and the mapping database system.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
skipping to change at page 27, line 39 skipping to change at page 27, line 39
control packet being encapsulated. When the control packet is control packet being encapsulated. When the control packet is
a Map-Request or Map-Register, the source port is selected by a Map-Request or Map-Register, the source port is selected by
the ITR/PITR and the destination port is 4342. When the the ITR/PITR and the destination port is 4342. When the
control packet is a Map-Reply, the source port is 4342 and the control packet is a Map-Reply, the source port is 4342 and the
destination port is assigned from the source port of the destination port is assigned from the source port of the
invoking Map-Request. Port number 4341 MUST NOT be assigned to invoking Map-Request. Port number 4341 MUST NOT be assigned to
either port. The checksum field MUST be non-zero. either port. The checksum field MUST be non-zero.
LCM: The format is one of the control message formats described in LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages are this section. At this time, only Map-Request messages are
allowed to be encapsulated. In the future, PIM Join/Prune allowed to be control-plane (ECM) encapsulated. In the future,
messages [RFC6831] might be allowed. Encapsulating other types PIM Join/Prune messages [RFC6831] might be allowed.
of LISP control messages is for further study. When Map- Encapsulating other types of LISP control messages is for
Requests are sent for RLOC-Probing purposes (i.e., the probe- further study. When Map-Requests are sent for RLOC-Probing
bit is set), they MUST NOT be sent inside Encapsulated Control purposes (i.e., the probe-bit is set), they MUST NOT be sent
Messages. inside Encapsulated Control Messages.
5. Interactions with Other LISP Components 6. Interactions with Other LISP Components
5.1. ITR EID-to-RLOC Mapping Resolution 6.1. ITR EID-to-RLOC Mapping Resolution
An ITR is configured with one or more Map-Resolver addresses. These An ITR is configured with one or more Map-Resolver addresses. These
addresses are "Locators" (or RLOCs) and must be routable on the addresses are "Locators" (or RLOCs) and MUST be routable on the
underlying core network; they must not need to be resolved through underlying core network; they MUST NOT need to be resolved through
LISP EID-to-RLOC mapping, as that would introduce a circular LISP EID-to-RLOC mapping, as that would introduce a circular
dependency. When using a Map-Resolver, an ITR does not need to dependency. When using a Map-Resolver, an ITR does not need to
connect to any other database mapping system. In particular, the ITR connect to any other database mapping system. In particular, the ITR
need not connect to the LISP+ALT infrastructure or implement the BGP need not connect to the LISP+ALT infrastructure or implement the BGP
and GRE protocols that it uses. and GRE protocols that it uses.
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
when it needs an EID-to-RLOC mapping that is not found in its local when it needs an EID-to-RLOC mapping that is not found in its local
map-cache. Using the Map-Resolver greatly reduces both the map-cache. Using the Map-Resolver greatly reduces both the
complexity of the ITR implementation and the costs associated with complexity of the ITR implementation and the costs associated with
skipping to change at page 28, line 44 skipping to change at page 28, line 44
o A Negative Map-Reply, with action code of "Natively-Forward", from o A Negative Map-Reply, with action code of "Natively-Forward", from
a Map-Server that is authoritative for an EID-Prefix that matches a Map-Server that is authoritative for an EID-Prefix that matches
the requested EID but that does not have an actively registered, the requested EID but that does not have an actively registered,
more-specific ID-prefix. In this case, the requested EID is said more-specific ID-prefix. In this case, the requested EID is said
to match a "hole" in the authoritative EID-Prefix. If the to match a "hole" in the authoritative EID-Prefix. If the
requested EID matches a more-specific EID-Prefix that has been requested EID matches a more-specific EID-Prefix that has been
delegated by the Map-Server but for which no ETRs are currently delegated by the Map-Server but for which no ETRs are currently
registered, a 1-minute TTL is returned. If the requested EID registered, a 1-minute TTL is returned. If the requested EID
matches a non-delegated part of the authoritative EID-Prefix, then matches a non-delegated part of the authoritative EID-Prefix, then
it is not a LISP EID and a 15-minute TTL is returned. See it is not a LISP EID and a 15-minute TTL is returned. See
Section 5.2 for discussion of aggregate EID-Prefixes and details Section 6.2 for discussion of aggregate EID-Prefixes and details
of Map-Server EID-Prefix matching. of Map-Server EID-Prefix matching.
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
possibly from a Map-Server answering on behalf of the ETR. See possibly from a Map-Server answering on behalf of the ETR. See
Section 5.4 for more details on Map-Resolver message processing. Section 6.4 for more details on Map-Resolver message processing.
Note that an ITR may be configured to both use a Map-Resolver and to Note that an ITR MAY be configured to both use a Map-Resolver and to
participate in a LISP+ALT logical network. In such a situation, the participate in a LISP+ALT logical network. In such a situation, the
ITR should send Map-Requests through the ALT network for any EID- ITR SHOULD send Map-Requests through the ALT network for any EID-
Prefix learned via ALT BGP. Such a configuration is expected to be Prefix learned via ALT BGP. Such a configuration is expected to be
very rare, since there is little benefit to using a Map-Resolver if very rare, since there is little benefit to using a Map-Resolver if
an ITR is already using LISP+ALT. There would be, for example, no an ITR is already using LISP+ALT. There would be, for example, no
need for such an ITR to send a Map-Request to a possibly non-existent need for such an ITR to send a Map-Request to a possibly non-existent
EID (and rely on Negative Map-Replies) if it can consult the ALT EID (and rely on Negative Map-Replies) if it can consult the ALT
database to verify that an EID-Prefix is present before sending that database to verify that an EID-Prefix is present before sending that
Map-Request. Map-Request.
5.2. EID-Prefix Configuration and ETR Registration 6.2. EID-Prefix Configuration and ETR Registration
An ETR publishes its EID-Prefixes on a Map-Server by sending LISP An ETR publishes its EID-Prefixes on a Map-Server by sending LISP
Map-Register messages. A Map-Register message includes Map-Register messages. A Map-Register message includes
authentication data, so prior to sending a Map-Register message, the authentication data, so prior to sending a Map-Register message, the
ETR and Map-Server must be configured with a shared secret or other ETR and Map-Server SHOULD be configured with a shared secret or other
relevant authentication information. A Map-Server's configuration relevant authentication information. A Map-Server's configuration
must also include a list of the EID-Prefixes for which each ETR is SHOULD also include a list of the EID-Prefixes for which each ETR is
authoritative. Upon receipt of a Map-Register from an ETR, a Map- authoritative. Upon receipt of a Map-Register from an ETR, a Map-
Server accepts only EID-Prefixes that are configured for that ETR. Server accepts only EID-Prefixes that are configured for that ETR.
Failure to implement such a check would leave the mapping system Failure to implement such a check would leave the mapping system
vulnerable to trivial EID-Prefix hijacking attacks. As developers vulnerable to trivial EID-Prefix hijacking attacks. As developers
and operators gain experience with the mapping system, additional, and operators gain experience with the mapping system, additional,
stronger security measures may be added to the registration process. stronger security measures MAY be added to the registration process.
In addition to the set of EID-Prefixes defined for each ETR that may In addition to the set of EID-Prefixes defined for each ETR that MAY
register, a Map-Server is typically also configured with one or more register, a Map-Server is typically also configured with one or more
aggregate prefixes that define the part of the EID numbering space aggregate prefixes that define the part of the EID numbering space
assigned to it. When LISP+ALT is the database in use, aggregate EID- assigned to it. When LISP+ALT is the database in use, aggregate EID-
Prefixes are implemented as discard routes and advertised into ALT Prefixes are implemented as discard routes and advertised into ALT
BGP. The existence of aggregate EID-Prefixes in a Map-Server's BGP. The existence of aggregate EID-Prefixes in a Map-Server's
database means that it may receive Map Requests for EID-Prefixes that database means that it MAY receive Map Requests for EID-Prefixes that
match an aggregate but do not match a registered prefix; Section 5.3 match an aggregate but do not match a registered prefix; Section 6.3
describes how this is handled. describes how this is handled.
Map-Register messages are sent periodically from an ETR to a Map- Map-Register messages are sent periodically from an ETR to a Map-
Server with a suggested interval between messages of one minute. A Server with a suggested interval between messages of one minute. A
Map-Server should time out and remove an ETR's registration if it has Map-Server SHOULD time out and remove an ETR's registration if it has
not received a valid Map-Register message within the past not received a valid Map-Register message within the past
three minutes. When first contacting a Map-Server after restart or three minutes. When first contacting a Map-Server after restart or
changes to its EID-to-RLOC database mappings, an ETR may initially changes to its EID-to-RLOC database mappings, an ETR MAY initially
send Map-Register messages at an increased frequency, up to one every send Map-Register messages at an increased frequency, up to one every
20 seconds. This "quick registration" period is limited to 20 seconds. This "quick registration" period is limited to
five minutes in duration. five minutes in duration.
An ETR may request that a Map-Server explicitly acknowledge receipt An ETR MAY request that a Map-Server explicitly acknowledge receipt
and processing of a Map-Register message by setting the "want-map- and processing of a Map-Register message by setting the "want-map-
notify" (M-bit) flag. A Map-Server that receives a Map-Register with notify" (M-bit) flag. A Map-Server that receives a Map-Register with
this flag set will respond with a Map-Notify message. Typical use of this flag set will respond with a Map-Notify message. Typical use of
this flag by an ETR would be to set it for Map-Register messages sent this flag by an ETR would be to set it for Map-Register messages sent
during the initial "quick registration" with a Map-Server but then during the initial "quick registration" with a Map-Server but then
set it only occasionally during steady-state maintenance of its set it only occasionally during steady-state maintenance of its
association with that Map-Server. Note that the Map-Notify message association with that Map-Server. Note that the Map-Notify message
is sent to UDP destination port 4342, not to the source port is sent to UDP destination port 4342, not to the source port
specified in the original Map-Register message. specified in the original Map-Register message.
Note that a one-minute minimum registration interval during Note that a one-minute minimum registration interval during
maintenance of an ETR-Map-Server association places a lower bound on maintenance of an ETR-Map-Server association places a lower bound on
how quickly and how frequently a mapping database entry can be how quickly and how frequently a mapping database entry can be
updated. This may have implications for what sorts of mobility can updated. This MAY have implications for what sorts of mobility can
be supported directly by the mapping system; shorter registration be supported directly by the mapping system; shorter registration
intervals or other mechanisms might be needed to support faster intervals or other mechanisms might be needed to support faster
mobility in some cases. For a discussion on one way that faster mobility in some cases. For a discussion on one way that faster
mobility may be implemented for individual devices, please see mobility MAY be implemented for individual devices, please see
[I-D.ietf-lisp-mn]. [I-D.ietf-lisp-mn].
An ETR may also request, by setting the "proxy Map-Reply" flag An ETR MAY also request, by setting the "proxy Map-Reply" flag
(P-bit) in the Map-Register message, that a Map-Server answer Map- (P-bit) in the Map-Register message, that a Map-Server answer Map-
Requests instead of forwarding them to the ETR. See Requests instead of forwarding them to the ETR. See
[I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets [I-D.ietf-lisp-rfc6830bis] for details on how the Map-Server sets
certain flags (such as those indicating whether the message is certain flags (such as those indicating whether the message is
authoritative and how returned Locators should be treated) when authoritative and how returned Locators SHOULD be treated) when
sending a Map-Reply on behalf of an ETR. When an ETR requests proxy sending a Map-Reply on behalf of an ETR. When an ETR requests proxy
reply service, it should include all RLOCs for all ETRs for the EID- reply service, it SHOULD include all RLOCs for all ETRs for the EID-
Prefix being registered, along with the routable flag ("R-bit") Prefix being registered, along with the routable flag ("R-bit")
setting for each RLOC. The Map-Server includes all of this setting for each RLOC. The Map-Server includes all of this
information in Map-Reply messages that it sends on behalf of the ETR. information in Map-Reply messages that it sends on behalf of the ETR.
This differs from a non-proxy registration, since the latter need This differs from a non-proxy registration, since the latter need
only provide one or more RLOCs for a Map-Server to use for forwarding only provide one or more RLOCs for a Map-Server to use for forwarding
Map-Requests; the registration information is not used in Map- Map-Requests; the registration information is not used in Map-
Replies, so it being incomplete is not incorrect. Replies, so it being incomplete is not incorrect.
An ETR that uses a Map-Server to publish its EID-to-RLOC mappings An ETR that uses a Map-Server to publish its EID-to-RLOC mappings
does not need to participate further in the mapping database does not need to participate further in the mapping database
skipping to change at page 31, line 5 skipping to change at page 31, line 5
this means that the ETR does not need to implement GRE or BGP, which this means that the ETR does not need to implement GRE or BGP, which
greatly simplifies its configuration and reduces its cost of greatly simplifies its configuration and reduces its cost of
operation. operation.
Note that use of a Map-Server does not preclude an ETR from also Note that use of a Map-Server does not preclude an ETR from also
connecting to the mapping database (i.e., it could also connect to connecting to the mapping database (i.e., it could also connect to
the LISP+ALT network), but doing so doesn't seem particularly useful, the LISP+ALT network), but doing so doesn't seem particularly useful,
as the whole purpose of using a Map-Server is to avoid the complexity as the whole purpose of using a Map-Server is to avoid the complexity
of the mapping database protocols. of the mapping database protocols.
5.3. Map-Server Processing 6.3. Map-Server Processing
Once a Map-Server has EID-Prefixes registered by its client ETRs, it Once a Map-Server has EID-Prefixes registered by its client ETRs, it
can accept and process Map-Requests for them. can accept and process Map-Requests for them.
In response to a Map-Request (received over the ALT if LISP+ALT is in In response to a Map-Request (received over the ALT if LISP+ALT is in
use), the Map-Server first checks to see if the destination EID use), the Map-Server first checks to see if the destination EID
matches a configured EID-Prefix. If there is no match, the Map- matches a configured EID-Prefix. If there is no match, the Map-
Server returns a Negative Map-Reply with action code "Natively- Server returns a Negative Map-Reply with action code "Natively-
Forward" and a 15-minute TTL. This may occur if a Map Request is Forward" and a 15-minute TTL. This MAY occur if a Map Request is
received for a configured aggregate EID-Prefix for which no more- received for a configured aggregate EID-Prefix for which no more-
specific EID-Prefix exists; it indicates the presence of a non-LISP specific EID-Prefix exists; it indicates the presence of a non-LISP
"hole" in the aggregate EID-Prefix. "hole" in the aggregate EID-Prefix.
Next, the Map-Server checks to see if any ETRs have registered the Next, the Map-Server checks to see if any ETRs have registered the
matching EID-Prefix. If none are found, then the Map-Server returns matching EID-Prefix. If none are found, then the Map-Server returns
a Negative Map-Reply with action code "Natively-Forward" and a a Negative Map-Reply with action code "Natively-Forward" and a
1-minute TTL. 1-minute TTL.
If any of the registered ETRs for the EID-Prefix have requested proxy If any of the registered ETRs for the EID-Prefix have requested proxy
reply service, then the Map-Server answers the request instead of reply service, then the Map-Server answers the request instead of
forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs,
and other information learned through the registration process. and other information learned through the registration process.
If none of the ETRs have requested proxy reply service, then the Map- If none of the ETRs have requested proxy reply service, then the Map-
Server re-encapsulates and forwards the resulting Encapsulated Map- Server re-encapsulates and forwards the resulting Encapsulated Map-
Request to one of the registered ETRs. It does not otherwise alter Request to one of the registered ETRs. It does not otherwise alter
the Map-Request, so any Map-Reply sent by the ETR is returned to the the Map-Request, so any Map-Reply sent by the ETR is returned to the
RLOC in the Map-Request, not to the Map-Server. Unless also acting RLOC in the Map-Request, not to the Map-Server. Unless also acting
as a Map-Resolver, a Map-Server should never receive Map-Replies; any as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any
such messages should be discarded without response, perhaps such messages SHOULD be discarded without response, perhaps
accompanied by the logging of a diagnostic message if the rate of accompanied by the logging of a diagnostic message if the rate of
Map-Replies is suggestive of malicious traffic. Map-Replies is suggestive of malicious traffic.
5.4. Map-Resolver Processing 6.4. Map-Resolver Processing
Upon receipt of an Encapsulated Map-Request, a Map-Resolver Upon receipt of an Encapsulated Map-Request, a Map-Resolver
decapsulates the enclosed message and then searches for the requested decapsulates the enclosed message and then searches for the requested
EID in its local database of mapping entries (statically configured EID in its local database of mapping entries (statically configured
or learned from associated ETRs if the Map-Resolver is also a Map- or learned from associated ETRs if the Map-Resolver is also a Map-
Server offering proxy reply service). If it finds a matching entry, Server offering proxy reply service). If it finds a matching entry,
it returns a LISP Map-Reply with the known mapping. it returns a LISP Map-Reply with the known mapping.
If the Map-Resolver does not have the mapping entry and if it can If the Map-Resolver does not have the mapping entry and if it can
determine that the EID is not in the mapping database (for example, determine that the EID is not in the mapping database (for example,
if LISP+ALT is used, the Map-Resolver will have an ALT forwarding if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
table that covers the full EID space), it immediately returns a table that covers the full EID space), it immediately returns a
negative LISP Map-Reply, with action code "Natively-Forward" and a negative LISP Map-Reply, with action code "Natively-Forward" and a
15-minute TTL. To minimize the number of negative cache entries 15-minute TTL. To minimize the number of negative cache entries
needed by an ITR, the Map-Resolver should return the least-specific needed by an ITR, the Map-Resolver SHOULD return the least-specific
prefix that both matches the original query and does not match any prefix that both matches the original query and does not match any
EID-Prefix known to exist in the LISP-capable infrastructure. EID-Prefix known to exist in the LISP-capable infrastructure.
If the Map-Resolver does not have sufficient information to know If the Map-Resolver does not have sufficient information to know
whether the EID exists, it needs to forward the Map-Request to whether the EID exists, it needs to forward the Map-Request to
another device that has more information about the EID being another device that has more information about the EID being
requested. To do this, it forwards the unencapsulated Map-Request, requested. To do this, it forwards the unencapsulated Map-Request,
with the original ITR RLOC as the source, to the mapping database with the original ITR RLOC as the source, to the mapping database
system. Using LISP+ALT, the Map-Resolver is connected to the ALT system. Using LISP+ALT, the Map-Resolver is connected to the ALT
network and sends the Map-Request to the next ALT hop learned from network and sends the Map-Request to the next ALT hop learned from
its ALT BGP neighbors. The Map-Resolver does not send any response its ALT BGP neighbors. The Map-Resolver does not send any response
to the ITR; since the source RLOC is that of the ITR, the ETR or Map- to the ITR; since the source RLOC is that of the ITR, the ETR or Map-
Server that receives the Map-Request over the ALT and responds will Server that receives the Map-Request over the ALT and responds will
do so directly to the ITR. do so directly to the ITR.
5.4.1. Anycast Map-Resolver Operation 6.4.1. Anycast Map-Resolver Operation
A Map-Resolver can be set up to use "anycast", where the same address A Map-Resolver can be set up to use "anycast", where the same address
is assigned to multiple Map-Resolvers and is propagated through IGP is assigned to multiple Map-Resolvers and is propagated through IGP
routing, to facilitate the use of a topologically close Map-Resolver routing, to facilitate the use of a topologically close Map-Resolver
by each ITR. by each ITR.
Note that Map-Server associations with ETRs should not use anycast Note that Map-Server associations with ETRs SHOULD NOT use anycast
addresses, as registrations need to be established between an ETR and addresses, as registrations need to be established between an ETR and
a specific set of Map-Servers, each identified by a specific a specific set of Map-Servers, each identified by a specific
registration association. registration association.
6. Security Considerations 7. Security Considerations
The 2-way LISP header nonce exchange documented in The 2-way LISP header nonce exchange documented in
[I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. [I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks.
To publish an authoritative EID-to-RLOC mapping with a Map-Server, an To publish an authoritative EID-to-RLOC mapping with a Map-Server, an
ETR includes authentication data that is a hash of the message using ETR includes authentication data that is a hash of the message using
a pair-wise shared key. An implementation must support use of HMAC- a pair-wise shared key. An implementation MUST support use of HMAC-
SHA-1-96 [RFC2104] and should support use of HMAC-SHA-256-128 SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128
[RFC6234] (SHA-256 truncated to 128 bits). [RFC6234] (SHA-256 truncated to 128 bits).
As noted in Section 5.2, a Map-Server should verify that all EID- As noted in Section 6.2, a Map-Server SHOULD verify that all EID-
Prefixes registered by an ETR match the configuration stored on the Prefixes registered by an ETR match the configuration stored on the
Map-Server. Map-Server.
The currently defined authentication mechanism for Map-Register The currently defined authentication mechanism for Map-Register
messages does not provide protection against "replay" attacks by a messages does not provide protection against "replay" attacks by a
"man-in-the-middle". Additional work is needed in this area. "man-in-the-middle". Additional work is needed in this area.
[I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin
authentication, integrity, anti-replay protection, and prevention of authentication, integrity, anti-replay protection, and prevention of
man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- man-in-the-middle and "overclaiming" attacks on the Map-Request/Map-
Reply exchange. Work is ongoing on this and other proposals for Reply exchange. Work is ongoing on this and other proposals for
resolving these open security issues. resolving these open security issues.
While beyond the scope of securing an individual Map-Server or Map- While beyond the scope of securing an individual Map-Server or Map-
Resolver, it should be noted that a BGP-based LISP+ALT network (if Resolver, it SHOULD be noted that a BGP-based LISP+ALT network (if
ALT is used as the mapping database infrastructure) can take ALT is used as the mapping database infrastructure) can take
advantage of standards work on adding security to BGP. advantage of standards work on adding security to BGP.
A complete LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in [RFC7835].
Please refer to it for more security related details. Please refer to it for more security related details.
7. IANA Considerations 8. 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
LISP control-plane specification, in accordance with BCP 26 LISP control-plane specification, in accordance with BCP 26
[RFC5226]. [RFC8126].
There are three namespaces (listed in the sub-sections below) in LISP There are three 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".
7.1. LISP Packet Type Codes 8.1. LISP Packet Type Codes
It is being requested that the IANA be authoritative for LISP Packet It is being requested that the IANA be authoritative for LISP Packet
Type definitions and that it refers to this document as well as Type definitions and that it refers to this document as well as
[RFC8113] as references. [RFC8113] as references.
Based on deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience of [RFC6830], the Map-Notify-Ack
message, message type 5, was added to this document. This document message, message type 5, was added to this document. This document
requests IANA to add it to the LISP Packet Type Registry. requests IANA to add it to the LISP Packet Type Registry.
7.2. LISP ACT and Flag Fields 8.2. LISP ACT and Flag Fields
New ACT values can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review or IESG approval.
Four values have already been allocated by [RFC6830]. This Four values have already been allocated by [RFC6830]. This
specification changes the name of ACT type 3 value from "Drop" to specification changes the name of ACT type 3 value from "Drop" to
"Drop/No-Reason" as well as adding two new ACT values, the "Drop/ "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).
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 [I-D.ietf-lisp-rfc6830bis]. New such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New
bits for flags in these fields can be implemented after IETF review bits for flags in these fields can be implemented after IETF review
or IESG approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by IANA.
7.3. LISP Address Type Codes 8.3. LISP Address Type Codes
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
defines LISP-specific encodings for AFI value 16387. LCAF encodings defines LISP-specific encodings for AFI value 16387. LCAF encodings
are used for specific use-cases where different address types for are used for specific use-cases where different address types for
EID-records and RLOC-records are required. EID-records and RLOC-records are required.
The IANA registry "LISP Canonical Address Format (LCAF) Types" is The IANA registry "LISP Canonical Address Format (LCAF) Types" is
used for LCAF types, the registry for LCAF types use the used for LCAF types, the registry for LCAF types use the
Specification Required policy [RFC5226]. Initial values for the Specification Required policy [RFC8126]. Initial values for the
registry as well as further information can be found in [RFC8060]. registry as well as further information can be found in [RFC8060].
Therefore, there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP Address Type
Codes" registry requested by [RFC6830]. This document requests to Codes" registry requested by [RFC6830]. This document requests to
remove it. remove it.
7.4. LISP Algorithm ID Numbers 8.4. LISP Algorithm ID Numbers
In [RFC6830], a request for a "LISP Key ID Numbers" registry was In [RFC6830], a request for a "LISP Key ID Numbers" registry was
submitted. This document renames the registry to "LISP Algorithm ID submitted. This document renames the registry to "LISP Algorithm ID
Numbers" and requests the IANA to make the name change. Numbers" and requests the IANA to make the name change.
The following Algorithm ID values are defined by this specification The following Algorithm ID values are defined by this specification
as used in any packet type that references a 'Algorithm ID' field: as used in any packet type that references a 'Algorithm ID' field:
Name Number Defined in Name Number Defined in
----------------------------------------------- -----------------------------------------------
None 0 n/a None 0 n/a
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 255. The allocation of values Number values are in the range of 0 to 255. The allocation of values
is on a first come first served basis. is on a first come first served basis.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Hashing for Message Authentication", RFC 2104, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, DOI 10.17487/RFC6831, January Environments", RFC 6831, DOI 10.17487/RFC6831, January
2013, <https://www.rfc-editor.org/info/rfc6831>. 2013, <https://www.rfc-editor.org/info/rfc6831>.
[RFC6836] Fuller, V., Farinacci, D., 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, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>. January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[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, Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013, DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>. <https://www.rfc-editor.org/info/rfc6837>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>. February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation [RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", RFC 8113, for Packet Type Allocations", RFC 8113,
DOI 10.17487/RFC8113, March 2017, DOI 10.17487/RFC8113, March 2017,
<https://www.rfc-editor.org/info/rfc8113>. <https://www.rfc-editor.org/info/rfc8113>.
8.2. Informative References [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
9.2. Informative References
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/assignments/address-family- NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, Febuary 2007.
[I-D.ermagan-lisp-nat-traversal] [I-D.ermagan-lisp-nat-traversal]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", draft-ermagan- F., and C. White, "NAT traversal for LISP", draft-ermagan-
lisp-nat-traversal-13 (work in progress), September 2017. lisp-nat-traversal-13 (work in progress), September 2017.
[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,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-00 Unified Control Plane", draft-ietf-lisp-eid-mobility-01
(work in progress), May 2017. (work in progress), November 2017.
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-lisp-mn] [I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-00 (work in progress), Mobile Node", draft-ietf-lisp-mn-01 (work in progress),
April 2017. October 2017.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-05 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-07 (work in progress),
August 2017. November 2017.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-13 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14
(work in progress), September 2017. (work in progress), October 2017.
[I-D.ietf-lisp-signal-free-multicast] [I-D.ietf-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-ietf-lisp-signal-free-multicast-06 (work in draft-ietf-lisp-signal-free-multicast-07 (work in
progress), August 2017. progress), November 2017.
[I-D.lewis-lisp-gpe] [I-D.lewis-lisp-gpe]
Lewis, D., Agarwal, P., Kreeger, L., Maino, F., Quinn, P., Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P.,
Smith, M., and N. Yadav, "LISP Generic Protocol Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol
Extension", draft-lewis-lisp-gpe-02 (work in progress), Extension", draft-lewis-lisp-gpe-04 (work in progress),
July 2014. December 2017.
[I-D.quinn-vxlan-gpe] [I-D.quinn-vxlan-gpe]
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F.,
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg,
P., and D. Melman, "Generic Protocol Extension for VXLAN", P., and D. Melman, "Generic Protocol Extension for VXLAN",
draft-quinn-vxlan-gpe-04 (work in progress), February draft-quinn-vxlan-gpe-04 (work in progress), February
2015. 2015.
[I-D.rodrigueznatal-lisp-pubsub] [I-D.rodrigueznatal-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., and D. Farinacci, Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
"Publish-Subscribe mechanism for LISP", draft- Boucadair, M., Jacquenet, C., and s.
rodrigueznatal-lisp-pubsub-00 (work in progress), August stefano.secci@lip6.fr, "Publish/Subscribe Functionality
2017. for LISP", draft-rodrigueznatal-lisp-pubsub-01 (work in
progress), October 2017.
[LISP-CONS] [LISP-CONS]
Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis, Brim, S., Chiappa, N., Farinacci, D., Fuller, V., Lewis,
D., and D. Meyer, "LISP-CONS: A Content distribution D., and D. Meyer, "LISP-CONS: A Content distribution
Overlay Network Service for LISP", Work in Progress, April Overlay Network Service for LISP", Work in Progress, April
2008. 2008.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016,
<https://www.rfc-editor.org/info/rfc7835>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to thank Greg Schudel, Darrel Lewis, John The authors would like to thank Greg Schudel, Darrel Lewis, John
Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver,
Fabio Maino, and members of the lisp@ietf.org mailing list for their Fabio Maino, and members of the lisp@ietf.org mailing list for their
feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work on Special thanks are due to Noel Chiappa for his extensive work on
caching with LISP-CONS, some of which may be used by Map-Resolvers. caching with LISP-CONS, some of which may be used by Map-Resolvers.
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-rfc6833bis-06 B.1. Changes to draft-ietf-lisp-rfc6833bis-07
o Posted December 2017.
o Make it more clear in a couple of places that RLOCs are used to
locate ETRs more so than for Map-Server Map-Request forwarding.
o Make it clear that "encapsualted" for a control message is an ECM
based message.
o Make it more clear what messages use source-port 4342 and which
ones use destinatino-port 4342.
o Don't make DDT references when the mapping transport system can be
of any type and the referneced text is general to it.
o Generalize text when referring to the format of an EID-prefix.
Can use othe AFIs then IPv4 and IPv6.
o Many editorial changes to clarify text.
o Changed some "must", "should", and "may" to capitalized.
o Added definitions for Map-Request and Map-Reply messages.
o Ran document through IDNITs.
B.2. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017. o Posted October 2017.
o Spec the I-bit to include the xTR-ID in a Map-Request message to o Spec the I-bit to include the xTR-ID in a Map-Request message to
be consistent with the Map-Register message and to anticipate the be consistent with the Map-Register message and to anticipate the
introduction of pubsub functionality to allow Map-Requests to introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes. subscribe to RLOC-set changes.
o Updated references for individual submissions that became working o Updated references for individual submissions that became working
group documents. group documents.
o Updated references for working group documents that became RFCs. o Updated references for working group documents that became RFCs.
B.2. Changes to draft-ietf-lisp-rfc6833bis-05 B.3. Changes to draft-ietf-lisp-rfc6833bis-05
o Posted May 2017. o Posted May 2017.
o Update IANA Considerations section based on new requests from this o Update IANA Considerations section based on new requests from this
document and changes from what was requested in [RFC6830]. document and changes from what was requested in [RFC6830].
B.3. Changes to draft-ietf-lisp-rfc6833bis-04 B.4. Changes to draft-ietf-lisp-rfc6833bis-04
o Posted May 2017. o Posted May 2017.
o Clarify how the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in Map-Register and Map-
Notify messages. Break the 16-bit field into a 8-bit Key-ID field Notify messages. Break the 16-bit field into a 8-bit Key-ID field
and a 8-bit Algorithm-ID field. and a 8-bit Algorithm-ID field.
o Move the control-plane codepoints from the IANA Considerations o Move the control-plane codepoints from the IANA Considerations
section of RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations section of this
document. document.
o In the "LISP Control Packet Type Allocations" section, indicate o In the "LISP Control Packet Type Allocations" section, indicate
how message Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how experimental RFC8113
sub-types should be requested. sub-types should be requested.
B.4. Changes to draft-ietf-lisp-rfc6833bis-03 B.5. Changes to draft-ietf-lisp-rfc6833bis-03
o Posted April 2017. o Posted April 2017.
o Add types 9-14 and specify they are not assigned. o Add types 9-14 and specify they are not assigned.
o Add the "LISP Shared Extension Message" type and point to RFC8113. o Add the "LISP Shared Extension Message" type and point to RFC8113.
B.5. Changes to draft-ietf-lisp-rfc6833bis-02 B.6. Changes to draft-ietf-lisp-rfc6833bis-02
o Posted April 2017. o Posted April 2017.
o Clarify that the LISP control-plane document defines how the LISP o Clarify that the LISP control-plane document defines how the LISP
data-plane uses Map-Requests with either the SMR-bit set or the data-plane uses Map-Requests with either the SMR-bit set or the
P-bit set supporting mapping updates and RLOC-probing. Indicating P-bit set supporting mapping updates and RLOC-probing. Indicating
that other data-planes can use the same mechanisms or their own that other data-planes can use the same mechanisms or their own
defined mechanisms to achieve the same functionality. defined mechanisms to achieve the same functionality.
B.6. Changes to draft-ietf-lisp-rfc6833bis-01 B.7. Changes to draft-ietf-lisp-rfc6833bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Remove references to self. o Remove references to self.
o Change references from RFC6830 to RFC6830bis. o Change references from RFC6830 to RFC6830bis.
o Add two new action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has posted to the LISP
WG mailing list. WG mailing list.
o In intro section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to I-D.ietf-lisp-introduction.
o Removed Open Issues section and references to "experimental". o Removed Open Issues section and references to "experimental".
B.7. Changes to draft-ietf-lisp-rfc6833bis-00 B.8. Changes to draft-ietf-lisp-rfc6833bis-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
-rfc6833-00 individual submission. No other changes made. -rfc6833-00 individual submission. No other changes made.
B.8. Changes to draft-farinacci-lisp-rfc6833bis-00 B.9. Changes to draft-farinacci-lisp-rfc6833bis-00
o Posted November 2016. o Posted November 2016.
o This is the initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into RFC 6833bis.
o The document name has changed from the "Locator/ID Separation o The document name has changed from the "Locator/ID Separation
Protocol (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the "Locator/ID
Separation Protocol (LISP) Control-Plane". Separation Protocol (LISP) Control-Plane".
o The fundamental change was to move the control-plane messages from o The fundamental change was to move the control-plane messages from
 End of changes. 106 change blocks. 
227 lines changed or deleted 285 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/