> 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.
So you don't find bogus traffic a harm to the network. I
presume you also don't find one-way firewalls a harm to the
network. I can assure you that the sites on the end of one
way streams *do* find it harmful. It results in big pipes
being required to sustain service levels for legitimate
traffic. It results in additional machines being required
to service the load. There is a real money cost to this.
No one packet won't harm the net. The harm is done when
it is multiplied by the thousands or millions.
> > > 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.
No it will work intermittently depending apon the number
of anycast instances and the topological relationships of
the end points. If it doesn't work you will get timeouts
/ connection failures. It will be difficult to diagnose
the problems unless you realise that you are dealing with
a anycast address and take appropriate steps to deal with
it.
For example named allows you to specify a query source
address. As a developer I want hard failures to occur if
a anycast address is used here accidently. I don't want
all of the millions of existing copies of named to be able
to anycast addresses to source packets without being upgraded.
It will lead to a support nightmare that will exist for
years. I also want to be able to identify a anycast address
when I scan the list of addresses on the machine (FreeBSD
has IN6_IFF_ANYCAST).
Without a socket option you are handing people a loaded gun
with the safety off. At least make it a loaded gun with the
safety on. They then have to do something deliberate before
they shoot themselves in the foot.
Also by allowing by allowing traffic to be sourced from a
anycast address without a socket option you are violating
the principal of least astonishment. The exist stack *do*
block this so current applications may depend on it.
Mark
> 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
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
