Re: [v6ops] A good example of why we need to careful about ULAs

[Lorenzo Colitti <[e-mail]>]

On Thu, May 30, 2013 at 5:11 PM, Mark Smith <[e-mail]>wrote:

> In the early news, not really a new problem.
>

The part where an RFC asserts says that we can generate globally unique
addresses with no global coordination is a new problem. Yes, in theory it
works, but in practice it doesn't, because everyone ends up using fd00:: -
because that's the way it worked in IPv4, and ULA is just RFC1918 all over
again, right?

The key point here is that people are going to assume is that ULA is like
RFC1918 and we should carefully document all the ways in which it isn't.

So is this draft aiming for BCP status and therefore should only reflect
> best common practice?
>

I think documents coming out of v6ops should reflect scenarios where there
is operational experience. I don't think v6ops is the place to say "here's
what we could build". It's the place to say "here's what we've built;
here's what works, and here's what doesn't".

As an example: we've already discovered one of the use cases in this draft
(the "use ULA as a pref64") is not a use case after all, because it causes
devices to prefer IPv4 transition technologies like 464xlat over NAT64. We
didn't know this because nobody had actually tried to *operate a network*
in such a use case. I happened to catch that one because I wrote and tested
an implementation, but who knows if there are caveats in any of the others?

If as an operational group we publish guidance to operators that doesn't
work in the real world (like the pref64 case above), it will be
embarrassing for us and wasteful of operators' time. We should strive to do
better than that.