[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140115114431.GB19945@order.stressinduktion.org>
Date: Wed, 15 Jan 2014 12:44:31 +0100
From: Hannes Frederic Sowa <hannes@...essinduktion.org>
To: François-Xavier Le Bail <fx.lebail@...oo.com>
Cc: netdev@...r.kernel.org, Bill Fink <billfink@...dspring.com>,
"David S. Miller" <davem@...emloft.net>,
Alexey Kuznetsov <kuznet@....inr.ac.ru>,
James Morris <jmorris@...ei.org>,
Hideaki Yoshifuji <yoshfuji@...ux-ipv6.org>,
Patrick McHardy <kaber@...sh.net>
Subject: Re: [PATCH net-next] IPv6: add option to use anycast addresses as source addresses in icmp error messages
Hi!
On Wed, Jan 15, 2014 at 01:46:03AM -0800, François-Xavier Le Bail wrote:
> On Tue, Jan 14, 2014 at 02:13:44PM +0100, Hannes Frederic Sowa wrote:
> > > On Mon, Jan 13, 2014 at 06:22:44PM +0100, Francois-Xavier Le Bail wrote:
> > > > - Add "anycast_src_icmp_error" sysctl to control the use of anycast addresses
> > > > as source addresses for ICMPv6 error messages. This sysctl is false by
> > > > default to preserve existing behavior.
> > > > - Use it in icmp6_send().
> > > >
> > > > Suggested-by: Bill Fink <billfink@...dspring.com>
> > > > Signed-off-by: Francois-Xavier Le Bail <fx.lebail@...oo.com>
> > >
> > > Regarding the anycast patches, I contacted someone from IETF.
> > >
> > > The number of sysctls needed to get introduced to have all the flexibility
> > > regarding source address selection and don't break backward compatibility
> > > concerns me a bit.
> > >
> > > Especially on end hosts, where those switches will be important, I think we
> > > really have to think about sensible defaults without breaking current
> > > software.
> > >
> > > I currently consider a per-address flag, if those anycast addresses
> > > should be available in source address selection (also with an enhancement to
> > > current IPV6_JOIN_ANYCAST logic).
> >
> > Francois, we should really think about this. Also if we should just
> > make the pre-defined subnet address just a normal anycast address in the
> > long-term (which just happens to get automatically added to an interface
> > if forwarding is enabled) and bundle all the source address selection
> > logic on the per-address state.
>
> Please submit patches with your solution, so that we can have a basis
> for discussion.
I won't have time for that in the next weeks and this is not on the top of my
TODO list, I fear :/ (I see what I can do).
Basically one would have to first start with address configuration support for
IPv6 and then add a flag to ifa_flags (damn is IPv6 getting complex) so one
could say
ip -6 a c fe80:: dev eth0 anycast anycast_pref
One easy thing would be to add this flag to the routing entries, but we may
run into problems with limited flag-store-space there, too:
So something would be possible
bool ipv6_use_anycast_addr(struct rt6_info *rt)
{
if ((rt->rt6i_flags & (RTF_ANYCAST|RTF_ANYCAST_PREF) == (RTF_ANYCAST|RTF_ANYCAST_PREF))
return true;
return false;
}
It seems you may eat a bit in the bit space of the generic RTF_ flags and use
flags to 32k (so adding in front of RTF_DEFAULT).
We could also link this flag to conditionally emit TCP-RSTs and ICMP error
messages with help of this flag.
Actually I don't like the solution with the rt6i_flags that much, I
would rather have this only in ifacaddr6 only. But lookup times will be
slower then. Don't know yet.
So we would have to tackle this problem from the other direction first and
implement proper anycast management via iproute first and then alter the
source address selection policies if we would go with something like that.
Maybe anycast_pref is a bad name, anycast_reply or anycast_use_src would be
better.
> > If that would be the case, we could revert
> > 509aba3b0d366b7f16a9a2eebac1156b25f5f622 ("IPv6: add the option to use
> > anycast addresses as source addresses in echo reply") and thus would
> > eliminate one sysctl.
>
> If your solution achieve the same goal without this sysctl, I agree with you.
I think it does, what do you think?
> > It would be fine if we can make this decision before David merges with
> > Linus. I guess we can still do this decision while in -rc phase. But
> > as soon as the knob is in a released version of linux we can never take
> > it back (I really don't like sysctls).
>
> Sure.
Greetings,
Hannes
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists