Date:	Mon, 23 Feb 2009 15:46:21 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	linux@...la.no
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: PROBLEM: IPv6 autoconf/accept_ra default values

From: Kolbjørn Barmen <linux@...la.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@...r.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists