< draft-ietf-lisp-rfc6833bis-12.txt | draft-ietf-lisp-rfc6833bis-13.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: January 27, 2019 UPC/BarcelonaTech | Expires: February 21, 2019 UPC/BarcelonaTech | |||
July 26, 2018 | August 20, 2018 | |||
Locator/ID Separation Protocol (LISP) Control-Plane | Locator/ID Separation Protocol (LISP) Control-Plane | |||
draft-ietf-lisp-rfc6833bis-12 | draft-ietf-lisp-rfc6833bis-12 | |||
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 | |||
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 January 27, 2019. | This Internet-Draft will expire on February 21, 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 25 ¶ | skipping to change at page 2, line 25 ¶ | |||
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 | |||
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 | 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 5 | 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 | 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 | |||
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 | 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 9 | |||
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 | 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 10 | |||
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 | 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 13 | |||
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 | 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 15 | |||
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 | 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 19 | |||
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 | 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 22 | |||
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 | 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 25 | |||
5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 | 5.8. Encapsulated Control Message Format . . . . . . . . . . . 26 | |||
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 | 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 | |||
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 | 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 | |||
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 | 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 | |||
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 | 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 | |||
8. Interactions with Other LISP Components . . . . . . . . . . . 32 | 8. Interactions with Other LISP Components . . . . . . . . . . . 32 | |||
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 | 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 | |||
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 | 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 | |||
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 | 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 | |||
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 | 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 | |||
8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 | 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 | 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 37 | |||
10.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | |||
10.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 | 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 | |||
10.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 38 | 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 | |||
10.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 | 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 | |||
10.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 39 | 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 | ||||
11.2. Informative References . . . . . . . . . . . . . . . . . 40 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 44 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 40 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 44 | 12.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
B.1. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 44 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45 | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 44 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45 | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 44 | B.1. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45 | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 44 | B.2. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45 | |||
B.5. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 44 | B.3. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45 | |||
B.6. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 45 | B.4. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 45 | |||
B.7. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 45 | B.5. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 | |||
B.8. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 46 | B.6. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46 | |||
B.9. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 46 | B.7. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46 | |||
B.10. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 46 | B.8. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47 | |||
B.11. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 46 | B.9. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47 | |||
B.12. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 46 | B.10. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47 | |||
B.13. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 47 | B.11. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 47 | |||
B.14. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 47 | B.12. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 | B.13. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48 | |||
B.14. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48 | ||||
B.15. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
1. Introduction | 1. Introduction | |||
The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and | The Locator/ID Separation Protocol [I-D.ietf-lisp-introduction] and | |||
[I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism | [I-D.ietf-lisp-rfc6830bis] specifies an architecture and mechanism | |||
for dynamic tunnelling by logically separating the addresses | for dynamic tunnelling 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 3, line 51 ¶ | skipping to change at page 4, line 5 ¶ | |||
The LISP Mapping Service defines two new types of LISP-speaking | The LISP Mapping Service defines two new types of LISP-speaking | |||
devices: the Map-Resolver, which accepts Map-Requests from an Ingress | devices: the Map-Resolver, which accepts Map-Requests from an Ingress | |||
Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a | Tunnel Router (ITR) and "resolves" the EID-to-RLOC mapping using a | |||
mapping database; and the Map-Server, which learns authoritative EID- | mapping database; and the Map-Server, which learns authoritative EID- | |||
to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes | to-RLOC mappings from an Egress Tunnel Router (ETR) and publishes | |||
them in a database. | them in a database. | |||
This LISP Control-Plane Mapping Service can be used by many different | This LISP Control-Plane Mapping Service can be used by many different | |||
encapsulation-based or translation-based Data-Planes which include | encapsulation-based or translation-based Data-Planes which include | |||
but are not limited to the ones defined in LISP RFC 6830bis | but are not limited to the ones defined in LISP RFC 6830bis | |||
[I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.lewis-lisp-gpe], VXLAN | [I-D.ietf-lisp-rfc6830bis], LISP-GPE [I-D.ietf-lisp-gpe], VXLAN | |||
[RFC7348], VXLAN-GPE [I-D.ietf-nvo3-vxlan-gpe], and ILA | ||||
[RFC7348], VXLAN-GPE [I-D.quinn-vxlan-gpe], and ILA | ||||
[I-D.herbert-intarea-ila]. | [I-D.herbert-intarea-ila]. | |||
Conceptually, LISP Map-Servers share some of the same basic | Conceptually, LISP Map-Servers share some of the same basic | |||
configuration and maintenance properties as Domain Name System (DNS) | configuration and maintenance properties as Domain Name System (DNS) | |||
[RFC1035] servers; likewise, Map-Resolvers are conceptually similar | [RFC1035] servers; likewise, Map-Resolvers are conceptually similar | |||
to DNS caching resolvers. With this in mind, this specification | to DNS caching resolvers. With this in mind, this specification | |||
borrows familiar terminology (resolver and server) from the DNS | borrows familiar terminology (resolver and server) from the DNS | |||
specifications. | specifications. | |||
Note that while this document assumes a LISP-ALT database mapping | Note that while this document assumes a LISP-ALT database mapping | |||
skipping to change at page 4, line 32 ¶ | skipping to change at page 4, line 33 ¶ | |||
toolset. Issues and concerns about the deployment of LISP for | toolset. Issues and concerns about the deployment of LISP for | |||
Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], | Internet traffic are discussed in [I-D.ietf-lisp-rfc6830bis], | |||
[RFC7215], and [I-D.rodrigueznatal-lisp-oam]. | [RFC7215], and [I-D.rodrigueznatal-lisp-oam]. | |||
This document obsoletes RFC 6833. | This document obsoletes RFC 6833. | |||
2. Requirements Notation | 2. Requirements Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119] and | |||
[RFC8174]. | ||||
3. Definition of Terms | 3. Definition of Terms | |||
Map-Server: A network infrastructure component that learns of EID- | Map-Server: A network infrastructure component that learns of EID- | |||
Prefix mapping entries from an ETR, via the registration mechanism | Prefix mapping entries from an ETR, via the registration mechanism | |||
described below, or some other authoritative source if one exists. | described below, or some other authoritative source if one exists. | |||
A Map-Server publishes these EID-Prefixes in a mapping database. | A Map-Server publishes these EID-Prefixes in a mapping database. | |||
Map-Request: A LISP Map-Request is a Control-Plane message to query | Map-Request: A LISP Map-Request is a Control-Plane message to query | |||
the mapping system to resolve an EID. A LISP Map-Request can also | the mapping system to resolve an EID. A LISP Map-Request can also | |||
skipping to change at page 11, line 17 ¶ | skipping to change at page 11, line 17 ¶ | |||
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is | s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is | |||
sending a Map-Request in response to a received SMR-based Map- | sending a Map-Request in response to a received SMR-based Map- | |||
Request. | Request. | |||
m: This is the LISP mobile-node m-bit. This bit is set by xTRs that | m: This is the LISP mobile-node m-bit. This bit is set by xTRs that | |||
operate as a mobile node as defined in [I-D.ietf-lisp-mn]. | operate as a mobile node as defined in [I-D.ietf-lisp-mn]. | |||
I: This is the xTR-ID bit. When this bit is set, what is appended to | I: This is the xTR-ID bit. When this bit is set, what is appended to | |||
the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage | the Map-Request is a 128-bit xTR router-ID. See LISP PubSub usage | |||
procedures in [I-D.rodrigueznatal-lisp-pubsub] for details. | procedures in [I-D.ietf-lisp-pubsub] for details. | |||
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on | Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on | |||
receipt. | receipt. | |||
L: This is the local-xtr bit. It is used by an xTR in a LISP site to | L: This is the local-xtr bit. It is used by an xTR in a LISP site to | |||
tell other xTRs in the same site that it is part of the RLOC-set | tell other xTRs in the same site that it is part of the RLOC-set | |||
for the LISP site. The L-bit is set to 1 when the RLOC is the | for the LISP site. The L-bit is set to 1 when the RLOC is the | |||
sender's IP address. | sender's IP address. | |||
D: This is the dont-map-reply bit. It is used in the SMR procedure | D: This is the dont-map-reply bit. It is used in the SMR procedure | |||
skipping to change at page 24, line 7 ¶ | skipping to change at page 24, line 7 ¶ | |||
is not currently used for any security function but MAY be in the | is not currently used for any security function but MAY be in the | |||
future as part of an anti-replay solution. | future as part of an anti-replay solution. | |||
Key ID: This is a configured key-id value that corresponds to a | Key ID: This is a configured key-id value that corresponds to a | |||
shared-secret password that is used to authenticate the sender. | shared-secret password that is used to authenticate the sender. | |||
Multiple shared-secrets can be used to roll over keys in a non- | Multiple shared-secrets can be used to roll over keys in a non- | |||
disruptive way. | disruptive way. | |||
Algorithm ID: This is the configured Message Authentication Code | Algorithm ID: This is the configured Message Authentication Code | |||
(MAC) algorithm value used for the authentication function. See | (MAC) algorithm value used for the authentication function. See | |||
Algorithm ID Numbers in the Section 10.5 for codepoint | Algorithm ID Numbers in the Section 11.5 for codepoint | |||
assignments. | assignments. | |||
Authentication Data Length: This is the length in octets of the | Authentication Data Length: This is the length in octets of the | |||
'Authentication Data' field that follows this field. The length | 'Authentication Data' field that follows this field. The length | |||
of the 'Authentication Data' field is dependent on the MAC | of the 'Authentication Data' field is dependent on the MAC | |||
algorithm used. The length field allows a device that doesn't | algorithm used. The length field allows a device that doesn't | |||
know the MAC algorithm to correctly parse the packet. | know the MAC algorithm to correctly parse the packet. | |||
Authentication Data: This is the message digest used from the output | Authentication Data: This is the message digest used from the output | |||
of the MAC algorithm. The entire Map-Register payload is | of the MAC algorithm. The entire Map-Register payload is | |||
skipping to change at page 28, line 16 ¶ | skipping to change at page 28, line 16 ¶ | |||
In the LISP architecture ITRs/PITRs use a local Map-Cache to store | In the LISP architecture ITRs/PITRs use a local Map-Cache to store | |||
EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a | EID-to-RLOC mappings for forwarding. When an ETR updates a mapping a | |||
mechanism is required to inform ITRs/PITRs that are using such | mechanism is required to inform ITRs/PITRs that are using such | |||
mappings. | mappings. | |||
The LISP Data-Plane defines several mechanism to update mappings | The LISP Data-Plane defines several mechanism to update mappings | |||
[I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map | [I-D.ietf-lisp-rfc6830bis]. This document specifies the Solicit-Map | |||
Request (SMR), a Control-Plane push-based mechanism. An additional | Request (SMR), a Control-Plane push-based mechanism. An additional | |||
Control-Plane mechanism based on the Publish/subscribe paradigm is | Control-Plane mechanism based on the Publish/subscribe paradigm is | |||
specified in [I-D.rodrigueznatal-lisp-pubsub]. | specified in [I-D.ietf-lisp-pubsub]. | |||
6.1. Solicit-Map-Request (SMR) | 6.1. Solicit-Map-Request (SMR) | |||
Soliciting a Map-Request is a selective way for ETRs, at the site | Soliciting a Map-Request is a selective way for ETRs, at the site | |||
where mappings change, to control the rate they receive requests for | where mappings change, to control the rate they receive requests for | |||
Map-Reply messages. SMRs are also used to tell remote ITRs to update | Map-Reply messages. SMRs are also used to tell remote ITRs to update | |||
the mappings they have cached. | the mappings they have cached. | |||
Since the ETRs don't keep track of remote ITRs that have cached their | Since the ETRs don't keep track of remote ITRs that have cached their | |||
mappings, they do not know which ITRs need to have their mappings | mappings, they do not know which ITRs need to have their mappings | |||
skipping to change at page 37, line 33 ¶ | skipping to change at page 37, line 33 ¶ | |||
resolving these open security issues. | resolving these open security issues. | |||
While beyond the scope of securing an individual Map-Server or Map- | While beyond the scope of securing an individual Map-Server or Map- | |||
Resolver, it SHOULD be noted that a BGP-based LISP-ALT network (if | Resolver, it SHOULD be noted that a BGP-based LISP-ALT network (if | |||
ALT is used as the mapping database infrastructure) can take | ALT is used as the mapping database infrastructure) can take | |||
advantage of standards work on adding security to BGP. | advantage of standards work on adding security to BGP. | |||
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 security related details. | |||
10. IANA Considerations | 10. Changes since RFC 6833 | |||
For implementation considerations, the following changes have been | ||||
made to this document since RFC 6833 was published: | ||||
o A Map-Notify-Ack message is added in this docuemnt to provide | ||||
reliability for Map-Notify messages. Any receivers of a Map- | ||||
Notify message must respond with a Map-Notify-Ack message. Map- | ||||
Servers who are senders of Map-Notify messages, must queue the | ||||
Map-Notify contents until they receive a Map-Notify-Ack with the | ||||
nonce used in the Map-Notify message. | ||||
o This document is incorporating the codepoint for the Map-Referral | ||||
message from the LISP-DDT specification [RFC8111] to indicate that | ||||
a Map-Server must send the final Map-Referral message when it | ||||
participates in the LISP-DDT mapping system procedures. | ||||
o The "m", "I", "L", and "D" bits are added to the Map-Request | ||||
message. See Section 5.3 for details. | ||||
o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- | ||||
Register message. See Section 5.6 for details. | ||||
o The 16-bit Key-ID field of the Map-Register message has been split | ||||
into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. | ||||
o This document adds two new Action values that are in an EID-record | ||||
that appear in Map-Reply, Map-Register, Map-Notify, and Map- | ||||
Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure | ||||
are the descriptions for the two new action values. See | ||||
Section 5.4 for details. | ||||
11. IANA Considerations | ||||
This section provides guidance to the Internet Assigned Numbers | This section provides guidance to the Internet Assigned Numbers | |||
Authority (IANA) regarding registration of values related to this | Authority (IANA) regarding registration of values related to this | |||
LISP Control-Plane specification, in accordance with BCP 26 | LISP Control-Plane specification, in accordance with BCP 26 | |||
[RFC8126]. | [RFC8126]. | |||
There are three namespaces (listed in the sub-sections below) in LISP | There are three namespaces (listed in the sub-sections below) in LISP | |||
that have been registered. | that have been registered. | |||
o LISP IANA registry allocations SHOULD NOT be made for purposes | o LISP IANA registry allocations SHOULD NOT be made for purposes | |||
unrelated to LISP routing or transport protocols. | unrelated to LISP routing or transport protocols. | |||
o The following policies are used here with the meanings defined in | o The following policies are used here with the meanings defined in | |||
BCP 26: "Specification Required", "IETF Review", "Experimental | BCP 26: "Specification Required", "IETF Review", "Experimental | |||
Use", and "First Come First Served". | Use", and "First Come First Served". | |||
10.1. LISP UDP Port Numbers | 11.1. LISP UDP Port Numbers | |||
The IANA registry has allocated UDP port number 4342 for the LISP | The IANA registry has allocated UDP port number 4342 for the LISP | |||
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 | |||
10.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 that it refers to this document as well as | |||
[RFC8113] as references. | [RFC8113] as references. | |||
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 to 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 | |||
10.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]. This | |||
specification changes the name of ACT type 3 value from "Drop" to | 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/ | "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 | |||
skipping to change at page 39, line 7 ¶ | skipping to change at page 39, line 35 ¶ | |||
Auth-Failure entry is dropped because the | Auth-Failure entry is dropped because the | |||
Map-Request for target EID fails an | Map-Request for target EID fails an | |||
authentication check by the xTR or | authentication check by the xTR or | |||
the mapping system. | 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. | |||
10.4. LISP Address Type Codes | 11.4. LISP Address Type Codes | |||
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that | LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that | |||
defines LISP-specific encodings for AFI value 16387. LCAF encodings | defines LISP-specific encodings for AFI value 16387. LCAF encodings | |||
are used for specific use-cases where different address types for | are used for specific use-cases where different address types for | |||
EID-records and RLOC-records are required. | EID-records and RLOC-records are required. | |||
The IANA registry "LISP Canonical Address Format (LCAF) Types" is | The IANA registry "LISP Canonical Address Format (LCAF) Types" is | |||
used for LCAF types, the registry for LCAF types use the | used for LCAF types, the registry for LCAF types use the | |||
Specification Required policy [RFC8126]. Initial values for the | Specification Required policy [RFC8126]. Initial values for the | |||
registry as well as further information can be found in [RFC8060]. | registry as well as further information can be found in [RFC8060]. | |||
Therefore, there is no longer a need for the "LISP Address Type | Therefore, there is no longer a need for the "LISP Address Type | |||
Codes" registry requested by [RFC6830]. This document requests to | Codes" registry requested by [RFC6830]. This document requests to | |||
remove it. | remove it. | |||
10.5. LISP Algorithm ID Numbers | 11.5. LISP Algorithm ID Numbers | |||
In [RFC6830], a request for a "LISP Key ID Numbers" registry was | In [RFC6830], a request for a "LISP Key ID Numbers" registry was | |||
submitted. This document renames the registry to "LISP Algorithm ID | submitted. This document renames the registry to "LISP Algorithm ID | |||
Numbers" and requests the IANA to make the name change. | Numbers" and requests the IANA to make the name change. | |||
The following Algorithm ID values are defined by this specification | The following Algorithm ID values are defined by this specification | |||
as used in any packet type that references a 'Algorithm ID' field: | as used in any packet type that references a 'Algorithm ID' field: | |||
Name Number Defined in | Name Number Defined in | |||
----------------------------------------------- | ----------------------------------------------- | |||
None 0 RFC6833bis | None 0 RFC6833bis | |||
HMAC-SHA-1-96 1 [RFC2404] | HMAC-SHA-1-96 1 [RFC2404] | |||
HMAC-SHA-256-128 2 [RFC4868] | HMAC-SHA-256-128 2 [RFC4868] | |||
Number values are in the range of 0 to 255. The allocation of values | Number values are in the range of 0 to 255. The allocation of values | |||
is on a first come first served basis. | is on a first come first served basis. | |||
11. References | 12. References | |||
11.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-00 (work in progress), July 2018. | lisp-6834bis-00 (work in progress), July 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-14 (work in progress), | (LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress), | |||
skipping to change at page 40, line 25 ¶ | skipping to change at page 41, line 5 ¶ | |||
[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>. | |||
11.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. | |||
[I-D.ermagan-lisp-nat-traversal] | [I-D.ermagan-lisp-nat-traversal] | |||
Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, | Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, | |||
F., and C. White, "NAT traversal for LISP", draft-ermagan- | F., and C. White, "NAT traversal for LISP", draft-ermagan- | |||
lisp-nat-traversal-14 (work in progress), April 2018. | lisp-nat-traversal-14 (work in progress), April 2018. | |||
skipping to change at page 40, line 47 ¶ | skipping to change at page 41, line 27 ¶ | |||
Herbert, T. and P. Lapukhov, "Identifier-locator | Herbert, T. and P. Lapukhov, "Identifier-locator | |||
addressing for IPv6", draft-herbert-intarea-ila-01 (work | addressing for IPv6", draft-herbert-intarea-ila-01 (work | |||
in progress), March 2018. | in progress), March 2018. | |||
[I-D.ietf-lisp-eid-mobility] | [I-D.ietf-lisp-eid-mobility] | |||
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, | Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, | |||
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a | F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a | |||
Unified Control Plane", draft-ietf-lisp-eid-mobility-02 | Unified Control Plane", draft-ietf-lisp-eid-mobility-02 | |||
(work in progress), May 2018. | (work in progress), May 2018. | |||
[I-D.ietf-lisp-gpe] | ||||
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. | ||||
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- | ||||
gpe-05 (work in progress), August 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), | |||
April 2018. | April 2018. | |||
[I-D.ietf-lisp-pubsub] | ||||
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | ||||
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | ||||
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ | ||||
Subscribe Functionality for LISP", draft-ietf-lisp- | ||||
pubsub-00 (work in progress), April 2018. | ||||
[I-D.ietf-lisp-sec] | [I-D.ietf-lisp-sec] | |||
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | |||
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 | Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 | |||
(work in progress), April 2018. | (work in progress), April 2018. | |||
[I-D.ietf-nvo3-vxlan-gpe] | ||||
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol | ||||
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work | ||||
in progress), April 2018. | ||||
[I-D.ietf-opsec-icmp-filtering] | [I-D.ietf-opsec-icmp-filtering] | |||
Gont, F., Gont, G., and C. Pignataro, "Recommendations for | Gont, F., Gont, G., and C. Pignataro, "Recommendations for | |||
filtering ICMP messages", draft-ietf-opsec-icmp- | filtering ICMP messages", draft-ietf-opsec-icmp- | |||
filtering-04 (work in progress), July 2013. | filtering-04 (work in progress), July 2013. | |||
[I-D.lewis-lisp-gpe] | ||||
Lewis, D., Lemon, J., Agarwal, P., Kreeger, L., Quinn, P., | ||||
Smith, M., Yadav, N., and F. Maino, "LISP Generic Protocol | ||||
Extension", draft-lewis-lisp-gpe-04 (work in progress), | ||||
December 2017. | ||||
[I-D.meyer-loc-id-implications] | [I-D.meyer-loc-id-implications] | |||
Meyer, D. and D. Lewis, "Architectural Implications of | Meyer, D. and D. Lewis, "Architectural Implications of | |||
Locator/ID Separation", draft-meyer-loc-id-implications-01 | Locator/ID Separation", draft-meyer-loc-id-implications-01 | |||
(work in progress), January 2009. | (work in progress), January 2009. | |||
[I-D.quinn-vxlan-gpe] | ||||
Quinn, P., Manur, R., Kreeger, L., Lewis, D., Maino, F., | ||||
Smith, M., Agarwal, P., Yong, L., Xu, X., Elzur, U., Garg, | ||||
P., and D. Melman, "Generic Protocol Extension for VXLAN", | ||||
draft-quinn-vxlan-gpe-04 (work in progress), February | ||||
2015. | ||||
[I-D.rodrigueznatal-lisp-oam] | [I-D.rodrigueznatal-lisp-oam] | |||
Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles- | Rodriguez-Natal, A., Cabellos-Aparicio, A., Portoles- | |||
Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM | Comeras, M., Kowal, M., Lewis, D., and F. Maino, "LISP-OAM | |||
(Operations, Administration and Management): Use cases and | (Operations, Administration and Management): Use cases and | |||
requirements", draft-rodrigueznatal-lisp-oam-08 (work in | requirements", draft-rodrigueznatal-lisp-oam-08 (work in | |||
progress), June 2018. | progress), June 2018. | |||
[I-D.rodrigueznatal-lisp-pubsub] | ||||
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | ||||
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | ||||
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ | ||||
Subscribe Functionality for LISP", draft-rodrigueznatal- | ||||
lisp-pubsub-02 (work in progress), March 2018. | ||||
[RFC1035] Mockapetris, P., "Domain names - implementation and | [RFC1035] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, | |||
November 1987, <https://www.rfc-editor.org/info/rfc1035>. | November 1987, <https://www.rfc-editor.org/info/rfc1035>. | |||
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the | |||
Internet checksum", RFC 1071, DOI 10.17487/RFC1071, | Internet checksum", RFC 1071, DOI 10.17487/RFC1071, | |||
September 1988, <https://www.rfc-editor.org/info/rfc1071>. | September 1988, <https://www.rfc-editor.org/info/rfc1071>. | |||
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, | Hashing for Message Authentication", RFC 2104, | |||
skipping to change at page 43, line 43 ¶ | skipping to change at page 44, line 25 ¶ | |||
Protocol (LISP): Shared Extension Message & IANA Registry | Protocol (LISP): Shared Extension Message & IANA Registry | |||
for Packet Type Allocations", RFC 8113, | for Packet Type Allocations", RFC 8113, | |||
DOI 10.17487/RFC8113, March 2017, | DOI 10.17487/RFC8113, March 2017, | |||
<https://www.rfc-editor.org/info/rfc8113>. | <https://www.rfc-editor.org/info/rfc8113>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | ||||
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>. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
The authors would like to thank Greg Schudel, Darrel Lewis, John | The authors would like to thank Greg Schudel, Darrel Lewis, John | |||
Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, | Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, | |||
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-12 | B.1. Changes to draft-ietf-lisp-rfc6833bis-13 | |||
o Posted August 2018. | ||||
o Final editorial changes before RFC submission for Proposed | ||||
Standard. | ||||
o Added section "Changes since RFC 6833" so implementators are | ||||
informed of any changes since the last RFC publication. | ||||
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-11 | B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-10 | B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-09 | B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-08 | B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-07 | B.7. 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 45, line 39 ¶ | skipping to change at page 47, line 5 ¶ | |||
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.7. Changes to draft-ietf-lisp-rfc6833bis-06 | B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-05 | B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-04 | B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-03 | B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-02 | B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-01 | B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-00 | B.14. 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.14. Changes to draft-farinacci-lisp-rfc6833bis-00 | B.15. 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. 39 change blocks. | ||||
80 lines changed or deleted | 126 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/ |