Bug 149603 - Incorrect IPv6 link address assigned to bridge interfaces
Incorrect IPv6 link address assigned to bridge interfaces
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-24 07:57 EST by Steve Hill
Modified: 2014-03-16 22:52 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-03 21:01:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 07:57 EST, Steve Hill
no flags Details | Diff

  None (edit)
Description Steve Hill 2005-02-24 07:57:52 EST
Description of problem:
A bridged interface, configured like:

ifcfg-br0:
  DEVICE=br0
  ONBOOT=yes
  TYPE=Bridge

ifcfg-eth2:
  DEVICE=eth2
  ONBOOT=yes
  BRIDGE=br0

ifcfg-eth3:
  DEVICE=eth3
  ONBOOT=yes
  BRIDGE=br0

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):
initscripts-7.93.5-1

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
interface.

Expected results:
IPv6 link local address should be set to a unique address.
Comment 1 Steve Hill 2005-02-24 07:57:52 EST
Created attachment 111372 [details]
Fix for bug
Comment 2 Steve Hill 2005-02-24 08:11:48 EST
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 13:00:18 EST
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.

DaveM?
Comment 4 David Miller 2005-10-03 19:14:21 EDT
The fix is probably to do something like:

1) Record link-level address at time of ipv6 link-level address
   assignment
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-03 21:01:14 EDT
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.