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

Owen DeLong <> Fri, 13 November 2015 23:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0825E1B34BB for <>; Fri, 13 Nov 2015 15:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.111
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C_z8iiDIqlhr for <>; Fri, 13 Nov 2015 15:18:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8C5D41B34BC for <>; Fri, 13 Nov 2015 15:18:52 -0800 (PST)
Received: from (delong-dhcp29 []) (authenticated bits=0) by (8.14.5/8.14.5) with ESMTP id tADNFm3J001655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2015 15:15:48 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Owen DeLong <>
In-Reply-To: <>
Date: Fri, 13 Nov 2015 15:15:48 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <! ! ! ! m> <> <> <> <> <> <> <> <>
To: "Hemant Singh (shemant)" <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Cc: "" <>
Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2015 23:18:55 -0000

> On Nov 13, 2015, at 15:06 , Hemant Singh (shemant) <> wrote:
> -----Original Message-----
> From: Owen DeLong [] 
> Sent: Friday, November 13, 2015 5:49 PM
> To: Hemant Singh (shemant)
> Cc: Alexandre Petrescu;
> Subject: Re: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
>> 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.
> Where does the buck stop? If the lo interface does not perform DAD, the interface should not join the all-nodes and its solicited-node multicast address?   The lo interface should not support ND address resolution either.  The interfaces ends up not supporting any ND nor any DAD.

Let me try and be more clear since you seem determined to follow reductio ad absurdum.

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.

However, there’s no benefit. An LO address can’t have any address on it not assigned under the exclusive control of the host on which the LO interface is being managed, by definition, so it’s impossible for there to be a duplicate.

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.

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.

> If the lo interface does not perform DAD, as I said before, set the DupAddrDetectTransmits variable for the interface to be zero. 

I have no problem with that. Just saying that there’s no need for LO to perform DAD in any sane configuration. Probably no reason for LO not to default to DupAddrDetectTransmits=0 as well.