rfc9301.original   rfc9301.txt 
Network Working Group D. Farinacci Internet Engineering Task Force (IETF) D. Farinacci
Internet-Draft lispers.net Request for Comments: 9301 lispers.net
Obsoletes: 6830, 6833 (if approved) F. Maino Obsoletes: 6830, 6833 F. Maino
Intended status: Standards Track Cisco Systems Category: Standards Track Cisco Systems
Expires: May 22, 2021 V. Fuller ISSN: 2070-1721 V. Fuller
vaf.net Internet Consulting vaf.net Internet Consulting
A. Cabellos (Ed.) A. Cabellos, Ed.
UPC/BarcelonaTech Universitat Politecnica de Catalunya
November 18, 2020 October 2022
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control Plane
draft-ietf-lisp-rfc6833bis-30
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 types of Locator/ID Separation Protocol (LISP), implemented by two types of
LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server --
that provides a simplified "front end" for one or more Endpoint ID to that provide a simplified "front end" for one or more Endpoint IDs
Routing Locator mapping databases. (EIDs) 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
Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
Egress Tunnel Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the details of
mapping database systems, which facilitates modularity with different mapping database systems; this behavior facilitates modularity with
database designs. Since these devices implement the "edge" of the different database designs. Since these devices implement the "edge"
LISP Control-Plane infrastructure, connecting EID addressable nodes of the LISP control plane infrastructure, connecting EID addressable
of a LISP site, it the implementation and operational complexity of nodes of a LISP site, the implementation and operational complexity
the overall cost and effort of deploying LISP. of the overall cost and effort of deploying LISP is reduced.
This document obsoletes RFC 6830 and RFC 6833. This document obsoletes RFCs 6830 and 6833.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9301.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 5 1.1. Scope of Applicability
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions of Terms
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 7 4. Basic Overview
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 5. LISP IPv4 and IPv6 Control Plane Packet Formats
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11 5.1. LISP Control Packet Type Allocations
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12 5.2. Map-Request Message Format
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 5.3. EID-to-RLOC UDP Map-Request Message
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 16 5.4. Map-Reply Message Format
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20 5.5. EID-to-RLOC UDP Map-Reply Message
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 23 5.6. Map-Register Message Format
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 27 5.7. Map-Notify and Map-Notify-Ack Message Formats
5.8. Encapsulated Control Message Format . . . . . . . . . . . 29 5.8. Encapsulated Control Message Format
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31 6. Changing the Contents of EID-to-RLOC Mappings
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 31 6.1. Solicit-Map-Request (SMR)
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 32 7. Routing Locator Reachability
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33 7.1. RLOC-Probing Algorithm
8. Interactions with Other LISP Components . . . . . . . . . . . 34 8. Interactions with Other LISP Components
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34 8.1. ITR EID-to-RLOC Mapping Resolution
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 35 8.2. EID-Prefix Configuration and ETR Registration
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 37 8.3. Map-Server Processing
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 8.4. Map-Resolver Processing
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 38 8.4.1. Anycast Operation
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40 10. Privacy Considerations
11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 41 11. Changes Related to RFCs 6830 and 6833
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 12. IANA Considerations
12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 42 12.1. LISP UDP Port Numbers
12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 42 12.2. LISP Packet Type Codes
12.3. LISP Map-Reply EID-Record Action Codes . . . . . . . . . 42 12.3. LISP Map-Reply EID-Record Action Codes
12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 43 12.4. LISP Address Type Codes
12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 43 12.5. LISP Algorithm ID Numbers
12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 44 12.6. LISP Bit Flags
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 13. References
13.1. Normative References . . . . . . . . . . . . . . . . . . 47 13.1. Normative References
13.2. Informative References . . . . . . . . . . . . . . . . . 48 13.2. Informative References
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 53 Acknowledgments
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 53 Authors' Addresses
B.1. Changes to draft-ietf-lisp-rfc6833bis-26 . . . . . . . . 53
B.2. Changes to draft-ietf-lisp-rfc6833bis-25 . . . . . . . . 53
B.3. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 54
B.4. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 54
B.5. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 54
B.6. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 54
B.7. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 54
B.8. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 55
B.9. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 55
B.10. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 55
B.11. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 55
B.12. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 55
B.13. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 55
B.14. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 56
B.15. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 56
B.16. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 56
B.17. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 56
B.18. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 56
B.19. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 56
B.20. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 57
B.21. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 57
B.22. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 58
B.23. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 58
B.24. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 58
B.25. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 58
B.26. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 58
B.27. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 59
B.28. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol [RFC9300] (see also [RFC9299])
also [I-D.ietf-lisp-introduction]) specifies an architecture and specifies an architecture and mechanism for dynamic tunneling by
mechanism for dynamic tunneling by logically separating the addresses logically separating the addresses currently used by IP in two
currently used by IP in two separate name spaces: Endpoint IDs separate namespaces: Endpoint IDs (EIDs), used within sites; and
(EIDs), used within sites; and Routing Locators (RLOCs), used on the Routing Locators (RLOCs), used on the transit networks that make up
transit networks that make up the Internet infrastructure. To the Internet infrastructure. To achieve this separation, LISP
achieve this separation, LISP defines protocol mechanisms for mapping defines protocol mechanisms for mapping from EIDs to RLOCs. In
from EIDs to RLOCs. In addition, LISP assumes the existence of a addition, LISP assumes the existence of a database to store and
database to store and propagate those mappings across mapping system propagate those mappings across Mapping System nodes. Several such
nodes. Several such databases have been proposed; among them are the databases have been proposed; among them are the Content distribution
Content distribution Overlay Network Service for LISP-NERD (a Not-so- Overlay Network Service for LISP-NERD (a Not-so-novel EID-to-RLOC
novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Database) [RFC6837], LISP Alternative Logical Topology (LISP-ALT)
Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree [RFC6836], and LISP Delegated Database Tree (LISP-DDT) [RFC8111].
(LISP-DDT) [RFC8111].
The LISP Mapping Service defines two types of LISP-speaking devices: The LISP Mapping Service defines two types of LISP-speaking devices:
the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel
Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping
database; and the Map-Server, which learns authoritative EID-to-RLOC database; and the Map-Server, which learns authoritative EID-to-RLOC
mappings from an Egress Tunnel Router (ETR) and publishes them in a mappings from an Egress Tunnel Router (ETR) and publishes them in a
database. database.
This LISP Control-Plane Mapping Service can be used by many different This LISP control plane and Mapping Service can be used by many
encapsulation-based or translation-based Data-Planes which include different encapsulation-based or translation-based data planes,
but are not limited to the ones defined in LISP RFC 6830bis including but not limited to those defined in LISP [RFC9300], the
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN LISP Generic Protocol Extension (LISP-GPE) [RFC9305], Virtual
[RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP eXtensible Local Area Networks (VXLANs) [RFC7348], VXLAN-GPE
[GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) [NVO3-VXLAN-GPE], GRE [RFC2890], the GPRS Tunneling Protocol (GTP)
[RFC8402]. [GTP-3GPP], Identifier-Locator Addressing (ILA) [INTAREA-ILA], and
Segment Routing (SRv6) [RFC8402].
Conceptually, LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same basic
configuration and maintenance properties as Domain Name System (DNS) configuration and maintenance properties as Domain Name System (DNS)
[RFC1035] servers; likewise, Map-Resolvers are conceptually similar servers [RFC1035]; likewise, Map-Resolvers are conceptually similar
to DNS caching resolvers. With this in mind, this specification to DNS caching resolvers. With this in mind, this specification
borrows familiar terminology (resolver and server) from the DNS borrows familiar terminology (resolver and server) from the DNS
specifications. specifications.
Note this document doesn't assume any particular database mapping Note that this document doesn't assume any particular database
infrastructure to illustrate certain aspects of Map-Server and Map- mapping infrastructure to illustrate certain aspects of Map-Server
Resolver operation. The Mapping Service interface can (and likely and Map-Resolver operations. The Mapping Service interface can (and
will) be used by ITRs and ETRs to access other mapping database likely will) be used by ITRs and ETRs to access other mapping
systems as the LISP infrastructure evolves. database systems as the LISP infrastructure evolves.
LISP is not intended to address problems of connectivity and scaling LISP is not intended to address problems of connectivity and scaling
on behalf of arbitrary communicating parties. Relevant situations on behalf of arbitrary communicating parties. Relevant situations
are described in the scoping section of the introduction to are described in Section 1.1 of [RFC9300].
[I-D.ietf-lisp-rfc6830bis].
This document obsoletes RFC 6830 and 6833. This document obsoletes [RFC6830] and [RFC6833].
1.1. Scope of Applicability 1.1. Scope of Applicability
LISP was originally developed to address the Internet-wide route LISP was originally developed to address the Internet-wide route
scaling problem [RFC4984]. While there are a number of approaches of scaling problem [RFC4984]. While there are a number of approaches of
interest for that problem, as LISP as been developed and refined, a interest for that problem, as LISP has been developed and refined, a
large number of other LISP uses have been found and are being used. large number of other uses for LISP have been found and are being
As such, the design and development of LISP has changed so as to implemented. As such, the design and development of LISP have
focus on these use cases. The common property of these uses is a changed so as to focus on these use cases. The common property of
large set of cooperating entities seeking to communicate over the these uses is a large set of cooperating entities seeking to
public Internet or other large underlay IP infrastructures, while communicate over the public Internet or other large underlay IP
keeping the addressing and topology of the cooperating entities infrastructures while keeping the addressing and topology of the
separate from the underlay and Internet topology, routing, and cooperating entities separate from the underlay and Internet
addressing. topology, routing, and addressing.
When communicating over the public Internet, deployers MUST consider When communicating over the public Internet, deployers MUST consider
the following guidelines: the following guidelines:
1. LISP-SEC MUST be implemented [I-D.ietf-lisp-sec]. This means 1. LISP Security (LISP-SEC) MUST be implemented [RFC9303]. This
that the S-bit MUST be set in the Map-Reply (Section 5.4), Map- means that the S-bit MUST be set in the Map-Reply (Section 5.4),
Register (Section 5.6) and Encapsulated Control messages Map-Register (Section 5.6), and Encapsulated Control Messages
(Section 5.8). (ECMs) (Section 5.8).
2. Implementations SHOULD use the 'HMAC-SHA256-128+HKDF-SHA256' as 2. Implementations SHOULD use 'HMAC-SHA256-128+HKDF-SHA256' as the
the Algorithm ID (Section 12.5) in Map-Register message
(Section 5.6), and MUST NOT use 'None' or 'HMAC-SHA-1-96-None' as
Algorithm ID (Section 12.5) in the Map-Register message Algorithm ID (Section 12.5) in the Map-Register message
(Section 5.6) (Section 5.6) and MUST NOT use 'None' or 'HMAC-SHA-1-96-None' as
the Algorithm ID (Section 12.5) in the Map-Register message
(Section 5.6).
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definition of Terms 3. Definitions 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 Map-Request: A control plane message that queries the Mapping System
the mapping system to resolve an EID. A LISP Map-Request can also to resolve an EID. A LISP Map-Request can also be sent to an RLOC
be sent to an RLOC to test for reachability and to exchange to test for reachability and to exchange security keys between an
security keys between an encapsulator and a decapsulator. This encapsulator and a decapsulator. This type of Map-Request is also
type of Map-Request is also known as an RLOC-Probe Request. known as an RLOC-Probe Request.
Map-Reply: A LISP Map-Reply is a Control-Plane message returned in Map-Reply: A control plane message returned in response to a Map-
response to a Map-Request sent to the mapping system when Request sent to the Mapping System when resolving an EID. A LISP
resolving an EID. A LISP Map-Reply can also be returned by a Map-Reply can also be returned by a decapsulator in response to a
decapsulator in response to a Map-Request sent by an encapsulator Map-Request sent by an encapsulator to test for reachability.
to test for reachability. This type of Map-Reply is known as a This type of Map-Reply is known as an RLOC-Probe Reply.
RLOC-Probe Reply.
Encapsulated Map-Request: A LISP Map-Request carried within an Encapsulated Map-Request: A LISP Map-Request carried within an ECM.
Encapsulated Control Message (ECM), which has an additional LISP This Map-Request has an additional LISP header prepended. Sent to
header prepended. Sent to UDP destination port 4342. The "outer" UDP destination port 4342. The "outer" addresses are routable IP
addresses are routable IP addresses, also known as RLOCs. Used by addresses, also known as RLOCs. Used by an ITR when sending to a
an ITR when sending to a Map-Resolver and by a Map-Server when Map-Resolver and by a Map-Server when forwarding a Map-Request to
forwarding a Map-Request to an ETR. an ETR.
Map-Resolver: A network infrastructure component that accepts LISP Map-Resolver: A network infrastructure component that accepts LISP
Encapsulated (ECM) Map-Requests, typically from an ITR, and Encapsulated (ECM) Map-Requests, typically from an ITR, and
determines whether or not the destination IP address is part of determines whether or not the destination IP address is part of
the EID 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.
Negative Map-Reply: A LISP Map-Reply that contains an empty Negative Map-Reply: A LISP Map-Reply that contains an empty Locator-
Locator-Set. Returned in response to a Map-Request if the Set. Returned in response to a Map-Request if the destination EID
destination EID is not registered in the mapping system, is policy is not registered in the Mapping System, is policy-denied, or
denied or fails authentication. fails authentication.
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 reach ETR(s). The Map-Server uses these RLOCs when RLOCs to reach ETR(s). The Map-Server uses these RLOCs when
forwarding Map-Requests (re-formatted as Encapsulated Map- forwarding Map-Requests (reformatted as Encapsulated Map-
Requests). An ETR MAY request that the Map-Server answer Map- Requests). An ETR MAY request that the Map-Server answer Map-
Requests on its behalf by setting the "proxy Map-Reply" flag Requests on its behalf by setting the "proxy Map-Reply" 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
to confirm that a Map-Register has been received and processed. confirm that a Map-Register has been received and processed. An
An ETR requests that a Map-Notify be returned by setting the ETR requests that a Map-Notify be returned by setting the "want-
"want-map-notify" flag (M-bit) in the Map-Register message. map-notify" flag (M-bit) in the Map-Register message. Unlike a
Unlike a Map-Reply, a Map-Notify uses UDP port 4342 for both Map-Reply, a Map-Notify uses UDP port 4342 for both source and
source and destination. Map-Notify messages are also sent to ITRs destination. Map-Notify messages are also sent to ITRs by Map-
by Map-Servers when there are RLOC-set changes. Servers when there are RLOC-Set changes.
For definitions of other terms, notably Ingress Tunnel Router (ITR), For definitions of other terms, notably Ingress Tunnel Router (ITR),
Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR), Egress Tunnel Router (ETR), and Re-encapsulating Tunnel Router (RTR),
refer to the LISP Data-Plane specification refer to the LISP data plane specification [RFC9300].
[I-D.ietf-lisp-rfc6830bis].
4. 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 originating from an ITR), it consults the mapping Request (typically originating from an ITR), it consults the mapping
database to find an ETR that can answer with the set of RLOCs for an database to find an ETR that can answer with the set of RLOCs for an
EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends EID-Prefix. To publish its EID-Prefixes, an ETR periodically sends
Map-Register messages to the Map-Server. A Map-Register message Map-Register messages to the Map-Server. A Map-Register message
contains a list of EID-Prefixes plus a set of RLOCs that can be used contains a list of EID-Prefixes plus a set of RLOCs that can be used
to reach the ETRs. to reach the ETRs.
When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server When LISP-ALT [RFC6836] is used as the mapping database, a Map-Server
connects to the ALT network and acts as a "last-hop" ALT-Router. connects to the ALT network and acts as a "last-hop" ALT-Router.
Intermediate ALT-Routers forward Map-Requests to the Map-Server that Intermediate ALT-Routers forward Map-Requests to the Map-Server that
skipping to change at page 7, line 34 skipping to change at line 279
Tree. Tree.
A Map-Resolver receives Encapsulated Map-Requests from its client A Map-Resolver receives Encapsulated Map-Requests from its client
ITRs and uses a mapping database system to find the appropriate ETR ITRs and uses a mapping database system to find the appropriate ETR
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 Map-Resolver could cache Note that while it is conceivable that a Map-Resolver could cache
responses to improve performance, issues surrounding cache management responses to improve performance, issues surrounding cache management
would need to be resolved so that doing so will be reliable and would need to be resolved so that doing so would be reliable and
practical. In this specification, Map-Resolvers will operate only in practical. In this specification, Map-Resolvers will operate only in
a non-caching mode, decapsulating and forwarding Encapsulated Map a non-caching mode, decapsulating and forwarding Encapsulated Map-
Requests received from ITRs. Any specification of caching Requests received from ITRs. Any specification of caching
functionality is out of scope for this document. functionality is out of scope for this document.
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,
connecting Map-Resolvers and Map-Servers together to make up the connecting Map-Resolvers and Map-Servers together to make up the
Mapping System. Mapping System.
5. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum | | Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Routing Locator | | Source Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Routing Locator | | Destination Routing Locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port | / | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 UDP LISP Control Message Figure 1: IPv4 UDP LISP Control Message
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| Traffic Class | Flow Label | |Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header=17| Hop Limit | | Payload Length | Next Header=17| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
skipping to change at page 9, line 37 skipping to change at line 358
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port | Dest Port | / | Source Port | Dest Port |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| LISP Message | | LISP Message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 UDP LISP Control Message Figure 2: IPv6 UDP LISP Control Message
When a UDP Map-Request, Map-Register, or Map-Notify (when used as a When a UDP Map-Request, Map-Register, or Map-Notify (when used as a
notification message) are sent, the UDP source port is chosen by the notification message) is sent, the UDP source port is chosen by the
sender and the destination UDP port number is set to 4342. When a sender and the destination UDP port number is set to 4342. When a
UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- UDP Map-Reply, Map-Notify (when used as an acknowledgment to a Map-
Register), or Map-Notify-Ack are sent, the source UDP port number is Register), or Map-Notify-Ack is 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. LISP is expected to be deployed by the LISP Message payload. LISP is expected to be deployed by
cooperating entities communicating over underlays. Deployers are cooperating entities communicating over underlays. Deployers are
expected to set the MTU according to the specific deployment expected to set the MTU according to the specific deployment
guidelines to prevent fragmentation of either the inner packet or the guidelines to prevent fragmentation of either the inner packet or the
outer encapsulated packet. For deployments not aware of the underlay outer encapsulated packet. For deployments not aware of the underlay
restrictions on path MTU, the message size MUST be limited to 576 restrictions on the path MTU, the message size MUST be limited to 576
bytes for IPv4 or 1280 bytes for IPv6 -considering the entire IP bytes for IPv4 or 1280 bytes for IPv6 -- considering the entire IP
packet- as outlined in [RFC8085]. packet -- as outlined in [RFC8085].
The UDP checksum is computed and set to non-zero for all messages The UDP checksum is computed and set to non-zero for all messages
sent to or from port 4342. It MUST be checked on receipt, and if the sent to or from port 4342. It MUST be checked on receipt, and if the
checksum fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped [RFC1071].
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.
5.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, the summary below includes the LISP Shared Extension completeness, the summary below includes the LISP Shared Extension
Message assigned by [I-D.ietf-lisp-rfc8113bis]. Message type Message assigned by [RFC9304]. Message type definitions are:
definitions are:
Reserved: 0 b'0000' +===================================+======+==================+
LISP Map-Request: 1 b'0001' | Message | Code | Codepoint |
LISP Map-Reply: 2 b'0010' +===================================+======+==================+
LISP Map-Register: 3 b'0011' | Reserved | 0 | b'0000' |
LISP Map-Notify: 4 b'0100' +-----------------------------------+------+------------------+
LISP Map-Notify-Ack: 5 b'0101' | LISP Map-Request | 1 | b'0001' |
LISP Map-Referral: 6 b'0110' +-----------------------------------+------+------------------+
Unassigned 7 b'0111' | LISP Map-Reply | 2 | b'0010' |
LISP Encapsulated Control Message: 8 b'1000' +-----------------------------------+------+------------------+
Unassigned 9-14 b'1001'- b'1110' | LISP Map-Register | 3 | b'0011' |
LISP Shared Extension Message: 15 b'1111' +-----------------------------------+------+------------------+
| LISP Map-Notify | 4 | b'0100' |
+-----------------------------------+------+------------------+
| LISP Map-Notify-Ack | 5 | b'0101' |
+-----------------------------------+------+------------------+
| LISP DDT Map-Referral | 6 | b'0110' |
+-----------------------------------+------+------------------+
| Unassigned | 7 | b'0111' |
+-----------------------------------+------+------------------+
| LISP Encapsulated Control Message | 8 | b'1000' |
+-----------------------------------+------+------------------+
| Unassigned | 9-14 | b'1001'- b'1110' |
+-----------------------------------+------+------------------+
| LISP Shared Extension Message | 15 | b'1111' |
+-----------------------------------+------+------------------+
Table 1
Protocol designers experimenting with new message formats are Protocol designers experimenting with new message formats are
recommended to use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message Type described
in [I-D.ietf-lisp-rfc8113bis]. in [RFC9304].
All LISP Control-Plane messages use Address Family Identifiers (AFI) All LISP control plane messages use Address Family Identifiers (AFIs)
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to [AFN] or LISP Canonical Address Format (LCAF) entries [RFC8060] to
encode either fixed or variable length addresses. This includes encode either fixed-length or variable-length addresses. This
explicit fields in each control message or part of EID-records or includes explicit fields in each control message or part of EID-
RLOC-records in commonly formatted messages. LISP control-plane Records or RLOC-Records in commonly formatted messages. LISP control
messages that include an unrecognized AFI MUST be dropped and the plane messages that include an unrecognized AFI MUST be dropped, and
event MUST be logged. the event MUST be logged.
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 Soliciting of Map-Requests as well as RLOC- messages to support the soliciting of Map-Requests as well as RLOC-
probing procedures. Probing procedures.
5.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|R|R| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 33 skipping to change at line 468
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-Prefix-AFI | / | Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... | \ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 1 (Map-Request) Type: 1 (Map-Request)
A: This is an authoritative bit, it is set to 1 when an ITR wants the A: This is an authoritative bit. It is set to 1 when an ITR wants
destination site to return the Map-Reply rather than the mapping the destination site to return the Map-Reply rather than the
database system returning a Map-Reply, and set to 0 otherwise. mapping database system returning a Map-Reply and is set to 0
otherwise.
M: This is the map-data-present bit. When set, it indicates that a M: This is the map-data-present bit. When set, it indicates that a
Map-Reply Record segment is included in the Map-Request. Map-Reply Record segment is included in the Map-Request.
P: This is the probe-bit, which indicates that a Map-Request MUST be P: This is the probe-bit, which indicates that a Map-Request MUST be
treated as a Locator reachability probe. The receiver MUST treated as a Locator reachability probe. The receiver MUST
respond with a Map-Reply with the probe-bit set, indicating that respond with a Map-Reply with the probe-bit set, indicating that
the Map-Reply is a Locator reachability probe reply, with the the Map-Reply is a Locator reachability probe reply, with the
nonce copied from the Map-Request. See RLOC-Probing Section 7.1 nonce copied from the Map-Request. See "RLOC-Probing Algorithm"
for more details. This RLOC-probe Map-Request MUST NOT be sent to (Section 7.1) for more details. This RLOC-Probe Map-Request MUST
the mapping system. If a Map-Resolver or Map-Server receives a NOT be sent to the Mapping System. If a Map-Resolver or Map-
Map-Request with the probe-bit set, it MUST drop the message. Server receives a Map-Request with the probe-bit set, it MUST drop
the message.
S: This is the Solicit-Map-Request (SMR) bit. See Solicit-Map- S: This is the Solicit-Map-Request (SMR) bit. See
Request (SMRs) Section 6.1 for details. "Solicit-Map-Request (SMR)" (Section 6.1) for details.
p: This is the PITR bit. This bit is set to 1 when a PITR sends a p: This is the Proxy Ingress Tunnel Router (PITR) bit. This bit is
Map-Request. The use of this bit is deployment-specific. set to 1 when a PITR sends a Map-Request. The use of this bit is
deployment specific.
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received SMR-based Map-
Request. Request.
R: This reserved and unassigned bit MUST be set to 0 on transmit and R: This reserved and unassigned bit MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
L: This is the local-xtr bit. It is used by an xTR in a LISP site to L: This is the local-xtr bit. It is used by an xTR in a LISP site
tell other xTRs in the same site that it is part of the RLOC-set to tell other xTRs in the same site that it is part of the RLOC-
for the LISP site. The L-bit is set to 1 when the RLOC is the Set for the LISP site. The L-bit is set to 1 when the RLOC is the
sender's IP address. sender's IP address.
D: This is the dont-map-reply bit. It is used in the SMR procedure D: This is the dont-map-reply bit. It is used in the SMR procedure
described in Section 6.1. When an xTR sends an SMR message, it described in Section 6.1. When an xTR sends an SMR message, it
doesn't need a Map-Reply returned. When this bit is set, the doesn't need a Map-Reply returned. When this bit is set, the
receiver of the Map-Request does not return a Map-Reply. receiver of the Map-Request does not return a Map-Reply.
IRC: This 5-bit field is the ITR-RLOC Count, which encodes the IRC: This 5-bit field is the ITR-RLOC Count, which encodes the
additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields additional number of ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC
Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields Address) pair MUST be encoded. Multiple 'ITR-RLOC Address' fields
are used, so a Map-Replier can select which destination address to are used, so a Map-Replier can select which destination address to
use for a Map-Reply. The IRC value ranges from 0 to 31. For a use for a Map-Reply. The IRC value ranges from 0 to 31. For a
value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, value of 0, there is 1 ITR-RLOC address encoded; for a value of 1,
there are 2 ITR-RLOC addresses encoded, and so on up to 31, which there are 2 ITR-RLOC addresses encoded, and so on up to 31, which
encodes a total of 32 ITR-RLOC addresses. encodes a total of 32 ITR-RLOC addresses.
Record Count: This is the number of records in this Map-Request Record Count: This is the number of records in this Map-Request
message. A record is comprised of the portion of the packet that message. A record is comprised of the portion of the packet that
is labeled 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of times equal to
Record Count. For this version of the protocol, a receiver MUST Record Count. For this version of the protocol, a receiver MUST
accept and process Map-Requests that contain one or more records, accept and process Map-Requests that contain one or more records,
but a sender MUST only send Map-Requests containing one record. but a sender MUST only send Map-Requests containing one record.
Nonce: This is an 8-octet random value created by the sender of the Nonce: This is an 8-octet random value created by the sender of the
Map-Request. This nonce will be returned in the Map-Reply. The Map-Request. This nonce will be returned in the Map-Reply. The
nonce is used as an index to identify the corresponding Map- nonce is used as an index to identify the corresponding Map-
Request when a Map-Reply message is received. The nonce MUST be Request when a Map-Reply message is received. The nonce MUST be
generated by a properly seeded pseudo-random source, see as an generated by a properly seeded pseudo-random source; for example,
example [RFC4086]. see [RFC4086].
Source-EID-AFI: This is the address family of the 'Source EID Source-EID-AFI: This is the address family of the 'Source EID
Address' field. Address' field.
Source EID Address: This is the EID of the source host that Source EID Address: This is the EID of the source host that
originated the packet that caused the Map-Request. When Map- originated the packet that caused the Map-Request. When Map-
Requests are used for refreshing a Map-Cache entry or for RLOC- Requests are used for refreshing a Map-Cache entry or for RLOC-
Probing, an AFI value 0 is used and this field is of zero length. Probing, an AFI value of 0 is used, and this field is of zero
length.
ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address' ITR-RLOC-AFI: This is the address family of the 'ITR-RLOC Address'
field that follows this field. field that follows this field.
ITR-RLOC Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the option of
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 [AFN] and [RFC8060].
EID-Prefix: This prefix address length is 4 octets for an IPv4 EID-Prefix: This prefix address length is 4 octets for an IPv4
address family and 16 octets for an IPv6 address family when the address family and 16 octets for an IPv6 address family when the
EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFN], the
address length varies and for the LCAF AFI the format is defined address length varies, and for the LCAF AFI, the format is defined
in [RFC8060]. When a Map-Request is sent by an ITR because a data in [RFC8060]. When a Map-Request is sent by an ITR because a data
packet is received for a destination where there is no mapping packet is received for a destination where there is no mapping
entry, the EID-Prefix is set to the destination IP address of the entry, the EID-Prefix is set to the destination IP address of the
data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 data packet, and the 'EID mask-len' field is set to 32 or 128 for
or IPv6, respectively. When an xTR wants to query a site about IPv4 or IPv6, respectively. When an xTR wants to query a site
the status of a mapping it already has cached, the EID-Prefix used about the status of a mapping it already has cached, the EID-
in the Map-Request has the same mask-length as the EID-Prefix Prefix used in the Map-Request has the same mask length as the
returned from the site when it sent a Map-Reply message. 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. It is important to note cache the data if it chooses to do so. It is important to note
that this mapping has not been validated by the Mapping System. that this mapping has not been validated by the Mapping System.
5.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 Time to Live (TTL) expiration. For the initial case, the
address used for the Map-Request is the data packet's destination destination IP address used for the Map-Request is the data packet's
address (i.e., the destination EID) that had a mapping cache lookup destination address (i.e., the destination EID) that had a mapping
failure. For the latter two cases, the destination IP address used cache lookup failure. For the latter two cases, the destination IP
for the Map-Request is one of the RLOC addresses from the Locator-Set address used for the Map-Request is one of the RLOC addresses from
of the Map-Cache entry. The source address is either an IPv4 or IPv6 the Locator-Set of the Map-Cache entry. The source address is either
RLOC address, depending on whether the Map-Request is using an IPv4 an IPv4 or IPv6 RLOC address, depending on whether the Map-Request is
or IPv6 header, respectively. In all cases, the UDP source port using an IPv4 or IPv6 header, respectively. In all cases, the UDP
number for the Map-Request message is a 16-bit value selected by the source port number for the Map-Request message is a 16-bit value
ITR/PITR, and the UDP destination port number is set to the well- selected by the ITR/PITR, and the UDP destination port number is set
known destination port number 4342. A successful Map-Reply, which is to the well-known destination port number 4342. A successful Map-
one that has a nonce that matches an outstanding Map-Request nonce, Reply, which is one that has a nonce that matches an outstanding Map-
will update the cached set of RLOCs associated with the EID-Prefix Request nonce, will update the cached set of RLOCs associated with
range. the EID-Prefix range.
One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') fields One or more Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC Address') fields
MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST be filled in by the ITR. The number of fields (minus 1) encoded
MUST be placed in the 'IRC' field. The ITR MAY include all locally MUST be placed in the 'IRC' field. The ITR MAY include all locally
configured Locators in this list or just provide one locator address configured Locators in this list or just provide one Routing Locator
from each address family it supports. If the ITR erroneously Address 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 5.8. found in Section 5.8.
Map-Requests MUST be rate-limited to 1 per second per EID-prefix. Map-Requests MUST be rate limited to 1 per second per EID-Prefix.
After 10 retransmits without receiving the corresponding Map-Reply After 10 retransmits without receiving the corresponding Map-Reply,
the sender MUST wait 30 seconds. the sender MUST wait 30 seconds.
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 MUST originate a not have this mapping in the Map-Cache, it MUST originate a
"verifying Map-Request" through the mapping database to validate thge "verifying Map-Request" through the mapping database to validate the
"piggybacked" mapping data. "piggybacked" mapping data.
5.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 . . . |
skipping to change at page 16, line 33 skipping to change at line 656
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: This is the probe-bit, which indicates that the Map-Reply is in P: This is the probe-bit, which indicates that the Map-Reply is in
response to a Locator reachability probe Map-Request. The 'Nonce' response to a Locator reachability probe Map-Request. The 'Nonce'
field must contain a copy of the nonce value from the original field must contain a copy of the nonce value from the original
Map-Request. See RLOC-probing Section 7.1 for more details. When Map-Request. See "RLOC-Probing Algorithm" (Section 7.1) for more
the probe-bit is set to 1 in a Map-Reply message, the A-bit in details. When the probe-bit is set to 1 in a Map-Reply message,
each EID-record included in the message MUST be set to 1, the A-bit in each EID-Record included in the message MUST be set
otherwise MUST be silently discarded. to 1; otherwise, it MUST be silently discarded.
E: This bit indicates that the ETR that sends this Map-Reply message E: This bit indicates that the ETR that sends this Map-Reply message
is advertising that the site is enabled for the Echo-Nonce Locator is advertising that the site is enabled for the Echo-Nonce Locator
reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] reachability algorithm. See Section 10.1 ("Echo-Nonce Algorithm")
for more details. of [RFC9300] for more details.
S: This is the Security bit. When set to 1, the following S: This is the Security bit. When set to 1, the following
authentication information will be appended to the end of the Map- authentication information will be appended to the end of the Map-
Reply. The details can be found in [I-D.ietf-lisp-sec]. Reply. Details can be found in [RFC9303].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This unassigned field MUST be set to 0 on transmit and Reserved: This unassigned field MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
Record Count: This is the number of records in this reply message. Record Count: This is the number of records in this reply message.
A record is comprised of that portion of the packet labeled A record is comprised of that portion of the packet labeled
'Record' above and occurs the number of times equal to Record 'Record' above and occurs the number of times equal to Record
Count. Note that the reply count can be larger than the requested Count. Note that the reply count can be larger than the requested
count, for instance when more-specifics are present. count, for instance, when more-specific prefixes are present.
Nonce: This 64-bit value from the Map-Request is echoed in this Nonce: This 64-bit value from the Map-Request is echoed in this
'Nonce' field of the Map-Reply. 'Nonce' field of the Map-Reply.
Record TTL: This is the time in minutes the recipient of the Map- Record TTL: This is the time in minutes the recipient of the Map-
Reply can store the mapping. If the TTL is 0, the entry MUST be Reply can store the mapping. If the TTL is 0, the entry MUST be
removed from the cache immediately. If the value is 0xffffffff, removed from the cache immediately. If the value is 0xffffffff,
the recipient can decide locally how long to store the mapping. the recipient can decide locally how long to store the mapping.
Locator Count: This is the number of Locator entries in the given Locator Count: This is the number of Locator entries in the given
Record. A Locator entry comprises what is labeled above as 'Loc'. Record. A Locator entry comprises what is labeled above as 'Loc'.
The Locator count can be 0, indicating that there are no Locators The Locator count can be 0, indicating that there are no Locators
for the EID-Prefix. for the EID-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. They are used to tell an ITR or PITR why a empty messages. They are used to tell an ITR or PITR why an empty
locator-set was returned from the mapping system and how it stores Locator-Set was returned from the Mapping System and how it stores
the map-cache entry. See Section 12.3 for additional information. the Map-Cache entry. See Section 12.3 for additional information.
(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 Map-Cache entry is created and flagged (2) Send-Map-Request: The Map-Cache entry is created and flagged
that any packet matching this entry invokes sending a Map- so that any packet matching this entry invokes sending a Map-
Request. Request.
(3) Drop/No-Reason: A packet that matches this Map-Cache entry is (3) Drop/No-Reason: A packet that matches this Map-Cache entry is
dropped. An ICMP Destination Unreachable message SHOULD be dropped. An ICMP Destination Unreachable message SHOULD be
sent. sent.
(4) Drop/Policy-Denied: A packet that matches this Map-Cache (4) Drop/Policy-Denied: A packet that matches this Map-Cache
entry is dropped. The reason for the Drop action is that a entry is dropped. The reason for the Drop action is that a
Map-Request for the target-EID is being policy denied by Map-Request for the target EID is being policy-denied by
either an xTR or the mapping system. either an xTR or the Mapping System.
(5) Drop/Authentication-Failure: A packet that matches this Map- (5) Drop/Auth-Failure: A packet that matches this Map-Cache entry
Cache entry is dropped. The reason for the Drop action is is dropped. The reason for the Drop action is that a Map-
that a Map-Request for the target-EID fails an authentication Request for the target EID fails an authentication
verification-check by either an xTR or the mapping system. verification check by either an xTR or the Mapping System.
A: The Authoritative bit MAY only be set to 1 by an ETR. A Map- A: The Authoritative bit MAY only be set to 1 by an ETR. A Map-
Server generating Map-Reply messages as a proxy MUST NOT set the Server generating Map-Reply messages as a proxy MUST NOT set the
A-bit to 1. This bit indicates to the requesting ITRs if the Map- A-bit to 1. This bit indicates to the requesting ITRs if the Map-
Reply was originated by a LISP node managed at the site that owns Reply was originated by a LISP node managed at the site that owns
the EID-Prefix. the EID-Prefix.
Map-Version Number: When this 12-bit value is non-zero, the Map- Map-Version Number: When this 12-bit value in an EID-Record of a
Reply sender is informing the ITR what the version number is for Map-Reply message is non-zero, see [RFC9302] for details.
the EID record contained in the Map-Reply. The ETR can allocate
this number internally but MUST coordinate this value with other
ETRs for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Map-Versioning
[I-D.ietf-lisp-6834bis] for more details.
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] EID-Prefix-AFI: This is the address family of the EID-Prefix
and [RFC8060]. according to [AFN] 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. 16 octets for an IPv6 address family.
Priority: Each RLOC is assigned a unicast Priority. Lower values Priority: Each RLOC is assigned a unicast Priority. Lower values
are more preferable. When multiple RLOCs have the same Priority, are preferable. When multiple RLOCs have the same Priority, they
they may be used in a load-split fashion. A value of 255 means may be used in a load-split fashion. A value of 255 means the
the RLOC MUST NOT be used for unicast forwarding. RLOC MUST NOT be used for unicast forwarding.
Weight: When priorities are the same for multiple RLOCs, the Weight Weight: When priorities are the same for multiple RLOCs, the Weight
indicates how to balance unicast traffic between them. Weight is indicates how to balance unicast traffic between them. Weight is
encoded as a relative weight of total unicast packets that match encoded as a relative weight of total unicast packets that match
the mapping entry. For example, if there are 4 Locators in a the mapping entry. For example, if there are 4 Locators in a
Locator-Set, where the Weights assigned are 30, 20, 20, and 10, Locator-Set, where the Weights assigned are 30, 20, 20, and 10,
the first Locator will get 37.5% of the traffic, the 2nd and 3rd the first Locator will get 37.5% of the traffic, the second and
Locators will each get 25% of the traffic, and the 4th Locator third Locators will each get 25% of the traffic, and the fourth
will get 12.5% of the traffic. If all Weights for a Locator-Set Locator will get 12.5% of the traffic. If all Weights for a
are equal, the receiver of the Map-Reply will decide how to load- Locator-Set are equal, the receiver of the Map-Reply will decide
split the traffic. See RLOC-hashing [I-D.ietf-lisp-rfc6830bis] how to load-split the traffic. See Section 12 ("Routing Locator
for a suggested hash algorithm to distribute the load across Hashing") of [RFC9300] for a suggested hash algorithm to
Locators with the same Priority and equal Weight values. distribute the load across Locators with the same Priority and
equal Weight values.
M Priority: Each RLOC is assigned a multicast Priority used by an M Priority: Each RLOC is assigned a multicast Priority used by an
ETR in a receiver multicast site to select an ITR in a source ETR in a receiver multicast site to select an ITR in a source
multicast site for building multicast distribution trees. A value multicast site for building multicast distribution trees. A value
of 255 means the RLOC MUST NOT be used for joining a multicast of 255 means the RLOC MUST NOT be used for joining a multicast
distribution tree. For more details, see [RFC6831]. distribution tree. For more details, see [RFC6831].
M Weight: When priorities are the same for multiple RLOCs, the M Weight: When priorities are the same for multiple RLOCs, the
Weight indicates how to balance building multicast distribution Weight indicates how to balance building multicast distribution
trees across multiple ITRs. The Weight is encoded as a relative trees across multiple ITRs. The Weight is encoded as a relative
weight (similar to the unicast Weights) of the total number of weight (similar to the unicast Weights) of the total number of
trees built to the source site identified by the EID-Prefix. If trees built to the source site identified by the EID-Prefix. If
all Weights for a Locator-Set are equal, the receiver of the Map- all Weights for a Locator-Set are equal, the receiver of the Map-
Reply will decide how to distribute multicast state across ITRs. Reply will decide how to distribute multicast state across ITRs.
For more details, see [RFC6831]. For more details, see [RFC6831].
Unused Flags: These are set to 0 when sending and ignored on Unused Flags: These are set to 0 when sending and ignored on
receipt. receipt.
L: When this bit is set, the Locator is flagged as a local Locator to L: When this bit is set, the Locator is flagged as a local Locator
the ETR that is sending the Map-Reply. When a Map-Server is doing to the ETR that is sending the Map-Reply. When a Map-Server is
proxy Map-Replying for a LISP site, the L-bit is set to 0 for all doing proxy Map-Replying for a LISP site, the L-bit is set to 0
Locators in this Locator-Set. for all Locators in this Locator-Set.
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the p: When this bit is set, an ETR informs the RLOC-Probing ITR that
locator address for which this bit is set is the one being RLOC- the Routing Locator Address for which this bit is set is the one
probed and may be different from the source address of the Map- being RLOC-Probed and may be different from the source address of
Reply. An ITR that RLOC-probes a particular Locator MUST use this the Map-Reply. An ITR that RLOC-Probes a particular Locator MUST
Locator for retrieving the data structure used to store the fact use this Locator for retrieving the data structure used to store
that the Locator is reachable. The p-bit is set for a single the fact that the Locator is reachable. The p-bit is set for a
Locator in the same Locator-Set. If an implementation sets more single Locator in the same Locator-Set. If an implementation sets
than one p-bit erroneously, the receiver of the Map-Reply MUST more than one p-bit erroneously, the receiver of the Map-Reply
select the first set p-bit Locator. The p-bit MUST NOT be set for MUST select the first set p-bit Locator. The p-bit MUST NOT be
Locator-Set records sent in Map-Request and Map-Register messages. set for Locator-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. from the receiver's point of view.
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 and used by an ITR as a destination AFI' field) assigned to an ETR and used by an ITR as a destination
RLOC address in the outer header of a LISP encapsulated packet. RLOC address in the outer header of a LISP encapsulated packet.
Note that the destination RLOC address of a LISP encapsulated Note that the destination RLOC address of a LISP encapsulated
packet MAY be an anycast address. A source RLOC of a LISP packet MAY be an anycast address. A source RLOC of a LISP
encapsulated packet can be an anycast address as well. The source encapsulated packet can be an anycast address as well. The source
or destination RLOC MUST NOT be the broadcast address or destination RLOC MUST NOT be the broadcast address
(255.255.255.255 or any subnet broadcast address known to the (255.255.255.255 or any subnet broadcast address known to the
router) and MUST NOT be a link-local multicast address. The router) and MUST NOT be a link-local multicast address. The
source RLOC MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The destination RLOC
SHOULD be a multicast address if it is being mapped from a SHOULD be a multicast address if it is being mapped from a
multicast destination EID. multicast destination EID.
Map-Reply MUST be rate-limited, it is RECOMMENDED that a Map-Reply Map-Replies MUST be rate limited. It is RECOMMENDED that a Map-Reply
for the same destination RLOC be sent no more than one packets per 3 for the same destination RLOC be sent to no more than one packet
seconds. every 3 seconds.
The Record format, as defined here, is used both in the Map-Reply and The Record format, as defined here, is used both in the Map-Reply and
Map-Register messages, this includes all the field definitions. Map-Register messages; this includes all the field definitions.
5.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 mask-length that is less A Map-Reply returns an EID-Prefix with a mask 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 of a record of a Map-Request. The RLOCs in the Map-Reply are the EID of a record of a Map-Request. The RLOCs in the Map-Reply are
routable IP addresses of all ETRs for the LISP site. Each RLOC routable IP addresses of all ETRs for the LISP site. Each RLOC
conveys status reachability but does not convey path reachability conveys status reachability but does not convey path reachability
from a requester's perspective. Separate testing of path from a requester's perspective. Separate testing of path
reachability is required. See RLOC-reachability Section 7.1 for reachability is required. See "RLOC-Probing Algorithm" (Section 7.1)
details. 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 + mask-length) than the Map-Request that triggers it. This (prefix + mask length) than the Map-Request that triggers it. This
might occur if a Map-Request were for a prefix that had been returned might 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 by an earlier Map-Reply. In such a case, the requester updates its
cache with the new prefix information and granularity. For example, cache with the new prefix information and granularity. For example,
a requester with two cached EID-Prefixes that are covered by a Map- a 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 EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], When an EID moves out of a LISP site [EID-MOBILITY], the database
the database mapping system may have overlapping EID-prefixes. Or Mapping System may have overlapping EID-Prefixes. Or when a LISP
when a LISP site is configured with multiple sets of ETRs that site is configured with multiple sets of ETRs that support different
support different EID-prefix mask-lengths, the database mapping EID-Prefix mask lengths, the database Mapping System may have
system may have overlapping EID-prefixes. When overlapping EID- overlapping EID-Prefixes. When overlapping EID-Prefixes exist, a
prefixes exist, a Map-Request with an EID that best matches any EID- Map-Request with an EID that best matches any EID-Prefix MUST be
Prefix MUST be returned in a single Map-Reply message. For instance, returned in a single Map-Reply message. For instance, if an ETR had
if an ETR had database mapping entries for EID-Prefixes: database mapping entries for EID-Prefixes:
2001:db8::/32 2001:db8::/32
2001:db8:1::/48 2001:db8:1::/48
2001:db8:1:1::/64 2001:db8:1:1::/64
2001:db8:1:2::/64 2001:db8:1:2::/64
A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a
record count of 1 to be returned with a mapping record EID-Prefix of record count of 1 to be returned with a mapping record EID-Prefix of
2001:db8:1:1::/64. 2001:db8:1:1::/64.
A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a
record count of 3 to be returned with mapping records for EID- record count of 3 to be returned with mapping records for EID-
Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, 2001:db8:1:2::/64, Prefixes 2001:db8:1::/48, 2001:db8:1:1::/64, and 2001:db8:1:2::/64,
filling out the /48 with more-specifics that exist in the mapping filling out the /48 with more-specific prefixes that exist in the
system. Mapping System.
Note that not all overlapping EID-Prefixes need to be returned but Note that not all overlapping EID-Prefixes need to be returned but
only the more-specific entries (note that in the second example above only the more-specific entries (note in the second example above that
2001:db8::/32 was not returned for requesting EID 2001:db8:1:5::5) 2001:db8::/32 was not returned for requesting EID 2001:db8:1:5::5)
for the matching EID-Prefix of the requesting EID. When more than for the matching EID-Prefix of the requesting EID. When more than
one EID-Prefix is returned, all SHOULD use the same Time to Live one EID-Prefix is returned, all SHOULD use the same TTL value so they
value so they can all time out at the same time. When a more- can all time out at the same time. When a more-specific EID-Prefix
specific EID-Prefix is received later, its Time to Live value in the is received later, its TTL value in the Map-Reply record can be
Map-Reply record can be stored even when other less-specific entries stored even when other less-specific entries exist. When a less-
exist. When a less-specific EID-Prefix is received later, its Map- specific EID-Prefix is received later, its Map-Cache expiration time
Cache expiration time SHOULD be set to the minimum expiration time of SHOULD be set to the minimum expiration time of any more-specific
any more-specific EID-Prefix in the Map-Cache. This is done so the EID-Prefix in the Map-Cache. This is done so the integrity of the
integrity of the EID-Prefix set is wholly maintained and so no more- EID-Prefix set is wholly maintained and so no more-specific entries
specific entries are removed from the Map-Cache while keeping less- are removed from the Map-Cache while keeping less-specific entries.
specific entries.
For scalability, it is expected that aggregation of EID addresses For scalability, it is expected that aggregation of EID addresses
into EID-Prefixes will allow one Map-Reply to satisfy a mapping for into EID-Prefixes will allow one Map-Reply to satisfy a mapping for
the EID addresses in the prefix range, thereby reducing the number of the EID addresses in the prefix range, thereby reducing the number of
Map-Request messages. Map-Request messages.
Map-Reply records can have an empty Locator-Set. A Negative Map- Map-Reply records can have an empty Locator-Set. A Negative Map-
Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies
convey special actions by the sender to the ITR or PITR that have convey special actions by the Map-Reply sender to the ITR or PITR
solicited the Map-Reply. There are two primary applications for that have solicited the Map-Reply. There are two primary
Negative Map-Replies. The first is for a Map-Resolver to instruct an applications for Negative Map-Replies. The first is for a Map-
ITR or PITR when a destination is for a LISP site versus a non-LISP Resolver to instruct an ITR or PITR when a destination is for a LISP
site, and the other is to source quench Map-Requests that are sent site versus a non-LISP site, and the other is to source quench Map-
for non-allocated EIDs. Requests that are sent for non-allocated EIDs.
For each Map-Reply record, the list of Locators in a Locator-Set MUST For each Map-Reply record, the list of Locators in a Locator-Set MUST
be sorted in order of ascending IP address where an IPv4 locator be sorted in order of ascending IP address where an IPv4 Routing
address is considered numerically 'less than' an IPv6 locator Locator Address is considered numerically "less than" an IPv6 Routing
address. Locator Address.
When sending a Map-Reply message, the destination address is copied When sending a Map-Reply message, the destination address is copied
from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can from one of the 'ITR-RLOC' fields from the Map-Request. The ETR can
choose a locator address from one of the address families it choose a Routing 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 chosen local IP addresses; this allows 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.
5.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 fields below are used in multiple control messages. They are The fields below are used in multiple control messages. They are
defined for Map-Register, Map-Notify and Map-Notify-Ack message defined for Map-Register, Map-Notify, and Map-Notify-Ack message
types. types.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
skipping to change at page 23, line 47 skipping to change at line 967
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy Map-Reply bit. When set to 1, the ETR sending P: This is the proxy Map-Reply bit. When set to 1, the ETR sending
the Map-Register message is requesting the Map-Server to proxy a the Map-Register message is requesting the Map-Server to proxy a
Map-Reply. The Map-Server will send non-authoritative Map-Replies Map-Reply. The Map-Server will send non-authoritative Map-Replies
on behalf of the ETR. on behalf of the ETR.
S: This is the security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the procedures from
[I-D.ietf-lisp-sec] are supported. [RFC9303] are supported.
I: This is the ID-present bit. This bit is set to 1 to indicate that I: This is the ID-present bit. This bit is set to 1 to indicate
a 128 bit xTR-ID and a 64 bit Site-ID fields are present at the that a 128-bit 'xTR-ID' field and a 64-bit 'Site-ID' field are
end of the Map-Register message. If an xTR is configured with an present at the end of the Map-Register message. If an xTR is
xTR-ID and Site-ID, it MUST set the I bit to 1 and include its configured with an xTR-ID and Site-ID, it MUST set the I-bit to 1
xTR-ID and Site-ID in the Map-Register messages it generates. The and include its xTR-ID and Site-ID in the Map-Register messages it
combination of Site-ID plus xTR-ID uniquely identifies an xTR in a generates. The combination of Site-ID plus xTR-ID uniquely
LISP domain and serves to track its last seen nonce. identifies an xTR in a LISP domain and serves to track its last
seen nonce.
Reserved: This unassigned field MUST be set to 0 on transmit and Reserved: This unassigned field MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
E: This is the Map-Register EID-notify bit. This is used by a First- E: This is the Map-Register EID-notify bit. This is used by a
Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify First-Hop Router that discovers a dynamic EID. This EID-notify-
based Map-Register is sent by the FHR to a same site xTR that based Map-Register is sent by the First-Hop Router to a same site
propogates the Map-Register to the mapping system. The site xTR xTR that propagates the Map-Register to the Mapping System. The
keeps state to later Map-Notify the FHR after the EID has moves site xTR keeps state to later Map-Notify the First-Hop Router
away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. after the EID has moved away. See [EID-MOBILITY] for a detailed
use case.
T: This is the use-TTL for timeout bit. When set to 1, the xTR wants T: This is the use TTL for timeout bit. When set to 1, the xTR
the Map-Server to time out registrations based on the value in the wants the Map-Server to time out registrations based on the value
"Record TTL" field of this message. Otherwise, the default in the 'Record TTL' field of this message. Otherwise, the default
timeout described in Section 8.2 is used. timeout described in Section 8.2 is used.
a: This is the merge-request bit. When set to 1, the xTR requests to a: This is the merge-request bit. When set to 1, the xTR requests
merge RLOC-records from different xTRs registering the same EID- to merge RLOC-Records from different xTRs registering the same
record. See signal-free multicast [RFC8378] for one use case EID-Record. See Signal-Free Multicast [RFC8378] for one use-case
example. example.
R: This reserved and unassigned bit MUST be set to 0 on transmit and R: This reserved and unassigned bit MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
M: This is the want-map-notify bit. When set to 1, an ETR is M: This is the want-map-notify bit. When set to 1, an ETR is
requesting a Map-Notify message to be returned in response to requesting a Map-Notify message to be returned in response to
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 incremented each time a Map- Nonce: This 8-octet 'Nonce' field is incremented each time a Map-
Register message is sent. When a Map-Register acknowledgement is Register message is sent. When a Map-Register acknowledgment is
requested, the nonce is returned by Map-Servers in Map-Notify requested, the nonce is returned by Map-Servers in Map-Notify
messages. Since the entire Map-Register message is authenticated, messages. Since the entire Map-Register message is authenticated,
the 'Nonce' field serves to protect against Map-Register replay the 'Nonce' field serves to protect against Map-Register replay
attacks. An ETR that registers to the mapping system SHOULD store attacks. An ETR that registers to the Mapping System SHOULD store
the last nonce sent in persistent storage so when it restarts it the last nonce sent in persistent storage, so when it restarts, it
can continue using an incrementing nonce. If the ETR cannot can continue using an incrementing nonce. If the ETR cannot
support saving the nonce, then when it restarts it MUST use a new support saving the nonce, then when it restarts, it MUST use a new
authentication key to register to the mapping system. A Map- authentication key to register to the Mapping System. A Map-
Server MUST track and save in persistent storage the last nonce Server MUST track and save in persistent storage the last nonce
received for each ETR xTR-ID and key pair. If a Map-Register is received for each ETR xTR-ID and key pair. If a Map-Register is
received with a nonce value that is not greater than the saved received with a nonce value that is not greater than the saved
nonce, it MUST drop the Map-Register message and SHOULD log the nonce, it MUST drop the Map-Register message and SHOULD log the
fact a replay attack could have occurred. fact that a replay attack could have occurred.
Key ID: A key-id value that identifies a pre-shared secret between Key ID: This is a key-id value that identifies a pre-shared secret
an ETR and a Map-Server. Per-message keys are derived from the between an ETR and a Map-Server. Per-message keys are derived
pre-shared secret to authenticate the origin and protect the from the pre-shared secret to authenticate the origin and protect
integrity of the Map-Register. The Key ID allows to rotate the integrity of the Map-Register. The Key ID allows rotating
between multiple pre-shared secrets in a non disruptive way. The between multiple pre-shared secrets in a nondisruptive way. The
pre-shared secret MUST be unique per each LISP "Site-ID" pre-shared secret MUST be unique per each LISP Site-ID.
Algorithm ID: This field identifies the Key Derivation Function Algorithm ID: This field identifies the Key Derivation Function
(KDF) and Message Authentication Code (MAC) algorithms used to (KDF) and Message Authentication Code (MAC) algorithms used to
derive the key and to compute the Authentication Data of a Map- derive the key and to compute the Authentication Data of a Map-
Register. This 8-bit field identifies the KDF and MAC algorithm Register. This 8-bit field identifies the KDF and MAC algorithm
pair. See Section 12.5 for codepoint assignments. pair. See Section 12.5 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 output of the MAC algorithm placed Authentication Data: This is the output of the MAC algorithm placed
in this field after the MAC computation. The MAC output is in this field after the MAC computation. The MAC output is
computed as follows: computed as follows:
1: The KDF algorithm is identified by the field 'Algorithm ID' 1. The KDF algorithm is identified by the 'Algorithm ID' field
according to the table in Section 12.5. Implementations of according to the table in Section 12.5. Implementations of
this specification MUST implement HMAC-SHA-256-128 [RFC4868] this specification MUST implement HMAC-SHA-256-128 [RFC4868]
and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC5869] . and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC5869].
2: The MAC algorithm is identified by the field 'Algorithm ID' 2. The MAC algorithm is identified by the 'Algorithm ID' field
according to the table in Section 12.5. according to the table in Section 12.5.
3: The pre-shared secret used to derive the per-message key is 3. The pre-shared secret used to derive the per-message key is
represented by PSK[Key ID], that is the pre-shared secret represented by PSK[Key ID], that is, the pre-shared secret
identified by the 'Key ID'. identified by the Key ID.
4: The derived per-message key is computed as: per-msg- 4. The derived per-message key is computed as: per-msg-
key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in key=KDF(nonce+PSK[Key ID],s). Where the nonce is the value in
the Nonce field of the Map-Register, '+' denotes concatenation the 'Nonce' field of the Map-Register, "+" denotes
and 's' (the salt) is a string that corresponds to the message concatenation and "s" (the salt) is a string that corresponds
type being authenticated. For Map-Register messages, it is to the message type being authenticated. For Map-Register
equal to "Map-Register Authentication". Similarly, for Map- messages, it is equal to "Map-Register Authentication".
Notify and Map-Notify-Ack messages, it is "Map-Notify Similarly, for Map-Notify and Map-Notify-Ack messages, it is
Authentication" and "Map-Notify-Ack Authentication", "Map-Notify Authentication" and "Map-Notify-Ack
respectively. For those Algorithm IDs defined in Section 12.5 Authentication", respectively. For those Algorithm IDs
that specify a 'none' KDF, the per-message key is computed as: defined in Section 12.5 that specify a 'none' KDF, the per-
per-msg-key = PSK[Key ID]. This means that the same key is message key is computed as: per-msg-key = PSK[Key ID]. This
used across multiple protocol messages. means that the same key is used across multiple protocol
messages.
5: The MAC output is computed using the MAC algorithm and the 5. The MAC output is computed using the MAC algorithm and the
per-msg-key over the entire Map-Register payload (from and per-msg-key over the entire Map-Register payload (from and
including the LISP message type field through the end of the including the LISP message type field through the end of the
last RLOC record) with the authenticated data field preset to last RLOC-Record) with the authenticated data field preset to
0. 0.
The definition of the rest of the Map-Register can be found in EID- The definition of the rest of the Map-Register can be found in the
record description in Section 5.4. When the I-bit is set, the EID-Record description in Section 5.4. When the I-bit is set, the
following fields are added to the end of the Map-Register message: following fields are added to the end of the Map-Register message:
xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register xTR-ID: 'xTR-ID' is a 128-bit field at the end of the Map-Register
message, starting after the final Record in the message. The xTR- message, starting after the final Record in the message. The xTR-
ID is used to uniquely identify a xTR. The same xTR-ID value MUST ID is used to uniquely identify an xTR. The same xTR-ID value
NOT be used in two different xTRs in the scope of the Site-ID. MUST NOT be used in two different xTRs in the scope of the Site-
ID.
Site-ID: Site-ID is a 64 bit field at the end of the Map- Register Site-ID: 'Site-ID' is a 64-bit field at the end of the Map-Register
message, following the xTR-ID. Site-ID is used to uniquely message, following the xTR-ID. The Site-ID is used to uniquely
identify to which site the xTR that sent the message belongs. identify to which site the xTR that sent the message belongs.
This document does not specify a strict meaning for the Site-ID This document does not specify a strict meaning for the 'Site-ID'
field. Informally it provides an indication that a group of xTRs field. Informally, it provides an indication that a group of xTRs
have some relation, either administratively, topologically or have some relationship, either administratively, topologically, or
otherwise. otherwise.
5.7. Map-Notify/Map-Notify-Ack Message Format 5.7. Map-Notify and Map-Notify-Ack Message Formats
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 27, line 43 skipping to change at line 1148
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
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 and the message. See "Map-Register Message Format" (Section 5.6) for field
Map-Reply section for EID-record and RLOC-record descriptions. descriptions and "Map-Reply Message Format" (Section 5.4) for EID-
Record and RLOC-Record descriptions.
The fields of the Map-Notify are copied from the corresponding Map- The fields of the Map-Notify are copied from the corresponding Map-
Register to acknowledge its correct processing. In the Map-Notfiy, Register to acknowledge its correct processing. In the Map-Notify,
the 'Authentication Data' field is recomputed using the corresponding the 'Authentication Data' field is recomputed using the corresponding
per-message key and according to the procedure defined in the per-message key and according to the procedure defined in the
previous section. The Map-Notify message can also used, outside the previous section. The Map-Notify message can also be used in an
scope of this specification, in an unsolicited manner, such as is unsolicited manner. This topic is out of scope for this document.
specified in [I-D.ietf-lisp-pubsub]. See [LISP-PUBSUB] for details.
After sending a Map-Register, if a Map-Notify is not received after 1 After sending a Map-Register, if a Map-Notify is not received after 1
second the transmitter MUST re-transmit the original Map-Register second, the transmitter MUST retransmit the original Map-Register
with an exponential backoff (base of 2, that is, the next backoff with an exponential backoff (base of 2, that is, the next backoff
timeout interval is doubled), the maximum backoff is 1 minute. Map- timeout interval is doubled); the maximum backoff is 1 minute. Map-
Notify messages are only transmitted upon the reception of a Map- Notify messages are only transmitted upon the reception of a Map-
Register with the M-bit set, Map-Notify messages are not Register with the M-bit set; Map-Notify messages are not
retransmitted. The only exeption to this is for unsolicited Map- retransmitted. The only exception to this is for unsolicited Map-
Notify messages, see below. Notify messages; see below.
A Map-Server sends an unsolicited Map-Notify message (one that is not A Map-Server sends an unsolicited Map-Notify message (one that is not
used as an acknowledgment to a Map-Register message) only in used as an acknowledgment to a Map-Register message) only in
conformance with the Congestion Control And Relability Guideline conformance with Section 3.1 ("Congestion Control Guidelines") of
sections of [RFC8085]. A Map-Notify is retransmitted until a Map- [RFC8085] and Section 3.3 ("Reliability Guidelines") of [RFC8085]. A
Notify-Ack is received by the Map-Server with the same nonce used in Map-Notify is retransmitted until a Map-Notify-Ack is received by the
the Map-Notify message. An implementation SHOULD retransmit up to 3 Map-Server with the same nonce used in the Map-Notify message. An
times at 3 second retransmission intervals, after which time the implementation SHOULD retransmit up to 3 times at 3-second
retransmission interval is exponentially backed-off (base of 2, that retransmission intervals, after which time the retransmission
is, the next backoff timeout interval is doubled) for another 3 interval is exponentially backed off (base of 2, that is, the next
retransmission attempts. Map-Notify-Ack messages are only backoff timeout interval is doubled) for another 3 retransmission
transmitted upon the reception of an unsolicited Map-Notify, Map- attempts. Map-Notify-Ack messages are only transmitted upon the
Notify-Ack messages are not retransmitted. reception of an unsolicited Map-Notify; Map-Notify-Ack messages are
not retransmitted.
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 an unsolicited message. It is used to acknowledge the receipt of an unsolicited
Map-Notify and, once the the authentication data is validated, allows Map-Notify and, once the Authentication Data is validated, allows the
for the sender to stop retransmitting a Map-Notify with the same sender to stop retransmitting a Map-Notify with the same nonce and
nonce and the authentication data validates. The fields of the Map- (validated) Authentication Data. The fields of the Map-Notify-Ack
Notify-Ack are copied from the corresponding Map-Notify message to are copied from the corresponding Map-Notify message to acknowledge
acknowledge its correct processing. The 'Authentication Data' field its correct processing. The 'Authentication Data' field is
is recomputed using the corresponding per-message key and according recomputed using the corresponding per-message key and according to
to the procedure defined in the previous section. the procedure defined in the previous section.
Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the Upon reception of a Map-Register, Map-Notify, or Map-Notify-Ack, the
receiver verifies the authentication data. If the authentication receiver verifies the Authentication Data. If the Authentication
data fails to validate, the message is dropped without further Data fails to validate, the message is dropped without further
processing. processing.
5.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 or internal packets sent between xTRs and the mapping database system or internal
to the mapping database system. to 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
skipping to change at page 29, line 37 skipping to change at line 1233
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy | / | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message | LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet header descriptions: Packet header descriptions:
OH: The outer IPv4 or IPv6 header, which uses RLOC addresses in the OH: This is the outer IPv4 or IPv6 header, which uses RLOC
source and destination header address fields. addresses in the source and destination header address fields.
UDP: The outer UDP header with destination port 4342. The source UDP: This is the outer UDP header with destination port 4342. The
port is randomly allocated. The checksum field MUST be non- source port is randomly allocated. The checksum field MUST be
zero. non-zero.
LISP: Type 8 is defined to be a "LISP Encapsulated Control Message", LISP: Type 8 is defined to be a "LISP Encapsulated Control Message",
and what follows is either an IPv4 or IPv6 header as encoded by and what follows is either an IPv4 or IPv6 header, as encoded
the first 4 bits after the 'Reserved' field, or the by the first 4 bits after the 'Reserved' field, or the
Authentication Data field [I-D.ietf-lisp-sec] if the S-bit (see 'Authentication Data' field [RFC9303] if the S-bit (see below)
below) is set. is set.
Type: 8 (Encapsulated Control Message (ECM))
Type: 8 (Encapsulated Control Message (ECM))
S: This is the Security bit. When set to 1, the field following S: This is the Security bit. When set to 1, the field following
the 'Reserved' field will have the following Authentication the 'Reserved' field will have the following Authentication
Data format and follow the procedures from [I-D.ietf-lisp-sec]. Data format and follow the procedures from [RFC9303].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D: This is the DDT-bit. When set to 1, the sender is requesting a D: This is the DDT-bit. When set to 1, the sender is requesting a
Map-Referral message to be returned. The details of this Map-Referral message to be returned. Details regarding this
procedure are described in [RFC8111]. procedure are described in [RFC8111].
R: This reserved and unassigned bit MUST be set to 0 on transmit R: This reserved and unassigned bit MUST be set to 0 on transmit
and MUST be ignored on receipt. and MUST be ignored on receipt.
IH: The inner IPv4 or IPv6 header, which can use either RLOC or EID IH: This is the inner IPv4 or IPv6 header, which can use either
addresses in the header address fields. When a Map-Request is RLOC or EID addresses in the header address fields. When a
encapsulated in this packet format, the destination address in Map-Request is encapsulated in this packet format, the
this header is an EID. destination address in this header is an EID.
UDP: The inner UDP header, where the port assignments depend on the UDP: This is the inner UDP header, where the port assignments depend
control packet being encapsulated. When the control packet is on the control packet being encapsulated. When the control
a Map-Request or Map-Register, the source port is selected by packet is a Map-Request or Map-Register, the source port is
the ITR/PITR and the destination port is 4342. When the selected by the ITR/PITR and the destination port is 4342.
control packet is a Map-Reply, the source port is 4342 and the When the control packet is a Map-Reply, the source port is 4342
destination port is assigned from the source port of the and the destination port is assigned from the source port of
invoking Map-Request. Port number 4341 MUST NOT be assigned to the invoking Map-Request. Port number 4341 MUST NOT be
either port. The checksum field MUST be non-zero. assigned to 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
Section 5. Map-Request messages are allowed to be Control- Section 5. Map-Request messages are allowed to be control
Plane (ECM) encapsulated. When Map-Requests are sent for RLOC- plane (ECM) encapsulated. When Map-Requests are sent for RLOC-
Probing purposes (i.e. the probe-bit is set), they MUST NOT be Probing purposes (i.e., the probe-bit is set), they MUST NOT be
sent inside Encapsulated Control Messages. PIM Join/Prune sent inside Encapsulated Control Messages. PIM Join/Prune
messages [RFC6831] are also allowed to be Control-Plane (ECM) messages [RFC6831] are also allowed to be control plane (ECM)
encapsulated. encapsulated.
6. Changing the Contents of EID-to-RLOC Mappings 6. Changing the Contents of EID-to-RLOC Mappings
In the LISP architecture ITRs/PITRs use a local Map-Cache to store In the LISP architecture, ITRs/PITRs use a local Map-Cache to store
EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a EID-to-RLOC mappings for forwarding. When an ETR updates a mapping,
mechanism is required to inform ITRs/PITRs that are using such a mechanism is required to inform ITRs/PITRs that are using such
mappings. mappings.
The LISP Data-Plane defines several mechanism to update mappings The LISP data plane defines several mechanisms to update mappings
[I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map [RFC9300]. This document specifies the Solicit-Map-Request (SMR), a
Request (SMR), a Control-Plane push-based mechanism. An additional control plane push-based mechanism. An additional control plane
Control-Plane mechanism based on the Publish/subscribe paradigm is mechanism based on the Publish/Subscribe paradigm is specified in
specified in [I-D.ietf-lisp-pubsub]. [LISP-PUBSUB].
6.1. Solicit-Map-Request (SMR) 6.1. Solicit-Map-Request (SMR)
Soliciting a Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached. the mappings they have cached.
Since ETRs are not required to keep track of remote ITRs that have Since ETRs are not required to keep track of remote ITRs that have
cached their mappings, they do not know which ITRs need to have their cached their mappings, they do not know which ITRs need to have their
mappings updated. As a result, an ETR will solicit Map-Requests to mappings updated. As a result, an ETR will solicit Map-Requests to
those sites to which it has been sending LISP encapsulated data those sites to which it has been sending LISP encapsulated data
packets for the last minute. As a result, when an ETR is also acting packets for the last minute, and when an ETR is also acting as an
as ITR, it will send an SMR to an ITR to which it has recently sent ITR, it will send an SMR to an ITR to which it has recently sent
encapsulated data. encapsulated data.
An SMR message is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request message. An ITR
or PITR will send a Map-Request (SMR-invoked Map-Request) when they or PITR will send a Map-Request (SMR-invoked Map-Request) when it
receive an SMR message. While the SMR message is sent through the receives an SMR message. While the SMR message is sent through the
data-plane, the SMR-invoked Map-Request MUST be sent through the data plane, the SMR-invoked Map-Request MUST be sent through the
Mapping System (not directly). Mapping System (not directly).
Both the SMR sender and the SMR responder MUST rate-limit these Both the SMR sender and the SMR responder MUST rate limit these
messages. It is RECOMMENDED that the SMR sender rate-limits Map- messages. It is RECOMMENDED that the SMR sender rate limit a Map-
Request for the same destination RLOC to no more than one packet per Request for the same destination RLOC to no more than one packet
3 seconds. It is RECOMMENDED that the SMR responder rate-limits Map- every 3 seconds. It is RECOMMENDED that the SMR responder rate limit
Request for the same EID-Prefix to no more than once per 3 seconds. a Map-Request for the same EID-Prefix to no more than once every 3
seconds.
When an ITR receives an SMR message for which it does not have a When an ITR receives an SMR message for which it does not have a
cached mapping for the EID in the SMR message, it SHOULD NOT send an cached mapping for the EID in the SMR message, it SHOULD NOT send an
SMR-invoked Map-Request. This scenario can occur when an ETR sends SMR-invoked Map-Request. This scenario can occur when an ETR sends
SMR messages to all Locators in the Locator-Set it has stored in its SMR messages to all Locators in the Locator-Set it has stored in its
Map-Cache but the remote ITRs that receive the SMR may not be sending Map-Cache but the remote ITRs that receive the SMR may not be sending
packets to the site. There is no point in updating the ITRs until packets to the site. There is no point in updating the ITRs until
they need to send, in which case they will send Map-Requests to they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry. obtain a Map-Cache entry.
7. Routing Locator Reachability 7. Routing Locator Reachability
This document defines several Control-Plane mechanisms for This document defines several control plane mechanisms for
determining RLOC reachability. Please note that additional Data- determining RLOC reachability. Please note that additional data
Plane reachability mechanisms are defined in plane reachability mechanisms are defined in [RFC9300].
[I-D.ietf-lisp-rfc6830bis].
1. An ITR may receive an ICMP Network Unreachable or Host 1. An ITR may receive an ICMP Network Unreachable or Host
Unreachable message for an RLOC it is using. This indicates that Unreachable message for an RLOC it is using. This indicates that
the RLOC is likely down. Note that trusting ICMP messages may the RLOC is likely down. Note that trusting ICMP messages may
not be desirable, but neither is ignoring them completely. not be desirable, but neither is ignoring them completely.
Implementations are encouraged to follow current best practices Implementations are encouraged to follow current best practices
in treating these conditions [I-D.ietf-opsec-icmp-filtering]. in treating these conditions [OPSEC-ICMP-FILTER].
2. When an ITR participates in the routing protocol that operates in 2. When an ITR participates in the routing protocol that operates in
the underlay routing system, it can determine that an RLOC is the underlay routing system, it can determine that an RLOC is
down when no Routing Information Base (RIB) entry exists that down when no Routing Information Base (RIB) entry exists that
matches the RLOC IP address. matches the RLOC IP address.
3. An ITR may receive an ICMP Port Unreachable message from a 3. An ITR may receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use destination host. This occurs if an ITR attempts to use
interworking [RFC6832] and LISP-encapsulated data is sent to a interworking [RFC6832] and LISP-encapsulated data is sent to a
non-LISP-capable site. non-LISP-capable site.
4. An ITR may receive a Map-Reply from an ETR in response to a 4. An ITR may receive a Map-Reply from an ETR in response to a
previously sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of the Map-Reply is
likely up, since the ETR was able to send the Map-Reply to the likely up, since the ETR was able to send the Map-Reply to the
ITR. Please note that in some scenarios the RLOC -from the outer ITR. Please note that in some scenarios the RLOC -- from the
header- can be an spoofable field. outer header -- can be a spoofable field.
5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described
below. below.
When ITRs receive ICMP Network Unreachable or Host Unreachable When ITRs receive ICMP Network Unreachable or Host Unreachable
messages as a method to determine unreachability, they will refrain messages as a method to determine unreachability, they will refrain
from using Locators that are described in Locator lists of Map- from using Locators that are described in Locator lists of Map-
Replies. However, using this approach is unreliable because many Replies. However, using this approach is unreliable because many
network operators turn off generation of ICMP Destination Unreachable network operators turn off generation of ICMP Destination Unreachable
messages. messages.
skipping to change at page 33, line 9 skipping to change at line 1389
packet the ITR encapsulated. packet the ITR encapsulated.
This assumption does create a dependency: Locator unreachability is This assumption does create a dependency: Locator unreachability is
detected by the receipt of ICMP Host Unreachable messages. When a detected by the receipt of ICMP Host Unreachable messages. When a
Locator has been determined to be unreachable, it is not used for Locator has been determined to be unreachable, it is not used for
active traffic; this is the same as if it were listed in a Map-Reply active traffic; this is the same as if it were listed in a Map-Reply
with Priority 255. with Priority 255.
The ITR can test the reachability of the unreachable Locator by The ITR can test the reachability of the unreachable Locator by
sending periodic Map-Requests. Both Map-Requests and Map-Replies sending periodic Map-Requests. Both Map-Requests and Map-Replies
MUST be rate-limited, see Section 5.3 and Section 5.4 for information MUST be rate limited; see Sections 5.3 and 5.4 for information about
about rate-limiting. Locator reachability testing is never done with rate limiting. Locator reachability testing is never done with data
data packets, since that increases the risk of packet loss for end- packets, since that increases the risk of packet loss for end-to-end
to-end sessions. sessions.
7.1. RLOC-Probing Algorithm 7.1. RLOC-Probing Algorithm
RLOC-Probing is a method that an ITR or PITR can use to determine the RLOC-Probing is a method that an ITR or PITR can use to determine the
reachability status of one or more Locators that it has cached in a reachability status of one or more Locators that it has cached in a
Map-Cache entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request and Map-Reply
messages is used for RLOC-Probing. messages is used for RLOC-Probing.
RLOC-Probing is done in the control plane on a timer basis, where an RLOC-Probing is done in the control plane on a timer basis, where an
ITR or PITR will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to a Routing
address from one of its own locator addresses. A Map-Request used as Locator Address from one of its own Routing Locator Addresses. A
an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to Map-Request used as an RLOC-Probe is NOT encapsulated and NOT sent to
the mapping database system as one would when requesting mapping a Map-Server or to the mapping database system as one would when
data. The EID record encoded in the Map-Request is the EID-Prefix of requesting mapping data. The EID-Record encoded in the Map-Request
the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a is the EID-Prefix of the Map-Cache entry cached by the ITR or PITR.
mapping data record for its own database mapping information that The ITR MAY include a mapping data record for its own database
contains the local EID-Prefixes and RLOCs for its site. RLOC-probes mapping information that contains the local EID-Prefixes and RLOCs
are sent periodically using a jittered timer interval. for its site. RLOC-Probes are sent periodically using a jittered
timer interval.
When an ETR receives a Map-Request message with the probe-bit set, it When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set to the IP address of the outgoing interface the the Map-Reply is set to the IP address of the outgoing interface the
Map-Reply destination address routes to. The Map-Reply SHOULD Map-Reply destination address routes to. The Map-Reply SHOULD
contain mapping data for the EID-Prefix contained in the Map-Request. contain mapping data for the EID-Prefix contained in the Map-Request.
This provides the opportunity for the ITR or PITR that sent the RLOC- This provides the opportunity for the ITR or PITR that sent the RLOC-
probe to get mapping updates if there were changes to the ETR's Probe to get mapping updates if there were changes to the ETR's
database mapping entries. database mapping entries.
There are advantages and disadvantages of RLOC-Probing. The main There are advantages and disadvantages of RLOC-Probing. The main
benefit of RLOC-Probing is that it can handle many failure scenarios benefit of RLOC-Probing is that it can handle many failure scenarios,
allowing the ITR to determine when the path to a specific Locator is allowing the ITR to determine when the path to a specific Locator is
reachable or has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a robust
mechanism for switching to using another Locator from the cached mechanism for switching to using another Locator from the cached
Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT) Locator. RLOC-Probing can also provide rough Round-Trip Time (RTT)
estimates between a pair of Locators, which can be useful for network estimates between a pair of Locators, which can be useful for network
management purposes as well as for selecting low delay paths. The management purposes as well as for selecting low-delay paths. The
major disadvantage of RLOC-Probing is in the number of control major disadvantage of RLOC-Probing is in the number of control
messages required and the amount of bandwidth used to obtain those messages required and the amount of bandwidth used to obtain those
benefits, especially if the requirement for failure detection times benefits, especially if the requirement for failure detection times
is very small. is very small.
8. Interactions with Other LISP Components 8. Interactions with Other LISP Components
8.1. ITR EID-to-RLOC Mapping Resolution 8.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. connect to any other database Mapping System.
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
its operation. its operation.
In response to an Encapsulated Map-Request, the ITR can expect one of In response to an Encapsulated Map-Request, the ITR can expect one of
the following: the following:
o An immediate Negative Map-Reply (with action code of "Natively- * An immediate Negative Map-Reply (with action code "Natively-
Forward", 15-minute Time to Live (TTL)) from the Map-Resolver if Forward" and a 15-minute TTL) from the Map-Resolver if the Map-
the Map-Resolver can determine that the requested EID does not Resolver can determine that the requested EID does not exist. The
exist. The ITR saves the EID-Prefix returned in the Map-Reply in ITR saves the EID-Prefix returned in the Map-Reply in its cache,
its cache, marks it as non-LISP-capable, and knows not to attempt marks it as non-LISP-capable, and knows not to attempt LISP
LISP encapsulation for destinations matching it. encapsulation for destinations matching it.
o A Negative Map-Reply, with action code of "Natively-Forward", from * A Negative Map-Reply (with action code "Natively-Forward") from a
a Map-Server that is authoritative (within the LISP deployment Map-Server that is authoritative (within the LISP deployment
Section 1.1) for an EID-Prefix that matches the requested EID but (Section 1.1)) for an EID-Prefix that matches the requested EID
that does not have an actively registered, more-specific EID- but that does not have an actively registered, more-specific EID-
prefix. In this case, the requested EID is said to match a "hole" Prefix. In this case, the requested EID is said to match a "hole"
in the authoritative EID-Prefix. If the requested EID matches a in the authoritative EID-Prefix. If the requested EID matches a
more-specific EID-Prefix that has been delegated by the Map-Server more-specific EID-Prefix that has been delegated by the Map-Server
but for which no ETRs are currently registered, a 1-minute TTL is but for which no ETRs are currently registered, a 1-minute TTL is
returned. If the requested EID matches a non-delegated part of returned. If the requested EID matches a non-delegated part of
the authoritative EID-Prefix, then it is not a LISP EID and a the authoritative EID-Prefix, then it is not a LISP EID and a
15-minute TTL is returned. See Section 8.2 for discussion of 15-minute TTL is returned. See Section 8.2 for a discussion of
aggregate EID-Prefixes and details of Map-Server EID-Prefix aggregate EID-Prefixes and details regarding Map-Server EID-Prefix
matching. matching.
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or * 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 8.4 for more details on Map-Resolver message processing. Section 8.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
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.
8.2. EID-Prefix Configuration and ETR Registration 8.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 pre-shared secret used ETR and Map-Server MUST be configured with a pre-shared secret used
to derive Map-Register authentication keys. A Map-Server's to derive Map-Register authentication keys. A Map-Server's
configuration SHOULD also include a list of the EID-Prefixes for configuration SHOULD also include a list of the EID-Prefixes for
which each ETR is authoritative. Upon receipt of a Map-Register from which each ETR is authoritative. Upon receipt of a Map-Register from
an ETR, a Map-Server accepts only EID-Prefixes that are configured an ETR, a Map-Server accepts only EID-Prefixes that are configured
for that ETR. Failure to implement such a check would leave the for that ETR. Failure to implement such a check would leave the
mapping system vulnerable to trivial EID-Prefix hijacking attacks. Mapping System vulnerable to trivial EID-Prefix hijacking attacks.
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 8.3 match an aggregate but do not match a registered prefix; Section 8.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
skipping to change at page 36, line 15 skipping to change at line 1539
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]. [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 Section 7.1 for Requests instead of forwarding them to the ETR. See Section 7.1 for
details on how the Map-Server sets certain flags (such as those details on how the Map-Server sets certain flags (such as those
indicating whether the message is authoritative and how returned indicating whether the message is authoritative and how returned
Locators SHOULD be treated) when sending a Map-Reply on behalf of an Locators SHOULD be treated) when sending a Map-Reply on behalf of an
ETR. When an ETR requests proxy reply service, it SHOULD include all ETR. When an ETR requests proxy reply service, it SHOULD include all
RLOCs for all ETRs for the EID-Prefix being registered, along with RLOCs for all ETRs for the EID-Prefix being registered, along with
the routable flag ("R-bit") setting for each RLOC. The Map-Server the routable flag ("R-bit") setting for each RLOC. The Map-Server
skipping to change at page 37, line 13 skipping to change at line 1581
of the mapping database protocols. of the mapping database protocols.
8.3. Map-Server Processing 8.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, the Map-Server first checks to see if In response to a Map-Request, the Map-Server first checks to see if
the destination EID matches a configured EID-Prefix. If there is no the destination EID matches a configured EID-Prefix. If there is no
match, the Map-Server returns a Negative Map-Reply with action code match, the Map-Server returns a Negative Map-Reply with action code
"Natively-Forward" and a 15-minute TTL. This can occur if a Map "Natively-Forward" and a 15-minute TTL. This can occur if a Map-
Request is received for a configured aggregate EID-Prefix for which Request is received for a configured aggregate EID-Prefix for which
no more-specific EID-Prefix exists; it indicates the presence of a no more-specific EID-Prefix exists; it indicates the presence of a
non-LISP "hole" in the aggregate EID-Prefix. non-LISP "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 the EID-prefix is either registered or not registered to the If the EID-Prefix is either registered or not registered to the
mapping system and there is a policy in the Map-Server to have the Mapping System and there is a policy in the Map-Server to have the
requestor drop packets for the matching EID-prefix, then a Drop/ requester drop packets for the matching EID-Prefix, then a Drop/
Policy-Denied action is returned. If the EID-prefix is registered or Policy-Denied action is returned. If the EID-Prefix is registered or
not registered and there is a authentication failure, then a Drop/ not registered and there is an authentication failure, then a Drop/
Authentication- failure action is returned. If either of these Auth-Failure action is returned. If either of these actions results
actions result as a temporary state in policy or authentication then as a temporary state in policy or authentication, then a Send-Map-
a Send-Map-Request action with 1-minute TTL MAY be returned to allow Request action with a 1-minute TTL MAY be returned to allow the
the requestor to retry the Map-Request. requester to retry the Map-Request.
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
skipping to change at page 38, line 12 skipping to change at line 1629
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 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
skipping to change at page 38, line 37 skipping to change at line 1654
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.
8.4.1. Anycast Operation 8.4.1. Anycast 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.
ETRs MAY have anycast RLOC addresses which are registered as part of ETRs MAY have anycast RLOC addresses that are registered as part of
their RLOC-set to the mapping system. However, registrations MUST their RLOC-Set to the Mapping System. However, registrations MUST
use their unique RLOC addresses, distinct authentication keys or use their unique RLOC addresses, distinct authentication keys, or
different XTR-IDs to identify security associations with the Map- different xTR-IDs to identify security associations with the Map-
Servers. Servers.
9. Security Considerations 9. Security Considerations
A LISP threat analysis can be found in [RFC7835]. In what follows we A LISP threat analysis can be found in [RFC7835]. Here, we highlight
highlight security considerations that apply when LISP is deployed in security considerations that apply when LISP is deployed in
environments such as those specified in Section 1.1, where the environments such as those specified in Section 1.1, where the
following assumptions hold: following assumptions hold:
1. The Mapping System is secure and trusted, and for the purpose of 1. The Mapping System is secure and trusted, and for the purpose of
this security considerations the Mapping System is considered as these security considerations, the Mapping System is considered
one trusted element. as one trusted element.
2. The ETRs have a pre-configured trust relationship with the 2. The ETRs have a preconfigured trust relationship with the Mapping
Mapping System, which includes some form of shared secret, and System, including some form of shared secret. The Mapping System
the Mapping System is aware of which EIDs an ETR can advertise. is aware of which EIDs an ETR can advertise. How those keys and
How those keys and mappings gets established is out of the scope mappings are established is out of scope for this document.
of this document.
3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network 3. LISP-SEC [RFC9303] MUST be implemented. Network operators should
operators should carefully weight how the LISP-SEC threat model carefully weigh how the LISP-SEC threat model applies to their
applies to their particular use case or deployment. If they particular use case or deployment. If they decide to ignore a
decide to ignore a particular recommendation, they should make particular recommendation, they should make sure the risk
sure the risk associated with the corresponding threats is well associated with the corresponding threats is well understood.
understood.
The Map-Request/Map-Reply message exchange can be exploited by an The Map-Request/Map-Reply message exchange can be exploited by an
attacker to mount DoS and/or amplification attacks. Attackers can attacker to mount DoS and/or amplification attacks. Attackers can
send Map-Requests at high rates to overload LISP nodes and increase send Map-Requests at high rates to overload LISP nodes and increase
the state maintained by such nodes or consume CPU cycles. Such the state maintained by such nodes or consume CPU cycles. Such
threats can be mitigated by systematically applying filters and rate threats can be mitigated by systematically applying filters and rate
limiters. limiters.
The Map-Request/Map-Reply message exchange can also be exploited to The Map-Request/Map-Reply message exchange can also be exploited to
inject forged mappings directly in the ITR EID-to-RLOC map-cache. inject forged mappings directly into the ITR EID-to-RLOC Map-Cache.
This can lead to traffic being redirected to the attacker, see This can lead to traffic being redirected to the attacker; see
further details in [RFC7835]. In addition, valid ETRs in the system further details in [RFC7835]. In addition, valid ETRs in the system
can perform overclaiming attacks. In this case, attackers can claim can perform overclaiming attacks. In this case, attackers can claim
to own an EID-prefix that is larger than the prefix owned by the ETR. to own an EID-Prefix that is larger than the prefix owned by the ETR.
Such attacks can be addressed by using LISP-SEC [I-D.ietf-lisp-sec]. Such attacks can be addressed by using LISP-SEC [RFC9303]. The LISP-
The LISP-SEC protocol defines a mechanism for providing origin SEC protocol defines a mechanism for providing origin authentication,
authentication, integrity protection, and prevention of 'man-in-the- integrity protection, and prevention of 'man-in-the-middle' and
middle' and 'prefix overclaiming' attacks on the Map-Request/Map- 'prefix overclaiming' attacks on the Map-Request/Map-Reply exchange.
Reply exchange. In addition and while beyond the scope of securing In addition, and while beyond the scope of securing an individual
an individual Map-Server or Map-Resolver, it should be noted that Map-Server or Map-Resolver, it should be noted that LISP-SEC can be
LISP-SEC can be complemented by additional security mechanisms complemented by additional security mechanisms defined by the Mapping
defined by the Mapping System Infrastructure. For instance, BGP- System infrastructure. For instance, BGP-based LISP-ALT [RFC6836]
based LISP-ALT [RFC6836] can take advantage of standards work on can take advantage of standards work on adding security to BGP, while
adding security to BGP while LISP-DDT [RFC8111] defines its own LISP-DDT [RFC8111] defines its own additional security mechanisms.
additional security mechanisms.
To publish an authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with a Map-Server
using the Map-Register message, an ETR includes authentication data using the Map-Register message, an ETR includes Authentication Data
that is a MAC of the entire message using a key derived from the pre- that is a MAC of the entire message using a key derived from the pre-
shared secret. An implementation SHOULD support HMAC-SHA256- shared secret. An implementation SHOULD support HMAC-SHA256-
128+HKDF-SHA256 [RFC5869]. The Map-Register message includes 128+HKDF-SHA256 [RFC5869]. The Map-Register message includes
protection for replay attacks by a man-in-the-middle. However, there protection against replay attacks by a man in the middle. However,
is a potential attack where a compromised ETR could overclaim the there is a potential attack where a compromised ETR could overclaim
prefix it owns and successfully register it on its corresponding Map- the prefix it owns and successfully register it on its corresponding
Server. To mitigate this and as noted in Section 8.2, a Map-Server Map-Server. To mitigate this, as noted in Section 8.2, a Map-Server
MUST verify that all EID-Prefixes registered by an ETR match the MUST verify that all EID-Prefixes registered by an ETR match the
configuration stored on the Map-Server. configuration stored on the Map-Server.
Deployments concerned about manipulations of Map-Request and Map- Deployments concerned about manipulations of Map-Request and Map-
Reply messages, and malicious ETR EID prefix overclaiming MUST drop Reply messages and malicious ETR EID-Prefix overclaiming MUST drop
LISP Control Plane messages that do not contain LISP-SEC material LISP control plane messages that do not contain LISP-SEC material
(S-bit, EID-AD, OTK-AD, PKT-AD). (S-bit, EID-AD, OTK-AD, PKT-AD). See Section 3 of [RFC9303] for
definitions of "EID-AD", "OTK-AD", and "PKT-AD".
Mechanisms to encrypt, support privacy, prevent eavesdropping and Mechanisms to encrypt, support privacy, and prevent eavesdropping and
packet tampering for messages exchanged between xTRs, xTRs and the packet tampering for messages exchanged between xTRs, between xTRs
mapping system, and nodes that make up the mapping system, SHOULD be and the Mapping System, and between nodes that make up the Mapping
deployed. Examples of this are DTLS [RFC6347] or LISP-crypto System SHOULD be deployed. Examples of this are DTLS [RFC9147] or
[RFC8061]. "lisp-crypto" [RFC8061].
10. Privacy Considerations 10. Privacy Considerations
As noted by [RFC6973] privacy is a complex issue that greatly depends As noted by [RFC6973], privacy is a complex issue that greatly
on the specific protocol use-case and deployment. As noted in depends on the specific protocol use case and deployment. As noted
section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases in Section 1.1 of [RFC9300], LISP focuses on use cases where entities
where entities communicate over the public Internet while keeping communicate over the public Internet while keeping separate
separate addressing and topology. In what follows we detail the addressing and topology. Here, we detail the privacy threats
privacy threats introduced by the LISP Control Plane, the analysis is introduced by the LISP control plane; the analysis is based on the
based on the guidelines detailed in [RFC6973]. guidelines detailed in [RFC6973].
LISP can use long-lived identifiers (EIDs) that survive mobility LISP can use long-lived identifiers (EIDs) that survive mobility
events. Such identifiers bind to the RLOCs of the nodes, which events. Such identifiers bind to the RLOCs of the nodes. The RLOCs
represents the topological location with respect to the specific LISP represent the topological location with respect to the specific LISP
deployments. In addition, EID-to-RLOC mappings are typically deployments. In addition, EID-to-RLOC mappings are typically
considered public information within the LISP deployment when considered public information within the LISP deployment when control
control-plane messages are not encrypted, and can be eavesdropped plane messages are not encrypted and can be eavesdropped while Map-
while Map-Request messages are sent to the corresponding Map- Request messages are sent to the corresponding Map-Resolvers or Map-
Resolvers or Map-Register messages to Map-Servers. Register messages to Map-Servers.
In this context, attackers can correlate the EID with the RLOC and In this context, attackers can correlate the EID with the RLOC and
track the corresponding user topological location and/or mobility. track the corresponding user topological location and/or mobility.
This can be achieved by off-path attackers, if they are This can be achieved by off-path attackers, if they are
authenticated, by querying the mapping system. Deployments concerned authenticated, by querying the Mapping System. Deployments concerned
about this threat can use access control-lists or stronger about this threat can use access control lists or stronger
authentication mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping authentication mechanisms [ECDSA-AUTH] in the Mapping System to make
system to make sure that only authorized users can access this sure that only authorized users can access this information (data
information (data minimization). Use of ephemeral EIDs minimization). Use of ephemeral EIDs [EID-ANONYMITY] to achieve
[I-D.ietf-lisp-eid-anonymity] to achieve anonymity is another anonymity is another mechanism to lessen persistency and identity
mechanism to lessen persistency and identity tracking. tracking.
11. Changes since RFC 6833 11. Changes Related to RFCs 6830 and 6833
For implementation considerations, the following major changes have For implementation considerations, the following major changes have
been made to this document since RFC 6833 was published: been made to this document since [RFC6830] and [RFC6833] were
published:
o A Map-Notify-Ack message is added in this document to provide * The 16-bit 'Key ID' field of the Map-Register and Map-Notify
messages as defined in [RFC6830] has been split into an 8-bit 'Key
ID' field and an 8-bit 'Algorithm ID' field. Note that this
change also applies to the Map-Notify-Ack message defined by this
document. See Sections 5.6 and 5.7.
* This document defines a Map-Notify-Ack message to provide
reliability for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver of a Map-Notify
message must respond with a Map-Notify-Ack message. Map-Servers message must respond with a Map-Notify-Ack message. Map-Servers
who are senders of Map-Notify messages, must queue the Map-Notify who are senders of Map-Notify messages must queue the Map-Notify
contents until they receive a Map-Notify-Ack with the nonce used contents until they receive a Map-Notify-Ack with the nonce used
in the Map-Notify message. Note that implementations for Map- in the Map-Notify message. Note that implementations for Map-
Notify-Ack support already exist and predate this document. Notify-Ack support already exist and predate this document.
o This document is incorporating the codepoint for the Map-Referral * This document has incorporated the codepoint for the Map-Referral
message from the LISP-DDT specification [RFC8111] to indicate that message from the LISP-DDT specification [RFC8111] to indicate that
a Map-Server must send the final Map-Referral message when it a Map-Server must send the final Map-Referral message when it
participates in the LISP-DDT mapping system procedures. participates in the LISP-DDT Mapping System procedures.
o The L" and "D" bits are added to the Map-Request message. See * Bits L and D have been added to the Map-Request message. See
Section 5.3 for details. Section 5.3 for details.
o The "S", "I", "E", "T", "a", "R", and "M" bits are added to the * Bits S, I, E, T, a, R, and M have been added to the Map-Register
Map-Register message. See Section 5.6 for details. message. See Section 5.6 for details.
o The 16-bit Key-ID field of the Map-Register message has been split
into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.
o The nonce and the authentication data in the Map-Register message * The nonce and the Authentication Data in the Map-Register message
have a different behaviour, see Section 5.6 for details. each behave differently; see Section 5.6 for details.
o This document adds two new Action values that are in an EID-record * This document adds two new action values that are in an EID-Record
that appear in Map-Reply, Map-Register, Map-Notify, and Map- that appears in Map-Reply, Map-Register, Map-Notify, and Map-
Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure Notify-Ack messages. These new action values are Drop/Policy-
are the descriptions for the two new action values. See Denied and Drop/Auth-Failure. See Section 5.4 for details.
Section 5.4 for details.
12. IANA Considerations 12. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to IANA regarding registration of
Authority (IANA) regarding registration of values related to this values related to this LISP control plane specification, in
LISP Control-Plane specification, in accordance with BCP 26 accordance with BCP 26 [RFC8126].
[RFC8126].
There are three namespaces (listed in the sub-sections below) in LISP
that have been registered.
o LISP IANA registry allocations should not be made for purposes * 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 * The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental BCP 26 [RFC8126]: "Specification Required", "IETF Review",
Use", and "First Come First Served". "Experimental Use", and "First Come First Served".
There are three namespaces (listed in the sub-sections below) in LISP
that have been registered (see [RFC9299].
12.1. LISP UDP Port Numbers 12.1. LISP UDP Port Numbers
The IANA registry has allocated UDP port number 4342 for the LISP IANA allocated UDP port number 4342 for the LISP control plane. IANA
Control-Plane. IANA has updated the description for UDP port 4342 as has updated the description for UDP port 4342 to reflect the
follows: following:
Keyword Port Transport Layer Description +==============+=============+===========+==============+===========+
------- ---- --------------- ----------- | Service Name | Port | Transport | Description | Reference |
lisp-control 4342 udp LISP Control Packets | | Number | Protocol | | |
+==============+=============+===========+==============+===========+
| lisp-control | 4342 | udp | LISP Control | RFC 9301 |
| | | | Packets | |
+--------------+-------------+-----------+--------------+-----------+
Table 2
12.2. LISP Packet Type Codes 12.2. LISP Packet Type Codes
It is being requested that the IANA be authoritative for LISP Packet IANA is now authoritative for LISP Packet Type definitions, so they
Type definitions and it is requested to replace the [RFC6830] have replaced the registry references to [RFC6830] with references to
registry message references with the RFC number assigned to this this document.
document.
Based on deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience related to [RFC6830], the Map-Notify-
message, message type 5, was added by this document. This document Ack message (message type 5) is defined in this document. IANA has
requests IANA to add it to the LISP Packet Type Registry. registered it in the "LISP Packet Types" registry.
Name Number Defined in +=====================+======+===========+
---- ------ ----------- | Message | Code | Reference |
LISP Map-Notify-Ack 5 RFC6833bis +=====================+======+===========+
| LISP Map-Notify-Ack | 5 | RFC 9301 |
+---------------------+------+-----------+
Table 3
12.3. LISP Map-Reply EID-Record Action Codes 12.3. LISP Map-Reply EID-Record Action Codes
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]. IANA is Four values have already been allocated by [RFC6830]. IANA has
requested to replace the [RFC6830] reference for this registry with replaced the reference pointing to [RFC6830] to point to this
the RFC number assigned to this document and [RFC6830]. This document. This specification changes the Action name of value 3 from
specification changes the name of ACT type 3 value from "Drop" to "Drop" to "Drop/No-Reason". It also adds the following new ACT
"Drop/No-Reason" as well as adding two new ACT values, the "Drop/ values.
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).
+-------+--------------------+-------------------------+------------+ +=======+===============+=============================+===========+
| Value | Action | Description | Raeference | | Value | Action | Description | Reference |
+-------+--------------------+-------------------------+------------+ +=======+===============+=============================+===========+
| 4 | Drop/Policy-Denied | A packet matching this | RFC6833bis | | 4 | Drop/Policy- | A packet matching this Map- | RFC 9301 |
| | | Map-Cache entry is | | | | Denied | Cache entry is dropped | |
| | | dropped because | | | | | because the target EID is | |
| | | the target EWID is | | | | | policy-denied by the xTR or | |
| | | policy-denied by the | | | | | the Mapping System. | |
| | | xTR or the mapping | | +-------+---------------+-----------------------------+-----------+
| | | system. | | | 5 | Drop/Auth- | A packet matching this Map- | RFC 9301 |
| 5 | Drop/Auth-Failure | Packet matching the | RFC6833bis | | | Failure | Cache entry is dropped | |
| | | Map-Cache entry is | | | | | because the Map-Request for | |
| | | dropped beacuse the | | | | | the target EID fails an | |
| | | Map-Request for the | | | | | authentication check by the | |
| | | target EID fails an | | | | | xTR or the Mapping System. | |
| | | authentication check | | +-------+---------------+-----------------------------+-----------+
| | | by the xTR or the | |
| | | mapping system. | |
+-------+--------------------+-------------------------+------------+
LISP Map-Reply Action Values Table 4: LISP Map-Reply Action Values
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 flags of the LISP header fields [RFC9300]. New bits for
bits for flags in these fields can be implemented after IETF review flags in these fields can be implemented after IETF Review or IESG
or IESG approval, but these need not be managed by IANA. Approval, but these need not be managed by IANA.
12.4. LISP Address Type Codes 12.4. LISP Address Type Codes
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] has an 8-bit Type
defines LISP-specific encodings for AFI value 16387. LCAF encodings field that defines LISP-specific encodings for AFI value 16387. LCAF
are used for specific use-cases where different address types for encodings are used for specific use cases where different address
EID-records and RLOC-records are required. types for EID-Records and RLOC-Records are required.
The IANA registry "LISP Canonical Address Format (LCAF) Types" is The "LISP Canonical Address Format (LCAF) Types" registry is used for
used for LCAF types. The registry for LCAF types use the LCAF types. The registry for LCAF types uses the Specification
Specification Required policy [RFC8126]. Initial values for the Required policy [RFC8126]. Initial values for the registry as well
registry as well as further information can be found in [RFC8060]. 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]. Per this document, the
remove it. registry has been closed.
12.5. LISP Algorithm ID Numbers 12.5. 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. Per this document, IANA has renamed the registry to "LISP
Numbers" and requests the IANA to make the name change. Algorithm ID Numbers" and listed this document as the registry
reference.
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 an 'Algorithm ID' field:
Name Number MAC KDF +=============================+========+===========+===========+
------------------------------------------------------- | Name | Number | MAC | KDF |
None 0 None None +=============================+========+===========+===========+
HMAC-SHA-1-96-None 1 [RFC2404] None | None | 0 | None | None |
HMAC-SHA-256-128-None 2 [RFC4868] None +-----------------------------+--------+-----------+-----------+
HMAC-SHA256-128+HKDF-SHA256 3 [RFC4868] [RFC4868] | HMAC-SHA-1-96-None | 1 | [RFC2404] | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA-256-128-None | 2 | [RFC4868] | None |
+-----------------------------+--------+-----------+-----------+
| HMAC-SHA256-128+HKDF-SHA256 | 3 | [RFC4868] | [RFC4868] |
+-----------------------------+--------+-----------+-----------+
Number values are in the range of 0 to 255. The allocation of values Table 5
is on a first come first served basis.
Number values are in the range of 0 to 255. Values are assigned on a
First Come First Served basis.
12.6. LISP Bit Flags 12.6. LISP Bit Flags
This document asks IANA to create a registry for allocation of bits This document asks IANA to create a registry for allocation of bits
in several headers of the LISP control plane, namely in the Map- in several headers of the LISP control plane, namely in Map-Request
Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) messages, Map-Reply messages, Map-Register messages, and Encapsulated
messages. Bit allocations are also requested for EID-records and Control Messages. Bit allocations are also requested for EID-Records
RLOC-records. The registry created should be named "LISP Control and RLOC-Records. The registry created should be named "LISP Control
Plane Header Bits". A sub-registry needs to be created per each Plane Header Bits". A subregistry needs to be created per each
message and EID-record. The name of each sub-registry is indicated message and EID-Record. The name of each subregistry is indicated
below, along with its format and allocation of bits defined in this below, along with its format and allocation of bits defined in this
document. Any additional bits allocation, requires a specification, document. Any additional bit allocations require a specification, in
according with [RFC8126] policies. accordance with policies defined in [RFC8126].
Sub-Registry: Map-Request Header Bits [Section 5.2]: Subregistry: Map-Request Header Bits (Section 5.2):
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|R|R| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+---------+---------------+-----------+-----------------------------+
| Spec | IANA Name | Bit | Description |
| Name | | Position | |
+---------+---------------+-----------+-----------------------------+
| A | map-request-A | 4 | Authoritative Bit |
| M | map-request-M | 5 | Map Data Present Bit |
| P | map-request-P | 6 | RLOC-Probe Request Bit |
| S | map-request-S | 7 | Solicit Map-Request (SMR) |
| | | | Bit |
| p | map-request-p | 8 | Proxy-ITR Bit |
| s | map-request-s | 9 | Solicit Map-Request Invoked |
| | | | Bit |
| L | map-request-L | 17 | Local xTR Bit |
| D | map-request-D | 18 | Don't Map-Reply Bit |
+---------+---------------+-----------+-----------------------------+
LISP Map-Request Header Bits +===========+===============+==============+========================+
| Spec Name | IANA Name | Bit Position | Description |
+===========+===============+==============+========================+
| A | Map-Request-A | 4 | Authoritative Bit |
+-----------+---------------+--------------+------------------------+
| M | Map-Request-M | 5 | Map Data Present Bit |
+-----------+---------------+--------------+------------------------+
| P | Map-Request-P | 6 | RLOC-Probe Request |
| | | | Bit |
+-----------+---------------+--------------+------------------------+
| S | Map-Request-S | 7 | Solicit Map-Request |
| | | | (SMR) Bit |
+-----------+---------------+--------------+------------------------+
| p | Map-Request-p | 8 | Proxy-ITR Bit |
+-----------+---------------+--------------+------------------------+
| s | Map-Request-s | 9 | Solicit Map-Request |
| | | | Invoked Bit |
+-----------+---------------+--------------+------------------------+
| L | Map-Request-L | 17 | Local xTR Bit |
+-----------+---------------+--------------+------------------------+
| D | Map-Request-D | 18 | Don't Map-Reply Bit |
+-----------+---------------+--------------+------------------------+
Sub-Registry: Map-Reply Header Bits [Section 5.4]: Table 6: LISP Map-Request Header Bits
0 1 2 3 Subregistry: Map-Reply Header Bits (Section 5.4):
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+-------------+--------------+------------------------+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+===========+=============+==============+========================+
| Spec Name | IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | Description |
+===========+=============+==============+========================+
| P | Map-Reply-P | 4 | RLOC-Probe Bit |
+-----------+-------------+--------------+------------------------+ +-----------+-------------+--------------+------------------------+
| P | map-reply-P | 4 | RLOC-Probe Bit | | E | Map-Reply-E | 5 | Echo-Nonce Capable Bit |
| E | map-reply-E | 5 | Echo Nonce Capable Bit | +-----------+-------------+--------------+------------------------+
| S | map-reply-S | 6 | Security Bit | | S | Map-Reply-S | 6 | Security Bit |
+-----------+-------------+--------------+------------------------+ +-----------+-------------+--------------+------------------------+
LISP Map-Reply Header Bits Table 7: LISP Map-Reply Header Bits
Sub-Registry: Map-Register Header Bits [Section 5.6]: Subregistry: Map-Register Header Bits (Section 5.6):
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=3 |P|S|I| Reserved |E|T|a|R|M| Record Count | |Type=3 |P|S|I| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+----------------+--------------+----------------------+
+===========+================+==============+======================+
| Spec Name | IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | Description |
+===========+================+==============+======================+
| P | Map-Register-P | 4 | Proxy Map-Reply Bit |
+-----------+----------------+--------------+----------------------+ +-----------+----------------+--------------+----------------------+
| P | map-register-P | 4 | Proxy Map-Reply Bit | | S | Map-Register-S | 5 | LISP-SEC Capable Bit |
| S | map-register-S | 5 | LISP-SEC Capable Bit | +-----------+----------------+--------------+----------------------+
| I | map-register-I | 6 | xTR-ID present flag | | I | Map-Register-I | 6 | xTR-ID Present Bit |
+-----------+----------------+--------------+----------------------+ +-----------+----------------+--------------+----------------------+
LISP Map-Register Header Bits Table 8: LISP Map-Register Header Bits
Sub-Registry: Encapsulated Control Message (ECM) Header Bits Subregistry: Encapsulated Control Message (ECM) Header Bits
[Section 5.8]: (Section 5.8):
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=8 |S|D|E|M| Reserved | |Type=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+-----------+--------------+----------------------------+ +===========+===========+==============+============================+
| Spec Name | IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | Description |
+===========+===========+==============+============================+
| S | ECM-S | 4 | Security Bit |
+-----------+-----------+--------------+----------------------------+ +-----------+-----------+--------------+----------------------------+
| S | ecm-S | 4 | Security Bit | | D | ECM-D | 5 | LISP-DDT Bit |
| D | ecm-D | 5 | LISP-DDT Bit | +-----------+-----------+--------------+----------------------------+
| E | ecm-E | 6 | Forward to ETR Bit | | E | ECM-E | 6 | Forward to ETR Bit |
| M | ecm-M | 7 | Destined to Map-Server Bit | +-----------+-----------+--------------+----------------------------+
| M | ECM-M | 7 | Destined to Map- |
| | | | Server Bit |
+-----------+-----------+--------------+----------------------------+ +-----------+-----------+--------------+----------------------------+
LISP Encapsulated Control Message (ECM) Header Bits Table 9: LISP Encapsulated Control Message (ECM) Header Bits
Sub-Registry: EID-Record Header Bits [Section 5.4]: Subregistry: EID-Record Header Bits (Section 5.4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Count | EID mask-len | ACT |A| Reserved | | Locator Count | EID mask-len | ACT |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+--------------+--------------+-------------------+ +===========+==============+==============+===================+
| Spec Name | IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | Description |
+-----------+--------------+--------------+-------------------+ +===========+==============+==============+===================+
| A | eid-record-A | 19 | Authoritative Bit | | A | EID-Record-A | 19 | Authoritative Bit |
+-----------+--------------+--------------+-------------------+ +-----------+--------------+--------------+-------------------+
LISP EID-Record Header Bits Table 10: LISP EID-Record Header Bits
Sub-Registry: RLOC-Record Header Bits [Section 5.4]: Subregistry: RLOC-Record Header Bits (Section 5.4):
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Flags |L|p|R| Loc-AFI | | Unused Flags |L|p|R| Loc-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+---------------+--------------+----------------------+ +===========+===============+==============+======================+
| Spec Name | IANA Name | Bit Position | Description | | Spec Name | IANA Name | Bit Position | Description |
+===========+===============+==============+======================+
| L | RLOC-Record-L | 13 | Local RLOC Bit |
+-----------+---------------+--------------+----------------------+ +-----------+---------------+--------------+----------------------+
| L | rloc-record-L | 13 | Local RLOC Bit | | p | RLOC-Record-p | 14 | RLOC-Probe Reply Bit |
| p | rloc-record-p | 19 | RLOC-Probe Reply Bit | +-----------+---------------+--------------+----------------------+
| R | rloc-record-R | 19 | RLOC Reachable Bit | | R | RLOC-Record-R | 15 | RLOC Reachable Bit |
+-----------+---------------+--------------+----------------------+ +-----------+---------------+--------------+----------------------+
LISP RLOC-Record Header Bits Table 11: LISP RLOC-Record Header Bits
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-07 (work in progress), October 2020.
[I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-35 (work in progress),
September 2020.
[I-D.ietf-lisp-rfc8113bis]
Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", draft-ietf-lisp-
rfc8113bis-03 (work in progress), January 2019.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-21
(work in progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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,
skipping to change at page 48, line 24 skipping to change at line 2099
[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>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013,
<https://www.rfc-editor.org/info/rfc6833>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References [RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos, Ed., "The Locator/ID Separation Protocol
(LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
<https://www.rfc-editor.org/info/rfc9300>.
[AFI] "Address Family Identifier (AFIs)", ADDRESS FAMILY [RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
NUMBERS http://www.iana.org/assignments/address-family- Separation Protocol (LISP) Map-Versioning", RFC 9302,
numbers/address-family-numbers.xhtml?, Febuary 2007. DOI 10.17487/RFC9302, October 2022,
<https://www.rfc-editor.org/info/rfc9302>.
[GTP-3GPP] [RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
"General Packet Radio System (GPRS) Tunnelling Protocol "Locator/ID Separation Protocol Security (LISP-SEC)",
User Plane (GTPv1-U)", TS.29.281 RFC 9303, DOI 10.17487/RFC9303, October 2022,
https://portal.3gpp.org/desktopmodules/Specifications/ <https://www.rfc-editor.org/info/rfc9303>.
SpecificationDetails.aspx?specificationId=1699, January
2015.
[I-D.herbert-intarea-ila] [RFC9304] Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Herbert, T. and P. Lapukhov, "Identifier-locator Protocol (LISP): Shared Extension Message and IANA
addressing for IPv6", draft-herbert-intarea-ila-01 (work Registry for Packet Type Allocations", RFC 9304,
in progress), March 2018. DOI 10.17487/RFC9304, October 2022,
<https://www.rfc-editor.org/info/rfc9304>.
[I-D.ietf-lisp-ecdsa-auth] 13.2. Informative References
[AFN] IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/>.
[ECDSA-AUTH]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", draft-ietf-lisp-ecdsa- Authentication and Authorization", Work in Progress,
auth-04 (work in progress), September 2020. Internet-Draft, draft-ietf-lisp-ecdsa-auth-09, 11
September 2022, <https://datatracker.ietf.org/doc/html/
draft-ietf-lisp-ecdsa-auth-09>.
[I-D.ietf-lisp-eid-anonymity] [EID-ANONYMITY]
Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
EID Anonymity", draft-ietf-lisp-eid-anonymity-09 (work in EID Anonymity", Work in Progress, Internet-Draft, draft-
progress), October 2020. ietf-lisp-eid-anonymity-13, 11 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-anonymity-13>.
[I-D.ietf-lisp-eid-mobility] [EID-MOBILITY]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles, M., Ashtaputre, V., Maino, F., Moreno, V., and
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a D. Farinacci, "LISP L2/L3 EID Mobility Using a Unified
Unified Control Plane", draft-ietf-lisp-eid-mobility-06 Control Plane", Work in Progress, Internet-Draft, draft-
(work in progress), May 2020. ietf-lisp-eid-mobility-10, 10 July 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
eid-mobility-10>.
[I-D.ietf-lisp-gpe] [GTP-3GPP] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Protocol User Plane (GTPv1-U)", TS.29.281, June 2022,
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- <https://portal.3gpp.org/desktopmodules/Specifications/
gpe-19 (work in progress), July 2020. SpecificationDetails.aspx?specificationId=1699>.
[I-D.ietf-lisp-introduction] [INTAREA-ILA]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Herbert, T. and P. Lapukhov, "Identifier-locator
Introduction to the Locator/ID Separation Protocol addressing for IPv6", Work in Progress, Internet-Draft,
(LISP)", draft-ietf-lisp-introduction-13 (work in draft-herbert-intarea-ila-01, 5 March 2018,
progress), April 2015. <https://datatracker.ietf.org/doc/html/draft-herbert-
intarea-ila-01>.
[I-D.ietf-lisp-mn] [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, Internet-Draft, draft-
Mobile Node", draft-ietf-lisp-mn-08 (work in progress), ietf-lisp-mn-12, 24 July 2022,
August 2020. <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-
12>.
[I-D.ietf-lisp-pubsub] [LISP-PUBSUB]
Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A.,
Barkai, S., and M. Boucadair, "Publish/Subscribe Barkai, S., and M. Boucadair, "Publish/Subscribe
Functionality for LISP", draft-ietf-lisp-pubsub-06 (work Functionality for LISP", Work in Progress, Internet-Draft,
in progress), July 2020. draft-ietf-lisp-pubsub-09, 28 June 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
pubsub-09>.
[I-D.ietf-nvo3-vxlan-gpe] [NVO3-VXLAN-GPE]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed.,
Extension for VXLAN (VXLAN-GPE)", draft-ietf-nvo3-vxlan- "Generic Protocol Extension for VXLAN (VXLAN-GPE)", Work
gpe-10 (work in progress), July 2020. in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12,
22 September 2021, <https://datatracker.ietf.org/doc/html/
draft-ietf-nvo3-vxlan-gpe-12>.
[I-D.ietf-opsec-icmp-filtering] [OPSEC-ICMP-FILTER]
Gont, F., Gont, G., and C. Pignataro, "Recommendations for Gont, F., Gont, G., and C. Pignataro, "Recommendations for
filtering ICMP messages", draft-ietf-opsec-icmp- filtering ICMP messages", Work in Progress, Internet-
filtering-04 (work in progress), July 2013. Draft, draft-ietf-opsec-icmp-filtering-04, 3 July 2013,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
icmp-filtering-04>.
[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>.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, DOI 10.17487/RFC1071, Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
September 1988, <https://www.rfc-editor.org/info/rfc1071>. September 1988, <https://www.rfc-editor.org/info/rfc1071>.
[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>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>. <https://www.rfc-editor.org/info/rfc2890>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>. <https://www.rfc-editor.org/info/rfc4984>.
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[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>.
skipping to change at page 53, line 5 skipping to change at line 2290
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Appendix A. Acknowledgments [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9299] Cabellos, A. and D. Saucez, Ed., "An Architectural
Introduction to the Locator/ID Separation Protocol
(LISP)", RFC 9299, DOI 10.17487/RFC9299, October 2022,
<https://www.rfc-editor.org/info/rfc9299>.
[RFC9305] Maino, F., Ed., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "Locator/ID Separation Protocol (LISP) Generic
Protocol Extension", RFC 9305, DOI 10.17487/RFC9305,
October 2022, <https://www.rfc-editor.org/info/rfc9305>.
Acknowledgments
The original authors would like to thank Greg Schudel, Darrel Lewis, The original authors would like to thank Greg Schudel, Darrel Lewis,
John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper
Skriver, Fabio Maino, and members of the lisp@ietf.org mailing list Skriver, and members of the lisp@ietf.org mailing list for their
for their feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his extensive work and
thought about caching in Map-Resolvers. thought about caching in Map-Resolvers.
The current authors would like to give a sincere thank you to the The current authors would like to give a sincere thank you to the
people who help put LISP on standards track in the IETF. They people who help put LISP on the Standards Track in the IETF. They
include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino,
Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete
Resnick, Colin Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin Resnick, Colin Perkins, Mirja KΓΌhlewind, Francis Dupont, Benjamin
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The
contributions they offered greatly added to the security, scale, and contributions they offered greatly added to the security, scale, and
robustness of the LISP architecture and protocols. robustness of the LISP architecture and protocols.
Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6833bis-26
o Posted November 2019.
o Fixed the required (MUST implement) authentcation algorithms.
o Fixed a large set of minor comments and edits.
B.2. Changes to draft-ietf-lisp-rfc6833bis-25
o Posted June 2019.
o Added change requested by Mirja describing Record Count in an EID-
record.
o Fixed Requirements Notation section per Pete.
o Added KDF for shared-secret
o Specified several rate-limiters for control messages
B.3. Changes to draft-ietf-lisp-rfc6833bis-24
o Posted February 2019.
o Added suggested text from Albert that Benjamin Kaduk agreed with.
o Added suggested editorial comments from Alvaro's rewview.
o Ran document through IDnits. Fixed bugs found.
B.4. Changes to draft-ietf-lisp-rfc6833bis-23
o Posted December 2018.
o Added to Security Considerations section that deployments that
care about prefix over claiming should use LISP-SEC.
o Added to Security Considerations section that DTLS or LISP-crypto
be used for control-plane privacy.
o Make LISP-SEC a normative reference.
o Make it more clear where field descriptions are spec'ed when
referencing to the same fields in other packet types.
B.5. Changes to draft-ietf-lisp-rfc6833bis-22
o Posted week after IETF November 2018.
o No longer need to use IPSEC for replay attacks.
B.6. Changes to draft-ietf-lisp-rfc6833bis-21
o Posted early November 2018.
o Added I-bit back in because its necessary to use for Map-Register
replay attack scenarios. The Map-Server tracks the nonce per xTR-
ID to detect duplicate or replayed Map-Register messages.
B.7. Changes to draft-ietf-lisp-rfc6833bis-20
o Posted late October 2018.
o Changed description about "reserved" bits to state "reserved and
unassigned".
o Make it more clear how Map-Register nonce processing is performed
in an ETR and Map-Server.
B.8. Changes to draft-ietf-lisp-rfc6833bis-19
o Posted mid October 2018.
o Added Fabio text to the Security Considerations section.
B.9. Changes to draft-ietf-lisp-rfc6833bis-18
o Posted mid October 2018.
o Fixed comments from Eric after more email clarity.
B.10. Changes to draft-ietf-lisp-rfc6833bis-17
o Posted early October 2018.
o Changes to reflect comments from Sep 27th Telechat.
o Added all flag bit definitions as request for allocation in IANA
Considersations section.
o Added an applicability statement in section 1 to address security
concerns from Telechat.
o Moved m-bit description and IANA request to draft-ietf-lisp-mn.
o Moved I-bit description and IANA request to draft-ietf-lisp-
pubsub.
B.11. Changes to draft-ietf-lisp-rfc6833bis-16
o Posted Late-September 2018.
o Re-wrote Security Considerations section. Thanks Albert.
o Added Alvaro text to be more clear about IANA actions.
B.12. Changes to draft-ietf-lisp-rfc6833bis-15
o Posted mid-September 2018.
o Changes to reflect comments from Colin and Mirja.
B.13. Changes to draft-ietf-lisp-rfc6833bis-14
o Posted September 2018.
o Changes to reflect comments from Genart, RTGarea, and Secdir
reviews.
B.14. Changes to draft-ietf-lisp-rfc6833bis-13
o Posted August 2018.
o Final editorial changes before RFC submission for Proposed
Standard.
o Added section "Changes since RFC 6833" so implementators are
informed of any changes since the last RFC publication.
B.15. Changes to draft-ietf-lisp-rfc6833bis-12
o Posted late July 2018.
o Moved RFC6830bis and RFC6834bis to Normative References.
B.16. Changes to draft-ietf-lisp-rfc6833bis-11
o Posted July 2018.
o Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again.
B.17. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format
description section.
o Say more about when the new Drop actions should be sent.
B.18. Changes to draft-ietf-lisp-rfc6833bis-09
o Posted March IETF week 2018.
o Fixed editorial comments submitted by document shepherd Luigi
Iannone.
B.19. Changes to draft-ietf-lisp-rfc6833bis-08
o Posted March 2018.
o Added RLOC-probing algorithm.
o Added Solicit-Map Request algorithm.
o Added several mechanisms (from 6830bis) regarding Routing Locator
Reachability.
o Added port 4342 to IANA Considerations section.
B.20. 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.21. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017.
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
introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes.
o Updated references for individual submissions that became working
group documents.
o Updated references for working group documents that became RFCs.
B.22. Changes to draft-ietf-lisp-rfc6833bis-05
o Posted May 2017.
o Update IANA Considerations section based on new requests from this
document and changes from what was requested in [RFC6830].
B.23. Changes to draft-ietf-lisp-rfc6833bis-04
o Posted May 2017.
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
and a 8-bit Algorithm-ID field.
o Move the Control-Plane codepoints from the IANA Considerations
section of RFC6830bis to the IANA Considerations section of this
document.
o In the "LISP Control Packet Type Allocations" section, indicate
how message Types are IANA allocated and how experimental RFC8113
sub-types should be requested.
B.24. Changes to draft-ietf-lisp-rfc6833bis-03
o Posted April 2017.
o Add types 9-14 and specify they are not assigned.
o Add the "LISP Shared Extension Message" type and point to RFC8113.
B.25. Changes to draft-ietf-lisp-rfc6833bis-02
o Posted April 2017.
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
P-bit set supporting mapping updates and RLOC-probing. Indicating
that other Data-Planes can use the same mechanisms or their own
defined mechanisms to achieve the same functionality.
B.26. Changes to draft-ietf-lisp-rfc6833bis-01
o Posted March 2017.
o Include references to new RFCs published.
o Remove references to self.
o Change references from RFC6830 to RFC6830bis.
o Add two new action/reasons to a Map-Reply has posted to the LISP
WG mailing list.
o In intro section, add refernece to I-D.ietf-lisp-introduction.
o Removed Open Issues section and references to "experimental".
B.27. Changes to draft-ietf-lisp-rfc6833bis-00
o Posted December 2016.
o Created working group document from draft-farinacci-lisp
-rfc6833-00 individual submission. No other changes made.
B.28. Changes to draft-farinacci-lisp-rfc6833bis-00
o Posted November 2016.
o This is the initial draft to turn RFC 6833 into RFC 6833bis.
o The document name has changed from the "Locator/ID Separation
Protocol (LISP) Map-Server Interface" to the "Locator/ID
Separation Protocol (LISP) Control-Plane".
o The fundamental change was to move the Control-Plane messages from
RFC 6830 to this document in an effort so any IETF developed or
industry created Data-Plane could use the LISP mapping system and
Control-Plane.
o Update Control-Plane messages to incorporate what has been
implemented in products during the early phase of LISP development
but wasn't able to make it into RFC6830 and RFC6833 to make the
Experimental RFC deadline.
o Indicate there may be nodes in the mapping system that are not MRs
or MSs, that is a ALT-node or a DDT-node.
o Include LISP-DDT in Map-Resolver section and explain how they
maintain a referral-cache.
o Removed open issue about additional state in Map-Servers. With
[RFC8111], Map-Servers have the same registration state and can
give Map-Resolvers complete information in ms-ack Map-Referral
messages.
o Make reference to the LISP Threats Analysis RFC [RFC7835].
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
lispers.net lispers.net
San Jose, CA
EMail: farinacci@gmail.com United States of America
Email: farinacci@gmail.com
Fabio Maino Fabio Maino
Cisco Systems Cisco Systems
San Jose, CA
EMail: fmaino@cisco.com United States of America
Email: fmaino@cisco.com
Vince Fuller Vince Fuller
vaf.net Internet Consulting vaf.net Internet Consulting
Email: vince.fuller@gmail.com
EMail: vaf@vaf.net Albert Cabellos (editor)
Universitat Politecnica de Catalunya
Albert Cabellos c/ Jordi Girona s/n
UPC/BarcelonaTech 08034 Barcelona
Campus Nord, C. Jordi Girona 1-3
Barcelona, Catalunya
Spain Spain
Email: acabello@ac.upc.edu
EMail: acabello@ac.upc.edu
 End of changes. 296 change blocks. 
1242 lines changed or deleted 954 lines changed or added

This html diff was produced by rfcdiff 1.48.