On Fri, Dec 20, 2013 at 01:47:44AM +0900, Lorenzo Colitti wrote: > On Fri, Dec 20, 2013 at 1:34 AM, Hannes Frederic Sowa < > [email protected]> wrote: > > > > > NM has a user-space RA listener. > > > > > > > > > > Sigh. Why do we keep reinventing the wheel? What was wrong with the > > > in-kernel RA implementation? > > > > I wondered myself and got this response: > > http://www.spinics.net/lists/netdev/msg255581.html > > > Hmm. It looks like the answer is: > > 1. "We want to be able to send RS whenever we feel like it." They could > have used disable_ipv6 for that, or they could have made a write to > accept_ra cause an RS to be sent out. Failing that, an RS is not hard to > generate - it's a multicast packet with no information in it. > > 2. "The kernel doesn't give us enough information to parse RDNSS and DNSSL > options correctly". Fair enough, though this still could have been fixed in > the kernel.
I think this is already fixed. > 3. The kernel doesn't give userspace any say in the process. If the sysctls > are on, it does what the RA tells it to, and if they're off, then userspace > doesn't see any of the advertisements. This is a better reason than the > ones above. I was looking into fixing this using multiple routing tables. What is your idea? Semantics of multiple routing tables are already very complex. Think e.g. about doing L=0 announcements and getting back redirects from a router. Which routing table should we apply this update on? Hold state in the stack on pings? Or just update all routing tables with new on-link information? Same for UDP pmtu discovery.
