Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]

"Hemant Singh (shemant)" <shemant@cisco.com> Fri, 13 November 2015 22:00 UTC

Return-Path: <shemant@cisco.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08BE1B3326 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 14:00:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtexKvEVYD9D for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 14:00:10 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DBD1B3322 for <v6ops@ietf.org>; Fri, 13 Nov 2015 14:00:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1447452010; x=1448661610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RdmaVt7TZMTaskHCqtUwRk1q8TQaXh2qXwFehywklR4=; b=XMeYcHLhWaZRO8KdovQSYm7a97bZq95IewfN50NZv1v4Y0EWGzRPm8UR UlmJGzbUVzFQ15EL6vpQFrvs4sRgnK/aQGKkft3tSeHRzXiHTF4ONc8iT +v9I3BXOslmjVzXvFGp8nh9fVKDlTTxLYpx53YeyS/SaVgvDNdgKlXWAQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgBHXEZW/49dJa1dgzuBQga+RgENg?= =?us-ascii?q?WSGEAIcgSI4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAE?= =?us-ascii?q?ICAIEDgUIiCawAJA3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGEQoMzgUQFl?= =?us-ascii?q?kgBjR+cSwEfAQFChARyhDaBBwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="49484314"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 13 Nov 2015 22:00:09 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tADM09k1001022 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 22:00:09 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 17:00:08 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 17:00:08 -0500
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Owen DeLong <owen@delong.com>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIA==
Date: Fri, 13 Nov 2015 22:00:08 +0000
Message-ID: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com>
References: <8D175A1F-B1AE-44B4-838E-1C853B6C937D@cisco.com> <CAKD1Yr15C-uoxUw0kgWO-d=LmUK8qWGLS7vt+22W+k8xXtDY+g@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F393F1@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3941D@XCH-BLV-504.nw.nos.boeing.com> <563811DF.9020603@gmail.com> <2134F8430051B64F815C691A62D9831832F394F7@XCH-BLV-504.nw.nos.boeing.com> <563821EB.3040508@gmail.com> <2134F8430051B64F815C691A62D9831832F39A09@XCH-BLV-504.nw.nos.boeing.com> <56392B6D.8030703@gmail.com> <2134F8430051B64F815C691A62D9831832F3A88F@XCH-BLV-504.nw.nos.boeing.com> <2134F8430051B64F815C691A62D9831832F3A97F@XCH-BLV-504.nw.nos.boeing.com> <CAHDzDLBG8xZxUFsAuN-7WuruZcULF1QAS_ch=gD5rGQMZfskow@mail.gmail.com> <2134F8430051B64F815C691A62D9831832F3E8B0@XCH-BLV-504.nw.nos.boeing.com> <CAJE_bqd-1x5EJ=rkebiBFdNds6so5+iNGftiUf+MUu9P1up1bA@mail.gmail.com> <CAKD1Yr1X8UzQ58FeG6PYG9L1MyibV0J-JpcS2hxwzCdV=HizXg@mail.gmail.com> <ad0e90cf5f74407fa5338a7b6130bd1a@XCH-RTP-005.cisco.co! ! m> <5645DE07.3050605@gmail.com> <6f8ba1d9357b4cf786df990ebe09c965@XCH-RTP-005.cisco.com> <D76E6E81-419B-459D-AF5F-A6B8781CF445@delong.com> <a562066cf4d14f80aa94de314c27d632@XCH-RTP-005.cisco.com> <F5469EDB-E8E3-459A-ACF0-C9B2F11A8968@delong.com>
In-Reply-To: <F5469EDB-E8E3-459A-ACF0-C9B2F11A8968@delong.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.255.174]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/_8h2rg6NcVCQ00Pt-sXuCkdotl4>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 22:00:11 -0000

-----Original Message-----
From: Owen DeLong [mailto:owen@delong.com] 
Sent: Friday, November 13, 2015 3:41 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu; v6ops@ietf.org
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]


>Sure, but in such a case, DAD on the LAN interface wouldn’t detect the loopback nor would DAD on the loopback interface.

If the loopback interface issues a DAD probe and if the router sends the probe out the outbound interface, another host on the LAN segment does see the DAD probe.  On detecting a duplicate, another node sends an NA to signal a Dup.  The NA does reach the router's outbound interface and then the router knows the IPv6 address provisioned on the loopback interface and thus cannot be used

An app such as tftpv6 or NTPv6 uses IPv6 global address of the loopback interface as source IPv6 address.   If a duplicate exists in the LAN segment, couldn't the tftpv6 or NTPv6 server responses head to the dup in the LAN instead of the loopback interface on the router?

If a loopback interface does not perform DAD, then use a configuration on the loopback interface to set DupAddrDetectTransmits to zero.  Why change other text in RFC4861 to special-case a loopback interface to be excluded for DAD.

Hemant