Re: [dhcwg] lease query question

[Kim Kinnear <[e-mail]>]

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