Re: svn commit: r197145 - in head: etc/defaults share/man/man5

[Doug Barton]

[Please direct follow-ups to freebsd-rc@]

Hiroki,

I realize that you've posted your patches in the past, and I
definitely had it in mind to review them in detail and give you
feedback on them. However I got focused on my own projects for the
pending release, and then since we were so close to the release I did
not think you would be committing these changes until after it was
done so I let review of these patches slip down my list of priorities.
Therefore I ask you to accept my apologies for this "after the fact"
review.

Before I forget, you keep putting "mfc after 3 days" in your commit
messages. You don't actually plan to MFC these changes to RELENG_8
prior to the 8.0-RELEASE do you? I would not be supportive of this
given the sweeping nature of the changes and the (unfortunately) small
percentage of our userbase that uses and tests IPv6. I think shaking
this code out in HEAD for several weeks at least would be a good thing.

That said I very much like the idea of integrating IPv6 support into
the overall network code, and I am very supportive of that. I do have
some small problems with the direction that you've taken in a few
areas, which happen to be neatly summarized in this post.

Hiroki Sato wrote:

> Author: hrs
> Date: Sat Sep 12 22:22:31 2009
> New Revision: 197145
> URL: http://svn.freebsd.org/changeset/base/197145
>
> Log:
>   The following changes are added because of
>   network_ipv6->rc.d/netif integration:
>  
>   - $ipv6_enable is now obsolete.  Instead, IPv6 is enabled by
>     default if the kernel supports it, and $ipv6_network_interfaces
>     is "none" by default.  If you want to use IPv6, define
>     $ipv6_network_interfaces and $ifconfig_xxx_ipv6.

In general I have a problem with the idea of drastically changing the
semantics of the current code when I can't see any real value in doing
so. I object to this change specifically because on my laptop I really
like having the ability to easily disable IPv6 when I am not on my
home network.

My preferred scenario would be something similar to what we have now,
which is that if ipv6_enable is set that it takes the same list of
interfaces as ipv4 (defaults to AUTO) and that rtadv is enabled by
default for each of those interfaces. My feeling is that this not only
significantly reduces POLA it will also more precisely fit the way
that the vast majority of our users will actually use IPv6.

On a "marketing" note I really think it would be valuable to make it
as easy as possible for the average user to get IPv6 working. We have
IPv4 down to it more or less "just works," I think IPv6 should be the
same way. (On a side note, I'd actually like to see DHCP be the
default for IPv4 such that if you have DHCP available on a network you
wouldn't have to do any configuration at all to get FreeBSD on line,
but that's a whole other topic.)

>     An interface which is in $network_interfaces and not in
>     $ipv6_network_interfaces will be marked as "inet6
>     -auto_linklocal ifdisabled" (see ifconfig(8)).

I think that if a user specifies both lists, and that they differ,
that this is a very good way to handle it.

>   - $ipv6_ifconfig_xxx is renamed to ifconfig_xxx_ipv6 for
>     consistency with other address families.  The old variables
>     still work but can be removed in the future.  Note that
>     ipv6_ifconfig_xxx="..." should be replaced with
>     ifconfig_xxx_ipv6="inet6 ...".

I see that you are giving a warn'ing when the old format is detected,
which is good.

>   - Receiving ICMPv6 Router Advertisement is not automatically
>     enabled even if there is no manual configuration of IPv6 in
>     rc.conf.  If you want it, define
>     ifconfig_xxx_ipv6="inet6 ... accept_rtadv".

What is the reason for this change? While I am definitely in favor of
making it easier to disable rtadv, I still think it should be the
default.

>   - The rc.d/ip6addrctl now chooses address selection policy based
>     on $ipv6_prefer, not $ipv6_enable.  The default is
>     ipv6_prefer=NO.

Once again, what is the reason for this change? My read of the
IPv6-using community is that if they have it available they want to
use it as a first choice. I know that is certainly my preference.


Once again my apologies for the late review, but hopefully this is useful.


Doug

--

    This .signature sanitized for your protection

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

[John Hay-3]

On Wed, Sep 16, 2009 at 02:59:42PM -0700, Doug Barton wrote:
...

>
> Hiroki Sato wrote:
> > Author: hrs
> > Date: Sat Sep 12 22:22:31 2009
> > New Revision: 197145
> > URL: http://svn.freebsd.org/changeset/base/197145
> >
> > Log:
> >   The following changes are added because of
> >   network_ipv6->rc.d/netif integration:
> >  
> >   - $ipv6_enable is now obsolete.  Instead, IPv6 is enabled by
> >     default if the kernel supports it, and $ipv6_network_interfaces
> >     is "none" by default.  If you want to use IPv6, define
> >     $ipv6_network_interfaces and $ifconfig_xxx_ipv6.
>
> In general I have a problem with the idea of drastically changing the
> semantics of the current code when I can't see any real value in doing
> so. I object to this change specifically because on my laptop I really
> like having the ability to easily disable IPv6 when I am not on my
> home network.
>
> My preferred scenario would be something similar to what we have now,
> which is that if ipv6_enable is set that it takes the same list of
> interfaces as ipv4 (defaults to AUTO) and that rtadv is enabled by
> default for each of those interfaces. My feeling is that this not only
> significantly reduces POLA it will also more precisely fit the way
> that the vast majority of our users will actually use IPv6.

Can we then have it default to ipv6_enable="YES" and let people who do
not want it, put ipv6_enable="NO" in their rc.conf? Most of the rest
of the world has changed that we and we were also there a few years
ago. (Yes I know because we run ipv6 at work and I can see how many
machines just work without people having to fiddle with it. On the
FreeBSD boxes you still have to go and enable it. :-((( )

John
--
John Hay -- jhay@... / jhay@...
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[Doug Barton]

John Hay wrote:

> On Wed, Sep 16, 2009 at 02:59:42PM -0700, Doug Barton wrote:
> ...
>> Hiroki Sato wrote:
>>> Author: hrs
>>> Date: Sat Sep 12 22:22:31 2009
>>> New Revision: 197145
>>> URL: http://svn.freebsd.org/changeset/base/197145
>>>
>>> Log:
>>>   The following changes are added because of
>>>   network_ipv6->rc.d/netif integration:
>>>  
>>>   - $ipv6_enable is now obsolete.  Instead, IPv6 is enabled by
>>>     default if the kernel supports it, and $ipv6_network_interfaces
>>>     is "none" by default.  If you want to use IPv6, define
>>>     $ipv6_network_interfaces and $ifconfig_xxx_ipv6.
>> In general I have a problem with the idea of drastically changing the
>> semantics of the current code when I can't see any real value in doing
>> so. I object to this change specifically because on my laptop I really
>> like having the ability to easily disable IPv6 when I am not on my
>> home network.
>>
>> My preferred scenario would be something similar to what we have now,
>> which is that if ipv6_enable is set that it takes the same list of
>> interfaces as ipv4 (defaults to AUTO) and that rtadv is enabled by
>> default for each of those interfaces. My feeling is that this not only
>> significantly reduces POLA it will also more precisely fit the way
>> that the vast majority of our users will actually use IPv6.
>
> Can we then have it default to ipv6_enable="YES" and let people who do
> not want it, put ipv6_enable="NO" in their rc.conf? Most of the rest
> of the world has changed that we and we were also there a few years
> ago. (Yes I know because we run ipv6 at work and I can see how many
> machines just work without people having to fiddle with it. On the
> FreeBSD boxes you still have to go and enable it. :-((( )

Certainly, I agree that "enabled" should be the default. Sorry if I
wasn't clear about that.


Doug

--

    This .signature sanitized for your protection

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

[hrs]

Hi Doug,

First, I am sorry for the delayed response.  I was in transit to UK to
attend EuroBSDCon and email application on my laptop was somewhat in a
bad state.

Doug Barton <dougb@...> wrote
  in <4AB15FCE.70505@...>:

do> I realize that you've posted your patches in the past, and I
do> definitely had it in mind to review them in detail and give you
do> feedback on them. However I got focused on my own projects for the
do> pending release, and then since we were so close to the release I did
do> not think you would be committing these changes until after it was
do> done so I let review of these patches slip down my list of priorities.
do> Therefore I ask you to accept my apologies for this "after the fact"
do> review.

 No problem.  I am willing to listen to any opinions and discuss if
 needed.

do> Before I forget, you keep putting "mfc after 3 days" in your commit
do> messages. You don't actually plan to MFC these changes to RELENG_8
do> prior to the 8.0-RELEASE do you? I would not be supportive of this
do> given the sweeping nature of the changes and the (unfortunately) small
do> percentage of our userbase that uses and tests IPv6. I think shaking
do> this code out in HEAD for several weeks at least would be a good thing.

 I am still want to merge it into 8.0R because this includes a
 user-visible change and the major version bump is a good timing.
 What I want to do are:

 - Make ND6_IFF_ACCEPT_RTADV a per-IF flag and turn it off by default.
   Accepting Router Advertisement by default on all interfaces when
   ipv6_enable=YES is too aggressive (explained later).  Also, I
   personally think RA should be accepted when the user specifies it
   explicitly.  We do not enable DHCP for IPv4 automatically when no
   manual configuration is in rc.conf, for example.

   IPv6 RFCs explains IPv6 nodes are classified as a host node and a
   router, and a host may perform automatic address configuration by
   DHCPv6, SLAAC or so.  In practice, however, a FreeBSD box does not
   always have only IPv6 interfaces.  Some people may want to use one
   of the interfaces for IPv4 only, and some want to use one for IPv6
   with a manual configuration.  The current implementation does not
   allow it and ipv6_enable=YES forces receiving RA enable on
   interfaces with no configuration.

 - Remove ipv6_enable.  It is a very confusing knob because a kernel
   with INET6 (in GENERIC, as you know) supports IPv6 and it is
   unclear that "what will be done on what interface".  In earlier
   days when IPv6 was an additional component maintained outside the
   tree it was okay.  However, it is now tightly integrated and I
   believe IPv6 configuration should be done in a consistent way with
   IPv4 (at least) wherever we can do so.  For IPv4, what we need is
   simply adding $ifconfig_IF (and $ifconfig_IF_aliasN if needed).
   So, they should work for IPv6 instead of "ipv6_"-prefixed
   variables.

   The user-visible changes I added are the following:

   1. $ipv6_enable is obsolete.  Simply adding $ifconfig_IF_ipv6
      works.

   2. $ipv6_ifconfig_IF is obsolete.  Use $ifconfig_IF_ipv6 instead.
      Note that $ifconfig_IF_ipv6 does NOT automatically add "inet6"
      keyword.

   3. For people who do not want to IPv6 at all (for security reason
      for example), interfaces with no manual configuration for IPv6
      are marked as ND6_IFF_IFDISABLED by rc.d/netif.  If you do not
      mind IPv6 is enabled for all interfaces, set $ipv6_prefer=YES.
      Even if $ipv6_prefer=NO (default), configurations by
      $ipv6_ifconfig_IF and so on work.  Also, you can disable IPv6 on
      only one interface by using "ifconfig IF inet6 ifdisabled" in
      $ifconfig_IF_ipv6.

      One thing you have to be careful is source address selection by
      ip6addrctl(8).  When both IPv4 and IPv6 are usable, which is
      used is controlled by it.  IPv4 is preferred when
      $ipv6_prefer=NO, and IPv6 is preferred when $ipv6_prefer=YES.

   4. A link-local address is almost always added to an interface.
      The link-local address is automatically assigned to an interface
      and can be used for IPv6 communication such as SSH.

      I remember there was a discussion that network communication on
      an interface should not be enabled if there is no configuration.
      And in our default configuration ($ipv6_enable=NO) this address
      is not assigned.  However, the link-local address is essential
      for IPv6 functionality and we cannot remove it if we need IPv6
      communication on that interface.  Something like "ifconfig fxp0
      inet6 2001:db8::1/64" can assign the IPv6 address to an
      interface even if it has no link-local address, it can lead
      unexpected behaviors.

      So, as a compromised way, I added the change described in "3."
      above.  A link-local address is always assigned, but no
      communication is allowed in that interface when it is marked as
      IFDISABLED.  The rc.d/netif script marks an interface as
      IFDISABLED only when "$ipv6_prefer=NO and no $ifconfig_IF_ipv6".

   5. If you want to enable SLAAC (State-Less Address
      AutoConfiguration), simply add "accept_rtadv" to
      $ifconfig_IF_ipv6.  It works in a per-IF basis.

   After all, $ipv6_enable does too many things, IMHO.  It detects
   whether it is a host node or a router, and then if a host it
   enables accepting RA on almost all interfaces and sends out a
   Router Solicitation message for SLAAC.  We need a more fine-grained
   way and consistency with way for IPv4.

   After committing my patch, I noticed there were some rough edges
   and bugs, and it needs more backward compatibility knob handling.
   I am appreciated it if you could review the attached patch.  The
   backward compatibility handling and incompatibilities are the
   following:

   a) When $ipv6_enable=YES is defined, it means $ipv6_prefer=YES and
      all interfaces with IPv6 configuration (it means
      $ifconfig_IF_ipv6 exists in rc.conf) accepts RA by default.
      This is almost the same behavior in the prior releases.

   b) If an $ipv6_ifconfig_IF="xxx" is defined, it is translated to
      $ifconfig_IF_ipv6="inet6 xxx" and display a warning.

   c) If an $ipv6_ifconfig_IF_aliasN="xxx" is defined, it is
      translated to $ifconfig_IF_aliasN="inter xxx" after evaluating
      the other $ifconfig_IF_aliasN.  A warning is displayed.

 So, in short, follow them to migrate to the new world:

  - If you use $ipv6_enable=YES, use $ipv6_prefer=YES instead.  If
    $ipv6_prefer=NO or no $ipv6_prefer, you can still use IPv6 but
    interfaces with no $ifconfig_IF_ipv6 are automatically disabled.
    Note that only IPv6 functionality on that interface is disabled.
    IPv4 communication works, and other interfaces with
    $ifconfig_IF_ipv6 work, too.  This means you can enable IPv6
    functionality only on interfaces with $ifconfig_IF_ipv6 when
    $ipv6_prefer=NO.  If you do not mind IPv6 is enabled on all
    interfaces, use $ipv6_prefer=YES.  In both cases, link-local
    address is assigned automatically.

  - If you use $ipv6_ifconfig_IF, use $ifconfig_IF_ipv6 instead.  Do
    not forget adding "inet6" keyword.

  - If you use $ipv6_ifconfig_IF_aliasN, use $ifconfig_IF_aliasN in
    the same way as IPv4.  Do not forget adding "inet6" keyword.

  - If you use Router Advertisement and SLAAC in your environment, add
    "accept_rtadv" keyword to appropriate $ifconfig_IF_ipv6.

 I think these are enough for backward compatibility.  Please note
 that above descriptions are based on the committed patch and the
 attached additional patch.  The committed patch does not support
 $ipv6_enable.

 I am sorry for committing them without detail explanations behind the
 change.  Hope the above (lengthy) sentences helps your understanding
 what I want to do.

do> In general I have a problem with the idea of drastically changing the
do> semantics of the current code when I can't see any real value in doing
do> so. I object to this change specifically because on my laptop I really
do> like having the ability to easily disable IPv6 when I am not on my
do> home network.
do>
do> My preferred scenario would be something similar to what we have now,
do> which is that if ipv6_enable is set that it takes the same list of
do> interfaces as ipv4 (defaults to AUTO) and that rtadv is enabled by
do> default for each of those interfaces. My feeling is that this not only
do> significantly reduces POLA it will also more precisely fit the way
do> that the vast majority of our users will actually use IPv6.
do>
do> On a "marketing" note I really think it would be valuable to make it
do> as easy as possible for the average user to get IPv6 working. We have
do> IPv4 down to it more or less "just works," I think IPv6 should be the
do> same way. (On a side note, I'd actually like to see DHCP be the
do> default for IPv4 such that if you have DHCP available on a network you
do> wouldn't have to do any configuration at all to get FreeBSD on line,
do> but that's a whole other topic.)

 Yes, I completely agree.  I am also concerned about POLA, and decide
 to add support of $ipv6_enable to recede the astonishment.  I would
 like your comments on my goal by combination of the committed and the
 attached patch.

do> >   - Receiving ICMPv6 Router Advertisement is not automatically
do> >     enabled even if there is no manual configuration of IPv6 in
do> >     rc.conf.  If you want it, define
do> >     ifconfig_xxx_ipv6="inet6 ... accept_rtadv".
do>
do> What is the reason for this change? While I am definitely in favor of
do> making it easier to disable rtadv, I still think it should be the
do> default.

 I think this may be a moot point.  As explained above, I think
 "$ipv6_enable on a host, not a router, and no IPv6 configuration
 always means receiving RA" is too aggressive. No configuration should
 be no configuration, does not mean "I want RA".  "Specifying it
 explicitly if you want it, no configuration if you don't" is safer
 and consistent.

 Another concern I have is the fact that RA includes default router
 address and the box configures the default route based on it.  This
 means it can override manually-configured default route.  If it
 handles only prefix-list then receiving RA by default would be okay,
 but I think we have to be more careful to whether we accepts it or
 not.

 Anyway, $ipv6_enable knob support in the attached patch emulates the
 old behavior.  My approach may not be the best, but the concern was
 as I explained.  Any comments are welcome.

do> >   - The rc.d/ip6addrctl now chooses address selection policy based
do> >     on $ipv6_prefer, not $ipv6_enable.  The default is
do> >     ipv6_prefer=NO.
do>
do> Once again, what is the reason for this change? My read of the
do> IPv6-using community is that if they have it available they want to
do> use it as a first choice. I know that is certainly my preference.

 Because IMHO the name $ipv6_enable was inappropriate (IPv6 is enabled
 by kernel already) from the start, and I want to use a new name
 rather than changing behavior of the old variable since they are not
 identical to each other.

 My patch virtually narrows the behavior down to 1) whether it marks
 non-manually-configured interfaces as IFDISABLED or not, and 2)
 whether it uses or not IPv6 address rather than IPv4 address when the
 both are available.  Also, people can notice that the variable is
 changed if the name is different.

 I understand the feeling that we do not want to change a
 long-standing practice for IPv6 configuration.  I want to fix such
 inconsistencies and make the IPv6 enabled by default on this occasion
 of the major version bump.

-- Hiroki

Index: etc/network.subr
===================================================================
--- etc/network.subr (revision 197340)
+++ etc/network.subr (working copy)
@@ -97,15 +97,26 @@
  if afexists inet6; then
  if ipv6if $1; then
  if checkyesno ipv6_gateway_enable; then
- _ipv6_opts="-accept_rtadv auto_linklocal"
+ _ipv6_opts="-accept_rtadv"
+ fi
+ else
+ if checkyesno ipv6_prefer; then
+ _ipv6_opts="-ifdisabled"
  else
- _ipv6_opts="auto_linklocal"
+ _ipv6_opts="ifdisabled"
  fi
- else
- _ipv6_opts="-auto_linklocal ifdisabled"
+
+ # backward compatibility: $ipv6_enable
+ case $ipv6_enable in
+ [Yy][Ee][Ss])
+ _ipv6_opts="${_ipv6_opts} accept_rtadv"
+ ;;
+ esac
  fi

- ifconfig $1 inet6 ${_ipv6_opts}
+ if [ -n "${_ipv6_opts}" ]; then
+ ifconfig $1 inet6 ${_ipv6_opts}
+ fi

  # ifconfig_IF_ipv6
  ifconfig_args=`ifconfig_getargs $1 ipv6`
@@ -382,7 +393,7 @@
 # 1 otherwise.
 ipv6if()
 {
- local _if i
+ local _if _tmpargs i
  _if=$1

  if ! afexists inet6; then
@@ -396,6 +407,18 @@
  ;;
  esac

+ # True if $ifconfig_IF_ipv6 is defined.
+ _tmpargs=`_ifconfig_getargs $_if ipv6`
+ if [ -n "${_tmpargs}" ]; then
+ return 0
+ fi
+
+ # backward compatibility: True if $ipv6_ifconfig_IF is defined.
+ _tmpargs=`get_if_var $_if ipv6_ifconfig_IF`
+ if [ -n "${_tmpargs}" ]; then
+ return 0
+ fi
+
  case "${ipv6_network_interfaces}" in
  [Aa][Uu][Tt][Oo])
  return 0
@@ -431,17 +454,30 @@
  if checkyesno ipv6_gateway_enable; then
  return 1
  fi
+ _tmpargs=`get_if_var $_if ipv6_prefix_IF`
+ if [ -n "${_tmpargs}" ]; then
+ return 1
+ fi

  case $_if in
  lo0|\
  stf[0-9]*|\
  faith[0-9]*|\
  lp[0-9]*|\
- sl[0-9]*)
+ sl[0-9]*|\
+ pflog[0-9]*|\
+ pfsync[0-9]*)
  return 1
  ;;
  esac

+ # backward compatibility: $ipv6_enable
+ case $ipv6_enable in
+ [Yy][Ee][Ss])
+ return 0
+ ;;
+ esac
+
  _tmpargs=`_ifconfig_getargs $_if ipv6`
  for _arg in $_tmpargs; do
  case $_arg in
@@ -451,6 +487,16 @@
  esac
  done

+ # backward compatibility: $ipv6_ifconfig_IF
+ _tmpargs=`get_if_var $_if ipv6_ifconfig_IF`
+ for _arg in $_tmpargs; do
+ case $_arg in
+ accept_rtadv)
+ return 0
+ ;;
+ esac
+ done
+
  return 1
 }

@@ -691,7 +737,7 @@
  ;;
  *)
  ifconfig $1 inet6 ${ifconfig_args} alias && _ret=0
- warn "\$ipv6_ifconfig_$1_alias${alias} is obsolete."
+ warn "\$ipv6_ifconfig_$1_alias${alias} is obsolete." \
     "  Use ifconfig_$1_aliasN instead."
  ;;
  esac
@@ -773,6 +819,7 @@
  done

  # backward compatibility: ipv6_ifconfig_IF_aliasN.
+ alias=0
  while : ; do
  ifconfig_args=`get_if_var $1 ipv6_ifconfig_IF_alias${alias}`
  case "${ifconfig_args}" in
@@ -780,13 +827,12 @@
  break
  ;;
  *)
- ifconfig $1 inet6 ${ifconfig_args} -alias
- alias=$((${alias} + 1))
- warn "\$ipv6_ifconfig_$1_alias${alias} is obsolete."
+ ifconfig $1 inet6 ${ifconfig_args} -alias && _ret=0
+ warn "\$ipv6_ifconfig_$1_alias${alias} is obsolete." \
     "  Use ifconfig_$1_aliasN instead."
- _ret=0
  ;;
  esac
+ alias=$((${alias} + 1))
  done

  return $_ret
Index: etc/rc.d/netif
===================================================================
--- etc/rc.d/netif (revision 197340)
+++ etc/rc.d/netif (working copy)
@@ -41,7 +41,7 @@
 extra_commands="cloneup clonedown"
 cmdifn=

-set_rcvar_obsolete ipv6_enable
+set_rcvar_obsolete ipv6_enable ipv6_prefer

 network_start()
 {
Index: etc/rc.d/ip6addrctl
===================================================================
--- etc/rc.d/ip6addrctl (revision 197340)
+++ etc/rc.d/ip6addrctl (working copy)
@@ -19,6 +19,8 @@
 prefer_ipv6_cmd="ip6addrctl_prefer_ipv6"
 prefer_ipv4_cmd="ip6addrctl_prefer_ipv4"

+set_rcvar_obsolete ipv6_enable ipv6_prefer
+
 ip6addrctl_prefer_ipv6()
 {
  ip6addrctl flush >/dev/null 2>&1
Index: etc/rc.d/rtadvd
===================================================================
--- etc/rc.d/rtadvd (revision 197340)
+++ etc/rc.d/rtadvd (working copy)
@@ -43,7 +43,10 @@
  case ${rtadvd_interfaces} in
  [Aa][Uu][Tt][Oo]|'')
  for i in `ifconfig -l` ; do
- if is_wired_interface $1; then
+ case $i in
+ lo0) continue ;;
+ esac
+ if ipv6if $i; then
  rtadvd_interfaces="${rtadvd_interfaces} ${i}"
  fi
  done

[hrs]

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.

-- Hiroki

[John Hay-3]

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

[hrs]

John Hay <jhay@...> wrote
  in <20091005055806.GB58246@...>:

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

 What do you mean by "off by default"?  I think IPv6 is not disabled
 by default with the patch.  Re-enabling of "automatic assignment of a
 link-local address by default" has been a big step for IPv6 ready out
 of the box.

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

 The initial patch had several regressions to mistakenly disable the
 functionality, but the current one should work by just adding an
 $ifconfig_IF_ipv6 line to rc.conf.  The intention of my patch is to
 set $ipv6_enable=YES automatically (in more modular manner) when an
 IPv6 configuration is specified for an interface.  Even with no
 per-interface configuration, when $ipv6_prefer=YES, IPv6
 communication by using link-local addresses works.  I believe it does
 not make it so complex compared with the old $ipv6_enable=YES model.

 I feel there is some difference between my understanding of "enable
 by default" and yours.  Do you elaborate the word "enable" a bit
 more, please?

-- Hiroki

[Bjoern A. Zeeb]

On Mon, 5 Oct 2009, John Hay wrote:

Hi,

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

link-local had been enabled by default in the past and I am not sure
if we had a SA or EN for that or that it was just preemptively
disabled.

The problem is that if it is enabled by default you are exposing
yourself to others on the same network.  That is of course especially
bad if you are in untrusted environments like conferences, ... or on a
public LAN.

If we'd support IPv4 link-local addresses by default we would have to
apply the same logic there.

I am not sure about OSX but at least Windows has a firewall set to
deny any unrelated incoming things by default these days.

Just because others haven't yet (really) thought about the problems
doesn't mean they aren't there.

If you want to use IPv4 you either add an address or start DHCP or ..
and you have to configure that.  If you want IPv6, you configure that
as well.  You shall not have anything enbaled by default that people
can use to attack you and you don't know about because you didn't
configure.

While (we) IPv6 people know that it would be there a lot of people are
still totally unaware of IPv6 and they would be surprised.

/bz

--
Bjoern A. Zeeb         It will not break if you know what you are doing.
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[Dag-Erling Smørgrav]

Hiroki Sato <hrs@...> writes:
> John Hay <jhay@...> writes:
> > Is there a good reason why we still ship with ipv6 off by default?
> What do you mean by "off by default"?  I think IPv6 is not disabled by
> default with the patch.

% ident /usr/src/etc/defaults/rc.conf
/usr/src/etc/defaults/rc.conf:
     $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $
% grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf
ipv6_network_interfaces="none" # List of IPv6 network interfaces
#ipv6_network_interfaces="ed0 ep0" # Examples for router
% grep ipv6_prefer /usr/src/etc/defaults/rc.conf
ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used

Does mean that IPv6 is disabled by default?  Who knows?  There is no
coherent explanation *anywhere* of what these variables mean, and
rc.conf(5) does not mention them at all.  In fact, the first hit for
"ipv6" in rc.conf(5) is this:

     ipv6_enable
                 (bool) Enable support for IPv6 networking.  Note that this
                 requires that the kernel has been compiled with options
                 INET6.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[Kevin Oberman]

> From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@...>
> Date: Mon, 05 Oct 2009 20:08:40 +0200
> Sender: owner-freebsd-current@...
>
> Hiroki Sato <hrs@...> writes:
> > John Hay <jhay@...> writes:
> > > Is there a good reason why we still ship with ipv6 off by default?
> > What do you mean by "off by default"?  I think IPv6 is not disabled by
> > default with the patch.
>
> % ident /usr/src/etc/defaults/rc.conf
> /usr/src/etc/defaults/rc.conf:
>      $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $
> % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf
> ipv6_network_interfaces="none" # List of IPv6 network interfaces
> #ipv6_network_interfaces="ed0 ep0" # Examples for router
> % grep ipv6_prefer /usr/src/etc/defaults/rc.conf
> ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used
>
> Does mean that IPv6 is disabled by default?  Who knows?  There is no
> coherent explanation *anywhere* of what these variables mean, and
> rc.conf(5) does not mention them at all.  In fact, the first hit for
> "ipv6" in rc.conf(5) is this:
>
>      ipv6_enable
>                  (bool) Enable support for IPv6 networking.  Note that this
>                  requires that the kernel has been compiled with options
>                  INET6.

Am I missing something here? From the same /etc/defaults/rc.conf:
### IPv6 options: ###
ipv6_enable="NO" # Set to YES to set up for IPv6.

That looks about a "disabled out of the box" as it gets.

As far as I can see (which may not be far), ipv6_network_interfaces is
only relevant to IPv6 routing.

I believe that ipv6_prefer controls the default behavior when DNS returns
both IPv4 and IPv6 addresses for a host. If it is set to "NO", IPv4 will
be tried first (preferred). If set to "YES", the IPv6 address will be
preferred. I strongly recommend keeping ipv6_prefer set to "NO".
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman@... Phone: [phone]
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[Dag-Erling Smørgrav]

"Kevin Oberman" <oberman@...> writes:
> Am I missing something here? From the same /etc/defaults/rc.conf:
> ### IPv6 options: ###
> ipv6_enable="NO" # Set to YES to set up for IPv6.
>
> That looks about a "disabled out of the box" as it gets.

AFAIK, ipv6_enable has no effect.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[Dimitry Andric]

On 2009-10-05 05:34, Hiroki Sato wrote:
>  The patch for stable/8 can be found at:
>
>   http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff

Hmm, build bombs out at sbin/ifconfig:

===> sbin/ifconfig (depend)
make: don't know how to make af_nd6.c. Stop
*** Error code 2

This is because the patch doesn't seem to contain
sbin/ifconfig/af_nd6.c.  Can I just use the version from head?
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[hrs]

Dag-Erling Smørgrav <des@...> wrote
  in <86my45vhlj.fsf@...>:

de> Hiroki Sato <hrs@...> writes:
de> > John Hay <jhay@...> writes:
de> > > Is there a good reason why we still ship with ipv6 off by default?
de> > What do you mean by "off by default"?  I think IPv6 is not disabled by
de> > default with the patch.
de>
de> % ident /usr/src/etc/defaults/rc.conf
de> /usr/src/etc/defaults/rc.conf:
de>      $FreeBSD: head/etc/defaults/rc.conf 197619 2009-09-29 16:49:10Z dougb $
de> % grep ipv6_network_interfaces /usr/src/etc/defaults/rc.conf
de> ipv6_network_interfaces="none" # List of IPv6 network interfaces
de> #ipv6_network_interfaces="ed0 ep0" # Examples for router
de> % grep ipv6_prefer /usr/src/etc/defaults/rc.conf
de> ipv6_prefer="NO" # Use IPv6 when both IPv4 and IPv6 can be used
de>
de> Does mean that IPv6 is disabled by default?  Who knows?  There is no
de> coherent explanation *anywhere* of what these variables mean, and
de> rc.conf(5) does not mention them at all.  In fact, the first hit for
de> "ipv6" in rc.conf(5) is this:
de>
de>      ipv6_enable
de>                  (bool) Enable support for IPv6 networking.  Note that this
de>                  requires that the kernel has been compiled with options
de>                  INET6.

No, the rc.conf(5) has been updated in r197526:

     ipv6_enable
                 (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is
                 added to all of ifconfig_<interface>_ipv6 and the ipv6_prefer
                 is defined as ``YES''.

                 This variable is deprecated.  Use ipv6_prefer and
                 ifconfig_<interface>_ipv6.

and UPDATING also explains the relationship between the $ipv6_enable
and the other variables.

IMHO "Enabling (or disabling) IPv6" is not a correct expression for
$ipv6_enable and $ipv6_prefer.  If you use a kernel with "options
INET6" (GENERIC has it) IPv6 is enabled, and $ipv6_enable=NO in the
old releases does not disable the functionality.  It just controlled
whether $ipv6_* in rc.conf are ignored or not.

-- Hiroki

[hrs]

Dimitry Andric <dimitry@...> wrote
  in <4ACA4B81.3090105@...>:

di> On 2009-10-05 05:34, Hiroki Sato wrote:
di> >  The patch for stable/8 can be found at:
di> >
di> >   http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff
di>
di> Hmm, build bombs out at sbin/ifconfig:
di>
di> ===> sbin/ifconfig (depend)
di> make: don't know how to make af_nd6.c. Stop
di> *** Error code 2
di>
di> This is because the patch doesn't seem to contain
di> sbin/ifconfig/af_nd6.c.  Can I just use the version from head?

 Yes, you can use the file in HEAD.  I do not know why but "svn diff"
 seems not to generate a diff delta for a newly-added file by "svn
 merge"...

 The missing delta can also be found at:

 http://people.freebsd.org/~hrs/af_nd6.c.diff

-- Hiroki

[Dag-Erling Smørgrav]

Hiroki Sato <hrs@...> writes:
> No, the rc.conf(5) has been updated in r197526:
>
>      ipv6_enable
>                  (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is
>                  added to all of ifconfig_<interface>_ipv6 and the ipv6_prefer
>                  is defined as ``YES''.
>
>                  This variable is deprecated.  Use ipv6_prefer and
>                  ifconfig_<interface>_ipv6.

Still not very helpful.

If I install FreeBSD from a release CD and use the GENERIC kernel and do
*not* want to use IPv6, what do I do?

Please don't answer "compile a custom kernel".

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[hrs]

Dag-Erling Smørgrav <des@...> wrote
  in <8663atv9dz.fsf@...>:

de> Hiroki Sato <hrs@...> writes:
de> > No, the rc.conf(5) has been updated in r197526:
de> >
de> >      ipv6_enable
de> >                  (bool) If the variable is ``YES'', ``inet6 accept_rtadv'' is
de> >                  added to all of ifconfig_<interface>_ipv6 and the ipv6_prefer
de> >                  is defined as ``YES''.
de> >
de> >                  This variable is deprecated.  Use ipv6_prefer and
de> >                  ifconfig_<interface>_ipv6.
de>
de> Still not very helpful.
de>
de> If I install FreeBSD from a release CD and use the GENERIC kernel and do
de> *not* want to use IPv6, what do I do?
de>
de> Please don't answer "compile a custom kernel".

 It depends on the definition of "use", but the answer is "do not put
 any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf".  If so, IPv6
 will be "disabled" (including communication using link-local
 addresses) on all of interfaces except lo0.  It is the default
 behavior now.

 I do not think this means "IPv6 is disabled by default".  By adding
 an IPv6 address by using ifconfig(8) after boot you can still use
 IPv6 on that interface.  This is almost the same as IPv4 does.  When
 I do not want to use IPv4, I do not put any IPv4 addresses to
 $ifconfig_IF.

 Strictly speaking the address ::1/128 on lo0 cannot be removed
 because it is assigned by the kernel itself unlike IPv4's 127.0.0.1,
 so you can use the loopback address without knowing it.  If you do
 not want to use it, you can disable IPv6 on lo0 manually by "ifconfig
 lo0 inet6 ifdisabled".  Anyway, the existence of this loopback
 address has not been changed for a long time.

-- Hiroki

[Doug Barton]

Hiroki Sato wrote:
> Hi,
>
>  I would like your comments about merging the network_ipv6 -> netif
>  integration to stable/8.  

I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As
stated previously my objections are as follows (in decreasing order of
general importance):

1. It is a fairly significant change happening too late in the release
cycle. IMO that is reason enough to not allow the change.
2. Although 8.0 seems to be getting more beta/rc testing than previous
.0 releases, the overall number of users testing it is still a small
percentage of the userbase.
3. A dramatically smaller percentage of those users who are actually
doing the testing is also using IPv6.
4. There are still rough edges to the changes.
5. I personally disagree with some of the choices you've made and
would like to see more discussion about them. (More about 4 and 5 below.)

The rough edges I've noticed have to do with the various problems
people have reported to the lists, including what seems to be a lack
of testing without IPv6 in the kernel, continuing evolution of how to
deal with the afnet tests, and personally I've noticed the following
on my console, although I haven't had time to research yet whether
it's definitely coming from your changes:

in6_ifattach_linklocal: failed to add a link-local addr to wpi0

In terms of design decisions you've made, I am still confused about
why you insist on deprecating ipv6_enable. Recent discussion on the
lists indicates to me that I'm not alone in thinking that this is a
valuable mechanism and that there is not only no reason to deprecate
it, to do so is not desirable.

I'd also like to explore further the idea that I suggested in a
previous thread that it should not be necessary to specify
ifconfig_IF_ipv6 at all. The vast majority of users will be using RA
for the next couple of years at least, so in my mind it makes sense to
default to using ipv6_network_interfaces=$network_interfaces and RA by
default. If the user has a need to configure something explicitly then
you've provided the mechanism for them to do that, but they shouldn't
be forced to use it. This is another reason that I think ipv6_enable
should be the "master" knob. I like the idea of the ipv6_prefer knob,
but I do not like the idea of overloading it with the function of
ipv6_enable too.

I can certainly understand why you are eager to get these changes into
8.0, however if we do a proper job of maintaining backwards
compatibility (which I think we should do anyway) I don't see any
reason that they cannot be merged after 8.0, and more importantly
after they have had a proper opportunity to shake out in HEAD.


Doug

--

    This .signature sanitized for your protection

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

[Li, Qing]

I agree with Doug and I'd prefer getting more runtime cycles
out of these changes before MFC into stable/8.

On a semi-related topic, I like the features developed in r197138.

The changes are significant enough that having a MFC of 3 days
is way too short. This changelist should also be postponed to post
REL_8.

-- Qing



> -----Original Message-----
> From: owner-freebsd-current@... [mailto:owner-freebsd-
> current@...] On Behalf Of Doug Barton
> Sent: Monday, October 05, 2009 3:23 PM
> To: Hiroki Sato
> Cc: freebsd-current@...; freebsd-rc@...
> Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif
integration

>
> Hiroki Sato wrote:
> > Hi,
> >
> >  I would like your comments about merging the network_ipv6 -> netif
> >  integration to stable/8.
>
> I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As
> stated previously my objections are as follows (in decreasing order of
> general importance):
>
> 1. It is a fairly significant change happening too late in the release
> cycle. IMO that is reason enough to not allow the change.
> 2. Although 8.0 seems to be getting more beta/rc testing than previous
> .0 releases, the overall number of users testing it is still a small
> percentage of the userbase.
> 3. A dramatically smaller percentage of those users who are actually
> doing the testing is also using IPv6.
> 4. There are still rough edges to the changes.
> 5. I personally disagree with some of the choices you've made and
> would like to see more discussion about them. (More about 4 and 5
> below.)
>
> The rough edges I've noticed have to do with the various problems
> people have reported to the lists, including what seems to be a lack
> of testing without IPv6 in the kernel, continuing evolution of how to
> deal with the afnet tests, and personally I've noticed the following
> on my console, although I haven't had time to research yet whether
> it's definitely coming from your changes:
>
> in6_ifattach_linklocal: failed to add a link-local addr to wpi0
>
> In terms of design decisions you've made, I am still confused about
> why you insist on deprecating ipv6_enable. Recent discussion on the
> lists indicates to me that I'm not alone in thinking that this is a
> valuable mechanism and that there is not only no reason to deprecate
> it, to do so is not desirable.
>
> I'd also like to explore further the idea that I suggested in a
> previous thread that it should not be necessary to specify
> ifconfig_IF_ipv6 at all. The vast majority of users will be using RA
> for the next couple of years at least, so in my mind it makes sense to
> default to using ipv6_network_interfaces=$network_interfaces and RA by
> default. If the user has a need to configure something explicitly then
> you've provided the mechanism for them to do that, but they shouldn't
> be forced to use it. This is another reason that I think ipv6_enable
> should be the "master" knob. I like the idea of the ipv6_prefer knob,
> but I do not like the idea of overloading it with the function of
> ipv6_enable too.
>
> I can certainly understand why you are eager to get these changes into
> 8.0, however if we do a proper job of maintaining backwards
> compatibility (which I think we should do anyway) I don't see any
> reason that they cannot be merged after 8.0, and more importantly
> after they have had a proper opportunity to shake out in HEAD.
>
>
> Doug
>
> --
>
>     This .signature sanitized for your protection
>
> _______________________________________________
> freebsd-current@... mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-
> unsubscribe@..."

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

[Dag-Erling Smørgrav]

Hiroki Sato <hrs@...> writes:

> Dag-Erling Smørgrav <des@...> writes:
> > If I install FreeBSD from a release CD and use the GENERIC kernel
> > and do *not* want to use IPv6, what do I do?
>  It depends on the definition of "use", but the answer is "do not put
>  any $ifconfig_IF_ipv6 or $ipv6_prefer to your rc.conf".  If so, IPv6
>  will be "disabled" (including communication using link-local
>  addresses) on all of interfaces except lo0.  It is the default
>  behavior now.
>
>  I do not think this means "IPv6 is disabled by default".

Close enough from my POV...  thanks.

Network configuration is complicated enough that I think we should have
a separate man page for it; rc.conf is pretty much useless unless you
already know what you're looking for.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."

[Dimitry Andric]

On 2009-10-05 21:39, Dimitry Andric wrote:
>>   http://people.freebsd.org/~hrs/ipv6_stable8.20091005.diff
> Hmm, build bombs out at sbin/ifconfig:
...
> This is because the patch doesn't seem to contain
> sbin/ifconfig/af_nd6.c.  Can I just use the version from head?

FYI, the patch also misses etc/rc.d/{faith,stf}.  Without these,
mergemaster fails; again, taking them from head fixes it.
_______________________________________________
freebsd-rc@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "freebsd-rc-unsubscribe@..."