Bug 149603

Summary: Incorrect IPv6 link address assigned to bridge interfaces
Product: [Fedora] Fedora Reporter: Steve Hill <steve>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED UPSTREAM QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: davem, dwmw2, dwmw2, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-04 01:01:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Fix for bug none

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

DaveM?
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
   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.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.