To SLAAC or not to SLAAC – what will it be? I might vote for SLAAC, slightly modified and used with IPv6 First Hop Security (FHS) with built-in monitoring.

Looking for a perfect solution for local IPv6 addressing which is stable, secure and private enough as well as easy to monitor?


SLAAC is native to IPv6 – built in the IPv6 protocol itself, therefore widely available and reliable. We have to keep in mind to persist with the basics in IPv6 and avoid to introduce any additional protocols (like DHCPv6) and applications. Well, SLAAC has some drawbacks:

  • it lacks in good balance of privacy and stability of host addressing and,
  • being stateless, it makes monitoring address usage tricky.

First one has already been taken care of. In october 2013 a proposal to deprecate EUI-64 based IPv6 addresses in SLAAC has been published as an IETF draft by IPv6 maintenance Working Group: Deprecating EUI-64 Based IPv6 Addresses. The document recommends the use of an alternative scheme for the generation of IPv6 stable addresses which are still composed of a network prefix advertised by a local router, and an interface identifier. The key to mitigate some of the major security and privacy implications, such as network activity correlation, location tracking, address scanning and device-specific vulnerability exploitation, is the proper choice of the interface identifier. Generating a stable and private identifier for SLAAC which will gradually diminish the need for privacy extensions in IPv6 addressing.

How to monitor local IPv6 address usage?

I find IPv6 First Hop Security (FHS) integration in the NetFlow version 9 exporter a good and affordable candidate to provide scalable and efficient way for monitoring IPv6 address usage in the local networks.

Why IPv6 FHS and Netflow?

IPv6 FHS, has finally reached the level of maturity adequate enough for implementation in access networking devices that are commonly used in enterprises, small businesses, research & educational networks and campuses. It is expected that IPv6 FHS will soon become a standard feature set in all contemporary networking gear. IPv6 FHS capable device maintains a binding table with sufficient information about active and valid IPv6 systems in the local networks. IPv6 is the source of all information we need to monitor the IPv6 activity in the local network.

There are several ways to export the information from the IPv6 FHS binding table to the monitoring system, like syslog, periodic polling with the use of SNMP or automated scripts, etc. My idea is to use NetFlow version 9, a technology for exporting statistical data about various types of network flows from a monitoring device (Exporter) to a server (Collector). NetFlow version 9 is expandable with the use of templates. To fulfil this purpose, we would need a few additional field types and define the appropriate flow record. This solution could be easily (well, I’m just guessing) implemented on both, exporters and collectors.

It is not the first time that Netflow is chosen as a monitoring technology for other network characteristics than just traffic flows. Cisco, for example, has implemented a feature called High-Speed Logging for NAT64. A NAT64 translator configured with nat64 logging translations flow-export v9 udp destination ... will periodically send records for each binding of the local address and the global address to which the local address is translated by NAT64. In a similar way, records from the IPv6 FHS binding table could be sent to a netflow v9 collector.

Maybe, DHCPv6 is the right solution and none of these add-ons are actually needed. IPv6 addressing by DHCPv6 is centrally controlled and logged, even more, DHCPv6 addresses can be automatically bound to a DNS, automatically configuring AAAA and PTR records (to be honest, we haven’t touched the DNS issues in the proposed SLAAC-based solution at all). Time will tell 🙂 .