RE: [dhcwg] dhcpv6-24: Temporary addresses

["Bernie Volz (EUD)" <[e-mail]>]

>> >    A server MUST return the same set of temporary address for the same
>> >    IA_TA (as identified by the IAID) as long as those addresses are
>> >    still valid.  After the lifetimes of the addresses in an IA_TA have
>> >    expired, the IAID may be reused to identify a new IA_TA with new
>> >    temporary addresses.
>
>> was in reference to a Request. We wanted to be clear on what happens
>> should a server receive a Request with the same IAID in a IA_TA
>> option that it already sent a Reply to.
>
>OK. This makes sense. This would be the same for temp and non-temp
>addresses. Right? Is the same text present in the non-temp case (I
>don't recall right off)?

Yes, it really should be the same and I think it is implied in other statements relating to addresses in an IA (that can not be removed until the valid lifetime has expired).

We do say (for the IA option): "When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired."

The one issue with Temporary Addresses is that a server implementor could assume "hey, they're temporary and assigned once and ..." so why save the binding information (they have to flag the address as in use until the valid lifetime expires, but that doesn't mean they'd have to remember which client was using it and for which binding). So, it was important to indicate that the server must remember this because of retransmissions (and now renewals since that wasn't in -24).

>No, I think "valid" is right. 

Agreed.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[e-mail]]
Sent: Thursday, May 09, 2002 9:32 AM
To: Bernie Volz (EUD)
Cc: [e-mail]
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses 


> One question is whether to modify the IA_TA option to be basically
> the same format as the IA option and include T1/T2 times. I would
> say NO. Instead, for IA_TAs, it is up to the client to initiate a
> Renew (and eventually Rebind) should it want to extend the
> lifetimes. Normally, the lifetimes are not extended (unless the
> client needs to do so). I think this matches the RFC 3041 behavior?

I think we could do it either way. I think it is fine for the client
to decide (if it wants to) whether (ever) to renew a temporary address.

> More text on when to get a new set of temp addresses also makes
> sense (as you proposed). A new set of temp addresses will require a
> new IA_TA IAID.

That is what I understand.

> The following text:

> >    A server MUST return the same set of temporary address for the same
> >    IA_TA (as identified by the IAID) as long as those addresses are
> >    still valid.  After the lifetimes of the addresses in an IA_TA have
> >    expired, the IAID may be reused to identify a new IA_TA with new
> >    temporary addresses.

> was in reference to a Request. We wanted to be clear on what happens
> should a server receive a Request with the same IAID in a IA_TA
> option that it already sent a Reply to.

OK. This makes sense. This would be the same for temp and non-temp
addresses. Right? Is the same text present in the non-temp case (I
don't recall right off)?

> This could happen, for
> example, because of retransmissions or if the client "crashes"
> before receiving the initial Reply and reuses the same IAID when
> booting perhaps several hours later. Anyway, the point was that in a
> Request, if the IA_TA IAID is the for an existing binding, the
> server should return that existing binding if the lifetimes are
> still reasonable. We might think about whether we should change "are
> still valid" to "are still preferred"?

No, I think "valid" is right. If the address is valid, it is still
assigned the client, and it would be incorrect for the server to
return a different address (in general).

Thomas