Bug 149603 - Incorrect IPv6 link address assigned to bridge interfaces
Summary: Incorrect IPv6 link address assigned to bridge interfaces
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-24 12:57 UTC by Steve Hill
Modified: 2014-03-17 02:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-04 01:01:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fix for bug (573 bytes, patch)
2005-02-24 12:57 UTC, Steve Hill
no flags Details | Diff

Description Steve Hill 2005-02-24 12:57:52 UTC
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):

How reproducible:
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
Actual results:
IPv6 link local address incorrectly set to fe80::200:ff:fe00:0/64 on bridge

Expected results:
IPv6 link local address should be set to a unique address.

Comment 1 Steve Hill 2005-02-24 12:57:52 UTC
Created attachment 111372 [details]
Fix for bug

Comment 2 Steve Hill 2005-02-24 13:11:48 UTC
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
thought :(

Comment 3 David Woodhouse 2005-02-24 18:00:18 UTC
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.


Comment 4 David Miller 2005-10-03 23:14:21 UTC
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 netdev@vger.kernel.org

Comment 5 Bill Nottingham 2005-10-04 01:01:14 UTC
OK. As such, closing this bug as UPSTREAM, as it needs to be tackled in the
upstream kernel.

Note You need to log in before you can comment on or make changes to this bug.