Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

["Antonio M. Moreiras" <[e-mail]>]

On 11/08/13 21:27, Mark Andrews wrote:
> In message <[e-mail]>, "Antonio M. Moreiras" writes:
>> On 11/08/13 19:29, Owen DeLong wrote:
>>> I support the idea. It might be worth also asking for a ULA Doc slice at th
>> e same time.
>>> I think a /48 is probably sufficient for most ULA examples.
>>>
>>> But I think it would be good to be able to write up ULA examples and traini
>> ng that use
>>> actual ULA prefixes intended for documentation.
>>
>> I agree. An organization could generate an ULA prefix specifically to
>> use in a course, or document. But it could be copied and used in
>> production environments. This would break the "global uniqueness", and
>> could lead to other problems.
> 
> FUD.
> 
> You either do the correct thing and generate your own prefix or you
> don't and copy one and hope that no one else has copied it that you
> are connecting to.  Having a reserved prefix will not help you here.

I can agree with you, in parts.

We should expect that people generate their own ULA prefix, following
RFC 4193.

But can we count on that? I think that one of the points in having
documentation prefixes it's because they can be filtered "in advance" in
our networks. So if an intern, a trainee, or a newbie just copy the
configs from a howto document, and manages to put it in our production
environment, we will be safe.

So, let's suppose that you write a brilliant book, or howto, about how
to use ULA addresses in some kind of application for a corporate
network. Let's suppose that you generate your own ULA for your document.
Your prefix may be copied and implemented in hundreds, maybe thousands
of networks.

It isn't a big problem, because ULA is for private use. But if two of
these companies merge, or have some kind of private agreement and want
to connect their networks and make their ULA blocks reachable, it would
be a problem... Ok, it is a big if.

But, what would be the downside of having an ULA prefix reserved for
documentation?

If the local filters are updated and block this prefix, when a newbie
try to copy your example and put it to work, it will not work. He will
realize that he is doing something wrong, and maybe he can learn how he
can use ULA addresses in the right way.

Please let's also remember that the current version of the *draft is not
asking for an ULA documentation prefix*.

The draft is asking for a bigger *unicast global* prefix for documentation.

> ULA are not "globally unique", they are locally unique with a
> extrememly low probability of collision when *locally* connecting.
> If you use them in a global context (i.e. publish to the world in
> AAAA records) without some global differentiator you will cause
> problems.
> 
> All a documentation prefix will do is have one potentially toxic
> prefix compared to a handful of potentially toxic prefixes.  There
> are 1099511627776 prefixes in fd00::/8.  Even if there were thousands
> of documentation prefixes the odds of you hitting one when generating
> your own prefix are astronomically small.  Additionally the more
> prefixes that are used in documentation the less toxic a particular
> prefix will be.
> 
> Mark
> 
>> It would be nice to have a specific ULA documentation prefix.
>>
>> I would suggest a prefix with the L bit cleared, easy to remember, and
>> maybe slightly shorter than /48. For example FC00:0:D0C0::/44.
>>
>> []s
>> Moreiras.