draft-ietf-lisp-gpe-12.txt   draft-ietf-lisp-gpe-13.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: May 22, 2020 Broadcom Expires: July 9, 2020 Broadcom
P. Agarwal P. Agarwal
Innovium Innovium
D. Lewis D. Lewis
M. Smith M. Smith
Cisco Cisco
November 19, 2019 January 6, 2020
LISP Generic Protocol Extension LISP Generic Protocol Extension
draft-ietf-lisp-gpe-12 draft-ietf-lisp-gpe-13
Abstract Abstract
This document describes extentions to the Locator/ID Separation This document describes extentions 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 May 22, 2020. This Internet-Draft will expire on July 9, 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 3, line 9 skipping to change at page 3, line 9
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]. [I-D.ietf-lisp-rfc6830bis]. Those two features are no longer
available when the P-bit is used. However, appropriate LISP-GPE shim
headers can be defined to 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
functionalities or IOAM metadata. functionalities or IOAM metadata.
Nonce, Map-Versioning and Locator Status Bit fields are not part of
the LISP-GPE header. Shim headers can be used to specify features
such as echo-noncing, map-versioning or reachability by defining
fields of the same size, or larger, of those specified in
[I-D.ietf-lisp-rfc6830bis].
1.1. Conventions 1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Definition of Terms 1.2. Definition of Terms
skipping to change at page 4, line 19 skipping to change at page 4, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits | | Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LISP Header Figure 1: LISP Header
3. Generic Protocol Extension for LISP (LISP-GPE) 3. Generic Protocol Extension for LISP (LISP-GPE)
This document defines two changes to the LISP header in order to This document defines two changes to the LISP header in order to
support multi-protocol encapsulation: the introduction of the P-bit support multi-protocol encapsulation: the introduction of the P-bit
and the definition of a Next Protocol field. This is shown in and the definition of a Next Protocol field. This document specifies
Figure 2 and described below. the protocol behavior when the P-bit is set to 1, no changes are
introduced when the P-bit is set to 0. The LISP-GPE header is shown
in Figure 2 and described below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res. |I|P|K|K| Reserved | Next Protocol | |N|L|E|V|I|P|K|K| Reserved | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | | Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LISP-GPE Header Figure 2: LISP-GPE Header
Bits 0-3 and 8-23: Bits 0-3 and 8-23 of the LISP-GPE header are P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is
Reserved. They MUST be set to zero on transmission and ignored on set to 1 to indicate the presence of the 8 bit Next Protocol
receipt. field.
Features that were implemented with bits 0-3 and 8-23 in
[I-D.ietf-lisp-rfc6830bis], such as echo-noncing, map-versioning
and reachability, can be implemented by defining the appropriate
shim headers.
Instance ID When the I-Bit is set to 1 the high-order 24 bits of the
Instance ID field are used as an Instance ID, as specified in
[I-D.ietf-lisp-rfc6830bis]. The low-order 8 bits are set to zero,
as the Locator-Status-Bits feature is not supported in LISP-GPE.
P-Bit: Flag bit 5 is defined as the Next Protocol bit.
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] with bits N, L, E to the definition in [I-D.ietf-lisp-rfc6830bis].
and V set to 0.
The P-bit is set to 1 to indicate the presence of the 8 bit Next When the P-bit is set to 1, bits N, E, and V MUST be set zero on
Protocol field. The combinations of bits that are allowed when transmission and ignored on receipt. Features equivalent to those
the P-bit is set are the same allowed by that were implemented with bits N,E and V in
[I-D.ietf-lisp-rfc6830bis] when bits N, L, E and V are set to 0. [I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-
versioning, can be implemented by defining appropriate LISP-GPE
shim headers.
Next Protocol: The lower 8 bits of the first 32-bit word are used to Next Protocol: The lower 8 bits of the first 32-bit word are used to
carry a Next Protocol. This Next Protocol field contains the carry a Next Protocol. This Next Protocol field contains the
protocol of the encapsulated payload packet. protocol of the encapsulated payload packet.
This document defines the following Next Protocol values: This document defines the following Next Protocol values:
0x01 : IPv4 0x01 : IPv4
0x02 : IPv6 0x02 : IPv6
skipping to change at page 10, line 19 skipping to change at page 10, line 19
When encapsulating IP packets to a non LISP-GPE capable router the When encapsulating IP packets to a non LISP-GPE capable router the
P-bit MUST be set to 0. That is, the encapsulation format defined in P-bit MUST be set to 0. That is, the encapsulation format defined in
this document MUST NOT be sent to a router that has not indicated this document MUST NOT be sent to a router that has not indicated
that it supports this specification because such a router would that it supports this specification because such a router would
ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so
would misinterpret the other LISP header fields possibly causing would misinterpret the other LISP header fields possibly causing
significant errors. significant errors.
5.1. Detection of ETR Capabilities 5.1. Detection of ETR Capabilities
The detection of ETR capabilities to support multiple data plane The discovery of xTR capabilities to support LISP-GPE is out of the
encapsulations and shim headers is out of the scope of this document. scope of this document. Given that the applicability domain of LISP-
Given that the applicability domain of LISP-GPE is a traffic-managed GPE is a traffic-managed controlled environment, ITR/ETR (xTR)
controlled environment, ITR/ETR (xTR) configuration mechanisms may be configuration mechanisms may be used for this purpose.
used for this purpose.
6. IANA Considerations 6. IANA Considerations
6.1. LISP-GPE Next Protocol Registry 6.1. LISP-GPE Next Protocol Registry
IANA is requested to set up a registry of LISP-GPE "Next Protocol". IANA is requested to set up a registry of LISP-GPE "Next Protocol".
These are 8-bit values. Next Protocol values in the table below are These are 8-bit values. Next Protocol values in the table below are
defined in this document. New values are assigned under the defined in this document. New values are assigned under the
Specification Required policy [RFC8126]. The protocols that are Specification Required policy [RFC8126]. The protocols that are
being assigned values do not themselves need to be IETF standards being assigned values do not themselves need to be IETF standards
skipping to change at page 11, line 6 skipping to change at page 11, line 6
| 0x05..0x7F | Unassigned | | | 0x05..0x7F | Unassigned | |
| 0x82..0xFF | Unassigned | | | 0x82..0xFF | Unassigned | |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
7. Security Considerations 7. Security Considerations
LISP-GPE security considerations are similar to the LISP security LISP-GPE security considerations are similar to the LISP security
considerations and mitigation techniques documented in [RFC7835]. considerations and mitigation techniques documented in [RFC7835].
LISP-GPE, as many encapsulations that use optional extensions, is LISP-GPE, as many encapsulations that use optional extensions, is
subject to on-path adversaries that by manipulating the g-Bit and the subject to on-path adversaries that by manipulating the P-Bit and the
packet itself can remove part of the payload. Typical integrity packet itself can remove part of the payload or claim to encapsulate
protection mechanisms (such as IPsec) SHOULD be used in combination any protocol payload type. Typical integrity protection mechanisms
with LISP-GPE by those protocol extensions that want to protect from (such as IPsec) SHOULD be used in combination with LISP-GPE by those
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.
skipping to change at page 11, line 51 skipping to change at page 11, line 51
o Puneet Agarwal, Innovium o Puneet Agarwal, Innovium
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-27 (work in progress), (LISP)", draft-ietf-lisp-rfc6830bis-28 (work in progress),
June 2019. November 2019.
[IEEE.802.1Q_2014] [IEEE.802.1Q_2014]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
DOI 10.1109/ieeestd.2014.6991462, December 2014, DOI 10.1109/ieeestd.2014.6991462, December 2014,
<http://ieeexplore.ieee.org/servlet/ <http://ieeexplore.ieee.org/servlet/
opac?punumber=6991460>. opac?punumber=6991460>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 12, line 28 skipping to change at page 12, line 28
Notification", RFC 6040, DOI 10.17487/RFC6040, November Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>. 2010, <https://www.rfc-editor.org/info/rfc6040>.
9.2. Informative References 9.2. Informative References
[I-D.brockners-ippm-ioam-vxlan-gpe] [I-D.brockners-ippm-ioam-vxlan-gpe]
Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A.,
Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE
Encapsulation for In-situ OAM Data", draft-brockners-ippm- Encapsulation for In-situ OAM Data", draft-brockners-ippm-
ioam-vxlan-gpe-02 (work in progress), July 2019. ioam-vxlan-gpe-03 (work in progress), November 2019.
[I-D.ietf-tsvwg-ecn-encap-guidelines] [I-D.ietf-tsvwg-ecn-encap-guidelines]
Briscoe, B., Kaippallimalil, J., and P. Thaler, Briscoe, B., Kaippallimalil, J., and P. Thaler,
"Guidelines for Adding Congestion Notification to "Guidelines for Adding Congestion Notification to
Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn- Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
encap-guidelines-13 (work in progress), May 2019. encap-guidelines-13 (work in progress), May 2019.
[I-D.lemon-vxlan-lisp-gpe-gbp] [I-D.lemon-vxlan-lisp-gpe-gbp]
Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group
Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon- Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon-
 End of changes. 16 change blocks. 
49 lines changed or deleted 36 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/