GRE-in-UDP Encapsulation
Extracted elements (28)
GRE-in-UDP was designed to enable ECMP load-balancing of GRE traffic by exposing the UDP five-tuple (including source port as entropy) to transit routers' hash functions, since plain GRE traffic only contributes IP addresses and protocol number to the ECMP hash, resulting in single-path forwarding.
The UDP checksum is preferred over the GRE checksum because the UDP checksum covers the pseudo-header and the full packet payload including the GRE header, making the GRE checksum mostly redundant when the UDP checksum is enabled. Enabling both may result in unnecessary processing.
Two deployment scenarios (default/Internet and TMCE) are defined because a tunnel implementation cannot detect its own deployment context, placing responsibility on operators to apply the correct requirements. The TMCE scenario allows weaker checksum and congestion requirements because the environment is controlled to avoid corruption and congestion.
IPv6 datagrams with a zero UDP checksum will be dropped by middleboxes (e.g., firewalls) that validate checksums per RFC 2460. There is no fallback mechanism in GRE-in-UDP to recover from such black-holing; use of UDP checksum is RECOMMENDED when middleboxes are present.
NAPT and firewall middleboxes conflict with GRE-in-UDP tunnels that use the UDP source port for entropy: NAPT rewrites the source port, and firewalls may require symmetric bidirectional port pairs. If middleboxes are present on the path, entropy usage should be disabled or middleboxes updated.
A default GRE-in-UDP tunnel MUST NOT be deployed or configured to carry traffic that is not congestion controlled. IP unicast traffic is generally assumed to be congestion controlled; most IP multicast traffic is not appropriate for a default tunnel.
For a default GRE-in-UDP tunnel over IPv6, a UDP checksum MUST be used. Over IPv4, a UDP checksum SHOULD be used.
For IPv6 delivery networks, flow entropy SHOULD also be placed in the IPv6 flow label field for ECMP per RFC 6438.
For TMCE tunnels using UDP zero-checksum mode with IPv6, the decapsulator MUST check that the source and destination IPv6 addresses are valid for the GRE-in-UDP tunnel on which the packet was received, and MUST discard packets failing this check.
For UDP in IPv4, when a non-zero UDP checksum is used, it MUST be processed per RFC 768 and RFC 1122. When a decapsulator receives a packet with a non-zero checksum, it MUST verify the checksum before accepting the packet; if verification fails, the packet MUST be dropped.
For UDP in IPv6, the UDP checksum MUST be processed per RFC 768 and RFC 2460 for both transmit and receive. A TMCE tunnel MAY use UDP zero-checksum mode only when specific conditions regarding packet corruption risk and operator willingness are satisfied.
IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator (e.g., monitoring Ethernet-layer packet error rates).
The GRE and UDP headers MUST be applied and removed as a pair at the encapsulation and decapsulation points. This specification does not support applying or removing either header at a node other than the UDP tunnel ingress or egress.
The UDP source port MUST be configurable so that a single value can be set for all traffic within the tunnel, disabling entropy. When a single value is set, a random ephemeral port SHOULD be selected to minimize vulnerability to off-path attacks.
Upon receiving an ICMP 'port unreachable' message from a peer that does not support GRE-in-UDP, the node MUST NOT continue to use GRE-in-UDP encapsulation toward that peer without management intervention.
When a GRE Key field is used for traffic separation (e.g., NVGRE), at least one of the UDP or GRE checksums MUST be used for both IPv4 and IPv6 GRE-in-UDP tunnels to guard against GRE header corruption.
When applying payload fragmentation, the UDP checksum MUST be used so that the receiving endpoint can validate reassembly; the same UDP source port SHOULD be used for all packet fragments to ensure transit routers forward fragments on the same path.
When DTLS is used for a GRE-in-UDP tunnel, any received packet that is not protected by the DTLS session or part of DTLS negotiation MUST be discarded and SHOULD be logged.
A TMCE GRE-in-UDP tunnel has relaxed requirements compared to the default tunnel: it MAY disable UDP checksum over IPv4, MAY override the IPv6 checksum default via UDP zero-checksum mode (subject to additional constraints in Section 6.2), and MAY carry non-congestion-controlled traffic.
DTLS (RFC 6347) MAY be used to secure a GRE-in-UDP tunnel. When DTLS is used, the UDP destination port MUST be set to 4755 (GRE-UDP-DTLS), and only a single DTLS session is permitted per encapsulator/decapsulator IP address pair.
GRE-in-UDP encapsulation wraps network protocol packets in a GRE header followed by a UDP header. The UDP source port carries a 16-bit entropy value for ECMP load-balancing, while the destination port is set to 4754 (GRE-in-UDP) or 4755 (GRE-in-UDP with DTLS).
The UDP source port field carries a 16-bit entropy value generated by the encapsulator to identify a flow. The value SHOULD be within the ephemeral port range 49152–65535, providing 14 bits of entropy for inner flow identification.
IANA allocated UDP destination port 4754 for GRE-in-UDP (service name: GRE-in-UDP) and port 4755 for GRE-in-UDP with DTLS (service name: GRE-UDP-DTLS), both assigned per RFC 8086.
DTLS SHOULD be used to secure GRE-in-UDP tunnel traffic. When entropy-based UDP source port usage is disabled, a random ephemeral port SHOULD be selected to minimize vulnerability to off-path attacks, and MAY be periodically changed to mitigate DoS attacks.
GRE header corruption can cause security concerns for applications that rely on the GRE Key field for traffic separation (e.g., NVGRE). At least one of the UDP or GRE checksums MUST be used in such cases to detect corruption.
Using a single standardized UDP destination port increases vulnerability to off-path attacks; an alternate agreed-upon port between encapsulator and decapsulator (per RFC 6056) may be used to mitigate this. The GRE Key field MAY be used to authenticate the encapsulator, and packets with invalid keys MUST be dropped.
The GRE-in-UDP packet structure over IPv4 consists of: IPv4 header (Protocol=17/UDP), UDP header (Source Port=entropy value, Dest Port=4754/4755, Length, Checksum), then GRE header (C/K/S flags, Reserved0, Ver, Protocol Type, optional Checksum, Key, and Sequence Number fields).
The GRE-in-UDP packet structure over IPv6 consists of: IPv6 header (NxtHdr=17/UDP, Flow Label may carry entropy), UDP header (Source Port=entropy, Dest Port=4754/4755), then GRE header with optional fields. The IPv6 flow label field SHOULD also carry entropy per RFC 6438.