IPv6 security in enterprise network
These days IPv6 is getting world-wide ISP adoption as well as implementation on content servers and server software but client side in enterprise networks is still problematic especially due to difficult IPv6 address assignment -> security issues.
In this post i will sum up current IPv4 security  and possible IPv6 security implementations in Silicon Hill network. This network has 4000+ devices connected to tens of VLANs - all directly routed in C6500 box. It is very straightforward network topology and most security policies are applied in access layer.
In Silicon Hill network ...
You want to be able to identify users based on their IP address (abuse resolution)
You want to prevent IP address spoofing
You want seamless user experience (Default client configuration should work)
So there is proprietary management software which manages database of users, devices, their MAC and IP addresses and configures switches accordingly.
Current IPv4 security for wired devices
L2 security - Each user has allowed MAC addresses on his switchport (port security)
L3 security - Each user has allowed IP addresses configured in inbound ACL applied to his switchport
DHCP assigned addresses based on MAC address
Current IPv4 security for wireless devices
L2 - Each user has allowed MAC addresses, which are checked during RADIUS ACCESS-REQUEST (Calling-Station-Id)
L3 - Only DHCP assigned addresses are allowed
It would be easy to implement IPv6 if same security approaches could be used, however this is not the case.
Client behavior in respect to global IP address selection is controlled using configurable Router Advertisements (RA) - SLAAC or DHCPv6.
SLAAC - Client uses network prefix (/64) provided in RA and chooses 64 LSBs of address in two ways.
EUI-64 - Device generates his host part of address from his MAC address using standardized algorithm.
Temporary address - Device generate his host part of address in random way (RFC 4941).
Temporary addresses are game changer, they prevents user tracking, however they made implementation of IPv6 security very problematic - Â once network administrator decides to use SLAAC, he looses control over which addresses are being used by users.
If there would be single bit in ICMPv6 RA to control wherever device is allowed to generate Temporary address  there would be no problem!
Thus if inbound ACL is applied to users switchport, which allows him to use only specified address (eg. EUI-64), once client device generates Temporary address it ends up with misconfigured dual-stack and would most probably end up in broken user experience.
Device would think it has valid IPv6 configuration, however ACL would drop its packets - this would result in timeouts of various protocols.
DHCPv6Â - Equivalent to DHCPv4, however several differences are there, most notably:
You cannot use MAC address to identify devices. Instead DUID is in DHCPv6 packet.
You cannot set default route.
For DHCPv6 packet delivery Link-Local and multicast addresses are used.
Which addresses are used to deliver DHCPv6 packets is not real problem and can be solved easily (Adding these addresses to switchports ACL).
Even using RA for default route preference makes sense.
DUID instead of MAC address for identification is again enhancing user privacy, however it is making implantation of IPv6 security problematic. Most because its generation is leaved to operating system and thus can result in problems as changing DUID after reinstallation of OS, or same DUID for cloned VMs.Â
This would leave us to constantly updating our database of users devices with their DUIDs.
We could use DHCPv6 server which would listen on L2 to DHCPv6 packets and read  MAC addresses directly from L2 frame header.Â
Current implementation of ISC-DHCPÂ is not supporting any of this. What is interesting is RFC 6939Â which adds Client Link-Layer address (MAC)Â as DHCPv6 option. This if implemented in DHCPv6 Relay on our C6500 would enable using ISC-DHCP for v6 the same way as for v4.
In the mean time we can use another DHCPv6 server - dhcpy6d (Developed at IFW Dresden). With simple modifications dhcpy6d can read MAC addresses from L2 frame header and provide address allocation according to static records in PostgreSQL database.
Enforcing security in IPv6 is not plug-n-play and for those which find logging of ND table (IPv6, MAC pairs) insufficient there is really no deployment ready simple solution.
