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

Ray Hunter <v6ops@globis.net> Sat, 29 June 2013 06:13 UTC

Return-Path: <v6ops@globis.net>
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 552B221F9E43 for <ipv6@ietfa.amsl.com>; Fri, 28 Jun 2013 23:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 sl3Ikt2quBfX for <ipv6@ietfa.amsl.com>; Fri, 28 Jun 2013 23:13:00 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFD3821F9E16 for <ipv6@ietf.org>; Fri, 28 Jun 2013 23:13:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id DAE8787006B for <ipv6@ietf.org>; Sat, 29 Jun 2013 08:12:44 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl6EClMhkdd6 for <ipv6@ietf.org>; Sat, 29 Jun 2013 08:12:44 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id B6905870047 for <ipv6@ietf.org>; Sat, 29 Jun 2013 08:12:44 +0200 (CEST)
Message-ID: <51CE7AD6.1040908@globis.net>
Date: Sat, 29 Jun 2013 08:12:38 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: 6man Mailing List <ipv6@ietf.org>
Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
Content-Type: text/plain; charset="UTF-8"
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: Sat, 29 Jun 2013 06:13:01 -0000

With all this talk of 1280 as the minimum *link* MTU, I think it's easy
to forget that 2460 states:

>   A node must be able to accept a fragmented packet that, after
>   reassembly, is as large as 1500 octets.  A node is permitted to
>  accept fragmented packets that reassemble to more than 1500 octets.
>   An upper-layer protocol or application that depends on IPv6
>   fragmentation to send packets larger than the MTU of a path should
>   not send packets larger than 1500 octets unless it has assurance that
>   the destination is capable of reassembling packets of that larger
>   size.

So there was a very clear expectation that the *application level API*
could always rely on being able to transmit as much data as it wanted as
long as it didn't exceed a *1500* octet packet, and that this would
always be reliably transmitted end to end. Anyone not transmitting this
data across their network is currently ignoring a must in 2460.

We should not forget the effect that changing such an important API
parameter will have. I think Brian Carpenter has certainly got that in
his suggestion.

But perhaps some additional limits on the sanity of fragments might
allow us to maintain a minimum 1500 octet limit at the API level, whilst
allowing middleware boxes to process them correctly? [ I do realise that
(nested) tunnels will always be problematic, no matter where you set any
MTU limit, but that's nothing new and we have ways of dealing with that]

regards,
RayH