Re: IPv6 configuration in rc.d

Doug Barton <dougb_at_FreeBSD.org> wrote
  in <4BCB6A14.5040308_at_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