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 think that draft-ietf-6man-ug clarifies this to some extent, as a side-effect of clarifying the U/G bits. Would it be useful to add an extra sentence in that draft, simply stating that a number of independent methods for forming an IID can exist? Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------