Re: [Int-area] [arch-d] 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 11:36 PM Joseph Touch <[e-mail]> wrote:

>
>
> On Feb 27, 2020, at 4:21 PM, Phillip Hallam-Baker <[e-mail]>
> wrote:
>
> 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.
>
>
> I’d start with RFCs 791 and 1122, but there’s also the pseudo header in
> RFC 793, to be very specific.
>
> 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.
>
>
> Hmmm. By what value do you call  TCP endpoint?
>
> You must have magic sockets that don’t actually refer to IP addresses.
>

I have a library that implements RFC6763. So my application code doesn't
actually consider IP addresses.

Since the platform doesn't provide real DNS resolution, I have to write my
own of course. And I will be putting DNSSEC in there at some point
probably. But it is a feature set that should be in the platform.

At some point, I am going to have to look at implementing TURN/STUN/PCP
etc. for NAT traversal. That certainly isn't application layer code.

So as far as i am concerned, I am resolving a triple of SRV prefix, DNS
name and account name to a socket.

The only case in which my application code would deal in a raw IP address
and port is if the resolution is delegated to an external presence service.
If Alice is trying to make a person-person call to Bob, we may want to
route the packets direct. So there has to be some sort of presence service
in the cloud to set up the connection which is going to end up telling one
of them to place a call for an IP address/port and the other of them to
listen for the incoming.


The test of this design is straightforward, all the proposals for DNS
privacy etc. sit inside the library. I can drop out regular client DNS for
DPRIV. Or I can use my omnibroker version which makes use of the RFC6763
interface.

Abstracting away from TLS and UDP means I can adapt to new transports like
QUIC very easily. For certain types of message, I have my own UDP based
transport. Most cryptographic service transactions consist of a single
request packet followed by one to a dozen response packets. That sits in
the same box.


It really isn't 'magic', it is just understanding that this is platform
code not application code.

We do not have 'layers' in the Internet architecture but we have modules
that we call layers. And those layers have interfaces to the layers above
and beneath them that are mediated by a naming infrastructure. And we
should be really explicit about what those interfaces are because they have
to be stable over long periods of time.