Re: [PATCH net-next v2] IPv6: add option to use Subnet-Router anycast addresses as source addresses

[Hannes Frederic Sowa <hannes@stressinduktion.org>]

On Fri, Jan 03, 2014 at 08:04:26AM +0100, Hannes Frederic Sowa wrote:
> On Thu, Jan 02, 2014 at 10:49:02PM -0800, François-Xavier Le Bail wrote:
> > On Fri, 1/3/14, Hannes Frederic Sowa <hannes@stressinduktion.org> wrote:
> > 
> > On Thu, Jan 02, 2014 at 10:19:24PM  -0800, François-Xavier Le Bail wrote:
> > 
> > >> Some setup may use a ping to Subnet-Router anycast
> > >> address and expect a reply to discover a unicast address
> > >> (not very secure, but ...).
> > >>
> > >> It is the reason why, I want to keep existing default.
> >  
> > > Yep, with pre-defined anycast address I actually meant the
> > > subnet router
> > > anycast address. We currently don't need to deal with more
> > > than that one:
> > > https://www.iana.org/assignments/ipv6-anycast-addresses/ipv6-anycast-addresses.xhtml
> >  
> > > As soon as this patch gets applied, we have to keep the knob stable
> > > in its semantic.  So my proposal would be to change the knob to just
> > > control the behaviour of ping replies and also change its
> > > name to reflect this.
> >  
> > > Leave datagram sending with specific anycast address as
> > > source just open and
> > > don't protect it with this knob. Would that be a plan?
> >  
> > But service discovery may be done also with UDP, so I see the knob as a router policy:
> > It enable or not anycast source.
> 
> Wouldn't distributions just enable this unconditionally and no one will ever
> look at this option again?
> 
> IMHO it would be better if it could be controlled per application, because
> they ultimately know how their discovery protocol works. In case of ping, it
> is ok, because applications cannot control the source address here.

And actually, my preferred setup would be to use anycast addresses as source
addresses, but still have ping use the unicast address. This current patch
does not allow that?

Greetings,

  Hannes