draft-ietf-lisp-gpe-16.txt   draft-ietf-lisp-gpe-17.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: December 5, 2020 Broadcom Expires: January 8, 2021 Broadcom
P. Agarwal P. Agarwal
Innovium Innovium
D. Lewis D. Lewis
M. Smith M. Smith
Cisco Cisco
June 3, 2020 July 7, 2020
LISP Generic Protocol Extension LISP Generic Protocol Extension
draft-ietf-lisp-gpe-16 draft-ietf-lisp-gpe-17
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.
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 December 5, 2020. This Internet-Draft will expire on January 8, 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3
3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 7 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 and TTL . . . . . . . . . . . . . . . . . . . . 9 4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12 8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
skipping to change at page 3, line 10 skipping to change at page 3, line 10
This document defines an extension for the LISP header, as defined in This document defines an extension for the LISP header, as defined in
[I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling
the encapsulation of Ethernet, IP or any other desired protocol all the encapsulation of Ethernet, IP or any other desired protocol all
the while ensuring compatibility with existing LISP deployments. the while ensuring compatibility with existing LISP deployments.
A flag in the LISP header, called the P-bit, is used to signal the A flag in the LISP header, called the P-bit, is used to signal the
presence of the 8-bit Next Protocol field. The Next Protocol field, presence of the 8-bit Next Protocol field. The Next Protocol field,
when present, uses 8 bits of the field that was allocated to the when present, uses 8 bits of the field that was allocated to the
echo-noncing and map-versioning features in echo-noncing and map-versioning features in
[I-D.ietf-lisp-rfc6830bis]. Those two features are no longer [I-D.ietf-lisp-rfc6830bis]. Those two features are no longer
available when the P-bit is used. However, appropriate LISP-GPE shim available when the P-bit is used. However, appropriate LISP-GPE
headers can be defined to specify capabilities that are equivalent to (LISP Generic Protocol Extension) shim headers can be defined to
echo-noncing and/or map-versioning. specify capabilities that are equivalent to echo-noncing and/or map-
versioning.
Since all of the reserved bits of the LISP Data-Plane header have Since all of the reserved bits of the LISP Data-Plane header have
been allocated, LISP-GPE can also be used to extend the LISP Data- been allocated, LISP-GPE can also be used to extend the LISP Data-
Plane header by defining Next Protocol "shim" headers that implements Plane header by defining Next Protocol "shim" headers that implements
new data plane functions not supported in the LISP header. For new data plane functions not supported in the LISP header. For
example, the use of the Group-Based Policy (GBP) header example, the use of the Group-Based Policy (GBP) header
[I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations, [I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations,
Administration, and Maintenance (IOAM) header Administration, and Maintenance (IOAM) header
[I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered [I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered
an extension to add support in the Data-Plane for Group-Based Policy an extension to add support in the Data-Plane for Group-Based Policy
skipping to change at page 4, line 43 skipping to change at page 4, line 43
P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is
set to 1 to indicate the presence of the 8 bit Next Protocol set to 1 to indicate the presence of the 8 bit Next Protocol
field. field.
If the P-bit is clear (0) the LISP header is bit-by-bit equivalent If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
to the definition in [I-D.ietf-lisp-rfc6830bis]. to the definition in [I-D.ietf-lisp-rfc6830bis].
When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the
'Nonce/Map-Version/Next Protocol' field MUST be set to zero on 'Nonce/Map-Version/Next Protocol' field MUST be set to zero on
transmission and ignored on receipt. Features equivalent to those transmission and MUST be ignored on receipt. Features equivalent
that were implemented with bits N,E and V in to those that were implemented with bits N,E and V in
[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map- [I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-
versioning, can be implemented by defining appropriate LISP-GPE versioning, can be implemented by defining appropriate LISP-GPE
shim headers. shim headers.
When the P-bit is set to 1, the LISP-GPE header is encoded as: When the P-bit is set to 1, the LISP-GPE header is encoded as:
0 x 0 0 x 1 x x 0 x 0 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol | |N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 21 skipping to change at page 5, line 21
Figure 3: LISP-GPE with P-bit set to 1 Figure 3: LISP-GPE with P-bit set to 1
Next Protocol: When the P-bit is set to 1, the lower 8 bits of the Next Protocol: When the P-bit is set to 1, the lower 8 bits of the
first 32-bit word are used to carry a Next Protocol. This Next first 32-bit word are used to carry a Next Protocol. This Next
Protocol field contains the protocol of the encapsulated payload Protocol field contains the protocol of the encapsulated payload
packet. packet.
This document defines the following Next Protocol values: This document defines the following Next Protocol values:
0x00 : Reserved
0x01 : IPv4 0x01 : IPv4
0x02 : IPv6 0x02 : IPv6
0x03 : Ethernet 0x03 : Ethernet
0x04 : Network Service Header (NSH) [RFC8300] 0x04 : Network Service Header (NSH) [RFC8300]
0x05 to 0x7D Unassigned 0x05 to 0x7D: Unassigned
0x7E to 0x7F: Experimentation and testing 0x7E, 0x7F: Experimentation and testing
0x80 to 0xFD: Unassigned (shim headers) 0x80 to 0xFD: Unassigned (shim headers)
0xFE to 0xFF: Experimentation and testing (shim headers) 0xFE, 0xFF: Experimentation and testing (shim headers)
The values are tracked in the IANA LISP-GPE Next Protocol Registry The values are tracked in the IANA LISP-GPE Next Protocol Registry
as described in Section 6.1. as described in Section 6.1.
Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for
experimentation and testing as per [RFC3692]. experimentation and testing as per [RFC3692].
Next protocol values from Ox80 to 0xFD are assigned to protocols Next protocol values from Ox80 to 0xFD are assigned to protocols
encoded as generic "shim" headers. All shim protocols MUST use the encoded as generic "shim" headers. All shim protocols MUST use the
header structure in Figure 4, which includes a Next Protocol field. header structure in Figure 4, which includes a Next Protocol field.
When a shim header is used with other protocols identified by next When shim headers are used with other protocols identified by next
protocol values from 0x0 to 0x7D, the shim header MUST come before protocol values from 0x00 to 0x7F, all the shim headers MUST come
the further protocol, and the next header of the shim will indicate first.
which protocol follows the shim header.
Shim headers can be used to incrementally deploy new GPE features, Shim headers can be used to incrementally deploy new GPE features,
keeping the processing of shim headers known to a given xTR keeping the processing of shim headers known to a given xTR
implementation in the 'fast' path (typically an ASIC), while punting implementation in the 'fast' path (typically an ASIC), while punting
the processing of the remaining new GPE features to the 'slow' path. the processing of the remaining new GPE features to the 'slow' path.
Shim protocols MUST have the first 32 bits defined as: Shim protocols MUST have the first 32 bits defined as:
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
skipping to change at page 6, line 28 skipping to change at page 6, line 30
~ Protocol Specific Fields ~ ~ Protocol Specific Fields ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Shim Header Figure 4: Shim Header
Where: Where:
Type: This field identifies the different messages of this protocol. Type: This field identifies the different messages of this protocol.
Length: The length, in 4-octect units, of this protocol message not Length: The length, in 4-octet units, of this protocol message not
including the first 4 octects. including the first 4 octets.
Reserved: The use of this field is reserved to the protocol defined Reserved: The use of this field is reserved to the protocol defined
in this message. in this message.
Next Protocol Field: The next protocol field contains the protocol Next Protocol Field: The next protocol field contains the protocol
of the encapsulated payload. The values are tracked in the IANA of the encapsulated payload. The values are tracked in the IANA
LISP-GPE Next Protocol Registry as described in Section 6.1. LISP-GPE Next Protocol Registry as described in Section 6.1.
4. Implementation and Deployment Considerations 4. Implementation and Deployment Considerations
skipping to change at page 7, line 42 skipping to change at page 7, line 45
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 Encapsulated payloads may have Explicit Congestion Notification
mechanisms that may or may not be mapped to the outer IP header ECN mechanisms that may or may not be mapped to the outer IP header ECN
field. Such new encapsulated payolads, when registered with LISP- field. Such new encapsulated payloads, when registered with LISP-
GPE, MUST be accompanied by a set of guidelines derived from GPE, MUST be accompanied by a set of guidelines derived from
[I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040]. [I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
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.
skipping to change at page 8, line 22 skipping to change at page 8, line 29
layer errors or malicious modification of the datagram (see layer errors or malicious modification of the datagram (see
Section 3.4 of [RFC8085]). In deployments where such a risk exists, Section 3.4 of [RFC8085]). In deployments where such a risk exists,
an operator SHOULD use additional data integrity mechanisms such as an operator SHOULD use additional data integrity mechanisms such as
offered by IPSec. offered by IPSec.
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
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 in Section 4.3.1 are met.
4.3.1. UDP Zero Checksum Handling with IPv6
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
(perhaps based on knowledge of equipment types in their underlay (perhaps based on knowledge of equipment types in their underlay
skipping to change at page 9, line 46 skipping to change at page 10, line 5
specified in [RFC6936]. specified in [RFC6936].
The requirement to check the source IPv6 address in addition to the The requirement to check the source IPv6 address in addition to the
destination IPv6 address, plus the recommendation against reuse of destination IPv6 address, plus the recommendation against reuse of
source IPv6 addresses among LISP-GPE tunnels collectively provide source IPv6 addresses among LISP-GPE tunnels collectively provide
some mitigation for the absence of UDP checksum coverage of the IPv6 some mitigation for the absence of UDP checksum coverage of the IPv6
header. A traffic-managed controlled environment that satisfies at header. A traffic-managed controlled environment that satisfies at
least one of three conditions listed at the beginning of this section least one of three conditions listed at the beginning of this section
provides additional assurance. provides additional assurance.
4.4. DSCP, ECN and TTL 4.4. DSCP, ECN, TTL, and 802.1Q
When encapsulating IP (including over Ethernet) packets [RFC2983] When encapsulating IP (including over Ethernet) packets [RFC2983]
provides guidance for mapping DSCP between inner and outer IP provides guidance for mapping DSCP between inner and outer IP
headers. The Pipe model typically fits better Network headers. The Pipe model typically fits better Network
virtualization. The DSCP value on the tunnel header is set based on virtualization. The DSCP value on the tunnel header is set based on
a policy (which may be a fixed value, one based on the inner traffic a policy (which may be a fixed value, one based on the inner traffic
class, or some other mechanism for grouping traffic). Some aspects class, or some other mechanism for grouping traffic). Some aspects
of the Uniform model (which treats the inner and outer DSCP value as of the Uniform model (which treats the inner and outer DSCP value as
a single field by copying on ingress and egress) may also apply, such a single field by copying on ingress and egress) may also apply, such
as the ability to remark the inner header on tunnel egress based on as the ability to remark the inner header on tunnel egress based on
 End of changes. 19 change blocks. 
25 lines changed or deleted 27 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/