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

[Tim Howe]

After sleeping on it, I think I have come to the (rather contrived)
conclusion that where it would be normal practice to assign a single IP
from a shared connecting range with IPv4, it is often expected that each
subscriber actually be assigned a unique connecting range.  Thereby
making these things equivalent by expected convention(?)

	It feels a bit messy putting all those subnets on the L3
interface, but at least I probably don't need to have them all resident
on the DHCP server's interface since the link local addresses should
handle that (I think).

--TimH

On Tue, 9 Jan 2018 09:15:17 -0500
Jason Guy <jguy at cumulusnetworks.com> wrote:

> 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
> >