Jinmei-san - in a private conversation, I made the following
recommendations:
After re-reading draft-ietf-ipv6-privacy-addrs-v2-04.txt, I
think the Abstract is now fine. I would recommend changing the first
sentence of the Introduction to:
Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
node generates addresses using information about available prefixes
obtained through Router Advertisement messages.
I recommend removing section 2.2 (as I did in the earlier post cited
by Suresh), as experience with IPv4 addressing has little bearing on
IPv6. This observation is bolstered by the text in section 2.3
describing the problem addressed by privacy addresses. For example,
a device gets an entirely new IPv4 address when it moves to a new
connection point, so tracking that device as it moves between connection
points is harder than in IPv6. And, I think there is a fundamental problem
that most IPv4 stacks and applications are built on the assumption of a
single address per interface, so privacy addresses would be hard to use in
any event. If section 2.2 is retained, some of the details should be
corrected; e.g., "Over the last few years, sites have begun moving
away from static allocation to dynamic allocation via DHCP [DHCP]."
sounds dated.
I recommend the same text as I recommended before for section 2.4:
One way to avoid some of the problems discussed above is to use
DHCPv6 [DHCPV6] for obtaining addresses. Section 12 of RFC 3315
discusses the use of DHCPv6 for the assignment and management of
"temporary addresses" (privacy addresses). Temporary addresses are
managed separately from non-temporary addresses, so a host can
differentiate between the two types of addresses. The lifetimes of
temporary addresses are independent of the lifetimes of any other
addresses, so the frequency of replacement for temporary addresses
can be adjusted as required.
- Ralph
On 8/24/06 7:48 AM, "JINMEI Tatuya / 神明達哉"
<[EMAIL PROTECTED]> wrote:
>>>>>> On Mon, 21 Aug 2006 14:45:55 -0700,
>>>>>> Bob Hinden <[EMAIL PROTECTED]> said:
>
>>> In particular, the text of Section 2.4, paragraph 1 beginning:
>>> "But DHCPv6 will solve the privacy issue" is new since RFC3041
>>> and seems to make questionable statements about the use of DHCP
>>> for generating temporary addresses, since 1) the server can be
>>> configured to hand out temporary addresses with short preferred/
>>> valid lifetimes, and 2) the client can go back to the server to
>>> get new temporary addresses whenever it wants to regardless of
>>> preferred/valid lifetimes.
>>>
>>> Again, unless I am missing something, suggestions are to
>>> 1) remove this new text from Section 2.4, and 2) relax any
>>> text (including the document title) that links the generation
>>> of privacy addresses with Stateless Address Autoconfiguration.
>
>> I agree that the text in Section 2.4 that is incorrect should be
>> fixed or removed.
>
>> This document is in the IESG for Draft standard, so I think it is out
>> of scope to make broader changes like changing the document title, etc.
>
> I agree with you on both the points. I think we can simply update the
> first paragraph of Section 2.4 to something like this:
>
> One way to avoid having a static non-changing address is to use
> DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server can be
> configured to hand out "temporary addresses", which are never
> renewed and provide the same property of temporary addresses
> described in this document with regards to the privacy concern.
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
>
> p.s., I also think RFC3315 could have been more specific about how to
> update the temporary addresses rather than stating "DHCPv6 says
> nothing about details" (Section 12 of RFC3315). We should eventually
> do that in some place, but (IMO) it's definitely not in
> privacy-addrs-v2. Perhaps we can do it in rfc3315bis in the future...
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
