[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.
					jinmei@xxxxxxxxxxxxxxxxxxxxx

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------