DHCPv6 accounting

[Tjeldnes, Terje]

-----Original Message-----
From: ipv6-ops-bounces+terje.tjeldnes=get.no at lists.cluenet.de [mailto:ipv6-ops-bounces+terje.tjeldnes=get.no at lists.cluenet.de] On Behalf Of Brian E Carpenter
Sent: 21. mai 2013 22:06
To: Phil Mayers
Cc: ipv6-ops at lists.cluenet.de
Subject: Re: DHCPv6 accounting

On 22/05/2013 04:20, Phil Mayers wrote:
> On 21/05/13 16:58, Tim Chown wrote:
> 
>> I would suspect in a largeish enterprise that that approach would be 
>> appropriate, as it's likely that all DHCPv6 traffic would be 
>> forwarded by a relay.
> 
> Except unicast traffic of course, unless the relays are expected to 
> interfere with such as well. This means the DHCP server will need to 
> stash the relay options (a common problem with DHCP option 82).
> 
> It's also worth asking whether DHCPv6 server operators would like to 
> know the source layer2 info as the relay saw it, as the client claims 
> it, or both.

In any case, the ground truth in IPv6 can surely only be found in the ND cache? It is not a safe assumption that all addresses were assigned by DHCPv6.

    Brian


In many cases, source-verify will be enabled on relay-agents (i.e. for CMTS or BRAS/BNG-equipment) to enforce DHCP. In residential customer context however, it's arguably irrelevant which link-layer address is assigned a specific v6 address since you can already identify the customer based on option 37 (roughly equivalent to DHCPv4 option 82). In many cases, unicast DHCP is also intercepted to verify customer state. Link-local is a different matter, but again, it might not matter depending on your configuration (i.e. blocking any other link-local traffic to the customer than ND/RA/DHCPv6 etc).

For enterprises I can see where it would be useful to know the link-layer address in every assignment, in which case ND-cache is currently your best bet until something like http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt/ is implemented.

Terje