Re: [v6ops] Thoughts about wider operational input

[Simon <[e-mail]>]

On 31 Mar 2022, at 21:43, Joe Maimon <[e-mail]> wrote:

>>> Simon wrote:
>>>> Any form of NAT breaks things<period> That’s the short answer.
>>>> 
>>>> Longer answer, any protocol that embeds addresses in it gets broken - e.g. during session setup one end tells the other, please contact me at address X and port Y. That is quite common once you get past a basic “open connection, squirt some data, close session”. Examples that come immediately to mind :
>>> In OSI speak thats a layering violation. An upper level protocol incorporates details and assumptions about lower layers as part of its operations.
>> Citation ?
> 
> https://www.rfc-editor.org/rfc/rfc3724.html
> 
> Since the upper level protocol incorporates lower level properties into its functionality, it is now dependent on them.

Hmm, that is not what that document says. I have to assume you are referring to section 4.2 since everything else is in favour of end-end connectivity.
>    Two key points in designing application
>    protocols are to ensure they don't have any dependencies that would
>    break the end-to-end principle and to ensure that they can identify
>    end points in a consistent fashion.

So nothing about not embedding an address and port into a message (e.g. a setup message for a session) since that doesn’t break the end-end principle, and it doesn’t affect the ability of the network to do it’s job (route packets between devices).
>    Architectural
>    considerations around this issue are discussed in RFC 3238 [5].  This
>    desire need not result in a violation of the end-to-end principle if
>    the partitioning of functioning is done so that services provided in
>    the network operate with the explicit knowledge and involvement of
>    endpoints, when such knowledge and involvement is necessary for the
>    proper functioning of the service.

NAT is not a network “operat(ing) with the explicit knowledge and involvement of endpoints”, it is a process whereby it’s mangling the packets in a way that the endpoint/application cannot (in the general case) reliably determine.


> 6.  Conclusions
>    The end-to-end principle continues to guide technical development of
>    Internet standards, and remains as important today for the Internet
>    architecture as in the past.


So, since we seem to have vastly differing interpretations of what that document actually says, over to you - where does it say that (e.g.) an application should not use network addresses/ports within messages ? The application is already fundamentally tied in with the lower layers - unless it understands IP (whether version 4 or 6) to at least some extent then it cannot use the network. At it’s simplest level, it needs to be able to allocate structures to hold address/port pairs of other devices with which it is communicating.


I’ll toss an analogy out there. I want to send a letter/card/whatever to a friend in the post. I don’t care HOW the postal service works, how it routes items (packets), whether all such items (packets) follow the same route. But I DO need to know how to address an item (packet) so that the postal service can route and deliver it. And I do expect the postal service to deliver it to the right address.
As we all know, with snail mail, the addressing is “quite flexible” and at many points there are humans that can apply common sense. So, taking an analogy for NAT, it’s enough for my item to be delivered to the concierge of the apartment block and he will be able to see it’s addressed to my friend and deal with putting it in the right mailbox. Similarly, this NAT isn’t opaque in that my friend (I assume) will know the address of his apartment block and can provide that to me - along with the apartment number.
A network with NAT is like living in an apartment block that you don’t know the address of. You can look at your front door and see it’s (e.g.) apartment 104 - equivalent to asking the OS for the address(es) of the system interface(s). It takes more effort to find out what address you need to tell your friends so they can have mail delivered to you. Furthermore, (in the general case) NAT (or more precisely NAPT) is finding that the numbers on the mailboxes in the foyer random change all the time - and there aren’t enough mailboxes for you each to have one full time. So while the front door of your apartment might say 104, you don’t have a reliable apartment number to tell friends to address stuff to you at. And, with IP, the addressing needs to be explicit - there no concierge who can sort out incorrectly addressed packets.


Now, while I am generally quite negative about NAT, I can see that there are some use cases to PREFIX translation with IPv6. I would qualify that with it being ONLY the prefix that gets changed - the local part of the address and the port would NEVER be mangled. And I’d also qualify it with there needing to be a simple, well defined, process by which the application may ask the network layer explicitly what translation is in place - i.e. meet the “operates with the explicit knowledge of the endpoints” bit above.
However, that last bit needs every application where it may be needed to be updated with support for whatever process/protocol was designed - much as they did (in a much harder manner) to try and figure out what IPv4 NAPT was doing to their packets.


Simon