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

[Suresh Krishnan <[e-mail]>]

Hi Michael,

> On Nov 3, 2019, at 12:18 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Suresh Krishnan <[e-mail]> wrote:
>>> I agree with you.
>>> 
>>>> Is there a larger documentation prefix than 192.0.2.0/24?
>>> 
>>> I wish that there was.
> 
>> Me too. I also think a larger prefix could be useful. Similarly a block
>> that would differentiate it as an example of private space to be used.
> 
>>> Maybe we could carve out of class E space as a /20 of documentation space.
> 
>> Sounds like a plan. If you write something up, I would be willing to AD
>> sponsor something like this. The biggest issue with repurposing E space
>> was that it would hit a lot of bogon filters. In this case that is a
>> desirable feature.
> 
> Okay, I will write something if there is further support.
> Should it update or replace RFC5737?

Either would work for me (with a slight preference for replacing). Write up the draft and ask for a slot in intarea if possible to gauge community interest in this. I can take it from there.

> 
>>> 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'd like the IPv6 documentation prefixes to have a pretty high Hamming
>>> Distance from each other to maximize the visual distinction.
> 
>> We have a /32 for this. Plenty of ways to be visually distinct
>> including some of the common ones I have used :-)
> 
>> 2001:db8:abba::/48
>> 2001:db8:beef::/48
>> 2001:db8:cafe::/48
>> 2001:db8:dead::/48
>> 2001:db8:face::/48
>> 2001:db8:c001::/48
> 
> I'm not sure that I agree.
> I don't see why we need to be so stingy about Documentation Prefixes in IPv6.
> Using part of 3ffe::/16 would appeal to me.


In case I was not clear above, I was just stating that I didn't *personally* see a need for an additional prefix block. If there is a community backed proposal to do so, I would consider myself in the rough and move aside :-).

Thanks
Suresh