Protocol Action: 'IANA Reserved IPv4 Prefix for Shared Address Space' to Best Current Practice (draft-weil-shared-transition-space-request-15.txt)

The IESG <iesg-secretary@ietf.org> Wed, 29 February 2012 18:55 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1EC421F86D5 for <ietf-announce@ietfa.amsl.com>; Wed, 29 Feb 2012 10:55:19 -0800 (PST)
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 kQmLdTNg2w4k; Wed, 29 Feb 2012 10:55:19 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DBD21F86EF; Wed, 29 Feb 2012 10:55:19 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'IANA Reserved IPv4 Prefix for Shared Address Space' to Best Current Practice (draft-weil-shared-transition-space-request-15.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120229185519.5924.84935.idtracker@ietfa.amsl.com>
Date: Wed, 29 Feb 2012 10:55:19 -0800
Cc: RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Feb 2012 18:55:20 -0000

The IESG has approved the following document:
- 'IANA Reserved IPv4 Prefix for Shared Address Space'
  (draft-weil-shared-transition-space-request-15.txt) as a Best Current
Practice

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Ronald Bonica.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/




Technical Summary

This document requests the allocation of an IPv4 /10 address block to be used 
as Shared Carrier Grade Network (CGN) Space.  Service Providers will use 
Shared CGN Space to number the interfaces that connect CGN devices to 
Customer Premise Equipment (CPE).  As this document proposes the allocation 
of an additional special-use IPv4 address block, it updates RFC 5735.


Working Group Summary

This memo is not the product of a WG. However, it has been discussed in the OPSARESA WG.

Document Quality

On October 10, 2011, the IESG issued a last call for comments regarding 
draft-weil-shared-transition-space-request-09 (IANA Reserved IPv4 Prefix for 
Shared CGN Space). While the community did not display consensus supporting 
the draft, it also did not display consensus against the draft. Therefore, I will 
submit the draft to the full IESG for its consideration at its December 1 
teleconference. The draft will be published as a BCP if a sufficient number of 
IESG members ballot "Yes" or "No Objection", and if no IESG member ballots "Discuss".

Because the decision to submit this draft to the full IESG is controversial, I 
will explain the decision making process.

The IETF has a precedent for interpreting silence as consent. Typically, if a 
last call elicits no response, the draft is brought to the full IESG for consideration. 
The October 10 last call regarding draft-weil-shared-transition-space-request-09 
evoked only two responses. One response supported publication of the draft while 
the other was opposed to it. The respondent voicing support for the draft offered no 
rationale. The respondent objecting offered many editorial comments, but almost no 
rationale for blocking the draft once the editorial comments are addressed.

Because the October 10 last call elicited so little response, and because many 
community members have privately expressed strong opinions regarding this draft, 
I will summarize outstanding issues below. The following are arguments *against* 
draft-weil-shared-transition-space-request:

- Allocation of a special-use /10 does not hasten the deployment of IPv6. It only 
extends the life of the IPv4 network.
- If a special-use /10 is allocated, it will be used as additional RFC 1918 address 
space, despite a specific prohibition against such use stated by the draft.
- If a special-use /10 is allocated, it will encourage others to request still more 
special-use address space.
- Some applications will break. These applications share the characteristic of assuming 
that an interface is globally reachable if it is numbered by an non-RFC 1918 address. 
To date, the only application that has been identified as breaking is 6to4, but others 
may be identified in the future.

Arguments *supporting* draft-weil-shared-transition-space-request-09 assume that 
operators will deploy CGNs and will number the interfaces between CGN and CPE. 
If the /10 proposed by draft-weil-shared-transition-space-request is not allocated, 
operators will number from one of the following:

- public address space 
- RFC 1918 address space
- squat space

If operators number from public address space, they will deplete an already scarce 
resource. If operators number from RFC 1918 space and the same RFC 1918 space 
is used on the customer premise, some CPE will behave badly. The consequences of 
numbering from squat space are determined by the squat space that is chosen.

In summary, allocation of the /10 will have certain adverse effects upon the community. 
However, failure to allocate the /10 will have different adverse effects on the community. 
The IESG is being asked to choose the lesser of two evils.
                                                               


Personnel

Document shepherd is Scott Bradner.

IESG Note

> "A number of operators have expressed a need for the special purpose 
> IPv4 address allocation described by this document.
> During deliberations, the IETF community demonstrated very rough 
> consensus in favor of the allocation.
> 
> While operational expedients, including the special purpose address 
> allocation described in this document, may help solve a short-term 
> operational problem, the IESG and the IETF remain committed to the 
> deployment of IPv6."