< 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/