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

Owen DeLong <owen@delong.com> Sat, 14 November 2015 00:09 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 6C06B1B362A for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 16:09:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.111
X-Spam-Level:
X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 sIPBXndCgsBu for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 16:09:20 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0094B1B3629 for <v6ops@ietf.org>; Fri, 13 Nov 2015 16:09:19 -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 tAE06D86007973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 16:06:14 -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: <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.com>
Date: Fri, 13 Nov 2015 16:06:13 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <EFB44958-1C5D-4F08-9859-275489392B3D@delong.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> <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>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/-gMbg2g5a_jBdR4rMem7sxvpgFo>
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: Sat, 14 Nov 2015 00:09:21 -0000

> On Nov 13, 2015, at 15:44 , Hemant Singh (shemant) <shemant@cisco.com> wrote:
> 
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen@delong.com] 
> Sent: Friday, November 13, 2015 6:16 PM
> To: Hemant Singh (shemant)
> Cc: Alexandre Petrescu; v6ops@ietf.org
> Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
> 
> 
>> A LO interface may, but does not need to perform DAD as far as I am concerned. Sure, if it’s convenient for the coders, the performance impact is negligible and it keeps code paths consistent reducing >the potential for bugs.
> 
> Please reply to my comment where I said if the lo does not perform DAD, then the lo does not have to join the all-nodes and the solicited-node multicast addresses.   One has to look at the comprehensive picture.   A NA signaling a DAD dup is destined to the all-nodes multicast destination - but the lo interface has disabled DAD.   So why join the all-nodes address or the solicited-node multicast address?  If the interface is also not initiating nor replying to any address resolution, there is not ND operation required on this lo interface.

Depending on the implementation, it may be needed for neighbor discovery/reachability, though admittedly this is unlikely.

Solicited Node and all-nodes are used for several things besides just DAD.

I don’t see the relationship that you are seeing or at least I don’t see it as being the only relationship in question.

> 
>> However, that does not mean that those addresses don’t need to work with ND correctly as it may well be that application A binds to one address on LO and communicates with an entirely different >address also on LO to carry out transactions with application B. As a result, A will need to be able to discover the link layer address for B, effectively.
> 
> No.  The lo interface forwards a packet to the outbound interface which performs any ND address resolution. 

Not in any implementation I am aware of. Why would you expect such a thing?

Why would the LO address be on the same subnet as any “outbound” interface?

Your argument here appears nonsensical to me.

>> Arguably, ND isn’t necessary since the LO binding should take care of this, but most operating systems don’t bother to special case this as the effort offers little reward and substantial complexity.
> 
> Please note IPv6 ND and DAD are interface-scoped.   An OS has to confirm to interface-specific IPv6 DAD and ND properties. 

Yes… hence my confusion about your statements and questions above.

Even though they are interface-scoped, every interface on the system may use the same code paths for ND and DAD, in which case the LO interface may (unnecessarily) implement ND and/or DAD for convenience.

Owen