radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+
Subsystems (2)
I'm seeing something strange. I'm running radvd on a VETH interface (veth0 for argument) with a single global IPv6 address (and a link-local address).
On hacked 2.6.31, this works as I expect: The veth0 interface does not gain or lose any IPv6 addresses and peer VETH port gets an auto-created IPv6 addresses.
On hacked 2.6.34 and 2.6.36 kernels, however, the veth0 gains a new address that appears to be generated similar to other IPs associated with auto-creation via radvd.
I have not yet tested intervening kernels or physical interfaces between two machines.
So, the question is: Is the new behaviour on purpose, or is it a regression bug?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 14 lines · Ben Greear
I'm seeing something strange. I'm running radvd on a VETH interface (veth0 for argument)
with a single global IPv6 address (and a link-local address).On hacked 2.6.31, this works as I expect: The veth0 interface does not gain or lose any
IPv6 addresses and peer VETH port gets an auto-created IPv6 addresses.On hacked 2.6.34 and 2.6.36 kernels, however, the veth0 gains a new address that appears
to be generated similar to other IPs associated with auto-creation via radvd.
Quoted 5 lines
I have not yet tested intervening kernels or physical interfaces between two machines.
So, the question is: Is the new behaviour on purpose, or is it a regression bug?
Actually, this doesn't seem to work for 2.6.31 either, so I guess it isn't a regression.
Is it expected behaviour, however?
Thanks,
Ben
Quoted 4 lines
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 5 lines · Ben Greear
Quoted 5 lines
On hacked 2.6.34 and 2.6.36 kernels, however, the veth0 gains a new address that appears to be generated similar to other IPs associated with auto-creation via radvd.
I have not yet tested intervening kernels or physical interfaces between two machines.
Quoted 7 lines
Quoted 2 lines
So, the question is: Is the new behaviour on purpose, or is it a regression bug?
Actually, this doesn't seem to work for 2.6.31 either, so I guess it isn't a regression.
Is it expected behaviour, however?
I would not be surprised if the IPv6 stack on Linux would gain IPv6 addresses using SLAAC from any interface if it sees RAs on it, regardless if these are locally generated or not.
I guess any Linux device running radvd should turn off autoconf on those interface that radvd is acting on?
net.ipv6.conf.veth0.accept_ra=0 should do the trick?
Signature · 1 line
Mikael Abrahamsson email: [email protected]
Quoted 8 lines · Mikael Abrahamsson
I would not be surprised if the IPv6 stack on Linux would gain IPv6 addresses using SLAAC from any interface if it sees RAs on it, regardless if these are locally generated or not.
I guess any Linux device running radvd should turn off autoconf on those interface that radvd is acting on?
net.ipv6.conf.veth0.accept_ra=0 should do the trick?
I believe radvd will turn-on IPv6 forwarding on all the interfaces, at least it does on Debian in /etc/init.d/radvd, which essentially disables the reception of RA's for address configuration purposes. I'm curious what these values are set to, and if something just got missed.
It might be something specific to veth too, not sure how packets are copied/looped-back on these devices from the stack.
-Brian
Quoted 10 lines · Brian Haley
Quoted 8 lines · Mikael Abrahamsson
I would not be surprised if the IPv6 stack on Linux would gain IPv6 addresses using SLAAC from any interface if it sees RAs on it, regardless if these are locally generated or not.
I guess any Linux device running radvd should turn off autoconf on those interface that radvd is acting on?
net.ipv6.conf.veth0.accept_ra=0 should do the trick?
Quoted 7 lines
I believe radvd will turn-on IPv6 forwarding on all the interfaces, at least it does on Debian in
/etc/init.d/radvd, which essentially disables the reception of RA's for address configuration purposes. I'm curious what these values are set to, and if something just got missed.It might be something specific to veth too, not sure how packets are copied/looped-back on these devices from the stack.
It's reproducible on standard Ethernet interfaces connected to a different machine (and one that is not running radvd or anything special).
I'll double-check that we have forwarding enabled, though I'm pretty sure we do.
Thanks,
Ben
Quoted 2 lines
-Brian
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
Quoted 10 lines · Brian Haley
Quoted 8 lines · Mikael Abrahamsson
I would not be surprised if the IPv6 stack on Linux would gain IPv6 addresses using SLAAC from any interface if it sees RAs on it, regardless if these are locally generated or not.
I guess any Linux device running radvd should turn off autoconf on those interface that radvd is acting on?
net.ipv6.conf.veth0.accept_ra=0 should do the trick?
Quoted 7 lines
I believe radvd will turn-on IPv6 forwarding on all the interfaces, at least it does on Debian in
/etc/init.d/radvd, which essentially disables the reception of RA's for address configuration purposes. I'm curious what these values are set to, and if something just got missed.It might be something specific to veth too, not sure how packets are copied/looped-back on these devices from the stack.
Thanks for the hint. I did not have ipv6 forwarding enabled for the radvd interfaces. Once I fixed that, it worked as expected with no auto-created global IPv6 address. I have been starting radvd manually, so I wouldn't benefit from any OS specific start scripts.
Thanks,
Ben
Quoted 2 lines
-Brian
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com