Static vs SLAAC - Static expected to be preferred?

[Mark Smith]

On Wed, 04 May 2011 10:44:13 +0200
Bjørn Mork <bjorn at mork.no> wrote:

> Mikael Abrahamsson <swmike at swm.pp.se> writes:
> 
> > On Thu, 28 Apr 2011, Benedikt Stockebrand wrote:
> >
> >> Ok, once more:
> >>
> >> I've just checked.  Disabling Autoconf can be done with
> >>
> >> Debian Sarge:
> >>  In /etc/sysctl.conf
> >>    net.ipv6.conf.{default|all|<ifname>}.accept_ra=0
> >>      disables all autoconfiguration
> >>    net.ipv6.conf.default.autoconf=0
> >>      disables address autoconfiguration but not default router
> >>      cconfiguration
> >
> > It still works. it should be noted though that I had to:
> >
> > net.ipv6.conf.default.accept_ra=0
> > net.ipv6.conf.eth0.accept_ra=0
> > net.ipv6.conf.eth1.accept_ra=0
> > net.ipv6.conf.eth2.accept_ra=0
> > net.ipv6.conf.eth3.accept_ra=0
> > net.ipv6.conf.eth4.accept_ra=0
> >
> > because sysctl.conf seems to be run after the interface comes up so
> > usually my box comes up with a EUI64 address anyway (in addition to my
> > static one), that I have to remove (manually since I'm too lazy to
> > script it and I reboot seldom).
> 
> Yes, the order of the procps (running "sysctl -p /etc/sysctl.conf") and
> networking (running "ifup -a") init scripts aren't guaranteed. There's
> no dependency defined between them.  A quick test on a few Debian
> squeeze systems with dependency based boot shows that they often end
> up with the same boot priority, making the networking script run first
> due to "n" < "p".
> 
> You can verify this by looking at the priorities:
> 
>   ls -l /etc/rcS.d/*{procps,networking}
> 
> 
> The safest bet is still to put 
> 
>   net.ipv6.conf.all.accept_ra=0 
>   net.ipv6.conf.default.accept_ra=0 
> 

Then you loose the ability everything else you can do with RAs, such as
having these hosts automatically learn their default routers, have their
neighbor discovery parameters changed, have their IPv6 MTU changed from
the default, have their hop count updated, have them be informed of
on-link prefixes even though they might not have an address within
that prefix etc.

This last half dozen emails or so, showing the significant amounts of
effort involved in disabling or overriding SLAAC addresses, are exactly
why I think configuring static addresses should be no harder than 

ip -6 addr add 2001:db8::1/64 dev eth0

as it is in IPv4. If the host has automatically learned SLAAC addresses,
you've inherently chosen to override them by the action of manually
configuring a static. The SLAAC addresses won't do any harm if they're
left there and never used as source addresses, and you still get to keep
using RAs for their other purposes.

A simplistic approach would be to just blindly prefer statics over all
other types of addresses. However, I think the more flexible approach is
to have the current value of the preferred lifetime value used as the
deciding factor. Static addresses, with their default infinite preferred
lifetimes, would always win. If you wanted to have a static
address only used for incoming connections (i.e. as a incoming
destination address for a server process), but use SLAAC (or other)
addresses for outgoing connections, you'd set the static address
preferred lifetime to 0, and leave it's valid lifetime as infinity.



> in /etc/sysctl.conf and 
> 
>   pre-up sysctl -w net.ipv6.conf.$IFACE.accept_ra=0
> 
> in any auto interface stanza in /etc/network/interfaces 
> 
> 
> Also note that enabling IPv6 forwarding will change the default
> router/host behaviour of all IPv6 interfaces.  
> 
> 
> Bjørn