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. Continue reading “DHCPv6 Option 52 on Cisco DHCPv6 Server”
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.
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.
At the end of the first part we had a configuration state which led to two global addresses on both systems involved, a DHCPv6 provided one and another one generated as part of the SLAAC process, which can create operational issues of all kinds (improper source address selection, hindered troubleshooting etc.). Furthermore such a setting does not reflect “the operational DHCPv4 model” which we envisaged as the ultimate goal of our exercise. I had finished that post along the lines: “we then have to get rid of the SLAAC address”.
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.
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: