On Wed, 20 Oct 2004, Ralph Droms wrote: > I disagree with the wording of this section regarding the use of DHCPv6 for > privacy addresses:
I thought you would, it was just a question when ;-) > At 12:03 AM 10/20/2004 -0400, Suresh Krishnan wrote: > >* Added the following text specifying the conditions for DHCPv6 to be used > >for privacy > > > > "One way to avoid some of the problems discussed above is to use > > DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be > > configured to hand out addresses that change over time. But DHCPv6 > > will solve the privacy issue only if it frequently handed out > > constantly changing addresses to the nodes. Since this does not > > happen automatically, and is difficult to configure manually, DHCPv6 > > is not really suited for solving the privacy issues addressed by this > > document." > > DHCPv6 includes mechanisms for assignment and management > of "temporary addresses" (see section 12 of RFC 3315). The frequency of > reassignment for temporary addresses can be as often as desired, and is > independent of the lifetimes for non-temporary addresses. "difficult to > configure manually" is an entirely subjective assessment, and is dependent > on the specific implementation rather than the protocol itself. The statement was referring to the changing the permanent addresses regularly to avoid giving out stable identifiers. > Therefore, I think the text should be edited to read: > > 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. I think this misses the main point. The text seems to be saying, "if you want privacy, DHCPv6 allocating public + privacy addresses provides you a way to do that", but there is no fundamental reason why to use DHCPv6 for that. Certainly it wouldn't make sense to deploy DHCPv6 privacy address assignment (if public ones are done with SLAAC), right? So, I think the tone of text should be something like: "If DHCPv6 is already used for address assignment, it makes sense to use DHCPv6 for privacy address assignment as well especially if SLAAC is not used at all; if not, using RFC 3041(bis) for privacy addresses makes much more sense" > Finally, at the risk of nit-picking, I wonder if the phrase "without the > necessity of a Dynamic Host Configuration Protocol (DHCP) server" is really > necessary? Is the sole purpose of stateless address autoconfiguration to > avoid the menace of DHCP, or does stateless address autoconfiguration avoid > manual configuration, as well? How about "Nodes use IPv6 stateless address > autoconfiguration generate addresses using a combination of locally > available information and information advertised by routers." (borrowed from > RFC 2462)? No objections from me, even though I don't think that's an issue one way or the other. "Menace of DHCP" for address assignment may or may not be an issue. Beyond that, whether or not DHCP server (e.g., for info requests) exists is irrelevant. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
