Hosnieh, "an application layer lifetime".
1) The problem that this is a solution for. I've looked through the draft multiple times, and what I see is a generic abstract and then a very specific dive-in into the details. What I think is very much missing is - what is the application you see in mind that would use this ? How would it look like to the user ? What is the trigger for the app to request an address ? 2) The cohabitation with other hosts and the network devices How does the app knows that it *can* request an address ? As I told: my employer's WiFi gear, based on the RFC you quoted and parameters therein, has a limit of 8 addresses per IPv6 host. With the default settings, if you use more than 8 addresses within 5 minutes, the latest addresses will be simply blocked. There is no mechanism today to communicate this kind of network parameters back to hosts, and at a minimum I think it should be added. I think having such a mechanism could be a very useful contribution to the protocol - and is in my opinion an integral part of such a proposal that allows to increase the frequency with which the host generates the addresses. 3) The state of the art in this. This is from my mac: ast login: Wed Jul 31 14:51:11 on ttys007 ayourtch-mac:~ ayourtch$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 28:cf:e9:1d:22:f7 inet6 fe80::2acf:e9ff:fe1d:22f7%en0 prefixlen 64 scopeid 0x4 inet 130.129.17.232 netmask 0xfffff800 broadcast 130.129.23.255 inet6 2001:df8::16:2acf:e9ff:fe1d:22f7 prefixlen 64 autoconf inet6 2001:df8::16:6110:66b2:eca2:cf4c prefixlen 64 autoconf temporary media: autoselect status: active **** disconnect wifi, reconnect wifi **** ayourtch-mac:~ ayourtch$ ifconfig en0 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 28:cf:e9:1d:22:f7 inet6 fe80::2acf:e9ff:fe1d:22f7%en0 prefixlen 64 scopeid 0x4 inet 130.129.17.232 netmask 0xfffff800 broadcast 130.129.23.255 inet6 2001:df8::16:2acf:e9ff:fe1d:22f7 prefixlen 64 autoconf inet6 2001:df8::16:f9f9:fb2:2767:5caf prefixlen 64 autoconf temporary media: autoselect status: active ayourtch-mac:~ ayourtch$ So, given that I also have to clear cookies, etc. etc. today to get any semblance of the privacy: I can as well flip the wifi. So, it is not as bad :-) Also, you saw the presentation from Guillaume - it's dramatically changed in the past 2 years. So, again - I'd like to see more text about the problem being solved, and interaction with the user. thanks! :-) --a On Wed, Jul 31, 2013 at 1:12 PM, Hosnieh Rafiee <i...@rozanak.com> wrote: > 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 --------------------------------------------------------------------
