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

|              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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg