Re: [v6ops] control and security of DHCP

[Ray Hunter <[e-mail]>]

> Owen DeLong <mailto:[e-mail]>
> 14 January 2014 19:17
> On Jan 14, 2014, at 10:11 , Ray Hunter<[e-mail]>  wrote:
>
>>> Nick Hilliard<mailto:[e-mail]>
>>> 14 January 2014 18:21
>>>
>>> private vlans are troublesome, to say the least. In a virtualised
>>> environment, you need multi-switch support for specific types of pvlans.
>>> This places vendor restrictions on the types of kit you need to deploy.
>>>
>>> Nick
>>> ------------------------------------------------------------------------
>> Yes.
>>
>> I've read posts from a number of DC operators who have expressly chosen for PVLANs compared to deploying dedicated L3 ports per server/ customer in multi-tenant environments, driven by a desire to save on very scarce public IPv4 addresses.
>
> Which might make sense when the customers are on separate hardware.
Agreed. But if you can emulate a L2 LAN, or a L3 router, you can 
presumably also emulate a PVLAN.
> When the customers are separate virtuals on the same hardware, PVLANs become a bit less useful, though at that point, dedicated L3 ports in the virtual switch on the host become much more feasible, though you still have the network addressing cost issue if you're tied to IPv4.
Right..
>> That of course will likely bring problems migrating to IPv6 in the future e.g. DAD is probably not going to be able to detect duplicate addresses via multicast.
>
> Depends on how the PVLANs treat link-scoped IPv6 multicast.
Yes. There's no standard AFAIK.
>
>> Hence my suggestion of prefix length>>  64 + PVLAN + DHCPv6 + DHCPv6 setting default router + HSRPv6/VRRPv3 to exactly mirror the IPv4 setup.
>
> Not sure how that really helps. Why is a longer prefix length allegedly useful in this context?
>
> Owen
>
>
The context of this thread was a request for DHCPv6 to be able to set 
the default router, and avoid using RA.
That's an interesting topic.

I'm happy to continue the discussion about prefix length in detail, but 
shall we do that another time?

Is it sufficient for now to say that in a virtual environment, I think 
it's even more important to contain resource depletion problems and 
potential cross-contamination between environments? The memory used to 
contain e.g. an ND table on one virtual LAN switch or router is almost 
certainly allocated from a shared pool that may not be well protected 
from overflowing. And it's going to be very easy to fill up the TCP 
session tables in e.g. machine firewalls using ip6tables, if a single 
rogue source on the local DC LAN can spoof source addresses from the 
equivalent of an entire continent today.

-- 
Regards,
RayH