[Dnsmasq-discuss] DHCPv6 lease hwaddr

Vladislav Grishenko themiron at mail.ru
Sun Aug 4 14:32:16 BST 2013


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





More information about the Dnsmasq-discuss mailing list