> On Mar 7, 2018, at 9:13 AM, Templin, Fred L <fred.l.temp...@boeing.com> wrote: > > Joe, > > About middle-box reassembly, it should probably also mention Virtual Fragment > Reassembly where the middlebox gathers fragments but does not reassemble > them.
That’s part of what I was referring to in my other post. Joe > Then, when all fragments have been received the middlebox performs > any transformations then releases the fragments. Several cisco webpages talk > about this. > > Thanks - Fred > >> -----Original Message----- >> From: Int-area [mailto:int-area-boun...@ietf.org] On Behalf Of Joe Touch >> Sent: Wednesday, March 07, 2018 8:52 AM >> To: Ron Bonica <rbon...@juniper.net> >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01 >> >> >> >>> On Mar 7, 2018, at 7:39 AM, Ron Bonica <rbon...@juniper.net> wrote: >>> >>> Joe, >>> >>> Your "Two Truths" are in line with the recommendations in Section 7 of >>> draft-bonica-intarea-frag-fragile-01. The draft recommends >> that upper-layer protocols avoid doing things that cause fragmentation. It >> does not recommend the deprecation of fragmentation. >> >> Understood, but without #2 being included and explicitly co-reinforced there >> is an implication to router designers that I would hope >> can be avoided. >> >> Joe >> >> >>> >>> >>> Ron >>> >>> . >>>> -----Original Message----- >>>> From: Joe Touch [mailto:to...@strayalpha.com] >>>> Sent: Tuesday, March 6, 2018 9:57 PM >>>> To: Ole Troan <otr...@employees.org> >>>> Cc: Tom Herbert <t...@herbertland.com>; Ron Bonica >>>> <rbon...@juniper.net>; int-area@ietf.org >>>> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01 >>>> >>>> >>>> >>>>> On Mar 6, 2018, at 11:16 AM, Ole Troan <otr...@employees.org> wrote: >>>>> >>>>> Joe, >>>>> >>>>>> Agreed but note that draft tunnels will update that RFC in some important >>>> ways. >>>>> >>>>> With other concerns than those raised in e.g. 4459 and 7597? >>>> >>>> draft-tunnels corrects an error in 4459 that deals with the details, not >>>> the >>>> overall recommendation (AFAIR, at least). >>>> >>>>> Unfortunately there are cases where there are no other choice than to do >>>> fragmentation/reassembly on tunnel endpoints, but still the >>>> recommendation holds. >>>>> It is so problematic, that it is strongly recommended to engineer the >>>> network to avoid that happening. >>>> >>>> IMO, there are two truths: >>>> >>>> 1) use of IP fragmentation SHOULD be avoided where possible, largely >>>> because it has reliability issues (ICMP blocking, NATs won’t tunnel frags >>>> and >>>> fail to [as required if they act on transport info] reassemble, etc.) >>>> >>>> 2) support for IP fragmentation MUST remain required, as MUST (IMO) NAT >>>> reassembly before transport rewriting >>>> >>>> Yeah, I know a lot of devices fail the MUSTs in #2, but the requirements >>>> ought to set the goal, not describe the (sorry) current state. >>>> >>>> #2 has to persist until we deprecate IP-in-IP tunneling (including tunnel- >>>> mode IPsec), as well as any IP-in-X*-in-IP for zero or more intermediate >>>> layers X where no layer supports fragmentation and reassembly >>>> >>>> I’ve been working to fix the need for IP frag by developing support for >>>> that in >>>> UDP, but it doesn’t mean we should be ready to outlaw it. >>>> >>>> I’m not sure what this doc does to add to this scene, though - it might be >>>> useful if the authors could explain how it affects 1 and 2 above and what >>>> else >>>> it adds in a *brief* post. >>>> >>>> Joe >> >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
