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

Owen DeLong <owen@delong.com> Mon, 16 November 2015 19:49 UTC

Return-Path: <owen@delong.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 F25541A88D0 for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 11:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.286
X-Spam-Level:
X-Spam-Status: No, score=-5.286 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] 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 rZ8SyPIp9W9m for <v6ops@ietfa.amsl.com>; Mon, 16 Nov 2015 11:49:47 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 634A51A88CB for <v6ops@ietf.org>; Mon, 16 Nov 2015 11:49:47 -0800 (PST)
Received: from delong-dhcp229.delong.com (delong-dhcp29 [192.159.10.229]) (authenticated bits=0) by owen.delong.com (8.14.5/8.14.5) with ESMTP id tAGJlgXc018940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 11:47:43 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <f3d8339f2bdf4947a632b01382e87ed1@XCH-RTP-005.cisco.com>
Date: Mon, 16 Nov 2015 11:47:42 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <03BC1DEF-17E0-49A1-A628-5CE786FFCF0D@delong.com>
References: <D76E6E81-419B-459D-AF5F-A6B8781CF445@delong.com> <a562066cf4d14f80aa94de314c27d632@XCH-RTP-005.cisco.com> <F5469EDB-E8E3-459A-ACF0-C9B2F11A8968@delong.com> <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com> <38D33D99-5075-4A52-9B57-9FEC9B088EF0@delong.com> <dcc3058655eb45319b5f2431db9667b0@XCH-RTP-005.cisco.com> <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com> <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com> <EFB44958-1C5D-4F08-9859-275489392B3D@delong.com> <a4050b82cc954ac8b25f50dc985451c9@XCH-RTP-005.cisco.com> <20151114181240.GI89490@Space.Net> <04d5779d611a4c5abd7db9093b991f81@XCH-RTP-005.cisco.com> <AE864A8C-9E88-4514-A0BA-A371DC3614DF@delong.com> <f3d8339f2bdf4947a632b01382e87ed1@XCH-RTP-005.cisco.com>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/yj9MpL61myolUa1DLAWUM9o0W-I>
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: Mon, 16 Nov 2015 19:49:49 -0000

> On Nov 14, 2015, at 17:21 , Hemant Singh (shemant) <shemant@cisco.com> wrote:
> 
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen@delong.com] 
> Sent: Saturday, November 14, 2015 7:58 PM
> To: Hemant Singh (shemant)
> Cc: Gert Doering; v6ops@ietf.org
> Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
>> I didn’t say you couldn’t bridge the LO and External interfaces… I said that short of doing that, having the same subnet on both interfaces is a misconfiguration.
> 
>> You haven’t proven that the interfaces aren’t bridged (or effectively so), nor have you proven that they are actually on the same subnet. Ergo, it is, actually, still a meaningless example.
> 
> An app has decides to use the IPv6 address of the lo interface to source the app's packets.   This is what the ping command in my example decides since the command is asked to use the source of the ICMPv6 packets as the lo interface's address.  Then usual data forwarding on the router takes over.  Routing decides from the packet destination, the packet has to egress out an outbound interface, say, eth0.   However, when the packet is to be egressed out eth0, the L2 destination lookup fails.  Eth0 issues a ND address resolution to resolve the destination uses its own source interface IPv6 address.  I forced the ND address resolution by clearing the IPv6 neighbor cache on the router.   Then I proved the packet is forwarded.   There is no bridging involved and packets are sourced fine using the lo interface.
> 
> Hemant

Which has exactly nothing to do with the idea of having ETH0 do DAD on an address on LO.

All I have been saying is that having an LO address on the same subnet as ETH0 without bridging is a misconfiguration.

I never said it couldn’t work. I never said it didn’t work.

Certainly at a minimum it is a recipe for a potential undetected duplicate address as the router SHOULD NOT respond to
an ND packet for it’s LO interface on ETH0 or any other non-LO interface.

Owen