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
   ...
[ message continues ]

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

[ message continues ]

Hello.


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

[ message continues ]

From: YOSHIFUJI Hideaki <yoshfuji@st-paulia.net>

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

--

[ message continues ]

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 ...
[ message continues ]

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

[ message continues ]

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

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


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

[ message continues ]

"default" is what's inherited by future devices, "all" is supposed to be the

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

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

[ message continues ]