Also IMO the lack of frag support should be called out as a bug, not merely acknowledged or (worse) commended. Reassembly by middle boxes should be called out as well - or by any DPI (or the equivalent, I e by reassembling a copy used for frag processing context.)
Joe > On Mar 7, 2018, at 8:52 AM, Joe Touch <to...@strayalpha.com> wrote: > > > >> 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
