Subject: lifetime of the IID - RFC 4941

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 31 Jul 2013 13:12:41 +0200

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

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 31 Jul 2013 20:17:26 +0200

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 <[email-masked]> 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.*
>
> ** **
>
> 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.*
>
> * *
>
> independent of the upper layer protocols.****
>
> ** **
>
> 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.  ****
>
> ** **
>
> 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.****
>
> ** **
>
> comment here.****
> ** **
> Thanks,****
> Hosnieh****