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

"Hemant Singh (shemant)" <shemant@cisco.com> Sun, 09 September 2012 12:33 UTC

Return-Path: <shemant@cisco.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 9F24F21F84D1 for <ipv6@ietfa.amsl.com>; Sun, 9 Sep 2012 05:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 twb1ZQRf34qC for <ipv6@ietfa.amsl.com>; Sun, 9 Sep 2012 05:33:22 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id D2D7F21F849D for <ipv6@ietf.org>; Sun, 9 Sep 2012 05:33:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2783; q=dns/txt; s=iport; t=1347194003; x=1348403603; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eomMbH4vbgiBnXNVKV0ToZPc+ihb+WaSUnjya6ueyCY=; b=OkL1stLewoB19/ZeYYHxU6fAEbwnYnUTCSOLpM2sLF2DYvzBrjHQKIiy q+lMBT5vF9pFnLU04Ea0fhUBL3UxDIJpRNTLmWhkL9RFUfqQiXZFtsPbg elV80xLhgJ2uFrC6Zp8W8KCyeuQ4OIyWjf/qOE1QlJ0+EumKm7Nk3JUPk Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALGLTFCtJV2b/2dsb2JhbABFu1OBB4IgAQEBBBIBJzQLDAQCAQgOAwQBAQsUCQcyFAkIAgQBDQUIGodumnqeeIsThVZgA6QTgWeCZoFaIw
X-IronPort-AV: E=Sophos;i="4.80,394,1344211200"; d="scan'208";a="119732643"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 09 Sep 2012 12:33:21 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q89CXKc6030812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Sep 2012 12:33:20 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Sun, 9 Sep 2012 07:33:20 -0500
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Ray Hunter <v6ops@globis.net>, "draft-ietf-6man-enhanced-dad@tools.ietf.org" <draft-ietf-6man-enhanced-dad@tools.ietf.org>
Subject: RE: I-D Action: draft-ietf-6man-enhanced-dad-01.txt
Thread-Topic: I-D Action: draft-ietf-6man-enhanced-dad-01.txt
Thread-Index: AQHNjbO8RVNJOyJbNUmsXyxWVlLVe5eBF0ew
Date: Sun, 09 Sep 2012 12:33:19 +0000
Message-ID: <75B6FA9F576969419E42BECB86CB1B8908381D@xmb-rcd-x06.cisco.com>
References: <504B2961.5060605@globis.net>
In-Reply-To: <504B2961.5060605@globis.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.250.33]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19172.005
x-tm-as-result: No--36.188800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 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 12:33:23 -0000

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