Hi, Can you clarify, succinctly, what your proposal adds that you cannot achieve by a combination of http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ and RFC4941?
It seems a key point is that 4941 "only" says SHOULD for the IID regeneration when the prefix changes. Yet afaics all implementations do this? Tim On 23 May 2013, at 16:04, "Hosnieh Rafiee" <[email protected]> wrote: > Follow up, > > I forgot to post the link to the draft :-) > http://tools.ietf.org/rfcdiff?url2=draft-rafiee-6man-ra-privacy > > Thanks, > Best, > Hosnieh > > > > I first want to thank Dave who took the time to read and comment on my draft > and to discuss the problems associated with it. Based on some offline > discussions with Dave, I have changed this document to better address the > current issues with RFC 4941 which are actually related to differences in > interpretation of the wording used in the that document. In many cases the > wording used gives implementations the choice of how best to accomplish the > goal which can lead to bad choices being made which negates the purpose of > the document. This draft is thus an update to the Privacy Extension document > and also, because it does not allow a node to generate and use an IID based > on a MAC address, an update to one section of RFC 4862 which pertains to this. > > In this document an approach is recommend that doesn't make use MAC addresses > in the generation of public addresses. It does, in fact, endorse the use > other approaches that aren't based on the use of MAC addresses in the > generation of public addresses. Public addresses can be valid forever but it > is recommended that, for privacy purposes, a node not make use of public > addresses. > The definition of public addresses here is the same as what Dave explained in > his last responses to the people on this list, i.e., the addresses that need > to have DNS records. In my opinion, these addresses are more useful for > servers than other nodes. > > I appreciate your support and any and all comments that you might proffer. > > Thank you, > Best, > Hosnieh > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
