Protocol Action: 'IPv6 Address Assignment to End Sites' to BCP (draft-ietf-v6ops-3177bis-end-sites-01.txt)
The IESG <iesg-secretary@ietf.org> Wed, 12 January 2011 19:50 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F473A6A87; Wed, 12 Jan 2011 11:50:45 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 h96gD9Z0lqmj; Wed, 12 Jan 2011 11:50:44 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623783A6A9C; Wed, 12 Jan 2011 11:50:42 -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: 'IPv6 Address Assignment to End Sites' to BCP (draft-ietf-v6ops-3177bis-end-sites-01.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.10
Message-ID: <20110112195042.11440.88026.idtracker@localhost>
Date: Wed, 12 Jan 2011 11:50:42 -0800
Cc: v6ops mailing list <v6ops@ietf.org>, Internet Architecture Board <iab@iab.org>, v6ops chair <v6ops-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 12 Jan 2011 19:50:45 -0000
The IESG has approved the following document: - 'IPv6 Address Assignment to End Sites' (draft-ietf-v6ops-3177bis-end-sites-01.txt) as a BCP This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ron Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/ Technical Summary RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document revisits and updates the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The role of the IETF is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. Moreover, the document clarifies that a one- size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document updates and replaces RFC 3177. Working Group Summary The IPv6 Operations Working Group very solidly supported the specific changes in proposed policy from RFC 3177. These are: 1) It is no longer recommended that /128s be given out. While ther may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices. 2) RFC 3177 specifically recommended using prefix lengths of /48, /64 and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that CIDR continues to apply to all bits of the routing prefixes. 3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate. This document does, however, reaffirm an important assumption behind RFC 3177: A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space. Document Quality The document appears to be of very high quality and essentially unanimous support. Personnel Fred Baker is shepherd for this document.