Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcvp6-leasequery-00.txt

From: [email-masked]
Date: Tue, 22 Aug 2006 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: DHCPv6 Leasequery
	Author(s)	: J. Brzozowski, et al.
	Filename	: draft-ietf-dhc-dhcvp6-leasequery-00.txt
	Pages		: 18
	Date		: 2006-8-22
	
This document specifies leasequery for the Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) which can be used as a means to obtain
lease information about DHCPv6 clients from a DHCPv6 server.  This
document specifies the scope of data that can be retrieved as well as
both DHCPv6 leasequery requestor and server behavior.  This document
extends DHCPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-dhc-dhcvp6-leasequery-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-dhcvp6-leasequery-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 28 Aug 2006 09:46:18 -0400

Shane:

See below (BV>).

- Bernie 

-----Original Message-----
From: Shane Kerr [mailto:[email-masked]] 
Sent: Monday, August 28, 2006 9:07 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcvp6-leasequery-00.txt

Bernie,

Bernie Volz (volz) wrote:
> Hi:
> 
> This revised (over the individual submission discussed at the Montreal
> IETF in July) draft has the following major change - all but the
> "by-address" query were removed. This query can return the information
> on a client that has either the address assigned or been delegated a
> prefix that includes that address.
> 
> This change also removed the anticipatory leasequery and the need for
> bulking and multiple responses (over UDP) or a TCP based protocol.
> 
> Please provide comments as to whether this is sufficient for at least
> our initial needs. And, of course point out improvements to make or
> errors to correct in the text.

I think going with the simpler model (no bulk queries and so on) makes
sense
because it closely matches the DHCPv4 LEASEQUERY, and does not introduce
a new
transport mechanism like the earlier draft.

I don't work with any networks with an access concentrator, so I want to
make
sure I understand the use case for DHCPv6 LEASEQUERY.

The idea is that an access concentrator will become aware that an IPv6
address
is in use that it did not know about, and then use DHCPv6 LEASEQUERY to
get some
information about the lease for that IPv6 that helps it act as a better
relay?

BV> Correct. Typically this happens after a reboot since the
concentrator does not generally have stable storage (or place
information about clients there). But, likely it is more general in that
if the information is not in the concentrator's memory, it will perform
a leasequery to see if a DHCPv6 server knows about that address and
update its memory accordingly.

In DHCPv4 LEASEQUERY, presumably an access concentrator could query the
entire
space it served fairly quickly from the server, one IP at a time
("anticipatory
leasequery" you called it above). Since this is not practical in IPv6, I
guess
this is why the previous version of the draft had query-by-prefix along
with the
mechanism for returning the data.

BV> No. While a DHCPv4 relay could do this, I am not aware that it is
done because typically the number of potential addresses is rather large
and DHCPv4 leasequery only allows querying a single address per request
so this would take LOTS of queries. And, there is little reason to do
this -- since the on-demand works fine. And, DHCPv4 does not have Prefix
Delegation, which is really where the issue is ...

BV> The problem with on-demand for DHCPv6 isn't for stateful addresses
(since the on-demand works great there). It is for Delegated Prefixes.
The problem here is spelled out in the draft (section 3.1):

   However, this approach has limitations when used with prefix
   delegation [4] as no traffic may arrive because the access
   concentrator is unable to inject the appropriate routing information
   into the routing infrastructure, such as after a reboot.  This
   approach does work if the access concentrator is configured to inject
   routing information for a prefix which aggregates potentially
   delegated prefixes.  Or, if the access concentrator and requesting
   router use a routing protocol; as then the requesting router can
   trigger the access concentrator to request information from a DHCPv6
   server and inject appropriate routing information into the routing
   infrastructure.

BV> With stateful addresses, the relay will be configured for the
prefix(es) for those addresses and thus inject them into the routing
infrastructure. However, for delegated prefixes that may or may not be
the case (as indicated above).

Is the anticipatory leasequery not a valuable use-case? Or did you just
decide
to omit it because of the difficulty in solving the problem?

BV> It has a potential use-case as indicated above. However, there are
other means to solve this problem and I think those are preferred
mechanisms because they solve other issues as well -- see
http://bgp.potaroo.net/ietf/html/ids-wg-bfd.html.

- --
Shane