Re: draft-bdgks-arin-shared-transition-space-03

Joel jaeggli <joelja@bogus.com> Sat, 24 September 2011 16:07 UTC

Return-Path: <joelja@bogus.com>
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 0878D21F84FA for <ietf@ietfa.amsl.com>; Sat, 24 Sep 2011 09:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 deDxXIchfKF8 for <ietf@ietfa.amsl.com>; Sat, 24 Sep 2011 09:07:13 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6C221F84ED for <ietf@ietf.org>; Sat, 24 Sep 2011 09:07:13 -0700 (PDT)
Received: from Zorch.local (adsl-75-36-141-120.dsl.pltn13.sbcglobal.net [75.36.141.120]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p8OG9mfi096649 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 24 Sep 2011 16:09:49 GMT (envelope-from joelja@bogus.com)
Message-ID: <4E7DFAFC.3080109@bogus.com>
Date: Sat, 24 Sep 2011 08:45:00 -0700
From: Joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: SM <sm@resistor.net>
Subject: Re: draft-bdgks-arin-shared-transition-space-03
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> <4E7D5313.6030201@dougbarton.us> <6.2.5.6.2.20110923235810.0c594f58@resistor.net>
In-Reply-To: <6.2.5.6.2.20110923235810.0c594f58@resistor.net>
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.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 24 Sep 2011 16:09:50 +0000 (UTC)
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 16:07:14 -0000

On 9/24/11 03:24 , SM wrote:
> At 20:48 23-09-2011, Doug Barton wrote:
>> 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.
> 
> There are three ways to get an allocation from the IANA free pool:
> 
>  1. RIR allocation (that's no longer possible)
> 
>  2. A global policy
> 
>  3. A protocol assignment
> 
> A global policy proposal would take some time and it would not fare well
> as the ARIN region has ticked off the APNIC region due to its unilateral
> stance about how IPv4 addresses should be managed.  The third option
> offers a path to work around that.
> 
> Section 2.2.2 of draft-bdgks-arin-shared-transition-space-03 is another
> option.  I would not be surprised if ARIN blessed that option.
> 
> Section 4.1.2.1 of the draft mentions that:
> 
>   "Since the volume of impacted endpoints will be low, operators can
>    likely manage the disabling of 6to4 when needed."
> 
> I smiled when I saw that as it is contrary to some positions taken
> during the previous 6to4 controversy. :-)

I don't really believe the scale of the problem is fairly characterized
by the text. manually disabling (where possible) or physcially replacing
existing cpe are no more scalable than any other form of intervention.
it is worth noting that in general this problem can be address by
putting an rfc 1918 address on the outside.

the proponents of the demise of 6to4 are precisely the folks who really
would prefer not to break 6to4 in this fashion. less-than-functional
auto-tunneling does enough damage already without our help.


_______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>