lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.01.0903200945160.20203@halbrend.uninett.no>
Date:	Fri, 20 Mar 2009 09:48:30 +0100 (CET)
From:	Kolbjørn Barmen <linux@...la.no>
To:	David Miller <davem@...emloft.net>
cc:	yoshfuji@...paulia.net, linux@...la.no, netdev@...r.kernel.org,
	yoshfuji@...ux-ipv6.org
Subject: Re: PROBLEM: IPv6 autoconf/accept_ra default values

On Thu, 19 Mar 2009, David Miller wrote:

> From: YOSHIFUJI Hideaki <yoshfuji@...paulia.net>
> Date: Wed, 18 Mar 2009 12:33:08 +0900 (JST)
> 
> > In article <alpine.LNX.2.00.0903180200590.10453@...da.kolla.no> (at
> > Wed, 18 Mar 2009 02:06:09 +0100 (CET)), Kolbjørn Barmen
> > <linux@...la.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
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ