Re: I-D Action: draft-ietf-6man-enhanced-dad-01.txt

Ray Hunter <v6ops@globis.net> Sun, 09 September 2012 18:32 UTC

Return-Path: <v6ops@globis.net>
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 D263E21F8549 for <ipv6@ietfa.amsl.com>; Sun, 9 Sep 2012 11:32:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599]
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 30m53gVOBVU2 for <ipv6@ietfa.amsl.com>; Sun, 9 Sep 2012 11:32:10 -0700 (PDT)
Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BA6ED21F84FC for <ipv6@ietf.org>; Sun, 9 Sep 2012 11:32:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 2D5DD870069; Sun, 9 Sep 2012 20:31:53 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3JoPLUwmFO4; Sun, 9 Sep 2012 20:31:24 +0200 (CEST)
Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id ECFF7870056; Sun, 9 Sep 2012 20:31:23 +0200 (CEST)
Message-ID: <504CE075.5070105@globis.net>
Date: Sun, 09 Sep 2012 20:31:17 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.4 (Macintosh/20120616)
MIME-Version: 1.0
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: Re: I-D Action: draft-ietf-6man-enhanced-dad-01.txt
References: <504B2961.5060605@globis.net> <75B6FA9F576969419E42BECB86CB1B8908381D@xmb-rcd-x06.cisco.com>
In-Reply-To: <75B6FA9F576969419E42BECB86CB1B8908381D@xmb-rcd-x06.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-6man-enhanced-dad@tools.ietf.org" <draft-ietf-6man-enhanced-dad@tools.ietf.org>, 6man Mailing List <ipv6@ietf.org>
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: Sun, 09 Sep 2012 18:32:10 -0000

Humbly suggest you read Section 4.3 one more time to double check that 
the text reflects what you mean.

I never claimed the two interfaces would have the same address.

Say Interface 2 is a stable interface. Interface 1 generates a new 
temporary address and performs DAD on it. The node remembers Interface 
1's address is tentative, and the nonce that was sent.

So one interpretation of the current text for me is that if Interface 2 
receives a NS(DAD) for interface1's address (which is in tentative or 
optimistic state) then the node should generate a system management message.

All I'm saying is that IMVHO it isn't entirely clear from the current 
text whether the filtering action is performed at node level, or locally 
per interface, or per (tentative) address.

IMHO the filtering action should only be applied if all 3 of the 
following constraints match:
1) the received nonce in the NS(DAD) message matches a saved nonce, and
2) the interface that received the NS(DAD) message is the same interface 
which was used to send this nonce (and associated NS(DAD) message), and
3) the (tentative) address in the received NS(DAD) message matches the 
(tentative) address associated with this receiving interface.

Then you have a loopback. And I think the text could be improved to make 
that clear.

Equally if a nonce is truly a nonce, then can't the nonce also be 
garbage collected immediately from local storage as soon as the first 
NS(DAD) loopback packet is received i.e. when the received NS(DAD) 
message is dropped? Is there really a need to always wait for DAD to 
complete in that case?

regards,
RayH


> Hemant Singh (shemant) <mailto:shemant@cisco.com>
> 9 September 2012 14:33
> Ray,
>
> Please see responses below for the use cases you raised.
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ray Hunter
> Sent: Saturday, September 08, 2012 7:18 AM
> To: draft-ietf-6man-enhanced-dad@tools.ietf.org
> Cc: 6man Mailing List
> Subject: I-D Action: draft-ietf-6man-enhanced-dad-01.txt
>
>
>> What should a receiver do if a node receives its own NS(DAD) on another
>> interface other than the source interface which is performing DAD?
>> [use case: two L3 interfaces on one node connected to one common L2
>> link, where one interface re-initialises or wants to use a new temporary
>> address and thus performs DAD. That isn't a loopback condition or error
>> condition at all if that NS(DAD) packet is received on the other interface.]
>
>> I think the text in section 4.3 could do with some clarification on
>> sending and receiving interfaces.
>
> For your use case, the issue won't happen during DAD for the global IPv6 address assigned to a L3 interface.  A node won't be able to configure two separate interfaces with the same IPv6 global address. The two L3 interfaces have different IPv6 global address(es) and for global address(es) each L3 interface is a separate link-local domain.  It's only for the link-local address that the two L3 interfaces may share one link-local domain.  Say, the two L3 interfaces are int1 and int2.  Then if int1 issues a NS(DAD) for the link-local address, and an identical NS(DAD) is received on int2 the implementation has to deal with DAD duplicates for all interfaces in the same link-local domain.
>
>> There are high availability situations that intentionally cause
>> collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6].
>> Do these need to be explicitly excluded from this draft? Or is that
>> someone else's problem?
>> [There is a table on the relevant manufacturers website labelled Table
>> 19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/
>> Virtual IPv6 is used for messages. AFAIK DAD is never performed on the
>> virtual address, as prevention of duplicate addresses is handled in the
>> HSRP protocol itself]
>>
>> There are high availability cases where multiple NICs are connected in
>> parallel [Teaming].
>> Does this require any special treatment? Or simply a clarification that
>> DAD is performed on the resulting virtual NIC interface or LACP bundle
>> rather, than individual physical links? Or is this plain obvious?
>
> I think it's obvious.  The manufacturer has also included documentation highlighting which IPv6 set of addresses are skipped for DAD.  Note, there are other networks where DAD is disabled such as a point-to-point links.
>
> Regards,
>
> Hemant
> Ray Hunter <mailto:v6ops@globis.net>
> 8 September 2012 13:17
> I have read this draft, and think this work is important.
>
> Some dumb questions for your consideration:
>
> Since the (tentative) IID and DAD operation is address and interface 
> specific; as well as the nonce, should the node also remember on which 
> interface the NS(DAD) was sent, and also for which (tentative) address?
>
> Should the node generate a separate nonce per instance of the DAD 
> algorithm, or per interface initialisation?
> [DAD may be performed multiple times for initialising a single 
> interface, and these may run in parallel if there are multiple 
> prefixes per interface, or if temporary addresses are in use as well 
> as SLAAC and DHCPv6...]
>
> Section 4.3 says "an interface on the node"
>
> What should a receiver do if a node receives its own NS(DAD) on 
> another interface other than the source interface which is performing 
> DAD?
> [use case: two L3 interfaces on one node connected to one common L2 
> link, where one interface re-initialises or wants to use a new 
> temporary address and thus performs DAD. That isn't a loopback 
> condition or error condition at all if that NS(DAD) packet is received 
> on the other interface.]
>
> I think the text in section 4.3 could do with some clarification on 
> sending and receiving interfaces.
>
> There are high availability situations that intentionally cause 
> collisions of IID and a virtual IPv6 address [e.g. HSRP IPv6].
> Do these need to be explicitly excluded from this draft? Or is that 
> someone else's problem?
> [There is a table on the relevant manufacturers website labelled Table 
> 19 "HSRP and IPv6 ND Addresses " which shows when the virtual MAC/ 
> Virtual IPv6 is used for messages. AFAIK DAD is never performed on the 
> virtual address, as prevention of duplicate addresses is handled in 
> the HSRP protocol itself]
>
> There are high availability cases where multiple NICs are connected in 
> parallel [Teaming].
> Does this require any special treatment? Or simply a clarification 
> that DAD is performed on the resulting virtual NIC interface or LACP 
> bundle rather, than individual physical links? Or is this plain obvious?
>
> When is it safe for a node to garbage collect the stored nonce?
> When should a node garbage collect the stored nonce [e.g. to  cover 
> equipment moves and interface re-patching]?
> Once DAD completes?
>
> Regards,
> RayH
>
> ------------------------------------------------------------------------