Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Joe Touch <[e-mail]>]

> On Aug 26, 2018, at 12:58 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch <[e-mail]> wrote:
>> 
>> 
>>> On Aug 26, 2018, at 10:31 AM, Christian Huitema <[e-mail]> wrote:
>>> 
>>> It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.
>>> 
>>> Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context?
>> 
>> NATs already have what they need to do the proper job - they need to reassemble and defragment using unique IDs (or cache the first fragment when it arrives and use it as context for later - or earlier cached - fragments). There’s no rule that IP packets that are fragmented MUST have a transport header both visible (not encrypted) and immediately following the IP header.
>> 
>> Firewalls are just delusions; the context they think they’re enforcing has no meaning except at the endpoints; it never did.
>> 
>> Using part of the IPv6 space for this solution would then break per-address network management (different UDP ports would use different IPv6 addresses, presumably).
>> 
>> The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful to try to address the symptoms of that disease individually.
>> 
> Joe,
> 
> That is only a better solution, not a complete or robust one.

It is complete and robust...

> For
> reassembly to work all fragments of a packet must traverse the same
> NAT device. There is no rule that IP packets going to the same
> destination (fragments or not) ever MUST follow the same path.

Correct, but there has to be a rule that all packets in a NAT’d flow go through the same NAT or multiple devices that emulate a single NAT.

> So in a
> multi-homed environment this will eventually break someone. For IPv6,
> this is also a clear violation of RFC8200 since intermediate nodes are
> processing a non-HBH extension header in a packet not addressed to the
> them.

A NAT is not a router. A router is not allowed to modify the IP addresses or port numbers.

When a NAT does these changes, it is acting as a proxy endpoint in the public Internet; as such, it is *required* to do whatever is necessary to ensure that its behavior follows that of a host.

> The only robust solution to NAT and its fragmentation problems,
> as well as a bunch of other problems NAT brings, is to not use NAT!
> (i.e. switch to IPv6)

As I’ve mentioned, there are rules under which a NAT is a valid Internet device, but it is simply not just a router.

Joe



> Tom
> 
>> Joe