> On 03/05/2013 18:49, Ray Hunter wrote: > > > > Hosnieh Rafiee wrote: > >> Fernando, > >> > >> The purpose of your draft was not to obsolete or update RFC 4941 and > >> you wanted to have your approach as an optional approach in parallel > >> with that approach. So what is your problem with improving that > >> document. It has nothing to do with your proposal. The people can > >> accept or reject yours. I do not see any harmful behavior here as I > >> also asked you 1000 times to update that rfc instead of having something > new or in between two RFCs. > >> > >> Hosnieh > > > > IMHO You are missing how the standards documents relate to each other. > > > > The base problem is that RFC4862 (IPv6 Stateless Address Autoconfiguration) > uses an IID defined in RFC4291 (IP Version 6 Addressing Architecture) Appendix > A. > > > > The fact that IID's are derived from EUI64 identifiers using a reversible > transformation (RFC4291 Appendix A) means that the IID portion of an IPV6 > SLAAC address can be used to infer privacy information about living persons > carrying a particular device. > > > > > RFC4941 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) > attempted to plug that gap. > > > > RFC4941 did NOT directly update RFC4862 nor RFC4291: it was an optional > extension to 4862. This update method was chosen so that RFC4941 was > backwards compatible with existing implementations (goal #1 of 4941 Section > 3). RFC4941 addresses outbound connections. But RFC4941 is an incomplete > solution: nodes implementing RFC4941 still respond on the native SLAAC > address generated by RFC4862. > > > > > > draft-ietf-6man-stable-privacy-addresses plugs that vestigial problem with > nodes responding on RFC4862 SLAAC generated addresses, whether RFC4941 > has been implemented or not. > > > > > > If draft-ietf-6man-stable-privacy-addresses updated RFC4941, it would miss > out all implementations that did not implement (the optional) RFC4941, so > those nodes would be left with a problem. > > > > If draft-ietf-6man-stable-privacy-addresses updated RFC4862, it would mean > all existing implementations would have to be mandatorily updated. There's no > need for this to guarantee interoperability, and it would clearly be > undesirable > to deprecate existing implementations (which is why RFC4941 included goal > #1). > > > > In the future there may even be better alternatives to RFC4941 and > > draft-ietf- > 6man-stable-privacy-addresses. > > > > IMHO These proposed solutions are all orthogonal, and are therefore best > defined in independent standards (that use each other as normative > references). > > Exactly
I have already responded to Ray about this. FYI: I have included that response here. "We are on the same page. Probably you read the following proposal. That email and his defensive reaction was because he thinks I want to have his proposal. http://tools.ietf.org/html/draft-rafiee-6man-ra-privacy-00 I wrote this yesterday after I found out that his purpose is to have a new optional approach. You can read it. The total text is two pages. It has nothing to do with his proposal. It is just an improvement on RFC 4941. If you see any overlap let me know and I will remove it. My plan is not to steal his idea or his proposal but to just improve the current document." My concern is also about privacy in a same network and I see it as an important issue. I think that by making a small update to RFC 4941, this will take care the problem. However, some people seem to think that this RFC does not maintain privacy very well. Finally, implementations or RFCs have never been as fast as new RFCs. This means nobody expects that vendors will immediately update their implementations with new options. In the off list messages exchanged between us, I explained this and asked Fernando whether or not he wants to also cover this privacy issue or he does not still see it as a problem and wants to have a stable IID in the same network. If he covers, I have no more need for my proposal and I can withdraw it but if he does not, then I will keep it because many implementations would rather implement RFC 4941. So why not update it? Hosnieh -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
