> On Aug 29, 2018, at 11:19 PM, Christian Huitema <[email protected]> wrote:
>
>> Regardless, middleboxes shouldn't be avoiding their own effort by creating
>> work for others. A corollary to the Postal Principle should be "you make the
>> mess, you clean it up".
>
> Joe's stubborn adherence to the letter of the RFC would be very nice if the
> protocol police could somehow punish the merchants of NATs…
My concerns are pragmatic - merely not supporting something does not make it
unnecessary.
There was a time when Internet service in hotels would regularly block all
except basically DNS and HTTP/HTTPS; that’s becoming much less the case. There
was a time when devices didn’t support IPv6 at all because it was considered
merely an unnecessary expense; that’s becoming much less the case too.
In this case, we have two problems
1) NATs/firewalls as currently implemented do not support fragments
2) our current protocols, in many cases, require fragments (IPsec
tunnel mode) and in other cases (tunnels in general) would benefit from IP
fragmentation support
3) we DO NOT HAVE an alternative (there are some piece-wise proposals
for various aspects, but none support IPsec tunnel mode and none are otherwise
universal
Yes, something needs to be done, but I argue that *until we have a worked
alternative*, we need to keep restating the fact - NATs/firewalls MUST
reassemble to work properly; where they don’t, the error is on them - not the
rest of the Internet for using fragments.
> The whole discussion reminds me of Martin Thomson's draft, "use it or lose
> it" (draft-thomson-use-it-or-lose-it-02). Martin is describing how extension
> mechanisms that are not actually used get ossified away by the deployment of
> middle-boxes. The same happened long ago with IP segmentation. With NATs,
> applications cannot assume that reassembly will work. With Firewalls,
> transports cannot assume that ICMP will work.
Yes, that’s the tension:
a) identify bugs and fix them
b) accept bugs as de-facto protocol evolution
The problem with (b) is that it is not guided by what Internet users need; it’s
guided by what is profitable for individual vendors. That path is hazardous -
there’s no reason to believe that the result will be a useful Internet. So
until we know it’s safe to do (b), we need to stick with (a).
Joe_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
