On Wed, 25 Jan 2012, Ray Soucy wrote:
We've used RFC1918 space for years (without NAT) for non-routed device management (switches, printers, IP phones, etc).
And we've done the same.
The idea behind the random bits was to avoid conflicts should organizations making use of ULA merge.
I'm also thinking down the road to possible cases where an internal host needs to be able to communicate with an internal host at another organization over a VPN tunnel, and a convincing argument can't be made for using public addresses - something that's pretty common today in the v4 world. The thought of having to something equivalent to NAT-T for v6 doesn't fill my heart (or my VPN termination devices) with joy... Along somewhat similar lines, I don't know if any of the relevant regulatory bodies have made any specific comments related to securing networks that are interconnected using v6. Also being in the higher-ed world, I'm thinking along the lines of HIPAA, GLB, SOX, and friends. The answer might be out there - I just haven't looked into it yet.
Locally managed means locally manage, though. The RFC is more of a suggestion than a requirement at that point.
Right, though it's a shame that the registry-assigned ULA concept didn't take off.
Since it's unenforceable, and the standards require it to function regardless, I do suspect that many will opt for a "random" value of zero to keep the notation short and sweet, despite the RFC, or develop an internal addressing schema for ULA space that works for them operationally.
So it stands a good chance of turning into the wild west ;) jms