Hi Ralph,
  Please see my comments inline.

Thanks
Suresh

On Wed, 20 Oct 2004, Ralph Droms wrote:

>I disagree with the wording of this section regarding the use of DHCPv6 for
>privacy addresses:
>
>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.
>
>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 see your point, but the text is about ALTERNATIVE approaches to privacy 
addresses, which means that DHCPv6 needs to be able create random 
addresses and rotate the addresses without the aid of the client. 
AFAIK, the IA_TA option requires the client to still generate the 
interface identifier and send it to the server. Nothing in the text 
precludes the use of DHCP to hand out temporary addresses. 

>
>I wonder if section 2.2 is required at all?  I don't think experience with
>IPv4 addressing has much bearing on IPv6.  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 hard.  If
>section 2.2 is retained, some of the details should be corrected.

It is more like "why this problem did not exist with IPv4 in the same 
scale". I would like to retain the text since it provides background 
information. Do you have any specific issues with the text? I will make 
changes to correct any wrong details.

>
>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)?

I retained the text from the previous version because I could not come up 
with anything better and accurate. I will come up with some text which 
will not vilify DHCP ;-)

>
>- Ralph
>
>
>
>
>
>
>--------------------------------------------------------------------
>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
--------------------------------------------------------------------

Reply via email to