-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Brian E Carpenter
Sent: 21. mai 2013 22:06
To: Phil Mayers
Cc: [email protected]
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
