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

[Tom Herbert <[e-mail]>]

On Fri, Feb 28, 2020 at 9:20 AM Phillip Hallam-Baker
<[e-mail]> wrote:
>
>
>
> On Fri, Feb 28, 2020 at 11:14 AM Tom Herbert <[e-mail]> wrote:
>>
>> On Fri, Feb 28, 2020 at 5:32 AM Phillip Hallam-Baker
>> <[e-mail]> wrote:
>> >
>> >
>> >
>> > 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.
>> >
>> It's great that _you_ have a solution, but not everyone does. The
>> standard says that a TCP connection endpoint is defined by a 4-tuple
>> of source address, destination address, source port, destination port.
>> It is an invariant that we have forty years of operational experience
>> with. If you think that design decision is obsolete or should be
>> revisited, then by all means propose an alternative in tsvwg.
>>
>> Tom
>
>
> That is a TCP connection. Applications don't deal in TCP connections, they deal in sockets.
>
> Its called abstraction. All that complexity belongs in a box that the application programmer doesn't need to open.
>
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.

In any case, I don't see how any of this is relevant to protocol
discussion. We build APIs based on protocol requirements, not the
other way around.

Tom
> Now current practice is that people use the gethostbyname() call to do DNS resolution and so they end up being unable to make use of DNS properly. But that is a problem with the 40 year old legacy API which can be changed or circumvented entirely
>
> RFC6763 is what the application layer should use.