When I talk to experienced network administrators, I often hear that they are hesitant to deploy IPv6 in their company networks. They cite different reasons: Some see no benefit in IPv6, since they use private IPv4 addresses internally and regard NAT as an additional line of defence. Some distrust the IPv6 autoconfiguration and wish for more control over the network access layer.
IETF network engineers, equipment manufacturers, and academic researchers treat IPv6 as a solved problem. But for all it shares with IPv4, IPv6 is a protocol that handles some things differently.
This is especially evident in the Neighbor Discovery Protocol and the way hosts manage their addresses through Stateless Address Autoconfiguration (SLAAC). This behaviour has consequences that reach below the network layer and may require changes in switching hardware and/or network management and monitoring solutions in order to run a safe network (RFC 6105).
Taking control of your IPv6 LAN
Having previously looked at the use of intrusion detection systems for the mitigation of IPv6 attacks, my team and I developed an idea to use a Software Defined Networking (SDN) switch to control local IPv6 configuration messages. SDN changed the way we could prototype network functions and roll our own custom network behaviour.
For this project we only touched the access switch of the network, so we used an SDN controller local to the switch. The controller acted as the sink and the source of all IPv6-Neighbor Discovery (ND) traffic on the switched Ethernet segment. It also generated the IPv6 Router-Advertisements, so we did not have to worry about somebody spoofing them.
The ND messages populate a cache of all active IPv6 devices on the Ethernet segment as well as their corresponding MAC, IPv6 addresses and connection points. In Figure 1, if Host A wants to send packets to Host B, the controller checks:
- If A is in the cache, sets B’s entry to pending and forwards the Neighbor Solicitation (NS) message.
- Host B’s Neighbor Advertisement (NA) is also checked against the cache. If B is valid, a flow rule allowing communication from B to A is inserted. The cache entry is set to active and the NA is forwarded to Host A.
We implemented this IPv6 ND proxy function as an app on the RYU controller framework and made it publicly available. A northbound API provides greater insight into the current network configuration via a REST interface. We also added some preliminary flooding protection.
The app still has a number of known limitations. Hosts must perform duplicate address detection (DAD) to be authenticated and it currently only works on a single switch network. Even so, it provides a very interesting vantage point into the deployment of IPv6 on Ethernet LANs.
We encourage any network administrator who is still contemplating IPv6 deployment to try it and learn about IPv6 and SDN at the same time. SDN is not only for data centres and IPv6 not only for home networks.
For more information about the app read our paper ‘Securing IPv6 Neighbor Discovery and SLAAC in Access Networks through SDN’, comment below or email.
Thomas Scheffler is a Professor and Convenor of the IPv6 Lab at HTW Berlin.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.