Fw: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

Fw: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[Andrew Morton]

Begin forwarded message:

Date: Thu, 10 Feb 2005 00:00:14 -0800
From: bugme-daemon@osdl.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts


http://bugme.osdl.org/show_bug.cgi?id=4189

           Summary: IPv6 link local addresses are not assigned correctly on
                    multiple-bonding enviromrnts
    Kernel Version: 2.6.10
            Status: NEW
          Severity: normal
             Owner: yoshfuji@linux-ipv6.org
         Submitter: ikebe.takashi@lab.ntt.co.jp


Distribution:Fedora core 3
Hardware Environment: x86, x86_64, NIC is e1000 x4
Software Environment: kernel 2.6.10
Problem Description:
IPv6 link local addresses are not assigned correctly on multiple-bonding
enviromrnts.
Same link local address is assigned to bond0 & bond1

bond0     Link encap:Ethernet  HWaddr 00:04:23:A8:F7:78
          inet addr:129.60.11.15  Bcast:129.60.11.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:4109866 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2624 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:360539888 (343.8 MiB)  TX bytes:352807 (344.5 KiB)

bond1     Link encap:Ethernet  HWaddr 00:04:23:A8:F7:79
          inet addr:129.60.11.21  Bcast:129.60.11.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:2483103 errors:0 dropped:0 overruns:0 frame:0
          TX packets:378 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:221572495 (211.3 MiB)  TX bytes:47244 (46.1 KiB)

In the source, net/ipv6/addrconf.c, there is a function;
static int ipv6_generate_eui64(u8 *eui, struct net_device *dev)

It create ipv6 address from MAC address, however it seems dev->dev_addr is "0"
in the case of bonding.

Steps to reproduce:
1.set the multiple bonding to the machine.
(In my case, set 4 nics to use the bonding, and set the double bond as following
modprobe.conf.
alias bond0 bonding
options bond0 miimon=100 mode=1 max_bonds=2
options bond1 -o bonding1 miimon=100 mode=1
)
2.start the network.
3.show /sbin/ifconfig and check link local address.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20050210002356.500401f7.akpm@osdl.org> (at Thu, 10 Feb 2005 00:23:56 -0800), Andrew Morton <akpm@osdl.org> says:

> http://bugme.osdl.org/show_bug.cgi?id=4189
> 
>            Summary: IPv6 link local addresses are not assigned correctly on
>                     multiple-bonding enviromrnts
>     Kernel Version: 2.6.10
>             Status: NEW
>           Severity: normal
>              Owner: yoshfuji@linux-ipv6.org
>          Submitter: ikebe.takashi@lab.ntt.co.jp
:
> It create ipv6 address from MAC address, however it seems dev->dev_addr is "0"
> in the case of bonding.

I don't think it is the case.

> Steps to reproduce:
> 1.set the multiple bonding to the machine.
> (In my case, set 4 nics to use the bonding, and set the double bond as following
> modprobe.conf.

This is the key. That we do is:

# ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned
# ifenslave bond0 eth0 ...

IPv6 Link-local address is configured just after the
corresponding device is enabled. MAC should be configured
before you bring up the interface.

So, currently, you need to do this:

# ip link set bond0 address 00:01:02:03:04:05
# ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned
# ifenslave bond0 eth0 ...

BTW, why is it required to bring up bonding device before its configuratoin?
Ethernet devices is not allowed to change its MAC during it is up.

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[YOSHIFUJI Hideaki / 吉藤英明]

Sorry for typo...

In article <20050210.182225.07335127.yoshfuji@linux-ipv6.org> (at Thu, 10 Feb 2005 18:22:25 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:

> So, currently, you need to do this:
> 
> # ip link set bond0 address 00:01:02:03:04:05
> # ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned
                              fe80::201:02ff:fe03:0405 is assigned
> # ifenslave bond0 eth0 ...

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[Takashi Ikebe]

I think this cause by network init script.
network init script always bring up ifcfg-[A-Za-z0-9\._-],
so ifcfg-bond* always bring up before ifcfg-eth*! ("b" is before "e" in
alphabet order!)
I see, this is not a kernel issue, and this is initscript issue.


YOSHIFUJI Hideaki / 吉藤英明 wrote:
> Sorry for typo...
> 
> In article <20050210.182225.07335127.yoshfuji@linux-ipv6.org> (at Thu, 10 Feb 2005 18:22:25 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:
> 
> 
>>So, currently, you need to do this:
>>
>># ip link set bond0 address 00:01:02:03:04:05
>># ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned
> 
>                               fe80::201:02ff:fe03:0405 is assigned
> 
>># ifenslave bond0 eth0 ...
> 
> 


-- 
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : ikebe.takashi@lab.ntt.co.jp

Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[Jay Vosburgh]

YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote:

>> It create ipv6 address from MAC address, however it seems dev->dev_addr is "0"
>> in the case of bonding.
>
>I don't think it is the case.

	Given the below sequence, i.e., ifconfig bond0 up before
ifenslave, then, yes, the dev_addr is all zeroes when the ifconfig up
happens.  The bonding master device (bond0) uses the ethernet address of
the first slave to be added, so if there are no slaves, the dev_addr is
all zeros.

># ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned
># ifenslave bond0 eth0 ...
>
>IPv6 Link-local address is configured just after the
>corresponding device is enabled. MAC should be configured
>before you bring up the interface.
>
>So, currently, you need to do this:
>
># ip link set bond0 address 00:01:02:03:04:05
># ifconfig bond0 up <= here fe80::200:ff:fe00:0/64 is assigned
># ifenslave bond0 eth0 ...
>
>BTW, why is it required to bring up bonding device before its configuratoin?

	I can't say for sure why it was originally done that way, but a
lot of initialization in done in the device open function, and that
happens at "ifconfig up" time.  For IPv4 it's not a problem (nothing
really happens at "ifconfig bond0 up", the device can't really
communicate until at least one slave is added, and the MAC address can
be gleaned at that time).  The general model for bonding is that down
means "no slaves," so "ifconfig bond0 down" releases the slaves (and the
module can be removed at that point).

	The model used by the bridge device is probably a better way to
go, particularly given that IPv6 link local addresses are created at
"ifconfig up" time.  In that case, bonding would insist on having at
least one slave before ifconfig up can succeed, and a ifconfig down
wouldn't necessarily release the slaves (although that part can be more
flexible; we could preserve the current "ifconfig down releases all
slaves" behavior).

	Changing this is a significant change to the user interface.
Making it backwards compatible with the current scheme while still
preventing users from ending up with bogus IPv6 link local addresses
seems difficult (I can't think of a way offhand; one method requires
that ifenslave happen before ifconfig up, the other requires the
opposite).

	I'll have to give this some thought; it will have to change
somehow, since IPv6 doesn't work properly with the current scheme.

>Ethernet devices is not allowed to change its MAC during it is up.

	Some of the bonding modes alter a slave's MAC addresses while
up, typically to have a slave masquerade as one of the other slaves (if,
e.g., the other slave fails).  Not all of the device drivers support
this, so it doesn't work with all devices.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[David S. Miller]

On Thu, 10 Feb 2005 10:17:06 -0800
Jay Vosburgh <fubar@us.ibm.com> wrote:

> 	The model used by the bridge device is probably a better way to
> go, particularly given that IPv6 link local addresses are created at
> "ifconfig up" time.

IPv6 should catch an event when MAC addresses change, to reassign
to correct link local address.  I don't think the bonding driver
needs to change at all.

IPv6 needs to fix this issue, regardless of bonding.  It is perfectly
legal to change MAC addresses while a link is still up.

Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[Rick Jones]

 >IPv6 should catch an event when MAC addresses change, to reassign
> to correct link local address.  I don't think the bonding driver
> needs to change at all.
> 
> IPv6 needs to fix this issue, regardless of bonding.  It is perfectly
> legal to change MAC addresses while a link is still up.

This may seem a silly question, but what happens to existing TCP connections 
when the IPv6 link local address changes?

rick jones

Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[Jay Vosburgh]

David S. Miller <davem@davemloft.net> wrote:

>On Thu, 10 Feb 2005 10:17:06 -0800
>Jay Vosburgh <fubar@us.ibm.com> wrote:
>
>> 	The model used by the bridge device is probably a better way to
>> go, particularly given that IPv6 link local addresses are created at
>> "ifconfig up" time.
>
>IPv6 should catch an event when MAC addresses change, to reassign
>to correct link local address.  I don't think the bonding driver
>needs to change at all.

	Except that most of the bonding internal MAC changes won't
generate any events (presuming you mean a NETDEV_CHANGEADDR).  The
bonding driver calls the slave's dev->set_mac_address directly; the
NETDEV_CHANGEADDR is generated by dev_ifsioc() (which isn't exported).
Now that I'm looking for it, there are some other cases of bonding
calling other dev->functions directly, e.g., change_mtu, that have
wrappers that generate events; I need to fix that.

	Would you have a problem with putting the SIOCSIFHWADDR code
from dev_ifsioc() into a separate exported function, similarly to how
dev_set_mtu() is done?  I can probably whip that up along with the
appropriate bonding changes this evening.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

Re: [Bonding-devel] Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[David S. Miller]

On Thu, 10 Feb 2005 18:40:29 -0800
Jay Vosburgh <fubar@us.ibm.com> wrote:

> 	Except that most of the bonding internal MAC changes won't
> generate any events (presuming you mean a NETDEV_CHANGEADDR).  The
> bonding driver calls the slave's dev->set_mac_address directly; the
> NETDEV_CHANGEADDR is generated by dev_ifsioc() (which isn't exported).
> Now that I'm looking for it, there are some other cases of bonding
> calling other dev->functions directly, e.g., change_mtu, that have
> wrappers that generate events; I need to fix that.
> 
> 	Would you have a problem with putting the SIOCSIFHWADDR code
> from dev_ifsioc() into a separate exported function, similarly to how
> dev_set_mtu() is done?  I can probably whip that up along with the
> appropriate bonding changes this evening.

That would be a great idea, as I read your first paragraph I was
going to suggest exactly this.

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[David S. Miller]

On Thu, 10 Feb 2005 18:22:25 +0900 (JST)
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B <yoshfuji@linux-ipv6.org> wrote:

> Ethernet devices is not allowed to change its MAC during it is up.

This is not true.

All ethernet drivers try to support this, and just about all do.
This is what dev->set_mac_address() driver routine implements.

I guess this causes problems for ipv6 local addresses, it
will need to catch some callback to handle these events and
thus adjust the local address properly.

This is the real bug in my opinion, ipv4 handles this situation
just fine.

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20050210122523.41276d5a.davem@davemloft.net> (at Thu, 10 Feb 2005 12:25:23 -0800), "David S. Miller" <davem@davemloft.net> says:

> I guess this causes problems for ipv6 local addresses, it
> will need to catch some callback to handle these events and
> thus adjust the local address properly.

Okay, I'll try to solve it:
1) catch NETDEV_CHANGEADDR
2) (try to) add new link-local address and deprecate old one.
3) (when DAD finishes) RS will be sent.

--yoshfuji

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[David S. Miller]

On Fri, 11 Feb 2005 09:29:16 +0900 (JST)
YOSHIFUJI Hideaki / ^[$B5HF#1QL@^[(B <yoshfuji@linux-ipv6.org> wrote:

> Okay, I'll try to solve it:
> 1) catch NETDEV_CHANGEADDR
> 2) (try to) add new link-local address and deprecate old one.
> 3) (when DAD finishes) RS will be sent.

Sounds perfect.

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[Rick Jones]

>>I guess this causes problems for ipv6 local addresses, it
>>will need to catch some callback to handle these events and
>>thus adjust the local address properly.
> 
> 
> Okay, I'll try to solve it:
> 1) catch NETDEV_CHANGEADDR
> 2) (try to) add new link-local address and deprecate old one.
> 3) (when DAD finishes) RS will be sent.

At present, for IPv4 if someone changes the MAC address of an interface, 
existing TCP connections don't really care right?  The ARP caches will be 
updated with a new IPv4 to MAC translation and happiness and joy ensues.

So, what would happen to TCP connections over IPv6 using link-local addresses? 
If the old address is taken away (deprecated), and a new address generated, 
doesn't that mean that TCP connections (using link-local addresses anyway) will 
fail on a MAC change?

rick jones

Re: [Bugme-new] [Bug 4189] New: IPv6 link local addresses are not assigned correctly on multiple-bonding enviromrnts

[YOSHIFUJI Hideaki / 吉藤英明]

In article <420C0D05.6020408@hp.com> (at Thu, 10 Feb 2005 17:40:21 -0800), Rick Jones <rick.jones2@hp.com> says:

> At present, for IPv4 if someone changes the MAC address of an interface, 
> existing TCP connections don't really care right?  The ARP caches will be 
> updated with a new IPv4 to MAC translation and happiness and joy ensues.
> 
> So, what would happen to TCP connections over IPv6 using link-local addresses? 
> If the old address is taken away (deprecated), and a new address generated, 
> doesn't that mean that TCP connections (using link-local addresses anyway) will 
> fail on a MAC change?

One thing: we won't delete it but deprecate it.

--yoshfuji