radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

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

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

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

[Ben Greear]

On 11/05/2010 02:24 PM, Ben Greear wrote:
>
> 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?

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

>
> Thanks,
> Ben
>


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

[Mikael Abrahamsson]

On Fri, 5 Nov 2010, Ben Greear wrote:

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

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

[Brian Haley]

On 11/06/2010 02:17 AM, Mikael Abrahamsson wrote:
> 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

Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

[Ben Greear]

On 11/08/2010 07:54 AM, Brian Haley wrote:
> On 11/06/2010 02:17 AM, Mikael Abrahamsson wrote:
>> 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.

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

>
> -Brian


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: radvd and auto-ipv6 address regression from 2.6.31 to 2.6.34+

[Ben Greear]

On 11/08/2010 07:54 AM, Brian Haley wrote:
> On 11/06/2010 02:17 AM, Mikael Abrahamsson wrote:
>> 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.

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

>
> -Brian


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com