Re: IPv6 Formal Anycast Addresses and Functional Anycast Addresses (Fwd: New Version Notification for draft-smith-6man-form-func-anycast-addresses-01.txt)

On Mon, 4 Nov 2019 at 11:27, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> Fred Baker <fredbaker.ietf@gmail.com> wrote:
>     > Funny. It doesn't work that way in DNS. Every root server simply thinks
>     > that one of its addresses is the anycast address and so accepts the
>     > packet as "directed to it". It also responds from that address, so that
>     > the requester recognizes the response.
>
> Yes, as long as it's UDP, or very short-lived TCP connections, it works.
> If someone wants to use anycast for a longer-lived connection (in DNS, that
> could include DoT...) then we run into problems.
>
> {shim6 could have dealt with this, but we decided we couldn't do it. I'm
> still sad}
>

Host Identity Protocol could have also achieve this.

I've started to wondered if solving the identifier/locator problem
within the transport layer, using temporary transport layer connection
identifiers - a  32 bit 'token' in MPTCP, rather than persistent host
identifiers, might be the better solution. It's certainly has been
much more successful at being deployed - Apple put MPTCP in iOS 7 and
it was being used for Siri (don't know if it still is).

>     >> On Nov 3, 2019, at 4:27 PM, Toerless Eckert <tte@cs.fau.de> wrote:
>     >>
>     >> It is somewhat architecturally dissatisfying that (AFAIK) we seem to need to
>     >> resolve limitations of anycast addresses at the transport layer,
>     >> e.g.: redirecting connection requests to an anycast address to a
>     >> unicast address of the transport responder. If initiators would know an address is
>     >> an anycast address, they could use some TBD network layer (ICMP) extension
>     >> to do that resolution independent of individual transport protocols.
>     >>
>     >> And the network layer would only know it needed to do this if there was
>     >> a way for the initiator to identify an address as an anycast address
>     >> AFAIK (can't think of a simpler way).
>     >>
>     >> Cheers
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------