RE: [dhcwg] lease query question

["Cosmo, Patrick" <[e-mail]>]

>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?

Here's one example:

some relay agents provide an "Host Authentication" feature where they only
fwd data from an device using an IP address that the device "really does
own". This is an attempt to prevent IP spoofing. The relay agent determines
who "owns" an IP address (who was actually leased the address) by gleaning
the DHCP messages that pass through it, or through DHCP lease query. In the
case where a device is manually configured with an IP and is not performing
DHCP, the DHCP service may be configured with a "static address" for the
device to indicate that the device really does "own" that IP address. The
relay agent can determine and recognize this fact through the use of DHCP
lease query.

There may be other current examples, or future uses not yet considered. It's
all about flexibility I think.


-----Original Message-----
From: Thomas Narten [mailto:[e-mail]]
Sent: Tuesday, February 11, 2003 12:51 PM
To: Kim Kinnear
Cc: [e-mail]; [e-mail]; Woundy, Richard
Subject: Re: [dhcwg] lease query question 


Hi Kim.

>         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.

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.

>         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.

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.

>         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 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?

>         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.

Makes complete sense for normal DHC usage.

>	  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.

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
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg