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

Mark Andrews <marka@isc.org> Wed, 26 June 2013 01:49 UTC

Return-Path: <marka@isc.org>
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 7316D21E8100 for <ipv6@ietfa.amsl.com>; Tue, 25 Jun 2013 18:49:10 -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 RZllOjGL3wDS for <ipv6@ietfa.amsl.com>; Tue, 25 Jun 2013 18:49:06 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FA21E810A for <ipv6@ietf.org>; Tue, 25 Jun 2013 18:49:02 -0700 (PDT)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id A11A6C9478; Wed, 26 Jun 2013 01:48:51 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1372211342; bh=9swPsSpTtAdjai5RbHAjqjvB/CXb+6M3eGUBL29dtpQ=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=vErHZsVuQDLk0+KtccuFFZumcULpbpmPsmGk2+CoCOOXnnQNqTSOoPyLGpiQ+Zre2 fOA7q3giGXGxWhtjmIUoANSOSQh5aGKP7+DampznLzdQtoEBLE3mW2NQRg4L4W5Jyw 6IiyiS7hOfR78uP9gGkQ8sk479P10iTEIyofxZWE=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 26 Jun 2013 01:48:51 +0000 (UTC) (envelope-from marka@isc.org)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CD64416005A; Wed, 26 Jun 2013 01:50:01 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fIgLNIIdG9nO; Wed, 26 Jun 2013 01:49:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 0DDF416008E; Wed, 26 Jun 2013 01:49:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at zmx1.isc.org
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jl7dyd6_3y-r; Wed, 26 Jun 2013 01:49:55 +0000 (UTC)
Received: from drugs.dv.isc.org (c211-30-172-21.carlnfd1.nsw.optusnet.com.au [211.30.172.21]) by zmx1.isc.org (Postfix) with ESMTPSA id 4693816008D; Wed, 26 Jun 2013 01:49:55 +0000 (UTC)
Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id AC55536439B3; Wed, 26 Jun 2013 11:48:41 +1000 (EST)
To: Usman Latif <osmankh@yahoo.com>
From: Mark Andrews <marka@isc.org>
References: <mailman.41.1372100409.29039.ipv6@ietf.org> <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com>
Subject: Re: New Version Notification for draft-bonica-6man-frag-deprecate-00.txt
In-reply-to: Your message of "Wed, 26 Jun 2013 11:06:45 +1000." <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com>
Date: Wed, 26 Jun 2013 11:48:41 +1000
Message-Id: <20130626014841.AC55536439B3@drugs.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: "ipv6@ietf.org" <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: Wed, 26 Jun 2013 01:49:10 -0000

In message <0F21D0E7-B884-4CC1-B808-E0C6447516B1@yahoo.com>, Usman Latif writes
:
> I have the following suggestion:
> 
> IPv6 hosts can try to gain knowledge of the path MTU to a destination. If the
>  path blocks or filters PMTUD etc, then the host should revert to 1280 bytes 
> else the hosts can use a higher packet size. 
> This mechanism would make Fragment header redundant anyway

No, it doesn't.

> The only implication of the above mechanism would be that network providers '
> must' support 1280 byte IPv6 packets in all situations
> 
> 
> Regards,
> Usman
> 
> 
> On 25/06/2013, at 5:00 AM, ipv6-request@ietf.org wrote:
> 
> > If you have received this digest without all the individual message
> > attachments you will need to update your digest options in your list
> > subscription.  To do so, go to 
> > 
> > https://www.ietf.org/mailman/listinfo/ipv6
> > 
> > Click the 'Unsubscribe or edit options' button, log in, and set "Get
> > MIME or Plain Text Digests?" to MIME.  You can set this option
> > globally for all the list digests you receive at this point.
> > 
> > 
> > 
> > Send ipv6 mailing list submissions to
> >    ipv6@ietf.org
> > 
> > To subscribe or unsubscribe via the World Wide Web, visit
> >    https://www.ietf.org/mailman/listinfo/ipv6
> > or, via email, send a message with subject or body 'help' to
> >    ipv6-request@ietf.org
> > 
> > You can reach the person managing the list at
> >    ipv6-owner@ietf.org
> > 
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of ipv6 digest..."
> > 
> > 
> > Today's Topics:
> > 
> >   1. RE: New Version Notification for
> >      draft-bonica-6man-frag-deprecate-00.txt (Ronald Bonica)
> >   2. Re: New Version Notification for
> >      draft-bonica-6man-frag-deprecate-00.txt (Fred Baker (fred))
> >   3. Re: New Version Notification for
> >      draft-bonica-6man-frag-deprecate-00.txt (Ole Troan)
> >   4. RE: New Version Notification for
> >      draft-bonica-6man-frag-deprecate-00.txt (Templin, Fred L)
> > 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Mon, 24 Jun 2013 16:38:06 +0000
> > From: Ronald Bonica <rbonica@juniper.net>
> > To: George Michaelson <ggm@algebras.org>, "ipv6@ietf.org 6man-wg"
> >    <ipv6@ietf.org>
> > Subject: RE: New Version Notification for
> >    draft-bonica-6man-frag-deprecate-00.txt
> > Message-ID:
> >    <2CF4CB03E2AA464BA0982EC92A02CE2509F870FC@BY2PRD0512MB653.namprd05.prod.
> outlook.com>
> >    
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > 
> > I'd like to understand the basis of these assertions. I believe what I am s
> eeing, on the edge, suggests there is in fact V6 fragmentation in both TCP an
> d UDP.
> > 
> > 
> > Hi George,
> > 
> > It would be helpful if you could describe:
> > 
> > 
> > -          Where your observations are being made
> > 
> > -          What percentage of traffic is fragmented
> > 
> > -          What kinds of packets are being fragmented
> >                                                Ron
> > 
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL: <http://www.ietf.org/mail-archive/web/ipv6/attachments/20130624/2d5885
> 47/attachment.htm>
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Mon, 24 Jun 2013 16:50:04 +0000
> > From: "Fred Baker (fred)" <fred@cisco.com>
> > To: Tore Anderson <tore@fud.no>
> > Cc: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>
> > Subject: Re: New Version Notification for
> >    draft-bonica-6man-frag-deprecate-00.txt
> > Message-ID:
> >    <8C48B86A895913448548E6D15DA7553B924440@xmb-rcd-x09.cisco.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> > 
> > 
> > On Jun 24, 2013, at 12:45 AM, Tore Anderson <tore@fud.no> wrote:
> > 
> >> * Fred Baker (fred)
> >> 
> >>> On Jun 22, 2013, at 2:29 AM, Tore Anderson <tore@fud.no> wrote:
> >>>> - When a SIIT translator receives an IPv4 packet with DF=0 that
> >>>> would result in an IPv6 packet that would exceed the IPv6 link MTU,
> >>>> it will split the original packet into IPv6 fragments.
> >>> 
> >>> It *could* fragment the IPv4 packet and send it in two unfragmented
> >>> IPv6 packets.
> >> 
> >> Wouldn't doing IPv4 fragmentation before translation to IPv6 be
> >> logically identical to this other case I mentioned?
> > 
> > Ah. You're correct. I was thinking about tunnels.
> > 
> >>>> - When a SIIT translator receives an IPv4 fragment, it will translate
> >>>> this into one or more IPv6 fragments.
> >> 
> >> I can't see how simply omitting the Fragmentation header in the IPv6
> >> output could work here, as the node receiving those two unfragmented
> >> IPv6 packets would see the first one containing a truncated L4 payload,
> >> while the second one would be just garbage as it doesn't include a L4
> >> header.
> >> 
> >> Tore
> > 
> > -----------------------------------
> > "We are learning to do a great many clever things...The next great task
> > will be to learn not to do them."
> > 
> > - G. K. Chesterton (1874-1936)
> > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 3
> > Date: Mon, 24 Jun 2013 13:37:41 -0400
> > From: Ole Troan <otroan@employees.org>
> > To: Sheng Jiang <jiangsheng@huawei.com>
> > Cc: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>,    "Fred Baker \(fred\)"
> >    <fred@cisco.com>
> > Subject: Re: New Version Notification for
> >    draft-bonica-6man-frag-deprecate-00.txt
> > Message-ID: <34E0F96D-5CCB-4275-AF64-E451B00369E0@employees.org>
> > Content-Type: text/plain; charset=us-ascii
> > 
> >>> I suppose I'm the contrarian
> >> 
> >> +1. For me, this draft looks dangerous by proposing to deprecate fragmenta
> tion with only one-side observation. This draft does not give enough analysis
>  on these existing fragmentation use cases, particularly these use cases the 
> fragments within a single domain.
> >> 
> >> On other side , only disallowing fragmentation to be used among domains ma
> y helpful to reduce the operational complex.
> > 
> > this draft should help us tease out answers to the question:
> > "if we wanted to deprecate IPv6 fragmentation, could we?"
> > 
> > then when we know the collateral damage, it will be easier to answer the ot
> her question:
> > "should we deprecate IP layer fragmentation or not".
> > 
> > cheers,
> > Ole
> > 
> > ------------------------------
> > 
> > Message: 4
> > Date: Mon, 24 Jun 2013 17:50:36 +0000
> > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
> > To: "Fred Baker (fred)" <fred@cisco.com>, Tore Anderson <tore@fud.no>
> > Cc: "ipv6@ietf.org 6man-wg" <ipv6@ietf.org>
> > Subject: RE: New Version Notification for
> >    draft-bonica-6man-frag-deprecate-00.txt
> > Message-ID:
> >    <2134F8430051B64F815C691A62D983180A93A6@XCH-BLV-504.nw.nos.boeing.com>
> > Content-Type: text/plain; charset="us-ascii"
> > 
> > Hi Fred,
> > 
> >> -----Original Message-----
> >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> >> Fred Baker (fred)
> >> Sent: Sunday, June 23, 2013 4:12 PM
> >> To: Tore Anderson
> >> Cc: ipv6@ietf.org 6man-wg
> >> Subject: Re: New Version Notification for draft-bonica-6man-frag-
> >> deprecate-00.txt
> >> 
> >> 
> >> On Jun 22, 2013, at 2:29 AM, Tore Anderson <tore@fud.no> wrote:
> >>> - When a SIIT translator receives an IPv4 packet with DF=0 that would
> >>> result in an IPv6 packet that would exceed the IPv6 link MTU, it will
> >>> split the original packet into IPv6 fragments.
> >> 
> >> It *could* fragment the IPv4 packet and send it in two unfragmented
> >> IPv6 packets.
> >> 
> >>> I cannot support your draft until it discusses or provides solutions
> >> for
> >>> the above considerations.
> >> 
> >> I'm in a similar case with respect to protocols above IPv6 (OSPF and
> >> NFS/UDP come quickly to mind) that depend on fragmentation to deal with
> >> the issue. I think the Robustness Principle tells us that such
> >> applications SHOULD figure out how to live with PMTU, but it also tells
> >> us that we can't deprecate fragmentation unless all known instances
> >> that depend on it have defined practical work-arounds. I suspect that
> >> this would imply the re-creation of the fragmentation feature in an
> >> intermediate protocol,
> > 
> > That is essentially what SEAL does - it provides an intermediate-level
> > segmentation and reassembly capability that avoids the pitfalls of IP
> > fragmentation.
> > 
> >> which seems like a lot of work with little real gain.
> > 
> > It's not that bad, and IMHO worth it.
> > 
> > Thanks - Fred
> > fred.l.templin@boeing.com
> > 
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > 
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > ipv6 mailing list
> > ipv6@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipv6
> > 
> > 
> > End of ipv6 Digest, Vol 110, Issue 75
> > *************************************
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org