On Thu, 2003-01-30 at 00:16, [EMAIL PROTECTED] wrote:
> > On Wed, 2003-01-29 at 01:28, [EMAIL PROTECTED] wrote:
> > > Well you don't actually want it lifted. You don't want a
> > > anycast address being used to *initiate* a transaction.
> >
> > Why not?
>
> Because the reply traffic is *not* guaranteed to go back
> to the same instance. The whole point of this thread is
> how to make the traffic go back to the correct instance.
To achieve that one can always use a unicast source address. That is not
a reason to disallow an anycast source address. While it may not be
useful with TCP, it is not harmful to the network either. With UDP
people might even find a use for it.
> > I don't think a socket option is needed. If an application binds
> > explicitly to anything other than :: it's only fair to assume that it
> > knows what it's doing.
>
> It's not a fair assumption that it knows that it is a anycast
> address. Every existing application written today that allow
> selection of source address fails your test that it know what
> it is doing w.r.t. anycast addresses.
The socket option doesn't help. If an application doesn't understand
anycast addresses and tries to use one as a source address, it will fail
regardless of whether there is a socket option for it or not. It will
just fail in a different way. A new socket option would just be
unnecessary bloat, IMHO. The key thing is that automatic source address
selection must never choose an anycast address.
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]
--------------------------------------------------------------------
