RFC: convert net.inet6.ip6.{accept_rtadv, auto_linklocal} to per-interface flags

[Bruce Simpson]

Hiroki Sato wrote:
>  The ip6.autolinklocal had been enabled but disabled since 6.2R by
>  default because automatic configuration of L3 address is insecure.
>  However, it makes IPv6 configuration complex because of no link-local
>  address on an interface.  Malformed address configuration can be
>  happened easily on a system with $ipv6_enable="NO". for example.  In
>  addition, the rc.conf knob does not mean the IPv6 functionality is
>  completely disabled.  Using an interface for IPv4-only is difficult.
>   

The MLDv2 code will use the link-local address by default if available, 
otherwise if the link is in DAD it will use ::.

In fact, link-local addresses are needed to make stuff like OSPFv3 and 
MLDv2 work properly. So we are in fact shooting ourselves in the foot 
over people's paranoia. Link-scope addresses starting 'fe80' don't 
belong in traffic beyond one L2 hop. We already have a check for 
169.254.0.0/16 in ip_forward(), ip6_forward() performs a scope check.

If people have legitimate security concerns about these address ranges, 
the place to implement that is at the perimeter, or in other forwarding 
policy, not by breaking IPv6 deployment for end-users.

>  So, I want to add the following changes:
>
>  1. Use per-interface ND6 flag "ifdisabled" as a flag for if it is
>     IPv6-enabled or not.  Set it by default.
>
>  2. Automatic link-local address configuration is performed when the
>     ifdisabled flag is clear, not at attach time of the interface.
>     This is implemented as a per-interface flag "auto_linklocal".
>   

This seems perfectly reasonable -- in fact -- it's closer to how other 
platforms do it.

>  3. Accepting Router Advertisement message is also controlled by
>     per-interface flag "accept_rtadv".
>   

Again, RTADV is something which most people who use IPv6 on an endpoint 
in a stub network are going to use, so it's reasonable to have it 
controllable on a per-interface basis.

>  The patch for the latest current is attached.  Thanks.
>   

Patch looks fine, but I'd fix the style(9) bugs before committing; && 
operators, etc should be before the line break, and initializers in 
variable declarations are generally discouraged. Also there should be 
whitespace between code and variable declarations.

thanks,
BMS