I am currently preparing the Troopers network in a
lab environment to ensure that we all will have a smooth Wi-Fi experience during
Troopers. I wanted to spice things up a little bit for the Wi-Fi deployment
(more on that in a following blogpost) and get rid of IPv4 wherever possible.
Our Wi-Fi infrastructure consists of typical Cisco Access Points (1602) and a
2504 Wireless LAN Controller. Beginning with WLC image 8.0 it is finally
supported to establish the CAPWAP tunnel between the AP and the WLC over IPv6,
which is awesome and I wanted to implement it right away.
We’ve just released a whitepaper discussing the behavior of different operating
systems once they receive IPv6 configuration parameters from different sources.
For that purpose a number of lab tests were conducted.
In short, it’s a mess.
Again, RFC ambiguity and/or
(perceived) vendor implementation freedom suck big time. For us practitioners
out (t)here this means (once more) we need extensive test labs and good
troubleshooting guides for large scale IPv6 deployments.
One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6
in some other posts – many
practitioners have been waiting for quite some time now, is full support of
RFC 6939 (Client Link-Layer Address
Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC
6939 support would allow a number of things which large organizations use in
their DHCPv4 based networks, incl.
reservations (assigning a kind-of fixed DHCP address based on the MAC address
of a system which in turn allows for “centralized administration of somewhat
static addresses”).
correlation of IPv4 and IPv6 addresses of a given host identified by its MAC
address.
(some type) of security enforcement based on the MAC address of a host
gathered in the course of a DHCP exchange (see for example slide #29 of
this presentation of the IPv6 deployment at CERN,
btw: slide #9 might be helpful when discussing IPv6 transition plans with
your CIO. or not).
So far it seemed very few components support RFC 6939. When
Tim Martin mentioned at Cisco Live that Cisco
devices running IOS XE support it by default, we decided go to the lab ;-).
RA Guard Evasion is well-known in the IPv6 “circles”; there is
RFC 7113 Advice for IPv6 Router
Advertisement Guard (RA-Guard) and many interesting blog-posts like this
one here,
here,
and this excellent write-up
here that discuss
this issue.
Moreover, as Jim Smalls states in his comprehensive
“IPv6 Attacks and Countermeasures”
presentation given at the
North American IPv6 Summit 2013,
DHCPv6 Guard or a corresponding IPv6 ACL can stop a DHCPv6 Rogue Servers, but
(only?) for non-malicious/non-fragmented DHCPv6 packets (slide 35). However, at
that time there wasn’t any known attack tool in the wild that had the
fragmentation evasion built in.
Probably due to the (“secondary”) role it has been historically assigned within
the IPv6 universe, DHCPv6 is a protocol which is very different from its IPv4
counterpart. Some of the differences and similarities have been discussed
recently (e.g. see Scott Hogg‘s article on
“High Availability DHCPv6“).
This post aims at covering a fundamental, yet widely unknown or misunderstood
difference, that is the properties of DHCPv6 addresses and their behavior on the
local-link.
This is the sequel post to the
first part
in which I mainly covered some elements of the specification wrt the “on-link”
flag and the IPv6 subnet model.
In short each IPv6 address has an associated flag which determines if the host
considers the respective address to be part of “a network where neighbors
exist”. If this is the case ND is performed to talk to them, otherwise all
communication with other hosts on that prefix is sent to the router. This flag
is NOT set for DHCPv6 addresses (and, btw, just to make this clear already,
there’s no way of setting it as part of the DHCP configuration procedure either)
so communication with hosts with the same DHCPv6 provided prefix is supposed to
go through a router, which in turn is very different (behavior) from the IPv4
world.
Some of you may already know (the ones who are following Enno on
Twitter) that Enno and I had our lab day
in preparation for the
IPv6 Security Summit
at Troopers. We had a brand new and shiny Cat4948E
as our lab device to do some testing of the current generation of Cisco’s IPv6
First Hop Security (FHS) mechanisms. The Catalyst was running the latest image
available (15.1(2)SG3).
In this small blog post, we will take a look at the configuration and behavior
of IPv6 Snooping and DHCPv6 Guard. So let’s start with IPv6 Snooping: