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

Owen DeLong <owen@delong.com> Fri, 13 November 2015 22:52 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 B3E341B33E1 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 14:52:09 -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 bYA0NgJ94Q2a for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 14:52:08 -0800 (PST)
Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 170F11B33DF for <v6ops@ietf.org>; Fri, 13 Nov 2015 14:52:07 -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 tADMn0Ot031416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 14:49:01 -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: <1c64119717ac4cc5a1e88dc8175af92f@XCH-RTP-005.cisco.com>
Date: Fri, 13 Nov 2015 14:49:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <38D33D99-5075-4A52-9B57-9FEC9B088EF0@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>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/OfkIdahSidB_g6f6fSPNtA06ZSc>
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:52:09 -0000

> On Nov 13, 2015, at 14:00 , Hemant Singh (shemant) <shemant@cisco.com> wrote:
> 
> 
> -----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

Sure, but you’re talking about this like the interface is autonomous from the operating system in this process which is absurd.

An interface doesn’t issue a DAD probe, the operating system does. The operating system, further, sends those out on the interface where the address in question is to be configured.

I suppose if the interface is a member of a bridge group (e.g. lo0 and eth0 are both members of br125 and the address in question is being configured on br125), then you would see the DAD request sent to both eth0 and lo0 as they are part of a common link (from the OS perspective, it is sent to br0 which in turn invokes the bridging driver which would deliver the packets in question to lo0 and eth0 as a result of the bridge group definition).

Short of that, however, the behavior you describe doesn’t match my understanding of the reality in any modern operating system with which I am familiar.

In most circumstances, it’s far from desirable to have addresses from the same subnet on different links separated by a router. (lo0 is separated from eth0 by the host in question which is acting as a router if it accepts packets on eth0 for destination address(es) configured on lo0 whether you want to admit this to yourself or not). In fact, most properly designed routers will flag such configurations as an error and refuse to install them.


> 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?

You’re talking about a strange corner case with a misconfigured router. Not sure why we should waste time engineering for such brokenness in the first place.

> 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.

I would argue that DAD on a lo interface is an absurd concept. By definition the addresses on a lo interface should not be outside of the exclusive control of the host in question and it should know all addresses in use on the lo interface.

The lo interface should not be sharing addresses with other interfaces unless they are members of a common bridge interface in which case the address would not apply to lo but would, instead, apply to the bridge group.

DAD is required on a bridge group interface.

There is no need for DAD on a loopback interface in any sane configuration.

Owen