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/