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

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Owen DeLong <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>
> Cc: "George, Wes" <[e-mail]>; "[e-mail]" <[e-mail]>
> Sent: Thursday, 15 August 2013 6:17 AM
> Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
> 
>>>> 
>>>>  [WEG] at the risk of debating bikeshed colors, I would suggest 
> perhaps 
>>>  using :db8:: for both the proposed GUA and ULA doc prefixes so that it 
> serves as 
>>>  a visual cue.
>>> 
>>>  I have no problem with that.
>>> 
>>>  How about 02db:8000::/20 and fc00:0db8::/32?
>>>   
>> 
>>  As fc00:0db8::/32 is from within the existing but albeit unused portion of 
> ULA prefix, any future use of fc00::/8 will need to specifically exclude it. I 
> think exceptions to the normal case are better to avoid because they're 
> another thing to remember, program as an exception case and therefore a prone to 
> errors etc.
> 
> 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 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. 

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

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

> As such, g-z would be a non-starter.

> 

I do agree it's not the greatest idea, but it would ensure the prefix can only be used in documentation and nothing else, and would facilitate training people on paper in how to subnet ULA-like space. After they've had that training they could then use real ULAs to implement a subnetting plan in their lab scenarios.

Regards,
Mark.