Subject: comments about draft-ietf-ipv6-privacy-addrs-v2-01

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 09 Nov 2004 12:21:58 +0900

Hello,

Here are my comments on draft-ietf-ipv6-privacy-addrs-v2-01.  I have
two major concerns which I believe should be addressed before being
submitted to the IESG.  I also found number of less significant points
(most of them are just editorial, but some may still be substantial).

*** Major concerns ***

1. 64-bit assumption

This document apparently assumes 64-bit interface identifiers.
However, our consensus in the rfc2462bis discussion was that we cannot
always assume that particular length for interface identifiers.  And,
in fact, the latest version of rfc2462bis does even not contain that
particular number.  It now reads, for example:

   interface identifier - a link-dependent identifier for an interface
      that is (at least) unique per link [RFC3513].  [...] The
      exact length of an interface identifier and the way it is created
      is defined in a separate link-type specific document that covers
      issues related to the transmission of IP over a particular link
      type (e.g., [RFC2464]).  Note that the address architecture
      [RFC3513] also defines the length of the interface identifiers for
      some set of addresses, but the two sets of definitions must be
      consistent.  [...]

If we are revising this document along with rfc2462bis (and this is my
understanding), I believe it should reflect the consensus on the IFID
length.  Specifically,

- it should not hard-code the fixed constant of 64.
- bullet 3 of Section 3.2.1 (how to create random IFID) should be
  revised to clarify this rule only applies to a certain type of
  interface IDs (i.e., only when "bit 6" has a special semantics).

2. Reference to ISATAP
  The draft refers to the ISATAP document as an informational one as
  follows:

   A randomized interface identifier is created as follows:
   [...]

   4.  Compare the generated identifier against a list of known values
       that should not be used.  Inappropriate values include those used
       in reserved anycast addresses [RFC2526], those used by ISATAP
       [ISATAP], the value 0, and those already assigned to an address
       on the local device.  [...]

  IMO, in this context the reference to ISATAP should be normative.
  In fact, if I were going to implement the privacy-addrs-v2
  specification, I'd have to hard-code the particular type of suffix
  for ISATAP.  So, in this sense, this reference is an essential part
  to understand/implement privacy-addrs-v2 itself; too essential to be
  referred to as informational.

  And then we'll encounter a down-reference problem; the ISATAP
  document is currently just a draft, and even if it becomes an RFC,
  it cannot become a DS so soon (I assume privacy-addrs-v2 is being
  revised to become a DS).

*** Semi substantial comments ***

3. In the 3rd paragraph of Section 1, the draft says

   [...]  The focus of this
   document is on addresses derived from IEEE identifiers, as the
   concern being addressed exists only in those cases where the
   interface identifier is globally unique and non-changing.

But, as far as I can see, "the concern" is not clearly identified
beforehand.  I guess we should somehow reorganize this section so that
we can first clearly define the concern and then discuss it.

4. In the 2nd paragraph of Section 2.2, it says

   [...]  Such users do not have permanent
   connections and are often assigned temporary addresses each time they
   connect to their ISP (e.g., AOL).

Should we really bother to mention AOL?  I don't think referring to a
particular company is appropriate in this kind of general
specification, and, IMO, we can convey the original intent without the
example ISP name.  So, I'd simply remove this example.

5. In the fourth paragraph of Section 2.2, it says:

   [...]  Although Dynamic DNS [DDNS] can be
   used to update the DNS dynamically, it is not yet widely deployed.

I see two problems in this sentence.  First, in my understanding,
dynamic DNS is quite widely deployed.  At least it's controversial
whether or how widely it is deployed right now.  Secondly, even if
this statement is true at this moment, we cannot be sure about it in
the near future (say, 3-5 years later).  I basically believe we should
not rely on the fact that is (or may be) only the case in a limited
period when we are trying to make a stable document.

So, I'd say:

   [...]  Although Dynamic DNS [DDNS] can be
   used to update the DNS dynamically, it is not always available
   depending on the administrator's policy.

I believe this statement is correct today, and will still be the case
in the future, regardless of how widely DDNS is deployed.

6. I cannot fully follow the logic of the first paragraph of Section
   2.4.  It seems to (mainly) talk about non-nomadic hosts configuring
   itself through DHCPv6 and about the privacy concern in this case
   when DHCPv6 does not frequently change the address.  But just
   before this part, the draft says in section 2.3 that one major
   troubling case for IPv6 is about nomadic hosts which can be tracked
   with their 64-bit IFIDs.  If this is really the main concern, can't
   DHCPv6 be a perfect solution?  That is, the DHCPv6 server in the
   new link can provide a different address with the nomadic node,
   which is independent from the previous address and is thus non
   trackable.

   I don't think this is an essential flaw of the document, but is
   just a matter of document context.  So, please clarify the problem
   and solution space once more so that we (or I at least) won't be
   confused.

7. bullet 3 of Section 3.3 currently says:

   3.  When a new public address is created as described in [ADDRCONF]
       (because the prefix advertised does not match the prefix of any
       address already assigned to the interface, and the Valid Lifetime
       in the option is not zero), the node SHOULD also create a new
       temporary address.
   (where [ADDRCONF] refers to rfc2462bis)

  This is not fully synchronized with a recent clarification of
  rfc2462bis.  The corresponding part in rfc2462bis now reads:

    d) If the prefix advertised is not equal to the prefix of an address
      configured by stateless autoconfiguration already in the list of
      addresses associated with the interface (where "equal" means the
      two prefix lengths are the same and the first prefix-length bits
      of the prefixes are identical), and the Valid Lifetime is not 0,
      form an address (and add it to the list) by [...]

  The major changes are that we now say "equal" instead of "match",
  and we clearly say we only consider addresses **configured by
  stateless autoconf** in the list.

  We should either
    - update the description of privacy-addrs-v2 accordingly, or
    - simply remove this part from privacy-addrs-v2 (and just refer to
      [ADDRCONF])

  I personally think the second approach is easy and enough.

8. bullets 4 and 11 of Section 7 (changes from RFC3041) seem to say
   almost the same thing.  Those should be unified.

*** Minor editorial comments and nits ***

9. In the fourth paragraph of Section 1

   document  to collectively refer to "Global unicast addresses" as

   s/document  to/document to/ (redundant white space)

10. We need a "period" at the end of the last paragraph of Section
    1.1.

11. In the second paragraph of Section 2.4,

   Another approach, compatible with the stateless address
   autoconfiguration architecture, would be to change the interface id
   portion of an address over time and generate new addresses from the
   [...]

 I would rephrase "interface id" with "interface identifier".  Or at
 least we should say "interface ID".

12. In the first sentence of Section 3.2.3

   Please note that there are other approaches to generate random
   interface identifiers, albeit with different goals and applicability.

 I'd avoid using an "informal" wording like "Please ...." in a formal
 document such as an RFC.  But this may be a matter of taste.

13. In bullet 1 of section 3.3,

       (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or
       (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively.  [...]

  I guess we need space characters before and after '-' for
  readability.

14. In the first paragraph of Section 3.4,

   Lifetime, then a new temporary address MUST NOT be generated.To

 We need a white space before "To".

15. There seems to be strange blank space at the top of Page 16.

16. We need a "period" at the end of Section 3.4.

17. We need a "period" at the end of Section 3.5.

18. In the second last paragraph of Section 3.6,

   [...]
   into an DNS name.  In addition, some applications may not behave

"an DNS name" should be "a DNS name".

19. In the last paragraph of Section 3.6,

   If a very small number of nodes(say only one) use a given prefix for
   extended   periods of time, [...]

I guess we need a space character between "nodes" and "(say only
one)".

Also, "extended   periods" should be "extended periods". (redundant
white space)

20. In the last paragraph of Section 3.6,

   [...]
   part of the prefix  may not be sufficient to ensure privacy, since
   [...]

shouldn't "prefix" be "address"?  (Otherwise, what do you mean by 'part
of the prefix' in this context?)

And, at least "prefix  may" should be "prefix may" (redundant white
space)

21. We need a "period" at the end of Section 3.6.

22. In the second paragraph of Section 6,

   The determination as to whether to use public vs.  temporary
   [...]

"vs.  temporary" should be "vs. temporary".  (redundant white space)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 10 Nov 2004 10:28:40 -0500 (EST)

Hi Tatuya,
  Thanks for your comments. I am making all the editorial changes 
you suggested. For the other stuff, please find comments inline.

Thanks
Suresh

>  interface IDs (i.e., only when "bit 6" has a special semantics).

Since the document only addresses interface identifiers constructed from 
IEEE identifiers (i.e. modified EUI-64s) I am inclined to leave it as it 
is. However, I will put this question to the WG in tomorrow's meeting to 
get a feel of what they think.

>  it cannot become a DS so soon (I assume privacy-addrs-v2 is being

That is why I moved it to informational ;-). I will also raise this 
at the WG meeting tomorrow as I see no proper way out of this. ISATAP will 
NEVER become a DS as it will be published as EXPERIMENTAL. So it is 
not just a question of delays. The question is whether this draft should 
acknowledge the existence of an experimental protocol.

>we can first clearly define the concern and then discuss it.

OK. Will do.

>example ISP name.  So, I'd simply remove this example.

Removed. 

>in the future, regardless of how widely DDNS is deployed.

Sounds good.

>   and solution space once more so that we (or I at least) won't be

I propose the following change to the first line of the paragraph

"One way to avoid some of the problems discussed above is to use
 DHCPv6 [DHCPV6] for obtaining addresses"

"One way to avoid having a static non-changing address is to use
 DHCPv6 [DHCPv6] for obtaining addresses."

Does that work for you?

>  I personally think the second approach is easy and enough.

I have just referenced RFC2462bis and removed the text in parantheses.

>   almost the same thing.  Those should be unified.

Good catch. I have removed 11.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Nov 2004 13:39:02 -0500

> acknowledge the existence of an experimental protocol.

One data point we need to consider.  Explicitly listing invalid 
interface
IDs will be a never-ending process.  Which means this document may
never get done if we leave in such references.

Perhaps we need to re-word this bullet to just point out the need
to check the validity of the generated ID.

Regards,
Brian

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 11 Nov 2004 15:45:43 +0900

Some quick responses...

>>>>> On Wed, 10 Nov 2004 10:28:40 -0500 (EST), 
>>>>> Suresh Krishnan <[email-masked]> said:

>> 1. 64-bit assumption

(snip)

> get a feel of what they think.

Hmm..., while I can imagine the same approach for privacy extension
can be applied to other types (future) of interface IDs, I won't
oppose to this resolution as long as the privacy address document does
not convey the impression that any IFIDs have the fixed length (64)
(or in other words, as long as this document clearly says it only
applies to the modified EUI-64 type of IFIDs).

>> 2. Reference to ISATAP

(snip)

> acknowledge the existence of an experimental protocol.

The "easiest" resolution is to keep it informational.  I personally
think it's irresponsible, but I won't necessarily make an objection to
that if the majority of wg accepts that.

Another possible approach is to "generalize" the description so that
we'll only mention the "characteristic" of the IFIDs which should not
be used as the IFID of a temporary address, without providing any
specific references.  I guess this is essentially the same as Brian's
proposal.  Personally, I can live with this approach.

BTW: regardless of how we deal with the reference to ISATAP, we'll
need the same issue with the reference to RFC2526, which is currently
a normative reference but the RFC is still PS.

					JINMEI, Tatuya

---

From: Fred Templin <[email-masked]>
Date: Thu, 11 Nov 2004 03:35:33 -0800 (PST)

(snip)

Better yet, I think we should institute a new reference category: "Obfuscational"
to go with the existing "Normative" and "Informational". Obfuscational references
are those used to intentionally confuse the reader, as opposed to the other
categories which have confusion as an unadvertised side benefit.
 
BTW, every time I have mentioned the "I*" word on this list the chairs have
acted quickly and firmly to shut down the discussion, so I guess it's OK now?
 
Thanks - Fred
[email-masked]