draft-ietf-lisp-rfc6833bis-25.txt   draft-ietf-lisp-rfc6833bis-26.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Obsoletes: 6830, 6833 (if approved) F. Maino Obsoletes: 6830, 6833 (if approved) F. Maino
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 18, 2019 V. Fuller Expires: May 20, 2020 V. Fuller
vaf.net Internet Consulting vaf.net Internet Consulting
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
June 16, 2019 November 17, 2019
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-25 draft-ietf-lisp-rfc6833bis-26
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 types of
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server --
-- that provides a simplified "front end" for one or more Endpoint ID that provides a simplified "front end" for one or more Endpoint ID to
to Routing Locator mapping databases. 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, connecting EID addressable nodes LISP Control-Plane infrastructure, connecting EID addressable nodes
of a LISP site, their implementation and operational complexity of a LISP site, their implementation and operational complexity
reduces the overall cost and effort of deploying LISP. reduces the overall cost and effort of deploying LISP.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 December 18, 2019. This Internet-Draft will expire on May 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 4 1.1. Scope of Applicability . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 28
5.8. Encapsulated Control Message Format . . . . . . . . . . . 30 5.8. Encapsulated Control Message Format . . . . . . . . . . . 30
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 32
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 32
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 33 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 33
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 35 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 34
8. Interactions with Other LISP Components . . . . . . . . . . . 36 8. Interactions with Other LISP Components . . . . . . . . . . . 35
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 36 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 35
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 37 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 36
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 39 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 38
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 39
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41
11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43 11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 42
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 43
12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44 12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 43
12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 12.3. LISP Map-Reply EID-Record Action Codes . . . . . . . . . 43
12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45 12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 44
12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 45 12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 44
12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46 12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1. Normative References . . . . . . . . . . . . . . . . . . 49 13.1. Normative References . . . . . . . . . . . . . . . . . . 48
13.2. Informative References . . . . . . . . . . . . . . . . . 50 13.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 54
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 55 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 54
B.1. Changes to draft-ietf-lisp-rfc6833bis-25 . . . . . . . . 55 B.1. Changes to draft-ietf-lisp-rfc6833bis-26 . . . . . . . . 54
B.2. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 55 B.2. Changes to draft-ietf-lisp-rfc6833bis-25 . . . . . . . . 54
B.3. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 56 B.3. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 55
B.4. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 56 B.4. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 55
B.5. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 56 B.5. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 55
B.6. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 56 B.6. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 55
B.7. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56 B.7. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 55
B.8. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 57 B.8. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56
B.9. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 57 B.9. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 56
B.10. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57 B.10. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 56
B.11. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 57 B.11. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 56
B.12. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 57 B.12. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 56
B.13. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 58 B.13. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 56
B.14. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 58 B.14. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 57
B.15. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 58 B.15. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 57
B.16. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 58 B.16. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 57
B.17. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 58 B.17. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 57
B.18. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 58 B.18. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 57
B.19. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 59 B.19. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 57
B.20. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59 B.20. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 58
B.21. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 60 B.21. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 58
B.22. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 60 B.22. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 59
B.23. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60 B.23. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 59
B.24. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60 B.24. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 59
B.25. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60 B.25. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 59
B.26. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 61 B.26. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 59
B.27. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 61 B.27. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 B.28. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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 across mapping system database to store and propagate those mappings across mapping system
nodes. Several such databases have been proposed; among them are the nodes. Several such databases have been proposed; among them are the
Content distribution Overlay Network Service for LISP-NERD (a Not-so- Content distribution Overlay Network Service for LISP-NERD (a Not-so-
novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical novel EID-to-RLOC Database) [RFC6837], LISP Alternative Logical
Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree Topology (LISP-ALT) [RFC6836], and LISP Delegated Database Tree
(LISP-DDT) [RFC8111]. (LISP-DDT) [RFC8111].
The LISP Mapping Service defines two new types of LISP-speaking The LISP Mapping Service defines two types of LISP-speaking devices:
devices: the Map-Resolver, which accepts Map-Requests from an Ingress the Map-Resolver, which accepts Map-Requests from an Ingress Tunnel
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a Router (ITR) and "resolves" the EID-to-RLOC mapping using a mapping
mapping database; and the Map-Server, which learns authoritative EID- database; and the Map-Server, which learns authoritative EID-to-RLOC
to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes mappings from an Egress Tunnel Router (ETR) and publishes them in a
them in a database. 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
but are not limited to the ones defined in LISP RFC 6830bis but are not limited to the ones defined in LISP RFC 6830bis
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN
[RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], GRE [RFC2890], GTP
[GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6)
[RFC8402]. [RFC8402].
Conceptually, LISP Map-Servers share some of the same basic Conceptually, LISP Map-Servers share some of the same basic
skipping to change at page 7, line 23 skipping to change at page 7, line 25
(GRE) tunnels configured to other ALT-Routers and uses BGP to learn (GRE) tunnels configured to other ALT-Routers and uses BGP to learn
paths to ETRs for different prefixes in the LISP-ALT database. The paths to ETRs for different prefixes in the LISP-ALT database. The
Map-Resolver uses this path information to forward Map-Requests over Map-Resolver uses this path information to forward Map-Requests over
the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map- the ALT to the correct ETRs. On a LISP-DDT network [RFC8111], a Map-
Resolver maintains a referral-cache and acts as a "first-hop" DDT- Resolver maintains a referral-cache and acts as a "first-hop" DDT-
node. The Map-Resolver uses the referral information to forward Map- node. The Map-Resolver uses the referral information to forward Map-
Requests. Requests.
Note that while it is conceivable that a Map-Resolver could cache Note that while it is conceivable that a Map-Resolver could cache
responses to improve performance, issues surrounding cache management responses to improve performance, issues surrounding cache management
will need to be resolved so that doing so will be reliable and would need to be resolved so that doing so will be reliable and
practical. As initially deployed, Map-Resolvers will operate only in practical. In this specification, Map-Resolvers will operate only in
a non-caching mode, decapsulating and forwarding Encapsulated Map a non-caching mode, decapsulating and forwarding Encapsulated Map
Requests received from ITRs. Any specification of caching Requests received from ITRs. Any specification of caching
functionality is out of scope for this document. functionality is out of scope for this document.
Note that a single device can implement the functions of both a Map- Note that a single device can implement the functions of both a Map-
Server and a Map-Resolver, and in many cases the functions will be Server and a Map-Resolver, and in many cases the functions will be
co-located in that way. Also, there can be ALT-only nodes and DDT- co-located in that way. Also, there can be ALT-only nodes and DDT-
only nodes, when LISP-ALT and LISP-DDT are used, respectively, to only nodes, when LISP-ALT and LISP-DDT are used, respectively, to
connecting Map-Resolvers and Map-Servers together to make up the connecting Map-Resolvers and Map-Servers together to make up the
Mapping System. Mapping System.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
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 returning a Map-Reply. 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 MUST be
be treated as a Locator reachability probe. The receiver SHOULD treated as a Locator reachability probe. The receiver MUST
respond with a Map-Reply with the probe-bit set, indicating that respond with a Map-Reply with the probe-bit set, indicating that
the Map-Reply is a Locator reachability probe reply, with the the Map-Reply is a Locator reachability probe reply, with the
nonce copied from the Map-Request. See RLOC-Probing Section 7.1 nonce copied from the Map-Request. See RLOC-Probing Section 7.1
for more details. This RLOC-probe Map-Request MUST NOT be sent to 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 the mapping system. If a Map-Resolver or Map-Server receives a
Map-Request with the probe-bit set, it MUST drop the message. 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.
skipping to change at page 13, line 52 skipping to change at page 14, line 4
message. A record is comprised of the portion of the packet that message. A record is comprised of the portion of the packet that
is labeled 'Rec' above and occurs the number of times equal to is labeled 'Rec' above and occurs the number of times equal to
Record Count. For this version of the protocol, a receiver MUST Record Count. For this version of the protocol, a receiver MUST
accept and process Map-Requests that contain one or more records, accept and process Map-Requests that contain one or more records,
but a sender MUST only send Map-Requests containing one record. but a sender MUST only send Map-Requests containing one record.
Nonce: This is an 8-octet random value created by the sender of the Nonce: This is an 8-octet random value created by the sender of the
Map-Request. This nonce will be returned in the Map-Reply. The Map-Request. This nonce will be returned in the Map-Reply. The
nonce is used as an index to identify the corresponding Map- nonce is used as an index to identify the corresponding Map-
Request when a Map-Reply message is received. The nonce MUST be Request when a Map-Reply message is received. The nonce MUST be
generated by a properly seeded pseudo-random (or strong random) generated by a properly seeded pseudo-random source, see as an
source. See [RFC4086] for advice on generating security-sensitive example [RFC4086].
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'
field that follows this field. field that follows this field.
ITR-RLOC Address: This is used to give the ETR the option of ITR-RLOC Address: This is used to give the ETR the option of
selecting the destination address from any address family for the selecting the destination address from any address family for the
Map-Reply message. This address MUST be a routable RLOC address Map-Reply message. This address MUST be a routable RLOC address
of the sender of the Map-Request message. of the sender of the Map-Request message.
EID mask-len: This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the EID-Prefix in decimal.
EID-Prefix-AFI: This is the address family of the EID-Prefix EID-Prefix-AFI: This is the address family of the EID-Prefix
according to [AFI] and [RFC8060]. according to [AFI] and [RFC8060].
EID-Prefix: This prefix address length is 4 octets for an IPv4 EID-Prefix: This prefix address length is 4 octets for an IPv4
address family and 16 octets for an IPv6 address family when the address family and 16 octets for an IPv6 address family when the
EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the
address length varies and for the LCAF AFI the format is defined address length varies and for the LCAF AFI the format is defined
in [RFC8060]. When a Map-Request is sent by an ITR because a data in [RFC8060]. When a Map-Request is sent by an ITR because a data
packet is received for a destination where there is no mapping packet is received for a destination where there is no mapping
skipping to change at page 15, line 45 skipping to change at page 15, line 45
must wait 30 seconds. must wait 30 seconds.
An ITR that is configured with mapping database information (i.e., it An ITR that is configured with mapping database information (i.e., it
is also an ETR) MAY optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the Map-Cache, it 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 (when it is an xTR co-located as an a Map-Cache entry. If the ETR (when it is an xTR co-located as an
ITR) has a Map-Cache entry that matches the "piggybacked" EID and the ITR) has a Map-Cache entry that matches the "piggybacked" EID and the
RLOC is in the Locator-Set for the entry, then it MAY send the RLOC is in the Locator-Set for the cached entry, then it MAY send the
"verifying Map-Request" directly to the originating Map-Request "verifying Map-Request" directly to the originating Map-Request
source. If the RLOC is not in the Locator-Set, then the ETR MUST source. If the RLOC is not in the Locator-Set, then the ETR MUST
send the "verifying Map-Request" to the "piggybacked" EID. Doing send the "verifying Map-Request" to the "piggybacked" EID. Doing
this forces the "verifying Map-Request" to go through the mapping this forces the "verifying Map-Request" to go through the mapping
database system to reach the authoritative source of information database system to reach the authoritative source of information
about that EID, guarding against RLOC-spoofing in the "piggybacked" about that EID, guarding against RLOC-spoofing in the "piggybacked"
mapping data. mapping data.
5.4. Map-Reply Message Format 5.4. Map-Reply Message Format
skipping to change at page 17, line 40 skipping to change at page 17, line 40
Packet field descriptions: Packet field descriptions:
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: This is the probe-bit, which indicates that the Map-Reply is in P: This is the probe-bit, which indicates that the Map-Reply is in
response to a Locator reachability probe Map-Request. The 'Nonce' response to a Locator reachability probe Map-Request. The 'Nonce'
field MUST contain a copy of the nonce value from the original field MUST contain a copy of the nonce value from the original
Map-Request. See RLOC-probing Section 7.1 for more details. When Map-Request. See RLOC-probing Section 7.1 for more details. When
the probe-bit is set to 1 in a Map-Reply message, the A-bit in the probe-bit is set to 1 in a Map-Reply message, the A-bit in
each EID-record included in the message MUST be set to 1. each EID-record included in the message MUST be set to 1,
otherwise MUST be silently discarded.
E: This bit indicates that the ETR that sends this Map-Reply message E: This bit indicates that the ETR that sends this Map-Reply message
is advertising that the site is enabled for the Echo-Nonce Locator is advertising that the site is enabled for the Echo-Nonce Locator
reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis] reachability algorithm. See Echo-Nonce [I-D.ietf-lisp-rfc6830bis]
for more details. for more details.
S: This is the Security bit. When set to 1, the following S: This is the Security bit. When set to 1, the following
authentication information will be appended to the end of the Map- authentication information will be appended to the end of the Map-
Reply. The details of signing a Map-Reply message can be found in Reply. The details can be found in [I-D.ietf-lisp-sec].
[I-D.ietf-lisp-sec].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: This unassigned field MUST be set to 0 on transmit and Reserved: This unassigned field MUST be set to 0 on transmit and
MUST be ignored on receipt. MUST be ignored on receipt.
Record Count: This is the number of records in this reply message. Record Count: This is the number of records in this reply message.
A record is comprised of that portion of the packet labeled A record is comprised of that portion of the packet labeled
'Record' above and occurs the number of times equal to Record 'Record' above and occurs the number of times equal to Record
Count. Count.
Nonce: This 64-bit value from the Map-Request is echoed in this Nonce: This 64-bit value from the Map-Request is echoed in this
'Nonce' field of the Map-Reply. 'Nonce' field of the Map-Reply.
Record TTL: This is the time in minutes the recipient of the Map- Record TTL: This is the time in minutes the recipient of the Map-
Reply will store the mapping. If the TTL is 0, the entry MUST be Reply can store the mapping. If the TTL is 0, the entry MUST be
removed from the cache immediately. If the value is 0xffffffff, removed from the cache immediately. If the value is 0xffffffff,
the recipient can decide locally how long to store the mapping. the recipient can decide locally how long to store the mapping.
Locator Count: This is the number of Locator entries. A Locator Locator Count: This is the number of Locator entries in the given
entry comprises what is labeled above as 'Loc'. The Locator count Record. A Locator entry comprises what is labeled above as 'Loc'.
can be 0, indicating that there are no Locators for the EID- The Locator count can be 0, indicating that there are no Locators
Prefix. for the EID-Prefix.
EID mask-len: This is the mask length for the EID-Prefix. EID mask-len: This is the mask length for the EID-Prefix in decimal.
ACT: This 3-bit field describes Negative Map-Reply actions. In any ACT: This 3-bit field describes Negative Map-Reply actions. In any
other message type, these bits are set to 0 and ignored on other message type, these bits are set to 0 and ignored on
receipt. These bits are used only when the 'Locator Count' field receipt. These bits are used only when the 'Locator Count' field
is set to 0. The action bits are encoded only in Map-Reply is set to 0. The action bits are encoded only in Map-Reply
messages. They are used to tell an ITR or PITR why a empty messages. They are used to tell an ITR or PITR why a empty
locator-set was returned from the mapping system and how it stores locator-set was returned from the mapping system and how it stores
the map-cache entry. the map-cache entry. See Section 12.3 for additional information.
(0) No-Action: The Map-Cache is kept alive, and no packet (0) No-Action: The Map-Cache is kept alive, and no packet
encapsulation occurs. encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The Map-Cache entry is created and flagged (2) Send-Map-Request: The Map-Cache entry is created and flagged
that any packet matching this entry invokes sending a Map- that any packet matching this entry invokes sending a Map-
Request. Request.
skipping to change at page 19, line 19 skipping to change at page 19, 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 set to 1, is always set to 1 by an A: The Authoritative bit MAY only be set to 1 by an ETR. A Map-
ETR. When a Map-Server is proxy Map-Replying for a LISP site, the Server generating Map-Reply messages as a proxy MUST NOT set the
Authoritative bit is set to 0. This indicates to requesting ITRs A-bit to 1 by an ETR, and not a Map-Server generating Map-Reply
that the Map-Reply was not originated by a LISP node managed at messages as a proxy. This bit indicates to requesting ITRs that
the site that owns the EID-Prefix. the Map-Reply was not originated by a LISP node managed at 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
Map-Request and Map-Register messages. See Map-Versioning Map-Request and Map-Register messages. See Map-Versioning
[I-D.ietf-lisp-6834bis] for more details. [I-D.ietf-lisp-6834bis] for more details.
skipping to change at page 23, line 6 skipping to change at page 23, line 6
Map-Reply records can have an empty Locator-Set. A Negative Map- Map-Reply records can have an empty Locator-Set. A Negative Map-
Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies Reply is a Map-Reply with an empty Locator-Set. Negative Map-Replies
convey special actions by the sender to the ITR or PITR that have convey special actions by the sender to the ITR or PITR that have
solicited the Map-Reply. There are two primary applications for solicited the Map-Reply. There are two primary applications for
Negative Map-Replies. The first is for a Map-Resolver to instruct an Negative Map-Replies. The first is for a Map-Resolver to instruct an
ITR or PITR when a destination is for a LISP site versus a non-LISP ITR or PITR when a destination is for a LISP site versus a non-LISP
site, and the other is to source quench Map-Requests that are sent site, and the other is to source quench Map-Requests that are sent
for non-allocated EIDs. for non-allocated EIDs.
For each Map-Reply record, the list of Locators in a Locator-Set MUST For each Map-Reply record, the list of Locators in a Locator-Set MUST
appear in the same order for each ETR that originates a Map-Reply be sorted in order of ascending IP address where an IPv4 locator
message. The Locator-Set MUST be sorted in order of ascending IP address is considered numerically 'less than' an IPv6 locator
address where an IPv4 locator address is considered numerically 'less 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
skipping to change at page 24, line 49 skipping to change at page 24, line 49
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy Map-Reply bit. When set to 1, an ETR sends a P: This is the proxy Map-Reply bit. When set to 1, the ETR sending
Map-Register message requesting the Map-Server to proxy a Map- the Map-Register message is requesting the Map-Server to proxy a
Reply. The Map-Server will send non-authoritative Map-Replies on Map-Reply. The Map-Server will send non-authoritative Map-Replies
behalf of the ETR. on behalf of the ETR.
S: This is the security-capable bit. When set, the procedures from S: This is the security-capable bit. When set, the procedures from
[I-D.ietf-lisp-sec] are supported. [I-D.ietf-lisp-sec] are supported.
I: This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64 I: This bit is set to 1 to indicate that a 128 bit xTR-ID and a 64
bit Site-ID fields are present at the end of the Map-Register bit Site-ID fields are present at the end of the Map-Register
message. If an xTR is configured with an xTR-ID and Site-ID, it message. If an xTR is configured with an xTR-ID and Site-ID, it
MUST set the I bit to 1 and include its xTR-ID and Site-ID in the MUST set the I bit to 1 and include its xTR-ID and Site-ID in the
Map-Register messages it generates. The combination of Site-ID Map-Register messages it generates. The combination of Site-ID
plus xTR-ID uniquely identifies an xTR in a LISP domain and serves plus xTR-ID uniquely identifies an xTR in a LISP domain and serves
skipping to change at page 27, line 27 skipping to change at page 27, line 27
last RLOC record) with the authenticated data field preset to last RLOC record) with the authenticated data field preset to
0. 0.
The definition of the rest of the Map-Register can be found in EID- The definition of the rest of the Map-Register can be found in EID-
record description in Section 5.4. When the I-bit is set, the record description in Section 5.4. When the I-bit is set, the
following fields are added to the end of the Map-Register message: following fields are added to the end of the Map-Register message:
xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register xTR-ID: xTR-ID is a 128 bit field at the end of the Map-Register
message, starting after the final Record in the message. The xTR- message, starting after the final Record in the message. The xTR-
ID is used to uniquely identify a xTR. The same xTR-ID value MUST ID is used to uniquely identify a xTR. The same xTR-ID value MUST
NOT be used in two different xTRs. NOT be used in two different xTRs in the scope of the Site-ID.
Site-ID: Site-ID is a 64 bit field at the end of the Map- Register Site-ID: Site-ID is a 64 bit field at the end of the Map- Register
message, following the xTR-ID. Site-ID is used to uniquely message, following the xTR-ID. Site-ID is used to uniquely
identify to which site the xTR that sent the message belongs. identify to which site the xTR that sent the message belongs.
This document does not specify a strict meaning for the Site-ID
field. Informally it provides an indication that a group of xTRs
have some relation, either administratively, topologically or
otherwise.
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.
The Map-Notify and Map-Notify-Ack message formats are: The Map-Notify and Map-Notify-Ack message formats are:
0 1 2 3 0 1 2 3
skipping to change at page 29, line 9 skipping to change at page 29, line 9
The fields of the Map-Notify are copied from the corresponding Map- The fields of the Map-Notify are copied from the corresponding Map-
Register to acknowledge its correct processing. In the Map-Notfiy, Register to acknowledge its correct processing. In the Map-Notfiy,
the 'Authentication Data' field is recomputed according to the the 'Authentication Data' field is recomputed according to the
procedure defined in the previous section. For an unsolicited Map- procedure defined in the previous section. For an unsolicited Map-
Notify, the fields of a Map-Notify used for publish/subscribe are Notify, the fields of a Map-Notify used for publish/subscribe are
specified in [I-D.ietf-lisp-pubsub]. specified in [I-D.ietf-lisp-pubsub].
After sending a Map-Register, if a Map-Notify is not received after 1 After sending a Map-Register, if a Map-Notify is not received after 1
second the transmitter MUST re-transmit the original Map-Register second the transmitter MUST re-transmit the original Map-Register
with an exponential backoff, the maximum backoff is 1 minute. with an exponential backoff (base of 2, that is, the next backoff
timeout interval is doubled), the maximum backoff is 1 minute.
The Map-Notify-Ack message has the same contents as a Map-Notify The Map-Notify-Ack message has the same contents as a Map-Notify
message. It is used to acknowledge the receipt of a Map-Notify message. It is used to acknowledge the receipt of a Map-Notify and
(solicited or unsolicited) and for the sender to stop retransmitting for the sender to stop retransmitting a Map-Notify with the same
a Map-Notify with the same nonce. The fields of the Map-Notify-Ack nonce. The fields of the Map-Notify-Ack are copied from the
are copied from the corresponding Map-Notify message to acknowledge corresponding Map-Notify message to acknowledge its correct
its correct processing. processing. The 'Authentication Data' field is recomputed according
to the procedure defined in the previous section.
A Map-Server sends an unsolicited Map-Notify message (one that is not A Map-Server sends an unsolicited Map-Notify message (one that is not
used as an acknowledgment to a Map-Register message) that follows the used as an acknowledgment to a Map-Register message) that follows the
Congestion Control And Relability Guideline sections of [RFC8085]. A Congestion Control And Relability Guideline sections of [RFC8085]. A
Map-Notify is retransmitted until a Map-Notify-Ack is received by the Map-Notify is retransmitted until a Map-Notify-Ack is received by the
Map-Server with the same nonce used in the Map-Notify message. If a Map-Server with the same nonce used in the Map-Notify message. If a
Map-Notify-Ack is never received by the Map-Server, it issues a log Map-Notify-Ack is never received by the Map-Server, it issues a log
message. An implementation SHOULD retransmit up to 3 times at 3 message. An implementation SHOULD retransmit up to 3 times at 3
second retransmission intervals, after which time the retransmission second retransmission intervals, after which time the retransmission
interval is exponentially backed-off for another 3 retransmission interval is exponentially backed-off (base of 2, that is, the next
attempts. After this time, an xTR can only get the RLOC-set change backoff timeout interval is doubled) for another 3 retransmission
by later querying the mapping system or by RLOC-probing one of the attempts.
RLOCs of the existing cached RLOC-set to get the new RLOC-set.
Upon reception of Map-Register, Map-Notify or Map-Notifiy-Ack, the
receiver verifies the authentication data.
5.8. Encapsulated Control Message Format 5.8. Encapsulated Control Message Format
An Encapsulated Control Message (ECM) is used to encapsulate control An Encapsulated Control Message (ECM) is used to encapsulate control
packets sent between xTRs and the mapping database system. packets sent between xTRs and the mapping database system.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
skipping to change at page 31, line 38 skipping to change at page 31, 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. Map-Request messages are allowed to be Control- Section 5. Map-Request messages are allowed to be Control-
Plane (ECM) encapsulated. When Map-Requests are sent for RLOC- Plane (ECM) encapsulated. When Map-Requests are sent for RLOC-
Probing purposes (i.e. the probe-bit is set), they MUST NOT be Probing purposes (i.e. the probe-bit is set), they MUST NOT be
sent inside Encapsulated Control Messages. PIM Join/Prune sent inside Encapsulated Control Messages. PIM Join/Prune
messages [RFC6831] are also allowed to be Control-Plane (ECM) messages [RFC6831] are also allowed to be Control-Plane (ECM)
encapsulated. encapsulated.
6. Changing the Contents of EID-to-RLOC Mappings 6. Changing the Contents of EID-to-RLOC Mappings
In the LISP architecture ITRs/PITRs use a local Map-Cache to store In the LISP architecture ITRs/PITRs use a local Map-Cache to store
EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a
skipping to change at page 32, line 29 skipping to change at page 32, line 29
Soliciting a Map-Request is a selective way for ETRs, at the site Soliciting a Map-Request is a selective way for ETRs, at the site
where mappings change, to control the rate they receive requests for where mappings change, to control the rate they receive requests for
Map-Reply messages. SMRs are also used to tell remote ITRs to update Map-Reply messages. SMRs are also used to tell remote ITRs to update
the mappings they have cached. the mappings they have cached.
Since ETRs are not required to keep track of remote ITRs that have Since ETRs are not required to keep track of remote ITRs that have
cached their mappings, they do not know which ITRs need to have their cached their mappings, they do not know which ITRs need to have their
mappings updated. As a result, an ETR will solicit Map-Requests mappings updated. As a result, an ETR will solicit Map-Requests
(called an SMR message) to those sites to which it has been sending (called an SMR message) to those sites to which it has been sending
LISP encapsulated data packets for the last minute. In particular, LISP encapsulated data packets for the last minute. As a result,
an ETR will send an SMR to an ITR to which it has recently sent when an ETR is also acting as ITR, it will send an SMR to an ITR to
encapsulated data. This can only occur when both ITR and ETR which it has recently sent encapsulated data.
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 SMR responder MUST rate-limit these Both the SMR sender and the SMR responder MUST rate-limit these
messages. It is RECOMMENDED that the SMR sender rate-limits Map- messages. It is RECOMMENDED that the SMR sender rate-limits Map-
Request for the same destination RLOC to no more than one packet per Request for the same destination RLOC to no more than one packet per
3 seconds. It is RECOMMENDED that the SMR responder rate-limits Map- 3 seconds. It is RECOMMENDED that the SMR responder rate-limits Map-
Request for the same EID-Prefix to no more than once per 3 seconds. Request for the same EID-Prefix to no more than once per 3 seconds.
The following procedure shows how an SMR exchange occurs when a site
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
begin to send Map-Requests with the SMR bit set for each Locator
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
a Map-Request message to the source locator address of the SMR
message or to the mapping database system. A newly allocated
random nonce is selected, and the EID-Prefix used is the one
copied from the SMR message. If the source Locator is the only
Locator in the cached Locator-Set, the remote ITR SHOULD send a
Map-Request to the database mapping system just in case the
single Locator has changed and may no longer be reachable to
accept the Map-Request.
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-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
database mapping.
4. The site sending SMR messages will reply to the Map-Request with
a Map-Reply message that has a nonce from the SMR-invoked Map-
Request. This is important to avoid Map-Reply implosion.
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
mapping data in the Map-Cache entry for the remote site so the
Locator-Status-Bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR
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
sender of an SMR-based Map-Request MUST be verified. If an ITR sender of an SMR-based Map-Request MUST be verified. If an ITR
receives an SMR-based Map-Request and the source is not in the receives an SMR-based Map-Request and the source is not in the
Locator-Set for the stored Map-Cache entry, then the responding Map- Locator-Set for the stored Map-Cache entry, then the responding Map-
Request MUST be sent with an EID destination to the mapping database Request MUST be sent with an EID destination to the mapping database
system. Since the mapping database system is a more secure way to system. Since the mapping database system is a more secure way to
reach an authoritative ETR, it will deliver the Map-Request to the reach an authoritative ETR, it will deliver the Map-Request to the
authoritative source of the mapping data. authoritative source of the mapping data. Please note that this
procedure does not result in cryptographic or strongly authenticated
verification.
When an ITR receives an SMR-based Map-Request for which it does not When an ITR receives an SMR-based Map-Request for which it does not
have a cached mapping for the EID in the SMR message, it SHOULD NOT have a cached mapping for the EID in the SMR message, it SHOULD NOT
send an SMR-invoked Map-Request. This scenario can occur when an ETR send an SMR-invoked Map-Request. This scenario can occur when an ETR
sends SMR messages to all Locators in the Locator-Set it has stored sends SMR messages to all Locators in the Locator-Set it has stored
in its Map-Cache but the remote ITRs that receive the SMR may not be in its Map-Cache but the remote ITRs that receive the SMR may not be
sending packets to the site. There is no point in updating the ITRs sending packets to the site. There is no point in updating the ITRs
until they need to send, in which case they will send Map-Requests to until they need to send, in which case they will send Map-Requests to
obtain a Map-Cache entry. obtain a Map-Cache entry.
skipping to change at page 34, line 44 skipping to change at page 34, line 10
from using Locators that are described in Locator lists of Map- from using Locators that are described in Locator lists of Map-
Replies. However, using this approach is unreliable because many Replies. However, using this approach is unreliable because many
network operators turn off generation of ICMP Destination Unreachable network operators turn off generation of ICMP Destination Unreachable
messages. messages.
If an ITR does receive an ICMP Network Unreachable or Host If an ITR does receive an ICMP Network Unreachable or Host
Unreachable message, it MAY originate its own ICMP Destination Unreachable message, it MAY originate its own ICMP Destination
Unreachable message destined for the host that originated the data Unreachable message destined for the host that originated the data
packet the ITR encapsulated. packet the ITR encapsulated.
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
locator address from a Locator-Set in a mapping entry matches a
prefix. If it does not find one and BGP is running in the Default-
Free Zone (DFZ), it can decide to not use the Locator even though the
Locator-Status-Bits indicate that the Locator is up. In this case,
the path from the ITR to the ETR that is assigned the Locator is not
available. More details are in [I-D.meyer-loc-id-implications].
Optionally, an ITR can send a Map-Request to a Locator, and if a Map-
Reply is returned, reachability of the Locator has been determined.
Obviously, sending such probes increases the number of control
messages originated by Tunnel Routers for active flows, so Locators
are assumed to be reachable when they are advertised.
This assumption does create a dependency: Locator unreachability is This assumption does create a dependency: Locator unreachability is
detected by the receipt of ICMP Host Unreachable messages. When a detected by the receipt of ICMP Host Unreachable messages. When a
Locator has been determined to be unreachable, it is not used for Locator has been determined to be unreachable, it is not used for
active traffic; this is the same as if it were listed in a Map-Reply active traffic; this is the same as if it were listed in a Map-Reply
with Priority 255. with Priority 255.
The ITR can test the reachability of the unreachable Locator by The ITR can test the reachability of the unreachable Locator by
sending periodic Requests. Both Requests and Replies MUST be rate- sending periodic Requests. Both Requests and Replies MUST be rate-
limited. Locator reachability testing is never done with data limited, see Section 5.3 and Section 5.4 for information about rate-
limiting. Locator reachability testing is never done with data
packets, since that increases the risk of packet loss for end-to-end packets, since that increases the risk of packet loss for end-to-end
sessions. sessions.
7.1. RLOC-Probing Algorithm 7.1. RLOC-Probing Algorithm
RLOC-Probing is a method that an ITR or PITR can use to determine the RLOC-Probing is a method that an ITR or PITR can use to determine the
reachability status of one or more Locators that it has cached in a reachability status of one or more Locators that it has cached in a
Map-Cache entry. The probe-bit of the Map-Request and Map-Reply Map-Cache entry. The probe-bit of the Map-Request and Map-Reply
messages is used for RLOC-Probing. messages is used for RLOC-Probing.
RLOC-Probing is done in the control plane on a timer basis, where an RLOC-Probing is done in the control plane on a timer basis, where an
ITR or PITR will originate a Map-Request destined to a locator ITR or PITR will originate a Map-Request destined to a locator
address from one of its own locator addresses. A Map-Request used as address from one of its own locator addresses. A Map-Request used as
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 requesting 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 to the IP address of the outgoing interface the the Map-Reply is set to the IP address of the outgoing interface the
Map-Reply destination address routes to. The Map-Reply SHOULD Map-Reply destination address routes to. The Map-Reply SHOULD
skipping to change at page 36, line 23 skipping to change at page 35, line 23
8. Interactions with Other LISP Components 8. Interactions with Other LISP Components
8.1. ITR EID-to-RLOC Mapping Resolution 8.1. ITR EID-to-RLOC Mapping Resolution
An ITR is configured with one or more Map-Resolver addresses. These An ITR is configured with one or more Map-Resolver addresses. These
addresses are "Locators" (or RLOCs) and MUST be routable on the addresses are "Locators" (or RLOCs) and MUST be routable on the
underlying core network; they MUST NOT need to be resolved through underlying core network; they MUST NOT need to be resolved through
LISP EID-to-RLOC mapping, as that would introduce a circular LISP EID-to-RLOC mapping, as that would introduce a circular
dependency. When using a Map-Resolver, an ITR does not need to dependency. When using a Map-Resolver, an ITR does not need to
connect to any other database mapping system. In particular, the ITR connect to any other database mapping system.
need not connect to the LISP-ALT infrastructure or implement the BGP
and GRE protocols that it uses.
An ITR sends an Encapsulated Map-Request to a configured Map-Resolver An ITR sends an Encapsulated Map-Request to a configured Map-Resolver
when it needs an EID-to-RLOC mapping that is not found in its local when it needs an EID-to-RLOC mapping that is not found in its local
Map-Cache. Using the Map-Resolver greatly reduces both the Map-Cache. Using the Map-Resolver greatly reduces both the
complexity of the ITR implementation and the costs associated with complexity of the ITR implementation and the costs associated with
its operation. its operation.
In response to an Encapsulated Map-Request, the ITR can expect one of In response to an Encapsulated Map-Request, the ITR can expect one of
the following: the following:
skipping to change at page 40, line 45 skipping to change at page 39, line 45
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 or distinct authentication keys to use their unique RLOC addresses, distinct authentication keys or
identify security associations with the Map-Servers. different XTR-IDs to identify security associations with the Map-
Servers.
9. Security Considerations 9. Security Considerations
A LISP threat analysis can be found in [RFC7835]. In what follows we A LISP threat analysis can be found in [RFC7835]. In what follows we
highlight security considerations that apply when LISP is deployed in highlight security considerations that apply when LISP is deployed in
environments such as those specified in Section 1.1, where the environments such as those specified in Section 1.1, where the
following assumptions hold: following assumptions hold:
1. The Mapping System is secure and trusted, and for the purpose of 1. The Mapping System is secure and trusted, and for the purpose of
this security considerations the Mapping System is considered as this security considerations the Mapping System is considered as
skipping to change at page 42, line 18 skipping to change at page 41, line 22
corresponding Map-Server. To mitigate this and as noted in corresponding Map-Server. To mitigate this and as noted in
Section 8.2, a Map-Server MUST verify that all EID-Prefixes Section 8.2, a Map-Server MUST verify that all EID-Prefixes
registered by an ETR match the configuration stored on the Map- registered by an ETR match the configuration stored on the Map-
Server. Server.
Deployments concerned about manipulations of Map-Request and Map- Deployments concerned about manipulations of Map-Request and Map-
Reply messages, and malicious ETR EID prefix overclaiming MUST drop Reply messages, and malicious ETR EID prefix overclaiming MUST drop
LISP Control Plane messages that do not contain LISP-SEC material LISP Control Plane messages that do not contain LISP-SEC material
(S-bit, EID-AD, OTK-AD, PKT-AD). (S-bit, EID-AD, OTK-AD, PKT-AD).
Encrypting control messages via DTLS [RFC6347] or LISP-crypto Mechanisms to encrypt, support privacy, prevent eavesdroping and
[RFC8061] SHOULD be used to support privacy to prevent eavesdroping packet tampering for messages exchanged between xTRs, xTRs and the
and packet tampering for messages exchanged between xTRs, xTRs and mapping system, and nodes that make up the mapping system, SHOULD be
the mapping system, and nodes that make up the mapping system. deployed. Examples of this are DTLS [RFC6347] or LISP-crypto
[RFC8061].
10. Privacy Considerations 10. Privacy Considerations
As noted by [RFC6973] privacy is a complex issue that greatly depends As noted by [RFC6973] privacy is a complex issue that greatly depends
on the specific protocol use-case and deployment. As noted in on the specific protocol use-case and deployment. As noted in
section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases
where entities communicate over the public Internet while keeping where entities communicate over the public Internet while keeping
separate addressing and topology. In what follows we detail the separate addressing and topology. In what follows we detail the
privacy threats introduced by the LISP Control Plane, the analysis is privacy threats introduced by the LISP Control Plane, the analysis is
based on the guidelines detailed in [RFC6973]. based on the guidelines detailed in [RFC6973].
skipping to change at page 43, line 7 skipping to change at page 42, line 11
authenticated, by querying the mapping system. Deployments concerned authenticated, by querying the mapping system. Deployments concerned
about this threat can use access control-lists or stronger about this threat can use access control-lists or stronger
authentication mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping authentication mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping
system to make sure that only authorized users can access this system to make sure that only authorized users can access this
information (data minimization). Use of ephemeral EIDs information (data minimization). Use of ephemeral EIDs
[I-D.ietf-lisp-eid-anonymity] to achieve anonymity is another [I-D.ietf-lisp-eid-anonymity] to achieve anonymity is another
mechanism to lessen persistency and identity tracking. mechanism to lessen persistency and identity tracking.
11. Changes since RFC 6833 11. Changes since RFC 6833
For implementation considerations, the following changes have been For implementation considerations, the following major changes have
made to this document since RFC 6833 was published: been 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
reliability for Map-Notify messages. Any receiver of a Map-Notify reliability for Map-Notify messages. Any receiver of a Map-Notify
message must respond with a Map-Notify-Ack message. Map-Servers message must respond with a Map-Notify-Ack message. Map-Servers
who are senders of Map-Notify messages, must queue the Map-Notify who are senders of Map-Notify messages, must queue the Map-Notify
contents until they receive a Map-Notify-Ack with the nonce used contents until they receive a Map-Notify-Ack with the nonce used
in the Map-Notify message. Note that implementations for Map- in the Map-Notify message. Note that implementations for Map-
Notify-Ack support already exist and predate this document. Notify-Ack support already exist and predate this document.
o This document is incorporating the codepoint for the Map-Referral o This document is incorporating the codepoint for the Map-Referral
message from the LISP-DDT specification [RFC8111] to indicate that message from the LISP-DDT specification [RFC8111] to indicate that
a Map-Server must send the final Map-Referral message when it a Map-Server must send the final Map-Referral message when it
participates in the LISP-DDT mapping system procedures. participates in the LISP-DDT mapping system procedures.
o The "m", "I", "L", and "D" bits are added to the Map-Request o The L" and "D" bits are added to the Map-Request message. See
message. See Section 5.3 for details. Section 5.3 for details.
o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- o The "S", "I", "E", "T", "a", "R", and "M" bits are added to the
Register message. See Section 5.6 for details. Map-Register message. See Section 5.6 for details.
o The 16-bit Key-ID field of the Map-Register message has been split o The 16-bit Key-ID field of the Map-Register message has been split
into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. into a 8-bit Key-ID field and a 8-bit Algorithm-ID field.
o The nonce and the authentication data in the Map-Register message
have a different behaviour, see Section 5.6 for details.
o This document adds two new Action values that are in an EID-record o This document adds two new Action values that are in an EID-record
that appear in Map-Reply, Map-Register, Map-Notify, and Map- that appear in Map-Reply, Map-Register, Map-Notify, and Map-
Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure
are the descriptions for the two new action values. See are the descriptions for the two new action values. See
Section 5.4 for details. Section 5.4 for details.
12. IANA Considerations 12. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to this Authority (IANA) regarding registration of values related to this
skipping to change at page 44, line 34 skipping to change at page 43, line 40
document. document.
Based on deployment experience of [RFC6830], the Map-Notify-Ack Based on deployment experience of [RFC6830], the Map-Notify-Ack
message, message type 5, was added by this document. This document message, message type 5, was added by this document. This document
requests IANA to add it to the LISP Packet Type Registry. requests IANA to add it to the LISP Packet Type Registry.
Name Number Defined in Name Number Defined in
---- ------ ----------- ---- ------ -----------
LISP Map-Notify-Ack 5 RFC6833bis LISP Map-Notify-Ack 5 RFC6833bis
12.3. LISP ACT and Flag Fields 12.3. LISP Map-Reply EID-Record Action Codes
New ACT values can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review or IESG approval.
Four values have already been allocated by [RFC6830], IANA is Four values have already been allocated by [RFC6830], IANA is
requested to replace the [RFC6830] reference for this registry with requested to replace the [RFC6830] reference for this registry with
the RFC number assigned to this document and the [RFC6830]. Action the RFC number assigned to this document and the [RFC6830]. Action
values references with the RFC number assigned to this document. values references with the RFC number assigned to this document.
This specification changes the name of ACT type 3 value from "Drop" This specification changes the name of ACT type 3 value from "Drop"
to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5).
+-------+--------------------+-------------------------+------------+ +-------+--------------------+-------------------------+------------+
| Value | Action | Description | Raeference | | Value | Action | Description | Raeference |
+-------+--------------------+-------------------------+------------+ +-------+--------------------+-------------------------+------------+
| 4 | Drop/Policy-Denied | A packet matching this | RFC6833bis | | 4 | Drop/Policy-Denied | A packet matching this | RFC6833bis |
| | | Map-Cache entry is | | | | | Map-Cache entry is | |
| | | dropped because the | | | | | dropped because | |
| | | target EWID is policy- | | | | | the target EWID is | |
| | | denied by the xTR or | | | | | policy-denied by the | |
| | | the mapping system. | | | | | xTR or the mapping | |
| | | system. | |
| 5 | Drop/Auth-Failure | Packet matching the | RFC6833bis | | 5 | Drop/Auth-Failure | Packet matching the | RFC6833bis |
| | | Map-Cache entry is | | | | | Map-Cache entry is | |
| | | dropped beacuse the | | | | | dropped beacuse the | |
| | | Map-Request for the | | | | | Map-Request for the | |
| | | target EID fails an | | | | | target EID fails an | |
| | | authentication check by | | | | | authentication check | |
| | | the xTR or the mapping | | | | | by the xTR or the | |
| | | system. | | | | | mapping system. | |
+-------+--------------------+-------------------------+------------+ +-------+--------------------+-------------------------+------------+
LISP Map-Reply Action Values LISP Map-Reply Action Values
In addition, LISP has a number of flag fields and reserved fields, In addition, LISP has a number of flag fields and reserved fields,
such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New
bits for flags in these fields can be implemented after IETF review bits for flags in these fields can be implemented after IETF review
or IESG approval, but these need not be managed by IANA. or IESG approval, but these need not be managed by IANA.
12.4. LISP Address Type Codes 12.4. LISP Address Type Codes
skipping to change at page 46, line 26 skipping to change at page 45, line 26
is on a first come first served basis. is on a first come first served basis.
12.6. LISP Bit Flags 12.6. LISP Bit Flags
This document asks IANA to create a registry for allocation of bits This document asks IANA to create a registry for allocation of bits
in several headers of the LISP control plane, namely in the Map- in several headers of the LISP control plane, namely in the Map-
Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM)
messages. Bit allocations are also requested for EID-records and messages. Bit allocations are also requested for EID-records and
RLOC-records. The registry created should be named "LISP Control RLOC-records. The registry created should be named "LISP Control
Plane Header Bits". A sub-registry needs to be created per each Plane Header Bits". A sub-registry needs to be created per each
message and record. The name of each sub-registry is indicated message and EID-record. The name of each sub-registry is indicated
below, along with its format and allocation of bits defined in this below, along with its format and allocation of bits defined in this
document. Any additional bits allocation, requires a specification, document. Any additional bits allocation, requires a specification,
according with [RFC8126] policies. according with [RFC8126] policies.
Sub-Registry: Map-Request Header Bits [Section 5.2]: Sub-Registry: Map-Request Header Bits [Section 5.2]:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|R| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+----------+---------------+------------+---------------------------+ +---------+---------------+-----------+-----------------------------+
| Spec | IANA Name | Bit | Description | | Spec | IANA Name | Bit | Description |
| Name | | Position | | | Name | | Position | |
+----------+---------------+------------+---------------------------+ +---------+---------------+-----------+-----------------------------+
| A | map-request-A | 4 | Authoritative Bit | | A | map-request-A | 4 | Authoritative Bit |
| M | map-request-M | 5 | Map Data Present Bit | | M | map-request-M | 5 | Map Data Present Bit |
| P | map-request-P | 6 | RLOC-Probe Request Bit | | P | map-request-P | 6 | RLOC-Probe Request Bit |
| S | map-request-S | 7 | Solicit Map-Request (SMR) | | S | map-request-S | 7 | Solicit Map-Request (SMR) |
| | | | Bit | | | | | Bit |
| p | map-request-p | 8 | Proxy-ITR Bit | | p | map-request-p | 8 | Proxy-ITR Bit |
| s | map-request-s | 9 | Solicit Map-Request | | s | map-request-s | 9 | Solicit Map-Request Invoked |
| | | | Invoked Bit | | | | | Bit |
| L | map-request-L | 17 | Local xTR Bit | | L | map-request-L | 17 | Local xTR Bit |
| D | map-request-D | 18 | Don't Map-Reply Bit | | D | map-request-D | 18 | Don't Map-Reply Bit |
+----------+---------------+------------+---------------------------+ +---------+---------------+-----------+-----------------------------+
LISP Map-Request Header Bits LISP Map-Request Header Bits
Sub-Registry: Map-Reply Header Bits [Section 5.4]: Sub-Registry: Map-Reply Header Bits [Section 5.4]:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count | |Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 49, line 28 skipping to change at page 48, line 28
LISP RLOC-Record Header Bits LISP RLOC-Record Header Bits
13. References 13. References
13.1. Normative References 13.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-03 (work in progress), February 2019. lisp-6834bis-04 (work in progress), August 2019.
[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-26 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress),
November 2018. June 2019.
[I-D.ietf-lisp-rfc8113bis] [I-D.ietf-lisp-rfc8113bis]
Boucadair, M. and C. Jacquenet, "Locator/ID Separation Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", draft-ietf-lisp- for Packet Type Allocations", draft-ietf-lisp-
rfc8113bis-03 (work in progress), January 2019. rfc8113bis-03 (work in progress), January 2019.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-18 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-19
(work in progress), June 2019. (work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
skipping to change at page 51, line 8 skipping to change at page 50, line 8
2015. 2015.
[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-ecdsa-auth] [I-D.ietf-lisp-ecdsa-auth]
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
Authentication and Authorization", draft-ietf-lisp-ecdsa- Authentication and Authorization", draft-ietf-lisp-ecdsa-
auth-01 (work in progress), March 2019. auth-02 (work in progress), September 2019.
[I-D.ietf-lisp-eid-anonymity] [I-D.ietf-lisp-eid-anonymity]
Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
EID Anonymity", draft-ietf-lisp-eid-anonymity-06 (work in EID Anonymity", draft-ietf-lisp-eid-anonymity-07 (work in
progress), April 2019. progress), October 2019.
[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-04 Unified Control Plane", draft-ietf-lisp-eid-mobility-04
(work in progress), May 2019. (work in progress), May 2019.
[I-D.ietf-lisp-gpe] [I-D.ietf-lisp-gpe]
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M.
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- Smith, "LISP Generic Protocol Extension", draft-ietf-lisp-
gpe-06 (work in progress), September 2018. gpe-09 (work in progress), October 2019.
[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-05 (work in progress), Mobile Node", draft-ietf-lisp-mn-06 (work in progress),
March 2019. September 2019.
[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-03 (work in progress), March 2019. pubsub-04 (work in progress), September 2019.
[I-D.ietf-nvo3-vxlan-gpe] [I-D.ietf-nvo3-vxlan-gpe]
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-07 (work Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-08 (work
in progress), April 2019. in progress), October 2019.
[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.
skipping to change at page 55, line 30 skipping to change at page 54, line 30
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper,
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The
contributions they offered greatly added to the security, scale, and contributions they offered greatly added to the security, scale, and
robustness of the LISP architecture and protocols. robustness of the LISP architecture and protocols.
Appendix B. Document Change Log 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-25 B.1. Changes to draft-ietf-lisp-rfc6833bis-26
o Posted November 2019.
o Fixed the required (MUST implement) authentcation algorithms.
o Fixed a large set of minor comments and edits.
B.2. Changes to draft-ietf-lisp-rfc6833bis-25
o Posted June 2019. o Posted June 2019.
o Added change requested by Mirja describing Record Count in an EID- o Added change requested by Mirja describing Record Count in an EID-
record. record.
o Fixed Requirements Notation section per Pete. o Fixed Requirements Notation section per Pete.
o Added KDF for shared-secret o Added KDF for shared-secret
o Specified several rate-limiters for control messages o Specified several rate-limiters for control messages
B.2. Changes to draft-ietf-lisp-rfc6833bis-24 B.3. Changes to draft-ietf-lisp-rfc6833bis-24
o Posted February 2019. o Posted February 2019.
o Added suggested text from Albert that Benjamin Kaduk agreed with. o Added suggested text from Albert that Benjamin Kaduk agreed with.
o Added suggested editorial comments from Alvaro's rewview. o Added suggested editorial comments from Alvaro's rewview.
o Ran document through IDnits. Fixed bugs found. o Ran document through IDnits. Fixed bugs found.
B.3. Changes to draft-ietf-lisp-rfc6833bis-23 B.4. Changes to draft-ietf-lisp-rfc6833bis-23
o Posted December 2018. o Posted December 2018.
o Added to Security Considerations section that deployments that o Added to Security Considerations section that deployments that
care about prefix over claiming should use LISP-SEC. care about prefix over claiming should use LISP-SEC.
o Added to Security Considerations section that DTLS or LISP-crypto o Added to Security Considerations section that DTLS or LISP-crypto
be used for control-plane privacy. be used for control-plane privacy.
o Make LISP-SEC a normative reference. o Make LISP-SEC a normative reference.
o Make it more clear where field descriptions are spec'ed when o Make it more clear where field descriptions are spec'ed when
referencing to the same fields in other packet types. referencing to the same fields in other packet types.
B.4. Changes to draft-ietf-lisp-rfc6833bis-22 B.5. Changes to draft-ietf-lisp-rfc6833bis-22
o Posted week after IETF November 2018. o Posted week after IETF November 2018.
o No longer need to use IPSEC for replay attacks. o No longer need to use IPSEC for replay attacks.
B.5. Changes to draft-ietf-lisp-rfc6833bis-21 B.6. Changes to draft-ietf-lisp-rfc6833bis-21
o Posted early November 2018. o Posted early November 2018.
o Added I-bit back in because its necessary to use for Map-Register o Added I-bit back in because its necessary to use for Map-Register
replay attack scenarios. The Map-Server tracks the nonce per xTR- replay attack scenarios. The Map-Server tracks the nonce per xTR-
ID to detect duplicate or replayed Map-Register messages. ID to detect duplicate or replayed Map-Register messages.
B.6. Changes to draft-ietf-lisp-rfc6833bis-20 B.7. Changes to draft-ietf-lisp-rfc6833bis-20
o Posted late October 2018. o Posted late October 2018.
o Changed description about "reserved" bits to state "reserved and o Changed description about "reserved" bits to state "reserved and
unassigned". unassigned".
o Make it more clear how Map-Register nonce processing is performed o Make it more clear how Map-Register nonce processing is performed
in an ETR and Map-Server. in an ETR and Map-Server.
B.7. Changes to draft-ietf-lisp-rfc6833bis-19 B.8. Changes to draft-ietf-lisp-rfc6833bis-19
o Posted mid October 2018. o Posted mid October 2018.
o Added Fabio text to the Security Considerations section. o Added Fabio text to the Security Considerations section.
B.8. Changes to draft-ietf-lisp-rfc6833bis-18 B.9. Changes to draft-ietf-lisp-rfc6833bis-18
o Posted mid October 2018. o Posted mid October 2018.
o Fixed comments from Eric after more email clarity. o Fixed comments from Eric after more email clarity.
B.9. Changes to draft-ietf-lisp-rfc6833bis-17 B.10. Changes to draft-ietf-lisp-rfc6833bis-17
o Posted early October 2018. o Posted early October 2018.
o Changes to reflect comments from Sep 27th Telechat. o Changes to reflect comments from Sep 27th Telechat.
o Added all flag bit definitions as request for allocation in IANA o Added all flag bit definitions as request for allocation in IANA
Considersations section. Considersations section.
o Added an applicability statement in section 1 to address security o Added an applicability statement in section 1 to address security
concerns from Telechat. concerns from Telechat.
o Moved m-bit description and IANA request to draft-ietf-lisp-mn. 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- o Moved I-bit description and IANA request to draft-ietf-lisp-
pubsub. pubsub.
B.10. Changes to draft-ietf-lisp-rfc6833bis-16 B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-15 B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-14 B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-13 B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-12 B.15. 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.15. Changes to draft-ietf-lisp-rfc6833bis-11 B.16. 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.16. Changes to draft-ietf-lisp-rfc6833bis-10 B.17. 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.17. Changes to draft-ietf-lisp-rfc6833bis-09 B.18. 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.18. Changes to draft-ietf-lisp-rfc6833bis-08 B.19. 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.19. Changes to draft-ietf-lisp-rfc6833bis-07 B.20. 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 59, line 37 skipping to change at page 58, line 39
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.20. Changes to draft-ietf-lisp-rfc6833bis-06 B.21. 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.21. Changes to draft-ietf-lisp-rfc6833bis-05 B.22. 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.22. Changes to draft-ietf-lisp-rfc6833bis-04 B.23. 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.23. Changes to draft-ietf-lisp-rfc6833bis-03 B.24. 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.24. Changes to draft-ietf-lisp-rfc6833bis-02 B.25. 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.25. Changes to draft-ietf-lisp-rfc6833bis-01 B.26. 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.26. Changes to draft-ietf-lisp-rfc6833bis-00 B.27. 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.27. Changes to draft-farinacci-lisp-rfc6833bis-00 B.28. 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. 83 change blocks. 
244 lines changed or deleted 217 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/