Re: draft-bonica-6man-frag-deprecate

Hagen Paul Pfeifer <hagen@jauu.net> Thu, 27 June 2013 05:52 UTC

Return-Path: <hagen@jauu.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 A650321F9C1D for <ipv6@ietfa.amsl.com>; Wed, 26 Jun 2013 22:52:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 x5AHD4f5x-cO for <ipv6@ietfa.amsl.com>; Wed, 26 Jun 2013 22:52:46 -0700 (PDT)
Received: from Chamillionaire.breakpoint.cc (Chamillionaire.breakpoint.cc [IPv6:2001:4d88:1ffa:82:880:aa0:9009:64ae]) by ietfa.amsl.com (Postfix) with ESMTP id 1772F21F9BF3 for <ipv6@ietf.org>; Wed, 26 Jun 2013 22:52:45 -0700 (PDT)
Received: from pfeifer by Chamillionaire.breakpoint.cc with local (Exim 4.72) (envelope-from <hagen@jauu.net>) id 1Us58M-0006nZ-Rj; Thu, 27 Jun 2013 07:52:43 +0200
Date: Thu, 27 Jun 2013 07:52:41 +0200
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: draft-bonica-6man-frag-deprecate
Message-ID: <20130627055241.GA3358@virgo.local>
References: <20130624204008.GB3647@virgo.local> <20130624205226.GC3647@virgo.local> <2CF4CB03E2AA464BA0982EC92A02CE2509F8761C@BY2PRD0512MB653.namprd05.prod.outlook.com> <51C902DC.9000408@gmail.com> <m24ncmaozs.wl%randy@psg.com> <2EA20F89-02F5-4D06-90EE-A7D2974045A3@employees.org> <m2li5yj7u3.wl%randy@psg.com> <8C48B86A895913448548E6D15DA7553B9268E3@xmb-rcd-x09.cisco.com> <m2ehbpij86.wl%randy@psg.com> <51CB91E4.5090603@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <51CB91E4.5090603@gmail.com>
X-Key-Id: 98350C22
X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: 6man <ipv6@ietf.org>
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: Thu, 27 Jun 2013 05:52:46 -0000

* Brian E Carpenter | 2013-06-27 13:14:12 [+1200]:

>Cutting to the chase, and assuming that the next version
>will have more analysis and observational evidence, I'm thinking
>something like the following:

Nearly, skip five words: "and the IPv6 fragment header". One more time: a
client of mine deploy sensor network applications using fragmentation. Not
just for fun, no because of 2460. Think about this: if this ID becomes an RFC
(or even earlier) someone posts a patch removing fragmentation from
Linux/*BSD,3 month later all distribution ship a fragmentation/reassembly less
stack. This breaks application, application which cannot changed because they
are hard wired into silicon (DSP). This incompatible protocol break needs more
time to mature out everywhere.

I support the deprecation of fragmentation, but we need reassembling for a
transition period - not fragmentation. But this is not in contradiction with
the current effort here - everybody can be happy. My recommendation (slightly
changed version, see second sentence):

3.  Recommendation

	 This memo deprecates IPv6 fragmentation. Host SHOULD still be able to
	 reassembly fragmented packets.  Application and transport layer protocols
	 SHOULD support effective PMTU discovery [RFC4821], since ICMP-based PMTU
	 discovery [RFC1981] is unreliable. Any application or transport layer
	 protocol that cannot support effective PMTU discovery MUST NOT in any
	 circumstances send IPv6 packets that exceed the IPv6 minimum MTU of 1280
	 bytes.

   IPv6 stacks and forwarding nodes SHOULD continue to support inbound
   fragmented IPv6 packets as specified in [RFC2460]. However, this
   requirement exceeds the capability of some types of forwarding node
   such as firewalls and load balancers. Therefore implementers and
   operators need to be aware that on many paths through the Internet,
   IPv6 fragmentation will fail. Legacy applications and transport layer
   protocols that do not conform to the previous paragraph can expect
   connectivity failures as a result.



Hagen