< draft-ietf-lisp-rfc6833bis-14.txt | draft-ietf-lisp-rfc6833bis-15.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 15, 2019 UPC/BarcelonaTech | Expires: March 18, 2019 UPC/BarcelonaTech | |||
September 11, 2018 | September 14, 2018 | |||
Locator/ID Separation Protocol (LISP) Control-Plane | Locator/ID Separation Protocol (LISP) Control-Plane | |||
draft-ietf-lisp-rfc6833bis-14 | draft-ietf-lisp-rfc6833bis-15 | |||
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 15, 2019. | This Internet-Draft will expire on March 18, 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 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 7 | 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 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 . . . . . . . . . . . 27 | |||
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 | 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 29 | |||
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 28 | 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 29 | |||
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 29 | 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 30 | |||
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 31 | 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 32 | |||
8. Interactions with Other LISP Components . . . . . . . . . . . 32 | 8. Interactions with Other LISP Components . . . . . . . . . . . 33 | |||
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 32 | 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 33 | |||
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 33 | 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 34 | |||
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 35 | 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 36 | |||
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 36 | 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 37 | |||
8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 36 | 8.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . 37 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 | |||
10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 37 | 10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 38 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | |||
11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 38 | 11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 39 | |||
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 | 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 39 | |||
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 | 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 40 | |||
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 | 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 40 | |||
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 | 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 41 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 41 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 41 | 12.2. Informative References . . . . . . . . . . . . . . . . . 42 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 46 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 46 | |||
B.1. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 45 | B.1. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 46 | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45 | B.2. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 46 | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45 | B.3. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 46 | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45 | B.4. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 46 | |||
B.5. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 46 | B.5. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 46 | |||
B.6. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 | B.6. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 47 | |||
B.7. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46 | B.7. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 47 | |||
B.8. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46 | B.8. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 47 | |||
B.9. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47 | B.9. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 47 | |||
B.10. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47 | B.10. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 48 | |||
B.11. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47 | B.11. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 48 | |||
B.12. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 48 | B.12. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 48 | |||
B.13. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48 | B.13. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 49 | |||
B.14. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48 | B.14. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 49 | |||
B.15. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48 | B.15. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 49 | |||
B.16. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 | B.16. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 49 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | B.17. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 49 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50 | ||||
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 tunnelling by logically separating the | mechanism for dynamic tunneling by logically separating the addresses | |||
addresses currently used by IP in two separate name spaces: Endpoint | currently used by IP in two separate name spaces: Endpoint IDs | |||
IDs (EIDs), used within sites; and Routing Locators (RLOCs), used on | (EIDs), used within sites; and Routing Locators (RLOCs), used on the | |||
the transit networks that make up the Internet infrastructure. To | transit networks that make up the Internet infrastructure. To | |||
achieve this separation, LISP defines protocol mechanisms for mapping | achieve this separation, LISP defines protocol mechanisms for mapping | |||
from EIDs to RLOCs. In addition, LISP assumes the existence of a | from EIDs to RLOCs. In addition, LISP assumes the existence of a | |||
database to store and propagate those mappings globally. Several | database to store and propagate those mappings globally. Several | |||
such databases have been proposed; among them are the Content | such databases have been proposed; among them are the Content | |||
distribution Overlay Network Service for LISP-NERD (a Not-so-novel | distribution Overlay Network Service for LISP-NERD (a Not-so-novel | |||
EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology | EID-to-RLOC Database) [RFC6837], LISP Alternative Logical Topology | |||
(LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) | (LISP-ALT) [RFC6836], and LISP Delegated Database Tree (LISP-DDT) | |||
[RFC8111]. | [RFC8111]. | |||
The LISP Mapping Service defines two new types of LISP-speaking | The LISP Mapping Service defines two new types of LISP-speaking | |||
skipping to change at page 4, line 20 ¶ | skipping to change at page 4, line 20 ¶ | |||
[GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) | [GTP-3GPP], ILA [I-D.herbert-intarea-ila], and Segment Routing (SRv6) | |||
[RFC8402]. | [RFC8402]. | |||
Conceptually, LISP Map-Servers share some of the same basic | Conceptually, LISP Map-Servers share some of the same basic | |||
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 this document doesn't assume any particular database mapping | |||
infrastructure to illustrate certain aspects of Map-Server and Map- | infrastructure to illustrate certain aspects of Map-Server and Map- | |||
Resolver operation, the Mapping Service interface can (and likely | Resolver operation, the Mapping Service interface can (and likely | |||
will) be used by ITRs and ETRs to access other mapping database | will) be used by ITRs and ETRs to access other mapping database | |||
systems as the LISP infrastructure evolves. | systems as the LISP infrastructure evolves. | |||
The LISP Mapping Service is an important component of the LISP | The LISP Mapping Service is an important component of the LISP | |||
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]. | |||
skipping to change at page 8, line 27 ¶ | skipping to change at page 8, line 27 ¶ | |||
sender and the destination UDP port number is set to 4342. When a | sender and the destination UDP port number is set to 4342. When a | |||
UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- | UDP Map-Reply, Map-Notify (when used as an acknowledgement to a Map- | |||
Register), or Map-Notify-Ack are sent, the source UDP port number is | Register), or Map-Notify-Ack are sent, the source UDP port number is | |||
set to 4342 and the destination UDP port number is copied from the | set to 4342 and the destination UDP port number is copied from the | |||
source port of either the Map-Request or the invoking data packet. | source port of either the Map-Request or the invoking data packet. | |||
Implementations MUST be prepared to accept packets when either the | Implementations MUST be prepared to accept packets when either the | |||
source port or destination UDP port is set to 4342 due to NATs | source port or destination UDP port is set to 4342 due to NATs | |||
changing port number values. | changing port number values. | |||
The 'UDP Length' field will reflect the length of the UDP header and | The 'UDP Length' field will reflect the length of the UDP header and | |||
the LISP Message payload. | the LISP Message payload. Implementations should follow the | |||
procedures from [RFC8085] to determine the maximum size used for any | ||||
LISP control message. | ||||
The UDP checksum is computed and set to non-zero for all messages | The UDP checksum is computed and set to non-zero for all messages | |||
sent to or from port 4342. It MUST be checked on receipt, and if the | sent to or from port 4342. It MUST be checked on receipt, and if the | |||
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 | |||
skipping to change at page 11, line 13 ¶ | skipping to change at page 11, line 13 ¶ | |||
Request (SMRs) Section 6.1 for details. | Request (SMRs) Section 6.1 for details. | |||
p: This is the PITR bit. This bit is set to 1 when a PITR sends a | p: This is the PITR bit. This bit is set to 1 when a PITR sends a | |||
Map-Request. | Map-Request. | |||
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is | s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is | |||
sending a Map-Request in response to a received SMR-based Map- | sending a Map-Request in response to a received SMR-based Map- | |||
Request. | Request. | |||
m: This is the LISP mobile-node m-bit. This bit is set by xTRs that | 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]. This | |||
bit can be ignored if an implementation does not support | ||||
[I-D.ietf-lisp-mn]. | ||||
I: This is the xTR-ID bit. When this bit is set, what is appended to | 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.ietf-lisp-pubsub] for details. | procedures in [I-D.ietf-lisp-pubsub] for details. This bit can be | |||
ignored if an implementation does not support | ||||
[I-D.ietf-lisp-pubsub]. | ||||
Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on | Rsvd: This field MUST be set to 0 on transmit and MUST be ignored on | |||
receipt. | receipt. | |||
L: This is the local-xtr bit. It is used by an xTR in a LISP site to | L: This is the local-xtr bit. It is used by an xTR in a LISP site to | |||
tell other xTRs in the same site that it is part of the RLOC-set | tell other xTRs in the same site that it is part of the RLOC-set | |||
for the LISP site. The L-bit is set to 1 when the RLOC is the | for the LISP site. The L-bit is set to 1 when the RLOC is the | |||
sender's IP address. | sender's IP address. | |||
D: This is the dont-map-reply bit. It is used in the SMR procedure | D: This is the dont-map-reply bit. It is used in the SMR procedure | |||
skipping to change at page 11, line 48 ¶ | skipping to change at page 12, line 4 ¶ | |||
value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, | value of 0, there is 1 ITR-RLOC address encoded; for a value of 1, | |||
there are 2 ITR-RLOC addresses encoded, and so on up to 31, which | there are 2 ITR-RLOC addresses encoded, and so on up to 31, which | |||
encodes a total of 32 ITR-RLOC addresses. | encodes a total of 32 ITR-RLOC addresses. | |||
Record Count: This is the number of records in this Map-Request | Record Count: This is the number of records in this Map-Request | |||
message. A record is comprised of the portion of the packet that | message. A record is comprised of the portion of the packet that | |||
is labeled 'Rec' above and occurs the number of times equal to | is labeled 'Rec' above and occurs the number of times equal to | |||
Record Count. For this version of the protocol, a receiver MUST | Record Count. For this version of the protocol, a receiver MUST | |||
accept and process Map-Requests that contain one or more records, | accept and process Map-Requests that contain one or more records, | |||
but a sender MUST only send Map-Requests containing one record. | but a sender MUST only send Map-Requests containing one record. | |||
Support for requesting multiple EIDs in a single Map-Request | ||||
Support for processing multiple EIDs in a single Map-Request | ||||
message will be specified in a future version of the protocol. | message will be specified in a future version of the protocol. | |||
Nonce: This is an 8-octet random value created by the sender of the | Nonce: This is an 8-octet random value created by the sender of the | |||
Map-Request. This nonce will be returned in the Map-Reply. The | Map-Request. This nonce will be returned in the Map-Reply. The | |||
security of the LISP mapping protocol critically depends on the | security of the LISP mapping protocol critically depends on the | |||
strength of the nonce in the Map-Request message. The nonce | strength of the nonce in the Map-Request message. The nonce | |||
SHOULD be generated by a properly seeded pseudo-random (or strong | SHOULD be generated by a properly seeded pseudo-random (or strong | |||
random) source. See [RFC4086] for advice on generating security- | random) source. See [RFC4086] for advice on generating security- | |||
sensitive random data. | sensitive random data. | |||
skipping to change at page 13, line 41 ¶ | skipping to change at page 13, line 43 ¶ | |||
Map-Requests can also be LISP encapsulated using UDP destination | Map-Requests can also be LISP encapsulated using UDP destination | |||
port 4342 with a LISP Type value set to "Encapsulated Control | port 4342 with a LISP Type value set to "Encapsulated Control | |||
Message", when sent from an ITR to a Map-Resolver. Likewise, Map- | Message", when sent from an ITR to a Map-Resolver. Likewise, Map- | |||
Requests are LISP encapsulated the same way from a Map-Server to an | Requests are LISP encapsulated the same way from a Map-Server to an | |||
ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be | ETR. Details on Encapsulated Map-Requests and Map-Resolvers can be | |||
found in Section 5.8. | found in Section 5.8. | |||
Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- | Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map- | |||
Request for the same EID-Prefix be sent no more than once per second. | Request for the same EID-Prefix be sent no more than once per second. | |||
However, recommendations from [RFC8085] SHOULD be considered. | ||||
An ITR that is configured with mapping database information (i.e., it | An ITR that is configured with mapping database information (i.e., it | |||
is also an ETR) MAY optionally include those mappings in a Map- | is also an ETR) MAY optionally include those mappings in a Map- | |||
Request. When an ETR configured to accept and verify such | Request. When an ETR configured to accept and verify such | |||
"piggybacked" mapping data receives such a Map-Request and it does | "piggybacked" mapping data receives such a Map-Request and it does | |||
not have this mapping in the Map-Cache, it MAY originate a "verifying | not have this mapping in the Map-Cache, it MAY originate a "verifying | |||
Map-Request", addressed to the map-requesting ITR and the ETR MAY add | Map-Request", addressed to the map-requesting ITR and the ETR MAY add | |||
a Map-Cache entry. If the ETR has a Map-Cache entry that matches the | a Map-Cache entry. If the ETR has a Map-Cache entry that matches the | |||
"piggybacked" EID and the RLOC is in the Locator-Set for the entry, | "piggybacked" EID and the RLOC is in the Locator-Set for the entry, | |||
then it MAY send the "verifying Map-Request" directly to the | then it MAY send the "verifying Map-Request" directly to the | |||
skipping to change at page 19, line 49 ¶ | skipping to change at page 19, line 49 ¶ | |||
When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], | When an EID moves out of a LISP site [I-D.ietf-lisp-eid-mobility], | |||
the database mapping system may have overlapping EID-prefixes. Or | the database mapping system may have overlapping EID-prefixes. Or | |||
when a LISP site is configured with multiple sets of ETRs that | when a LISP site is configured with multiple sets of ETRs that | |||
support different EID-prefix lengths, the database mapping system may | support different EID-prefix lengths, the database mapping system may | |||
have overlapping EID-prefixes. When overlapping EID-prefixes exist, | have overlapping EID-prefixes. When overlapping EID-prefixes exist, | |||
a Map-Request with an EID that best matches any EID-Prefix MUST be | a Map-Request with an EID that best matches any EID-Prefix MUST be | |||
returned in a single Map-Reply message. For instance, if an ETR had | returned in a single Map-Reply message. For instance, if an ETR had | |||
database mapping entries for EID-Prefixes: | database mapping entries for EID-Prefixes: | |||
10.0.0.0/8 | 2001:db8::/16 | |||
10.1.0.0/16 | 2001:db8:1::/24 | |||
10.1.1.0/24 | 2001:db8:1:1::/32 | |||
10.1.2.0/24 | 2001:db8:1:2::/32 | |||
A Map-Request for EID 10.1.1.1 would cause a Map-Reply with a record | A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a | |||
count of 1 to be returned with a mapping record EID-Prefix of | record count of 1 to be returned with a mapping record EID-Prefix of | |||
10.1.1.0/24. | 2001:db8:1:1::/32. | |||
A Map-Request for EID 10.1.5.5 would cause a Map-Reply with a record | A Map-Request for EID 2001:db8:1:5::5 would cause a Map-Reply with a | |||
count of 3 to be returned with mapping records for EID-Prefixes | record count of 3 to be returned with mapping records for EID- | |||
10.1.0.0/16, 10.1.1.0/24, and 10.1.2.0/24. | Prefixes 2001:db8:1::/24, 2001:db8:1:1::/32, 2001:db8:1:2::/32. Note | |||
filling out the /16 with more-specifics that exist in the mapping | ||||
system. | ||||
Note that not all overlapping EID-Prefixes need to be returned but | Note that not all overlapping EID-Prefixes need to be returned but | |||
only the more-specific entries (note that in the second example above | only the more-specific entries (note that in the second example above | |||
10.0.0.0/8 was not returned for requesting EID 10.1.5.5) for the | 2001:db8::/16 was not returned for requesting EID 2001:db8:1:5::5) | |||
matching EID-Prefix of the requesting EID. When more than one EID- | for the matching EID-Prefix of the requesting EID. When more than | |||
Prefix is returned, all SHOULD use the same Time to Live value so | one EID-Prefix is returned, all SHOULD use the same Time to Live | |||
they can all time out at the same time. When a more-specific EID- | value so they can all time out at the same time. When a more- | |||
Prefix is received later, its Time to Live value in the Map-Reply | specific EID-Prefix is received later, its Time to Live value in the | |||
record can be stored even when other less-specific entries exist. | Map-Reply record can be stored even when other less-specific entries | |||
When a less-specific EID-Prefix is received later, its Map-Cache | exist. When a less-specific EID-Prefix is received later, its Map- | |||
expiration time SHOULD be set to the minimum expiration time of any | Cache expiration time SHOULD be set to the minimum expiration time of | |||
more-specific EID-Prefix in the Map-Cache. This is done so the | any more-specific EID-Prefix in the Map-Cache. This is done so the | |||
integrity of the EID-Prefix set is wholly maintained and so no more- | integrity of the EID-Prefix set is wholly maintained and so no more- | |||
specific entries are removed from the Map-Cache while keeping less- | specific entries are removed from the Map-Cache while keeping less- | |||
specific entries. | specific entries. | |||
Map-Replies SHOULD be sent for an EID-Prefix no more often than once | Map-Replies SHOULD be sent for an EID-Prefix no more often than once | |||
per second to the same requesting router. For scalability, it is | per second to the same requesting router. For scalability, it is | |||
expected that aggregation of EID addresses into EID-Prefixes will | expected that aggregation of EID addresses into EID-Prefixes will | |||
allow one Map-Reply to satisfy a mapping for the EID addresses in the | allow one Map-Reply to satisfy a mapping for the EID addresses in the | |||
prefix range, thereby reducing the number of Map-Request messages. | prefix range, thereby reducing the number of Map-Request messages. | |||
skipping to change at page 23, line 30 ¶ | skipping to change at page 23, line 30 ¶ | |||
T: This is the use-TTL for timeout bit. When set to 1, the xTR wants | T: This is the use-TTL for timeout bit. When set to 1, the xTR wants | |||
the Map-Server to time out registrations based on the value in the | the Map-Server to time out registrations based on the value in the | |||
"Record TTL" field of this message. | "Record TTL" field of this message. | |||
a: This is the merge-request bit. When set to 1, the xTR requests to | a: This is the merge-request bit. When set to 1, the xTR requests to | |||
merge RLOC-records from different xTRs registering the same EID- | merge RLOC-records from different xTRs registering the same EID- | |||
record. See signal-free multicast [RFC8378] for one use case | record. See signal-free multicast [RFC8378] for one use case | |||
example. | example. | |||
m: This is the mobile-node bit. When set to 1, the registering xTR | m: This is the mobile-node bit. When set to 1, the registering xTR | |||
supports the procedures in [I-D.ietf-lisp-mn]. | supports the procedures in [I-D.ietf-lisp-mn]. This bit can be | |||
ignored if an implementation does not support [I-D.ietf-lisp-mn] | ||||
M: This is the want-map-notify bit. When set to 1, an ETR is | M: This is the want-map-notify bit. When set to 1, an ETR is | |||
requesting a Map-Notify message to be returned in response to | requesting a Map-Notify message to be returned in response to | |||
sending a Map-Register message. The Map-Notify message sent by a | sending a Map-Register message. The Map-Notify message sent by a | |||
Map-Server is used to acknowledge receipt of a Map-Register | Map-Server is used to acknowledge receipt of a Map-Register | |||
message. | message. | |||
Record Count: This is the number of records in this Map-Register | Record Count: This is the number of records in this Map-Register | |||
message. A record is comprised of that portion of the packet | message. A record is comprised of that portion of the packet | |||
labeled 'Record' above and occurs the number of times equal to | labeled 'Record' above and occurs the number of times equal to | |||
skipping to change at page 26, line 5 ¶ | skipping to change at page 26, line 5 ¶ | |||
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. | message. See the Map-Register section for field descriptions. | |||
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 and | message. It is used to acknowledge the receipt of a Map-Notify and | |||
for the sender to stop retransmitting a Map-Notify with the same | for the sender to stop retransmitting a Map-Notify with the same | |||
nonce. | nonce. | |||
A sender of an unsolicited Map-Notify message (one that is not used | ||||
as an acknowledgment to a Map-Register message) will follow the | ||||
Congestion Control And Relability Guideline sections of [RFC8085]. A | ||||
Map-Notify is retransmitted until a Map-Notify-Ack with the same | ||||
nonce from ther Map-Notify message is received. If a Map-Notify-Ack | ||||
is never received, a log message is issued. An implementation SHOULD | ||||
retransmit up to 3 times at 3 second retransmission intervals, after | ||||
which time the retransmission interval is exponentially backed-off | ||||
for anthoer 3 retransmission attempts. After this time, the Map- | ||||
Notify sender can only get the RLOC-set change by later querying the | ||||
mapping system or by RLOC-probing one of the RLOCs of the existing | ||||
cached RLOC-set to get the new RLOC-set. | ||||
5.8. Encapsulated Control Message Format | 5.8. Encapsulated Control Message Format | |||
An Encapsulated Control Message (ECM) is used to encapsulate control | An Encapsulated Control Message (ECM) is used to encapsulate control | |||
packets sent between xTRs and the mapping database system. | packets sent between xTRs and the mapping database system. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
/ | IPv4 or IPv6 Header | | / | IPv4 or IPv6 Header | | |||
OH | (uses RLOC addresses) | | OH | (uses RLOC addresses) | | |||
skipping to change at page 29, line 16 ¶ | skipping to change at page 30, line 16 ¶ | |||
accept the Map-Request. | accept the Map-Request. | |||
3. The remote ITR MUST rate-limit the Map-Request until it gets a | 3. The remote ITR MUST rate-limit the Map-Request until it gets a | |||
Map-Reply while continuing to use the cached mapping. When | Map-Reply while continuing to use the cached mapping. When | |||
Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, | Map-Versioning as described in [I-D.ietf-lisp-6834bis] is used, | |||
an SMR sender can detect if an ITR is using the most up-to-date | an SMR sender can detect if an ITR is using the most up-to-date | |||
database mapping. | database mapping. | |||
4. The ETRs at the site with the changed mapping will reply to the | 4. The ETRs at the site with the changed mapping will reply to the | |||
Map-Request with a Map-Reply message that has a nonce from the | Map-Request with a Map-Reply message that has a nonce from the | |||
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate- | SMR-invoked Map-Request. The Map-Reply messages MUST be rate- | |||
limited. This is important to avoid Map-Reply implosion. | limited according to procedures in [RFC8085]. This is important | |||
to avoid Map-Reply implosion. | ||||
5. The ETRs at the site with the changed mapping record the fact | 5. The ETRs at the site with the changed mapping record the fact | |||
that the site that sent the Map-Request has received the new | that the site that sent the Map-Request has received the new | |||
mapping data in the Map-Cache entry for the remote site so the | mapping data in the Map-Cache entry for the remote site so the | |||
Locator-Status-Bits are reflective of the new mapping for packets | Locator-Status-Bits are reflective of the new mapping for packets | |||
going to the remote site. The ETR then stops sending SMR | going to the remote site. The ETR then stops sending SMR | |||
messages. | messages. | |||
For security reasons, an ITR MUST NOT process unsolicited Map- | For security reasons, an ITR MUST NOT process unsolicited Map- | |||
Replies. To avoid Map-Cache entry corruption by a third party, a | Replies. To avoid Map-Cache entry corruption by a third party, a | |||
skipping to change at page 35, line 35 ¶ | skipping to change at page 36, line 35 ¶ | |||
1-minute TTL. | 1-minute TTL. | |||
If the EID-prefix is either registered or not registered to the | If the EID-prefix is either registered or not registered to the | |||
mapping system and there is a policy in the Map-Server to have the | mapping system and there is a policy in the Map-Server to have the | |||
requestor drop packets for the matching EID-prefix, then a Drop/ | requestor drop packets for the matching EID-prefix, then a Drop/ | |||
Policy-Denied action is returned. If the EID-prefix is registered or | Policy-Denied action is returned. If the EID-prefix is registered or | |||
not registered and there is a authentication failure, then a Drop/ | not registered and there is a authentication failure, then a Drop/ | |||
Authentication- failure action is returned. If either of these | Authentication- failure action is returned. If either of these | |||
actions result as a temporary state in policy or authentication then | actions result as a temporary state in policy or authentication then | |||
a Send-Map-Request action with 1-minute TTL MAY be returned to allow | a Send-Map-Request action with 1-minute TTL MAY be returned to allow | |||
the reqeustor to retry the Map-Request. | the requestor to retry the Map-Request. | |||
If any of the registered ETRs for the EID-Prefix have requested proxy | If any of the registered ETRs for the EID-Prefix have requested proxy | |||
reply service, then the Map-Server answers the request instead of | reply service, then the Map-Server answers the request instead of | |||
forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, | forwarding it. It returns a Map-Reply with the EID-Prefix, RLOCs, | |||
and other information learned through the registration process. | and other information learned through the registration process. | |||
If none of the ETRs have requested proxy reply service, then the Map- | If none of the ETRs have requested proxy reply service, then the Map- | |||
Server re-encapsulates and forwards the resulting Encapsulated Map- | Server re-encapsulates and forwards the resulting Encapsulated Map- | |||
Request to one of the registered ETRs. It does not otherwise alter | Request to one of the registered ETRs. It does not otherwise alter | |||
the Map-Request, so any Map-Reply sent by the ETR is returned to the | the Map-Request, so any Map-Reply sent by the ETR is returned to the | |||
skipping to change at page 37, line 43 ¶ | skipping to change at page 38, line 43 ¶ | |||
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 | |||
contents until they receive a Map-Notify-Ack with the nonce used | contents until they receive a Map-Notify-Ack with the nonce used | |||
in the Map-Notify message. | in the Map-Notify message. Note that implementations for Map- | |||
Notify-Ack support already exist and predate this document. | ||||
o This document is incorporating the codepoint for the Map-Referral | o This document is incorporating the codepoint for the Map-Referral | |||
message from the LISP-DDT specification [RFC8111] to indicate that | message from the LISP-DDT specification [RFC8111] to indicate that | |||
a Map-Server must send the final Map-Referral message when it | a Map-Server must send the final Map-Referral message when it | |||
participates in the LISP-DDT mapping system procedures. | participates in the LISP-DDT mapping system procedures. | |||
o The "m", "I", "L", and "D" bits are added to the Map-Request | o The "m", "I", "L", and "D" bits are added to the Map-Request | |||
message. See Section 5.3 for details. | message. See Section 5.3 for details. | |||
o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- | o The "S", "I", "E", "T", "a", and "m" bits are added to the Map- | |||
skipping to change at page 40, line 35 ¶ | skipping to change at page 41, line 35 ¶ | |||
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-16 (work in progress), | (LISP)", draft-ietf-lisp-rfc6830bis-17 (work in progress), | |||
August 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>. | |||
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | ||||
Guidelines", BCP 145, RFC 8085, DOI 10.17487/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. | |||
[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 45, line 19 ¶ | skipping to change at page 46, 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-14 | B.1. Changes to draft-ietf-lisp-rfc6833bis-15 | |||
o Posted mid-September 2018. | ||||
o Changes to reflect comments from Colin and Mirja. | ||||
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-13 | B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-12 | B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-11 | B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-10 | B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-09 | B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-08 | B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-07 | B.9. 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 47, line 13 ¶ | skipping to change at page 48, line 16 ¶ | |||
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.9. Changes to draft-ietf-lisp-rfc6833bis-06 | B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-05 | B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-04 | B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-03 | B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-02 | B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-01 | B.15. 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.15. Changes to draft-ietf-lisp-rfc6833bis-00 | B.16. 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.16. Changes to draft-farinacci-lisp-rfc6833bis-00 | B.17. 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. | ||||
96 lines changed or deleted | 133 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/ |