Dynamic Host Configuration (dhc)

headers Huan Huan | 1 Mar 2012 14:05

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Picking this back up again in the hopes of achieving a resolution...

I think we're close to consensus on the relationship (or lack thereof, I guess), between the lifetime of a
location URI and DHCP refresh mechanics. I suggest the following edit to Section 2.3 to clarify this:

===
OLD:

The Valid-For (LuriType=2) indicates how long, in seconds, the
   client is to consider this location URI (LuriType=1) valid
   before performing a refresh of this Option, with a refreshed
   LuriType=2 (Valid-For) value.  A client will update its Location URI
   either as part of the normal DHCP lease renewal, or through a
   renewal request sent due to the Valid-For timer reaching the value
   described in this document. Note that in the second case, the
   request could ask only for the LocationURI option.

   The Valid-For (LuriType=2) offers no meaningful information without
   an accompanying Location URI (LuriType=1), therefore a Valid-For
   (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).

   If the Valid-For timer (LuriType=2) is received (solicited or
   unsolicited), it is RECOMMENDED that the client refresh the Location
   URI when the (Valid-For) counter value reaches approximately the
   halfway point.  For example, if 16000 was the initial value of the
   Valid-For (LuriType=2) value, when 8000 seconds have passed, the
   Option SHOULD be refreshed.  However, if every client on a network
   were to attempt a refresh at the same time, say if power when out
   and was brought back up at the same time, there would be an
   avalanche of location requests or transmissions. This can be avoided
   by varying the timers between the nodes on the same network.  This
   can be a good reason for not giving out the same Valid-for timer
   (amount) with each Location URI sent.

NEW:

The Valid-For (LuriType=2) indicates how long, in seconds, the
   client is to consider this location URI (LuriType=1) valid. The choice of the Valid-For value is a policy
decision for the domain administrator. It can be statically configured on the DHCP server or provisioned
dynamically (via an out-of-band exchange with a Location Information Server) as requests for location
URIs are received. Expiration of the Valid-For timeframe does not trigger an automatic refresh of the
location URI or impinge on DHCP mechanics in any other way -- it merely informs the client of the URI's valid lifetime.

   The Valid-For (LuriType=2) offers no meaningful information without
   an accompanying Location URI (LuriType=1), therefore a Valid-For
   (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
===

If that satisfies the folks that have been discussing this, I think that concludes the DHC review of this document.

Alissa

On Dec 8, 2011, at 2:58 PM, Robert Sparks wrote:

> On 12/8/11 11:27 AM, Ted Lemon wrote:
>> On Dec 7, 2011, at 4:31 PM, Robert Sparks wrote:
>>> If I have it right, the essence of (this part of) your concern is that a dhcp server can't be constrained
>>> to go ask an external process for the information it needs to respond to a request. That is, it needs
>>> to be able to respond to the request with the data it has at the time the request arrives. The operational
>>> model is that the data you have to respond with is the kind of stuff the server admin would enter as
>>> configuration (and it's possible that the admin would need to type very fast). It would be ok for an external
>>> process to be providing new information, but not ok to require the server to ask that external process for
>>> information (or wait on it if information became stale, etc.)
>> 
>> So I've been ruminating about this since my rather terse response yesterday.   I think it's inappropriate
for me as an individual or as a working group chair to be the only one weighing in on this.   I have some pretty
strong opinions about what standards should require of DHCP servers, and I don't really think my opinions
are inherently right—they're just opinions.
>> 
>> My essential concern about this document is that it seems to be placing expectations on a DHCP server that
I think a typical DHCP server vendor would not be comfortable with.   At the same time, it's also clear to me
that there are DHCP servers out there that could certainly serve this data, even if they did an in-band
query from another server to fetch it.   I know Nominum's DHCP server can do this, and I am pretty sure CNR can
do it as well.
>> 
>> So what I'm saying is that I don't really think it's wrong for a DHCP server to do this.   My concern is that it
might not be practical for an IETF document to effectively _require_ that a DHCP server do this.
>> 
>> That's a fairly weak objection.   If this document were to go through and become a standard, and people
didn't want to implement it, they just wouldn't implement it.
>> 
>> So perhaps it would help if the document were simply clearer about what it was asking of the DHCP server.  
Right now it's a bit vague—all the out-of-band or in-band querying is implied rather than explicitly
stated.   This is part of what I was getting at by asking about real expected use cases.
> Thanks Ted - I agree that we need to make the document clearer. This document should not be causing the
refresh mechanics at a dhcp server or client to change, and it shouldn't be asking the server to do something
> fundamentally different from the kinds of things it already does in order to satisfy the request. I don't
think we really have anybody asking for that, but we need to make the document clear so we're sure. This is
where I was
> trying to focus the first part of the conversation (please do let me know if what I had in that message was right
> or not).
> 
> I'm going to take a stab at answering what I think you're asking for real expected use cases. But be aware
> of this context:
> 
> Email list conversations around how location references are created, moved around, and consumed have been
> notoriously difficult. It's easy to make assumptions, both as the reader and writer, when trying to make short
> points that lead folks to start talking passionately past each other. I think that might have happened early
> in the discussion of this document on this list. The way we've dealt with it is to capture things in the drafts
> (many now RFCs) in more detail. When things start to seem odd, please refer back to those to see if they
> clear up the oddness. A good touchstone starting place is RFC5808 section 3 (including its subsections).
> Because of the context, this is going to be verbose, and nit-sensitive - please read it as an attempt to 
> balance being specific with being concise.
> 
> The use case this draft is addressing is allowing a host to be configured (via dhcp) with a reference to
> a location object that it can hand off (convey) to other elements. If those elements are able to use the
> reference successfully, they get the location object and can use it as part of whatever function they
> are running (these elements are called location recipients).
> 
> The mechanism is intended to be general - there is no one specific expected use case, but some of the
> major instances used while developing the architecture include giving an application on your (fixed)
> desktop the ability to tell the local pizza delivery service where it is, and your mobile phone the ability
> to tell an emergency response center where it is.
> 
> The reference itself will not typically change rapidly - that's a major advantage of using a reference instead
> of providing location-by-value. If you had a deployment where you didn't need to worry about who you've
> given the reference to in the past, it could be configured once and have a very long life. In a more general
> deployment, the reference itself will need to occasionally change - but note that it does so based on the
> application use requirements, not inherently because the bits (location) that the reference points to might
> have changed. For instance, you might be willing to let some delivery service know were you are right now,
> but you don't want them to be able to use the reference you give them next week. This is where the location
> URI expiration notion becomes important - it lets the host know how long the location server will honor
> the reference. It lets the applications on the host make an informed decision about who they expose the
> reference to (I might be willing to give a reference to one of my friends that's good for several days, but
> I might choose not to hand one of those to the cab company in the city I'm visiting). 
> 
> There are some applications where you don't want to give the same reference to two different location recipients.
> Those applications would be better served using a different location configuration protocol than the
one we're
> talking about here, such as HELD (RFC5985).
> 
> Let me stop there and ask if I'm on a path to address your question or if you were looking for something
> completely different.
> 
> Given what's above, I'd like to reiterate the point the we should clarify the draft to make it clear we're not
> trying to change what a dhcp client or server does. How we fix how it's trying to convey URI expiration needs
> to get that part right. I don't think we should remove it from the information that is configured, and I don't
> think we should tie it to the lease time (either by making it being exactly the lease time, or by artificially
> stimulating refreshes based on it. Rather, this is a management coordination task/policy decision for the
> administrative domain. A reasonable Location Information Service that is having its URIs configured into
> hosts using dhcp should be configured to have the exipiry of those URIs be at least as long as the expected
> lease time.
> 
> 
>> Robert, can you or James speak to that?   I don't want you to feel like I'm trying to checkmate you by getting
you to admit to a use case that's forbidden—I don't think it's true that the use case I'm reluctant to
encourage is in fact forbidden.   I just feel like right now the way this is expected to be used is unstated and
vague, and it would be better if it were not.   That is, it would be better for you to really make a case for how
you actually intend to use this option than for us to gloss over it.
>> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg <at> ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

Alissa

thanks for the text offering. It looks good to me.

If the DHCWG has consensus with it, I'll 
incorporate it into the next rev and get that out before the -0X deadline.

James

At 12:52 PM 3/1/2012, Alissa Cooper wrote:
>Picking this back up again in the hopes of achieving a resolution...
>
>I think we're close to consensus on the 
>relationship (or lack thereof, I guess), between 
>the lifetime of a location URI and DHCP refresh 
>mechanics. I suggest the following edit to Section 2.3 to clarify this:
>
>===
>OLD:
>
>The Valid-For (LuriType=2) indicates how long, in seconds, the
>    client is to consider this location URI (LuriType=1) valid
>    before performing a refresh of this Option, with a refreshed
>    LuriType=2 (Valid-For) value.  A client will update its Location URI
>    either as part of the normal DHCP lease renewal, or through a
>    renewal request sent due to the Valid-For timer reaching the value
>    described in this document. Note that in the second case, the
>    request could ask only for the LocationURI option.
>
>    The Valid-For (LuriType=2) offers no meaningful information without
>    an accompanying Location URI (LuriType=1), therefore a Valid-For
>    (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
>
>    If the Valid-For timer (LuriType=2) is received (solicited or
>    unsolicited), it is RECOMMENDED that the client refresh the Location
>    URI when the (Valid-For) counter value reaches approximately the
>    halfway point.  For example, if 16000 was the initial value of the
>    Valid-For (LuriType=2) value, when 8000 seconds have passed, the
>    Option SHOULD be refreshed.  However, if every client on a network
>    were to attempt a refresh at the same time, say if power when out
>    and was brought back up at the same time, there would be an
>    avalanche of location requests or transmissions. This can be avoided
>    by varying the timers between the nodes on the same network.  This
>    can be a good reason for not giving out the same Valid-for timer
>    (amount) with each Location URI sent.
>
>NEW:
>
>The Valid-For (LuriType=2) indicates how long, in seconds, the
>    client is to consider this location URI 
> (LuriType=1) valid. The choice of the Valid-For 
> value is a policy decision for the domain 
> administrator. It can be statically configured 
> on the DHCP server or provisioned dynamically 
> (via an out-of-band exchange with a Location 
> Information Server) as requests for location 
> URIs are received. Expiration of the Valid-For 
> timeframe does not trigger an automatic refresh 
> of the location URI or impinge on DHCP 
> mechanics in any other way -- it merely informs 
> the client of the URI's valid lifetime.
>
>    The Valid-For (LuriType=2) offers no meaningful information without
>    an accompanying Location URI (LuriType=1), therefore a Valid-For
>    (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
>===
>
>If that satisfies the folks that have been 
>discussing this, I think that concludes the DHC review of this document.
>
>Alissa
>
>On Dec 8, 2011, at 2:58 PM, Robert Sparks wrote:
>
> > On 12/8/11 11:27 AM, Ted Lemon wrote:
> >> On Dec 7, 2011, at 4:31 PM, Robert Sparks wrote:
> >>> If I have it right, the essence of (this 
> part of) your concern is that a dhcp server can't be constrained
> >>> to go ask an external process for the 
> information it needs to respond to a request. That is, it needs
> >>> to be able to respond to the request with 
> the data it has at the time the request arrives. The operational
> >>> model is that the data you have to respond 
> with is the kind of stuff the server admin would enter as
> >>> configuration (and it's possible that the 
> admin would need to type very fast). It would be ok for an external
> >>> process to be providing new information, 
> but not ok to require the server to ask that external process for
> >>> information (or wait on it if information became stale, etc.)
> >>
> >> So I've been ruminating about this since my 
> rather terse response yesterday.   I think it's 
> inappropriate for me as an individual or as a 
> working group chair to be the only one weighing 
> in on this.   I have some pretty strong 
> opinions about what standards should require of 
> DHCP servers, and I don't really think my 
> opinions are inherently rightthey're just opinions.
> >>
> >> My essential concern about this document is 
> that it seems to be placing expectations on a 
> DHCP server that I think a typical DHCP server 
> vendor would not be comfortable with.   At the 
> same time, it's also clear to me that there are 
> DHCP servers out there that could certainly 
> serve this data, even if they did an in-band 
> query from another server to fetch it.   I know 
> Nominum's DHCP server can do this, and I am pretty sure CNR can do it as well.
> >>
> >> So what I'm saying is that I don't really 
> think it's wrong for a DHCP server to do 
> this.   My concern is that it might not be 
> practical for an IETF document to effectively 
> _require_ that a DHCP server do this.
> >>
> >> That's a fairly weak objection.   If this 
> document were to go through and become a 
> standard, and people didn't want to implement 
> it, they just wouldn't implement it.
> >>
> >> So perhaps it would help if the document 
> were simply clearer about what it was asking of 
> the DHCP server.   Right now it's a bit 
> vagueall the out-of-band or in-band querying 
> is implied rather than explicitly 
> stated.   This is part of what I was getting at 
> by asking about real expected use cases.
> > Thanks Ted - I agree that we need to make the 
> document clearer. This document should not be 
> causing the refresh mechanics at a dhcp server 
> or client to change, and it shouldn't be asking the server to do something
> > fundamentally different from the kinds of 
> things it already does in order to satisfy the 
> request. I don't think we really have anybody 
> asking for that, but we need to make the 
> document clear so we're sure. This is where I was
> > trying to focus the first part of the 
> conversation (please do let me know if what I had in that message was right
> > or not).
> >
> > I'm going to take a stab at answering what I 
> think you're asking for real expected use cases. But be aware
> > of this context:
> >
> > Email list conversations around how location 
> references are created, moved around, and consumed have been
> > notoriously difficult. It's easy to make 
> assumptions, both as the reader and writer, when trying to make short
> > points that lead folks to start talking 
> passionately past each other. I think that might have happened early
> > in the discussion of this document on this 
> list. The way we've dealt with it is to capture things in the drafts
> > (many now RFCs) in more detail. When things 
> start to seem odd, please refer back to those to see if they
> > clear up the oddness. A good touchstone 
> starting place is RFC5808 section 3 (including its subsections).
> > Because of the context, this is going to be 
> verbose, and nit-sensitive - please read it as an attempt to
> > balance being specific with being concise.
> >
> > The use case this draft is addressing is 
> allowing a host to be configured (via dhcp) with a reference to
> > a location object that it can hand off 
> (convey) to other elements. If those elements are able to use the
> > reference successfully, they get the location 
> object and can use it as part of whatever function they
> > are running (these elements are called location recipients).
> >
> > The mechanism is intended to be general - 
> there is no one specific expected use case, but some of the
> > major instances used while developing the 
> architecture include giving an application on your (fixed)
> > desktop the ability to tell the local pizza 
> delivery service where it is, and your mobile phone the ability
> > to tell an emergency response center where it is.
> >
> > The reference itself will not typically 
> change rapidly - that's a major advantage of using a reference instead
> > of providing location-by-value. If you had a 
> deployment where you didn't need to worry about who you've
> > given the reference to in the past, it could 
> be configured once and have a very long life. In a more general
> > deployment, the reference itself will need to 
> occasionally change - but note that it does so based on the
> > application use requirements, not inherently 
> because the bits (location) that the reference points to might
> > have changed. For instance, you might be 
> willing to let some delivery service know were you are right now,
> > but you don't want them to be able to use the 
> reference you give them next week. This is where the location
> > URI expiration notion becomes important - it 
> lets the host know how long the location server will honor
> > the reference. It lets the applications on 
> the host make an informed decision about who they expose the
> > reference to (I might be willing to give a 
> reference to one of my friends that's good for several days, but
> > I might choose not to hand one of those to 
> the cab company in the city I'm visiting).
> >
> > There are some applications where you don't 
> want to give the same reference to two different location recipients.
> > Those applications would be better served 
> using a different location configuration protocol than the one we're
> > talking about here, such as HELD (RFC5985).
> >
> > Let me stop there and ask if I'm on a path to 
> address your question or if you were looking for something
> > completely different.
> >
> > Given what's above, I'd like to reiterate the 
> point the we should clarify the draft to make it clear we're not
> > trying to change what a dhcp client or server 
> does. How we fix how it's trying to convey URI expiration needs
> > to get that part right. I don't think we 
> should remove it from the information that is configured, and I don't
> > think we should tie it to the lease time 
> (either by making it being exactly the lease time, or by artificially
> > stimulating refreshes based on it. Rather, 
> this is a management coordination task/policy decision for the
> > administrative domain. A reasonable Location 
> Information Service that is having its URIs configured into
> > hosts using dhcp should be configured to have 
> the exipiry of those URIs be at least as long as the expected
> > lease time.
> >
> >
> >> Robert, can you or James speak to that?   I 
> don't want you to feel like I'm trying to 
> checkmate you by getting you to admit to a use 
> case that's forbiddenI don't think it's true 
> that the use case I'm reluctant to encourage is 
> in fact forbidden.   I just feel like right now 
> the way this is expected to be used is unstated 
> and vague, and it would be better if it were 
> not.   That is, it would be better for you to 
> really make a case for how you actually intend 
> to use this option than for us to gloss over it.
> >>
> >
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Dear WG,

A new draft named "Authorization Option for DHCPv6 Relay Agents on Broadband Access Server" has been
posted yesterday. Questions and comments on it are more than welcome.

Best Regards,
Leaf

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, March 05, 2012 5:26 PM
To: Leaf yeh
Subject: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt

A new version of I-D, draft-yeh-dhc-dhcpv6-authorization-opt-00.txt has been successfully submitted
by Leaf Y. Yeh and posted to the IETF repository.

Filename:	 draft-yeh-dhc-dhcpv6-authorization-opt
Revision:	 00
Title:		 Authorization Option for DHCPv6 Relay Agents on Broadband Access Server
Creation date:	 2012-03-05
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
   The DHCPv6 authorization option provides a communication mechanism
   between relay agent and the server.  This mechanism can help the
   centralized DHCPv6 server to select the right configuration for the
   client based on the authorization information got from the
   centralized RADIUS server which is not located at the same place of
   DHCPv6 server in the case when the NAS works as DHCPv6 relay agent
   and RADIUS client simultaneously.

The IETF Secretariat

I have some comments about draft-ietf-dhc-dhcpv4-over-ipv6-00.txt:
 - first, these are from implementation feedback

 - but this doesn't mean I have good ideas about real world use cases (

 - it is not clear in the introduction but this can work only
  for DHCPv4 messages, not legacy BOOTP messages (in the case
  BOOTP itself is still used?)

 - the document requires the CRA to be colocated with the client,
  in fact it works well when the client is directly attached, i.e.,
  "on the same link" is enough

 - the CRA MUST NOT include an option 82 (RAI): this really limits
  the CRA service, for instance a CRA can't serve more than one link
  (but it is already limited to colocated and with multiple IPv6 source
   addresses it is easy to run several CRAs on the same box)

 - the choice of the ports should be explained, in particular I'd like
  to understand "A CRA also listens for DHCP packets on IPv6 UDP port 68."
  (note I have no concern about the choice itself).

Regards

Francis.Dupont <at> fdupont.fr

PS: I implemented CRA, TRA, TSV and TSV+normal (i.e., the "A TSV can
also listen on IPv4 UDP port 67 like a normal DHCPv4 server"). And
BTW wireshark is fine enough to ignore the IP version when it dissects
UDP port 67/68 packets as DHCPv4.

_______________________________________________
dhcwg mailing list
dhcwg <at> ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

Mon	Tue	Wed	Thu	Fri	Sat	Sun

			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31

78	May 2013
207	April 2013
148	March 2013
120	February 2013
39	January 2013
116	December 2012
146	November 2012
147	October 2012
190	September 2012
157	August 2012
101	July 2012
25	June 2012
21	May 2012
124	April 2012
168	March 2012
80	February 2012
33	January 2012
108	December 2011
60	November 2011
97	October 2011
50	September 2011
46	August 2011
58	July 2011
47	June 2011
91	May 2011
35	April 2011
61	March 2011
9	February 2011
26	January 2011
51	December 2010
42	November 2010
146	October 2010
107	September 2010
155	August 2010
24	July 2010
27	June 2010
41	May 2010
44	April 2010
54	March 2010
232	February 2010
57	January 2010
33	December 2009
137	November 2009
120	October 2009
39	September 2009
24	August 2009
86	July 2009
27	June 2009
27	May 2009
91	April 2009
168	March 2009
60	February 2009
92	January 2009
114	December 2008
75	November 2008
205	October 2008
126	September 2008
123	August 2008
130	July 2008
29	June 2008
37	May 2008
38	April 2008
60	March 2008
63	February 2008
58	January 2008
160	December 2007
281	November 2007
109	October 2007
87	September 2007
149	August 2007
37	July 2007
76	June 2007
41	May 2007
43	April 2007
191	March 2007
146	February 2007
69	January 2007
39	December 2006
110	November 2006
92	October 2006
71	September 2006
95	August 2006
72	July 2006
148	June 2006
44	May 2006
33	April 2006
152	March 2006
123	February 2006
48	January 2006
67	December 2005
140	November 2005
130	October 2005
97	September 2005
46	August 2005
138	July 2005
96	June 2005
199	May 2005
36	April 2005
98	March 2005
111	February 2005
90	January 2005
74	December 2004
81	November 2004
76	October 2004
70	September 2004
200	August 2004
99	July 2004
57	June 2004
41	May 2004
161	April 2004
157	March 2004
192	February 2004
103	January 2004
67	December 2003
152	November 2003
239	October 2003
60	September 2003
50	August 2003
126	July 2003
78	June 2003
62	May 2003
53	April 2003
81	March 2003
206	February 2003
90	January 2003
46	December 2002
63	November 2002
109	October 2002
56	September 2002
54	August 2002
72	July 2002
66	June 2002
200	May 2002
68	April 2002
1	September 2000

Re: dhcwg Digest, DHCP Renew vs Confirm

Re: dhcwg Digest, DHCP Renew vs Confirm

Re: review of draft-ietf-geopriv-dhcp-lbyr-uri-option

Re: review of draft-ietf-geopriv-dhcp-lbyr-uri-option

Re: dhcwg Digest, DHCP Renew vs Confirm

Re: 答复： Re: dhcwg Digest, DHCP Renew vs Confirm

Fwd: I-D Action: draft-lemon-dhc-dns-pd-00.txt

FW: New Version Notification for draft-yeh-dhc-dhcpv6-authorization-opt-00.txt

about draft-ietf-dhc-dhcpv4-over-ipv6-00.txt

Fwd: Last Call: <draft-ietf-savi-dhcp-12.txt> (SAVI Solution for DHCP) to Proposed Standard