Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

Nick Hilliard <nick@inex.ie> Thu, 16 February 2012 16:58 UTC

Return-Path: <nick@inex.ie>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82921F855F for <ietf@ietfa.amsl.com>; Thu, 16 Feb 2012 08:58:12 -0800 (PST)
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 zt+3wOotIvyC for <ietf@ietfa.amsl.com>; Thu, 16 Feb 2012 08:58:11 -0800 (PST)
Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id C669321F881A for <ietf@ietf.org>; Thu, 16 Feb 2012 08:58:07 -0800 (PST)
X-Envelope-To: <ietf@ietf.org>
Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q1GGwqnV060204 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Thu, 16 Feb 2012 16:58:53 GMT (envelope-from nick@inex.ie)
Message-ID: <4F3D359C.7020907@inex.ie>
Date: Thu, 16 Feb 2012 16:58:04 +0000
From: Nick Hilliard <nick@inex.ie>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
References: <CB5FF399.1B4E7%jeff.finkelstein@cox.com> <4F3AAA08.2040204@qualcomm.com> <01OBZ9WQSHWY00ZUIL@mauve.mrochek.com> <4F3ABF6C.1030803@qualcomm.com> <m2d39hi267.wl%randy@psg.com> <4F3B09C3.1090005@qualcomm.com> <1329388980.5382.44.camel@davinci.millnert.se> <CAC1-dtnJ77PgMmfeYJHZfO13C10ckznuseVyEECAb8dUPoj1ew@mail.gmail.com> <1329410134.5382.72.camel@davinci.millnert.se>
In-Reply-To: <1329410134.5382.72.camel@davinci.millnert.se>
X-Enigmail-Version: 1.3.5
X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804
X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3
X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee
X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24.
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 16:58:12 -0000

On 16/02/2012 16:35, Martin Millnert wrote:
> You seem to want me to believe that: 
>   - there is a fixed set of networks, who are going to deploy either:
>     - a sucky IPv4 network, or, 
>     - a less sucky IPv4 network, 
>   - it would be entirely depending on the passing of this draft, 
>   - the failure of passing of this draft somehow will exclude from these
> networks the possibility of obtaining non-RFC1918 space in another way,
> for example as I outlined
> 
> The latter two points seem a bit far-fetched.

Martin,

Far-fetched - like all straw men.

> I'm curious how you can possibly have sufficient knowledge to make those
> statements as *facts*, rather than opinions, informed as the may be (but
> of limited scope -- I think it unlikely you've spoken to every network
> on the planet).

More straw men.  Look, we're adults here: please present good arguments.

The bottom line for this ID is that address space will be required for CGN,
and rfc1918 doesn't cut it for reasons described in the ID.  This means
that the address space must come from somewhere else.  The choices are:

1. one or more shared pools allocated by RIRs/IANA/whatever
2. private pools, each of which come from the carriers' own address blocks

option #1 is by definition more efficient than #2.

At least one of the RIRs has indicated that they cannot assign this space
due to charter problems.

There is no particular reason to allocate this space on a regional basis,
unless for some reason you believe that you can force carriers only to use
this shared address space for specific purposes - and I cannot see why you
think that this is remotely feasible for shared address space.  Private
address space, perhaps.  But certainly not shared address space.

The core function of a RIR is to guarantee that if they allocate you a
bunch of numbers, that they haven't allocated the same bunch of numbers to
someone else.  Therefore by definition they have no particular authority
over the way that shared address space might be used internally by a carrier.

Incidentally, I support this draft.

Nick