Some of my clients operate pretty large enterprise networks. Within those networks, they want to avoid using the so-called "privacy IPv6 addresses" because of requirements (e.g. the US HIPAA law) to be able to audit their network, including auditing precisely which devices are present.
IPv6 SLAAC works fine for this, provided that the so-called IPv6 privacy addresses are not used. DHCPv6 also could work, but has substantial deployment costs, including recurring operational costs, making it a visibly more expensive deployment approach than SLAAC. So at least some of my enterprise network clients would be very interested in seeing a SLAAC flag be created to inform end systems that the so-called IPv6 privacy addresses are NOT to be used with a given routing-prefix advertised via IPv6 RA messages. So I think it would be valuable for the WG to explore the ideas of this I-D. The document itself is clearly not yet mature, however. 1) The "Introduction" of this I-D needs additional editorial work to clarify the broader range of reasons (some examples are provided above) why this flag might be useful within some IPv6 deployments. 2A) The "Security Considerations" needs to include a thorough and serious discussion of the differences in user privacy expectations between corporate/enterprise network deployments and home/residential network deployments. 2B) Within home/residential deployments, use of privacy addressing ought NOT be disabled operationally because there is a reasonable expectation of privacy when a user is on his/her home/residential network. This advice needs to be clearly documented within this I-D in the Security Considerations section. One last thing. A number of my clients have a very crisp perception that the ongoing IETF IPv6 WG activity to add/change specifications means that "IPv6 is NOT yet ready to deploy operationally". I think this perception is pretty widespread. Reducing the rate of change/addition to the IPv6 specification set generally would be helpful to encouraging IPv6 deployment. I'm not suggesting zero changes/additions, but instead suggesting that the WG carefully consider whether a proposed change/addition is really useful and whether it needs to be undertaken now/soon as part of considering each proposed change/addition to the IPv6 specifications. A lower rate of change/addition will tend to speed IPv6 deployment, in my estimation. Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
