[Kea-users] Why aren't remote-id, circuit-id, and interface-id treated the same for v4 and v6?

Jason Guy jguy at cumulusnetworks.com
Tue Jan 9 14:15:17 UTC 2018


Hi Tim,

If I recall, the gPON and DSL network deployments are *similar* to how
things are done in a cable network, which is mentioned in section 9.9 of
the docs. So that may be a good starting point to understand the design
aspects of the Kea DHCPv6 implementation. I am sure you know that DHCPv6
offers functionality that is not available in DHCPv4. Generally it has a
lot more functionality to design around, and thus the config may be a
little more complicated than DHCPv4.

In the docs section 9.10 it mentions all of the options available to
identify clients. Have you set the "mac-sources" list in the order to try
identifying the client?
It sounds like the relay agent in your setup will know which customer
making the request, and the relay-agent can set the remote-id,
subscriber-id, or some other unique identifier. This is very much
deployment specific. The subnet selection will likely be based on the
interface-id parameter, as Francis mentioned.

Cheers,
Jason

On Tue, Jan 9, 2018 at 5:04 AM, Francis Dupont <fdupont at isc.org> wrote:

> According to RFC 3315 (I didn't check if its update was already published)
> the interface ID (DHCPv6 option 18) identifies a link, not a client on
> a link:
>
> 22.18. Interface-Id Option
>
>    The relay agent MAY send the Interface-id option to identify the
>    interface on which the client message was received.  If a relay agent
>    receives a Relay-reply message with an Interface-id option, the relay
>    agent relays the message to the client through the interface
>    identified by the option.
>
> so it is used in Kea to select a subnet.
>
> Now if you want to use it as an identifier for host reservation the
> obvious solution is the flex-id hook library...
>
> Note the standard way to identify a dual-stack client is to use client ID
> options. For old DHCPv4 clients which don't know it you still have the
> hardware address: the problem is on the DHCPv6 side but there are a lot
> of ways to get the client hardware address including Cisco proprietary
> relay option...
>
> Regards
>
> Francis Dupont <fdupont at isc.org>
> _______________________________________________
> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20180109/63dc675c/attachment.htm>


More information about the Kea-users mailing list