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

"Antonio M. Moreiras" <moreiras@nic.br> Thu, 15 August 2013 12:07 UTC

Return-Path: <moreiras@nic.br>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1136511E8119 for <v6ops@ietfa.amsl.com>; Thu, 15 Aug 2013 05:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZHZlOyM3rZq for <v6ops@ietfa.amsl.com>; Thu, 15 Aug 2013 05:07:23 -0700 (PDT)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA511E80F8 for <v6ops@ietf.org>; Thu, 15 Aug 2013 05:07:21 -0700 (PDT)
Received: from moreiras.in.nic.br (5.96.net.registro.br [200.160.5.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 2BE2520800FD for <v6ops@ietf.org>; Thu, 15 Aug 2013 09:07:16 -0300 (BRT)
Message-ID: <520CC474.3050004@nic.br>
Date: Thu, 15 Aug 2013 09:07:16 -0300
From: "Antonio M. Moreiras" <moreiras@nic.br>
Organization: NIC.br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: v6ops@ietf.org
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <CA+z-_EWFAGFqyo3E3LzrEhpMRV6axdLJTC50BNwXMNGuJtZuTA@mail.gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <A84D9405-B3D2-4D55-BAEE-FE25ACE45EB6@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com> <165C9BFD-B154-4F5C-89C5-684B621D2696@delong.com> <1376435086.63006.YahooMailNeo@web142506.mail.bf1.yahoo.com> <E2F5B184-5386-48E7-B840-72753AC4E984@delong.com> <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com>
In-Reply-To: <1376552030.18421.YahooMailNeo@web142501.mail.bf1.yahoo.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2013 12:07:29 -0000

On 15/08/13 04:33, Mark ZZZ Smith wrote:
> ----- Original Message -----
>> > From: Owen DeLong <owen@delong.com>
>> > To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> > Cc: "George, Wes" <wesley.george@twcable.com>om>; "v6ops@ietf.org" <v6ops@ietf.org>
>> > 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 am not following closely the discussions on ULA-C. I think this matter
isn't discussed since 2007, or 2008, is it? But let's suppose that
someone revives the subject, and we come to create such a central
registry for ULA-C space. Based on previous discussions, I think it is
safe to assume that it would just allocate /48 prefixes from fc00::/8,
probably choosing them randomically. In this context, what could happen
if we reserve some prefixes for documentation, now? They would just be
marked as already in use, by such central registry. What else could happen?

The networks could treat the ULA documentation prefixes the same way
they treat any other ULA prefix that are not their own. As ULA, in
general, is already being filtered at network borders, maybe we really
wouldn't need special rules, or exceptions, as we need with
2001:0db8::/32. The main advantage of an ULA documentation prefix, such
as fc00:0db8::/32 would be the "visual clue", then. If someone a bit
experienced sees something like fc00:db8:a:coffe::1 in the network, it
would be very clear that it was copied from some example, and should not
be there.

Moreiras.