Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02

From: Stig Venaas <[email-masked]>
Date: Wed, 25 Aug 2004 17:15:59 +0200

I've tried to update the text based on all the suggestions and
comments received. I may still try to improve the language, but
please read the text below and let me know if you have problems
with what it says. Lines from the draft are prefixed by "|". I
have some comments/questions inline. I'm hoping that we can come
to agreement on the text in 1-2 weeks, so that I can finalize
version 02, which then hopefully can go to WGLC.

|              Information Refresh Time Option for DHCPv6

What do you think of this name? I think the problem with just
"refresh time option" is that it sounds more like an option for
refreshing time...

|Abstract
|
|  This document describes an option for specifying an upper bound for
|  how long a client should wait before refreshing information retrieved
|  from DHCP.  It's useful for stateless DHCPv6 where there are no
|  addresses or other entities with lifetimes that can tell the client
|  when to contact the DHCP server to refresh its configuration.

|1. Introduction
|
|  DHCPv6 [RFC 3315] specifies stateful autoconfiguration for IPv6
|  hosts.  However, many hosts will use stateless autoconfiguration as
|  specified in [RFC 2462] for address assignment, and use DHCPv6 only
|  for other configuration data.  This other configuration data will
|  typically have no associated lifetime, hence there may be no
|  information telling a host when to refresh its DHCP configuration
|  data.
|
|  This option may be useful in unstable environments where unexpected
|  changes are likely to occur, or for planned changes, including
|  renumbering where an administrator can gradually decrease the value
|  as the event nears.
|
|  It may also be useful to allow the client to detect within an
|  appropriate amount of time when a specific service change has been
|  made, e.g. the addition of a new NTP server, or a change of address
|  of a DNS server within the local network.  See [RENUMREQS] for
|  further details.

|3. Information refresh time option definition
|
|  The information refresh time option specifies an upper bound for how
|  long a client should wait before refreshing information retrieved
|  from DHCP.  It's only used for replies to Information-request
|  messages.  In other messages there will usually be other options that
|  indicate when the client should contact the server, e.g. addresses
|  with lifetimes.
|
|  Note that it's only an upper bound.  If the client has any reason to
|  make a DHCP request before the refresh time expires, it should
|  attempt to refresh all the data.
|
|  There are a number of potential reasons for the client to contact the
|  server before the refresh time expires.  One reason might be other
|  options that have some associated lifetime that is shorter than the
|  refresh time.  Other reasons might be a new IPv6 prefix announced by
|  a router, or that a server becomes unreachable on the address learnt
|  from DHCP.  The client may also determine that it needs to request
|  additional options.

Do you think it's ok that client might update information if a server
becomes unreachable? Say you learn DNS or NTP server address from DHCP,
and at some point the resolver or NTP client determines that it can't
reach the server. Would it then be ok to make the dhcp client request
new data? An issue might be that if a server goes down, thousands of
clients may try to update their DHCP config almost simultaneously...
I'm only trying to give an example though, but is it a good one?

|  Note that this also means that it doesn't make sense to have
|  different refresh time options for different data, since when the
|  client has reason to refresh some of its data, it should also
|  refresh the remaining data.
|
|  The expiry of the refresh time in itself does not in anyway mean that
|  the client should remove the data.  The client should keep it's
|  current data while attempting to refresh it.  The client is however
|  free to fall back to other mechanisms if it cannot refresh the data
|  within a reasonable amount of time.
|
|  In some cases the client uses a default refresh time IRT_DEFAULT.
|  The recommended value for IRT_DEFAULT is 86400 (24 hours).  The
|  client implementation should allow for this value to be configured.

What do you think of 24 hours? I've got suggestions for 1, 6-12, at
least 12 hours and more from you.

|3.1. Client behaviour
|
|  A client MUST include this option in the Option Request Option (ORO)
|  when sending Information-request messages to the DHCP server.  A
|  client MUST NOT include this option in the ORO in any other messages.
|
|  If the reply to an Information-request message does not contain this
|  option, the client MUST behave as if the option with value
|  IRT_DEFAULT was provided.
|
|  A client MUST also use the default refresh time IRT_DEFAULT if it
|  receives the option with value less than 600.

Do you agree with a minimum like this? It should make it harder to
do bad things, and I don't see a use for <10 minutes. If <600,
would you rather use 600 than IRT_DEFAULT?

|  If a client contacts the server to obtain new data or refresh some
|  existing data before the refresh time expires, then it SHOULD also
|  refresh all data covered by this option.
|
|  When the client detects that the refresh time has expired, it SHOULD
|  try to update its configuration data by making a new DHCP request as
|  follows.
|
|  Before making the request it MUST wait for a random amount of time
|  between 0 and INF_MAX_DELAY.  INF_MAX_DELAY is defined in [RFC 3315].
|  Note that this delay is in addition to the rules specified in [RFC
|  3315].
|
|  Then it can make the DHCP request to update the configuration.  The
|  message MUST be created and transmitted according to [RFC 3315].  For
|  an Information-request message it must be done according to the rules
|  for creation and transmission of Information-request messages in
|  section 18.1.5 of [RFC 3315].

We could perhaps say clearly that it must send Information-request.

I think there's one thing we should discuss that is related to this.
What if client at some point determines that it wants to request an
address (switch to stateful mode). Then we should perhaps say that
client should also refresh this data and forget the previous refresh
time. What if it makes a request but does not get a reply with new
data? Perhaps it should only forget refresh time when it gets new
data, so that it can keep using it if not?

|3.2. Server behaviour
|
|  A server sending a reply to an Information-request message SHOULD
|  include this option if it's included in the ORO of the request.  It

Do you agree with SHOULD, or do you want MUST? My thinking is that
server should allow the refresh time to be configured, and probably
have IRT_DEFAULT as the default value (although some servers may
prefer some other default, e.g. if made for us in a specific
environment). Rather than sending the value IRT_DEFAULT it might
just as well not include it.

Do you think we should talk about this being configurable on the
server and server default, or is it all pretty obvious and better
left to the implementation?

|  MUST NOT be included if it's not in the ORO of the request.

Is this ok? There's no harm in including it, but it's totally
pointless since we require client to include it in ORO, so if
not in the request, the client will ignore it.

|  When server sends a message that is not a reply to an Information-
|  request message, it MUST NOT include the option.

It would be sufficient to say that it's only to be included if
requested by client, since client MUST ONLY request it in
Information-request messages. So this paragraph could be omitted.

|  The option value MUST be no less than 600.

Stig

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 26 Aug 2004 08:10:09 -0400

Hi Stig:

Comments below, in line prefixed by "BV>".

You don't document the format of the option? But, this is just a portion of
the text?

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Stig Venaas
> Sent: Wednesday, August 25, 2004 11:16 AM
> To: [email-masked]
> Subject: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02
> 
> 
> I've tried to update the text based on all the suggestions 
> and comments received. I may still try to improve the 
> language, but please read the text below and let me know if 
> you have problems with what it says. Lines from the draft are 
> prefixed by "|". I have some comments/questions inline. I'm 
> hoping that we can come to agreement on the text in 1-2 
> weeks, so that I can finalize version 02, which then 
> hopefully can go to WGLC.
> 
> 
> "refresh time option" is that it sounds more like an option 
> for refreshing time...
> 
> |Abstract
> |

BV> "It is used with stateless DHCPv6 as there are no"

> | for other configuration data.  This other configuration data will  

BV> Add reference to [RFC 3736]?

> | from DHCP.  It's only used for replies to Information-request  

BV> "It is only used in Reply messages in response to Information-Request"

> Do you think it's ok that client might update information if 
> a server becomes unreachable? Say you learn DNS or NTP server 
> address from DHCP, and at some point the resolver or NTP 
> client determines that it can't reach the server. Would it 
> then be ok to make the dhcp client request new data? An issue 
> might be that if a server goes down, thousands of clients may 
> try to update their DHCP config almost simultaneously... I'm 
> only trying to give an example though, but is it a good one?

NO. Like Rich, I think this would be an extremely bad idea. Let's remove it.

I'd replace the two above paragraphs with:

  The Information Refresh Time option's time is an upper bound as to when
  the client SHOULD refresh its configuration information. A client MAY
  refresh this information before this time, such as if one or more
  prefixes for addresses in the configuration information expire.

> | client has reason to refresh some of its data, it should 
> also  refresh 
> | the remaining data.

I'd reword this to simply state that there is ONE time for all configuration
data.

> What do you think of 24 hours? I've got suggestions for 1, 
> 6-12, at least 12 hours and more from you.

I like 24 hours.

> | client MUST NOT include this option in the ORO in any other 

Perhaps: "If a client supports this option, it MUST ..."

> Do you agree with a minimum like this? It should make it 
> harder to do bad things, and I don't see a use for <10 
> minutes. If <600, would you rather use 600 than IRT_DEFAULT?

As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a
parameter?

> I think there's one thing we should discuss that is related 
> to this. What if client at some point determines that it 
> wants to request an address (switch to stateful mode). Then 
> we should perhaps say that client should also refresh this 
> data and forget the previous refresh time. What if it makes a 
> request but does not get a reply with new data? Perhaps it 
> should only forget refresh time when it gets new data, so 
> that it can keep using it if not?

Let's not mention this. Clients should always request this other conf. info.

> | include this option if it's included in the ORO of the request.  It

BV> "if it is".

> 
> Do you agree with SHOULD, or do you want MUST? My thinking is 
> that server should allow the refresh time to be configured, 
> and probably have IRT_DEFAULT as the default value (although 
> some servers may prefer some other default, e.g. if made for 
> us in a specific environment). Rather than sending the value 
> IRT_DEFAULT it might just as well not include it.

BV> If configured in the server, the server MUST return it (if requested). I
do not think the server should treat this option specially - such as supply
a default if not configured.

> 
> Do you think we should talk about this being configurable on 
> the server and server default, or is it all pretty obvious 
> and better left to the implementation?
> 

BV> Pretty obvious.

> not in the request, the client will ignore it.

BV> No, drop it. A server is always free to include any other options it
wants. If a client doesn't support it, it will ignore it.

> It would be sufficient to say that it's only to be included 
> if requested by client, since client MUST ONLY request it in 

BV> I'd drop it. If a client were to include this option in an ORO for a
non-Information-Request message, and it was configured in the server, the
server might return it (again, want to avoid special code in the server) and
I think that is OK. The client is wrong but so what - what the client might
do with this time is unknown but since it is broken, do we really care? Fix
the client.

> |  The option value MUST be no less than 600.

BV> I'd leave this to the client.

---

From: Tim Chown <[email-masked]>
Date: Fri, 27 Aug 2004 09:34:06 +0100

>   prefixes for addresses in the configuration information expire.

That sounds fine to me.  
 
> I'd reword this to simply state that there is ONE time for all configuration

Also fine by me.  Less is more :)
 
> > 6-12, at least 12 hours and more from you.

The value will depend on the environment.  I think if the admin knows the
environment is one liable to be changed, they will make active use of this
timer, if not, then it'll be a typical (relatively) static environment in
which case 24 hours would be ample.   In the event of a major change, the
admin can ramp it down.
 
> As I suggested it, I like it. Perhaps we should specify IRT_MINIMUM as a

I think this is an interesting suggestion.  Again, it depends on the
environment.  If it's a renumbering event, and a document like Fred Baker's
without-a-flag-day draft is followed, the minimum value can certainly be 
higher than 10 minutes.   One would assume in that type of renumbering
environment the old and new prefixes coexist for some time.   If a DNS
or NTP server is being turned off/phased out, then the replacement should
be made available in advance.   The awkward case is where there is a
sudden transition between (DNS, NTP, etc) servers or networks, but these
are I believe typically user, not administrator, driven.

Tim

---

From: Joe Quanaim <[email-masked]>
Date: Fri, 27 Aug 2004 08:54:09 -0400

> would you rather use 600 than IRT_DEFAULT?

I think a minimum is a good idea, but it probably should not be reset to 24 
hours.  That's probably not what an admin intended by setting the value that 
low.

Also, are 0 or 0xffffffff a special case like elsewhere in dhcpv6?  I am not 
sure it's necessary; I am just bringing up the point.

Thanks,
Joe Quanaim.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 31 Aug 2004 14:14:01 +0200

> hours.  That's probably not what an admin intended by setting the value that 

I agree sort of. For the protocol, I like the idea of totally ignoring
option with invalid value though, which means using the default. The
server implementation should perhaps give the administrator a warning,
or send 600 rather than the configured value.

We could also do what you suggest though. Other opinions?

> sure it's necessary; I am just bringing up the point.

I think it infinity could potentially be useful, but 0xffffffff is in
practice infinity anyway.

If we leave it out now, we can still add it later if we want.

Stig

---

From: Ted Lemon <[email-masked]>
Date: Tue, 31 Aug 2004 09:46:07 -0700

> We could also do what you suggest though. Other opinions?

There are cases where if any low value for this option is sent out over 
and over again by the server, it will cause operational problems.   But 
this isn't something we can easily prevent without being too 
restrictive, and I think you have to be really well-placed on a network 
(i.e., on the DHCP server's network) to get much amplification out of a 
DoS attack based on this.   In fact, when I think of how to come up 
with such a DoS attack, it seems like it would actually be very 
difficult.   So I think the real risk here is that the server 
administrator will configure a too-low value, so I think the right way 
to address this is to say that servers SHOULD warn the server 
administrator through an appropriate mechanism if the administrator 
tries to configure a too-low value for this option.

I think if you try to specify this on the protocol level, you're just 
making needless trouble for yourself, and not getting any benefit from 
it.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 31 Aug 2004 21:26:50 -0400

Stig:

I agree with Ted (in response to your message) that the server SHOULD warn
if the time is below the minimum.

I don't agree with you that the client should just ignore the option if the
value is below the minimum - it should use the minimum.

I'd follow the convention used in RFC 3315 to declare 0xffffffff as
infinity. 0 isn't special - though as it is below the minimum, the minimum
would be used.

- Bernie

> Sent: Tuesday, August 31, 2004 8:14 AM
> To: Joe Quanaim
> Cc: [email-masked]
> Subject: Re: [dhcwg] Attempt at text for draft-ietf-dhc-lifetime-02
> 
> 
> harder to 
> > > do bad things, and I don't see a use for <10 minutes. If 
> <600, would 
> > > you rather use 600 than IRT_DEFAULT?
> > 
> > I think a minimum is a good idea, but it probably should 
> not be reset 
> > to 24
> I agree sort of. For the protocol, I like the idea of totally 
> ignoring option with invalid value though, which means using 
> the default. The server implementation should perhaps give 
> the administrator a warning, or send 600 rather than the 
> configured value.
> 
> > Also, are 0 or 0xffffffff a special case like elsewhere in 
> dhcpv6?  I 
> > am not
> I think it infinity could potentially be useful, but 
> 0xffffffff is in practice infinity anyway.
>