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

"Antonio M. Moreiras" <moreiras@nic.br> Mon, 12 August 2013 22:12 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 92D3021E804C for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001]
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 OujjQR8ucs8A for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 15:12:02 -0700 (PDT)
Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 161CB11E80E1 for <v6ops@ietf.org>; Mon, 12 Aug 2013 15:12:02 -0700 (PDT)
Received: from moreiras.in.nic.br (unknown [IPv6:2001:12ff:0: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 9598620801BF for <v6ops@ietf.org>; Mon, 12 Aug 2013 19:11:59 -0300 (BRT)
Message-ID: <52095DAF.2050505@nic.br>
Date: Mon, 12 Aug 2013 19:11:59 -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>
In-Reply-To: <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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: Mon, 12 Aug 2013 22:12:04 -0000

On 12/08/13 18:07, Owen DeLong wrote:
> But having obviously different prefixes for the class to use to indicate
> what is ULA and what is "simulated GUA" is still very useful from a
> teaching perspective.
> 
> Owen

(repeating myself) Generally our IPv6 trainings are the first contact
with IPv6 for some network guys. Their biggest difficulties generally
lies in understanding the IPv6 addresses. The types of addresses, where
to use each of them, the new format, etc. From a didactic point of view,
it would be a bad idea to use ULAs and tell them: please don't forget to
pretend that this ULA block is our Global Unicast block, and this other
ULA prefix will be  the "real" ULA in our lab. Something looking more
like GUAs would be better. The prefix 2001:db8::/32 do represent GUAs in
documentation.

It is difficult to convince people that private addresses and NATs are
not to be used in all situations. Using ULAs in the labs, instead of
Globals, would not help. I fear that using ULAs would result in people
used to see them in the wrong places, and could lead us to a situation
where some networks would finish having just ULA addresses (and NAT66)
in scenarios where it would not be the better choice.

I would prefer to choose an arbitrary prefix, inside or outside
2000::/3, but that "looks like" a GUA, than use ULAs in the classes.

Moreiras.

> 
> On Aug 12, 2013, at 1:30 PM, "George, Wes" <wesley.george@twcable.com
> <mailto:wesley.george@twcable.com>> wrote:
> 
>>  
>> *From:* Owen DeLong [mailto:owen@delong.com <http://delong.com>] 
>>
>> Because in some cases, the lab is also teaching about ULA+GUA
>> configurations.
>>  
>> */[WEG]/* I don’t follow your logic. 2001:db8::/32 is not GUA, nor
>> would any such documentation prefix be –quite the contrary, in fact.
>> It just happens to come from 2000::/3 so it **looks** more like GUA,
>> but the network behavior is no different.
>>  
>> Wes
>>  
>> On Aug 12, 2013, at 13:05 , "George, Wes" <wesley.george@twcable.com
>> <mailto:wesley.george@twcable.com>> wrote:
>>
>>
>>  
>> *From:* v6ops-bounces@ietf.org
>> <mailto:v6ops-bounces@ietf.org> [mailto:v6ops-bounces@ietf.org
>> <mailto:bounces@ietf.org>] *On Behalf Of *Carlos Martinez-Cagnazzo
>>
>>
>>  
>> As far as I understand, Antonio does some training involving 6RD
>> deployments, where each 'team' needs its own /32. There might be other
>> cases though, like for example doing some work involving BGP routing
>> between different teams and for which you expect each one of them to
>> carve a /32.
>> */[WEG] /*and that environment can’t use ULA because….?
>>  
>> Not saying that there aren’t legitimate cases when having more than
>> /32 of documentation space might be useful, just saying that I don’t
>> believe the needs of a lab environment (even in the context of
>> training) is necessarily one of them.
>>  
>> Wes George
>> Anything below this line has been added by my company’s mail server, I
>> have no control over it.
>> -----------------
>>  
>> ------------------------------------------------------------------------
>> This E-mail and any of its attachments may contain Time Warner Cable
>> proprietary information, which is privileged, confidential, or subject
>> to copyright belonging to Time Warner Cable. This E-mail is intended
>> solely for the use of the individual or entity to which it is
>> addressed. If you are not the intended recipient of this E-mail, you
>> are hereby notified that any dissemination, distribution, copying, or
>> action taken in relation to the contents of and attachments to this
>> E-mail is strictly prohibited and may be unlawful. If you have
>> received this E-mail in error, please notify the sender immediately
>> and permanently delete the original and any copy of this E-mail and
>> any printout.