Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt

Erik Nordmark <> Tue, 21 January 2014 01:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 880AD1A025B for <>; Mon, 20 Jan 2014 17:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6ic6w1ByOpBU for <>; Mon, 20 Jan 2014 17:57:57 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E1B711A0002 for <>; Mon, 20 Jan 2014 17:57:57 -0800 (PST)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id s0L1vnIs002564 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 20 Jan 2014 17:57:51 -0800
Message-ID: <>
Date: Mon, 20 Jan 2014 17:57:48 -0800
From: Erik Nordmark <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ing-Wher Chen <>, "" <>
Subject: Re: draft-halpern-6man-nd-pre-resolve-addr-00.txt
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sonic-ID: C;Ki+Cbj+C4xGyEDqjisUCUQ== M;gOg6bz+C4xGyEDqjisUCUQ==
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2014 01:57:59 -0000

On 1/20/14 4:09 PM, Ing-Wher Chen wrote:
>> -----Original Message-----
>> From: Erik Nordmark []
>> Sent: Friday, January 17, 2014 9:02 PM
>> To: Greg Daley; Ing-Wher Chen;
>> Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-
>> resolve-addr-00.txt
>>   ...
>> In addition to your concern about multicast snooping environments, the
>> DAD packets are not reliably delivered. If e.g. there is a short WiFi
>> drop, the spanning tree is reconverging, etc then the single
>> transmitted DAD packet will not be received.
> No ND packets are reliably delivered.  So this is not different from any other ND traffic.

The DAD probe is different that NS messages used for address resolution. 
For address resolution the NS is retransmitted (3 times) until there is 
a response.

But the DAD probe is single (multicast) NS message, and if there is no 
response in one second then the node will conclude that there is no 

Thus if there is packet loss (e.g., on WiFi where multicast packets 
don't get ARQ), or on wired Ethernet with a spanning tree reconvergence 
when the DAD probe is sent, then the prober will incorrectly assume it 
is not a duplicate.

RFC 4862 talks about this lack of guarantees in section 5.4.

>> Thus as best this will collect some entries in the neighbor cache.
> We agree that the approach in the draft might not capture all neighbors.
> However, when a router is under an off-link attack, having this additional
> source of target addresses will mean that the router can continue to service
> new hosts, as it sees them.  The alternative, without the approach in the draft,
> is that the router does not service any additional new hosts, starting from
> the time the router is under attack.  (The DAD-NS approach can be seen as a
> heuristic to distinguish legitimate target addresses from invalid target addresses.)

I don't think you need to do anything special with DAD to accomplish 
that. When a new host appears it will send other packets to the router 
(the first might be either a RS or a NS depending on the host 
implementation) which includes a source IPv6 address and a source 
link-layer address. The router would (according to RFC 4861) populate 
the neighbor cache based on the source information that RS or NS.

What does overloading the DAD probe do in addition?

> In short, using the approach in the draft will yield a better result than not using it.

Please provide more information.

Do you have studies of existing implementations that show that they do 
not populate the neighbor cache based on the source of the RS or NS?

Is that an implementation issue or a standards issue?

> Since DOS attacks are impossible to prevent in the general case, all that can be
> done -- by any mechanism -- is to reduce the impact of such attacks.  This approach
> does reduce the impact of such attacks.

In don't see how it reduces the impact assuming the host and router 
follows RFC 4861.

>> It isn't at all clear when a node should discard entries from its
>> neighbor cache. That is potentially problematic when there are lots of
>> devices that pick new temporary IPv6 addresses each time they power on
>> since that will force routers to sooner or later discard entries from
>> the neighbor cache. The routers would have to guess which addresses
>> might still be assigned to the hosts.
> We rely on Neighbor Unreachability Detection to remove stale neighbors, as specified
> by the existing IETF ND standards.  We believe the standards make this clear.  We are
> happy to cite the existing ND standards in this area (NUD to remove stale neighbors)
> more explicitly in a future version of this draft.

But NUD only comes into play if there is traffic towards those IP 
addresses. An implementation needs a strategy to garbage collect NCEs in 
the absence of traffic that would trigger NUD.


>> Thus all in all this is not a robust approach to the problem.
> There is no perfect solution to a DOS attack.  This method yields better results than
> not using this method, reducing the severity of the attack in a measurable way.
> Thanks,
> Helen
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------