Subject: Re: lifetime of the IID - RFC 4941

From: Erik Nordmark <[email-masked]>
Date: Thu, 01 Aug 2013 10:18:03 +0200

On 7/31/13 1:12 PM, Hosnieh Rafiee wrote:

>  From the above sections, I presume that the current approach in RFC
> 4941 uses the same approach that is defined in RFC 4862. So, it removes
> the IID independent of the upper layer protocols.

For the questions you are asking, they behave the same. (The difference 
is that 4862 talks about the lifetimes on the prefixes, and 4941 about 
the lifetime of an IID. The lifetime of a temporary address is the min 
of those two lifetimes.)

> This means that it makes problem for applications like FTP or other
> application even though it continue to keep its connections after the
> IID is deprecated if a there is any. Because it considers it as
> connection and not if the application using it.

We try to minimize the application issues by having a significantly 
longer default valid lifetime than preferred lifetime. Basically 4941 
assumes that an application (that uses temporary addresses) would not 
keep a connection open for more than 7 days.

If instead RFC 4941 had picked a default (preferred, valid) lifetimes of 
(1, 7) minutes (i.e., minutes instead of days), then things would be 
more challenging. Hence for shorter lifetimes we'd need something 
difference.

> The advantage of ra-privacy
> http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy is to have:
>
> ·*an application layer lifetime.*
>
> There are some variables that is used to control “the lifetime of the
> IID”, “the number of application per IID” and “the number of valid IID”.
> The total number of valid IID cannot exceed the max valid IID.  So, The
> difference of this approach with RFC 4941  is that as long as an
> application uses an IID, this IID will not be removed, although, the
> maximum lifetime is reached. But it cannot be used for assigning any new
> application to it. Also always the assign of application to IID is based
> on the highest lifetime. The draft is also handled the exceptional
> situation where the maximum number of IID and the maximum number of
> application per IID are reached. In this case it increase the local
> value which keeps the maximum number of application for a specific IID.
> So it can later play with this value to handle this exceptional
> situation and again set the application to the IID with highest
> lifetime. It also set the lifetime of all IIDs to zero when it receives
> new router advertisement.

Suppose we wanted to have temporary/privacy addresses with quite short 
lifetimes, then I think we'd want a way to quickly remove (invalidate) 
addresses that are no longer used by any applications.

Tracking which sockets have an open connection using a given address can 
definitely help doing that. But what I don't is at what point we'd want 
to discard such an address when there is a socket that refers to it. I'm 
assuming we wouldn't want to keep it around forever.

With your proposed algorithm can't you get in the state where all the 
IIDs have exceeded the lifetime, hence a new applications/sockets can 
not use any of the IIDs? Or is it that in that case all the new 
applications/sockets would end up using the most recently expired IID?

In general if we have shorter lifetimes for temporary/privacy addresses 
then there would be some additional churn - routers and hosts would need 
to add entries to their neighbor caches more frequently and we'd see 
more MLD messages for the solicited node multicast addresses.
I don't know what the sweetspot is in the tradeoff between those 
performance implications and better privacy.

To me the obvious place to improve privacy related to IPv6 addresses is 
to ensure that different IIDs are used when the prefix changes (due to 
mobility or multihoming). For a host at home there might not be much 
benefits in changing the IID frequently within the same /64 prefix, 
because a privacy attacker/snooper could assume that everything from the 
prefix is comes from one or very few devices and associated individuals.

Things are different for hosts at enterprises, public hotspots, etc 
i.e., on links where there are devices that are associated with a larger 
set of individuals. For enterprises there are some tradeoffs between 
various management and security approaches, which might assume that a 
single device has one IID and the privacy of the users when they 
communicate outside of the enterprise.

My 2 cents,
    Erik

Regards,
    Erik