From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7676.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc7676.txt (limited to 'doc/rfc/rfc7676.txt') diff --git a/doc/rfc/rfc7676.txt b/doc/rfc/rfc7676.txt new file mode 100644 index 0000000..2187d95 --- /dev/null +++ b/doc/rfc/rfc7676.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Pignataro +Request for Comments: 7676 Cisco Systems +Category: Standards Track R. Bonica +ISSN: 2070-1721 Juniper Networks + S. Krishnan + Ericsson + October 2015 + + + IPv6 Support for Generic Routing Encapsulation (GRE) + +Abstract + + Generic Routing Encapsulation (GRE) can be used to carry any network- + layer payload protocol over any network-layer delivery protocol. + Currently, GRE procedures are specified for IPv4, used as either the + payload or delivery protocol. However, GRE procedures are not + specified for IPv6. + + This document specifies GRE procedures for IPv6, used as either the + payload or delivery protocol. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7676. + + + + + + + + + + + + + + + + +Pignataro, et al. Standards Track [Page 1] + +RFC 7676 GRE IPv6 October 2015 + + +Copyright Notice + + Copyright (c) 2015 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 + (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 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 4 + 3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 5 + 3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 5 + 3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5 + 4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6 + 4.1. Next Header Considerations . . . . . . . . . . . . . . . 6 + 4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6 + 4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 8 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 6.2. Informative References . . . . . . . . . . . . . . . . . 9 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + + + + + + + + + + + + + + + +Pignataro, et al. Standards Track [Page 2] + +RFC 7676 GRE IPv6 October 2015 + + +1. Introduction + + Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used + to carry any network-layer payload protocol over any network-layer + delivery protocol. Currently, GRE procedures are specified for IPv4 + [RFC791], used as either the payload or delivery protocol. However, + GRE procedures are not specified for IPv6 [RFC2460]. + + This document specifies GRE procedures for IPv6, used as either the + payload or delivery protocol. Like RFC 2784, this document describes + how GRE has been implemented by several vendors. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Terminology + + The following terms are used in this document: + + o GRE delivery header: An IPv4 or IPv6 header whose source address + represents the GRE ingress node and whose destination address + represents the GRE egress node. The GRE delivery header + encapsulates a GRE header. + + o GRE header: The GRE protocol header. The GRE header is + encapsulated in the GRE delivery header and encapsulates the GRE + payload. + + o GRE payload: A network-layer packet that is encapsulated by the + GRE header. + + o GRE overhead: The combined size of the GRE delivery header and the + GRE header, measured in octets. + + o Path MTU (PMTU): The minimum MTU of all the links in a path + between a source node and a destination node. If the source and + destination node are connected through Equal-Cost Multipath + (ECMP), the PMTU is equal to the minimum link MTU of all links + contributing to the multipath. + + o Path MTU Discovery (PMTUD): A procedure for dynamically + discovering the PMTU between two nodes on the Internet. PMTUD + procedures for IPv6 are defined in [RFC1981]. + + + + + +Pignataro, et al. Standards Track [Page 3] + +RFC 7676 GRE IPv6 October 2015 + + + o GRE MTU (GMTU): The maximum transmission unit, i.e., maximum + packet size in octets, that can be conveyed over a GRE tunnel + without fragmentation of any kind. The GMTU is equal to the PMTU + associated with the path between the GRE ingress and the GRE + egress, minus the GRE overhead. + +2. GRE Header Fields + + This document does not change the GRE header format or any behaviors + specified by RFC 2784 or RFC 2890. + +2.1. Checksum Present + + The GRE ingress node SHOULD set the Checksum Present field in the GRE + header to zero. However, implementations MAY support a configuration + option that causes the GRE ingress node to set the Checksum Present + field to one. + + As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum + Present field to calculate the length of the GRE header. If the + Checksum Present field is set to one, the GRE egress node MUST use + the GRE Checksum to verify the integrity of the GRE header and + payload. + + Setting the Checksum Present field to zero reduces the computational + cost of GRE encapsulation and decapsulation. In many cases, the GRE + Checksum is partially redundant with other checksums. For example: + + o If the payload protocol is IPv4, the IPv4 header is protected by + both the GRE Checksum and the IPv4 Checksum. + + o If the payload carries TCP [RFC793], the TCP pseudo header, TCP + header, and TCP payload are protected by both the GRE Checksum and + TCP Checksum. + + o If the payload carries UDP [RFC768], the UDP pseudo header, UDP + header, and UDP payload are protected by both the GRE Checksum and + UDP Checksum. + + However, if the GRE Checksum Present field is set to zero, the GRE + header is not protected by any checksum. Furthermore, depending on + which of the above-mentioned conditions are true, selected portions + of the GRE payload will not be protected by any checksum. + + Network operators should evaluate risk factors in their networks and + configure GRE ingress nodes appropriately. + + + + + +Pignataro, et al. Standards Track [Page 4] + +RFC 7676 GRE IPv6 October 2015 + + +3. IPv6 as GRE Payload + + The following considerations apply to GRE tunnels that carry an IPv6 + payload. + +3.1. GRE Protocol Type Considerations + + The Protocol Type field in the GRE header MUST be set to Ether Type + [RFC7042] 0x86DD (IPv6). + +3.2. MTU Considerations + + A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from + ingress to egress, without fragmenting the payload packet. All GRE + tunnels with a GMTU of 1280 octets or greater satisfy this + requirement. GRE tunnels that can fragment and reassemble delivery + packets also satisfy this requirement, regardless of their GMTU. + However, the ability to fragment and reassemble delivery packets is + not a requirement of this specification. This specification requires + only that GRE ingress nodes refrain from activating GRE tunnels that + do not satisfy the above-mentioned requirement. + + Before activating a GRE tunnel and periodically thereafter, the GRE + ingress node MUST verify the tunnel's ability to carry a 1280-octet + IPv6 payload packet from ingress to egress, without fragmenting the + payload. Having executed those procedures, the GRE ingress node MUST + activate or deactivate the tunnel accordingly. + + Implementation details regarding the above-mentioned verification + procedures are beyond the scope of this document. However, a GRE + ingress node can verify tunnel capabilities by sending a 1280-octet + IPv6 packet addressed to itself through the tunnel under test. + + Many existing implementations [RFC7588] do not support the above- + mentioned verification procedures. Unless deployed in environments + where the GMTU is guaranteed to be greater than 1280, these + implementations MUST be configured so that the GRE endpoints can + fragment and reassemble the GRE delivery packet. + +3.3. Fragmentation Considerations + + When the GRE ingress receives an IPv6 payload packet whose length is + less than or equal to the GMTU, it can encapsulate and forward the + packet without fragmentation of any kind. In this case, the GRE + ingress router MUST NOT fragment the payload or delivery packets. + + + + + + +Pignataro, et al. Standards Track [Page 5] + +RFC 7676 GRE IPv6 October 2015 + + + When the GRE ingress receives an IPv6 payload packet whose length is + greater than the GMTU, and the GMTU is greater than or equal to 1280 + octets, the GRE ingress router MUST: + + o discard the IPv6 payload packet + + o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 + payload packet source. The MTU field in the ICMPv6 PTB message is + set to the GMTU. + + When the GRE ingress receives an IPv6 payload packet whose length is + greater than the GMTU, and the GMTU is less than 1280 octets, the GRE + ingress router MUST: + + o encapsulate the entire IPv6 packet in a single GRE header and IP + delivery header + + o fragment the delivery header, so that it can be reassembled by the + GRE egress + +4. IPv6 as GRE Delivery Protocol + + The following considerations apply when the delivery protocol is + IPv6. + +4.1. Next Header Considerations + + When the GRE delivery protocol is IPv6, the GRE header MAY + immediately follow the GRE delivery header. Alternatively, IPv6 + extension headers MAY be inserted between the GRE delivery header and + the GRE header. + + If the GRE header immediately follows the GRE delivery header, the + Next Header field in the IPv6 header of the GRE delivery packet MUST + be set to 47. If extension headers are inserted between the GRE + delivery header and the GRE header, the Next Header field in the last + IPv6 extension header MUST be set to 47. + +4.2. Checksum Considerations + + As stated in [RFC2784], the GRE header can contain a checksum. If + present, the GRE header checksum can be used to detect corruption of + the GRE header and GRE payload. + + The GRE header checksum cannot be used to detect corruption of the + IPv6 delivery header. Furthermore, the IPv6 delivery header does not + contain a checksum of its own. Therefore, no available checksum can + be used to detect corruption of the IPv6 delivery header. + + + +Pignataro, et al. Standards Track [Page 6] + +RFC 7676 GRE IPv6 October 2015 + + + In one failure scenario, the destination address in the IPv6 delivery + header is corrupted. As a result, the IPv6 delivery packet is + delivered to a node other than the intended GRE egress node. + Depending upon the state and configuration of that node, it will + either: + + a. Drop the packet + + b. Decapsulate the payload and forward it to its intended + destination + + c. Decapsulate the payload and forward it to a node other than its + intended destination. + + Behaviors a) and b) are acceptable. Behavior c) is not acceptable. + + Behavior c) is possible only when the following conditions are true: + + 1. The intended GRE egress node is a Virtual Private Network (VPN) + Provider Edge (PE) router. + + 2. The node to which the GRE delivery packet is mistakenly delivered + is also a VPN PE router. + + 3. VPNs are attached to both of the above-mentioned nodes. At least + two of these VPN's number hosts are from a non-unique (e.g., + [RFC1918]) address space. + + 4. The intended GRE egress node maintains state that causes it to + decapsulate the packet and forward the payload to its intended + destination + + 5. The node to which the GRE delivery packet is mistakenly delivered + maintains state that causes it to decapsulate the packet and + forward the payload to an identically numbered host in another + VPN. + + While the failure scenario described above is extremely unlikely, a + single misdelivered packet can adversely impact applications running + on the node to which the packet is misdelivered. Furthermore, + leaking packets across VPN boundaries also constitutes a security + breach. The risk associated with behavior c) could be mitigated with + end-to-end authentication of the payload. + + Before deploying GRE over IPv6, network operators should consider the + likelihood of behavior c) in their network. GRE over IPv6 MUST NOT + be deployed other than where the network operator deems the risk + associated with behavior c) to be acceptable. + + + +Pignataro, et al. Standards Track [Page 7] + +RFC 7676 GRE IPv6 October 2015 + + +4.3. MTU Considerations + + By default, the GRE ingress node cannot fragment the IPv6 delivery + header. However, implementations MAY support an optional + configuration in which the GRE ingress node can fragment the IPv6 + delivery header. + + Also by default, the GRE egress node cannot reassemble the IPv6 + delivery header. However, implementations MAY support an optional + configuration in which the GRE egress node can reassemble the IPv6 + delivery header. + +5. Security Considerations + + The Security Considerations section of [RFC4023] identifies threats + encountered when MPLS is delivered over GRE. These threats apply to + any GRE payload. As stated in RFC 4023, these various threats can be + mitigated through options such as authenticating and/or encrypting + the delivery packet using IPsec [RFC4301]. Alternatively, when the + payload is IPv6, these threats can also be mitigated by + authenticating and/or encrypting the payload using IPsec, instead of + the delivery packet. Otherwise, the current specification introduces + no security considerations beyond those mentioned in RFC 2784. + + More generally, security considerations for IPv6 are discussed in + [RFC4942]. Operational security for IPv6 is discussed in [OPSEC-V6], + and security concerns for tunnels in general are discussed in + [RFC6169]. + +6. References + +6.1. Normative References + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + DOI 10.17487/RFC0768, August 1980, + . + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + DOI 10.17487/RFC0791, September 1981, + . + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, DOI 10.17487/RFC0793, September 1981, + . + + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery + for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August + 1996, . + + + +Pignataro, et al. Standards Track [Page 8] + +RFC 7676 GRE IPv6 October 2015 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, . + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + DOI 10.17487/RFC2784, March 2000, + . + + [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", + RFC 2890, DOI 10.17487/RFC2890, September 2000, + . + + [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., + "Encapsulating MPLS in IP or Generic Routing Encapsulation + (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, + . + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, + December 2005, . + + [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", RFC 4443, + DOI 10.17487/RFC4443, March 2006, + . + +6.2. Informative References + + [OPSEC-V6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational + Security Considerations for IPv6 Networks", Work in + Progress, draft-ietf-opsec-v6-07, September 2015. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + . + + [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ + Co-existence Security Considerations", RFC 4942, + DOI 10.17487/RFC4942, September 2007, + . + + + +Pignataro, et al. Standards Track [Page 9] + +RFC 7676 GRE IPv6 October 2015 + + + [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security + Concerns with IP Tunneling", RFC 6169, + DOI 10.17487/RFC6169, April 2011, + . + + [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and + IETF Protocol and Documentation Usage for IEEE 802 + Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, + October 2013, . + + [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely + Deployed Solution to the Generic Routing Encapsulation + (GRE) Fragmentation Problem", RFC 7588, + DOI 10.17487/RFC7588, July 2015, + . + +Acknowledgements + + The authors would like to thank Fred Baker, Stewart Bryant, Benoit + Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins, + Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen + Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko, and Lucy Yong + for their thorough review and useful comments. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Pignataro, et al. Standards Track [Page 10] + +RFC 7676 GRE IPv6 October 2015 + + +Authors' Addresses + + Carlos Pignataro + Cisco Systems + 7200-12 Kit Creek Road + Research Triangle Park, North Carolina 27709 + United States + + Email: cpignata@cisco.com + + + Ron Bonica + Juniper Networks + 2251 Corporate Park Drive + Herndon, Virginia + United States + + Email: rbonica@juniper.net + + + Suresh Krishnan + Ericsson + 8400 Decarie Blvd. + Town of Mount Royal, QC + Canada + + Phone: +1 514 345 7900 x42871 + Email: suresh.krishnan@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + +Pignataro, et al. Standards Track [Page 11] + -- cgit v1.2.3