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

[Owen DeLong <[e-mail]>]

>> By definition, a documentation prefix is going to be an exception.
>>  
> 
> Yes, but there has to be code to except it when it is being generated, recorded, precluded from ACLs etc. If fc00:0db8::/32 was used, then a potential future registry would have to exclude that range of prefixes, and assuming the operational rules are applied, then there would be mixed cases where parts of fc00::/8 are permitted/accepted/forwarded and then fc00:0db8::/32 has to either explicitly or implicitly denied/filtered/blocked. I think it is better to make the network's handling of all prefixes within fc00::/8 consistent, with no exceptions.

I don't see that as a significant hurdle. If (and I think that's a big IF at this point) a registry is created, then you prime the registry with an entry for fc00:0db8::/32 as a Doc prefix and you're done.

By definition, any given network which uses space within fc00::/8 will not be able to handle it consistently with no exceptions. They will need to permit the ranges they are using and exclude the rest anyway.

OTOH, any network not using fc00::/8 space can reject all of fc00::/8 without exception.

As such, I think you're pushing a red herring.

>>> I think it would be better to specify a documentation ULA prefix that has 
>> the nearly the properties as conventional ULAs, but doesn't fall within 
>> fc00::/7 (perhaps fe::/7 or something within it?). The only differences would be 
>> statements about no forwarding, no accepting routes etc.
>> 
>> That's an awful lot of space to devote to documentation. Personally, I 
>> thought a /32 was excessive for ULA. A 7 is ridiculous, IMHO.
>>  
> 
> I agree the /7 is large and excessive, and I'm not really advocating for it. I suggested fe::/7 only to make a documentation ULA look similar to and adjacent to the existing non-documentation ULA space, rather than falling within the existing ULA space. Choosing to use a /7 for a documentation ULA would obviously need a lot of thought and justification, and I wouldn't think it'd be likely to be accepted. 

I don't see it as offering any advantages over fc00:0db8::/32, either.

> 
>>> Ultimately though, I think it is fundamentally impossible to prevent 
>> something silly like using documentation prefixes on a production network, 
>> unless you use actually invalid IPv6 prefixes. The only way I can think of to do 
>> that would be by doing things such as adding invalid hexadecimal 'g-z' 
>> numbers into the example prefixes. I'm not sure I like the idea, although it 
>> might cause people who get tripped up on it to go back and think some more about 
>> what they're doing and put more effort into getting it right.
>> 
>> It is impossible to prevent. This aims to:
>> 
>>     1.    Make it less likely.
>>     2.    Make it easier to identify
> 
> This is the key reason I think outside of fc00::/7 would be better.

Since 2001:0db8::/32 has proven to be perfectly viable for this purpose, I thing that argument falls flat.

> 
>>     3.    Cause earlier identification (and thus easier rectification) when it 
>> does occur.
>> 
>> The doc prefix, in order to achieve full value, needs to be implementable in 
>> some training lab scenarios.
> 
> If it is a documentation prefix then I think it should never be implemented in training labs, otherwise it is now more than just a documentation prefix. For a lab, standard ULA prefixes should do fine, and the exercise of students generating and deploying a conventional ULA prefix for their own network would be a good one to teach them how ULAs are to be properly generated and used.

We can agree to disagree on this. Admittedly, I prefer to do as you say above, but there are other instructors that want to allow students to do certain ab initio exercises using the exact book examples. I think both should be supported.

Owen