At Wed, 13 Apr 2005 14:13:34 -0700, Bob Hinden wrote:
> 
> Here is a proposal (rough) based loosely on Fred Baker's proposal and 
> subsequent discussion on the list:
> 
>     Arbitrary use of Internet anycast addresses is not recommended.  There
>     are known complications and hazards when using them in their full
>     generality [ANYCST].  Specific usage guidelines are:

Ok so far, although "arbitrary" is in the eye of the beholder....

>        1) Anycast may be used for simple query response applications
>           (for example DNS) where all nodes serving the anycast
>           address will respond with the same information and the packets
>           are limited in size so path mtu discovery is not needed.

Not quite right.  DNS packets might be big enough to need
fragmentation.  But there isn't any useful way to do path MTU
discovery in DNS/UDP anyway (very high client/server ratio, idempotent
lookup protocal, and the big packets are the responses going from the
server to the client, so the overhead of performing PMTU discovery and
keeping the necessary state on the server almost certainly outweighs
cost of just performing the query again when fragments get dropped).

So the criteria here are:

a) Short-lived session (typically two packet UDP exchange, but some
   argue that even a fast 7 packet TCP exchange is ok, so long as it's
   fast);

b) Path MTU either not needed or not useful for reasons having nothing
   to do with use of anycast.

>        2) Anycast may be used for applications where anycast is used to
>           rendezvous with a server and subsequently learn a stable unicast
>           address for further communication.

Ok.

>        3) Except as described in 1) and 2) above an anycast address must
>           not be used as the source address of an IPv6 packet.

Too strong.  I'd be ok with "should not".

>        4) Except as described in 1) and 2) an anycast address must not be
>           assigned to an IPv6 host, that is, it may be assigned to an IPv6
>           router only.

I realize that this is just continuation of a fine old IPv6 tradition,
but it has never made any sense to me.  What's so special about
routers in this context?  Why is it ok when a router does it but not
when a host does it?  As near as I can tell, the real historical
answer to this is that, once upon a time, somebody thought that router
discovery might use anycast, back before the current RA protocol.

If there's a strong technical justification for treating routers and
hosts differently here, please make it (here and in the text), but
absent such a justification I'd urge dropping point (4) entirely.

> Another approach is to write a separate document that relaxes the rules and 
> describes the issues in more depth than we might want to add here.  This 
> would keep the current limits in the address architecture (going forward to 
> Draft standard) and have the new document start at Proposed standard.

I'd rather just fix the current doc and let the ongoing work happen in
GROW.  If the GROW work results in enough IPv6-specific stuff that
there's a need for a new IPv6 WG document, fine, but so far I am not
seeing it.  Anycast is mostly an IP issue, not an IPv6 or IPv4 issue.

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

Reply via email to