[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments about draft-ietf-ipv6-privacy-addrs-v2-01
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
If we are revising this document along with rfc2462bis (and this is my
understanding), I believe it should reflect the consensus on the IFID
- 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
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
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
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
(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
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
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_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. [...]
I guess we need space characters before and after '-' for
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
Also, "extended periods" should be "extended periods". (redundant
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
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)
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6