Re: PROBLEM: IPv6 autoconf/accept_ra default values

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[David Miller]

From: Kolbjørn Barmen <linux@kolla.no>
Date: Mon, 23 Feb 2009 15:42:41 +0100 (CET)

> 
> Hello
> 
> 1. Summary of problem

You'll get more replies if you contact the networking developers
at netdev@vger.kernel.org

> autoconfig and accept_ra is by default on (by the way of forwarning) -
> this is very problematic in many ways.
> 
> 2. Full description of the problem/report:
> 
> * if you want staticly only configured addresses/gateway (which is
>   something you just might want for server machines for example) you need
>   to change the sysctl parameters before the interface is brought up. 
>   (yes, I want staticly, and only staticly configured addresses, dont get
>   me started on why - keywords: source address, dns, ssl, access control)
> 
> * to change the default values, ipv6 module needs to be loaded, in many
>   distros this leads to race conditions, especially in these "autodetect
>   hardware and bring up everything magically" days :)
> 
> * if you netboot with ipv6 enabled kernel, interface will pick up ipv6
>   autoconf no matter, so you need to remove addresses and routes manually
>   after boot. As far as I know there is now kernel parameters to tell
>   kernel to not autoconf ipv6. I admit I have not tested out whether it's
>   possible to use ipv6-addresses as kernel parameters at all.
> 
> * ipv6 kernel module has no load paramters as far as I can tell?
> 
> * changing net.ipv6.conf.all.* and net.ipv6.conf.default.* dont work as
>   intended? I'm really not sure how this is meant to work, but intuitively
>   I would think that "...all.*" would affect all interfaces present, and
>   "...*.default.*" would set the default values for "future" interfaces.
>   Maybe I'm wrong? Look further down...
> 
> 3. Keywords
>    ipv6, forwarding, autoconf, accept_ra
> 
> 4. Kernel version (from /proc/version):
>    This goes accross all 2.6 kernels as far as I can tell, no matter what
>    distro.
> 
> 5. Output of Oops.. message
>    No oops so far :)
> 
> 6. A small shell script or example program which triggers the problem 
>    
>    root:~# sysctl net.ipv6.conf.all.accept_ra
>    net.ipv6.conf.all.accept_ra = 1
>    root:~# sysctl -w net.ipv6.conf.all.accept_ra=0
>    net.ipv6.conf.all.accept_ra = 0
>    root:~# sysctl net.ipv6.conf.eth0.accept_ra
>    net.ipv6.conf.all.accept_ra = 1
>    
> I suppose the above is fals behaviour? I'm really not sure, but if this is
> not a bug, then I fail to see the purpose of the "...all.*" and
> "...default.*" sysctl parameters. From the documentation
> (networking/ip-sysctl.txt) I get the impression that the above behaviour
> is wrong:
> 
> --- 
> conf/default/*:
>         Change the interface-specific default settings.
> 
> conf/all/*:
>         Change all the interface-specific settings.
> 
>         [XXX:  Other special features than forwarding?]
> ---
> 
> Looks like this is unclear for more than just me :)
> 
> 
> My personal oppinion is that anything ipv6 autoconfig/accept_ra should be
> default _off_, since this simplifies all the above mentioned issues, and
> it is incredibly easy to turn on again with systcl if people want it.
> It is much easier to enable ipv6 automagic than to disable it.
> At least there should be kernel/module parameter to set default behaviour.
> 
> Part of the problem with deploying IPv6 is due to "magic" like this, all
> the autoconfig/router announcement magic looks very well on paper and in
> theory, but out in the field it quickly leads to loads of totally
> unnecessary extra work, work that could easily be avoided if default
> behaviour was to have it off. It should be in the interest of IPv6
> advocates to support a "soft" transition from IPv4-only to dual-stack,
> fencing off unwanted "magic" only adds to the frustration for those who
> actually try to deploy it.
> 
> What do you think?
> 
> If there already is a simple stright forward solution, then I apologize
> for this rant - please enlighten me :)
> 
> -- kolla
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

PROBLEM: IPv6 autoconf/accept_ra default values

[Kolbjørn Barmen]

Hello

I was tipped by someone at linux-kernel@vger.kernel.org to post this to 
netdev@vger.kernel.org instead, so here goes...

1. Summary of problem

autoconfig and accept_ra is by default on (by the way of forwarning) -
this is very problematic in many ways.

2. Full description of the problem/report:

* if you want staticly only configured addresses/gateway (which is
  something you just might want for server machines for example) you need
  to change the sysctl parameters before the interface is brought up. 
  (yes, I want staticly, and only staticly configured addresses, dont get
  me started on why - keywords: source address, dns, ssl, access control)

* to change the default values, ipv6 module needs to be loaded, in many
  distros this leads to race conditions, especially in these "autodetect
  hardware and bring up everything magically" days :)

* if you netboot with ipv6 enabled kernel, interface will pick up ipv6
  autoconf no matter, so you need to remove addresses and routes manually
  after boot. As far as I know there is now kernel parameters to tell
  kernel to not autoconf ipv6. I admit I have not tested out whether it's
  possible to use ipv6-addresses as kernel parameters at all.

* ipv6 kernel module has no load paramters as far as I can tell?

* changing net.ipv6.conf.all.* and net.ipv6.conf.default.* dont work as
  intended? I'm really not sure how this is meant to work, but intuitively
  I would think that "...all.*" would affect all interfaces present, and
  "...*.default.*" would set the default values for "future" interfaces.
  Maybe I'm wrong? Look further down...

3. Keywords
   ipv6, forwarding, autoconf, accept_ra

4. Kernel version (from /proc/version):
   This goes accross all 2.6 kernels as far as I can tell, no matter what
   distro.

5. Output of Oops.. message
   No oops so far :)

6. A small shell script or example program which triggers the problem 
   
   root:~# sysctl net.ipv6.conf.all.accept_ra
   net.ipv6.conf.all.accept_ra = 1
   root:~# sysctl -w net.ipv6.conf.all.accept_ra=0
   net.ipv6.conf.all.accept_ra = 0
   root:~# sysctl net.ipv6.conf.eth0.accept_ra
   net.ipv6.conf.all.accept_ra = 1
   
I suppose the above is fals behaviour? I'm really not sure, but if this is
not a bug, then I fail to see the purpose of the "...all.*" and
"...default.*" sysctl parameters. From the documentation
(networking/ip-sysctl.txt) I get the impression that the above behaviour
is wrong:

--- 
conf/default/*:
        Change the interface-specific default settings.

conf/all/*:
        Change all the interface-specific settings.

        [XXX:  Other special features than forwarding?]
---

Looks like this is unclear for more than just me :)


My personal oppinion is that anything ipv6 autoconfig/accept_ra should be
default _off_, since this simplifies all the above mentioned issues, and
it is incredibly easy to turn on again with systcl if people want it.
It is much easier to enable ipv6 automagic than to disable it.
At least there should be kernel/module parameter to set default behaviour.

Part of the problem with deploying IPv6 is due to "magic" like this, all
the autoconfig/router announcement magic looks very well on paper and in
theory, but out in the field it quickly leads to loads of totally
unnecessary extra work, work that could easily be avoided if default
behaviour was to have it off. It should be in the interest of IPv6
advocates to support a "soft" transition from IPv4-only to dual-stack,
fencing off unwanted "magic" only adds to the frustration for those who
actually try to deploy it.

What do you think?

If there already is a simple stright forward solution, then I apologize
for this rant - please enlighten me :)

-- kolla

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[Kolbjørn Barmen]

On Tue, 24 Feb 2009, Kolbjørn Barmen wrote:

> 1. Summary of problem
> 
> autoconfig and accept_ra is by default on (by the way of forwarning) -
> this is very problematic in many ways.

[snip]

> My personal oppinion is that anything ipv6 autoconfig/accept_ra should be
> default _off_, since this simplifies all the above mentioned issues, and
> it is incredibly easy to turn on again with systcl if people want it.
> It is much easier to enable ipv6 automagic than to disable it.
> At least there should be kernel/module parameter to set default behaviour.
> 
> Part of the problem with deploying IPv6 is due to "magic" like this, all
> the autoconfig/router announcement magic looks very well on paper and in
> theory, but out in the field it quickly leads to loads of totally
> unnecessary extra work, work that could easily be avoided if default
> behaviour was to have it off. It should be in the interest of IPv6
> advocates to support a "soft" transition from IPv4-only to dual-stack,
> fencing off unwanted "magic" only adds to the frustration for those who
> actually try to deploy it.
> 
> What do you think?

Obviously noone really think much of this, one way or the other, so here's a
patch that changes the default values.

--------
--- linux/net/ipv6/addrconf.c.orig      2009-03-17 23:41:10.000000000 +0100
+++ linux/net/ipv6/addrconf.c   2009-03-17 23:42:18.000000000 +0100
@@ -157,9 +157,9 @@
        .forwarding             = 0,
        .hop_limit              = IPV6_DEFAULT_HOPLIMIT,
        .mtu6                   = IPV6_MIN_MTU,
-       .accept_ra              = 1,
+       .accept_ra              = 0,
        .accept_redirects       = 1,
-       .autoconf               = 1,
+       .autoconf               = 0,
        .force_mld_version      = 0,
        .dad_transmits          = 1,
        .rtr_solicits           = MAX_RTR_SOLICITATIONS,
@@ -192,9 +192,9 @@
        .forwarding             = 0,
        .hop_limit              = IPV6_DEFAULT_HOPLIMIT,
        .mtu6                   = IPV6_MIN_MTU,
-       .accept_ra              = 1,
+       .accept_ra              = 0,
        .accept_redirects       = 1,
-       .autoconf               = 1,
+       .autoconf               = 0,
        .dad_transmits          = 1,
        .rtr_solicits           = MAX_RTR_SOLICITATIONS,
        .rtr_solicit_interval   = RTR_SOLICITATION_INTERVAL,
--------

Cheers!

-- kolla

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[YOSHIFUJI Hideaki]

Hello.

In article <alpine.LNX.2.00.0903180200590.10453@firda.kolla.no> (at Wed, 18 Mar 2009 02:06:09 +0100 (CET)), Kolbjørn Barmen <linux@kolla.no> says:

> > My personal oppinion is that anything ipv6 autoconfig/accept_ra should be
> > default _off_, since this simplifies all the above mentioned issues, and
> > it is incredibly easy to turn on again with systcl if people want it.
> > It is much easier to enable ipv6 automagic than to disable it.
> > At least there should be kernel/module parameter to set default behaviour.
> > 
> > Part of the problem with deploying IPv6 is due to "magic" like this, all
> > the autoconfig/router announcement magic looks very well on paper and in
> > theory, but out in the field it quickly leads to loads of totally
> > unnecessary extra work, work that could easily be avoided if default
> > behaviour was to have it off. It should be in the interest of IPv6
> > advocates to support a "soft" transition from IPv4-only to dual-stack,
> > fencing off unwanted "magic" only adds to the frustration for those who
> > actually try to deploy it.
> > 
> > What do you think?
> 
> Obviously noone really think much of this, one way or the other, so here's a
> patch that changes the default values.

Default should be ON.

But I would agree to have some (relatively easy) way to disable
autoconfiguration.  Well yes, probably kernel module papameter.

Simple interface:
 - disable_ipv6=1
 - autoconf=0

Do anyone need more complex interface?
 - disable_ipv6={all|IF}:0,...
 - autoconf={all|IF}:0,...

--yoshfuji

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[David Miller]

From: YOSHIFUJI Hideaki <yoshfuji@st-paulia.net>
Date: Wed, 18 Mar 2009 12:33:08 +0900 (JST)

> In article <alpine.LNX.2.00.0903180200590.10453@firda.kolla.no> (at Wed, 18 Mar 2009 02:06:09 +0100 (CET)), Kolbjørn Barmen <linux@kolla.no> says:
> 
> > > My personal oppinion is that anything ipv6 autoconfig/accept_ra should be
> > > default _off_, since this simplifies all the above mentioned issues, and
> > > it is incredibly easy to turn on again with systcl if people want it.
> > > It is much easier to enable ipv6 automagic than to disable it.
> > > At least there should be kernel/module parameter to set default behaviour.
> > > 
> > > Part of the problem with deploying IPv6 is due to "magic" like this, all
> > > the autoconfig/router announcement magic looks very well on paper and in
> > > theory, but out in the field it quickly leads to loads of totally
> > > unnecessary extra work, work that could easily be avoided if default
> > > behaviour was to have it off. It should be in the interest of IPv6
> > > advocates to support a "soft" transition from IPv4-only to dual-stack,
> > > fencing off unwanted "magic" only adds to the frustration for those who
> > > actually try to deploy it.
> > > 
> > > What do you think?
> > 
> > Obviously noone really think much of this, one way or the other, so here's a
> > patch that changes the default values.
> 
> Default should be ON.

I absolutely agree.

It can't be called autoconfiguration if it's off by default, and
you have to "configure" something.

What are people smoking? :-)

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[Kolbjørn Barmen]

On Thu, 19 Mar 2009, David Miller wrote:

> From: YOSHIFUJI Hideaki <yoshfuji@st-paulia.net>
> Date: Wed, 18 Mar 2009 12:33:08 +0900 (JST)
> 
> > In article <alpine.LNX.2.00.0903180200590.10453@firda.kolla.no> (at
> > Wed, 18 Mar 2009 02:06:09 +0100 (CET)), Kolbjørn Barmen
> > <linux@kolla.no> says:
> > 
> > > > My personal oppinion is that anything ipv6 autoconfig/accept_ra
> > > > should be default _off_, since this simplifies all the above
> > > > mentioned issues, and it is incredibly easy to turn on again with
> > > > systcl if people want it.  It is much easier to enable ipv6
> > > > automagic than to disable it.  At least there should be
> > > > kernel/module parameter to set default behaviour.
> > > > 
> > > > Part of the problem with deploying IPv6 is due to "magic" like
> > > > this, all the autoconfig/router announcement magic looks very well
> > > > on paper and in theory, but out in the field it quickly leads to
> > > > loads of totally unnecessary extra work, work that could easily be
> > > > avoided if default behaviour was to have it off. It should be in
> > > > the interest of IPv6 advocates to support a "soft" transition from
> > > > IPv4-only to dual-stack, fencing off unwanted "magic" only adds to
> > > > the frustration for those who actually try to deploy it.
> > > > 
> > > > What do you think?
> > > 
> > > Obviously noone really think much of this, one way or the other, so here's a
> > > patch that changes the default values.
> > 
> > Default should be ON.
> 
> I absolutely agree.
> 
> It can't be called autoconfiguration if it's off by default, and
> you have to "configure" something.
> 
> What are people smoking? :-)

Reality?

Anyways, I'm overthrilled to actually see response, since this has been
pestering me (well, us), for years - configuring server with static
addresses is a real _pain_ if machine is located on a network where
autoconfigure and router announcements exist (or suddenly show up by
error due to someone untentionally configuring their machine as router,
some systems are even so clever that if they dont see router
announcements, they will assume all sorts of things and start acting as
6to4 router themselves - YAY! NOT!  People creating unintended network
loops on the switch panel is another classic, leaving all machiens with
double up of adresses and faulty default routes long after physical error
has been fixed - woohoo! Sheesh, I could go on all day long about what a
bad idea autoconf/accept_ra really is... :P )

I personally really dont care what is default as long as I have a _very
easy_ way to turn it off, kernel module paramters and boot parameters -
great! If the rest of the world has decided they want to fight this
manually by default, fine by me :)

How about the behaviour that I described:

    root:~# sysctl net.ipv6.conf.all.accept_ra 
    net.ipv6.conf.all.accept_ra = 1 
    root:~# sysctl -w net.ipv6.conf.all.accept_ra=0 
    net.ipv6.conf.all.accept_ra = 0 
    root:~# sysctl net.ipv6.conf.eth0.accept_ra 
    net.ipv6.conf.all.accept_ra = 1  

Is this intended behaviour or not? Bug or (mis)feature?

A few days ago I recieved mail from someone who was annoyed that even as
he changed the values with sysctl and restarted the interface, the old
addresses, routes etc were still up - yes, the lack of proper IPv6 support
in distros "network interface up/down" scripts is really tedious, and
there really is no easy way to "reset" ipv6 status on a machine, except
from doing it manually. I dont see any distro care much for IPv6 anytime
soon, so anything that can be done to ease IPv6 configuration is _very
much appreciated_ for those of us who actually run IPv6 in full
production.

Cheers!

-- 
Kolbjørn Barmen

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[Brian Haley]

Kolbjørn Barmen wrote:
> I personally really dont care what is default as long as I have a _very
> easy_ way to turn it off, kernel module paramters and boot parameters -
> great! If the rest of the world has decided they want to fight this
> manually by default, fine by me :)

I'll work on the module parameters Yoshifuji mentioned, the "harder" version
since to me it seems more useful.  Since it's of interest to you can you give me
some input?  Are the two parameters he described for this going to be good
enough for you?  I was thinking of also adding a "default" keyword to control
net.ipv6.conf.default.*, for example:

	disable_ipv6=all,default,eth0,eth1
	autoconf=all,default,eth2,eth3

This is because "default" is what's inherited by all the ethX values, "all" is
the big hammer.

And also adding an "enable_ipv6" one:

	enable_ipv6=lo,eth4,eth5

This would let you do:

	disable_ipv6=default
	enable_ipv6=lo,eth0

Which saves you from listing many interfaces:

	disable_ipv6=eth1,eth2,eth3,eth4....

Of course I could be over-thinking this and the simple solution could work just
fine:

	disable_ipv6=1
	autoconf=0

Then just let you put things in sysctl.conf to enable what you want.  I'll play
with that first to see if it's enough.

I'd rather get this right the first time...

> How about the behaviour that I described:
> 
>     root:~# sysctl net.ipv6.conf.all.accept_ra 
>     net.ipv6.conf.all.accept_ra = 1 
>     root:~# sysctl -w net.ipv6.conf.all.accept_ra=0 
>     net.ipv6.conf.all.accept_ra = 0 
>     root:~# sysctl net.ipv6.conf.eth0.accept_ra 
>     net.ipv6.conf.all.accept_ra = 1  
> 
> Is this intended behaviour or not? Bug or (mis)feature?

I *think* that's intended, at least it's one of the ways IPv6 differs from IPv4
- setting "all" doesn't reset to individual nic settings.  But the code in
ndisc_router_discovery() should probably check the "all" flag and drop the RA.
The other "all" sysctl's should behave the same, so someone needs to take a
deeper look.

-Brian

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[Kolbjørn Barmen]

On Fri, 20 Mar 2009, Brian Haley wrote:

> Kolbjørn Barmen wrote:
> > I personally really dont care what is default as long as I have a _very
> > easy_ way to turn it off, kernel module paramters and boot parameters -
> > great! If the rest of the world has decided they want to fight this
> > manually by default, fine by me :)
> 
> I'll work on the module parameters Yoshifuji mentioned, the "harder"
> version since to me it seems more useful.  Since it's of interest to you
> can you give me some input? 

Definetly! Thanks alot for the effort! :)

> Are the two parameters he described for this going to be good enough for
> you?  I was thinking of also adding a "default" keyword to control
> net.ipv6.conf.default.*, for example:
> 
> 	disable_ipv6=all,default,eth0,eth1
> 	autoconf=all,default,eth2,eth3
> 
> This is because "default" is what's inherited by all the ethX values,
> "all" is the big hammer.

This is still unclear for me. I've been assuming that by changing
"default" all future devices will inherit the value, but leaving existing
devices as is. "all" I've assumed takes all existing interfaces, but
leaving default as is. Is this what you are saying?

> And also adding an "enable_ipv6" one:
> 
> 	enable_ipv6=lo,eth4,eth5
> 
> This would let you do:
> 
> 	disable_ipv6=default
> 	enable_ipv6=lo,eth0
> 
> Which saves you from listing many interfaces:
> 
> 	disable_ipv6=eth1,eth2,eth3,eth4....
> 
> Of course I could be over-thinking this and the simple solution could work just
> fine:
> 
> 	disable_ipv6=1
> 	autoconf=0
> 
> Then just let you put things in sysctl.conf to enable what you want.  I'll play
> with that first to see if it's enough.

I think this would be enough yes. Probably best to think about how one
would be able to set boot paramets so that a machine gets static address
and no autoconf, for example for NFS-root etc. This falls under same
"mission"?

> I'd rather get this right the first time...

Ofcourse :)

> > How about the behaviour that I described:
> > 
> >     root:~# sysctl net.ipv6.conf.all.accept_ra 
> >     net.ipv6.conf.all.accept_ra = 1 
> >     root:~# sysctl -w net.ipv6.conf.all.accept_ra=0 
> >     net.ipv6.conf.all.accept_ra = 0 
> >     root:~# sysctl net.ipv6.conf.eth0.accept_ra 
> >     net.ipv6.conf.all.accept_ra = 1  
> > 
> > Is this intended behaviour or not? Bug or (mis)feature?
> 
> I *think* that's intended, at least it's one of the ways IPv6 differs from IPv4
> - setting "all" doesn't reset to individual nic settings.  But the code in
> ndisc_router_discovery() should probably check the "all" flag and drop the RA.
> The other "all" sysctl's should behave the same, so someone needs to take a
> deeper look.

OK, I have this weird feeling that this "worked" some years ago, but I
dont have any old systems to try out that theory on. I fail to see wht
purpose "all" has, if it isn't setting the value of all interfaces.

Again, thank you very much for looking into this! :)

-- kolla

Re: PROBLEM: IPv6 autoconf/accept_ra default values

[Brian Haley]

Kolbjørn Barmen wrote:
>> Are the two parameters he described for this going to be good enough for
>> you?  I was thinking of also adding a "default" keyword to control
>> net.ipv6.conf.default.*, for example:
>>
>> 	disable_ipv6=all,default,eth0,eth1
>> 	autoconf=all,default,eth2,eth3
>>
>> This is because "default" is what's inherited by all the ethX values,
>> "all" is the big hammer.
> 
> This is still unclear for me. I've been assuming that by changing
> "default" all future devices will inherit the value, but leaving existing
> devices as is. "all" I've assumed takes all existing interfaces, but
> leaving default as is. Is this what you are saying?

"default" is what's inherited by future devices, "all" is supposed to be the
over-ride for all devices, but doesn't change any device-specific values.

>> Of course I could be over-thinking this and the simple solution could work just
>> fine:
>>
>> 	disable_ipv6=1
>> 	autoconf=0
>>
>> Then just let you put things in sysctl.conf to enable what you want.  I'll play
>> with that first to see if it's enough.
> 
> I think this would be enough yes. Probably best to think about how one
> would be able to set boot paramets so that a machine gets static address
> and no autoconf, for example for NFS-root etc. This falls under same
> "mission"?

My patch wouldn't address getting a static address via a module parameter, that
can still be done in, for example, /etc/network/interfaces.  So no, this isn't
part of my "mission", just getting the basic functionality in place.

>>> How about the behaviour that I described:
>>>
>>>     root:~# sysctl net.ipv6.conf.all.accept_ra 
>>>     net.ipv6.conf.all.accept_ra = 1 
>>>     root:~# sysctl -w net.ipv6.conf.all.accept_ra=0 
>>>     net.ipv6.conf.all.accept_ra = 0 
>>>     root:~# sysctl net.ipv6.conf.eth0.accept_ra 
>>>     net.ipv6.conf.all.accept_ra = 1  
>>>
>>> Is this intended behaviour or not? Bug or (mis)feature?
>> I *think* that's intended, at least it's one of the ways IPv6 differs from IPv4
>> - setting "all" doesn't reset to individual nic settings.  But the code in
>> ndisc_router_discovery() should probably check the "all" flag and drop the RA.
>> The other "all" sysctl's should behave the same, so someone needs to take a
>> deeper look.
> 
> OK, I have this weird feeling that this "worked" some years ago, but I
> dont have any old systems to try out that theory on. I fail to see wht
> purpose "all" has, if it isn't setting the value of all interfaces.

I fixed the autoconf one, but this would still need to be addressed in a future
patch, trying to sneak-in before the deadline.  Might be too late...

I sent the actual patch to netdev a few minutes ago for review.

-Brian