Subject: RE: Issue from San Diego IETF - temporary addresses

From: [email-masked]
Date: Tue, 6 Mar 2001 17:24:04 -0600

Thomas,

There is no way to differentiate a temp addr from other addr semantically.
Please give us an example I don't see this in src addr select at all.  In
fact there are no bits in IPv6 addr arch anywhere to support this.

Putting on my IPv6 hat I got to say that your statement that temporary
addresses are part of the IPv6 address architecture is NOT TRUE.  Its an
appeasement for paranoids.

There is nothing in stateless addr conf or ND or anywhere to do something
special for IPv6 addresses.  So I object to you putting that on this WG and
DHCPv6 unless you can be more clear on showing consistency elsewhere.

Also src addr select does not have consensus and a few folks (including me)
will object at IESG last call and make issues if some things are not fixed
in that spec.

regards,
/jim

> -----Original Message-----
> From: ext Thomas Narten [mailto:[email-masked]]
> Sent: Tuesday,March 06,2001 4:54 PM
> To: DHCPv6 discussion list
> Subject: Re: Issue from San Diego IETF - temporary addresses 
> 
> 
> > Narten also raised issue of interaction between DHCP and temporary
> > addresses. DHCP server can provide temporary addresses by assigning
> > addresses with short lifetimes. However, there will be an API
> > through which an application can request a temporary address. How
> > can the DHCP server indicate to the client which addresses are to be
> > "temporary" and which are "permanent"? Narten thinks IESG will
> > bounce anything that doesn't deal with temporary addresses. He will
> > develop requirements doc so WG can develop solution.
> 
> Let me try to summarize the issues. The IPv6 architecture now support
> the notion of temporary addresses. Temporary addresses are normal
> addresses, i.e., they can be used just like other IPv6
> addresses. However, they are designed to be used in cases where the
> TCP connection doesn't last forever, i.e., is "short" where short can
> mean a few seconds to minutes to hours. It does not mean for weeks or
> months. I.e., RFC 3041 suggests that a temporary address be
> 'preferred' for one day, and become invalid after a week. So its
> really intended for connections that don't last very long. Also,
> temporary addresses are intended to be uses by applications/devices
> that don't want to expose their (permanent) interface identifier to
> remote sites.
> 
> There is a need for an API so that applications can indicate if they
> want to use a temporary vs. a "public" address, i.e., one that that
> doesn't change (or at least, doesn't change until there is a
> renumbering event, etc.). That is still a TBD item in IPNG and is not
> something this WG needs to worry about too much.
> 
> For nodes using stateless autoconfiguration, RFC 3041 describes how
> temporary addresses are created, when they expire, etc. DHCPv6,
> because it can also be used to assign addresses to nodes, needs to
> have a story on temporary addresses. That is, a node should be able to
> use temporary addresses regardless of whether stateless or stateful
> address autoconfiguration is needed. Thus, the DHCPv6 spec needs to
> say how temporary addresses are created and/or assigned when DHCPv6 is
> used.
> 
> Note that RFC 3041 makes it clear which addresses are "temporary" and
> which are not, and the address selection document
> draft-ietf-ipngwg-default-addr-select-02.txt makes recommendations on
> what to do with temporary addresses. I.e., it is a property of the
> address whether it is temporary or not, and that property is exploited
> in other parts of the IPv6 architecture.  So I believe what DHCPv6
> needs to do is define the mechanics for how temporary addresses are
> assigned to nodes.
> 
> > Shouldn't this say "How can the DHCP client indicate to the server
> > which addreses are to be "temporary" and which are "permanent"? It
> > is after all the client that might have an understanding of how long
> > the address is desired.
> 
> I would turn it around. One possible way of providing temporary
> address support in DHCP is to allow (require?) that the client request
> (via DHCP) that it wants temporary address(es) in addition to regular
> addresses. Note I am not saying the client says how many or anything
> other than "it does want temporary addresses". The DHCP server then
> *could* return a set of addresses, with the temporary addresses
> flagged with a special indication so that the client knows they are
> temporary (this is needed for the address selection rules mentioned
> earlier).
> 
> > As the client will send an "Identity Association Option" to request
> > address(es), couldn't this simply be communicated via a lease
> > request time? Though there probably is no good field to store this
> > in.
> 
> I don't think you want to overload lease time for this
> purpose. Temporary addresses are semantically different than addresses
> with a short lease. 
> 
> > And, then we should perhaps ask WHY DOES THE SERVER CARE? If the
> > client wants a short lease, the server simply grants it the
> > address(es) for however long the server policy dictates. If the
> > client doesn't want to use the address after a period of time, it is
> > ALWAYS able to RELEASE it whenever it is done. Even if it doesn't
> > release it but instead simply lets it expire, what's the harm? There
> > should be plenty of addresses available in IPv6.
> 
> The client doesn't just want a short lease. It wants a temporary
> address (in addition to a public address). When its current temporary
> address expires, it will want to get a new one that is  different than
> the one it had before. If the client just requested a new address with
> shorter lease, it might just get back the one it just had, which
> defeats the reason for having temporary addresses.
> 
> > Of course, the requirements document might help answer why Thomas
> > feels there is a need to have a mechanism to explicitly request
> > these temporary addresses. Perhaps the reason for the 'temporary'
> > addresses is that they are supposed to be 'random' instead of based
> > on the EUI-64 identifier of the client; but as a previous message
> > pointed out nothing has been said as to how a DHCP server will
> > assign addresses.
> 
> Not random, but changing over time and not to be reused in a
> predictable way.
> 
> Thomas
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Mar 2001 09:08:36 -0500

Catching up on a number of postings..

[email-masked] writes:

> There is no way to differentiate a temp addr from other addr
> semantically.  Please give us an example I don't see this in src
> addr select at all.  In fact there are no bits in IPv6 addr arch
> anywhere to support this.

I agree that there is no way to distinguish temporary addresses from
other ones by looking at them (i.e., syntactically). But there are
times when an implementation needs to know whether an address is
temporary or not. Hence, if DHCP is to be used to send temporary
addresses from the server to the client, there will need to be a way
to flag this. E.g., a bit in the extention.

Note: the addr-select document in the ID directory is old. Per a note
to the IPNg list:

"Richard Draves" <[email-masked]> writes:

> I submitted these twelve hours before the deadline, but somehow they
> didn't get there in time:

> ftp://ftp.research.microsoft.com/users/richdr/draft-ietf-ipngwg-default-addr-select-03.txt
> ftp://ftp.research.microsoft.com/users/richdr/draft-draves-ipngwg-router-selection-01.txt

Temporary addresses are described in the default-addr-select document.

> Putting on my IPv6 hat I got to say that your statement that
> temporary addresses are part of the IPv6 address architecture is NOT
> TRUE.  Its an appeasement for paranoids.

I suspect we're having a disagreement over terminology more than
substance. Temporary addresses exist, they are part of the overall
IPv6 picture. Not everyone needs to implement them. But because they
are part of the overall picture, and they fit in with the existing
IPv6 architecture, I say they are part of the architecture.

> This is just a knob an API is not needed.  We have these all over IPv6
> implementations today.

We're in agreement, just differing on terminology. I'm assuming "new
API" means extensions to the existing ones (i.e., the basic API).

Note also that if an application can indicate (through the API) that
it does (or does not) want temporary addresses used, that is another
reason why such addresses must be distinguishable within an
implementation. I.e, source address selection indicates how to choose
temporary vs. public addresses when the application doesn't care, the
API is needed so that applications can override the defaults.

> This is not entirely correct.  3041 does not tell how to create them but
> only how select that an address has a temporary context based on the
> lifetimes used for the addresses.  By the way what is unclear in 3041 is
> whether the router or the host alters the lifetimes.  That needs to be
> fixed.  My assumption is that its the host and not the router.

The host does the lifetimes.

> Also none of this is mandatory for IPv6 or it would never have gotten thru
> IPng or me. Recall our conversation about this at last call?  And as is
> pointed out in 3041:

>    Use of the extensions defined in this document may complicate
>    debugging and other operational troubleshooting activities.
>    Consequently, it may be site policy that temporary addresses should
>    not be used.  Implementations may provide a method for a trusted
>    administrator to override the use of temporary addresses.

> No they do not.  What they do is give an algorithm to set the lifetimes as
> follows using these constants:

> TEMP_VALID_LIFETIME -- Default value: 1 week.  Users should be able
>           to override the default value.
> TEMP_PREFERRED_LIFETIME -- Default value: 1 day.  Users should be
>           able to override the default value.
> REGEN_ADVANCE -- 5 seconds
> MAX_DESYNC_FACTOR -- 10 minutes.  Upper bound on DESYNC_FACTOR.
> DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR.
>           It is computed once at system start (rather than each time
>           it is used) and must never be greater than
>           (TEMP_VALID_LIFETIME - REGEN_ADVANCE).

> As one who has written the code and shipped in the market stateless addr
> conf one could set a bit or switch that once the algorithm in 3041 is
> executed set a bit that this address has undergone the processes to become
> temporary.

> But to state that an IPv6 address can be identified for example from tcpdump
> output by looking at the address as literal, hex, or binary format is not
> true.

We are miscommunicating, as I have never stated that one can identify
temporary addresses via tcpdump.

> An address being temporary is a state and context in an
> implementation.

I agree. But *if* DHCP supports temporary addresses by having the
server send them to the client, there would seem to need to be a way
for those addresses to be flagged as temporary. Stateless addrconf
doesn't have this issue because its all internal to the implementation
(e.g., not on the wire).

Also, I'm not saying that DHCP has to support temporary addresses this
way. Another approach would be for the the DHCP server to send the
client the routing prefix and then have the host do everything else,
ala 3041. I wonder though if this is the "right" model in an
enviroment where DHCP is being used. I.e., presumably a site using
DHCP wants to know  *ALL* the addresses that are in use and by whom,
and having the client generate them would not support this. This is
something the WG needs to work through.

Note: I'm not responding to some of your other points because I think
they all result from a more basic disagreement that is addresses
earlier in this note. Those may need to be revisited if this note
isn't clarifying things.

Thomas