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