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.