Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Apr 2007 18:46:44 +0300
From:      Mike Makonnen <mtm@FreeBSD.Org>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        freebsd-net@freebsd.org, freebsd-rc@freebsd.org
Subject:   Re: Merging rc.d/network_ipv6 into rc.d/netif
Message-ID:  <20070405154644.GB1844@rogue.navcom.lan>
In-Reply-To: <20070403231423.GA52441@lor.one-eyed-alien.net>
References:  <20070329182906.GB38703@rogue.navcom.lan> <20070403231423.GA5244 1@lor.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 03, 2007 at 06:14:23PM -0500, Brooks Davis wrote:
> >  - You can now do things like:
> > 	# Start/Stop IPv6 on all interfaces
> > 	/etc/rc.d/netif (start|stop) ip6
> > 	# Start/Stop IPv6 only on interface rl0
> > 	/etc/rc.d/netif (start|stop) rl0 ip6
> > 	# Do IPv6 options processing
> > 	/etc/rc.d/routing options ip6
> 
> I think I'd prefer (start|stop)(4|6).  I not sure what the value of the
> separation is, but don't care much.

I'll post a new patch with this change. Now that its been mentioned
I agree, it's a better thatn what I came up with. 

> > Overview of the changes in src/etc
> > -----------------------------------
> >  - In order to differentiate between v4 and v6 configuration directives some
> >    knobs in rc.conf(5)have been renamed with an ipv4_ prefix:
> > 	network_interfaces
> 
> I fell fairly strongly that ipv6_network_interfaces and
> network_interfaces are a mistake and that we should remove them
> rather than propagating them.  The way I'd prefer to see interfaces
> that are exceptional with regard to address families specified with
> (|NO)IPV(4|6) variables in ifconfig_<interface> or simply by not
> having ipv(4|6)_ifconfig_interface variables (that it's a little more
> complicated than that with ipv4_addrs_<interface> around, but I think
> the concept holds).

I agree completely. However, when this hits the tree I don't want peoples
configurations to break (especially since I would like to see this in
6-stable if we can aggree on it). Also, since this feature is already
deprecated in the man page I think we can provide silent support for
it without explicitly advertising it untill people have had a suffient
transition period.

> 
> > 	ifconfig_DEFAULT
> > 	ifconfig_<interface>
> 
> ipv4 versions of these make sense, but at least ifconfig_<interface>
> should continue to exist.  For example both setting the mac address and
> starting WPA via the WPA keyword should not work in any address specific
> version because that would be a layering violation.
> 

Ok. That should be doable, but it's probably going to make
configuration decisions more complicated. For example, do we ignore
the WPA in the ipv(4|6)_* variables or does it's presence in any
of the variables enable it?

> > I would
> > especially like feedback from folks more familiar with IPv6. One
> > gotcha I've noticed is that if you boot with ipv6_enable turned
> > off, then try to start IPv6 on an interface later on, it doesn't
> > work because none of the interfaces (except lo0) has a link-local
> > address (see rc.d/auto_linklocal). How can we fix this? Also, I
> > would appreciate feedback on how stopping IPv6 on an interface
> > should be handled. In rc.d/network_ipv6 it was handled at all.
> > Currently, it goes through and deletes all
> > IPv6 addresses on the interface.
> 
> I'd say if ipv6_enable=NO, attempting to configure IPv6 on an interface
> should fail.  If they turn it on, I'm not sure what the best approach
> is.  Not worrying about it may well be most appropriate.

I don't agree. I would expect that if I enable IPv6 in rc.conf I wouldn't
have to reboot the machine to get my network interfaces configured
properly.

Cheers.
-- 
Mike Makonnen          | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc
mmakonnen @ gmail.com | AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm @ FreeBSD.Org     | FreeBSD - http://www.freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070405154644.GB1844>