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 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
