[Feature request] DHCPv6 protocol

[Martin Huněk]

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.

-------------- 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/20170402/cdb5c12d/attachment.asc>