Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums

Joe Touch <> Fri, 02 May 2014 22:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D0761A09C3; Fri, 2 May 2014 15:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ta080TWruD-x; Fri, 2 May 2014 15:45:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 643391A0957; Fri, 2 May 2014 15:45:53 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s42MjT4S005175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 May 2014 15:45:29 -0700 (PDT)
Message-ID: <>
Date: Fri, 02 May 2014 15:45:29 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Tom Herbert <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: "" <>,, "" <>, "" <>, "" <>
Subject: Re: [Tofoo] VXLAN (UDP tunnel protocols) and non-zero checksums
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 May 2014 22:45:54 -0000

On 5/2/2014 3:34 PM, Tom Herbert wrote:
> On Fri, May 2, 2014 at 3:25 PM, Joe Touch <> wrote:
>> On 5/2/2014 2:34 PM, Tom Herbert wrote:
>> ...
>>>             VXLAN draft also breaks this by making accepting packets with
>>>          zero checksums a MUST.
>>>      That's not "breaking" anything; VXLAN is - to UDP - an application.
>>> Perhaps not, but making it a MUST in the encapsulation protocol
>>> definition to always accept UDP packets with zero checksums seems a bit
>>> austere. For instance, if I know within my deployment that all senders
>>> are configured to use checksums, then receiving a packet with zero
>>> checksum should be considered an invalid packet.
>> Sorry if I'm missing something here - this started with the following, from draft-mahalingam-dutt-dcops-vxlan-09, which focuses on the non-zero checksum case:
>> "When a decapsulating endpoint receives a packet with a non-zero
>> checksum it MAY choose to verify the checksum"
>> The point is that this is NOT an option. If the UDP checksum is nonzero, it MUST be validated.
>> (this isn't open to interpretation; if you want to have VXLAN accept non-zero checksums that are invalid, then you are not compliant with what few standards the Internet has)
> I am referring to:
> "When a packet is received with a UDP checksum of zero, it MUST be
> accepted for decapsulation."

That is a completely valid choice w.r.t. RFCs 1122 and 768.

1122 is the most specific on these points:

             A host MUST implement the facility to generate and validate
             UDP checksums.  An application MAY optionally be able to
             control whether a UDP checksum will be generated, but it
             MUST default to checksumming on.

             If a UDP datagram is received with a checksum that is non-
             zero and invalid, UDP MUST silently discard the datagram.
             An application MAY optionally be able to control whether UDP
             datagrams without checksums should be discarded or passed to
             the application.

The "application" here is VXLAN. So you can say that VXLAN SHOULD set 
the UDP checksum to zero, but you cannot say that it MUST (because 
app-layer control is a MAY).

When receiving nonzero invalid checksums, you cannot say that VLXAN will 
process those packets, because UDP MUST silently discard them.

When receiving zero checksums, you cannot say that VXLAN MUST NOT see 
them, because app-layer control of discard is optional.


I think your objection may be that you don't think we can assume that 
zero-checksum packets arrive at VXLAN, because of how RFC1122 is worded. 
However, RFC768 permits zero-checksum packets as valid and useful to the 
upper layer, so I interpret RFC 1122 as saying "the app might be able to 
configure UDP to discard zero-checksum packets", but if it doesn't, 
those packets already will end up at the application.