IETF Logo Mail Archive

Re: [v6ops] draft-liu-v6ops-ula-usage-analysis

Arturo Servin <arturo.servin@gmail.com> Wed, 20 March 2013 13:30 UTC

Return-Path: <arturo.servin@gmail.com>
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 523C921F84BE for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2013 06:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 o7YQTxzN46LG for <v6ops@ietfa.amsl.com>; Wed, 20 Mar 2013 06:30:04 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 69F5021F848D for <v6ops@ietf.org>; Wed, 20 Mar 2013 06:30:04 -0700 (PDT)
Received: by mail-ob0-f182.google.com with SMTP id va7so1604250obc.13 for <v6ops@ietf.org>; Wed, 20 Mar 2013 06:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RfxmXN2Dq6asK9vOeoXIMgNXfE/yZlg7ou8zBh0RVQc=; b=WjhbYyGjobkyeteR6JlDvD/0euePQxu7RXos5k7Ihi8t6qlh54JyQRPXzP3MHW3Go9 rKbvx9IsQoXv01cHC7eAjvvzUcjdOy9G1Zt563qhQUSm35VzQgSK1nv/+KTuS8t3t7f+ zHa3q/9SDAZC6jvDkkHg2TwXBa80Lujx4/jpVA+OfOgDe2sVaZv48rOGBJk2fGs6LHbQ 9bWdEcccUpfs++suBlAcg/zywo7uanRCdK/6YvuwGa8FlprgAZLy4BZQO2eHKW2+vH7k ElN1ROQ6gOR3TFDYIT1ZcTvLMWuikQ8UAX7JquYqWh8Na6Qk6TJfE6H3Eaiao7wTJ2yN z74w==
X-Received: by 10.182.190.19 with SMTP id gm19mr4013538obc.34.1363786203943; Wed, 20 Mar 2013 06:30:03 -0700 (PDT)
Received: from 85-7-200.lacnic.net.uy ([2001:13c7:7001:5128:ed04:56f9:69f7:9174]) by mx.google.com with ESMTPS id v8sm1839395oea.4.2013.03.20.06.30.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Mar 2013 06:30:03 -0700 (PDT)
Message-ID: <5149B9DD.5030108@gmail.com>
Date: Wed, 20 Mar 2013 10:30:05 -0300
From: Arturo Servin <arturo.servin@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Owen DeLong <owen@delong.com>
References: <8C48B86A895913448548E6D15DA7553B7D2287@xmb-rcd-x09.cisco.com> <514863DB.4000507@globis.net> <050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <EMEW3|ed90b2ff5d71cffee6823b382fff1536p2J7gm03tjc|ecs.soton.ac.uk|050AA46E-501A-4EDD-80E3-8A2CD67BEA4A@ecs.soton.ac.uk> <514977CF.9030806@gmail.com> <5149A22C.7080705@gmail.com> <9C8C9502-725A-44AF-8AD9-A1CBB793AA7E@delong.com>
In-Reply-To: <9C8C9502-725A-44AF-8AD9-A1CBB793AA7E@delong.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis
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: Wed, 20 Mar 2013 13:30:06 -0000

	They have some real uses but in very specific scenarios with specif
constrains like in homenet and DC with IPv6:

http://tools.ietf.org/html/draft-ietf-homenet-arch-07#section-2.4

http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6-04#section-3.1

	And even there, it may be questionable.

/as

On 3/20/13 10:05 AM, Owen DeLong wrote:
>>>
>>> It depends. If the draft says "If you choose to use a ULA prefix, here
>>> are some guidelines on how to do it properly", BCP might be appropriate.
>>> However, an informational description of appropriate deployment scenarios
>>> would be quite OK.
>>
>> 	I agree, but we have so little experience with ULA deployment that
>> these recommendations are far for being a BCP. In reality they are like
>> "we think that this is the best way to use ULAs, but we don't really
>> know because we haven't use it a lot."
>>
> 
> +1
> 
> Well said, Arturo. Personally, the more this discussion evolves, the more
> convinced I become that ULA is an ugly can of worms that is best when left
> unopened.
> 
> Unfortunately, that ship has sailed.
> 
> Owen
>

v2.23.0 | Report a Bug | By Email