Re: [Int-area] draft-bonica-intarea-frag-fragile-01

Joe,

About middle-box reassembly,  it should probably also mention Virtual Fragment
Reassembly where the middlebox gathers fragments but does not reassemble
them. 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-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Wednesday, March 07, 2018 8:52 AM
> To: Ron Bonica <rbonica@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 <rbonica@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:touch@strayalpha.com]
> >> Sent: Tuesday, March 6, 2018 9:57 PM
> >> To: Ole Troan <otroan@employees.org>
> >> Cc: Tom Herbert <tom@herbertland.com>; Ron Bonica
> >> <rbonica@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 <otroan@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