[Feature request] DHCPv6 protocol
Martin Huněk
martin.hunek at lbcfree.net
Sat Apr 1 13:08:31 CEST 2017
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
-------------- 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