Date: Fri, 26 Jan 2007 03:13:07 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: John Hay <jhay@meraka.org.za> Cc: "Bruce A. Mah" <bmah@freebsd.org>, freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? Message-ID: <y7vmz47x9e4.wl%jinmei@isl.rdc.toshiba.co.jp> In-Reply-To: <20070121073244.GA80811@zibbi.meraka.csir.co.za> References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121073244.GA80811@zibbi.meraka.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Sun, 21 Jan 2007 09:32:44 +0200, >>>>> John Hay <jhay@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@isl.rdc.toshiba.co.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vmz47x9e4.wl%jinmei>