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

Marc Lampo <marc.lampo.ietf@gmail.com> Thu, 27 June 2013 06:39 UTC

Return-Path: <marc.lampo.ietf@gmail.com>
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 689F421F9C5B for <ipv6@ietfa.amsl.com>; Wed, 26 Jun 2013 23:39:28 -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, HTML_MESSAGE=0.001, 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 V9DtBxkvYxn7 for <ipv6@ietfa.amsl.com>; Wed, 26 Jun 2013 23:39:27 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7613021F9C53 for <ipv6@ietf.org>; Wed, 26 Jun 2013 23:39:27 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id id13so126564vcb.27 for <ipv6@ietf.org>; Wed, 26 Jun 2013 23:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=io7hyNgUSiJDD9MhPTfI2hq4ZAbcyS7KRyi7oxiIO0M=; b=gdHW82N2Dmdfp0QKhAe+7YLCIEyA8P5gIMl3NER4Scnw/0j3Zm7plUXRMFSnC/pDX4 ldpFpQOappSbnagjgNy06ESc08YIIUQXghKwNP2RAJrX5tW0o8Y1MudcbZMaeU68GK+z x9hgMxpxsEarJXKPHlawK2UZD23GrnkHfKjxaP59Rp7E9uo1E7mKP15Vsn+eTqJBNUFW Na+DfGaOpuu7DRhewAAT1NVBl3cRY5fW/lowKj0VnnUGPD/RZZ93t/tWC11GUosK8ZEg m3TeDWeo7nD73hHbx3nrb2trTlvU4wfybh80rXVDAV+uweZB3ZyodkopgkAG1vFHikyw 1ocQ==
MIME-Version: 1.0
X-Received: by 10.58.181.225 with SMTP id dz1mr2972313vec.95.1372315164868; Wed, 26 Jun 2013 23:39:24 -0700 (PDT)
Received: by 10.59.2.100 with HTTP; Wed, 26 Jun 2013 23:39:24 -0700 (PDT)
In-Reply-To: <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> <20130627055241.GA3358@virgo.local>
Date: Thu, 27 Jun 2013 08:39:24 +0200
Message-ID: <CAB0C4xNdr2YxxcNXDrA+HpnneKeWS37F=qW7iJc-iqieYqeS9A@mail.gmail.com>
Subject: Re: draft-bonica-6man-frag-deprecate
From: Marc Lampo <marc.lampo.ietf@gmail.com>
To: Hagen Paul Pfeifer <hagen@jauu.net>
Content-Type: multipart/alternative; boundary="047d7b605020ec079904e01d05ea"
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 06:39:28 -0000

> This incompatible protocol break ...

Incompatible protocol or is it time for the next IP version, without
fragmentation right from the beginning ?


As the reasons, stated in the draft, also apply to IPv4.  Would we think
about deprecating the use of fragmentation fields in the IPv4 header and
recommending they MUST always be set to 0 ?


Kind regards,

Marc Lampo


On Thu, Jun 27, 2013 at 7:52 AM, Hagen Paul Pfeifer <hagen@jauu.net> wrote:

> * 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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>