[v6ops] Last Call: <draft-ietf-v6ops-v6nd-problems-04.txt> (Operational Neighbor Discovery Problems) to Informational RFC
The IESG <iesg-secretary@ietf.org> Mon, 06 February 2012 15:02 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928A721F8699; Mon, 6 Feb 2012 07:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.458
X-Spam-Level:
X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 mSVFGnvPSaPn; Mon, 6 Feb 2012 07:02:14 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FB921F85EA; Mon, 6 Feb 2012 07:02:14 -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>
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p1
Message-ID: <20120206150214.5445.40209.idtracker@ietfa.amsl.com>
Date: Mon, 06 Feb 2012 07:02:14 -0800
Cc: v6ops@ietf.org
Subject: [v6ops] Last Call: <draft-ietf-v6ops-v6nd-problems-04.txt> (Operational Neighbor Discovery Problems) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2012 15:02:14 -0000
The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Operational Neighbor Discovery Problems' <draft-ietf-v6ops-v6nd-problems-04.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ No IPR declarations have been submitted directly on this I-D.