From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 11 21:18:57 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06204 for ; Wed, 11 Aug 2004 21:18:56 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LDKPHWYPJO8X1IPC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 Aug 2004 11:15:28 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id A627580038; Thu, 12 Aug 2004 11:15:00 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by larry.its.monash.edu.au (Postfix) with ESMTP id 501BF3C010; Thu, 12 Aug 2004 11:15:00 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7C1DfE21971 for dna-list; Thu, 12 Aug 2004 11:13:41 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7C1Dch21965 for ; Thu, 12 Aug 2004 11:13:38 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LDKPG092X48X1PTE@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 12 Aug 2004 11:13:31 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5B9D1AB542; Thu, 12 Aug 2004 11:13:28 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by curly.its.monash.edu.au (Postfix) with ESMTP id 34B5E4FB14; Thu, 12 Aug 2004 11:13:28 +1000 (EST) Date: Thu, 12 Aug 2004 11:13:28 +1000 From: Greg Daley Subject: One Week Consensus call on L2 hint/notification Terminology Re: [DNA] L2 notifications Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin Cc: dna@eng.monash.edu.au, "'Bernard Aboba'" , Pekka Nikander Reply-to: greg.daley@eng.monash.edu.au Message-id: <411AC438.70200@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <014901c47ff0$60296260$9b1d9069@sisa.samsung.com> Content-Transfer-Encoding: 7BIT Hi, Just to place a boundary on the time, I'd like to ask that people with comments on the terminology do so before 01:00 UTC on the 19th of August. I invite those who have opinions (even those who expressed their opinions in the session) to indicate them during this period. Greg Alper Yegin wrote: > This is an attempt to re-iterate the consensus we reached at the DNA > IETF60 meeting regarding L2-L3 interaction discussions. Please register > your opinion, otherwise we'll update the dna-l2-hints (name subject to > change :-) accordingly and move it forward. > > Here we go: > > "Link up" and "link down" events are conveyed to L3 via so-called > "link-layer event notifications". As part of this notification, in > addition to the event type, optional information associated with the > event can be provided. Specific to the link-type, this may be an IP > address (e.g., PPP [IPv4] with cdma2000, or PDP with GPRS), remote > interface identifier (e.g., PPP [IPv6] with cdma2000), or BSSID/SSID > (IEEE 802.11). > > A L2 event notification and the associated information may be used as a > "hint" by their consumers (e.g., DNA) depending on the context they are > used, but this is very much consumer specific. So, downgrading them to > "hints" is fine in DNA solution space, but this should not be the > characterization as the information is generated and delivered to the > consumer. > > Additionally we should add IEEE 802.3 to the I-D, for which volunteers > are sought to provide text for.... Please follow this up in a separate thread. Greg From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 11 21:32:29 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06768 for ; Wed, 11 Aug 2004 21:32:27 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDKQ0VJKQY8Y4X5I@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 12 Aug 2004 11:29:36 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CE30AAB546; Thu, 12 Aug 2004 11:29:30 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by curly.its.monash.edu.au (Postfix) with ESMTP id 449C14FB7A; Thu, 12 Aug 2004 11:29:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7C1TNs22205 for dna-list; Thu, 12 Aug 2004 11:29:23 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7C1TMh22201 for ; Thu, 12 Aug 2004 11:29:23 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDKQ0DWCY88WVZCB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 12 Aug 2004 11:29:07 +1000 Received: by localhost (Postfix, from userid 510) id 3815BAB544; Thu, 12 Aug 2004 11:29:07 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by moe.its.monash.edu.au (Postfix) with ESMTP id 402964FB03 for ; Thu, 12 Aug 2004 11:29:06 +1000 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2B00HEA7YO7S@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 12 Aug 2004 10:25:36 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2B00GX27WH7G@mailout1.samsung.com> for dna@eng.monash.edu.au; Thu, 12 Aug 2004 10:24:17 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2B00F2E7WG54@mmp1.samsung.com> for dna@eng.monash.edu.au; Thu, 12 Aug 2004 10:24:17 +0900 (KST) Date: Thu, 12 Aug 2004 10:25:21 +0900 From: "S. Daniel Park" Subject: RE: [DNA] L2 notifications In-reply-to: <014901c47ff0$60296260$9b1d9069@sisa.samsung.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: Alper Yegin , dna@eng.monash.edu.au Cc: "'Bernard Aboba'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) Content-Transfer-Encoding: 7BIT - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: owner-dna@ecselists.eng.monash.edu.au > [mailto:owner-dna@ecselists.eng.monash.edu.au]On Behalf Of Alper Yegin > Sent: Thursday, August 12, 2004 7:13 AM > To: dna@eng.monash.edu.au > Cc: 'Bernard Aboba' > Subject: [DNA] L2 notifications > > > > This is an attempt to re-iterate the consensus we reached at the DNA > IETF60 meeting regarding L2-L3 interaction discussions. Please register > your opinion, otherwise we'll update the dna-l2-hints (name subject to > change :-) accordingly and move it forward. > > Here we go: > > "Link up" and "link down" events are conveyed to L3 via so-called > "link-layer event notifications". As part of this notification, in > addition to the event type, optional information associated with the > event can be provided. Specific to the link-type, this may be an IP > address (e.g., PPP [IPv4] with cdma2000, or PDP with GPRS), remote > interface identifier (e.g., PPP [IPv6] with cdma2000), or BSSID/SSID > (IEEE 802.11). > > A L2 event notification and the associated information may be used as a > "hint" by their consumers (e.g., DNA) depending on the context they are > used, but this is very much consumer specific. So, downgrading them to > "hints" is fine in DNA solution space, but this should not be the > characterization as the information is generated and delivered to the > consumer. > > Additionally we should add IEEE 802.3 to the I-D, for which volunteers > are sought to provide text for.... > > Cheers, > > Alper > > > > > From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 19 02:23:08 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04395 for ; Thu, 19 Aug 2004 02:23:06 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUS89A1ME8WX61P@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 Aug 2004 16:20:54 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id D3B8EAB54A; Thu, 19 Aug 2004 16:20:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by moe.its.monash.edu.au (Postfix) with ESMTP id 659614FB11; Thu, 19 Aug 2004 16:20:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7J6JQl32521 for dna-list; Thu, 19 Aug 2004 16:19:26 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7J6JMh32517 for ; Thu, 19 Aug 2004 16:19:23 +1000 Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUS6I82I08WX610@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 19 Aug 2004 16:19:15 +1000 Received: by localhost (Postfix, from userid 510) id 604DAAB545; Thu, 19 Aug 2004 16:19:14 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id A448F4FB09; Thu, 19 Aug 2004 16:19:13 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2O00A4TK7Y0T@mailout3.samsung.com>; Thu, 19 Aug 2004 15:19:10 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2O00LDFK780I@mailout3.samsung.com>; Thu, 19 Aug 2004 15:18:45 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2O007OSK782W@mmp1.samsung.com>; Thu, 19 Aug 2004 15:18:44 +0900 (KST) Date: Thu, 19 Aug 2004 15:18:44 +0900 From: JinHyeock Choi Subject: [DNA] Issue 1: Remove the second part of Abstract Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au, Jari Arkko , JinHyeock Choi Message-id: <014f01c485b4$615feae0$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_Kysx3d0x8OcT+XL08PJ/rQ)" X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) This is a multi-part message in MIME format. --Boundary_(ID_Kysx3d0x8OcT+XL08PJ/rQ) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 1 Jim Bound proposed to remove the second part of Abstract. * This may necessitate the rewriting of Abstract. Suggested resolution: We rephrased the Abstract as belows. Abstract At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. During link identity detection, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment (DNA). DNA schemes should be 1) precise, 2) sufficiently fast and 3) of limited signaling. Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks for Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock --Boundary_(ID_Kysx3d0x8OcT+XL08PJ/rQ) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT
Dear DNA WG
 
This is an attempt to resolve this issue:
 
Issue 1
Jim Bound proposed to remove the second part of Abstract.
* This may necessitate the rewriting of Abstract.
 
Suggested resolution: We rephrased the Abstract as belows.
 
Abstract
 
At the time a host establishes a new link-layer connection, it may or
may not have a valid IP configuration for Internet connectivity. The
host may check for link change, i.e. determine whether a link change
has occurred, and then, based on the result, it can automatically
decide whether its IP configuration is still valid or not. During
link identity detection, the host may also collect necessary information
to initiate a new IP configuration for the case that the IP subnet has
changed. In this memo, this procedure is called Detecting Network
Attachment (DNA). DNA schemes should be 1) precise, 2) sufficiently
fast and 3) of limited signaling.
 
Please register your opinion if you have any comments, otherwise
we'll update the goals draft accordingly and move it forward.
 
Thanks for Greg's kind work, we now have the issue list at 
 
 
Thanks for your kind consideration.
 
Best Regards
 
JinHyeock 
--Boundary_(ID_Kysx3d0x8OcT+XL08PJ/rQ)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 19 02:44:17 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05776 for ; Thu, 19 Aug 2004 02:44:16 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LDUSSLH2WK8YDMWD@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 Aug 2004 16:37:58 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 04F2380009; Thu, 19 Aug 2004 16:37:03 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by larry.its.monash.edu.au (Postfix) with ESMTP id A2FCD3C00C; Thu, 19 Aug 2004 16:37:02 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7J6auc32621 for dna-list; Thu, 19 Aug 2004 16:36:56 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7J6ath32617 for ; Thu, 19 Aug 2004 16:36:55 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUSS91ZY48Y57CG@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 19 Aug 2004 16:36:47 +1000 Received: by localhost (Postfix, from userid 510) id 7E91E80002; Thu, 19 Aug 2004 16:36:46 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id C35A53C015; Thu, 19 Aug 2004 16:36:45 +1000 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2O00J0EL15X4@mailout1.samsung.com>; Thu, 19 Aug 2004 15:36:41 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2O001F9L14TP@mailout1.samsung.com>; Thu, 19 Aug 2004 15:36:41 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2O007G8L142W@mmp1.samsung.com>; Thu, 19 Aug 2004 15:36:40 +0900 (KST) Date: Thu, 19 Aug 2004 15:36:39 +0900 From: JinHyeock Choi Subject: [DNA] Issue2: Remove Section 2 - DNA in existing systems Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au, Jari Arkko , JinHyeock Choi Message-id: <016c01c485b6$e263f440$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: multipart/alternative; boundary="Boundary_(ID_rwOyi8qXMSNxxIpE02VTZw)" X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) This is a multi-part message in MIME format. --Boundary_(ID_rwOyi8qXMSNxxIpE02VTZw) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 2 Jim Bound proposed to remove Section 2. Detecting Network Attachment in Existing IPv6 Systems Suggested resolution We will remove the Sec 2 from the Goals draft. At San Diego meeting, WG agreed to remove Sec 2 from the Goals draft (and, if needed, moved them to BCP draft.). Please register your opinion if you have any comments, otherwise we'll update the Goals draft accordingly and move it forward. Thanks for Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock --Boundary_(ID_rwOyi8qXMSNxxIpE02VTZw) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT
Dear DNA WG
 
This is an attempt to resolve this issue:
 
Issue 2
Jim Bound proposed to remove
Section 2. Detecting Network Attachment in Existing IPv6 Systems
 
Suggested resolution 
 
We will remove the Sec 2 from the Goals draft. 
 
At San Diego meeting, WG agreed to remove Sec 2 from the Goals draft
(and, if needed, moved them to BCP draft.).
 
Please register your opinion if you have any comments, otherwise
we'll update the Goals draft accordingly and move it forward.
 
Thanks for Greg's kind work, we now have the issue list at
 
http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals
 
Thanks for your kind consideration.
 
Best Regards
 
JinHyeock 
--Boundary_(ID_rwOyi8qXMSNxxIpE02VTZw)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 19 03:57:39 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10550 for ; Thu, 19 Aug 2004 03:57:37 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUVFXZD928WX6G3@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 Aug 2004 17:53:14 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C05FAB545; Thu, 19 Aug 2004 17:53:08 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by curly.its.monash.edu.au (Postfix) with ESMTP id D0F614FB0F; Thu, 19 Aug 2004 17:53:07 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7J7qpr00627 for dna-list; Thu, 19 Aug 2004 17:52:51 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7J7qmh00619 for ; Thu, 19 Aug 2004 17:52:48 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LDUVF6UT108ZDZ0V@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 19 Aug 2004 17:52:32 +1000 Received: by localhost (Postfix, from userid 510) id 2B871AB542; Thu, 19 Aug 2004 17:52:32 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id 08D0C4FB09; Thu, 19 Aug 2004 17:52:31 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2O00EHDOJH58@mailout3.samsung.com>; Thu, 19 Aug 2004 16:52:29 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2O00LSQOGS50@mailout3.samsung.com>; Thu, 19 Aug 2004 16:50:53 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2O00IQMOGS7P@mmp1.samsung.com>; Thu, 19 Aug 2004 16:50:52 +0900 (KST) Date: Thu, 19 Aug 2004 16:50:52 +0900 From: JinHyeock Choi Subject: [DNA] Issue 3: Remove Subsection 3.2 - Inadequacies in RA information Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au, Jari Arkko , JinHyeock Choi Message-id: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: MULTIPART/ALTERNATIVE; BOUNDARY="Boundary_(ID_JeZV/Y4r4VyBAHp/aiIxHQ)" X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) This is a multi-part message in MIME format. --Boundary_(ID_JeZV/Y4r4VyBAHp/aiIxHQ) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 3 Jim Bound proposed to remove Sub-sec 3.2. Inadequacies in RA information Suggested resolution At San Diego meeting, WG agreed to remove Sub-sec 3.2, so we reduced Sub-sec 3.2 to just present the difficulty for a single RA message to indicate a link change. We propose to change Sub-sec 3.2 (after we remove Sec 2, this will be Sub-sec 2.2) as below. 3.2 Link identity detection with a single RA Usually a host gets the information necessary for IP configuration from RA messages. Based on the current definition [ND], it's difficult for a host to check for link change upon a single RA reception. To detect link identity, a host may compare the informations in an RA, for example router address or prefixes, with the existing ones. The host may use a router address to check for link change. But the router address in the source address field of an RA is link-local scope, so its uniqueness is not guaranteed out side of a link. So if it happens that two different router interfaces have the same link-local address, the host can't detect that it has moved from one interface to another by checking the router address in RA messages. Or the host may check whether an incoming RA includes the currently stored prefix. But an unsolicited RA message can omit some prefixes for convenience [4]. Hence, the host can't be sure that the existing prefix is not supported on the currently attached link, even though the prefix is not contained in a received RA. The set of all the global prefixes assigned to a link can represent a link identity. But it's not easy for a host to attain and retain all the prefixes with certainty, so the prefix list based DNA scheme needs further investigation [CPL]. Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks to Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock --Boundary_(ID_JeZV/Y4r4VyBAHp/aiIxHQ) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT
Dear DNA WG
 
This is an attempt to resolve this issue:
 
Issue 3
Jim Bound proposed to remove
Sub-sec 3.2. Inadequacies in RA information
 
Suggested resolution 
 
At San Diego meeting, WG agreed to remove Sub-sec 3.2, so we reduced
Sub-sec 3.2 to just present the difficulty for a single RA message to
indicate a link change. We propose to change Sub-sec 3.2 (after we remove
Sec 2, this will be Sub-sec 2.2) as below.
 
 
3.2  Link identity detection with a single RA
 
Usually a host gets the information necessary for IP configuration
from RA messages. Based on the current definition [ND], it's difficult
for a host to check for link change upon a single RA reception.
 
To detect link identity, a host may compare the informations in an RA,
for example router address or prefixes, with the existing ones. 
 
The host may use a router address to check for link change. But the
router address in the source address field of an RA is link-local
scope, so its uniqueness is not guaranteed out side of a link. So if it
happens that two different router interfaces have the same link-local
address, the host can't detect that it has moved from one interface
to another by checking the router address in RA messages.
 
Or the host may check whether an incoming RA includes the currently
stored prefix. But an unsolicited RA message can omit some prefixes
for convenience [4]. Hence, the host can't be sure that the existing
prefix is not supported on the currently attached link, even though the
prefix is not contained in a received RA.
 
The set of all the global prefixes assigned to a link can represent a link
identity. But it's not easy for a host to attain and retain all the prefixes
with certainty, so the prefix list based DNA scheme needs further
investigation [CPL].
 
 
Please register your opinion if you have any comments, otherwise
we'll update the goals draft accordingly and move it forward.
 
Thanks to Greg's kind work, we now have the issue list at
 
http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals
 
Thanks for your kind consideration.
 
Best Regards
 
JinHyeock 
 
 
--Boundary_(ID_JeZV/Y4r4VyBAHp/aiIxHQ)-- From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 19 04:23:06 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11929 for ; Thu, 19 Aug 2004 04:23:05 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUWHHTLHQ8WX6O5@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 Aug 2004 18:22:41 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 05DE9AB54A; Thu, 19 Aug 2004 18:22:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7357B4FB02; Thu, 19 Aug 2004 18:22:37 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7J8MSi01029 for dna-list; Thu, 19 Aug 2004 18:22:28 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7J8MRh01025 for ; Thu, 19 Aug 2004 18:22:27 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LDUWH02TKK8YDU32@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 19 Aug 2004 18:22:20 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 4146A80005; Thu, 19 Aug 2004 18:22:14 +1000 (EST) Received: from [130.194.252.100] (brettpc.eng.monash.edu.au [130.194.252.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 29DFD3C006; Thu, 19 Aug 2004 18:22:14 +1000 (EST) Date: Thu, 19 Aug 2004 18:22:13 +1000 From: Brett Pentland Subject: Re: [DNA] Issue 3: Remove Subsection 3.2 - Inadequacies in RA information In-reply-to: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <41246335.10703@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk User-Agent: Mozilla Thunderbird 0.7 (X11/20040615) X-Accept-Language: en-us, en References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Hi JinHyeock, JinHyeock Choi wrote: > The set of all the global prefixes assigned to a link can represent a link > identity. But it's not easy for a host to attain and retain all the > prefixes > with certainty, so the prefix list based DNA scheme needs further > investigation [CPL]. This last paragraph seems more like a potential solution than a goal. The set of all the global prefixes assigned to a link can represent a link identity, but there are other ways. I don't think that the goals document should specify this. I would suggest just removing it. Brett. From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 19 04:50:42 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13536 for ; Thu, 19 Aug 2004 04:50:41 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUXG0U28C8WX5Y4@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 Aug 2004 18:50:32 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 413FF80004; Thu, 19 Aug 2004 18:50:28 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by larry.its.monash.edu.au (Postfix) with ESMTP id DE1C13C004; Thu, 19 Aug 2004 18:50:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7J8oIF01215 for dna-list; Thu, 19 Aug 2004 18:50:18 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7J8oHh01211 for ; Thu, 19 Aug 2004 18:50:17 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDUXFILDB68Y57F2@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 19 Aug 2004 18:50:04 +1000 Received: by localhost (Postfix, from userid 510) id CAEF780002; Thu, 19 Aug 2004 18:50:03 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 3FBB13C007; Thu, 19 Aug 2004 18:50:03 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2O00G60R7DXU@mailout3.samsung.com>; Thu, 19 Aug 2004 17:50:01 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2O00LP0R660I@mailout3.samsung.com>; Thu, 19 Aug 2004 17:49:19 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2O00I6NR66OQ@mmp1.samsung.com>; Thu, 19 Aug 2004 17:49:18 +0900 (KST) Date: Thu, 19 Aug 2004 17:49:18 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 3: Remove Subsection 3.2 - Inadequacies in RA information Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Message-id: <023d01c485c9$69f633c0$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <41246335.10703@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT > Hi JinHyeock, > > JinHyeock Choi wrote: > > > The set of all the global prefixes assigned to a link can represent a link > > identity. But it's not easy for a host to attain and retain all the > > prefixes > > with certainty, so the prefix list based DNA scheme needs further > > investigation [CPL]. > > This last paragraph seems more like a potential solution than a goal. > The set of all the global prefixes assigned to a link can represent > a link identity, but there are other ways. I don't think that the > goals document should specify this. I would suggest just removing it. The paragraph is intended to present the limitation of prefix list based approach at current stage. It's not my intention to suggest prefix list based approach as the solution. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 19 06:47:04 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19374 for ; Thu, 19 Aug 2004 06:47:02 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LDV1FGSOGA8YE7N8@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 19 Aug 2004 20:45:05 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 53BB380003; Thu, 19 Aug 2004 20:44:33 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by larry.its.monash.edu.au (Postfix) with ESMTP id 010D03C00A; Thu, 19 Aug 2004 20:44:33 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7JAi3m01855 for dna-list; Thu, 19 Aug 2004 20:44:03 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7JAi1h01851 for ; Thu, 19 Aug 2004 20:44:01 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LDV1EC2ZQK8Y5540@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 19 Aug 2004 20:43:39 +1000 Received: by localhost (Postfix, from userid 510) id 80D4A80002; Thu, 19 Aug 2004 20:43:38 +1000 (EST) Received: from [192.168.1.2] (unknown [202.63.56.112]) (user brett) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by larry.its.monash.edu.au (Postfix) with ESMTP id 3363D3C007; Thu, 19 Aug 2004 20:43:37 +1000 (EST) Date: Thu, 19 Aug 2004 20:43:40 +1000 From: Brett Pentland Subject: Re: [DNA] Issue 3: Remove Subsection 3.2 - Inadequacies in RA information In-reply-to: <023d01c485c9$69f633c0$ed2f024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: dna@eng.monash.edu.au Message-id: <4124845C.3000409@eng.monash.edu.au> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <41246335.10703@eng.monash.edu.au> <023d01c485c9$69f633c0$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: >>Hi JinHyeock, >> >>JinHyeock Choi wrote: >> >> >>>The set of all the global prefixes assigned to a link can represent a link >>>identity. But it's not easy for a host to attain and retain all the >>>prefixes >>>with certainty, so the prefix list based DNA scheme needs further >>>investigation [CPL]. >> >>This last paragraph seems more like a potential solution than a goal. >>The set of all the global prefixes assigned to a link can represent >>a link identity, but there are other ways. I don't think that the >>goals document should specify this. I would suggest just removing it. > > > The paragraph is intended to present the limitation of prefix list based > approach at current stage. It's not my intention to suggest prefix list > based approach as the solution. > The previous paragraph already states that RAs don't necessarily carry a complete list of prefixes. This paragraph seems out of place to me. Brett. From dna-owner@webcamserver.eng.monash.edu.au Mon Aug 23 00:32:29 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23776 for ; Mon, 23 Aug 2004 00:32:27 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE09C42OG48WXROA@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Mon, 23 Aug 2004 14:25:04 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8AAE080003; Mon, 23 Aug 2004 14:24:52 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.136.152]) by larry.its.monash.edu.au (Postfix) with ESMTP id 43FE23C004; Mon, 23 Aug 2004 14:24:52 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7N4NeE32637 for dna-list; Mon, 23 Aug 2004 14:23:40 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7N4Ndh32633 for ; Mon, 23 Aug 2004 14:23:40 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE09AJLQ7U8ZECCG@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Mon, 23 Aug 2004 14:23:37 +1000 Received: by localhost (Postfix, from userid 510) id BAE6AAB54D; Mon, 23 Aug 2004 14:23:36 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by curly.its.monash.edu.au (Postfix) with ESMTP id E16244FB0D; Mon, 23 Aug 2004 14:23:35 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2V00MC9TJAB4@mailout3.samsung.com>; Mon, 23 Aug 2004 13:23:34 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2V00HY5TGX9H@mailout3.samsung.com>; Mon, 23 Aug 2004 13:22:10 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2V009D4TGXNO@mmp2.samsung.com>; Mon, 23 Aug 2004 13:22:09 +0900 (KST) Date: Mon, 23 Aug 2004 13:22:09 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 3: Remove Subsection 3.2 - Inadequacies in RA information Sender: owner-dna@ecselists.eng.monash.edu.au To: Brett Pentland Cc: dna@eng.monash.edu.au Message-id: <015801c488c8$c1d31750$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <41246335.10703@eng.monash.edu.au> <023d01c485c9$69f633c0$ed2f024b@jinchoe> <4124845C.3000409@eng.monash.edu.au> Content-Transfer-Encoding: 7BIT Dear Brett Thanks for your helpful feedback that clarified my thoughts. > > The paragraph is intended to present the limitation of prefix list based > > approach at current stage. It's not my intention to suggest prefix list > > based approach as the solution. > > > The previous paragraph already states that RAs don't necessarily carry a > complete list of prefixes. This paragraph seems out of place to me. 'Omission of prefix' is not the only limitation of prefix based approach. Moreover I found that 'the omission of prefix' is about not so much 'detect link identity' as 'validate IP address'. So I incorporate the last two paragraphs to update the 3.2. as below. Kindly give your opinions. Best Regards JinHyeock ------------------------------------------------------------------------ 3.2 Link identity detection with a single RA Usually a host gets the information necessary for IP configuration from RA messages. Based on the current definition [ND], it's difficult for a host to check for link change upon a single RA reception. To detect link identity, a host may compare the informations in an RA, such as router address or prefixes, with the existing ones. The host may use a router address to try to check for link change. The router address in the source address field of an RA is of link-local scope, however, so its uniqueness is not guaranteed outside of a link. If it happens that two different router interfaces on different links have the same link-local address, the host can't detect that it has moved from one link to another by checking the router address in RA messages. The set of all the global prefixes assigned to a link can represent a link identity. The host may compare the prefixes in an incoming RA with the currently stored ones. An unsolicited RA message, however, can omit some prefixes for convenience [4] and it's not easy for a host to attain and retain all the prefixes with certainty. Hence, neither the absence of a previously known prefix nor the presence of a previously unknown prefix in the RA guarantees that link change has occurred. From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 25 04:17:21 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23114 for ; Wed, 25 Aug 2004 04:17:20 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE39V1OUOO8YELO4@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 Aug 2004 18:13:32 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id EFFA7AB577; Wed, 25 Aug 2004 18:12:23 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 9D9234FB0C; Wed, 25 Aug 2004 18:12:23 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7P8B9113061 for dna-list; Wed, 25 Aug 2004 18:11:09 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7P8B4613057 for ; Wed, 25 Aug 2004 18:11:05 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE39RWHD2E8YF28L@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 Aug 2004 18:10:01 +1000 Received: by localhost (Postfix, from userid 510) id 1628680009; Wed, 25 Aug 2004 18:09:59 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7C9CE3C006; Wed, 25 Aug 2004 18:09:58 +1000 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z0090FTCKMS@mailout2.samsung.com>; Wed, 25 Aug 2004 17:09:57 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00M64TC6KV@mailout2.samsung.com>; Wed, 25 Aug 2004 17:09:42 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2Z00H4KTC6HT@mmp2.samsung.com>; Wed, 25 Aug 2004 17:09:42 +0900 (KST) Date: Wed, 25 Aug 2004 17:09:41 +0900 From: JinHyeock Choi Subject: [DNA] Issue 5: Manage connection to multiple links as a new goal Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com, JinHyeock Choi Cc: dna@eng.monash.edu.au, Jari Arkko Message-id: <02a201c48a7a$e02375c0$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 5 Jim Bound proposed as an additional DNA goal, To analyze the case of the host hearing both links with respect to seamless mobility Suggested resolution: We propose to accept this and add to goals list G10 Hosts with multiple interfaces or in particular wireless environments may perceive routers reachable on different links. DNA schemes should take into consideration the case where a host is attached to more than one link at the same time. Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks to Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 25 04:22:10 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23320 for ; Wed, 25 Aug 2004 04:22:09 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE3A2D89XY8YF1UC@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 Aug 2004 18:18:22 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 5CFAAAB547; Wed, 25 Aug 2004 18:17:38 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 1949E4FB10; Wed, 25 Aug 2004 18:17:38 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7P8HaS13138 for dna-list; Wed, 25 Aug 2004 18:17:36 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7P8HY613133 for ; Wed, 25 Aug 2004 18:17:35 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE3A1Q46DK8YF1UC@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 Aug 2004 18:17:08 +1000 Received: by localhost (Postfix, from userid 510) id 52020AB548; Wed, 25 Aug 2004 18:17:07 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by curly.its.monash.edu.au (Postfix) with ESMTP id BAFEB4FB11; Wed, 25 Aug 2004 18:17:06 +1000 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z00A25TOGQQ@mailout2.samsung.com>; Wed, 25 Aug 2004 17:17:04 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00JF1TMOXS@mailout2.samsung.com>; Wed, 25 Aug 2004 17:16:01 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2Z006BNTMO2G@mmp1.samsung.com>; Wed, 25 Aug 2004 17:16:00 +0900 (KST) Date: Wed, 25 Aug 2004 17:16:00 +0900 From: JinHyeock Choi Subject: [DNA] Issue 6: Describe properties of L2 for routing or link change as a new goal Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com, JinHyeock Choi Cc: dna@eng.monash.edu.au, Jari Arkko Message-id: <02a801c48a7b$c1be9640$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 6 Jim Bound proposed as an additional DNA goal, To describe the L2 properties with respect to routing and link detection Suggested resolution: We propose to reject this. It's our opinion that it would be better for this work to be done at link-layer notification or BCP. Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks to Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 25 08:27:35 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10281 for ; Wed, 25 Aug 2004 08:27:33 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE3INGIDMQ8WXVRS@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 Aug 2004 22:23:47 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 8345BAB543; Wed, 25 Aug 2004 22:23:42 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 38DCB4FB04; Wed, 25 Aug 2004 22:23:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7PCNAP15335 for dna-list; Wed, 25 Aug 2004 22:23:10 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7PCN5615293 for ; Wed, 25 Aug 2004 22:23:06 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE39LUKCIU8Y5E4Y@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Wed, 25 Aug 2004 18:05:07 +1000 Received: by localhost (Postfix, from userid 510) id EA5C780005; Wed, 25 Aug 2004 18:05:05 +1000 (EST) Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5C0A93C01A; Wed, 25 Aug 2004 18:05:05 +1000 (EST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I2Z00FVMT4DTA@mailout1.samsung.com>; Wed, 25 Aug 2004 17:05:01 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I2Z00B20T2HC5@mailout1.samsung.com>; Wed, 25 Aug 2004 17:03:53 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I2Z00LT3T2H0K@mmp2.samsung.com>; Wed, 25 Aug 2004 17:03:53 +0900 (KST) Date: Wed, 25 Aug 2004 17:03:53 +0900 From: JinHyeock Choi Subject: [DNA] Issue 4: Attain and retain prefixes with certainty as a new goal Sender: owner-dna@ecselists.eng.monash.edu.au To: Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com, JinHyeock Choi Cc: dna@eng.monash.edu.au, Jari Arkko Message-id: <028d01c48a7a$10411380$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 4 Jim Bound proposed as an additional DNA goal, To investigate a way for a host to attain and retain all prefixes with certainty. Suggested resolution: We propose to reject this. G1 states that 'DNA schemes should detect the identity of the currently attached link'. Right now, there are two candidates to achieve G1, the complete prefix list and an explicit link identifier. We think it may be premature for WG to state the particular way to achieve the G1 as a goal. It's our opinion that it's better for WG to investigate how DNA schemes would achieve G1, whether with the complete prefix list or with an explicit link identifier, in solution work. Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks to Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 25 10:04:37 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16514 for ; Wed, 25 Aug 2004 10:04:36 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE3LWPY8O48Y5EGN@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Wed, 25 Aug 2004 23:57:36 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E2EEC80005; Wed, 25 Aug 2004 23:57:27 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 93B323C006; Wed, 25 Aug 2004 23:57:27 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7PDvB316435 for dna-list; Wed, 25 Aug 2004 23:57:11 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7PDv7616431 for ; Wed, 25 Aug 2004 23:57:07 +1000 Received: from localhost ([130.194.13.82]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE3LVYNG528ZELRJ@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Wed, 25 Aug 2004 23:56:51 +1000 Received: by localhost (Postfix, from userid 510) id 480B280002; Wed, 25 Aug 2004 23:56:51 +1000 (EST) Received: from jaju.cvnet.co.kr (unknown [219.252.92.142]) by larry.its.monash.edu.au (Postfix) with SMTP id C75D73C002 for ; Wed, 25 Aug 2004 23:56:49 +1000 (EST) Received: from 221.147.158.246 (221.147.158.246) by jaju.cvnet.co.kr with ZMAIL SMTP; Wed, 25 Aug 2004 22:55:28 +0900 Date: Wed, 25 Aug 2004 22:55:18 +0900 From: JinHyeock Choi Subject: [DNA] Issue 7: Clarify Goal 7 SEND/IPsec Compatability Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com, JinHyeock Choi Cc: dna@eng.monash.edu.au, Jari Arkko Message-id: <20ae01c48aab$2b123230$f69e93dd@syoung> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) X-Spam-Level: * References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 7 Jari Arkko proposed to clarify G7. G7. DNA schemes should be compatible with security schemes such as Secure Neighbour Discovery [8] and IPSec [7]. "I understand the SEND part. Not sure I understand the IPsec part. ... perhaps you could clarify what your requirement is" Suggested resolution: We propose to remove IPSec part as below. G7. DNA schemes should be compatible with security schemes such as Secure Neighbour Discovery [7]. Because DNA will be based on ND, SEND will be sufficient and, as Jari commented, IPsec part can cause unnecessary ambiguities with little benefit. Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks to Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 25 10:16:28 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17937 for ; Wed, 25 Aug 2004 10:16:25 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE3M8WK19K8WY0HT@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 Aug 2004 00:06:39 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 53684AB544; Thu, 26 Aug 2004 00:06:30 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 0A7E94FB0D; Thu, 26 Aug 2004 00:06:30 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7PE6SY16544 for dna-list; Thu, 26 Aug 2004 00:06:28 +1000 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7PE6Q616540 for ; Thu, 26 Aug 2004 00:06:26 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE3M8EHZEA8ZELRY@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Thu, 26 Aug 2004 00:06:06 +1000 Received: by localhost (Postfix, from userid 510) id 288D2AB545; Thu, 26 Aug 2004 00:06:06 +1000 (EST) Received: from jaju.cvnet.co.kr (unknown [219.252.92.142]) by moe.its.monash.edu.au (Postfix) with SMTP id AFD204FB08 for ; Thu, 26 Aug 2004 00:06:04 +1000 (EST) Received: from 221.147.158.246 (221.147.158.246) by jaju.cvnet.co.kr with ZMAIL SMTP; Wed, 25 Aug 2004 23:04:06 +0900 Date: Wed, 25 Aug 2004 23:03:56 +0900 From: JinHyeock Choi Subject: [DNA] Issue 8: Modify Security Considerations Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi , JinHyeock Choi , Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com Cc: dna@eng.monash.edu.au, Jari Arkko , JinHyeock Choi Message-id: <20b401c48aac$600bf1a0$f69e93dd@syoung> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) X-Spam-Level: * References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> Content-Transfer-Encoding: 7BIT Dear DNA WG This is an attempt to resolve this issue: Issue 8 Jari Arkko proposed to modify Security Consideration "You may want to add something like what Bernard wrote in his DNAv4 document about not trusting the DNA procedures to turn on/off your personal firewall based on "recognizing" your home network." Suggested resolution: We propose to modify Security Considerations as belows. Because DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in [9]. Nodes connected over wireless interfaces may be particularly susceptible to jamming, monitoring and packet insertion attacks. As a result, when Neighbor Discovery is not secured, it is inadvisable for a host to adjust its security based on which network it believes it is attached to. For example, it would be inappropriate for a host to disable its personal firewall based on the belief that it had connected to a home network. Use of [7] to secure Neighbor Discovery is important in achieving reliable detecting network attachment. DNA schemes SHOULD incorporate the solutions developed in IETF SEND WG if available, where assessment indicates such procedures are required. * We add something like what Bernard wrote in DNAv4 I-D between "... packet insertion attacks' and 'Use of...' Please register your opinion if you have any comments, otherwise we'll update the goals draft accordingly and move it forward. Thanks to Greg's kind work, we now have the issue list at http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Wed Aug 25 21:38:09 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14000 for ; Wed, 25 Aug 2004 21:38:07 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE4AAWTYMS8YEVYB@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 Aug 2004 11:37:31 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 25EE7AB546; Thu, 26 Aug 2004 11:35:19 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id C39104FB06; Thu, 26 Aug 2004 11:35:18 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7Q1Wle23774 for dna-list; Thu, 26 Aug 2004 11:32:47 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7Q1Wh623770 for ; Thu, 26 Aug 2004 11:32:43 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4A7JNF2Y8WYANB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 26 Aug 2004 11:32:37 +1000 Received: by localhost (Postfix, from userid 510) id 6DB8FAB545; Thu, 26 Aug 2004 11:32:36 +1000 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by moe.its.monash.edu.au (Postfix) with ESMTP id 25DF74FB0A; Thu, 26 Aug 2004 11:32:35 +1000 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7Q1VYc00371; Wed, 25 Aug 2004 18:31:34 -0700 Received: from mvdhcp141129.americas.nokia.com (172.18.141.129, claiming to be "[172.18.141.129]") by darkstar.iprg.nokia.com smtpd9mF0Wa; Wed, 25 Aug 2004 18:31:31 -0700 (PDT) Date: Wed, 25 Aug 2004 18:32:08 -0700 From: Vijay Devarapalli Subject: Re: [DNA] Issue 8: Modify Security Considerations In-reply-to: <20b401c48aac$600bf1a0$f69e93dd@syoung> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: JinHyeock Choi , Greg Daley , Pekka Nikander , margaret@thingmagic.com, narten@us.ibm.com, dna@eng.monash.edu.au, Jari Arkko Message-id: <412D3D98.3080103@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-mProtect: <200408260131> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> <20b401c48aac$600bf1a0$f69e93dd@syoung> Content-Transfer-Encoding: 7BIT I am not sure I understood the issue. I agree that some secure mechanism is need to detect crossing security boundaries before a personal firewall is turned off. but why is this tied to SEND? I dont see anything in SEND for detecting crossing security boundaries. it might suffice to say, in the Security Considerations section, that a secure mechanism is needed to detect crossing security boundaries before taking actions like turning off personal firewall and that DNA mechanisms might not be sufficient. Vijay JinHyeock Choi wrote: > Dear DNA WG > > This is an attempt to resolve this issue: > > Issue 8 > Jari Arkko proposed to modify Security Consideration > > "You may want to add something like what Bernard wrote in his DNAv4 > document about not trusting the DNA procedures to turn on/off your personal > firewall based on "recognizing" your home network." > > Suggested resolution: We propose to modify Security Considerations as belows. > > Because DNA schemes are based on Neighbor Discovery, its trust models > and threats are similar to the ones presented in [9]. Nodes > connected over wireless interfaces may be particularly susceptible to > jamming, monitoring and packet insertion attacks. > > As a result, when Neighbor Discovery is not secured, it is > inadvisable for a host to adjust its security based on which network > it believes it is attached to. For example, it would be > inappropriate for a host to disable its personal firewall based on > the belief that it had connected to a home network. > > Use of [7] to secure Neighbor Discovery is important in achieving > reliable detecting network attachment. DNA schemes SHOULD > incorporate the solutions developed in IETF SEND WG if available, > where assessment indicates such procedures are required. > > * We add something like what Bernard wrote in DNAv4 I-D between > "... packet insertion attacks' and 'Use of...' > > Please register your opinion if you have any comments, otherwise > we'll update the goals draft accordingly and move it forward. > > Thanks to Greg's kind work, we now have the issue list at > > http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNAGoals > > Thanks for your kind consideration. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 26 06:39:16 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19945 for ; Thu, 26 Aug 2004 06:39:14 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4T9BTR088WY9LO@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 Aug 2004 20:38:33 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 10CA7AB6E1; Thu, 26 Aug 2004 20:29:30 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id BD3224FB13; Thu, 26 Aug 2004 20:29:29 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7QAPKt28958 for dna-list; Thu, 26 Aug 2004 20:25:20 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7QAPH628954 for ; Thu, 26 Aug 2004 20:25:18 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4SQQIB7O8Y5GWV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 26 Aug 2004 20:23:29 +1000 Received: by localhost (Postfix, from userid 510) id 2C5E980061; Thu, 26 Aug 2004 20:08:34 +1000 (EST) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by larry.its.monash.edu.au (Postfix) with ESMTP id 7D3993C006; Thu, 26 Aug 2004 20:08:33 +1000 (EST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3100404TI7M9@mailout2.samsung.com>; Thu, 26 Aug 2004 19:08:31 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3100EEMTI7AT@mailout2.samsung.com>; Thu, 26 Aug 2004 19:08:31 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I31009OJTI6P7@mmp1.samsung.com>; Thu, 26 Aug 2004 19:08:30 +0900 (KST) Date: Thu, 26 Aug 2004 19:08:31 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 8: Modify Security Considerations Sender: owner-dna@ecselists.eng.monash.edu.au To: Vijay Devarapalli Cc: Greg Daley , Pekka Nikander , dna@eng.monash.edu.au, JinHyeock Choi Message-id: <00ec01c48b54$a3e58be0$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> <20b401c48aac$600bf1a0$f69e93dd@syoung> <412D3D98.3080103@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Vijay Thanks for your feedback. > I am not sure I understood the issue. I agree that some secure > mechanism is need to detect crossing security boundaries before > a personal firewall is turned off. but why is this tied to SEND? > I dont see anything in SEND for detecting crossing security > boundaries. > > it might suffice to say, in the Security Considerations section, > that a secure mechanism is needed to detect crossing security > boundaries before taking actions like turning off personal > firewall and that DNA mechanisms might not be sufficient. Our line of thoughts are like below. 1. With SEND, we can secure Router Discovery, such as Router Advertisement. 2. With secured RA messages, we can secure DNA. 3. With secured DNA mechanisms, a host can safely adjust its security based on which network link it believe it is attached to. 4. Without secured DNA schemes, it's inadvisable to do so. We think that DNA schemes can be used to detect crossing security boundaries indirectly and SEND can be used to secure DNA, so the connection. It seems, however, that the phrases need clarification. How about this? Because DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in [9]. Nodes connected over wireless interfaces may be particularly susceptible to jamming, monitoring and packet insertion attacks. Use of [7] to secure Neighbor Discovery is important in achieving reliable detecting network attachment. DNA schemes SHOULD incorporate the solutions developed in IETF SEND WG if available, where assessment indicates such procedures are required. With unsecured DNA schemes, it is inadvisable for a host to adjust its security based on which network it believes it is attached to. For example, it would be inappropriate for a host to disable its personal firewall based on the belief that it had connected to a home network. I exchanged the second and the third part with slight modification to clarify the paragraphs. Kindly comment on it. Thanks for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 26 07:54:37 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24121 for ; Thu, 26 Aug 2004 07:54:36 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4VPAP6E48Y5GYL@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 Aug 2004 21:48:40 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id F2F2BAB76A; Thu, 26 Aug 2004 21:39:42 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9F6944FB0B; Thu, 26 Aug 2004 21:39:42 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7QBdNE29664 for dna-list; Thu, 26 Aug 2004 21:39:23 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7QBdJ629658 for ; Thu, 26 Aug 2004 21:39:20 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4V3Y6U948Y5GYB@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 26 Aug 2004 21:31:23 +1000 Received: by localhost (Postfix, from userid 510) id 63342AB81B; Thu, 26 Aug 2004 21:20:00 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id CAF4A4FB0A; Thu, 26 Aug 2004 21:19:59 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3100M0FWT9NK@mailout3.samsung.com>; Thu, 26 Aug 2004 20:19:57 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I31000ATWSNFT@mailout3.samsung.com>; Thu, 26 Aug 2004 20:19:35 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I310055KWSN83@mmp2.samsung.com>; Thu, 26 Aug 2004 20:19:35 +0900 (KST) Date: Thu, 26 Aug 2004 20:19:35 +0900 From: JinHyeock Choi Subject: [DNA] Closing the Goals Issues Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Greg Daley , Pekka Nikander , dna@eng.monash.edu.au, Jari Arkko Message-id: <014601c48b5e$912da190$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> <20b401c48aac$600bf1a0$f69e93dd@syoung> <412D3D98.3080103@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Dear DNA WG 13th Friday has passed without Jason's appearance, so I am filled with high hope for speedy Goals advancement. :-) We have posted the proposed resolutions for all the existing issues. We ask WG to investigate and comment on them. Just to place a boundary on the time, we'd like to ask that people with comments on the proposals do so before 01:00 UTC on the 1st of September. If you think that proposed resolutions are inacceptable or need improvement, kindly register your opinion during this period. Otherwise we'll close the issues to update the goals draft accordingly and move it forward. The interim version of goals draft is available at http://math87.ensoltek.co.kr/board/files/draft-ietf-dna-goals-01int.txt Thanks in advance for your kind consideration. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 26 07:58:07 2004 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24362 for ; Thu, 26 Aug 2004 07:58:05 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4VUM5AGC8WYD4B@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Thu, 26 Aug 2004 21:53:00 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 209C2AB6A3; Thu, 26 Aug 2004 21:45:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id BE7D54FB18; Thu, 26 Aug 2004 21:45:34 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7QBjVx29730 for dna-list; Thu, 26 Aug 2004 21:45:31 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7QBjT629726 for ; Thu, 26 Aug 2004 21:45:30 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE4VILZ7XA8Y5FRV@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Thu, 26 Aug 2004 21:43:13 +1000 Received: by localhost (Postfix, from userid 510) id 11128AB54C; Thu, 26 Aug 2004 21:33:45 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by moe.its.monash.edu.au (Postfix) with ESMTP id 686904FB15; Thu, 26 Aug 2004 21:33:44 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3100201XG624@mailout3.samsung.com>; Thu, 26 Aug 2004 20:33:42 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I31000K0XG6FT@mailout3.samsung.com>; Thu, 26 Aug 2004 20:33:42 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I3100IWCXG5U0@mmp1.samsung.com>; Thu, 26 Aug 2004 20:33:42 +0900 (KST) Date: Thu, 26 Aug 2004 20:33:41 +0900 From: JinHyeock Choi Subject: [DNA] [Announce] DNA in IPv6 Goals I-D Update Sender: owner-dna@ecselists.eng.monash.edu.au To: Pekka Nikander , Greg Daley , JinHyeock Choi Cc: Dna Message-id: <015d01c48b60$89dc8b70$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <006c01c422ad$3ad1a180$ee2f024b@jinchoe> <00b501c45042$4dcf9590$f52f024b@jinchoe> Content-Transfer-Encoding: 7BIT Dear DNA Group We have reflected the existing issues to update DNA in IPv6 Goals draft. The interim version of the draft is available at the URL: http://math87.ensoltek.co.kr/board/files/draft-ietf-dna-goals-01int.txt Main changes are as below. Abstract We removed the second part and slightly modified the end of first part. 1. Introduction. We removed the part starting from 'While other information... ' to '....but not necessarily vice versa'. Jim Bound pointed out that there might be the instance contrary to the statement. We removed the Sec 2 of the previous version. 2. Problems in Detecting Network Attachment We reduced the problems section substantially. We tried to sketch the specific problems that make efficient DNA, such as fast, precise and of-limited signaling, difficult. Particularly we intend Sub-sec 2.2 to present the difficulty for a SINGLE RA to indicate a link change. It's not our intention that Sub-sec 2.2 deals with the difficulty for multiple RAs to indicate a link change, because we are worried that may cause unnecessary arguments with little benefit. 3. Goals for Detecting Network Attachment We rephrased and reshuffled the Goals lists. In G6, we reflected Issue 7, raised by Jari to delete the IPsec part. G8, G9 in 00-draft are combined to G8. G10, G11 in 00-draft are combined to G9. G10 is added to reflect issue 5 raised by Jim Bound. 5. Security Considerations. We reflected issue 8, raised by Jari, to add something like what Bernard wrote in DNAv4 I-D. Kindly see the draft to check there is something incorrect or missing. Thanks in advance for your kind consideration. Best Regards JinHyeock Choi and Greg Daley (Authors) From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 26 16:53:33 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10794 for ; Thu, 26 Aug 2004 16:53:31 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE5EO3ZQDG8Y4Z1J@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 27 Aug 2004 06:51:33 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 1C965AB543; Fri, 27 Aug 2004 06:51:17 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id C6B314FB10; Fri, 27 Aug 2004 06:51:16 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7QKoW702206 for dna-list; Fri, 27 Aug 2004 06:50:32 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7QKoT602202 for ; Fri, 27 Aug 2004 06:50:29 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE5EMWDERW8WYFEL@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 27 Aug 2004 06:50:18 +1000 Received: by localhost (Postfix, from userid 510) id A558580002; Fri, 27 Aug 2004 06:50:18 +1000 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by larry.its.monash.edu.au (Postfix) with ESMTP id 516403C008; Fri, 27 Aug 2004 06:50:17 +1000 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7QKnNK25451; Thu, 26 Aug 2004 13:49:23 -0700 Received: from mvdhcp141167.americas.nokia.com (172.18.141.167, claiming to be "[172.18.141.167]") by darkstar.iprg.nokia.com smtpd79zIOD; Thu, 26 Aug 2004 13:49:21 -0700 (PDT) Date: Thu, 26 Aug 2004 13:50:00 -0700 From: Vijay Devarapalli Subject: Re: [DNA] Issue 8: Modify Security Considerations In-reply-to: <00ec01c48b54$a3e58be0$ed2f024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Greg Daley , Pekka Nikander , dna@eng.monash.edu.au, JinHyeock Choi Message-id: <412E4CF8.7070702@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-mProtect: <200408262049> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> <20b401c48aac$600bf1a0$f69e93dd@syoung> Content-Transfer-Encoding: 7BIT JinHyeock Choi wrote: > Vijay > > Thanks for your feedback. > > >>I am not sure I understood the issue. I agree that some secure >>mechanism is need to detect crossing security boundaries before >>a personal firewall is turned off. but why is this tied to SEND? >>I dont see anything in SEND for detecting crossing security >>boundaries. >> >>it might suffice to say, in the Security Considerations section, >>that a secure mechanism is needed to detect crossing security >>boundaries before taking actions like turning off personal >>firewall and that DNA mechanisms might not be sufficient. > > > Our line of thoughts are like below. > > 1. With SEND, we can secure Router Discovery, such as Router > Advertisement. > 2. With secured RA messages, we can secure DNA. this reasoning is flawed. who said all DNA mechanisms will be based on RA messages? > 3. With secured DNA mechanisms, a host can safely adjust its > security based on which network link it believe it is attached to. > 4. Without secured DNA schemes, it's inadvisable to do so. > > We think that DNA schemes can be used to detect crossing security > boundaries indirectly and SEND can be used to secure DNA, so the > connection. that is your opinion. IMO, it doesnt belong in a Goals document. what if I have never planned on using SEND. :) > > It seems, however, that the phrases need clarification. How about this? > > Because DNA schemes are based on Neighbor Discovery, its trust models > and threats are similar to the ones presented in [9]. Nodes > connected over wireless interfaces may be particularly susceptible to > jamming, monitoring and packet insertion attacks. > > Use of [7] to secure Neighbor Discovery is important in achieving > reliable detecting network attachment. DNA schemes SHOULD > incorporate the solutions developed in IETF SEND WG if available, > where assessment indicates such procedures are required. > > With unsecured DNA schemes, it is inadvisable for a host to adjust > its security based on which network it believes it is attached to. > For example, it would be inappropriate for a host to disable its > personal firewall based on the belief that it had connected to a home > network. just delete the second paragraph. you can still convey what you want to in the Security Considerations section without that text. Because DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in [9]. Nodes connected over wireless interfaces may be particularly susceptible to jamming, monitoring and packet insertion attacks. With unsecured DNA schemes, it is inadvisable for a host to adjust its security based on which network it believes it is attached to. For example, it would be inappropriate for a host to disable its personal firewall based on the belief that it had connected to a home network. Vijay ps: Reference [9] is RFC 3775. you probably wanted to say RFC 3756 which is reference [10] > > I exchanged the second and the third part with slight modification to clarify > the paragraphs. Kindly comment on it. > > Thanks for your kind consideration. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Thu Aug 26 21:31:41 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00797 for ; Thu, 26 Aug 2004 21:31:39 -0400 (EDT) Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE5OAIUV068WYA9R@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Fri, 27 Aug 2004 11:26:46 +1000 Received: from larry.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id AFBE28000B; Fri, 27 Aug 2004 11:26:39 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by larry.its.monash.edu.au (Postfix) with ESMTP id 5FE8C3C017; Fri, 27 Aug 2004 11:26:39 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7R1Q5R04695 for dna-list; Fri, 27 Aug 2004 11:26:05 +1000 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7R1Q2604691 for ; Fri, 27 Aug 2004 11:26:03 +1000 Received: from localhost ([130.194.13.82]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE5O9D6O4O8Y5I0M@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Fri, 27 Aug 2004 11:25:44 +1000 Received: by localhost (Postfix, from userid 510) id 6F3B480018; Fri, 27 Aug 2004 11:25:41 +1000 (EST) Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by larry.its.monash.edu.au (Postfix) with ESMTP id 95F0A3C015; Fri, 27 Aug 2004 11:25:40 +1000 (EST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3200940ZYPHW@mailout3.samsung.com>; Fri, 27 Aug 2004 10:25:37 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3200AYQZX4CC@mailout3.samsung.com>; Fri, 27 Aug 2004 10:24:41 +0900 (KST) Received: from jinchoe ([75.2.47.237]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I320081YZX4CG@mmp2.samsung.com>; Fri, 27 Aug 2004 10:24:40 +0900 (KST) Date: Fri, 27 Aug 2004 10:24:40 +0900 From: JinHyeock Choi Subject: Re: [DNA] Issue 8: Modify Security Considerations Sender: owner-dna@ecselists.eng.monash.edu.au To: Vijay Devarapalli Cc: Greg Daley , Pekka Nikander , dna@eng.monash.edu.au Message-id: <002b01c48bd4$a0694e40$ed2f024b@jinchoe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> <20b401c48aac$600bf1a0$f69e93dd@syoung> <412E4CF8.7070702@iprg.nokia.com> Content-Transfer-Encoding: 7BIT Vijay > > Our line of thoughts are like below. > > > > 1. With SEND, we can secure Router Discovery, such as Router > > Advertisement. > > 2. With secured RA messages, we can secure DNA. > > this reasoning is flawed. who said all DNA mechanisms will be > based on RA messages? Even though, at this point, we can't be certain that DNA will be based on RA message, I think that's highly likely and will bet a dinner on it. :-) Thinking it over, 'ALL' is a very hard qualitifier to satisfy. > > 3. With secured DNA mechanisms, a host can safely adjust its > > security based on which network link it believe it is attached to. > > 4. Without secured DNA schemes, it's inadvisable to do so. > > > > We think that DNA schemes can be used to detect crossing security > > boundaries indirectly and SEND can be used to secure DNA, so the > > connection. > > that is your opinion. IMO, it doesnt belong in a Goals document. > what if I have never planned on using SEND. :) I see your point. It may be premature to mention SEND in goals draft because, right now, we can't say what form DNA schemes will take. It maybe be better for us to mention SEND in Solution drafts. [omitted] > just delete the second paragraph. you can still convey what you > want to in the Security Considerations section without that text. > > Because DNA schemes are based on Neighbor Discovery, its trust models > and threats are similar to the ones presented in [9]. Nodes > connected over wireless interfaces may be particularly susceptible to > jamming, monitoring and packet insertion attacks. > > With unsecured DNA schemes, it is inadvisable for a host to adjust > its security based on which network it believes it is attached to. > For example, it would be inappropriate for a host to disable its > personal firewall based on the belief that it had connected to a home > network. I agree. I'll modify as you proposed. It may be better for us to include the second paragraph in Security Consideration of Solution drafts. > ps: Reference [9] is RFC 3775. you probably wanted to say RFC 3756 > which is reference [10] The reference number is from the new version. In it, [9] is RFC 3756. This comment warms my heart because it showed that you really paid attention. :-) Thanks for your kind and helpful comments. Best Regards JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Fri Aug 27 14:29:35 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21866 for ; Fri, 27 Aug 2004 14:29:33 -0400 (EDT) Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LE6NWMUNHU8WW3KS@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Sat, 28 Aug 2004 04:27:10 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 3779BAB543; Sat, 28 Aug 2004 04:27:02 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by curly.its.monash.edu.au (Postfix) with ESMTP id 31DD04FB04; Sat, 28 Aug 2004 04:27:01 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7RINOA13166 for dna-list; Sat, 28 Aug 2004 04:23:24 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7RILJ613146 for ; Sat, 28 Aug 2004 04:21:20 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LE6NP75X6E8WYKUC@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Sat, 28 Aug 2004 04:21:02 +1000 Received: by localhost (Postfix, from userid 510) id BC75BAB542; Sat, 28 Aug 2004 04:21:02 +1000 (EST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by moe.its.monash.edu.au (Postfix) with ESMTP id 7938C4FB02; Sat, 28 Aug 2004 04:21:01 +1000 (EST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i7RIJF032601; Fri, 27 Aug 2004 11:19:15 -0700 Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdc5mUVz; Fri, 27 Aug 2004 11:19:13 -0700 (PDT) Date: Fri, 27 Aug 2004 11:29:31 -0700 From: Vijay Devarapalli Subject: Re: [DNA] Issue 8: Modify Security Considerations In-reply-to: <002b01c48bd4$a0694e40$ed2f024b@jinchoe> Sender: owner-dna@ecselists.eng.monash.edu.au To: JinHyeock Choi Cc: Greg Daley , Pekka Nikander , dna@eng.monash.edu.au Message-id: <412F7D8B.3060408@iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en Precedence: bulk User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-mProtect: <200408271819> Nokia Silicon Valley Messaging Protection X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) References: <01ae01c485c1$405b63d0$ed2f024b@jinchoe> <028d01c48a7a$10411380$ed2f024b@jinchoe> <02a201c48a7a$e02375c0$ed2f024b@jinchoe> <02a801c48a7b$c1be9640$ed2f024b@jinchoe> <20ae01c48aab$2b123230$f69e93dd@syoung> <20b401c48aac$600bf1a0$f69e93dd@syoung> Content-Transfer-Encoding: 7BIT thanks. Vijay JinHyeock Choi wrote: > Vijay > > >>>Our line of thoughts are like below. >>> >>>1. With SEND, we can secure Router Discovery, such as Router >>> Advertisement. >>>2. With secured RA messages, we can secure DNA. >> >>this reasoning is flawed. who said all DNA mechanisms will be >>based on RA messages? > > > Even though, at this point, we can't be certain that DNA will be > based on RA message, I think that's highly likely and will bet a > dinner on it. :-) Thinking it over, 'ALL' is a very hard qualitifier to > satisfy. > > >>>3. With secured DNA mechanisms, a host can safely adjust its >>> security based on which network link it believe it is attached to. >>>4. Without secured DNA schemes, it's inadvisable to do so. >>> >>>We think that DNA schemes can be used to detect crossing security >>>boundaries indirectly and SEND can be used to secure DNA, so the >>>connection. >> >>that is your opinion. IMO, it doesnt belong in a Goals document. >>what if I have never planned on using SEND. :) > > > I see your point. It may be premature to mention SEND in goals draft > because, right now, we can't say what form DNA schemes will > take. It maybe be better for us to mention SEND in Solution drafts. > > [omitted] > >>just delete the second paragraph. you can still convey what you >>want to in the Security Considerations section without that text. >> >> Because DNA schemes are based on Neighbor Discovery, its trust models >> and threats are similar to the ones presented in [9]. Nodes >> connected over wireless interfaces may be particularly susceptible to >> jamming, monitoring and packet insertion attacks. >> >> With unsecured DNA schemes, it is inadvisable for a host to adjust >> its security based on which network it believes it is attached to. >> For example, it would be inappropriate for a host to disable its >> personal firewall based on the belief that it had connected to a home >> network. > > > I agree. I'll modify as you proposed. It may be better for us to include > the second paragraph in Security Consideration of Solution drafts. > > >>ps: Reference [9] is RFC 3775. you probably wanted to say RFC 3756 >>which is reference [10] > > > The reference number is from the new version. In it, [9] is RFC 3756. > This comment warms my heart because it showed that you really paid > attention. :-) > > Thanks for your kind and helpful comments. > > Best Regards > > JinHyeock From dna-owner@webcamserver.eng.monash.edu.au Tue Aug 31 05:17:43 2004 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00931 for ; Tue, 31 Aug 2004 05:17:41 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LEBPUKDN6U8ZE18U@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 Aug 2004 19:16:52 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id CC727AB542; Tue, 31 Aug 2004 19:16:35 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 805174FB11; Tue, 31 Aug 2004 19:16:35 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7V9DsK27375 for dna-list; Tue, 31 Aug 2004 19:13:54 +1000 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7V9Dq627371 for ; Tue, 31 Aug 2004 19:13:52 +1000 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LEBPR526F68Y5N2Z@vaxh.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT rfc822;dna@eng.monash.edu.au); Tue, 31 Aug 2004 19:13:50 +1000 Received: by localhost (Postfix, from userid 510) id 4BE45AB543; Tue, 31 Aug 2004 19:13:50 +1000 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by moe.its.monash.edu.au (Postfix) with ESMTP id 962874FB15; Tue, 31 Aug 2004 19:13:47 +1000 (EST) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; Tue, 31 Aug 2004 11:27:06 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7V9D7Ti025587; Tue, 31 Aug 2004 11:13:39 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 11:13:10 +0200 Date: Tue, 31 Aug 2004 11:11:52 +0200 From: "Pascal Thubert (pthubert)" Subject: [DNA] Tree Discovery Sender: owner-dna@ecselists.eng.monash.edu.au To: Thierry Ernst , Greg Daley Cc: mattias.l.pettersson@ericsson.com, nemo@ietf.org, dna@eng.monash.edu.au Message-id: <7892795E1A87F04CADFCCF41FADD00FC104244@xmb-ams-337.emea.cisco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: Tree Discovery Thread-Index: AcSPDY/TmvC7zaJPQAyKefzPuDzifAAHhpkQ Content-class: urn:content-classes:message X-BrightmailFiltered: true X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) X-OriginalArrivalTime: 31 Aug 2004 09:13:10.0945 (UTC) FILETIME=[BCAB8910:01C48F3A] Content-Transfer-Encoding: 7BIT Hi: This thread is about http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt . > > > > ferry boat <- car <- pan. > > This one is a valid scenario. > > > > > NEMO does not provide for the PAN to attach to a car (mine in > > > > particular), for the car to attach to a ferry etc... We could end up > > > > having a car joining the ferry and then the hundred other in a daisy > > > > chain till the overhead of tunnels is so huge that it does not work > > Would you explain what you mean by "NEMO does not provide for the PAN to > attach to a car" ? I'm not sure I get it. From my first understanding, > I would disagree. NEMO basic support does not provide tooling for default router selection. I may be wrong, but I'm afraid that a detecting/building a multi-hop network attachment is out of scope for DNA as well - copying Greg and DNA here. As far as NEMO basic support is concerned, the MR serving my PAN could attach to my wife's PAN which could attach to the neighbour's car which could attach to my car, maybe all cars forming a daisy chain... and maybe a loop, for quite a long time. This is issue 24. You need additional control to establish/maintain the ferry boat <- car <- pan chain quickly and efficiently. I think it was Steve Deering at IETF 54, who asked how we (NEMMO WG) make sure that we do not get the whole ferry boat going out via my PAN... The preference in TD provides for that case. That same result can be achieved by manual config (e.g. SSID for 802.11) and AAA, as I understand Mattias is proposing. I do not see firemen playing with SSIDs in front of a fire, though. Nor me changing my SSID when I hop in a bus for a few minutes, just to maintain my VOIP call. TD is an extension of ND that improves the default router selection. It is pretty generic and can be adapted for the use cases we want to support. But first, we need to reckon that there is a problem and make sure somebody is looking at it. > But, taking the example of a bus, connected to the Internet via 802.11 > APs deployed in the street, and also offering a 802.11 access to its > customers within the bus, I would guess that only MR would have the > credentials to join the street-AP (key, etc), while the bus-AP icould > only be accessed to the passengers who have the credentials for the > bus-AP. I wish to discuss that case further. Same question as above. Is this all AAA based, or do we need to enhance the default Router selection? I understand there's a need for AAA anyway, but I'm not sure that we can leave it at that: Say I'm a pedestrian in the street. My PAN MR attaches to an AR along the curb. I'm not nested. Now I hop into the bus. Should I keep roaming using curb MRs or should I attach to the bus MR and let the bus do the roaming in a nested fashion? Do I need to change my MR config to do one or the other? One good thing could be to do AAA with the ARs regardless on whether I hop via the bus or not (PANA?) One other good thing would be to get a CareOf from the bus while I'm in the bus and only while I'm in the bus (not if buses pass by me). One other good thing would be that buses do not use my PAN to get to the curb AR. One other good thing would be that another PAN might relay my own if I do not have direct visibility to the AR (anonymous relaying). ... Pascal From dna-owner@webcamserver.eng.monash.edu.au Tue Aug 31 06:01:17 2004 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02683 for ; Tue, 31 Aug 2004 06:01:15 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LEBRBK6LR68Y5NHZ@vaxh.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 Aug 2004 19:58:38 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 734F5AB543; Tue, 31 Aug 2004 19:58:32 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 2F1094FB05; Tue, 31 Aug 2004 19:58:32 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7V9wMO27755 for dna-list; Tue, 31 Aug 2004 19:58:22 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7V9wM627751 for ; Tue, 31 Aug 2004 19:58:22 +1000 Received: from localhost ([130.194.13.87]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LEBRB41KZA90MYK5@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 Aug 2004 19:58:11 +1000 Received: from curly.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C3E8AAB542; Tue, 31 Aug 2004 19:58:10 +1000 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by curly.its.monash.edu.au (Postfix) with ESMTP id 141874FB18; Tue, 31 Aug 2004 19:58:10 +1000 (EST) Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i7V9vSmk028872; Tue, 31 Aug 2004 02:57:28 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i7V7vBaT028836; Tue, 31 Aug 2004 02:57:12 -0500 Date: Tue, 31 Aug 2004 11:57:16 +0200 From: Alexandru Petrescu Subject: [DNA] Re: [nemo] Tree Discovery In-reply-to: <7892795E1A87F04CADFCCF41FADD00FC104244@xmb-ams-337.emea.cisco.com> Sender: owner-dna@ecselists.eng.monash.edu.au To: "Pascal Thubert (pthubert)" Cc: Thierry Ernst , Greg Daley , nemo@ietf.org, dna@eng.monash.edu.au, mattias.l.pettersson@ericsson.com Message-id: <41344B7C.902@motorola.com> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------enig1E3BF25393DC51B43CC051F3; protocol="application/pgp-signature"; micalg=pgp-sha1 Precedence: bulk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <7892795E1A87F04CADFCCF41FADD00FC104244@xmb-ams-337.emea.cisco.com> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1E3BF25393DC51B43CC051F3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > As far as NEMO basic support is concerned, the MR serving my PAN > could attach to my wife's PAN which could attach to the neighbour's > car which could attach to my car, maybe all cars forming a daisy > chain... and maybe a loop, for quite a long time. This is issue 24. Tell your wife your neighbour's car is not adequate for attaching, or get control of her laptop. The apparent ubiquity of wifi cafes and browsing yahoo for everbody does not mean that _setting up_ networks is a mundane task that mere mortals could get trapped into. > You need additional control to establish/maintain the ferry boat <- > car <- pan chain quickly and efficiently. I think it was Steve > Deering at IETF 54, who asked how we (NEMMO WG) make sure that we do > not get the whole ferry boat going out via my PAN... The preference > in TD provides for that case. Make sure that the admin who sets up the TD preferences does it right. Make sure that the TD preferences do not lead to TD loops. > That same result can be achieved by manual config (e.g. SSID for > 802.11) and AAA, as I understand Mattias is proposing. I do not see > firemen playing with SSIDs in front of a fire, though. I do not see firemen playing with TD preferences in front of a fire. > Nor me changing my SSID when I hop in a bus for a few minutes, just > to maintain my VOIP call. Well, you don't have to. If you use the same bus company every day, just make sure you add it to your Windows preferences and then order those preferences with the street AP's, and you're all set. If you take similar trajectories daily, you won't have to manually change the ESSID, Windows (and associated driver) will do it by your preferences. > TD is an extension of ND that improves the default router selection. > It is pretty generic and can be adapted for the use cases we want to > support. But first, we need to reckon that there is a problem and > make sure somebody is looking at it. I think a better default router selection can be used when several AR-AP pairs are outgoing routers for the same unique IP link. Let's first identify where such cases occur in wireless? A hotspot deployment in Paris/France (where Cisco is a partner) has fixed hotspot areas that may overlap each other. Both AP's have the same ESSID. In the small overlapping area a Client may see two AP's, same ESSID. However, it can not communicate with both at the same time, the Client "flips" between the two AP's; in this particular case, the IP stack can not choose between two default routes, it is only one AP accessible at a time. In the same area, the overlapping common physical area, although covered by two AP's with same ESSID and key, are not actually the same unique IP subnet. The IP(v4!) address obtained from one AP/AR and the associated masks are different than the ones obtained from the other AP/AR. So this particular deployment does not qualify for an intelligent default router selection, IMHO. In order to have a need for a better default router selection, we need to have a wireless deployment with two AP-AR pairs, same ESSID and same subnet mask (or IPv6 prefix). That can be 802.11b or another wireless with a MAC layer. Cellular GPRS and UMTS do not apply because GPRS/UMTS use ppp and the default route is practically tied to an innterface. >> But, taking the example of a bus, connected to the Internet via >> 802.11 APs deployed in the street, and also offering a 802.11 >> access to its customers within the bus, I would guess that only MR >> would have the credentials to join the street-AP (key, etc), while >> the bus-AP icould only be accessed to the passengers who have the >> credentials for the bus-AP. Passengers may have both credentials (for bus and for street). An existing train deployment, passenger buys credentials for both the train and the station. The train is not connected to the station AP's but to GPRS (and I doubt any bus will roam between hotspot areas, it's just too fast). When the passenger is in the train inside the station, passenger has the choice of AP of this train, or neighbour trains, or the station's AP. Passenger has all these choices, but I don't think the IP stack has any choice once the passengers has chosen one. > Say I'm a pedestrian in the street. My PAN MR attaches to an AR along > the curb. I'm not nested. Now I hop into the bus. Should I keep > roaming using curb MRs or should I attach to the bus MR and let the > bus do the roaming in a nested fashion? Do I need to change my MR > config to do one or the other? > > One good thing could be to do AAA with the ARs regardless on whether > I hop via the bus or not (PANA?) > > One other good thing would be to get a CareOf from the bus while I'm > in the bus and only while I'm in the bus (not if buses pass by me). > > One other good thing would be that buses do not use my PAN to get to > the curb AR. > > One other good thing would be that another PAN might relay my own if > I do not have direct visibility to the AR (anonymous relaying). I think there are many ways in which one would design a wireless hotspot deployment. The best way to do better is to pick an existing hostpot deployment and see where are the problems. The 2-3 hotspot deployments I've seen, my favourite problems are the following: -none uses IPv6. -none uses Mobile IPv4. -IPv4 address is changed from hotspot area to the next. -all are behind NAT. -none offers continuous applications when changing AP, thus not allowing for any physical movement (don't even dream of "fast" movements). Alex --------------enig1E3BF25393DC51B43CC051F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBNEuCMmC0w56zj54RAoKrAKCVh1TRAKHikIRIf8hb/XNy18QUVwCgqQMq 9YCOnC2beTtSi/ug+iCQ0rU= =Ndx9 -----END PGP SIGNATURE----- --------------enig1E3BF25393DC51B43CC051F3-- From dna-owner@webcamserver.eng.monash.edu.au Tue Aug 31 07:44:10 2004 Received: from ALPHA1.ITS.MONASH.EDU.AU (alpha1.its.monash.edu.au [130.194.1.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09433 for ; Tue, 31 Aug 2004 07:44:09 -0400 (EDT) Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LEBUTZSMEO8ZE1PV@vaxc.its.monash.edu.au> for dna-archive@lists.ietf.org; Tue, 31 Aug 2004 21:39:06 +1000 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id B589CAB547; Tue, 31 Aug 2004 21:38:53 +1000 (EST) Received: from webcamserver.eng.monash.edu.au (webcamserver.eng.monash.edu.au [130.194.5.143]) by moe.its.monash.edu.au (Postfix) with ESMTP id 31CF24FB06; Tue, 31 Aug 2004 21:38:53 +1000 (EST) Received: (from majordomo@localhost) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) id i7VBcSh28754 for dna-list; Tue, 31 Aug 2004 21:38:28 +1000 Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by webcamserver.eng.monash.edu.au (8.11.6/8.11.0) with ESMTP id i7VBcR628749 for ; Tue, 31 Aug 2004 21:38:27 +1000 Received: from localhost ([130.194.13.88]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LEBUT9BU8G8ZE1PV@vaxc.its.monash.edu.au> for dna@ecselists.eng.monash.edu.au (ORCPT dna@eng.monash.edu.au); Tue, 31 Aug 2004 21:38:19 +1000 Received: by localhost (Postfix, from userid 510) id 38F0DAB543; Tue, 31 Aug 2004 21:38:19 +1000 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by moe.its.monash.edu.au (Postfix) with ESMTP id 8E9734FB05; Tue, 31 Aug 2004 21:38:17 +1000 (EST) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; Tue, 31 Aug 2004 13:51:43 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i7VBbjTo021389; Tue, 31 Aug 2004 13:38:12 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 31 Aug 2004 13:37:44 +0200 Date: Tue, 31 Aug 2004 13:37:38 +0200 From: "Pascal Thubert (pthubert)" Subject: [DNA] RE: [nemo] Tree Discovery Sender: owner-dna@ecselists.eng.monash.edu.au To: Alexandru Petrescu Cc: Thierry Ernst , Greg Daley , nemo@ietf.org, dna@eng.monash.edu.au, mattias.l.pettersson@ericsson.com Message-id: <7892795E1A87F04CADFCCF41FADD00FC1042EF@xmb-ams-337.emea.cisco.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Precedence: bulk Thread-Topic: [nemo] Tree Discovery Thread-Index: AcSPQQpK3EGdX25AT7GLPfQpDnme/QADafLg Content-class: urn:content-classes:message X-BrightmailFiltered: true X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) X-OriginalArrivalTime: 31 Aug 2004 11:37:44.0738 (UTC) FILETIME=[EEA75020:01C48F4E] Content-Transfer-Encoding: 7BIT > > The 2-3 hotspot deployments I've seen, my favourite problems are the > following: > -none uses IPv6. > -none uses Mobile IPv4. > -IPv4 address is changed from hotspot area to the next. > -all are behind NAT. > -none offers continuous applications when changing AP, thus not allowing > for any physical movement (don't even dream of "fast" movements). > Try Doors :) http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ipv4-traver sal-01.txt Pascal