Subject: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt

From: [email-masked]
Date: Tue, 12 Feb 2008 07:00:01 -0800 (PST)

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 Bulk Leasequery
	Author(s)       : M. Stapp
	Filename        : draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt
	Pages           : 17
	Date            : 2008-02-11

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv6 bindings.  That mechanism is limited to
queries for individual bindings.  In some situations individual
binding queries may not be efficient, or even possible.  This
document specifies extensions to the Leasequery protocol that add new
query types and allow for bulk transfer of DHCPv6 binding data.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-bulk-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-dhcpv6-bulk-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-dhcpv6-bulk-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]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Tue, 12 Feb 2008 10:15:24 -0500

Hello all,

This is the first 'working-group' version of the dhcpv6 bulk leasequery 
draft that we discussed at the vancouver ietf.

There aren't huge changes between the individual submission and this 
version. I did add a brief section to cover the relationship between the 
existing rfc5007 UDP leasequery and the new proposal. I also made a 
variety of clarifications and cleanups that were suggested during a 
couple of mailing-list threads. Thanks to everyone who offered 
suggestions and corrections.

Please take a look and send comments to the list. I will be doing 
another brief presentation at the philadelphia ietf meeting - I think 
that's already on Ralph's proposed agenda.

Thanks,
Mark

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Feb 2008 08:28:53 -0800

> version. I did add a brief section to cover the relationship between the 

The main technical debate about the individual submission centered
around handling of leasequery option codes that were bulk-query
specific; whether to emit errors, have some sort of 'more bit', just
drop the bogus kinds of packets, etc.  Did you come to a conclusion
that made it into this draft?

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Tue, 12 Feb 2008 11:33:46 -0500

Hi David,

yes: I've added text that says the bulk protocol can use the RFC5007 
queries but not vice-versa. bulk lq servers should respond with the 
NotAllowed status if a bulk query-type shows up in a UDP query message.

-- Mark

David W. Hankins wrote:
> ------------------------------------------------------------------------
>

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 12 Feb 2008 09:20:02 -0800

> NotAllowed status if a bulk query-type shows up in a UDP query message.

OK, I'll give it a read, thanks Mark.

---

From: Marcus <[email-masked]>
Date: Wed, 20 Feb 2008 13:48:51 +0100

Hi Mark,

Was there any consensus on the DOCSIS cablemodem MAC address query
discussion? I have not seen anything about it being mentioned in the draft.

Personally I would think that the remote-ID query should be generic enough
to cover this scenario on a protocol level. The relay agent (CMTS) could
take care of populating the CableLabs vendor option as well as the RFC4649
remote-ID with the appropriate values. That would also guarantee that any
DHCP server, supporting RFC4649 would be able to cope with a DOCSIS
environment, without vendor specific changes (for leasequeries, that is).

Marcus

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 20 Feb 2008 14:00:22 -0500

Marcus,
 
I was the CMTS representative in the development of RFC5007. After that
I am slowly getting up to speed on the Bulk Lease Query(LQ) development.
Let me see if I can answer this issue for you.
 
Firstly, your idea below makes sense. I think Bernie Volz also mentioned
the use of remote-id over a vendor specific information option defined
by cable docsis 3.0 standards.
 
Both DHCPv4 or v6 query protocols were developed for Cable industry (and
use by any other deployment) to source verify client PC's sitting behind
cable modems. No one in a cable network issues a LQ for a cable modem.
The modem is always verifiable for all its information including
mac-addr and L3 address via cable specific docsis messages. Since the
remote-id option is the mac-addr of the modem we have to evaluate what
good is this option to query a PC information for? For both modem and PC
DHCPv4 or v6 traffic, if the CMTS supports remote-id, the CMTS relay
slaps the mac-addr of modem in the remote-id option.
 
The remote-id for a modem is only useful if the modem is an IPv6 router
modem to which a PD will be delegated - then CMTS queries the server via
remote-id and gets the PD assigned to the modem back. Then CMTS checks
if any PC traffic to be source verified matches the PD. However, if the
modem is an IPv6 bridged modem, how a server collects information about
PC's behind such a modem is left to the server vendor - at least that is
how I think it should be. Others may have different opinions.
 
Hemant

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marcus
Sent: Wednesday, February 20, 2008 7:49 AM
To: Mark Stapp (mjs)
Cc: DHC WG
Subject: Re: [dhcwg] I-D
Action:draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt

Hi Mark,

Was there any consensus on the DOCSIS cablemodem MAC address query
discussion? I have not seen anything about it being mentioned in the
draft.

Personally I would think that the remote-ID query should be generic
enough to cover this scenario on a protocol level. The relay agent
(CMTS) could take care of populating the CableLabs vendor option as well
as the RFC4649 remote-ID with the appropriate values. That would also
guarantee that any DHCP server, supporting RFC4649 would be able to cope
with a DOCSIS environment, without vendor specific changes (for
leasequeries, that is).

Marcus

	Hi David,
	
	yes: I've added text that says the bulk protocol can use the
RFC5007
	queries but not vice-versa. bulk lq servers should respond with
the
	NotAllowed status if a bulk query-type shows up in a UDP query
message.
	
	-- Mark

---

From: John Jason Brzozowski <[email-masked]>
Date: Wed, 20 Feb 2008 14:21:39 -0500

Marcus,

From what I recall what you outline below is accurate which is why I suspect
the DHCPv6 Bulk Leasequery ID does not specify a query-by-cl-mac-address
query or some other custom query.

The CMTS is this case will have to continue to support vendor options when
relaying packets and RFC4649 when issuing bulk leasequeries.  As you suggest
the DHCP server will also need to support RFC4649 relative to bulk
leasequeries.

John

On 2/20/08 7:48 AM, "Marcus" <[email-masked]> wrote:

> Hi Mark,
> 
> Was there any consensus on the DOCSIS cablemodem MAC address query discussion?
> I have not seen anything about it being mentioned in the draft.
> 
> Personally I would think that the remote-ID query should be generic enough to
> cover this scenario on a protocol level. The relay agent (CMTS) could take
> care of populating the CableLabs vendor option as well as the RFC4649
> remote-ID with the appropriate values. That would also guarantee that any DHCP
> server, supporting RFC4649 would be able to cope with a DOCSIS environment,
> without vendor specific changes (for leasequeries, that is).
> 
> Marcus
> 

=========================================
John Jason Brzozowski (CISSP, RHCT)
Comcast Corporation
e) mailto:[email-masked]
m) 609-377-6594
p) 856-324-2671
=========================================

---

From: John Jason Brzozowski <[email-masked]>
Date: Wed, 20 Feb 2008 14:40:37 -0500

I do believe I agree with Hemant in that the most useful scenario for
query-by-remoteid is when the the CPE device is some sort of (IPv6) router
device.

In advance of the above bulking leasequery will likely prove useful in the
scenario below that Hemant describes source verification data is rebuilt
proactively.

John

On 2/20/08 2:00 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Marcus,
>  
> I was the CMTS representative in the development of RFC5007. After that I am
> slowly getting up to speed on the Bulk Lease Query(LQ) development. Let me see
> if I can answer this issue for you.
>  
> Firstly, your idea below makes sense. I think Bernie Volz also mentioned the
> use of remote-id over a vendor specific information option defined by cable
> docsis 3.0 standards.
>  
> Both DHCPv4 or v6 query protocols were developed for Cable industry (and use
> by any other deployment) to source verify client PC's sitting behind cable
> modems. No one in a cable network issues a LQ for a cable modem. The modem is
> always verifiable for all its information including mac-addr and L3 address
> via cable specific docsis messages. Since the remote-id option is the mac-addr
> of the modem we have to evaluate what good is this option to query a PC
> information for? For both modem and PC DHCPv4 or v6 traffic, if the CMTS
> supports remote-id, the CMTS relay slaps the mac-addr of modem in the
> remote-id option.
>  
> The remote-id for a modem is only useful if the modem is an IPv6 router modem
> to which a PD will be delegated - then CMTS queries the server via remote-id
> and gets the PD assigned to the modem back. Then CMTS checks if any PC traffic
> to be source verified matches the PD. However, if the modem is an IPv6 bridged
> modem, how a server collects information about PC's behind such a modem is
> left to the server vendor - at least that is how I think it should be. Others
> may have different opinions.
>  
> Hemant
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Marcus
> Subject: Re: [dhcwg] I-D Action:draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt
> 
> Hi Mark,
>

---

From: Marcus <[email-masked]>
Date: Fri, 22 Feb 2008 09:23:11 +0100

Hermant,

Yes, I also think Bernie Volz mentioned this option and it seemed to make a
lot of sense.

You are right that the CMTS would anyway put the cable modem MAC address
into the remote-ID field, if supported, I did not really think about that.

I would think that the CMTS would get the PD from a remote-ID query even
with an IPv6 bridged modem, because the CMTS would attach the cable modem
MAC as a remote-ID to the DHCP traffic of the IPv6 router behind it (which
is requesting the PD). But please correct me if I am wrong here.

Marcus

On Wed, Feb 20, 2008 at 8:00 PM, Hemant Singh (shemant) <[email-masked]>
wrote:

> I am slowly getting up to speed on the Bulk Lease Query(LQ) development. Let
> me see if I can answer this issue for you.
>
> the use of remote-id over a vendor specific information option defined by
> cable docsis 3.0 standards.
>
> cable modems. No one in a cable network issues a LQ for a cable modem. The
> modem is always verifiable for all its information including mac-addr and L3
> address via cable specific docsis messages. Since the remote-id option is
> the mac-addr of the modem we have to evaluate what good is this option to
> query a PC information for? For both modem and PC DHCPv4 or v6 traffic, if
> the CMTS supports remote-id, the CMTS relay slaps the mac-addr of modem in
> the remote-id option.
>
> remote-id and gets the PD assigned to the modem back. Then CMTS checks if
> any PC traffic to be source verified matches the PD. However, if the modem
> is an IPv6 bridged modem, how a server collects information about PC's
> behind such a modem is left to the server vendor - at least that is how I
> think it should be. Others may have different opinions.
>
> Hemant
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Marcus
> *Sent:* Wednesday, February 20, 2008 7:49 AM
> *To:* Mark Stapp (mjs)
> *Cc:* DHC WG
> *Subject:* Re: [dhcwg] I-D Action:
> draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt
>
> Hi Mark,
>

---

From: Marcus <[email-masked]>
Date: Fri, 22 Feb 2008 09:30:49 +0100

John,

It will certainly be useful in cases where the CPE device is a router,
although I believe that it would also help if a router is behind a modem (as
written in the reply to Hermant).

Yes, I can also see it helpful to proactively built up the source
verification data.

Marcus

On Wed, Feb 20, 2008 at 8:40 PM, John Jason Brzozowski <
[email-masked]> wrote:

> I am
> use
> modem
> Of
> > Subject: Re: [dhcwg] I-D Action:
> discussion?
> enough to

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 22 Feb 2008 07:07:12 -0500

Marcus,
 
See Fig. 1 in section 3.1 of 
 
http://www.ietf.org/internet-drafts/draft-wbeebee-on-link-and-off-link-d
etermination-01.txt
 
The bridged modem case as you describe below mentioned there. Indeed if
there is a Rtr behind the bridged modem, this case would also work the
same on CMTS as when the modem is a Rtr itself.
 
However, when I said a bridged modem case is left to the sever vendor, I
was referring to the case when no Rtr exists behind the bridged modem -
the device behind the modem is only a switch or a hub. In such a
network, the there is no device downstream of the CMTS that can be
assigned a PD. That is why I said, it's up to server vendors to figure
out what they want to do here. 
 
Hemant

From: Marcus [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 3:23 AM
To: Hemant Singh (shemant)
Cc: Mark Stapp (mjs); DHC WG
Subject: Re: [dhcwg] I-D
Action:draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt

Hermant,

Yes, I also think Bernie Volz mentioned this option and it seemed to
make a lot of sense.

You are right that the CMTS would anyway put the cable modem MAC address
into the remote-ID field, if supported, I did not really think about
that.

I would think that the CMTS would get the PD from a remote-ID query even
with an IPv6 bridged modem, because the CMTS would attach the cable
modem MAC as a remote-ID to the DHCP traffic of the IPv6 router behind
it (which is requesting the PD). But please correct me if I am wrong
here.

Marcus

On Wed, Feb 20, 2008 at 8:00 PM, Hemant Singh (shemant)
<[email-masked]> wrote:

	Marcus,
	 
	I was the CMTS representative in the development of RFC5007.
After that I am slowly getting up to speed on the Bulk Lease Query(LQ)
development. Let me see if I can answer this issue for you.
	 
	Firstly, your idea below makes sense. I think Bernie Volz also
mentioned the use of remote-id over a vendor specific information option
defined by cable docsis 3.0 standards.
	 
	Both DHCPv4 or v6 query protocols were developed for Cable
industry (and use by any other deployment) to source verify client PC's
sitting behind cable modems. No one in a cable network issues a LQ for a
cable modem. The modem is always verifiable for all its information
including mac-addr and L3 address via cable specific docsis messages.
Since the remote-id option is the mac-addr of the modem we have to
evaluate what good is this option to query a PC information for? For
both modem and PC DHCPv4 or v6 traffic, if the CMTS supports remote-id,
the CMTS relay slaps the mac-addr of modem in the remote-id option.
	 
	The remote-id for a modem is only useful if the modem is an IPv6
router modem to which a PD will be delegated - then CMTS queries the
server via remote-id and gets the PD assigned to the modem back. Then
CMTS checks if any PC traffic to be source verified matches the PD.
However, if the modem is an IPv6 bridged modem, how a server collects
information about PC's behind such a modem is left to the server vendor
- at least that is how I think it should be. Others may have different
opinions.
	 
	Hemant

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marcus
	Sent: Wednesday, February 20, 2008 7:49 AM
	To: Mark Stapp (mjs)
	Cc: DHC WG
	Subject: Re: [dhcwg] I-D
Action:draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt

	Hi Mark,
	
	Was there any consensus on the DOCSIS cablemodem MAC address
query discussion? I have not seen anything about it being mentioned in
the draft.
	
	Personally I would think that the remote-ID query should be
generic enough to cover this scenario on a protocol level. The relay
agent (CMTS) could take care of populating the CableLabs vendor option
as well as the RFC4649 remote-ID with the appropriate values. That would
also guarantee that any DHCP server, supporting RFC4649 would be able to
cope with a DOCSIS environment, without vendor specific changes (for
leasequeries, that is).
	
	Marcus

		Hi David,
		
		yes: I've added text that says the bulk protocol can use
the RFC5007
		queries but not vice-versa. bulk lq servers should
respond with the
		NotAllowed status if a bulk query-type shows up in a UDP
query message.
		
		-- Mark

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 24 Feb 2008 22:52:10 -0500

We do want to use only Remote-ID "only".
 
Note also that a DOCSIS bulk LQ server can look for a match on the
remote-id and if it is not found, could instead look for the appropriate
CableLabs vendor-optns data. (Or it could synthesize the remote-id if
none was provided when processing client requests.) At least this would
provide support until the CMTS' are updated to send the remote-id.
 
- Bernie

Cc: DHC WG; Mark Stapp (mjs)

Hermant,

Marcus

	Marcus,

	 

	Hemant

	Hi Mark,

	
	Marcus

		Hi David,

		-- Mark