[Feature request] DHCPv6 protocol
Hello, When I was recently in CZ.NIC and I've asked for this feature (DHCPv6 protocol support in bird), I've been told that I should try to make my case on this list. So: (Short list on bottom) I think that adding the DHCPv6 would be logical step for bird development due to DHCPv6-PD (prefix delegation). Today, if you want to do DHCPv6-PD on Linux you have these options: 1) Run DHCPv6 relay on L3 switch / router (on segment) and DHCPv6 server on Linux: Then you can run any of current servers (ISC DHCP, Kea, so on) without problem because routing of the delegated prefix is done on switch/router. It works out of the box and larger ISPs do that. 2) Run DHCPv6 server as stand-alone on Linux: Then you run into problems. None of the current implementation which I've tried (ISC, Kea, DHCPKit) doesn't add routes for delegated prefixes into routing table. This way the delegated prefix is unreachable and end user has got broken connectivity. There are ways how to try circumvent that: a) There is modified version of ISC DHCP which adds information about next hop to hooks. But it is not in mainline. b) You can make hook into standard ISC to guess the link-local address of CPE from DUID. But this might work only for first type of DUID-LLT or third type DUID-LL and only if such DUID is computed from WAN MAC and if it uses EUI-64. c) Snooping of DHCP communication with clients and adjust routing table accordingly. But this depend on another daemon and if it fails, it results in broken connectivity for end user. d) Make static route for every prefix like: 2001:db8:1234:100::/56 via 2001:db8:1234::100 But this makes those prefixes reachable even when not allocated. Making connection to host in such prefix would result in timeout, rather then ICMP message "unreachable". That would not be really DHCPv6-PD because the prefix would be routed to CPE even if it doesn't ask for it. e) Write your own DHCPv6 relay or plug-in to DHCPv6 server (like intended in DHCPKit from RIPE 73) f) Don't use DHCPv6-PD and use static configuration instead. My point is that, there is none of implementation of DHCPv6 server/relay which handles routing of delegated prefix by design. Even there are some ways how to solve that they don't work in all cases (rising amount of devices which uses DUID-UUID or which doesn't use EUI-64 even for link-local addresses). Rather then try to teach DHCPv6 server routing it seems logical to try to teach the routing daemon to dispatch addresses it already have. For a start it doesn't have to be anything fancy, even just relay functionality would have been huge help. Of course the full implementation would have its benefits. Short list of reasons: - No reliable implementation of DHCPv6-PD with routing on Linux - Competitive advantage over Quagga (especially in small networks) - Makes sense to routing daemon to handle routing of a delegated prefix - Less software needed on router just ip6tables and bird for whole IPv6 - Just one software which edits the routing table I do realize that you do have got a lot of work on Bird v2 and that main focus of bird is in BGP, but this feature could really help us as well as other small networks. Best Regards Martin Hunek
Hello!
Then you run into problems. None of the current implementation which I've tried (ISC, Kea, DHCPKit) doesn't add routes for delegated prefixes into routing table. This way the delegated prefix is unreachable and end user has got broken connectivity.
Maybe I am missing something, but is there any reason for not adding this feature to the DHCP daemon? It looks much easier than implementing the whole of DHCP from scratch :-) Have a nice fortnight -- Martin `MJ' Mares <mj@ucw.cz> http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth For every complex problem, there's a solution that is simple, neat and wrong.
On Sat, Apr 01, 2017 at 01:08:31PM +0200, Martin Huněk wrote:
Hello,
When I was recently in CZ.NIC and I've asked for this feature (DHCPv6 protocol support in bird), I've been told that I should try to make my case on this list. So:
...
Short list of reasons: - No reliable implementation of DHCPv6-PD with routing on Linux - Competitive advantage over Quagga (especially in small networks) - Makes sense to routing daemon to handle routing of a delegated prefix - Less software needed on router just ip6tables and bird for whole IPv6
Hello I agree that there is no reliable implementation of DHCPv6-PD, AFAIK. It is a shame considering that it is more than ten years old standard and is crucial for IPv6 deployment. Implementing full DHCPv6 server in BIRD is out of the question. OTOH, just DHCPv6 relay seems like very simple thing to implement. It just relays DHCP messages between downstream and upstream and snoops on prefix delegations to generate appropriate routes. This approach is used by several routers / L3 switch vendors, but i see one possible problem: When a DHCPv6 relay is restarted, it does not have a reliable way to learn which leases were delegated through it in the past and are still valid. There are extensions RFC 5007 (DHCPv6 Leasequery) and RFC 5460 (DHCPv6 Bulk Leasequery), which would solve that problem, but AFAIK both ISC and Kea do not support it. I see two possible approaches for reliable DHCPv6-DP: 1) Implement DHCPv6 relay in BIRD and somehow workaround the restart issue. Even if relay is not necessary (when DHCPv6 servers are running directly on PE routers), it should be possible to run both relay and server on the same machine. 2) Implement some local, out-of-band mechanism to learn leases from DHCPv6 server and use it to generate routes in BIRD. When relays are used (DHCPv6 server is separate from PE routers), then BIRD on DHCPv6 server could propagate routes to BIRDs on PE routers by e.g. BGP. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hello Ondrej, Thank you for considering implementation of DHCPv6 relay, this would make deployment of IPv6 much easier. As for problem of restarting the relay, I would prefer the Leasequery for dealing with that as it is the standard way. There is already support in DHCPKit for that [1], as well as it is able to run only on unicast address (multicast address could be disabled) so it should be no problem to run it on same machine as relay. As for the proposed implementation, I would prefer the first one. Again, it is the standard and it would behave the same way as it does in dedicated routers / L3 switches. Even more, when relay fails it will result in no IPv6. When that out-of-band mechanism fails it would result in broken IPv6 (which is worse because it affects whole dual-stack). Wouldn't be possible to do the same trick as for graceful restart? Eventually to make them persistent and after the restart check the peer-address if it is still reachable? Store in file: Delegated prefix Peer-address Preferred time until (timestamp) Valid time until (timestamp) This way the routes could be kept in over the clean restart. [1] https://dhcpkit.readthedocs.io/en/stable/config/leasequery.html Best Regards Martin Hunek Dne neděle 2. dubna 2017 12:31:24 CEST jste napsal(a):
On Sat, Apr 01, 2017 at 01:08:31PM +0200, Martin Huněk wrote:
Hello,
When I was recently in CZ.NIC and I've asked for this feature (DHCPv6 protocol support in bird), I've been told that I should try to make my case on this list. So: ...
Short list of reasons: - No reliable implementation of DHCPv6-PD with routing on Linux - Competitive advantage over Quagga (especially in small networks) - Makes sense to routing daemon to handle routing of a delegated prefix - Less software needed on router just ip6tables and bird for whole IPv6
Hello
I agree that there is no reliable implementation of DHCPv6-PD, AFAIK. It is a shame considering that it is more than ten years old standard and is crucial for IPv6 deployment.
Implementing full DHCPv6 server in BIRD is out of the question. OTOH, just DHCPv6 relay seems like very simple thing to implement. It just relays DHCP messages between downstream and upstream and snoops on prefix delegations to generate appropriate routes. This approach is used by several routers / L3 switch vendors, but i see one possible problem: When a DHCPv6 relay is restarted, it does not have a reliable way to learn which leases were delegated through it in the past and are still valid. There are extensions RFC 5007 (DHCPv6 Leasequery) and RFC 5460 (DHCPv6 Bulk Leasequery), which would solve that problem, but AFAIK both ISC and Kea do not support it.
I see two possible approaches for reliable DHCPv6-DP:
1) Implement DHCPv6 relay in BIRD and somehow workaround the restart issue. Even if relay is not necessary (when DHCPv6 servers are running directly on PE routers), it should be possible to run both relay and server on the same machine.
2) Implement some local, out-of-band mechanism to learn leases from DHCPv6 server and use it to generate routes in BIRD. When relays are used (DHCPv6 server is separate from PE routers), then BIRD on DHCPv6 server could propagate routes to BIRDs on PE routers by e.g. BGP.
participants (3)
-
Martin Huněk -
Martin Mares -
Ondrej Zajicek