<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 30, 2013 at 3:53 PM, Phil Mayers <span dir="ltr"><<a href="mailto:p.mayers@imperial.ac.uk" target="_blank">p.mayers@imperial.ac.uk</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, it's not secure if all clients get all the RAs for all the VLANs,<br>
and (in theory at least) can thus just pick the one that works. The<br>
</blockquote>
<br></div>
Well, RAs contain both the gateway and prefix info. So "the one" isn't quite that simple. For gateways, in theory dead neighbour detection will do the job (unless you have a dumb stack that only uses 1 gateway grumble NetworkManager grumble). For prefixes...</blockquote>
<div><br></div><div>No, I mean - from a *security* perspective there's actually no security, because if there existed a host implementation that always tried all source addresses every time it connected, then that implementation would always work with no issues, even if you tried to put it on a restricted VLAN.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If that's the case,<br>
then you don't need to do routing in DHCPv6 for this to work - if you<br>
want to solve this using DHCPv6, you can do that by using DHCPv6 to<br>
configure addressing, not routing (which you can already do today).<br>
</blockquote>
<br></div>
Good point. But then I have to run DHCPv6-for-addressing with M=1 to give the clients VLAN-appropriate source-addresses *in addition* to RA for prefix/router info. Which gets us back to "why run two protocols" ;o)<br>
</blockquote><div><br></div><div>If you want to solve it with DHCP, then yes, you have to put addresses in DHCP and set A=0 and O=0 in the prefix in the RA. And yes, it is "run two protocols", but some might say, "well, that's the price you pay for picking a terrible architecture" :-)</div>
<div><br></div><div>You could also fix this on the network side. You can even do this while maintaining the architecture :-) - when we had this problem many years ago (on wifi), the vendor fixed it by converting all RAs to unicast. It's not the solution I was advocating, but it does solve the problem.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There's also a small but not inconsiderable number of clients that don't do DHCPv6 yet; so I'd be locking them out, which is maybe tolerable given the alternatives.<br>
</blockquote><div><br></div><div>If you want to solve it using DHCP, then yes, clients that don't support DHCP are out. But again, you can fix this in the network as well. From an architectural perspective, what you have is a hack that happens to work in IPv4 because nothing depends on true VLAN isolation. It doesn't happen to work in IPv6.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And finally, it's been a while since I tested it, but last time I looked the DHCPv6 relay in Cisco IOS didn't work in MPLS L3VPN scenarios on our platform, as it fails to lookup the next-hop correctly, so right now we can't run DHCPv6 (doh!). Which of course makes the whole thing academic from our PoV.<br>
</blockquote><div><br></div><div>There goes your DHCPv6 solution then I guess :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Routing is already fine.<br>
</blockquote>
<br>
I guess there's a problem with communications from prefixA to prefixB; the endpoints will see prefix and on-link info for both, and try to send to each other directly but fail? Haven't tested it, but if so, we're back to suppressing/demuxing/whatever the RAs (or not doing this entire thing).</blockquote>
<div><br></div><div>If the switch drops that traffic, you can fix it by setting O=0 in the RA; all traffic will be sent through the default router. Yes, that will cause hairpinning, but, given the architecture that you chose, there's no way around that.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">Not sure yet. It may be we have to give up the ">1 vlan" thing and forgoe the benefits. Or perhaps DHCPv6 will be widely deployed enough that we can force it for addressing without losing too many clients. Or maybe we'll have ripped & replaced the entire network by then, and some other solution will exist.</span></div>
</blockquote><div><br></div><div>My 2 cents: put each MAC address in its own VLAN and give it a /64 using an RA with O=1 A=1. If you're assuming that the clients are untrusted, that's what you need to do anyway (unless you want to do first-hop security on individual IPv6 addresses, which sounds like a nightmare). That will give you proper isolation, support privacy addresses, /64 sharing, the whole lot. Yes, it will require support from the switch vendor, but who knows, maybe in a few years IPv6 features might be important and they might actually be listening.</div>
<div><br></div><div>IMO this is the direction we should be going in. Not "let's just use DHCPv6, because it works so well in IPv4" (not).</div><div><br></div><div>Cheers,</div><div>Lorenzo</div></div></div>
</div>