<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 December 2013 18:57, Shixiong Shang <span dir="ltr"><<a href="mailto:sparkofwisdom.cloud@gmail.com" target="_blank">sparkofwisdom.cloud@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Yes, the man page is a little bit confusing. The “slaac” mode requires “—enable-ra” since it needs to manipulate MOAL bits in the RA. As matter of fact, all of the modes available for IPv6 rely on “—enable-ra”.<div>


<br></div><div>My understanding is, the ra-names option has nothing to do with RA. It resolves the problem of where to find DNS server. It should work with slaac mode or ra-stateless mode.</div></div></blockquote><div><br>


</div><div>I'm going to reiterate what I said in my comment on that patch and its blueprint.  <br><br>1. The patch ties Neutron's parameters specifically to dnsmasq.  It would be, I think, impossible to reimplement this for isc-dhcpd, for instance.<br>


</div><div>2. The fact that ra-names is under consideration says that we're thinking in implementation terms, not API design terms.  dnsmasq isn't a DNS server in Openstack, so ra-names isn't an appropriate choice in any case.  It's only in the list because the options on offer are the options dnsmasq allows, which is the tail wagging the dog.<br>


<br></div><div>What we should have is the reverse: first, what do we want from the interface, and second, what does that imply for the implementation?  I don't think we need all the modes just because dnsmasq offers them.<br>

-- <br>Ian.<br>
</div></div></div></div>