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 > -------------------------------------------------------------------- >
- Thought on IPv6 Zero UDP Checksums Margaret Wasserman
- Re: Thought on IPv6 Zero UDP Checksums Gorry Fairhurst
- Re: Thought on IPv6 Zero UDP Checksums Joel M. Halpern