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

[Philip Homburg <[e-mail]>]

>> 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. I.e., such layering violations should not exist in the
first place, so it is TCP that is broken.

>On 11/8/2015 3:08 PM, Philip Homburg wrote:
>>> ddns is also a layering violation because it makes an assumption at layer 7
>>> >about what's going on in layer 3.
>>
>> Again, we have to use transport layer identifiers, because the IP stack
>> doesn't define anything else.
>
>Note that some protocols do define other identifiers, e.g., HTTP uses URNs.
>
>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).

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.

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

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