FWD: I-D Action: draft-gashinsky-6man-v6nd-enhance-01.txt
joel jaeggli <joelja@bogus.com> Thu, 20 September 2012 21:13 UTC
Return-Path: <joelja@bogus.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A121E8093; Thu, 20 Sep 2012 14:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level:
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdhKaIgpSJEQ; Thu, 20 Sep 2012 14:13:34 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id A9ED221E805F; Thu, 20 Sep 2012 14:13:28 -0700 (PDT)
Received: from joels-MacBook-Air.local (host-64-47-153-50.masergy.com [64.47.153.50]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q8KLDR93074793 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 20 Sep 2012 21:13:27 GMT (envelope-from joelja@bogus.com)
Message-ID: <505B86F1.6020602@bogus.com>
Date: Thu, 20 Sep 2012 14:13:21 -0700
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20120828 Thunderbird/16.0
MIME-Version: 1.0
To: IPv6 Ops WG <v6ops@ietf.org>, "ipv6@ietf.org 6man" <ipv6@ietf.org>
Subject: FWD: I-D Action: draft-gashinsky-6man-v6nd-enhance-01.txt
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 20 Sep 2012 21:13:27 +0000 (UTC)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Sep 2012 21:13:35 -0000
Greetings, On the heals of work on draft-ietf-6man-impatient-nud-02 and rfc 6583 the authors have decided to take a lot at their proposal for gratuitous neighbor advertisement. We believe that this approach has the potential to ameliorate some problems experienced today in large broadcast domains where control plane processors may spend a significant chunk of their cpu cycles mananging NDP even under normal circumstances. There is some real world experience of meltdowns not caused by deliberate DOS that we ascribe to the current handling of NDP so we'd like to see some additional effort in this area. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Neighbor Discovery Enhancement for DOS mititgation Author(s) : Warren Kumari Filename : draft-gashinsky-6man-v6nd-enhance-01.txt Pages : 10 Date : 2012-09-20 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 can be vulnerable to denial of service attacks 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 that scan networks for inventory and other purposes. 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 a modification to the [RFC4861] neighbor discovery protocol aimed at improving the resilience of the neighbor discovery process. We call this process Gratuitous neighbor discovery and it derives inspiration in part from analogous IPv4 gratuitous ARP implementation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-gashinsky-6man-v6nd-enhance There's also a htmlized version available at: http://tools.ietf.org/html/draft-gashinsky-6man-v6nd-enhance-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-gashinsky-6man-v6nd-enhance-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
- FWD: I-D Action: draft-gashinsky-6man-v6nd-enhanc… joel jaeggli