> 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
