IETF Logo Mail Archive

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

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

Return-Path: <shemant@cisco.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 4A69A1B3573 for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 15:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv2YxmVNbr4M for <v6ops@ietfa.amsl.com>; Fri, 13 Nov 2015 15:44:37 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5CB1B3570 for <v6ops@ietf.org>; Fri, 13 Nov 2015 15:44:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0ArAgAbdUZW/5JdJa1egzuBQga+RQENgWSGEAIcgRo4FAEBAQEBAQGBCoQ0AQEBBCMRRQwEAgEIEQQBAQMCIwMCAgIwFAEICAIEDgUIiCawCJA3AQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBilGHdYFEBZZIAY0fgWKEQJYpAR8BAUKCER2BVnKENoEHAQEB
X-IronPort-AV: E=Sophos;i="5.20,289,1444694400"; d="scan'208";a="49508878"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP; 13 Nov 2015 23:44:36 +0000
Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-10.cisco.com (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 xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 18:44:35 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 18:44:35 -0500
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: Owen DeLong <owen@delong.com>
Thread-Topic: [v6ops] DAD again [was: draft-ietf-v6ops-host-addr-availability discussion]
Thread-Index: AQHRFohEbga31qC+rEetrILg3VHRBZ6LRgsAgAa8AYCAAnb/AIAFJeaAgAAIg4CAAEiPQIAAXDaA//+8puCAAJNfgP//ymfwgABnY4D//75MIAAMrMUAAAokG4D//7ZcAIAAThMA
Date: Fri, 13 Nov 2015 23:44:35 +0000
Message-ID: <158e13b7080a494cb3503476dc378a1e@XCH-RTP-005.cisco.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>
In-Reply-To: <8A25D382-C4C6-4FBA-B5FF-D10BD4F398A9@delong.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.255.174]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/KHkhWtYSx26KwDJCIypksZOTwpg>
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 23:44:39 -0000


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

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

Hemant

v2.23.0 | Report a Bug | By Email