draft-ietf-lisp-gpe-01.txt   draft-ietf-lisp-gpe-02.txt 
Internet Engineering Task Force D. Lewis 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: September 6, 2018 Broadcom Expires: October 1, 2018 Broadcom
P. Agarwal P. Agarwal
Innovium Innovium
L. Kreeger D. Lewis
P. Quinn
M. Smith M. Smith
N. Yadav
F. Maino, Ed.
Cisco Cisco
March 05, 2018 March 30, 2018
LISP Generic Protocol Extension LISP Generic Protocol Extension
draft-ietf-lisp-gpe-01 draft-ietf-lisp-gpe-02
Abstract Abstract
This draft describes extending the Locator/ID Separation Protocol This document describes extending the Locator/ID Separation Protocol
(LISP), via changes to the LISP header, to support multi-protocol (LISP) Data-Plane, via changes to the LISP header, to support multi-
encapsulation. 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
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 6, 2018. This Internet-Draft will expire on October 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 22 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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) . . . . . . . 3 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 3
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4
4.1. Type of Service . . . . . . . . . . . . . . . . . . . . . 5 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR
4.2. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 5 Capabilities . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4.2. Type of Service . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4.3. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements and Contributors . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
LISP, as defined in [RFC6830] and extended in LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines
[I-D.ietf-lisp-rfc6830bis], defines an encapsulation format that an encapsulation format that carries IPv4 or IPv6 (henceforth
carries IPv4 or IPv6 (henceforth referred to as IP) packets in a LISP referred to as IP) packets in a LISP header and outer UDP/IP
header and outer UDP/IP transport. transport.
The LISP header does not specify the protocol being encapsulated and The LISP Data-Plane header does not specify the protocol being
therefore is currently limited to encapsulating only IP packet encapsulated and therefore is currently limited to encapsulating only
payloads. Other protocols, most notably VXLAN [RFC7348] (which IP packet payloads. Other protocols, most notably VXLAN [RFC7348]
defines a similar header format to LISP), are used to encapsulate L2 (which defines a similar header format to LISP), are used to
protocols such as Ethernet. encapsulate L2 protocols such as Ethernet.
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 allocated to the echo-noncing when present, uses 8 bits of the field allocated to the echo-noncing
and map-versioning features. The two features are still available, and map-versioning features. The two features are still available,
skipping to change at page 4, line 27 skipping to change at page 4, line 23
When the P-bit and the N-bit are set to 1, the Nonce field is the When the P-bit and the N-bit are set to 1, the Nonce field is the
middle 16 bits. middle 16 bits.
When the P-bit and the V-bit are set to 1, the Version field is When the P-bit and the V-bit are set to 1, the Version field is
the middle 16 bits. the middle 16 bits.
When the P-bit is set to 1 and the N-bit and the V-bit are both 0, When the P-bit is set to 1 and the N-bit and the V-bit are both 0,
the middle 16-bits are set to 0. the middle 16-bits are set to 0.
This draft defines the following Next Protocol values: This document defines the following Next Protocol values:
0x1 : IPv4 0x1 : IPv4
0x2 : IPv6 0x2 : IPv6
0x3 : Ethernet 0x3 : Ethernet
0x4 : Network Service Header [RFC8300] 0x4 : Network Service Header [RFC8300]
0 1 2 3 0 1 2 3
skipping to change at page 5, line 9 skipping to change at page 4, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator-Status-Bits | | Instance ID/Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LISP-GPE Header LISP-GPE Header
4. Backward Compatibility 4. Backward Compatibility
LISP-GPE uses the same UDP destination port (4341) allocated to LISP. LISP-GPE uses the same UDP destination port (4341) allocated to LISP.
A LISP-GPE router MUST not encapsulate non-IP packets to a LISP The next Section describes a method to determine the Data-Plane
router. A method for determining the capabilities of a LISP router capabilities of a LISP ETR, based on the use of the "Multiple Data-
(GPE or "legacy") is out of the scope of this draft. Planes" LCAF type defined in [RFC8060]. Other mechanisms can be
used, including static xTR configuration, but are out of the scope of
this document.
When encapsulating IP packets to a LISP "legacy" router the P bit When encapsulating IP packets to a non LISP-GPE capable router the P
MUST be set to 0. bit MUST be set to 0.
4.1. Type of Service A LISP-GPE router MUST not encapsulate non-IP packets to a non LISP-
GPE capable router.
4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities
The LISP Canonical Address Format (LCAF) [RFC8060] defines the
"Multiple Data-Planes" LCAF type, that can be included by an ETR in a
Map-Reply to encode the encapsularion formats supported by a given
RLOC. In this way an ITR can be made aware of the capability to
support LISP-GPE on a given RLOC of that ETR.
The "Multiple Data-Planes" LCAF type, as defined in [RFC8060], has a
Reserved-for-Future-Encapsulations 25-bit field. This document
defines the least significant bit of that field as g bit (bit 24 in
the third 32-bit word of the LCAF).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = 16387 | Rsvd1 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 16 | Rsvd2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved-for-Future-Encapsulations |g|U|G|N|v|V|l|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI = x | Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Multiple Data-Planes LCAF Type
g Bit: The RLOCs listed in the AFI-encoded addresses in the next
longword can accept LISP-GPE (Generic Protocol Extension)
encapsulation using destination UDP port 4341
All other fields As defined in [RFC8060]
4.2. Type of Service
When a LISP-GPE router performs Ethernet encapsulation, the inner When a LISP-GPE router performs Ethernet encapsulation, the inner
802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from
the encapsulated frame to the Type of Service field in the outer IPv4 the encapsulated frame to the Type of Service field in the outer IPv4
header, or in the case of IPv6 the 'Traffic Class' field. header, or in the case of IPv6 the 'Traffic Class' field
4.2. VLAN Identifier (VID) 4.3. VLAN Identifier (VID)
When a LISP-GPE router performs Ethernet encapsulation, the inner When a LISP-GPE router performs Ethernet encapsulation, the inner
header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or
used to determine the LISP Instance ID field. used to determine the LISP Instance ID field.
5. IANA Considerations 5. IANA Considerations
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 draft. New values are assigned via Standards Action defined in this document. New values are assigned via Standards
[RFC5226]. Action [RFC5226].
+---------------+-------------+---------------+ +---------------+-------------+---------------+
| Next Protocol | Description | Reference | | Next Protocol | Description | Reference |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
| 0 | Reserved | This Document | | 0 | Reserved | This Document |
| 1 | IPv4 | This Document | | 1 | IPv4 | This Document |
| 2 | IPv6 | This Document | | 2 | IPv6 | This Document |
| 3 | Ethernet | This Document | | 3 | Ethernet | This Document |
| 4 | NSH | This Document | | 4 | NSH | This Document |
| 5..255 | Unassigned | | | 5..255 | Unassigned | |
+---------------+-------------+---------------+ +---------------+-------------+---------------+
6. Security Considerations 6. Security Considerations
LISP-GPE security considerations are similar to the LISP security LISP-GPE security considerations are similar to the LISP security
considerations documented at length in [I-D.ietf-lisp-rfc6830bis]. considerations and mitigation techniques documented in [RFC7835].
With LISP-GPE, issues such as dataplane 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.
7. Acknowledgements 7. 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.
This WG document originated as draft-lewis-lisp-gpe; the following
are its coauthors and contributors along with their respective
affiliations at the time of WG adoption. The editor of this document
would like to thank and recognize them and their contributions.
These coauthors and contributors provided invaluable concepts and
content for this document's creation.
o Darrel Lewis, Cisco Systems, Inc.
o Fabio Maino, Cisco Systems, Inc.
o Paul Quinn, Cisco Systems, Inc.
o Michael Smith, Cisco Systems, Inc.
o Navindra Yadav, Cisco Systems, Inc.
o Larry Kreeger
o John Lemon, Broadcom
o Puneet Agarwal, Innovium
8. References 8. References
8.1. Normative References 8.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
editor.org/info/rfc5226>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, <https://www.rfc-
editor.org/info/rfc6830>.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
DOI 10.17487/RFC6834, January 2013, <https://www.rfc- DOI 10.17487/RFC6834, January 2013, <https://www.rfc-
editor.org/info/rfc6834>. editor.org/info/rfc6834>.
8.2. Informative References
[I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress),
March 2018.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
editor.org/info/rfc5226>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", RFC 7835,
DOI 10.17487/RFC7835, April 2016, <https://www.rfc-
editor.org/info/rfc7835>.
[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060,
February 2017, <https://www.rfc-editor.org/info/rfc8060>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, <https://www.rfc- DOI 10.17487/RFC8300, January 2018, <https://www.rfc-
editor.org/info/rfc8300>. editor.org/info/rfc8300>.
8.2. Informative References
[I-D.ietf-lisp-rfc6830bis]
Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
Cabellos-Aparicio, "The Locator/ID Separation Protocol
(LISP)", draft-ietf-lisp-rfc6830bis-10 (work in progress),
March 2018.
Authors' Addresses Authors' Addresses
Darrel Lewis Fabio Maino (editor)
Cisco Systems Cisco Systems
San Jose, CA 95134
USA
Email: darlewis@cisco.com Email: fmaino@cisco.com
John Lemon John Lemon
Broadcom Broadcom
3151 Zanker Road 3151 Zanker Road
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: john.lemon@broadcom.com Email: john.lemon@broadcom.com
Puneet Agarwal Puneet Agarwal
Innovium Innovium
USA USA
Email: puneet@acm.org Email: puneet@acm.org
Darrel Lewis
Larry Kreeger
USA
Email: lkreeger@gmail.com
Paul Quinn
Cisco Systems Cisco Systems
Email: paulq@cisco.com Email: darlewis@cisco.com
Michael Smith Michael Smith
Cisco Systems Cisco Systems
Email: michsmit@cisco.com Email: michsmit@cisco.com
Navindra Yadav
Cisco Systems
Email: nyadav@cisco.com
Fabio Maino (editor)
Cisco Systems
San Jose, CA 95134
USA
Email: fmaino@cisco.com
 End of changes. 32 change blocks. 
73 lines changed or deleted 133 lines changed or added

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