>>>>> 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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to