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). best regards, RayH <snip> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
