[Dnsmasq-discuss] DHCPv6 lease hwaddr

Simon Kelley simon at thekelleys.org.uk
Mon Aug 5 16:11:32 BST 2013


On 04/08/13 14:32, Vladislav Grishenko wrote:
> Hi Simon,
>
> dnsmasq 2.67test9 dhcpv6 leases implementation uses only clid approach,
> which is the same and should not be treated as containing client's hwaddr.
> It makes impossible in real life to specify specific dhcpv6 options for
> clients, if only mac address is known (ISP billing, specific&  static
> allocations, etc).
>
> But, in fact, if DHCPv6 client directly attached, link layer address is
> available just from the packet, but if they are served via relay,  relay
> agent may use OPTION_CLIENT_LINKLAYER_ADDR as defined in RFC6939. Refer
> http://tools.ietf.org/html/rfc6939:
>
> 5.  DHCPv6 Relay Agent Behavior
>     DHCPv6 relay agents that receive messages originating from clients
>     (for example, Solicit and Request, but not, for example,
>     Relay-Forward or Advertise) MAY include the link-layer source address
>     of the received DHCPv6 message in the Client Link-Layer Address
>     option, in relayed DHCPv6 Relay-Forward messages.  The DHCPv6 relay
>     agent behavior can depend on configuration that decides whether the
>     Client Link-Layer Address option needs to be included.
> 6.  DHCPv6 Server Behavior
>     If the DHCPv6 server is configured to store or use a client link-
>     layer address, it SHOULD look for the Client Link-Layer Address
>     option in the Relay-Forward DHCP message of the DHCPv6 relay agent
>     closest to the client.  The mechanism described in this document is
>     not necessary in the case where the DHCPv6 server is connected to the
>     same network link as the client, because the server can obtain the
>     link-layer address from the link-layer header of the DHCPv6 message.
>     If the DHCP server receives a Client Link-Layer Address option
>     anywhere in any encapsulated message that is not a Relay-Forward DHCP
>     message, the server MUST silently ignore that option
>
> So, we can keep using hwaddr for DHCPv6 clients, if it's available, and make
> leasefile&  mac-based options work.
> Also, it will allow struct lease, code and leasefile format cleanup:
>
> Lease struct contains struct in_addr addr and hwaddr member is reused as
> struct in_addr in6_addr, so we have no hwaddr for v6 clients
> Lease file is looks like, where for DHCPv6 records hwaddr is replaced by
> hwtype + 32 bit of hwaddr
>        86400 00:21:6a:xx:xx:xx 192.168.1.191 host 01:00:21:6a:xx:xx:xx
>        86400 553656682 201:db8::109 host
> 00:01:00:01:14:0d:23:69:90:e6:ba:xx:xx:xx
> If lease struct will contain separate struct in6_addr for ipv6 address or
> even struct all_addr, hwaddr could be kept and used as is.
> As for lease file format, it could look like below:
>        86400 [hwtype-]00:21:6a:xx:xx:xx 192.168.1.191 host
> 01:00:21:6a:xx:xx:xx [%04x: flags like TA/NA/other]
>        86400 [hwtype-]00:21:6a:xx:xx:xx 201:db8::109 host
> 00:01:00:01:14:0d:23:69:90:e6:ba:xx:xx:xx [%04x: flags like TA/NA/etc]
> Legacy format with %u (even not %lu for keeping the whole hwaddr...) can be
> easily supported, but doesn't worth to, since no soft writes it directly for
> ipv6 leases.
>
> Best Regards, Vladislav Grishenko
>
>
>


Indeed, I've been following that standard through the IETF and waiting 
for it to make RFC. Don't something which allows MAC-address 
configuration to work is firmly on my list.



Cheers,

Simon.




More information about the Dnsmasq-discuss mailing list