Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration (was: Re: svn commit: r197145 - in head: etc/defaults share/man/man5)

From: John Hay <jhay_at_meraka.org.za>
Date: Mon, 5 Oct 2009 07:58:06 +0200
On Mon, Oct 05, 2009 at 12:34:27PM +0900, Hiroki Sato wrote:
> Hi,
> 
>  I would like your comments about merging the network_ipv6 -> netif
>  integration to stable/8.  The issue of this rc.d script change is it
>  involves user-visible changes in rc.conf(5) variables as described in
>  UPDATING.
> 
>  I still want to do so before 8.0-R because the ND6 change in -CURRENT
>  needs updating IPv6-related rc.d scripts first.  While the ND6 change
>  is not harmful from viewpoint of compatibility because basically it
>  just converts a global knob to a per-interface flag, handling it in
>  the rc.d scripts needs a kind of overhaul of rc.d/network_ipv6 and
>  rc.d/netif.
> 
>  The necessary changes have already been committed into -CURRENT.  It
>  displays a warning to inform the users what is old in the rc.conf if
>  the user uses rc.d variables that have been changed, and at the same
>  time it keeps backward compatibility so that the old variables also
>  work.  So, I think the impact is small enough, and this sort of
>  visible changes should be included in the .0 release rather than in
>  the middle of future 8.x releases.
> 
>  The patch for stable/8 can be found at:
> 
>   http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff
> 
>  This includes both of the ND6 kernel change and the rc.d script
>  change.  If there is an objection from someone here I will put off
>  the merge until after 8.0-R.

Is there a good reason why we still ship with ipv6 off by default? Most
others seem to ship with ipv6 on. At least Windows, most linux flavours
and Mac OS X which make out the rest of the machines on our network here
at Meraka Institute.

One thing that I have against the way the stuff in -current is done at
the moment, is that it seems to be a lot more work to just get ipv6 to
work. Either I did things wrong or we are taking a step backward. Make
no mistake, I like the idea of being able to control it per interface,
but it seems that you have to enable it per interface with a long string
for each... I would rather that it is enabled everywhere by default and
then you disbale it where you do not want it.

John
-- 
John Hay -- jhay_at_meraka.csir.co.za / jhay_at_FreeBSD.org
Received on Mon Oct 05 2009 - 03:58:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:56 UTC