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)
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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].
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
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, North Carolina 27709 United States
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia United States
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada