draft-ietf-lisp-rfc6830bis-28.txt   draft-ietf-lisp-rfc6830bis-29.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft lispers.net Internet-Draft lispers.net
Obsoletes: 6830 (if approved) V. Fuller Obsoletes: 6830 (if approved) V. Fuller
Intended status: Standards Track vaf.net Internet Consulting Intended status: Standards Track vaf.net Internet Consulting
Expires: May 20, 2020 D. Meyer Expires: July 11, 2020 D. Meyer
1-4-5.net 1-4-5.net
D. Lewis D. Lewis
Cisco Systems Cisco Systems
A. Cabellos (Ed.) A. Cabellos (Ed.)
UPC/BarcelonaTech UPC/BarcelonaTech
November 17, 2019 January 8, 2020
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-28 draft-ietf-lisp-rfc6830bis-29
Abstract Abstract
This document describes the Data-Plane protocol for the Locator/ID This document describes the Data-Plane protocol for the Locator/ID
Separation Protocol (LISP). LISP defines two namespaces, End-point Separation Protocol (LISP). LISP defines two namespaces, End-point
Identifiers (EIDs) that identify end-hosts and Routing Locators Identifiers (EIDs) that identify end-hosts and Routing Locators
(RLOCs) that identify network attachment points. With this, LISP (RLOCs) that identify network attachment points. With this, LISP
effectively separates control from data, and allows routers to create effectively separates control from data, and allows routers to create
overlay networks. LISP-capable routers exchange encapsulated packets overlay networks. LISP-capable routers exchange encapsulated packets
according to EID-to-RLOC mappings stored in a local Map-Cache. according to EID-to-RLOC mappings stored in a local Map-Cache.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 May 20, 2020. This Internet-Draft will expire on July 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15
6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19
7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19
7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20
7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21
8. Using Virtualization and Segmentation with LISP . . . . . . . 21 8. Using Virtualization and Segmentation with LISP . . . . . . . 21
9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22
10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24
10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26
11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27
12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27
13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28
13.1. Locator-Status-Bits . . . . . . . . . . . . . . . . . . 29 13.1. Locator-Status-Bits . . . . . . . . . . . . . . . . . . 29
13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29
14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30
15. Router Performance Considerations . . . . . . . . . . . . . . 31 15. Router Performance Considerations . . . . . . . . . . . . . . 31
16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32
17. Network Management Considerations . . . . . . . . . . . . . . 33 17. Network Management Considerations . . . . . . . . . . . . . . 33
18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33
skipping to change at page 22, line 23 skipping to change at page 22, line 23
When an ETR decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup. to use for the inner destination EID lookup.
For example, an 802.1Q VLAN tag or VPN identifier could be used as a For example, an 802.1Q VLAN tag or VPN identifier could be used as a
24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case
details. details.
Participants within a LISP deployment must agree on the meaning of Participants within a LISP deployment must agree on the meaning of
Instance ID values. Instance ID values. The source and destination EIDs MUST belong to
the same Instance ID.
9. Routing Locator Selection 9. Routing Locator Selection
The Map-Cache contains the state used by ITRs and PITRs to The Map-Cache contains the state used by ITRs and PITRs to
encapsulate packets. When an ITR/PITR receives a packet from inside encapsulate packets. When an ITR/PITR receives a packet from inside
the LISP site to a destination outside of the site a longest-prefix the LISP site to a destination outside of the site a longest-prefix
match lookup of the EID is done to the Map-Cache (see Section 6). match lookup of the EID is done to the Map-Cache (see Section 6).
The lookup returns a single Locator-Set containing a list of RLOCs The lookup returns a single Locator-Set containing a list of RLOCs
corresponding to the EID's topological location. Each RLOC in the corresponding to the EID's topological location. Each RLOC in the
Locator-Set is associated with a 'Priority' and 'Weight', this Locator-Set is associated with a 'Priority' and 'Weight', this
skipping to change at page 26, line 32 skipping to change at page 26, line 39
other Locator reachability algorithms. Once the ITR determines that other Locator reachability algorithms. Once the ITR determines that
the path to the ETR is down, it can switch to another Locator for the path to the ETR is down, it can switch to another Locator for
that EID-Prefix. that EID-Prefix.
Note that "ITR" and "ETR" are relative terms here. Both devices MUST Note that "ITR" and "ETR" are relative terms here. Both devices MUST
be implementing both ITR and ETR functionality for the echo nonce be implementing both ITR and ETR functionality for the echo nonce
mechanism to operate. mechanism to operate.
The ITR and ETR MAY both go into the echo-nonce-request state at the The ITR and ETR MAY both go into the echo-nonce-request state at the
same time. The number of packets sent or the time during which echo same time. The number of packets sent or the time during which echo
nonce requests are sent is an implementation-specific setting. nonce requests are sent is an implementation-specific setting. In
However, when an ITR is in the echo-nonce-request state, it can echo this case, an xTR receiving the echo-nonce-request packets will
the ETR's nonce in the next set of packets that it encapsulates and suspend the echo-nonce-request state and setup a 'echo-nonce-request-
subsequently continue sending echo-nonce-request packets. state' timer. After the 'echo-nonce-request-state' timer expires it
will resume the echo-nonce-request state.
This mechanism does not completely solve the forward path This mechanism does not completely solve the forward path
reachability problem, as traffic may be unidirectional. That is, the reachability problem, as traffic may be unidirectional. That is, the
ETR receiving traffic at a site MAY not be the same device as an ITR ETR receiving traffic at a site MAY not be the same device as an ITR
that transmits traffic from that site, or the site-to-site traffic is that transmits traffic from that site, or the site-to-site traffic is
unidirectional so there is no ITR returning traffic. unidirectional so there is no ITR returning traffic.
The echo-nonce algorithm is bilateral. That is, if one side sets the The echo-nonce algorithm is bilateral. That is, if one side sets the
E-bit and the other side is not enabled for echo-noncing, then the E-bit and the other side is not enabled for echo-noncing, then the
echoing of the nonce does not occur and the requesting side may echoing of the nonce does not occur and the requesting side may
erroneously consider the Locator unreachable. An ITR SHOULD only set erroneously consider the Locator unreachable. An ITR SHOULD set the
the E-bit in an encapsulated data packet when it knows the ETR is E-bit in an encapsulated data packet when it knows the ETR is enabled
enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- for echo-noncing. This is conveyed by the E-bit in the RLOC-probe
probe Map-Reply message. Map-Reply message.
Many implementations default to not advertising they are echo-nonce Many implementations default to not advertising they are echo-nonce
capable in Map-Reply messages and so RLOC-probing tends to be used capable in Map-Reply messages and so RLOC-probing tends to be used
for RLOC reachability. for RLOC reachability.
The echo-nonce mechanism SHOULD NOT be used over the public Internet The echo-nonce mechanism SHOULD NOT be used over the public Internet
and SHOULD only be used in trusted and closed deployments. Refer to and SHOULD only be used in trusted and closed deployments. Refer to
Section 16 for security issues regarding this mechanism. Section 16 for security issues regarding this mechanism.
11. EID Reachability within a LISP Site 11. EID Reachability within a LISP Site
skipping to change at page 34, line 31 skipping to change at page 34, line 31
20.1. Normative References 20.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-04 (work in progress), August 2019. lisp-6834bis-04 (work in progress), August 2019.
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-
Aparicio, "Locator/ID Separation Protocol (LISP) Control- Aparicio, "Locator/ID Separation Protocol (LISP) Control-
Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), Plane", draft-ietf-lisp-rfc6833bis-26 (work in progress),
June 2019. November 2019.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980, DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>. <https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 36, line 7 skipping to change at page 36, line 7
<http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>. <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.
[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-vpn] [I-D.ietf-lisp-vpn]
Moreno, V. and D. Farinacci, "LISP Virtual Private Moreno, V. and D. Farinacci, "LISP Virtual Private
Networks (VPNs)", draft-ietf-lisp-vpn-04 (work in Networks (VPNs)", draft-ietf-lisp-vpn-05 (work in
progress), May 2019. progress), November 2019.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
 End of changes. 11 change blocks. 
19 lines changed or deleted 21 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/