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
- RE: New Version Notification for draft-bonica-6ma… Usman Latif
- Re: New Version Notification for draft-bonica-6ma… Mark Andrews
- RE: New Version Notification for draft-bonica-6ma… Templin, Fred L
- Re: New Version Notification for draft-bonica-6ma… Ray Hunter
- RE: FW: New Version Notification for draft-bonica… Ronald Bonica