RA & DHCP problem...

[Lorenzo Colitti]

On Mon, Dec 30, 2013 at 3:53 PM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:
>
> Also, it's not secure if all clients get all the RAs for all the VLANs,
>> and (in theory at least) can thus just pick the one that works. The
>>
>
> 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...


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.


> If that's the case,
>> then you don't need to do routing in DHCPv6 for this to work - if you
>> want to solve this using DHCPv6, you can do that by using DHCPv6 to
>> configure addressing, not routing (which you can already do today).
>>
>
> 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)
>

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" :-)

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.

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

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.

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

There goes your DHCPv6 solution then I guess :-)


>  Routing is already fine.
>>
>
> 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).


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.

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

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.

IMO this is the direction we should be going in. Not "let's just use
DHCPv6, because it works so well in IPv4" (not).

Cheers,
Lorenzo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20131230/181be8f3/attachment.htm>