> On Aug 31, 2018, at 8:44 AM, Tom Herbert <[email protected]> wrote:
>>
> Joe,
>
> There is an alternative: don't use NAT!
Agreed - that should also be part of the observations of this doc.
>> 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.
>
> Reassembly could only be a MUST for NAT, not firewalls.
“or its equivalent"
> NAT might be
> required because of the identifier space issue, however we already
> shown how a firewall can achieve proper functionality without
> reassembly and to be stateless by forwarding fragments and potentially
> dropping the first one that contains port information being filtered.
First, firewalls that port-filter need to do the same thing as a NAT in terms
of keeping state.
> The fact that this might forward fragments that are never reassembled
> is at best an optimization with unproven benefit.
ATM proved otherwise in numerous published studies in the late 1980s. Those
fragments compete for bandwidth further along the path; anytime they “win”,
that decision is not work-conserving.
Note that keeping some state is already needed (if port-filtering) and that -
as you note - the state filtering need not be “perfect”. However, it really
ought to be SHOULD at least.
>
> There is another case where in-network reassembly could be required
> which is load balancing to a virtual IP address.
Any middlebox that uses state not available in all fragments MUST reassemble or
keep equivalent storage/state to process fragments appropriately.
> Like NAT though, in the long run I believe IPv6 offers a better
> solution that would eliminate the need for VIPs.
That’s true right up until we end up in a world where (mostly) nobody correctly
uses flow IDs. Oh, wait - we’re already there…
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
