On 30/12/2013 15:13, Lorenzo Colitti wrote:
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.
Er, no. Sorry, I don't understand why you'd think that. Perhaps I am
misunderstanding you, or you me.
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.
I did point this out in my original mail. As noted, our vendor is
IPv6-ignorant, so on this current platform it's not going to happen,
which is a shame as it's a moderately easy solution.
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.
Yes.
If DHCPv6 were usable, and could carry gw/prefix info, perhaps the hack
would work again, and maybe it's a hack that's common and useful to a
number of people, hence my email.
However, since that will never happen IMO, it is (to risk repeating
myself) of solely academic interest to me.
I feel like we're going in circles a bit, so given the above I'm going
to shut up now.
IMO this is the direction we should be going in. Not "let's just use
DHCPv6, because it works so well in IPv4" (not).
Maybe. I guess we'll see in the medium term if those features become
common enough (and operationally usable).
