> On Aug 26, 2018, at 12:58 PM, Tom Herbert <[email protected]> wrote:
> 
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch <[email protected]> wrote:
>> 
>> 
>>> On Aug 26, 2018, at 10:31 AM, Christian Huitema <[email protected]> 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

_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to