[Feature request] DHCPv6 protocol

[Ondrej Zajicek]

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 at 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."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20170402/32fbba04/attachment.asc>