draft-ietf-lisp-rfc6833bis-16.txt   draft-ietf-lisp-rfc6833bis-17.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Obsoletes: 6833 (if approved) Cisco Systems Obsoletes: 6833 (if approved) Cisco Systems
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track A. Cabellos (Ed.)
Expires: March 30, 2019 UPC/BarcelonaTech Expires: April 6, 2019 UPC/BarcelonaTech
September 26, 2018 October 3, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-16 draft-ietf-lisp-rfc6833bis-17
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this Control-Plane service interface and communicating with By using this Control-Plane service interface and communicating with
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, which facilitates modularity with different
database designs. Since these devices implement the "edge" of the database designs. Since these devices implement the "edge" of the
LISP Control-Plane infrastructure, connect directly to LISP-capable LISP Control-Plane infrastructure, connecting EID addressable nodes
Internet end sites, and comprising the bulk of LISP-speaking devices, of a LISP site, their implementation and operational complexity
reducing their implementation and operational complexity should also reduces the overall cost and effort of deploying LISP.
reduce the overall cost and effort of deploying LISP.
This document obsoletes RFC 6830 and 6833. This document obsoletes RFC 6830 and 6833.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 30, 2019. This Internet-Draft will expire on April 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 10
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 11
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 16
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 23
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 26
5.8. Encapsulated Control Message Format . . . . . . . . . . . 27 5.8. Encapsulated Control Message Format . . . . . . . . . . . 28
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 30
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 30 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 31
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33
8. Interactions with Other LISP Components . . . . . . . . . . . 33 8. Interactions with Other LISP Components . . . . . . . . . . . 34
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 34 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 35
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 36 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 37
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 38
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 37 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 40 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 41
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 40 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 41
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 41
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 41 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 42
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 42
11.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
12.1. Normative References . . . . . . . . . . . . . . . . . . 41 12.1. Normative References . . . . . . . . . . . . . . . . . . 46
12.2. Informative References . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 47 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51
B.1. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 47 B.1. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 51
B.2. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 47 B.2. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 51
B.3. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 47 B.3. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 51
B.4. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 47 B.4. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 52
B.5. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 48 B.5. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 52
B.6. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 48 B.6. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 52
B.7. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 48 B.7. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 52
B.8. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 48 B.8. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 52
B.9. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 48 B.9. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 52
B.10. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 48 B.10. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 53
B.11. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 49 B.11. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 53
B.12. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 49 B.12. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 53
B.13. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 49 B.13. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 54
B.14. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 50 B.14. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 54
B.15. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 50 B.15. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 54
B.16. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 50 B.16. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 54
B.17. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 50 B.17. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 55
B.18. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 51 B.18. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 B.19. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see
also [I-D.ietf-lisp-introduction]) specifies an architecture and also [I-D.ietf-lisp-introduction]) specifies an architecture and
mechanism for dynamic tunneling by logically separating the addresses mechanism for dynamic tunneling by logically separating the addresses
currently used by IP in two separate name spaces: Endpoint IDs currently used by IP in two separate name spaces: Endpoint IDs
(EIDs), used within sites; and Routing Locators (RLOCs), used on the (EIDs), used within sites; and Routing Locators (RLOCs), used on the
transit networks that make up the Internet infrastructure. To transit networks that make up the Internet infrastructure. To
achieve this separation, LISP defines protocol mechanisms for mapping achieve this separation, LISP defines protocol mechanisms for mapping
from EIDs to RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the existence of a
database to store and propagate those mappings globally. Several database to store and propagate those mappings across mapping system
such databases have been proposed; among them are the Content nodes. Several such databases have been proposed; among them are the
distribution Overlay Network Service for LISP-NERD (a Not-so-novel Content distribution Overlay Network Service for LISP-NERD (a Not-so-
EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical
(LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree
[RFC8111]. (LISP-DDT) [RFC8111].
The LISP Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two new types of LISP-speaking
devices: the Map-Resolver, which accepts Map-Requests from an Ingress devices: the Map-Resolver, which accepts Map-Requests from an Ingress
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a
mapping database; and the Map-Server, which learns authoritative EID- mapping database; and the Map-Server, which learns authoritative EID-
to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes
them in a database. them in a database.
This LISP Control-Plane Mapping Service can be used by many different This LISP Control-Plane Mapping Service can be used by many different
encapsulation-based or translation-based Data-Planes which include encapsulation-based or translation-based Data-Planes which include
skipping to change at page 4, line 22 skipping to change at page 4, line 24
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 [RFC1035] servers; 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 this document doesn't assume any particular database mapping
infrastructure to illustrate certain aspects of Map-Server and Map- infrastructure to illustrate certain aspects of Map-Server and Map-
Resolver operation, the Mapping Service interface can (and likely Resolver operation. The Mapping Service interface can (and likely
will) be used by ITRs and ETRs to access other mapping database will) be used by ITRs and ETRs to access other mapping database
systems as the LISP infrastructure evolves. systems as the LISP infrastructure evolves.
The LISP Mapping Service is an important component of the LISP LISP is not intended to address problems of connectivity and scaling
toolset. Issues and concerns about the deployment of LISP for on behalf of arbitrary communicating parties. Relevant situations
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], are described in the scoping section of the introduction to
[RFC7215], and [I-D.rodrigueznatal-lisp-oam]. [I-D.ietf-lisp-rfc6830bis].
This document obsoletes RFC 6830 and 6833. This document obsoletes RFC 6830 and 6833.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] and "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Definition of Terms 3. Definition of Terms
Map-Server: A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that learns of EID-
Prefix mapping entries from an ETR, via the registration mechanism Prefix mapping entries from an ETR, via the registration mechanism
described below, or some other authoritative source if one exists. described below, or some other authoritative source if one exists.
A Map-Server publishes these EID-Prefixes in a mapping database. A Map-Server publishes these EID-Prefixes in a mapping database.
Map-Request: A LISP Map-Request is a Control-Plane message to query Map-Request: A LISP Map-Request is a Control-Plane message to query
the mapping system to resolve an EID. A LISP Map-Request can also the mapping system to resolve an EID. A LISP Map-Request can also
skipping to change at page 9, line 38 skipping to change at page 10, line 38
recommended to use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message Type described
in [RFC8113]. in [RFC8113].
All LISP Control-Plane messages use Address Family Identifiers (AFI) All LISP Control-Plane messages use Address Family Identifiers (AFI)
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
encode either fixed or variable length addresses. This includes encode either fixed or variable length addresses. This includes
explicit fields in each control message or part of EID-records or explicit fields in each control message or part of EID-records or
RLOC-records in commonly formatted messages. RLOC-records in commonly formatted messages.
The LISP control-plane describes how other data-planes can encode The LISP control-plane describes how other data-planes can encode
messages to support the SMR and RLOC-probing procedures. messages to support the Soliciting of Map-Requests as well as RLOC-
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|m|I| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
skipping to change at page 10, line 38 skipping to change at page 11, line 38
| 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, which is set to 0 for UDP-based Map- A: This is an authoritative bit, which is set to 0 for UDP-based Map-
Requests sent by an ITR. It is set to 1 when an ITR wants the Requests sent by an ITR. It is set to 1 when an ITR wants the
destination site to return the Map-Reply rather than the mapping destination site to return the Map-Reply rather than the mapping
database system. database system returning a Map-Reply.
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 SHOULD P: This is the probe-bit, which indicates that a Map-Request SHOULD
be treated as a Locator reachability probe. The receiver SHOULD be treated as a Locator reachability probe. The receiver SHOULD
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 Section 7.1
for more details. for more details. This RLOC-probe Map-Request MUST not be sent to
the mapping system. If a Map-Resolver or Map-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 Solicit-Map-
Request (SMRs) Section 6.1 for details. Request (SMRs) 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 PITR bit. This bit is set to 1 when a PITR sends a
Map-Request. Map-Request.
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.
m: This is the LISP mobile-node m-bit. This bit is set by xTRs that R: This reserved bit MUST be set to 0 on transmit and MUST be ignored
operate as a mobile node as defined in [I-D.ietf-lisp-mn]. This on receipt.
bit can be ignored if an implementation does not support
[I-D.ietf-lisp-mn].
I: This is the xTR-ID bit. When this bit is set, what is appended to
the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage
procedures in [I-D.ietf-lisp-pubsub] for details. This bit can be
ignored if an implementation does not support
[I-D.ietf-lisp-pubsub].
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 to
tell other xTRs in the same site that it is part of the RLOC-set tell other xTRs in the same site that it is part of the RLOC-set
for the LISP site. The L-bit is set to 1 when the RLOC is the 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
skipping to change at page 12, line 4 skipping to change at page 12, line 47
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.
Support for processing multiple EIDs in a single Map-Request Support for processing multiple EIDs in a single Map-Request
message will be specified in a future version of the protocol. message will be specified in a future version of the protocol.
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
security of the LISP mapping protocol critically depends on the security of the LISP mapping protocol critically depends on the
strength of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. The nonce MUST
SHOULD be generated by a properly seeded pseudo-random (or strong be generated by a properly seeded pseudo-random (or strong random)
random) source. See [RFC4086] for advice on generating security- source. See [RFC4086] for advice on generating security-sensitive
sensitive random data. random data.
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 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'
skipping to change at page 13, line 51 skipping to change at page 14, line 49
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-
Request for the same EID-Prefix be sent no more than once per second. Request for the same EID-Prefix be sent no more than once per second.
However, recommendations from [RFC8085] SHOULD be considered. However, recommendations from [RFC8085] SHOULD be considered.
An ITR that is configured with mapping database information (i.e., it An ITR that is configured with mapping database information (i.e., it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the Map-Cache, it MAY originate a "verifying not have this mapping in the Map-Cache, it MAY originate a "verifying
Map-Request", addressed to the map-requesting ITR and the ETR MAY add Map-Request", addressed to the map-requesting ITR and the ETR MAY add
a Map-Cache entry. If the ETR has a Map-Cache entry that matches the a Map-Cache entry. If the ETR (when it is an xTR co-located as an
"piggybacked" EID and the RLOC is in the Locator-Set for the entry, ITR) has a Map-Cache entry that matches the "piggybacked" EID and the
then it MAY send the "verifying Map-Request" directly to the RLOC is in the Locator-Set for the entry, then it MAY send the
originating Map-Request source. If the RLOC is not in the Locator- "verifying Map-Request" directly to the originating Map-Request
Set, then the ETR MUST send the "verifying Map-Request" to the source. If the RLOC is not in the Locator-Set, then the ETR MUST
"piggybacked" EID. Doing this forces the "verifying Map-Request" to send the "verifying Map-Request" to the "piggybacked" EID. Doing
go through the mapping database system to reach the authoritative this forces the "verifying Map-Request" to go through the mapping
source of information about that EID, guarding against RLOC-spoofing database system to reach the authoritative source of information
in the "piggybacked" mapping data. about that EID, guarding against RLOC-spoofing in the "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 19 skipping to change at page 17, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This field MUST be set to 0 on transmit and MUST be Reserved: This field MUST be set to 0 on transmit and MUST be
ignored on receipt. 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. Count.
Nonce: This is a 24-bit value set in a Data-Probe Nonce: This 64-bit value from the Map-Request is echoed in this
[I-D.ietf-lisp-rfc6830bis] or a 64-bit value from the Map-Request 'Nonce' field of the Map-Reply.
is echoed in this 'Nonce' field of the Map-Reply. When a 24-bit
value is supplied, it resides in the low-order 64 bits of the
'Nonce' field.
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 will store the mapping. If the TTL is 0, the entry MUST be Reply will 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. A Locator Locator Count: This is the number of Locator entries. A Locator
entry comprises what is labeled above as 'Loc'. The Locator count entry comprises what is labeled above as 'Loc'. The Locator count
can be 0, indicating that there are no Locators for the EID- can be 0, indicating that there are no Locators for the EID-
Prefix. Prefix.
skipping to change at page 17, line 23 skipping to change at page 18, line 19
(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/Authentication-Failure: A packet that matches this Map-
Cache entry is dropped. The reason for the Drop action is Cache entry is dropped. The reason for the Drop action is
that a Map-Request for the target-EID fails an authentication that a Map-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, when sent, is always set to 1 by an ETR. A: The Authoritative bit, when set to 1, is always set to 1 by an
When a Map-Server is proxy Map-Replying for a LISP site, the ETR. When a Map-Server is proxy Map-Replying for a LISP site, the
Authoritative bit is set to 0. This indicates to requesting ITRs Authoritative bit is set to 0. This indicates to requesting ITRs
that the Map-Reply was not originated by a LISP node managed at that the Map-Reply was not originated by a LISP node managed at
the site that owns the EID-Prefix. the site that owns the EID-Prefix.
Map-Version Number: When this 12-bit value is non-zero, the Map- Map-Version Number: When this 12-bit value is non-zero, the Map-
Reply sender is informing the ITR what the version number is for Reply sender is informing the ITR what the version number is for
the EID record contained in the Map-Reply. The ETR can allocate the EID record contained in the Map-Reply. The ETR can allocate
this number internally but MUST coordinate this value with other this number internally but MUST coordinate this value with other
ETRs for the site. When this value is 0, there is no versioning ETRs for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can be included in
skipping to change at page 18, line 44 skipping to change at page 19, line 40
Locators in this Locator-Set. 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 the
locator address for which this bit is set is the one being RLOC- locator address for which this bit is set is the one being RLOC-
probed and may be different from the source address of the Map- probed and may be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular Locator MUST use this Reply. An ITR that RLOC-probes a particular Locator MUST use this
Locator for retrieving the data structure used to store the fact Locator for retrieving the data structure used to store the fact
that the Locator is reachable. The p-bit is set for a single that the Locator is reachable. The p-bit is set for a single
Locator in the same Locator-Set. If an implementation sets more Locator in the same Locator-Set. If an implementation sets more
than one p-bit erroneously, the receiver of the Map-Reply MUST than one p-bit erroneously, the receiver of the Map-Reply MUST
select the first Locator. The p-bit MUST NOT be set for Locator- select the first set p-bit Locator. The p-bit MUST NOT be set for
Set records sent in Map-Request and Map-Register messages. 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. See also EID-Reachability from the receiver's point of view. See also EID-Reachability
Section 7.1 for another way the R-bit may be used. Section 7.1 for another way the R-bit may be used.
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc-
AFI' field) assigned to an ETR. Note that the destination RLOC AFI' field) assigned to an ETR and used by an ITR as a destination
address MAY be an anycast address. A source RLOC can be an RLOC address in the outer header of a LISP encapsualted packet.
anycast address as well. The source or destination RLOC MUST NOT
be the broadcast address (255.255.255.255 or any subnet broadcast Note that the destination RLOC address of a LISP encapsulated
address known to the router) and MUST NOT be a link-local packet MAY be an anycast address. A source RLOC of a LISP
multicast address. The source RLOC MUST NOT be a multicast encapsulated packet can be an anycast address as well. The source
address. The destination RLOC SHOULD be a multicast address if it or destination RLOC MUST NOT be the broadcast address
is being mapped from a multicast destination EID. (255.255.255.255 or any subnet broadcast address known to the
router) and MUST NOT be a link-local multicast address. The
source RLOC MUST NOT be a multicast address. The destination RLOC
SHOULD be a multicast address if it is being mapped from a
multicast destination EID.
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 prefix length that is less A Map-Reply returns an EID-Prefix with a prefix length that is less
than or equal to the EID being requested. The EID being requested is than or equal to the EID being requested. The EID being requested is
either from the destination field of an IP header of a Data-Probe or either from the destination field of an IP header of a Data-Probe or
the EID record of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the Map-Reply are
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
skipping to change at page 20, line 11 skipping to change at page 21, line 11
2001:db8:1::/24 2001:db8:1::/24
2001:db8:1:1::/32 2001:db8:1:1::/32
2001:db8:1:2::/32 2001:db8:1:2::/32
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::/32. 2001:db8:1:1::/32.
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::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32,
filling out the /24 with more-specifics that exist in the mapping filling out the /24 with more-specifics that exist in the mapping
system. 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 that in the second example above
2001:db8::/16 was not returned for requesting EID 2001:db8:1:5::5) 2001:db8::/16 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 Time to Live
value so they can all time out at the same time. When a more- value so they can all time out at the same time. When a more-
specific EID-Prefix is received later, its Time to Live value in the specific EID-Prefix is received later, its Time to Live value in the
skipping to change at page 21, line 8 skipping to change at page 22, line 8
message. The Locator-Set MUST be sorted in order of ascending IP message. The Locator-Set MUST be sorted in order of ascending IP
address where an IPv4 locator address is considered numerically 'less address where an IPv4 locator address is considered numerically 'less
than' an IPv6 locator address. than' an IPv6 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 locator address from one of the address families it
supports. For Data-Probes, the destination address of the Map-Reply supports. For Data-Probes, the destination address of the Map-Reply
is copied from the source address of the Data-Probe message that is is copied from the source address of the Data-Probe message that is
invoking the reply. The source address of the Map-Reply is one of invoking the reply. The source address of the Map-Reply is one of
the local IP addresses chosen to allow Unicast Reverse Path the local IP addresses chosen, to allow Unicast Reverse Path
Forwarding (uRPF) checks to succeed in the upstream service provider. Forwarding (uRPF) checks to succeed in the upstream service provider.
The destination port of a Map-Reply message is copied from the source The destination port of a Map-Reply message is copied from the source
port of the Map-Request or Data-Probe, and the source port of the port of the Map-Request or Data-Probe, and the source port of the
Map-Reply message is set to the well-known UDP port 4342. Map-Reply message is set to the well-known UDP port 4342.
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 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|m|M| Record Count | |Type=3 |P|S|R| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Algorithm ID | Authentication Data Length | | Key ID | Algorithm ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
skipping to change at page 23, line 5 skipping to change at page 24, line 5
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a
Map-Register message requesting the Map-Server to proxy a Map- Map-Register message requesting the Map-Server to proxy a Map-
Reply. The Map-Server will send non-authoritative Map-Replies on Reply. The Map-Server will send non-authoritative Map-Replies on
behalf of the ETR. 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. [I-D.ietf-lisp-sec] are supported.
I: This is the xTR-ID bit. When this bit is set, what is appended to
the Map-Register is a 128-bit xTR router-ID and then a 64-bit
site-ID. See LISP NAT-Traversal procedures in
[I-D.ermagan-lisp-nat-traversal] for details.
Reserved: This field MUST be set to 0 on transmit and MUST be Reserved: This field MUST be set to 0 on transmit and MUST be
ignored on receipt. 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 First-
Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify Hop-Router (FHR) which discovers a dynamic-EID. This EID-notify
based Map-Register is sent by the FHR to the same site xTR that based Map-Register is sent by the FHR to the same site xTR that
propogates the Map-Register to the mapping system. The site xTR propogates the Map-Register to the mapping system. The site xTR
keeps state to later Map-Notify the FHR after the EID has moves keeps state to later Map-Notify the FHR after the EID has moves
away. See [I-D.ietf-lisp-eid-mobility] for a detailed use-case. away. See [I-D.ietf-lisp-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 wants
the Map-Server to time out registrations based on the value in the the Map-Server to time out registrations based on the value in the
"Record TTL" field of this message. "Record TTL" field of this message. Otherwise, the default
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 to
merge RLOC-records from different xTRs registering the same EID- merge RLOC-records from different xTRs registering the same EID-
record. See signal-free multicast [RFC8378] for one use case record. See signal-free multicast [RFC8378] for one use case
example. example.
m: This is the mobile-node bit. When set to 1, the registering xTR R: This reserved bit MUST be set to 0 on transmit and MUST be ignored
supports the procedures in [I-D.ietf-lisp-mn]. This bit can be on receipt.
ignored if an implementation does not support [I-D.ietf-lisp-mn]
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
skipping to change at page 24, line 19 skipping to change at page 25, line 13
(MAC) algorithm value used for the authentication function. See (MAC) algorithm value used for the authentication function. See
Algorithm ID Numbers in the Section 11.5 for codepoint Algorithm ID Numbers in the Section 11.5 for codepoint
assignments. assignments.
Authentication Data Length: This is the length in octets of the Authentication Data Length: This is the length in octets of the
'Authentication Data' field that follows this field. The length 'Authentication Data' field that follows this field. The length
of the 'Authentication Data' field is dependent on the MAC of the 'Authentication Data' field is dependent on the MAC
algorithm used. The length field allows a device that doesn't algorithm used. The length field allows a device that doesn't
know the MAC algorithm to correctly parse the packet. know the MAC algorithm to correctly parse the packet.
Authentication Data: This is the message digest used from the output Authentication Data: This is the output of the MAC algorithm. The
of the MAC algorithm. The entire Map-Register payload is entire Map-Register payload (from and including the LISP message
type field through the end of the last RLOC record) is
authenticated with this field preset to 0. After the MAC is authenticated with this field preset to 0. After the MAC is
computed, it is placed in this field. Implementations of this computed, it is placed in this field. Implementations of this
specification MUST include support for HMAC-SHA-1-96 [RFC2404], specification MUST include support for either HMAC-SHA-1-96
and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. [RFC2404] and HMAC-SHA-256-128 [RFC4868] where the latter is
RECOMMENDED.
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 EID-
record description in Section 5.4. record description in Section 5.4.
5.7. Map-Notify/Map-Notify-Ack Message Format 5.7. Map-Notify/Map-Notify-Ack Message Format
This section specifies the encoding format for the Map-Notify and This section specifies the encoding format for the Map-Notify and
Map-Notify-Ack messages. The messages are sent inside a UDP packet Map-Notify-Ack messages. The messages are sent inside a UDP packet
with source and destination UDP ports equal to 4342. with source and destination UDP ports equal to 4342.
skipping to change at page 28, line 38 skipping to change at page 29, line 38
UDP: The inner UDP header, where the port assignments depend on the UDP: The inner UDP header, where the port assignments depend on the
control packet being encapsulated. When the control packet is control packet being encapsulated. When the control packet is
a Map-Request or Map-Register, the source port is selected by a Map-Request or Map-Register, the source port is selected by
the ITR/PITR and the destination port is 4342. When the the ITR/PITR and the destination port is 4342. When the
control packet is a Map-Reply, the source port is 4342 and the control packet is a Map-Reply, the source port is 4342 and the
destination port is assigned from the source port of the destination port is assigned from the source port of the
invoking Map-Request. Port number 4341 MUST NOT be assigned to invoking Map-Request. Port number 4341 MUST NOT be assigned to
either port. The checksum field MUST be non-zero. either port. The checksum field MUST be non-zero.
LCM: The format is one of the control message formats described in LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages are this section. Map-Request messages are allowed to be Control-
allowed to be Control-Plane (ECM) encapsulated. In the future, Plane (ECM) encapsulated. When Map-Requests are sent for RLOC-
PIM Join/Prune messages [RFC6831] might be allowed. Probing purposes (i.e. the probe-bit is set), they MUST NOT be
Encapsulating other types of LISP control messages is for sent inside Encapsulated Control Messages. PIM Join/Prune
further study. When Map-Requests are sent for RLOC-Probing messages [RFC6831] are also allowed to be Control-Plane (ECM)
purposes (i.e., the probe-bit is set), they MUST NOT be sent encapsulated.
inside Encapsulated Control Messages.
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 a
mechanism is required to inform ITRs/PITRs that are using such 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 mechanism to update mappings
[I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map
skipping to change at page 29, line 25 skipping to change at page 30, line 25
Control-Plane mechanism based on the Publish/subscribe paradigm is Control-Plane mechanism based on the Publish/subscribe paradigm is
specified in [I-D.ietf-lisp-pubsub]. specified in [I-D.ietf-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 the ETRs don't keep track of remote ITRs that have cached their Since ETRs are not required to keep track of remote ITRs that have
mappings, they do not know which ITRs need to have their mappings cached their mappings, they do not know which ITRs need to have their
updated. As a result, an ETR will solicit Map-Requests (called an mappings updated. As a result, an ETR will solicit Map-Requests
SMR message) to those sites to which it has been sending encapsulated (called an SMR message) to those sites to which it has been sending
data for the last minute. In particular, an ETR will send an SMR to LISP encapsulated data packets for the last minute. In particular,
an ITR to which it has recently sent encapsulated data. This can an ETR will send an SMR to an ITR to which it has recently sent
only occur when both ITR and ETR functionality reside in the same encapsulated data. This can only occur when both ITR and ETR
router. functionality reside in the same router.
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 when they receive an SMR message. or PITR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder MUST rate-limit Both the SMR sender and the Map-Request responder MUST rate-limit
these messages. Rate-limiting can be implemented as a global rate- these messages. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination. limiter or one rate-limiter per SMR destination.
The following procedure shows how an SMR exchange occurs when a site The following procedure shows how an SMR exchange occurs when a site
is doing Locator-Set compaction for an EID-to-RLOC mapping: is doing Locator-Set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site 1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each Locator begin to send Map-Requests with the SMR bit set for each Locator
in each Map-Cache entry the ETR caches. in each Map-Cache entry the ETR (when it is an xTR co-located as
an ITR) caches.
2. A remote ITR that receives the SMR message will schedule sending 2. A remote ITR that receives the SMR message will schedule sending
a Map-Request message to the source locator address of the SMR a Map-Request message to the source locator address of the SMR
message or to the mapping database system. A newly allocated message or to the mapping database system. A newly allocated
random nonce is selected, and the EID-Prefix used is the one random nonce is selected, and the EID-Prefix used is the one
copied from the SMR message. If the source Locator is the only copied from the SMR message. If the source Locator is the only
Locator in the cached Locator-Set, the remote ITR SHOULD send a Locator in the cached Locator-Set, the remote ITR SHOULD send a
Map-Request to the database mapping system just in case the Map-Request to the database mapping system just in case the
single Locator has changed and may no longer be reachable to single Locator has changed and may no longer be reachable to
accept the Map-Request. accept the Map-Request.
3. The remote ITR MUST rate-limit the Map-Request until it gets a 3. The remote ITR MUST rate-limit the Map-Request until it gets a
Map-Reply while continuing to use the cached mapping. When Map-Reply while continuing to use the cached mapping. When
Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used,
an SMR sender can detect if an ITR is using the most up-to-date an SMR sender can detect if an ITR is using the most up-to-date
database mapping. database mapping.
4. The ETRs at the site with the changed mapping will reply to the 4. The site sending SMR messages will reply to the Map-Request with
Map-Request with a Map-Reply message that has a nonce from the a Map-Reply message that has a nonce from the SMR-invoked Map-
SMR-invoked Map-Request. The Map-Reply messages MUST be rate- Request. The Map-Reply messages MUST be rate-limited according
limited according to procedures in [RFC8085]. This is important to procedures in [RFC8085]. This is important to avoid Map-Reply
to avoid Map-Reply implosion. implosion.
5. The ETRs at the site with the changed mapping record the fact 5. The ETRs at the site with the changed mapping record the fact
that the site that sent the Map-Request has received the new that the site that sent the Map-Request has received the new
mapping data in the Map-Cache entry for the remote site so the mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops sending SMR
messages. messages.
For security reasons, an ITR MUST NOT process unsolicited Map- For security reasons, an ITR MUST NOT process unsolicited Map-
Replies. To avoid Map-Cache entry corruption by a third party, a Replies. To avoid Map-Cache entry corruption by a third party, a
skipping to change at page 32, line 39 skipping to change at page 33, line 43
an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or to
the mapping database system as one would when soliciting mapping the mapping database system as one would when soliciting mapping
data. The EID record encoded in the Map-Request is the EID-Prefix of data. The EID record encoded in the Map-Request is the EID-Prefix of
the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a the Map-Cache entry cached by the ITR or PITR. The ITR MAY include a
mapping data record for its own database mapping information that mapping data record for its own database mapping information that
contains the local EID-Prefixes and RLOCs for its site. RLOC-probes contains the local EID-Prefixes and RLOCs for its site. RLOC-probes
are sent periodically using a jittered timer interval. are sent periodically using a jittered timer interval.
When an ETR receives a Map-Request message with the probe-bit set, it When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set according to the procedure described in the Map-Reply is set to the IP address of the outgoing interface the
[I-D.ietf-lisp-rfc6830bis]. The Map-Reply SHOULD contain mapping Map-Reply destination address routes to. The Map-Reply SHOULD
data for the EID-Prefix contained in the Map-Request. This provides contain mapping data for the EID-Prefix contained in the Map-Request.
the opportunity for the ITR or PITR that sent the RLOC-probe to get This provides the opportunity for the ITR or PITR that sent the RLOC-
mapping updates if there were changes to the ETR's database mapping probe to get mapping updates if there were changes to the ETR's
entries. database mapping entries.
There are advantages and disadvantages of RLOC-Probing. The greatest 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
skipping to change at page 37, line 45 skipping to change at page 38, line 47
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 which 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, xTR-IDs, or distinct authentication use their unique RLOC addresses or distinct authentication keys to
keys to identify security associations with the Map-Servers. identify security associations with the Map-Servers.
9. Security Considerations 9. Security Considerations
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.
skipping to change at page 38, line 29 skipping to change at page 39, line 35
overclaiming' attacks on the Map-Request/Map-Reply exchange. In overclaiming' attacks on the Map-Request/Map-Reply exchange. In
addition and while beyond the scope of securing an individual Map- addition and while beyond the scope of securing an individual Map-
Server or Map-Resolver, it should be noted that LISP-SEC can be Server or Map-Resolver, it should be noted that LISP-SEC can be
complemented by additional security mechanisms defined by the Mapping complemented by additional security mechanisms defined by the Mapping
System Infrastructure. For instance, BGP-based LISP-ALT [RFC6836] System Infrastructure. For instance, BGP-based LISP-ALT [RFC6836]
can take advantage of standards work on adding security to BGP while can take advantage of standards work on adding security to BGP while
LISP-DDT [RFC8111] defines its own additional security mechanisms. LISP-DDT [RFC8111] defines its own 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 hash of the entire message using a pair-wise shared key. that is a MAC of the entire message using a pair-wise shared key. An
An implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD
SHOULD support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128
to 128 bits). The Map-Register message is vulnerable to replay bits). The Map-Register message is vulnerable to replay attacks by a
attacks by a man-in-the-middle. Deployments that are concerned with man-in-the-middle. Deployments that are concerned with active man-
active man-in-the-middle attacks to the Map-Register message SHOULD in-the-middle attacks to the Map-Register message SHOULD use a
use a transport-level integrity and anti-reply protection mechanism transport-level integrity and anti-reply protection mechanism such as
such as IPSEC [RFC6071]. In addition, a compromised ETR can IPSEC [RFC6071]. In addition, a compromised ETR can overclaim the
overclaim the prefix it owns and successfully register it on its prefix it owns and successfully register it on its corresponding Map-
corresponding Map-Server. To mitigate this and as noted in Server. To mitigate this and as noted in Section 8.2, a Map-Server
Section 8.2, a Map-Server SHOULD verify that all EID-Prefixes SHOULD verify that all EID-Prefixes registered by an ETR match the
registered by an ETR match the configuration stored on the Map- configuration stored on the Map-Server.
Server.
A complete LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in [RFC7835].
Please refer to it for more detailed security related details. Please refer to it for more detailed security related details.
10. Changes since RFC 6833 10. Changes since RFC 6833
For implementation considerations, the following changes have been For implementation considerations, the following changes have been
made to this document since RFC 6833 was published: made to this document since RFC 6833 was published:
o A Map-Notify-Ack message is added in this document to provide o A Map-Notify-Ack message is added in this document to provide
skipping to change at page 41, line 18 skipping to change at page 42, line 31
or IESG approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by IANA.
11.4. LISP Address Type Codes 11.4. LISP Address Type Codes
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
defines LISP-specific encodings for AFI value 16387. LCAF encodings defines LISP-specific encodings for AFI value 16387. LCAF encodings
are used for specific use-cases where different address types for are used for specific use-cases where different address types for
EID-records and RLOC-records are required. EID-records and RLOC-records are required.
The IANA registry "LISP Canonical Address Format (LCAF) Types" is The IANA registry "LISP Canonical Address Format (LCAF) Types" is
used for LCAF types, the registry for LCAF types use the used for LCAF types. The registry for LCAF types use the
Specification Required policy [RFC8126]. Initial values for the Specification Required policy [RFC8126]. Initial values for the
registry as well as further information can be found in [RFC8060]. registry as well as further information can be found in [RFC8060].
Therefore, there is no longer a need for the "LISP Address Type Therefore, there is no longer a need for the "LISP Address Type
Codes" registry requested by [RFC6830]. This document requests to Codes" registry requested by [RFC6830]. This document requests to
remove it. remove it.
11.5. LISP Algorithm ID Numbers 11.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
skipping to change at page 41, line 44 skipping to change at page 43, line 8
Name Number Defined in Name Number Defined in
----------------------------------------------- -----------------------------------------------
None 0 RFC6833bis None 0 RFC6833bis
HMAC-SHA-1-96 1 [RFC2404] HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC4868] HMAC-SHA-256-128 2 [RFC4868]
Number values are in the range of 0 to 255. The allocation of values Number values are in the range of 0 to 255. The allocation of values
is on a first come first served basis. is on a first come first served basis.
11.6. LISP Bit Flags
This document asks IANA to create a registry for allocation of bits
in several headers of the LISP control plane, namely in the Map-
Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM)
messages. Bit allocations are also requested for EID-records and
RLOC-records. The registry created should be named "LISP Control
Plane Header Bits". A sub-registry needs to be created per each
message and record. The name of each sub-registry is indicated
below, along with its format and allocation of bits defined in this
document. Any additional bits allocation, requires a specification,
according with [RFC5226] policies.
Sub-Registry: Map-Request Header Bits [Section 5.2]:
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=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
Sub-Registry: Map-Reply Header Bits [Section 5.4]:
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 |
+-----------+-------------+--------------+------------------------+
| P | map-reply-P | 4 | RLOC-Probe Bit |
| E | map-reply-E | 5 | Echo Nonce Capable Bit |
| S | map-reply-S | 6 | Security Bit |
+-----------+-------------+--------------+------------------------+
LISP Map-Reply Header Bits
Sub-Registry: Map-Register Header Bits [Section 5.6]:
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=3 |P|S|R| Reserved |E|T|a|R|M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+----------------+--------------+----------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+----------------+--------------+----------------------+
| P | map-register-P | 4 | Proxy Map-Reply Bit |
| S | map-register-S | 5 | LISP-SEC Capable Bit |
+-----------+----------------+--------------+----------------------+
LISP Map-Register Header Bits
Sub-Registry: Encapsulated Control Message (ECM) Header Bits
[Section 5.8]:
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=8 |S|D|E|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+-----------+--------------+----------------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+-----------+--------------+----------------------------+
| S | ecm-S | 4 | Security Bit |
| D | ecm-D | 5 | LISP-DDT Bit |
| E | ecm-E | 6 | Forward to ETR Bit |
| M | ecm-M | 7 | Destined to Map-Server Bit |
+-----------+-----------+--------------+----------------------------+
LISP Encapsulated Control Message (ECM) Header Bits
Sub-Registry: EID-Record Header Bits [Section 5.4]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Count | EID mask-len | ACT |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+--------------+--------------+-------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+--------------+--------------+-------------------+
| A | eid-record-A | 19 | Authoritative Bit |
+-----------+--------------+--------------+-------------------+
LISP EID-Record Header Bits
Sub-Registry: RLOC-Record Header Bits [Section 5.4]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused Flags |L|p|R| Loc-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------+---------------+--------------+----------------------+
| Spec Name | IANA Name | Bit Position | Description |
+-----------+---------------+--------------+----------------------+
| L | rloc-record-L | 13 | Local RLOC Bit |
| p | rloc-record-p | 19 | RLOC-Probe Reply Bit |
| R | rloc-record-R | 19 | RLOC Reachable Bit |
+-----------+---------------+--------------+----------------------+
LISP RLOC-Record Header Bits
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-lisp-6834bis] [I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf- Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), September 2018.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-19 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-22 (work in progress),
September 2018. October 2018.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011, DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>. <https://www.rfc-editor.org/info/rfc6071>.
[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>.
12.2. Informative References 12.2. Informative References
skipping to change at page 42, line 47 skipping to change at page 47, line 12
NUMBERS http://www.iana.org/assignments/address-family- NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, Febuary 2007.
[GTP-3GPP] [GTP-3GPP]
3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", TS.29.281
https://portal.3gpp.org/desktopmodules/Specifications/ https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1699, January SpecificationDetails.aspx?specificationId=1699, January
2015. 2015.
[I-D.ermagan-lisp-nat-traversal]
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino,
F., and C. White, "NAT traversal for LISP", draft-ermagan-
lisp-nat-traversal-14 (work in progress), April 2018.
[I-D.herbert-intarea-ila] [I-D.herbert-intarea-ila]
Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-intarea-ila-01 (work addressing for IPv6", draft-herbert-intarea-ila-01 (work
in progress), March 2018. in progress), March 2018.
[I-D.ietf-lisp-eid-mobility] [I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-02 Unified Control Plane", draft-ietf-lisp-eid-mobility-02
(work in progress), May 2018. (work in progress), May 2018.
skipping to change at page 43, line 29 skipping to change at page 47, line 36
gpe-06 (work in progress), September 2018. gpe-06 (work in progress), September 2018.
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-lisp-mn] [I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-02 (work in progress), Mobile Node", draft-ietf-lisp-mn-03 (work in progress),
April 2018. October 2018.
[I-D.ietf-lisp-pubsub] [I-D.ietf-lisp-pubsub]
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F.,
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., Cabellos-Aparicio, A., Barkai, S., Farinacci, D.,
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ Boucadair, M., Jacquenet, C., and S. Secci, "Publish/
Subscribe Functionality for LISP", draft-ietf-lisp- Subscribe Functionality for LISP", draft-ietf-lisp-
pubsub-00 (work in progress), April 2018. pubsub-00 (work in progress), April 2018.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
skipping to change at page 44, line 10 skipping to change at page 48, line 20
[I-D.ietf-opsec-icmp-filtering] [I-D.ietf-opsec-icmp-filtering]
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", draft-ietf-opsec-icmp-
filtering-04 (work in progress), July 2013. filtering-04 (work in progress), July 2013.
[I-D.meyer-loc-id-implications] [I-D.meyer-loc-id-implications]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", draft-meyer-loc-id-implications-01 Locator/ID Separation", draft-meyer-loc-id-implications-01
(work in progress), January 2009. (work in progress), January 2009.
[I-D.rodrigueznatal-lisp-oam]
Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles-
Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM
(Operations, Administration and Management): Use cases and
requirements", draft-rodrigueznatal-lisp-oam-08 (work in
progress), June 2018.
[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- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
skipping to change at page 45, line 21 skipping to change at page 49, line 26
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <https://www.rfc-editor.org/info/rfc6836>. January 2013, <https://www.rfc-editor.org/info/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013, DOI 10.17487/RFC6837, January 2013,
<https://www.rfc-editor.org/info/rfc6837>. <https://www.rfc-editor.org/info/rfc6837>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, April
2014, <https://www.rfc-editor.org/info/rfc7215>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835, Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, DOI 10.17487/RFC7835, April 2016,
skipping to change at page 47, line 19 skipping to change at page 51, line 19
Fabio Maino, and members of the lisp@ietf.org mailing list for their Fabio Maino, and members of the lisp@ietf.org mailing list for their
feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work 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.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6833bis-16 B.1. 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.2. Changes to draft-ietf-lisp-rfc6833bis-16
o Posted Late-September 2018. o Posted Late-September 2018.
o Re-wrote Security Considerations section. Thanks Albert. o Re-wrote Security Considerations section. Thanks Albert.
o Added Alvaro text to be more clear about IANA actions. o Added Alvaro text to be more clear about IANA actions.
B.2. Changes to draft-ietf-lisp-rfc6833bis-15 B.3. Changes to draft-ietf-lisp-rfc6833bis-15
o Posted mid-September 2018. o Posted mid-September 2018.
o Changes to reflect comments from Colin and Mirja. o Changes to reflect comments from Colin and Mirja.
B.3. Changes to draft-ietf-lisp-rfc6833bis-14 B.4. Changes to draft-ietf-lisp-rfc6833bis-14
o Posted September 2018. o Posted September 2018.
o Changes to reflect comments from Genart, RTGarea, and Secdir o Changes to reflect comments from Genart, RTGarea, and Secdir
reviews. reviews.
B.4. Changes to draft-ietf-lisp-rfc6833bis-13 B.5. Changes to draft-ietf-lisp-rfc6833bis-13
o Posted August 2018. o Posted August 2018.
o Final editorial changes before RFC submission for Proposed o Final editorial changes before RFC submission for Proposed
Standard. Standard.
o Added section "Changes since RFC 6833" so implementators are o Added section "Changes since RFC 6833" so implementators are
informed of any changes since the last RFC publication. informed of any changes since the last RFC publication.
B.5. Changes to draft-ietf-lisp-rfc6833bis-12 B.6. Changes to draft-ietf-lisp-rfc6833bis-12
o Posted late July 2018. o Posted late July 2018.
o Moved RFC6830bis and RFC6834bis to Normative References. o Moved RFC6830bis and RFC6834bis to Normative References.
B.6. Changes to draft-ietf-lisp-rfc6833bis-11 B.7. Changes to draft-ietf-lisp-rfc6833bis-11
o Posted July 2018. o Posted July 2018.
o Fixed Luigi editorial comments to ready draft for RFC status and o Fixed Luigi editorial comments to ready draft for RFC status and
ran through IDNITs again. ran through IDNITs again.
B.7. Changes to draft-ietf-lisp-rfc6833bis-10 B.8. Changes to draft-ietf-lisp-rfc6833bis-10
o Posted after LISP WG at IETF week March. o Posted after LISP WG at IETF week March.
o Move AD field encoding after S-bit in the ECM packet format o Move AD field encoding after S-bit in the ECM packet format
description section. description section.
o Say more about when the new Drop actions should be sent. o Say more about when the new Drop actions should be sent.
B.8. Changes to draft-ietf-lisp-rfc6833bis-09 B.9. Changes to draft-ietf-lisp-rfc6833bis-09
o Posted March IETF week 2018. o Posted March IETF week 2018.
o Fixed editorial comments submitted by document shepherd Luigi o Fixed editorial comments submitted by document shepherd Luigi
Iannone. Iannone.
B.9. Changes to draft-ietf-lisp-rfc6833bis-08 B.10. Changes to draft-ietf-lisp-rfc6833bis-08
o Posted March 2018. o Posted March 2018.
o Added RLOC-probing algorithm. o Added RLOC-probing algorithm.
o Added Solicit-Map Request algorithm. o Added Solicit-Map Request algorithm.
o Added several mechanisms (from 6830bis) regarding Routing Locator o Added several mechanisms (from 6830bis) regarding Routing Locator
Reachability. Reachability.
o Added port 4342 to IANA Considerations section. o Added port 4342 to IANA Considerations section.
B.10. Changes to draft-ietf-lisp-rfc6833bis-07 B.11. Changes to draft-ietf-lisp-rfc6833bis-07
o Posted December 2017. o Posted December 2017.
o Make it more clear in a couple of places that RLOCs are used to 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. locate ETRs more so than for Map-Server Map-Request forwarding.
o Make it clear that "encapsualted" for a control message is an ECM o Make it clear that "encapsualted" for a control message is an ECM
based message. based message.
o Make it more clear what messages use source-port 4342 and which o Make it more clear what messages use source-port 4342 and which
skipping to change at page 49, line 25 skipping to change at page 53, line 45
Can use othe AFIs then IPv4 and IPv6. Can use othe AFIs then IPv4 and IPv6.
o Many editorial changes to clarify text. o Many editorial changes to clarify text.
o Changed some "must", "should", and "may" to capitalized. o Changed some "must", "should", and "may" to capitalized.
o Added definitions for Map-Request and Map-Reply messages. o Added definitions for Map-Request and Map-Reply messages.
o Ran document through IDNITs. o Ran document through IDNITs.
B.11. Changes to draft-ietf-lisp-rfc6833bis-06 B.12. Changes to draft-ietf-lisp-rfc6833bis-06
o Posted October 2017. o Posted October 2017.
o Spec the I-bit to include the xTR-ID in a Map-Request message to o Spec the I-bit to include the xTR-ID in a Map-Request message to
be consistent with the Map-Register message and to anticipate the be consistent with the Map-Register message and to anticipate the
introduction of pubsub functionality to allow Map-Requests to introduction of pubsub functionality to allow Map-Requests to
subscribe to RLOC-set changes. subscribe to RLOC-set changes.
o Updated references for individual submissions that became working o Updated references for individual submissions that became working
group documents. group documents.
o Updated references for working group documents that became RFCs. o Updated references for working group documents that became RFCs.
B.12. Changes to draft-ietf-lisp-rfc6833bis-05 B.13. Changes to draft-ietf-lisp-rfc6833bis-05
o Posted May 2017. o Posted May 2017.
o Update IANA Considerations section based on new requests from this o Update IANA Considerations section based on new requests from this
document and changes from what was requested in [RFC6830]. document and changes from what was requested in [RFC6830].
B.13. Changes to draft-ietf-lisp-rfc6833bis-04 B.14. Changes to draft-ietf-lisp-rfc6833bis-04
o Posted May 2017. o Posted May 2017.
o Clarify how the Key-ID field is used in Map-Register and Map- o Clarify how the Key-ID field is used in Map-Register and Map-
Notify messages. Break the 16-bit field into a 8-bit Key-ID field Notify messages. Break the 16-bit field into a 8-bit Key-ID field
and a 8-bit Algorithm-ID field. and a 8-bit Algorithm-ID field.
o Move the Control-Plane codepoints from the IANA Considerations o Move the Control-Plane codepoints from the IANA Considerations
section of RFC6830bis to the IANA Considerations section of this section of RFC6830bis to the IANA Considerations section of this
document. document.
o In the "LISP Control Packet Type Allocations" section, indicate o In the "LISP Control Packet Type Allocations" section, indicate
how message Types are IANA allocated and how experimental RFC8113 how message Types are IANA allocated and how experimental RFC8113
sub-types should be requested. sub-types should be requested.
B.14. Changes to draft-ietf-lisp-rfc6833bis-03 B.15. Changes to draft-ietf-lisp-rfc6833bis-03
o Posted April 2017. o Posted April 2017.
o Add types 9-14 and specify they are not assigned. o Add types 9-14 and specify they are not assigned.
o Add the "LISP Shared Extension Message" type and point to RFC8113. o Add the "LISP Shared Extension Message" type and point to RFC8113.
B.15. Changes to draft-ietf-lisp-rfc6833bis-02 B.16. Changes to draft-ietf-lisp-rfc6833bis-02
o Posted April 2017. o Posted April 2017.
o Clarify that the LISP Control-Plane document defines how the LISP o Clarify that the LISP Control-Plane document defines how the LISP
Data-Plane uses Map-Requests with either the SMR-bit set or the Data-Plane uses Map-Requests with either the SMR-bit set or the
P-bit set supporting mapping updates and RLOC-probing. Indicating P-bit set supporting mapping updates and RLOC-probing. Indicating
that other Data-Planes can use the same mechanisms or their own that other Data-Planes can use the same mechanisms or their own
defined mechanisms to achieve the same functionality. defined mechanisms to achieve the same functionality.
B.16. Changes to draft-ietf-lisp-rfc6833bis-01 B.17. Changes to draft-ietf-lisp-rfc6833bis-01
o Posted March 2017. o Posted March 2017.
o Include references to new RFCs published. o Include references to new RFCs published.
o Remove references to self. o Remove references to self.
o Change references from RFC6830 to RFC6830bis. o Change references from RFC6830 to RFC6830bis.
o Add two new action/reasons to a Map-Reply has posted to the LISP o Add two new action/reasons to a Map-Reply has posted to the LISP
WG mailing list. WG mailing list.
o In intro section, add refernece to I-D.ietf-lisp-introduction. o In intro section, add refernece to I-D.ietf-lisp-introduction.
o Removed Open Issues section and references to "experimental". o Removed Open Issues section and references to "experimental".
B.17. Changes to draft-ietf-lisp-rfc6833bis-00 B.18. Changes to draft-ietf-lisp-rfc6833bis-00
o Posted December 2016. o Posted December 2016.
o Created working group document from draft-farinacci-lisp o Created working group document from draft-farinacci-lisp
-rfc6833-00 individual submission. No other changes made. -rfc6833-00 individual submission. No other changes made.
B.18. Changes to draft-farinacci-lisp-rfc6833bis-00 B.19. Changes to draft-farinacci-lisp-rfc6833bis-00
o Posted November 2016. o Posted November 2016.
o This is the initial draft to turn RFC 6833 into RFC 6833bis. o This is the initial draft to turn RFC 6833 into RFC 6833bis.
o The document name has changed from the "Locator/ID Separation o The document name has changed from the "Locator/ID Separation
Protocol (LISP) Map-Server Interface" to the "Locator/ID Protocol (LISP) Map-Server Interface" to the "Locator/ID
Separation Protocol (LISP) Control-Plane". Separation Protocol (LISP) Control-Plane".
o The fundamental change was to move the Control-Plane messages from o The fundamental change was to move the Control-Plane messages from
 End of changes. 63 change blocks. 
219 lines changed or deleted 343 lines changed or added

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