Subject: Re: a few comments on anycast mechanisms

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 16:16:16 +0100 (CET)

> Not necessarily. The <anycast,unicast> binding could be stored in the
> binding cache as in MIPv6 and TCP could continue using the anycast
> address.

Depends what happens when the binding times out and
needs to be refreshed/re-established.
MIPv6 assumes that it can just redo the RR exchange and
still end up sending to the same host. That isn't the case for
anycast since the anycast address identifies more of a service than a host.
Thus to make it more likely that the transport connection survive 
routing changes it makes sense to get the transport connection basically
be redirected to use a unicast member of the anycast group.

   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-masked]
--------------------------------------------------------------------

---

From: Mika Liljeberg <[email-masked]>
Date: 21 Feb 2003 19:40:39 +0200

> be redirected to use a unicast member of the anycast group.

I don't know that the binding needs to have a limited lifetime in this
case. It can be deleted when the TCP connection is closed (or via a
reference counting mechanism in case multiple connections can map to the
same binding).

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Feb 2003 15:57:54 +0100 (CET)

> reference counting mechanism in case multiple connections can map to the

What about the case when you have UDP communication which needs to reach
the same server? (or at least be notified when the anycast server changes).
In that case you can't rely on the fact that the kernel has a single notion
of active communication.

   Erik

---

From: Mika Liljeberg <[email-masked]>
Date: 24 Feb 2003 19:58:30 +0200

> In that case you can't rely on the fact that the kernel has a single notion

Well, this was only proposed for 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?

	MikaL

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 25 Feb 2003 14:28:16 +0100 (CET)

> 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

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

---

From: Mika Liljeberg <[email-masked]>
Date: 25 Feb 2003 20:10:24 +0200

> So the draft fron Brian and me sure proposes using this for more than

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 don't know about "easily" - they would need to provide the secure binding

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.

> to multiple "stateful" protocols without requiring every such protocol

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.

> things fail (like trying to create a binding to a different member of

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?

> 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