Subject: Re: Anycast support in draft-ietf-ipv6-addr-arch-v4-02.txt

From: [email-masked]
Date: Thu, 7 Apr 2005 11:02:37 -0700 (GMT-07:00)

> Do you have any concerns that relate to using an anycast address as the 
> *source*?

What keeps 2 different hosts from using the same anycast address? If they both talk to the same destination address tuple (a different anycast address but 2 different hosts) can't there be problems?

Seems that there are edge cases that can cause real problems.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Joe Abley <[email-masked]>
Date: Thu, 7 Apr 2005 14:35:09 -0400

On 7 Apr 2005, at 14:02, [email-masked] wrote:

> What keeps 2 different hosts from using the same anycast address? If 
> they both talk to the same destination address tuple (a different 
> anycast address but 2 different hosts) can't there be problems?
>

It is usual for more than one host to use the same anycast address 
(that's what makes the otherwise-unremarkable unicast address concerned 
"anycast").

The proposal to remove the restrictions in the v6 address architecture 
is not based on the belief that it is impossible to use anycast badly; 
it is based on operational experience that it is possible to use 
anycast safely.

Successful anycast services deployments are made in environments where 
the expected stability of the routing system between a unicast client 
and an anycast destination is good enough that packets from the client 
to the service address will continue to land on the same server for as 
long as it takes for the transaction to complete.

For some routing systems this means that only short-lived transactions 
are suitable for deployment as anycast systems (e.g. DNS has a small 
transaction time, and experience seems to show that it is a reasonable 
candidate for anycast deployment on the public Internet with relatively 
dense node placement).

For other routing systems, longer-duration transactions may be suitable 
(e.g. within the IGP of a service provider, it is not unknown for web 
cache services and mail submission services to be anycast within the 
IGP, say one server per site, allowing rapid service for local clients 
with an automatic fall-back to other sites if a server fails).

Where anycast is used inappropriately, it is entirely possible that 
persistent failures may result from successive packets from the same 
client (in the same transaction) being received by different anycast 
nodes.

The grow wg document draft-ietf-grow-anycast-00 aims to provide 
guidance to implementors such that inappropriate use of anycast can be 
avoided.

Joe