Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC]

Joel Jaeggli <joelja@bogus.com> Wed, 04 August 2010 16:29 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A2213A69FC for <behave@core3.amsl.com>; Wed, 4 Aug 2010 09:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.809
X-Spam-Level:
X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 119dqvNc5h-M for <behave@core3.amsl.com>; Wed, 4 Aug 2010 09:29:40 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 356183A69E3 for <behave@ietf.org>; Wed, 4 Aug 2010 09:29:40 -0700 (PDT)
Received: from dhcp-183.nokia.net (dhcp-183.nokia.net [192.103.16.183] (may be forged)) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o74GU8uM068522 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Aug 2010 16:30:09 GMT (envelope-from joelja@bogus.com)
Message-ID: <4C599591.3070301@bogus.com>
Date: Wed, 04 Aug 2010 09:30:09 -0700
From: Joel Jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1
MIME-Version: 1.0
To: Victor Kuarsingh <vicmank@rogers.com>
References: <C87E3D04.D001%vicmank@rogers.com>
In-Reply-To: <C87E3D04.D001%vicmank@rogers.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Wed, 04 Aug 2010 16:30:09 +0000 (UTC)
Cc: behave@ietf.org
Subject: Re: [BEHAVE] [Fwd: Last Call: draft-azinger-additional-private-ipv4-space-issues (Additional Private IPv4 Space) to INFORMATIONAL RFC]
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Aug 2010 16:29:44 -0000

Victor...

On 8/3/10 6:39 PM, Victor Kuarsingh wrote:
> Based on these points, the SP will then be left with a couple of options,
> have access to a new /8 to provide more race track while IPv6 is put online
> (remember even some transition options need IPv4 space to glue the CPE to
> the upstream box like 6RD and NAT444) or camp out on IPv4 space anyway
> (unrouted IPv4 space that is assigned.  If the /8 is not provided, then the
> latter is likely to occur, which will bring all the problems related to a
> the proposed option (in draft-weil) plus the added problems which arise when
> camping on other's IP address space.

That's sounds kind of like a shake-down... Provide us more address-space
or we'll kill the baby.

The fact of the matter is we're going to employee ugly transition
schemes anyway and the question is only when and how many times we're
going to pay for it not if...

Regarding camping on other's IP space, "hey it's not our fault we're
camping on a /8 that got assigned out from under us" is a pretty shallow
excuse. It was a business decision to do that before just as it is today
and the consequences were known then and now.

This comes down to venue shopping. The RIRs can't provide what we think
you need anymore so we're here at the IETF dicussing whether to soak up
an addtional 16.7 million addresses as rfc1918 space...

Heck I'm in favor of that, RFC1918 space isn't big enough for my
employer either and we're not even a Cable MSO but I think that probably
comes to bear on the point of whether and how long you can expect and
justification of fewer collisions with net 10 having any merit.