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

[Joe Touch <[e-mail]>]

> On Mar 7, 2018, at 7:39 AM, Ron Bonica <[e-mail]> 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:[e-mail]]
>> Sent: Tuesday, March 6, 2018 9:57 PM
>> To: Ole Troan <[e-mail]>
>> Cc: Tom Herbert <[e-mail]>; Ron Bonica
>> <[e-mail]>; [e-mail]
>> Subject: Re: [Int-area] draft-bonica-intarea-frag-fragile-01
>> 
>> 
>> 
>>> On Mar 6, 2018, at 11:16 AM, Ole Troan <[e-mail]> 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