draft-ietf-lisp-rfc6833bis-23.txt   draft-ietf-lisp-rfc6833bis-24.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Obsoletes: 6833 (if approved) Cisco Systems Obsoletes: 6830, 6833 (if approved) Cisco Systems
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track A. Cabellos (Ed.)
Expires: June 13, 2019 UPC/BarcelonaTech Expires: August 8, 2019 UPC/BarcelonaTech
December 10, 2018 February 4, 2019
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-23 draft-ietf-lisp-rfc6833bis-24
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this Control-Plane service interface and communicating with By using this Control-Plane service interface and communicating with
Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and
Egress Tunnel Routers (ETRs) are not dependent on the details of Egress Tunnel Routers (ETRs) are not dependent on the details of
mapping database systems, which facilitates modularity with different mapping database systems, which facilitates modularity with different
database designs. Since these devices implement the "edge" of the database designs. Since these devices implement the "edge" of the
LISP Control-Plane infrastructure, 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.
This document obsoletes RFC 6830 and 6833. This document obsoletes RFC 6830 and RFC 6833.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2019. This Internet-Draft will expire on August 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . 15 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15
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
skipping to change at page 3, line 5 skipping to change at page 3, line 5
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 40
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 40
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 42
11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43 11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44
12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44 12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 44
12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44 12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 44
12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45 12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 45
12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 45 12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 46
12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46 12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
13.1. Normative References . . . . . . . . . . . . . . . . . . 49 13.1. Normative References . . . . . . . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . 50 13.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 55
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 55 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 55
B.1. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 55 B.1. Changes to draft-ietf-lisp-rfc6833bis-24 . . . . . . . . 55
B.2. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 55 B.2. Changes to draft-ietf-lisp-rfc6833bis-23 . . . . . . . . 55
B.3. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 56 B.3. Changes to draft-ietf-lisp-rfc6833bis-22 . . . . . . . . 56
B.4. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 56 B.4. Changes to draft-ietf-lisp-rfc6833bis-21 . . . . . . . . 56
B.5. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56 B.5. Changes to draft-ietf-lisp-rfc6833bis-20 . . . . . . . . 56
B.6. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 56 B.6. Changes to draft-ietf-lisp-rfc6833bis-19 . . . . . . . . 56
B.7. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 56 B.7. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 56
B.8. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57 B.8. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 56
B.9. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 57 B.9. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 57
B.10. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 57 B.10. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 57
B.11. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 57 B.11. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 57
B.12. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 57 B.12. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 57
B.13. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 57 B.13. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 57
B.14. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 58 B.14. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 58
B.15. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 58 B.15. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 58
B.16. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 58 B.16. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 58
B.17. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 58 B.17. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 58
B.18. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59 B.18. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 58
B.19. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 59 B.19. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 59
B.20. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 59 B.20. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 59
B.21. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60 B.21. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 59
B.22. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60 B.22. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 60
B.23. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60 B.23. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 60
B.24. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 60 B.24. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 60
B.25. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 60 B.25. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 60
B.26. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 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
skipping to change at page 4, line 46 skipping to change at page 4, line 47
LISP is not intended to address problems of connectivity and scaling LISP is not intended to address problems of connectivity and scaling
on behalf of arbitrary communicating parties. Relevant situations on behalf of arbitrary communicating parties. Relevant situations
are described in the scoping section of the introduction to are described in the scoping section of the introduction to
[I-D.ietf-lisp-rfc6830bis]. [I-D.ietf-lisp-rfc6830bis].
This document obsoletes RFC 6830 and 6833. This document obsoletes RFC 6830 and 6833.
1.1. Scope of Applicability 1.1. Scope of Applicability
LISP was originally developed to address the Internet-wide route LISP was originally developed to address the Internet-wide route
scaling problem [RFC4984].. While there are a number of approaches scaling problem [RFC4984]. While there are a number of approaches of
of interest for that problem, as LISP as been developed and refined, interest for that problem, as LISP as been developed and refined, a
a large number of other LISP uses have been found and are being used. large number of other LISP uses have been found and are being used.
As such, the design and development of LISP has changed so as to As such, the design and development of LISP has changed so as to
focus on these use cases. The common property of these uses is a focus on these use cases. The common property of these uses is a
large set of cooperating entities seeking to communicate over the large set of cooperating entities seeking to communicate over the
public Internet or other large underlay IP infrastructures, while public Internet or other large underlay IP infrastructures, while
keeping the addressing and topology of the cooperating entities keeping the addressing and topology of the cooperating entities
separate from the underlay and Internet topology, routing, and separate from the underlay and Internet topology, routing, and
addressing. addressing.
2. Requirements Notation 2. Requirements Notation
In many IETF documents, several words, when they are in all capitals
as shown below, are used to signify the requirements in the
specification. These capitalized words can bring significant clarity
and consistency to documents because their meanings are well defined.
This document defines how those words are interpreted in IETF
documents when the words are in all capitals.
o These words can be used as defined here, but using them is not
required. Specifically, normative text does not require the use
of these key words. They are used for clarity and consistency
when that is what's wanted, but a lot of normative text does not
use them and is still normative.
o The words have the meanings specified herein only when they are in
all capitals.
o When these words are not capitalized, they have their normal
English meanings and are not affected by this document.
Authors who follow these guidelines should incorporate this phrase
near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Definition of Terms 3. Definition of Terms
Map-Server: A network infrastructure component that learns of EID- Map-Server: A network infrastructure component that learns of EID-
Prefix mapping entries from an ETR, via the registration mechanism Prefix mapping entries from an ETR, via the registration mechanism
skipping to change at page 11, line 10 skipping to change at page 11, line 10
The format of control messages includes the UDP header so the The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit message checksum and length fields can be used to protect and delimit message
boundaries. boundaries.
5.1. LISP Control Packet Type Allocations 5.1. LISP Control Packet Type Allocations
This section defines the LISP control message formats and summarizes This section defines the LISP control message formats and summarizes
for IANA the LISP Type codes assigned by this document. For for IANA the LISP Type codes assigned by this document. For
completeness, the summary below includes the LISP Shared Extension completeness, the summary below includes the LISP Shared Extension
Message assigned by [RFC8113]. Message type definitions are: Message assigned by [I-D.ietf-lisp-rfc8113bis]. Message type
definitions are:
Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110'
Not Assigned 7 b'0111'
LISP Encapsulated Control Message: 8 b'1000'
Not Assigned 9-14 b'1001'- b'1110'
LISP Shared Extension Message: 15 b'1111' [RFC8113]
Values in the "Not Assigned" range can be assigned according to Reserved: 0 b'0000'
procedures in [RFC8126]. LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110'
Unassigned 7 b'0111'
LISP Encapsulated Control Message: 8 b'1000'
Unassigned 9-14 b'1001'- b'1110'
LISP Shared Extension Message: 15 b'1111'
Protocol designers experimenting with new message formats are Protocol designers experimenting with new message formats are
recommended to use the LISP Shared Extension Message Type described recommended to use the LISP Shared Extension Message Type described
in [RFC8113]. in [I-D.ietf-lisp-rfc8113bis].
All LISP Control-Plane messages use Address Family Identifiers (AFI) All LISP Control-Plane messages use Address Family Identifiers (AFI)
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
encode either fixed or variable length addresses. This includes encode either fixed or variable length addresses. This includes
explicit fields in each control message or part of EID-records or explicit fields in each control message or part of EID-records or
RLOC-records in commonly formatted messages. RLOC-records in commonly formatted messages.
The LISP control-plane describes how other data-planes can encode The LISP control-plane describes how other data-planes can encode
messages to support the Soliciting of Map-Requests as well as RLOC- messages to support the Soliciting of Map-Requests as well as RLOC-
probing procedures. probing procedures.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
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 SHOULD
be treated as a Locator reachability probe. The receiver SHOULD be treated as a Locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating that respond with a Map-Reply with the probe-bit set, indicating that
the Map-Reply is a Locator reachability probe reply, with the the Map-Reply is a Locator reachability probe reply, with the
nonce copied from the Map-Request. See RLOC-Probing Section 7.1 nonce copied from the Map-Request. See RLOC-Probing Section 7.1
for more details. 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.
p: This is the PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a PITR sends a
Map-Request. Map-Request.
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
skipping to change at page 28, line 49 skipping to change at page 28, line 49
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 4/5 (Map-Notify/Map-Notify-Ack) Type: 4/5 (Map-Notify/Map-Notify-Ack)
The Map-Notify message has the same contents as a Map-Register The Map-Notify message has the same contents as a Map-Register
message. See the Map-Register section for field descriptions and the message. See the Map-Register section for field descriptions and the
Map-Reply section for EID-record and RLOC-record descriptions. Map-Reply section for EID-record and RLOC-record descriptions.
The fields of the Map-Notify are copied from the corresponding Map-
Register to acknowledge its correct processing. For an unsolicited
Map-Notify, the fields of a Map-Notify used for publish/subscribe are
specified in [I-D.ietf-lisp-pubsub]].
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
(solicited or unsolicited) and for the sender to stop retransmitting (solicited or unsolicited) and for the sender to stop retransmitting
a Map-Notify with the same nonce. a Map-Notify with the same nonce. The fields of the Map-Notify-Ack
are copied from the corresponding Map-Notify message to acknowledge
its correct processing.
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 for another 3 retransmission
skipping to change at page 41, line 40 skipping to change at page 41, line 40
attacker to mount DoS and/or amplification attacks. Attackers can attacker to mount DoS and/or amplification attacks. Attackers can
send Map-Requests at high rates to overload LISP nodes and increase send Map-Requests at high rates to overload LISP nodes and increase
the state maintained by such nodes or consume CPU cycles. Such the state maintained by such nodes or consume CPU cycles. Such
threats can be mitigated by systematically applying filters and rate threats can be mitigated by systematically applying filters and rate
limiters. limiters.
The 2-way LISP control-plane header nonce exchange can be used to The 2-way LISP control-plane header nonce exchange can be used to
avoid ITR spoofing attacks, but active on-path attackers (e.g 'man- avoid ITR spoofing attacks, but active on-path attackers (e.g 'man-
in-the-middle') capable of intercepting the nonce can exploit the in-the-middle') capable of intercepting the nonce can exploit the
Map-Request/Map-Reply message exchange to inject forged mappings Map-Request/Map-Reply message exchange to inject forged mappings
directly in the ITR EID-to-RLOC map-cache. In addition, valid ETRs directly in the ITR EID-to-RLOC map-cache. This can lead to traffic
in the system can perform overclaiming attacks. In this case, being redirected to the attacker, see further details in [RFC7835].
attackers can claim to own an EID-prefix that is larger than the In addition, valid ETRs in the system can perform overclaiming
prefix owned by the ETR. Such attacks can be addressed by using attacks. In this case, attackers can claim to own an EID-prefix that
LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC protocol defines a is larger than the prefix owned by the ETR. Such attacks can be
mechanism for providing origin authentication, integrity, anti- addressed by using LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC
replay, protection, and prevention of 'man-in-the-middle' and 'prefix protocol defines a mechanism for providing origin authentication,
overclaiming' attacks on the Map-Request/Map-Reply exchange. In integrity, anti-replay, protection, and prevention of 'man-in-the-
addition and while beyond the scope of securing an individual Map- middle' and 'prefix overclaiming' attacks on the Map-Request/Map-
Server or Map-Resolver, it should be noted that LISP-SEC can be Reply exchange. In addition and while beyond the scope of securing
complemented by additional security mechanisms defined by the Mapping an individual Map-Server or Map-Resolver, it should be noted that
System Infrastructure. For instance, BGP-based LISP-ALT [RFC6836] LISP-SEC can be complemented by additional security mechanisms
can take advantage of standards work on adding security to BGP while defined by the Mapping System Infrastructure. For instance, BGP-
LISP-DDT [RFC8111] defines its own additional security mechanisms. based LISP-ALT [RFC6836] can take advantage of standards work on
adding security to BGP while LISP-DDT [RFC8111] defines its own
additional security mechanisms.
To publish an authoritative EID-to-RLOC mapping with a Map-Server To publish an authoritative EID-to-RLOC mapping with a Map-Server
using the Map-Register message, an ETR includes authentication data using the Map-Register message, an ETR includes authentication data
that is a MAC of the entire message using a pair-wise shared key. An that is a MAC of the entire message using a pair-wise shared key. An
implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD implementation MUST support use of HMAC-SHA-1-96 [RFC2104] and SHOULD
support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128 support use of HMAC-SHA-256-128 [RFC6234] (SHA-256 truncated to 128
bits). The Map-Register message is vulnerable to replay attacks by a bits). The Map-Register message is vulnerable to replay attacks by a
man-in-the-middle. A compromised ETR can overclaim the prefix it man-in-the-middle. A compromised ETR can overclaim the prefix it
owns and successfully register it on its corresponding Map-Server. owns and successfully register it on its corresponding Map-Server.
To mitigate this and as noted in Section 8.2, a Map-Server SHOULD To mitigate this and as noted in Section 8.2, a Map-Server SHOULD
skipping to change at page 45, line 9 skipping to change at page 45, line 9
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 Reference +-------+--------------------+-------------------------+------------+
----- ------ ----------- --------- | Value | Action | Description | Raeference |
4 Drop/ A Packet matching this Map-Cache RFC6833bis +-------+--------------------+-------------------------+------------+
Policy-Denied entry is dropped because the target | 4 | Drop/Policy-Denied | A packet matching this | RFC6833bis |
EID is policy-denied by the xTR or | | | Map-Cache entry is | |
the mapping system. | | | dropped because the | |
| | | target EWID is policy- | |
| | | denied by the xTR or | |
| | | the mapping system. | |
| 5 | Drop/Auth-Failure | Packet matching the | RFC6833bis |
| | | Map-Cache entry is | |
| | | dropped beacuse the | |
| | | Map-Request for the | |
| | | target EID fails an | |
| | | authentication check by | |
| | | the xTR or the mapping | |
| | | system. | |
+-------+--------------------+-------------------------+------------+
5 Drop/ A Packet matching this Map-Cache RFC6833bis LISP Map-Reply Action Values
Auth-Failure entry is dropped because the
Map-Request for target EID fails an
authentication check by the xTR or
the mapping system.
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
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that
defines LISP-specific encodings for AFI value 16387. LCAF encodings defines LISP-specific encodings for AFI value 16387. LCAF encodings
skipping to change at page 46, line 25 skipping to change at page 46, line 34
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 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 [RFC5226] 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 |
skipping to change at page 49, line 20 skipping to change at page 49, line 36
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf- Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), September 2018.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress),
November 2018. November 2018.
[I-D.ietf-lisp-rfc8113bis]
Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", draft-ietf-lisp-
rfc8113bis-03 (work in progress), January 2019.
[I-D.ietf-lisp-sec] [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-17 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-17
(work in progress), November 2018. (work in progress), November 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap", RFC 6071,
DOI 10.17487/RFC6071, February 2011,
<https://www.rfc-editor.org/info/rfc6071>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/assignments/address-family- NUMBERS http://www.iana.org/assignments/address-family-
numbers/address-family-numbers.xhtml?, Febuary 2007. numbers/address-family-numbers.xhtml?, Febuary 2007.
[GTP-3GPP] [GTP-3GPP]
3GPP, "General Packet Radio System (GPRS) Tunnelling 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", TS.29.281 Protocol User Plane (GTPv1-U)", TS.29.281
https://portal.3gpp.org/desktopmodules/Specifications/ https://portal.3gpp.org/desktopmodules/Specifications/
skipping to change at page 52, line 5 skipping to change at page 52, line 23
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, DOI 10.17487/RFC1071, Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
September 1988, <https://www.rfc-editor.org/info/rfc1071>. September 1988, <https://www.rfc-editor.org/info/rfc1071>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>. <https://www.rfc-editor.org/info/rfc2890>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
skipping to change at page 53, line 31 skipping to change at page 53, line 47
[RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
(LISP) Data-Plane Confidentiality", RFC 8061, (LISP) Data-Plane Confidentiality", RFC 8061,
DOI 10.17487/RFC8061, February 2017, DOI 10.17487/RFC8061, February 2017,
<https://www.rfc-editor.org/info/rfc8061>. <https://www.rfc-editor.org/info/rfc8061>.
[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A.
Smirnov, "Locator/ID Separation Protocol Delegated Smirnov, "Locator/ID Separation Protocol Delegated
Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111,
May 2017, <https://www.rfc-editor.org/info/rfc8111>. May 2017, <https://www.rfc-editor.org/info/rfc8111>.
[RFC8113] Boucadair, M. and C. Jacquenet, "Locator/ID Separation
Protocol (LISP): Shared Extension Message & IANA Registry
for Packet Type Allocations", RFC 8113,
DOI 10.17487/RFC8113, March 2017,
<https://www.rfc-editor.org/info/rfc8113>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID
Separation Protocol (LISP) Multicast", RFC 8378, Separation Protocol (LISP) Multicast", RFC 8378,
DOI 10.17487/RFC8378, May 2018, DOI 10.17487/RFC8378, May 2018,
<https://www.rfc-editor.org/info/rfc8378>. <https://www.rfc-editor.org/info/rfc8378>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
skipping to change at page 55, line 30 skipping to change at page 55, 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-23 B.1. Changes to draft-ietf-lisp-rfc6833bis-24
o Posted February 2019.
o Added suggested text from Albert that Benjamin Kaduk agreed with.
o Added suggested editorial comments from Alvaro's rewview.
o Ran document through IDnits. Fixed bugs found.
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-22 B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-21 B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-20 B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-19 B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-18 B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-17 B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-16 B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-15 B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-14 B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-13 B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-12 B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-11 B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-10 B.15. 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.15. Changes to draft-ietf-lisp-rfc6833bis-09 B.16. 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.16. Changes to draft-ietf-lisp-rfc6833bis-08 B.17. 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.17. Changes to draft-ietf-lisp-rfc6833bis-07 B.18. 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 13 skipping to change at page 59, line 19
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.18. Changes to draft-ietf-lisp-rfc6833bis-06 B.19. 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.19. Changes to draft-ietf-lisp-rfc6833bis-05 B.20. 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.20. Changes to draft-ietf-lisp-rfc6833bis-04 B.21. 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.21. Changes to draft-ietf-lisp-rfc6833bis-03 B.22. 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.22. Changes to draft-ietf-lisp-rfc6833bis-02 B.23. 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.23. Changes to draft-ietf-lisp-rfc6833bis-01 B.24. 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.24. Changes to draft-ietf-lisp-rfc6833bis-00 B.25. 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.25. Changes to draft-farinacci-lisp-rfc6833bis-00 B.26. 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. 54 change blocks. 
142 lines changed or deleted 179 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/