<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 30, 2013 at 5:07 AM, Brian E Carpenter <span dir="ltr"><<a href="mailto:brian.e.carpenter@gmail.com" target="_blank">brian.e.carpenter@gmail.com</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="im"><span style="color:rgb(34,34,34)">What I'm seeing is Nick describing a use case in bits and pieces.</span><br>

</div>
If we could have a draft that describes the use case completely,<br>
with example numerical requirements, that would be very helpful IMHO.<br></blockquote><div><br></div><div>AIUI Nick has said that the main reason to he wants to put routing in DHCPv6 is because his network will need to run DHCPv6 anyway and doesn't want to use two protocols.</div>

<div><br></div><div><div>Not sure you can really call that a use case, since it's not something that can't be done with RAs.</div></div><div><br></div><div>The failover considerations are not relevant since those depend only on the router redundancy protocol (e.g., VRRP), not on the protocol used to communicate routing information to hosts.</div>

<div><br></div><div>The fact that RAs cannot provision different information to different hosts is also mostly a question of which protocol is used between the routers and the configuration store (e.g., radius), not so much which protocol is used between the routers and the hosts. For example, current access network gear can already send different RAs to different clients by automatically putting clients into different VLANs based on MAC address and fetching the VLAN information from radius.</div>

<div><br></div><div>So - again AIUI - the argument is mostly the usual "DHCPv6 is more suited to this network than RAs". This is true, but there are other networks where RAs are a better fit than DHCPv6. The question has always been whether we should completely duplicate routing configuration functionality into DHCPv6, and add support for that into clients, and the answer has repeatedly been that there is no consensus to do so.</div>

</div></div></div>