Re: [arch-d] [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Feb 27, 2020 at 5:47 PM Joe Touch <[e-mail]> wrote:

> On 2020-02-27 14:26, Phillip Hallam-Baker wrote:
>
> On Thu, Feb 27, 2020 at 5:09 PM Tom Herbert <[e-mail]> wrote:
>
>> Fernando,
>>
>> I think we need to be careful that IETF is labeled as a collection of
>> inflexible architectural purists. We know that standards conformance
>> is voluntary and we haven't seen the last time that someone, possibly
>> even a major vendor, will circumvent the system for their own
>> purposes.
>
>
> IP end to end does not mean the IP address is constant end to end. It
> never has meant that and never will.
>
>
> Actually, that's the only thing it ever meant and always will. When
> addresses change, *by definition*, the*ends* change (and yes, that's what
> NATs do - they create end-to-end CONTENT transfer over separate end-to-end
> Internets).
>

By whose definition? Not by mine.

TCP and TLS give me a reliable end-to-end stream. The fact that the IP
address is exposed is merely an unfortunate defect in the legacy APIs.

As the application layer designer, I am the customer here. I do not care
about the IP address.



> ..
> We discovered that there were good reasons for NATing IPv4 besides address
> multiplexing. The topology of my network is none of your business.
>
>
> Agreed; there's nothing that forces you to use IP addresses in a way that
> exposes your topology (you're free to build a net using host routing). That
> has nothing to do with NAT.
>
> I have not found a rationale for NATs that doesn't start and end with a
> business model where servers are charged business rates and clients are
> charged customer rates. Everything else about NATs either isn't a NAT
> property (hiding topology) or can be achieved by a stateful firewall (that
> predates NATs by a decade, e.g. that lets outgoing connections go through
> but not incoming).
>

Then you have had a remarkably sheltered upbringing.

Concealing details of the internal network structure is only common sense.



>
>
> More generally, Internet standards only apply to the Inter-net, the
> network of networks. What happens inside the networks at either end is for
> the owners of those networks to decide. If we go back to the original
> Internet design, they didn't even need to run IP. IP end to end come later.
>
>
> That's true, but then their "end" on the public Internet would be the
> firewall or NAT box at their edge.
>

There isn't a single 'end' in a protocol which is one of the reasons
end-to-end security has been done so badly. If Alice sends Bob a business
email, we have the following ends:

1) Application layer: SUBMIT Client -> SUBMIT Service, SMTP Client -> SMTP
Service, IMAP Client -> IMAP Service.
2) Message layer: Alice Email client -> Bob Email Client
3) Trust: Alice's employer <-> Bob's employer

Feel free to introduce extra ends if you like, it is irrelevant to my
concerns at the application layer.



>
>
> So let us stop being dogmatic about things that don't actually matter. The
> only job of the network layer is to get packets from one end to another.
> The only job of the transport layer is to provide reliable streams. An
> application protocol that depends on the IP address remaining constant end
> to end is a bad protocol and should be rejected.
>
>
> That's a very OSI view of protocols - about as out-dated and about as
> useful., IMO. Every layer of the stack might be involved in any function;
> anything that claims a single layer owns a single job hasn't existed since
> at least IP over IP.
>

The notion of encapsulation has been established in the object oriented
programming world for decades. The notion that the application program
should be abstracted from the transport and network layer is hardly a
controversial one.

As for OSI, I would not know as I have not made a detailed study of it. It
is not a model I find interesting as it doesn't describe the role of the
naming systems and it isn't able to describe systems like SDN and VPN which
we make use of.