IETF Logo Mail Archive

Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC

Doug Barton <dougb@dougbarton.us> Sat, 24 September 2011 03:46 UTC

Return-Path: <dougb@dougbarton.us>
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 33E1821F8CA3 for <ietf@ietfa.amsl.com>; Fri, 23 Sep 2011 20:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.477
X-Spam-Level:
X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 iYQOH67l4Vs3 for <ietf@ietfa.amsl.com>; Fri, 23 Sep 2011 20:46:02 -0700 (PDT)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 37EB221F8C98 for <ietf@ietf.org>; Fri, 23 Sep 2011 20:46:02 -0700 (PDT)
Received: (qmail 3628 invoked by uid 399); 24 Sep 2011 03:48:37 -0000
Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 24 Sep 2011 03:48:37 -0000
X-Originating-IP: 12.207.105.210
X-Sender: dougb@dougbarton.us
Message-ID: <4E7D5313.6030201@dougbarton.us>
Date: Fri, 23 Sep 2011 20:48:35 -0700
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110912 Thunderbird/6.0.2
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-03.txt> (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
References: <6.2.5.6.2.20110819111507.09a77b18@resistor.net> <CA78256F.1D45A%c.donley@cablelabs.com> <6.2.5.6.2.20110822200837.09adf660@resistor.net> <4E7B7FE6.7090405@piuha.net>
In-Reply-To: <4E7B7FE6.7090405@piuha.net>
X-Enigmail-Version: undefined
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
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: Sat, 24 Sep 2011 03:46:03 -0000

On 09/22/2011 11:35, Jari Arkko wrote:
> It would have been even better if we had access to research that has
> looked at the various impacts in a rigorous manner. E.g., what's the
> likelihood of ISP - subscriber address collision in the different parts
> of the current RFC 1918 space vs. what is the likelihood of application
> failures with the new space. Not sure if we have time for that research
> now unless it already exists.

I agree with Jari that this would be a better alternative (in addition
to Jari's other point that software which relies on being able to detect
non-RFC-1918 space having problems with this new range). I have a very
difficult time being sympathetic to the people that created the problem
by sticking their fingers in their ears and singing "la la la la la la
la" while the v4 address space went away. I would much rather see them
take responsibility for fixing the problem they helped create by finding
a way to deal with it using existing resources.

This document, and
https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space-03
talk about the potential pitfalls of not allocating the space, but my
reading of them didn't reveal an adequate examination of the opportunity
cost of taking 4,096 /22s out of the free pool.

Finally, I have absolutely zero sympathy for any argument that
performing such an allocation is "urgent." The coming IPv4 exhaustion
problem has been a known issue for over 15 years. Section 5.1 of bdgks
talks about the history of similar requests going back to 2004. In an
ideal world the message that "IPv6 is the solution to this problem"
would have been received at some point in the process.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

v2.23.0 | Report a Bug | By Email