IPv6 Support for Generic Routing Encapsulation (GRE)
Extracted elements (19)
Setting the GRE Checksum Present field to zero reduces computational cost of encapsulation/decapsulation. In many cases the GRE Checksum is partially redundant with checksums in payload protocols (IPv4, TCP, UDP), though the GRE header itself would then be unprotected.
The 1280-octet minimum GMTU requirement for IPv6 payload tunnels mirrors IPv6's minimum MTU requirement, ensuring that GRE tunnels do not prevent compliant IPv6 communication. Tunnels unable to meet this without fragmentation must not be activated.
When GMTU < 1280 and payload exceeds GMTU, the IPv6 payload is encapsulated whole (not fragmented) and the delivery packet is fragmented instead, because IPv6 sources cannot receive ICMPv6 PTB messages indicating MTUs below 1280.
Many existing GRE implementations (per RFC 7588) do not support the tunnel capability verification procedures required by this specification. Such implementations must be configured to allow fragmentation and reassembly of GRE delivery packets unless the GMTU is guaranteed to exceed 1280 octets.
A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from ingress to egress without fragmenting the payload packet. GRE ingress nodes MUST refrain from activating tunnels that do not satisfy this 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 without fragmentation, and MUST activate or deactivate the tunnel accordingly.
GRE over IPv6 MUST NOT be deployed other than where the network operator deems the risk associated with misdirected packet decapsulation (behavior c) to be acceptable.
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.
Implementations that do not support tunnel verification procedures MUST be configured so that GRE endpoints can fragment and reassemble the GRE delivery packet, unless deployed where GMTU is guaranteed greater than 1280.
The GRE ingress node SHOULD set the Checksum Present field in the GRE header to zero, but implementations MAY support a configuration option to set it to one.
The Protocol Type field in the GRE header MUST be set to Ether Type 0x86DD (IPv6) when carrying an IPv6 payload.
When an IPv6 payload packet exceeds the GMTU and GMTU < 1280, the GRE ingress MUST encapsulate the entire IPv6 packet in a single GRE header and IP delivery header, then fragment the delivery header for reassembly by the GRE egress.
When the GRE delivery protocol is IPv6 and the GRE header immediately follows the delivery header, the Next Header field in the IPv6 header MUST be set to 47. If extension headers intervene, the Next Header field in the last extension header MUST be set to 47.
When the GRE ingress receives an IPv6 payload packet whose length is less than or equal to the GMTU, the GRE ingress router MUST NOT fragment the payload or delivery packets.
By default the GRE ingress node cannot fragment the IPv6 delivery header, and the GRE egress node cannot reassemble it; both behaviors may be enabled via optional configuration.
IPv6 extension headers MAY be inserted between the GRE delivery header and the GRE header when IPv6 is used as the GRE delivery protocol. The GRE header may immediately follow the IPv6 delivery header or be preceded by extension headers.
The GRE MTU (GMTU) is defined as the PMTU between the GRE ingress and egress minus the GRE overhead (combined size of GRE delivery header and GRE header in octets).
The IPv6 delivery header has no checksum of its own, and the GRE checksum does not protect it. A corrupted destination address could cause the delivery packet to be misdelivered to a different GRE-capable node, which might decapsulate and forward the payload to an unintended destination, constituting a security breach especially in VPN environments with non-unique address space.
Threats identified in RFC 4023 for MPLS-over-GRE apply to any GRE payload and can be mitigated via IPsec authentication and/or encryption of either the delivery packet or (when payload is IPv6) the payload itself. Additional IPv6 security considerations are discussed in RFC 4942 and RFC 6169.