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

["Woundy, Richard" <[e-mail]>]

>Do you think it's ok that client might update information if a server
becomes unreachable?

If the application server is down for network connectivity issues, and if
the DHCPv6 server could only point to this application server which is down,
and if there are now several hundred/thousand clients that want to reach the
application server and cannot... Do you really want these several
hundred/thousand clients to query the DHCPv6 server at once, to get no
useful information???

-- rich

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Stig Venaas
Sent: Wednesday, August 25, 2004 11:16 AM
To: [e-mail]
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.


|              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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg

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