Re: Thought on IPv6 Zero UDP Checksums

"Joel M. Halpern" <jmh@joelhalpern.com> Mon, 09 November 2009 09:14 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47ADD3A6B10 for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 01:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.438
X-Spam-Level:
X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQIT9A3GjaCI for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 01:14:58 -0800 (PST)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5EC673A689F for <ipv6@ietf.org>; Mon, 9 Nov 2009 01:14:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id C81AB43A901; Mon, 9 Nov 2009 01:15:24 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [133.93.18.245] (host-18-245.meeting.ietf.org [133.93.18.245]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 449E343A900; Mon, 9 Nov 2009 01:15:24 -0800 (PST)
Message-ID: <4AF7DDAB.9050509@joelhalpern.com>
Date: Mon, 09 Nov 2009 04:15:23 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk
Subject: Re: Thought on IPv6 Zero UDP Checksums
References: <57B1DE18-848C-4F23-BA6B-EEFDB7692F8B@sandstorm.net> <4AF7B7E1.1070501@erg.abdn.ac.uk>
In-Reply-To: <4AF7B7E1.1070501@erg.abdn.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org Mailing List" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2009 09:14:59 -0000

(Sorry, I will not be able to participate in the 6man discussion at the 
meeting, as I have to be in another session.)

It appears likely that it is impossible to meet all of the relevant 
constraints.  But less us not pretend that solutions likely this are 
obviously sufficient.

One of the major drivers of the UDP checksum question is tunnel 
protocols where the tunneling is being handled by high end routers with 
large volumes of traffic.
1) Many of such routers are designed such that it is difficult, 
expensive, or sometimes even impossible to calculate a per-byte checksum 
across the entire encapsualted packet when encapsuatling a packet for 
tunneling.
2) When there is high volume, it is clearly desirable that the resulting 
packets be able to be load balanced using the existing Internet core 
hardware to spread packets across equal cost paths of link groups, while 
keeping individual packet streams to single paths.  Currently, this is 
support for UDP and TCP packets, but not for SCTP or UDP-Lite. 
(Effective traffic distribution across link groups is very important in 
real deployments.)
2') There is an argument that the right way to handle this balancing for 
IPv6 would be to use the flow label.  But that is not the current 
practice in either the use of the label field or the implementation of 
the balancing logic.

I understand that there is a reasonable concern that if such tunnel 
packets are redirected due to packet corruption they may get sent to 
devices which do not understand what is happening, and may be 
potentially confused if we allow the non-use of UDP checksums.
If that is indeed the primary problem, then solutions like negotiation 
are addressing secondary issues. (Of course, not everyone may agree as 
to what the "primary" problem is.)

Yours,
Joel M. Halpern

Gorry Fairhurst wrote:
> Using UDP-Lite would be fine. I'm not sure how a transition to UDP with 
> no checksum would help the transport concerns with mis-delivery, etc.
> 
> Gorry
> 
> 
> Margaret Wasserman wrote:
>>
>> I had a thought on the use of zero UDP checksums in IPv6...
>>
>> What if we allowed the use of zero checksums for UDP as a _negotiated 
>> option_ in IETF tunneling protocols?  Those protocols could default to 
>> the use of UDP Lite (or UDP with non-zero checksums if their designers 
>> prefer) and negotiate the use of Zero UDP checksums when both sides 
>> support it.
>>
>> Margaret
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>