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

[Usman Latif <[e-mail]>]

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
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, [e-mail] 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
>    [e-mail]
> 
> 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
>    [e-mail]
> 
> You can reach the person managing the list at
>    [e-mail]
> 
> 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 <[e-mail]>
> To: George Michaelson <[e-mail]>, "[e-mail] 6man-wg"
>    <[e-mail]>
> Subject: RE: New Version Notification for
>    draft-bonica-6man-frag-deprecate-00.txt
> Message-ID:
>    <[e-mail]>
>    
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> I'd like to understand the basis of these assertions. I believe what I am seeing, on the edge, suggests there is in fact V6 fragmentation in both TCP and 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/2d588547/attachment.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 24 Jun 2013 16:50:04 +0000
> From: "Fred Baker (fred)" <[e-mail]>
> To: Tore Anderson <[e-mail]>
> Cc: "[e-mail] 6man-wg" <[e-mail]>
> Subject: Re: New Version Notification for
>    draft-bonica-6man-frag-deprecate-00.txt
> Message-ID:
>    <[e-mail]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> 
> On Jun 24, 2013, at 12:45 AM, Tore Anderson <[e-mail]> wrote:
> 
>> * Fred Baker (fred)
>> 
>>> On Jun 22, 2013, at 2:29 AM, Tore Anderson <[e-mail]> 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 <[e-mail]>
> To: Sheng Jiang <[e-mail]>
> Cc: "[e-mail] 6man-wg" <[e-mail]>,    "Fred Baker \(fred\)"
>    <[e-mail]>
> Subject: Re: New Version Notification for
>    draft-bonica-6man-frag-deprecate-00.txt
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=us-ascii
> 
>>> I suppose I'm the contrarian
>> 
>> +1. For me, this draft looks dangerous by proposing to deprecate fragmentation 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 may 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 other 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" <[e-mail]>
> To: "Fred Baker (fred)" <[e-mail]>, Tore Anderson <[e-mail]>
> Cc: "[e-mail] 6man-wg" <[e-mail]>
> Subject: RE: New Version Notification for
>    draft-bonica-6man-frag-deprecate-00.txt
> Message-ID:
>    <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
> 
> Hi Fred,
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Fred Baker (fred)
>> Sent: Sunday, June 23, 2013 4:12 PM
>> To: Tore Anderson
>> Cc: [e-mail] 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 <[e-mail]> 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
> [e-mail]
> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> 
> ------------------------------
> 
> _______________________________________________
> ipv6 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipv6
> 
> 
> End of ipv6 Digest, Vol 110, Issue 75
> *************************************