IPv6 accept_rtadv + bfe0

Hiroki Sato hrs at FreeBSD.org
Sat Oct 22 07:14:09 UTC 2011


Doug Barton <dougb at FreeBSD.org> wrote
  in <4EA23C08.6060906 at FreeBSD.org>:

do> On 10/19/2011 00:29, Hiroki Sato wrote:
do> > Mattia Rossi <mrossi at swin.edu.au> wrote
do> >   in <4E9DFE11.2070203 at swin.edu.au>:
do> >
do> > mr> So the _ipv6 bit doesn't take care of passing "inet6" to ifconfig
do> > mr> automatically?
do> >
do> >  No.  You always need to add the inet6 keyword wherever needed.
do>
do> That seems redundant, and contrary to how the IPv4 equivalents work. And
do> obviously it's confusing to users. From what I can see looking at some
do> 7.x and 8.x systems it also seems to be a POLA violation.
do>
do> Perhaps this is something that you should reconsider?

 I am still thinking that omitting an address family keyword before an
 address is a bad practice.

 Omitting "inet" keyword in ifconfig_IF and doing in ifconfing_IF_AF
 are different.  The former one uses ifconfig(8)'s default AF, and
 bz's experiments of noinet/noinet6 environment showed it was
 problematic.  For the latter a keyword has to be automatically
 prepended in the rc.d scripts if we want to do so.  For IPv6, having
 a non-null $ifconfig_IF_ipv6 means the interface is IPv6-capable and
 doesn't always involve address configuration
 (e.g. ifconfig_IF_ipv6="up" is valid).  So, automatic prepending of
 "inet6" breaks this.  Thus, both have a bad side effect.

 And I want to make ifconfig accept a command line for v4->v6 and/or
 v6->v4 tunneling as a p2p link like "inet 10.1.1.1 2001:db8::1" for a
 specific type of interfaces in the future.  I am not sure if it will
 happen actually, but omitting an AF keyword and/or automatic
 prepending of the keyword make things difficult.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20111022/c8f21396/attachment.pgp


More information about the freebsd-current mailing list