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

Douglas Otis <dotis@mail-abuse.org> Fri, 23 September 2011 04:26 UTC

Return-Path: <dotis@mail-abuse.org>
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 7FB2911E8086 for <ietf@ietfa.amsl.com>; Thu, 22 Sep 2011 21:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, 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 eSgSxDmfEh2U for <ietf@ietfa.amsl.com>; Thu, 22 Sep 2011 21:26:57 -0700 (PDT)
Received: from SJDC-SDIRelay3.sdi.trendmicro.com (sjdc-sdirelay3.sdi.trendmicro.com [150.70.69.27]) by ietfa.amsl.com (Postfix) with ESMTP id 179F011E8073 for <ietf@ietf.org>; Thu, 22 Sep 2011 21:26:57 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by SJDC-SDIRelay3.sdi.trendmicro.com (Postfix) with ESMTP id 533686E013D for <ietf@ietf.org>; Fri, 23 Sep 2011 04:29:28 +0000 (UTC)
Received: from US-DOUGO-MAC.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id E0AA8A9443B for <ietf@ietf.org>; Fri, 23 Sep 2011 04:29:28 +0000 (UTC)
Message-ID: <4E7C0B27.2000602@mail-abuse.org>
Date: Thu, 22 Sep 2011 21:29:27 -0700
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: ietf@ietf.org
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> <34E4F50CAFA10349A41E0756550084FB0F8D1DCE@PRVPEXVS04.corp.twcable.com> <4E7BAFBA.7050508@piuha.net>
In-Reply-To: <4E7BAFBA.7050508@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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: Fri, 23 Sep 2011 04:26:57 -0000

Dual-Stack Lite, RFC6333 that makes these conversions using a single NAT 
by combining IPv6 address space with a common 192.0.0.0/29.  This 
approach does not suffer from scaling limitations other than 
constraining access points to 6 IPv4 interfaces where IPv6 provides the 
native IP protocol.   While taking a chunk out of 240/4 should not 
introduce any hardship, the intended use is for compound NAT topology 
seems aimed at retaining the provider's IPv4 infrastructure.  Such 
inferior IPv4 networks will certainly expedite demand for IPv6 access.

Any IPv4 need can be satisfied by the CPE  that conforms with RFC6333 at 
roughly the cost of the monthly service.  Does it really make since to 
endorse a strategy that attempts to produce inferior networks to delay 
an upgrade and impact many services now offered over IPv4?  This is 
likely to be significant mistake, IMHO.

-Doug