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