Description of problem:
A bridged interface, configured like:
When the network is started, the bridged interface is assigned a IPv6 link
address of fe80::200:ff:fe00:0/64 - the link address is taken from the MAC
address of the interface and at time of assignment the MAC of a bridge is
obviously 00:00:00:00:00:00. If you have two machines with bridges attached to
the same network this is very bad since both machines have the same link address.
The attached patch fixes the problem by cycling the bridge interface down/up
when an interface is added to it - this causes the link address to be reassigned
using the newly assigned MAC address.
As a side note, don't the RFCs require that machines with the same link
addresses on the same network must automagically reassign their addresses to
avoid the conflict? The Linux kernel doesn't appear to do this and instead just
complains in dmesg if it sees another machine on the same address.
Version-Release number of selected component (if applicable):
Almost always - I have once seen it assign the address correctly but I've not
been able to reproduce the correct behaviour.
Steps to Reproduce:
1. Configure bridged interfaces as described above
IPv6 link local address incorrectly set to fe80::200:ff:fe00:0/64 on bridge
IPv6 link local address should be set to a unique address.
Created attachment 111372 [details]
Fix for bug
Oops, urrm - the "fix" I attached of course destroys all the routing associated
with the interface when it takes it down. This may not be as easy to fix as I
Sounds more like a kernel bug to me. We probably shouldn't assign a link-local
address when the bridge has no devices and hence an all-zero MAC address. We
should assign the link-local address when the first device is added.
The fix is probably to do something like:
1) Record link-level address at time of ipv6 link-level address
2) Add a device event notifier to ipv6
3) In the device notifier, if the remembered link-level address
has changed, update the IPV6 link-level address.
For step #3, simply removing the old then adding the new one should
take care of all local-network route issues.
I don't have time to code up such a change, but I'll happily review
and integrate one written by others.
Further discussion belongs on email@example.com
OK. As such, closing this bug as UPSTREAM, as it needs to be tackled in the