Geneve Explained: RFC 8926 Overlay Encapsulation, TLV Options, Security

Geneve (Generic Network Virtualization Encapsulation) is the IETF standard tunnel format for data centre overlay networks, published as RFC 8926 in November 2020. It wraps an Ethernet frame or IP packet in UDP, sent to port 6081, behind an 8 byte base header that carries a 24 bit Virtual Network Identifier (VNI), a protocol type, two flag bits named O and C, and up to 252 bytes of type length value (TLV) options. Geneve has no authentication or encryption of its own, so securing it means keeping port 6081 inside a trusted underlay, filtering it at every untrusted edge, and adding IPsec or another cryptographic layer wherever the underlay, a tenant or a transit device is not fully trusted.

This post goes one level below our VXLAN and EVPN explainer, which covers overlays in general. Here we stay on Geneve: why the IETF chose it, the header bit by bit, option classes and critical options, where it runs, NIC offload, and a lab where you build, capture, decode and fence off a Geneve tunnel between two Linux hosts.

Key takeaways

• RFC 8926 is a Standards Track RFC published on 6 November 2020 by the IETF NVO3 working group. VXLAN (RFC 7348) and NVGRE (RFC 7637) are Informational. STT never became an RFC.
• The base header is 8 bytes: version, a 6 bit option length in 4 byte words, the O (control) and C (critical options present) bits, a 16 bit protocol type (0x6558 for Ethernet) and a 24 bit VNI. With options it ranges from 8 to 260 bytes.
• Each option has a 16 bit class, an 8 bit type whose top bit marks it critical, and a 5 bit length. An endpoint that does not recognise a critical option must drop the packet; transit devices must never drop, modify or reorder options.
• IANA runs the Geneve Option Class registry. Linux holds 0x0100, Open vSwitch 0x0101 and OVN 0x0102; the IETF range 0x0000 to 0x00FF is still empty.
• RFC 8926 says Geneve does not have "any inherent security mechanisms." Anyone on the underlay can snoop on, alter or inject tunnel traffic, and a compromised endpoint can spoof a VNI to reach another tenant. The RFC points to isolation and filtering inside one security domain and to IPsec across untrusted links. It does not mention MACsec.
• Plan the MTU for the largest options you allow. On a 1,500 byte IPv4 underlay, Geneve carrying Ethernet with no options leaves 1,450 bytes for the inner IP packet; with OVN's 8 byte option, 1,442.

Why Geneve was created after VXLAN, NVGRE and STT

By the early 2010s, data centre operators wanted to run thousands of isolated tenant networks over a routed IP fabric, without stretching VLANs across it. Three encapsulations appeared, each from a different group of vendors, and each solved the problem in a slightly different way.

VXLAN puts an Ethernet frame inside UDP port 4789, behind an 8 byte header with a 24 bit VXLAN Network Identifier and one meaningful flag, the I bit. RFC 7348 also described a flood and learn control plane over IP multicast, which most large deployments later replaced with BGP EVPN.

NVGRE reuses GRE. RFC 7637 splits the 32 bit GRE key into a 24 bit Virtual Subnet Identifier and an 8 bit FlowID for per flow entropy, with payload type 0x6558, the same value Geneve uses for Ethernet. With no UDP header, equal cost multipath (ECMP) hashing only works well if switches look inside the GRE key.

STT, the Stateless Transport Tunneling protocol, used "a TCP-like header" so that existing NIC TCP segmentation offload could chop large frames into wire sized segments, plus a 64 bit Context ID. Its segments carry IP protocol number 6 although the endpoints keep no TCP state, which made it fast on the NICs of the day and awkward for middleboxes expecting real TCP.

Each format had a fixed header with little room for metadata. RFC 8926 Section 2 argues the formats were "only superficially different," while control planes differed "in very fundamental ways." So Geneve standardises only the data format, stays independent of any control plane, and adds options so new metadata does not need a new protocol.

What the IETF NVO3 working group decided

The Network Virtualization Overlays (NVO3) working group was chartered to develop protocols for multi-tenant data centre networks over an IP underlay. Its charter says the group would "select, extend, and/or develop one or more data plane encapsulation format(s)." Rather than bless all three existing formats, the chairs and the Routing Area director set up a design team to see whether one common encapsulation could address the technical concerns.

The design team's report, draft-ietf-nvo3-encap, records the outcome. Its goals were to avoid "a design that is burdensome on hardware," allow future extensibility, behave well with ICMP and ECMP, and make sure further extensions would not need the consent of an organisation outside the IETF. Its abstract states that the team "recommend Geneve with few modifications as the common encapsulation." Section 7 explains why:

• A 24 bit VNI must be present in every packet, matching VXLAN and NVGRE.
• Geneve's total options length field lets NICs and transit devices skip straight to the inner payload; VXLAN-GPE with the Network Service Header lacked one.
• TLV options were judged more flexible than bit field extensions for operations, telemetry and security metadata, and the C bit lets a receiver decide quickly whether it must parse them.
• Geneve options were already in production use.

The team also asked for clearer guidance on critical options and fragmentation, and asked the working group to "work on security options for Geneve." No IETF standard security option exists yet, as the registry section below shows.

Timeline: from GRE to RFC 8926

How a Geneve packet is built

A Geneve packet has four layers: an outer Ethernet header for the underlay link, an outer IPv4 or IPv6 header addressed between the two tunnel endpoints, a UDP header, and the Geneve header followed by the payload. RFC 8926 shows both the IPv4 and IPv6 layouts in Figures 2 and 3. The payload is typically an Ethernet frame without its preamble, start frame delimiter or frame check sequence.

The outer UDP header and port 6081

The UDP header does two jobs. It identifies the packet as Geneve, and it gives the fabric something to hash on.

• Destination port. IANA assigned 6081. RFC 8926 says implementations should use it by default and recommends making it configurable. Unlike TCP, the port is not swapped for the return direction: both ends send to 6081.
• Source port. The sending endpoint picks it, and the RFC says it should be a hash of the inner packet's headers, for example the inner 5 tuple, so that each inner flow keeps one path and different flows spread across ECMP links. The whole 16 bit range may be used. Over IPv6, the flow label may carry entropy too.
• Checksum. Over IPv4, the UDP checksum should be generated. Over IPv6 it must be generated by default. A zero checksum is allowed only under the conditions in Section 4.3.1, which include checking that the IPv6 source and destination are valid for that tunnel and keeping zero checksum traffic from escaping to the Internet. Section 4.3 also warns that the UDP checksum is "not strong from a coding or cryptographic perspective" and does not detect malicious modification.

Because the source port changes per inner flow, firewall rules should match Geneve on destination port 6081 and the endpoint addresses, never on a source port.

The 8 byte base header, field by field

Two rules in Section 3.4 deserve attention. First, transit devices must forward consistently whatever the Opt Len value, including when they pick an ECMP link, so a packet's path never changes just because an endpoint started adding options. Second, the VNI's meaning is up to the control plane. The RFC says it often represents a layer 2 segment, but "the control plane defines the forwarding semantics." That is why the VNI on its own is not a security boundary: it is a label that both endpoints agree to honour.

Worked example 1: decoding an OVN Geneve header byte by byte

OVN, the virtual networking system built on Open vSwitch, gives a concrete case. Its architecture manual says that for Geneve, OVN puts the logical datapath identifier in the VNI and sends the logical ingress and egress ports in an option with class 0x0102, type 0x80 and a 32 bit value: 1 reserved bit, a 15 bit ingress port and a 16 bit egress port.

Suppose the logical datapath is 5, the ingress port is 1 and the egress port is 2. The Geneve header is 16 bytes:

02 40 65 58   00 00 05 00   01 02 80 01   00 01 00 02

Reading it:

1. 0x02 is binary 00 000010. The version is 0 and Opt Len is 2, meaning 2 times 4 = 8 bytes of options.
2. 0x40 is binary 0 1 000000. O is 0 (a data packet) and C is 1 (a critical option is present).
3. 0x6558 is the protocol type: the payload is an Ethernet frame.
4. 00 00 05 is the VNI, decimal 5, followed by the reserved byte 00.
5. 01 02 is the option class 0x0102, registered to OVN.
6. 0x80 is the type. Its high bit is 1, so this option is critical. That is why the C bit in the base header had to be set: RFC 8926 says if any option has its critical bit set, the C bit "MUST also be set."
7. 0x01 holds 3 reserved bits (000) and a 5 bit length of 1, meaning 1 times 4 = 4 bytes of option data after the 4 byte option header.
8. 00 01 00 02 is the data: reserved bit 0, ingress port 1 in the next 15 bits, egress port 2 in the last 16 bits.

Check the arithmetic: the one option is 4 header bytes plus 4 data bytes, 8 bytes in total, which equals Opt Len 2 times 4. If those two numbers ever disagree, Section 3.5 says the packet is invalid and must be silently dropped by an endpoint that processes options.

Because OVN marks its port option critical, an endpoint that does not understand class 0x0102 type 0x80 will drop the packet rather than deliver it to the wrong logical port. That is the critical bit doing its job: fail closed when the metadata needed to forward safely is not understood.

Worked example 2: tunnel overhead and the inner MTU

Overlay MTU problems are the most common Geneve outage, so it is worth doing the arithmetic. The underlay MTU counts the outer IP packet, not the outer Ethernet header. For an Ethernet payload, everything from the outer IP header to the end of the inner Ethernet header is overhead.

Add 4 bytes per inner 802.1Q tag. The maximum options row matters because RFC 8926 Section 4.4.1 says "the maximum length of options MUST be assumed" when sizing the tunnel MTU, since options can vary per packet. In practice deployments size for the options they negotiate, which is why the control plane must cap them. The RFC also recommends Path MTU Discovery and lets the encapsulating endpoint send ICMP "fragmentation needed" or "Packet Too Big" messages back to the tenant.

Option classes, types and critical options

The option TLV format

Each option starts with a 4 byte header:

An option is therefore 4 to 128 bytes long, and the sum of all options must equal Opt Len. RFC 8926 adds rules on how options evolve. Once an option type is defined as fixed length, it "MUST NOT be redefined to a different length." Some parsers ignore the length field for known fixed length types, so changing a length would break the parsing of every option after it. The fix is to allocate a new type.

Who allocates option classes

IANA created the Geneve Option Class registry on 4 May 2020, under a new Network Virtualization Overlay (NVO3) heading. The ranges are:

When we checked the registry on 24 October 2026, every allocation was in the first come first served range. The first four are open projects and specifications: 0x0100 Linux, 0x0101 Open vSwitch, 0x0102 OVN and 0x0103 In-band Network Telemetry. The rest are held by cloud providers, network and equipment makers, telecom operators and individual projects, many with blocks of several classes. The 0x0000 to 0x00FF IETF range was still unassigned, which means there is no IETF standard option yet, for security or anything else.

So the registry tells you who defined a class you see in a capture, but the meaning of each type lives in that owner's documentation.

What implementations do with options they do not understand

The critical drop rule "applies to the entire tunnel endpoint system," so a switch ASIC that cannot parse an option may punt the packet to its CPU over a rate limited channel instead. If total options exceed what an endpoint can process, it must drop the packet; the control plane must make sure peers only send options the other side can handle.

Why critical options matter for security

The critical bit is a safety feature. It lets a sender say "if you do not understand this, do not deliver the packet," which prevents a receiver from forwarding traffic without the policy metadata it was meant to carry. The OVN example shows the pattern: logical port information is critical, because delivering a packet without it could put it in the wrong place.

The same rules create two risks you should design for.

• Expensive drops. Anyone who can inject packets onto the underlay can attach unknown critical options. The drop itself is harmless, but if an endpoint logs, counts or punts every drop to a CPU, a flood becomes a denial of service.
• Slow path pressure. Where hardware sends unknown options to a general purpose CPU, RFC 8926 says that channel should be rate limited. Check that your platform's is.

Both come back to one mitigation: accept unauthenticated Geneve only from known tunnel endpoints.

Where Geneve is used

Linux kernel geneve devices

The Linux kernel has a native geneve link type, configured with ip link. The ip-link(8) manual lists its options: id for the VNI, remote for the peer address, ttl, tos, df, flowlabel, dstport to use a port "other than the default of 6081", external to let another component such as Open vSwitch or an eBPF program set the tunnel metadata per packet, and checksum controls (udpcsum, udp6zerocsumtx, udp6zerocsumrx). The innerprotoinherit flag carries IPv4 or IPv6 directly instead of an Ethernet frame. In external mode one device serves many VNIs and peers, with the metadata set per packet; this collect metadata mode is what Open vSwitch now relies on.

Open vSwitch

Open vSwitch supports Geneve as a tunnel port type. Its release FAQ lists Geneve over IPv4 as available with Linux 4.3 and later in the kernel datapath and from Open vSwitch 2.4 in the userspace datapath, and notes that newer Open vSwitch releases rely on the standard kernel tunnel devices with collect metadata support, which makes Linux 4.3 the minimum for these tunnels. The ovs-vswitchd database reference documents that when the csum option is unset, outgoing checksums are computed for UDP over IPv6 tunnels and not for GRE or UDP over IPv4 tunnels. Open vSwitch also has a built in IPsec mode that its documentation says supports GRE, Geneve and VXLAN tunnels, which we use in the lab below.

OVN

The ovn-architecture(7) manual says that "Due to its flexibility, the preferred encapsulation between hypervisors is Geneve." OVN needs more than 32 bits of metadata per packet: the logical datapath goes in the VNI and the logical ingress and egress ports go in the critical option described above. When VXLAN is enabled anywhere in an OVN cluster, the manual says datapath and egress port identifier ranges shrink to 12 bits each to fit in VXLAN's 24 bit VNI, and some features are lost. That is the extensibility argument from the RFC, playing out in a real system.

Cloud load balancers and appliance insertion

Some cloud platforms use Geneve to carry traffic between a load balancer and virtual appliances. The AWS documentation for Gateway Load Balancer, for example, says the load balancer and its registered appliance instances exchange traffic "using the GENEVE protocol on port 6081." Check your provider's own documentation for the options it adds.

Telemetry

The In-band Network Telemetry specification holds option class 0x0103 so switches can add metadata such as switch identifiers, ports and delays to passing packets. That is useful, and it also exposes internal topology to anyone who can capture underlay traffic.

How hardware offload works on NICs

At 25 Gbit/s and above, hosts depend on NIC offloads. RFC 8926 Section 4.6 lets a NIC help without understanding every option: it copies all options onto each segment during segmentation offload, merges received packets only when their headers are byte for byte equal, never reorders options and never drops unknown ones unless configured to (the NIC row in the table above). The Linux kernel's segmentation offload documentation describes the general mechanism: a SKB_GSO_UDP_TUNNEL segmentation type and separate inner header offsets so a device can segment the inner TCP stream and rebuild outer UDP headers for each segment. You can see what a NIC advertises with ethtool -k (look for features whose names include udp_tnl) and, on drivers that support it, ethtool --show-tunnels, which the ethtool manual says lists the UDP ports the kernel has programmed the device to parse as VXLAN or Geneve. Offloads are usually keyed on the UDP destination port, which is one practical reason to keep the default 6081 unless you have a reason to move it.

Comparison: VXLAN, Geneve, GRE and NVGRE

None of the four authenticates or encrypts anything. The choice between them is about metadata, interoperability and hardware, not security.

Which one to pick

The security properties of Geneve

No authentication, no encryption, no integrity

RFC 8926 Section 6 is direct. Because Geneve is carried in UDP and IP, it has no inherent security, so "an attacker with access to the underlay network transporting the IP packets has the ability to snoop on, alter, or inject packets." It adds that compromised tunnel endpoints or transit devices "may also spoof identifiers in the tunnel header to gain access to networks owned by other tenants."

That one paragraph covers most of the threat model:

RFC 7348 says the same of VXLAN: a MAC over IP mechanism "significantly extends this attack surface." Geneve inherits every one of those risks.

What RFC 8926 says about IPsec, and where MACsec fits

The RFC recommends three layers, depending on where the traffic goes.

1. Inside one security domain, such as a single operator's data centre, it says the most common and highest performing mechanism is "isolation of trusted components": carry tunnel traffic on a separate VLAN and filter it at any untrusted boundary.
2. Across untrusted links, such as the Internet between data centres, it says VPN technology "such as IPsec" should provide authentication and encryption of the outer IP packets, and that any Geneve data leaving the operator's security domain "SHOULD be secured by encryption mechanisms."
3. Where tenants need confidentiality from the underlay or from each other, it says an encryption mechanism should be used end to end between the NVEs, naming IPsec and DTLS, and notes that tenants may also bring their own protection, such as IPsec or TLS, inside the overlay.

RFC 8926 does not mention MACsec. MACsec (IEEE 802.1AE) protects Ethernet frames hop by hop, so each switch or router decrypts them. It is useful for underlay links you do not physically control, but a compromised switch in the path still sees clear text, and MACsec does not authenticate the far tunnel endpoint. IPsec between endpoints covers both. Our posts on MACsec and on IKEv2 and IPsec cover the two mechanisms in depth.

Why the VNI is not an isolation boundary on a shared underlay

The VNI keeps honest endpoints' traffic apart and does nothing against a dishonest sender. An endpoint cannot tell, inside Geneve, whether a packet with VNI 5 came from a legitimate peer, so anyone who can reach its address on UDP 6081 can choose the VNI. The real boundary is the underlay: who can send to port 6081 and who can see the wire.

Step by step: build, capture and fence off a Geneve tunnel between two Linux hosts

This lab uses two Linux hosts on a lab network. Host A has underlay address 192.0.2.1 on interface eth0, host B has 192.0.2.2. The commands need root and a kernel with the geneve module. They only create virtual interfaces and firewall rules; nothing here erases data. Use addresses from your own lab, not production.

Step 1: check that the kernel supports Geneve

# Is the geneve module available?
modinfo geneve | head -5

# Load it if needed (most distributions load it on demand)
sudo modprobe geneve

# Note the underlay MTU before you start
ip -br link show eth0

Step 2: create the tunnel on both hosts

On host A:

sudo ip link add gnv0 type geneve id 5001 remote 192.0.2.2 dstport 6081
sudo ip addr add 10.10.0.1/24 dev gnv0
sudo ip link set gnv0 up

On host B:

sudo ip link add gnv0 type geneve id 5001 remote 192.0.2.1 dstport 6081
sudo ip addr add 10.10.0.2/24 dev gnv0
sudo ip link set gnv0 up

Inspect the result with details:

ip -d link show gnv0

The detailed output shows the link type, the VNI, the remote address, the destination port and checksum settings. Confirm that id and dstport match on both sides; a VNI mismatch produces silence, not an error.

Step 3: check and set the MTU

With a 1,500 byte underlay over IPv4 and no options, Worked example 2 gives an inner MTU of 1,450. Set it explicitly rather than relying on defaults:

sudo ip link set gnv0 mtu 1450

Now test it from host A. ping -M do forbids fragmentation, and -s sets the ICMP payload size. An inner IPv4 packet is the payload plus 8 bytes of ICMP header plus 20 bytes of IP header, so 1,422 bytes of payload makes a 1,450 byte packet:

# Should succeed: 1422 + 8 + 20 = 1450
ping -M do -s 1422 -c 3 10.10.0.2

# Should fail with a local "message too long" error: 1423 + 28 = 1451
ping -M do -s 1423 -c 3 10.10.0.2

If the first ping fails, the underlay path has a smaller MTU than you think or drops ICMP fragmentation needed messages.

Step 4: capture and decode the Geneve header

On host B, capture the underlay traffic while host A pings:

# All Geneve traffic on the underlay interface, verbose, with hex
sudo tcpdump -ni eth0 -vv -e -X udp dst port 6081

tcpdump's Geneve printer decodes UDP port 6081. Its output shows the outer IP and UDP headers, then a Geneve line with the flags, the VNI in hex and any options (with class, type and length), followed by the inner packet. Add -e to also print the protocol type. VNI 5001 appears as 0x1389. In the hex dump, find the 8 bytes right after the 8 byte UDP header: with no options they read 00 00 65 58 00 13 89 00. The first byte is 0 because Opt Len is 0, the second is 0 because neither O nor C is set, then come the protocol type 0x6558 and the VNI.

The pcap-filter(7) manual adds a geneve keyword (available since libpcap 1.8.0) that matches Geneve packets and shifts later filter terms to the inner packet. That lets you filter on inner traffic in a given VNI:

# Only ICMP inside VNI 5001
sudo tcpdump -ni eth0 'geneve 5001 and icmp'

# Only inner IPv4 traffic to 10.10.0.2 in that VNI
sudo tcpdump -ni eth0 'geneve 5001 and ip dst 10.10.0.2'

Note what the capture proves: anyone with a span port or tap on the underlay sees every inner packet in clear text. That is the snooping threat from RFC 8926 Section 6.1, in your own terminal.

Step 5: fence off UDP 6081 on each host

Allow Geneve only from known peers and drop it from everyone else. This nftables example runs on host B; mirror it on host A with the peer address changed. Load it from a file so you can review it first.

cat > /tmp/geneve-guard.nft <<'EOF'
table inet geneve_guard {
  set geneve_peers {
    type ipv4_addr
    elements = { 192.0.2.1 }
  }
  chain input {
    type filter hook input priority -10; policy accept;
    udp dport 6081 ip saddr @geneve_peers accept
    udp dport 6081 counter drop
  }
}
EOF
sudo nft -c -f /tmp/geneve-guard.nft   # check syntax only
sudo nft -f /tmp/geneve-guard.nft
sudo nft list table inet geneve_guard

For an IPv6 underlay, add an ipv6_addr set and matching rule. The drop counter shows whether anything else is trying the port. This host rule is a last line of defence, not the first.

Step 6: filter at the underlay edge

The host rule protects one endpoint. The fabric should also stop Geneve from ever entering the underlay from outside it. At every boundary router or firewall between the underlay and anything else (the Internet, the corporate network, tenant facing networks, management networks), apply the equivalent of:

Do the same for 4789 if you also run VXLAN, then confirm from a lab machine outside the fabric that the port is filtered and from inside that endpoints still reach each other.

Step 7: add IPsec between endpoints where the underlay is not trusted

If the tunnel crosses links you do not control, or the risk analysis says tenants need confidentiality from the underlay, encrypt the outer packets. With Open vSwitch, the OVS IPsec documentation shows tunnel ports configured with IPsec options, using a pre shared key, self signed certificates or CA signed certificates. A Geneve port with CA signed certificates looks like this, with the daemon and certificates set up as that guide describes:

sudo ovs-vsctl add-port br0 gnv-ipsec0 -- \
  set interface gnv-ipsec0 type=geneve \
  options:remote_ip=192.0.2.2 \
  options:remote_name=hostb.example.internal

The same guide documents a plaintext policy setting, other_config:ipsec_skb_mark, that makes OVS drop unencrypted tunnel packets so a failed IPsec negotiation cannot fall back to clear text. Use it once all peers are configured. Recompute the MTU afterwards: ESP adds its own header, initialisation vector, padding and integrity check value on top of the Geneve overhead.

Step 8: clean up

sudo ip link del gnv0
sudo nft delete table inet geneve_guard

How to secure a Geneve deployment: a checklist

1. Inventory every Geneve speaker (hypervisors, gateways, load balancers, appliances) and put them on a dedicated underlay VLAN or VRF that tenants cannot reach.
2. Filter UDP 6081 at every edge and on each host, allowing only known endpoint prefixes, with ingress filtering and reverse path checks on endpoint source addresses.
3. Encrypt with IPsec between endpoints whenever traffic leaves your security domain, crosses a shared underlay, or tenants need confidentiality.
4. Restrict options in the control plane: agree which classes and types each pair of endpoints may send, cap total option length, set the MTU for that maximum, and rate limit the slow path for unknown options.
5. Protect the control plane. The NVA or SDN controller that maps VNIs to tenants is worth more to an attacker than any single tunnel. Authenticate it and the endpoints to each other, and patch it like any other critical service.
6. Alert on unexpected Geneve. A packet to UDP 6081 from an address that is not an endpoint signals misconfiguration or probing.

Common mistakes

• Setting the overlay MTU for zero options. Turning on a telemetry or policy option later shrinks the usable payload, and large packets start disappearing. Plan for the maximum options length you will allow, as RFC 8926 Section 4.4.1 requires.
• Filtering ICMP on the underlay. Path MTU Discovery depends on fragmentation needed and Packet Too Big messages. Blocking them turns an MTU mismatch into hung TCP sessions inside tenants.
• Treating the VNI as an isolation boundary on a shared underlay. The VNI is a label any sender can choose. Isolation comes from controlling who can reach port 6081 and, where needed, from IPsec.
• Leaving UDP 6081 reachable from untrusted networks. An Internet facing or tenant reachable endpoint accepts injected frames into any VNI it serves. Filter at the edge and on the host.
• Matching Geneve by source port. The source port is a per flow hash. Match on destination port 6081 and endpoint addresses.
• Forgetting custom ports. If you changed dstport, update firewall rules, capture filters and NIC offload settings that key on the port.
• Disabling UDP checksums over IPv6 casually. RFC 8926 allows it only under specific conditions, including receiver address checks and filters that keep such traffic off the Internet.
• Assuming MACsec on the fabric equals end to end protection. Every switch on the path still sees clear text Geneve, including the VNI and options.

FAQ

What is Geneve in networking?

Geneve, short for Generic Network Virtualization Encapsulation, is a tunnelling protocol defined in RFC 8926 that carries virtual network traffic between tunnel endpoints across an IP network. It uses UDP port 6081, a 24 bit Virtual Network Identifier and optional TLV metadata, and it is used mostly in virtualised data centres and cloud networks.

What port does Geneve use?

UDP destination port 6081, assigned by IANA. RFC 8926 recommends that implementations let you change it, and the Linux ip link command accepts a dstport option. The UDP source port is a hash of the inner flow and changes from flow to flow.

What is the difference between Geneve and VXLAN?

Both put a frame inside UDP with a 24 bit network identifier, and both have an 8 byte base header. VXLAN's header is fixed and carries only Ethernet. Geneve can carry any Ethertype and adds variable length TLV options, so systems can send metadata such as logical ports, policy tags or telemetry with each packet. VXLAN uses UDP 4789; Geneve uses UDP 6081.

Is Geneve encrypted?

No. RFC 8926 states that Geneve has no inherent security mechanisms. Anyone with access to the underlay can read, change or inject Geneve packets. Use IPsec or another VPN technology between tunnel endpoints when traffic crosses untrusted links or when tenants need confidentiality.

What is the maximum Geneve header size?

260 bytes: the 8 byte base header plus up to 252 bytes of options, because the 6 bit Opt Len field counts up to 63 words of 4 bytes. Each individual option is between 4 and 128 bytes.

What does the C bit mean in Geneve?

The C bit in the base header says at least one option is critical. A critical option has the top bit of its type field set. A receiving endpoint that does not understand a critical option must drop the packet, and an endpoint that cannot parse options at all must drop any packet with the C bit set. Transit devices ignore it.

What MTU should I use for a Geneve tunnel?

1,450 bytes for the inner IP packet over a 1,500 byte IPv4 underlay with no options. Subtract 20 for IPv6, your maximum options, 4 per inner VLAN tag and any IPsec overhead, or raise the underlay to jumbo frames.

Does Geneve support hardware offload?

Yes, on many current server NICs, and RFC 8926 sets rules so a NIC can offload without understanding every option. On Linux, check ethtool -k for the tx-udp_tnl-segmentation feature.

Can I use Geneve over the Internet?

RFC 8926 is written for data centres run by one operator or cooperating operators, and says Geneve leaving the operator's security domain should be encrypted, for example with IPsec. Unencrypted Geneve over the Internet exposes every tenant frame and invites injection.

Where Safeguard fits

Safeguard does not inspect tunnels, filter UDP 6081, configure IPsec or manage switches and NICs. The fit is indirect and sits one layer up, in the software that runs an overlay: virtual switch agents, SDN controllers, gateways and the container images that package them, all built from open source dependencies. Safeguard scans the repositories, container images and SBOMs your team builds for those services (safeguard scan --dir ., --image <name>, --sbom <file>), matches components against vulnerability databases, shows which projects contain a given component and version, applies reachability analysis and policy gates, and can open fix pull requests when you turn autonomous remediation on. It does not patch the host kernel's geneve driver, a NIC's firmware or a vendor appliance's operating system; those fixes come from your distribution or vendor.

Software supply chain hygiene still matters here because an overlay is only as trustworthy as the controller and virtual switch software that programs it, and that software ships with long lists of open source dependencies. The fix paths below apply to the dependencies and container images you build and deploy around Geneve, not to kernels, NIC firmware or vendor appliances, which still have to be patched through their own channels.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at the container image of an SDN controller, gateway or virtual switch agent your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild when an advisory lands for a networking library.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a pinned dependency in the service that programs your overlay, where you want a human to see every change before it reaches the control plane.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific release of a networking library in your controller images, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 8926: Geneve, Generic Network Virtualization Encapsulation (November 2020)
• IETF Datatracker: RFC 8926 history
• IETF Datatracker: draft-gross-geneve
• draft-ietf-nvo3-encap-05: NVO3 Encapsulation Considerations (February 2020)
• IETF NVO3 working group charter
• RFC 7348: VXLAN (August 2014)
• RFC 7637: NVGRE (September 2015)
• RFC 2784: Generic Routing Encapsulation (March 2000)
• RFC 8086: GRE-in-UDP Encapsulation (March 2017)
• RFC 7365: Framework for Data Center Network Virtualization (October 2014)
• RFC 8014: An Architecture for Data-Center Network Virtualization over Layer 3 (December 2016)
• draft-davie-stt-08: A Stateless Transport Tunneling Protocol for Network Virtualization (April 2016, expired)
• IANA: Network Virtualization Overlay (NVO3) registry, Geneve Option Class
• IANA: Service Name and Transport Protocol Port Number Registry
• ip-link(8) manual page
• ethtool(8) manual page
• pcap-filter(7) manual page
• Linux kernel documentation: Segmentation Offloads
• Open vSwitch FAQ: Releases
• Open vSwitch: ovs-vswitchd.conf.db(5)
• Open vSwitch: Encrypt Open vSwitch Tunnels with IPsec
• OVN: ovn-architecture(7)
• AWS documentation: What is a Gateway Load Balancer?

Last reviewed: 24 October 2026. Geneve option formats are defined by each option class owner and implementations differ in which options, offloads and checksum defaults they support; check your own platform's documentation before relying on any behavior described here.