draft-ietf-lisp-gpe-17.txt   draft-ietf-lisp-gpe-18.txt 
Internet Engineering Task Force F. Maino, Ed. Internet Engineering Task Force F. Maino, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track J. Lemon Intended status: Standards Track J. Lemon
Expires: January 8, 2021 Broadcom Expires: January 14, 2021 Broadcom
P. Agarwal P. Agarwal
Innovium Innovium
D. Lewis D. Lewis
M. Smith M. Smith
Cisco Cisco
July 7, 2020 July 13, 2020
LISP Generic Protocol Extension LISP Generic Protocol Extension
draft-ietf-lisp-gpe-17 draft-ietf-lisp-gpe-18
Abstract Abstract
This document describes extensions to the Locator/ID Separation This document describes extensions to the Locator/ID Separation
Protocol (LISP) Data-Plane, via changes to the LISP header, to Protocol (LISP) Data-Plane, via changes to the LISP header, to
support multi-protocol encapsulation. support multi-protocol encapsulation and allow to introduce new
protocol capabilities.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 8, 2021. This Internet-Draft will expire on January 14, 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 2, line 26 skipping to change at page 2, line 27
4. Implementation and Deployment Considerations . . . . . . . . 6 4. Implementation and Deployment Considerations . . . . . . . . 6
4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6 4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6
4.2. Congestion Control Functionality . . . . . . . . . . . . 7 4.2. Congestion Control Functionality . . . . . . . . . . . . 7
4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8 4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8 4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8
4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11 5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11 6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It The LISP Data-Plane is defined in [I-D.ietf-lisp-rfc6830bis]. It
specifies an encapsulation format that carries IPv4 or IPv6 packets specifies an encapsulation format that carries IPv4 or IPv6 packets
(henceforth jointly referred to as IP) in a LISP header and outer (henceforth jointly referred to as IP) in a LISP header and outer
UDP/IP transport. UDP/IP transport.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
4.2. Congestion Control Functionality 4.2. Congestion Control Functionality
LISP-GPE does not natively provide congestion control functionality LISP-GPE does not natively provide congestion control functionality
and relies on the payload protocol traffic for congestion control. and relies on the payload protocol traffic for congestion control.
As such LISP-GPE MUST be used with congestion controlled traffic or As such LISP-GPE MUST be used with congestion controlled traffic or
within a network that is traffic managed to avoid congestion (TMCE). within a network that is traffic managed to avoid congestion (TMCE).
An operator of a traffic managed network (TMCE) may avoid congestion An operator of a traffic managed network (TMCE) may avoid congestion
by careful provisioning of their networks, rate-limiting of user data by careful provisioning of their networks, rate-limiting of user data
traffic and traffic engineering according to path capacity. traffic and traffic engineering according to path capacity.
Encapsulated payloads may have Explicit Congestion Notification Keeping in mind the reccomendation above, new encapsulated payloads,
mechanisms that may or may not be mapped to the outer IP header ECN when registered with LISP-GPE, should be designed for explicit
field. Such new encapsulated payloads, when registered with LISP- congestion signals to propagate consistently from lower layer
GPE, MUST be accompanied by a set of guidelines derived from protocols into IP. Then the IP internetwork layer can act as a
[I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. portability layer to carry congestion notification from non-IP-aware
congested nodes up to the transport layer (L4). Such new
encapsulated payloads, when registered with LISP-GPE, MUST be
accompanied by a set of guidelines derived from [RFC6040] and SHOULD
follow the guidelines defined in
[I-D.ietf-tsvwg-ecn-encap-guidelines].
4.3. UDP Checksum 4.3. UDP Checksum
For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies
how to handle UDP Checksums encouraging implementors to consider UDP how to handle UDP Checksums encouraging implementors to consider UDP
checksum usage guidelines in section 3.4 of [RFC8085] when it is checksum usage guidelines in section 3.4 of [RFC8085] when it is
desirable to protect UDP and LISP headers against corruption. desirable to protect UDP and LISP headers against corruption.
In order to provide integrity of LISP-GPE headers, options and In order to provide integrity of LISP-GPE headers, options and
payload, for example to avoid mis-delivery of payload to different payload, for example to avoid mis-delivery of payload to different
skipping to change at page 8, line 33 skipping to change at page 8, line 35
An operator MAY choose to disable UDP checksum and use zero checksum An operator MAY choose to disable UDP checksum and use zero checksum
if LISP-GPE packet integrity is provided by other data integrity if LISP-GPE packet integrity is provided by other data integrity
mechanisms such as IPsec or additional checksums or if one of the mechanisms such as IPsec or additional checksums or if one of the
conditions in Section 4.3.1 a, b, c are met. conditions in Section 4.3.1 a, b, c are met.
4.3.1. UDP Zero Checksum Handling with IPv6 4.3.1. UDP Zero Checksum Handling with IPv6
By default, UDP checksum MUST be used when LISP-GPE is transported By default, UDP checksum MUST be used when LISP-GPE is transported
over IPv6. A tunnel endpoint MAY be configured for use with zero UDP over IPv6. A tunnel endpoint MAY be configured for use with zero UDP
checksum if additional requirements in Section 4.3.1 are met. checksum if additional requirements described in this section are
met.
When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6 When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6
headers, UDP headers and LISP-GPE headers and payload from potential headers, UDP headers and LISP-GPE headers and payload from potential
data corruption. As such by default LISP-GPE MUST use UDP checksum data corruption. As such by default LISP-GPE MUST use UDP checksum
when transported over IPv6. An operator MAY choose to configure to when transported over IPv6. An operator MAY choose to configure to
operate with zero UDP checksum if operating in a traffic managed operate with zero UDP checksum if operating in a traffic managed
controlled environment as stated in Section 4.1 if one of the controlled environment as stated in Section 4.1 if one of the
following conditions are met: following conditions are met:
a. It is known that the packet corruption is exceptionally unlikely a. It is known that the packet corruption is exceptionally unlikely
skipping to change at page 12, line 15 skipping to change at page 12, line 24
(such as IPsec) SHOULD be used in combination with LISP-GPE by those (such as IPsec) SHOULD be used in combination with LISP-GPE by those
protocol extensions that want to protect from on-path attackers. protocol extensions that want to protect from on-path attackers.
With LISP-GPE, issues such as data-plane spoofing, flooding, and With LISP-GPE, issues such as data-plane spoofing, flooding, and
traffic redirection may depend on the particular protocol payload traffic redirection may depend on the particular protocol payload
encapsulated. encapsulated.
8. Acknowledgements and Contributors 8. Acknowledgements and Contributors
A special thank you goes to Dino Farinacci for his guidance and A special thank you goes to Dino Farinacci for his guidance and
detailed review. detailed review. Thanks to Tom Herbert for the suggestion to assign
codepoints for experimentations and testing.
This Working Group (WG) document originated as draft-lewis-lisp-gpe; This Working Group (WG) document originated as draft-lewis-lisp-gpe;
the following are its coauthors and contributors along with their the following are its coauthors and contributors along with their
respective affiliations at the time of WG adoption. The editor of respective affiliations at the time of WG adoption. The editor of
this document would like to thank and recognize them and their this document would like to thank and recognize them and their
contributions. These coauthors and contributors provided invaluable contributions. These coauthors and contributors provided invaluable
concepts and content for this document's creation. concepts and content for this document's creation.
o Darrel Lewis, Cisco Systems, Inc. o Darrel Lewis, Cisco Systems, Inc.
 End of changes. 10 change blocks. 
15 lines changed or deleted 23 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/