Re: [Int-area] Continuing the addressing discussion: what is an address anyway?

[Tom Herbert <[e-mail]>]

On Tue, Jan 25, 2022 at 3:38 AM Geoff Huston <[e-mail]> wrote:
>
>
>
> > On 25 Jan 2022, at 6:19 pm, Dirk Trossen <dirk.trossen=[e-mail]> wrote:
> >
> > All,
> >
> > Thanks for the great discussion, following our side meeting at IETF 112, so far.
> >
> > I wanted to turn the discussion to a key question which not only arose in the side meeting already but also in the discussions since, namely “what is an address anyway?”.
> >
>
> In this world of NATs it seems that we treat addresses as no more than temporary ephemeral session tokens and we've passed all the heavy lifting of service identification over to the name system. These days you and I could be accessing the same service yet we could b e using entirely different addresses to do so. Or I could be accessing the same service at different times, and again be using different addresses each time. I find it somewhat ironic that we see increasing moves to pull in IP addresses as part of the set of personal information in some regulatory regimes, yet what the larger network sees of end clients is a temporary NAT binding to a public address that may be shared by hundreds if not thousands of others.
>
> And IPv6’s use of privacy addressing achieves a similar outcome in a different way. And QUIC’s use of the session token inside the encrypted envelope even makes the binding of an address to a single session fluid, as the same QUIC session can be address agile on the client side.
>
> So perhaps an address these days is just an ephemeral transport token and really has little more in the way of semantic intent.

Geoff,

That might be true for QUIC, but not for TCP. Each TCP endpoint
requires stable addresses for the lifetime of the connection since the
addresses are part of the four-tuple identifying the connection. While
the addresses at each end point of a connection may differ, they must
be consistent for the lifetime of the connection at both endpoints.
That's where NAT breaks things, if NAT state is evicted or lost TCP
connections routed through NAT are no longer viable, hence that's why
it's correct to say that NAT breaks the end to end model. TCP
properties also makes it difficult to change the addresses of TCP
connections on the fly for privacy, but giving each connection it's
own unique IP address is potentially feasible since there are no
necessary protocol requirements for consistent addressing between
different connections.

Tom

>
> Geoff
>
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area