[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