Greg Troxel wrote:
> I don't think so.  But you could put them in rc.local instead of
> ifconfig.gif0

   Okay.  I wrote up a network-late script, as a modification of
rc.d/network.  It brings up ifconfig-late.xxN interfaces, and
I've moved my gif0 and gre0 there.

   But, I'm having a different problem.  Both when configured
by that script, and when I try to configure the interface
by hand on the machine, it isn't working.  This is gif0 I'm
talking about.

   I have:

# gif0 config
create
tunnel MY.EXTERNAL.IP4.ADDR OTHER.SIDE.OF.TUNNEL
inet6 2001:0408:1010:ffff::1:1/112 2001:0408:1010:ffff::1:2

   For some reason, this doesn't work.  I can do:

# ifconfig gif0 create
# ifconfig gif0 tunnel MY.EXTERNAL.IP4.ADDR OTHER.SIDE.OF.TUNNEL
# ifconfig gif0
gif0: flags=8050<POINTOPOINT,RUNNING,MULTICAST> mtu 1280
         tunnel inet MY.EXTERNAL.IP4.ADDR --> OTHER.SIDE.OF.TUNNEL
# ifconfig gif0 inet6 2001:0408:1010:ffff::1:1/112 2001:0408:1010:ffff::1:2
ifconfig: SIOCAIFADDR: Invalid argument
# ifconfig gif0 inet6 2001:0408:1010:ffff::1:1 2001:0408:1010:ffff::1:2
ifconfig: SIOCAIFADDR: Invalid argument
#

   No matter what I do, I can't seem to get rid of that error.
Now, I looked at the source to ifconfig, and it is a little
naive about what it prints.  In the case of an IPv6 addr, it's
actually using the SIOCAIFADDR_IN6 ioctl, it just doesn't put
that in the warn().  And, if I look in sys/netinet6/in6.c, I
see a small number of places where EINVAL could be returned.

   The one I think is most likely is:

netinet6/in6.c, rev 1.86, line 628-:
         case SIOCAIFADDR_IN6:
         {
                 int i, error = 0;
                 struct nd_prefix pr0, *pr;

                 /* reject read-only flags */
                 if ((ifra->ifra_flags & IN6_IFF_DUPLICATED) != 0 ||
                     (ifra->ifra_flags & IN6_IFF_DETACHED) != 0 ||
                     (ifra->ifra_flags & IN6_IFF_NODAD) != 0 ||
                     (ifra->ifra_flags & IN6_IFF_AUTOCONF) != 0) {
                         return (EINVAL);
                 }

   Now, I'm not sure if any of these flags are set.  But, in
theory, it wouldn't be unreasonable if IFF_NODAD was set,
because this is the first address being set, which is when
you'd expect NODAD to be set.

   But, more than that, I didn't *used* to have this problem.
Running 2.0 or 2.0.1 on this same machine, I was able to
set this tunnel up earlier.

   Does anyone have any suggestions as to things I could try to
better diagnose the problem I'm having?

   Thanks...

                               - Chris