On 07/13/14 at 03:08pm, Tom Herbert wrote:
On Fri, Jul 11, 2014 at 9:59 AM, Thomas Graf [off-list ref] wrote:
quoted
The VXLAN receive code is currently conservative in what it accepts and
will reject any frame that uses any of the reserved fields. The VXLAN
draft specifies that "reserved fields MUST be set to zero on transmit
and ignored on receive." though.
Be liberal in only requiring the I bit to allow for VXLAN extensions
to be implemented.
This is not robust (this is a problem in the VXLAN spec not your
patch). There is no requirement that the VXLAN bits are optional. For
example, if a receiver accepts a GPE packet but doesn't implement it
the packet will be misinterpreted. I've already pointed this out to
the VLXAN folks on nvo3 list. Dropping packets with unknown bits set
is the only sane approach.
I agree, it's a mess.
At least VXLAN-gpe has realized this and will reserve an individual
port number. The port number is not yet fixed so it can't be enforced
yet but once that is done, gpe frame acceptance can be bound to the use
of that particular UDP port.