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 PAA19444 for ; Wed, 15 May 2002 15:34:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA24726 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 15:34:30 -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 PAA24637; Wed, 15 May 2002 15:33:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24617 for ; Wed, 15 May 2002 15:33:04 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19316 for ; Wed, 15 May 2002 15:32:48 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 83B165A55; Wed, 15 May 2002 15:33:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:33:01 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.52E445F0" Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Date: Wed, 15 May 2002 15:33:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8694@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: Temporary addresses Thread-Index: AcH8NXypwydHVemDQGSaXYIvYC12EwAEczlw From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 15 May 2002 19:33:01.0288 (UTC) FILETIME=[53434680:01C1FC47] 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C1FC47.52E445F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable this sounds good to me. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 15, 2002 1:25 PM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Ralph:=20 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=20 -----Original Message-----=20 From: Ralph Droms [ mailto:rdroms@cisco.com]=20 Sent: Wednesday, May 15, 2002 1:11 PM=20 To: dhcwg@ietf.org=20 Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses=20 At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote:=20 > > A server MUST return the same set of temporary address for the = same=20 > > IA_TA (as identified by the IAID) as long as those addresses are=20 > > still valid. After the lifetimes of the addresses in an IA_TA = have=20 > > expired, the IAID may be reused to identify a new IA_TA with new=20 > > temporary addresses.=20 >=20 >I don't think the above is what we want. A Client should be able to=20 >renew/extend lifetimes for temp addresses *if* they want. But in=20 >general, they won't. (Note this is also allowed in 3041 in the sense=20 >that this is left open as a possibility -- I don't see a need for DHC=20 >to preclude this from being done)=20 OK (but see below).=20 >Ralph asked:=20 >=20 > > 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=20 > > be extended, how are they different from non-temp addresses? Good=20 > > question to discuss in WG.=20 >=20 >They are different in that applications can specifically request that=20 >temp addresses be used for communication, *or* that temp addresses NOT=20 >be used. Thus, there has to be a way to distinguish between temp and=20 >non-temp addresses. Also, I believe that a node might be using several=20 >sets of temp addresses simultaneously. Normally, that would mean one=20 >set that is "preferred", but there could be a number of others that=20 >are "deprecated", meaning not to be used for new communication, but=20 >still available to the applications that are already using them. If an=20 >application is still using a temp address, it may need to extend the=20 >valid Lifetime to prevent the address from going away.=20 I agree that the protocol software needs to identify temporary addresses = so=20 that applications can select for or against them. But, how does DHCP=20 handle temporary and non-temp addresses differently? Is is just a tag = that=20 the server supplies and the protocol software interprets to identify=20 temporary addresses or are there other differences?=20 >This also raises a different point. There should be more text about=20 >when to get a new set of temp addresses. I.e., one could point to 3041=20 >for guidance on when to get a new one and use similar rules. I.e.,=20 >unlike permanent addresses, the normal action when a temporary address=20 >becomes deprecated is to request a new (i.e., different) one. The old=20 >one still remains for a while, but is being phased out. In contrast,=20 >for public/global addresses, the normal action is to renew the *same*=20 >address and extend its preferred lifetime.=20 >=20 > > An identity association for temporary addresses option MUST NOT=20 > > appear in a Renew or Rebind message. This option MAY appear in a = > > Confirm message if the lifetimes on the temporary addresses in = the=20 > > associated IA have not expired.=20 >=20 >If the client wants to extend a binding (perhaps an application is=20 >still using that address) it should not be prohibited by the=20 >protocol from doing so.=20 OK - we can reference RFC3041 for that guidance...=20 >Thomas=20 >=20 >_______________________________________________=20 >dhcwg mailing list=20 >dhcwg@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/dhcwg=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1FC47.52E445F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Temporary addresses
this=20 sounds good to me.
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, May = 15, 2002=20 1:25 PM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: = RE:=20 [dhcwg] dhcpv6-24: Temporary addresses

Ralph:

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

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

- Bernie

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


At 11:11 AM 5/8/2002 -0400, Thomas Narten = wrote:=20
> >    A server MUST return = the same set=20 of temporary address for the same
>=20 >    IA_TA (as identified by the IAID) as long as = those=20 addresses are
> >    = still=20 valid.  After the lifetimes of the addresses in an IA_TA = have=20
> >    expired, the IAID may = be reused=20 to identify a new IA_TA with new
>=20 >    temporary addresses.
>
>I don't think the above is = what we=20 want. A Client should be able to
>renew/extend=20 lifetimes for temp addresses *if* they want. But in
>general, they won't. (Note this is also allowed in 3041 = in the=20 sense
>that this is left open as a = possibility -- I=20 don't see a need for DHC
>to preclude = this from=20 being done)

OK (but see below).


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

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


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

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


>Thomas
> =
>_______________________________________________ =
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20


_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C1FC47.52E445F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg