Subject: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 03 Aug 2004 10:52:42 +0900

Hoping it's not too late, here a couple of comments (or questions,
actually) on the draft.

1. I'm still not really sure what the client should do for information
   when a lifetime expires.

   For example, the draft says in Section 3.1 that

     If client has received a lifetime with this option, and contacts
     server to receive new or update any existing data prior to its
     expiration, it SHOULD also update data covered by this option.  If no
     new lifetime is received, it MUST behave as if no value was ever
     provided.

  I don't understand the scenario.  Does this mean the following case?

  - The client sends an Information-request message, and gets a reply
    with a DNS server address (call it X) with lifetime of 1 hour.
  - 30 minutes later, the client happens to resend an
    Information-request message.  This time, it gets a response, but
    the response does not contain either DNS server address X or a new
    lifetime.

  If this is an intended scenario, then what does "behave as if no
  value was ever provided"?  Does it mean the client MUST treat
  address X as if it had infinite lifetime?  Or does this mean the
  client MUST regard address X expired immediately?  Or something
  else?

  Also, I don't understand what the client should do with DNS server
  address X when the lifetime expires and the client does not get any
  reply for the try to update the information.  Should the client
  invalidate address X?  Can/should it continue to use it?

  Even if the client can update the information of address X with a
  new lifetime, how can we regard the period from the time when the
  previous lifetime expires and the time when the client gets the new
  information?  Should we temporarily invalidate the address during
  the update period?  Or Can we continue to use it?  Probably the
  latter makes sense when the client can update the information, but
  it does not really match my intuition of "expiration"...
  
2. the usage of the lifetime option for other exchanges than
   Info-req/Reply exchanges.

   I'm even not 100% sure if the lifetime can be used for the other
   types of exchanges.  Probably it can according to the draft, but
   then I'll have several questions on how to use it.

   For example, the draft says:

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

  Is this also applies to the other cases even if INF_MAX_DELAY is a
  dedicated parameter for Info-req?  If so, is it really valid?

  Also, how does the client exactly react to the expiration event for
  the other cases?  For example, consider the following scenario:

  - the client performs Solicit->Advertise->Request->Reply exchanges,
    and gets an IPv6 address allocated, a DNS server address X, and an
    associated lifetime T.
  - before the timeout "T1" for the allocated address passes, lifetime
    T expires.  In this case, should the client restart the entire
    session from Solicit?  Or should the client send a renew message?
    If so, the renew message also tries to update the allocated
    address even if it's too early?  Or should the client even start
    Information-request/Reply exchanges just to update the DNS address
    information?

As an implementor, it's very hard to implement this option with
confidence just from this specification...

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 3 Aug 2004 05:33:57 +0200

>   client MUST regard address X expired immediately?  Or something

I'm open for anything. But my intention is that client behaves as if
it didn't get a lifetime in the first place. That is, just like it would
behave if it doesn't know a specific lifetime. Whether it's infinite or
not, depends on the client.

I don't think this scenario will be common anyway, but we should say
something. My thinking is that the last response is the authoritative
one, so new lifetime value overrides the old, and no lifetime means
ignore the old and behave like you haven't ever seen one.

Another option would be to keep using the last seen lifetime until
expiry, but I'm not sure that's better.

Very happy to see suggestions for alternative behaviour, or for text
changes that makes it more clear.

>   invalidate address X?  Can/should it continue to use it?

I think it can be left to the client. The client will retry for a long
period of time, and would usually get updated info; the lifetime simply
says when to start this process. So you're talking about a rare failure
case. I think it's sensible to keep using the info, at least if there
is nothing to fall back to.

I'm thinking of the option as a hint to the client when it should try
to update the info. I'm not sure if we need to specify the failure
modes in detail.

>   it does not really match my intuition of "expiration"...

My intention is definitely that you should continue using it. I guess
that should be made clear.

>     Information-request/Reply exchanges just to update the DNS address

I agree, this needs more thought. So first question is whether we should
support stateless only. Stateless is what I'm focusing on, but when I
wrote it I thought it could also be of use for stateful case. As it says,
the option only specifies a lifetime for options that don't have an
associated lifetime. I think doing Information-request/Reply exchange just
to update the DNS address information is fine, but would it be a problem
to renew everything?

> confidence just from this specification...

Right. I think this is very good input. I would like to get more input
on which behaviour people think is best. Then I'll try to make the text
clearer.

Stig

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Aug 2004 22:43:07 -0700

I think that we should specify what a client should do when it isn't 
given a lifetime option, rather than leaving it to the implementor.   I 
would pick a number - say an hour - and recommend that as a default 
value when no lifetime has been given.   I would require that this be 
configurable on the client.   We should make sure that there isn't some 
corner case where a network administrator that wants a really long 
lifetime doesn't get hosed by the default value, but I don't think it's 
okay to just leave it unstated.

Sorry for not saying this sooner - I was dithering over whether to make 
a point of it, and when Jinmei Tatuya stepped in with his observations, 
that gave me a good excuse to kibbitz.   :')

---

From: Joe Quanaim <[email-masked]>
Date: Tue, 3 Aug 2004 09:33:29 -0400

JINMEI Tatuya / 神明達哉 wrote:
[...]
>   dedicated parameter for Info-req?  If so, is it really valid?

Isn't this duplicating rfc 3315?  Removing it would prevent any subsequent 
updates to rfc 3315 from conflicing with this statement.

>     Information-request/Reply exchanges just to update the DNS address

Using this option in a stateful transaction makes things more complicated.  
The lifetime option can expire between t1, t2, or the valid lifetime of an 
address.  As Jinmei Tatuya notes, what should the client be expected to do?  
Restart the message exchange; just do an information-request; etc.

Any negotiated value for t1, t2, or valid lifetime of an address could take 
precedence over the lifetime option.  This essentially makes the option 
stateless only, but it simplifies the resulting changes to a client 
implementation.

Joe Quanaim.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 3 Aug 2004 17:28:15 +0200

> okay to just leave it unstated.

First, if the option is implemented by both client and server, I would
expect it to always be used.

One hour sounds rather short to me, normally I would expect several days
between each change. Question is then how bad it is if there is a change
and it takes some time before the client learns of it. But why wouldn't
you use this option if you worry about that. I would expect most servers
to support this option...

I think I would choose 6 hours or something as default, but that's just
my personal feeling.

Stig

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Aug 2004 09:49:45 -0700

IMHO, this draft should be folded into any future update of RFC3315.   
So it's okay to contradict 3315 if that is the correct thing to, 
although we shouldn't do it gratuitously.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 3 Aug 2004 13:20:22 -0400

I too would recommend that this option only be used with stateless
(Information-Request/Reply). It does not apply to stateful - in stateful,
even if there are no T1/T2 times (i.e., no IA_NA option), the client will
need to do something when it no longer has addresses so it will get new
information from the server.

When the lifetime expires, the client should simply initiate an
Information-Request message to the server(s). It should retry this 'forever'
based on the Information-Request retransmission policy specified in RFC 3315
(see 18.1.5). When a (valid) REPLY is received, the client should remove its
existing information and install the new information. If it doesn't receive
a (valid) REPLY, it keeps its existing information.

I too would support a default lifetime if no lifetime option is received. 6
to 12 hours seems a more reasonable value to me than 1 hour.

Note also that I believe the lifetime is just one input ... The DHCP client
can use other information, such as expiration of prefixes for configured
items, to decide whether to refresh information (though this would require
the DHCP client to poll the system periodically or when certain events occur
which may or may not be practical).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Joe Quanaim
> Sent: Tuesday, August 03, 2004 9:33 AM
> To: JINMEI Tatuya / ???? ; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
>
>
>

---

From: Stig Venaas <[email-masked]>
Date: Wed, 11 Aug 2004 12:36:22 +0200

On Tue, Aug 03, 2004 at 09:33:29AM -0400, Joe Quanaim wrote:
> 
> JINMEI Tatuya / ???????????? wrote:
> [...]

So what you're saying is that should say 1 sec, rather than
INF_MAX_DELAY? Or are you saying that shouldn't specify random delay
at all?

At first I didn't see the need for random delay since there is one
prior to the first information request according to rfc 3315, but as
someone said it might be required. If for instance the client checks
for expired lifetime every second or less often.

> stateless only, but it simplifies the resulting changes to a client 

I'm happy with this. If anyone got other opinions, please speak up.
I'll mail text suggestion soon,

> Joe Quanaim.

Thanks,

Stig

---

From: Joe Quanaim <[email-masked]>
Date: Wed, 11 Aug 2004 09:55:04 -0400

Stig Venaas wrote:
> > Isn't this duplicating rfc 3315?  Removing it would prevent any
> > subsequent updates to rfc 3315 from conflicing with this statement.
>

Ok.  I felt like the entire statement was repeating rfc 3315 and could be 
removed.  Looking again, I think you are trying to differentiate between the 
first info request (which 3315 dictates) and enforce the INF_MAX_DELAY for 
subsequent info requests after a lifetime expires.  I am okay with that.  I 
would have considered this to be a new exchange and therefore under the 3315 
guidelines, but having it spelled out does not hurt.

Also, if a client is checking for an expired lifetime every second, that's a 
problem.  Perhaps we should add a statement saying that a client should not 
recheck lifetimes without waiting a period of at least half the received 
lifetime.  It would need to be should instead of must to allow client reboots 
and such, but it would at least make bombarding a server with requests 
inappropriate behavior.

> > Using this option in a stateful transaction makes things more
> > complicated. The lifetime option can expire between t1, t2, or the valid
> > lifetime of an address.  As Jinmei Tatuya notes, what should the client
> > be expected to do? Restart the message exchange; just do an
> > information-request; etc.
> >
> > Any negotiated value for t1, t2, or valid lifetime of an address could
> > take precedence over the lifetime option.  This essentially makes the
> > option stateless only, but it simplifies the resulting changes to a
> > client implementation.
>

I feel like this statement is sufficient for the current ia's: na, ta, and pd.

Thanks,
Joe Quanaim.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 11 Aug 2004 23:12:16 +0900

>>>>> On Tue, 3 Aug 2004 13:20:22 -0400, 
>>>>> "Bernie Volz" <[email-masked]> said:

> information from the server.

I tend to agree.  In addition to the above points, I'd like to point
out that in the stateful exchanges the server can initiate update by
Reconfigure - at least in theory.

					JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Aug 2004 11:31:21 +0200

> > information from the server.

I think stateless only might be too strict.

One example I have in mind is:

If a client sends a request message to obtain addresses and other config
options and it does not get any addresses but receives other config
data. Then the client may use those options and not make a
Request/Information-Request, right? You say client needs to do something
when it no longer has addresses, but if you have IPv4 addresses, and the
only IPv6 DHCP server says it has no addresses, then I think it's ok for
the client to just use what it got without switching to stateless mode,
and at some later point make a new Request, still not using stateless
mode.

How about saying this instead?:

   The lifetime option is mainly intended for Stateless DHCP service as
   specified in RFC 3736.  If the client receives IA Address options
   containing lifetimes, the lifetime option should be ignored.  The
   client should get updated configuration data from the server when it
   renews the addresses.

Another thing I'm wondering about is if T1, T2 are zero or infinity. I
think the lifetime option might make sense then. In 3315 it says:

   If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no
   T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind
   message, respectively, at the client's discretion.

If you get e.g. 0, it might be good to have some sort of lifetime for
the other data, and I guess you might then do renew/rebind when the
lifetime expires.

> Reconfigure - at least in theory.

Yes, if clients support it...

Stig

---

From: Joe Quanaim <[email-masked]>
Date: Thu, 12 Aug 2004 08:31:01 -0400

Stig Venaas wrote:
> > > (Information-Request/Reply). It does not apply to stateful - in
> > > stateful, even if there are no T1/T2 times (i.e., no IA_NA option), the
> > > client will need to do something when it no longer has addresses so it
> > > will get new information from the server.
>

I am not sure that the lifetime option is necessary when using stateful.  I 
would consider this example stateless because the client has not successfully 
negotiated any (IPv6) addresses.  Here I think you are right, though, a 
client should use the lifetime option.  If it has any addresses, I think it 
should ignore the lifetime option.

> the other data, and I guess you might then do renew/rebind when the

Even if T1 and T2 are zero or infinity, you have the lifetime of the address 
to fall back on.  RFC 3315 says:

   Note that an IA_NA has no explicit "lifetime" or "lease length" of
   its own.  When the valid lifetimes of all of the addresses in an
   IA_NA have expired, the IA_NA can be considered as having expired.

And says something similar for IA_TA's.  There is still an issue when the 
lifetime of the address is set to infinity, but this seems like a special 
case and one that might be used intentionally for one time configuration.

Joe Quanaim.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Aug 2004 14:40:31 +0200

[...]
> should ignore the lifetime option.

OK, I can agree with you if you define stateless that way. I'm thinking
of stateless as defined in RFC 3736 using only Information-Request/Reply.
My point is that it might be useful to use it with Request/Reply as well.

So, my suggested wording should be ok then I understand you correctly.

> case and one that might be used intentionally for one time configuration.

Right, sounds reasonable.

Thanks,

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 08:43:27 -0400

If a server sets the T1/T2 times to infinity, it gets what it asked for -
the configuration is static FOREVER. This is one reason it would be an
extremely bad idea to ever use these values. We added them for clarity in
the RFC, though never really figured they would be used in practice.

The no address issue is an interested one.

On a SOLICIT, the server is ONLY to return the Status Message response with
NoAddrAvail status. It is *NOT* supposed to return any configuration
information!!!

Though it is always possible that a subsequent REQUEST or RENEW/REBIND would
result in no addresses. However, in those cases the IA_NA is still returned
with T1 and T2 times and those would, IMHO, apply. (In these cases, the
NoAddrAvail status is embedded *INSIDE* the IA_* options so these options
are still returned.)

I suppose there is the case when a SOLICIT/REQUEST/RENEW/REBIND for an IA_NA
and IA_TA results in no addresses for a IA_NA and one or more addresses for
a IA_TA, in which case no T1/T2 times are provided - thought the IA_TA does
have lifetimes.

But, all of this gets very messy fairly quickly.

So, perhaps the easiest thing to do is to *ALWAYS* allow the LIFETIME option
- for stateful and stateless. A client *SHOULD* renew (etc) its information
whenver the shortest time expires - LIFETIME, T1, or lifetime on an address
(and the client needs a replacement address). If the client is stateful, is
uses RENEW (whether the client includes on or more IA_NAs if no T1 time has
expired is a matter of local policy - though it would seem reasonable for me
if it did since there's no harm in doing so). If a client is stateless, it
uses INFORMATION-REQUEST.

This also makes server implementations easier since the T1/T2 times and
"other-configuration-parameters" lifetime can be configured independently
and a server need not assure that no T1 time is greater than
"other-configuration-parameters".

- Bernie

> From: Joe Quanaim [mailto:[email-masked]] 
> Sent: Thursday, August 12, 2004 8:31 AM
> To: Stig Venaas; JINMEI Tatuya / ?$B?@L@C#:H
> Cc: [email-masked]; [email-masked]; Bernie Volz
> > On Wed, Aug 11, 2004 at 11:12:16PM +0900, JINMEI Tatuya / 
> ?$B?@L@C#:H 
> > wrote:
> > > > stateful, even if there are no T1/T2 times (i.e., no IA_NA 
> > > > option), the client will need to do something when it no longer 
> > > > has addresses so it will get new information from the server.
> >
> > If a client sends a request message to obtain addresses and other 
> > config options and it does not get any addresses but receives other 
> > config data. Then the client may use those options and not make a 
> > Request/Information-Request, right? You say client needs to do 
> > something when it no longer has addresses, but if you have IPv4 
> > addresses, and the only IPv6 DHCP server says it has no addresses, 
> > then I think it's ok for the client to just use what it got without 
> > switching to stateless mode, and at some later point make a new 
> > Request, still not using stateless mode.
>

---

From: Joe Quanaim <[email-masked]>
Date: Thu, 12 Aug 2004 09:10:40 -0400

> > >    client should get updated configuration data from the server when it

I think that this wording is good.

It does not intermix the lifetime option among the various possible t1, t2, 
and address lifetimes which I think complicates. 

Thanks,
Joe.

---

From: Stig Venaas <[email-masked]>
Date: Thu, 12 Aug 2004 15:10:34 +0200

> "other-configuration-parameters".

This is more in line with my original idea for lifetime. I've started
improving the draft, and I now have these paragraphs:

   The lifetime option specifies a lifetime for all configuration data
   contained in other options in an advertise or reply message that have
   no associated lifetime.  If any of the options have an associated
   lifetime of their own which is shorter than the lifetime option value,
   then that should take precedence.

   Or in other words, the lifetime option specifies an upper bound for
   how long the client should wait before attempting to renew the data.
   If there are options with a shorter lifetime or the client has other
   reasons for requesting data from the DHCP server, then it should also
   update the data covered by the lifetime option.

I think this should pretty much cover what you say and is in line with
my own thinking.

After that I have the paragraph:

   The lifetime option is mainly intended for Stateless DHCP service as
   specified in [RFC 3736].  If the client receives IA Address options
   containing lifetimes, the lifetime option should be ignored.  The
   client should get updated configuration data from the server when it
   renews the addresses.

Personally I'm happy to remove that again. I guess we should try to
come to some consensus before I do more writing.

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 09:53:01 -0400

>    client should get updated configuration data from the server when it

It confuses the issue.

Perhaps something like:

  The primary motivation for the lifetime option is for situations where
  no lifetime (or renewal time) is communicated to the client, such as for
  Stateless DHCP service as specified in [RFC 3736]. However, it applies
  to both stateful and stateless DHCP clients and is an upper bound for
  when a client should initiate renewal of at least its non-address based
  configuration parameters - a stateful client MAY renew its addresses at
  the same time and SHOULD always get updated configuration data from the
  server when it renews any addresses.

  One difference between Stateful and Stateless clients with regards
  to this option is that a Stateful client that does not receive this
  option MUST NOT apply the default lifetime. 

- Bernie

> From: Stig Venaas [mailto:[email-masked]] 
> Sent: Thursday, August 12, 2004 9:11 AM
> To: Bernie Volz
> Cc: [email-masked]; 'JINMEI Tatuya / ?$B?@L@C#:H'; 
> [email-masked]; [email-masked]
> > If a server sets the T1/T2 times to infinity, it gets what it asked 
> > for - the configuration is static FOREVER. This is one 
> reason it would 
> > be an extremely bad idea to ever use these values. We added 
> them for 
> > clarity in the RFC, though never really figured they would 
> be used in 
> > practice.
> > 
> > On a SOLICIT, the server is ONLY to return the Status 
> Message response 
> > with NoAddrAvail status. It is *NOT* supposed to return any 
> > configuration information!!!
> > 
> > Though it is always possible that a subsequent REQUEST or 
> RENEW/REBIND 
> > would result in no addresses. However, in those cases the IA_NA is 
> > still returned with T1 and T2 times and those would, IMHO, 
> apply. (In 
> > these cases, the NoAddrAvail status is embedded *INSIDE* the IA_* 
> > options so these options are still returned.)
> > 
> > I suppose there is the case when a 
> SOLICIT/REQUEST/RENEW/REBIND for an 
> > IA_NA and IA_TA results in no addresses for a IA_NA and one or more 
> > addresses for a IA_TA, in which case no T1/T2 times are provided - 
> > thought the IA_TA does have lifetimes.
> > 
> > So, perhaps the easiest thing to do is to *ALWAYS* allow 
> the LIFETIME 
> > option
> > This also makes server implementations easier since the T1/T2 times 
> > and "other-configuration-parameters" lifetime can be configured 
> > independently and a server need not assure that no T1 time 
> is greater 
> > than "other-configuration-parameters".
> 
> This is more in line with my original idea for lifetime. I've 
> started improving the draft, and I now have these paragraphs:
> 
> I think this should pretty much cover what you say and is in 
> line with my own thinking.
> 
> Personally I'm happy to remove that again. I guess we should 
> try to come to some consensus before I do more writing.
> 
> Stig
>

---

From: Joe Quanaim <[email-masked]>
Date: Thu, 12 Aug 2004 10:18:57 -0400

> >    client should get updated configuration data from the server when it

I would prefer leaving the paragraph.

>   option MUST NOT apply the default lifetime.

As noted, the motivation of the lifetime option is to ensure stateless clients 
receive current configuration information.  As such, I think keeping it out 
of stateful configuration is the simplest approach.  As we have discussed, 
stateful configuration already has several variables to manipulate client 
behavior.  I do not see much gain in adding another.

Still, it's not that complex a change.  If I am outvoted, so be it.

Joe Quanaim.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 12:12:12 -0400

My impression is that people want it for stateful as well - or at least not
to restrict it from being used there.

I was where you are - keeping it for stateless only. But there are some edge
cases where stateful clients might not receive any times or might receive
extremely long times (though I think these are really exceptional cases).

I also think it is easier configuration wise to just allow an administrator
on a server to configure this option and not have code in the server not to
send this for a stateful REPLY (or on a client to ignore it). Though I guess
we could place the responsibility on the client not to include it in the ORO
when stateful.

So, I've changed my mind - allow it for stateful as well.

BTW, shouldn't we improve the langauge in the draft regarding the ORO? It is
currently:

3.1. Client behaviour

   A client supporting this option MAY include it in the Option Request
   Option (ORO) when sending messages to the DHCP server that allows ORO
   to be included.

I would suggest we change it to:

3.1. Client behaviour

   A client supporting this option MUST include it in the Option Request
   Option (ORO) when sending SOLICIT, REQUEST, RENEW, REBIND, and
   INFORMATION-REQUEST messages to the DHCP server.

If the consenus is to keep this for stateless only, then it would read:

3.1. Client behaviour

   A client supporting this option MUST include it in the Option Request
   Option (ORO) when sending INFORMATION-REQUEST messages to the DHCP
server.
   A client MUST NOT include this option in an ORO option in any other
   messages.

- Bernie

> Sent: Thursday, August 12, 2004 10:19 AM
> To: Bernie Volz; 'Stig Venaas'
> Cc: [email-masked]; [email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 16 Aug 2004 21:15:54 +0900

>>>>> On Thu, 12 Aug 2004 11:31:21 +0200, 
>>>>> Stig Venaas <[email-masked]> said:

> Request/Information-Request, right?

A quick response for clarification: if you mean the case where the
client receives an Advertise message containing a NoAddrsAvail status
code, I don't think the client may use other configuration options
(moreover, I don't think the client ever receives such configuration
options in this case).

RFC3315 is not so explicit in such a case, but it requires the client
just to ignore such an Advertise message:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.
(Section 17.1.3)

and the server to send minimum information to indicate the error:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an Advertise
   message to the client that includes only a Status Code option with
                                       ^^^^
   code NoAddrsAvail and a status message for the user, a Server
   Identifier option with the server's DUID, and a Client Identifier
   option with the client's DUID.
(Section 17.2.2)

Again, this is just for clarification, and may be irrelevant to the
main point of this discussion.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 17 Aug 2004 17:45:05 +0900

>>>>> On Thu, 12 Aug 2004 10:18:57 -0400, 
>>>>> Joe Quanaim <[email-masked]> said:

> behavior.  I do not see much gain in adding another.

It's not a strong opinion, but I'd also still prefer to restrict the
use of the lifetime option to the stateless case.  The reasons are:

- even if it might be true that the client can use stateful exchanges
  without having addresses or infinite T1/T2 timers for other
  configurations only, it should be a very minor case (I'm pretty sure
  that everyone agrees on this - whether still want to allow such
  usage or not).  In my understanding, the sense of RFC3315 is that
  "if you can get an address, you may get other information.  If you
  cannot get an address, then give up any possible information."  In
  fact, Section 18.1.8 says

    [...]  If the client receives no addresses in
    any of the IAs, it may either try another server (perhaps restarting
    the DHCP server discovery process) or use the Information-request
    message to obtain other configuration information only.

  but the RFC does not (explicitly) allow the client to continue to
  use other information configuration than addresses.  What you are
  going to achieve in the scenario of the lifetime option with the
  stateful case seems to contradict the original sense, IMO.

- recalling that we rejected the idea of multiple lifetime options for
  multiple configuration parameters, it's odd to me that we are now
  going to have T1/T2 as well as the lifetime option (I was happy with
  rejecting the idea of multiple lifetimes, BTW).  If we applied the
  same logic, we could simply use an appropriate T1 value to implement
  controlled update of the other configuration information.  Again,
  it's true that stateful exchanges can provide no finite timers,
  but, as I said in the above bullet, it's very minor or even
  almost-unexpected use case in my understanding.

- as I pointed out in my first message, we'll have to define all the
  details, most of which are boring corner cases (but the implementors
  would be unhappy if we didn't define those).  I know some of you are
  now trying to address those, and trying to minimize the complexity
  of the specification.  However, right now I'm not sure if it really
  makes sense, considering the usage case of stateful+lifetime is
  minor.  I admit this is a tradeoff issue, and perhaps we need to
  end up discussing details to make a clear consensus.

- one thing I'm concerned about which is related to the above point:
  there is already a non-address IA that has a notion of timeout:
  IA_PD.  So, we'll probably have to consider the combination of IA_PD
  and the lifetime option.  Moreover, the lifetime option document may
  need to be generic enough to prepare for any future stateful
  resources that has a notion of timeout.

> Still, it's not that complex a change.  If I am outvoted, so be it.

Same here.  Though I'm still skeptical about the benefit of the use
case of stateful+lifetime, considering the possible complexity, I can
live with that if the specification is crystal clear about all the
details.

					JINMEI, Tatuya

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Aug 2004 13:47:28 +0200

> use of the lifetime option to the stateless case.  The reasons are:

I think we should come to a decision and proceed. I've given this some
more thought, and personally I don't mind restricting it to stateless.
I'm not sure I like using the term stateless though.

I suggest saying that the option should only be used in replies to
Information-Request messages. This solves the stateless renumbering
issue we set out to solve.

>   almost-unexpected use case in my understanding.

I agree with this. At least it's my understanding that when renewing
the address the client should also update other info.

>   end up discussing details to make a clear consensus.

Yes, it might be just corner cases. I guess the scope of the option
could be expanded later if needed. It's better to do that later, than
possibly making the scope too large now.

>   resources that has a notion of timeout.

Right.

> live with that if the specification is crystal clear about all the

I must say I don't quite understand why it is so difficult. OTOH it
seems I have some problems explaining clearly how I think it should
work, so perhaps it is complex after all (;

Well, are you happy with limiting it to replies to Information-Request
then? Has anyone got big problems with that? If there are no major
objections I'll propose some text to you, to make sure we are in
agreement.

Thanks for all the input. I hope to go through the issues, proposing
text and hopefully have concencus on how to resolve it so that I can
put out a new and hopefully final version soon.

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 20 Aug 2004 08:44:14 -0400

I'm OK to restricting the Lifetime Option to replies to
Information-Request's.

The client MUST ignore a Lifetime Option that is in any message other than a
REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
Option number in an ORO except when sending an INFORMATION-REQUEST message.

The server MUST NOT include the Lifetime Option in any message other than a
REPLY to an INFORMATION-REQUEST.

- Bernie

> Sent: Friday, August 20, 2004 7:47 AM
> To: JINMEI Tatuya / ?$B?@L@C#:H
> Cc: [email-masked]; [email-masked]; [email-masked]; Bernie Volz
> > >> The primary motivation for the lifetime option is for situations 
> > >> where no lifetime (or renewal time) is communicated to 
> the client, 
> > >> such as for Stateless DHCP service as specified in [RFC 3736]. 
> > >> However, it applies to both stateful and stateless DHCP 
> clients and 
> > >> is an upper bound for when a client should initiate 
> renewal of at 
> > >> least its non-address based configuration parameters - a 
> stateful 
> > >> client MAY renew its addresses at the same time and 
> SHOULD always 
> > >> get updated configuration data from the server when it 
> renews any 
> > >> addresses.
> > >> 
> I think we should come to a decision and proceed. I've given 
> this some more thought, and personally I don't mind 
> restricting it to stateless. I'm not sure I like using the 
> term stateless though.
> 
> I suggest saying that the option should only be used in 
> replies to Information-Request messages. This solves the 
> stateless renumbering issue we set out to solve.
> 
> I agree with this. At least it's my understanding that when 
> renewing the address the client should also update other info.
> 
> Yes, it might be just corner cases. I guess the scope of the 
> option could be expanded later if needed. It's better to do 
> that later, than possibly making the scope too large now.
> 
> I must say I don't quite understand why it is so difficult. 
> OTOH it seems I have some problems explaining clearly how I 
> think it should work, so perhaps it is complex after all (;
> 
> Well, are you happy with limiting it to replies to 
> Information-Request then? Has anyone got big problems with 
> that? If there are no major objections I'll propose some text 
> to you, to make sure we are in agreement.
> 
> Thanks for all the input. I hope to go through the issues, 
> proposing text and hopefully have concencus on how to resolve 
> it so that I can put out a new and hopefully final version soon.
> 
> Stig
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Aug 2004 15:24:51 +0200

> REPLY to an INFORMATION-REQUEST.

Right, sounds good. Thanks for the text.

This brings up another thing I want to discuss.

Is it actually useful for the client to include it in ORO at all?
Should the server really care?

I can think of basically three options. I'll be a bit vague on the
MAY/SHOULD/MUSTs for now.

1. Client may include it. If server sees option it should include
   it in reply. If server does not see it, it may include it anyway.

2. Client always includes it, and server only includes it in reply if
   client included it in request.

3. Client never includes it, and server always or never includes it
   depending on configuration.

It would be nice to come to agreement on which alternative is best
before trying to formalize things.

Personally I think alternative 3 makes sense.

That is, if a server implements the option and is configured with some
lifetime by the administrator, then it should always include it.

If it is not configured by the administrator, then it should not include
it, so that clients will just use the default.

Or do you see a problem with server including the option when client
doesn't implement it?

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 20 Aug 2004 09:53:31 -0400

YES! The client MUST include this in the ORO if it is interested in the
parameter. Ted discussed this on the mailing list a few weeks back - that
options really must be in the ORO. And, I do agree with him that this is the
best policy.

If I recall correctly, Ted stated that if a client "wants" an option, it
MUST include it in the ORO.

A server MUST return any options for which it has information if they are in
the ORO. A server MAY include other options that are not in the ORO BUT
there is NO requirement that it must do so.

Note that there are a few exceptions, such as Client-ID, Server-ID, IA_NA,
IA_TA, IAADDR, ... as these are protocol options.

So, by this rule, the client MUST include it in the ORO to assure it gets it
if configured and supported by the server.

- Bernie

> Sent: Friday, August 20, 2004 9:25 AM
> To: Bernie Volz
> Cc: 'JINMEI Tatuya / ?$B?@L@C#:H'; [email-masked]; 
> > The client MUST ignore a Lifetime Option that is in any 
> message other 
> > than a REPLY to an INFORMATION-REQUEST. A client MUST NOT 
> include the 
> > Lifetime Option number in an ORO except when sending an 
> > INFORMATION-REQUEST message.
> > 
> > The server MUST NOT include the Lifetime Option in any 
> message other 
> > than a REPLY to an INFORMATION-REQUEST.
> 
> Is it actually useful for the client to include it in ORO at 
> all? Should the server really care?
> 
> I can think of basically three options. I'll be a bit vague 
> on the MAY/SHOULD/MUSTs for now.
> 
> It would be nice to come to agreement on which alternative is 
> best before trying to formalize things.
> 
> 
> That is, if a server implements the option and is configured 
> with some lifetime by the administrator, then it should 
> always include it.
> 
> If it is not configured by the administrator, then it should 
> not include it, so that clients will just use the default.
> 
> Or do you see a problem with server including the option when 
> client doesn't implement it?
> 
> Stig
>

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Aug 2004 16:11:02 +0200

> MUST include it in the ORO.

I apologize for my ignorance, I don't know DHCP well enough. I found and
read Ted's mail now. I see how it simplifies server implementation.

I think I have enough input to propose new text for the draft now. I'll
post a proposal soon.

Thanks for your input and patience,

Stig

---

From: Joe Quanaim <[email-masked]>
Date: Fri, 20 Aug 2004 10:55:04 -0400

Bernie Volz wrote:
> The client MUST ignore a Lifetime Option that is in any message other than
> a REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime

This sounds good to me.

Also, did we reach consensus on a default value?  This seems like the 
appropriate place to mention it:

If a client requests a Lifetime Option and does not receive one in the reply, 
it should use the default value of n hours.

Or something to that effect...

Joe.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 20 Aug 2004 17:08:15 +0200

> Or something to that effect...

Yes, I've already written some text to that effect, it's not done.
What I have so far is:

   In some cases a default lifetime LT_DEFAULT is used.
   The recommended value for LT_DEFAULT is 21600 (6 hours).

I just took 6 out of the air, input needed.

and then under client behaviour:

   A client implementing this option MUST when a reply to an
   Information-Request message does not contain the option, behave
   as if the option with value LT_DEFAULT was provided.

   A client MUST also use the default lifetime LT_DEFAULT if the
   value of the option is zero.

   If client has received a lifetime with this option, and contacts
   server to receive new or update any existing data prior to its
   expiration, it SHOULD also update data covered by this option.
   If no new lifetime is received, it MUST use the default lifetime
   LT_DEFAULT.

I need to work a bit more on the text, but let me know if this is not
in line with what you think.

Stig

---

From: "Bernie Volz" <[email-masked]>
Date: Fri, 20 Aug 2004 12:44:38 -0400

While the load on a server for processing Information-Requests should be
relatively small, why use a default that is so short? This means that in a
typical working day (8 or more hours) while you've connected your laptop at
work, it will get the parameters when you first connect and at LEAST once
more.

If we're to believe there will be billions of IPv6 devices and a sizeable
fraction will use stateless, why have all of this DHCP traffic?

The lifetime mechanism MUST NOT be used in place of redundancy - if you're
only going to have one DNS resolving server, you're asking for trouble and
using this lifetime option to work aroud failures is NOT correct.

This information should generally be valid for LONG time periods unless a
site has an explicit need to refresh this information more frequently, in
which case the server should be configured with the desired value.

Personally I would like to see a DEFAULT lifetime of NOT LESS than 12 hours.
(Most operational network use a day to a week for lease times from my
expierence.)

Ask yourself what are typical LEASE times and cut these in half. Or, if you
have data on typical address LIFETIMES for IPv6 addresses, use these values.

And, remember we're specifying the DEFAULT. If a server administrator wants
to reduce this, she is free to do so.

I also believe we should, in order to prevent Denial-of-Service attacks or
"Information-Request" storms, specify a LOWER BOUND of something like 10
minutes.

And, the lifetime option shouldn't be the only trigger a client uses to
refresh this information. Connecting a network cable to the client,
significant changes in the prefixes active on the link, etc. are all other
considerations that a client SHOULD use to trigger refreshing this
information. The lifetime should only apply to very STATIC situations -
where the client isn't mobile and the network addresses don't change.

- Bernie

> Sent: Friday, August 20, 2004 11:08 AM
> To: Joe Quanaim
> Cc: Bernie Volz; 'JINMEI Tatuya / ?$B?@L@C#:H'; 
> > > The client MUST ignore a Lifetime Option that is in any message 
> > > other than a REPLY to an INFORMATION-REQUEST. A client MUST NOT 
> > > include the Lifetime Option number in an ORO except when 
> sending an 
> > If a client requests a Lifetime Option and does not receive 
> one in the 
> > reply,
> Yes, I've already written some text to that effect, it's not 
> done. What I have so far is:
> 
> I need to work a bit more on the text, but let me know if 
> this is not in line with what you think.
> 
> Stig
>

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 23 Aug 2004 16:52:10 +0900

>>>>> On Fri, 20 Aug 2004 08:44:14 -0400, 

> REPLY to an INFORMATION-REQUEST.

I'm happy with this (of course).

Alternatively, if someone feels it is too restrictive, I guess we
could also say the use of the lifetime option in
solicit/advertise/... exchanges is beyond the scope of the document.

This way we can implicitly tell implementors that they can only
concentrate on the usage for information-requests while leaving a
future possibility of extension.

(just a thought, not intending to introduce further confusion...)

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 23 Aug 2004 18:23:30 +0900

(Sorry for the delay in response)

I've changed the title since I'm concentrating on this particular
issue.

Instead of making a response to each sub-issue (attached below), let
me raise a more fundamental concern.

Perhaps I'm just pedantic, but the current behavior of the lifetime
option, however clearly it is defined, does not sound like a
"lifetime" that I would envision.  To me, if a lifetime of some
information expires, the information should be invalid (in some
sense).  But the current behavior described in dhc-lifetime-01 does
not seem to invalidate the information in any way; the "lifetime"
would rather seem like an "update timer" or something.

One obvious "fix" to this is to change the option name to something
like "Information Update Timer" option (too long?).

However, I personally would like to leave the possibility of
invalidating the information on lifetime expiry.  With this sense I'd
imagine something like this:

- the option name ("lifetime option") is the same
- the client starts re-sending Information-Requests at some point in
  time to the expiration.  (e.g. a half of the lifetime)
- even if the clients cannot get a response by the expiration, it
  should continue sending Information-requests.  However, it can also
  invalidate the expired information in some way, e.g., by preferring
  a "last resort" default or by using other means of configuration.

What do others think?

					JINMEI, Tatuya

>>>>> On Tue, 3 Aug 2004 05:33:57 +0200,

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Aug 2004 10:28:12 -0400

>   a "last resort" default or by using other means of configuration.

Can you think of a real-world scenario where this would be the right 
thing to do?   I can't come up with one.   For example, if we wanted to 
fall back to some sort of link-local protocol, this wouldn't help us, 
because it would take too long.   I think that in just about any 
scenario where you'd think to benefit by switching to some other 
configuration scheme, the switch would happen much too late, using this 
mechanism, to be of any benefit.

So I think that we'd really be better off, as you suggest, renaming 
this the update timer.   If there's some other configuration mechanism 
to which we should fall back, I think we need another mechanism for 
deciding when to fall back to it, and that should probably be specified 
in the draft that describes the fallback mechanism.

---

From: Joe Quanaim <[email-masked]>
Date: Mon, 23 Aug 2004 10:45:02 -0400

>   a "last resort" default or by using other means of configuration.

I also noticed the difference in semantics for this option versus address 
lifetimes.

If the lifetime option means that any option associated with it is no longer 
valid at expiration, then a client needs to start the message exchange before 
the lifetime expires.  Otherwise, normal processing will leave a client 
system without critical information (probably dns) for a second or two under 
normal processing.

For example, when the lifetime expires, the options associated with it will be 
removed from system configuration by the client.  The client then restarts 
the message exchange including a delay for sending.  If all goes well, the 
client receives a response and updates the system.  During the exchange, most 
applications will have problems even if there have been no network changes.

If the lifetime option simply represents a timer to update the associated 
options, this problem goes away.  The previously configured values can remain 
in place while an exchange takes places.  After the exchange the system can 
be updated, if necessary.

I read the lifetime option as a timer.  I did it this way defensively, since 
it does not introduce (short lived) breakage.

Perhaps, as you suggested,  the better fix is to use half the lifetime option 
as a sort of t1 value.  This brings it inline with address lifetime 
semantics.  This would require some rewording of the draft.

Also, if this change is made, it is probably more important to specify a 
minimum lifetime value so that half the configured lifetime does not cause a 
significant change in network usage.  Bernie Volz has mentioned this already.

Thanks for bringing up this issue.

Joe.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 23 Aug 2004 17:10:21 +0200

> > like "Information Update Timer" option (too long?).

Yes, the term lifetime is a bit misleading. I'm open for
suggestions for other names.

> > imagine something like this:

I don't see why you would want that.

> system without critical information (probably dns) for a second or two under 

Yes, that is no good.

> semantics.  This would require some rewording of the draft.

I don't like this, sounds more complex than we need.
> Thanks for bringing up this issue.

I feel strongly that it should only tell the client when it should
try to update the info (like t1 I guess). But the client should
keep the info while it keeps trying to update the info. As I
understand the DHCP spec, it will keep retransmitting the
Information-Request indefinitely if necessary, which means that
the config data also might be kept indefinitely.

Of course there could be other reasons for the client to remove
configuration, the lifetime spec shouldn't prevent that either.
But that would be completely independent of the lifetime option.

The reason we want the option, is to have some control of when a
client tries to update its info. We're trying to solve problem
stated in the problem statement. The point is not to ensure
stateless info is removed at the host. Why would you want that?

I agree the name is misleading. The draft should make clear what
it is, but another name might help.

Stig

---

From: Tim Chown <[email-masked]>
Date: Mon, 23 Aug 2004 16:32:40 +0100

> in the draft that describes the fallback mechanism.

The original idea for the "timer", as documented in the stateless-renumbering
draft, was a "hint" for nodes to re-request information such that if there
was a renumbering event, or a change in DNS, NTP, etc servers, the 
(stateless) node could learn of them.   Without any timer, the node has
no standard mechanisms for this (it could do so on receipt of a new prefix
in an RA, but that doesn't cover new DNS servers being added).

So I think "update timer" may be better.

Is there any case for different behaviour for stateful and stateless
nodes (i.e. based on the method the node's address was obtained from)?

Tim

---

From: Joe Quanaim <[email-masked]>
Date: Mon, 23 Aug 2004 13:42:39 -0400

> the config data also might be kept indefinitely.

I agree with this sentiment.  If a client must remove configured information 
when the lifetime option expires, the client is punished.  A client that did 
not implement the lifetime option could continue to use configured 
information.  The option expiration is not necessarily indicative of a change 
in the network.

It sounds like all that is needed is a new name for this option.

Joe.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Aug 2004 11:22:09 +0200

On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote:
[...]
> It sounds like all that is needed is a new name for this option.

So let's try to find a new name. I think "update time option" is
one possibility. I don't like "update timer option" because this
is only a value to use for the timer, not the timer itself.

Another alternative is "refresh time option" perhaps?

I discussed it with a colleague, and we came up with alternatives
like "suggested refresh/update time option" or "refresh/update
within option". Not so sure about the last one, it tries to make
it clear that you might refresh/update before the specified time.

I think we should keep the name fairly short. We should have a
name that isn't misleading, but people will still have to read the
draft to understand exactly what it is.

Stig

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 24 Aug 2004 21:12:01 +0900

>>>>> On Mon, 23 Aug 2004 10:28:12 -0400, 
>>>>> Ted Lemon <[email-masked]> said:

> thing to do?   I can't come up with one.

The scenario I thought of is that if the "lifetime" of a DNS
(recursive) server expires with no update I'd stop using the server
and start a local recursive server daemon (e.g., run BIND named on my
laptop and specify ::1 in /etc/resolv.conf) as a last resort.  I'm
quite sure that this is a "real world" scenario because I, for one,
would like to have this feature and I'm living in the real world of
the Internet.  I admit this might be a niche demand though.

I can also think of a scenario where I'll then prefer information
from DHCPv4 (over the expired information from DHCPv6).  But I don't
know this makes sense in the real world.

Aside from the scenarios, I'm also concerned about a (possible)
pitfall with the "update timer" semantics.

Assume that we have a reply to Information-request containing a DNS
server address X with update timer (or lifetime) T.  T seconds later,
the client will restart Information-request/reply exchanges.  If we
then get a different DNS server address Y, we'll stop using the old
address X and switch to Y.  This should exactly be the "renumbering
scenario", and the behavior looks reasonable.  But what if the reply
does not contain any new DNS server address?  Can we still continue to
use address X, or will we then lose any usable DNS server address?

If the former is the intent, it seems a bit odd to me that the
behavior is different based on whether the replied set is empty or not
(at least the specification is not very clear on this).  If the latter
is the intent, doesn't it almost mean we invalidate the expired
information X?

Anyway...so far, others do not seem to be very happy with the idea of
invalidating expired information.  If the above explanation is still
not so convincing, I won't stick to the idea.  I can live with the
"update timer" semantics as long as the specification is clear enough
to implement.

					JINMEI, Tatuya

p.s. I'm afraid I won't be able to be very active on the list this
week.  I'd apologize in advance for future delay of my responses.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Aug 2004 15:26:50 +0200

> know this makes sense in the real world.

OK, I can see that. How about adding this:

The expiry of the lifetime 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.

It's a bit vague, but I don't think we should standardize every detail.

> use address X, or will we then lose any usable DNS server address?

It is reasonable to remove it in my opinion. However if the client
has no fallback mechanism to obtain a new resolver address, I guess it
could decide to keep using it.

If however say NTP server address is removed, and the client has no
fallback, I would say disable NTP.

Try to think what you would do without this option. Your client would
try to refresh the info at some point wouldn't it? If you move to new
link, if user requests it etc. What do you do if no server is specified
in the reply? If the DNS server address is not in the new reply, the
administrator has removed it from the DHCP server config, and is
expecting clients to obtain DNS server address in some other way, or?
It's just another hint for when to update the info.

Also, if you stop offering some service, or by accident include
something. There should be a way to remove it.

> "update timer" semantics as long as the specification is clear enough

Well, I'm interested in hearing what you think is reasonable, and what
you would implement in your client if you don't have this options, but
renew the data for other reasons.

> week.  I'd apologize in advance for future delay of my responses.

NP. I hope to post my suggestions for next revision later this week.
I'll then wait several days to see if people are satisfied, in which
case I'll make it the official "02" version.

Stig

---

From: Joe Quanaim <[email-masked]>
Date: Tue, 24 Aug 2004 10:25:11 -0400

> draft to understand exactly what it is.

Another alternative might be "refresh delay".  This changes the nature of the 
name from "check back in n seconds" to "do not check again until at least n 
seconds".  It does not piggyback on the notion of expiration, which is well 
defined in the address management side of dhcp, but not on the stateless 
option side.

Joe.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Aug 2004 11:08:14 -0400

> the Internet.  I admit this might be a niche demand though.

I would never want to suggest that your needs as a network user are not 
representative of the average user, of course!   :')

However, let's consider your scenario a little more closely.   You 
acquire some information from the DHCP server.   Subsequently, for some 
reason, it becomes impossible for the server to respond to the client.

I have a couple of observations about this.   First, the time at which 
it becomes impossible for the server to respond is not the same as the 
time at which the client attempts to refresh its configuration 
information.   The two events are unrelated.

Second, we should consider why the DHCP server is no longer able to 
respond.   I would say the most likely scenario is that I am no longer 
connected to the same link, so that my routing information is stale.   
But in this case I am going to notice that I am no longer on the same 
link because of RA messages, or because of a physical network link 
state transition.   And this will happen at the time when it becomes 
impossible to contact the DHCP server, *not* at the time that the 
refresh time comes.   So I would say in this case that you will already 
have invalidated the refresh timer and the information covered by the 
refresh timer, so we have no need to say what you would do when the 
refresh timer expired, because it will not ever expire.

Another scenario that might occur is that the DHCP server might be 
turned off, and then it wouldn't reply because it's not available.   In 
this case, I can think of two basic reasons why this might have 
happened.   One is that the server needs some kind of maintenance.   
The other is that DHCP service is no longer wanted on the link.

In the first case, you want to continue using the configuration 
information, because it's still valid.   It would be somewhat 
disastrous to stop using it.   In the second case, which I would argue 
is unlikely on a production network, it would be nice if there was some 
way to indicate that the information was no longer valid.

I would say that if you want to address the concern you've raised, this 
is the scenario that you need to address, and that the solution you've 
proposed doesn't fit the scenario you've described, because in the most 
common case where you care, the solution isn't needed, and in the 
second-most-common case, the proposed solution would result in the 
network becoming unusable to the average user.

> know this makes sense in the real world.

This is a fertile area of DHCP research.   :')

> use address X, or will we then lose any usable DNS server address?

It's a good question.   I think that it's unlikely that the DNS server 
address would be missing unless the server had been configured to no 
longer send it, so I think it would indeed make sense to stop using the 
stale information.   This could be the answer to the scenario you 
proposed initially - if you want to turn off the DHCP server, you 
configure it to send an empty information reply message.   You leave it 
configured this way for the duration of the refresh time.   Then you 
turn it off, because you can be confident that any client that was 
connected to the network during the interval when it was sending empty 
information reply messages will no longer be relying on DHCP for the 
information the DHCP server had been providing.

This implies that if we *start up* on a link to which we were 
previously connected, we should immediately attempt to contact the DHCP 
server.   In this case, if we are not able to contact the DHCP server 
by the time the refresh time has passed, we can assume that it is no 
longer active on the link, and that any information we have cached is 
no longer valid.   This would be analogous to the INIT-REBOOT state in 
DHCPv4.

> week.  I'd apologize in advance for future delay of my responses.

I would like to defer making a decision on this point until you have 
time to respond, so if that's next week, let's wait until next week to 
resolve these issues.

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 24 Aug 2004 21:00:45 -0400

I'd vote for "Refresh Time Option". I have no problem renaming this and I do
how we keep it simple - client should refresh its data when the time elapses
(note that this doesn't preclude the client from doing it earlier if it has
a good reason to do so).

- Bernie

> Sent: Tuesday, August 24, 2004 10:25 AM
> To: Stig Venaas
> Subject: Re: [dhcwg] behavior on lifetime expiration (Re: 
> comments ondraft-ietf-dhc-lifetime-01.txt)
> 
> 
> Stig Venaas wrote:
> > On Mon, Aug 23, 2004 at 01:42:39PM -0400, Joe Quanaim wrote: [...]
> >
> > So let's try to find a new name. I think "update time 
> option" is one 
> > possibility. I don't like "update timer option" because 
> this is only a 
> > value to use for the timer, not the timer itself.
> >
> > I discussed it with a colleague, and we came up with 
> alternatives like 
> > "suggested refresh/update time option" or "refresh/update within 
> > option". Not so sure about the last one, it tries to make it clear 
> > that you might refresh/update before the specified time.
> >
> > I think we should keep the name fairly short. We should have a name 
> > that isn't misleading, but people will still have to read 
> the draft to 
> > understand exactly what it is.
>

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 24 Aug 2004 21:12:07 -0400

Jinmei:

You'd prefer IPv4 based information over IPv6?

And DHCPv4, if Inform was used, doesn't have *ANY* time to expire the
information - so I don't think you'd want to use this information in
preference to DHCPv6 information with a time?

If you can't obtain newer information, you're always free to take whatever
steps you like on the client - ie, start a local recursive server daemon
(e.g., run BIND named on my laptop and specify ::1 in /etc/resolv.conf).

The issue of not receiving some information that was previously received is
a good one and we probably should give some advice in the draft as to
possible options that a client could chose (based on "local" policy). My own
feeling is that I'd discard the old information and use the new, especially
if the source can be trusted (ie, authentication was used). There may be
valid reasons why some options are no longer available; in other cases it
could be a configuration error and in that case it may be good for
administrators to know about it sooner than later. The worst is if it is a
Denial of Service attack, but in that case they can just as easily send you
bogus information.

- Bernie

> On Behalf Of JINMEI Tatuya / _–¾’BÆ
> Sent: Tuesday, August 24, 2004 8:12 AM
> To: Ted Lemon
> Cc: [email-masked]
> commentson draft-ietf-dhc-lifetime-01.txt)
> 
> 
> >> invalidate the expired information in some way, e.g., by 
> preferring a 
> >> "last resort" default or by using other means of configuration.
> 
> (recursive) server expires with no update I'd stop using the 
> server and start a local recursive server daemon (e.g., run 
> BIND named on my laptop and specify ::1 in /etc/resolv.conf) 
> as a last resort.  I'm quite sure that this is a "real world" 
> scenario because I, for one, would like to have this feature 
> and I'm living in the real world of the Internet.  I admit 
> this might be a niche demand though.
> 
> I can also think of a scenario where I'll then prefer 
> information from DHCPv4 (over the expired information from 
> DHCPv6).  But I don't know this makes sense in the real world.
> 
> Aside from the scenarios, I'm also concerned about a 
> (possible) pitfall with the "update timer" semantics.
> 
> Assume that we have a reply to Information-request containing 
> a DNS server address X with update timer (or lifetime) T.  T 
> seconds later, the client will restart 
> Information-request/reply exchanges.  If we then get a 
> different DNS server address Y, we'll stop using the old 
> address X and switch to Y.  This should exactly be the 
> "renumbering scenario", and the behavior looks reasonable.  
> But what if the reply does not contain any new DNS server 
> address?  Can we still continue to use address X, or will we 
> then lose any usable DNS server address?
> 
> If the former is the intent, it seems a bit odd to me that 
> the behavior is different based on whether the replied set is 
> empty or not (at least the specification is not very clear on 
> this).  If the latter is the intent, doesn't it almost mean 
> we invalidate the expired information X?
> 
> Anyway...so far, others do not seem to be very happy with the 
> idea of invalidating expired information.  If the above 
> explanation is still not so convincing, I won't stick to the 
> idea.  I can live with the "update timer" semantics as long 
> as the specification is clear enough to implement.
> 
> 					JINMEI, Tatuya
> p.s. I'm afraid I won't be able to be very active on the list 
> this week.  I'd apologize in advance for future delay of my responses.
>

---

From: Robert Elz <[email-masked]>
Date: Fri, 27 Aug 2004 12:45:02 +0700

Date:        Tue, 24 Aug 2004 21:00:45 -0400
    From:        "Bernie Volz" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'd vote for "Refresh Time Option". I have no problem renaming this

The name of the option isn't really the point.   Jinmei has a valid point,
but didn't manage to express the real issue perhaps as clearly as should
have been done.

The issue isn't really "what happens when the lifetime expires" (whatever
you call it), the issue is "what happens when the DHCP server doesn't give
us some information that was given to us before" ?

You're mostly all thinking (it seems) of the case where the DHCP server
doesn't reply at all to a later request for information - and so no new
data is provided.

The other case, where the dhcp server does reply, and supplies new information.
We all know what to do in that case.

But those aren't the only two cases - the problem case is what happens when
the (a) DHCP server does reply, but only supplies values for some of the
options that an earlier DHCP response had supplied.

That is, suppose I ask for NTP servers and DNS servers.   When I boot
I get told fe80::99 for NTP, and fe80::7 for DNS.   Then later, I ask
again, and get told 2001:1234:5678::16 for DNS, but get no NTP server
addresses supplied at all.

What is the client expected to do in that case?   It seems reasonably clear
(to me anyway) that the likely cause of this kind of change, is that the
client is a portable device, that has been moved from one location to
another, and is now talking to a different DHCP server than it was before
(though entirely possibly both servers migh just happen to have been
configured at fe80::9 on their respective LANs).

Should the client just keep on using the (probably now bogus) NTP server
address, or should it just give up on NTP, given the local lan most
likely has no available server?   Does it make a difference if the
previous "lifetime" has or has not expired?   Or for that matter, whether
or not there was ever a lifetime option, or whether or not the client
requested it (and knows anything aboutthis new option) ?

Once you work out the right answer to that problem, it is a minor issue to
extend that answer to the case where no answers at all are returned.

kre

ps: notice here I am not suggesting what the answer should be.

---

From: Robert Elz <[email-masked]>
Date: Fri, 27 Aug 2004 13:08:32 +0700

Date:        Fri, 20 Aug 2004 08:44:14 -0400
    From:        "Bernie Volz" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm OK to restricting the Lifetime Option to replies to
  | Information-Request's.
  | 
  | The client MUST ignore a Lifetime Option that is in any message other than a
  | REPLY to an INFORMATION-REQUEST. A client MUST NOT include the Lifetime
  | Option number in an ORO except when sending an INFORMATION-REQUEST message.
  | 
  | The server MUST NOT include the Lifetime Option in any message other than a
  | REPLY to an INFORMATION-REQUEST.

I've been reading all of the messages on this topic (catching up) and I
haven't managed to find a reason why anyone would want to add this kind
of restriction, I just don't see the need.

You seem to all be imagining that things have to get much more complex
for the clients if they get two timer values, and they're different.
But that's nonsense.

All of these timers are just upper bounds - a client that wants to be
simple just wants a single timer.   If one option says "the upper bound
is 86400 seconds" and another says "the upper bound is 43200 seconds",
then to the client, it just tries again, for all the info, before the
43200 second timer expires.   This isn't complex, it is trivial.

On the other hand, if the client doesn't need to be quite that simple,
then I see no compelling reason to require it to be so.

In particular, and especially given we're talking about IPv6, I see
no reason why a client shouldn't use very long lease times (well,
comparatively long - in IPv4 I've seen values counted in years - that's
absurd, but values of several weeks for address lifetime should be
reasonable).    If there's no prospect that the prefixes are going to
change anytime soon, there's no reason that an IPv6 node shouldn't be
able to keep using its address for a very long time, even if the DHCP
server is down for an extended period (and that's what the lease timers
are all about really - no-one disputes but that addresses stop being
used when their lifetime expires).

On the other hand, we may want to be able to shift which hosts run various
servers with much time lag, so the "other option lifetime" (or whatever it
ends up being called) might want to be quite a bit smaller (maybe measured
in hours, or a day or so).

A simple client will simply refresh everything when the shorter timer
expires.   A complex one might prefer to just use info requests when the
shorter info timer expires, and only do the full dhcp protocol when the
addresses actually expire - aside from anything else, this allows dhcp-lite
servers to respond, where only a full duchv6 server can handle address 
requests.

Why would anyone really want to forbid this?   That's all the proposed
language is doing, nothing really gets any simpler (in a simple client now
instead of just taking the lower timer value, it instead has to know
to ignore this particular option if it happens to occur in that particular
message type - which I think is a rather unusual case).

kre

---

From: Stig Venaas <[email-masked]>
Date: Fri, 27 Aug 2004 08:23:21 +0200

> requested it (and knows anything aboutthis new option) ?

Thanks for making this clear. We just had some discussion on this, but
the problem was perhaps not clearly stated. And this is one of the
things I tried to ask. What would you do if this happened without this
option. As you said, this is a more generic problem, and it makes me
wonder whether people already have thought about this.

> extend that answer to the case where no answers at all are returned.

Is there a theoretical possibility that you get a response, but without
any options? That should possibly be treated differently from not
getting any reply at all.

> ps: notice here I am not suggesting what the answer should be.

If you get a response from a server, and later a new from the same
server but with some options missing, then I believe the administrator
must have removed the it on purpose and the old information is not
valid.

However, this is not so clear if you get a reply from a new server.
If you're still in the same site, then I think situation is pretty
much like above. But if the client has moved to a new site, the old
information might be valid, but not necessarily.

E.g. if I learn an NTP server at home, I might wish to keep using it
from a new location, even if the administrator in that new location
doesn't care about NTP and hasn't configured anything. Whether I
should continue using the one at home really depends on policy. The
access to the NTP server might for instance be blocked in a firewall
deployed in/around my home site or the site I'm now visiting.

I'm not sure if the answer to these issues need to be described in
the draft since it's a more generic issue. OTOH this draft might be
the most obvious place we have for now.

Stig

---

From: Robert Elz <[email-masked]>
Date: Fri, 27 Aug 2004 13:52:49 +0700

Date:        Fri, 27 Aug 2004 08:23:21 +0200
    From:        Stig Venaas <[email-masked]>
    Message-ID:  <[email-masked]>

  | I'm not sure if the answer to these issues need to be described in
  | the draft since it's a more generic issue. OTOH this draft might be
  | the most obvious place we have for now.

Yes, it is a much bigger issue than just providing a mechanism for
specifying when a new info request should be attempted.

But it is when we specify that that the problem becomes obvious, and
we need to have a solution - until now (including in IPv4) we mostly
just pretended that none of this ever happened, and once learned, all
of this information was static forever (hence, DNS "servers" (back end
resolvers really) go in /etc/resolv.conf - that gets updated when the
info changes, but applications know nothing of that, and simply keep on
using the old information forever).

All this is something of a quagmire - but is something that needs to be
addressed, and ought to be addressed along with this new option (if not
necessarily in the same document).

kre

---

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

> necessarily in the same document).

I agree that this is an issue, but I don't think it's something this document 
should address.  It's a larger part of the dhcp specification, and the 
example you gave could happen in stateful configuration as well.

For the example involving dns and this option, I read the draft as such: when 
the option expires, don't dismiss the configured dns data.  Request new 
information.  When new information is received, replace the existing data 
with the newly obtained.  This prevents the client from being left without 
dns while making an attempt to be current.  Also, if a server returns an 
empty set of dns servers, that is what the client should use.  It doesn't 
make much sense, but misconfigured dhcp servers aren't something a client 
should be programmed to handle.

Generalizing this issue is not simple.  How does a dhcp client update the ntp 
configuration?  And why does it?  The ntp configuration could be pointing to 
a server reachable from multiple networks.  This seems like local policy.

Joe Quanaim.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 27 Aug 2004 13:32:42 -0500

> should be programmed to handle.

I agree that this is what the client should do.   If this isn't clear 
to kre from reading it, then perhaps we need to make it clearer, but I 
certainly agree that this is the behavior that we want to specify.

---

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

> for the clients if they get two timer values, and they're different.

I pretty much agree with what you say. The reason the option isn't
needed when you have leases, is of course that you can set the lease
time short, just to ensure that client update other config. I agree that
it could still be useful though.

I don't know what people think, I have no strong feelings myself, but
we could relax things a bit perhaps. But there is some added complexity
and it isn't essential. It could also be extended later if necessary.

We could tweak the spec to allow what you say, if there's agreement on
that. But most of all, I want to come to some conclusion really soon.

I posted a mail with subject "Attempt at text for
draft-ietf-dhc-lifetime-02" where I tried to write text that most so
far seems to agree with. Most of it is based on inputs from discussions
on mailing list.

Bernie gave some comments that I plan to include.

I did not say any about what should happen if some config data is
removed from one client update to the next. Do you really want that
in? I'm not sure I do, since as also some others agreed to, it's a
more generic problem. If I were to write text, I would say that it
should indeed be removed.

Stig

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 01 Sep 2004 01:01:51 +0900

>>>>> On Tue, 24 Aug 2004 11:08:14 -0400, 
>>>>> Ted Lemon <[email-masked]> said:

> information.   The two events are unrelated.

Okay, I concur on this.  I also see that the scenario might differ
based on whether the client moves to a new link or it stays in the
same link.

Instead of making further responses point by point, I'll try to
summarize major points throughout the thread, and propose what I
personally would envision based on the points (if you feel this
approach is unfair, please say so).  I'll also call the new option
"refresh timer option" in the followings since that's the closest
notion which we now seem to agree on.

The case of moving clients is probably too difficult to provide
a complete solution, but it would be helpful some considerations along
with the this new option.

Now assuming a still client (i.e., a client that doesn't move), we
seem to be close to the consensus.
  - when the refresh timer expires, the client resends a new
    Information-request message.  (it can do so earlier than the
    expiration time based on its local policy)
  - if the client gets a response, it (MUST) replace the old
    information with the new one.  This also means if the response
    contains an empty set of some particular information, the client
    should stop using the old information.
    (BTW, there are two types of an "empty set".  The first one is a
     response that contains the corresponding DHCPv6 option, e.g., DNS
     recursive name server option, with an empty list.  The second one
     is a response that doesn't contain the DHCPv6 option.  It seems
     to me it makes sense to regard both types as "an empty set").
  - if the client cannot get a response, it (SHOULD?) continue using
    the old information because of the reason Ted provided.

So, what I would expect in this document is as follows:

- we basically concentrate on the case of a still client and
  explicitly say so in the document.
- then we describe the detailed behavior for that type of clients as
  shown above (of course, based on a consensus in the wg).
- we also provide some considerations on moving clients (in an
  appendix?), which would be something like this:
    + we assume we can detect the movement (or simply say it's beyond
      the scope of this work).  I think we can simply refer to the
      beginning of Section 18.1.2 of RFC3315 if necessary.
    + when the client detects the movement, it should start contacting
      the DHCP server immediately, regardless of the remaining time of
      the refresh timer.  In this case, how the client deals with the
      old information is up to the client based on its local policy
     (there can be so many valid scenarios as we've seen in the
      discussion).  This should particularly apply when the client
      receives an "empty set" for some information or when the client
      cannot get any responses at all.  However, if the client gets a
      non empty set of new information, it SHOULD(?) replace the old
      information with the new one.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 01 Sep 2004 01:06:20 +0900

>>>>> On Tue, 24 Aug 2004 21:12:07 -0400, 

> You'd prefer IPv4 based information over IPv6?

No, in that example, I assumed a dual-stack host.

> preference to DHCPv6 information with a time?

I think I would, since in this case I'd regard the "expired" DHCPv6
information as less reliable than DHCPv4 information without any
expiration time.

But I won't stick to this point any more as I (perhaps implicitly)
said in my response to Ted.   Let's just throw away this
mostly-imaginary scenario.

					JINMEI, Tatuya

---

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

> that. But most of all, I want to come to some conclusion really soon.

I think using the IRT option in a context where there is a lifetime 
already doesn't make sense, and should not be allowed.   I don't mean 
the client should drop the packet if it gets both - just that the 
option has no meaning in the context of a stateful DHCP message.

---

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

> should indeed be removed.

I think we need to collect some experience on this, and that we should 
update the RFC later when we have more information.   For now, we 
should not say what to do.   I can easily think of a byzantine set of 
specifications for how to do this, but I'm not sure they're either 
necessary or correct.

---

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

> So, what I would expect in this document is as follows:

What you've proposed sounds good to me!