> Well, this was only proposed for TCP.

I don't know what "this" refers to but the original message from Pekka
commented on draft-haberman-ipv6-anycast-rr-00.txt and I responded to
those comments.

That draft has this in the abstract:
   Today, the use of IPv6 anycast is limited.  This document proposes a
   mechanism by which TCP/SCTP and stateful protocols using UDP can

So the draft fron Brian and me sure proposes using this for more than
just TCP.

> I'm not sure if we should consider
> something similar for UDP. Basically, UDP based protocols can be easily
> written to handle the peer address change on the application layer.
> However, if we want to support existing UDP applications that for
> example connect() their socket to a destination address, we'd need to
> device something similar for UDP as well. Do you think we need this?

I don't know about "easily" - they would need to provide the secure binding
mechanism themselves.
I think it makes sense to try to figure out a mechanism which can be applied
to multiple "stateful" protocols without requiring every such protocol
to roll their own.
At one end of the scale one could consider doing do changes to the transport
at all by hiding it all in a MIPv6 binding cache. Thus the transport
protocol would think it is actually talking to the anycast address.
I think such an approach has problems since the fact that the transport is
not aware that anycast is used means it can't take specific actions when
things fail (like trying to create a binding to a different member of
the anycast address).
Providing this "transport protocol aware anycast model" means that there
will be some changes to the transport protocol, but I think one can
avoid placing all the mechanisms in each transport protocol.

  Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to