Geneve: Generic Network Virtualization Encapsulation
Extracted elements (29)
Geneve is a pure data-plane tunnel format specification that does not mandate any control plane. This was a deliberate choice because control planes are diverse in fundamental ways and standardization offers less value there; decoupling the data format from the control plane simultaneously promotes a shared data format while reducing obsolescence risk from future control plane evolution.
The UDP source port is used to expose entropy from encapsulated inner packets to underlay ECMP fabric. Without this, only tunnel endpoint addresses are available for ECMP hashing, leading to poor load distribution. The source port SHOULD be computed as a hash (e.g., 5-tuple) of inner packet headers, and the full 16-bit range MAY be used to maximize entropy.
TLV-format variable-length options were chosen to allow new metadata types to be defined, deployed, and either standardized or retired independently, enabling product differentiation and a faster pace of advancement. Options are required in data packets (not just control packets) because use cases such as input-port security policies and service-interposition tags must be applied to data traffic.
Geneve is designed to coexist with VXLAN and NVGRE; since these protocols share base data-plane functionality, porting an existing control plane to Geneve requires minimal effort. Transit devices see all protocols equivalently as IP/UDP traffic, so no additional interoperability concerns are introduced at the transit layer. Implementations are strongly suggested to support simultaneous operation of Geneve and existing tunneling protocols.
An NVE MUST NOT propagate Geneve packets beyond the NVE to tenant systems and SHOULD employ packet-filtering mechanisms to prevent unauthorized traffic between tenant systems in different tenant networks. An NVE MUST NOT interpret Geneve packets from tenant systems other than as frames to be encapsulated.
By default, UDP checksums MUST be used when Geneve is transported over IPv6. A tunnel endpoint MAY be configured for zero UDP checksum only when operating in a traffic-managed controlled environment (TMCE) meeting specific conditions in Section 4.3.1, and MUST meet all requirements of RFC 6936 Section 4 and requirement 1 of Section 5.
ECN behavior from RFC 6040 MUST be followed for IP packets encapsulated in Geneve, exposing ECN capabilities on the tunnel and propagating congestion markers to inner packets.
Geneve MUST be used with congestion-controlled traffic or within a traffic-managed controlled environment (TMCE) to avoid congestion, as Geneve itself provides no congestion-control functionality.
Measures SHOULD be taken to prevent Geneve traffic over IPv6 with zero UDP checksum from escaping to the general Internet, for example via packet filters at gateways or logical/physical separation of the Geneve network.
Options defined to be a fixed length MUST NOT be redefined to a different length, because implementations may ignore the Length field and parse by well-known size; changing the length would corrupt parsing of all subsequent options. A new Type value must be allocated instead.
Packets in which the total length of all options is not equal to the Opt Len value in the base header are invalid and MUST be silently dropped if received by a tunnel endpoint that processes options. If Opt Len exceeds the endpoint's processing capability, the endpoint MUST drop such packets.
Receiving tunnel endpoints MUST drop packets containing unknown options with the critical 'C' bit set in the option type field. If the C bit is set in any option, the C bit in the Geneve base header MUST also be set. Transit devices MUST NOT drop packets due to unknown options, including critical ones.
Transit devices MUST NOT modify Geneve headers and MUST NOT insert or delete options; options MUST only be generated and terminated by tunnel endpoints. The contents and ordering of options MUST NOT be modified by transit devices.
Tunnel endpoints MUST drop Geneve packets received with an unknown version number. Transit devices encountering an unknown version MUST treat the packet as a UDP packet with an unknown payload rather than dropping it.
When determining the MTU size of a tunnel link, the maximum length of options MUST be assumed since options may vary on a per-packet basis. Path MTU Discovery (RFC 1191, RFC 8201) is RECOMMENDED to prevent or minimize fragmentation.
When Geneve is encapsulated in IPv4, the UDP checksum SHOULD be generated per RFC 768 and RFC 1122 to protect the Geneve header, options, and payload from corruption. When encapsulated in IPv6, the UDP checksum MUST be generated by default; non-zero checksums received MUST be validated and packets with incorrect checksums MUST be dropped.
When performing LSO, a NIC MUST replicate the entire Geneve header and all options (including unknown ones) onto each resulting segment unless an option provides an exception. Options MUST NOT be reordered during offload processing. NICs performing offloads MUST NOT drop packets with unknown or critical options unless explicitly configured to do so.
The C bit in the Geneve base header indicates that one or more options have their critical bit set. When C is set, tunnel endpoints MUST parse the options list; tunnel endpoints that cannot parse options MUST drop the packet on the basis of this bit alone. Transit devices MUST NOT drop packets on the basis of the C bit.
The O bit in the Geneve header marks a control packet sent between tunnel endpoints. Tunnel endpoints MUST NOT forward the payload when O is set, transit devices MUST NOT interpret it, and transit devices MUST NOT alter forwarding (e.g., ECMP selection) based on this bit.
The Protocol Type field (16 bits) identifies the payload PDU type using Ethertype conventions; Ethernet is represented by 0x6558. This field allows Geneve to carry arbitrary payload protocols beyond Ethernet.
The Virtual Network Identifier (VNI) is a 24-bit field in the Geneve tunnel header that identifies a unique element of a virtual network (often an L2 segment). The control plane defines forwarding semantics; the VNI MAY be used in ECMP decisions or to distinguish overlapping address spaces when load balancing across CPUs.
IANA allocated UDP port 6081 as the well-known destination port for Geneve under the service name 'geneve'. Implementations SHOULD make this port configurable but SHOULD use 6081 by default; the port MUST NOT be reversed as with TCP.
IANA created the 'Geneve Option Class' registry (16-bit values) under the NVO3 heading. Ranges: 0x0000–0x00FF (IETF Review), 0x0100–0xFEFF (First Come First Served), 0xFF00–0xFFFF (Experimental Use). Each organization owning a class may independently allocate Type values within it.
Geneve has no inherent security mechanisms. An attacker with access to the underlay network can snoop, alter, or inject packets, and compromised endpoints can spoof VNIs to access other tenants' networks. Isolation (separate VLANs, filtering) is recommended within a trusted domain; IPsec or other VPN technologies SHOULD be used when crossing untrusted links such as the general Internet.
In multi-tenant environments where data confidentiality is required, an encryption mechanism SHOULD be used to encrypt tenant data end-to-end between NVEs. Any Geneve overlay data leaving the operator's security domain (e.g., inter-data-center over public networks) SHOULD be secured by IPsec or equivalent VPN technologies.
To mitigate spoofing or rogue NVE threats, an operator SHOULD use an authentication mechanism such as IPsec to verify that Geneve packets originate from the intended NVE peer. Simpler ingress filtering (VLAN/MAC/IP, reverse-path forwarding) may be used in sufficiently trusted environments.
When Geneve options are interpreted by transit devices, the operator MUST ensure those transit devices are trusted and not compromised. If the Geneve packet is end-to-end encrypted (e.g., via IPsec), transit devices will have no visibility into the Geneve header or options and MUST treat the packet as any other IP packet.
Each Geneve option TLV begins with a 4-byte header: Option Class (16 bits, namespace), Type (8 bits, high-order bit is the critical 'C' flag), three reserved R bits (must be zero), and Length (5 bits, in 4-byte multiples excluding the header, giving a total option size of 4–128 bytes), followed by variable-length option data.
The Geneve fixed tunnel header is 8 bytes: Ver (2 bits, current=0), Opt Len (6 bits, in 4-byte multiples, yielding a total header of 8–260 bytes), O flag (1 bit, control packet), C flag (1 bit, critical options present), Rsvd (6 bits, must be zero), Protocol Type (16 bits, Ethertype convention), VNI (24 bits), and Reserved (8 bits).