<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 20, 2013 at 1:34 AM, Hannes Frederic Sowa <span dir="ltr"><<a href="mailto:hannes@stressinduktion.org" target="_blank">hannes@stressinduktion.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">> > NM has a user-space RA listener.<br>


> ><br>
><br>
> Sigh. Why do we keep reinventing the wheel? What was wrong with the<br>
> in-kernel RA implementation?<br>
<br>
</div></div>I wondered myself and got this response:<br>
<a href="http://www.spinics.net/lists/netdev/msg255581.html" target="_blank">http://www.spinics.net/lists/netdev/msg255581.html</a></blockquote><div><br></div><div>Hmm. It looks like the answer is:</div><div><br></div><div>

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.</div>

<div><br></div><div>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.</div><div><br></div><div>

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.</div>

<div><br></div><div>Dan's proposal to have the kernel do a part of the address config and userspace do another part seems brittle though.</div></div></div></div>