[Feature request] DHCPv6 protocol

Martin Huněk martin.hunek at lbcfree.net
Sat Apr 1 13:08:31 CEST 2017


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 
 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20170401/a30a0151/attachment.asc>

More information about the Bird-users mailing list