Subject: draft-ietf-ipv6-privacy-addrs-v2-04

From: [email-masked]
Date: Thu, 02 Jun 2005 11:01:32 -0500 (CDT)

Good morning all. I'm aware this draft is in AD Review/AD Follow-up status, and hope this is an appropriate time to raise questions (none being rhetorical) and issues. I'd greatly appreciate technical group feedback on the following:

___

In section 3, it is stated 'Deprecated addresses can continue to be used for already established connections...'. In section 3.6 it is stated '... some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions but expects them all to use the same addresses.'

It seems to me that given section 3., the only times when the section 3.6 statement would likely be true is if a session is terminated, then a new one is established.

___

In section 3.5, it is stated 'The value DESYNC_FACTOR is a random value (different for each client) that ensures that clients don't synchronize with each other and generate new addresses at exactly the same time.'

How do we really know if DESYNC_VALUE will be different for each client? The answer doesn't seem to be in this draft.

Presuming DESYNC_VALUE to be an integer (0=lower bound, 600 seconds=MAX_DESYNC_FACTOR=upper bound), there would only be 601 possible values. Thus it seems to me the random number generator used to determine this value is fairly limited.

___

Including in section 5., regarding both the TEMP_VALID_LIFETIME and the TEMP_PREFERRED_LIFETIME values: 'Users should be able to override the default value.' Is the network administrator able to override values set by users? It seems to me administrators should have that ability.

___

Best regards,

Tim Enos
1Sam16:7

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 03 Jun 2005 19:04:24 -0400

Hi Tim,
   Thanks for the comments. Please see my replies inline.

Cheers
Suresh

[email-masked] wrote:
> Good morning all. I'm aware this draft is in AD Review/AD Follow-up 
> status, and hope this is an appropriate time to raise questions (none 
> being rhetorical) and issues. I'd greatly appreciate technical group 
> feedback on the following:
> 
> ___
> 
> In section 3, it is stated 'Deprecated addresses can continue to be used 
> for already established connections...'. In section 3.6 it is stated 
> '... some applications may not behave robustly if temporary addresses 
> are used and an address expires before the application has terminated, 
> or if it opens multiple sessions but expects them all to use the same 
> addresses.'
> 
> It seems to me that given section 3., the only times when the section 
> 3.6 statement would likely be true is if a session is terminated, then a 
> new one is established.

Section 3.6 deals with deployment considerations. The statement you 
quoted is just a warning for implementers to disable use of temporary 
addresses when the applications may not handle them properly.

  "In addition, some applications may not behave
   robustly if temporary addresses are used and an address expires
   before the application has terminated, or if it opens multiple
   sessions, but expects them to all use the same addresses.
   Consequently, the use of temporary addresses SHOULD be disabled by
   default in order to minimize potential disruptions."

So, in summary, section 3 specifies that WHEN temporary addresses ARE 
BEING USED, what should be the behaviour of the system when the 
preferred lifetime expires

Section 3.6 recommends DISABLING temporary addresses if there is a high 
probability of some applications misbehaving because of enabling them.

Does that answer your question? If not, please let me know and maybe we 
can work on some text.

> 
> ___
> 
> In section 3.5, it is stated 'The value DESYNC_FACTOR is a random value 
> (different for each client) that ensures that clients don't synchronize 
> with each other and generate new addresses at exactly the same time.'
> 
> How do we really know if DESYNC_VALUE will be different for each client? 
> The answer doesn't seem to be in this draft.
> 
> Presuming DESYNC_VALUE to be an integer (0=lower bound, 600 
> seconds=MAX_DESYNC_FACTOR=upper bound), there would only be 601 possible 
> values. Thus it seems to me the random number generator used to 
> determine this value is fairly limited.

The granularity of DESYNC_FACTOR is not mandated by the draft. If you 
feel that 600 unique values are not sufficient, you can use a 
DESYNC_FACTOR with millisecond accuracy thus giving you 600000 unique 
values.

> 
> ___
> 
> Including in section 5., regarding both the TEMP_VALID_LIFETIME and the 
> TEMP_PREFERRED_LIFETIME values: 'Users should be able to override the 
> default value.' Is the network administrator able to override values set 
> by users? It seems to me administrators should have that ability.

Actually it was meant to be used the other way. The network admins set 
the default value and the users can override it if their applications 
need different values. If you think admins should have absolute control, 
  you don't have to allow users to override these values (that is why 
the requirement is SHOULD and not MUST) and still be compliant to the 
specification.

---

From: "timothy enos" <[email-masked]>
Date: Mon, 06 Jun 2005 20:55:32 -0400

Hi Suresh,

Thank you also for your reply! My apologies for not having sent mine
sooner; please see inline:

Best regards,

Tim
1Sam16:7

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Friday, June 03, 2005 7:04 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-ipv6-privacy-addrs-v2-04

Hi Tim,

Cheers
Suresh

> addresses when the applications may not handle them properly.

OK. It's just that in the first instance (wherein a temp address expires
before the application has terminated), it still isn't clear to me why
the application would not handle that properly. When would it ever be
the case?

I suppose an app could be written so that it would terminate any
sessions that are using addresses that become deprecated. My thinking is
that it would be better for them to continue to be used. Termination of
the session could be achieved either by user/admin intervention, or by
the expiration of some other timer (e.g. idle timeout). Again not
rhetorical; I truly do not know the answer.

In the second instance, are you referring to an application residing on
one host (call it node A) opening multiple sessions with one other host
(node B), or more than one host (B, C, ...)? 

> Does that answer your question? If not, please let me know and maybe
we 

If possible, I'd like to work on some text (though not a deal breaker if
we do not).

> DESYNC_FACTOR with millisecond accuracy thus giving you 600000 unique 

Ceteris paribus, it seems that having three orders of magnitude more
potential values from which to choose increases our odds of getting the
desired results (nodes generating different values). Not required, but
potentially helpful (and can't imagine it harmful) to explicitly state
that no particular granularity is mandated. 

> the requirement is SHOULD and not MUST) and still be compliant to the 

IMO, even the SHOULD is a bit too strong. While not advocating for a
MUST NOT, I would advocate for a MAY.