Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14495 for ; Wed, 15 May 2002 13:25:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14541 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 13:25:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14389; Wed, 15 May 2002 13:24:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14332 for ; Wed, 15 May 2002 13:24:42 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14425 for ; Wed, 15 May 2002 13:24:28 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g4FHOfl19172 for ; Wed, 15 May 2002 12:24:41 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g4FHOf807227 for ; Wed, 15 May 2002 12:24:41 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 15 12:24:40 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:24:40 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41B@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Date: Wed, 15 May 2002 12:24:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC35.63CF22B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FC35.63CF22B0 Content-Type: text/plain; charset="iso-8859-1" Ralph: I think all we wanted to do was to remove the prohibition against renewing IA_TA's. I don't think we want to drop the IA_TA concept or need to add T1/T2 times to the IA_TA option since the intent is NOT to renew these. If the client needs to continue using existing temporary addresses, it must initiate a Renew in time to renew them. The server can always have policy that would disallow this (for example if a renumbering event is happening). And, adding some comments that in a managed (stateful) addressing environment the RFC 3041 procedures basically trigger stateful requests for temporary addresses in place of the stateless autoconfiguration would be useful. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 15, 2002 1:11 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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. > >I don't think the above is what we want. A Client should be able to >renew/extend lifetimes for temp addresses *if* they want. But in >general, they won't. (Note this is also allowed in 3041 in the sense >that this is left open as a possibility -- I don't see a need for DHC >to preclude this from being done) OK (but see below). >Ralph asked: > > > The basic question is "can a client ask and a server agree to extend > > the lifetimes on temp addresses". If lifetimes on temp addresses can > > be extended, how are they different from non-temp addresses? Good > > question to discuss in WG. > >They are different in that applications can specifically request that >temp addresses be used for communication, *or* that temp addresses NOT >be used. Thus, there has to be a way to distinguish between temp and >non-temp addresses. Also, I believe that a node might be using several >sets of temp addresses simultaneously. Normally, that would mean one >set that is "preferred", but there could be a number of others that >are "deprecated", meaning not to be used for new communication, but >still available to the applications that are already using them. If an >application is still using a temp address, it may need to extend the >valid Lifetime to prevent the address from going away. I agree that the protocol software needs to identify temporary addresses so that applications can select for or against them. But, how does DHCP handle temporary and non-temp addresses differently? Is is just a tag that the server supplies and the protocol software interprets to identify temporary addresses or are there other differences? >This also raises a different point. There should be more text about >when to get a new set of temp addresses. I.e., one could point to 3041 >for guidance on when to get a new one and use similar rules. I.e., >unlike permanent addresses, the normal action when a temporary address >becomes deprecated is to request a new (i.e., different) one. The old >one still remains for a while, but is being phased out. In contrast, >for public/global addresses, the normal action is to renew the *same* >address and extend its preferred lifetime. > > > An identity association for temporary addresses option MUST NOT > > appear in a Renew or Rebind message. This option MAY appear in a > > Confirm message if the lifetimes on the temporary addresses in the > > associated IA have not expired. > >If the client wants to extend a binding (perhaps an application is >still using that address) it should not be prohibited by the >protocol from doing so. OK - we can reference RFC3041 for that guidance... >Thomas > >_______________________________________________ >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 ------_=_NextPart_001_01C1FC35.63CF22B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Temporary addresses

Ralph:

I think all we wanted to do was to remove the = prohibition against renewing IA_TA's. I don't think we want to drop the = IA_TA concept or need to add T1/T2 times to the IA_TA option since the = intent is NOT to renew these. If the client needs to continue using = existing temporary addresses, it must initiate a Renew in time to renew = them. The server can always have policy that would disallow this (for = example if a renumbering event is happening).

And, adding some comments that in a managed = (stateful) addressing environment the RFC 3041 procedures basically = trigger stateful requests for temporary addresses in place of the = stateless autoconfiguration would be useful.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, May 15, 2002 1:11 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Temporary = addresses


At 11:11 AM 5/8/2002 -0400, Thomas Narten = wrote:
> >    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.
>
>I don't think the above is what we want. A = Client should be able to
>renew/extend lifetimes for temp addresses *if* = they want. But in
>general, they won't. (Note this is also allowed = in 3041 in the sense
>that this is left open as a possibility -- I = don't see a need for DHC
>to preclude this from being done)

OK (but see below).


>Ralph asked:
>
> > The basic question is "can a client = ask and a server agree to extend
> > the lifetimes on temp = addresses".  If lifetimes on temp addresses can
> > be extended, how are they different from = non-temp addresses?  Good
> > question to discuss in WG.
>
>They are different in that applications can = specifically request that
>temp addresses be used for communication, *or* = that temp addresses NOT
>be used. Thus, there has to be a way to = distinguish between temp and
>non-temp addresses. Also, I believe that a node = might be using several
>sets of temp addresses simultaneously. Normally, = that would mean one
>set that is "preferred", but there = could be a number of others that
>are "deprecated", meaning not to be = used for new communication, but
>still available to the applications that are = already using them. If an
>application is still using a temp address, it = may need to extend the
>valid Lifetime to prevent the address from going = away.

I agree that the protocol software needs to identify = temporary addresses so
that applications can select for or against = them.  But, how does DHCP
handle temporary and non-temp addresses = differently?  Is is just a tag that
the server supplies and the protocol software = interprets to identify
temporary addresses or are there other = differences?


>This also raises a different point. There should = be more text about
>when to get a new set of temp addresses. I.e., = one could point to 3041
>for guidance on when to get a new one and use = similar rules. I.e.,
>unlike permanent addresses, the normal action = when a temporary address
>becomes deprecated is to request a new (i.e., = different) one. The old
>one still remains for a while, but is being = phased out. In contrast,
>for public/global addresses, the normal action = is to renew the *same*
>address and extend its preferred = lifetime.
>
> >    An identity association = for temporary addresses option MUST NOT
> >    appear in a Renew or = Rebind message.  This option MAY appear in a
> >    Confirm message if the = lifetimes on the temporary addresses in the
> >    associated IA have not = expired.
>
>If the client wants to extend a binding (perhaps = an application is
>still using that address) it should not be = prohibited by the
>protocol from  doing so.

OK - we can reference RFC3041 for that = guidance...


>Thomas
>
>_______________________________________________
>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

------_=_NextPart_001_01C1FC35.63CF22B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg