Re: Additional Documentation Prefixes (was Re: AD Evaluation : draft-ietf-6man-ra-pref64-06)

[Brian E Carpenter <[e-mail]>]

On 04-Nov-19 11:34, Mark Smith wrote:
> 
> 
> On Mon, 4 Nov 2019, 06:33 Brian E Carpenter, <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On 04-Nov-19 06:18, Michael Richardson wrote:
>     >
>     > Suresh Krishnan <[e-mail] <mailto:[e-mail]>> wrote:
>     ...
>     >     >> I'd also like to have three or four additional IPv6 documentation prefixes,
>     >     >> plus some documentation space from ULA-R and ULA-C.
>     >
>     >     > What is ULA-R? Did you mean ULA-L? If so, it would be a pain to reserve
>     >     > something now since we also need to update RFC4193 to make sure that
>     >     > the Random “Global ID”s will not collide with the reserved prefixes. If
>     >     > ULA-C does take off, this would be a good idea to do something like
>     >     > this.
>     >
>     > I guess L=1 is why you call it ULA-L. I have known it as ULA-Random.
>     > We are both talking about RFC4193 though.  So such a document would need to
>     > update RFC4193.
> 
>     I think this is a bad and pointless idea. Pointless because it is 100% OK
>     to use any RFC4193 prefix as an example, since by definition it will never
>     be used on the Internet, and the chance of collision on a given ULA site
>     is 1 in 2**40 (and who cares anyway?). Bad because it means that millions
>     of existing boxes that can generate ULA prefixes would be non-conformant
>     and, seriously, is any vendor going to update date their firmware for this?
> 
> 
> I redacted my ULA in examples in a presentation I did recently. That made it impossible to type in and for somebody to duplicate.
> 
> If the goal is ensure people can't try to use these example addresses on real networks, then perhaps using invalid addresses in the document with a note that they're examples and invalid on purpose is a better idea.
> 
> For example, using non-hexidecimal letters, with a note about them being substitutes for 'a' through 'f'.
> 
> E.g.
> 
> 2001:db8:xxxx:yyyy::zzz1
> 

Yes, that makes sense, and could be applied to link-local and RFC1918
addresses too. It's a much less fiddly solution.

    Brian