Merging rc.d/network_ipv6 into rc.d/netif

Hello folks,

Ever since rc.d was brought into the tree we all agreed IPv6
needed
to be integrated better. Well, I've finally gotten arround
to it... several
years later :-P

The patch is at: http
://people.freebsd.org/~mtm/src-etc.ipv6.diff

What it does
------------
 - rc.d/network_ipv6 is no longer necessary and can be
removed
 - IPv6 configuration is done on each interface in
rc.d/netif along with IPv4
 - IPv6 routing and options processing is done in
rc.d/routing along with IPv4
 - 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
	
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
	ifconfig_DEFAULT
	ifconfig_<interface>
	ifconfig_<interface>_aliasX
	defaultrouter
	gateway_enable
	static_routes
	etc...

 - Modify all scripts that reference old knobs (without
ipv4_ prefix) to
   reference the new version of the knobs

 - Compatibility shims in rc.subr(8) so that old uses of
knobs without an
   ipv4_ prefix work as expected. As part of this change
split the
   code for this processing into its own function:
old2new_knobs()

 - Modify some routines in etc/network.subr to take an
additional argument
   to specify v4 or v6 configuration:
	_ifconfig_get_args
	ifconfig_getargs
	autoif
	wpaif

 - Move some invocations of route(8) and v6 options
processing into
   rc.d/routing


I'm using the patches on my main work machine without any
problems, so I think it's ready for a wider review. Please
try it out and send me any comments, bug-reports, etc.

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.

Cheers.
-- 
Mike Makonnen       | GPG-KEY: http://www.identd.
net/~mtm/mtm.asc
mmakonnengmail.com | AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82
7CD4 1F55
mtmFreeBSD.Org     | FreeBSD - Unleash the Daemon !
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Mike Makonnen wrote:
> 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 agree. We should be able to add/remove IPv6 link-local
addresses 
somehow at runtime, after boot, without necessarily bringing
up IPv6 on 
an interface during boot.

I am thinking at some point it may be for the best if some
of the code 
to do with address families is restructured so that the
administrator is 
able to explicitly attach or detach protocol domains e.g.
AF_INET, 
AF_INET6 to network interfaces on the command line, based on
my 
experience of making the changes necessary for refcounting
of various 
network stack structures.

I'd like to get this fixed going forward, though, as ever,
other work 
takes priority...

Regards,
BMS
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Mike Makonnen <mtmFreeBSD.Org> writes:
>  - 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

I hope we never get an if_ip NIC driver 

DES
-- 
Dag-Erling Smørgrav - desdes.no
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Hi,

I'm going to take a look over these changes as well.

Best,
George
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

Hi Mike,

Thank you for working on this.  I'm always glad to see
someone working
on homogenization.  I dare to post a few comments though:

On Thu, Mar 29, 2007 at 09:29:06PM +0300, Mike Makonnen
wrote:
> What it does
> ------------
>  - rc.d/network_ipv6 is no longer necessary and can be
removed
>  - IPv6 configuration is done on each interface in
rc.d/netif along with IPv4
>  - IPv6 routing and options processing is done in
rc.d/routing along with IPv4
>  - 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

As Dag-Erling said, it may conflict with a future if_ip. 
Moreover,
network interfaces are renameable, so the namespace conflict
is even
more likely.

Although it breaks the standard rc(8) syntax, I would
personaly prefer:
	/etc/rc.d/netif (start6|stop6) rl0

BTW, the proposed syntax isn't very usual either .

>  - 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
> 	ifconfig_DEFAULT
> 	ifconfig_<interface>
> 	ifconfig_<interface>_aliasX
> 	defaultrouter
> 	gateway_enable
> 	static_routes
> 	etc...
> 
>  - Modify all scripts that reference old knobs (without
ipv4_ prefix) to
>    reference the new version of the knobs
> 
>  - Compatibility shims in rc.subr(8) so that old uses
of knobs without an
>    ipv4_ prefix work as expected. As part of this
change split the
>    code for this processing into its own function:
old2new_knobs()

This is neat.  What about issuing a warning in order to make
a
quicker transition ?

Again, thank you for working on this.
Best regards,
-- 
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot
org >
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

I keep forgetting to do a review so a few comments now and
hopefully a
fuller review later.

On Thu, Mar 29, 2007 at 09:29:06PM +0300, Mike Makonnen
wrote:
> Hello folks,
> 
> Ever since rc.d was brought into the tree we all agreed
IPv6 needed
> to be integrated better. Well, I've finally gotten
arround to it... several
> years later :-P
> 
> The patch is at: http
://people.freebsd.org/~mtm/src-etc.ipv6.diff
> 
> What it does
> ------------
>  - rc.d/network_ipv6 is no longer necessary and can be
removed
>  - IPv6 configuration is done on each interface in
rc.d/netif along with IPv4
>  - IPv6 routing and options processing is done in
rc.d/routing along with IPv4
>  - 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.

> 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).

> 	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.

> 	ifconfig_<interface>_aliasX
> 	defaultrouter
> 	gateway_enable
> 	static_routes
> 	etc...
> 
>  - Modify all scripts that reference old knobs (without
ipv4_ prefix) to
>    reference the new version of the knobs
> 
>  - Compatibility shims in rc.subr(8) so that old uses
of knobs without an
>    ipv4_ prefix work as expected. As part of this
change split the
>    code for this processing into its own function:
old2new_knobs()
> 
>  - Modify some routines in etc/network.subr to take an
additional argument
>    to specify v4 or v6 configuration:
> 	_ifconfig_get_args
> 	ifconfig_getargs
> 	autoif
> 	wpaif
> 
>  - Move some invocations of route(8) and v6 options
processing into
>    rc.d/routing
> 
> 
> I'm using the patches on my main work machine without
any
> problems, so I think it's ready for a wider review.
Please
> try it out and send me any comments, bug-reports, etc.
> 
> 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.

-- Brooks

On Tue, Apr 03, 2007 at 11:11:32PM +0200, Jeremie Le Hen
wrote:
> 
> As Dag-Erling said, it may conflict with a future
if_ip.  Moreover,
> network interfaces are renameable, so the namespace
conflict is even
> more likely.
> 
> Although it breaks the standard rc(8) syntax, I would
personaly prefer:
> 	/etc/rc.d/netif (start6|stop6) rl0
> 
> BTW, the proposed syntax isn't very usual either .

I wasn't happy about the syntax either, but I was at a loss
at how
to handle it. Now that you've mentioned the obvious answer,
I'm
wondering how come it never occured to me :-P

> 
> >  - 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
> > 	ifconfig_DEFAULT
> > 	ifconfig_<interface>
> > 	ifconfig_<interface>_aliasX
> > 	defaultrouter
> > 	gateway_enable
> > 	static_routes
> > 	etc...
> > 
> >  - Modify all scripts that reference old knobs
(without ipv4_ prefix) to
> >    reference the new version of the knobs
> > 
> >  - Compatibility shims in rc.subr(8) so that old
uses of knobs without an
> >    ipv4_ prefix work as expected. As part of this
change split the
> >    code for this processing into its own function:
old2new_knobs()
> 
> This is neat.  What about issuing a warning in order to
make a
> quicker transition ?
> 

I think this is a matter of personal preference. If a lot of
people
think there should be a warning I can add it. Personally, I
don't
see the need, we can keep the shims as long as we want.

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
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

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
_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"

On Thu, Apr 05, 2007 at 06:46:44PM +0300, Mike Makonnen
wrote:
> 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.

OK, do you think it would be possible to kill off 

> > > 	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'd ignore WPA outside of ifconfig_<interface>.  I
think we'll want DHCP
to work there and under ipv4_ifconfig_<interface>, but
not IPv6.  That
will change if/when a dhcp6 client arrives, but who knows
when that will
happen.

> > > 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.

That would be nice if we can make it work.  I'm just not
sure how much
effort it's worth to make all the edge cases work.

-- Brooks

On Thu, Apr 05, 2007 at 11:02:51AM -0500, Brooks Davis
wrote:
> > > 
> > > 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.
> 
> OK, do you think it would be possible to kill off 

Yes, I think so. while working on the updated patch I
realized that in
order for this to work it would require a violation POLA, so
MFC isn't
going to be possible.

> 
> > > > 	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'd ignore WPA outside of ifconfig_<interface>. 
I think we'll want DHCP
> to work there and under
ipv4_ifconfig_<interface>, but not IPv6.  That
> will change if/when a dhcp6 client arrives, but who
knows when that will
> happen.

The current patch also moves DHCP to the versioned variables
because it is
inevitable that we'll have an IPv6 dhcp client in the
future. So, we might
as well prepare for it now.

BTW, there are some dhcp6 related knobs and
functions in the current patch, but they don't really do
anything at the
moment. They are there to prepare the way for an IPv6
dhclient in the future
or to allow the one in the ports tree to plugin to rc.d
easily.

The patch is at: http
://people.freebsd.org/~mtm/src-etc.ipv6.diff

I have attached a description of the changes to this email.

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

_______________________________________________
freebsd-netfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
"freebsd-net-unsubscribefreebsd.org"