On Tue, 2003-02-25 at 15:28, Erik Nordmark wrote:
> > 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.
Right, I had forgotten where the thread started. I was referring to
Pekka's idea of using an ICMP error response as a simple redirect
indication to a TCP sender and "authenticating" the ICMP packet by
checking the TCP sequence number in the ICMP payload.
> > 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.
TCP has the problem that it simply can't be used with an anycast address
without changing the protocol or somehow handling the binding
transparently on L3 (as in MIPv6). UDP doesn't have this problem; at
most the applications need to be changed to react correctly to peer
address change.
I didn't consider the above from the viewpoint of authenticating the
binding. I can see that the authentication could get quite involved with
UDP. I'm not sure it's wise to do it transparently in all cases. I guess
the RR mechanism could be adapted but there are some problems.
Some of the problems relate to figuring out what constitutes a session
with a UDP application. A connectionless socket could be used to
communicate simultaneously with multiple peers, the protocol could just
be a one-shot request-reply interaction, or the flows could be
uni-directional, etc.
Also, as I pointed out earlier, the RR mechanism in MIPv6 affords the CN
some protection against DoS at the expense of the MN. In
draft-haberman-ipv6-anycast-rr-00 the anycast server takes the role of
the MN, which means that it draws the short straw when it comes to DoS
protection.
> 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.
That's a good goal. Different applications might have different
requirements, though. Some might require that the binding is
authenticated, while others might value a speedy redirect, even if
unsafe.
> 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).
True. It is also worth asking what is the proper granularity for storing
the binding: per host, per flow, or something in between? Do we want to
redirect all applications to the same unicast address, or should we
allow different flows go to different unicast addresses?
> 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.
Maybe some basic L3 mechanisms, like the binding cache and RR, could be
made available to applications and transport protocols as a "toolbox"
via an appropriate service interface. Each "anycast user" could then use
this toolbox in the most appropriate way.
MikaL
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
