One document matched: draft-ietf-nvo3-vxlan-gpe-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-nvo3-vxlan-gpe-03" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="VXLAN-GPE">Generic Protocol Extension for VXLAN</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Fabio Maino (Editor)" initials="F." surname="Maino, Ed.">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<region></region>
<country></country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</author>
<author fullname="Larry Kreeger (editor)" initials="L."
surname="Kreeger, Ed.">
<organization></organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<region></region>
<country></country>
</postal>
<email>lkreeger@gmail.com</email>
</address>
</author>
<author fullname="Uri Elzur (editor)" initials="U." surname="Elzur, Ed.">
<organization>Intel</organization>
<address>
<postal>
<street></street>
<code></code>
<city></city>
<region></region>
<country></country>
</postal>
<email>uri.elzur@intel.com</email>
</address>
</author>
<date day="25" month="October" year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>LISP; L2 Overlay, L3 Overlay</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This draft describes extending Virtual eXtensible Local Area Network
(VXLAN), via changes to the VXLAN header, with three new capabilities:
support for multi-protocol encapsulation, operations, administration and
management (OAM) signaling and explicit versioning.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Virtual eXtensible Local Area Network VXLAN <xref
target="RFC7348"></xref> defines an encapsulation format that
encapsulates Ethernet frames in an outer UDP/IP transport. As data
centers evolve, the need to carry other protocols encapsulated in an IP
packet is required, as well as the need to provide increased visibility
and diagnostic capabilities within the overlay. The VXLAN header does
not specify the protocol being encapsulated and therefore is currently
limited to encapsulating only Ethernet frame payload, nor does it
provide the ability to define OAM protocols. In addition, <xref
target="RFC6335"></xref> requires that new transports not use transport
layer port numbers to identify tunnel payload, rather it encourages
encapsulations to use their own identifiers for this purpose. VXLAN GPE
is intended to extend the existing VXLAN protocol to provide protocol
typing, OAM, and versioning capabilities.</t>
<t>The Version and OAM bits are introduced in <xref
target="vxlan-gpe"></xref>, and the choice of location for these fields
is driven by minimizing the impact on existing deployed hardware. </t>
<t>In order to facilitate deployments of VXLAN GPE with hardware
currently deployed to support VXLAN, changes from legacy VXLAN have been
kept to a minimum. <xref target="compatibility"></xref> provides a
detailed discussion about how VXLAN GPE addresses the requirement for
backward compatibility with VXLAN.</t>
</section>
<section title="VXLAN Without Protocol Extension">
<t>VXLAN provides a method of creating multi-tenant overlay networks by
encapsulating packets in IP/UDP along with a header containing a network
identifier which is used to isolate tenant traffic in each overlay
network from each other. This allows the overlay networks to run over an
existing IP network.</t>
<t>Through this encapsulation, VXLAN creates stateless tunnels between
VXLAN Tunnel End Points (VTEPs) which are responsible for adding/
removing the IP/UDP/VXLAN headers and providing tenant traffic isolation
based on the VXLAN Network Identifier (VNI). Tenant systems are unaware
that their networking service is being provided by an overlay.</t>
<t>When encapsulating packets, a VTEP must know the IP address of the
proper remote VTEP at the far end of the tunnel that can deliver the
inner packet to the Tenant System corresponding to the inner destination
address. In the case of tenant multicast or broadcast, the outer IP
address may be an IP multicast group address, or the VTEP may replicate
the packet and send it to all known VTEPs. If multicast is used in the
underlay network to send encapsulated packets to remote VTEPs, Any
Source Multicast is used and each VTEP serving a particular VNI must
perform a (*, G) join to the same group IP address.</t>
<t>Inner to outer address mapping can be determined in two ways. One is
source based learning in the data plane, and the other is distribution
via a control plane. </t>
<t>Source based learning requires a receiving VTEP to create an inner to
outer address mapping by gleaning the information from the received
packets by correlating the inner source address to the outer source IP
address. When a mapping does not exist, a VTEP forwards the packets to
all remote VTEPs participating in the VNI by using IP multicast in the
IP underlay network. Each VTEP must be configured with the IP multicast
address to use for each VNI. How this occurs is out of scope.</t>
<t>The control plane used to distribute inner to outer mappings is also
out of scope. It could use a centralized authority or be distributed, or
use a hybrid.</t>
<t>The VXLAN Network Identifier (VNI) provides scoping for the addresses
in the header of the encapsulated PDU. If the encapsulated packet is an
Ethernet frame, this means the Ethernet MAC addresses are only unique
within a given VNI and may overlap with MAC addresses within a different
VNI. If the encapsulated packet is an IP packet, this means the IP
addresses are only unique within that VNI.</t>
<t><figure anchor="vxlan_header" title="VXLAN Header">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|R|R|I|R|R|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
<section anchor="vxlan-gpe"
title="Generic Protocol Extension for VXLAN (VXLAN GPE)">
<section title="VXLAN GPE Header">
<t><figure anchor="vxlan_gpe" title="VXLAN GPE Header">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|R|O| Reserved |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><list style="hanging">
<t hangText="Flags (8 bits):">The first 8 bits of the header are
the flag field. The bits designated "R" above are reserved flags.
These MUST be set to zero on transmission and ignored on
receipt.</t>
<t hangText="Version (Ver):">Indicates VXLAN GPE protocol version.
The initial version is 0. If a receiver does not support the
version indicated it MUST drop the packet.</t>
<t hangText="Instance Bit (I bit):">The I bit MUST be set to
indicate a valid VNI.</t>
<t hangText="Next Protocol Bit (P bit):">The P bit is set to
indicate that the Next Protocol field is present.</t>
<t hangText="OAM Flag Bit (O bit):">The O bit is set to indicate
that the packet is an OAM packet.</t>
<t hangText="Next Protocol:">This 8 bit field indicates the
protocol header immediately following the VXLAN GPE header.</t>
<t hangText="VNI:">This 24 bit field identifies the VXLAN overlay
network the inner packet belongs to. Inner packets belonging to
different VNIs cannot communicate with each other (unless
explicitly allowed by policy).</t>
<t hangText="Reserved:">Reserved fields MUST be set to zero on
transmission and ignored on receipt.</t>
</list></t>
</section>
<section title="Multi Protocol Support">
<t>This draft defines the following two changes to the VXLAN header in
order to support multi-protocol encapsulation:</t>
<t><list style="hanging">
<t hangText="P Bit:">Flag bit 5 is defined as the Next Protocol
bit. The P bit MUST be set to 1 to indicate the presence of the 8
bit next protocol field.</t>
<t hangText="">When UDP dest port=4790, P = 0 the "Next Protocol"
field must be set to zero and the payload MUST be ETHERNET(L2) as
defined by <xref target="RFC7348"></xref>.</t>
<t hangText="">Flag bit 5 was chosen as the P bit because this
flag bit is currently reserved in VXLAN.</t>
<t hangText="Next Protocol Field:">The lower 8 bits of the first
word are used to carry a next protocol. This next protocol field
contains the protocol of the encapsulated payload packet. A new
protocol registry will be requested from IANA, see section
9.2.</t>
<t hangText="">This draft defines the following Next Protocol
values:</t>
<t hangText=""><list style="hanging">
<t hangText="0x1 :">IPv4</t>
<t hangText="0x2 :">IPv6</t>
<t hangText="0x3 :">Ethernet</t>
<t hangText="0x4 :">Network Service Header <xref
target="I-D.ietf-sfc-nsh"></xref></t>
<t hangText="0x5 :">Multiprotocol Label Switching <xref
target="RFC3031"></xref>. Please see <xref
target="I-D.ietf-idr-tunnel-encaps"></xref> for more
details.</t>
</list></t>
</list></t>
</section>
<section title="OAM Support">
<t>Flag bit 7 is defined as the O bit. When the O bit is set to 1, the
packet is an OAM packet and OAM processing MUST occur. Other header
fields including Next Protocol MUST adhere to the definitions in <xref
target="vxlan-gpe"></xref>. The OAM protocol details are out of scope
for this document. As with the P-bit, bit 7 is currently a reserved
flag in VXLAN.</t>
</section>
<section title="Version Bits">
<t>VXLAN GPE bits 2 and 3 are defined as version bits. These bits are
reserved in VXLAN. The version field is used to ensure backward
compatibility going forward with future VXLAN GPE updates. </t>
<t> The initial version for VXLAN GPE is 0. </t>
</section>
</section>
<section title="Outer Encapsulations">
<t>In addition to the VXLAN GPE header, the packet is further
encapsulated in UDP and IP. Data centers based on Ethernet, will then
send this IP packet over Ethernet.</t>
<t>Outer UDP Header:</t>
<t>Destination UDP Port: IANA has assigned the value 4790 for the VXLAN
GPE UDP port. This well-known destination port is used when sending
VXLAN GPE encapsulated packets.</t>
<t>Source UDP Port: The source UDP port is used as entropy for devices
forwarding encapsulated packets across the underlay (ECMP for IP
routers, or load splitting for link aggregation by bridges). Tenant
traffic flows should all use the same source UDP port to lower the
chances of packet reordering by the underlay for a given flow. It is
recommended for VTEPs to generate this port number using a hash of the
inner packet headers. Implementations MAY use the entire 16 bit source
UDP port for entropy.</t>
<t>UDP Checksum: Source VTEPs MAY either calculate a valid checksum, or
if this is not possible, set the checksum to zero. When calculating a
checksum, it MUST be calculated across the entire packet (outer IP
header, UDP header, VXLAN GPE header and payload packet). All receiving
VTEPs must accept a checksum value of zero. If the receiving VTEP is
capable of validating the checksum, it MAY validate a non-zero checksum
and MUST discard the packet if the checksum is determined to be
invalid.</t>
<t>Outer IP Header:</t>
<t>This is the header used by the underlay network to deliver packets
between VTEPs. The destination IP address can be a unicast or a
multicast IP address. The source IP address must be the source VTEP IP
address which can be used to return tenant packets to the tenant system
source address within the inner packet header.</t>
<t>When the outer IP header is IPv4, VTEPs MUST set the DF bit. </t>
<t>Outer Ethernet Header:</t>
<t>Most data centers networks are built on Ethernet. Assuming the outer
IP packet is being sent across Ethernet, there will be an Ethernet
header used to deliver the IP packet to the next hop, which could be the
destination VTEP or be a router used to forward the IP packet towards
the destination VTEP. If VLANs are in use within the data center, then
this Ethernet header would also contain a VLAN tag.</t>
<t>The following figures show the entire stack of protocol headers that
would be seen on an Ethernet link carrying encapsulated packets from a
VTEP across the underlay network for both IPv4 and IPv6 based underlay
networks.</t>
<t> </t>
<t><figure anchor="outer_header"
title="Outer Headers for VXLAN GPE over IPv4">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocl=17(UDP)| Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = 4790 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN GPE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|R|O| Reserved |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Depends on VXLAN GPE Next Protocol field above. |
| Note that if the payload is Ethernet, then the original |
| Ethernet Frame's FCS is not included. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t></t>
<t></t>
<t><figure anchor="outer_header_ipv6"
title="Outer Headers for VXLAN GPE over IPv6">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Ethertype = C-Tag 802.1Q | Outer VLAN Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv6 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | NxtHdr=17(UDP)| Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Source IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Outer Destination IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port = 4790 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VXLAN GPE Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|Ver|I|P|R|O| Reserved |Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Depends on VXLAN GPE Next Protocol field above. |
| Note that if the payload is Ethernet, then the original |
| Ethernet Frame's FCS is not included. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame Check Sequence:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New FCS (Frame Check Sequence) for Outer Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<section title="Inner VLAN Tag Handling">
<t>If the inner packet (as indicated by the VXLAN GPE Next Protocol
field) is an Ethernet frame, it is recommended that it does not
contain a VLAN tag. In the most common scenarios, the tenant VLAN tag
is translated into a VXLAN Network Identifier. In these scenarios,
VTEPs should never send an inner Ethernet frame with a VLAN tag, and a
VTEP performing decapsulation should discard any inner frames received
with a VLAN tag. However, if the VTEPs are specifically configured to
support it for a specific VXLAN Network Identifier, a VTEP may support
transparent transport of the inner VLAN tag between all tenant systems
on that VNI. The VTEP never looks at the value of the inner VLAN tag,
but simply passes it across the underlay.</t>
</section>
<section title="Fragmentation Considerations">
<t>VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and
when the outer IP header is IPv4, VTEPs MUST set the DF bit in the
outer IPv4 header. It is recommended that the underlay network be
configured to carry an MTU at least large enough to accommodate the
added encapsulation headers. It is recommended that VTEPs perform Path
MTU discovery <xref target="RFC1191"></xref> <xref
target="RFC1981"></xref> to determine if the underlay network can
carry the encapsulated payload packet.</t>
</section>
</section>
<section anchor="compatibility" title="Backward Compatibility">
<section title="VXLAN VTEP to VXLAN GPE VTEP">
<t>A VXLAN VTEP conforms to VXLAN frame format and uses UDP
destination port 4789 when sending traffic to VXLAN GPE VTEP. As per
VXLAN, reserved bits 5 and 7, VXLAN GPE P and O-bits respectively must
be set to zero. The remaining reserved bits must be zero, including
the VXLAN GPE version field, bits 2 and 3. The encapsulated payload
MUST be Ethernet.</t>
</section>
<section title="VXLAN GPE VTEP to VXLAN VTEP">
<t>A VXLAN GPE VTEP MUST NOT encapsulate non-Ethernet frames to a
VXLAN VTEP. When encapsulating Ethernet frames to a VXLAN VTEP, the
VXLAN GPE VTEP MUST conform to VXLAN frame format and hence will set
the P bit to 0, the Next Protocol to 0 and use UDP destination port
4789. A VXLAN GPE VTEP MUST also set O = 0 and Ver = 0 when
encapsulating Ethernet frames to VXLAN VTEP. The receiving VXLAN VTEP
will treat this packet as a VXLAN packet.</t>
<t>A method for determining the capabilities of a VXLAN VTEP (GPE or
non-GPE) is out of the scope of this draft.</t>
</section>
<section title="VXLAN GPE UDP Ports">
<t>VXLAN GPE uses a IANA assigned UDP destination port, 4790, when
sending traffic to VXLAN GPE VTEPs.</t>
</section>
<section title="VXLAN GPE and Encapsulated IP Header Fields">
<t>When encapsulating and decapsulating IPv4 and IPv6 packets, certain
fields, such as IPv4 Time to Live (TTL) from the inner IP header need
to be considered. VXLAN GPE IP encapsulation and decapsulation
utilizes the techniques described in <xref target="RFC6830"></xref>,
section 5.3.</t>
</section>
</section>
<section anchor="examples" title="VXLAN GPE Examples">
<t>This section provides three examples of protocols encapsulated using
the Generic Protocol Extension for VXLAN described in this document.</t>
<t><figure anchor="ipv4_example" title="IPv4 and VXLAN GPE">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|0|0|I|1|R|0| Reserved | NP = IPv4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original IPv4 Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><figure anchor="ipv6_example" title="IPv6 and VXLAN GPE">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|0|0|I|1|R|0| Reserved | NP = IPv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original IPv6 Packet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t><figure anchor="ethernet_example" title="Ethernet and VXLAN GPE">
<preamble></preamble>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|0|0|I|1|R|0| Reserved |NP = Ethernet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Ethernet Frame |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t></t>
</section>
<section anchor="security" title="Security Considerations">
<t>VXLAN's security is focused on issues around L2 encapsulation into
L3. With VXLAN GPE, issues such as spoofing, flooding, and traffic
redirection are dependent on the particular protocol payload
encapsulated.</t>
</section>
<section anchor="contributors" title="Contributors">
<t><figure>
<artwork><![CDATA[ Paul Quinn
Cisco Systems
paulq@cisco.com
Rajeev Manur
Broadcom
rmanur@broadcom.com
Michael Smith
Cisco Systems
michsmit@cisco.com
Darrel Lewis
Cisco Systems
darlewis@cisco.com
Puneet Agarwal
Innovium, Inc
puneet@acm.org
Lucy Yong
Huawei USA
lucy.yong@huawei.com
Xiaohu Xu
Huawei Technologies
xuxiaohu@huawei.com
Pankaj Garg
Microsoft
pankajg@microsoft.com
David Melman
Marvell
davidme@marvell.com]]></artwork>
</figure></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgments">
<t>A special thank you goes to Dino Farinacci for his guidance and
detailed review.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section title="UDP Port">
<t>UDP 4790 port has been assigned by IANA for VXLAN GPE.</t>
</section>
<section title="VXLAN GPE Next Protocol">
<t>IANA is requested to set up a registry of "Next Protocol". These
are 8-bit values. Next Protocol values 0, 1, 2, 3 and 4 are defined in
this draft. New values are assigned via Standards Action <xref
target="RFC5226"></xref>.</t>
<t></t>
<texttable>
<ttcol>Next Protocol</ttcol>
<ttcol>Description</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c>This Document</c>
<c>1</c>
<c>IPv4</c>
<c>This Document</c>
<c>2</c>
<c>IPv6</c>
<c>This Document</c>
<c>3</c>
<c>Ethernet</c>
<c>This Document</c>
<c>4</c>
<c>NSH</c>
<c>This Document</c>
<c>5</c>
<c>MPLS</c>
<c>This Document</c>
<c>6..253</c>
<c>Unassigned</c>
<c></c>
</texttable>
<t></t>
</section>
<section title="VXLAN GPE Flag and Reserved Bits">
<t>There are ten flag bits at the beginning of the VXLAN GPE header,
followed by 16 reserved bits and an 8-bit reserved field at the end of
the header. New bits are assigned via Standards Action <xref
target="RFC5226"></xref>.</t>
<t><list style="empty">
<t>Bits 0-1 - Reserved</t>
<t>Bits 2-3 - Version</t>
<t>Bit 4 - Instance ID (I bit)</t>
<t>Bit 5 - Next Protocol (P bit)</t>
<t>Bit 6 - Reserved</t>
<t>Bit 7 - OAM (O bit)</t>
<t>Bit 8-23 - Reserved</t>
<t>Bits 24-31 in the 2nd Word -- Reserved</t>
</list></t>
<t>Reserved bits/fields MUST be set to 0 by the sender and ignored by
the receiver.</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7348.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6335.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6830.xml"?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-10.xml"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-idr-tunnel-encaps-02.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 22:30:25 |