IPv6 Security [Was: Re: misunderstanding scale]
Luke S. Crawford
lsc at prgmr.com
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,
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
More information about the NANOG