< draft-ietf-lisp-rfc6833bis-13.txt | draft-ietf-lisp-rfc6833bis-14.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: February 25, 2019 UPC/BarcelonaTech | Expires: March 9, 2019 UPC/BarcelonaTech | |||
August 24, 2018 | September 5, 2018 | |||
Locator/ID Separation Protocol (LISP) Control-Plane | Locator/ID Separation Protocol (LISP) Control-Plane | |||
draft-ietf-lisp-rfc6833bis-13 | draft-ietf-lisp-rfc6833bis-14 | |||
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 February 25, 2019. | This Internet-Draft will expire on March 9, 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 3, line 10 ¶ | skipping to change at page 3, line 10 ¶ | |||
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 | 11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 38 | |||
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 | 11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 39 | |||
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 | 11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 39 | |||
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 | 11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 40 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 40 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 40 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 41 | 12.2. Informative References . . . . . . . . . . . . . . . . . 41 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 45 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 45 | |||
B.1. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45 | B.1. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 45 | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45 | B.2. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 45 | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45 | B.3. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 45 | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 45 | B.4. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 45 | |||
B.5. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 | B.5. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 45 | |||
B.6. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46 | B.6. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 46 | |||
B.7. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46 | B.7. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 46 | |||
B.8. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47 | B.8. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 46 | |||
B.9. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47 | B.9. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 47 | |||
B.10. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47 | B.10. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 47 | |||
B.11. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 47 | B.11. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 47 | |||
B.12. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48 | B.12. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 47 | |||
B.13. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48 | B.13. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 48 | |||
B.14. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48 | B.14. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 48 | |||
B.15. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 | B.15. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 48 | |||
B.16. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 48 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | 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 | |||
skipping to change at page 9, line 25 ¶ | skipping to change at page 9, line 25 ¶ | |||
LISP Map-Register: 3 b'0011' | LISP Map-Register: 3 b'0011' | |||
LISP Map-Notify: 4 b'0100' | LISP Map-Notify: 4 b'0100' | |||
LISP Map-Notify-Ack: 5 b'0101' | LISP Map-Notify-Ack: 5 b'0101' | |||
LISP Map-Referral: 6 b'0110' | LISP Map-Referral: 6 b'0110' | |||
LISP Encapsulated Control Message: 8 b'1000' | LISP Encapsulated Control Message: 8 b'1000' | |||
Not Assigned 9-14 b'1001'- b'1110' | Not Assigned 9-14 b'1001'- b'1110' | |||
LISP Shared Extension Message: 15 b'1111' [RFC8113] | LISP Shared Extension Message: 15 b'1111' [RFC8113] | |||
Values in the "Not Assigned" range can be assigned according to | Values in the "Not Assigned" range can be assigned according to | |||
procedures in [RFC8126]. Documents that request for a new LISP | procedures in [RFC8126]. Documents that request for a new LISP | |||
packet type MAY indicate a preferred value. | packet type may indicate a preferred value. | |||
Protocol designers experimenting with new message formats SHOULD use | Protocol designers experimenting with new message formats SHOULD use | |||
the LISP Shared Extension Message Type and request a [RFC8113] sub- | the LISP Shared Extension Message Type and request a [RFC8113] sub- | |||
type assignment. | type assignment. | |||
All LISP Control-Plane messages use Address Family Identifiers (AFI) | All LISP Control-Plane messages use Address Family Identifiers (AFI) | |||
[AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to | [AFI] or LISP Canonical Address Format (LCAF) [RFC8060] formats to | |||
encode either fixed or variable length addresses. This includes | encode either fixed or variable length addresses. This includes | |||
explicit fields in each control message or part of EID-records or | explicit fields in each control message or part of EID-records or | |||
RLOC-records in commonly formatted messages. | RLOC-records in commonly formatted messages. | |||
skipping to change at page 17, line 46 ¶ | skipping to change at page 17, line 46 ¶ | |||
[I-D.ietf-lisp-6834bis] for more details. | [I-D.ietf-lisp-6834bis] for more details. | |||
EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] | EID-Prefix-AFI: Address family of the EID-Prefix according to [AFI] | |||
and [RFC8060]. | and [RFC8060]. | |||
EID-Prefix: This prefix is 4 octets for an IPv4 address family and | EID-Prefix: This prefix is 4 octets for an IPv4 address family and | |||
16 octets for an IPv6 address family. | 16 octets for an IPv6 address family. | |||
Priority: Each RLOC is assigned a unicast Priority. Lower values | Priority: Each RLOC is assigned a unicast Priority. Lower values | |||
are more preferable. When multiple RLOCs have the same Priority, | are more preferable. When multiple RLOCs have the same Priority, | |||
they MAY be used in a load-split fashion. A value of 255 means | they may be used in a load-split fashion. A value of 255 means | |||
the RLOC MUST NOT be used for unicast forwarding. | the RLOC MUST NOT be used for unicast forwarding. | |||
Weight: When priorities are the same for multiple RLOCs, the Weight | Weight: When priorities are the same for multiple RLOCs, the Weight | |||
indicates how to balance unicast traffic between them. Weight is | indicates how to balance unicast traffic between them. Weight is | |||
encoded as a relative weight of total unicast packets that match | encoded as a relative weight of total unicast packets that match | |||
the mapping entry. For example, if there are 4 Locators in a | the mapping entry. For example, if there are 4 Locators in a | |||
Locator-Set, where the Weights assigned are 30, 20, 20, and 10, | Locator-Set, where the Weights assigned are 30, 20, 20, and 10, | |||
the first Locator will get 37.5% of the traffic, the 2nd and 3rd | the first Locator will get 37.5% of the traffic, the 2nd and 3rd | |||
Locators will get 25% of the traffic, and the 4th Locator will get | Locators will get 25% of the traffic, and the 4th Locator will get | |||
12.5% of the traffic. If all Weights for a Locator-Set are equal, | 12.5% of the traffic. If all Weights for a Locator-Set are equal, | |||
skipping to change at page 18, line 38 ¶ | skipping to change at page 18, line 38 ¶ | |||
Unused Flags: These are set to 0 when sending and ignored on | Unused Flags: These are set to 0 when sending and ignored on | |||
receipt. | receipt. | |||
L: When this bit is set, the Locator is flagged as a local Locator to | L: When this bit is set, the Locator is flagged as a local Locator to | |||
the ETR that is sending the Map-Reply. When a Map-Server is doing | the ETR that is sending the Map-Reply. When a Map-Server is doing | |||
proxy Map-Replying for a LISP site, the L-bit is set to 0 for all | proxy Map-Replying for a LISP site, the L-bit is set to 0 for all | |||
Locators in this Locator-Set. | Locators in this Locator-Set. | |||
p: When this bit is set, an ETR informs the RLOC-Probing ITR that the | p: When this bit is set, an ETR informs the RLOC-Probing ITR that the | |||
locator address for which this bit is set is the one being RLOC- | locator address for which this bit is set is the one being RLOC- | |||
probed and MAY be different from the source address of the Map- | probed and may be different from the source address of the Map- | |||
Reply. An ITR that RLOC-probes a particular Locator MUST use this | Reply. An ITR that RLOC-probes a particular Locator MUST use this | |||
Locator for retrieving the data structure used to store the fact | Locator for retrieving the data structure used to store the fact | |||
that the Locator is reachable. The p-bit is set for a single | that the Locator is reachable. The p-bit is set for a single | |||
Locator in the same Locator-Set. If an implementation sets more | Locator in the same Locator-Set. If an implementation sets more | |||
than one p-bit erroneously, the receiver of the Map-Reply MUST | than one p-bit erroneously, the receiver of the Map-Reply MUST | |||
select the first Locator. The p-bit MUST NOT be set for Locator- | select the first Locator. The p-bit MUST NOT be set for Locator- | |||
Set records sent in Map-Request and Map-Register messages. | Set records sent in Map-Request and Map-Register messages. | |||
R: This is set when the sender of a Map-Reply has a route to the | R: This is set when the sender of a Map-Reply has a route to the | |||
Locator in the Locator data record. This receiver MAY find this | Locator in the Locator data record. This receiver may find this | |||
useful to know if the Locator is up but not necessarily reachable | useful to know if the Locator is up but not necessarily reachable | |||
from the receiver's point of view. See also EID-Reachability | from the receiver's point of view. See also EID-Reachability | |||
Section 7.1 for another way the R-bit MAY be used. | Section 7.1 for another way the R-bit may be used. | |||
Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- | Locator: This is an IPv4 or IPv6 address (as encoded by the 'Loc- | |||
AFI' field) assigned to an ETR. Note that the destination RLOC | AFI' field) assigned to an ETR. Note that the destination RLOC | |||
address MAY be an anycast address. A source RLOC can be an | address MAY be an anycast address. A source RLOC can be an | |||
anycast address as well. The source or destination RLOC MUST NOT | anycast address as well. The source or destination RLOC MUST NOT | |||
be the broadcast address (255.255.255.255 or any subnet broadcast | be the broadcast address (255.255.255.255 or any subnet broadcast | |||
address known to the router) and MUST NOT be a link-local | address known to the router) and MUST NOT be a link-local | |||
multicast address. The source RLOC MUST NOT be a multicast | multicast address. The source RLOC MUST NOT be a multicast | |||
address. The destination RLOC SHOULD be a multicast address if it | address. The destination RLOC SHOULD be a multicast address if it | |||
is being mapped from a multicast destination EID. | is being mapped from a multicast destination EID. | |||
skipping to change at page 23, line 46 ¶ | skipping to change at page 23, line 46 ¶ | |||
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 | |||
Record Count. | Record Count. | |||
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register | Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register | |||
messages if no Map-Notify message is expected to acknowledge it. | messages if no Map-Notify message is expected to acknowledge it. | |||
Since the Map-Register message is authenticated, the 'Nonce' field | Since the Map-Register message is authenticated, the 'Nonce' field | |||
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 11.5 for codepoint | Algorithm ID Numbers in the Section 11.5 for codepoint | |||
skipping to change at page 30, line 5 ¶ | skipping to change at page 30, line 5 ¶ | |||
until they need to send, in which case they will send Map-Requests to | until they need to send, in which case they will send Map-Requests to | |||
obtain a Map-Cache entry. | obtain a Map-Cache entry. | |||
7. Routing Locator Reachability | 7. Routing Locator Reachability | |||
This document defines several Control-Plane mechanisms for | This document defines several Control-Plane mechanisms for | |||
determining RLOC reachability. Please note that additional Data- | determining RLOC reachability. Please note that additional Data- | |||
Plane reachability mechanisms are defined in | Plane reachability mechanisms are defined in | |||
[I-D.ietf-lisp-rfc6830bis]. | [I-D.ietf-lisp-rfc6830bis]. | |||
1. An ITR MAY receive an ICMP Network Unreachable or Host | 1. An ITR may receive an ICMP Network Unreachable or Host | |||
Unreachable message for an RLOC it is using. This indicates that | Unreachable message for an RLOC it is using. This indicates that | |||
the RLOC is likely down. Note that trusting ICMP messages may | the RLOC is likely down. Note that trusting ICMP messages may | |||
not be desirable, but neither is ignoring them completely. | not be desirable, but neither is ignoring them completely. | |||
Implementations are encouraged to follow current best practices | Implementations are encouraged to follow current best practices | |||
in treating these conditions [I-D.ietf-opsec-icmp-filtering]. | in treating these conditions [I-D.ietf-opsec-icmp-filtering]. | |||
2. When an ITR participates in the routing protocol that operates in | 2. When an ITR participates in the routing protocol that operates in | |||
the underlay routing system, it can determine that an RLOC is | the underlay routing system, it can determine that an RLOC is | |||
down when no Routing Information Base (RIB) entry exists that | down when no Routing Information Base (RIB) entry exists that | |||
matches the RLOC IP address. | matches the RLOC IP address. | |||
3. An ITR MAY receive an ICMP Port Unreachable message from a | 3. An ITR may receive an ICMP Port Unreachable message from a | |||
destination host. This occurs if an ITR attempts to use | destination host. This occurs if an ITR attempts to use | |||
interworking [RFC6832] and LISP-encapsulated data is sent to a | interworking [RFC6832] and LISP-encapsulated data is sent to a | |||
non-LISP-capable site. | non-LISP-capable site. | |||
4. An ITR MAY receive a Map-Reply from an ETR in response to a | 4. An ITR may receive a Map-Reply from an ETR in response to a | |||
previously sent Map-Request. The RLOC source of the Map-Reply is | previously sent Map-Request. The RLOC source of the Map-Reply is | |||
likely up, since the ETR was able to send the Map-Reply to the | likely up, since the ETR was able to send the Map-Reply to the | |||
ITR. | ITR. | |||
5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described | 5. An ITR/ETR pair can use the 'RLOC-Probing' mechanism described | |||
below. | below. | |||
When ITRs receive ICMP Network Unreachable or Host Unreachable | When ITRs receive ICMP Network Unreachable or Host Unreachable | |||
messages as a method to determine unreachability, they will refrain | messages as a method to determine unreachability, they will refrain | |||
from using Locators that are described in Locator lists of Map- | from using Locators that are described in Locator lists of Map- | |||
skipping to change at page 33, line 9 ¶ | skipping to change at page 33, line 9 ¶ | |||
registered, a 1-minute TTL is returned. If the requested EID | registered, a 1-minute TTL is returned. If the requested EID | |||
matches a non-delegated part of the authoritative EID-Prefix, then | matches a non-delegated part of the authoritative EID-Prefix, then | |||
it is not a LISP EID and a 15-minute TTL is returned. See | it is not a LISP EID and a 15-minute TTL is returned. See | |||
Section 8.2 for discussion of aggregate EID-Prefixes and details | Section 8.2 for discussion of aggregate EID-Prefixes and details | |||
of Map-Server EID-Prefix matching. | of Map-Server EID-Prefix matching. | |||
o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or | o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or | |||
possibly from a Map-Server answering on behalf of the ETR. See | possibly from a Map-Server answering on behalf of the ETR. See | |||
Section 8.4 for more details on Map-Resolver message processing. | Section 8.4 for more details on Map-Resolver message processing. | |||
Note that an ITR MAY be configured to both use a Map-Resolver and to | Note that an ITR may be configured to both use a Map-Resolver and to | |||
participate in a LISP-ALT logical network. In such a situation, the | participate in a LISP-ALT logical network. In such a situation, the | |||
ITR SHOULD send Map-Requests through the ALT network for any EID- | ITR SHOULD send Map-Requests through the ALT network for any EID- | |||
Prefix learned via ALT BGP. Such a configuration is expected to be | Prefix learned via ALT BGP. Such a configuration is expected to be | |||
very rare, since there is little benefit to using a Map-Resolver if | very rare, since there is little benefit to using a Map-Resolver if | |||
an ITR is already using LISP-ALT. There would be, for example, no | an ITR is already using LISP-ALT. There would be, for example, no | |||
need for such an ITR to send a Map-Request to a possibly non-existent | need for such an ITR to send a Map-Request to a possibly non-existent | |||
EID (and rely on Negative Map-Replies) if it can consult the ALT | EID (and rely on Negative Map-Replies) if it can consult the ALT | |||
database to verify that an EID-Prefix is present before sending that | database to verify that an EID-Prefix is present before sending that | |||
Map-Request. | Map-Request. | |||
skipping to change at page 33, line 33 ¶ | skipping to change at page 33, line 33 ¶ | |||
Map-Register messages. A Map-Register message includes | Map-Register messages. A Map-Register message includes | |||
authentication data, so prior to sending a Map-Register message, the | authentication data, so prior to sending a Map-Register message, the | |||
ETR and Map-Server SHOULD be configured with a shared secret or other | ETR and Map-Server SHOULD be configured with a shared secret or other | |||
relevant authentication information. A Map-Server's configuration | relevant authentication information. A Map-Server's configuration | |||
SHOULD also include a list of the EID-Prefixes for which each ETR is | SHOULD also include a list of the EID-Prefixes for which each ETR is | |||
authoritative. Upon receipt of a Map-Register from an ETR, a Map- | authoritative. Upon receipt of a Map-Register from an ETR, a Map- | |||
Server accepts only EID-Prefixes that are configured for that ETR. | Server accepts only EID-Prefixes that are configured for that ETR. | |||
Failure to implement such a check would leave the mapping system | Failure to implement such a check would leave the mapping system | |||
vulnerable to trivial EID-Prefix hijacking attacks. As developers | vulnerable to trivial EID-Prefix hijacking attacks. As developers | |||
and operators gain experience with the mapping system, additional, | and operators gain experience with the mapping system, additional, | |||
stronger security measures MAY be added to the registration process. | stronger security measures may be added to the registration process. | |||
In addition to the set of EID-Prefixes defined for each ETR that MAY | In addition to the set of EID-Prefixes defined for each ETR that may | |||
register, a Map-Server is typically also configured with one or more | register, a Map-Server is typically also configured with one or more | |||
aggregate prefixes that define the part of the EID numbering space | aggregate prefixes that define the part of the EID numbering space | |||
assigned to it. When LISP-ALT is the database in use, aggregate EID- | assigned to it. When LISP-ALT is the database in use, aggregate EID- | |||
Prefixes are implemented as discard routes and advertised into ALT | Prefixes are implemented as discard routes and advertised into ALT | |||
BGP. The existence of aggregate EID-Prefixes in a Map-Server's | BGP. The existence of aggregate EID-Prefixes in a Map-Server's | |||
database means that it MAY receive Map Requests for EID-Prefixes that | database means that it may receive Map Requests for EID-Prefixes that | |||
match an aggregate but do not match a registered prefix; Section 8.3 | match an aggregate but do not match a registered prefix; Section 8.3 | |||
describes how this is handled. | describes how this is handled. | |||
Map-Register messages are sent periodically from an ETR to a Map- | Map-Register messages are sent periodically from an ETR to a Map- | |||
Server with a suggested interval between messages of one minute. A | Server with a suggested interval between messages of one minute. A | |||
Map-Server SHOULD time out and remove an ETR's registration if it has | Map-Server SHOULD time out and remove an ETR's registration if it has | |||
not received a valid Map-Register message within the past | not received a valid Map-Register message within the past | |||
three minutes. When first contacting a Map-Server after restart or | three minutes. When first contacting a Map-Server after restart or | |||
changes to its EID-to-RLOC database mappings, an ETR MAY initially | changes to its EID-to-RLOC database mappings, an ETR MAY initially | |||
send Map-Register messages at an increased frequency, up to one every | send Map-Register messages at an increased frequency, up to one every | |||
skipping to change at page 34, line 21 ¶ | skipping to change at page 34, line 21 ¶ | |||
this flag by an ETR would be to set it for Map-Register messages sent | this flag by an ETR would be to set it for Map-Register messages sent | |||
during the initial "quick registration" with a Map-Server but then | during the initial "quick registration" with a Map-Server but then | |||
set it only occasionally during steady-state maintenance of its | set it only occasionally during steady-state maintenance of its | |||
association with that Map-Server. Note that the Map-Notify message | association with that Map-Server. Note that the Map-Notify message | |||
is sent to UDP destination port 4342, not to the source port | is sent to UDP destination port 4342, not to the source port | |||
specified in the original Map-Register message. | specified in the original Map-Register message. | |||
Note that a one-minute minimum registration interval during | Note that a one-minute minimum registration interval during | |||
maintenance of an ETR-Map-Server association places a lower bound on | maintenance of an ETR-Map-Server association places a lower bound on | |||
how quickly and how frequently a mapping database entry can be | how quickly and how frequently a mapping database entry can be | |||
updated. This MAY have implications for what sorts of mobility can | updated. This may have implications for what sorts of mobility can | |||
be supported directly by the mapping system; shorter registration | be supported directly by the mapping system; shorter registration | |||
intervals or other mechanisms might be needed to support faster | intervals or other mechanisms might be needed to support faster | |||
mobility in some cases. For a discussion on one way that faster | mobility in some cases. For a discussion on one way that faster | |||
mobility MAY be implemented for individual devices, please see | mobility may be implemented for individual devices, please see | |||
[I-D.ietf-lisp-mn]. | [I-D.ietf-lisp-mn]. | |||
An ETR MAY also request, by setting the "proxy Map-Reply" flag | An ETR MAY also request, by setting the "proxy Map-Reply" flag | |||
(P-bit) in the Map-Register message, that a Map-Server answer Map- | (P-bit) in the Map-Register message, that a Map-Server answer Map- | |||
Requests instead of forwarding them to the ETR. See Section 7.1 for | Requests instead of forwarding them to the ETR. See Section 7.1 for | |||
details on how the Map-Server sets certain flags (such as those | details on how the Map-Server sets certain flags (such as those | |||
indicating whether the message is authoritative and how returned | indicating whether the message is authoritative and how returned | |||
Locators SHOULD be treated) when sending a Map-Reply on behalf of an | Locators SHOULD be treated) when sending a Map-Reply on behalf of an | |||
ETR. When an ETR requests proxy reply service, it SHOULD include all | ETR. When an ETR requests proxy reply service, it SHOULD include all | |||
RLOCs for all ETRs for the EID-Prefix being registered, along with | RLOCs for all ETRs for the EID-Prefix being registered, along with | |||
skipping to change at page 35, line 17 ¶ | skipping to change at page 35, line 17 ¶ | |||
8.3. Map-Server Processing | 8.3. Map-Server Processing | |||
Once a Map-Server has EID-Prefixes registered by its client ETRs, it | Once a Map-Server has EID-Prefixes registered by its client ETRs, it | |||
can accept and process Map-Requests for them. | can accept and process Map-Requests for them. | |||
In response to a Map-Request (received over the ALT if LISP-ALT is in | In response to a Map-Request (received over the ALT if LISP-ALT is in | |||
use), the Map-Server first checks to see if the destination EID | use), the Map-Server first checks to see if the destination EID | |||
matches a configured EID-Prefix. If there is no match, the Map- | matches a configured EID-Prefix. If there is no match, the Map- | |||
Server returns a Negative Map-Reply with action code "Natively- | Server returns a Negative Map-Reply with action code "Natively- | |||
Forward" and a 15-minute TTL. This MAY occur if a Map Request is | Forward" and a 15-minute TTL. This can occur if a Map Request is | |||
received for a configured aggregate EID-Prefix for which no more- | received for a configured aggregate EID-Prefix for which no more- | |||
specific EID-Prefix exists; it indicates the presence of a non-LISP | specific EID-Prefix exists; it indicates the presence of a non-LISP | |||
"hole" in the aggregate EID-Prefix. | "hole" in the aggregate EID-Prefix. | |||
Next, the Map-Server checks to see if any ETRs have registered the | Next, the Map-Server checks to see if any ETRs have registered the | |||
matching EID-Prefix. If none are found, then the Map-Server returns | matching EID-Prefix. If none are found, then the Map-Server returns | |||
a Negative Map-Reply with action code "Natively-Forward" and a | a Negative Map-Reply with action code "Natively-Forward" and a | |||
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 | |||
skipping to change at page 35, line 47 ¶ | skipping to change at page 35, line 47 ¶ | |||
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 | |||
RLOC in the Map-Request, not to the Map-Server. Unless also acting | RLOC in the Map-Request, not to the Map-Server. Unless also acting | |||
as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; any | as a Map-Resolver, a Map-Server should never receive Map-Replies; any | |||
such messages SHOULD be discarded without response, perhaps | such messages SHOULD be discarded without response, perhaps | |||
accompanied by the logging of a diagnostic message if the rate of | accompanied by the logging of a diagnostic message if the rate of | |||
Map-Replies is suggestive of malicious traffic. | Map-Replies is suggestive of malicious traffic. | |||
8.4. Map-Resolver Processing | 8.4. Map-Resolver Processing | |||
Upon receipt of an Encapsulated Map-Request, a Map-Resolver | Upon receipt of an Encapsulated Map-Request, a Map-Resolver | |||
decapsulates the enclosed message and then searches for the requested | decapsulates the enclosed message and then searches for the requested | |||
EID in its local database of mapping entries (statically configured | EID in its local database of mapping entries (statically configured | |||
or learned from associated ETRs if the Map-Resolver is also a Map- | or learned from associated ETRs if the Map-Resolver is also a Map- | |||
skipping to change at page 37, line 26 ¶ | skipping to change at page 37, line 26 ¶ | |||
messages does not provide protection against "replay" attacks by a | messages does not provide protection against "replay" attacks by a | |||
"man-in-the-middle". Additional work is needed in this area. | "man-in-the-middle". Additional work is needed in this area. | |||
[I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin | [I-D.ietf-lisp-sec] defines a proposed mechanism for providing origin | |||
authentication, integrity, anti-replay protection, and prevention of | authentication, integrity, anti-replay protection, and prevention of | |||
man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- | man-in-the-middle and "overclaiming" attacks on the Map-Request/Map- | |||
Reply exchange. Work is ongoing on this and other proposals for | Reply exchange. Work is ongoing on this and other proposals for | |||
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. 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: | |||
skipping to change at page 38, line 27 ¶ | skipping to change at page 38, line 27 ¶ | |||
11. IANA Considerations | 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". | |||
11.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 | |||
skipping to change at page 40, line 30 ¶ | skipping to change at page 40, line 30 ¶ | |||
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. | |||
12. References | 12. References | |||
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-00 (work in progress), July 2018. | lisp-6834bis-01 (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-14 (work in progress), | (LISP)", draft-ietf-lisp-rfc6830bis-16 (work in progress), | |||
July 2018. | August 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>. | |||
skipping to change at page 45, line 19 ¶ | skipping to change at page 45, 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-13 | B.1. Changes to draft-ietf-lisp-rfc6833bis-14 | |||
o Posted September 2018. | ||||
o Changes to reflect comments from Genart review. | ||||
B.2. 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.2. Changes to draft-ietf-lisp-rfc6833bis-12 | B.3. 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.3. Changes to draft-ietf-lisp-rfc6833bis-11 | B.4. 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.4. Changes to draft-ietf-lisp-rfc6833bis-10 | B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-09 | B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-08 | B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-07 | B.8. 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 5 ¶ | skipping to change at page 47, line 9 ¶ | |||
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.8. Changes to draft-ietf-lisp-rfc6833bis-06 | B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-05 | B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-04 | B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-03 | B.12. 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.12. Changes to draft-ietf-lisp-rfc6833bis-02 | B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-01 | B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-00 | B.15. 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.15. Changes to draft-farinacci-lisp-rfc6833bis-00 | B.16. 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. 40 change blocks. | ||||
56 lines changed or deleted | 63 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/ |