I'm sorry for introducing other recommendations into your thread. I forwarded comments from a private exchange about the draft. I'll separate the other recommendations out into a different thread.
I don't have a strong opinion about your text, either and perhaps brevity is a virtue. How about: One way to avoid having a static non-changing address 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", which are never renewed and provide the same property of temporary addresses described in this document with regards to the privacy concern. - Ralph On 8/25/06 2:49 AM, "JINMEI Tatuya / 神明達哉" <[EMAIL PROTECTED]> wrote: >>>>>> On Thu, 24 Aug 2006 17:08:55 -0400, >>>>>> Ralph Droms <[EMAIL PROTECTED]> said: > >> Jinmei-san - in a private conversation, I made the following >> recommendations: > > (snip) > >> 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. > > If I understand the context correctly, this is the only recommendation > regarding this thread, right? So I'm responding to this part first: > > I don't have an objection to your recommended text. I personally > think this is too much for this document and prefer mine, but it's > probably a matter of taste. > > I'm not sure if we want to discuss the other recommendations right now > on this thread, but I'm going to provide short responses: > >> 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'm fine with removing the reference to DHCPv6, but then I'd like to > change "how an IPv6 node generates addresses" to "how an IPv6 node > autonomously generates addresses" so that the important characteristic > of stateless address autoconfiguration is clear. > >> 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 don't have a strong opinion on this, but I personally think the > current text is okay as general background information, and it doesn't > sound odd to me. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
