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, [email protected] 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 > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: George Michaelson <[email protected]>, "[email protected] 6man-wg" > <[email protected]> > Subject: RE: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: > > <2cf4cb03e2aa464ba0982ec92a02ce2509f87...@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 > 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)" <[email protected]> > To: Tore Anderson <[email protected]> > Cc: "[email protected] 6man-wg" <[email protected]> > Subject: Re: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > On Jun 24, 2013, at 12:45 AM, Tore Anderson <[email protected]> wrote: > >> * Fred Baker (fred) >> >>> On Jun 22, 2013, at 2:29 AM, Tore Anderson <[email protected]> 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 <[email protected]> > To: Sheng Jiang <[email protected]> > Cc: "[email protected] 6man-wg" <[email protected]>, "Fred Baker \(fred\)" > <[email protected]> > Subject: Re: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: <[email protected]> > 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" <[email protected]> > To: "Fred Baker (fred)" <[email protected]>, Tore Anderson <[email protected]> > Cc: "[email protected] 6man-wg" <[email protected]> > Subject: RE: New Version Notification for > draft-bonica-6man-frag-deprecate-00.txt > Message-ID: > <2134f8430051b64f815c691a62d983180a9...@xch-blv-504.nw.nos.boeing.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Fred, > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Fred Baker (fred) >> Sent: Sunday, June 23, 2013 4:12 PM >> To: Tore Anderson >> Cc: [email protected] 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 <[email protected]> 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 > [email protected] > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > ------------------------------ > > _______________________________________________ > ipv6 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipv6 > > > End of ipv6 Digest, Vol 110, Issue 75 > ************************************* -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
