Subject: [dhcwg] lease query question

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Feb 2003 11:28:40 -0500

I've started my AD review on draft-ietf-dhc-leasequery-04.txt, and
have a basic question. From the problem statement, I understood the
problem to be fairly narrowly scoped, that is, an ability to rebuild
the state that an access concentrator builds from gleaned DHC
messages, but loses if it (say) restarts.  The abstract/problem
statement says:

   Access concentrators that act as DHCP relay agents need to determine
   the endpoint locations of IP addresses across public broadband access
   networks such as cable, DSL, and wireless networks.  Because ARP
   broadcasts are undesirable in public networks, many access
   concentrator implementations "glean" location information from DHCP
   messages forwarded by its relay agent function.  Unfortunately, the
   typical access concentrator loses its gleaned information when the
   access concentrator is rebooted or is replaced.  This memo proposes
   that when gleaned DHCP information is not available, the access
   concentrator/relay agent obtains the location information directly
   from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY
   message.

That is, I assumed that what is needed is a mechanism that allows a
concentrator to avoid the need to invoke ARP, by querying the DHC
server instead.  To achieve this, I would have assumed that a simple
query-response protocol that would solve the problem as stated. That
is, I would have assumed perhaps two queries:

 - tell me the IP addresses of all devices behind a particular
   link-layer "MAC", or [note: one might use this to rebuild state
   about a particular link]
   
 - Tell me which of my links (if any) the following IP address resides
   on. [note: one might use this if one received an packet to forward,
   and needed to do the equivalent of "ARP" for it]

I would expect that the leasequery might say "give me the info", and
the server would respond with the same info it would give the
client. I.e, the information received is the same as that it would
glean from the normal DHC trafic (and in particular, without any new
information specific to the leasequery protocol).

But the protocol is quite a bit more complex than that. For example, a
server can respond with a "sort of" answer, one that indicates I don't
have a lease, but I did in the past. Likewise, there is also an R bit
for providing further information about the details of a particular
lease.

I don't fully understand the motivation or need for the additional
stuff. There seem to be some unstated assumptions about the nature of
the problem being solved. Could someone please clarify what the actual
problem is that needs solving here?

Thomas
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 10 Feb 2003 18:31:56 -0500

>   from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY

        We have evolved the leasequery capability and draft quite
        a bit without, perhaps, similarly evolving the
        abstract/problem statement.  This is due, no doubt, to
        the fact that it has taken quite a while to get this
        draft completed.

        Having said that (which is true), I don't see significant
        deviation from at least my conceptualization of the
        current problem the leasequery protocol/draft solves.

        There are implementations of this capability in the field
        today, and the actual draft is informed by not only our
        intellectual exercises in protocol design but by actual
        implementations and actual users of those implementations
        with real requirements.  If you think there is dramatic
        mis-match between the problem statement with the actual
        protocol, we can certainly revise the problem statement
        to whatever degree you deem necessary.

>information specific to the leasequery protocol).

        Largely, this is what it does.

>for providing further information about the details of a particular

        To a first approximation, the server is trying to supply
        information that is similar to that it would supply to
        the DHCP client.  However, the client of a leasequery is
        not precisely identical to the DHCP client that is
        requesting a lease.

        So, for instance, if a "real" DHCP client was talking to
        the DHCP server, it would give the client a lease (as
        opposed to telling the client that it had a lease at some
        point in the past).  However, the client for a leasequery
        request isn't looking for a lease -- it is looking for
        information *about* a lease.  Allowing a server to return
        information that indicates that a lease existed for a
        client at sometime in the past may well be useful to a
        device which is trying to rebuild its state, since this
        is information that it normally would have available if
        it had not lost its state.

        The R bit is designed to allow a device which uses DHCP
        gleaning to also operate correctly in the event that some
        IP addresses are "hard coded" or "hand configured".  In
        this case, if the DHCP server is supplied with a
        reservation for the hand configured IP<->MAC
        relationship, then if the DHCP client asks for an IP
        address, it will get the proper one.  More importantly,
        the leasequery client doesn't have to be configured with
        the hand-configured IP address, since it can determine
        which IP addresses are "allowable" from the results of a
        leasequery.  This is indeed a capability that the
        leasequery protocol allows that isn't possible in a
        straightforward way without it.

        You could argue that it is a convenience, I suppose, and
        that it is beyond the mission statement of the original
        protocol.  It is one of the capabilities that has been
        requested by actual users of devices that utilize the
        leasequery protocol, since those devices are much less
        useful if you have to hand configure them with this
        information.  Some major customers have argued that this
        sort of capability fits squarely into the leasequery
        approach, and we agree with them.

        But you are right -- this is a capability that is
        somewhat beyond what was possible without the leasequery
        protocol.

>problem is that needs solving here?

        I guess that I don't understand exactly which stuff you
        consider extraneous, other than the two points which I
        already addressed above.  One of those capabilities I
        don't consider extraneous, and the other I see only as a
        logical extension to the basic capability, so I can't
        reason from those to the other things that you find
        "additional".

        Were I to state the problem that leasequery is trying to
        solve without reference to the original problem statement
        (as something of an exercise), I would say:

        Router-type devices which want to enforce some level of
        access control over which IP addresses are allowed on
        their links need to maintain information concerning
        IP<->MAC/client-id mappings using DHCP gleaning, and
        these devices don't typically have stable storage
        sufficient to keep this information over reloads.  The
        leasequery request allows them to efficiently rebuild
        this information as necessary.  Moreover, for these
        devices to be as useful in as many environments as
        possible, some information not available from DHCP
        gleaning can also be determined by using the leasequery
        capability.

        But that explanation is only a slight extension from what
        we already have in the draft (and that you quoted above).

        I'll be glad to pursue this if you wish.  I can either
        add some variant of the last sentence above to the
        mission statement in the draft.

        Alternatively we can discuss other items that you
        consider beyond the scope of the leasequery protocol.  In
        order to do that effectively, I'm going to have to have
        additional information as to which other capabilities you
        consider "additional".

        I don't expect any difficulty explaining why they 'fit'
        into the mission statement of the protocol, or to
        expanding the mission statement to cover them, for what
        that is worth.  I don't think that it is any more complex
        than it needs to be to solve the task at hand, though
        I'll admit the task is becoming something of a second
        generation task as opposed to a first generation task.

        Cheers -- Kim

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Feb 2003 12:51:22 -0500

Hi Kim.

>         current problem the leasequery protocol/draft solves.

I guess I do. I could imagine solving the simple problem by having
just a pair of messages (request and reply), with the reply saying
"yes there is a lease" or "no there is not" and not having the R bit
at all. Thus, I'd like to understand whether and why the more complex
solution is really necessary. Ideally, this would follow from the
problem statement.

>         to whatever degree you deem necessary.

Well, one can always revise a problem statement to make sure that a
proposed solution follows from it. But that isn't generally the way to
get good protocols. What I would rather understand is the actual
problem, independent of the solution. If it happens that the solution
is a reasonable one given the problem statement, that would be
great. But if there are simpler solutions, they should be considered
too.

So far, you've provided a very high-level, general problem
description. From it, I don't see the need for some of the proposed
protocol features.  I really do want to understand if the proposed
solution is the best one for the actual problem.

>         it had not lost its state.

The above is not obvious to me. Why should the relay agent care if an
address used to be in use on a particular link in the past? I would
think that the relay agent shouldn't be creating ARP state based on
that because:

 - in fact that address might be in use by a different node elsewhere
   on a different link now (and the server responding might not know
   that because its not coordinating properly with the other server).

 - if the lease is no longer valid, presumably the device using that
   address shouldn't be using that address anymore (after all, it
   didn't renew the lease). So why should the relay agent forward
   packets for that address to the site where a device used to be in
   the past?

>         address, it will get the proper one.

Makes complete sense for normal DHC usage.

>	  More importantly,

The above I don't follow, for the reason I mentioned above. Seems to
me, the relay agent shouldn't be populating it's ARP cache *unless*
there is a valid lease. Thus, knowing that an address is reserved, but
not currently in use, doesn't seem to be info the relay agent really
needs. Am I missing some other important detail here?

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 19 Feb 2003 12:51:17 -0500

Kim,

Based on the discussion and current draft of the spec, it looks to me like 
the protocol has evolved beyond simply reporting lease information into a 
mechanism for populating an access concentrator with device identity and 
location information.  It's more than a mere formality to ensure that the 
problem statement and design motivation match the protocol itself - those 
readers who have not been part of the evolution need to be able match up 
the problem statement and the protocol spec to effectively evaluate the 
correctness and applicability of the protocol.

For example, I think the following problem statement more accurately 
reflects the current protocol and the problem that is causing its evolution:

         Router-type devices which want to enforce some level of access
         control over which IP addresses are allowed on their links
         need to maintain information concerning IP<->MAC/client-id
         mappings.  One way in which these devices can obtain
         information about IP<->MAC/client-id bindings is through "DHCP
         gleaning", in which the device extracts useful information
         from DHCP messages exchanged between hosts and DHCP servers.

         However, these devices don't typically have stable storage
         sufficient to keep this information over reloads.  There may
         be additional information that is useful to the device that
         cannot be obtained through DHCP gleaning.  The leasequery
         request message described in this document allows a device to
         obtain information about IP<->MAC/client-id bindings from a
         DHCP server.  This information may include currently active
         bindings, bindings involving previously assigned addresses for
         which the lease on the address has expired and static bindings
         for devices that are otherwise configured and not using DHCP
         for address assignment.

- Ralph

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 25 Feb 2003 15:29:09 -0500

Ralph,

Thanks!  That's a great problem statement.

Thomas,

Would replacing the current problem statement with this one
suggested by Ralph be sufficient to meet (enough of) your
concerns to allow the draft to proceed?

Is there something instead of or in addition to that change that
you would suggest we do in order to move forward here?

Thanks -- Kim

At 12:51 PM 2/19/2003, Ralph Droms wrote:
>Kim,
>
>Based on the discussion and current draft of the spec, it looks to me like the protocol has evolved beyond simply reporting lease information into a mechanism for populating an access concentrator with device identity and location information.  It's more than a mere formality to ensure that the problem statement and design motivation match the protocol itself - those readers who have not been part of the evolution need to be able match up the problem statement and the protocol spec to effectively evaluate the correctness and applicability of the protocol.
>
>For example, I think the following problem statement more accurately reflects the current protocol and the problem that is causing its evolution:
>

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Feb 2003 10:34:46 -0500

> concerns to allow the draft to proceed?

Not really.

What we had originally (I had thought) was is a relatively simple
problem, with a relatively simple solution, and one that didn't really
change DHC in any serious way. The solution seem to have taken on
feature creap, where the problem got expanded, and the solution got
expanded. Sure, given any solution, one can go back and rewrite the
problem statement to make it match the solution. While that is
certainly necessary to make the document accurate, I have to wonder
whether the problem statement actually makes sense or is well defined.

> >        from DHCP messages exchanged between hosts and DHCP

So far, simple.

> >        for devices that are otherwise configured and not using DHCP

Note, that above is pretty vague and doesn't say what information the
access device needs. It's hard to look at the problem statement and
say "yes, I understand the boundaries of the problem" and then "and
the solution seems like a good match for the problem".

Popping up a level, how is it even appropriate for the DHC WG to be
doing work on "access control in router type devices"? One can argue
that work of this broad a scope is well out-of-scope for this WG
(e.g., look at the recently approved charter). I'm far from clear that
work of this scope should be done in DHC or that the problem is well
enough understood to conclude that DHC lease query is the right
solution or that any DHC-based solution is the right one.  What about
routers wanting to do access control that don't use DHC, for instance?

And note, I'm not raising these issue just to be a PITA. These are
questions that I expect that the IESG would ask if I brought the
document forward. Thus, I need to have reasonable responses to those
questions. Otherwise, I can predict the likely outcome.

Thomas

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 26 Feb 2003 12:07:14 -0500

Thomas,

This approach to access control was developed by joint work with
the folks building our access concentrators and several of us in
the DHCP implementation group.  They found that the functionality
delivered to actual users was of sufficient value to those users
to be worth the cost of engineering this particular solution.
We supported them in moving the implementation forward.

The solution was not based on the charter of the DHC working
group either then or now -- it was based on a rather pragmatic
approach to meeting the needs of users, which it has seemed to
do.  In my view at least, it fits within spirit of the DHC WG
activities, and was a logical extension of the those activities.

It isn't a comprehensive approach to any sort of security (nor
was it designed to be such) -- it is a supporting piece of
technology to one limited form of access control.

We decided to bring this work to IETF to see if anyone felt it
was worthwhile to standardize it, and at the time the sense of
the working group was that standardization was appropriate.  We
did this knowing full well that we would have to re-implement our
support after the standardization process was complete, but felt
that something this valuable should be standardized and available
to all.

I think it is time to ask that question again of the DHC WG -- is
there any value to standardizing the leasequery capability?

I will do so in a separate email, and we'll see just where this
work stands with the other members of the working group.

Kim

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 26 Feb 2003 12:36:55 -0500

Folks,

We have come to something of a impasse on the leasequery draft,
and I need *your* support if you believe we should continue to
pursue this draft.

===============================================================
Without considerable support from the DHC WG, we will halt work
on the leasequery draft and all attempts to bring this work to
standard status.
===============================================================

If you believe that there is any value in standardizing the
leasequery capability, please at least respond to this list ASAP
with your positive support.

If you have the time and expertise, please read the rest of this
email and see if you can offer cogent arguments as to why this is
work that the DHC working group should be pursuing.

If we don't standardize the leasequery capability, each vendor of
access concentrators and DHCP products that wish to use this
approach will then need to work together (possibly in some other
forum) to try to get their products to be compatible.  Of course,
it may well be that we are the only folks who see this as a
useful capability, and so that may not be an issue at all.

Thanks -- Kim

-----------------------  Summary -----------------------

In case you haven't been following the email between Thomas
Narten and myself, he has been questioning the problem statement
of the leasequery draft.  Ralph proposed a new problem statement,
but Thomas feels that this whole capability is questionable.

You are invited to respond to Thomas' arguments, which I have
distilled as follows:

  1.  Doing anything in the DHC WG like supporting "access
  control in router type devices" is out of scope for the working
  group, and doesn't fit its current charter.

  2.  Access control in router type devices is not well enough
  understood to be sure that:

	a) leasequery is the right solution.

	b) any DHC-based approach is the "right" approach to
	solve this problem.

  3.  Until we are sure of 2(a), then we should not proceed with
  this work (I believe that this statement is implicit in Thomas'
  comments.)

-----------------------  Background ---------------------------

Here is Ralph's proposed problem statement:

   Router-type devices which want to enforce some level of access
   control over which IP addresses are allowed on their links
   need to maintain information concerning IP<-MAC/client-id
   mappings.  One way in which these devices can obtain
   information about IP<-MAC/client-id bindings is through "DHCP
   gleaning", in which the device extracts useful information
   from DHCP messages exchanged between hosts and DHCP servers.

   obtain information about IP<-MAC/client-id bindings from a

Thomas' concerns center on the second paragraph above, and he says:

   Note, that above is pretty vague and doesn't say what
   information the access device needs.  It's hard to look at the
   problem statement and say "yes, I understand the boundaries of
   the problem" and then "and the solution seems like a good
   match for the problem".

   Popping up a level, how is it even appropriate for the DHC WG
   to be doing work on "access control in router type devices"?
   One can argue that work of this broad a scope is well
   out-of-scope for this WG (e.g., look at the recently approved
   charter).  I'm far from clear that work of this scope should
   be done in DHC or that the problem is well enough understood
   to conclude that DHC lease query is the right solution or that
   any DHC-based solution is the right one.  What about routers
   wanting to do access control that don't use DHC, for instance?

   And note, I'm not raising these issue just to be a PITA. These
   are questions that I expect that the IESG would ask if I
   brought the document forward.  Thus, I need to have reasonable
   responses to those questions.  Otherwise, I can predict the
   likely outcome.

My response to Thomas was:

   This approach to access control was developed by joint work
   with the folks building our access concentrators and several
   of us in the DHCP implementation group.  They found that the
   functionality delivered to actual users was of sufficient
   value to those users to be worth the cost of engineering this
   particular solution.  We supported them in moving the
   implementation forward.

   activities, and was a logical extension of the those
   activities.

Thanks for your interest in the leasequery capability.

Kim

---

From: "Kevin A. Noll" <[email-masked]>
Date: Wed, 26 Feb 2003 15:17:20 -0500

Kim,

At the risk of sounding foolish since I'm not an active
participant in the WG...

I think there is a need to standardize leasequery.

It seems to me that the problem statement is the real issue.

LeaseQuery should not be positioned in any way as an access
control mechanism or *necessarily* involved in such, especially
since there are other uses for this information.

Leasequery is just what the name implies - a *standard* method for
external entities (whether they be routers or some other system)
to query the DHCP server for lease information.

As it is today, there is no *standard* backend DHCP database that
can be queried. Some use text files, some use LDAP, some use proprietary
databases, etc. Therefore, the ability to query a DHCP server for
lease information does not exist except through proprietary methods.

This limits interoperability of the various vendors systems. For example,
there is no way for vendor X to query vendor Y's DHCP server unless
they cooperate outside the standards bodies.

This functionality is not limited to routers (or other devices)
using the information for access control. There are cases (not
necessarily well documented) where systems external to the DHCP
server need to find out about a lease for network management or
troubleshooting reasons.

One example is a helpdesk staffer trying to find out whether a
device is up or down, but only knows the MAC address of the device.
How does he/she find out the IP?

Okay, DNS could be consulted, but it isn't authoritative for information
regarding MAC-to-IP mapping, only NAME-to-IP mapping. There have been
various schemes to store this information in DNS (e.g. the NAME is easily
derived given the MAC, etc), but there are all kinds of issues that arise
with this solution (what if we don't *want* that information in DNS, etc.)

The stable storage statements in the current problem statement aren't
necessarily relevant, either.

My suggestion is that the problem statement be centered around making the
DHCP server the *authority* for lease information.

An alternative would be to write a new draft (maybe not within this WG) that
would define a way to make some existing network database (probably DNS)
authoritative for this information.

I think we could come up with a better problem statement that
would get your leasequery draft further down the road.

Anyway, that's my 2 cents worth.

--kan--
--
Kevin A. Noll, KD4WOZ				[email-masked]
CCIE,CCDP
Perfect Order, Inc.				717-796-1936

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Kim
Kinnear
Sent: Wednesday, 26 February, 2003 12:37 PM
To: [email-masked]
Cc: Ralph Droms; Thomas Narten; Kim Kinnear
Subject: [dhcwg] Leasequery: should it be standardized?

Folks,

Thanks -- Kim

-----------------------  Background ---------------------------

Kim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Feb 2003 14:30:51 -0600

> with your positive support.

Yes, DHCPLEASEQUERY is a good thing, and I support it.   I don't know 
how to address Thomas' complaints about its relevance to the WG charter 
- perhaps it should be advanced in some other WG, or independent of a 
WG - but it's certainly a good idea, and certainly whether or not there 
is some other WG in which it need also be discussed, it was highly 
appropriate to raise it here, since it is an extension to DHCP, and 
this is where the DHCP expertise is concentrated.

My recollection, though, was that back in the beginning of all this, 
DHCPLEASEQUERY was about providing a way to refresh the ARP cache of a 
concentrator without having to broadcast an ARP request to every one of 
the concentrator's ports.   Is that no longer the case?

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Feb 2003 15:52:27 -0500

> the concentrator's ports.   Is that no longer the case?

Apparently so, and that is what has prompted my asking questions. The
scope of the problem seems to have expanded quite a bit beyond:

  "providing a way to refresh the ARP cache of a concentrator without
  having to broadcast an ARP request to every one of the
  concentrator's ports",

to something perhaps closer to providing "access control in router
type devices", including cases where DHCP isn't even being used.

I don't have a real problem with leasequery as it was originally
described. But if the scope of the problem being solved expands well
beyond the original problem, it's no longer clear that:

 - the problem statement is adequately well understood and accepted by
   the broader community (or maybe even the DHC community).  Maybe
   other folk not familiar with DHC need a solution to the broader
   problem and will see this solution as being deficient for their
   needs.

 - it's no longer clear whether DHC has the right expertise to get the
   problem defined properly or to work out a good solution.

 - it's no longer obvious that DHC is the best solution to the expanded
   problem.

I am not saying that leasequery as a concept is flawed, but I am
asking questions about the current version of the leasequery draft and
whether it has the right level of functionality and features in it and
is the right thing to standardize on.

Thomas

---

From: "Kevin A. Noll" <[email-masked]>
Date: Wed, 26 Feb 2003 15:37:34 -0500

Kim,

--kan--

-----Original Message-----

Folks,

Thanks -- Kim

-----------------------  Background ---------------------------

Kim

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 26 Feb 2003 15:59:24 -0500

At 03:30 PM 2/26/2003, Ted Lemon wrote:
>Yes, DHCPLEASEQUERY is a good thing, and I support it.   I don't know how to address Thomas' complaints about its relevance to the WG charter - perhaps it should be advanced in some other WG, or independent of a WG - but it's certainly a good idea, and certainly whether or not there is some other WG in which it need also be discussed, it was highly appropriate to raise it here, since it is an extension to DHCP, and this is where the DHCP expertise is concentrated.

        Thanks.  Of course I agree, or I would never    
        have bothered to spend time on it.

>My recollection, though, was that back in the beginning of all this, DHCPLEASEQUERY was about providing a way to refresh the ARP cache of a concentrator without having to broadcast an ARP request to every one of the concentrator's ports.   Is that no longer the case?

        Strangely, that was never actually the reason that I
        thought we were doing leasequery.  ARP is mentioned in
        the draft as an inadequate solution to recovering IP
        address <-> MAC address relationships originally
        discovered by DHCP "gleaning".  Perhaps that is
        synonymous with refreshing the ARP cache.  Certainly that
        involves the same information, but perhaps the use to
        which an ARP cache is put is not the same as the use to
        which the IP address <-> MAC address relationships
        discovered from DHCP gleaning is to be put.

        Cheers -- Kim

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 27 Feb 2003 16:15:28 -0800

Kim--

I agree that the proposed leasequery mechanism is of value for refreshing
stateless devices such as access concentrators, relay agents, and others.  I
further agree that using the existing BOOTP packet layout as the framework
for requesting and supplying information is appropriate.

I do have a few nits with the draft, however.  The position of the "R" bit
flag needs to be identified, or at least, proposed.

Selectively quoting from the -04 draft:

3.  Background

   The focus of this document is to enable access concentrators
   to send DHCPLEASEQUERY messages to DHCP servers, to obtain
   location information of broadband access network devices.

5.  Protocol Overview

   The access concentrator initiates all DHCPLEASEQUERY message
   conversations.

7.  Security Considerations

   Access concentrators SHOULD minimize potential denial of service
   attacks on the DHCP servers by minimizing the generation of
   DHCPLEASEQUERY messages.

These three excerpts suggest, but do not mandate, that a leasequery exchange
is solely between the access concentrator and server.  Two issues with this:

(1) I have a mild objection to using the term "access concentrator" solely
because that is not a component of the DHCP model environment, which
consists of clients, servers, and relay agents.  Since your proposed
definition states that an access concentrator must contain relay agent
functionality, why not just call it a relay agent?

(2) There is no language prohibiting forwarding of leasequery messages from
a downstream device, presumably because relay agents are often cascaded when
constructing large networks.  This suggests that dhcp clients or other
network hosts may originate leasequery messages:  a relay agent must forward
the messages because there is no mechanism defined to prevent this.  Hence,
a potential Denial of Service attack, initiated by a rogue client or other
rogue host.  Note that I don't have any suggestions short of the use of DHCP
Authentication to prevent this.

A more general question arises with respect to the "R" flag.  Why is it
important to know if the IP to MAC or IP to Client Identifier mappings
exist(ed) because of a reservation?  If a reservation exists, but the server
has not had a protocol exchange with the client, the server would respond
with DHCPLEASEKNOWN, and if queried for the IP Address Lease Time, the
server could respond with an all-ones entry (signifying infinite).  I also
contend that an unused reservation should not receive a DHCPLEASEACTIVE
reply as that somewhat misstates the circumstances.

For your information, Glenn and I will be submitting the -08 draft of the
DHCPv4 server MIB prior to the San Francisco meeting.  In the [hopefully
final] draft there is a table defined, the dhcpv4ServerClientTable, that
contains the IP address, last client request type and time of request, and
the last server response type, indexed by the 3-tuple, 'hlen,' 'htype,' and
'chaddr.'  There is a second table, the dhcpv4ServerAddressTable, that
contains the lease type (static, dynamic, expired, reserved, unusable),
allowed and served protocol, physical address, client identifier, host name,
and domain name, indexed by the IP address.  So, while this covers the same
information (and more) as the proposed leasequery option, it is much less
usable for lightweight inquiries.

--Barr