[dhcwg] Other comments on the leasequery spec

[Ralph Droms <[e-mail]>]

Thomas Narten:

Specific comments:

 >         For this query, the requester supplies only a MAC address in the
 >         DHCPLEASEQUERY message.  The DHCP server will return any
 >         information that it has on the IP address most recently accessed
 >         by a client with that MAC address.  In addition, it may supply
 >         addition IP addresses which have been associated with that MAC
 >         address in different subnets.  Information about these bindings
 >         can then be found using the Query by IP Address, described
 >         above.

may or does above? (multiple occurrences) Seems like this should be a
MUST (in order for good interoperability/correctness). I.e., if only
one address is returned (when there are several) it might be  the
wrong address and incorrect behavior may result.

 >    Any DHCP server which supports the DHCPLEASEQUERY message should save
 >    the information from the most recent Relay Agent Information option
 >    (option 82) [RFC 3046] associated with every IP address which it
 >    serves. It is assumed that most clients which generate the

seems like should -> MUST.

 >    A server which implements DHCPLEASEQUERY should also save the
 >    information on the most recent Vendor class identifier, option 60,
 >    associated with each IP address, since this option is also a likely
 >    candidate to be requested by clients sending the DHCPLEASEQUERY
 >    message.

Why? How is this info useful to the relay agent? Also, for
interoperabilty, SHOULD->MUST??

 >          client-last-transaction-time

is this really critical? How is it used? Document doesn't say.

 >       o DHCPLEASEUNASSIGNED
 >
 >         The server MUST respond with a DHCPLEASEUNASSIGNED message if
 >         this server has information about the IP address, but there is
 >         no active lease for the IP address.  The DHCPLEASEUNASSIGNED
 >         message is only returned for a query by IP address, and
 >         indicates that the server manages this IP address but there is
 >         no currently active lease on this IP address.

Are any DHC options returned? I'd assume no, but it would be good to
say that explicitely.

 >    If the "ciaddr" field is zero in a DHCPLEASEQUERY message, then the
 >    IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE message
 >    MUST be that of an IP address for which the client that most recently
 >    used the IP address matches the Client-identifier or MAC address
 >    specified in the DHCPLEASEQUERY message.

wording: not "must recently used" but the one who currently owns the
lease. Right?

 >    In the case where more than one IP address has been accessed by the
 >    client specified by the MAC address or Client-identifier option, then
 >    the DHCP server MUST return the IP address returned to the client in
 >    the most recent transaction with the client unless the DHCP server
 >    has been configured by the server administrator to use some other
 >    preference mechanism.

Shouldn't it return _all_ the addresses? Above reads like only one
address needs to be returned.

 >    If the Client-identifier option (option 61) is specified in the
 >    Parameter Request List option (option 55), then the Client-identifier
 >    (if any) of the client associated with the IP address in the "ciaddr"
 >    field SHOULD be returned in the DHCPLEASEACTIVE message.

Does a server already normally store the client identifier option?
I.e., is this required already?

 >    In the case where more than one IP address has been involved in a
 >    DHCP message exchange with the client specified by the MAC address
 >    and/or Client-identifier option, then the list of all of the IP
 >    addresses SHOULD be returned in the associated-ip option (option
 >    TBD), if that option was requested as part of the Parameter Request
 >    List option.

Seems potentially problematic for a client to ask for just one, and
get only one, if there are many.  It might get back the wrong one and
do the wrong thing.


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg