Date: Sat, 24 Apr 2010 00:26:08 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: dougb@FreeBSD.org Cc: freebsd-current@FreeBSD.org, bz@FreeBSD.org Subject: Re: IPv6 configuration in rc.d Message-ID: <20100424.002608.259526748.hrs@allbsd.org> In-Reply-To: <4BCB6A14.5040308@FreeBSD.org> References: <4BCA2B55.9000609@FreeBSD.org> <20100419.040457.248129042.hrs@allbsd.org> <4BCB6A14.5040308@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Apr_24_00_26_08_2010_381)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Doug Barton <dougb@FreeBSD.org> wrote
in <4BCB6A14.5040308@FreeBSD.org>:
do> > # ifconfig gif0 create
do> > # ifconfig gif0 up
do>
do> Your statement is literally true, in this case the network.subr stuff
do> "has no control" because it isn't run. That was the same for the old
do> code as it is for the new code.
No, in this case devd(8) invokes rc.d/netif as it is created. The
old code does "ifconfig inet6 -ifdisabled" before it becomes "up"
when ipv6_prefer=YES, and the new code always does "ifconfig inet6
ifdisabled" when no ifconfig_gif0_ipv6 line, respectively.
do> Note that IPv6 link-local addresses (those that start with fe80::) will
do> be automatically configured whenever possible. You may need to remove
do> IPv6 link-local addresses manually using ifconfig(8) ...
No, the ifdisabled flag set via devd(8) prevents this.
do> > IPv4 people hates that gif0 has an IPv6 link-local (and IPv6
do> > communication itself),
do>
do> People who don't want v6 at all compile it out of the kernel, and the
do> whole problem goes away. The project made a decision a long time ago to
do> ship with v6 in GENERIC, so this is not a new issue.
No, the auto link-local addr assignment was turned to off by default
some years ago for this reason. This was a secteam's decision after
IPv6 was included in GENERIC. This is an issue for both IPv4 and
IPv6 people.
do> > and IPv6 people hates that it needs an
do> > additional step to enable it (ifconfig inet6 -ifdisabled in this
do> > case). gif (and other cloned interfaces) can be created by a program
do> > (a ppp script, for example), so we cannot prepare $ifconfig line in
do> > rc.conf in advance.
do>
do> Why not? There is no reason you can't have ifconfig_* lines for
do> interfaces that are not always configured, I do it all the time.
Because the interface identifier cannot always be known in advance.
For example, IPv6 tunnel server/client which accept an incoming
connection and establish a gif tunnel between the two create a lot of
gif interfaces on demand, and the created gif interfaces must be
ready for IPv6 without "ifconfig -ifdisabled" if the sysadmin wants
IPv6. The net/dtcp{,client} in the ports collection is one of the
typical applications. This situation is also common in a
linkup/linkdown scripts for PPP(IPV6CP). Having all possible
interface names in rc.conf is not practical even if the number of
interfaces is small. IPv6 people (including me) surely want a knob
for "-ifdisabled on interfaces with no $ifconfig line in rc.conf" if
an interface has the ifdisabled flag. Without it, such kind of
programs do not work.
Of course we can fix the programs to always use -ifdisabled, but the
ifdisabled flag should not become popular for users. I reluctantly
designed the ifdisabled flag only for IPv4 people who hate a
link-local addr, in order to make IPv6 enabled by default as much as
possible with minimal impact to them as well as IPv6 people. This is
*the reason* why I improved the ifdisabled flag and used it in the
rc.d scripts. This has no compatibility with other KAME-derived
implementation, and for IPv6 people it is nothing but an annoying
obstacle.
The ifdisabled flag never disables the IPv6 functionality, and it can
make various wired situations for IPv6 people because the
functionality is enabled but the communication including the critical
ones is disabled. It can be used only as a seatbelt for IPv4 people;
not as a generic way to disable IPv6 on an interface. My design was
discussed with ex-KAME members last year and we all agreed that the
ifdisabled flag should not be abused in a way other than that. You
can see the difference between "disabling the functionality" and
"disabling the communication" if you read sys/netinet6*.
Anyway, if we will go ahead with "to use IPv6 please do ifconfig
inet6 -ifdisabled first" or "please always add the interface name to
rc.conf" as the current implementation does, I will revert my changes
which added support of the ifdisabled flag into ifconfig before
BSDCan. This flag is just needed to solve the issues I explained in
this and previous emails. If my concerns are just an illusion,
removing the flag makes the world much simpler.
do> Are you theorizing here, or do you have actual examples? If you can find
do> actual examples of "here is something that used to work, but now it does
do> not" then we can work on a solution. I am not necessarily opposed to the
do> idea of automatically creating link-local addresses for cloned
do> interfaces, but it's impossible for me to code against something I don't
do> have in front of me. :)
See tunnel server/client programs like what I described above and/or
try to build an L2TP over UDP concentrator which uses IPV6CP +
DHCPv6-PD.
-- Hiroki
----Security_Multipart(Sat_Apr_24_00_26_08_2010_381)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEABECAAYFAkvRvBAACgkQTyzT2CeTzy2HlQCgznKxD97MoSy/PuH2k2cHQK0k
0bkAoInppZQuSrgNHz4Wp28wYYVw/2V9
=BXPp
-----END PGP SIGNATURE-----
----Security_Multipart(Sat_Apr_24_00_26_08_2010_381)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100424.002608.259526748.hrs>