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