Re: [dhcwg] lease query question

[Ralph Droms <[e-mail]>]

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

At 06:31 PM 2/10/2003 -0500, Kim Kinnear wrote:
>At 11:28 AM 2/4/2003, Thomas Narten wrote:
> >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.
>
>         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.
>
>
> >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).
>
>         Largely, this is what it does.
>
>
> >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.
>
>         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.
>
>
> >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?
>
>
>         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
>
>
> >Thomas
> >_______________________________________________
> >dhcwg mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/dhcwg

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