On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont <[email protected]> wrote: > > On 4/9/19 18:26, Templin (US), Fred L wrote: > > Hi Ole, > > > >> -----Original Message----- > >> From: Ole Troan [mailto:[email protected]] > >> Sent: Wednesday, September 04, 2019 7:37 AM > >> To: Templin (US), Fred L <[email protected]> > >> Cc: Bob Hinden <[email protected]>; Tom Herbert <[email protected]>; > >> Joel Halpern <[email protected]>; draft- > >> [email protected]; [email protected] > >> Subject: Re: [Int-area] Alissa Cooper's No Objection on > >> draft-ietf-intarea-frag-fragile-16: (with COMMENT) > >> > >> Fred, > >> > >> I removed the IESG from this list, as we seem to have drifted into a more > >> general fragmentation discussion as opposed to discussing > >> the exact changes to this draft. > >> > >>>>>> Why is that more useful than what is in 3.5? If it’s not making a > >>>>>> recommendation, why call this out in the introduction. There are > >> lot > >>>> of > >>>>>> other things it doesn’t make recommendations about that aren’t in the > >>>>>> Introduction either. > >>>>> > >>>>> Because it sets a more appropriate tone and lets the reader know from > >>>>> the onset that > >>>>> fragmentation and encapsulation go hand in hand. And tunnel > >>>>> fragmentation avoids the > >>>>> issues raised by others in this thread. > >>>> > >>>> While inner fragmentation ensures the fragment will reach the tunnel > >>>> tail end, a tunnel endpoint will typically not reassemble that > >>>> fragment, so will generate fragments after the tunnel hop. > >>>> Inner fragmentation is only available on IPv4. > >>> > >>> Not true. For IPv6 packets, simply insert a GUE header or an RFC2473 > >>> header and > >>> fragment on that. The fragments will be reassembled by the tunnel tail > >>> end, then > >>> passed to the next hop as a whole IPv6 packet. The fragmentation > >>> footprint is > >>> therefore the same as the tunnel footprint. > >> > >> Is that not the exact definition of outer fragmentation? > > > > No. I am talking about outer header (OH) followed by tunnel header (TH) > > followed > > by inner packet (IP). Recipe: > > > > 1) wrap the IP in a TH to create a tunnel packet (TP) > > 2) fragment the TP > > 3) encapsulate each tunnel fragment in an independent OH > > 4) send each outer packet (OP). These will look like ordinary > > unfragmented IP packets, but will contain a tunnel fragment > > This looks like a recent claim from the IAB that QUIC has shown that it > is possible to deploy new transport protocols on the Internet. -- when > quick employs UDP, and hence from the pov of the Internet, UDP is the > transport protocol. > > Same with your example: you are tunneling your fragments. The Internet > will not see fragments. *That* is why it would work. > > i.e., if you want fragmentation to not be fragile on the Internet, the > trick is that packets shouldn't look like fragmens ;-) > Fernando,
Sure, if we dress up protocols in UDP there is a greater probability they can traverse the Internet. But this doesn't always work and it's fallacious to think that unbiquitously solves the problem of protocol ossification. I really wish the IAB would look at the issues of wide spread middlebox non-conformance-- this is the root problem and a fundamental deterrent to evolving the Internet IMO. Tom > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
