draft-ietf-lisp-rfc6830bis-33.txt   draft-ietf-lisp-rfc6830bis-34.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: January 30, 2021 D. Meyer Expires: March 13, 2021 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
July 29, 2020 September 9, 2020
The Locator/ID Separation Protocol (LISP) The Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-rfc6830bis-33 draft-ietf-lisp-rfc6830bis-34
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 January 30, 2021. This Internet-Draft will expire on March 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 18, line 14 skipping to change at page 18, line 14
LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is
randomly generated by an ITR when the N-bit is set to 1. Nonce randomly generated by an ITR when the N-bit is set to 1. Nonce
generation algorithms are an implementation matter but are generation algorithms are an implementation matter but are
required to generate different nonces when sending to different required to generate different nonces when sending to different
RLOCs. The nonce is also used when the E-bit is set to request RLOCs. The nonce is also used when the E-bit is set to request
the nonce value to be echoed by the other side when packets are the nonce value to be echoed by the other side when packets are
returned. When the E-bit is clear but the N-bit is set, a remote returned. When the E-bit is clear but the N-bit is set, a remote
ITR is either echoing a previously requested echo-nonce or ITR is either echoing a previously requested echo-nonce or
providing a random nonce. See Section 10.1 for more details. providing a random nonce. See Section 10.1 for more details.
Finally, when both the N and V-bit are not set (N=0, V=0), then
both the Nonce and Map-Version fields are set to 0 and ignored on
receipt.
LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the
'Locator-Status-Bits' field in the LISP header is set by an ITR to 'Locator-Status-Bits' field in the LISP header is set by an ITR to
indicate to an ETR the up/down status of the Locators in the indicate to an ETR the up/down status of the Locators in the
source site. Each RLOC in a Map-Reply is assigned an ordinal source site. Each RLOC in a Map-Reply is assigned an ordinal
value from 0 to n-1 (when there are n RLOCs in a mapping entry). value from 0 to n-1 (when there are n RLOCs in a mapping entry).
The Locator-Status-Bits are numbered from 0 to n-1 from the least The Locator-Status-Bits are numbered from 0 to n-1 from the least
significant bit of the field. The field is 32 bits when the I-bit significant bit of the field. The field is 32 bits when the I-bit
is set to 0 and is 8 bits when the I-bit is set to 1. When a is set to 0 and is 8 bits when the I-bit is set to 1. When a
Locator-Status-Bit is set to 1, the ITR is indicating to the ETR Locator-Status-Bit is set to 1, the ITR is indicating to the ETR
skipping to change at page 21, line 9 skipping to change at page 21, line 9
It is left to the implementor to decide if the stateless or stateful It is left to the implementor to decide if the stateless or stateful
mechanism SHOULD be implemented. Both or neither can be used, since mechanism SHOULD be implemented. Both or neither can be used, since
it is a local decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to deal with MTU
issues, and sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing mechanisms.
Both stateless and stateful mechanisms also apply to Re-encapsulating Both stateless and stateful mechanisms also apply to Re-encapsulating
and Recursive Tunneling, so any actions below referring to an ITR and Recursive Tunneling, so any actions below referring to an ITR
also apply to a TE-ITR. also apply to a TE-ITR.
Both stateless and stateful mechanisms also apply to Re-encapsulating
and Recursive Tunneling, so any actions below referring to an ITR
also apply to a TE-ITR.
7.1. A Stateless Solution to MTU Handling 7.1. A Stateless Solution to MTU Handling
An ITR stateless solution to handle MTU issues is described as An ITR stateless solution to handle MTU issues is described as
follows: follows:
1. Define H to be the size, in octets, of the outer header an ITR 1. Define H to be the size, in octets, of the outer header an ITR
prepends to a packet. This includes the UDP and LISP header prepends to a packet. This includes the UDP and LISP header
lengths. lengths.
2. Define L to be the size, in octets, of the maximum-sized packet 2. Define L to be the size, in octets, of the maximum-sized packet
skipping to change at page 23, line 5 skipping to change at page 22, line 45
stored with the Map-Cache entry associated with the destination stored with the Map-Cache entry associated with the destination
EID the packet is for, the ITR will send an ICMPv4 ICMP EID the packet is for, the ITR will send an ICMPv4 ICMP
Unreachable/Fragmentation-Needed message back to the source. The Unreachable/Fragmentation-Needed message back to the source. The
packet size advertised by the ITR in the ICMP message is the packet size advertised by the ITR in the ICMP message is the
effective MTU minus the LISP encapsulation length. effective MTU minus the LISP encapsulation length.
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
Please note that [RFC1191] and [RFC1981], which describe the use of
ICMP packets for PMTU discovery, can behave suboptimally in the
presence of ICMP black holes or off-path attackers that spoof ICMP.
Possible mitigations include ITRs and ETRs cooperating on MTU probe
packets ([RFC4821], [I-D.ietf-tsvwg-datagram-plpmtud]), or ITRs
storing the beginning of large packets to verify that they match the
echoed packet in ICMP Frag Needed/PTB.
8. Using Virtualization and Segmentation with LISP 8. Using Virtualization and Segmentation with LISP
There are several cases where segregation is needed at the EID level. There are several cases where segregation is needed at the EID level.
For instance, this is the case for deployments containing overlapping For instance, this is the case for deployments containing overlapping
addresses, traffic isolation policies or multi-tenant virtualization. addresses, traffic isolation policies or multi-tenant virtualization.
For these and other scenarios where segregation is needed, Instance For these and other scenarios where segregation is needed, Instance
IDs are used. IDs are used.
An Instance ID can be carried in a LISP-encapsulated packet. An ITR An Instance ID can be carried in a LISP-encapsulated packet. An ITR
that prepends a LISP header will copy a 24-bit value used by the LISP that prepends a LISP header will copy a 24-bit value used by the LISP
skipping to change at page 35, line 44 skipping to change at page 35, line 44
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-06 (work in progress), February 2020. lisp-6834bis-06 (work in progress), February 2020.
[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-27 (work in progress), Plane", draft-ietf-lisp-rfc6833bis-28 (work in progress),
January 2020. July 2020.
[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 37, line 36 skipping to change at page 37, line 36
<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-05 (work in Networks (VPNs)", draft-ietf-lisp-vpn-06 (work in
progress), November 2019. progress), August 2020.
[I-D.ietf-tsvwg-datagram-plpmtud]
Fairhurst, G., Jones, T., Tuexen, M., Ruengeler, I., and
T. Voelker, "Packetization Layer Path MTU Discovery for
Datagram Transports", draft-ietf-tsvwg-datagram-plpmtud-22
(work in progress), June 2020.
[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>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[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>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <https://www.rfc-editor.org/info/rfc1981>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>. 2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced
skipping to change at page 38, line 28 skipping to change at page 38, line 42
[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>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <https://www.rfc-editor.org/info/rfc4459>. 2006, <https://www.rfc-editor.org/info/rfc4459>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007, RFC 4984, DOI 10.17487/RFC4984, September 2007,
<https://www.rfc-editor.org/info/rfc4984>. <https://www.rfc-editor.org/info/rfc4984>.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, (LISP) and Non-LISP Sites", RFC 6832,
DOI 10.17487/RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<https://www.rfc-editor.org/info/rfc6832>. <https://www.rfc-editor.org/info/rfc6832>.
 End of changes. 12 change blocks. 
12 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/