Separate gateway policy from tunnel security
06A gateway can connect a VXLAN overlay to a conventional Ethernet network using a Virtual Local Area Network (VLAN). Its VLAN policy and the trustworthiness of tunnel endpoints are separate from VNI parsing.
A separately configured admission/ACL or IPsec boundary can restrict traffic or provide authentication and optional encryption. VXLAN itself has not gained an encrypted mode or automatic identity verification.
Source for this drawing: RFC 7348 · Read RFC section 6 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
A VNI scopes forwarding; it does not authenticate or encrypt a tunnel.
- A gateway can map an incoming conventional VLAN to a configured VXLAN overlay. A VLAN ID and a VNI are different identifiers; the example maps VLAN 7 to VNI 100 by administrator choice.
- On encapsulation, a VTEP SHOULD NOT include an inner VLAN tag and SHOULD strip an existing tag unless configured otherwise. On decapsulation, an inner-tagged VXLAN frame SHOULD be discarded unless configured otherwise.
- These are SHOULD-level defaults with explicit configuration exceptions, not unconditional MUST rules.
- RFC 7348 adds no specific cryptographic defense against traffic injection or MAC spoofing. Administrative controls and Access Control Lists (ACLs) are possible separate measures. IPsec can authenticate and optionally encrypt tunneled traffic with its own credential infrastructure.
The gateway/VLAN diagrams and the security comparisons are separate examples. The optional ACL/IPsec boundary is not a built-in VXLAN feature or a claim to implement an authentication protocol. VTEPs may live in software, physical servers or switches; they are not limited to a hypervisor.
Read the RFC section ↗