IPv6 over gif(4) broken in 6.2-RELEASE?

[JINMEI Tatuya / 神明達哉]

>>>>> On Sun, 21 Jan 2007 09:32:44 +0200, 
>>>>> John Hay <jhay at meraka.org.za> said:

>> There's another workaround for people stuck in this situation and who
>> aren't in a position to try this diff.  That is to manually install
>> the host route like this:
>> 
>> # route add -host -inet6 aaaa:bbbb:cccc:dddd::2 -interface gif0 -nostatic -llinfo
>> 
>> Comments?

> Well it seems that even my stuff does not always work perfectly with that
> change (1.48.2.15), so maybe we should revert it and I will search for
> yet other ways to make FreeBSD's IPv6 code to actually work for our stuff.

> My "stuff" is a wireless IPv6 only network running in adhoc mode with
> olsrd as the routing protocol. The problem is that all nodes on a subnet
> cannot "see" each other, so olsrd needs to add routes to a node through
> another node. Sometimes, just to complicate matters a little more, you
> would want to have more than one network card in a host, all with the same
> subnet address. (For instance on a high site, with sector antennas.)

> The case that I found that still does not work reliably, is if olsrd add
> the route and route is not immediately used, then the nd code will time
> it out and remove it.

I think I'm responsible for the troubles.  I've been thinking about
how to meet all the requests, and concluded that it's more complicated
than I originally thought.

I've come across an idea that may solve the problems, but I'll need
more time to implement and test it.

At the moment, I suggest reverting the 1.48.2.16 change for those who
simply wanted a gif to work.

Regarding the OLSRD stuff, I'd like to know more specific features
that are sought.  For example,

- what should happen if link-layer address resolution fails?  Should
  then entry be removed?  Probably not according to your description
  above, but what would you expect the entry to become in this case?

- once the link-layer address is resolved for the entry, should it be
  regarded as "permanent" without any ND state changes?  For example,
  should NUD be performed on the cache?  If yes, what should happen if
  NUD detects the neighbor is unreachable?  Should the entry be
  removed?  Again, probably not, but then what should it become?
  Keeping it with the same link-layer address?  Keeping it with an
  empty link-layer address?  Others?  What if the neighbor is acting
  as a router (setting the router flag in NAs)?  Should destination
  caches using the now-unreachable router be removed as described in
  the protocol spec?  Or should the destination caches be intact?

I have my own speculation on these points, but I'd like to know what
the actual user(s) of these features want before taking any action
based on the speculation.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp