summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7676.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7676.txt')
-rw-r--r--doc/rfc/rfc7676.txt619
1 files changed, 619 insertions, 0 deletions
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,
+ <http://www.rfc-editor.org/info/rfc768>.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ DOI 10.17487/RFC0791, September 1981,
+ <http://www.rfc-editor.org/info/rfc791>.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7,
+ RFC 793, DOI 10.17487/RFC0793, September 1981,
+ <http://www.rfc-editor.org/info/rfc793>.
+
+ [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+ for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
+ 1996, <http://www.rfc-editor.org/info/rfc1981>.
+
+
+
+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,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+ December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+ [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+ Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+ DOI 10.17487/RFC2784, March 2000,
+ <http://www.rfc-editor.org/info/rfc2784>.
+
+ [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
+ RFC 2890, DOI 10.17487/RFC2890, September 2000,
+ <http://www.rfc-editor.org/info/rfc2890>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc4023>.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+ December 2005, <http://www.rfc-editor.org/info/rfc4301>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc4443>.
+
+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,
+ <http://www.rfc-editor.org/info/rfc1918>.
+
+ [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/
+ Co-existence Security Considerations", RFC 4942,
+ DOI 10.17487/RFC4942, September 2007,
+ <http://www.rfc-editor.org/info/rfc4942>.
+
+
+
+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,
+ <http://www.rfc-editor.org/info/rfc6169>.
+
+ [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, <http://www.rfc-editor.org/info/rfc7042>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc7588>.
+
+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]
+