From nobody Tue Nov 4 10:33:18 2014 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9951A0071 for ; Tue, 4 Nov 2014 04:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, 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 L3BLLv_9OOBS for ; Tue, 4 Nov 2014 04:24:51 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972681A00B7 for ; Tue, 4 Nov 2014 04:24:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3854; q=dns/txt; s=iport; t=1415103891; x=1416313491; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=wyQ2a6Xf+xa5Guwj8tmZCVYaIOVFnvluUvtddsqf8/A=; b=mFM2Ru1khnFgdUeI24grfJHgcHLOwYLrWm5QEGcxCWivTVF+VbzK+2ZG 5YADVeRlezVh1TdrijISCuB9D/tPHeSvnL1Qz7XrS8NyqYlDzGw31pyLB WMjKjhHlpuVHbUbVCt6UY+rITup6fTUt9ysU1yhdD7luBDwa/Wa+pQSrd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAEDEWFStJA2N/2dsb2JhbABcgw6BLATWKAKBHxYBAQEBAX2EAgEBAQQnUhIBCBEDAQILVh0JAQQBDQUIiDnMFgEBAQEBAQEBAgEBAQEBAQEBGop0hWsxgzSBHgWLPIZkjRiDTI1JhAmDeGyBBgIFGQYcgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,313,1413244800"; d="scan'208";a="366012916" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 04 Nov 2014 12:24:51 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sA4COoIl003903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Nov 2014 12:24:50 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.134]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 06:24:50 -0600 From: "Hemant Singh (shemant)" To: "6man-chairs@tools.ietf.org" <6man-chairs@tools.ietf.org>, "int-dir@ietf.org" Thread-Topic: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-dad-06 Thread-Index: Ac/4KlFdyRo9iN7xQmSpd0ArHxJOfw== Date: Tue, 4 Nov 2014 12:24:50 +0000 Message-ID: <75B6FA9F576969419E42BECB86CB1B89155F19F4@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.251.114] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/int-dir/Oh9pPgsoPHpRDW0k9lf0SpFoNuw X-Mailman-Approved-At: Tue, 04 Nov 2014 10:33:17 -0800 Cc: "Carlos Pignataro \(cpignata\)" , "Pascal Thubert \(pthubert\)" , "Hemant Singh \(shemant\)" , "Wes Beebee \(wbeebee\)" Subject: Re: [Int-dir] Internet Directorate review of draft-ietf-6man-enhanced-dad-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 12:24:53 -0000 Pascal, Thanks much for the review. I have made changes to the draft as per your c= omments. Some comments need more discussion. Please see in line below. From: "Pascal Thubert (pthubert)" Date: October 28, 2014 at 2:17:32 PM EDT To: Ole Troan , "int-dir@ietf.org" Cc: 6man Chairs <6man-chairs@tools.ietf.org> Subject: Re: [Int-dir] Internet Directorate review of draft-ietf-6man-enhan= ced-dad-06 Hi Ole: >Please find my review below: > > >", the interface moves the Target Address to the assigned =A0>=A0state."=20 >-> Please add: and discards the nonce. The SEND document in RFC 3971 does not use any text such as "discards = the nonce" when the SEND RFC also matches the nonce between sent and receiv= ed control messages. The SEND RFC, on page 5, also defines the nonce. The= definition says the nonce is used only once. Thus, I think, it is clear t= he nonce is discarded when used once.=20 >" If any probe is looped back within RetransTimer milliseconds after >=A0=A0having sent DupAddrDetectTransmits NS(DAD) messages, the interface >=A0=A0continues with another MAX_MULTICAST_SOLICIT number of NS(DAD) >=A0=A0messages transmitted RetransTimer millseconds apart. >I would have expected that the nonce is recomputed for these retries as in= dicated earlier in=20 >" >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Also, because the nodes will have >=A0=A0detected what appear to be looped back NS(DAD) messages, they will >=A0=A0continue to probe, and it is unlikely that they will choose the same >=A0=A0nonce the second time (assuming quality random number generators). >" Please see the definition of the Nonce on page 5 of RFC 3971 (SEND). = The nonce is used only once. Thus any subsequent DAD probe uses a new nonc= e.=20 >In 4.3 >" >If the interface does not receive any DAD failure >=A0=A0indications within RetransTimer milliseconds after having sent >=A0=A0DupAddrDetectTransmits Neighbor Solicitations, the interface moves >=A0=A0the Target Address to the assigned state. >" -> this text belongs to 4.2, and is already there I will discuss with other authors and see if we can remove the text s= ince it belongs to section 4.2. >In 4.4: >I expect that both the CGA and the public key have better properties for u= niqueness validation than the nonce, so the send node should probably use t= hat first. Note the SEND protocol uses a nonce to catch solicited ND responses. = When a node supports both the SEND protocol and the Enhanced DAD algorithm= the nonce used should be the same. That is context of section 4.4 of our = document. Use of CGA is an orthogonal issue. In any case, what if a node= does not support SEND but supports the Enhanced DAD algorithm? Then CGA c= annot be used. >4.5 >- I do not see that the introduction of 4862 is the best place for an RFC = 2119 keyword. > >" >For example, if the interface on an IPv6 node is >=A0=A0connected to a circuit that supports loopback testing, then the node >=A0=A0SHOULD implement the Enhanced DAD algorithm that allows the IPv6 >=A0=A0interface to self-heal after loopback testing is ended on the >=A0=A0circuit. =A0Another example is when the IPv6 interface resides on an >=A0=A0access concentrator running DAD Proxy. =A0The interface supports up = to >=A0=A0a hundred thousand IPv6 clients (broadband modems) connected to the >=A0=A0interface. =A0 > "-> please remove the normative text above that is redundant with the fir= st normative sentence below. I removed all normative text in the paragraph above. Thanks, Hemant