DHCPv6 accounting

[Brian E Carpenter]

On 22/05/2013 20:39, Tjeldnes, Terje wrote:
> 
> -----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 

That depends who "you" is. It is entirely reasonable that a parent would want
to know (and be entitled to know) which child has been downloading which
movie, etc. Nothing said has persuaded me that any source other than ND
is sufficient for all cases.

    Brian

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