draft-ietf-lisp-rfc6833bis-15.txt   draft-ietf-lisp-rfc6833bis-16.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Obsoletes: 6833 (if approved) Cisco Systems Obsoletes: 6833 (if approved) Cisco Systems
Intended status: Standards Track A. Cabellos (Ed.) Intended status: Standards Track A. Cabellos (Ed.)
Expires: March 22, 2019 UPC/BarcelonaTech Expires: March 30, 2019 UPC/BarcelonaTech
September 18, 2018 September 26, 2018
Locator/ID Separation Protocol (LISP) Control-Plane Locator/ID Separation Protocol (LISP) Control-Plane
draft-ietf-lisp-rfc6833bis-15 draft-ietf-lisp-rfc6833bis-16
Abstract Abstract
This document describes the Control-Plane and Mapping Service for the This document describes the Control-Plane and Mapping Service for the
Locator/ID Separation Protocol (LISP), implemented by two new types Locator/ID Separation Protocol (LISP), implemented by two new types
of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server
-- that provides a simplified "front end" for one or more Endpoint ID -- that provides a simplified "front end" for one or more Endpoint ID
to Routing Locator mapping databases. to Routing Locator mapping databases.
By using this Control-Plane service interface and communicating with By using this Control-Plane service interface and communicating with
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2019. This Internet-Draft will expire on March 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32
8. Interactions with Other LISP Components . . . . . . . . . . . 33 8. Interactions with Other LISP Components . . . . . . . . . . . 33
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 34 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 34
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 36 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 36
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 37 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 40
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 40
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 40 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 41
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . 41 12.1. Normative References . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 47
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 47
B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 46 B.1. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 47
B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 46 B.2. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 47
B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 46 B.3. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 47
B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 46 B.4. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 47
B.5. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 46 B.5. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 48
B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 47 B.6. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 48
B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 47 B.7. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 48
B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 47 B.8. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 48
B.9. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 47 B.9. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 48
B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 48 B.10. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 48
B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 48 B.11. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 49
B.12. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 48 B.12. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 49
B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 49 B.13. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 49
B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 49 B.14. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 50
B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 49 B.15. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 50
B.16. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 49 B.16. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 50
B.17. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49 B.17. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 B.18. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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
skipping to change at page 9, line 9 skipping to change at page 9, line 9
checksum fails, the control message MUST be dropped [RFC1071]. checksum fails, the control message MUST be dropped [RFC1071].
The format of control messages includes the UDP header so the The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit message checksum and length fields can be used to protect and delimit message
boundaries. boundaries.
5.1. LISP Control Packet Type Allocations 5.1. LISP Control Packet Type Allocations
This section defines the LISP control message formats and summarizes This section defines the LISP control message formats and summarizes
for IANA the LISP Type codes assigned by this document. For for IANA the LISP Type codes assigned by this document. For
completeness, this document references the LISP Shared Extension completeness, the summary below includes the LISP Shared Extension
Message assigned by [RFC8113]. Message type definitions are: Message assigned by [RFC8113]. Message type definitions are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Map-Notify-Ack: 5 b'0101' LISP Map-Notify-Ack: 5 b'0101'
LISP Map-Referral: 6 b'0110' LISP Map-Referral: 6 b'0110'
Not Assigned 7 b'0111' Not Assigned 7 b'0111'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
Not Assigned 9-14 b'1001'- b'1110' Not Assigned 9-14 b'1001'- b'1110'
LISP Shared Extension Message: 15 b'1111' [RFC8113] LISP Shared Extension Message: 15 b'1111' [RFC8113]
Values in the "Not Assigned" range can be assigned according to Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126]. Documents that request for a new LISP procedures in [RFC8126].
packet type may indicate a preferred value.
Protocol designers experimenting with new message formats SHOULD use Protocol designers experimenting with new message formats are
the LISP Shared Extension Message Type and request a [RFC8113] sub- recommended to use the LISP Shared Extension Message Type described
type assignment. in [RFC8113].
All LISP Control-Plane messages use Address Family Identifiers (AFI) All LISP Control-Plane messages use Address Family Identifiers (AFI)
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to
encode either fixed or variable length addresses. This includes encode either fixed or variable length addresses. This includes
explicit fields in each control message or part of EID-records or explicit fields in each control message or part of EID-records or
RLOC-records in commonly formatted messages. RLOC-records in commonly formatted messages.
The LISP control-plane describes how other data-planes can encode The LISP control-plane describes how other data-planes can encode
messages to support the SMR and RLOC-probing procedures. messages to support the SMR and RLOC-probing procedures.
skipping to change at page 37, line 50 skipping to change at page 37, line 50
routing, to facilitate the use of a topologically close Map-Resolver routing, to facilitate the use of a topologically close Map-Resolver
by each ITR. by each ITR.
ETRs MAY have anycast RLOC addresses which are registered as part of ETRs MAY have anycast RLOC addresses which are registered as part of
their RLOC-set to the mapping system. However, registrations MUST their RLOC-set to the mapping system. However, registrations MUST
use their unique RLOC addresses, xTR-IDs, or distinct authentication use their unique RLOC addresses, xTR-IDs, or distinct authentication
keys to identify security associations with the Map-Servers. keys to identify security associations with the Map-Servers.
9. Security Considerations 9. Security Considerations
The 2-way LISP header nonce exchange documented in The Map-Request/Map-Reply message exchange can be exploited by an
[I-D.ietf-lisp-rfc6830bis] can be used to avoid ITR spoofing attacks. attacker to mount DoS and/or amplification attacks. Attackers can
send Map-Requests at high rates to overload LISP nodes and increase
To publish an authoritative EID-to-RLOC mapping with a Map-Server, an the state maintained by such nodes or consume CPU cycles. Such
ETR includes authentication data that is a hash of the message using threats can be mitigated by systematically applying filters and rate
a pair-wise shared key. An implementation MUST support use of HMAC- limiters.
SHA-1-96 [RFC2104] and SHOULD support use of HMAC-SHA-256-128
[RFC6234] (SHA-256 truncated to 128 bits).
As noted in Section 8.2, a Map-Server SHOULD verify that all EID-
Prefixes registered by an ETR match the configuration stored on the
Map-Server.
The currently defined authentication mechanism for Map-Register
messages does not provide protection against "replay" attacks by a
"man-in-the-middle". Additional work is needed in this area.
[I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin The 2-way LISP control-plane header nonce exchange can be used to
authentication, integrity, anti-replay protection, and prevention of avoid ITR spoofing attacks, but active on-path attackers (e.g 'man-
man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- in-the-middle') capable of intercepting the nonce can exploit the
Reply exchange. Work is ongoing on this and other proposals for Map-Request/Map-Reply message exchange to inject forged mappings
resolving these open security issues. directly in the ITR EID-to-RLOC map-cache. In addition, valid ETRs
in the system can perform overclaiming attacks. In this case,
attackers can claim to own an EID-prefix that is larger than the
prefix owned by the ETR. Such attacks can be addressed by using
LISP-SEC [I-D.ietf-lisp-sec]. The LISP-SEC protocol defines a
mechanism for providing origin authentication, integrity, anti-
replay, protection, and prevention of 'man-in-the-middle' and 'prefix
overclaiming' attacks on the Map-Request/Map-Reply exchange. In
addition and while beyond the scope of securing an individual Map-
Server or Map-Resolver, it should be noted that LISP-SEC can be
complemented by additional security mechanisms defined by the Mapping
System Infrastructure. For instance, BGP-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.
While beyond the scope of securing an individual Map-Server or Map- To publish an authoritative EID-to-RLOC mapping with a Map-Server
Resolver, it should be noted that a BGP-based LISP-ALT network (if using the Map-Register message, an ETR includes authentication data
ALT is used as the mapping database infrastructure) can take that is a hash of the entire message using a pair-wise shared key.
advantage of standards work on adding security to BGP. An 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 bits). The Map-Register message is vulnerable to replay
attacks by a man-in-the-middle. Deployments that are concerned with
active man-in-the-middle attacks to the Map-Register message SHOULD
use a transport-level integrity and anti-reply protection mechanism
such as IPSEC [RFC6071]. In addition, a compromised ETR can
overclaim the prefix it owns and successfully register it on its
corresponding Map-Server. To mitigate this and as noted in
Section 8.2, a Map-Server SHOULD verify that all EID-Prefixes
registered by an ETR match the configuration stored on the Map-
Server.
A complete LISP threat analysis has been published in [RFC7835]. A complete LISP threat analysis has been published in [RFC7835].
Please refer to it for more security related details. Please refer to it for more detailed security related details.
10. Changes since RFC 6833 10. Changes since RFC 6833
For implementation considerations, the following changes have been For implementation considerations, the following changes have been
made to this document since RFC 6833 was published: made to this document since RFC 6833 was published:
o A Map-Notify-Ack message is added in this document to provide o A Map-Notify-Ack message is added in this document to provide
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
skipping to change at page 39, line 47 skipping to change at page 40, line 18
Control-Plane. IANA has updated the description for UDP port 4342 as Control-Plane. IANA has updated the description for UDP port 4342 as
follows: follows:
Keyword Port Transport Layer Description Keyword Port Transport Layer Description
------- ---- --------------- ----------- ------- ---- --------------- -----------
lisp-control 4342 udp LISP Control Packets lisp-control 4342 udp LISP Control Packets
11.2. LISP Packet Type Codes 11.2. LISP Packet Type Codes
It is being requested that the IANA be authoritative for LISP Packet It is being requested that the IANA be authoritative for LISP Packet
Type definitions and that it refers to this document as well as Type definitions and it is requested to replace the [RFC6830]
[RFC8113] as references. registry message references with the RFC number assigned to this
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 to 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
11.3. LISP ACT and Flag Fields 11.3. LISP ACT and Flag Fields
New ACT values can be allocated through IETF review or IESG approval. New ACT values can be allocated through IETF review or IESG approval.
Four values have already been allocated by [RFC6830]. This Four values have already been allocated by [RFC6830], IANA is
specification changes the name of ACT type 3 value from "Drop" to requested to replace the [RFC6830] reference for this registry with
"Drop/No-Reason" as well as adding two new ACT values, the "Drop/ the RFC number assigned to this document and the [RFC6830]. Action
values references with the RFC number assigned to this document.
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/
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 Reference
----- ------ ----------- --------- ----- ------ ----------- ---------
4 Drop/ A Packet matching this Map-Cache RFC6833bis 4 Drop/ A Packet matching this Map-Cache RFC6833bis
Policy-Denied entry is dropped because the target Policy-Denied entry is dropped because the target
EID is policy-denied by the xTR or EID is policy-denied by the xTR or
the mapping system. the mapping system.
5 Drop/ A Packet matching this Map-Cache RFC6833bis 5 Drop/ A Packet matching this Map-Cache RFC6833bis
skipping to change at page 41, line 35 skipping to change at page 42, line 8
12.1. Normative References 12.1. Normative References
[I-D.ietf-lisp-6834bis] [I-D.ietf-lisp-6834bis]
Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", draft-ietf- Separation Protocol (LISP) Map-Versioning", draft-ietf-
lisp-6834bis-02 (work in progress), September 2018. lisp-6834bis-02 (work in progress), September 2018.
[I-D.ietf-lisp-rfc6830bis] [I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-18 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-19 (work in progress),
September 2018. September 2018.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November ESP and AH", RFC 2404, DOI 10.17487/RFC2404, November
1998, <https://www.rfc-editor.org/info/rfc2404>. 1998, <https://www.rfc-editor.org/info/rfc2404>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
384, and HMAC-SHA-512 with IPsec", RFC 4868, 384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007, DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>. <https://www.rfc-editor.org/info/rfc4868>.
[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>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
12.2. Informative References 12.2. Informative References
[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.
skipping to change at page 42, line 41 skipping to change at page 43, line 19
[I-D.ietf-lisp-eid-mobility] [I-D.ietf-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-ietf-lisp-eid-mobility-02 Unified Control Plane", draft-ietf-lisp-eid-mobility-02
(work in progress), May 2018. (work in progress), May 2018.
[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-05 (work in progress), August 2018. gpe-06 (work in progress), September 2018.
[I-D.ietf-lisp-introduction] [I-D.ietf-lisp-introduction]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Cabellos-Aparicio, A. and D. Saucez, "An Architectural
Introduction to the Locator/ID Separation Protocol Introduction to the Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-introduction-13 (work in (LISP)", draft-ietf-lisp-introduction-13 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-lisp-mn] [I-D.ietf-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-ietf-lisp-mn-02 (work in progress), Mobile Node", draft-ietf-lisp-mn-02 (work in progress),
skipping to change at page 46, line 19 skipping to change at page 47, line 19
Fabio Maino, and members of the lisp@ietf.org mailing list for their Fabio Maino, and members of the lisp@ietf.org mailing list for their
feedback and helpful suggestions. feedback and helpful suggestions.
Special thanks are due to Noel Chiappa for his extensive work and Special thanks are due to Noel Chiappa for his extensive work and
thought about caching in Map-Resolvers. thought about caching in Map-Resolvers.
Appendix B. Document Change Log Appendix B. Document Change Log
[RFC Editor: Please delete this section on publication as RFC.] [RFC Editor: Please delete this section on publication as RFC.]
B.1. Changes to draft-ietf-lisp-rfc6833bis-15 B.1. Changes to draft-ietf-lisp-rfc6833bis-16
o Posted Late-September 2018.
o Re-wrote Security Considerations section. Thanks Albert.
o Added Alvaro text to be more clear about IANA actions.
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-14 B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-13 B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-12 B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-11 B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-10 B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-09 B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-08 B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-07 B.10. 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 48, line 16 skipping to change at page 49, line 25
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.10. Changes to draft-ietf-lisp-rfc6833bis-06 B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-05 B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-04 B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-03 B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-02 B.15. 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.15. Changes to draft-ietf-lisp-rfc6833bis-01 B.16. 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.16. Changes to draft-ietf-lisp-rfc6833bis-00 B.17. 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.17. Changes to draft-farinacci-lisp-rfc6833bis-00 B.18. 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. 36 change blocks. 
84 lines changed or deleted 115 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/