[RFC IPv6] Disabling IPv6 autoconf

[RFC IPv6] Disabling IPv6 autoconf

[Olaf Kirch]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

Hi,

we had bug reports from people seeing lots of spurious messages
like the following:

kernel: peth0: received packet with own address as source address.

and

xenbr0: duplicate address detected!

This is on a Xen enabled machine, with lots of Xen machines on the
same network.

When the Xen code configures the bridge device, this will do IPv6
autoconfiguration for the interface, and since they use synthetic MAC
addresses, there will be DAD collisions.

When the Xen people looked for a way to disable IPv6 autoconf of the
bridge, they didn't find any way to do it without bringing up the
device first (and thereby triggering DAD).

The attached tentative patch makes IPv6 autoconf depend on the
availability of IFF_MULTICAST. This is admittedly a bit of a hack, but
it makes sense, since DAD and router solicitation do rely on multicast.

Any comments?

Thanks,
Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

[-- Attachment #2: ipv6-no-autoconf --]
[-- Type: text/plain, Size: 1524 bytes --]

Summary: Allow to bring up network interface w/o ipv6 autoconf

When bringing up a xen bridge device, it will always be configured to
use a MAC address of ff:ff:ff:ff:ff:fe.  This greatly confuses IPv6 DAD,
which starts logging lots and lots of useless messages to syslog.

We really want to disable IPv6 on these interfaces, and there doesn't
seem to be a reliable way to do this without bringing the interface
up first (and triggering IPv6 autoconf). 

This patch makes autoconf (DAD and router discovery) depend on the
interface's ability to do multicast. Turning off multicast for an
interface before bringing it up will suppress autoconfiguration.

Signed-off-by: Olaf Kirch <okir@suse.de>

 net/ipv6/addrconf.c |    2 ++
 1 files changed, 2 insertions(+)

Index: build/net/ipv6/addrconf.c
===================================================================
--- build.orig/net/ipv6/addrconf.c
+++ build/net/ipv6/addrconf.c
@@ -2462,6 +2462,7 @@ static void addrconf_dad_start(struct in
 	spin_lock_bh(&ifp->lock);
 
 	if (dev->flags&(IFF_NOARP|IFF_LOOPBACK) ||
+	    !(dev->flags&IFF_MULTICAST) ||
 	    !(ifp->flags&IFA_F_TENTATIVE)) {
 		ifp->flags &= ~IFA_F_TENTATIVE;
 		spin_unlock_bh(&ifp->lock);
@@ -2546,6 +2547,7 @@ static void addrconf_dad_completed(struc
 	if (ifp->idev->cnf.forwarding == 0 &&
 	    ifp->idev->cnf.rtr_solicits > 0 &&
 	    (dev->flags&IFF_LOOPBACK) == 0 &&
+	    (dev->flags & IFF_MULTICAST) &&
 	    (ipv6_addr_type(&ifp->addr) & IPV6_ADDR_LINKLOCAL)) {
 		struct in6_addr all_routers;
 

Re: [RFC IPv6] Disabling IPv6 autoconf

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20060829082435.GA2676@suse.de> (at Tue, 29 Aug 2006 10:24:35 +0200), Olaf Kirch <okir@suse.de> says:

> When the Xen code configures the bridge device, this will do IPv6
> autoconfiguration for the interface, and since they use synthetic MAC
> addresses, there will be DAD collisions.
:
> The attached tentative patch makes IPv6 autoconf depend on the
> availability of IFF_MULTICAST. This is admittedly a bit of a hack, but
> it makes sense, since DAD and router solicitation do rely on multicast.

I disagree.  The node MUST NOT assign live address on
that interface.

Further analysis is needed, but one idea is to skip
addrconf_dev_config() if !(dev->flags & IFF_MULTICAST).

--yoshfuji

Re: [RFC IPv6] Disabling IPv6 autoconf

[David Miller]

From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST)

> Further analysis is needed, but one idea is to skip
> addrconf_dev_config() if !(dev->flags & IFF_MULTICAST).

Yes, it is logical because without multicast IPV6 cannot
work correctly.

But from another perspective (I assume these bridged Xen devices use
ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared
IFF_MULTICAST flag seems potentially problematic.  How many other
things break over such a device?

Re: [RFC IPv6] Disabling IPv6 autoconf

[Herbert Xu]

David Miller <davem@davemloft.net> wrote:
> 
> But from another perspective (I assume these bridged Xen devices use
> ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared
> IFF_MULTICAST flag seems potentially problematic.  How many other
> things break over such a device?

Netfilter is broken for a different reason.  It breaks because packets
pass through it twice, once going through brigde netfilter and once
through the Xen netloop interface.  So ideally they'd get rid of the
netloop device in which case they won't have to disable multicasting
on the bridge device anymore.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC IPv6] Disabling IPv6 autoconf

[Olaf Kirch]

On Tue, Aug 29, 2006 at 08:39:53PM +1000, Herbert Xu wrote:
> Netfilter is broken for a different reason.  It breaks because packets
> pass through it twice, once going through brigde netfilter and once
> through the Xen netloop interface.  So ideally they'd get rid of the
> netloop device in which case they won't have to disable multicasting
> on the bridge device anymore.

I agree, this would be the right long-term fix.

Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

Re: [RFC IPv6] Disabling IPv6 autoconf

[Pekka Savola]

On Tue, 29 Aug 2006, David Miller wrote:
> From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST)
>
>> Further analysis is needed, but one idea is to skip
>> addrconf_dev_config() if !(dev->flags & IFF_MULTICAST).
>
> Yes, it is logical because without multicast IPV6 cannot
> work correctly.
>
> But from another perspective (I assume these bridged Xen devices use
> ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared
> IFF_MULTICAST flag seems potentially problematic.  How many other
> things break over such a device?

It's not obvious that IFF_MULTICAST is good enough.  IMHO, you should 
be able to run addrconf on non-multicast interfaces as well (e.g., 
point-to-point interfaces, tunnels in particular).

It seems that current code already excludes IFF_NOARP interfaces 
though.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Re: [RFC IPv6] Disabling IPv6 autoconf

[Olaf Kirch]

On Tue, Aug 29, 2006 at 01:55:28PM +0300, Pekka Savola wrote:
> It's not obvious that IFF_MULTICAST is good enough.  IMHO, you should 
> be able to run addrconf on non-multicast interfaces as well (e.g., 
> point-to-point interfaces, tunnels in particular).

So would it work to use this?
	(flags & (IFF_MULTICAST|IFF_POINTOPOINT)) == 0

> It seems that current code already excludes IFF_NOARP interfaces 
> though.

I looked at that - it doesn't help because it just disables DAD, but
still does router solicitation, and I think it also sends a MLD listener
report with the bogus link-layer address. I tend to agree that it's
incorrect to assign an address at all in this case.

Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

Re: [RFC IPv6] Disabling IPv6 autoconf

[Peter Bieringer]

Pekka Savola schrieb:
> On Tue, 29 Aug 2006, David Miller wrote:
>> From: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>> Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST)
>>
>>> Further analysis is needed, but one idea is to skip
>>> addrconf_dev_config() if !(dev->flags & IFF_MULTICAST).
>>
>> Yes, it is logical because without multicast IPV6 cannot
>> work correctly.
>>
>> But from another perspective (I assume these bridged Xen devices use
>> ARPHRD_ETHER, do they?) a device with ARPHRD_ETHER and cleared
>> IFF_MULTICAST flag seems potentially problematic.  How many other
>> things break over such a device?
> 
> It's not obvious that IFF_MULTICAST is good enough.  IMHO, you should be
> able to run addrconf on non-multicast interfaces as well (e.g.,
> point-to-point interfaces, tunnels in particular).

Hmm, at least on RHEL4 (2.6.9):

1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
4: sit0: <NOARP> mtu 1480 qdisc noop
5: sit1@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 3
8: tun6to4@NONE: <NOARP,UP> mtu 1480 qdisc noqueue


And contributed from FC5:

5: vmnet8: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen
1000
7: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc
pfifo_fast qlen 100


ppp0, tun0 has IFF_MULTICAST set, so not an issue.

> It seems that current code already excludes IFF_NOARP interfaces though.

So 6-in-4 tunnels are already except.


Don't wonder about Flag "10000", missing support in "ip", already
reported https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202199 and
fixed in rawhide.


Just my 2 cents,

	Peter
-- 
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                       mailto:pb@bieringer.de
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/
OpenBC                    http://www.openbc.com/hp/Peter_Bieringer/
Personal invitation to OpenBC  http://www.openbc.com/go/invita/3889

Re: [RFC IPv6] Disabling IPv6 autoconf

[Alexey Kuznetsov]

Hello!

> Yes, it is logical because without multicast IPV6 cannot
> work correctly.

This is not quite true. IFF_BROADCAST is enough, it will work just
like IPv4.

Real troubles start only when interface is not IFF_BROADCAST and not
IFF_POINTOPOINT.


> IFF_MULTICAST flag seems potentially problematic.  How many other
> things break over such a device?

Nothing should break. IFF_MULTICAST is an advisory flag, saying
mostly "You do not want to stream high bandwidth multicast video here".
So that, it can be used to block autoconfiguration.

It does not change the fact that Xen device makes something profoundly
wrong. IPv6 autoconfiguration is _auto_configuration. It is triggered
only for a few of media types, for which autoconfiguration is prescribed
by corresponding RFCs. Ethernet is one of them.

If Xen does not support the things, which are required for each
ethernet device, it should not be ARPHRD_ETHER. If it wants to pretend
to be ARPHRD_ETHER, it must support basic ethernet functions, which IMHO
is so _easy_, that the question does not even makes sense.

Alexey

Re: [RFC IPv6] Disabling IPv6 autoconf

[Olaf Kirch]

On Tue, Aug 29, 2006 at 06:34:26PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> > The attached tentative patch makes IPv6 autoconf depend on the
> > availability of IFF_MULTICAST. This is admittedly a bit of a hack, but
> > it makes sense, since DAD and router solicitation do rely on multicast.
> 
> I disagree.  The node MUST NOT assign live address on
> that interface.

I'm not sure I understand. The Xen bridge devices get fe:ff:ff:ff:ff:ff
as MAC address.  Which is a bit hackish, but that seems to be the way
the Xen folks want to do it.

OTOH they do not want to do any IPv6 autoconfiguration with these
addresses, because they generate DAD warnings, and cause one
random machine to obtain fe80::ffff:ffff:feff:ffff as link-local
address.

> Further analysis is needed, but one idea is to skip
> addrconf_dev_config() if !(dev->flags & IFF_MULTICAST).

That should work just as well. Do you want me to submit an
updated patch?

Thanks,
Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

Re: [RFC IPv6] Disabling IPv6 autoconf

[Stephen Hemminger]

On Tue, 29 Aug 2006 12:44:18 +0200
Olaf Kirch <okir@suse.de> wrote:

> On Tue, Aug 29, 2006 at 06:34:26PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> > > The attached tentative patch makes IPv6 autoconf depend on the
> > > availability of IFF_MULTICAST. This is admittedly a bit of a hack, but
> > > it makes sense, since DAD and router solicitation do rely on multicast.
> > 
> > I disagree.  The node MUST NOT assign live address on
> > that interface.
> 
> I'm not sure I understand. The Xen bridge devices get fe:ff:ff:ff:ff:ff
> as MAC address.  Which is a bit hackish, but that seems to be the way
> the Xen folks want to do it.

They should be using random_ether_addr() or putting some per instance
specific info into the address.

-- 
Stephen Hemminger <shemminger@osdl.org>

Re: [RFC IPv6] Disabling IPv6 autoconf

[Hasso Tepper]

Olaf Kirch wrote:
> When the Xen people looked for a way to disable IPv6 autoconf of the
> bridge, they didn't find any way to do it without bringing up the
> device first (and thereby triggering DAD).

Because no /proc/sys/net/ipv6/conf/<interface> exist (yes, I know it's 
user visible effect)? This is just odd IMHO. I asked why it was changed 
and how userspace should behave now regarding this, but got no answer.

Simple scenario with GNU/Debian:

Computer is booted with no ethernet link. Ethernet interface should get 
address via autoconf. No link => no IPv6 addresses on interface => 
no /proc/sys/net/ipv6/conf/<interface>. Bootup scripts (procps.sh reading 
sysctl.conf existing in most of distributions AFAIK) can't set/get 
anything in /proc/sys/net/ipv6/conf/<interface> because it doesn't exist.

How userspace should behave now? Mandating daemon which listens interface 
events via netlink?


regards,

-- 
Hasso Tepper

Re: [RFC IPv6] Disabling IPv6 autoconf

[Peter Bieringer]

Hasso Tepper schrieb:
> Olaf Kirch wrote:
>> When the Xen people looked for a way to disable IPv6 autoconf of the
>> bridge, they didn't find any way to do it without bringing up the
>> device first (and thereby triggering DAD).
> 
> Because no /proc/sys/net/ipv6/conf/<interface> exist (yes, I know it's 
> user visible effect)? This is just odd IMHO. I asked why it was changed 
> and how userspace should behave now regarding this, but got no answer.
> 
> Simple scenario with GNU/Debian:
> 
> Computer is booted with no ethernet link. Ethernet interface should get 
> address via autoconf. No link => no IPv6 addresses on interface => 
> no /proc/sys/net/ipv6/conf/<interface>. Bootup scripts (procps.sh reading 
> sysctl.conf existing in most of distributions AFAIK) can't set/get 
> anything in /proc/sys/net/ipv6/conf/<interface> because it doesn't exist.
> 
> How userspace should behave now? Mandating daemon which listens interface 
> events via netlink?

BTW: this is also the reason why autoconf or accept_ra cannot be
disabled by e.g. initscripts *per* interface before bringing one up.

This issue was discussed some time ago with Pekka and reported in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809

There is still no solution for that afaik.

	Peter
-- 
Dr. Peter Bieringer                     http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D                       mailto:pb@bieringer.de
Deep Space 6 Co-Founder and Core Member  http://www.deepspace6.net/
OpenBC                    http://www.openbc.com/hp/Peter_Bieringer/
Personal invitation to OpenBC  http://www.openbc.com/go/invita/3889

Re: [RFC IPv6] Disabling IPv6 autoconf

[Herbert Xu]

Peter Bieringer <pb@bieringer.de> wrote:
>
>> anything in /proc/sys/net/ipv6/conf/<interface> because it doesn't exist.
>> 
>> How userspace should behave now? Mandating daemon which listens interface 
>> events via netlink?
> 
> BTW: this is also the reason why autoconf or accept_ra cannot be
> disabled by e.g. initscripts *per* interface before bringing one up.

You can disable it in /proc/sys/net/ipv6/conf/default/... and then
reenable it on the interfaces that you actually want.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC IPv6] Disabling IPv6 autoconf

[Hasso Tepper]

Herbert Xu wrote:
> Peter Bieringer <pb@bieringer.de> wrote:
> > BTW: this is also the reason why autoconf or accept_ra cannot be
> > disabled by e.g. initscripts *per* interface before bringing one up.
>
> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> reenable it on the interfaces that you actually want.

You can't do that either (ie. reenable) in initscripts before link is up.


regards,

-- 
Hasso

Re: [RFC IPv6] Disabling IPv6 autoconf

[Herbert Xu]

Hasso Tepper <hasso@estpak.ee> wrote:
>
>> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
>> reenable it on the interfaces that you actually want.
> 
> You can't do that either (ie. reenable) in initscripts before link is up.

As soon as you do ifconfig ethX up it'll appear in /proc/sys and
you can reenable it.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [RFC IPv6] Disabling IPv6 autoconf

[YOSHIFUJI Hideaki / 吉藤英明]

In article <E1GIDgg-00043h-00@gondolin.me.apana.org.au> (at Wed, 30 Aug 2006 10:12:10 +1000), Herbert Xu <herbert@gondor.apana.org.au> says:

> Hasso Tepper <hasso@estpak.ee> wrote:
> >
> >> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> >> reenable it on the interfaces that you actually want.
> > 
> > You can't do that either (ie. reenable) in initscripts before link is up.
> 
> As soon as you do ifconfig ethX up it'll appear in /proc/sys and
> you can reenable it.

The point is:

 - Until we have live address(es), we do not create inet6_dev{} for that
   device.
 - We do NOT run DAD until the link is ready (netif_carrier_ok()).

This means, we do NOT have any addresses until the link is once up,
and thus, because the sysctl entries live in inet6_dev{}, we do not
install net.ipv6.conf.ethX from values of net.ipv6.conf.default until
then.

Maybe, we can install inet6_dev{} without any IPv6 addresses when we
are bringing up the device before we start DAD.

--yoshfuji

Re: [RFC IPv6] Disabling IPv6 autoconf

[Hasso Tepper]

Herbert Xu wrote:
> Hasso Tepper <hasso@estpak.ee> wrote:
> >> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> >> reenable it on the interfaces that you actually want.
> >
> > You can't do that either (ie. reenable) in initscripts before link is
> > up.
>
> As soon as you do ifconfig ethX up it'll appear in /proc/sys and
> you can reenable it.

Only if you have addresses on it. Point is that you haven't any if 
autoconf is used (no manually configured addresses) and carrier is down 
(no cable or smth). Even link-local address is created after first 
carrier up event.

And problem isn't specific to IPv6, there is same problem with IPv4. For 
example if carrier aware network configuration method is used (as 
nowadays common Networkmanager is).

regards,

-- 
Hasso Tepper

Re: [RFC IPv6] Disabling IPv6 autoconf

[Thomas Graf]

* Olaf Kirch <okir@suse.de> 2006-08-29 10:24
> we had bug reports from people seeing lots of spurious messages
> like the following:
> 
> kernel: peth0: received packet with own address as source address.
> 
> and
> 
> xenbr0: duplicate address detected!
> 
> This is on a Xen enabled machine, with lots of Xen machines on the
> same network.
> 
> When the Xen code configures the bridge device, this will do IPv6
> autoconfiguration for the interface, and since they use synthetic MAC
> addresses, there will be DAD collisions.
> 
> When the Xen people looked for a way to disable IPv6 autoconf of the
> bridge, they didn't find any way to do it without bringing up the
> device first (and thereby triggering DAD).

They didn't find any because there is no need to disable it. I
hardly think that the network stack should fix things that Xen
got wrong. Setting dev_addr to -1 is just plain wrong, other
virtual ethernet devices call random_ether_addr(), it's not a
new problem at all.

Re: [RFC IPv6] Disabling IPv6 autoconf

[Olaf Kirch]

On Tue, Aug 29, 2006 at 08:10:21PM +0200, Thomas Graf wrote:
> > When the Xen people looked for a way to disable IPv6 autoconf of the
> > bridge, they didn't find any way to do it without bringing up the
> > device first (and thereby triggering DAD).
> 
> They didn't find any because there is no need to disable it. I

Well, as a global statement that may merit a separate debate.
In this specific case, maybe.

First off, I do agree that the use of a constant MAC address across the
board is a bad move :)

OTOH, there are good reasons why you want to turn off autoconf on
specific devices; and the current method of first bringing up
the device and then disabling it doesnt quite cut it.

One could also argue that there's a good reason to not assign addresses
to pure bridge devices at all, regardless of their brokenness.
We don't want to assign IPv4 addresses to a pure bridge, and I think it's
a reasonable expectation that there should be a way to tell the IPv6
stack to keep its hands off that device, too.

> got wrong. Setting dev_addr to -1 is just plain wrong, other
> virtual ethernet devices call random_ether_addr(), it's not a
> new problem at all.

Okay, fine with me - maybe we can convince them to use that
instead.

Thanks for the feedback,
Olaf
-- 
Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
okir@suse.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax