On 10/02/2013 06:11 AM, Nehal J Wani wrote:
> On Wed, Oct 2, 2013 at 3:18 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
>> On Wed, Oct 02, 2013 at 03:08:00PM +0530, Nehal J Wani wrote:
>>> On Wed, Oct 2, 2013 at 1:43 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote:
>>>> On Tue, Oct 01, 2013 at 05:39:02PM -0600, Eric Blake wrote:
>>>>> On 09/26/2013 02:08 AM, Nehal J Wani wrote:
>>>>>> Introduce 3 new APIs, virNetworkGetDHCPLeases, virNetworkGetDHCPLeasesForMAC
>>>>>> and virNetworkDHCPLeaseFree.
>>>>>>
>>>>>> * virNetworkGetDHCPLeases: returns the dhcp leases information for a given
>>>>>> virtual network.
>>>>>>
>>>>>> For DHCPv4, the information includes:
>>>>>> - Expirytime
>>>>>> - MAC Address
>>>>>> - IPv4 address (with type and prefix)
>>>>>> - Hostname (can be NULL)
>>>>>> - Client ID (can be NULL)
>>>>>>
>>>>>> For DHCPv6, the information includes
>>>>>> - Expirytime
>>>>>> - IAID
>>>>>> - IPv6 address (with type and prefix)
>>>>>> - Hostname (can be NULL)
>>>>>> - Client DUID
>>>>>>
>>>>>> * virNetworkGetDHCPLeasesForMAC: returns the dhcp leases information for a
>>>>>> given virtual network and specified MAC Address.
>>>>>>
>>>>>> * virNetworkDHCPLeaseFree: allows the upper layer application to free the
>>>>>> network interface object conveniently.
>>>>>>
>>>>>> There is no support for flags, so user is expected to pass 0 for
>>>>>> both the APIs.
>>>>>
>>>>>> +typedef struct _virNetworkDHCPLeases virNetworkDHCPLeases;
>>>>>> +typedef virNetworkDHCPLeases *virNetworkDHCPLeasesPtr;
>>>>>> +struct _virNetworkDHCPLeases {
>>>>>> + long long expirytime; /* Seconds since epoch */
>>>>>> + union {
>>>>>> + char *mac; /* MAC address */
>>>>>> + unsigned long iaid; /* Identity association identifier (IAID) */
>>>>>> + } id;
>>>>> I'm not sure I like iaid - the whole point of this interface was to
>>>>> return IP addresses associated with a MAC. Either the iaid is important
>>>>> and deserves a separate field, or all we care about is the MAC address.
>>>>> Not to mention that you didn't document which leg of the id union is
>>>>> valid based on the type discriminator.
>>>> Agreed, we want the MAC address to be unconditionally available
>>>> here. IMHO the IAID is not something we care about exposing. That
>>>> is a impl detail of the DHCP comms protocol that is not useful
>>>> to people outside.
>>>>
>>> So in case DHCPv6 is used by the client, should we report the rest of
>>> the lease fields and report MAC as NULL?
>> No, we must report the MAC. This data is useless without the MAC address
>> being present.
>>
>> You can't even implement the virNetworkGetDHCPLeasesForMAC API without
>> knowing the MAC for a lease.
> The issue is, in case of leases containing ipv6 addresses, there is no
> field for MAC address. Laine suggested extracting MAC address from the
> cliend DUID. For example:
>
> 1380692760 52:54:00:e7:85:1e 192.168.122.116 * *
> duid 00:01:00:01:19:dd:fb:37:f0:4d:a2:8c:14:51
> 1380692762 15172894 2001:db8:ca2:2:1::de *
> 00:01:00:01:19:dd:fb:af:52:54:00:e7:85:1e
>
> The last 17 chars of the client DUID represent the MAC address
> [00:01:00:01:19:dd:fb:af:((52:54:00:e7:85:1e))]. But RFC3315 strictly
> suggests:
> """
> Clients and servers MUST treat DUIDs as opaque values and MUST only
> compare DUIDs for equality. Clients and servers MUST NOT in any
> other way interpret DUIDs. Clients and servers MUST NOT restrict
> DUIDs to the types defined in this document, as additional DUID types
> may be defined in the future.
You aren't a client or a server (i.e. you aren't participating in the
protocol). You are a third party who is already invading the internal
state data store of one particular implementation of DHCP server -
dnsmasq (and only dnsmasq) - to try and mine some useful information. It
is a happy coincidence that the MAC address is contained in the DUID in
dnsmasq, but it *is* there, and doesn't appear to be available anywhere
else (without snooping packets on the bridge for a matching IP address).
So your choices are use that, snoop the packets, or go home. (You should
not, however, attempt to write a general purpose function intended to
derive the MAC address from the DUID of a lease for *any* DHCP
implementation - *that* is what the RFC says you must not do)
BTW, I agree with Dan that all we care about are IP address and MAC
address - IAID and DUID are just artifacts of the method used to assign
an IP address, and won't mean anything to anybody except the DHCP server
and client software.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list