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

[Keith Moore <[e-mail]>]

On 2/28/20 1:58 PM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Feb 28, 2020 at 1:48 PM Keith Moore 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     On 2/28/20 1:12 PM, Tom Herbert wrote:
>
>     > Yes, but in BSD sockets, the most common networking API, "bind"
>     takes
>     > an address and port number argument, "connect" takes and address and
>     > port number argument, getsockname and getpeername return the
>     > respective pairs set on a socket. So the TCP 4-tuple is very visible
>     > to applications and has been for many years. If there's a better way
>     > to do this that hides this and makes it easier I say go for it, but
>     > please don't call this a solved problem until you've achieved
>     > ubiquitous deployment and we can obsolete the sockets API since
>     no one
>     > is using it anymore.
>
>     And in particular any API that presumes that DNS will be reliable and
>     have the correct address for a peer, or even that it exists at
>     all, is
>     going to suffer from a huge disconnect from reality.
>
>     The beautiful thing about only needing an address and a port (and
>     often,
>     having a default port) is that it doesn't need any higher-layer
>     infrastructure to make it work.   This is a feature, not a bug.
>
>
> OK we are officially done.
>
> DNS is correct by definition. The resolution of example.com 
> <http://example.com> is not a matter for discussion, it is what the 
> DNS resolution service you decide to trust returns.

Sorry, no.    DNS can be, and is often, out of sync with reality.  And 
when DNS fails, as it often does, the IP address still works.  That's 
why millions of local networks use static IP address assignment, because 
it's easier to just use IP addresses than to make sure that DNS always 
works.   For example, when the DNS servers are located elsewhere and the 
local network gets disconnected.

You can claim that such sites should have multiple network links and 
provision their DNS better.   But you don't get to impose your 
requirements on others' operations.

> I have given the application layer view of the transport layer and 
> below. I really don't care if you think we are doing it wrong, that is 
> how we is going to continue to do it.

I'm glad you don't get to dictate how others write applications or 
operate their networks.

>
> There are of course concerns that arise from attempting to use 
> manually configured DNS as the basis for discovery. Manual 
> configuration is unreliable which is why I intend to automate the 
> process at some point.
>
> There should be a single point of management for service hosts in a 
> domain.

Uh, no.   Single points of failure make everything unreliable. 
ESPECIALLY management.

> Hosts should register/deregister the services they provide as they 
> come up and down.

Uh, no.   There are lots of issues with that, including not only 
degraded reliability but also privacy.

> This should also coordinate with the provision of certificates. And 
> the DNS config should be calculated from that. So all the 
> DANE/SPF/TXT/SRV records should be generated automatically.
>
> But if you config manually and people can't reach your service, that 
> is because your DNS is configured to say your service is down. That is 
> not a protocol failure.

No, if you design an application so that it needs unreliable services in 
order to operate reliably, it's a design failure.

Keith