> 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.

Int-area mailing list

Reply via email to