DHCPv6 proxy prefix delegation/address assignments

[jkroonza]

Hi,

I've looked a bit into how to best handle IPv6 requests here.

KEA (ISC replacement) DHCPv6 server is perfectly capable of issuing prefix delegations, and maintaining persistence and all of than, but it really, really sucks at dynamic interfaces. It's probably OK if you only have a handful of connections, but we had extreme problems just to get it configured in this way.

I then started on a DHCPv6 proxy (yes, there were existing ones, none of which has active maintenance), but then realised that getting PD delegations and all that into radius, whilst it can be done externally, it would overall be simpler if we can build the DHCPv6 proxy (which also knows how to handle radius IPv6 static assignments and delegations) straight into pppd.

I've started playing in https://github.com/jkroonza/dhcpv6-relay towards a standalone relay, but the complexities involved with not being part of the pppd daemon is tremendous once radius interactions becomes involved.

Using strace the pppd daemon sits mainly in this system call.

pselect6(13, [8 10 12], NULL, [8 10 12], {tv_sec=29, tv_nsec=999946000}, NULL

In this case fd 8 is a pipe whilst 10 and 12 are /dev/ppp. The write-end of the pipe is at fd=9 and I suspect this is to enable signals to interrupt the select.

This will likely result in work on top of #544 where the function to add/remove the default route will start accepting a specific prefix. This can happen before #544 but has the obvious rebasing caveats.

It looks like it's fairly trivial to add a file descriptor using add_fd to this set of descriptors, but I see no obvious way to associate an event handler with this file descriptor.

Would the following set of PRs (or commits in a single PR) be acceptable?

1. Adjust add_fd to take two additional arguments: a function pointer "void (callback)(int fd, void pvt)", and a "void* pvt"? Alterantively a new function in pppd/main.c add_fd_event_handler that has these semantics, and builds on top of add_fd but instead in handle_events calls the callback functions if these file descriptors has input available? (the latter is probably a cleaner approach, and won't break backwards compatibility with external modules)
2. Adjust the route add/remove code with support for a prefix.
3. In radius module add support Framed-Route (when it's encountered add a route to the interface, should remove too when link goes down).
4. In radius module add support for Framed-IPv6-Route (similar).
5. Make note of any of the following for DHCPv6 proxy module:
   1. Delegated-IPv6-Prefix
   2. DNS-Server-IPv6-Address
   3. tag for IPv6 local assignment that will result in RAs being transmitted.
6. DHCPv6 module (if above tags are present use to serve request, else, proxy to upstream DHCPv6 server which may well be on the same host - there are some interesting caveats with that as I've found out during dhcpv6-proxy work).

[Neustradamus]

@jkroonza: Thanks for this ticket!

@paulusmack: What do you think?

[paulusmack]

I have very little experience with IPv6, sorry. What you suggest sounds OK. I don't know really why having a DHCPv6 proxy outside of pppd will end up more complicated than having it inside pppd, but I take it that you know what you're talking about here. Possibly seeing the actual code would help with that.

[jkroonza]

No problem. Client side perspective is easy enough.

The problem stems from the fact that we need to bind to each ppp interface separately, both for the multicast address as well as the response address. This can be done externally by monitoring new interfaces being added/removed, or possibly by signalling from ipv6-up/down. It just gets a lot more complicated and it's easier if we can avoid that complexity.

Much of this is still exploratory regardless, I might well when I get started change my mind again, so this is asking for opinions to influence my own as much as technical guidance.

The advantage of in-pppd is that we "cannot go out of sync", and a simple "dhcpv6proxy ..." option means we bind the ports on the ppp interface itself, and just proxy to the relevant address after possibly adding option 82 based on remotenumber for example, or if radius provided PD attributes, simply responding with the relevant PD.

For things like "active ethernet" tools like KEA (ISC) is perfectly workable already, but it really struggles with dynamic interfaces, and I cannot get it to not crash. Also very non-responsive upstream in my experience, which is why I was considering following the proxy route to begin with.