Message-ID: <4B7C1F60.4080701@hp.com>
Date:	Wed, 17 Feb 2010 11:54:56 -0500
From:	Brian Haley <brian.haley@...com>
To:	Kolbjørn Barmen <linux@...la.no>
CC:	Vlad Yasevich <vladislav.yasevich@...com>, davem@...emloft.net,
	yoshfuji@...ux-ipv6.org, netdev@...r.kernel.org
Subject: Re: IPv6 autoconf/accept_ra default values - revisited

Hi Kolla,

Kolbjørn Barmen wrote:
>> For a test, can you turno-off accept_ra/accept_ra_defrtr/accept_ra_pinfo
> 
> What are they, documented anywhere?

Documentation/networking/ip-sysctl.txt

>> and see if you can get the behavior you want?
> 
> I must admit that I havent tried using those yet, but still
> I somehow managed to get what I want like this:
> 
> ~ # cat /etc/modprobe.d/ipv6.conf
> options ipv6 disable_ipv6=1 autoconf=0
> ~ # cat /etc/sysctl.d/ipv6.conf
> net.ipv6.conf.default.autoconf=0
> net.ipv6.conf.default.accept_ra=0
> net.ipv6.conf.default.disable_ipv6 = 0
> net.ipv6.conf.all.autoconf=0
> net.ipv6.conf.all.accept_ra=0
> net.ipv6.conf.lo.disable_ipv6=0
> 
> I'm still not convinced it really works, but it looks good so far.

Ok, so when the IPv6 module is loaded, it won't configure any addresses.
Then you enable IPv6 on future interfaces that are added, and enable it
on lo.  So after this you just have an address on lo and your bridges,
right?

>>> So, could "autoconf" also please turn off accept_ra?
>>> Or, if you like, add another parameter for it :P
>> There are other things in the RA that are useful, like MTU, turning-off
>> accept_ra would miss that
> 
> So what is one supposed to do when one wants fully statically configured
> IPv6 addresses and routes? Or is that not supposed to be possible?

This sequence worked for me on a single interface:

# sysctl net.ipv6.conf.eth0.disable_ipv6=1
# sysctl net.ipv6.conf.eth0.accept_ra_defrtr=0
# sysctl net.ipv6.conf.eth0.accept_ra_pinfo=0
# sysctl net.ipv6.conf.eth0.disable_ipv6=0

Interface now has just link-local and you can add addresses and routes
as necessary.

So it looks possible to modify your conf file like this:

net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_pinfo=0

>> I think maybe ignoring the prefix info options when autoconf=0 might be
>> what you want.  I guess we could do another module parameter if we had
>> to.
> 
> Yes - all I want is ignore prefix and router announcements, they are not
> to be trusted.

By router announcements do you mean you don't want to make the sender the
default router?

>>> And the entire "all" vs. "default" still confuses me.
>>>
>>> * "default" is supposed to cover _all future_ interfaces?
>>> * "all" is supposed to cover _all existing_ interfaces, and change them?
>>>   If not, then what is its function?
>> Yes, "default" covers future interfaces, but "all" behavior depends on
>> the option - "all->forwarding" and "all->disable_ipv6" will reset
>> interfaces and "all->proxy_ndp" affects all interfaces.  Other than
>> that, the "all" variables seem not to be used.  Making it more like the
>> IPv4 code sooner than later might be a good thing, maybe others have
>> thoughts on that?
> 
> I'd say yes, and the sooner the better.
> (I've noticed the Debian has "Full IPv6 support" in their feature list for
> next release this summer, it would be nice to have something ready for that.)

Well, I'll see what I can do...

>>> And lastly - all this would be a non-issue if the defaults values were so
>>> that all autoconf/accept_ra were 0 - it's _so_ easy to turn on, but
>>> incredibly complicated to turn off. The harder it is to make sense out of
>>> things like this, the harder it is to have people start with IPv6.
>> I don't think that default is going to change since it would effectively
>> disable IPv6 for 99.9% of users, my grandmother would wonder why nothing works
>> any more and not know how to fix it :)  In other words, people not doing
>> autoconfiguration are in the minority, and might need to change all these
>> default settings, but we should make it easier to use.
> 
> Right, here it comes, the "most users" argument.
> Sorry, but I just want to rant a little over this ;)
> 
> Your grandmother will be pretty fed up anyways since some random wifi
> stumbler with 6to4 accidently turned on, jumps on her weakly configured
> access point, announcing routes so that her computer now routes all
> traffic through the stumblers laptop, which works fine till the stumbler
> vanishes, leaving your grandmother's computer with lots of stalled TCP
> sessions and a broken default gateway. Not to mention all the timeouts she
> will have to wait for as her computer attempts to contact all the ipv6
> addresses it resolves before finally, maybe, trying ipv4 instead.

Yes, I've seen this too when someone configures their laptop to be an
IPv6 router at home, and then comes into the office.  We then track them
down and "educate" them :)  The only solution to this is SeND I believe,
and that's not widely deployed at all.

> I have worked with ipv6 in "production" long enough to know that the
> overly optimistic view on how things are supposed to work is one of the
> big obstacles for deployment of IPv6, it's just too fragile...
> 
> 6to4 accidently activated on a machine on the LAN? Boom!
> Loop between LANs as resault of accident plugging on switch? Boom!
> Multihomed machine accidently forwards between interfaces? Boom!
> 
> And what do you do when suddenly you have heaploads of machiens with
> nonworking IPv6 configurations? DHCPv6 to the rescue? Or not? :)

DHCPv6 is going to be widely used from what I know, as enterprises
typically use DHCPv4 today, they don't want the end-user to be
administering this stuff at all.

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