Date: Wed, 14 Mar 2007 17:17:45 +0200 From: John Hay <jhay@meraka.org.za> To: "JINMEI Tatuya / ?$B?@L@C#:H" <jinmei@isl.rdc.toshiba.co.jp> Cc: "Bruce A. Mah" <bmah@freebsd.org>, freebsd-net@freebsd.org Subject: Re: IPv6 over gif(4) broken in 6.2-RELEASE? Message-ID: <20070314151745.GA45847@zibbi.meraka.csir.co.za> In-Reply-To: <y7vmz47x9e4.wl%jinmei@isl.rdc.toshiba.co.jp> References: <20070120162936.GA18104@tomcat.kitchenlab.org> <20070121073244.GA80811@zibbi.meraka.csir.co.za> <y7vmz47x9e4.wl%jinmei@isl.rdc.toshiba.co.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Tatuya, Well after getting distracted for a while, I am back with this one. On Fri, Jan 26, 2007 at 03:13:07AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > >>>>> 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. Maybe some background. Olsrd (http://www.olsr.org/) does not use link-local addresses. I think it might have made thinks simpler... Except if you kill it in a weird way, it should remove routes that it have added, so I guess we don't really need a timeout. I can think of 3 types of routes that olsr use: 1) A direct route. In a single interface, you actually would not need these because the standard FreeBSD/Kame IPv6 code would handle it. The problem come in when you have more than one interface (and in the same subnet). I think it would be great if I can just tell the kernel which interface to use and let it do all the normal IPv6 stuff to make comms work to that host, but do it on the specified interface. If it then timeout the low-level stuff because of comms problems, that is fine, as long as it remember which interface to use when it has to try again. Let me try a picture: An olsr router may have more than one wireless interface to cover different areas. In this example ath0 and ath1 are configured with the same IPv6 subnet, eg. fd12:3:4:5::/48 --------------------- | | | D | | | |ath0 ath1| --------------------- )-| |-( ) ( ) ( A B C Then the client might be somewhere between A and B and sometimes work through ath0 and sometimes through ath1. Olsrd must be able to tell the kernel which interface to use. And it must keep on using that interface until olsrd delete that route and add another one. 2) A host route through another host. In my above picture, C might be too far to reach D directly, so it will need to add a route through B to get to D and A. The signal might fluctuate a bit, so it might be that C can reach D directly sometimes, so it must be possible for olsrd to delete a type 1 route and add a type 2 and also the other way around. I guess what I am saying is that when olsrd removes a route and the kernel have added some of its own stuff to make it work, that has to be deleted too or at least not stand in the way when another route for the same destination is added. 3) A network route. These are what they call HNA routes. They are not a problem on FreeBSD because they are our "normal" kind, eg. "route add 3ffe::/16 1234:4567::89" If you have more questions, please ask. Thanks. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070314151745.GA45847>