Date:        Mon, 1 Jul 2002 13:39:09 -0500 (CDT)
    From:        Lista de NetBSD Users <list10@sepc.edu.mx>
    Message-ID:  <Pine.NEB.4.33.0207011332210.14615-100000@tarkus.csxxi.net.mx>

  | My IPv6 network works *very very very FINE*
  | except in the routers ;)

You're missing a little configuration.

  | Yes, specially host2. I would like to receive
  | mail with ipv6 in host2 but nobody in the world
  | can see the global address of interfase host2-gif0.

An obvious answer would be to just publish it's other address
(host2-ex1) which would probably suffice as a workaround, but
isn't needed, as the fix is simple.

  | Note3:
  | Is a infinite loop between host3-gif2 and cisco-tunX

That's the clue.   That tells you that host3 is sending packets to
the cisco, when it should be sending them to host2 instead.   That
tells you to go look in host3's routing table, which we can do, just
below...

  | NOTE:
  |     host3 needs a push in order to work with the cisco
  |     of my ISP (ipv6) and the push is the following:

This tells you that the cisco config isn't advertising a default
route.   cisco tend not to advertise default by default, but generally
will if they are configured to.   But this isn't your problem.
If it bothers you, complain to the ISP, and have them advertise an IPv6
default to you.

  |     (Does host2 needs a push like this?)

No, its routing table shows a default route included.   If it didn't,
neither host2, nor anything connected via it (host1) would be able
to reach the world.

  |     (what about I run zebra/ripng instead route6d in host2?)

No difference, the problem isn't on host2 as seen above - it is on host3
(and due to the nature of the problem, there's nothing host2 can really
do to influence it).

This is where you see the problem ...

  | host3# netstat -rn
  | Internet6:
  | Destination                   Gateway                   Flags     Refs     Use    Mtu  Interface
  | 3ffe:aaaa:bbbb:2:250:daff:fe69:47fd ::1                       UH          0       27  33228  lo0
  | 3ffe:aaaa:bbbb:4::/64         link#2                    UC          2        0   1500  ex1
  | 3ffe:aaaa:bbbb:4:250:daff:fe69:4749 00:50:da:69:47:49         UHLc        0        9   1500  ex1
  | 3ffe:aaaa:bbbb:4:250:daff:fe69:48d6 00:50:da:69:48:d6         UHLc        0      987   1500  lo0
  | 3ffe:aaaa:bbbb:6::2           ::1                       UH          0       95  33228  lo0
  | 3ffe:aaaa:bbbb:6:250:daff:fe69:47fd ::1                       UH          0        0  33228  lo0
  | 3ffe:aaaa:bbbb:10::/64        fe80::250:daff:fe6b:7ae6%gif1 UG1         0      199   1280  gif1
  | -----------------------------------------------------
  | This table looks nice... I like it

It might look nice, but it is wrong for your configuration, so you
don't really like it after all...

I deleted all the irrelevant parts, left just the bit that matters.

Notice that you have routed to prefix:4/64 and prefix:10/64 (that is,
routes to those subnets).    But you have no routes to prefix:2/64 nor
to prefix:6/64.   I'm not sure what prefix:6 is supposed to be numbering,
so will say no more on that (you might need to fix it, or you might not).

But prefix:2 is the net you have assigned to the tunnel to host2.
You're not going to be able to reach any addresses on that net (except
the address assigned to the local end of the tunnel, for which a host
route exists) unless you create a route for it.

Look at the setup on host3 for ex1 (prefix:4/64) - that has the correct
routes, and allows any address to be reached.

You need the same on gif2 - its routes should look just the same (because
it is a point to point link, and so has exactly 2 allocated addresses
normally, you could "cheat" and just install a host route for host2-gif0
but that's not really the right way).

The setup on ex1 would have happened automatically, ethernets add routes
to their connected nets when they're configured (on NetBSD anyway, I believe
that on linux even that doesn't happen, not that it is relevant).   But on
NetBSD, point to point links don't add routes to their connected net.
You have to do that yourself.

In ifconfig.gif1 (on host3 of course) somewhere near the end, add

	! route add -inet6 3ffe:aabb:ccdd:2:: -prefixlen 64 fe80::99%gif1

The actual address at the end of the line doesn't matter, provided it is
a link local address, and ends "%gif1", and doesn't happen to be the link
local address assigned to the local node.   It doesn't hurt to make it be
the LL address of host2 on (its) gif0 - but that isn't required (logically
that is what would be correct, but in this setup, the address isn't used
anywhere, for anything, so it really doesn't matter).

You could also to the route change trick (like you used for the gif2 to
add the default route) to make it an interface route if you prefer (that
you can't just add an interface route directly is a bug that should be
fixed sometime or other).   You can also use the "any random link local
address" trick so only one command is needed for the default route setup
to the cisco if you prefer.

That will be enough to get the packets delivered that you want delivered.

Beyond that, you should also be squashing the routing loop, and any others
like it.   Make sure that (on the cisco in your setup I would guess)
you have a reject route (on a cisco that's a route to nul0 or nul1 or
something) installed for prefix::/48 so packets for subnets that don't
exist won't start looping.   You might have that already, you didn't
show your the cisco config.   It is also possible that that route should
be in host3 instead (it depends just who owns what addresses, and what
kind of routing is being done).   If the cisco has none of the prefix::/48
addresses assigned to it, apart from one on its tunnel to you (ie: the
tunnel to host3 is numbered out of your prefix, we can see that), and simply
routes all of prefix::/48 to you (probably other than the one address it
uses for its tunnel endpoint), then you need the reject route installed
on host3 (and it would have prevented the loop in this case).

Look in /etc/rc.d/network to see how reject routes get installed.

kre