[Kea-users] DHCPv6 pool-selection based on Interface-ID (option 18)

[michael marshall]

Hello users and developers of KEA-dhcp!

I am looking for suggestions on the possibility to change the behavior of the kea-dhcpv6-server in a way that it facilitate the needs as an operator that provides internet to customers in other operators fiber-optic MAN-networks. (The is the standard model for how Fiber Optic ISP-business is done in Sweden). Operators like our self, have not yet deployed IPv6 to customers yet because the technology in the network has not been mature enough and it has been hard to coordinate the implementation with the MAN-network owners, but as of year 2017 and the works of the ISC, we seem to have a stable product that is very soon capable of meeting the requirements we as an operator have to be able to deploy it and also set the limits of what can be achieved with ISC DHCPv6 in Sweden. As I see it, we are closer than ever on achieving a great community goal.

The requirements we need to meet to finalize IPv6 deployment:
One /64 subnet per access-loop in the FTTx-providers network. Behind one access-loop, there may be endless amounts of clients, but normally it would be a residential home or a facility owned by an organization or company connected to a fiber-optic MAN-network.
The only way we can make the DHCP-server provide a /64 based on the access-loop is to match based on the circuit-id, and from what I can tell that would be option 18.

For example if we look at Junipers DHCP-relay option in dual-stack networks they have the option to make their relay-agents include the DHCPv4 option 82 value into the DHCPv6 option 18 value.

This option 18 gives the DHCPv6 server the ability to allow the customer to connect to one giant ipv6 network and have all its endpoints connected to the same network.

And for example, if a IPV6-router is connected to this access-loop network it is able to receive its own prefix through prefix delegation to extend the network even further.


1.      We need to reserve an IPv6 address-pool based on the interface-id and the relay-agent ip-address set in the forward-relay: solicit package.

2.      The available pools and it's prefix size should be specified in the configuration, and based on the available pools, they should be dynamically assigned and it should dynamically assign ipv6 host-addresses accordingly with the servers default behavior.

3.      When there is no requesting/active lease for the pool, the pool is made available to be reserved by another client identified by the interface-id (option 18) value in conjunction with the IP-address of the relay.

The easy way to obtain this is not with the logic from the old age - to define 1 million pools and also define the expected option 18 value for each one, that is not remotely possibly to expect us to do.
It is by the logic used in ISC DHCP, the "spawn with subscriber.id" that was phenomenally good when using the (customer -> relay -> dhcp-server) model with option82 identifying the circuit.id that served us well.
>From what I can tell the same logic should be applied when using KEA dhcpv6 for serving ipv6 networks to one access-loop and dynamically serving the users end nodes ipv6 addresses.

This solution is to facilitate the recommendations of section 4.2.2 in the document TR-177, which is used as a guideline for the biggest FTTx MAN-network provider in Sweden. (https://www.broadband-forum.org/technical/download/TR-177.pdf)

Final statement
I may be wrong and there may be better ways of solving this issue, there may also be known issues that address what is needing to be done, I really hope a senior developer/technician at KEA, can help me address these issues, so that we can solve the problems of ipv4 exhaustion and implement ipv6 in the manners desired for the evolution of the Internet.

Big thanks to everyone involved! I am very much excited to see the response to this big issue.


Best of regards,

Michael Marshall
Fiber Optic Network Engineer
Internetport Sweden AB
+46 (0) 650 - 40 20 00



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20170330/22bae064/attachment.htm>