Let's first start the discussion about the lifetime of an IID. There are some sections in RFC 4941 that explains the lifetime of an IID
The maximum lifetime is 1 week and preferred lifetime is 1 day. The address cannot exceed the maximum lifetime value. When it reaches to this maximum value, the state of this IID will change to deprecated. Section 3.3. http://tools.ietf.org/html/rfc4941#section-3.3 If a received option will extend the lifetime of a public address, the lifetimes of temporary addresses should be extended, subject to the overall constraint that no temporary addresses should ever remain "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR), respectively. This section explains the case where a node receives a new router advertisement with an option to extend the lifetime of its IID. So, if the maximum lifetime is not reached, it does it. (might not change IID when receives new RA) Section 3.4. http://tools.ietf.org/html/rfc4941#section-3.4 As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or upper layers as detailed in Section 6 <http://tools.ietf.org/html/rfc4941#section-6> . Section 6 http://tools.ietf.org/html/rfc4941#section-6 An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when they become invalid [ADDRCONF <http://tools.ietf.org/html/rfc4941#ref-ADDRCONF> ], independent of whether or not upper layer protocols are still using them. For TCP connections, such information is available in control blocks. For UDP-based applications, it may be the case that only the applications have knowledge about what addresses are actually in use. Consequently, an implementation generally will need to use heuristics in deciding when an address is no longer in use. >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. 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. 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. . Introduces an highly randomized algorithm for use in place of the algorithm used in RFC 4941 that is preferable because there is no stable storage is needed Other updates: . In case the first approach is used, it changes the word "might" to "should" or MUST in order to force application use randomization RFC. If there are any more issues that I need to concern please leave your comment here. Thanks, Hosnieh
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
