[Dnsmasq-discuss] DHCPv6 lease hwaddr

[Vladislav Grishenko]

Little addition, previous mail says nothing about iaid, it needs be moved to
separate lease filed too, and, for example before/after/with flags in
leasefile.

Best Regards, Vladislav Grishenko


> -----Original Message-----
> From: Vladislav Grishenko [mailto:themiron at mail.ru]
> Sent: Sunday, August 04, 2013 7:32 PM
> To: 'dnsmasq-discuss at lists.thekelleys.org.uk'
> Cc: Simon Kelley (simon at thekelleys.org.uk)
> Subject: DHCPv6 lease hwaddr
> 
> 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