Re: IPv6 accept_rtadv + bfe0
----Security_Multipart(Sat_Oct_22_16_13_36_2011_719)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Doug Barton <dougb@FreeBSD.org> wrote
in <4EA23C08.6060906@FreeBSD.org>:
do> On 10/19/2011 00:29, Hiroki Sato wrote:
do> > Mattia Rossi <mrossi@swin.edu.au> wrote
do> > in <4E9DFE11.2070203@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
----Security_Multipart(Sat_Oct_22_16_13_36_2011_719)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEABECAAYFAk6ibSAACgkQTyzT2CeTzy0XPQCgsumDkpNdP62JiuaXg9mlKdBY
A+IAn0dSiHhripJ8iClGbGMOqgfl+xp/
=4blp
-----END PGP SIGNATURE-----
----Security_Multipart(Sat_Oct_22_16_13_36_2011_719)----
討論串 (同標題文章)
完整討論串 (本文為第 7 之 9 篇)：