Anycast to unicast resolution (was: Re: Generic anycast addresses...)

[Toerless Eckert <[e-mail]>]

Christian:

I would certainly like a mechanism to resolve from anycast to unicast
that is independent of a specific transport protocol like QUIC. I guess
the interesting new requirement that QUIC introduced into that equation
is that such resolution should avoid any additional round-trip.

One way to do this would be to have a generic simple anycast resolution
mechanism with one request and one reply and both can carry a
transport protocol specific payload. Only thing it costs is that those
two packets reduce the transport size available to the first request/reply,
not sure how problematic this would be. But at least it would be lovely
not having to reinvent that wheel for QUIC, TCP, STCP and the vairiety
of UDP transports we have.

On Tue, Jun 04, 2019 at 05:54:25AM -0700, Christian Huitema wrote:
> I am not sure that we could safely engineer these functions in a shim
> layer like Shim6. QUIC can do it because it is an encrypted transport.
> Path continuity can be verified and proven by demonstrating knowledge of
> the encryption keys, which are negotiated end to end as part of the
> transport setup.

I guess for the anycast resolution request/reply, a none should be
sufficient. Whether the transport uses encryption or not is unaffected
by this. What the transport is affected by is the notion that the
transport connection ID does not use the anycast address but the
resulting unicast address.

> That said, we are a bit far from the original discussion of generic
> anycast addresses.

Easily resolved by chnge of subject ;-)

Cheer
    Toerless
> 
> -- Christian Huitema
> 
>