Document Action: 'Local Network Protection for IPv6' to Informational RFC
The IESG <iesg-secretary@ietf.org> Thu, 15 February 2007 16:24 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjP3-0001RV-2v; Thu, 15 Feb 2007 11:24:13 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHjP1-0001Qo-NE for ietf-announce@ietf.org; Thu, 15 Feb 2007 11:24:11 -0500
Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HHjP0-0000Y1-Dp for ietf-announce@ietf.org; Thu, 15 Feb 2007 11:24:11 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3439C175F2; Thu, 15 Feb 2007 16:23:40 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HHjOV-0002Eh-VV; Thu, 15 Feb 2007 11:23:39 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1HHjOV-0002Eh-VV@stiedprstage1.ietf.org>
Date: Thu, 15 Feb 2007 11:23:39 -0500
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc: v6ops mailing list <v6ops@ops.ietf.org>, Internet Architecture Board <iab@iab.org>, v6ops chair <v6ops-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Local Network Protection for IPv6' to Informational RFC
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces@ietf.org
The IESG has approved the following document: - 'Local Network Protection for IPv6 ' <draft-ietf-v6ops-nap-06.txt> as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-06.txt Technical Summary Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 does not support NAT by design and this document shows how Network Architecture Protection (NAP) using IPv6 can provide the same or more benefits without the need for NAT. Working Group Summary This document is a product of the v6ops working group. Protocol Quality David Kessens reviewed this document for the IESG. Note to RFC Editor: In section 2.6, first paragraph, please change: OLD: While the widespread use of IPv4+NAT has reduced the potential consumption rate, the ongoing depletion of the IPv4 address range has already taken the remaining pool of unallocated IPv4 addresses well below 25%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a direct result of this continuous resource consumption is that the administrative overhead for acquiring globally unique IPv4 addresses will continue increasing in direct response to tightening allocation policies. NEW: While the widespread use of IPv4+NAT has reduced the potential consumption rate, the ongoing depletion of the IPv4 address range has already taken the remaining IANA pool of unallocated IPv4 addresses well below 25%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a possible result of this continuous resource consumption is that the overhead for acquiring globally unique IPv4 addresses will at some point increase noticeably due to tightening allocation policies. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce