This page documents the effort to develop an RA server during IETF hackathon.
SLAAC stands for stateless address autoconfiguration.
The ultimate goal of this effort is for Kea to be able to provide configurations in slaac (dhcp-less) IPv6 networks. It does not seek to replace DHCPv6, simply provide another delivery channel that could convey configuration parameters to hosts.
We want to implement a Kea server that would wait for incoming RS (Router Solicitations) and would send back RAs (Router Advertisements). Once that is done, we will extend it to include universal RA option specified here.
The code is able to read a JSON based config file. It specifies typical RA parameters (M,O bits, reachable and valid lifetimes etc.). A value for universal RA can be specified. The value can be an arbitrary JSON. The example provided defines 3 paramters: DNS domain, DNS servers addresses and NAT64 prefix.
The code is able to receive RS and respond with RA that includes the parameters. We expect to improve the logic over time.
During the hackathon we used Scapy to generate RS.
Look at Cisco's VPP. The general idea is to provide the universal RA capabilities and values of other options.
Extend our scapy client to print out received universal option (maybe call an external script)? Would be useful for testing purposes.
Test with actual hosts (may be tricky to find RA clients that are able to understand universal RA option).
Extend wireshark to be able to inspect the option (if nobody implemented support for it yet).
Evaluate if the whole thing makes any sense. If it does, make sure it is easier to install and could be installed without all the DHCP stuff.
Extend the code to use client classes to provide different values for different device types (VOIP phones get only RA with VOIP parameters, cable modems get only DOCSIS options etc).
Slow path: Look at whether host reservations from Kea could be used to provide per host specific parameters. This would require per packet lookup, so would be much smaller, but would give fine grained control over who gets what. The advantage of this approach is that it wouldn't require any protocol changes.
develop your code on a branch
if there is someone to review it - great. If not, merge it to hackathon-slaac branch.
This is a hackathon. We don't care about nonsense such as unit-tests, comments or portability ;). If it compiles on your system, it's good enough.
A word of warning. Just make sure you're merging this to hackathon-slaac, NOT to master.