Please DO NOT enable privacy extensions by default. For enterprise networks, this causes serious headaches, and is a very bad idea. There are good reasons why the RFC says this should be disabled by default. It impacts address management, DNS updates, forensics in response to incidents, ability to correlate and analyze logs, to name a few of the issues.
The RFC does say that systems administrators should be able to enable or disable this feature. But no mechanism is offered to network administrators who may want to enable or disable this across the networks that they manage. And most network administrators of IPv6-enabled enterprise networks will tell you how much they hate this feature and it's being the default in Microsoft implementations.
We outlaw IPv6 privacy extensions in our enterprise network, and even had to write scanning tools to track down all the systems that have it enabled, and then have to instruct the admins on what registry settings they have to change to disable it. It kills the beauty of IPv6 auto-configuration (plug-n-play) for us, because now we are forced into human intervention for each new Windows system that plugs into our network. We hate it.
When pointing out to Microsoft how their current default is a very bad idea, they just tell you that you can disable it globally using Active Directory. But that does no good for networks that don't run AD, or where only a portion of their Microsoft systems are controlled by AD. The one saving grace has been that only Microsoft has made this mistake, and our Linux, Solaris, Mac OSX, and other operating systems are still doing the right thing.
Another solution sometimes offered is DHCPv6. That is not an complete solution today because a significant portion of the installed base does not include any DHCPv6 client support.
Don't make the mistake that Microsoft did by enabling this by default. Leave it disabled, but then allow systems administrators to enable it when desired and when local policy allows.
Please DO NOT enable privacy extensions by default. For enterprise networks, this causes serious headaches, and is a very bad idea. There are good reasons why the RFC says this should be disabled by default. It impacts address management, DNS updates, forensics in response to incidents, ability to correlate and analyze logs, to name a few of the issues.
The RFC does say that systems administrators should be able to enable or disable this feature. But no mechanism is offered to network administrators who may want to enable or disable this across the networks that they manage. And most network administrators of IPv6-enabled enterprise networks will tell you how much they hate this feature and it's being the default in Microsoft implementations.
We outlaw IPv6 privacy extensions in our enterprise network, and even had to write scanning tools to track down all the systems that have it enabled, and then have to instruct the admins on what registry settings they have to change to disable it. It kills the beauty of IPv6 auto-configuration (plug-n-play) for us, because now we are forced into human intervention for each new Windows system that plugs into our network. We hate it.
When pointing out to Microsoft how their current default is a very bad idea, they just tell you that you can disable it globally using Active Directory. But that does no good for networks that don't run AD, or where only a portion of their Microsoft systems are controlled by AD. The one saving grace has been that only Microsoft has made this mistake, and our Linux, Solaris, Mac OSX, and other operating systems are still doing the right thing.
Another solution sometimes offered is DHCPv6. That is not an complete solution today because a significant portion of the installed base does not include any DHCPv6 client support.
Don't make the mistake that Microsoft did by enabling this by default. Leave it disabled, but then allow systems administrators to enable it when desired and when local policy allows.