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

Behcet Sarikaya <> Wed, 30 April 2014 19:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7553A1A099B; Wed, 30 Apr 2014 12:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GmVcEdXJFp_F; Wed, 30 Apr 2014 12:46:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22c]) by (Postfix) with ESMTP id 584A21A097C; Wed, 30 Apr 2014 12:46:50 -0700 (PDT)
Received: by with SMTP id hr17so1614198lab.31 for <multiple recipients>; Wed, 30 Apr 2014 12:46:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=m8xM+daoLLmDandhwEroLzGZH43/Kc+u3Hoj1SFJRPA=; b=ebMC0wQwopDLq1A0OlcwossTdvqJHBPRFFfL5a/2UXI6sMiwpJqP+B3vHd+wKGjY86 ntpUFzA6EyX6N0pJzTkltKDVT1/4qJ/WgAyoWPLVA7P6ZH0t1LaNcT/5UL8JO+0AwGjL q2EHnCbO4n9VwDdaruiCFQU3++fqvXNZXOEX7WV98H1L0qEspQE3Uc7laOBRjRkLL/CC BVrauAPembQ3DI7GYXRcE7w1tFQ7bcA6YEzh2xPXqTdXAlFQN/EtDCFGfs+xhzacz0nM HlfS0rWdl3uyEBfQqXGeE/Mm2YguWS7hBCd1aD6QGpEZV4boqzxny368U7aONU61iKRj 3rCA==
MIME-Version: 1.0
X-Received: by with SMTP id li8mr2488810lab.45.1398887208075; Wed, 30 Apr 2014 12:46:48 -0700 (PDT)
Received: by with HTTP; Wed, 30 Apr 2014 12:46:48 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 30 Apr 2014 14:46:48 -0500
Message-ID: <>
From: Behcet Sarikaya <>
To: Tom Herbert <>
Content-Type: multipart/alternative; boundary=089e01176b3b1e48fa04f847cf77
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: Wed, 30 Apr 2014 19:46:52 -0000

This is what VXLAN draft says:

The UDP checksum field SHOULD be transmitted as zero.  When a packet
   is received with a UDP checksum of zero, it MUST be accepted for
   decapsulation.  Optionally, if the encapsulating endpoint includes a
   non-zero UDP checksum, it MUST be correctly calculated across the
   entire packet including the IP header, UDP header, VXLAN header and
   encapsulated MAC frame.  When a decapsulating endpoint receives a
   packet with a non-zero checksum it MAY choose to verify the checksum

value.  If it chooses to perform such verification, and the
   verification fails, the packet MUST be dropped.  If the
   decapsulating destination chooses not to perform the verification,
   or performs it successfully, the packet MUST be accepted for

What is wrong with it?


On Wed, Apr 30, 2014 at 2:01 PM, Tom Herbert <> wrote:

> Hi,
> I noticed that the VXLAN draft allows an implementation to potentially
> ignore a non-zero invalid UDP checksum.
> From:
> "When a decapsulating endpoint receives a packet with a non-zero
> checksum it MAY choose to verify the checksum"
> However, from RFC 1122:
> "If a UDP datagram is received with a checksum that is non-zero and
> invalid, UDP MUST silently discard the datagram."
> It doesn't seem like 1122 allows checksum verification to be optional,
> so these would seem to be a conflict. Presumably, ignoring the RX csum
> is included for performance but since the sender can already send zero
> checksums in UDP (they are optional in IPv4 and allowed for IPv6
> tunnels in RFC 6935) I'm not sure this is necessary. Besides that, the
> UDP checksum is potentially the only thing that protection of the vni
> against corruption end to end so allowing a receiver to ignore a bad
> checksum seems very risky.
> As a comparison, RFC 3931 (L2TP) has the following wording:
> "Thus, UDP checksums MAY be disabled in order to reduce the associated
> packet processing burden at the L2TP endpoints."
> This is somewhat ambiguous, but seems like the correct interpretation
> should be that zero checksums may be sent with L2TP/UDP, but on
> receive non-zero checksums should still be validated.
> Are these interpretations correct? Is there there a need to clarify
> the requirement for UDP tunnel protocols and checksums?
> Thanks,
> Tom
> _______________________________________________
> Tofoo mailing list