Re: Generic anycast addresses...

[Christian Huitema <[e-mail]>]

On 6/3/2019 7:49 AM, Michael Richardson wrote:
> Mikael Abrahamsson <[e-mail]> wrote:
>     >> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
>
>     > I have now read RFC1546 and now I understand some of the confusion. Did the
>     > concept of "send SYN to anycast address and get SYN-ACK back from actual
>     > unicast address" ever get implemented anywhere?
>
> I don't think so.
> Maybe some BSD 4.0 could support it, but it would be fly in the face of most
> firewalls.  It would rely only on the sequence number to match things up.
> That would be pretty weak, particularly at the time RFC1546 was published!

There is support for this kind of behavior in QUIC with the "preferred
address" transport parameter, although it is quite different from what
is stated in RFC1546. From the spec, "QUIC allows servers to accept
connections on one IP address and attempt to transfer these connections
to a more preferred address shortly after the handshake. This is
particularly useful when clients initially connect to an address shared
by multiple servers but would prefer to use a unicast address to ensure
connection stability." In that scenario, the full handshake is performed
over the anycast, but the client tried to opens a new path after that to
the "preferred address" of the server. If the path verification
succeeds, the exchange moves to the new address.

-- Christian Huitema