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

[Mark Smith <[e-mail]>]

>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: Mark Smith <[e-mail]> 
>Cc: "[e-mail] WG" <[e-mail]>; "[e-mail]" <[e-mail]> 
>Sent: Thursday, 30 May 2013 7:07 PM
>Subject: Re: [v6ops] A good example of why we need to careful about ULAs
> 
>
>
>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?
>

I don't agree with trying to create a registry for the non-centrally assigned ULAs (because I think those people probably think they now own that prefix), however here is quite a list to show that a lot of people from a variety of organisations get that ULAs aren't set to fd00::/8

http://www.sixxs.net/tools/grh/ula/list/


>
>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.
>

Agree with documenting it. Site-locals were "fd00::". The site-local deprecation RFC is pretty much the inverse of all the ways ULAs aren't site-locals and RFC1918s.

>
>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.
>
>

Ok. So then a follow up question is how to provide perhaps more tutorial oriented information? RFCs, quite reasonably, provide enough information to justify what is proposed, and usually one use case, but not all of them. That may not be enough information for more of a novice fully understand the problem that is being solved, the variety of opportunities to use it, and the pros and cons of the use of what is proposed in those scenarios. I haven't thought v6ops was just a place to document what has been done, but rather to document any topics related to operations, including advice and more information on how things invented here and in other IPv6 working groups could be used.

Regards,
Mark.