Re: [OPSAWG] draft-davies-reusable-ipv4-address-block-00

Leo Vegoda <leo.vegoda@icann.org> Wed, 20 January 2010 02:28 UTC

Return-Path: <leo.vegoda@icann.org>
X-Original-To: opsawg@core3.amsl.com
Delivered-To: opsawg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107D33A63D3 for <opsawg@core3.amsl.com>; Tue, 19 Jan 2010 18:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 sQaGVMtmlF0I for <opsawg@core3.amsl.com>; Tue, 19 Jan 2010 18:28:23 -0800 (PST)
Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id F0C463A68AC for <opsawg@ietf.org>; Tue, 19 Jan 2010 18:28:22 -0800 (PST)
Received: from [10.0.232.3] (76.169.52.154) by smtpx.exc.icann.org (64.78.22.244) with Microsoft SMTP Server (TLS) id 8.1.336.0; Tue, 19 Jan 2010 18:28:19 -0800
From: Leo Vegoda <leo.vegoda@icann.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Jan 2010 18:28:20 -0800
Message-ID: <69B6A9A5-8EC1-4813-8569-1243A13976FD@icann.org>
To: greg.davies@team.telstra.com, Christopher LILJENSTOLPE <cdl@asgaard.org>, opsawg@ietf.org
MIME-Version: 1.0 (Apple Message framework v1077)
X-Mailer: Apple Mail (2.1077)
Subject: Re: [OPSAWG] draft-davies-reusable-ipv4-address-block-00
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 02:28:24 -0000

Hi,

We have reviewed this draft and have several comments on parts of it.

Section 2.1 proposes an address block to be assigned for a temporary period but the document does not explain the reason for the recommendation of a 10 year assignment rather than a shorter or longer period. It would be useful to include reasoning for a 10 year period and also to describe how likely it is that any assignment of this type could ever be temporary. For that reason, it would be useful to document how it is intended for this block to be returned to the free pool and made available for allocation to end user networks at the conclusion of the assignment period.

Section 2.3 proposes that the block should be made available for use by transit providers. However, it does not define what a transit provider is. Arguably, Internet transit can be provided by networks of almost any size, including very small networks providing Internet access to small sites. It would be useful to define the term transit provider and to document if there is a mechanism other than self-restraint on the part of network operators for keeping the address range in use by one section of the operator community and not by others.

Section 2.4 requests IANA to select a suitable address range to be assigned for this purpose but only provides very broad brush guidance on how to do that. As there are a dozen or more /8s that fit the criteria described in this section it might be helpful to provide additional guidance so that the /8 selected is not just suitable for this purpose but is the most suitable of a fairly broad group.

Section 2.5 requests the assignment of a /10 prefix but the text is not specific on why this prefix length is more suitable than something shorter or longer. An explanation of why a /11 or /9 would not be a better choice would be helpful.

Further, while assigning a /10 for this purpose would be possible, one consequence of such an assignment is that the remainder of the /8 would no longer be available for allocation to an RIR under the current global policy for IPv4 allocations (http://www.icann.org/general/allocation-IPv4-rirs.html) as that policy requires IANA to "allocate IPv4 address space to the RIRs in /8 units". For this reason, it would be useful to get input from the RIR community so that they can make sure three quarters of a /8 are not left in limbo if this document is approved. Also, if the remaining address space in the /8 is made available for use the requirement in 2.7 would need to be amended to allow the relevant RIR's nameservers to return the NXDOMAIN response for reverse DNS queries for addresses in this /10.

Kind regards,

Marla Azinger & Leo Vegoda