From nobody Wed Mar 5 09:43:55 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE261A0692 for ; Wed, 5 Mar 2014 09:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 1rRjr3OV3AFJ for ; Wed, 5 Mar 2014 09:43:50 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6AA1A053B for ; Wed, 5 Mar 2014 09:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4902; q=dns/txt; s=iport; t=1394041427; x=1395251027; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Hd8iky9YAid62Voa5Uj3+C3g5VS8cxxNhO9JUw+BN74=; b=hDeFRDMqNCuqN38SVSHJUwiNYOVy0otpKZWf3kKoPsbL5JxeSPq4hf4v 7qrHAipnd9QoStD1p6xH+wrlZH/qJkMztXeY8Cl/i8MN8OVgRZPHR8K9d MRTBv3L/yOOEoiwyojyxdoANvmL2XpL5cLELQuJGesOxGBZJ/hXdEe5W/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAPZhF1OtJXG+/2dsb2JhbABXA4MGO1fBDYEaFnSCJQEBAQRJJAwMBAIBCBEDAQIBLjIdCAIEDgUbh17OTBeOHggbEAcGC4QnBJg9kiuDLYIq X-IronPort-AV: E=Sophos;i="4.97,593,1389744000"; d="scan'208";a="308220362" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 05 Mar 2014 17:43:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s25HhkAt027071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 17:43:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.113]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 11:43:46 -0600 From: "Eric Vyncke (evyncke)" To: "Fred Baker (fred)" , "Brzozowski, John" Thread-Topic: Question re your two drafts Thread-Index: AQHPNqtVUzft0lFG60qn/erShQmrZZrS/02AgAAnJAA= Date: Wed, 5 Mar 2014 17:43:45 +0000 Message-ID: References: <9CE7FB96-DF94-4648-A2B2-BB5B9F0DDE54@cisco.com> <5103EB9D-C732-4472-A7A5-415EB75512F8@cisco.com> <640FC29B-0A5D-4C14-B845-CC67FD9E25F1@cisco.com> In-Reply-To: <640FC29B-0A5D-4C14-B845-CC67FD9E25F1@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.61.174.141] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0429DC26B0EBCD45A1189920F975CBF1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/TGIYgczC-RQ-_znv2DhatDSJZZU Cc: "draft-yourtchenko-colitti-nd-reduce-multicast@tools.ietf.org" , "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-vyncke-6man-mcast-not-efficient@tools.ietf.org" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Question re your two drafts X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:43:53 -0000 Something in those lines for the problem statement (my I-D plus intro of Andrew & Lorenzo's one + some comments from the room): - explanations about how NDP has been specified as it is - explanations about 'unexpected' (for IETFers) behaviors of 802.11 + the two kinds of 'sleeping modes' =3D=3D> ignoring other radio communications for now? I.e. No VSAT, no 802.11p - impact on NDP (mcast, DAD, waking up causing traffic), possibly with a detailed mathematical model and verification by experimentation/measurements - not sure whether we need to write the 'annoyance' of mDNS On 5/03/14 15:03, "Fred Baker (fred)" wrote: > >On Mar 5, 2014, at 2:33 PM, "Brzozowski, John" > wrote: > >> I think it would be good for one of the documents (as we discussed >>during >> the WG meeting) to cover the various deployment scenarios and some >> approaches that have been used in the mean time to allow IPv6 >>deployments >> to advance. I think Eric Vyncke mentioned this may belong in his draft. > >Well, yes. I'd like a complete problem statement, which is to say >something that identifies the problem, which pretty much implies talking >about use cases in which the problems occur. > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> John Jason Brzozowski >> Comcast Cable >> m) 609-377-6594 >> o) 484-962-0060 >> w) www.comcast6.net >> e) john_brzozowski@cable.comcast.com >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Fred Baker >> Date: Monday, March 3, 2014 8:36 AM >> To: Eric Vyncke >> Cc: "draft-vyncke-6man-mcast-not-efficient@tools.ietf.org" >> , >> "draft-yourtchenko-colitti-nd-reduce-multicast@tools.ietf.org" >> , John >> Brzozowski , >> "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org> >> Subject: Re: Question re your two drafts >>=20 >>> OK. Glad I tumbled to the plan :-) >>>=20 >>> On Mar 3, 2014, at 7:41 AM, "Eric Vyncke (evyncke)" >>> wrote: >>>=20 >>>> Fred and John, >>>>=20 >>>> I think that Wednesday discussion could be useful indeed and this was >>>> the >>>> plan anyway? >>>>=20 >>>> The two drafts are linked together even if the authors did not really >>>> worked together on those drafts (lack of time); 'mine' tries to be the >>>> problem statement and Andrew's one is about one operational solution; >>>> you >>>> may be aware that Erik N., Pascal T. And others have a proposal in >>>>6MAN >>>> which modifies/replaces NDP (hence a protocol solution to the >>>>problem). >>>>=20 >>>> I do not think that the two draft should be merged though as one is >>>>the >>>> problem statement (could be 6MAN and/or V6OPS) and Andrew's I-D could >>>> be a >>>> V6OPS solution and Erik's I-D could be a 6MAN solution (which is what >>>> you >>>> propose as well). >>>>=20 >>>> Hope this helps to prepare Wednesday discussion (BTW expect slides >>>> today) >>>>=20 >>>> -=E9ric >>>>=20 >>>> On 3/03/14 07:39, "Fred Baker (fred)" wrote: >>>>=20 >>>>> John and I have commented to each other that your drafts could be >>>>> usefully merged. They address the same topic from different >>>>> perspectives >>>>> - one as a problem statement with hints at possible solutions, and >>>>>the >>>>> other more as operational solutions that could be put into place. >>>>>=20 >>>>> Two questions for you: >>>>>=20 >>>>> On Wednesday, I think it might make sense to have both of you >>>>>introduce >>>>> your drafts and your thoughts, and then have a combined discussion of >>>>> the >>>>> problem space and possible solution space. Do you think that would >>>>>make >>>>> sense, or do you want to have separate discussions focused on your >>>>> individual drafts? >>>>>=20 >>>>> Going forward, do you agree that a constructive merger is possible, >>>>>or >>>>> if >>>>> the drafts remain separate, a refactoring to make them clearly a >>>>> problem >>>>> statement (joint between v6ops and 6man), a set of operational >>>>> solutions >>>>> (for v6ops), and perhaps a set of proposed modifications to IPv6 >>>>> multicast (for 6man)? >>>>=20 >>>=20 >>> =80 Make things as simple as possible, but not simpler. >>> Albert Einstein >>>=20 >>=20 > >----------------------------------- >"We are learning to do a great many clever things...The next great task >will be to learn not to do them." > >- G. K. Chesterton (1874-1936) > > > > From nobody Thu Mar 6 02:09:29 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A591A021B for ; Thu, 6 Mar 2014 02:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 FVXo6nMqJat5 for ; Thu, 6 Mar 2014 02:09:19 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id F07D21A0205 for ; Thu, 6 Mar 2014 02:09:15 -0800 (PST) Received: from [31.133.180.98] (dhcp-b462.meeting.ietf.org [31.133.180.98]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s26A997N029841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 02:09:11 -0800 Message-ID: <53184947.9050305@sonic.net> Date: Thu, 06 Mar 2014 10:09:11 +0000 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: efficientnd-dt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;ljfzWxel4xG/29KVOBdzQA== M;EBmhXBel4xG/29KVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/m5N7aCatfrci91MyqFphrZPUeLE Subject: [Efficientnd-dt] efficient-nd DT meeting today at 5:30-6:30 in meeting room 5-6 X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:09:21 -0000 The room is in the 3rd floor business center which is in the tower - in the same area as the terminal room. Key agenda item is ideas/brainstorming on what to do with DAD not just from an efficiency perspective (network and host) but also from a robustness perspective. Erik From nobody Thu Mar 6 10:52:48 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9861A010A for ; Thu, 6 Mar 2014 10:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 HkQtOkKG1mb2 for ; Thu, 6 Mar 2014 10:52:46 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id E5AA61A0088 for ; Thu, 6 Mar 2014 10:52:45 -0800 (PST) Received: from [31.133.180.98] (dhcp-b462.meeting.ietf.org [31.133.180.98]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s26IqdxL021860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 10:52:40 -0800 Message-ID: <5318C3F7.4070307@sonic.net> Date: Thu, 06 Mar 2014 18:52:39 +0000 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: efficientnd-dt@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;FmvjfWCl4xGOtdKVOBdzQA== M;4oZffmCl4xGOtdKVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/KcmWMvJQ822euWrPxy_igFFxR9k Subject: [Efficientnd-dt] My DAD notes X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:52:47 -0000 Problems/constraints/goals: 1. No permission from network to form address 2. Duplicate MAC address in broadband and with vms (in some deployment) 3. Efficient Little/no multicast Save battery 4. Allow sleep 5. Partitioned link that heals When I left I think we had a handle on 1, 3, and 4. Makes sense to talk more about 2 - whether there is a way to detect IPv6 duplicate addresses even when the MAC address is a duplicate. Not clear whether we can also handle #5 - something which ACD does handle. Erik From nobody Thu Mar 6 11:23:29 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D368F1A012C for ; Thu, 6 Mar 2014 11:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 bGVfB7je-026 for ; Thu, 6 Mar 2014 11:23:21 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE0C1A00C2 for ; Thu, 6 Mar 2014 11:23:21 -0800 (PST) X-AuditID: c618062d-b7f858e0000031c7-3a-5318cb206969 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 6D.DB.12743.02BC8135; Thu, 6 Mar 2014 20:23:12 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 14:23:16 -0500 From: Samita Chakrabarti To: Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] My DAD notes Thread-Index: AQHPOW1JQTVzuWW0A02gbZ1iHYv1X5rUaxrw Date: Thu, 6 Mar 2014 19:23:15 +0000 Message-ID: References: <5318C3F7.4070307@sonic.net> In-Reply-To: <5318C3F7.4070307@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyuXRPuK7CaYlgg5Nv1S1efLrJaPGycwOb A5PHkiU/mTyedjezBDBFcdmkpOZklqUW6dslcGU8PPGDreA/V8Wy2ftYGhi/cnQxcnBICJhI zJvA2MXICWSKSVy4t56ti5GLQ0jgCKPExH0zWCGcZYwSP2ctAqtiE7CS6Ojdww5iiwjEStyf cJsFxBYW0JK4d34OK8hQEQFtiU3LhCFKjCQuvdjLBGKzCKhILJo1nw3E5hXwlZja8gssLiSg IdF9+ALYeE4BTYl9R9+B1TACHfT91BqwGmYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtpLE nNfXmCHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7Q4 tSw33chgEyMwFo5JsOnuYNzz0vIQozQHi5I475e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGLnXp9mfsLtd/nSWz/PoaV0F0n5xu58VHg159Y7r3ouPJZrVnV+aC00Pfd2jYfFnQsUF //j3828+6nh+da+px8XvUnplk7ZeO9llr6jHb+ekb6V+6UIbz1RH3kcm83KsLh/V9P1tsLLd lFmx1SE6prdyetcxxXC9TSFXvhy/+y7908ebrTPnsymxFGckGmoxFxUnAgCXDtBqUwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/ZzixTh9Ph4zkfbZuS-Kv7La9r6I Subject: Re: [Efficientnd-dt] My DAD notes X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:23:25 -0000 A few ideas that have been discussed after you left: - What happens when registration fails and there is one default router in t= he network? Suggestions from Andrew and Lorenzo: the host should fall back to the legac= y behavior [not energy aware] Other suggestions: - Likes to see registration-like enhancements optional [ which is optional = today in the efficient-nd draft] - Like to provide registration like benefit in mixed-mode as well -Samita -----Original Message----- From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of = Erik Nordmark Sent: Thursday, March 06, 2014 10:53 AM To: efficientnd-dt@ietf.org Subject: [Efficientnd-dt] My DAD notes Problems/constraints/goals: 1. No permission from network to form address 2. Duplicate MAC address in b= roadband and with vms (in some deployment) 3. Efficient Little/no multicast Save battery 4. Allow sleep 5. Partitioned link that heals When I left I think we had a handle on 1, 3, and 4. Makes sense to talk more about 2 - whether there is a way to detect IPv6 du= plicate addresses even when the MAC address is a duplicate. Not clear whether we can also handle #5 - something which ACD does handle. Erik _______________________________________________ Efficientnd-dt mailing list Efficientnd-dt@ietf.org https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Thu Mar 6 11:34:13 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD681A0114 for ; Thu, 6 Mar 2014 11:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 MBNikM0sm7or for ; Thu, 6 Mar 2014 11:34:02 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5E1A0157 for ; Thu, 6 Mar 2014 11:34:00 -0800 (PST) Received: from [31.133.180.98] (dhcp-b462.meeting.ietf.org [31.133.180.98]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s26JXomM024793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 11:33:51 -0800 Message-ID: <5318CD9D.70109@sonic.net> Date: Thu, 06 Mar 2014 19:33:49 +0000 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Samita Chakrabarti , "efficientnd-dt@ietf.org" References: <5318C3F7.4070307@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;/rmaPmal4xGqYLRWCY+HFQ== M;JNUXP2al4xGqYLRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/KzEi8y8FYrT1lkxC8bKRTJTfGGs Subject: Re: [Efficientnd-dt] My DAD notes X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:34:10 -0000 Samita, thanks for the notes. On 3/6/14 7:23 PM, Samita Chakrabarti wrote: > A few ideas that have been discussed after you left: > > - What happens when registration fails and there is one default router in the network? > > Suggestions from Andrew and Lorenzo: the host should fall back to the legacy behavior [not energy aware] Makes sense. > > Other suggestions: > - Likes to see registration-like enhancements optional [ which is optional today in the efficient-nd draft] I think that is basically saying that we should assume mixed-mode forever. (which would be fine with me) > - Like to provide registration like benefit in mixed-mode as well I think we have that already - unless I'm missing something. One random though - if we have registered addresses in the routers would there be cases we'd use that only for DAD (and do address resolution using the normal way)? [Excuses if that makes no sense - it's been a long week.] Erik > > -Samita > > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of Erik Nordmark > Sent: Thursday, March 06, 2014 10:53 AM > To: efficientnd-dt@ietf.org > Subject: [Efficientnd-dt] My DAD notes > > > Problems/constraints/goals: > > 1. No permission from network to form address 2. Duplicate MAC address in broadband and with vms (in some deployment) 3. Efficient > Little/no multicast > Save battery > 4. Allow sleep > 5. Partitioned link that heals > > When I left I think we had a handle on 1, 3, and 4. > Makes sense to talk more about 2 - whether there is a way to detect IPv6 duplicate addresses even when the MAC address is a duplicate. > > Not clear whether we can also handle #5 - something which ACD does handle. > > Erik > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt > From nobody Thu Mar 6 17:40:58 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08101A01A0 for ; Thu, 6 Mar 2014 17:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 HbW3R0um8uCs for ; Thu, 6 Mar 2014 17:40:54 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4CC1A0186 for ; Thu, 6 Mar 2014 17:40:54 -0800 (PST) X-AuditID: c6180641-b7f2f8e000002cdc-b9-531923a33da9 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 04.CE.11484.3A329135; Fri, 7 Mar 2014 02:40:51 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 20:40:49 -0500 From: Samita Chakrabarti To: Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] My DAD notes Thread-Index: AQHPOW1JQTVzuWW0A02gbZ1iHYv1X5rUaxrwgABb24CAABGA0A== Date: Fri, 7 Mar 2014 01:40:49 +0000 Message-ID: References: <5318C3F7.4070307@sonic.net> <5318CD9D.70109@sonic.net> In-Reply-To: <5318CD9D.70109@sonic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPoO5iZclgg8Uv1CxefLrJaPGycwOb A5PHkiU/mTyedjezBDBFcdmkpOZklqUW6dslcGVsX+1XsICn4vGzjcwNjLc5uxg5OSQETCSW dv9igbDFJC7cW8/WxcjFISRwhFFi/vxPrBDOMkaJhVdvMINUsQlYSXT07mEHsUUEYiXuT7gN 1i0soCVx7/wcoAYOoLi2xKZlwhAlThKzb84DK2ERUJGY+7ePEcTmFfCV2HHuJNT8TkaJTWuv sYIkOAXUJZZfvQRmMwJd9P3UGiYQm1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSTx8fd8 doh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctN NzLcxAiMhmMSbI47GBd8sjzEKM3BoiTO++Wtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG RsHXfOd8uyOs2nc0fnjtsYcrWI+tvOzFV/sZ+rV746P8ma89NCmxaxH7+5GzcN+E3+Unfnv9 c9tWp/VQ6WOI7/XqslunH11dsVQicXL0RsZnl04ETZV66rhv8jGllK2qP9efevT0a2efvICC o9q0JfOYv56Tkl+f7L6kczqXVvBP7xAOduVgFiWW4oxEQy3mouJEACkXI4BUAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/HAGidFeKPQ4OZrIDAYycYG67rpQ Subject: Re: [Efficientnd-dt] My DAD notes X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 01:40:57 -0000 One random though - if we have registered addresses in the routers would th= ere be cases we'd use that only for DAD (and do address resolution using th= e normal way)? [Excuses if that makes no sense - it's been a long week.] Erik [SC>] If the node registers in order to avoid DAD, then it makes sense to = do address resolution via the Router. Without that, NS address resolution m= essages will still be multicast and they can be lot more in case of short l= ived connections; defeats the purpose of reducing multicast in my mind. Thanks, -Samita > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On=20 > Behalf Of Erik Nordmark > Sent: Thursday, March 06, 2014 10:53 AM > To: efficientnd-dt@ietf.org > Subject: [Efficientnd-dt] My DAD notes > > > Problems/constraints/goals: > > 1. No permission from network to form address 2. Duplicate MAC address in= broadband and with vms (in some deployment) 3. Efficient > Little/no multicast > Save battery > 4. Allow sleep > 5. Partitioned link that heals > > When I left I think we had a handle on 1, 3, and 4. > Makes sense to talk more about 2 - whether there is a way to detect IPv6 = duplicate addresses even when the MAC address is a duplicate. > > Not clear whether we can also handle #5 - something which ACD does handle= . > > Erik > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt > From nobody Fri Mar 7 10:24:49 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51A21A00EC for ; Fri, 7 Mar 2014 10:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 en2DVqqaswdt for ; Fri, 7 Mar 2014 10:24:44 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7AF1A0143 for ; Fri, 7 Mar 2014 10:24:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2457; q=dns/txt; s=iport; t=1394216680; x=1395426280; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=28OoIjh+emofx5Rc1ZFByZUtmNPuB2vP2yJ4a27Sgkc=; b=k5wEsHDX7tb2ZlP7ub5sT2iTa/67g+u98toLd/EE8+npYALOvn0N9Y/r W6cyJXrYK3Zuxjmr/2sa1LOFBf8VyFunQy8TWduEbfqGqrP0mbHCvpGsA XK9WdT4EPEeqR3//nkPbxzwvSMIdYYDYiqNZYRI9ZGXze+fxH8ontK7Or o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJANGlOtJV2a/2dsb2JhbABagwY7V8BXT4EUFnSCJQEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIh3EN0CkTBI1zNzgGgx6BFASUV5YXgy2CKw X-IronPort-AV: E=Sophos;i="4.97,609,1389744000"; d="scan'208";a="25759198" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 07 Mar 2014 18:24:40 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s27IOd0H024246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 18:24:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 12:24:39 -0600 From: "Pascal Thubert (pthubert)" To: Samita Chakrabarti , Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] My DAD notes Thread-Index: AQHPOW1F5O+Tjbsqyki2R9B2feYkLJrU1MWAgAAC9ICAAGaKgIAAqXMg Date: Fri, 7 Mar 2014 18:24:38 +0000 Deferred-Delivery: Fri, 7 Mar 2014 18:24:00 +0000 Message-ID: References: <5318C3F7.4070307@sonic.net> <5318CD9D.70109@sonic.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.82.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/TuAFo8Yw7vsTR4zP_3yjq_afb1g Subject: Re: [Efficientnd-dt] My DAD notes X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:24:46 -0000 Hello Erik: At a minimum, the router that has a registration could observe or defend re= gistered addresses. Today, Cisco SAVI devices do not support unicast NS lookup because the host= does not know where to ask. But we can proxy for snooped entries, or defend them against theft by a thi= rd party. Cheers, Pascal > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf O= f > Samita Chakrabarti > Sent: vendredi 7 mars 2014 02:41 > To: Erik Nordmark; efficientnd-dt@ietf.org > Subject: Re: [Efficientnd-dt] My DAD notes >=20 >=20 >=20 >=20 > One random though - if we have registered addresses in the routers would = there > be cases we'd use that only for DAD (and do address resolution using the = normal > way)? [Excuses if that makes no sense - it's been a long week.] >=20 > Erik >=20 > [SC>] If the node registers in order to avoid DAD, then it makes sense t= o do > address resolution via the Router. Without that, NS address resolution me= ssages > will still be multicast and they can be lot more in case of short lived c= onnections; > defeats the purpose of reducing multicast in my mind. >=20 > Thanks, > -Samita >=20 > > -----Original Message----- > > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On > > Behalf Of Erik Nordmark > > Sent: Thursday, March 06, 2014 10:53 AM > > To: efficientnd-dt@ietf.org > > Subject: [Efficientnd-dt] My DAD notes > > > > > > Problems/constraints/goals: > > > > 1. No permission from network to form address 2. Duplicate MAC address = in > broadband and with vms (in some deployment) 3. Efficient > > Little/no multicast > > Save battery > > 4. Allow sleep > > 5. Partitioned link that heals > > > > When I left I think we had a handle on 1, 3, and 4. > > Makes sense to talk more about 2 - whether there is a way to detect IPv= 6 > duplicate addresses even when the MAC address is a duplicate. > > > > Not clear whether we can also handle #5 - something which ACD does hand= le. > > > > Erik > > > > _______________________________________________ > > Efficientnd-dt mailing list > > Efficientnd-dt@ietf.org > > https://www.ietf.org/mailman/listinfo/efficientnd-dt > > >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Fri Mar 14 11:04:55 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232E81A01B7 for ; Fri, 14 Mar 2014 11:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 eXAmJma4Qz_6 for ; Fri, 14 Mar 2014 11:04:52 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 82F4E1A01C0 for ; Fri, 14 Mar 2014 11:04:52 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2EI4i5Q022097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 14 Mar 2014 11:04:44 -0700 Message-ID: <532344BC.3030408@sonic.net> Date: Fri, 14 Mar 2014 11:04:44 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "efficientnd-dt@ietf.org" References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> In-Reply-To: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> X-Forwarded-Message-Id: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;UvUtH6Or4xGJEdKVOBdzQA== M;hP05H6Or4xGJEdKVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/nO3Mx6_YTWRWmDheteFT36zIWF0 Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 18:04:54 -0000 Let's keep some momentum going by touching base for half an hour or less every other week starting next week. Please pick a time in the poll. http://doodle.com/usa83cbr5z5mfuny In terms of working through the issues it would be good have some structure. What do we need to do as a team to get more data from deployment problems? What about analysis of existing implementations e.g., to understand the unsolicited NAs to all-nodes we saw in London? I suggest we work through the suggestions somewhat separate for the three areas: - RS/RA - NS/NA for address resolution - DAD I'll start writing up the ideas and issues following that structure, but if someone wants to take one of them and drive it let me know. Erik From nobody Fri Mar 14 16:29:30 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2621A020F for ; Fri, 14 Mar 2014 16:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 iaPNIXz5qYns for ; Fri, 14 Mar 2014 16:29:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 039F41A0203 for ; Fri, 14 Mar 2014 16:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2953; q=dns/txt; s=iport; t=1394839760; x=1396049360; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=diSKclwdRwgeQCoN/RK2Z58JszrQVPcBviwJJTELzmw=; b=ZdF4UH4KfQKs6Bdo4vf2LrPFxOj5sgDOm6cQN8Kz0Eum/qnd/ZMy1MAE 5C38PdGly1RFw414l2KTP2OaClfhUViuhOpMvRKjH8oEq8+J8bwgBhz8o x86h2MRxXicutGt/yzUoXJYn3LPvbY6DciJS4OcCXBsbKbOmLPPJBXOLT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAE+QI1OtJXG9/2dsb2JhbABZgwY7V7pKhmFPgRQWdIIlAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQBEggTh14N1DIXjg8EIzgGgx6BFASZd5B8gy2BaUI X-IronPort-AV: E=Sophos;i="4.97,657,1389744000"; d="scan'208";a="310484660" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 14 Mar 2014 23:29:19 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2ENTJu2018383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 23:29:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.10]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 18:29:19 -0500 From: "Pascal Thubert (pthubert)" To: Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" Thread-Index: AQHPP6/mGLzLqUw8dkK2on8zPZHGSZrhNGzQ Date: Fri, 14 Mar 2014 23:29:18 +0000 Deferred-Delivery: Fri, 14 Mar 2014 23:29:00 +0000 Message-ID: References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> In-Reply-To: <532344BC.3030408@sonic.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Igodgeb0PpUdjZq6PnFFVSBaHEA Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 23:29:29 -0000 Hello Erik; Your split of the problem space makes sense to me; we could make a table to= map it with solution space.=20 The solution space we discussed so far to divide the broadcast domain would= be (to my recollection): 1) no ND, a /64 per device. I think John will detail this approach and use = cases where that makes sense (including 3G). 2) Mixed registered node vs. classical nodes (efficient ND). In that model = the usage of NS/NA multicast is reduced roughly by the ratio of registered = nodes. 3) Multiple private (secondary) vlans with a primary (federating) vlan wher= e all the common services would reside. In that model devices in a pvlan ca= nnot reach devices in other pvlans and DAD proxy is used to avoid address c= ollisions globally. All multicasts including NS/NA from the primary vlan ar= e effectively flooded but not multicasts originated from the pvlans which a= re limited to the pvlan and the primary. This is also deployable today and = we probably can document how it works and when it makes sense to use it.=20 4) backbone router model: If registered nodes are all on the "southern" sid= e of the backbone routers and classical ND runs over a federating backbone = on the "northern" side then NS / NA mcasts can be completely avoided in the= southern domain. With the backbone routers acting as proxies, any to any r= eachability is available for global and ULA unicast addresses.=20 In model 1 the subnet can be much smaller than the link. In model 2 the sub= net is congruent with the link. In the last 2 models, the subnet is larger = than the links, IOW we are in multilink subnet space. Cheers, Pascal > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf O= f Erik > Nordmark > Sent: vendredi 14 mars 2014 11:05 > To: efficientnd-dt@ietf.org > Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" >=20 >=20 > Let's keep some momentum going by touching base for half an hour or less > every other week starting next week. >=20 > Please pick a time in the poll. >=20 > http://doodle.com/usa83cbr5z5mfuny >=20 > In terms of working through the issues it would be good have some structu= re. >=20 > What do we need to do as a team to get more data from deployment problems= ? > What about analysis of existing implementations e.g., to understand the > unsolicited NAs to all-nodes we saw in London? >=20 > I suggest we work through the suggestions somewhat separate for the three > areas: > - RS/RA > - NS/NA for address resolution > - DAD >=20 > I'll start writing up the ideas and issues following that structure, but = if someone > wants to take one of them and drive it let me know. >=20 > Erik >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Sat Mar 15 03:43:47 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835811A00E3 for ; Sat, 15 Mar 2014 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 OOQAxipqcqZj for ; Sat, 15 Mar 2014 03:43:38 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B902F1A00E8 for ; Sat, 15 Mar 2014 03:43:38 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-4d-53242c81ef63 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7C.8F.12743.18C24235; Sat, 15 Mar 2014 11:33:37 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Sat, 15 Mar 2014 06:43:31 -0400 From: Samita Chakrabarti To: "Pascal Thubert (pthubert)" , Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" Thread-Index: AQHPP6/toaGDuQL+7UmEKteCpuEujprhfh4AgAB41vA= Date: Sat, 15 Mar 2014 10:43:29 +0000 Message-ID: References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyuXRPiG6jjkqwwcXDUhYvPt1ktHjZuYHN YsaUd4wOzB5Tfm9k9Viy5CeTx9PuZpYA5igum5TUnMyy1CJ9uwSujA27zArmylQcP3SXvYHx m1gXIyeHhICJxMWrE9ggbDGJC/fWA9lcHEICRxglJkxZyQjhLGeU2LzjETtIFZuAlURH7x52 kISIQD+jxIMznSwgCWEBV4kLe68ygtgiAm4Sc+4vZIewrSRWn5rBCmKzCKhKLD1/FijOwcEr 4Ctx9K0cxIJdjBLLJqwEm8MJFH+8fDrYHEagk76fWsMEYjMLiEvcejKfCeJUAYkle84zQ9ii Ei8f/2OFsBUl9vVPZ4eo15FYsPsTG4StLbFs4Wuwel4BQYmTM5+wTGAUnYVk7CwkLbOQtMxC 0rKAkWUVI0dpcWpZbrqRwSZGYIwck2DT3cG456XlIUZpDhYlcd4vb52DhATSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTC6LYj9e0o83/xi8xr+l6lmvWdfzvvWoLxi09sbWnfKp7uIyTXr72vz Wad5octk6/xTn3YzLfUUUcwNPfxOx9Bl0r6MPVMkGaK3xzFHyTZKbQl6KvX3eVXxhneimcql T//uNuaV2nVQcmNs6zbTk61/mE5PkF3v7exTJrn6RlToX/93Ox62SWYqsRRnJBpqMRcVJwIA DwGYeV8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Emq0PEfTv48_OcHyYfoAIfsfF9w Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 10:43:45 -0000 Hi Pascal/Erik: Will 6man be interested in dealing with multi-link subnets? But I agree that we should at least separate out the problem space for the= multi-link subnet models. -Samita -----Original Message----- From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert) Sent: Friday, March 14, 2014 4:29 PM To: Erik Nordmark; efficientnd-dt@ietf.org Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" Hello Erik; Your split of the problem space makes sense to me; we could make a table to= map it with solution space.=20 The solution space we discussed so far to divide the broadcast domain would= be (to my recollection): 1) no ND, a /64 per device. I think John will detail this approach and use = cases where that makes sense (including 3G). 2) Mixed registered node vs. classical nodes (efficient ND). In that model = the usage of NS/NA multicast is reduced roughly by the ratio of registered = nodes. 3) Multiple private (secondary) vlans with a primary (federating) vlan wher= e all the common services would reside. In that model devices in a pvlan ca= nnot reach devices in other pvlans and DAD proxy is used to avoid address c= ollisions globally. All multicasts including NS/NA from the primary vlan ar= e effectively flooded but not multicasts originated from the pvlans which a= re limited to the pvlan and the primary. This is also deployable today and = we probably can document how it works and when it makes sense to use it.=20 4) backbone router model: If registered nodes are all on the "southern" sid= e of the backbone routers and classical ND runs over a federating backbone = on the "northern" side then NS / NA mcasts can be completely avoided in the= southern domain. With the backbone routers acting as proxies, any to any r= eachability is available for global and ULA unicast addresses.=20 In model 1 the subnet can be much smaller than the link. In model 2 the sub= net is congruent with the link. In the last 2 models, the subnet is larger = than the links, IOW we are in multilink subnet space. Cheers, Pascal > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On=20 > Behalf Of Erik Nordmark > Sent: vendredi 14 mars 2014 11:05 > To: efficientnd-dt@ietf.org > Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" >=20 >=20 > Let's keep some momentum going by touching base for half an hour or=20 > less every other week starting next week. >=20 > Please pick a time in the poll. >=20 > http://doodle.com/usa83cbr5z5mfuny >=20 > In terms of working through the issues it would be good have some structu= re. >=20 > What do we need to do as a team to get more data from deployment problems= ? > What about analysis of existing implementations e.g., to understand=20 > the unsolicited NAs to all-nodes we saw in London? >=20 > I suggest we work through the suggestions somewhat separate for the=20 > three > areas: > - RS/RA > - NS/NA for address resolution > - DAD >=20 > I'll start writing up the ideas and issues following that structure,=20 > but if someone wants to take one of them and drive it let me know. >=20 > Erik >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt _______________________________________________ Efficientnd-dt mailing list Efficientnd-dt@ietf.org https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Sun Mar 16 22:46:42 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0601A038E for ; Sun, 16 Mar 2014 22:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 618bue4J-m3w for ; Sun, 16 Mar 2014 22:46:37 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2D41A02CC for ; Sun, 16 Mar 2014 22:46:37 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id w8so4901931qac.12 for ; Sun, 16 Mar 2014 22:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rpngR7Wc/oBZBqZXnV2pvLuFskQX1iAee3yDD0x3YRI=; b=j3S9zGzbqWbaMizNPv3TDJ0F5QeO0d69hUg/oHcPOJDA7uVTBl3lciI+iFGDFUu2VH tr1zzjM1GCcuHkQGdvNFsoC0HIfdOAIjK070SLoegootr729jH1ElTGpsEGJdJgdRUCj Pvsvkou1wasS3Jfa7Fc7I79vp4qIplf9GcpiSeofcC4UiSREgzP58hNUok8q8pMUMa0Y BQdmwausJZS70gl8WuMAy3YYhXhXz1fCoFUocxWWnvSVoC8ZzzrllAkGzHoU4h7Rqw7s nvNVP3kZwSEBz5y4vPchIErUXDf7Ectx7ORHq4fWD2rg1UmZ07ipTc6ymnDi5hBypM0H XD6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rpngR7Wc/oBZBqZXnV2pvLuFskQX1iAee3yDD0x3YRI=; b=T/53PIbs92XYMZtqXxvUw1Wy4jzVe/sVAu8GW0ERv4SW1iG4ARuC6Uce9ciM2aiY/U NYlZEQtLHuXn0hrla1XiCnxQsS/SMGj906jGOAj5WDVm2iys1yOIaRmx2/vtw/JMb1rf aNH9okoQWnnR/FaHu6pGRj7yXAbJaHxroP6zkMt64YSr45tPtNfrmeIVJ8+rVpAHwsgS /NwYTpVRJ2dQCMsiUbTQnIsoMaKStBvXtf2jERSisc395bztGaP6t2qm8apQmMk9uBKz zjMkMj8Cestm4zyRtUEl5SABZjL5bVrm1sHEbn3Lx0qbwd8yed2JvXrJXHFEz8tM2UcG G0EQ== X-Gm-Message-State: ALoCoQlxHooySKhcZzbYsqEAx+QEBYjZogwetPcHlwZSwqUDjiDV1hfJN6BvQuKbaBeYNsUkRkgA1wY11Bod/G29T4bjWndH7nlsNLyeb7StjdS8NiEV3LWm3HlYmDpoU5sFKi8ZmP3m102Y7KWOU7la6bngyzyTf94jSYUupOTQO5a4y+UQJ46Ci6ARad5aPNiSf9jRlpdBHjbRHn9RBeLPOH8clzpt3g== X-Received: by 10.229.96.199 with SMTP id i7mr1036525qcn.20.1395035189656; Sun, 16 Mar 2014 22:46:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.28.195 with HTTP; Sun, 16 Mar 2014 22:46:09 -0700 (PDT) In-Reply-To: References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> From: Erik Kline Date: Mon, 17 Mar 2014 14:46:09 +0900 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Je1pTDuf8fYPhVyk6Z8H76ZpGpI Cc: Erik Nordmark , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 05:46:39 -0000 Pascal, > 2) Mixed registered node vs. classical nodes (efficient ND). In that model the usage of NS/NA multicast is reduced roughly by the ratio of registered nodes. ... > In model 1 the subnet can be much smaller than the link. In model 2 the subnet is congruent with the link. In the last 2 models, the subnet is larger than the links, IOW we are in multilink subnet space. It's not clear to me that this #2 mixed mode is not also the multi-link model. In the "factory with lots of sensors and some normal hosts" example, that to me was a multi-link example, was it not? From nobody Sun Mar 16 23:35:37 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39ECB1A03A5 for ; Sun, 16 Mar 2014 23:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 mb1WvGAV-7jG for ; Sun, 16 Mar 2014 23:35:33 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 972291A03A3 for ; Sun, 16 Mar 2014 23:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1315; q=dns/txt; s=iport; t=1395038126; x=1396247726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TrK0+5d6IciATMTkAOWIYa/bcbPWJ3mY+6UP99mxx9Q=; b=gxtX7gmoKOxBLDNoBMDxhbrq5Eq5QZYjYY9zsbRMrQYtDyEGaWAGQ9Oz Rsyfm3ciEjDbe0e/H4+493hPPjyjoaXL/LKohBCNC4uIShQ9HYC9//Mq4 xli3l5uCW7ozMF+SSy1dRfJzWVqcO+uD6/5I2xU2fSZ/ioizpoYq9EqQs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAFOXJlOtJXG8/2dsb2JhbABZgwbDGYEXFnSCJQEBAQMBeQULAgEIDjgyJQIEDgWHcQjSNReONTMHgySBFAEDiRqPLJIvgy0 X-IronPort-AV: E=Sophos;i="4.97,668,1389744000"; d="scan'208";a="310714498" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 17 Mar 2014 06:35:25 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2H6ZP2s028630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 06:35:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.10]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 01:35:25 -0500 From: "Pascal Thubert (pthubert)" To: Erik Kline Thread-Topic: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" Thread-Index: AQHPP6/mGLzLqUw8dkK2on8zPZHGSZrhNGzQgAPoaoD//7nxHQ== Date: Mon, 17 Mar 2014 06:35:24 +0000 Message-ID: <27C7C256-D1B9-4F5A-898F-7BD9724F6FB4@cisco.com> References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: 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/efficientnd-dt/2LvK3MjRGeFZ8uC7m3ygbw9gTY8 Cc: Erik Nordmark , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 06:35:35 -0000 Hello Erik > Le 17 mars 2014 =E0 06:46, "Erik Kline" a =E9crit : >=20 > Pascal, >=20 >> 2) Mixed registered node vs. classical nodes (efficient ND). In that mod= el the usage of NS/NA multicast is reduced roughly by the ratio of register= ed nodes. > ... >> In model 1 the subnet can be much smaller than the link. In model 2 the = subnet is congruent with the link. In the last 2 models, the subnet is larg= er than the links, IOW we are in multilink subnet space. >=20 > It's not clear to me that this #2 mixed mode is not also the > multi-link model. In the "factory with lots of sensors and some > normal hosts" example, that to me was a multi-link example, was it > not? That is model 4 actually. In both cases the router will proxy ND. In model 2, the TLLA in the proxied NA will be that of the device. The pack= ets can be switched to the mac of the destination and Layer 2 has to suppor= t the mobility of the device.=20 In model 4 the TLLA in the proxied NA will be that of the router. This allo= ws for sleeping devices and not switchable addresses, eg mac64 in 802.15.4 = or firewire. WiFi could play in both case with pro/cons but the factory is 6TiSCH, defin= itely an MLSN, because of: - mesh routing - incompatible mac=20 Cheers, Pascal= From nobody Mon Mar 17 01:03:51 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5C1A004C for ; Mon, 17 Mar 2014 01:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 C586v1RSScqo for ; Mon, 17 Mar 2014 01:03:41 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8401D1A03BB for ; Mon, 17 Mar 2014 01:03:41 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id lx4so5060570iec.38 for ; Mon, 17 Mar 2014 01:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yq/1PESD4TClWO4ZphDtmWrNgxKgH71SnU/oe29sfbc=; b=kXn2scz1eZidMy4cObJNcV4IPuAx6GRF23deI5LQ9tjWiUumW2XWXQj7ephKVzFh8D awb9krZ2df1gI8NjmUIpAcP2hRWBx7NYVtV/Pi9WTyLYRCrwKWluTuuh4BIPTQFrfZrU WXB2D4CfzUzggdTZk3ylVfWHhjq3IpB7onVBqBf96/jTWvKSwj0040vEJUYZdaV7VSk7 2qMm4fA3ekzjw7/Qj24PzTvvbcdF5kZaiScTe2Fi/56mxNDRbTp8oy5cIxigv/bs0yoa EYhuGWT2xo0/+QgLethfvFTZy3MbhjaxIkB+bBiy47J9XioUaql9w45PgKqjNvxxOacO +hAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yq/1PESD4TClWO4ZphDtmWrNgxKgH71SnU/oe29sfbc=; b=HhQEjTkwL8mdglBHyNUrO07GX8ZamEN4A/q/N6iVgcyAY77lv5FhJcSlU9zrF+HWWv ICvNGzaJudcnyrMR9rKTpoH9CbvRD8qpDShWfmR1hLySPOW56yFjqs5nAcfHSs2BnE8P EO6pX6OTl45op9kYyxPgJetHwusonAJ8JjM7hLT93mRzi2Whtb95LvN3BUlzg5DzEvuu XPpuVX89RzDgxNqmhjxbX9xWjoM+0DQvTDqaQACABfaLRhEPeTPhQN7qgHP7hCAbYRQu E0v5I9kQP9Fdq7QRuySqxHg+hvADSP7+hZ/hsgGFl10dehXRXCK/lwPLOyP8y0xszswA TG1A== X-Gm-Message-State: ALoCoQkCQOIOO+YNSG5pCuDs1At15b9F5ts+8EFxkjryCcas+lNRc9zEb+1wX01RcPp8ehEdTNXzoqCYwf3XGDF6+GPNHFmd8apI5QoIKkyKHSetDtnLz4WMTpsI8pX+Q2yYe3DkDUMjOUdM2oiAC+PSaQTBYqO1WSjOZ12ogC9fb0PYO16o5GQCF9ewu0E6E8QKGHFippp4T1gIvy9jzFQEcTu6JRJQRw== X-Received: by 10.50.225.134 with SMTP id rk6mr11455696igc.31.1395043413522; Mon, 17 Mar 2014 01:03:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.18.136 with HTTP; Mon, 17 Mar 2014 01:03:13 -0700 (PDT) In-Reply-To: References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> From: Lorenzo Colitti Date: Mon, 17 Mar 2014 17:03:13 +0900 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=f46d042ac0f41c356304f4c8dbb5 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/2WFgZ-MH3tPJMn4ZcCm0Epb0D1w Cc: Erik Nordmark , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 08:03:47 -0000 --f46d042ac0f41c356304f4c8dbb5 Content-Type: text/plain; charset=UTF-8 All, just to make things very clear from the start: I think we need a detailed problem statement (more likely, more than one, since there's more than one problem to solve) before we move into solution space. The efficient-nd draft does not have what I consider to be a useful problem statement for this purpose, because it starts with the assumption that it is a goal to remove as much ND multicast traffic as possible. I don't think we know yet whether this is a goal or not. Cheers, Lorenzo On Sat, Mar 15, 2014 at 8:29 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Erik; > > Your split of the problem space makes sense to me; we could make a table > to map it with solution space. > The solution space we discussed so far to divide the broadcast domain > would be (to my recollection): > > 1) no ND, a /64 per device. I think John will detail this approach and use > cases where that makes sense (including 3G). > 2) Mixed registered node vs. classical nodes (efficient ND). In that model > the usage of NS/NA multicast is reduced roughly by the ratio of registered > nodes. > 3) Multiple private (secondary) vlans with a primary (federating) vlan > where all the common services would reside. In that model devices in a > pvlan cannot reach devices in other pvlans and DAD proxy is used to avoid > address collisions globally. All multicasts including NS/NA from the > primary vlan are effectively flooded but not multicasts originated from the > pvlans which are limited to the pvlan and the primary. This is also > deployable today and we probably can document how it works and when it > makes sense to use it. > 4) backbone router model: If registered nodes are all on the "southern" > side of the backbone routers and classical ND runs over a federating > backbone on the "northern" side then NS / NA mcasts can be completely > avoided in the southern domain. With the backbone routers acting as > proxies, any to any reachability is available for global and ULA unicast > addresses. > > In model 1 the subnet can be much smaller than the link. In model 2 the > subnet is congruent with the link. In the last 2 models, the subnet is > larger than the links, IOW we are in multilink subnet space. > > Cheers, > > Pascal > > > -----Original Message----- > > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf > Of Erik > > Nordmark > > Sent: vendredi 14 mars 2014 11:05 > > To: efficientnd-dt@ietf.org > > Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" > > > > > > Let's keep some momentum going by touching base for half an hour or less > > every other week starting next week. > > > > Please pick a time in the poll. > > > > http://doodle.com/usa83cbr5z5mfuny > > > > In terms of working through the issues it would be good have some > structure. > > > > What do we need to do as a team to get more data from deployment > problems? > > What about analysis of existing implementations e.g., to understand the > > unsolicited NAs to all-nodes we saw in London? > > > > I suggest we work through the suggestions somewhat separate for the three > > areas: > > - RS/RA > > - NS/NA for address resolution > > - DAD > > > > I'll start writing up the ideas and issues following that structure, but > if someone > > wants to take one of them and drive it let me know. > > > > Erik > > > > _______________________________________________ > > Efficientnd-dt mailing list > > Efficientnd-dt@ietf.org > > https://www.ietf.org/mailman/listinfo/efficientnd-dt > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt > --f46d042ac0f41c356304f4c8dbb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

just to make things very clear fro= m the start: I think we need a detailed problem statement (more likely, mor= e than one, since there's more than one problem to solve) before we mov= e into solution space.

The efficient-nd draft does not have what I consider to= be a useful problem statement for this purpose, because it starts with the= assumption that it is a goal to remove as much ND multicast traffic as pos= sible. I don't think we know yet whether this is a goal or not.

Cheers,
Lorenzo


On Sat, Mar 15, 2014 at 8:29 AM= , Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hello Erik;

Your split of the problem space makes sense to me; we could make a table to= map it with solution space.
The solution space we discussed so far to divide the broadcast domain would= be (to my recollection):

1) no ND, a /64 per device. I think John will detail this approach and use = cases where that makes sense (including 3G).
2) Mixed registered node vs. classical nodes (efficient ND). In that model = the usage of NS/NA multicast is reduced roughly by the ratio of registered = nodes.
3) Multiple private (secondary) vlans with a primary (federating) vlan wher= e all the common services would reside. In that model devices in a pvlan ca= nnot reach devices in other pvlans and DAD proxy is used to avoid address c= ollisions globally. All multicasts including NS/NA from the primary vlan ar= e effectively flooded but not multicasts originated from the pvlans which a= re limited to the pvlan and the primary. This is also deployable today and = we probably can document how it works and when it makes sense to use it. 4) backbone router model: If registered nodes are all on the "southern= " side of the backbone routers and classical ND runs over a federating= backbone on the "northern" side then NS / NA mcasts can be compl= etely avoided in the southern domain. With the backbone routers acting as p= roxies, any to any reachability is available for global and ULA unicast add= resses.

In model 1 the subnet can be much smaller than the link. In model 2 the sub= net is congruent with the link. In the last 2 models, the subnet is larger = than the links, IOW we are in multilink subnet space.

Cheers,

Pascal

> -----Original Message-----
> From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of Erik
> Nordmark
> Sent: vendredi 14 mars 2014 11:05
> To: efficientnd-dt@ietf.org=
> Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly&= quot;
>
>
> Let's keep some momentum going by touching base for half an hour o= r less
> every other week starting next week.
>
> Please pick a time in the poll.
>
> http:= //doodle.com/usa83cbr5z5mfuny
>
> In terms of working through the issues it would be good have some stru= cture.
>
> What do we need to do as a team to get more data from deployment probl= ems?
> What about analysis of existing implementations e.g., to understand th= e
> unsolicited NAs to all-nodes we saw in London?
>
> I suggest we work through the suggestions somewhat separate for the th= ree
> areas:
> =C2=A0 - RS/RA
> =C2=A0 - NS/NA for address resolution
> =C2=A0 - DAD
>
> I'll start writing up the ideas and issues following that structur= e, but if someone
> wants to take one of them and drive it let me know.
>
> =C2=A0 =C2=A0 Erik
>
> _______________________________________________
> Efficientnd-dt mailing list
> Efficientnd-dt@ietf.org=
> https://www.ietf.org/mailman/listinfo/efficientnd-dt

_______________________________________________
Efficientnd-dt mailing list
Efficientnd-dt@ietf.org
https://www.ietf.org/mailman/listinfo/efficientnd-dt

--f46d042ac0f41c356304f4c8dbb5-- From nobody Mon Mar 17 11:02:14 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C351A044C for ; Mon, 17 Mar 2014 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 ELi6e3_6k0bN for ; Mon, 17 Mar 2014 11:02:08 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4051A02F2 for ; Mon, 17 Mar 2014 11:02:08 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2HI1uWR031522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Mar 2014 11:01:57 -0700 Message-ID: <53273894.7040203@sonic.net> Date: Mon, 17 Mar 2014 11:01:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Lorenzo Colitti , "Pascal Thubert (pthubert)" References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;QAKwOv6t4xGt8rRWCY+HFQ== M;oEC8Ov6t4xGt8rRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/mrp9ybRkqFShB20gP7A881PZCBU Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:02:11 -0000 On 3/17/14 1:03 AM, Lorenzo Colitti wrote: > All, > > just to make things very clear from the start: I think we need a > detailed problem statement (more likely, more than one, since there's > more than one problem to solve) before we move into solution space. > > The efficient-nd draft does not have what I consider to be a useful > problem statement for this purpose, because it starts with the > assumption that it is a goal to remove as much ND multicast traffic as > possible. I don't think we know yet whether this is a goal or not. Lorenzo, What type of problem statement you have in mind? Please send text ;-) At least an example indicating the direction would be very helpful. I think David offered some wording at the 6man microphone but I don't remember the exact words. Perhaps it was something along the lines of ND not getting in the way of scaling a subnet to have lots more hosts?? Erik > > Cheers, > Lorenzo > > > On Sat, Mar 15, 2014 at 8:29 AM, Pascal Thubert (pthubert) > > wrote: > > Hello Erik; > > Your split of the problem space makes sense to me; we could make a > table to map it with solution space. > The solution space we discussed so far to divide the broadcast > domain would be (to my recollection): > > 1) no ND, a /64 per device. I think John will detail this approach > and use cases where that makes sense (including 3G). > 2) Mixed registered node vs. classical nodes (efficient ND). In > that model the usage of NS/NA multicast is reduced roughly by the > ratio of registered nodes. > 3) Multiple private (secondary) vlans with a primary (federating) > vlan where all the common services would reside. In that model > devices in a pvlan cannot reach devices in other pvlans and DAD > proxy is used to avoid address collisions globally. All multicasts > including NS/NA from the primary vlan are effectively flooded but > not multicasts originated from the pvlans which are limited to the > pvlan and the primary. This is also deployable today and we > probably can document how it works and when it makes sense to use it. > 4) backbone router model: If registered nodes are all on the > "southern" side of the backbone routers and classical ND runs over > a federating backbone on the "northern" side then NS / NA mcasts > can be completely avoided in the southern domain. With the > backbone routers acting as proxies, any to any reachability is > available for global and ULA unicast addresses. > > In model 1 the subnet can be much smaller than the link. In model > 2 the subnet is congruent with the link. In the last 2 models, the > subnet is larger than the links, IOW we are in multilink subnet space. > > Cheers, > > Pascal > > > -----Original Message----- > > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org > ] On Behalf Of Erik > > Nordmark > > Sent: vendredi 14 mars 2014 11:05 > > To: efficientnd-dt@ietf.org > > Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" > > > > > > Let's keep some momentum going by touching base for half an hour > or less > > every other week starting next week. > > > > Please pick a time in the poll. > > > > http://doodle.com/usa83cbr5z5mfuny > > > > In terms of working through the issues it would be good have > some structure. > > > > What do we need to do as a team to get more data from deployment > problems? > > What about analysis of existing implementations e.g., to > understand the > > unsolicited NAs to all-nodes we saw in London? > > > > I suggest we work through the suggestions somewhat separate for > the three > > areas: > > - RS/RA > > - NS/NA for address resolution > > - DAD > > > > I'll start writing up the ideas and issues following that > structure, but if someone > > wants to take one of them and drive it let me know. > > > > Erik > > > > _______________________________________________ > > Efficientnd-dt mailing list > > Efficientnd-dt@ietf.org > > https://www.ietf.org/mailman/listinfo/efficientnd-dt > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt > > From nobody Mon Mar 17 11:03:42 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850711A044C for ; Mon, 17 Mar 2014 11:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 RVM41VEqwVo3 for ; Mon, 17 Mar 2014 11:03:34 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9778F1A042F for ; Mon, 17 Mar 2014 11:03:34 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2HI3NxV000385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Mar 2014 11:03:23 -0700 Message-ID: <532738EA.9010904@sonic.net> Date: Mon, 17 Mar 2014 11:03:22 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Erik Kline , "Pascal Thubert (pthubert)" References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;QmEHbv6t4xGgyLRWCY+HFQ== M;YI8Qbv6t4xGgyLRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/a9P4WXK8l15hstIOxiqWmVVAe9w Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:03:40 -0000 On 3/16/14 10:46 PM, Erik Kline wrote: > Pascal, > >> 2) Mixed registered node vs. classical nodes (efficient ND). In that model the usage of NS/NA multicast is reduced roughly by the ratio of registered nodes. > ... >> In model 1 the subnet can be much smaller than the link. In model 2 the subnet is congruent with the link. In the last 2 models, the subnet is larger than the links, IOW we are in multilink subnet space. > It's not clear to me that this #2 mixed mode is not also the > multi-link model. In the "factory with lots of sensors and some > normal hosts" example, that to me was a multi-link example, was it > not? Erik, I think they are quite separate or at least separable. efficient-nd is an existence proof of a single subnet on a single link providing for mixed mode. A general case of a multi-link subnet requires additional pieces. For instance, to handle those in 6lowpan there was a need to provide for multi-hop mechanisms in RFC 6775. I'd like to keep the scope of the DT limited to the case of single-link subnets. While we shouldn't make in any more difficult than in 4861 to have proxies and backbone routers, but I don't think we've been asked to make that any easier. Erik > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt > From nobody Mon Mar 17 11:10:11 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654671A046A for ; Mon, 17 Mar 2014 11:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 nupzS8FUyakM for ; Mon, 17 Mar 2014 11:10:04 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6D81A045D for ; Mon, 17 Mar 2014 11:10:04 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2HI9rA1014685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Mar 2014 11:09:53 -0700 Message-ID: <53273A71.9080502@sonic.net> Date: Mon, 17 Mar 2014 11:09:53 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "efficientnd-dt@ietf.org" References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;2PLIVv+t4xGLpdKVOBdzQA== M;bD3WVv+t4xGLpdKVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/4sh9NqMXEX4C9b4un8PbFAoEYUk Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:10:08 -0000 On 3/14/14 4:29 PM, Pascal Thubert (pthubert) wrote: > Hello Erik; > > Your split of the problem space makes sense to me; we could make a table to map it with solution space. > The solution space we discussed so far to divide the broadcast domain would be (to my recollection): > > 1) no ND, a /64 per device. I think John will detail this approach and use cases where that makes sense (including 3G). Yes. > 2) Mixed registered node vs. classical nodes (efficient ND). In that model the usage of NS/NA multicast is reduced roughly by the ratio of registered nodes. #2 assumes that we'd have some explicit registrations. I wouldn't take that for granted up front. > 3) Multiple private (secondary) vlans with a primary (federating) vlan where all the common services would reside. In that model devices in a pvlan cannot reach devices in other pvlans and DAD proxy is used to avoid address collisions globally. All multicasts including NS/NA from the primary vlan are effectively flooded but not multicasts originated from the pvlans which are limited to the pvlan and the primary. This is also deployable today and we probably can document how it works and when it makes sense to use it. We haven't talked about that option. It would be good to understand whether it is different than the other techniques that have been discussed. From a quick look it appears the same as the split-horizon approach with proxy-dad; the router(s) can multicast RA, multicast RS will only make it to the router(s), etc. > 4) backbone router model: If registered nodes are all on the "southern" side of the backbone routers and classical ND runs over a federating backbone on the "northern" side then NS / NA mcasts can be completely avoided in the southern domain. With the backbone routers acting as proxies, any to any reachability is available for global and ULA unicast addresses. That seems to be part of a solution to a multi-link subnet, which I don't think we need to work on in the DT. > > In model 1 the subnet can be much smaller than the link. In model 2 the subnet is congruent with the link. In the last 2 models, the subnet is larger than the links, IOW we are in multilink subnet space. My take is that in #1 they are congruent - the subnets are picked to match the links with one /64 per link. Erik > > Cheers, > > Pascal > >> -----Original Message----- >> From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf Of Erik >> Nordmark >> Sent: vendredi 14 mars 2014 11:05 >> To: efficientnd-dt@ietf.org >> Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" >> >> >> Let's keep some momentum going by touching base for half an hour or less >> every other week starting next week. >> >> Please pick a time in the poll. >> >> http://doodle.com/usa83cbr5z5mfuny >> >> In terms of working through the issues it would be good have some structure. >> >> What do we need to do as a team to get more data from deployment problems? >> What about analysis of existing implementations e.g., to understand the >> unsolicited NAs to all-nodes we saw in London? >> >> I suggest we work through the suggestions somewhat separate for the three >> areas: >> - RS/RA >> - NS/NA for address resolution >> - DAD >> >> I'll start writing up the ideas and issues following that structure, but if someone >> wants to take one of them and drive it let me know. >> >> Erik >> >> _______________________________________________ >> Efficientnd-dt mailing list >> Efficientnd-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Mon Mar 17 11:37:59 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3021A043A for ; Mon, 17 Mar 2014 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 Wg0Y1L_pJsND for ; Mon, 17 Mar 2014 11:37:52 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 094591A0489 for ; Mon, 17 Mar 2014 11:37:51 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2HIbg7T002403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Mar 2014 11:37:42 -0700 Message-ID: <532740F5.1040705@sonic.net> Date: Mon, 17 Mar 2014 11:37:41 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "efficientnd-dt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;Mh1eOQOu4xG/gbRWCY+HFQ== M;zEppOQOu4xG/gbRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Qr__PosdOQOwu8fgaKKJ_6T3Icg Subject: [Efficientnd-dt] NS/NA address resolution - some thoughts X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:37:54 -0000 Seems like there are several potential origins of multicast NA and/or NS. The ones that come to mind are: 1. Initial address resolution 1a. host->router 1b. router->host 1c. host->host 1a shouldn't happen if the RA contains the SLLAO 1b shouldn't happen if the RS contains the SLLAO 1c. why do hosts on the IETF link talk to each other? Could this host-to-host be triggered by Bonjour finding e.g. a file server causing it to unicast to find out more about the server? We can remove 1c using L=0, but that in itself wasn't a big chunk in Eric's piechart. 2. Unsolicited NA to all-nodes Why do we see those on the link? Do implementations send each time the link/interface comes up? 3. Discarding NCEs (on hosts or routers) causing redoing multicast address resolution Is this due to NUD timing things out after 3 seconds of unreachable? Due to LRU/garbage collection? We can potentially address #3 using higher ReachableTime (if there is only one router in the default router list) or by hosts and/or routers implementing impatient-nud (RFC 7048); either will reduce the probability of discarding a entry just because the target was unreachable for a few seconds. 4. Router loosing state (e.g., reboot or VRRP failover) causes a flood of 1b NSs Seems like we need more analysis of the traffic and implementations to determine the causes so we can think about useful remedies. Erik From nobody Mon Mar 17 11:58:32 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DA41A0303 for ; Mon, 17 Mar 2014 11:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 bjhGGAD_R_Ky for ; Mon, 17 Mar 2014 11:58:25 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 26B2E1A01D5 for ; Mon, 17 Mar 2014 11:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2736; q=dns/txt; s=iport; t=1395082697; x=1396292297; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Elxvh8UK9vhSCXuxbxcCuZ9vxCAlEnsZL6j6Gudjybo=; b=h36BKRs8HdREiWVTKb13BVcXVlgXGmWJAkPWN4conPLtnr4zsz8eUX2O A2zMcnol6FLPfyNZX89O2iF9DedMBGGn96G3yf9m8mSqnbtjvLI4B4+Sn i/T+ADqd1NickZZt3MsAh0IZZXX64Y7FE7Dyu+jEE0gWR0oTxNTb2VFxE Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAE9FJ1OtJV2Z/2dsb2JhbABZgwY7V7pThmFPgSAWdIIlAQEBAwEBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIh2kIDdMaF44QBCM4BoMegRQEmXiQfYMtgWlC X-IronPort-AV: E=Sophos;i="4.97,671,1389744000"; d="scan'208";a="28121874" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP; 17 Mar 2014 18:58:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2HIwGxe023444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 18:58:16 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.10]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 13:58:16 -0500 From: "Pascal Thubert (pthubert)" To: Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" Thread-Index: AQHPP6/mGLzLqUw8dkK2on8zPZHGSZrhNGzQgAS4NoD//7SCcA== Date: Mon, 17 Mar 2014 18:58:16 +0000 Deferred-Delivery: Mon, 17 Mar 2014 18:43:00 +0000 Message-ID: References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> <53273A71.9080502@sonic.net> In-Reply-To: <53273A71.9080502@sonic.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/ft8uZ2apaTIAhdnDw66U26TjQcw Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:58:27 -0000 Hello Erik > > 3) Multiple private (secondary) vlans with a primary (federating) vlan = where all > the common services would reside. In that model devices in a pvlan cannot > reach devices in other pvlans and DAD proxy is used to avoid address coll= isions > globally. All multicasts including NS/NA from the primary vlan are effect= ively > flooded but not multicasts originated from the pvlans which are limited t= o the > pvlan and the primary. This is also deployable today and we probably can > document how it works and when it makes sense to use it. >=20 > We haven't talked about that option. It would be good to understand > whether it is different than the other techniques that have been > discussed. From a quick look it appears the same as the split-horizon > approach with proxy-dad; the router(s) can multicast RA, multicast RS > will only make it to the router(s), etc. >=20 [PT] It is the same, for all I know, and it is what I tried to describe fro= m inside the box. The private vlan is the way our switches impose the split horizon. Unsure if it is a generalized terminology. And yes, we do DAD proxy to isol= ate the customers. Pascal > > > >> -----Original Message----- > >> From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behal= f Of > Erik > >> Nordmark > >> Sent: vendredi 14 mars 2014 11:05 > >> To: efficientnd-dt@ietf.org > >> Subject: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" > >> > >> > >> Let's keep some momentum going by touching base for half an hour or le= ss > >> every other week starting next week. > >> > >> Please pick a time in the poll. > >> > >> http://doodle.com/usa83cbr5z5mfuny > >> > >> In terms of working through the issues it would be good have some stru= cture. > >> > >> What do we need to do as a team to get more data from deployment > problems? > >> What about analysis of existing implementations e.g., to understand th= e > >> unsolicited NAs to all-nodes we saw in London? > >> > >> I suggest we work through the suggestions somewhat separate for the th= ree > >> areas: > >> - RS/RA > >> - NS/NA for address resolution > >> - DAD > >> > >> I'll start writing up the ideas and issues following that structure, b= ut if > someone > >> wants to take one of them and drive it let me know. > >> > >> Erik > >> > >> _______________________________________________ > >> Efficientnd-dt mailing list > >> Efficientnd-dt@ietf.org > >> https://www.ietf.org/mailman/listinfo/efficientnd-dt >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Mon Mar 17 11:58:34 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F891A0449 for ; Mon, 17 Mar 2014 11:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 J66AxtaqZUYE for ; Mon, 17 Mar 2014 11:58:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7651A02FB for ; Mon, 17 Mar 2014 11:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1069; q=dns/txt; s=iport; t=1395082698; x=1396292298; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yV0TIMovYgWavo9+mKGWtdaOsd9+9TGVwZpwuIpvbS0=; b=KnXG6YoQFvqKyoZg2KC5UX/T61lz1ZQF32ogzLPcsmdHUB7OKDBUiYlt ULTUwiLkIz5ulBVFvKoQzXhVb/uSPjLS0p0gHNgbVEHyV2f4oR57TpAY2 IKPZ4M//M3IQzCuqkrTrGEilzSWdxj/JwnNquVWCtujSb3PNS2UnPTEoF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAN1EJ1OtJV2d/2dsb2JhbABZgwaBEsIDgSAWdIIlAQEBAwE6TwIBCCIUEDIlAgQBGodpCNMmF443OIMkgRQBA6p1gy2CKw X-IronPort-AV: E=Sophos;i="4.97,671,1389744000"; d="scan'208";a="310848723" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 17 Mar 2014 18:58:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2HIwHRF007051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Mar 2014 18:58:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.10]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 13:58:17 -0500 From: "Pascal Thubert (pthubert)" To: Erik Nordmark , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" Thread-Index: AQHPP6/mGLzLqUw8dkK2on8zPZHGSZrhNGzQgAS4NoD//7VL8A== Date: Mon, 17 Mar 2014 18:58:17 +0000 Deferred-Delivery: Mon, 17 Mar 2014 18:54:00 +0000 Message-ID: References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> <53273A71.9080502@sonic.net> In-Reply-To: <53273A71.9080502@sonic.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.109.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/daKrLRRBnIFUJXOtqTxK_4gJ_fk Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:58:28 -0000 > > In model 1 the subnet can be much smaller than the link. In model 2 the= subnet > is congruent with the link. In the last 2 models, the subnet is larger th= an the links, > IOW we are in multilink subnet space. > My take is that in #1 they are congruent - the subnets are picked to > match the links with one /64 per link. [PT] Depends on the use case and what we call the link, I suspect. Say you = have a large shared Ethernet / WiFi fabric, and even multiple ones. The fab= ric is a single broadcast domain and a transit link.=20 It is possible to use the /64 to enable mobility designs across L2 and L3. = In that case, broadcast RAs do not carry prefixes, but unicast RAs are tail= ored to the various devices pretty much like PMIP does. Unsure if John's model needs to include mobility, but as a side effect it c= an certainly be achieved. In any fashion, if a link is the SSID and the con= nected vlan, the prefix is smaller than the link and may even move from lin= k to link. V6 has certainly multiple interesting facets : ) Pascal From nobody Mon Mar 17 14:50:09 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB51A05D3 for ; Mon, 17 Mar 2014 14:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 G3AgaX9amHYE for ; Mon, 17 Mar 2014 14:50:05 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id E52E61A0584 for ; Mon, 17 Mar 2014 14:50:04 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2HLnsrW019658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Mar 2014 14:49:54 -0700 Message-ID: <53276E02.4080303@sonic.net> Date: Mon, 17 Mar 2014 14:49:54 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , "efficientnd-dt@ietf.org" References: <1944465138.1124923.1394819057227.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <532344BC.3030408@sonic.net> <53273A71.9080502@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;bIA/Ex6u4xGpt9KVOBdzQA== M;yrZLEx6u4xGpt9KVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Nuir3kj6-3lJ4GkSqjLYw5unSHQ Subject: Re: [Efficientnd-dt] Doodle: "IPv6 ND design team bi-weekly" X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 21:50:08 -0000 On 3/17/14 11:58 AM, Pascal Thubert (pthubert) wrote: >>> In model 1 the subnet can be much smaller than the link. In model 2 the subnet >> is congruent with the link. In the last 2 models, the subnet is larger than the links, >> IOW we are in multilink subnet space. >> My take is that in #1 they are congruent - the subnets are picked to >> match the links with one /64 per link. > [PT] Depends on the use case and what we call the link, I suspect. Say you have a large shared Ethernet / WiFi fabric, and even multiple ones. The fabric is a single broadcast domain and a transit link. > It is possible to use the /64 to enable mobility designs across L2 and L3. In that case, broadcast RAs do not carry prefixes, but unicast RAs are tailored to the various devices pretty much like PMIP does. FWIW the 16ng working group explored that model and decided on the simpler approach. See RFC 5121 and RFC 4968 IEEE 802.16 is capable of treating the physical network as a single link, but that is inefficient due to broadcast and multicast, thus 5121 treats it as independent links each with a /64. Regards, Erik > Unsure if John's model needs to include mobility, but as a side effect it can certainly be achieved. In any fashion, if a link is the SSID and the connected vlan, the prefix is smaller than the link and may even move from link to link. > V6 has certainly multiple interesting facets : ) > > Pascal > > From nobody Mon Mar 17 17:56:01 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78CE1A02FC for ; Mon, 17 Mar 2014 17:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 Ai9_mADZXquN for ; Mon, 17 Mar 2014 17:55:56 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 79D851A0307 for ; Mon, 17 Mar 2014 17:55:56 -0700 (PDT) Received: from [172.22.209.219] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2I0tlNm016670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 17 Mar 2014 17:55:47 -0700 Message-ID: <53279992.3050505@sonic.net> Date: Mon, 17 Mar 2014 17:55:46 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "efficientnd-dt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;4v7eCjiu4xGdeNKVOBdzQA== M;kuzrCjiu4xGdeNKVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/xsQuX5wnFhpDdMX_Q9y1kebgtnI Subject: [Efficientnd-dt] RS/RA list of items X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 00:55:58 -0000 Do we have issues with multicast RS? The data from the IETF didn't show it but that might be due to filters in the APs for all-routers?? The DNA RFC currently states that the unicast NS and multicast RS be sent in parallel. It might make sense to suggest that hosts implement DNA in a way where the multicast RS is deferred so that should it get an immediate solicited NA it does not multicast the RS. Higher timers for periodic RA - tuning - increasing allowed max in RFC 4861 Encourage router implementations to unicast solicited RAs - but listening to Ran's concern about satellite networks, perhaps there needs to be a config option so that on links where multicast is efficient they can continue to do multicast? Allow for hosts that optionally want to use RS to refresh the RA information. - would need a way to limit their traffic - again, Ran's satellite network case might mean that the network should be in control of this behavior. - One could envision a new field/option in the RA with the "RS refresh interval". When a new router appears on the link, per 4861 it will multicast 3 initial RAs. What about the case when a router wants to quickly disseminate a change (like adding a prefix and deprecating another prefix). In that case it would make sense to also allow a multicast of 3 initial RAs i.e., relax the current spec. Erik From nobody Mon Mar 17 18:54:47 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED3A1A034F for ; Mon, 17 Mar 2014 18:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 TIuyGozaRr6t for ; Mon, 17 Mar 2014 18:54:43 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DE63B1A0349 for ; Mon, 17 Mar 2014 18:54:42 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so6385534pdi.33 for ; Mon, 17 Mar 2014 18:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QvngaFsXGHIz8pU+3Ahu+qzk7aZPobbtB/XO/oq2mD4=; b=ILt0Aaq3OgWO0czpA2yAqoESGFM7Ozu8FBSJtDrOQ2cZCTSqIV4fQCoSA0OlTWIOLL NFVdXGsz+Fah87Tm5DVQ0SjFn+LK35W7rwIsIeEi9oVrUBR4kI+F/kP4TmyexFJKLr1O VE/rR3S1uyu3AAc31m7PG3fWrvKTfafayLNKgPP8GQg+cGtqgY2EtT1BocpiITzqA/DO pWsNqBYDo1DYt/Fsu47XqIoxXL1wo+9s9FXBmCM6XP0otDnywDgkVEDNjbMG7BexkwEf 1sJI5h7UVRgfvtUEXax2Lm6OmH9/3/n1+/0ajQlQF6I1+6+fZjZxu7ezEhase61WCeH5 ZYFg== X-Received: by 10.66.217.133 with SMTP id oy5mr30222229pac.46.1395107674852; Mon, 17 Mar 2014 18:54:34 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id x9sm47374513pbu.1.2014.03.17.18.54.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Mar 2014 18:54:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <53279992.3050505@sonic.net> Date: Tue, 18 Mar 2014 09:54:13 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53279992.3050505@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/wXBtg3iYjVPHYHyT-4eickH55Wg Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RS/RA list of items X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 01:54:45 -0000 Erik, On Mar 18, 2014, at 8:55 AM, Erik Nordmark wrote: >=20 > Do we have issues with multicast RS? The data from the IETF didn't = show it but that might be due to filters in the APs for all-routers?? > The DNA RFC currently states that the unicast NS and multicast RS be = sent in parallel. It might make sense to suggest that hosts implement = DNA in a way where the multicast RS is deferred so that should it get an = immediate solicited NA it does not multicast the RS. >=20 > Higher timers for periodic RA > - tuning > - increasing allowed max in RFC 4861 See below.. I think there is room for profiling here. >=20 > Encourage router implementations to unicast solicited RAs > - but listening to Ran's concern about satellite networks, perhaps = there needs to be a config option so that on links where multicast is = efficient they can continue to do multicast? >=20 > Allow for hosts that optionally want to use RS to refresh the RA = information. > - would need a way to limit their traffic > - again, Ran's satellite network case might mean that the network = should be in control of this behavior. > - One could envision a new field/option in the RA with the "RS refresh = interval". Couldn't we use RA's router lifetime for this purpose? Just add some clarifications to the rules for sending RSes before the router lifetime expires (controllable with a config knob or a RA header flag bit) and=20 how to set (min|max)rtradvinterval. I'd be conservative adding a new option for this purpose. - Jouni >=20 > When a new router appears on the link, per 4861 it will multicast 3 = initial RAs. >=20 > What about the case when a router wants to quickly disseminate a = change (like adding a prefix and deprecating another prefix). > In that case it would make sense to also allow a multicast of 3 = initial RAs i.e., relax the current spec. >=20 > Erik >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Tue Mar 18 09:34:58 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CD51A042E for ; Tue, 18 Mar 2014 09:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 xP-3TM-kSgcm for ; Tue, 18 Mar 2014 09:34:55 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 022A71A0418 for ; Tue, 18 Mar 2014 09:34:54 -0700 (PDT) Received: from [172.22.209.194] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2IGYhFW005533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Mar 2014 09:34:43 -0700 Message-ID: <532875A5.5060505@sonic.net> Date: Tue, 18 Mar 2014 09:34:45 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jouni Korhonen References: <53279992.3050505@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;5llyNbuu4xGAYbRWCY+HFQ== M;Skt8Nbuu4xGAYbRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/cqYKkuDQex-cFQNWCZvnhcB8SiM Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RS/RA list of items X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:34:56 -0000 On 3/17/14 6:54 PM, Jouni Korhonen wrote: > Erik, > > > > Higher timers for periodic RA > - tuning > - increasing allowed max in RFC 4861 > See below.. I think there is room for profiling here. Jouni, Didn't understand what profiling you had below that relates to the advertisement interval. > >> Encourage router implementations to unicast solicited RAs >> - but listening to Ran's concern about satellite networks, perhaps there needs to be a config option so that on links where multicast is efficient they can continue to do multicast? >> >> Allow for hosts that optionally want to use RS to refresh the RA information. >> - would need a way to limit their traffic >> - again, Ran's satellite network case might mean that the network should be in control of this behavior. >> - One could envision a new field/option in the RA with the "RS refresh interval". > Couldn't we use RA's router lifetime for this purpose? Just add some > clarifications to the rules for sending RSes before the router lifetime > expires (controllable with a config knob or a RA header flag bit) and > how to set (min|max)rtradvinterval. A RA flag ("please refresh using unicast RS") is sufficient to leave the network manager in control (Ran's concern to not make it worse on links where multicast is the most efficient way). The router lifetime can be used but we need to hard-code a ratio. What I mean is that the default settings is that the router lifetime is 3x the RA advertisement interval. Thus if that ratio holds, then a RS refresh would make sense at e.g. one forth of the router lifetime. However, if the network admin configures the ratio between router lifetime and RA interval as 10x, then the unicast RS would never trigger. If the unsolicited RAs are a less frequent (say every 2 hours as opposed to the default every 10 minutes) then it wouldn't be unreasonable to use a higher ratio. E.g., adv interval 2 hours and router lifetime 18 hours. As long as we are comfortable picking a fixed ratio R and have the host unicast a RS when "router lifetime/R" has expired, then we don't need an explicit way for the router to include the RS refresh time in the RA. So it depends how much control we want to leave to the network admin as opposed to hard-coding in the spec. Erik > > I'd be conservative adding a new option for this purpose. > > - Jouni > > >> When a new router appears on the link, per 4861 it will multicast 3 initial RAs. >> >> What about the case when a router wants to quickly disseminate a change (like adding a prefix and deprecating another prefix). >> In that case it would make sense to also allow a multicast of 3 initial RAs i.e., relax the current spec. >> >> Erik >> >> _______________________________________________ >> Efficientnd-dt mailing list >> Efficientnd-dt@ietf.org >> https://www.ietf.org/mailman/listinfo/efficientnd-dt > From nobody Tue Mar 18 09:52:01 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8011A0418 for ; Tue, 18 Mar 2014 09:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 IXAHPfbhjFXg for ; Tue, 18 Mar 2014 09:51:57 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id AC47C1A01BE for ; Tue, 18 Mar 2014 09:51:57 -0700 (PDT) Received: from [172.22.209.194] ([162.210.130.3]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2IGpkUm020744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 18 Mar 2014 09:51:46 -0700 Message-ID: <532879A4.6090507@sonic.net> Date: Tue, 18 Mar 2014 09:51:48 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "efficientnd-dt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;tExIl72u4xGFW9KVOBdzQA== M;UlBWl72u4xGFW9KVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/SSWDWrgkO3tNLyJpuzzAqdW-gFU Subject: [Efficientnd-dt] ND call on Thu 20th 7am PDT X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:51:59 -0000 Let's have a quick call to talk about - my idea to split the analysis and remedies into 3 parts (RS/RA, NS/NA except DAD, DAD) - who is and will be working on what parts Only volunteer I have down is John for the /64 writeup Folks talked in London about students that would work on analysis etc. Would be good to understand what info we'd expect to see. I'll set up a call or google hangout for this time. Erik From nobody Tue Mar 18 18:50:11 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93A01A04A3 for ; Tue, 18 Mar 2014 18:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 IwMoPog_KsEr for ; Tue, 18 Mar 2014 18:50:06 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5AD1A0338 for ; Tue, 18 Mar 2014 18:50:06 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so8191057pab.38 for ; Tue, 18 Mar 2014 18:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+25HaPdwi9duGBrxyvrKZFQhTNQHpKEyuGQRNfKiw+k=; b=mUJYEIvNb/JyCLdAFQCleSf5K8vLatILZic2o/Vq7/rHIDL7lBTqcV7MIaZ5D7fBw9 8GCWUcDzwj0oYctXUdDlayNDRZeeBuXJ9Xy6LTW1LO8QUSk3Y5TAyEpK0oDS+wwwZCup tOzCq6RvYMwREUpoNgqcJX+0rtteQE7lMzCGaTmAdTTQrZVl5xSb8/5l3mAc3Z50JEqf H1QjzLtEcziJruIz5hitjaLUrL2j/FGYosddzqCdqmT/ozsSWko1beZOiVBv07FRysJY X1u94ewpoHm7kd8IEU8CTiAUBOskH1/ul8kgnkcWvGjGX3fxu9D8OeQVWlu6qQVt/kMR COGQ== X-Received: by 10.68.143.231 with SMTP id sh7mr36879242pbb.7.1395193796965; Tue, 18 Mar 2014 18:49:56 -0700 (PDT) Received: from [172.31.2.72] ([211.155.168.89]) by mx.google.com with ESMTPSA id e6sm56916531pbg.4.2014.03.18.18.49.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 18:49:53 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <532875A5.5060505@sonic.net> Date: Wed, 19 Mar 2014 09:47:16 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53279992.3050505@sonic.net> <532875A5.5060505@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/YgvSmHQxv04vt-5RFnh7oSZkqag Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RS/RA list of items X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 01:50:10 -0000 Erik, On Mar 19, 2014, at 12:34 AM, Erik Nordmark wrote: > On 3/17/14 6:54 PM, Jouni Korhonen wrote: >> Erik, >>=20 >>=20 >>=20 >> Higher timers for periodic RA >> - tuning >> - increasing allowed max in RFC 4861 >> See below.. I think there is room for profiling here. >=20 > Jouni, > Didn't understand what profiling you had below that relates to the = advertisement interval. What I had in mind was possibly giving guidance for = (min|max)rtradvinterval use so that unsolicited RAs are sent closer to expiration of the router life time. For example saying minrtradvinterval =3D 0.8 * = maxrtradvinterval and AdvDefaultLifetime =3D 2 * maxrtradvinterval etc.. in certain types = of environments. As an example.. >>> Encourage router implementations to unicast solicited RAs >>> - but listening to Ran's concern about satellite networks, perhaps = there needs to be a config option so that on links where multicast is = efficient they can continue to do multicast? >>>=20 >>> Allow for hosts that optionally want to use RS to refresh the RA = information. >>> - would need a way to limit their traffic >>> - again, Ran's satellite network case might mean that the network = should be in control of this behavior. >>> - One could envision a new field/option in the RA with the "RS = refresh interval". >> Couldn't we use RA's router lifetime for this purpose? Just add some >> clarifications to the rules for sending RSes before the router = lifetime >> expires (controllable with a config knob or a RA header flag bit) and >> how to set (min|max)rtradvinterval. > A RA flag ("please refresh using unicast RS") is sufficient to leave = the network manager in control (Ran's concern to not make it worse on = links where multicast is the most efficient way). >=20 > The router lifetime can be used but we need to hard-code a ratio. > What I mean is that the default settings is that the router lifetime = is 3x the RA advertisement interval. Thus if that ratio holds, then a RS = refresh would make sense at e.g. one forth of the router lifetime. = However, if the network admin configures the ratio between router = lifetime and RA interval as 10x, then the unicast RS would never = trigger. > If the unsolicited RAs are a less frequent (say every 2 hours as = opposed to the default every 10 minutes) then it wouldn't be = unreasonable to use a higher ratio. E.g., adv interval 2 hours and = router lifetime 18 hours. Like in cellular where the lifetime is encouraged to be set to 18 hours. > As long as we are comfortable picking a fixed ratio R and have the = host unicast a RS when "router lifetime/R" has expired, then we don't = need an explicit way for the router to include the RS refresh time in = the RA. That would work as what I suggested above as "clarifications" for = sending RS. > So it depends how much control we want to leave to the network admin = as opposed to hard-coding in the spec. Right..=20 - Jouni >=20 > Erik >=20 >>=20 >> I'd be conservative adding a new option for this purpose. >>=20 >> - Jouni >>=20 >>=20 >>> When a new router appears on the link, per 4861 it will multicast 3 = initial RAs. >>>=20 >>> What about the case when a router wants to quickly disseminate a = change (like adding a prefix and deprecating another prefix). >>> In that case it would make sense to also allow a multicast of 3 = initial RAs i.e., relax the current spec. >>>=20 >>> Erik >>>=20 >>> _______________________________________________ >>> Efficientnd-dt mailing list >>> Efficientnd-dt@ietf.org >>> https://www.ietf.org/mailman/listinfo/efficientnd-dt >>=20 >=20 From nobody Wed Mar 19 10:30:18 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8D01A02F5 for ; Wed, 19 Mar 2014 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 X45AlC_4hGox for ; Wed, 19 Mar 2014 10:30:16 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8C61C1A06D8 for ; Wed, 19 Mar 2014 10:30:16 -0700 (PDT) Received: from [172.22.209.194] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2JHU4jQ007075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Mar 2014 10:30:05 -0700 Message-ID: <5329D41F.7090807@sonic.net> Date: Wed, 19 Mar 2014 10:30:07 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jouni Korhonen References: <53279992.3050505@sonic.net> <532875A5.5060505@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;iPHpG4yv4xGWn7RWCY+HFQ== M;uOD3G4yv4xGWn7RWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/wXnYm9Nm39Nwnzt0dq91yOUos8o Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RS/RA list of items X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 17:30:18 -0000 On 3/18/14 6:47 PM, Jouni Korhonen wrote: > Erik, > > > Jouni, > Didn't understand what profiling you had below that relates to the advertisement interval. > What I had in mind was possibly giving guidance for (min|max)rtradvinterval > use so that unsolicited RAs are sent closer to expiration of the router > life time. For example saying minrtradvinterval = 0.8 * maxrtradvinterval > and AdvDefaultLifetime = 2 * maxrtradvinterval etc.. in certain types of > environments. As an example.. If folks have operational recommendations, then we should write them down and get feedback. On lossy links (assuming to unicast RS refresh) the AdvDefaultLifetime to maxrtradvinterval ratio must be sufficiently large to get a small probability of loosing all of them before the lifetime expires. If it is known to the router that the hosts to unicast RS refresh that that isn't an issue any more. >> >> The router lifetime can be used but we need to hard-code a ratio. >> What I mean is that the default settings is that the router lifetime is 3x the RA advertisement interval. Thus if that ratio holds, then a RS refresh would make sense at e.g. one forth of the router lifetime. However, if the network admin configures the ratio between router lifetime and RA interval as 10x, then the unicast RS would never trigger. >> If the unsolicited RAs are a less frequent (say every 2 hours as opposed to the default every 10 minutes) then it wouldn't be unreasonable to use a higher ratio. E.g., adv interval 2 hours and router lifetime 18 hours. > Like in cellular where the lifetime is encouraged to be set to 18 hours. What is the maxrtradvinterval recommendation? And does the link ensure reasonable reliability for the multicast RAs? Erik From nobody Wed Mar 19 18:59:34 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FED1A04C1 for ; Wed, 19 Mar 2014 18:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 dIlP7CuKyDBq for ; Wed, 19 Mar 2014 18:59:30 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6DD1A04BC for ; Wed, 19 Mar 2014 18:59:30 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md12so198832pbc.21 for ; Wed, 19 Mar 2014 18:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=89Hc7hrDKVtzCarkAf4+MmcCdT4/hGjK7Z9ayAFR8D0=; b=xBC5OFfjndBavPbUKiAshsyNh9ujXhmVVV6xPvNx/7M/f30YJUAjwEx63ZAd1Y+FJL HTeauH6AvmZQg21xSRx1iuf1Wabk0MKCE7PtQCvMT+2FfvlwNnfja8BsHE7OhrNw/X+Y RHDZMW4se5EjPtDqLliAi7RxlSe2mJSHHD3VbUrSGTRz0xrk/sgKfh7v1NrLUH6bq0aI zDKPjgNG3h/syRLh9cqOSdKuYG7qmC2O9R3lq8fQSBWEiKd9OixAaZG3SQNggEDA3+2i lE4KijvVoZOgUbiM+8xSh2SdRXbDBBKEj40TuGgkZi64+QOicVivxar5V+VinlRQApm+ muPQ== X-Received: by 10.68.171.229 with SMTP id ax5mr44165294pbc.125.1395280761733; Wed, 19 Mar 2014 18:59:21 -0700 (PDT) Received: from dhcp-18-187.meeting.verilan.com ([123.124.234.161]) by mx.google.com with ESMTPSA id id10sm524962pbc.35.2014.03.19.18.59.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Mar 2014 18:59:20 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5329D41F.7090807@sonic.net> Date: Thu, 20 Mar 2014 09:59:12 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53279992.3050505@sonic.net> <532875A5.5060505@sonic.net> <5329D41F.7090807@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/g4aDhEkJutnUrclLDJYjDle-X7A Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RS/RA list of items X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 01:59:32 -0000 Erik, On Mar 20, 2014, at 1:30 AM, Erik Nordmark wrote: > On 3/18/14 6:47 PM, Jouni Korhonen wrote: >> Erik, >>=20 >>=20 >> Jouni, >> Didn't understand what profiling you had below that relates to the = advertisement interval. >> What I had in mind was possibly giving guidance for = (min|max)rtradvinterval >> use so that unsolicited RAs are sent closer to expiration of the = router >> life time. For example saying minrtradvinterval =3D 0.8 * = maxrtradvinterval >> and AdvDefaultLifetime =3D 2 * maxrtradvinterval etc.. in certain = types of >> environments. As an example.. > If folks have operational recommendations, then we should write them = down and get feedback. >=20 > On lossy links (assuming to unicast RS refresh) the AdvDefaultLifetime = to maxrtradvinterval ratio must be sufficiently large to get a small = probability of loosing all of them before the lifetime expires. If it is = known to the router that the hosts to unicast RS refresh that that isn't = an issue any more. >=20 >>>=20 >>> The router lifetime can be used but we need to hard-code a ratio. >>> What I mean is that the default settings is that the router lifetime = is 3x the RA advertisement interval. Thus if that ratio holds, then a RS = refresh would make sense at e.g. one forth of the router lifetime. = However, if the network admin configures the ratio between router = lifetime and RA interval as 10x, then the unicast RS would never = trigger. >>> If the unsolicited RAs are a less frequent (say every 2 hours as = opposed to the default every 10 minutes) then it wouldn't be = unreasonable to use a higher ratio. E.g., adv interval 2 hours and = router lifetime 18 hours. >> Like in cellular where the lifetime is encouraged to be set to 18 = hours. > What is the maxrtradvinterval recommendation? MaxRtrAdvInterval 6h MinRtrAdvInterval 0,75 =D7 MaxRtrAdvInterval i.e. 4,5h > And does the link ensure reasonable reliability for the multicast RAs? More or less.. the link is considered reliable. Also, the multicast = messages are in reality unicast since the link model is p2p for this = type of traffic. However, I have seen that RAs still get lost in reality = but that has been more of an issue for the initial RAs when the link = comes up. - JOuni >=20 > Erik >=20 From nobody Thu Mar 20 05:37:31 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1C81A06C3 for ; Thu, 20 Mar 2014 05:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 Vuy6mWqPn90v for ; Thu, 20 Mar 2014 05:37:28 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id D9E4F1A0545 for ; Thu, 20 Mar 2014 05:37:28 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 09A1D60B8 for ; Thu, 20 Mar 2014 05:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:message-id:date:to:mime-version; s= selector1; bh=69j2UKtPOOhYV7VKCe+CmTbJD2w=; b=o10Ba0I04O39aVdZOp Ngy/P1oGi9e3iUaAJaeeXsPEJQDe1OI9WFBfQvnmP1+hxUQQN5xkZeKmJ2hbubqy uFBLFu9wUrWX+F9zx3RLJQCSWOE1gBbY1yeindX/9R4CsLAGoYBkc6UaePQXmV7g oGZrGnbNxPqg5uA4c7kPT/MoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:message-id:date:to:mime-version; q=dns; s= selector1; b=Eoy4BqXKSU7xtEPyVMNNA3owGDdUqm2e134+I246qUT05qagw6j hbZqS0URvfNEygiUHIxTC5mWrdIX+eixoKm9pTRQpxizxcAGfWHTK6B0emsrxdyF 3IY7g9UxTscSntf//V+F4dhkEeKv9Y1psvpSkjYD37POMel1mDOeu3Pg= Received: from dhcp-10-61-110-164.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id BBC296073 for ; Thu, 20 Mar 2014 05:35:36 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_8BAA7F1A-0859-48E8-95F6-3256A37F688E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> Date: Thu, 20 Mar 2014 12:35:31 +0000 To: "efficientnd-dt@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/1OIP0wpB-zDoA4vZ09YhP3mlpyI Subject: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 12:37:30 -0000 --Apple-Mail=_8BAA7F1A-0859-48E8-95F6-3256A37F688E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I tried to list the number of problems with DAD as currently specified = in RFC4861/4862: Doesn=92t detect duplicate L2 addresses Unreliable - fails at detecting actual duplicates in several cases: - Blocked L2 ports - Unreliable multicast (collision detection requires two multicast = messages to pass through) (with default DAD attempts =3D 1 - False positives in case of looped interfaces (solved by enhanced-dad) Delays use of address until DAD is finished (rfc4429) Doesn=92t deal with partition and joining Doesn=92t specify what to do in case of collision Requires all nodes to be awake to defend their address Unclear on what a node should do after L2 events / waking up from sleep Vendor sauce: May be used as a signalling message from network to host = that it cannot use an address Vendor sauce: Used by the network to build state anything else? cheers, Ole --Apple-Mail=_8BAA7F1A-0859-48E8-95F6-3256A37F688E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTKuCUAAoJEFuJXizso86gJhoH/1mWSzYx7GRhmjPeA+QvaRpe QSJPkM4k/VqtHgLsCoXhGKTIN0O56LMybc422N/FXpngAJIP+zhuwEZ4S9DFxJwd uTuJIpaJYwHrg0bqwBFwyGpUIa1ByiH9kJbjKC/wSLlleTbjqB06xNzEBl+511n9 cumpDUZgt0P3EWs+dvgV/rskzN9WQpo9zcKWAbUuvLrQWZSf8DFbhHD/7tPd2ho2 g8KtEMx+taykogjMWmVHlSrC+/BUICZDf50iUoiVlUIMTy2gGVaw2fXtbv1yynIm RhivInCZhizQ5LTJP0rrbQ00S4ccxPzGsY8Gdl+pzlivgO+NtklrB2879EbTOME= =1nD2 -----END PGP SIGNATURE----- --Apple-Mail=_8BAA7F1A-0859-48E8-95F6-3256A37F688E-- From nobody Thu Mar 20 06:54:05 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813F1A06CF for ; Thu, 20 Mar 2014 06:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 ieNA8MzkxCgd for ; Thu, 20 Mar 2014 06:54:02 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 026AA1A03FA for ; Thu, 20 Mar 2014 06:54:01 -0700 (PDT) Received: from [10.0.1.68] (184-23-158-127.dsl.dynamic.sonic.net [184.23.158.127]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2KDrpRZ025271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Mar 2014 06:53:52 -0700 Message-ID: <532AF2EF.20902@sonic.net> Date: Thu, 20 Mar 2014 06:53:51 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "efficientnd-dt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;8gWiETew4xG5abRWCY+HFQ== M;nMezETew4xG5abRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/DUclBeL21mEz8kMFKyC5cNDpO1U Subject: [Efficientnd-dt] Let's use appear.in for the call X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:54:03 -0000 Go to https://appear.in/efficientnd-dt Needs an WebRTC browser such as Crome Erik From nobody Thu Mar 20 07:02:00 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930891A08C5 for ; Thu, 20 Mar 2014 07:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 AG8cP4ELsDjs for ; Thu, 20 Mar 2014 07:01:55 -0700 (PDT) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id BEB811A08C8 for ; Thu, 20 Mar 2014 07:01:54 -0700 (PDT) Received: from [10.0.1.68] (184-23-158-127.dsl.dynamic.sonic.net [184.23.158.127]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2KE1hno031193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Mar 2014 07:01:43 -0700 Message-ID: <532AF4C7.3040006@sonic.net> Date: Thu, 20 Mar 2014 07:01:43 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan , "efficientnd-dt@ietf.org" References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> In-Reply-To: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-ID: C;JCTEKjiw4xG2d9KVOBdzQA== M;Tkb6Kjiw4xG2d9KVOBdzQA== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/CUtgJHqA9bpVpmIFiVcApWH-_Ws Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 14:01:57 -0000 On 3/20/14 5:35 AM, Ole Troan wrote: > I tried to list the number of problems with DAD as currently specified in RFC4861/4862: > > Doesn’t detect duplicate L2 addresses Sometimes it does, but under rather limited cases. > Unreliable - fails at detecting actual duplicates in several cases: > - Blocked L2 ports > - Unreliable multicast (collision detection requires two multicast messages to pass through) > (with default DAD attempts = 1 > - False positives in case of looped interfaces (solved by enhanced-dad) > Delays use of address until DAD is finished (rfc4429) > Doesn’t deal with partition and joining > Doesn’t specify what to do in case of collision We don't have a generic specification - but things like temporary and CGA do specify it. > Requires all nodes to be awake to defend their address > Unclear on what a node should do after L2 events / waking up from sleep > Vendor sauce: May be used as a signalling message from network to host that it cannot use an address > Vendor sauce: Used by the network to build state > > anything else? Can't think of any. Erik > > cheers, > Ole > > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Thu Mar 20 07:28:12 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D3F1A03CA for ; Thu, 20 Mar 2014 07:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 wseVgq4aiSbL for ; Thu, 20 Mar 2014 07:28:10 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA081A03FE for ; Thu, 20 Mar 2014 07:28:10 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i8so1047130qcq.3 for ; Thu, 20 Mar 2014 07:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zVhfcF7Y4UodmPIQHN5seDz1afjTtM7JrD5ZzuJjTJo=; b=pOUUxaaZkzYZiteOiLBEhbgaxUmuKp5XygcWL1pp+XetWbQ+6OKD58KpeYu1zpIaPB VHmDkkCu0mGqeVz1ejkLlc3wQHPNvGbpVVWZvTF3sJmMu8IGeBnYsnCslOxnxBGDf5q1 sY9mOxn0zCECUhyB2bZftPFV2nAaE9O7VZ7fT7LTjdrFG71ly2kiWX33Xa+/QGovMc6f G92NM6rVdM+uHvLf4D8LUi/I+ZrKzx6Xq4HKoRjzwaGJ90dzVGLrE2Qw4EBqKeXsNPOW TFBaMOVaLRontS6eqWwfIttlHelouBANXaqRh9Gi83+FrQJmBNnyHZZOY2/brCSbudFc LK/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zVhfcF7Y4UodmPIQHN5seDz1afjTtM7JrD5ZzuJjTJo=; b=WIDp1QVImUhku/uHcn9yfP1aE7+JYbDkT00uj6EfIBjJsPqgnpHTJuQia1o+Su/yih fL1fFS10DWPeCO4dPW9tl9wYjzPDoz/Ry4tloY1EWLRKeMNnHlnZvVtNe9z6dzV8o4Lw +hHHDgdJPFm+9NxdmoJwGXr/NDdcQMibMSRLLB3urET1dNKDoyP45VIBboP9jn30vynV mlfSujVaVQ3QESIThyq33RoAd+xBtFs4BvJY9tPSl3ZxtqWCe4RvqzbRPOTpiEhnCe/P 2QvnlAd2AopPq5PPMMJck9FgifCS65G09Bee9s16eysU/Nnay+rFdEj6ZIfVbSsxnPpr FKsQ== X-Gm-Message-State: ALoCoQmG7Mww1y8ps3P+CKvKtSuFh1C5B2/d1bH8mDWGPb5j5rOS9CcEeU5UdTKRKPXdWtca3M2sX4DzYXCFBY/WPjI21fz7VGr5zGT6u+XMv+k6r6naXGOKeIcUXTcUFm2YdOsCXlPJOm8e4TiYmdnzouvg3hZ22OZqmG8fgbWado0AJujFxZ24DLO3/TnDKDA/gEzTOH0twV9QxVl6bBE53M5OdU4QEg== X-Received: by 10.224.160.201 with SMTP id o9mr6138427qax.85.1395325681343; Thu, 20 Mar 2014 07:28:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.28.195 with HTTP; Thu, 20 Mar 2014 07:27:41 -0700 (PDT) In-Reply-To: <532AF2EF.20902@sonic.net> References: <532AF2EF.20902@sonic.net> From: Erik Kline Date: Thu, 20 Mar 2014 23:27:41 +0900 Message-ID: To: Erik Nordmark Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/5FbYbMTFo_-MmLz1ZCyDLAuiOSY Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Let's use appear.in for the call X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 14:28:12 -0000 For reasons I haven't determined I'm only able to hear about 1 audio packet in 5, or something. I'll try to catch up on whatever notes may be produced. Sorry. :-/ From nobody Thu Mar 20 21:54:18 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B3F1A092D for ; Thu, 20 Mar 2014 21:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 8Tg1IrqOp23D for ; Thu, 20 Mar 2014 21:54:14 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5F41A084D for ; Thu, 20 Mar 2014 21:54:14 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id um1so1926389pbc.30 for ; Thu, 20 Mar 2014 21:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wXkvHjBPPzvVFCFWuu9KiGmE47xbhpdsskrJRzXKL6k=; b=lmCQMszIYL1A4LpZ+T5dQVFuAKEpdvakE3ZufVPmE99Nxf1PD8iZ16JCiQRBKK7Adn bO4W4P4YF7oD254b89AQqiZn3TotmoR19Qq30N+qxnQkbOZNy0b34z5YrzHtn8zkWeWP K7BJYqAyLJIdAsgjyC0FnWeoykRdDMALQ7Nz0dX6aNO8FdpnvQTwDdzpnqmjEAFXsv91 ehkE7qwtueCOetfPWMTPuzoe4EqIHHksLco1lhR20ZZd4+cEIgE7pOauYHdk/Jd/FPI1 5cxAWaFQFstg0q9b9YYWCHsaRLa2YKiFK7Y7Cu45TT96kRWYaXJnbXu/DXKs3s5W4jXt dGpg== X-Received: by 10.68.143.231 with SMTP id sh7mr51925608pbb.7.1395377645204; Thu, 20 Mar 2014 21:54:05 -0700 (PDT) Received: from [172.23.208.21] ([125.35.60.218]) by mx.google.com with ESMTPSA id yo9sm19905348pab.16.2014.03.20.21.54.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Mar 2014 21:54:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <532AF2EF.20902@sonic.net> Date: Fri, 21 Mar 2014 12:53:47 +0800 Content-Transfer-Encoding: 7bit Message-Id: References: <532AF2EF.20902@sonic.net> To: Erik Nordmark X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/es5cOWC0ArM37lqE0xlifHt9BnU Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] Let's use appear.in for the call X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 04:54:16 -0000 Sorry for missing a call. Got last minute schedule change. - JOuni On Mar 20, 2014, at 9:53 PM, Erik Nordmark wrote: > Go to https://appear.in/efficientnd-dt > > Needs an WebRTC browser such as Crome > > Erik > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Fri Mar 21 02:06:49 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09361A08AB for ; Fri, 21 Mar 2014 02:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 isZ4G0oFZkOI for ; Fri, 21 Mar 2014 02:06:46 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id C64221A08A4 for ; Fri, 21 Mar 2014 02:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1355; q=dns/txt; s=iport; t=1395392797; x=1396602397; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=LIV1WhsqbKmCcPJYg4nbDw9tL34qr3B0606WzOpBv8w=; b=IzNfMDWgf9hfxS/4CDT/n8bhT1wZih7LsKV32rvcIoj/KXaq5b5nioP9 HDkpxb+U6LvURnvLDKsFXcT2w8eW0s6jHOoiITECNczSmcZg1Bsmtk9wu 7qHrq2/Ivzw35Wdwj9k3eM/xS/soojbXI7zDDqr0tOdijNZTHjb2Hd7Xt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABYALFOtJV2a/2dsb2JhbABZgwaBEsJUgRMWdIIsgQsBCA5qJQIEARKHec9qF45xhDgEiRqPL5Ixgy2CKw X-IronPort-AV: E=Sophos;i="4.97,702,1389744000"; d="scan'208";a="29250119" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 21 Mar 2014 09:06:37 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2L96bEt026962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 09:06:37 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.22]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 04:06:37 -0500 From: "Eric Levy- Abegnoli (elevyabe)" To: Ole Troan , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] DAD problems Thread-Index: AQHPROTdNaHlZfr8OEyBXED/XY1evA== Date: Fri, 21 Mar 2014 09:06:36 +0000 Message-ID: In-Reply-To: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.49.80.36] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5F73378897593949B8BBA020841F90F7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/iDMxDhlfH0vEApEjbfc2HCTh4cQ Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 09:06:48 -0000 Vendor sauce is mostly rfc6620: (Used by the network to build state). You can add: rfc6620: used by switches to poll devices for checking an address in use. DAD is used because this is the only query that does not need a source address (unlike NUD or NS-lokkup). This is problematic because it can get confused by the the target as "my address is a duplicate. Eric=20 On 20/03/14 13:35, "Ole Troan" wrote: >I tried to list the number of problems with DAD as currently specified in >RFC4861/4862: > >Doesn=B9t detect duplicate L2 addresses >Unreliable - fails at detecting actual duplicates in several cases: >- Blocked L2 ports >- Unreliable multicast (collision detection requires two multicast >messages to pass through) > (with default DAD attempts =3D 1 >- False positives in case of looped interfaces (solved by enhanced-dad) >Delays use of address until DAD is finished (rfc4429) >Doesn=B9t deal with partition and joining >Doesn=B9t specify what to do in case of collision >Requires all nodes to be awake to defend their address >Unclear on what a node should do after L2 events / waking up from sleep >Vendor sauce: May be used as a signalling message from network to host >that it cannot use an address >Vendor sauce: Used by the network to build state > >anything else? > >cheers, >Ole From nobody Fri Mar 21 03:02:13 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E2B1A0696 for ; Fri, 21 Mar 2014 03:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 2Zd1fS21phCD for ; Fri, 21 Mar 2014 03:02:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F3AEA1A06B4 for ; Fri, 21 Mar 2014 03:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3863; q=dns/txt; s=iport; t=1395396117; x=1396605717; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Wy6k20EprMrNFETp6mRW/uhzb5kiOdvltl3bMg5f+Wo=; b=chvKWaRJmSthdG7I+ftQ92BmQvg9ljJxnyJ0P/vhYx7Bcs0WW8Bfn9xG JbNm3cw0v45vp3LnvNJHUv+/pmCW6XVPdrzI3cjBov2j7U60By2DDyFjd DB+s3gvCv2qJidpTtPdO2TJePvk/yMsPuTeMhkgTa+KL7RQXM4YAlmCS8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAJgNLFOtJXG//2dsb2JhbABPCoMGO1e7IYZjUYEXFnSCJQEBAQQBAQEkRxcEAgEIEQQBAQEKHQcnCxQJCAIEARIIh3ENz1gTBI4OKzgGgx6BFASJGqFggy2CKw X-IronPort-AV: E=Sophos;i="4.97,703,1389744000"; d="scan'208";a="311898220" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 21 Mar 2014 10:01:56 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2LA1uQ2018185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 10:01:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 05:01:56 -0500 From: "Pascal Thubert (pthubert)" To: "Eric Levy- Abegnoli (elevyabe)" , Ole Troan , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] DAD problems Thread-Index: AQHPROTdNaHlZfr8OEyBXED/XY1evJrrSMiw Date: Fri, 21 Mar 2014 10:01:56 +0000 Deferred-Delivery: Fri, 21 Mar 2014 10:01:00 +0000 Message-ID: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] 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/efficientnd-dt/LEQ_0cx7kYlYgJK-d2iHhMODgJY Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 10:02:09 -0000 Hello Eric and Ole 1) DAD will not discriminate between self-inflicted and real duplication. There are multiple use cases when a DAD can come back though it's not class= ical Ethernet.=20 Note: I'm not saying that we need to care about duplicate MAC, this is a se= parate debate. I'm saying that layer 3 should take care of its own regardless of the weird= ness of L2. -> It could seem relevant that DAD uniquely identify the requester like DHC= P does. 2) The DAD behavior when the node moves needs to be improved and unified to= support ND proxies. In RFC 4389, RFC 6275, and 6TiSCH, we define proxies that will do DAD on be= half of not-onlink devices. In some cases a node may move onto the link whe= re the proxy is defending its address(es), and the proxy may (will in RFC62= 75) prevent the node from inserting the address unless a proper deregistrat= ion has taken place. In Eric's case the proxy polls the device using DAD an= d if that happens in TENTATIVE, then again the device loses it address. -> It could be relevant to reaffirm the role of the A bit in conjunction wi= th the unique ID above. 3) As in 1) there is a need to determine which is the node behind a proxy. = And If that is the case and finally 2 proxies contend for a same address fo= r a same owner, we cannot sort out which of the proxies (if any) has a stal= e state. In the duocast model, which is used in industrial wireless, both proxies co= uld actually reach the device at the same time so they would not be exclusi= ve. To support that model we need to have allow for asynchronous registrati= ons that are not mutually exclusive. In the traditional model with a unique proxy, one proxy did not see the wir= eless device move away (yet). In that model, a notion of time or sequence = of events would do. -> A simple sequence number covers both cases. In duocast, the 2 registrati= ons would come with a same sequence. Cheers, Cheers, Pascal > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf O= f Eric > Levy- Abegnoli (elevyabe) > Sent: vendredi 21 mars 2014 10:07 > To: Ole Troan; efficientnd-dt@ietf.org > Subject: Re: [Efficientnd-dt] DAD problems >=20 > Vendor sauce is mostly rfc6620: (Used by the network to build state). > You can add: > rfc6620: used by switches to poll devices for checking an address in use. > DAD is used because this is the only query that does not need a source ad= dress > (unlike NUD or NS-lokkup). This is problematic because it can get confuse= d by > the the target as "my address is a duplicate. > Eric >=20 > On 20/03/14 13:35, "Ole Troan" wrote: >=20 > >I tried to list the number of problems with DAD as currently specified > >in > >RFC4861/4862: > > > >Doesn=B9t detect duplicate L2 addresses > >Unreliable - fails at detecting actual duplicates in several cases: > >- Blocked L2 ports > >- Unreliable multicast (collision detection requires two multicast > >messages to pass through) > > (with default DAD attempts =3D 1 > >- False positives in case of looped interfaces (solved by enhanced-dad) > >Delays use of address until DAD is finished (rfc4429) Doesn=B9t deal wit= h > >partition and joining Doesn=B9t specify what to do in case of collision > >Requires all nodes to be awake to defend their address Unclear on what > >a node should do after L2 events / waking up from sleep Vendor sauce: > >May be used as a signalling message from network to host that it cannot > >use an address Vendor sauce: Used by the network to build state > > > >anything else? > > > >cheers, > >Ole >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Fri Mar 21 03:52:21 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C02D1A0717 for ; Fri, 21 Mar 2014 03:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 yhX-U93kxpVf for ; Fri, 21 Mar 2014 03:52:16 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id A6C631A07B5 for ; Fri, 21 Mar 2014 03:52:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6787; q=dns/txt; s=iport; t=1395399127; x=1396608727; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1JmgArO14xpHFqqEPeoOH6Na2GVH/B46hNAY1gzoaY8=; b=KnCnPpjCG2O0l4X8HpAOcwX/dNSGBNzarrQgfng7My7CTkIY1mboIBRO VqzdjcCNIfmnZZfUQn1tfFCCqs7Qce8lP8I5vKw84BfGFrit0ysEVL86w ElHfday3zQK5bMzm5nXM8Ba4V8pNZGmlJcN7Iak2zhm8Svcqw8uGp0b8G k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAO0YLFOtJV2Y/2dsb2JhbABPCoMGO1e7JIZjUYEXFnSCJQEBAQQBAQEkRxcEAgEIEQQBAQEKHQcnCxQJCAIEARIIh3ENz2YTBI4OKzgGgx6BFASJGqFggy2CKw X-IronPort-AV: E=Sophos;i="4.97,703,1389744000"; d="scan'208";a="29281630" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 21 Mar 2014 10:52:07 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2LAq7eE024653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 10:52:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 05:52:06 -0500 From: "Pascal Thubert (pthubert)" To: "Eric Levy- Abegnoli (elevyabe)" , Ole Troan , "efficientnd-dt@ietf.org" Thread-Topic: [Efficientnd-dt] DAD problems Thread-Index: AQHPROTdNaHlZfr8OEyBXED/XY1evJrrSMiwgAASWCA= Date: Fri, 21 Mar 2014 10:52:06 +0000 Deferred-Delivery: Fri, 21 Mar 2014 10:51:00 +0000 Message-ID: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.4] 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/efficientnd-dt/yAvu9T2L86CgH-iNrtTnaht6NBs Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 10:52:20 -0000 Hello Eric and Ole (fixed typos) 1) DAD will not discriminate between self-inflicted and real duplication. There are multiple use cases when a DAD can come back though it's not class= ical Ethernet.=20 Note: I'm not saying that we need to care about duplicate MAC, this is a se= parate debate. I'm saying that layer 3 should take care of its own regardless of the weird= ness of L2. -> It could seem relevant that DAD uniquely identify the requester like DHC= P does. 2) The DAD behavior when the node moves needs to be improved and unified to= support ND proxies. In RFC 4389, RFC 6275, and 6TiSCH, we define proxies that will do DAD on be= half of not-onlink devices. In some cases a node may move onto the link whe= re the proxy is defending its address(es), and the proxy may (will in RFC62= 75) prevent the node from inserting the address unless a proper deregistrat= ion has taken place. In Eric's case the proxy polls the device using DAD an= d if that happens in TENTATIVE, then again the device loses it address. -> It could be relevant to reaffirm the role of the Override bit in NA in c= onjunction with the unique ID above, and maybe define the bit in NS as well= . 3) As for hosts in 1) there is a need to determine which is the node behind= a proxy. If that is in place and 2 proxies contend for a same address for = a same owner, the additional problem is to determine which of the proxies (= or none or both) has a stale state. In the duocast model, which is used in industrial wireless, both proxies co= uld actually serve the device at the same time. To support that model we ne= ed to have allow for asynchronous registrations that are not mutually exclu= sive. In the traditional model with a unique proxy, we end up in a contention if = one proxy did not see the wireless device move away (yet). In that model, = a notion of time or sequence of events would do. -> PTP (1588) is complex, requires specific hardware, does not help in duoc= ast and is complete overkill for the case. =20 -> A simple sequence number covers both cases. In duocast, the 2 registrati= ons would come with a same sequence. Cheers, Pascal Cheers, Pascal > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf O= f > Pascal Thubert (pthubert) > Sent: vendredi 21 mars 2014 11:02 > To: Eric Levy- Abegnoli (elevyabe); Ole Troan; efficientnd-dt@ietf.org > Subject: Re: [Efficientnd-dt] DAD problems >=20 > Hello Eric and Ole >=20 > 1) DAD will not discriminate between self-inflicted and real duplication. >=20 > There are multiple use cases when a DAD can come back though it's not cla= ssical > Ethernet. > Note: I'm not saying that we need to care about duplicate MAC, this is a > separate debate. > I'm saying that layer 3 should take care of its own regardless of the wei= rdness of > L2. > -> It could seem relevant that DAD uniquely identify the requester like D= HCP > does. >=20 >=20 > 2) The DAD behavior when the node moves needs to be improved and unified = to > support ND proxies. >=20 > In RFC 4389, RFC 6275, and 6TiSCH, we define proxies that will do DAD on = behalf > of not-onlink devices. In some cases a node may move onto the link where = the > proxy is defending its address(es), and the proxy may (will in RFC6275) p= revent > the node from inserting the address unless a proper deregistration has ta= ken > place. In Eric's case the proxy polls the device using DAD and if that ha= ppens in > TENTATIVE, then again the device loses it address. > -> It could be relevant to reaffirm the role of the A bit in conjunction = with the > unique ID above. >=20 > 3) As in 1) there is a need to determine which is the node behind a proxy= . And If > that is the case and finally 2 proxies contend for a same address for a s= ame > owner, we cannot sort out which of the proxies (if any) has a stale state= . >=20 > In the duocast model, which is used in industrial wireless, both proxies = could > actually reach the device at the same time so they would not be exclusive= . To > support that model we need to have allow for asynchronous registrations t= hat > are not mutually exclusive. > In the traditional model with a unique proxy, one proxy did not see the w= ireless > device move away (yet). In that model, a notion of time or sequence of e= vents > would do. > -> A simple sequence number covers both cases. In duocast, the 2 registra= tions > would come with a same sequence. >=20 > Cheers, >=20 >=20 > Cheers, >=20 > Pascal >=20 > > -----Original Message----- > > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On > > Behalf Of Eric > > Levy- Abegnoli (elevyabe) > > Sent: vendredi 21 mars 2014 10:07 > > To: Ole Troan; efficientnd-dt@ietf.org > > Subject: Re: [Efficientnd-dt] DAD problems > > > > Vendor sauce is mostly rfc6620: (Used by the network to build state). > > You can add: > > rfc6620: used by switches to poll devices for checking an address in us= e. > > DAD is used because this is the only query that does not need a source > > address (unlike NUD or NS-lokkup). This is problematic because it can > > get confused by the the target as "my address is a duplicate. > > Eric > > > > On 20/03/14 13:35, "Ole Troan" wrote: > > > > >I tried to list the number of problems with DAD as currently > > >specified in > > >RFC4861/4862: > > > > > >Doesn=B9t detect duplicate L2 addresses Unreliable - fails at detectin= g > > >actual duplicates in several cases: > > >- Blocked L2 ports > > >- Unreliable multicast (collision detection requires two multicast > > >messages to pass through) > > > (with default DAD attempts =3D 1 > > >- False positives in case of looped interfaces (solved by > > >enhanced-dad) Delays use of address until DAD is finished (rfc4429) > > >Doesn=B9t deal with partition and joining Doesn=B9t specify what to do= in > > >case of collision Requires all nodes to be awake to defend their > > >address Unclear on what a node should do after L2 events / waking up f= rom > sleep Vendor sauce: > > >May be used as a signalling message from network to host that it > > >cannot use an address Vendor sauce: Used by the network to build > > >state > > > > > >anything else? > > > > > >cheers, > > >Ole > > > > _______________________________________________ > > Efficientnd-dt mailing list > > Efficientnd-dt@ietf.org > > https://www.ietf.org/mailman/listinfo/efficientnd-dt >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Fri Mar 21 09:53:09 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7051A08D2 for ; Fri, 21 Mar 2014 09:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 dVwx59Yz_CCr for ; Fri, 21 Mar 2014 09:52:56 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 23B951A09BD for ; Fri, 21 Mar 2014 09:52:56 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 87D9660B9; Fri, 21 Mar 2014 09:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=AOdWIoCiGlyBShaZB2CvueylRx4=; b=IH/DXVMdtUovjzCO05 dpvgBl+VO4dzdWcLEDGbn9Rqh9fRu9d5TKk7SLXiPyuolqWfvE/FhIajpUDT9YuX AF3/dSfTxHKSAh+cOFvg6eGi+1GhEx3GqPUVarFO+nPzRyi+KhM7pTDtno2L77Gl I2YpGtM/v1ro9e+mZhj6SXCbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=bVXliF923KPMNZjP0NmtpIl82Xjiungxc7PyFltvTyFgJ6F019k Z/WmZ2GVDC+yRGuG4/8qlthREoFV0GlE2SSppGVOl7juzN4vngVn5FdRWxg/Hks0 s5YqymbqfcUCQ1akZyowHromEcUGH92x9/zNnRwgyJS/JDq2V8kW3+uk= Received: from dhcp-10-61-110-248.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 69FB260A3; Fri, 21 Mar 2014 09:52:43 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ole Troan In-Reply-To: Date: Fri, 21 Mar 2014 16:52:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/27fZb4SivuqfbRCZDHOCtd2wRcU Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 16:52:58 -0000 Pascal, > 1) DAD will not discriminate between self-inflicted and real = duplication. >=20 > There are multiple use cases when a DAD can come back though it's not = classical Ethernet.=20 > Note: I'm not saying that we need to care about duplicate MAC, this is = a separate debate. > I'm saying that layer 3 should take care of its own regardless of the = weirdness of L2. > -> It could seem relevant that DAD uniquely identify the requester = like DHCP does. >=20 indeed. I already had that under: "- False positives in case of looped interfaces (solved by = enhanced-dad)" > 2) The DAD behavior when the node moves needs to be improved and = unified to support ND proxies. >=20 > In RFC 4389, RFC 6275, and 6TiSCH, we define proxies that will do DAD = on behalf of not-onlink devices. In some cases a node may move onto the = link where the proxy is defending its address(es), and the proxy may = (will in RFC6275) prevent the node from inserting the address unless a = proper deregistration has taken place. In Eric's case the proxy polls = the device using DAD and if that happens in TENTATIVE, then again the = device loses it address. > -> It could be relevant to reaffirm the role of the A bit in = conjunction with the unique ID above. here we are talking about a use of DAD that it was never designed for. I = don't think we can classify this as a problem with DAD as specified in = 4861/4862. > 3) As in 1) there is a need to determine which is the node behind a = proxy. And If that is the case and finally 2 proxies contend for a same = address for a same owner, we cannot sort out which of the proxies (if = any) has a stale state. >=20 > In the duocast model, which is used in industrial wireless, both = proxies could actually reach the device at the same time so they would = not be exclusive. To support that model we need to have allow for = asynchronous registrations that are not mutually exclusive. > In the traditional model with a unique proxy, one proxy did not see = the wireless device move away (yet). In that model, a notion of time or = sequence of events would do. > -> A simple sequence number covers both cases. In duocast, the 2 = registrations would come with a same sequence. again, I don't see how this is a problem with DAD. with regards to multi-link subnets; there is an IETF consensus that = multilink-subnets had so many issues that work on it should be = abandoned. with regards to ND proxies, that's experimental. what are the = results of the experiment? it is unclear to me what bearing multi-link subnets / ND proxies should = have on this work in general and on the thread of DAD problems = specifically. cheers, Ole From nobody Fri Mar 21 10:30:30 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A231A08DC for ; Fri, 21 Mar 2014 10:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 UTSNt2aoe9ZB for ; Fri, 21 Mar 2014 10:30:26 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7B11A046A for ; Fri, 21 Mar 2014 10:30:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3641; q=dns/txt; s=iport; t=1395423016; x=1396632616; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=IHCxOJbjKmSxm50UUUP8rU9WG1rWtrcn+IPpQmfxWaY=; b=EvutPO7dTgc7XHz04ZmN4nQ7MVeH73mZImrpLvT5znDqeGLit5wl9Ukr DsjQhpDZKQESpJLpJGp4C/XDT+pOz4FpGcAI2jZFp1qi4wlV8YhMKOjoy 0qB4SzYJKgwnGfGrv95EW3G/a2QAVFUZ6RKv0x7dCIY2oY7x+p4/emzgc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAOd1LFOtJV2c/2dsb2JhbABPCoMGO1e7JYZpUYEWFnSCJQEBAQMBAQEBJBM0CwUHBAIBCA4DBAEBCxQJBycLFAkIAgQOBQiHaQgNz1kTBI4OKzEHBoMegRQEqnqDLYIr X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208";a="311981028" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 21 Mar 2014 17:30:16 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2LHUG5Y012427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 17:30:16 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 12:30:16 -0500 From: "Pascal Thubert (pthubert)" To: Ole Troan Thread-Topic: [Efficientnd-dt] DAD problems Thread-Index: AQHPROTdNaHlZfr8OEyBXED/XY1evJrrSMiwgADNMwD//7OgUA== Date: Fri, 21 Mar 2014 17:30:15 +0000 Deferred-Delivery: Fri, 21 Mar 2014 17:29:00 +0000 Message-ID: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> In-Reply-To: <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/L3FwS09A10jgexn8IEE0qCR8MpQ Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 17:30:28 -0000 Hello Ole: I agree that DAD in 4862 was not designed with those use cases in mind - I'= ll buy the not_a_bug - but the use cases are out there (MIP, DAD proxy) and= if we are to revamp DAD, my suggestion is to make it work at least to the = expectation of existing RFCs... Cheers, Pascal > -----Original Message----- > From: Efficientnd-dt [mailto:efficientnd-dt-bounces@ietf.org] On Behalf O= f Ole > Troan > Sent: vendredi 21 mars 2014 17:53 > To: Pascal Thubert (pthubert) > Cc: Eric Levy- Abegnoli (elevyabe); efficientnd-dt@ietf.org > Subject: Re: [Efficientnd-dt] DAD problems >=20 > Pascal, >=20 > > 1) DAD will not discriminate between self-inflicted and real duplicatio= n. > > > > There are multiple use cases when a DAD can come back though it's not > classical Ethernet. > > Note: I'm not saying that we need to care about duplicate MAC, this is = a > separate debate. > > I'm saying that layer 3 should take care of its own regardless of the w= eirdness > of L2. > > -> It could seem relevant that DAD uniquely identify the requester like= DHCP > does. > > >=20 > indeed. I already had that under: > "- False positives in case of looped interfaces (solved by enhanced-dad)" >=20 > > 2) The DAD behavior when the node moves needs to be improved and unifie= d > to support ND proxies. > > > > In RFC 4389, RFC 6275, and 6TiSCH, we define proxies that will do DAD o= n > behalf of not-onlink devices. In some cases a node may move onto the link > where the proxy is defending its address(es), and the proxy may (will in = RFC6275) > prevent the node from inserting the address unless a proper deregistratio= n has > taken place. In Eric's case the proxy polls the device using DAD and if t= hat > happens in TENTATIVE, then again the device loses it address. > > -> It could be relevant to reaffirm the role of the A bit in conjunctio= n with the > unique ID above. >=20 > here we are talking about a use of DAD that it was never designed for. I = don't > think we can classify this as a problem with DAD as specified in 4861/486= 2. >=20 > > 3) As in 1) there is a need to determine which is the node behind a pro= xy. And If > that is the case and finally 2 proxies contend for a same address for a s= ame > owner, we cannot sort out which of the proxies (if any) has a stale state= . > > > > In the duocast model, which is used in industrial wireless, both proxie= s could > actually reach the device at the same time so they would not be exclusive= . To > support that model we need to have allow for asynchronous registrations t= hat > are not mutually exclusive. > > In the traditional model with a unique proxy, one proxy did not see the > wireless device move away (yet). In that model, a notion of time or sequ= ence of > events would do. > > -> A simple sequence number covers both cases. In duocast, the 2 regist= rations > would come with a same sequence. >=20 > again, I don't see how this is a problem with DAD. >=20 > with regards to multi-link subnets; there is an IETF consensus that multi= link- > subnets had so many issues that work on it should be abandoned. with rega= rds > to ND proxies, that's experimental. what are the results of the experimen= t? > it is unclear to me what bearing multi-link subnets / ND proxies should h= ave on > this work in general and on the thread of DAD problems specifically. >=20 > cheers, > Ole >=20 > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Fri Mar 21 10:40:47 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08781A046A for ; Fri, 21 Mar 2014 10:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 4L0kZEi8NrYS for ; Fri, 21 Mar 2014 10:40:44 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4771A03BF for ; Fri, 21 Mar 2014 10:40:44 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id D18C360C0; Fri, 21 Mar 2014 10:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=yu09HfwpD4lM0LtWswQiy X7rEqk=; b=kxRFc8+1KKHL/gAnwX1v5pNFuZUDlvJIM3HLKCfCy1A0SuhXnX1NG NGOQ0i8YcKU+UHDtrP1tVp3WvDXthmTZ2YB43TbOqucNoAfDl8SKpu3hhHsm8zZS R+lAbnQR/k/K1FRkO4lJjzH9ggozpjXX8h4+OF+LyZg1RGOBxXt2Sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=qhGd71WYF+8bPwc xEq6DiSyHRTFF2gW1u9Z1XV/XeHcuvAb8ZtvVtY68hFC+JRW9bBRPaCZbZY1iAd6 ObgSSdQgeQHE+dasmntULRknYclojgF4dgjM2xEO+hebc8/isaWNyXBf/sfHCzcH NxWvbS9yhqc9/N1bOJLw/fHHXgv4= Received: from dhcp-10-61-110-248.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 959C560C8; Fri, 21 Mar 2014 10:40:29 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_50CA22F5-D5C8-4CD3-AEA4-ED556D08A23C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ole Troan In-Reply-To: Date: Fri, 21 Mar 2014 17:40:23 +0000 Message-Id: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/bF4Obmk1x7dWaytixwVEmgc3hH8 Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 17:40:45 -0000 --Apple-Mail=_50CA22F5-D5C8-4CD3-AEA4-ED556D08A23C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pascal, > I agree that DAD in 4862 was not designed with those use cases in mind = - I'll buy the not_a_bug - but the use cases are out there (MIP, DAD = proxy) and if we are to revamp DAD, my suggestion is to make it work at = least to the expectation of existing RFCs... if the actual use case isn't duplicate address detection, then there may = be better solutions out there than abusing DAD. I'm all for getting a good understanding of 'creative uses' of DAD as = well as understanding the problems that you are looking at solving. do = you have a simple text explaining the problem you want to solve? cheers, Ole --Apple-Mail=_50CA22F5-D5C8-4CD3-AEA4-ED556D08A23C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTLHmHAAoJEFuJXizso86gns8H/jyvNF6tCl4FWO+VF1XnRI6D 1KYCsXAL0W/4R5QJ3NFxiTyRmSZzaudvjhENQgUFp7z9n2Mzx5COTFo4LfxKyRof 2Act4iWqfrsmhw0hxEeru9d3ibDO6Rbc5O7O0P3rePttAkapnQX8+xSlChiRw3d8 rpUXsNC5O39ftecKhuO1Rq9w/FeZi2dlLdjbflFDNONlXIupVzAe7FHPivx1tk0R m/i5LQMn/+7CvXKBftySYn62WcOCfDowqReh+OI68/4Ac+6Z9SnQaa758Q910hoP 7XU2AIqnUDjFeTqp2gy9AsmpYQn21rwHsmSvKgrhqKqhn//G6LzSAQbnAc1BGQQ= =o+CL -----END PGP SIGNATURE----- --Apple-Mail=_50CA22F5-D5C8-4CD3-AEA4-ED556D08A23C-- From nobody Fri Mar 21 11:23:37 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AA91A09FF for ; Fri, 21 Mar 2014 11:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 c17h47ee0JfW for ; Fri, 21 Mar 2014 11:23:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 810271A0790 for ; Fri, 21 Mar 2014 11:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1931; q=dns/txt; s=iport; t=1395426205; x=1396635805; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CotFYKcecXv+KHbwWEuoNYIL86k8wKEYs9mLqVgLeng=; b=XSk/FEJ3uBNzI1L3kZZYNrzJq0NKevcI1ACUUpB8x3l7SeY77EWmg64n LN7yQ5qHpQ8qKM2t24uuuhLBgVWgR9hqcW6lGu5jCl70v6ScyIyzrugkD 6+1iVUcbDHriU0x4RoaX9IQx3JzUSrGchyeUv6Q2pxRLp+HZUEVVcoFMX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAOWCLFOtJXG8/2dsb2JhbABZgwaBEsJfgRYWdIIlAQEBBDo/DAQCAQgOAwQBAQsUCQcyFAkIAgQOBQgTh17PaReOOTEHBoMegRQBA6p6gy2CKw X-IronPort-AV: E=Sophos;i="4.97,704,1389744000"; d="scan'208";a="308958722" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 21 Mar 2014 18:23:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2LINMWm015559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 18:23:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 13:23:21 -0500 From: "Pascal Thubert (pthubert)" To: Ole Troan Thread-Topic: [Efficientnd-dt] DAD problems Thread-Index: AQHPROTdNaHlZfr8OEyBXED/XY1evJrrSMiwgADNMwD//7OgUIAAWbKA//+x06A= Date: Fri, 21 Mar 2014 18:23:21 +0000 Deferred-Delivery: Fri, 21 Mar 2014 18:23:00 +0000 Message-ID: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.22.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/EwgKbzHR3e2VE3tI3sDIOl5pdXM Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:23:34 -0000 I see what you're saying, Ole, and would agree on the case you describe.=20 But the issue here is that existing DAD is fooled by those configuration an= d provides a false positive... that's different. On the side, I do agree with Ran (on the 6MAN ML today) on the fact that ef= ficient ND should be innocuous to non E-ND devices, and that it should not = enter in the certification of devices that have no use of it. If there was = a misunderstanding there, just making it clear; I answered on the ML a few = minutes ago. For DAD to detect the anomalies that we are talking about, all we need is a= device unique ID and a sequence counter in a new option. Devices implement= ing this new option can perfectly cohabit with other devices that do not im= plement the option as long as the latter devices do not misbehave when rece= iving the option. The support of the option would only be recommended for = devices that move or may use a proxy.=20 Cheers, Pascal > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: vendredi 21 mars 2014 18:40 > To: Pascal Thubert (pthubert) > Cc: Eric Levy- Abegnoli (elevyabe); efficientnd-dt@ietf.org > Subject: Re: [Efficientnd-dt] DAD problems >=20 > Pascal, >=20 > > I agree that DAD in 4862 was not designed with those use cases in mind = - I'll > buy the not_a_bug - but the use cases are out there (MIP, DAD proxy) and = if we > are to revamp DAD, my suggestion is to make it work at least to the expec= tation > of existing RFCs... >=20 > if the actual use case isn't duplicate address detection, then there may = be better > solutions out there than abusing DAD. > I'm all for getting a good understanding of 'creative uses' of DAD as wel= l as > understanding the problems that you are looking at solving. do you have a > simple text explaining the problem you want to solve? >=20 > cheers, > Ole From nobody Fri Mar 21 13:30:24 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A391A0A0C for ; Fri, 21 Mar 2014 13:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] 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 LNIx8rWMadPm for ; Fri, 21 Mar 2014 13:30:21 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id CDD571A08E2 for ; Fri, 21 Mar 2014 13:30:21 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 153DE60F1; Fri, 21 Mar 2014 13:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=qqTTv2hpHWRgYZSXpcGXB 3SK/xs=; b=hCL5KvevNsCNEWoc8/xMPbfz6sGT50S92kzdtv/3QLIVfzxD/tPd1 dRosPZWlWpoFDSnUPHqs3o39tyULEDqg+/JHrvUS3qGHvRzR7pOW+Kr8S4mEu9cC VqPpHNp1rxyRmP8s0XKAYN5WPIBFJBTfA9Y46z4cXE1xerg/r4F2RU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=loKzCI3HhC0/J60 EUUR6+tiDKKCNLdNj7HS3/VN65XmW50QrtNyJtHWO+S3jAw8PaFAtXbsdTL6CHP6 lCbpRBjGhbSd6Mx1+c561SaJhAPYqFInf04j+o2gkEjCSMNvh/reuOH/Rt9eSCCc 2UJjFUqyY9thsVS46VzFdElFNx10= Received: from dhcp-10-61-106-234.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id AD79D60E3; Fri, 21 Mar 2014 13:30:08 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_19B3EA1D-12AC-4308-A63D-9E407C660896"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ole Troan In-Reply-To: Date: Fri, 21 Mar 2014 20:30:02 +0000 Message-Id: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/Gwd6tqeDNIKyZXlEChXWX38k-1w Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 20:30:23 -0000 --Apple-Mail=_19B3EA1D-12AC-4308-A63D-9E407C660896 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pascal, > I see what you're saying, Ole, and would agree on the case you = describe.=20 >=20 > But the issue here is that existing DAD is fooled by those = configuration and provides a false positive... that's different. >=20 > On the side, I do agree with Ran (on the 6MAN ML today) on the fact = that efficient ND should be innocuous to non E-ND devices, and that it = should not enter in the certification of devices that have no use of it. = If there was a misunderstanding there, just making it clear; I answered = on the ML a few minutes ago. >=20 > For DAD to detect the anomalies that we are talking about, all we need = is a device unique ID and a sequence counter in a new option. Devices = implementing this new option can perfectly cohabit with other devices = that do not implement the option as long as the latter devices do not = misbehave when receiving the option. The support of the option would = only be recommended for devices that move or may use a proxy.=20 for the looped link/receiving your own multicast we do have: http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-04 that's about to go working group last call. does that also cover the = cases you have in mind? cheers, Ole --Apple-Mail=_19B3EA1D-12AC-4308-A63D-9E407C660896 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTLKFKAAoJEFuJXizso86g+EoIAKPn8/KICXANyNp+cEdbJCN6 nDe23+uLTKsqK1WT5T8rUs6vnZoEn32UNuaLmeLJqU3R95U8oQI5DbgmaTTdq0m6 DxZVv3PC3wi8db2B9Zn3Juctq/AmtY1xe07tlDoPi3vRit/0rN4+Dh+B0AzNc7mg xMR2wi42zqWtdyzsMgO2fcgtG2X5UtsiAGCkaopmiyFTNZ0uB53Bbx9pntg200RI PhHOUxa7RuOg9hRYhlpHZfXzQhtN48X3lOSQt6g2LSeMtFlUIyN5E4ZsEVoxh7HA yeV+Rpr2MSbdxyBR5/GcQk8+mwZ09dvVyO6oWffI6knrAzTEaq44+/mOy54Jtco= =pHKc -----END PGP SIGNATURE----- --Apple-Mail=_19B3EA1D-12AC-4308-A63D-9E407C660896-- From nobody Sat Mar 22 00:45:14 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756B01A091E for ; Sat, 22 Mar 2014 00:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 lvm2ZuQyu7Sg for ; Sat, 22 Mar 2014 00:45:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF351A091D for ; Sat, 22 Mar 2014 00:45:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2600; q=dns/txt; s=iport; t=1395474301; x=1396683901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=k2bXiXHJG88/MKnHwfjJUDRmPVD755nxIqM2j7xDVGM=; b=Qx9T6UXQxmjtoBaEdQ2mdOzCK0kEWPsGN93ezjSl1TEdWQfsZEW62Ojw ozRbYJ+1b5yPkhF/i/W7dseZp7qUDpuU8RWvkdjyBXD5Ufrs7i+HJkXTE 9VOmusVDPk9syfECA2Hs6CO0Z8D/CzVkhfAMQGZ83iKbVcqa+00k2tgPa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAI0+LVOtJV2c/2dsb2JhbABZgwY7V8JrgRQWdIIlAQEBBDo/DAQCAQgOAwQBAQsUCQcyFAkIAgQOBQgRAodeDc4sF44+MQcGgx6BFASZfJB/gy2CKw X-IronPort-AV: E=Sophos;i="4.97,708,1389744000"; d="scan'208";a="312104243" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 22 Mar 2014 07:44:59 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2M7ixsH012314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 07:44:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Sat, 22 Mar 2014 02:44:58 -0500 From: "Pascal Thubert (pthubert)" To: Ole Troan Thread-Topic: [Efficientnd-dt] DAD problems Thread-Index: AQHPROTdNaHlZfr8OEyBXED/XY1evJrrSMiwgADNMwD//7OgUIAAWbKA//+x06CAAH2TAIAAZPjQ Date: Sat, 22 Mar 2014 07:44:58 +0000 Deferred-Delivery: Sat, 22 Mar 2014 07:44:00 +0000 Message-ID: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.64.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/sshXy-C0z9S9xMJvqAqgmYf485Y Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] DAD problems X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 07:45:12 -0000 Hello Ole: The nonce is not a UID; the draft helps for the immediate loopback problem = but not for the delayed one, e.g. a proxy. The difference is that the UID: * has a longer life. The node must be able to save it or reconstruct it as = long as it exists as a state in the network. * is expected to have more properties than a nonce, e.g. more likely to be = unique or harder to forge (CGA). Same problem as 4862: the solution works but the problem space that is envi= sioned is too narrow, so it will need more patching soon. How many steps do= we want to take? I understand that we cannot work on problems that we imagine we may have, b= ut here we are talking about clear and present issues in existing RFCs and = deployments.=20 This time I'll follow Lorenzo's wisdom. Overloading the nonce option can on= ly take use so far, as opposed to designing a new option that covers the ne= eds that are identified today. We know that those needs can be covered by a= UID and a TID. Cheers, Pascal > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: vendredi 21 mars 2014 21:30 > To: Pascal Thubert (pthubert) > Cc: Eric Levy- Abegnoli (elevyabe); efficientnd-dt@ietf.org > Subject: Re: [Efficientnd-dt] DAD problems >=20 > Pascal, >=20 > > I see what you're saying, Ole, and would agree on the case you describe= . > > > > But the issue here is that existing DAD is fooled by those configuratio= n and > provides a false positive... that's different. > > > > On the side, I do agree with Ran (on the 6MAN ML today) on the fact tha= t > efficient ND should be innocuous to non E-ND devices, and that it should = not > enter in the certification of devices that have no use of it. If there wa= s a > misunderstanding there, just making it clear; I answered on the ML a few > minutes ago. > > > > For DAD to detect the anomalies that we are talking about, all we need = is a > device unique ID and a sequence counter in a new option. Devices implemen= ting > this new option can perfectly cohabit with other devices that do not impl= ement > the option as long as the latter devices do not misbehave when receiving = the > option. The support of the option would only be recommended for devices = that > move or may use a proxy. >=20 > for the looped link/receiving your own multicast we do have: > http://tools.ietf.org/html/draft-ietf-6man-enhanced-dad-04 >=20 > that's about to go working group last call. does that also cover the case= s you > have in mind? >=20 > cheers, > Ole From nobody Sun Mar 23 03:37:28 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA63A1A6EF7 for ; Sun, 23 Mar 2014 03:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1TeMHmrq401n for ; Sun, 23 Mar 2014 03:37:24 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 259F81A0996 for ; Sun, 23 Mar 2014 03:37:24 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id A199D5FE8; Sun, 23 Mar 2014 03:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=DGdcEmeX8mjxkZSBultiZ ZJfLQI=; b=VJZDeDogtq4TUYQhomEJq1XPwSqvdUV2LUQ9AiHCsDvz4OaMaZ6I9 yAeJ0a6CJZw+YvjBw3QPN06F5bMeYy6otR5CFSgOHAZQYrD5Th01CA5zGFzfK/PH Xuj5sj9gpWO7zHxCHedoQb1jGcDqTuNQL172wh1Kn/eCJxEeLT6coU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=cskoGlmgVjxH7mr 8oj8tUsUQQC1WbDtHGuT/OjW5hGkqR+Qbgsd9Cw3Jvbh5TYesAah3ZN/UdPK/CH6 Q91T4sHKuPtz/0iEUWhWow87Yf0zoA10RQa4zokr0Ei1EPb1qFCLGa4Pzq9Z0iDE viYVizzUShQZrYnNjBrdS/mxBfjU= Received: from dhcp-10-61-96-76.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 87DDF5FDF; Sun, 23 Mar 2014 03:37:20 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AE54FDA7-5A0F-453D-8681-F34A612D7D3F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ole Troan In-Reply-To: Date: Sun, 23 Mar 2014 11:37:20 +0100 Message-Id: <9C4C892A-1241-4A99-9E74-43DEECF71D26@employees.org> References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/zyXiRgcou6a4aFy3lkNbN8iflL4 Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: [Efficientnd-dt] The larger problem (was Re: DAD problems) X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 10:37:26 -0000 --Apple-Mail=_AE54FDA7-5A0F-453D-8681-F34A612D7D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pascal, I've created a new thread for this discussion as it isn't directly = related to immediate problems with DAD. > The nonce is not a UID; the draft helps for the immediate loopback = problem but not for the delayed one, e.g. a proxy. >=20 > The difference is that the UID: > * has a longer life. The node must be able to save it or reconstruct = it as long as it exists as a state in the network. > * is expected to have more properties than a nonce, e.g. more likely = to be unique or harder to forge (CGA). the nonce is defined in rfc3971 > Same problem as 4862: the solution works but the problem space that is = envisioned is too narrow, so it will need more patching soon. How many = steps do we want to take? Pascal, you are many steps ahead of us (at least me :-)). I wouldn't be = surprised to learn that your solution is the correct one, but I would = dearly like to understand the logical steps that took you to it. - what problems are you trying to solve? - what led you t conclude that you need multilink-subnets? - what are you thinking of using DAD for? that doesn't appear to be = directly related to detection of duplicate addresses? - what are the purpose and benefits for "classic" IPv6 hosts? > I understand that we cannot work on problems that we imagine we may = have, but here we are talking about clear and present issues in existing = RFCs and deployments.=20 >=20 > This time I'll follow Lorenzo's wisdom. Overloading the nonce option = can only take use so far, as opposed to designing a new option that = covers the needs that are identified today. We know that those needs can = be covered by a UID and a TID. I'm not against working on multi-link subnets or solving the problem of = duplicate address detection in multi-link subnets. there are other more = pressing problems with multi-link subnets than DAD though. the DAD = problem can be simply solved. if every node picks a random iid out of a = 2^64 space, I'm happy to take all the support calls myself for the cases = of actual duplicates. ;-) cheers, Ole --Apple-Mail=_AE54FDA7-5A0F-453D-8681-F34A612D7D3F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTLrlgAAoJEFuJXizso86gIi4H/itM25cg3d7nFS+dunygIMRa TB1HEXxOc95Ekh9Aoy390M84+3pQKcKduBm+9Bu9FmudQb6yZm5o/uT3ydSI93Cw Zvs80aRVM43HLTFx/bnzy64lz9nD+VvMeiVv3ICGCJmV1pYHFOcnvRpoElofRlnn mSxRlFt1yZWaYD4qCHIaIGfea9ckhmPYadh4wsezHBqjrf7fJv3Qs8LoDcNuUjiK xn8DtXNBS6a4R7JWkO1W9ThQr6jsdXeDvBk7N1Xt2sUUdTlJPKJJg43fKchNf/Bk u7HsRxF00HL9vtwogPFNOndGBsdMg+ngQFEBPCohctDM5/6TVRZBRwzSAbwp3To= =t9me -----END PGP SIGNATURE----- --Apple-Mail=_AE54FDA7-5A0F-453D-8681-F34A612D7D3F-- From nobody Sun Mar 23 03:47:02 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125051A098B for ; Sun, 23 Mar 2014 03:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 8XINsoaRm6-6 for ; Sun, 23 Mar 2014 03:46:58 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61D1A6F64 for ; Sun, 23 Mar 2014 03:46:58 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id CC57E603F for ; Sun, 23 Mar 2014 03:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:message-id:date:to:mime-version; s= selector1; bh=9eHWdY9XgK7+7a1Js5JB5XR7MMg=; b=UmRvFH4H3T1zeLbRNj i3Msth/SjYExgIVRlGi/h0qBISQlN9lhfxC4wZAWFJnDL0LUiD57pDxppr/IKDWs XWKjp0PmWa0Uj5ht9tTGKneLQyp96OMUjChZD/T49/p16NJb1u+Jr1xvtAe2lO9K YpC8f4Fbe2Az/zay/G9+Wr1So= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:message-id:date:to:mime-version; q=dns; s= selector1; b=XDphWRbe4FJ2mi5nzDfcWC2W4qI9+C9MinyRuHtuAA+jLzW3na9 Zgm2GzHIWA6XF19IkCvYe2nu3k7gr1lPxgOKknUKUH+UtTin41Vn8zx4niixHFuM zVqkcOv5MdGafiV59FahUFQiQV2QYt9sYGExuqkInf/ABHJ2AvvebX3U= Received: from dhcp-10-61-96-76.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 1B3FF5FBF for ; Sun, 23 Mar 2014 03:46:56 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_E35C2AD4-4774-45E0-944F-0BF9253B3B59"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <65830AFC-9492-410B-BCF6-64C93C8A5125@employees.org> Date: Sun, 23 Mar 2014 11:46:56 +0100 To: efficientnd-dt@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/I1gWSXcexjKxGrwgioNEULFWHTk Subject: [Efficientnd-dt] DAD problems (revision 2) X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 10:47:00 -0000 --Apple-Mail=_E35C2AD4-4774-45E0-944F-0BF9253B3B59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 all, an updated list of DAD problems. 1. Doesn=92t detect duplicate L2 addresses in all cases 2. Fails when L2 port is blocked. Host connected to a switch with STP = enabled (~50 seconds before traffic is allowed) 3. Fails on multicast unreliable links (collision detection requires two = multicast messages to pass through) 4. False positives in case of looped interfaces (solved by enhanced-dad) 5. Introduces delays before an address can be used (Optimistic DAD fixes = that rfc4429) 6. Doesn=92t deal with partition and joining, since detection is only = done on start up. 7. Doesn=92t specify what to do in case of collision in the general = case. CGA, privacy addresses have their own schemes. 8. Requires all nodes to be awake to defend their address 9. Unclear on what a node should do after L2 events / waking up from = sleep 10. DAD is used to build state in the network 11. DAD is used by L2 devices to check if an address is in use (RFC6620) 12. DAD doesn't support multi-link subnets (but the IPv6 architecture = doesn't either). cheers, Ole --Apple-Mail=_E35C2AD4-4774-45E0-944F-0BF9253B3B59 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTLrugAAoJEFuJXizso86gDD0IAIjY7Cvhye9ccQgV2ABkfuwS peA4a8vX7tJuL/F1U9DWLZO7gm8gIcgR1wgt798uNA/FoaU/f7fLIPnDC0xHkdBv 2VP7V3c/MmKS07a1IoVDKOpu7Kw0ZbwBSiUppQCHsOIQAGve2kke1urMFS/xqMuY 8GnB44UFKhXlHtg9nX7yShooCM5fmJN9NkVZYCbZLOI6Kobkwz712TQN7kYBvgV8 CQGrCrNL3m5H4u2V4ZRPQBn3CpOmAG0p4u3Iw4LEUmhzo7AzhcQ8VVTz9xckma8Y B2XsJwrUfTIwOsNexqZvriuAzNQcDtoOjpWchPmBPYdwY9JmM0WXu+eGdbdG9nY= =WxZ/ -----END PGP SIGNATURE----- --Apple-Mail=_E35C2AD4-4774-45E0-944F-0BF9253B3B59-- From nobody Sun Mar 23 06:55:49 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1671A6FB2 for ; Sun, 23 Mar 2014 06:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Z4SgQhlZShsO for ; Sun, 23 Mar 2014 06:55:45 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 225441A0468 for ; Sun, 23 Mar 2014 06:55:45 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 9CAB06061; Sun, 23 Mar 2014 06:55:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=tCnt+4xysW79utJkOA4RK aW4bfk=; b=TBNEgP4eAwnFkVRwwKSWD40UQXNshbpHSQElaGKJ+p0pnKa+zmIya BJPY5BTz3IIgmTwGRocanE9tQgkywj59+yobY24tJkID7xVUuTbj1FSJ9Ev+7jcL wV3mFL5xopAuMs+gy/W6/Zd0LiAG58Y5S6yK1bhyu+6T19B5CpTFYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=lEcIXBvNJx8pP1n KR0Q2QTC32uulDbMPed+8797Vlt87Zr0h7yHWss5voyvzsls8qztk5ABx5c9CPOD EzYkktlBv4LwrvYoK2xpJ3J43s9aEmikvimrWd+PQzCmCCu2rqvS/1KnskcI4Tq+ dXQNhcwY/gaHPcUeGYGAg0lw9dok= Received: from dhcp-10-61-96-176.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 2CB146072; Sun, 23 Mar 2014 06:55:41 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_63A10E32-D603-4329-8DE1-C9AC2DF40341"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ole Troan In-Reply-To: Date: Sun, 23 Mar 2014 14:55:42 +0100 Message-Id: References: To: "Eric Levy- Abegnoli (elevyabe)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/_1dtnfSXdMpA5mctGOn7NSLlEx8 Cc: "efficientnd-dt@ietf.org" Subject: [Efficientnd-dt] RFC6620 use of DAD (was: Re: DAD problems) X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 13:55:47 -0000 --Apple-Mail=_63A10E32-D603-4329-8DE1-C9AC2DF40341 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Eric, > Vendor sauce is mostly rfc6620: (Used by the network to build state). > You can add: > rfc6620: used by switches to poll devices for checking an address in = use. > DAD is used because this is the only query that does not need a source > address (unlike NUD or NS-lokkup). This is problematic because it can = get > confused by the the target as "my address is a duplicate. I've tried to read RFC6620, but I'm still far from understanding the = implications of how 6620 uses ND. e.g. if a FCFS switch misses the DAD message, what happens? does it = build state based on DAD? cheers, Ole --Apple-Mail=_63A10E32-D603-4329-8DE1-C9AC2DF40341 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTLufeAAoJEFuJXizso86gzsYH/2PCD/zoS9W08w4h/ZR20mOH GqJ6g77JwWMN/K8/keXr+fWZhne1a3h7xddLMh6k2lA5erVuJGVGIG6ZGoCFGfa8 tZ9SmJxCMiKcdjuYviZ3TqF21s4K1AE3CYmZx3Ky9B+YpPHYZJTgL3sFdGM4BNbq 437nv2miQQFq+j0ax7EpKP2qGBr4LQMopu1dp0TuE827yI/er2OwR63fyhqyr8o8 k0dAwVaOuXeTuP1a8CFKsfwACir7EUcLaIy0jlJXcp1gpAptv6DOu1uIiQcTPYPX dbBUeY/i8+n0OqziygFDtxfXkwVUzGpj+5G4PV10qHdUirPtech2OpXA1oU4FqQ= =QScD -----END PGP SIGNATURE----- --Apple-Mail=_63A10E32-D603-4329-8DE1-C9AC2DF40341-- From nobody Sun Mar 23 22:25:43 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E711A00ED for ; Sun, 23 Mar 2014 22:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 nKhNquL90AHZ for ; Sun, 23 Mar 2014 22:25:40 -0700 (PDT) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id 969091A0055 for ; Sun, 23 Mar 2014 22:25:40 -0700 (PDT) Received: from [10.0.1.68] (184-23-158-127.dsl.dynamic.sonic.net [184.23.158.127]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s2O5P5kF020344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 23 Mar 2014 22:25:13 -0700 Message-ID: <532FC1AF.1080900@sonic.net> Date: Sun, 23 Mar 2014 22:25:03 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ole Troan , "Eric Levy- Abegnoli (elevyabe)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;hL0iqBSz4xG6iLRWCY+HFQ== M;sgsRrBSz4xG6iLRWCY+HFQ== Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/EVRYjvnPKjCsJdV-wHyZ6-Qup8Q Cc: "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] RFC6620 use of DAD X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 05:25:42 -0000 On 3/23/14 6:55 AM, Ole Troan wrote: > Eric, > >> Vendor sauce is mostly rfc6620: (Used by the network to build state). >> You can add: >> rfc6620: used by switches to poll devices for checking an address in use. >> DAD is used because this is the only query that does not need a source >> address (unlike NUD or NS-lokkup). This is problematic because it can get >> confused by the the target as "my address is a duplicate. > I've tried to read RFC6620, but I'm still far from understanding the implications of how 6620 uses ND. > e.g. if a FCFS switch misses the DAD message, what happens? does it build state based on DAD? In that case the SAVI is triggered by receiving any IPv6 packet with an unknown IPv6 source address. Erik > > cheers, > Ole > > > > _______________________________________________ > Efficientnd-dt mailing list > Efficientnd-dt@ietf.org > https://www.ietf.org/mailman/listinfo/efficientnd-dt From nobody Mon Mar 24 06:57:09 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8AB1A0214 for ; Mon, 24 Mar 2014 06:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.511 X-Spam-Level: X-Spam-Status: No, score=-8.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no 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 lMmR0_Tia_C0 for ; Mon, 24 Mar 2014 06:57:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id CEE461A0211 for ; Mon, 24 Mar 2014 06:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5605; q=dns/txt; s=iport; t=1395669425; x=1396879025; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ifyT7dBm5QGeH2kZ8LpZ3CLEFE2TLFxPT7KdsaaWPC0=; b=fLuEZh3cq4B0NmEu3/IA8abysJ059zwNOiR99CUQ00LZKKA4jmZFQiK0 CdwnRzmRojtfdgLXnQa/Zvl7FK3JRbyC2oyE2XtylibAT+Ss5v/VmEX++ JO2+TrViuppDbu/wugS6PvK04UsdRw/5AwWDy7KBD9NoyItbExrBYtKEv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAMM4MFOtJV2c/2dsb2JhbABZgwaBEsJygRYWdIIlAQEBBDo/DAQCAQgOAwEDAQELFAkHMhQDBggCBA4FCBECh17OIxeOSTEHBoMegRQBA6p7gy2CKw X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208";a="29876364" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 24 Mar 2014 13:57:04 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2ODv4Ho031490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 13:57:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.208]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 08:57:04 -0500 From: "Pascal Thubert (pthubert)" To: Ole Troan Thread-Topic: The larger problem (was Re: [Efficientnd-dt] DAD problems) Thread-Index: AQHPRoPhRLDZP6iCC0KcDNGdiQ9Wq5rwN6ig Date: Mon, 24 Mar 2014 13:57:02 +0000 Deferred-Delivery: Mon, 24 Mar 2014 13:57:00 +0000 Message-ID: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> <9C4C892A-1241-4A99-9E74-43DEECF71D26@employees.org> In-Reply-To: <9C4C892A-1241-4A99-9E74-43DEECF71D26@employees.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/dqi7nAZKpzY3Xru6getWg6BECio Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] The larger problem (was Re: DAD problems) X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 13:57:07 -0000 Hello Ole: Basically the multilink subnet approach that we have in large scale WSN is = dictated by the use case we cover.=20 We use ND proxy, which is an interesting technique when: - the direct L2 connectivity is not at all possible, e.g. MAC64 to Ethernet= ,=20 - or not *always* possible, e.g. mobile or sleeping device.=20 In an architecture with a federating backbone we found that: - ND as it stands is effectively a great protocol for adhoc node/address di= scovery over one hop iff multicast is affordable over the backbone - ND's operation compares to that of AODV if used in similar circumstances = - but for the mobile aspect - ND lacks the capability to handle movement, just like non MANET routing p= rotocols (say BGP, ISIS, OSPF) would if used as alternate, no magic there. The problems we found show up as soon as you have a state in the network th= at might interact with the DAD operation, IOW that also uses DAD flows for = its own purpose asynchronously to the device itself: - the device may be misled when receiving a DAD from a proxy. Is that 2 nod= es fighting for a same address or 2 messages that are ultimately about the = same node? - Exclusive state owner cannot resolve a collision. Which is the SAVI switc= h/proxy that the device is effectively attached to / relying upon? We have such state in the network in DAD proxy, MIPv6/NEMO, SAVI, LISP... P= ractice has gone way beyond experimental. In summary, when it appears through DAD that there are 2 states in the netw= ork, ND as it stands cannot determinate:=20 a) if the states are about the same node or not, and=20 b) if states are exclusive, which is the correct one.=20 It seems to me that the loopback DAD is a subset of a).=20 We found we can solve with a) and b) with a quick and simple logic if we a= dd simple option in ND with=20 1) a UID ala DHCP and=20 2) a sequence counter ala RPL/AODV=20 This approach conserves the ND flows over the backbone and appears a lot si= mpler to implement and deploy than adding to the picture a limitation like = non-onlink or an alternate routing protocol (a MANET or a modified routing = protocol) that would have to be deployed on the backbone. When I consider your long list of DAD problems, it seems to me that these a= re not necessarily the problems per se, but sometimes environments or use c= ases where DAD as it stands does not fully and efficiently perform its task= . My lists boils down to: a) and b) above plus c) sensitive to frame loss multicast / lossy environment=20 d) expensive in environments where multicast is not efficient eg 802.11=20 e) unfeasible in constrained environments with no multicast support, e.g. 8= 02.15.4 f) incompatible with non-persistent connectivity e.g. sleeping or mobile de= vices a) and b) drive the content of the ARO option, and e) lead to RFC 6775 but = can be leveraged for c), d) and f) . All in all, it appears to me that WiND (efficient ND) is a rather low cost = extension to ND WRT the problems that it solves... Cheers, Pascal > -----Original Message----- > From: Ole Troan [mailto:otroan@employees.org] > Sent: dimanche 23 mars 2014 11:37 > To: Pascal Thubert (pthubert) > Cc: Eric Levy- Abegnoli (elevyabe); efficientnd-dt@ietf.org > Subject: The larger problem (was Re: [Efficientnd-dt] DAD problems) >=20 > Pascal, >=20 > I've created a new thread for this discussion as it isn't directly relate= d to > immediate problems with DAD. >=20 > > The nonce is not a UID; the draft helps for the immediate loopback prob= lem > but not for the delayed one, e.g. a proxy. > > > > The difference is that the UID: > > * has a longer life. The node must be able to save it or reconstruct it= as long as > it exists as a state in the network. > > * is expected to have more properties than a nonce, e.g. more likely to= be > unique or harder to forge (CGA). >=20 > the nonce is defined in rfc3971 >=20 > > Same problem as 4862: the solution works but the problem space that is > envisioned is too narrow, so it will need more patching soon. How many st= eps > do we want to take? >=20 > Pascal, you are many steps ahead of us (at least me :-)). I wouldn't be s= urprised > to learn that your solution is the correct one, but I would dearly like t= o > understand the logical steps that took you to it. > - what problems are you trying to solve? > - what led you t conclude that you need multilink-subnets? > - what are you thinking of using DAD for? that doesn't appear to be dire= ctly > related to detection of duplicate addresses? > - what are the purpose and benefits for "classic" IPv6 hosts? >=20 > > I understand that we cannot work on problems that we imagine we may hav= e, > but here we are talking about clear and present issues in existing RFCs a= nd > deployments. > > > > This time I'll follow Lorenzo's wisdom. Overloading the nonce option ca= n only > take use so far, as opposed to designing a new option that covers the nee= ds that > are identified today. We know that those needs can be covered by a UID an= d a > TID. >=20 > I'm not against working on multi-link subnets or solving the problem of d= uplicate > address detection in multi-link subnets. there are other more pressing pr= oblems > with multi-link subnets than DAD though. the DAD problem can be simply so= lved. > if every node picks a random iid out of a 2^64 space, I'm happy to take a= ll the > support calls myself for the cases of actual duplicates. ;-) >=20 > cheers, > Ole From nobody Tue Mar 25 02:08:25 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19ED1A03B9 for ; Tue, 25 Mar 2014 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.011 X-Spam-Level: X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 ueunMECI9EPC for ; Tue, 25 Mar 2014 02:08:22 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 278AF1A0369 for ; Tue, 25 Mar 2014 02:08:22 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 3688C60C2; Tue, 25 Mar 2014 02:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=selector1; bh=fGTJtUOgzacSWI6BBQyrf i5sork=; b=Nk2093P4JKst8pgaOyuOZB+pI/YH9tzyw+ibzERAx6iHZhJXSavpP Yaj5ixJWRZI1pHdjrNITsRhb3/IkjupAFuOQ0ujHtzJdqE8Ry9e2xueTVVZler65 XKBQZeFKhSb8UvK1v7ca31ciETM7lVoDYB7YljZPvyopn54tqPVnoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; q=dns; s=selector1; b=BPVTvjePveNpSvJ HJ+g0eUeyuHISYUN6NPWAPGWBrG7RrWQyPgvnSIs9LT9kaP33ijuLnU+iTsAh9gz OVb8ax7JagfmJOd1bYzjYfWDcP8Mg41MPK9oCFbThQFM9HudVCyiP7j2PwCyBZk7 C8XnmcG/DSr3GUH/OfrSw19HxfUk= Received: from dhcp-lys01-vla250-10-147-112-204.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 23E2760AC; Tue, 25 Mar 2014 02:08:18 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1597EB12-2F61-4146-B971-076228DE25FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ole Troan In-Reply-To: Date: Tue, 25 Mar 2014 10:08:17 +0100 Message-Id: References: <2B4641D7-A7B7-4A07-AA3B-7D056BB9606A@employees.org> <71D753A9-35FB-485E-96C6-4D49E506DBEE@employees.org> <9C4C892A-1241-4A99-9E74-43DEECF71D26@employees.org> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/3eBQhBg3cJZJeX8ubn7MyaYCMIQ Cc: "Eric Levy- Abegnoli \(elevyabe\)" , "efficientnd-dt@ietf.org" Subject: Re: [Efficientnd-dt] The larger problem (was Re: DAD problems) X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 09:08:23 -0000 --Apple-Mail=_1597EB12-2F61-4146-B971-076228DE25FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Pascal, > Basically the multilink subnet approach that we have in large scale = WSN is dictated by the use case we cover.=20 >=20 > We use ND proxy, which is an interesting technique when: > - the direct L2 connectivity is not at all possible, e.g. MAC64 to = Ethernet,=20 > - or not *always* possible, e.g. mobile or sleeping device.=20 I'm still not sure I understand the use case for MLSR / ND proxy? could you elaborate? why MLSR instead of normal subnets? the RFC4389 ND proxy only works in very specific cases, I don't think we = want to restrict all IPv6 subnets to those very limited topologies. or = are you talking about a different ND proxy? > In an architecture with a federating backbone we found that: > - ND as it stands is effectively a great protocol for adhoc = node/address discovery over one hop iff multicast is affordable over the = backbone > - ND's operation compares to that of AODV if used in similar = circumstances - but for the mobile aspect > - ND lacks the capability to handle movement, just like non MANET = routing protocols (say BGP, ISIS, OSPF) would if used as alternate, no = magic there. >=20 > The problems we found show up as soon as you have a state in the = network that might interact with the DAD operation, IOW that also uses = DAD flows for its own purpose asynchronously to the device itself: > - the device may be misled when receiving a DAD from a proxy. Is that = 2 nodes fighting for a same address or 2 messages that are ultimately = about the same node? > - Exclusive state owner cannot resolve a collision. Which is the SAVI = switch/proxy that the device is effectively attached to / relying upon? > We have such state in the network in DAD proxy, MIPv6/NEMO, SAVI, = LISP... Practice has gone way beyond experimental. >=20 > In summary, when it appears through DAD that there are 2 states in the = network, ND as it stands cannot determinate:=20 > a) if the states are about the same node or not, and=20 > b) if states are exclusive, which is the correct one.=20 > It seems to me that the loopback DAD is a subset of a).=20 I take it you aren't talking about DAD as for "duplicate address = detection", but DAD as a mechanism to generate and maintain state in the = network? I think DAD is particularly poorly suited for that... and I'm not sure = that's a practice we should continue. what happens in your cases when the DAD message is lost? > We found we can solve with a) and b) with a quick and simple logic if = we add simple option in ND with=20 > 1) a UID ala DHCP and=20 > 2) a sequence counter ala RPL/AODV=20 >=20 > This approach conserves the ND flows over the backbone and appears a = lot simpler to implement and deploy than adding to the picture a = limitation like non-onlink or an alternate routing protocol (a MANET or = a modified routing protocol) that would have to be deployed on the = backbone. >=20 > When I consider your long list of DAD problems, it seems to me that = these are not necessarily the problems per se, but sometimes = environments or use cases where DAD as it stands does not fully and = efficiently perform its task. My lists boils down to: >=20 > a) and b) above plus > c) sensitive to frame loss multicast / lossy environment=20 > d) expensive in environments where multicast is not efficient eg = 802.11=20 > e) unfeasible in constrained environments with no multicast support, = e.g. 802.15.4 > f) incompatible with non-persistent connectivity e.g. sleeping or = mobile devices >=20 > a) and b) drive the content of the ARO option, and e) lead to RFC 6775 = but can be leveraged for c), d) and f) . > All in all, it appears to me that WiND (efficient ND) is a rather low = cost extension to ND WRT the problems that it solves... I still don't understand the applicability of what you say to classic = IPv6. if I'm the only one lost here I'll shut up, but otherwise I'd really = like you to explain the complete problem (or point to documents). cheers, Ole --Apple-Mail=_1597EB12-2F61-4146-B971-076228DE25FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTMUeBAAoJEFuJXizso86g17kIAIJ6q9xJHTzFrdmVMg/RO8Rb ii23LGTgUVbZjZH/Nhjw8JFS9tD1itSXMcsUjW/ky+eWXK1NRdN2Sc6aJl8X4Gn1 BdcE0JyjfvOT3Z/o3Q+kEIvkEL8w/2SbzUdGikXO+TH7hA0B5MGsZxoe4JVd3sBK yr4Ng9I7gGfH8XZLv6qq/2byJ+L18CiaC1thZXBGInuGLwwW1oKTmrGc6BJwg3HS 4f2t883mC+hqfrQbi+snWez2j0gnfPLDa/ofbYnbsGpnSroLMsjoZH/4CJOyTN57 /WJ4tY4ETRESng+qEynxvmmoa8uVDtYM/sqHPOrF5jIuxXPc27jyhtS9ts8Uu5Q= =Gi2F -----END PGP SIGNATURE----- --Apple-Mail=_1597EB12-2F61-4146-B971-076228DE25FD-- From nobody Mon Mar 31 06:24:02 2014 Return-Path: X-Original-To: efficientnd-dt@ietfa.amsl.com Delivered-To: efficientnd-dt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43951A084B for ; Mon, 31 Mar 2014 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 9-zzYxXZmrA5 for ; Mon, 31 Mar 2014 06:23:57 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) by ietfa.amsl.com (Postfix) with ESMTP id 55C111A084C for ; Mon, 31 Mar 2014 06:23:57 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id E29B760E4 for ; Mon, 31 Mar 2014 06:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:references:to:message-id :mime-version; s=selector1; bh=DUZrlv6DOPUtzGS/z5w3U8ySLVs=; b=m AOB30Wf/xu4xdXRhVOGP8k28psWUDaXDBpqYB2eemQnxNrXvRoODSbftc0JGVgq5 VAV8llGwyc4nt4NnLXX5tW8OsRrcx9tS+SrIRnMm1fBUzMKPVpfs/nFIyPms8V1k qOc3wdlS74Xl+IHCgtFrPBT9LWbdjXJUlH6hE/5C4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:references:to:message-id :mime-version; q=dns; s=selector1; b=KAoeWjl9eCpReQ3/vGa5UUdUX3N K4+XtAf33Cd8M2yCZDFmnKHIEMnlV0TSXWP5qv6B9yZPLKM2juyotuwXJLREamyY lT8o18g9CVZttL0/vB5JmOiNVEK0/lj6y+unz+RkNnbpX8AZyRyE51UvyC+XjdmW GDgNrBECYJtkSCOA= Received: from 122.242.214.82.in-addr.arpa (unknown [82.214.242.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 1FF1F60D2 for ; Mon, 31 Mar 2014 06:23:50 -0700 (PDT) From: Ole Troan Content-Type: multipart/signed; boundary="Apple-Mail=_D30470DF-D92A-4CC1-B264-B571AB307A4F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 31 Mar 2014 15:23:37 +0200 References: <489D13FBFA9B3E41812EA89F188F018E1AF7A8D9@xmb-rcd-x04.cisco.com> To: efficientnd-dt@ietf.org Message-Id: <1A2B0052-146D-46CE-9BC0-359E95F45D90@employees.org> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/efficientnd-dt/3eXzrO40Nb11aIDcP5w-wcoCFF8 Subject: [Efficientnd-dt] Fwd: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - respond by April 13, 2014 X-BeenThere: efficientnd-dt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 6man Efficient ND Design Team discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:24:00 -0000 --Apple-Mail=_D30470DF-D92A-4CC1-B264-B571AB307A4F Content-Type: multipart/alternative; boundary="Apple-Mail=_6C73A29F-FF01-4D01-AC31-B80F30C12145" --Apple-Mail=_6C73A29F-FF01-4D01-AC31-B80F30C12145 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii folks, this may be of interest to you too. cheers, Ole Begin forwarded message: > From: "Bernie Volz (volz)" > Subject: [dhcwg] WGLC for draft-ietf-dhc-addr-registration-04 - = respond by April 13, 2014 > Date: 29 Mar 2014 15:04:22 GMT+1 > To: "dhcwg@ietf.org" > Message-Id: = <489D13FBFA9B3E41812EA89F188F018E1AF7A8D9@xmb-rcd-x04.cisco.com> >=20 > Folks, the authors of draft-ietf-dhc-addr-registration = (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04) > feel it's ready for work group last call. Please review this draft and = indicate whether or not you feel it is ready to be published. > =20 > At the time of this writing, there is no IPR reported against this = draft. > =20 > Tomek and I will evaluate consensus after April 13, 2014. > =20 > Thanks, > Bernie & Tomek > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_6C73A29F-FF01-4D01-AC31-B80F30C12145 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii folks,

this may be of interest to = you = too.

cheers,
Ole

Begin= forwarded message:

From: "Bernie Volz (volz)" <volz@cisco.com>
Subject: [dhcwg] WGLC for = draft-ietf-dhc-addr-registration-04 - respond by April 13, = 2014
Date: = 29 Mar 2014 15:04:22 = GMT+1
Message-Id: <489D13FBFA9B3E41812EA89F188F018E1AF7A8D9@xmb-rcd-x04.cisco.com>= ;

Folks, the authors of draft-ietf-dhc-addr-registration (http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-04= )
feel it's ready for work group = last call. Please review this draft and indicate whether or not you feel = it is ready to be published.
 
At the = time of this writing, there is no IPR reported against this = draft.
 
Tomek and = I will evaluate consensus after April 13, 2014.
 
Thanks,
Bernie = & Tomek
 
________________________________= _______________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

= --Apple-Mail=_6C73A29F-FF01-4D01-AC31-B80F30C12145-- --Apple-Mail=_D30470DF-D92A-4CC1-B264-B571AB307A4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTOWxZAAoJEFuJXizso86gkAAIAJe2I4N0s8VDnun0z3QbqCwb ofR2ux4se/vuvDW8EWpcJWQi5XI+6zGO0aGIUvP4Kln/avt2RshCzYUyN5QyXocR rm/HlInQvuq6FoNgvOYPz/qb/cOwwOSfRKDTStdamLKiRp1razMQrif3+xApDWEL LqzWD9ed5W6SNLzCwIjv2VLz/CA8qADdo+y+Jpmpb6U3DY7Xfi5/m9Ik/g9OTQjZ VMULEgx5Rj9g1784n560K1W0cHZ7OD96c6tvEpclstFxKo5UAmgyjV4lZc0C/330 kWslG+q9sc+mGRirOYXdYRruU2nrVmoYKT4Ic+blp36qUFHv+3gziTtL8otQO+M= =4Y6S -----END PGP SIGNATURE----- --Apple-Mail=_D30470DF-D92A-4CC1-B264-B571AB307A4F--