IPv6 Security [Was: Re: misunderstanding scale]

Wed Mar 26 23:25:57 UTC 2014

On 03/26/2014 03:49 PM, Matt Palmer wrote:
> On Wed, Mar 26, 2014 at 10:55:03AM -0700, Luke S. Crawford wrote:
>> There are many ways to skin this cat; stateless autoconfig looks
>> like it mostly works, but privacy extensions seem to be the default
>> in many places; outgoing IPv6 from those random addresses will trip
>> my BCP38 filters.
>
> Your what-now?  You do realise SLAAC works entirely within a single /64,
> which shouldn't be difficult to decide is either routable or not in one hit,
> right?

If you give every customer their own vlan and /64, sure. That can be 
done, and there are many advantages to doing it that way.   But it's 
quite a bit more complex than my current setup.

The way I'm setup now, I've got an IPv4  address block on a vlan, and an 
IPv6/64 on the same vlan.   I have many customers on that vlan.   Each 
customer has one (or more) IPv4 /32 addresses and one IPv6 /128 
addresses. (if the customer wants more IPv6, we just route a /64 to the 
/128 they are allowed.)  There are firewall rules that only allow 
appropriate packets in and out of the interface.    These rules are 
important for privacy as well as preventing spoofing;  they prevent 
sniffing of most traffic bound for other guests.

This is in production on many of my hosts, and because I give every user 
both an IPv4 and an IPv6 address, this mostly works.  My setup scripts 
wire down both the v4 and v6 addresses before I hand it off to the user; 
   if the user wants re-install, well, they can wire down the IPv6 
address by hand if they want it, and IPv4 works regardless.

It is valid to say that I'm trying to use IPv6 the way I use IPv4, and 
perhaps that is the wrong thing to do.  Perhaps IPv6 needs to be thought 
of in a different way from IPv4;  Perhaps in IPv6, a /64 should be the 
smallest block I give to a user, and the smallest block I filter on, and 
I just need to eat the network complexity costs inherent to giving each 
user a vlan.

My original comment and complaint, though, was in response to the 
assertion that DHCPv6 is as robust as DHCPv4.   My point is that DHCPv6 
does not fill the role that DHCPv4 fills, if you care about tying an IP 
to a MAC and you want that connection to persist across OS installs by 
customers.