Re: ipv6_enable

On Mon, 5 Apr 2010, jhell wrote:

Hi,

reading the thread in thread view I had wondered why your reply had
been ignored until I realized that it was the last to come in.  So
I'll use it to reply to, especially as I like it.

I have no idea (unless I'll read them) about the guts of various shell
function magic we use to configure interfaces, and I heck do not care
about where it's called autoblah_foo or zigbangbusheek as none of our
users does, so I'll ignore that.  I'll probably have to comment on a
few rc.conf knobs as that's all a user cares about.

> Not really seeing the correct thread to reply to with this content I
> decided to reply to Kevin and lead off from here.
>
> Seeing a lot of *_enable for interfaces makes sense in the traditional
> way of configuring daemons or enabling things like rtsold/rtadvd for
> IPv6. Don't get me wrong but the below I am not talking about phasing
> those _enables out for the daemons.
>
> Personally I believe that using them for such a behavior as configuring
> a protocol for a interface is incorrect usage given the current use of
> IPv4 and not needing something like ipv4_enable.
>
> Why not skip the need for ipv?_enable all-in-all and leave those out of
> the mix?. Since they do not really disable them or enable anything other
> than the ability to use and or check ipv6 related daemons.

As said, I like the idea of simplification. And I like the idea of having:

ifconfig_<IF>_ipv6="inet6 ..."
ifconfig_<IF>_ipv6_alias<n>="inet6 ..."
as well as
ipv6_defaultrouter=".."
ipv6_static_routes=".."
ipv6_gateway_enable=".."

An I like it for IPv4 and actually if you look at defaults/rc.conf you
will find that we even liked it for:

ifconfig_ed0_ipx="ipx 0x00010010"
ipxgateway_enable="NO"

So here comes one of the things I don't like, POLA back POLA forth.
None of the three AFs was implemented in a consistent way.

In the old days we used (and still) have (though a lot less) a mix of
"ip6" and "ipv6" and while IPv4 was kind of "default" there was no
ifconfig_<IF>_ipv4=".." which has historic reasons I believe but it
was ifconfig_<IF>_ipx=  and I like it that it's ifconfig_<IF>_ipv6
now.  It should be ipx_gateway_enable instaed of ipxgateway_enable
but that's something to cleanup more easily;)

Neither IPv4 nor IPX have an <AF>_enable="" knob in defaults/rc.conf
and I cannot see why we would need it for IPv6.  You don't configure
it on an interface you don't have it configured an interface.
The fact that it had been there for IPv6 is historic and could have
been a good or bad idea at that time during the early days of
development.  I am actully too lazy to see why it had really been added.


If I boot up without having any RC framework or anything but the shell
run, these days I get a network stack with a loopback interface and it
looks like this:

# ifconfig -a
lo0: flags=8008<LOOPBACK,MULTICAST> metric 0 mtu 16384
         options=3<RXCSUM,TXCSUM>

if it also had an interface it would look like this:
iface: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         ether 02:00:00:00:07:0a


There is no IPv6 address, there is no IPv4 address, they are down
because noone told them to be up.  If I "up" them manually it looks
like this:

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
         options=3<RXCSUM,TXCSUM>
         inet6 ::1 prefixlen 128
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
         nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
iface: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
         ether 02:00:00:00:07:0a
         inet6 fe80::ff:fe00:70a%iface prefixlen 64 scopeid 0x2
         nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

This actually is bad but that's because neither devd nor the rc
framework were run yet and the kernel defaults were never changed
(if my memory serves me right for RFC reasons).  Silly me doing this
in "single user";)

I wouldn't want to have a link-local address on my non-loopback
interfaces working unless I asked for them.  That's why we had
ipv6_autolinklocal in the past and that's why the current rc/devd/iface
framework prevents this from happening unless explicitly asked for.
That's why there is nd6 options=<IFDISABLED>.

If if were to implement 3927 (I think it was) 169.254.0.0 stuff like
some other OSes do we would want to control that as well and have it
off by default.

Why do I not want that for our users?  Let me repeat the argument from
a couple of years ago from other people:
"If I put my FreeBSD machine anywhere and I have no clue about IPv6
I don't want my neighbor to ping6 or ssh or even compromise my machine
just because I didn't know we have this kind of thing and autom-agic
happened."
That's why link-local addresses had been disabled in the past (similar
arguemnts would apply for the 169.254/16 case).
Re-enabling them had never worked well in the past if ipv6_enable
was NO on boot.  You had to change the sysctl (manually) and then down
up the interface(s) leading to serivce interruption even for IPv4.
There is a PR about it if you want to check.

In the past there was no way to express "enable it on my wired interface
but not on my wireless" or "enable on the inside but not the outside
interface" or enabled/disable it smoothly on run-time. It was global
which was bad and has been fixed.  I can savely put my FreeBSD laptop
on a conference LAN and have DHCP enabled and be sure I'll only get at
best an IPv4 address on the interface.
I can configure IPv6 on my interfaces and not even have to think about
IPv4 if not configured.
Similary I do not have to think of IPv6 tcp_wrappers or firewalls or
if my sshd would be reachable from the local LAN with hundreds of
unknown people.
I can savely express accept rtadv on the left interface but not on the
right. I can say I want an IPv6 link-local on this one but not the
others.  I can even say "disable IPv6 processing on this interface"
(kind of) and we actually do by default.

Having any kind of auto-magic happen with an IPv4 DHCP knob for IPv6
will get us back to where we had been 6 years ago - or actually would
make it worse as we'd mix v4 and v6 config options even more again.
I don't want to go back.  I want to move forward.

I am trying to think of a reason I had needed ipv6_interfaces in the
past and I can find some.  I have checked my current configurations
and I couldn't find any instance of *interfaces anymore.  Being able
to use ifconfig_<IF>**, especially with the IPv6 per interface options,
seems to have fixed all for me with the current implementation.


Why do we need ipv6_prefer?  Well, actually we do not need it. We
could have people use ip6addrctl and a static config file with their
preference.  It's really something entirely different to the overall
interface configuration story and RS/RA things.
It is one of those knobs like v4-mapped-v6 addresses that are
supposed to ease transition (but not only).
I actually do not care what it will end up by default if does what I
tell it by configuration prefer IPv6 over IPv4 or not.
It's one of the ipv6_ variables I might have to set if I would want
IPv6 by default.  It's a shame we didn't have that to decide whether
to use IPX over IP or not;-)
If you want to "fix" that make it more "if6addrctl" a-like so people
can not only have YES/NO default but also a config file but I bet
even fewer people will understand it; the current thing "just works"
for users.


So what do you people actually want to change?  You want auto-magic to
happen (again) that suits your local setup or that does what we used
to have in the 5.x days?  Well put your "local" needs into
ifconfig_<IF>_ipv6 and be done.
Once DHCPv6 would come to your setup you would to undo some of this
"automagic" again anyway and say ifconfig_<IF>_ipv6="DHCP[6]" and be
done. Right?

If you want to help users running FreeBSD desktops build a crazy blinky
app that says "Oh I have sniffed this network and found IPv6 was
available but you haven't enabled it. Do you want to use it? Yes?
Should I start the firewall for it as well?" and add some big buttons
with smileys dancing kames and hopping Google letters but please do
not have us make two steps backwards again.

You want "sane" defaults for users?  The only sane default is "if
there is nothing configured, don't do anything" for everything else
you need a good crystal ball and if you had that you wouldn't be here
but would have won the lottery long ago.

my 2cts.

-- 
Bjoern A. Zeeb         It will not break if you know what you are doing.