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

Reply via email to