Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

Joel jaeggli <joelja@bogus.com> Mon, 20 February 2012 17:43 UTC

Return-Path: <joelja@bogus.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 E7D3921F87A0 for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 09:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level:
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 GVJpVl93w5XC for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 09:42:56 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 67FD521F86D1 for <v6ops@ietf.org>; Mon, 20 Feb 2012 09:42:56 -0800 (PST)
Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q1KHgq2R076583 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 20 Feb 2012 17:42:53 GMT (envelope-from joelja@bogus.com)
Message-ID: <4F42861C.20208@bogus.com>
Date: Mon, 20 Feb 2012 09:42:52 -0800
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Rémi Després <despres.remi@laposte.net>
References: <BB119B6D-FC99-4637-988D-D17FBB50597A@laposte.net> <CAD6AjGTdfGz1egdp3MpWPYBdzCM56aZejfG98pe+bWS4zf6cvA@mail.gmail.com> <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <CAD6AjGQSTE1VQyme50aY+Ki5_o57joay03KV=s7nDvm=gtm6Ag@mail.gmail.com> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net>
In-Reply-To: <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 20 Feb 2012 17:42:54 +0000 (UTC)
Cc: Russell Housley <housley@vigilsec.com>, v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.
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, 20 Feb 2012 17:43:01 -0000

On 2/20/12 09:23 , Rémi Després wrote:
> Cameron,
> Le 2012-02-20 à 16:32, Cameron Byrne a écrit :

>>
>> I have brought to softwires the concern that stateless core NAT64 is
>> not acceptable given the address efficiency issues (please don't blast
>> me about how my issues are non-issues).
> 
> I never did, I hope, but I think I rather asked about real order of magnitudes of your problem.
> Didn't get it yet.

Running a network with 30 million users and a /15 ip addresses is the
right order of magnitude to describe tmob. There are networks that are
larger but with proportionally fewer and smaller networks with a lot less.

> Ideally that would include the number of simultaneous devices to be supported, and the size of the IPv4 space available, with lengths of IPv4 prefixes that compose it.
> In any case, your requirement is yours,  and some other operators do have different requirements (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html).
> That's why some coordination makes sense.
>  
>>  On the softwire list, i
>> brought this up and was told a /14 of IPv4 was probably needed to meet
>> a mid to large size wireless operator.  
>> Unfortunately, these address
>> are not available in APNIC today and will not be available in ARIN or
>> RIPE in the very near future.... considering the timeline scope the
>> IETF operates at.  That said, the stateless solutions have an audience
>> with network operators that already have large allocations and wish to
>> be more efficient.  That's great, live and let live.