Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Joe Touch <[e-mail]>]

On 11/10/2015 3:50 AM, Philip Homburg wrote:
>>> Call me old fashioned, but what NAT breaks is not what is traditionally
>>> called a protocol layering violation. (The TCP checksum is one of the classical
>>> layering violations in the IP protocol stack)
> 
>> Given that a NAT breaks the TCP checksum (which depends on the IP
>> pseudoheader and TCP header) and thus has to recalculate it, wouldn't
>> that be proof that a NAT breaks what you consider protocol layer violation?
> 
> If a layering violation like in TCP gets broken by NAT, then I consider
> that fair game.

What's the layering violation?

TCP endpoints are defined as being the endpoint IP + port pair. TCP and
IP are not independent layers; they never have been.

> I.e., such layering violations should not exist in the
> first place, so it is TCP that is broken.

If you believe that TCP should have its own IP addresses, then fine.
Let's consider the following:

	IP-IP-TCP

Then the first layer is IP, the second is the IP-TCP pair.

That would provide the clean layering you desire, but NATs would break
that too. NATs intentionally overwrite identities - not just routes.
There's no way to do that without violating every basic premise of layering.

...
>> We often use L4 identifiers when there are no other upper layer
>> end-to-end identifiers available, e.g., the app uses 128.9.160.161:80
>> because that's what the user provided. The fact that these are L4 (or
>> L3) identifiers is true only because the addresses got passed down
>> through the stack - which is definitely not layer violation.
> 
> Commonly used URNs rely on transport layer addresses (which are broken by
> NAT) or DNS, which is also broken by NAT (in some cases).

Right - the basic concept of a NAT is exactly opposite the concept of
strict layering.

> One way of looking at NAT is that it deals with a failure of IP addressing.
> In the case of IPv4, with the fact that 32 bits is just not enough.

Another view is that NATs also exist - especially in IPv6 - as a way for
ISPs to enforce a pricing policy that differentiates consumers from
corporate customers by artificially and deliberately interfering with
the Internet model of global endpoint addresses (i.e., to interfere with
setting up a server, because - of course - only a corporate customer
would need to do that).

> And in IPv6 most likely in cases where the locator/identifier split is not
> in the architecture. 

See above.

> I.e. NAT breaks the model because it is a fix where the model is broken.

I agree that NATs for true address sharing serve a useful purpose, but
that disappears with IPv6. NATs for security can easily be replaced by
stateful firewalls, i.e., that limit incoming connections without
rewriting the headers.

The problem with believing that NATs fix a broken model is that, if the
model *is* broken, it's because of a lack of transport-layer IDs. NATs
further destroy that concept when they overwrite both addresses and
ports - that's not fixing a broken model, it's breaking it even more.

Joe