[148863] in North American Network Operators' Group
Re: using ULA for 'hidden' v6 devices?
daemon@ATHENA.MIT.EDU (Justin M. Streiner)
Wed Jan 25 12:55:36 2012
Date: Wed, 25 Jan 2012 12:55:11 -0500 (EST)
From: "Justin M. Streiner" <streiner@cluebyfour.org>
To: nanog@nanog.org
In-Reply-To: <CALFTrnPDH6BOgNqGyGGMmWjO1tw3gCDtwSgS_8ewMcXZBbcXvA@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
