Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DHCPv6 proxy prefix delegation/address assignments #546

Open
jkroonza opened this issue Jan 23, 2025 · 1 comment
Open

DHCPv6 proxy prefix delegation/address assignments #546

jkroonza opened this issue Jan 23, 2025 · 1 comment

Comments

@jkroonza
Copy link
Contributor

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
Copy link
Member

@jkroonza: Thanks for this ticket!

@paulusmack: What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants