diff options
| author |   Neale Ranns <nranns@cisco.com> | 2020-09-21 08:17:51 +0000 |
|---|---|---|
| committer |   Damjan Marion <dmarion@me.com> | 2020-09-22 16:01:29 +0000 |
| commit | 2b202bc4b2d870d76bfe6fb1906ae62e253cec72 (patch) | |
| tree | b05011f96b8d9d080647323e4609af0fac90b612 /src/vnet/lisp-gpe/rfc.txt | |
| parent | b468773aa4164bf52e0751fdf780f67248037cc0 (diff) | |
lisp: Move to plugin
Type: refactor
Change-Id: I54df533a8f863c4e49742903cf2457f18b4fc506
Signed-off-by: Neale Ranns <nranns@cisco.com>
Diffstat (limited to 'src/vnet/lisp-gpe/rfc.txt')
| -rw-r--r-- | src/vnet/lisp-gpe/rfc.txt | 826 |
1 files changed, 0 insertions, 826 deletions
diff --git a/src/vnet/lisp-gpe/rfc.txt b/src/vnet/lisp-gpe/rfc.txt deleted file mode 100644 index 5e3da150c70..00000000000 --- a/src/vnet/lisp-gpe/rfc.txt +++ /dev/null @@ -1,826 +0,0 @@ -Network Working Group D. Lewis -Internet-Draft Cisco Systems, Inc. -Intended status: Informational P. Agarwal -Expires: January 5, 2015 Broadcom - L. Kreeger - F. Maino - P. Quinn - M. Smith - N. Yadav - Cisco Systems, Inc. - July 4, 2014 - - - LISP Generic Protocol Extension - draft-lewis-lisp-gpe-02.txt - -Abstract - - This draft describes extending the Locator/ID Separation Protocol - (LISP) [RFC6830], via changes to the LISP header, with three new - capabilities: support for multi-protocol encapsulation, operations, - administration and management (OAM) signaling, and explicit - versioning. - -Status of this Memo - - This Internet-Draft is submitted in full conformance with the - provisions of BCP 78 and BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF). Note that other groups may also distribute - working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - This Internet-Draft will expire on January 5, 2015. - -Copyright Notice - - Copyright (c) 2014 IETF Trust and the persons identified as the - document authors. All rights reserved. - - This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents - - - -Lewis, et al. Expires January 5, 2015 [Page 1] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - - (http://trustee.ietf.org/license-info) in effect on the date of - publication of this document. Please review these documents - carefully, as they describe your rights and restrictions with respect - to this document. Code Components extracted from this document must - include Simplified BSD License text as described in Section 4.e of - the Trust Legal Provisions and are provided without warranty as - described in the Simplified BSD License. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 4 - 3. Generic Protocol Extension for LISP (LISP-gpe) . . . . . . . . 5 - 3.1. Multi Protocol Support . . . . . . . . . . . . . . . . . . 5 - 3.2. OAM Support . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.3. Version Bits . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8 - 4.1. LISP-gpe Routers to (legacy) LISP Routers . . . . . . . . 8 - 4.2. (legacy) LISP Routers to LISP-gpe Routers . . . . . . . . 8 - 4.3. Type of Service . . . . . . . . . . . . . . . . . . . . . 8 - 4.4. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 8 - 5. LISP-gpe Examples . . . . . . . . . . . . . . . . . . . . . . 9 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 2] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -1. Introduction - - LISP [RFC6830] defines an encapsulation format that carries IPv4 or - IPv6 (henceforth referred to as IP) packets in a LISP header and - outer UDP/IP transport. - - The LISP header does not specify the protocol being encapsulated and - therefore is currently limited to encapsulating only IP packet - payloads. Other protocols, most notably VXLAN [VXLAN] (which defines - a similar header format to LISP), are used to encapsulate L2 - protocols such as Ethernet. LISP [RFC6830] can be extended to - indicate the inner protocol, enabling the encapsulation of Ethernet, - IP or any other desired protocol all the while ensuring compatibility - with existing LISP [RFC6830] deployments. - - As LISP is deployed, there's also the need to provide increased - visibility and diagnostic capabilities within the overlay. - - This document describes extending LISP ([RFC6830]) via the following - changes: - - Next Protocol Bit (P bit): A reserved flag bit is allocated, and set - in the LISP-gpe header to indicate that a next protocol field is - present. - - OAM Flag Bit (O bit): A reserved flag bit is allocated, and set in - the LISP-gpe header, to indicate that the packet is an OAM packet. - - Version: Two reserved bits are allocated, and set in the LISP-gpe - header, to indicate LISP-gpe protocol version. - - Next protocol: An 8 bit next protocol field is present in the LISP- - gpe header. - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 3] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -2. LISP Header Without Protocol Extensions - - As described in the introduction, the LISP header has no protocol - identifier that indicates the type of payload being carried by LISP. - Because of this, LISP is limited to an IP payload. Furthermore, the - LISP header has no mechanism to signal OAM packets. - - The LISP header contains flags (some defined, some reserved), a - Nonce/Map-version field and an instance ID/Locator-status-bit field. - The flags provide flexibility to define how the reserved bits can be - used to change the definition of the LISP header. - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|flags| Nonce/Map-Version | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 1: LISP Header - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 4] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -3. Generic Protocol Extension for LISP (LISP-gpe) - -3.1. Multi Protocol Support - - This draft defines the following changes to the LISP header in order - to support multi-protocol encapsulation. - - P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit - MUST be set to 1 to indicate the presence of the 8 bit next - protocol field. - - P = 0 indicates that the payload MUST conform to LISP as defined - in [RFC6830]. - - Flag bit 5 was chosen as the P bit because this flag bit is - currently unallocated in LISP [RFC6830]. - - Next Protocol Field: The lower 8 bits of the first word are used to - carry a next protocol. This next protocol field contains the - protocol of the encapsulated payload packet. - - LISP [RFC6830] uses the lower 16 bits of the first word for either - a nonce, an echo-nonce ([RFC6830]) or to support map-versioning - ([RFC6834]). These are all optional capabilities that are - indicated by setting the N, E, and the V bit respectively. - - To maintain the desired data plane compatibility, when the P bit - is set, the N, E, and V bits MUST be set to zero. - - A new protocol registry will be requested from IANA for the Next - Protocol field. This draft defines the following Next Protocol - values: - - 0x1 : IPv4 - - 0x2 : IPv6 - - 0x3 : Ethernet - - 0x4: Network Service Header - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 5] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|P|R|R| Reserved | Next Protocol | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 2: LISP-gpe Next Protocol (P=1) - -3.2. OAM Support - - Flag bit 7 is defined as the O bit. When the O bit is set to 1, the - packet is an OAM packet and OAM processing MUST occur. The OAM - protocol details are out of scope for this document. As with the - P-bit, bit 7 is currently a reserved flag in [RFC6830]. - - - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|P|R|O| Reserved | Next Protocol | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 3: LISP-gpe OAM bit (P=1) - -3.3. Version Bits - - LISP-gpe bits8 and 9 are defined as version bits. The version field - is used to ensure backward compatibility going forward with future - LISP-gpe updates. - - The initial version for LISP-gpe is 0. - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 6] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|P|R|O|Ver| Reserved | Next Protocol | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 4: LISP-gpe Version bits (P=1) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 7] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -4. Backward Compatibility - - Undefined (in RFC6830) flag bits 5 and 7, LISP-gpe P and O bits, were - selected to ensure compatibility with existing LISP [RFC6830] - deployments. - - Similarly, using P = 0 to indicate that the format of the header and - payload conforms to [RFC6830] ensures compatibility with existing - LISP hardware forwarding platforms. - -4.1. LISP-gpe Routers to (legacy) LISP Routers - - A LISP-gpe router MUST not encapsulate non-IP packet nor OAM packets - to a LISP router. A method for determining the capabilities of a - LISP router (gpe or "legacy") is out of the scope of this draft. - - When encapsulating IP packets to a LISP router the P bit SHOULD be - set to 1 and the UDP port MUST be set to 4341. OAM bit MUST be set - to 0. The Next Protocol field SHOULD be 0x1 (IPv4) or 0x2 (IPv6). - The (legacy) LISP router will ignore the P bit and the protocol type - field. The (legacy) LISP router will treat the packet as a LISP - packet and inspect the first nibble of the payload to determine the - IP version. - - When the P bit is set, the N, E, and V bits MUST be set to zero. The - receiving (legacy) LISP router will ignore N, E and V bits, when the - P bit is set. - -4.2. (legacy) LISP Routers to LISP-gpe Routers - - When a LISP-gpe router receives a packet from a (legacy) LISP router, - the P bit MUST not be set and the UDP port MUST be 4341. The payload - MUST be IP, and the LISP-gpe router will inspect the first nibble of - the payload to determine IP version. - -4.3. Type of Service - - When a LISP-gpe router performs Ethernet encapsulation, the inner - 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 - header, or in the case of IPv6 the 'Traffic Class' field. - -4.4. VLAN Identifier (VID) - - When a LISP-gpe router performs Ethernet encapsulation, the inner - header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or - used to determine the LISP Instance ID field. - - - - -Lewis, et al. Expires January 5, 2015 [Page 8] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -5. LISP-gpe Examples - - This section provides two examples of IP protocols, and one example - of Ethernet encapsulated LISP-gpe using the generic extension - described in this document. - - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|1|0|0|0| Reserved | NP = IPv4 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original IPv4 Packet | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 5: IPv4 and LISP-gpe - - - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|1|0|0|0| Reserved | NP = IPv6 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original IPv6 Packet | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 6: IPv6 and LISP-gpe - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 9] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |N|L|E|V|I|1|0|0|0| Reserved | NP = Ethernet | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Instance ID/Locator-Status-Bits | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Original Ethernet Frame | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 7: Ethernet and LISP-gpe - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 10] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -6. Security Considerations - - LISP-gpe security considerations are similar to the LISP security - considerations documented at length in LISP [RFC6830]. With LISP- - gpe, issues such as dataplane spoofing, flooding, and traffic - redirection are dependent on the particular protocol payload - encapsulated. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 11] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -7. Acknowledgments - - A special thank you goes to Dino Farinacci for his guidance and - detailed review. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 12] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -8. IANA Considerations - - IANA is requested to set up a registry of "Next Protocol". These are - 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in - this draft. New values are assigned via Standards Action [RFC5226]. - - +---------------+-------------+---------------+ - | Next Protocol | Description | Reference | - +---------------+-------------+---------------+ - | 0 | Reserved | This document | - | | | | - | 1 | IPv4 | This document | - | | | | - | 2 | IPv6 | This document | - | | | | - | 3 | Ethernet | This document | - | | | | - | 4 | NSH | This document | - | | | | - | 5..253 | Unassigned | | - +---------------+-------------+---------------+ - - Table 1 - - There are ten bits at the beginning of the LISP-gpe header. New - bits are assigned via Standards Action [RFC5226]. - - Bits 0-3 - Assigned by LISP [RFC6830] - Bit 4 - Instance ID (I bit) - Bit 5 - Next Protocol (P bit) - Bit 6 - Reserved - Bit 7 - OAM (O bit) - Bits 8-9 - Version - - - - - - - - - - - - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 13] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -9. References - -9.1. Normative References - - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. - - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 5226, - May 2008. - -9.2. Informative References - - [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, - <http://www.iana.org/assignments/ieee-802-numbers/ - ieee-802-numbers.xml>. - - [IEEE8021Q] - The IEEE Computer Society, "Media Access Control (MAC) - Bridges and Virtual Bridge Local Area Networks", August - 2012, <http://standards.ieee.org/getieee802/download/ - 802.1Q-2011.pdf>. - - [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, - October 1994. - - [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The - Locator/ID Separation Protocol (LISP)", RFC 6830, - January 2013. - - [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID - Separation Protocol (LISP) Map-Versioning", RFC 6834, - January 2013. - - [VXLAN] Dutt, D., Mahalingam, M., Duda, K., Agarwal, P., Kreeger, - L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A - Framework for Overlaying Virtualized Layer 2 Networks over - Layer 3 Networks", 2013. - - - - - - - -Lewis, et al. Expires January 5, 2015 [Page 14] - -Internet-Draft LISP Generic Protocol Extension July 2014 - - -Authors' Addresses - - Darrel Lewis - Cisco Systems, Inc. - - Email: darlewis@cisco.com - - - Puneet Agarwal - Broadcom - - Email: pagarwal@broadcom.com - - - Larry Kreeger - Cisco Systems, Inc. - - Email: kreeger@cisco.com - - - Fabio Maino - Cisco Systems, Inc. - - Email: fmaino@cisco.com - - - Paul Quinn - Cisco Systems, Inc. - - Email: paulq@cisco.com - - - Michael Smith - Cisco Systems, Inc. - - Email: michsmit@cisco.com - - - Navindra Yadav - Cisco Systems, Inc. - - Email: nyadav@cisco.com |