Disabling IPv6 autoconf

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
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

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.

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

Index: 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;
 

In article <[email protected]> (at Tue, 29 Aug 2006 10:24:35 +0200), Olaf Kirch <[email protected]> says:

:

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

From: YOSHIFUJI Hideaki <[email protected]>
Date: Tue, 29 Aug 2006 18:34:26 +0900 (JST)

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?

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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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.

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
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

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

Olaf

Olaf Kirch   |  --- o --- Nous sommes du soleil we love when we play
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

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

So would it work to use this?

	(flags & (IFF_MULTICAST|IFF_POINTOPOINT)) == 0

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
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

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.

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:[email protected]
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

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

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:[email protected]
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

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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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

regards,

Hasso

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

Stephen Hemminger <[email protected]>

Hello!

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.

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

* Olaf Kirch <[email protected]> 2006-08-29 10:24

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.

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.

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
[email protected] |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

In article <[email protected]> (at Wed, 30 Aug 2006 10:12:10 +1000), Herbert Xu <[email protected]> says:

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

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