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

"Hemant Singh (shemant)" <> Fri, 13 November 2015 23:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A69A1B3573 for <>; Fri, 13 Nov 2015 15:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cv2YxmVNbr4M for <>; Fri, 13 Nov 2015 15:44:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D5CB1B3570 for <>; Fri, 13 Nov 2015 15:44:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2566; q=dns/txt; s=iport; t=1447458277; x=1448667877; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k3SMc0bnhaPtUb7r0ytYZwuAGSPIAlcUhpdBdK4eNz4=; b=gtUKK4K+SlPBdCf1O0XFCGj4+6ogz1jtWXH+9lJdpdVQzfGvqQyP26lO B4xYldRmDl9Mnd8mZVIeLQDtQGNPzQyyvcrfYSsweDH0FjtVf1GHNFR1Y HVzpcdu/MdJZcnAPIkyqpwRD4Fyfigo32RzWv9fVwN965nnZ50FuZ2Nxx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="49508878"
Received: from ([]) by with ESMTP; 13 Nov 2015 23:44:36 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id tADNiaos027478 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 23:44:36 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 18:44:35 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 18:44:35 -0500
From: "Hemant Singh (shemant)" <>
To: Owen DeLong <>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Date: Fri, 13 Nov 2015 23:44:35 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <! ! ! ! m> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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:44:39 -0000

-----Original Message-----
From: Owen DeLong [] 
Sent: Friday, November 13, 2015 6:16 PM
To: Hemant Singh (shemant)
Cc: Alexandre Petrescu;
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.

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

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