On 7 Apr 2005, at 14:02, [EMAIL PROTECTED] wrote:
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.
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
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
