Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt

Doug Barton <dougb@dougbarton.us> Mon, 24 June 2013 01:53 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D3721E8085 for <ipv6@ietfa.amsl.com>; Sun, 23 Jun 2013 18:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0ZgmNvmy7UG for <ipv6@ietfa.amsl.com>; Sun, 23 Jun 2013 18:53:43 -0700 (PDT)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34F21E8083 for <ipv6@ietf.org>; Sun, 23 Jun 2013 18:53:43 -0700 (PDT)
Received: from [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b] (unknown [IPv6:2001:470:d:5e7:224:e8ff:fe30:109b]) by dougbarton.us (Postfix) with ESMTPSA id A49CE22B0F for <ipv6@ietf.org>; Mon, 24 Jun 2013 01:53:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dougbarton.us; t=1372038819; bh=Z201fLaiAnKWcQR2CXdImOMTdMEeeQHy8WOhmIU4hXM=; h=Date:From:To:Subject:References:In-Reply-To; b=QVe39L/LKtQ3O5o8MYOEVspy7Wuw04D8g7xK5X2/RBqT3b+kuyWjvBsS61QYabRBz lPG4Tsre9bjy12WyFEoEYvkjZVkhqeB2uxvXaygM+XlbBNqVBl0Py7KU7E+YhRfW6I IbMBGLcNVneOStk9jjujRbZci11OpY8Hs0sqUccs=
Message-ID: <51C7A69F.40400@dougbarton.us>
Date: Sun, 23 Jun 2013 18:53:35 -0700
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: FW: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
References: <2CF4CB03E2AA464BA0982EC92A02CE2509F85151@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C408BC.4030909@forthnetgroup.gr> <2CF4CB03E2AA464BA0982EC92A02CE2509F85BCB@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C48776.9070107@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F85FBA@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4AD03.2050303@globis.net> <2CF4CB03E2AA464BA0982EC92A02CE2509F86075@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C4BD1E.6030002@gmail.com>
In-Reply-To: <51C4BD1E.6030002@gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 24 Jun 2013 01:53:44 -0000

On 06/21/2013 01:52 PM, Brian E Carpenter wrote:
> On 22/06/2013 07:53, Ronald Bonica wrote:
>>> I don't 100% agree. In the case that PMTUD is broken, there'd be
>>> nothing to stop a current DNSSEC implementation from always assuming a
>>> default path MTU of 1280, without awaiting confirmation from PMTUD, and
>>> fragmenting the UDP packet pre-emptively [assuming fragmentation was
>>> not equally broken along the path as ICMP PTB was].
>>>
>>
>> Do any implementations actually do this?
>>
>> If they do, how well are they working, today?
>
> Does it matter? Since we know that fragmentation is broken on some
> paths due to broken firewalls, and that other paths have tunnels
> on them, and that MSS negotiation fails on some paths, today's
> sad reality is that the only safe link MTU for all times and places
> is 1280.
>
> I'm not yet convinced that deprecating fragmentation is sufficient
> to fix this problem. In this case, not being sufficient might
> also mean not necessary, so I'd like to see much more thorough
> analysis across the IETF as a whole before reaching a conclusion.
>
> (Thanks to the authors for coming out and saying it, though.)

Given that larger and faster pipes are becoming more common, and given 
that we know that larger packet sizes make for more efficient 
utilization of those pipes, IMO it's a really bad idea to "give up the 
fight" at this early stage in IPv6 deployment.

Until there is dramatic evidence to the contrary it seems to me that 
it's still worthwhile to push for making the protocol work as designed.

Doug