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

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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> On Behalf Of Joe Quanaim
> Sent: Tuesday, August 03, 2004 9:33 AM
> To: JINMEI Tatuya / ???? ; venaas@uninett.no; tjc@ecs.soton.ac.uk
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] comments on draft-ietf-dhc-lifetime-01.txt
>
>
>
> JINMEI Tatuya / 神明達哉 wrote:
> [...]
> > 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?
>
> Isn't this duplicating rfc 3315?  Removing it would prevent
> any subsequent
> updates to rfc 3315 from conflicing with this statement.
>
> >   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?
>
> 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.
>
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg