< draft-ietf-lisp-rfc6833bis-17.txt | draft-ietf-lisp-rfc6833bis-18.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: April 6, 2019 UPC/BarcelonaTech | Expires: April 14, 2019 UPC/BarcelonaTech | |||
October 3, 2018 | October 11, 2018 | |||
Locator/ID Separation Protocol (LISP) Control-Plane | Locator/ID Separation Protocol (LISP) Control-Plane | |||
draft-ietf-lisp-rfc6833bis-17 | draft-ietf-lisp-rfc6833bis-18 | |||
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 47 ¶ | skipping to change at page 1, line 47 ¶ | |||
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 April 6, 2019. | This Internet-Draft will expire on April 14, 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 27 ¶ | skipping to change at page 2, line 27 ¶ | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 | 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 | 5. LISP IPv4 and IPv6 Control-Plane Packet Formats . . . . . . . 8 | |||
5.1. LISP Control Packet Type Allocations . . . . . . . . . . 10 | 5.1. LISP Control Packet Type Allocations . . . . . . . . . . 11 | |||
5.2. Map-Request Message Format . . . . . . . . . . . . . . . 11 | 5.2. Map-Request Message Format . . . . . . . . . . . . . . . 12 | |||
5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 14 | 5.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . . . 15 | |||
5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 16 | 5.4. Map-Reply Message Format . . . . . . . . . . . . . . . . 17 | |||
5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 20 | 5.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . . . 21 | |||
5.6. Map-Register Message Format . . . . . . . . . . . . . . . 23 | 5.6. Map-Register Message Format . . . . . . . . . . . . . . . 24 | |||
5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 26 | 5.7. Map-Notify/Map-Notify-Ack Message Format . . . . . . . . 27 | |||
5.8. Encapsulated Control Message Format . . . . . . . . . . . 28 | 5.8. Encapsulated Control Message Format . . . . . . . . . . . 29 | |||
6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 30 | 6. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 31 | |||
6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 30 | 6.1. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . . . 31 | |||
7. Routing Locator Reachability . . . . . . . . . . . . . . . . 31 | 7. Routing Locator Reachability . . . . . . . . . . . . . . . . 32 | |||
7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 33 | 7.1. RLOC-Probing Algorithm . . . . . . . . . . . . . . . . . 34 | |||
8. Interactions with Other LISP Components . . . . . . . . . . . 34 | 8. Interactions with Other LISP Components . . . . . . . . . . . 35 | |||
8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 34 | 8.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . 35 | |||
8.2. EID-Prefix Configuration and ETR Registration . . . . . . 35 | 8.2. EID-Prefix Configuration and ETR Registration . . . . . . 36 | |||
8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 37 | 8.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 38 | |||
8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 38 | 8.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 39 | |||
8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 38 | 8.4.1. Anycast Operation . . . . . . . . . . . . . . . . . . 39 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 | |||
10. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 40 | 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 41 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 | 11. Changes since RFC 6833 . . . . . . . . . . . . . . . . . . . 41 | |||
11.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 41 | 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 | |||
11.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 41 | 12.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 42 | |||
11.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 41 | 12.2. LISP Packet Type Codes . . . . . . . . . . . . . . . . . 42 | |||
11.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 42 | 12.3. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . 43 | |||
11.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 42 | 12.4. LISP Address Type Codes . . . . . . . . . . . . . . . . 43 | |||
11.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 43 | 12.5. LISP Algorithm ID Numbers . . . . . . . . . . . . . . . 44 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 12.6. LISP Bit Flags . . . . . . . . . . . . . . . . . . . . . 44 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 46 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 46 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 47 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 | 13.2. Informative References . . . . . . . . . . . . . . . . . 48 | |||
Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 53 | |||
B.1. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 51 | Appendix B. Document Change Log . . . . . . . . . . . . . . . . 53 | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 51 | B.1. Changes to draft-ietf-lisp-rfc6833bis-18 . . . . . . . . 53 | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 51 | B.2. Changes to draft-ietf-lisp-rfc6833bis-17 . . . . . . . . 53 | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 52 | B.3. Changes to draft-ietf-lisp-rfc6833bis-16 . . . . . . . . 54 | |||
B.5. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 52 | B.4. Changes to draft-ietf-lisp-rfc6833bis-15 . . . . . . . . 54 | |||
B.6. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 52 | B.5. Changes to draft-ietf-lisp-rfc6833bis-14 . . . . . . . . 54 | |||
B.7. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 52 | B.6. Changes to draft-ietf-lisp-rfc6833bis-13 . . . . . . . . 54 | |||
B.8. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 52 | B.7. Changes to draft-ietf-lisp-rfc6833bis-12 . . . . . . . . 54 | |||
B.9. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 52 | B.8. Changes to draft-ietf-lisp-rfc6833bis-11 . . . . . . . . 54 | |||
B.10. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 53 | B.9. Changes to draft-ietf-lisp-rfc6833bis-10 . . . . . . . . 55 | |||
B.11. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 53 | B.10. Changes to draft-ietf-lisp-rfc6833bis-09 . . . . . . . . 55 | |||
B.12. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 53 | B.11. Changes to draft-ietf-lisp-rfc6833bis-08 . . . . . . . . 55 | |||
B.13. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 54 | B.12. Changes to draft-ietf-lisp-rfc6833bis-07 . . . . . . . . 55 | |||
B.14. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 54 | B.13. Changes to draft-ietf-lisp-rfc6833bis-06 . . . . . . . . 56 | |||
B.15. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 54 | B.14. Changes to draft-ietf-lisp-rfc6833bis-05 . . . . . . . . 56 | |||
B.16. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 54 | B.15. Changes to draft-ietf-lisp-rfc6833bis-04 . . . . . . . . 56 | |||
B.17. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 55 | B.16. Changes to draft-ietf-lisp-rfc6833bis-03 . . . . . . . . 57 | |||
B.18. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 55 | B.17. Changes to draft-ietf-lisp-rfc6833bis-02 . . . . . . . . 57 | |||
B.19. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 55 | B.18. Changes to draft-ietf-lisp-rfc6833bis-01 . . . . . . . . 57 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 | B.19. Changes to draft-ietf-lisp-rfc6833bis-00 . . . . . . . . 57 | |||
B.20. Changes to draft-farinacci-lisp-rfc6833bis-00 . . . . . . 57 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 | ||||
1. Introduction | 1. Introduction | |||
The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see | The Locator/ID Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see | |||
also [I-D.ietf-lisp-introduction]) specifies an architecture and | also [I-D.ietf-lisp-introduction]) specifies an architecture and | |||
mechanism for dynamic tunneling by logically separating the addresses | mechanism for dynamic tunneling by logically separating the addresses | |||
currently used by IP in two separate name spaces: Endpoint IDs | currently used by IP in two separate name spaces: Endpoint IDs | |||
(EIDs), used within sites; and Routing Locators (RLOCs), used on the | (EIDs), used within sites; and Routing Locators (RLOCs), used on the | |||
transit networks that make up the Internet infrastructure. To | transit networks that make up the Internet infrastructure. To | |||
achieve this separation, LISP defines protocol mechanisms for mapping | achieve this separation, LISP defines protocol mechanisms for mapping | |||
skipping to change at page 8, line 31 ¶ | skipping to change at page 8, line 31 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
/ | Source Port | Dest Port | | / | Source Port | Dest Port | | |||
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
\ | UDP Length | UDP Checksum | | \ | UDP Length | UDP Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| LISP Message | | | LISP Message | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
IPv4 UDP LISP Control Message | ||||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|Version| Traffic Class | Flow Label | | |Version| Traffic Class | Flow Label | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Payload Length | Next Header=17| Hop Limit | | | Payload Length | Next Header=17| Hop Limit | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+ + | + + | |||
| | | | | | |||
skipping to change at page 9, line 15 ¶ | skipping to change at page 9, line 37 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
/ | Source Port | Dest Port | | / | Source Port | Dest Port | | |||
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
\ | UDP Length | UDP Checksum | | \ | UDP Length | UDP Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
| LISP Message | | | LISP Message | | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
IPv6 UDP LISP Control Message | ||||
When a UDP Map-Request, Map-Register, or Map-Notify (when used as a | When a UDP Map-Request, Map-Register, or Map-Notify (when used as a | |||
notification message) are sent, the UDP source port is chosen by the | notification message) are sent, the UDP source port is chosen by the | |||
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. | |||
skipping to change at page 13, line 30 ¶ | skipping to change at page 14, line 30 ¶ | |||
ITR-RLOC Address: This is used to give the ETR the option of | ITR-RLOC Address: This is used to give the ETR the option of | |||
selecting the destination address from any address family for the | selecting the destination address from any address family for the | |||
Map-Reply message. This address MUST be a routable RLOC address | Map-Reply message. This address MUST be a routable RLOC address | |||
of the sender of the Map-Request message. | of the sender of the Map-Request message. | |||
EID mask-len: This is the mask length for the EID-Prefix. | EID mask-len: This is the mask length for the EID-Prefix. | |||
EID-Prefix-AFI: This is the address family of the EID-Prefix | EID-Prefix-AFI: This is the address family of the EID-Prefix | |||
according to [AFI] and [RFC8060]. | according to [AFI] and [RFC8060]. | |||
EID-Prefix: This prefix is 4 octets for an IPv4 address family and | EID-Prefix: This prefix address length is 4 octets for an IPv4 | |||
16 octets for an IPv6 address family when the EID-Prefix-AFI is 1 | address family and 16 octets for an IPv6 address family when the | |||
or 2, respectively. For other AFIs [AFI], the length varies and | EID-Prefix-AFI is 1 or 2, respectively. For other AFIs [AFI], the | |||
for the LCAF AFI the format is defined in [RFC8060]. When a Map- | address length varies and for the LCAF AFI the format is defined | |||
Request is sent by an ITR because a data packet is received for a | in [RFC8060]. When a Map-Request is sent by an ITR because a data | |||
destination where there is no mapping entry, the EID-Prefix is set | packet is received for a destination where there is no mapping | |||
to the destination IP address of the data packet, and the 'EID | entry, the EID-Prefix is set to the destination IP address of the | |||
mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. | data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 | |||
When an xTR wants to query a site about the status of a mapping it | or IPv6, respectively. When an xTR wants to query a site about | |||
already has cached, the EID-Prefix used in the Map-Request has the | the status of a mapping it already has cached, the EID-Prefix used | |||
same mask length as the EID-Prefix returned from the site when it | in the Map-Request has the same mask-length as the EID-Prefix | |||
sent a Map-Reply message. | returned from the site when it sent a Map-Reply message. | |||
Map-Reply Record: When the M-bit is set, this field is the size of a | Map-Reply Record: When the M-bit is set, this field is the size of a | |||
single "Record" in the Map-Reply format. This Map-Reply record | single "Record" in the Map-Reply format. This Map-Reply record | |||
contains the EID-to-RLOC mapping entry associated with the Source | contains the EID-to-RLOC mapping entry associated with the Source | |||
EID. This allows the ETR that will receive this Map-Request to | EID. This allows the ETR that will receive this Map-Request to | |||
cache the data if it chooses to do so. | cache the data if it chooses to do so. | |||
5.3. EID-to-RLOC UDP Map-Request Message | 5.3. EID-to-RLOC UDP Map-Request Message | |||
A Map-Request is sent from an ITR when it needs a mapping for an EID, | A Map-Request is sent from an ITR when it needs a mapping for an EID, | |||
skipping to change at page 20, line 17 ¶ | skipping to change at page 21, line 17 ¶ | |||
encapsulated packet can be an anycast address as well. The source | encapsulated packet can be an anycast address as well. The source | |||
or destination RLOC MUST NOT be the broadcast address | or destination RLOC MUST NOT be the broadcast address | |||
(255.255.255.255 or any subnet broadcast address known to the | (255.255.255.255 or any subnet broadcast address known to the | |||
router) and MUST NOT be a link-local multicast address. The | router) and MUST NOT be a link-local multicast address. The | |||
source RLOC MUST NOT be a multicast address. The destination RLOC | source RLOC MUST NOT be a multicast address. The destination RLOC | |||
SHOULD be a multicast address if it is being mapped from a | SHOULD be a multicast address if it is being mapped from a | |||
multicast destination EID. | multicast destination EID. | |||
5.5. EID-to-RLOC UDP Map-Reply Message | 5.5. EID-to-RLOC UDP Map-Reply Message | |||
A Map-Reply returns an EID-Prefix with a prefix length that is less | A Map-Reply returns an EID-Prefix with a mask-length that is less | |||
than or equal to the EID being requested. The EID being requested is | than or equal to the EID being requested. The EID being requested is | |||
either from the destination field of an IP header of a Data-Probe or | either from the destination field of an IP header of a Data-Probe or | |||
the EID record of a Map-Request. The RLOCs in the Map-Reply are | the EID record of a Map-Request. The RLOCs in the Map-Reply are | |||
routable IP addresses of all ETRs for the LISP site. Each RLOC | routable IP addresses of all ETRs for the LISP site. Each RLOC | |||
conveys status reachability but does not convey path reachability | conveys status reachability but does not convey path reachability | |||
from a requester's perspective. Separate testing of path | from a requester's perspective. Separate testing of path | |||
reachability is required. See RLOC-reachability Section 7.1 for | reachability is required. See RLOC-reachability Section 7.1 for | |||
details. | details. | |||
Note that a Map-Reply MAY contain different EID-Prefix granularity | Note that a Map-Reply MAY contain different EID-Prefix granularity | |||
(prefix + length) than the Map-Request that triggers it. This might | (prefix + mask-length) than the Map-Request that triggers it. This | |||
occur if a Map-Request were for a prefix that had been returned by an | might occur if a Map-Request were for a prefix that had been returned | |||
earlier Map-Reply. In such a case, the requester updates its cache | by an earlier Map-Reply. In such a case, the requester updates its | |||
with the new prefix information and granularity. For example, a | cache with the new prefix information and granularity. For example, | |||
requester with two cached EID-Prefixes that are covered by a Map- | a requester with two cached EID-Prefixes that are covered by a Map- | |||
Reply containing one less-specific prefix replaces the entry with the | Reply containing one less-specific prefix replaces the entry with the | |||
less-specific EID-Prefix. Note that the reverse, replacement of one | less-specific EID-Prefix. Note that the reverse, replacement of one | |||
less-specific prefix with multiple more-specific prefixes, can also | less-specific prefix with multiple more-specific prefixes, can also | |||
occur, not by removing the less-specific prefix but rather by adding | occur, not by removing the less-specific prefix but rather by adding | |||
the more-specific prefixes that, during a lookup, will override the | the more-specific prefixes that, during a lookup, will override the | |||
less-specific prefix. | less-specific prefix. | |||
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 mask-lengths, the database mapping | |||
have overlapping EID-prefixes. When overlapping EID-prefixes exist, | system may have overlapping EID-prefixes. When overlapping EID- | |||
a Map-Request with an EID that best matches any EID-Prefix MUST be | prefixes exist, a Map-Request with an EID that best matches any EID- | |||
returned in a single Map-Reply message. For instance, if an ETR had | Prefix MUST be returned in a single Map-Reply message. For instance, | |||
database mapping entries for EID-Prefixes: | if an ETR had database mapping entries for EID-Prefixes: | |||
2001:db8::/16 | 2001:db8::/16 | |||
2001:db8:1::/24 | 2001:db8:1::/24 | |||
2001:db8:1:1::/32 | 2001:db8:1:1::/32 | |||
2001:db8:1:2::/32 | 2001:db8:1:2::/32 | |||
A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a | A Map-Request for EID 2001:db8:1:1::1 would cause a Map-Reply with a | |||
record 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 | |||
2001:db8:1:1::/32. | 2001:db8:1:1::/32. | |||
skipping to change at page 24, line 39 ¶ | skipping to change at page 25, line 39 ¶ | |||
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 | |||
Record Count. | Record Count. | |||
Nonce: This 8-octet 'Nonce' field is set to 0 in Map-Register | Nonce: This 8-octet 'Nonce' field is incremented each time a Map- | |||
messages if no Map-Notify message is expected to acknowledge it. | Register message is sent. When a Map-Register acknowledgement is | |||
Since the Map-Register message is authenticated, the 'Nonce' field | requested, the nonce is returned by Map-Servers in Map-Notify | |||
is not currently used for any security function but may be in the | messages. Since the entire Map-Register message is authenticated, | |||
future as part of an anti-replay solution. | the 'Nonce' field serves to protect against Map-Register replay | |||
attacks. | ||||
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 12.5 for codepoint | |||
assignments. | assignments. | |||
Authentication Data Length: This is the length in octets of the | Authentication Data Length: This is the length in octets of the | |||
'Authentication Data' field that follows this field. The length | 'Authentication Data' field that follows this field. The length | |||
of the 'Authentication Data' field is dependent on the MAC | of the 'Authentication Data' field is dependent on the MAC | |||
algorithm used. The length field allows a device that doesn't | algorithm used. The length field allows a device that doesn't | |||
know the MAC algorithm to correctly parse the packet. | know the MAC algorithm to correctly parse the packet. | |||
Authentication Data: This is the output of the MAC algorithm. The | Authentication Data: This is the output of the MAC algorithm. The | |||
entire Map-Register payload (from and including the LISP message | entire Map-Register payload (from and including the LISP message | |||
skipping to change at page 40, line 5 ¶ | skipping to change at page 41, line 5 ¶ | |||
transport-level integrity and anti-reply protection mechanism such as | transport-level integrity and anti-reply protection mechanism such as | |||
IPSEC [RFC6071]. In addition, a compromised ETR can overclaim the | IPSEC [RFC6071]. In addition, a compromised ETR can overclaim the | |||
prefix it owns and successfully register it on its corresponding Map- | prefix it owns and successfully register it on its corresponding Map- | |||
Server. To mitigate this and as noted in Section 8.2, a Map-Server | Server. To mitigate this and as noted in Section 8.2, a Map-Server | |||
SHOULD verify that all EID-Prefixes registered by an ETR match the | SHOULD verify that all EID-Prefixes registered by an ETR match the | |||
configuration stored on the Map-Server. | configuration stored on the Map-Server. | |||
A complete LISP threat analysis has been published in [RFC7835]. | A complete LISP threat analysis has been published in [RFC7835]. | |||
Please refer to it for more detailed security related details. | Please refer to it for more detailed security related details. | |||
10. Changes since RFC 6833 | 10. Privacy Considerations | |||
As noted by [RFC6973] privacy is a complex issue that greatly depends | ||||
on the specific protocol use-case and deployment. As noted in | ||||
section 1.1 of [I-D.ietf-lisp-rfc6830bis] LISP focuses on use-cases | ||||
where entities communicate over the public Internet while keeping | ||||
separate addressing and topology. In what follows we detail the | ||||
privacy threats introduced by the LISP Control Plane, the analysis is | ||||
based on the guidelines detailed in [RFC6973]. | ||||
LISP can use long-lived identifiers (EIDs) that survive mobility | ||||
events. Such identifiers bind to the RLOCs of the nodes, which | ||||
represents the topological location with respect to the specific LISP | ||||
deployments. In addition, EID-to-RLOC mappings are typically | ||||
considered public information within the LISP deployment when | ||||
control-plane messages are not encrypted, and can be eavesdropped | ||||
while Map-Request messages are sent to the corresponding Map- | ||||
Resolvers or Map-Register messages to Map-Servers. | ||||
In this context, attackers can correlate the EID with the RLOC and | ||||
track the corresponding user topological location and/or mobility. | ||||
This can be achieved by off-path attackers, if they are | ||||
authenticated, by querying the mapping system. Deployments concerned | ||||
about this threat can use access control-lists or stronger | ||||
authentication mechanisms [I-D.ietf-lisp-ecdsa-auth] in the mapping | ||||
system to make sure that only authorized users can access this | ||||
information (data minimization). Use of ephemeral EIDs | ||||
[I-D.ietf-lisp-eid-anonymity] to achieve anonymity is another | ||||
mechanism to lessen persistency and identity tracking. | ||||
11. 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. Note that implementations for Map- | in the Map-Notify message. Note that implementations for Map- | |||
skipping to change at page 40, line 38 ¶ | skipping to change at page 42, line 20 ¶ | |||
o The 16-bit Key-ID field of the Map-Register message has been split | o The 16-bit Key-ID field of the Map-Register message has been split | |||
into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. | into a 8-bit Key-ID field and a 8-bit Algorithm-ID field. | |||
o This document adds two new Action values that are in an EID-record | o This document adds two new Action values that are in an EID-record | |||
that appear in Map-Reply, Map-Register, Map-Notify, and Map- | that appear in Map-Reply, Map-Register, Map-Notify, and Map- | |||
Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure | Notify-Ack messages. The Drop/Policy-Denied and Drop/Auth-Failure | |||
are the descriptions for the two new action values. See | are the descriptions for the two new action values. See | |||
Section 5.4 for details. | Section 5.4 for details. | |||
11. IANA Considerations | 12. 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 | 12.1. LISP UDP Port Numbers | |||
The IANA registry has allocated UDP port number 4342 for the LISP | The IANA registry has allocated UDP port number 4342 for the LISP | |||
Control-Plane. IANA has updated the description for UDP port 4342 as | Control-Plane. IANA has updated the description for UDP port 4342 as | |||
follows: | follows: | |||
Keyword Port Transport Layer Description | Keyword Port Transport Layer Description | |||
------- ---- --------------- ----------- | ------- ---- --------------- ----------- | |||
lisp-control 4342 udp LISP Control Packets | lisp-control 4342 udp LISP Control Packets | |||
11.2. LISP Packet Type Codes | 12.2. LISP Packet Type Codes | |||
It is being requested that the IANA be authoritative for LISP Packet | It is being requested that the IANA be authoritative for LISP Packet | |||
Type definitions and it is requested to replace the [RFC6830] | Type definitions and it is requested to replace the [RFC6830] | |||
registry message references with the RFC number assigned to this | registry message references with the RFC number assigned to this | |||
document. | document. | |||
Based on deployment experience of [RFC6830], the Map-Notify-Ack | Based on deployment experience of [RFC6830], the Map-Notify-Ack | |||
message, message type 5, was added by this document. This document | message, message type 5, was added by this document. This document | |||
requests IANA to add it to the LISP Packet Type Registry. | requests IANA to add it to the LISP Packet Type Registry. | |||
Name Number Defined in | Name Number Defined in | |||
---- ------ ----------- | ---- ------ ----------- | |||
LISP Map-Notify-Ack 5 RFC6833bis | LISP Map-Notify-Ack 5 RFC6833bis | |||
11.3. LISP ACT and Flag Fields | 12.3. LISP ACT and Flag Fields | |||
New ACT values can be allocated through IETF review or IESG approval. | New ACT values can be allocated through IETF review or IESG approval. | |||
Four values have already been allocated by [RFC6830], IANA is | Four values have already been allocated by [RFC6830], IANA is | |||
requested to replace the [RFC6830] reference for this registry with | requested to replace the [RFC6830] reference for this registry with | |||
the RFC number assigned to this document and the [RFC6830]. Action | the RFC number assigned to this document and the [RFC6830]. Action | |||
values references with the RFC number assigned to this document. | values references with the RFC number assigned to this document. | |||
This specification changes the name of ACT type 3 value from "Drop" | This specification changes the name of ACT type 3 value from "Drop" | |||
to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ | to "Drop/No-Reason" as well as adding two new ACT values, the "Drop/ | |||
Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). | Policy-Denied" (type 4) and "Drop/Authentication-Failure" (type 5). | |||
skipping to change at page 42, line 23 ¶ | skipping to change at page 43, line 42 ¶ | |||
Auth-Failure entry is dropped because the | Auth-Failure entry is dropped because the | |||
Map-Request for target EID fails an | Map-Request for target EID fails an | |||
authentication check by the xTR or | authentication check by the xTR or | |||
the mapping system. | the mapping system. | |||
In addition, LISP has a number of flag fields and reserved fields, | In addition, LISP has a number of flag fields and reserved fields, | |||
such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New | such as the LISP header flags field [I-D.ietf-lisp-rfc6830bis]. New | |||
bits for flags in these fields can be implemented after IETF review | bits for flags in these fields can be implemented after IETF review | |||
or IESG approval, but these need not be managed by IANA. | or IESG approval, but these need not be managed by IANA. | |||
11.4. LISP Address Type Codes | 12.4. LISP Address Type Codes | |||
LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that | LISP Canonical Address Format (LCAF) [RFC8060] is an 8-bit field that | |||
defines LISP-specific encodings for AFI value 16387. LCAF encodings | defines LISP-specific encodings for AFI value 16387. LCAF encodings | |||
are used for specific use-cases where different address types for | are used for specific use-cases where different address types for | |||
EID-records and RLOC-records are required. | EID-records and RLOC-records are required. | |||
The IANA registry "LISP Canonical Address Format (LCAF) Types" is | The IANA registry "LISP Canonical Address Format (LCAF) Types" is | |||
used for LCAF types. The registry for LCAF types use the | used for LCAF types. The registry for LCAF types use the | |||
Specification Required policy [RFC8126]. Initial values for the | Specification Required policy [RFC8126]. Initial values for the | |||
registry as well as further information can be found in [RFC8060]. | registry as well as further information can be found in [RFC8060]. | |||
Therefore, there is no longer a need for the "LISP Address Type | Therefore, there is no longer a need for the "LISP Address Type | |||
Codes" registry requested by [RFC6830]. This document requests to | Codes" registry requested by [RFC6830]. This document requests to | |||
remove it. | remove it. | |||
11.5. LISP Algorithm ID Numbers | 12.5. LISP Algorithm ID Numbers | |||
In [RFC6830], a request for a "LISP Key ID Numbers" registry was | In [RFC6830], a request for a "LISP Key ID Numbers" registry was | |||
submitted. This document renames the registry to "LISP Algorithm ID | submitted. This document renames the registry to "LISP Algorithm ID | |||
Numbers" and requests the IANA to make the name change. | Numbers" and requests the IANA to make the name change. | |||
The following Algorithm ID values are defined by this specification | The following Algorithm ID values are defined by this specification | |||
as used in any packet type that references a 'Algorithm ID' field: | as used in any packet type that references a 'Algorithm ID' field: | |||
Name Number Defined in | Name Number Defined in | |||
----------------------------------------------- | ----------------------------------------------- | |||
None 0 RFC6833bis | None 0 RFC6833bis | |||
HMAC-SHA-1-96 1 [RFC2404] | HMAC-SHA-1-96 1 [RFC2404] | |||
HMAC-SHA-256-128 2 [RFC4868] | HMAC-SHA-256-128 2 [RFC4868] | |||
Number values are in the range of 0 to 255. The allocation of values | Number values are in the range of 0 to 255. The allocation of values | |||
is on a first come first served basis. | is on a first come first served basis. | |||
11.6. LISP Bit Flags | 12.6. LISP Bit Flags | |||
This document asks IANA to create a registry for allocation of bits | This document asks IANA to create a registry for allocation of bits | |||
in several headers of the LISP control plane, namely in the Map- | in several headers of the LISP control plane, namely in the Map- | |||
Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) | Request, Map-Reply, Map-Register, Encapsulated Control Message (ECM) | |||
messages. Bit allocations are also requested for EID-records and | messages. Bit allocations are also requested for EID-records and | |||
RLOC-records. The registry created should be named "LISP Control | RLOC-records. The registry created should be named "LISP Control | |||
Plane Header Bits". A sub-registry needs to be created per each | Plane Header Bits". A sub-registry needs to be created per each | |||
message and record. The name of each sub-registry is indicated | message and record. The name of each sub-registry is indicated | |||
below, along with its format and allocation of bits defined in this | below, along with its format and allocation of bits defined in this | |||
document. Any additional bits allocation, requires a specification, | document. Any additional bits allocation, requires a specification, | |||
skipping to change at page 46, line 5 ¶ | skipping to change at page 47, line 21 ¶ | |||
+-----------+---------------+--------------+----------------------+ | +-----------+---------------+--------------+----------------------+ | |||
| Spec Name | IANA Name | Bit Position | Description | | | Spec Name | IANA Name | Bit Position | Description | | |||
+-----------+---------------+--------------+----------------------+ | +-----------+---------------+--------------+----------------------+ | |||
| L | rloc-record-L | 13 | Local RLOC Bit | | | L | rloc-record-L | 13 | Local RLOC Bit | | |||
| p | rloc-record-p | 19 | RLOC-Probe Reply Bit | | | p | rloc-record-p | 19 | RLOC-Probe Reply Bit | | |||
| R | rloc-record-R | 19 | RLOC Reachable Bit | | | R | rloc-record-R | 19 | RLOC Reachable Bit | | |||
+-----------+---------------+--------------+----------------------+ | +-----------+---------------+--------------+----------------------+ | |||
LISP RLOC-Record Header Bits | LISP RLOC-Record Header Bits | |||
12. References | 13. References | |||
12.1. Normative References | 13.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-22 (work in progress), | (LISP)", draft-ietf-lisp-rfc6830bis-23 (work in progress), | |||
October 2018. | October 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 46, line 48 ¶ | skipping to change at page 48, line 19 ¶ | |||
[RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and | [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and | |||
Internet Key Exchange (IKE) Document Roadmap", RFC 6071, | Internet Key Exchange (IKE) Document Roadmap", RFC 6071, | |||
DOI 10.17487/RFC6071, February 2011, | DOI 10.17487/RFC6071, February 2011, | |||
<https://www.rfc-editor.org/info/rfc6071>. | <https://www.rfc-editor.org/info/rfc6071>. | |||
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage | |||
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, | |||
March 2017, <https://www.rfc-editor.org/info/rfc8085>. | March 2017, <https://www.rfc-editor.org/info/rfc8085>. | |||
12.2. Informative References | 13.2. Informative References | |||
[AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY | [AFI] IANA, "Address Family Identifier (AFIs)", ADDRESS FAMILY | |||
NUMBERS http://www.iana.org/assignments/address-family- | NUMBERS http://www.iana.org/assignments/address-family- | |||
numbers/address-family-numbers.xhtml?, Febuary 2007. | numbers/address-family-numbers.xhtml?, Febuary 2007. | |||
[GTP-3GPP] | [GTP-3GPP] | |||
3GPP, "General Packet Radio System (GPRS) Tunnelling | 3GPP, "General Packet Radio System (GPRS) Tunnelling | |||
Protocol User Plane (GTPv1-U)", TS.29.281 | Protocol User Plane (GTPv1-U)", TS.29.281 | |||
https://portal.3gpp.org/desktopmodules/Specifications/ | https://portal.3gpp.org/desktopmodules/Specifications/ | |||
SpecificationDetails.aspx?specificationId=1699, January | SpecificationDetails.aspx?specificationId=1699, January | |||
2015. | 2015. | |||
[I-D.herbert-intarea-ila] | [I-D.herbert-intarea-ila] | |||
Herbert, T. and P. Lapukhov, "Identifier-locator | Herbert, T. and P. Lapukhov, "Identifier-locator | |||
addressing for IPv6", draft-herbert-intarea-ila-01 (work | addressing for IPv6", draft-herbert-intarea-ila-01 (work | |||
in progress), March 2018. | in progress), March 2018. | |||
[I-D.ietf-lisp-ecdsa-auth] | ||||
Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA | ||||
Authentication and Authorization", draft-ietf-lisp-ecdsa- | ||||
auth-00 (work in progress), September 2018. | ||||
[I-D.ietf-lisp-eid-anonymity] | ||||
Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP | ||||
EID Anonymity", draft-ietf-lisp-eid-anonymity-02 (work in | ||||
progress), April 2018. | ||||
[I-D.ietf-lisp-eid-mobility] | [I-D.ietf-lisp-eid-mobility] | |||
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, | Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, | |||
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a | F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a | |||
Unified Control Plane", draft-ietf-lisp-eid-mobility-02 | Unified Control Plane", draft-ietf-lisp-eid-mobility-02 | |||
(work in progress), May 2018. | (work in progress), May 2018. | |||
[I-D.ietf-lisp-gpe] | [I-D.ietf-lisp-gpe] | |||
Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. | Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. | |||
Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- | Smith, "LISP Generic Protocol Extension", draft-ietf-lisp- | |||
gpe-06 (work in progress), September 2018. | gpe-06 (work in progress), September 2018. | |||
[I-D.ietf-lisp-introduction] | [I-D.ietf-lisp-introduction] | |||
Cabellos-Aparicio, A. and D. Saucez, "An Architectural | Cabellos-Aparicio, A. and D. Saucez, "An Architectural | |||
Introduction to the Locator/ID Separation Protocol | Introduction to the Locator/ID Separation Protocol | |||
(LISP)", draft-ietf-lisp-introduction-13 (work in | (LISP)", draft-ietf-lisp-introduction-13 (work in | |||
progress), April 2015. | progress), April 2015. | |||
[I-D.ietf-lisp-mn] | [I-D.ietf-lisp-mn] | |||
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP | Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP | |||
Mobile Node", draft-ietf-lisp-mn-03 (work in progress), | Mobile Node", draft-ietf-lisp-mn-04 (work in progress), | |||
October 2018. | October 2018. | |||
[I-D.ietf-lisp-pubsub] | [I-D.ietf-lisp-pubsub] | |||
Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., | |||
Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | Cabellos-Aparicio, A., Barkai, S., Farinacci, D., | |||
Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ | Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ | |||
Subscribe Functionality for LISP", draft-ietf-lisp- | Subscribe Functionality for LISP", draft-ietf-lisp- | |||
pubsub-00 (work in progress), April 2018. | pubsub-01 (work in progress), October 2018. | |||
[I-D.ietf-lisp-sec] | [I-D.ietf-lisp-sec] | |||
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. | |||
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 | Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 | |||
(work in progress), April 2018. | (work in progress), April 2018. | |||
[I-D.ietf-nvo3-vxlan-gpe] | [I-D.ietf-nvo3-vxlan-gpe] | |||
Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol | Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol | |||
Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work | Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work | |||
in progress), April 2018. | in progress), April 2018. | |||
skipping to change at page 49, line 26 ¶ | skipping to change at page 51, line 5 ¶ | |||
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, | [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, | |||
"Locator/ID Separation Protocol Alternative Logical | "Locator/ID Separation Protocol Alternative Logical | |||
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, | Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, | |||
January 2013, <https://www.rfc-editor.org/info/rfc6836>. | January 2013, <https://www.rfc-editor.org/info/rfc6836>. | |||
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to | [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to | |||
Routing Locator (RLOC) Database", RFC 6837, | Routing Locator (RLOC) Database", RFC 6837, | |||
DOI 10.17487/RFC6837, January 2013, | DOI 10.17487/RFC6837, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6837>. | <https://www.rfc-editor.org/info/rfc6837>. | |||
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., | ||||
Morris, J., Hansen, M., and R. Smith, "Privacy | ||||
Considerations for Internet Protocols", RFC 6973, | ||||
DOI 10.17487/RFC6973, July 2013, | ||||
<https://www.rfc-editor.org/info/rfc6973>. | ||||
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, | [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, | |||
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual | L., Sridhar, T., Bursell, M., and C. Wright, "Virtual | |||
eXtensible Local Area Network (VXLAN): A Framework for | eXtensible Local Area Network (VXLAN): A Framework for | |||
Overlaying Virtualized Layer 2 Networks over Layer 3 | Overlaying Virtualized Layer 2 Networks over Layer 3 | |||
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, | Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, | |||
<https://www.rfc-editor.org/info/rfc7348>. | <https://www.rfc-editor.org/info/rfc7348>. | |||
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID | [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID | |||
Separation Protocol (LISP) Threat Analysis", RFC 7835, | Separation Protocol (LISP) Threat Analysis", RFC 7835, | |||
DOI 10.17487/RFC7835, April 2016, | DOI 10.17487/RFC7835, April 2016, | |||
skipping to change at page 51, line 7 ¶ | skipping to change at page 53, line 7 ¶ | |||
DOI 10.17487/RFC8378, May 2018, | DOI 10.17487/RFC8378, May 2018, | |||
<https://www.rfc-editor.org/info/rfc8378>. | <https://www.rfc-editor.org/info/rfc8378>. | |||
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | |||
Decraene, B., Litkowski, S., and R. Shakir, "Segment | Decraene, B., Litkowski, S., and R. Shakir, "Segment | |||
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | |||
July 2018, <https://www.rfc-editor.org/info/rfc8402>. | July 2018, <https://www.rfc-editor.org/info/rfc8402>. | |||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
The authors would like to thank Greg Schudel, Darrel Lewis, John | The original authors would like to thank Greg Schudel, Darrel Lewis, | |||
Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, | John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper | |||
Fabio Maino, and members of the lisp@ietf.org mailing list for their | Skriver, Fabio Maino, and members of the lisp@ietf.org mailing list | |||
feedback and helpful suggestions. | for their 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. | |||
The current authors would like to give a sincere thank you to the | ||||
people who help put LISP on standards track in the IETF. They | ||||
include Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, | ||||
Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete | ||||
Resnick, Colin Perkins, Mirja Kuhlewind, Francis Dupont, Benjamin | ||||
Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, | ||||
Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagen, Mohamed | ||||
Boucadair, Brian Trammell, Sabrina Tanamal, and John Drake. The | ||||
contributions they offered greatly added to the security, scale, and | ||||
robustness of the LISP architecture and protocols. | ||||
Appendix B. Document Change Log | Appendix B. Document Change Log | |||
[RFC Editor: Please delete this section on publication as RFC.] | [RFC Editor: Please delete this section on publication as RFC.] | |||
B.1. Changes to draft-ietf-lisp-rfc6833bis-17 | B.1. Changes to draft-ietf-lisp-rfc6833bis-18 | |||
o Posted mid October 2018. | ||||
o Fixed comments from Eric after more email clarity. | ||||
B.2. Changes to draft-ietf-lisp-rfc6833bis-17 | ||||
o Posted early October 2018. | o Posted early October 2018. | |||
o Changes to reflect comments from Sep 27th Telechat. | o Changes to reflect comments from Sep 27th Telechat. | |||
o Added all flag bit definitions as request for allocation in IANA | o Added all flag bit definitions as request for allocation in IANA | |||
Considersations section. | Considersations section. | |||
o Added an applicability statement in section 1 to address security | o Added an applicability statement in section 1 to address security | |||
concerns from Telechat. | concerns from Telechat. | |||
o Moved m-bit description and IANA request to draft-ietf-lisp-mn. | o Moved m-bit description and IANA request to draft-ietf-lisp-mn. | |||
o Moved I-bit description and IANA request to draft-ietf-lisp- | o Moved I-bit description and IANA request to draft-ietf-lisp- | |||
pubsub. | pubsub. | |||
B.2. Changes to draft-ietf-lisp-rfc6833bis-16 | B.3. Changes to draft-ietf-lisp-rfc6833bis-16 | |||
o Posted Late-September 2018. | o Posted Late-September 2018. | |||
o Re-wrote Security Considerations section. Thanks Albert. | o Re-wrote Security Considerations section. Thanks Albert. | |||
o Added Alvaro text to be more clear about IANA actions. | o Added Alvaro text to be more clear about IANA actions. | |||
B.3. Changes to draft-ietf-lisp-rfc6833bis-15 | B.4. Changes to draft-ietf-lisp-rfc6833bis-15 | |||
o Posted mid-September 2018. | o Posted mid-September 2018. | |||
o Changes to reflect comments from Colin and Mirja. | o Changes to reflect comments from Colin and Mirja. | |||
B.4. Changes to draft-ietf-lisp-rfc6833bis-14 | B.5. 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.5. Changes to draft-ietf-lisp-rfc6833bis-13 | B.6. 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.6. Changes to draft-ietf-lisp-rfc6833bis-12 | B.7. 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.7. Changes to draft-ietf-lisp-rfc6833bis-11 | B.8. 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.8. Changes to draft-ietf-lisp-rfc6833bis-10 | B.9. 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.9. Changes to draft-ietf-lisp-rfc6833bis-09 | B.10. 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.10. Changes to draft-ietf-lisp-rfc6833bis-08 | B.11. 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.11. Changes to draft-ietf-lisp-rfc6833bis-07 | B.12. 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 53, line 45 ¶ | skipping to change at page 56, line 13 ¶ | |||
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.12. Changes to draft-ietf-lisp-rfc6833bis-06 | B.13. 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.13. Changes to draft-ietf-lisp-rfc6833bis-05 | B.14. 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.14. Changes to draft-ietf-lisp-rfc6833bis-04 | B.15. 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.15. Changes to draft-ietf-lisp-rfc6833bis-03 | B.16. 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.16. Changes to draft-ietf-lisp-rfc6833bis-02 | B.17. 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.17. Changes to draft-ietf-lisp-rfc6833bis-01 | B.18. 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.18. Changes to draft-ietf-lisp-rfc6833bis-00 | B.19. 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.19. Changes to draft-farinacci-lisp-rfc6833bis-00 | B.20. 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. 49 change blocks. | ||||
122 lines changed or deleted | 192 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/ |