From mailman-admin@ietf.org Mon Sep 1 14:26:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10376 for ; Mon, 1 Sep 2003 14:26:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toIY-0006Eg-Is for nemo-archive@lists.ietf.org; Mon, 01 Sep 2003 09:00:46 -0400 Date: Mon, 01 Sep 2003 09:00:46 -0400 Message-ID: <20030901130046.21711.15117.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-admin@ietf.org Tue Sep 2 04:26:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29347 for ; Tue, 2 Sep 2003 04:26:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4tS-0003i9-9J; Tue, 02 Sep 2003 02:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1Dj-0002F1-3t for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:48:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01128 for ; Mon, 1 Sep 2003 22:48:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1De-0001wP-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:48:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19tqOy-0000vL-00 for nemo@ietf.org; Mon, 01 Sep 2003 11:15:32 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Sep 2003 17:13:56 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h81FCV28014422; Mon, 1 Sep 2003 17:12:31 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Sep 2003 16:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Mon, 1 Sep 2003 16:14:49 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNmoK6sRKhyz4MbTMWQSst8eKSJKAJ+evzg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , X-OriginalArrivalTime: 01 Sep 2003 15:14:50.0707 (UTC) FILETIME=[C9F5B230:01C3709B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi again Vijay > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 20 ao=FBt 2003 00:24 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; nemo@ietf.org > Subject: Source Address Selection (was Re: [nemo] crossover = tunnel....) >=20 > "Pascal Thubert (pthubert)" wrote: >=20 >=20 > > When a MR joins a new link, there's more that happens than we = actually described. > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > In the process of Source Address Selection, the MRHA tunnel = is considered as > > any other link, with the restriction that only a global = address may be selected. >=20 > this is not necessarily true. link local addresses can be > used as source and destination address in the inner IPv6 > header. infact link local address are used, for example, > if DHCPv6 messages are exchanged over the MR-HA tunnel. > the outer IPv6 header ofcourse will contain MR's CoA and > HA's address. >=20 > > So when the MR is not at Home, the Home Address will be = selected as source > > address when and only when the destination is reached via = the MRHA tunnel. >=20 > right. >=20 > > > > The MR has a set of connected routes for its attached MNPs. = It may also > > have some static routes and a set of routes obtained from a = routing protocol. > > For all these routes, SAS takes place normally and if the = MRHA tunnel is not > > the link to the next hop, the best scoped global address on = that link should > > be preferred, avoiding the MIP encapsulation and the need = for global connectivity. >=20 > I am not sure what you mean by global connectivity here? > the rest of the paragraph makes sense. I meant that the connectivity to the infrastructure may not be there and = yet SAS allows internal connectivity. Example between a VMN and a LFN in = a mobile network when the MR that owns the mobile network is not bound = to its HA and there's no MRHA tunnel. >=20 > > In particular, when a MR forms a CoA from a visited prefix, = it inserts a > > connected route to that prefix, over the associated egress = interface, in > > its routing table. So when the MR initiates a socket to a = node on that link, > > SAS will select the CareOf address as source. >=20 > why? the MR may want to use Route Optimization with the > node on the visited link. in this case, the MR-HA tunnel > wouldnt be outgoing interface. the application on the > MR may initiate a socket with the home address and depend > on the kernel to add the Home Address option. when the > packet is actually sent out on the visited link, the > source address would be the CoA with the home address in > the Home Address Option. >=20 > but I agree with the general idea in your text. and I think > it can be simplified. >=20 > For any packet, if the interface through which the packet > is sent out is the MR-HA tunnel, then the Home Address must > be selected as the source address. The source must be set > to the link local address, if the destination of the packet > is a link local address. The Mobile Router MUST NOT set the > source address to Home Address if the packets are sent to > the visited link. >=20 I agree with that text, but there's something missing to the last = sentence. The Mobile Router may have other routes than via the MRHA = tunnel. For instance running a routing protocol locally in the visited = network. For all these routes, the interface out will not he the MRHA = tunnel, and SAS must select the appropriate address as it does normally = as if Nemo was not there. This is all normal SAS, considering that the = global address on the MRHA is the home address. Can you please reword = the last sentence?=20 Pascal From nemo-admin@ietf.org Tue Sep 2 05:22:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02895 for ; Tue, 2 Sep 2003 05:22:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u56F-0005mi-0e; Tue, 02 Sep 2003 02:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0wj-0000Tq-VQ for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24915 for ; Mon, 1 Sep 2003 22:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0wf-0005t8-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:31:01 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19u0r9-0002K0-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:25:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h822OZ308891; Mon, 1 Sep 2003 19:24:35 -0700 X-mProtect: <200309020224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPplExr; Mon, 01 Sep 2003 19:24:34 PDT Message-ID: <3F53FF62.D0097432@iprg.nokia.com> Date: Mon, 01 Sep 2003 19:24:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: "'Pascal Thubert (pthubert)'" , nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: <000001c370f8$4e7310f0$dbf02e93@JONGKN02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jongkeun Na wrote: > > Hi Pascal and Vijay, > > I have a question. When does MR want to use SAS for what connectivity? > It's not clear to me. Some cases that I can understand are as follows: > 1) The connectivity between any node on visited link and MR > itself(acting as MN) we are discussing only case 1 here. Vijay > 2) The connectivity between any node on visited link and LFN/VMN in > Mobile Network. > > In this case, I've just considered Mobile Network as a simple type with > one egress and one ingress interface. Is there any other case? > And, SAS can describe case 1), but not about case 2). I wondering if > case 2) can be concerned in our discussion. If case 2) is possible > without any route optimization, it'd be good because many of > applications no longer depend on their MRHA tunnel for local > connectivity. > > Regards, > /Jongkeun From nemo-admin@ietf.org Tue Sep 2 07:49:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13532 for ; Tue, 2 Sep 2003 07:49:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5Me-0000CE-MT; Tue, 02 Sep 2003 03:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0yS-0000ex-8D for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:32:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25447 for ; Mon, 1 Sep 2003 22:32:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0yN-0006Jq-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:32:47 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19u0jM-0006SF-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:17:17 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h822Db92016628; Tue, 2 Sep 2003 11:13:37 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" Cc: Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 11:17:06 +0900 Message-ID: <000001c370f8$4e7310f0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Pascal and Vijay, I have a question. When does MR want to use SAS for what connectivity? It's not clear to me. Some cases that I can understand are as follows: 1) The connectivity between any node on visited link and MR itself(acting as MN) 2) The connectivity between any node on visited link and LFN/VMN in Mobile Network. In this case, I've just considered Mobile Network as a simple type with one egress and one ingress interface. Is there any other case? And, SAS can describe case 1), but not about case 2). I wondering if case 2) can be concerned in our discussion. If case 2) is possible without any route optimization, it'd be good because many of applications no longer depend on their MRHA tunnel for local connectivity. Regards, /Jongkeun > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, September 02, 2003 12:15 AM > To: Vijay Devarapalli > Cc: Jongkeun Na; nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > Hi again Vijay >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: mercredi 20 ao=FBt 2003 00:24 > > To: Pascal Thubert (pthubert) > > Cc: Jongkeun Na; nemo@ietf.org > > Subject: Source Address Selection (was Re: [nemo] crossover tunnel....) > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > When a MR joins a new link, there's more that happens than we actually > described. > > > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > > > In the process of Source Address Selection, the MRHA tunnel is > considered as > > > any other link, with the restriction that only a global address may be > selected. > > > > this is not necessarily true. link local addresses can be > > used as source and destination address in the inner IPv6 > > header. infact link local address are used, for example, > > if DHCPv6 messages are exchanged over the MR-HA tunnel. > > the outer IPv6 header ofcourse will contain MR's CoA and > > HA's address. > > > > > So when the MR is not at Home, the Home Address will be selected > as source > > > address when and only when the destination is reached via the > MRHA tunnel. > > > > right. > > > > > > > > The MR has a set of connected routes for its attached MNPs. It may > also > > > have some static routes and a set of routes obtained from a routing > protocol. > > > For all these routes, SAS takes place normally and if the MRHA > tunnel is not > > > the link to the next hop, the best scoped global address on that link > should > > > be preferred, avoiding the MIP encapsulation and the need for > global connectivity. > > > > I am not sure what you mean by global connectivity here? > > the rest of the paragraph makes sense. >=20 > I meant that the connectivity to the infrastructure may not be there and yet SAS > allows internal connectivity. Example between a VMN and a LFN in a mobile > network when the MR that owns the mobile network is not bound to its HA and > there's no MRHA tunnel. >=20 >=20 > > > > > In particular, when a MR forms a CoA from a visited prefix, it inserts > a > > > connected route to that prefix, over the associated egress interface, > in > > > its routing table. So when the MR initiates a socket to a node on > that link, > > > SAS will select the CareOf address as source. > > > > why? the MR may want to use Route Optimization with the > > node on the visited link. in this case, the MR-HA tunnel > > wouldnt be outgoing interface. the application on the > > MR may initiate a socket with the home address and depend > > on the kernel to add the Home Address option. when the > > packet is actually sent out on the visited link, the > > source address would be the CoA with the home address in > > the Home Address Option. > > > > but I agree with the general idea in your text. and I think > > it can be simplified. > > > > For any packet, if the interface through which the packet > > is sent out is the MR-HA tunnel, then the Home Address must > > be selected as the source address. The source must be set > > to the link local address, if the destination of the packet > > is a link local address. The Mobile Router MUST NOT set the > > source address to Home Address if the packets are sent to > > the visited link. > > >=20 > I agree with that text, but there's something missing to the last sentence. The > Mobile Router may have other routes than via the MRHA tunnel. For instance > running a routing protocol locally in the visited network. For all these routes, the > interface out will not he the MRHA tunnel, and SAS must select the appropriate > address as it does normally as if Nemo was not there. This is all normal SAS, > considering that the global address on the MRHA is the home address. Can you > please reword the last sentence? >=20 >=20 > Pascal From nemo-admin@ietf.org Tue Sep 2 08:38:15 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17455 for ; Tue, 2 Sep 2003 08:38:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6kh-0004gR-2S; Tue, 02 Sep 2003 04:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4oT-0002ju-Qe for nemo@optimus.ietf.org; Tue, 02 Sep 2003 02:38:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20533 for ; Tue, 2 Sep 2003 02:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u4oP-0007M4-00 for nemo@ietf.org; Tue, 02 Sep 2003 02:38:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19u4oN-0007E8-00 for nemo@ietf.org; Tue, 02 Sep 2003 02:38:43 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2003 08:37:16 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h826Zq1C001561; Tue, 2 Sep 2003 08:35:53 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Sep 2003 07:38:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 07:38:11 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNw+FpRYHuoQRSJTDeyVOinKV6pLAAIv7Aw From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Sep 2003 06:38:12.0352 (UTC) FILETIME=[C7E9D800:01C3711C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable MR does SAS when it opens a socket. So it's not your case 2, and it's = more than your case 1. The remote end may be on the visited link or some hops away. The key is = whether the route to the remote end is via the MRHA or not. If the route = is via MRHA, then the home address should be used as the global address = on that link, that's all I'm saying. The MR has a connected route to the prefix of the CareOf. In your case 2 = (LFN to end node in the visited network) the packets will not be routed = via MRHA because there is a better prefix match. Consequence the packets = from the LFN will reach the destination. But the end node will not have = a route to the LFN so the return connectivity will be broken if there's = no MRHA tunnel. We still have to find a solution for that. Maybe some proxy by the MR, = or some advertisement of its MNP on the visited link? Pascal > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: mardi 2 septembre 2003 04:17 > To: Pascal Thubert (pthubert); 'Vijay Devarapalli' > Cc: nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover = tunnel....) >=20 > Hi Pascal and Vijay, >=20 > I have a question. When does MR want to use SAS for what connectivity? > It's not clear to me. Some cases that I can understand are as follows: > 1) The connectivity between any node on visited link and MR > itself(acting as MN) > 2) The connectivity between any node on visited link and LFN/VMN in > Mobile Network. > In this case, I've just considered Mobile Network as a simple type = with > one egress and one ingress interface. Is there any other case? > And, SAS can describe case 1), but not about case 2). I wondering if > case 2) can be concerned in our discussion. If case 2) is possible > without any route optimization, it'd be good because many of > applications no longer depend on their MRHA tunnel for local > connectivity. >=20 > Regards, > /Jongkeun >=20 >=20 > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: Tuesday, September 02, 2003 12:15 AM > > To: Vijay Devarapalli > > Cc: Jongkeun Na; nemo@ietf.org > > Subject: RE: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > Hi again Vijay > > > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > Sent: mercredi 20 ao=FBt 2003 00:24 > > > To: Pascal Thubert (pthubert) > > > Cc: Jongkeun Na; nemo@ietf.org > > > Subject: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > When a MR joins a new link, there's more that happens than we > actually > > described. > > > > > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > > > > > In the process of Source Address Selection, the MRHA > tunnel is > > considered as > > > > any other link, with the restriction that only a global > address may be > > selected. > > > > > > this is not necessarily true. link local addresses can be > > > used as source and destination address in the inner IPv6 > > > header. infact link local address are used, for example, > > > if DHCPv6 messages are exchanged over the MR-HA tunnel. > > > the outer IPv6 header ofcourse will contain MR's CoA and > > > HA's address. > > > > > > > So when the MR is not at Home, the Home Address will be > selected > > as source > > > > address when and only when the destination is reached = via > the > > MRHA tunnel. > > > > > > right. > > > > > > > > > > > The MR has a set of connected routes for its attached > MNPs. It may > > also > > > > have some static routes and a set of routes obtained = from > a routing > > protocol. > > > > For all these routes, SAS takes place normally and if = the > MRHA > > tunnel is not > > > > the link to the next hop, the best scoped global address > on that link > > should > > > > be preferred, avoiding the MIP encapsulation and the = need > for > > global connectivity. > > > > > > I am not sure what you mean by global connectivity here? > > > the rest of the paragraph makes sense. > > > > I meant that the connectivity to the infrastructure may not be there > and yet SAS > > allows internal connectivity. Example between a VMN and a LFN in a > mobile > > network when the MR that owns the mobile network is not bound to its > HA and > > there's no MRHA tunnel. > > > > > > > > > > > In particular, when a MR forms a CoA from a visited > prefix, it inserts > > a > > > > connected route to that prefix, over the associated = egress > interface, > > in > > > > its routing table. So when the MR initiates a socket to = a > node on > > that link, > > > > SAS will select the CareOf address as source. > > > > > > why? the MR may want to use Route Optimization with the > > > node on the visited link. in this case, the MR-HA tunnel > > > wouldnt be outgoing interface. the application on the > > > MR may initiate a socket with the home address and depend > > > on the kernel to add the Home Address option. when the > > > packet is actually sent out on the visited link, the > > > source address would be the CoA with the home address in > > > the Home Address Option. > > > > > > but I agree with the general idea in your text. and I think > > > it can be simplified. > > > > > > For any packet, if the interface through which the packet > > > is sent out is the MR-HA tunnel, then the Home Address must > > > be selected as the source address. The source must be set > > > to the link local address, if the destination of the packet > > > is a link local address. The Mobile Router MUST NOT set the > > > source address to Home Address if the packets are sent to > > > the visited link. > > > > > > > I agree with that text, but there's something missing to the last > sentence. The > > Mobile Router may have other routes than via the MRHA tunnel. For > instance > > running a routing protocol locally in the visited network. For all > these routes, the > > interface out will not he the MRHA tunnel, and SAS must select the > appropriate > > address as it does normally as if Nemo was not there. This is all > normal SAS, > > considering that the global address on the MRHA is the home address. > Can you > > please reword the last sentence? > > > > > > Pascal From nemo-admin@ietf.org Tue Sep 2 09:30:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22331 for ; Tue, 2 Sep 2003 09:30:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAQ5-0001FR-3i; Tue, 02 Sep 2003 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u84K-0006Fj-JE for nemo@optimus.ietf.org; Tue, 02 Sep 2003 06:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06335 for ; Tue, 2 Sep 2003 06:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u84F-00016k-00 for nemo@ietf.org; Tue, 02 Sep 2003 06:07:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19u84E-00012V-00 for nemo@ietf.org; Tue, 02 Sep 2003 06:07:19 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2003 12:05:47 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h82A3m1n024875; Tue, 2 Sep 2003 12:04:23 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Sep 2003 11:06:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 11:06:42 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNwxfu1QemB4f1qTyeJoobPsJYx6AAcsjXg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Sep 2003 10:06:43.0375 (UTC) FILETIME=[E91073F0:01C37139] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 1 septembre 2003 22:17 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > "Pascal Thubert (pthubert)" wrote: >=20 > > > For any packet, if the interface through which the packet > > > is sent out is the MR-HA tunnel, then the Home Address must > > > be selected as the source address. The source must be set > > > to the link local address, if the destination of the packet > > > is a link local address. The Mobile Router MUST NOT set the > > > source address to Home Address if the packets are sent to > > > the visited link. > > > > > > > I agree with that text, but there's something missing to the last sentence. The Mobile > > Router may have other routes than via the MRHA tunnel. >=20 > ofcourse. >=20 > > For instance running a routing > > protocol locally in the visited network. For all these routes, the interface out will not > > he the MRHA tunnel, and SAS must select the appropriate address as it does normally as if > > Nemo was not there. >=20 > right. the CoA should be used. >=20 > > This is all normal SAS, considering that the global address on the > > MRHA is the home address. Can you please reword the last sentence? >=20 > what specific text are you looking for? I am not sure I understood > that from your email. we just want to place restriction on the use > of home address when the MR is on a visited link, which the > paragraph I proposed above does. >=20 I'm looking for some text that says that SAS works as defined in RFCs, with the Home Address considered as the global address on the MRHA tunnel. Your text gives examples of that, but the best is to refer to the existing definition. The first sentence of your text is the key example. I'd turn it into: " For Source Address Selection purposes, the Home Address is considered as the global address on the MRHA tunnel. Consequently, in most cases, the Home Address will be selected as the source address if and only if the interface through which the packet is sent out is the MR-HA tunnel.=20 " What do you think? Pascal From nemo-admin@ietf.org Tue Sep 2 09:35:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23600 for ; Tue, 2 Sep 2003 09:35:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAyv-0005he-23; Tue, 02 Sep 2003 09:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7F3-0007y0-Am for nemo@optimus.ietf.org; Tue, 02 Sep 2003 05:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02269 for ; Tue, 2 Sep 2003 05:14:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7Ez-0000DD-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:14:21 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19u7Ex-0000Cv-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:14:19 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h829Aj92018331; Tue, 2 Sep 2003 18:10:45 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" Cc: Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 18:14:13 +0900 Message-ID: <000001c37132$93f227d0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks for your explanation. >=20 > The remote end may be on the visited link or some hops away. The key is whether > the route to the remote end is via the MRHA or not. If the route is via MRHA, then > the home address should be used as the global address on that link, that's all I'm > saying. Yes, I agree. But, how can MR decide to choose it's CoA of visited link to send some packets to a node on some hops away? If MR can be configured by static routes, it's possible. However, I don't think that is a thing we really want to find. There is something we should think about. There is some benefit if MR can use it's CoA for the outgoing connection that has the destination node on global internet, not just some hops away. That is because most of applications of Mobile Network will be client type except sort of emerging services like VoIP that is required to accept an incoming connection. Is there any problem in using it's CoA for outgoing connections? Any difference in doing for nodes on some hops away? >=20 > The MR has a connected route to the prefix of the CareOf. In your case 2 (LFN to > end node in the visited network) the packets will not be routed via MRHA because > there is a better prefix match. Consequence the packets from the LFN will reach > the destination. But the end node will not have a route to the LFN so the return > connectivity will be broken if there's no MRHA tunnel. >=20 > We still have to find a solution for that. Maybe some proxy by the MR, or some > advertisement of its MNP on the visited link? Yes, I agree. There are some points we need to come up with for route optimization.=20 /Jongkeun >=20 > Pascal >=20 > > -----Original Message----- > > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > > Sent: mardi 2 septembre 2003 04:17 > > To: Pascal Thubert (pthubert); 'Vijay Devarapalli' > > Cc: nemo@ietf.org > > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) > > > > Hi Pascal and Vijay, > > > > I have a question. When does MR want to use SAS for what connectivity? > > It's not clear to me. Some cases that I can understand are as follows: > > 1) The connectivity between any node on visited link and MR > > itself(acting as MN) > > 2) The connectivity between any node on visited link and LFN/VMN in > > Mobile Network. > > In this case, I've just considered Mobile Network as a simple type with > > one egress and one ingress interface. Is there any other case? > > And, SAS can describe case 1), but not about case 2). I wondering if > > case 2) can be concerned in our discussion. If case 2) is possible > > without any route optimization, it'd be good because many of > > applications no longer depend on their MRHA tunnel for local > > connectivity. > > > > Regards, > > /Jongkeun > > > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > > Sent: Tuesday, September 02, 2003 12:15 AM > > > To: Vijay Devarapalli > > > Cc: Jongkeun Na; nemo@ietf.org > > > Subject: RE: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > Hi again Vijay > > > > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > Sent: mercredi 20 ao=FBt 2003 00:24 > > > > To: Pascal Thubert (pthubert) > > > > Cc: Jongkeun Na; nemo@ietf.org > > > > Subject: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > > > When a MR joins a new link, there's more that happens than we > > actually > > > described. > > > > > > > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > > > > > > > In the process of Source Address Selection, the MRHA > > tunnel is > > > considered as > > > > > any other link, with the restriction that only a global > > address may be > > > selected. > > > > > > > > this is not necessarily true. link local addresses can be > > > > used as source and destination address in the inner IPv6 > > > > header. infact link local address are used, for example, > > > > if DHCPv6 messages are exchanged over the MR-HA tunnel. > > > > the outer IPv6 header ofcourse will contain MR's CoA and > > > > HA's address. > > > > > > > > > So when the MR is not at Home, the Home Address will be > > selected > > > as source > > > > > address when and only when the destination is reached via > > the > > > MRHA tunnel. > > > > > > > > right. > > > > > > > > > > > > > > The MR has a set of connected routes for its attached > > MNPs. It may > > > also > > > > > have some static routes and a set of routes obtained from > > a routing > > > protocol. > > > > > For all these routes, SAS takes place normally and if the > > MRHA > > > tunnel is not > > > > > the link to the next hop, the best scoped global address > > on that link > > > should > > > > > be preferred, avoiding the MIP encapsulation and the need > > for > > > global connectivity. > > > > > > > > I am not sure what you mean by global connectivity here? > > > > the rest of the paragraph makes sense. > > > > > > I meant that the connectivity to the infrastructure may not be there > > and yet SAS > > > allows internal connectivity. Example between a VMN and a LFN in a > > mobile > > > network when the MR that owns the mobile network is not bound to its > > HA and > > > there's no MRHA tunnel. > > > > > > > > > > > > > > > In particular, when a MR forms a CoA from a visited > > prefix, it inserts > > > a > > > > > connected route to that prefix, over the associated egress > > interface, > > > in > > > > > its routing table. So when the MR initiates a socket to a > > node on > > > that link, > > > > > SAS will select the CareOf address as source. > > > > > > > > why? the MR may want to use Route Optimization with the > > > > node on the visited link. in this case, the MR-HA tunnel > > > > wouldnt be outgoing interface. the application on the > > > > MR may initiate a socket with the home address and depend > > > > on the kernel to add the Home Address option. when the > > > > packet is actually sent out on the visited link, the > > > > source address would be the CoA with the home address in > > > > the Home Address Option. > > > > > > > > but I agree with the general idea in your text. and I think > > > > it can be simplified. > > > > > > > > For any packet, if the interface through which the packet > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > be selected as the source address. The source must be set > > > > to the link local address, if the destination of the packet > > > > is a link local address. The Mobile Router MUST NOT set the > > > > source address to Home Address if the packets are sent to > > > > the visited link. > > > > > > > > > > I agree with that text, but there's something missing to the last > > sentence. The > > > Mobile Router may have other routes than via the MRHA tunnel. For > > instance > > > running a routing protocol locally in the visited network. For all > > these routes, the > > > interface out will not he the MRHA tunnel, and SAS must select the > > appropriate > > > address as it does normally as if Nemo was not there. This is all > > normal SAS, > > > considering that the global address on the MRHA is the home address. > > Can you > > > please reword the last sentence? > > > > > > > > > Pascal From exim@www1.ietf.org Tue Sep 2 09:35:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23642 for ; Tue, 2 Sep 2003 09:35:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBJ6-00017i-Dr for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 09:34:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DYq99004312 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:34:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBJ6-00017O-27 for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:34:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23445 for ; Tue, 2 Sep 2003 09:34:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBJ3-0007Q0-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:34:49 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBJ1-0007Px-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:34:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAyv-0005he-23; Tue, 02 Sep 2003 09:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7F3-0007y0-Am for nemo@optimus.ietf.org; Tue, 02 Sep 2003 05:14:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02269 for ; Tue, 2 Sep 2003 05:14:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7Ez-0000DD-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:14:21 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19u7Ex-0000Cv-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:14:19 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h829Aj92018331; Tue, 2 Sep 2003 18:10:45 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" Cc: Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 18:14:13 +0900 Message-ID: <000001c37132$93f227d0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for your explanation. >=20 > The remote end may be on the visited link or some hops away. The key is whether > the route to the remote end is via the MRHA or not. If the route is via MRHA, then > the home address should be used as the global address on that link, that's all I'm > saying. Yes, I agree. But, how can MR decide to choose it's CoA of visited link to send some packets to a node on some hops away? If MR can be configured by static routes, it's possible. However, I don't think that is a thing we really want to find. There is something we should think about. There is some benefit if MR can use it's CoA for the outgoing connection that has the destination node on global internet, not just some hops away. That is because most of applications of Mobile Network will be client type except sort of emerging services like VoIP that is required to accept an incoming connection. Is there any problem in using it's CoA for outgoing connections? Any difference in doing for nodes on some hops away? >=20 > The MR has a connected route to the prefix of the CareOf. In your case 2 (LFN to > end node in the visited network) the packets will not be routed via MRHA because > there is a better prefix match. Consequence the packets from the LFN will reach > the destination. But the end node will not have a route to the LFN so the return > connectivity will be broken if there's no MRHA tunnel. >=20 > We still have to find a solution for that. Maybe some proxy by the MR, or some > advertisement of its MNP on the visited link? Yes, I agree. There are some points we need to come up with for route optimization.=20 /Jongkeun >=20 > Pascal >=20 > > -----Original Message----- > > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > > Sent: mardi 2 septembre 2003 04:17 > > To: Pascal Thubert (pthubert); 'Vijay Devarapalli' > > Cc: nemo@ietf.org > > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) > > > > Hi Pascal and Vijay, > > > > I have a question. When does MR want to use SAS for what connectivity? > > It's not clear to me. Some cases that I can understand are as follows: > > 1) The connectivity between any node on visited link and MR > > itself(acting as MN) > > 2) The connectivity between any node on visited link and LFN/VMN in > > Mobile Network. > > In this case, I've just considered Mobile Network as a simple type with > > one egress and one ingress interface. Is there any other case? > > And, SAS can describe case 1), but not about case 2). I wondering if > > case 2) can be concerned in our discussion. If case 2) is possible > > without any route optimization, it'd be good because many of > > applications no longer depend on their MRHA tunnel for local > > connectivity. > > > > Regards, > > /Jongkeun > > > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > > Sent: Tuesday, September 02, 2003 12:15 AM > > > To: Vijay Devarapalli > > > Cc: Jongkeun Na; nemo@ietf.org > > > Subject: RE: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > Hi again Vijay > > > > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > Sent: mercredi 20 ao=FBt 2003 00:24 > > > > To: Pascal Thubert (pthubert) > > > > Cc: Jongkeun Na; nemo@ietf.org > > > > Subject: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > > > When a MR joins a new link, there's more that happens than we > > actually > > > described. > > > > > > > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > > > > > > > In the process of Source Address Selection, the MRHA > > tunnel is > > > considered as > > > > > any other link, with the restriction that only a global > > address may be > > > selected. > > > > > > > > this is not necessarily true. link local addresses can be > > > > used as source and destination address in the inner IPv6 > > > > header. infact link local address are used, for example, > > > > if DHCPv6 messages are exchanged over the MR-HA tunnel. > > > > the outer IPv6 header ofcourse will contain MR's CoA and > > > > HA's address. > > > > > > > > > So when the MR is not at Home, the Home Address will be > > selected > > > as source > > > > > address when and only when the destination is reached via > > the > > > MRHA tunnel. > > > > > > > > right. > > > > > > > > > > > > > > The MR has a set of connected routes for its attached > > MNPs. It may > > > also > > > > > have some static routes and a set of routes obtained from > > a routing > > > protocol. > > > > > For all these routes, SAS takes place normally and if the > > MRHA > > > tunnel is not > > > > > the link to the next hop, the best scoped global address > > on that link > > > should > > > > > be preferred, avoiding the MIP encapsulation and the need > > for > > > global connectivity. > > > > > > > > I am not sure what you mean by global connectivity here? > > > > the rest of the paragraph makes sense. > > > > > > I meant that the connectivity to the infrastructure may not be there > > and yet SAS > > > allows internal connectivity. Example between a VMN and a LFN in a > > mobile > > > network when the MR that owns the mobile network is not bound to its > > HA and > > > there's no MRHA tunnel. > > > > > > > > > > > > > > > In particular, when a MR forms a CoA from a visited > > prefix, it inserts > > > a > > > > > connected route to that prefix, over the associated egress > > interface, > > > in > > > > > its routing table. So when the MR initiates a socket to a > > node on > > > that link, > > > > > SAS will select the CareOf address as source. > > > > > > > > why? the MR may want to use Route Optimization with the > > > > node on the visited link. in this case, the MR-HA tunnel > > > > wouldnt be outgoing interface. the application on the > > > > MR may initiate a socket with the home address and depend > > > > on the kernel to add the Home Address option. when the > > > > packet is actually sent out on the visited link, the > > > > source address would be the CoA with the home address in > > > > the Home Address Option. > > > > > > > > but I agree with the general idea in your text. and I think > > > > it can be simplified. > > > > > > > > For any packet, if the interface through which the packet > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > be selected as the source address. The source must be set > > > > to the link local address, if the destination of the packet > > > > is a link local address. The Mobile Router MUST NOT set the > > > > source address to Home Address if the packets are sent to > > > > the visited link. > > > > > > > > > > I agree with that text, but there's something missing to the last > > sentence. The > > > Mobile Router may have other routes than via the MRHA tunnel. For > > instance > > > running a routing protocol locally in the visited network. For all > > these routes, the > > > interface out will not he the MRHA tunnel, and SAS must select the > > appropriate > > > address as it does normally as if Nemo was not there. This is all > > normal SAS, > > > considering that the global address on the MRHA is the home address. > > Can you > > > please reword the last sentence? > > > > > > > > > Pascal From nemo-admin@ietf.org Tue Sep 2 09:38:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24030 for ; Tue, 2 Sep 2003 09:38:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAKG-0000I9-L3; Tue, 02 Sep 2003 08:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7wj-0005Dm-2p for nemo@optimus.ietf.org; Tue, 02 Sep 2003 05:59:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05803 for ; Tue, 2 Sep 2003 05:59:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7we-0007NE-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:59:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19u7wd-0007Js-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:59:27 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2003 11:58:00 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h829uaEo026916; Tue, 2 Sep 2003 11:56:37 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Sep 2003 10:58:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 10:58:55 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNxMqT0iASqZD0bTMGsEvAfbAq8DAABGPCA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Sep 2003 09:58:56.0020 (UTC) FILETIME=[D27FBD40:01C37138] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: mardi 2 septembre 2003 11:14 > To: Pascal Thubert (pthubert); 'Vijay Devarapalli' > Cc: nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > Thanks for your explanation. > > > > The remote end may be on the visited link or some hops away. The key > is whether > > the route to the remote end is via the MRHA or not. If the route is > via MRHA, then > > the home address should be used as the global address on that link, > that's all I'm > > saying. > Yes, I agree. But, how can MR decide to choose it's CoA of visited link > to send some packets to a node on some hops away? If MR can be > configured by static routes, it's possible. However, I don't think that > is a thing we really want to find. There is something we should think > about. There is some benefit if MR can use it's CoA for the outgoing > connection that has the destination node on global internet, not just > some hops away. That is because most of applications of Mobile Network > will be client type except sort of emerging services like VoIP that is > required to accept an incoming connection. Is there any problem in using > it's CoA for outgoing connections? Any difference in doing for nodes on > some hops away? >=20 I meant hops away but known by a local routing protocol (eg MANET). In that case, a routing protocol has injected a best match than whatever goes via MRHA (usually ::/0). Note that a MR could be configured with a route via MRHA that's not ::/0 (for instance just your company's prefix), in which case ::/0 would be via the access router using the CareOf. If you mean that packet sourced by MR over MRHA may use CareOf as source, yes, it's possible but it violates SAS. It may be interesting for some application in a Mobile Host, but I do not perceive any point for MRs. I believe that the SAS I described in a generic MN thing, not just a MR thing. This is what I said at last IETF. > > > > The MR has a connected route to the prefix of the CareOf. In your case > 2 (LFN to > > end node in the visited network) the packets will not be routed via > MRHA because > > there is a better prefix match. Consequence the packets from the LFN > will reach > > the destination. But the end node will not have a route to the LFN so > the return > > connectivity will be broken if there's no MRHA tunnel. > > > > We still have to find a solution for that. Maybe some proxy by the MR, > or some > > advertisement of its MNP on the visited link? >=20 > Yes, I agree. There are some points we need to come up with for route > optimization. >=20 It's a very open question with many options. MR RA's and proxies MNP on the visited link, MR RA's visited link in MNet and proxies the visited prefix, etc... We need to think whether we want just one level of bridging or if we can cover a mobile tree. And to which extend this goes before global RO (MR-CN tunnel) takes over. I do not think it's a priority for the WG at the moment, though. Pascal From exim@www1.ietf.org Tue Sep 2 09:39:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24695 for ; Tue, 2 Sep 2003 09:39:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBH7-0000Nl-RP for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 09:32:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DWntd001458 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:32:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAPv-0001Bm-BV for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 08:37:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17411 for ; Tue, 2 Sep 2003 08:37:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uAPu-0001Y6-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 08:37:50 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uAPt-0001Y3-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 08:37:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6kh-0004gR-2S; Tue, 02 Sep 2003 04:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4oT-0002ju-Qe for nemo@optimus.ietf.org; Tue, 02 Sep 2003 02:38:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20533 for ; Tue, 2 Sep 2003 02:38:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u4oP-0007M4-00 for nemo@ietf.org; Tue, 02 Sep 2003 02:38:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19u4oN-0007E8-00 for nemo@ietf.org; Tue, 02 Sep 2003 02:38:43 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2003 08:37:16 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h826Zq1C001561; Tue, 2 Sep 2003 08:35:53 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Sep 2003 07:38:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 07:38:11 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNw+FpRYHuoQRSJTDeyVOinKV6pLAAIv7Aw From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Sep 2003 06:38:12.0352 (UTC) FILETIME=[C7E9D800:01C3711C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable MR does SAS when it opens a socket. So it's not your case 2, and it's = more than your case 1. The remote end may be on the visited link or some hops away. The key is = whether the route to the remote end is via the MRHA or not. If the route = is via MRHA, then the home address should be used as the global address = on that link, that's all I'm saying. The MR has a connected route to the prefix of the CareOf. In your case 2 = (LFN to end node in the visited network) the packets will not be routed = via MRHA because there is a better prefix match. Consequence the packets = from the LFN will reach the destination. But the end node will not have = a route to the LFN so the return connectivity will be broken if there's = no MRHA tunnel. We still have to find a solution for that. Maybe some proxy by the MR, = or some advertisement of its MNP on the visited link? Pascal > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: mardi 2 septembre 2003 04:17 > To: Pascal Thubert (pthubert); 'Vijay Devarapalli' > Cc: nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover = tunnel....) >=20 > Hi Pascal and Vijay, >=20 > I have a question. When does MR want to use SAS for what connectivity? > It's not clear to me. Some cases that I can understand are as follows: > 1) The connectivity between any node on visited link and MR > itself(acting as MN) > 2) The connectivity between any node on visited link and LFN/VMN in > Mobile Network. > In this case, I've just considered Mobile Network as a simple type = with > one egress and one ingress interface. Is there any other case? > And, SAS can describe case 1), but not about case 2). I wondering if > case 2) can be concerned in our discussion. If case 2) is possible > without any route optimization, it'd be good because many of > applications no longer depend on their MRHA tunnel for local > connectivity. >=20 > Regards, > /Jongkeun >=20 >=20 > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: Tuesday, September 02, 2003 12:15 AM > > To: Vijay Devarapalli > > Cc: Jongkeun Na; nemo@ietf.org > > Subject: RE: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > Hi again Vijay > > > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > Sent: mercredi 20 ao=FBt 2003 00:24 > > > To: Pascal Thubert (pthubert) > > > Cc: Jongkeun Na; nemo@ietf.org > > > Subject: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > When a MR joins a new link, there's more that happens than we > actually > > described. > > > > > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > > > > > In the process of Source Address Selection, the MRHA > tunnel is > > considered as > > > > any other link, with the restriction that only a global > address may be > > selected. > > > > > > this is not necessarily true. link local addresses can be > > > used as source and destination address in the inner IPv6 > > > header. infact link local address are used, for example, > > > if DHCPv6 messages are exchanged over the MR-HA tunnel. > > > the outer IPv6 header ofcourse will contain MR's CoA and > > > HA's address. > > > > > > > So when the MR is not at Home, the Home Address will be > selected > > as source > > > > address when and only when the destination is reached = via > the > > MRHA tunnel. > > > > > > right. > > > > > > > > > > > The MR has a set of connected routes for its attached > MNPs. It may > > also > > > > have some static routes and a set of routes obtained = from > a routing > > protocol. > > > > For all these routes, SAS takes place normally and if = the > MRHA > > tunnel is not > > > > the link to the next hop, the best scoped global address > on that link > > should > > > > be preferred, avoiding the MIP encapsulation and the = need > for > > global connectivity. > > > > > > I am not sure what you mean by global connectivity here? > > > the rest of the paragraph makes sense. > > > > I meant that the connectivity to the infrastructure may not be there > and yet SAS > > allows internal connectivity. Example between a VMN and a LFN in a > mobile > > network when the MR that owns the mobile network is not bound to its > HA and > > there's no MRHA tunnel. > > > > > > > > > > > In particular, when a MR forms a CoA from a visited > prefix, it inserts > > a > > > > connected route to that prefix, over the associated = egress > interface, > > in > > > > its routing table. So when the MR initiates a socket to = a > node on > > that link, > > > > SAS will select the CareOf address as source. > > > > > > why? the MR may want to use Route Optimization with the > > > node on the visited link. in this case, the MR-HA tunnel > > > wouldnt be outgoing interface. the application on the > > > MR may initiate a socket with the home address and depend > > > on the kernel to add the Home Address option. when the > > > packet is actually sent out on the visited link, the > > > source address would be the CoA with the home address in > > > the Home Address Option. > > > > > > but I agree with the general idea in your text. and I think > > > it can be simplified. > > > > > > For any packet, if the interface through which the packet > > > is sent out is the MR-HA tunnel, then the Home Address must > > > be selected as the source address. The source must be set > > > to the link local address, if the destination of the packet > > > is a link local address. The Mobile Router MUST NOT set the > > > source address to Home Address if the packets are sent to > > > the visited link. > > > > > > > I agree with that text, but there's something missing to the last > sentence. The > > Mobile Router may have other routes than via the MRHA tunnel. For > instance > > running a routing protocol locally in the visited network. For all > these routes, the > > interface out will not he the MRHA tunnel, and SAS must select the > appropriate > > address as it does normally as if Nemo was not there. This is all > normal SAS, > > considering that the global address on the MRHA is the home address. > Can you > > please reword the last sentence? > > > > > > Pascal From exim@www1.ietf.org Tue Sep 2 09:40:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24784 for ; Tue, 2 Sep 2003 09:40:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAF9-0007uV-SV for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 08:26:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82CQhwl030401 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 08:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u6UR-0002cJ-Oh for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 04:26:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29327 for ; Tue, 2 Sep 2003 04:26:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u6UO-0001HA-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 04:26:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u6UN-0001H5-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 04:26:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4tS-0003i9-9J; Tue, 02 Sep 2003 02:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1Dj-0002F1-3t for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:48:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01128 for ; Mon, 1 Sep 2003 22:48:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1De-0001wP-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:48:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19tqOy-0000vL-00 for nemo@ietf.org; Mon, 01 Sep 2003 11:15:32 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Sep 2003 17:13:56 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h81FCV28014422; Mon, 1 Sep 2003 17:12:31 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Sep 2003 16:14:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Mon, 1 Sep 2003 16:14:49 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNmoK6sRKhyz4MbTMWQSst8eKSJKAJ+evzg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Jongkeun Na" , X-OriginalArrivalTime: 01 Sep 2003 15:14:50.0707 (UTC) FILETIME=[C9F5B230:01C3709B] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi again Vijay > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 20 ao=FBt 2003 00:24 > To: Pascal Thubert (pthubert) > Cc: Jongkeun Na; nemo@ietf.org > Subject: Source Address Selection (was Re: [nemo] crossover = tunnel....) >=20 > "Pascal Thubert (pthubert)" wrote: >=20 >=20 > > When a MR joins a new link, there's more that happens than we = actually described. > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > In the process of Source Address Selection, the MRHA tunnel = is considered as > > any other link, with the restriction that only a global = address may be selected. >=20 > this is not necessarily true. link local addresses can be > used as source and destination address in the inner IPv6 > header. infact link local address are used, for example, > if DHCPv6 messages are exchanged over the MR-HA tunnel. > the outer IPv6 header ofcourse will contain MR's CoA and > HA's address. >=20 > > So when the MR is not at Home, the Home Address will be = selected as source > > address when and only when the destination is reached via = the MRHA tunnel. >=20 > right. >=20 > > > > The MR has a set of connected routes for its attached MNPs. = It may also > > have some static routes and a set of routes obtained from a = routing protocol. > > For all these routes, SAS takes place normally and if the = MRHA tunnel is not > > the link to the next hop, the best scoped global address on = that link should > > be preferred, avoiding the MIP encapsulation and the need = for global connectivity. >=20 > I am not sure what you mean by global connectivity here? > the rest of the paragraph makes sense. I meant that the connectivity to the infrastructure may not be there and = yet SAS allows internal connectivity. Example between a VMN and a LFN in = a mobile network when the MR that owns the mobile network is not bound = to its HA and there's no MRHA tunnel. >=20 > > In particular, when a MR forms a CoA from a visited prefix, = it inserts a > > connected route to that prefix, over the associated egress = interface, in > > its routing table. So when the MR initiates a socket to a = node on that link, > > SAS will select the CareOf address as source. >=20 > why? the MR may want to use Route Optimization with the > node on the visited link. in this case, the MR-HA tunnel > wouldnt be outgoing interface. the application on the > MR may initiate a socket with the home address and depend > on the kernel to add the Home Address option. when the > packet is actually sent out on the visited link, the > source address would be the CoA with the home address in > the Home Address Option. >=20 > but I agree with the general idea in your text. and I think > it can be simplified. >=20 > For any packet, if the interface through which the packet > is sent out is the MR-HA tunnel, then the Home Address must > be selected as the source address. The source must be set > to the link local address, if the destination of the packet > is a link local address. The Mobile Router MUST NOT set the > source address to Home Address if the packets are sent to > the visited link. >=20 I agree with that text, but there's something missing to the last = sentence. The Mobile Router may have other routes than via the MRHA = tunnel. For instance running a routing protocol locally in the visited = network. For all these routes, the interface out will not he the MRHA = tunnel, and SAS must select the appropriate address as it does normally = as if Nemo was not there. This is all normal SAS, considering that the = global address on the MRHA is the home address. Can you please reword = the last sentence?=20 Pascal From exim@www1.ietf.org Tue Sep 2 09:40:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24800 for ; Tue, 2 Sep 2003 09:40:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAGq-0008AX-Og for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 08:28:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82CSSUv031393 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 08:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7MB-0000Rc-2y for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 05:21:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02870 for ; Tue, 2 Sep 2003 05:21:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7M6-0001d7-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 05:21:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u7M6-0001d4-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 05:21:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u56F-0005mi-0e; Tue, 02 Sep 2003 02:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0wj-0000Tq-VQ for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:31:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24915 for ; Mon, 1 Sep 2003 22:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0wf-0005t8-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:31:01 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19u0r9-0002K0-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:25:19 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h822OZ308891; Mon, 1 Sep 2003 19:24:35 -0700 X-mProtect: <200309020224> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPplExr; Mon, 01 Sep 2003 19:24:34 PDT Message-ID: <3F53FF62.D0097432@iprg.nokia.com> Date: Mon, 01 Sep 2003 19:24:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jongkeun Na CC: "'Pascal Thubert (pthubert)'" , nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: <000001c370f8$4e7310f0$dbf02e93@JONGKN02> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jongkeun Na wrote: > > Hi Pascal and Vijay, > > I have a question. When does MR want to use SAS for what connectivity? > It's not clear to me. Some cases that I can understand are as follows: > 1) The connectivity between any node on visited link and MR > itself(acting as MN) we are discussing only case 1 here. Vijay > 2) The connectivity between any node on visited link and LFN/VMN in > Mobile Network. > > In this case, I've just considered Mobile Network as a simple type with > one egress and one ingress interface. Is there any other case? > And, SAS can describe case 1), but not about case 2). I wondering if > case 2) can be concerned in our discussion. If case 2) is possible > without any route optimization, it'd be good because many of > applications no longer depend on their MRHA tunnel for local > connectivity. > > Regards, > /Jongkeun From nemo-admin@ietf.org Tue Sep 2 09:42:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25058 for ; Tue, 2 Sep 2003 09:42:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u68H-0007PP-Vw; Tue, 02 Sep 2003 04:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u10Y-0000sG-Gk for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26278 for ; Mon, 1 Sep 2003 22:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u10T-0006mE-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:34:58 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19tv6t-0001KW-00 for nemo@ietf.org; Mon, 01 Sep 2003 16:17:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h81KGWS01017; Mon, 1 Sep 2003 13:16:32 -0700 X-mProtect: <200309012016> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9wPZZl; Mon, 01 Sep 2003 13:16:30 PDT Message-ID: <3F53A91E.C08F78D7@iprg.nokia.com> Date: Mon, 01 Sep 2003 13:16:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > For any packet, if the interface through which the packet > > is sent out is the MR-HA tunnel, then the Home Address must > > be selected as the source address. The source must be set > > to the link local address, if the destination of the packet > > is a link local address. The Mobile Router MUST NOT set the > > source address to Home Address if the packets are sent to > > the visited link. > > > > I agree with that text, but there's something missing to the last sentence. The Mobile > Router may have other routes than via the MRHA tunnel. ofcourse. > For instance running a routing > protocol locally in the visited network. For all these routes, the interface out will not > he the MRHA tunnel, and SAS must select the appropriate address as it does normally as if > Nemo was not there. right. the CoA should be used. > This is all normal SAS, considering that the global address on the > MRHA is the home address. Can you please reword the last sentence? what specific text are you looking for? I am not sure I understood that from your email. we just want to place restriction on the use of home address when the MR is on a visited link, which the paragraph I proposed above does. Vijay From exim@www1.ietf.org Tue Sep 2 09:42:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25184 for ; Tue, 2 Sep 2003 09:42:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u67Z-0007DU-IM for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 04:02:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8282Znq027691 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 04:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0co-0007ST-3b for nemo-web-archive@optimus.ietf.org; Mon, 01 Sep 2003 22:10:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21929 for ; Mon, 1 Sep 2003 22:10:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0ci-0005AI-00 for nemo-web-archive@ietf.org; Mon, 01 Sep 2003 22:10:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19tx4C-0006Z9-00 for nemo-web-archive@ietf.org; Mon, 01 Sep 2003 18:22:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toNJ-0001iU-Es for nemo-web-archive@ietf.org; Mon, 01 Sep 2003 09:05:41 -0400 Date: Mon, 01 Sep 2003 09:05:41 -0400 Message-ID: <20030901130541.21711.13546.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: nemo-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for nemo-web-archive@ietf.org: List Password // URL ---- -------- nemo@ietf.org dawauv https://www1.ietf.org/mailman/options/nemo/nemo-web-archive%40ietf.org From exim@www1.ietf.org Tue Sep 2 09:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25471 for ; Tue, 2 Sep 2003 09:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBS3-0003ZC-4k for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 09:44:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Di7Ho013703 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:44:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBE9-0007uZ-K7 for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:29:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22221 for ; Tue, 2 Sep 2003 09:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBE7-0006mX-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:29:43 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBE5-0006mP-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:29:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAQ5-0001FR-3i; Tue, 02 Sep 2003 08:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u84K-0006Fj-JE for nemo@optimus.ietf.org; Tue, 02 Sep 2003 06:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06335 for ; Tue, 2 Sep 2003 06:07:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u84F-00016k-00 for nemo@ietf.org; Tue, 02 Sep 2003 06:07:19 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19u84E-00012V-00 for nemo@ietf.org; Tue, 02 Sep 2003 06:07:19 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2003 12:05:47 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h82A3m1n024875; Tue, 2 Sep 2003 12:04:23 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Sep 2003 11:06:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 11:06:42 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNwxfu1QemB4f1qTyeJoobPsJYx6AAcsjXg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Sep 2003 10:06:43.0375 (UTC) FILETIME=[E91073F0:01C37139] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: lundi 1 septembre 2003 22:17 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > "Pascal Thubert (pthubert)" wrote: >=20 > > > For any packet, if the interface through which the packet > > > is sent out is the MR-HA tunnel, then the Home Address must > > > be selected as the source address. The source must be set > > > to the link local address, if the destination of the packet > > > is a link local address. The Mobile Router MUST NOT set the > > > source address to Home Address if the packets are sent to > > > the visited link. > > > > > > > I agree with that text, but there's something missing to the last sentence. The Mobile > > Router may have other routes than via the MRHA tunnel. >=20 > ofcourse. >=20 > > For instance running a routing > > protocol locally in the visited network. For all these routes, the interface out will not > > he the MRHA tunnel, and SAS must select the appropriate address as it does normally as if > > Nemo was not there. >=20 > right. the CoA should be used. >=20 > > This is all normal SAS, considering that the global address on the > > MRHA is the home address. Can you please reword the last sentence? >=20 > what specific text are you looking for? I am not sure I understood > that from your email. we just want to place restriction on the use > of home address when the MR is on a visited link, which the > paragraph I proposed above does. >=20 I'm looking for some text that says that SAS works as defined in RFCs, with the Home Address considered as the global address on the MRHA tunnel. Your text gives examples of that, but the best is to refer to the existing definition. The first sentence of your text is the key example. I'd turn it into: " For Source Address Selection purposes, the Home Address is considered as the global address on the MRHA tunnel. Consequently, in most cases, the Home Address will be selected as the source address if and only if the interface through which the packet is sent out is the MR-HA tunnel.=20 " What do you think? Pascal From exim@www1.ietf.org Tue Sep 2 09:44:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25470 for ; Tue, 2 Sep 2003 09:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBDZ-0007o7-Kt for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 09:29:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DT9Io030003 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u9eg-0002tx-3F for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 07:49:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13489 for ; Tue, 2 Sep 2003 07:48:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u9ef-0002Me-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 07:49:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u9ee-0002Ma-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 07:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u5Me-0000CE-MT; Tue, 02 Sep 2003 03:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u0yS-0000ex-8D for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:32:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25447 for ; Mon, 1 Sep 2003 22:32:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u0yN-0006Jq-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:32:47 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19u0jM-0006SF-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:17:17 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h822Db92016628; Tue, 2 Sep 2003 11:13:37 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" Cc: Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 11:17:06 +0900 Message-ID: <000001c370f8$4e7310f0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Pascal and Vijay, I have a question. When does MR want to use SAS for what connectivity? It's not clear to me. Some cases that I can understand are as follows: 1) The connectivity between any node on visited link and MR itself(acting as MN) 2) The connectivity between any node on visited link and LFN/VMN in Mobile Network. In this case, I've just considered Mobile Network as a simple type with one egress and one ingress interface. Is there any other case? And, SAS can describe case 1), but not about case 2). I wondering if case 2) can be concerned in our discussion. If case 2) is possible without any route optimization, it'd be good because many of applications no longer depend on their MRHA tunnel for local connectivity. Regards, /Jongkeun > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, September 02, 2003 12:15 AM > To: Vijay Devarapalli > Cc: Jongkeun Na; nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > Hi again Vijay >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: mercredi 20 ao=FBt 2003 00:24 > > To: Pascal Thubert (pthubert) > > Cc: Jongkeun Na; nemo@ietf.org > > Subject: Source Address Selection (was Re: [nemo] crossover tunnel....) > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > When a MR joins a new link, there's more that happens than we actually > described. > > > > > > I suggest to insert a 5.7 chapter: SAS for mobile router > > > > > > In the process of Source Address Selection, the MRHA tunnel is > considered as > > > any other link, with the restriction that only a global address may be > selected. > > > > this is not necessarily true. link local addresses can be > > used as source and destination address in the inner IPv6 > > header. infact link local address are used, for example, > > if DHCPv6 messages are exchanged over the MR-HA tunnel. > > the outer IPv6 header ofcourse will contain MR's CoA and > > HA's address. > > > > > So when the MR is not at Home, the Home Address will be selected > as source > > > address when and only when the destination is reached via the > MRHA tunnel. > > > > right. > > > > > > > > The MR has a set of connected routes for its attached MNPs. It may > also > > > have some static routes and a set of routes obtained from a routing > protocol. > > > For all these routes, SAS takes place normally and if the MRHA > tunnel is not > > > the link to the next hop, the best scoped global address on that link > should > > > be preferred, avoiding the MIP encapsulation and the need for > global connectivity. > > > > I am not sure what you mean by global connectivity here? > > the rest of the paragraph makes sense. >=20 > I meant that the connectivity to the infrastructure may not be there and yet SAS > allows internal connectivity. Example between a VMN and a LFN in a mobile > network when the MR that owns the mobile network is not bound to its HA and > there's no MRHA tunnel. >=20 >=20 > > > > > In particular, when a MR forms a CoA from a visited prefix, it inserts > a > > > connected route to that prefix, over the associated egress interface, > in > > > its routing table. So when the MR initiates a socket to a node on > that link, > > > SAS will select the CareOf address as source. > > > > why? the MR may want to use Route Optimization with the > > node on the visited link. in this case, the MR-HA tunnel > > wouldnt be outgoing interface. the application on the > > MR may initiate a socket with the home address and depend > > on the kernel to add the Home Address option. when the > > packet is actually sent out on the visited link, the > > source address would be the CoA with the home address in > > the Home Address Option. > > > > but I agree with the general idea in your text. and I think > > it can be simplified. > > > > For any packet, if the interface through which the packet > > is sent out is the MR-HA tunnel, then the Home Address must > > be selected as the source address. The source must be set > > to the link local address, if the destination of the packet > > is a link local address. The Mobile Router MUST NOT set the > > source address to Home Address if the packets are sent to > > the visited link. > > >=20 > I agree with that text, but there's something missing to the last sentence. The > Mobile Router may have other routes than via the MRHA tunnel. For instance > running a routing protocol locally in the visited network. For all these routes, the > interface out will not he the MRHA tunnel, and SAS must select the appropriate > address as it does normally as if Nemo was not there. This is all normal SAS, > considering that the global address on the MRHA is the home address. Can you > please reword the last sentence? >=20 >=20 > Pascal From exim@www1.ietf.org Tue Sep 2 09:45:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25642 for ; Tue, 2 Sep 2003 09:45:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBSW-0003ii-DX for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 09:44:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DiZVD014284 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:44:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBST-0003gC-Gm for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:44:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25449 for ; Tue, 2 Sep 2003 09:44:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBSR-0000CC-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:44:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBPj-00005e-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:41:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u68H-0007PP-Vw; Tue, 02 Sep 2003 04:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u10Y-0000sG-Gk for nemo@optimus.ietf.org; Mon, 01 Sep 2003 22:35:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26278 for ; Mon, 1 Sep 2003 22:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u10T-0006mE-00 for nemo@ietf.org; Mon, 01 Sep 2003 22:34:58 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19tv6t-0001KW-00 for nemo@ietf.org; Mon, 01 Sep 2003 16:17:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h81KGWS01017; Mon, 1 Sep 2003 13:16:32 -0700 X-mProtect: <200309012016> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9wPZZl; Mon, 01 Sep 2003 13:16:30 PDT Message-ID: <3F53A91E.C08F78D7@iprg.nokia.com> Date: Mon, 01 Sep 2003 13:16:30 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > For any packet, if the interface through which the packet > > is sent out is the MR-HA tunnel, then the Home Address must > > be selected as the source address. The source must be set > > to the link local address, if the destination of the packet > > is a link local address. The Mobile Router MUST NOT set the > > source address to Home Address if the packets are sent to > > the visited link. > > > > I agree with that text, but there's something missing to the last sentence. The Mobile > Router may have other routes than via the MRHA tunnel. ofcourse. > For instance running a routing > protocol locally in the visited network. For all these routes, the interface out will not > he the MRHA tunnel, and SAS must select the appropriate address as it does normally as if > Nemo was not there. right. the CoA should be used. > This is all normal SAS, considering that the global address on the > MRHA is the home address. Can you please reword the last sentence? what specific text are you looking for? I am not sure I understood that from your email. we just want to place restriction on the use of home address when the MR is on a visited link, which the paragraph I proposed above does. Vijay From nemo-admin@ietf.org Tue Sep 2 09:53:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26323 for ; Tue, 2 Sep 2003 09:53:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBag-0004pu-3U; Tue, 02 Sep 2003 09:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAI4-0008Nq-Kc for nemo@optimus.ietf.org; Tue, 02 Sep 2003 08:29:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16738 for ; Tue, 2 Sep 2003 08:29:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uAI3-0000bt-00 for nemo@ietf.org; Tue, 02 Sep 2003 08:29:43 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19uAI2-0000bd-00 for nemo@ietf.org; Tue, 02 Sep 2003 08:29:42 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h82CQ492018969; Tue, 2 Sep 2003 21:26:04 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" Cc: Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 21:29:32 +0900 Message-ID: <000001c3714d$dc9ad160$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Please see inline. > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, September 02, 2003 6:59 PM > To: Jongkeun Na; Vijay Devarapalli > Cc: nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) > > > > Thanks for your explanation. > > > > > > The remote end may be on the visited link or some hops away. The key > > is whether > > > the route to the remote end is via the MRHA or not. If the route is > > via MRHA, then > > > the home address should be used as the global address on that link, > > that's all I'm > > > saying. > > Yes, I agree. But, how can MR decide to choose it's CoA of visited > link > > to send some packets to a node on some hops away? If MR can be > > configured by static routes, it's possible. However, I don't think > that > > is a thing we really want to find. There is something we should think > > about. There is some benefit if MR can use it's CoA for the outgoing > > connection that has the destination node on global internet, not just > > some hops away. That is because most of applications of Mobile Network > > will be client type except sort of emerging services like VoIP that is > > required to accept an incoming connection. Is there any problem in > using > > it's CoA for outgoing connections? Any difference in doing for nodes > on > > some hops away? > > > > I meant hops away but known by a local routing protocol (eg MANET). In > that case, a routing protocol has injected a best match than whatever > goes via MRHA (usually ::/0). Note that a MR could be configured with a > route via MRHA that's not ::/0 (for instance just your company's > prefix), in which case ::/0 would be via the access router using the > CareOf. > > If you mean that packet sourced by MR over MRHA may use CareOf as > source, yes, it's possible but it violates SAS. It may be interesting > for some application in a Mobile Host, but I do not perceive any point > for MRs. I believe that the SAS I described in a generic MN thing, not > just a MR thing. This is what I said at last IETF. > I meant just for local and short-lived outgoing connection and in case having best matched routes other than MRHA tunnel(default route ::/0). I can see your point generally. One comment regarding to SAS, in respect of MN, we need some sort of user preference about applying or not SAS for outgoing connection because doing it means no guarantee of session continuity. In some scenarios with no MRHA tunnel or unreachable HA, this option maybe helpful to user. In other words, my point is that applying SAS without considering mobility or user preference would break the continuity of session for Mobile Node. /Jongkeun > > > > > > > The MR has a connected route to the prefix of the CareOf. In your > case > > 2 (LFN to > > > end node in the visited network) the packets will not be routed via > > MRHA because > > > there is a better prefix match. Consequence the packets from the LFN > > will reach > > > the destination. But the end node will not have a route to the LFN > so > > the return > > > connectivity will be broken if there's no MRHA tunnel. > > > > > > We still have to find a solution for that. Maybe some proxy by the > MR, > > or some > > > advertisement of its MNP on the visited link? > > > > Yes, I agree. There are some points we need to come up with for route > > optimization. > > > > It's a very open question with many options. MR RA's and proxies MNP on > the visited link, MR RA's visited link in MNet and proxies the visited > prefix, etc... We need to think whether we want just one level of > bridging or if we can cover a mobile tree. And to which extend this goes > before global RO (MR-CN tunnel) takes over. I do not think it's a > priority for the WG at the moment, though. > > Pascal > > From exim@www1.ietf.org Tue Sep 2 09:54:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26401 for ; Tue, 2 Sep 2003 09:54:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBbG-0005HG-QY for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 09:53:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Drc15020276 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:53:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBbG-0005Gl-8v for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:53:38 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26349 for ; Tue, 2 Sep 2003 09:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBag-0004pu-3U; Tue, 02 Sep 2003 09:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAI4-0008Nq-Kc for nemo@optimus.ietf.org; Tue, 02 Sep 2003 08:29:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16738 for ; Tue, 2 Sep 2003 08:29:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uAI3-0000bt-00 for nemo@ietf.org; Tue, 02 Sep 2003 08:29:43 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 19uAI2-0000bd-00 for nemo@ietf.org; Tue, 02 Sep 2003 08:29:42 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h82CQ492018969; Tue, 2 Sep 2003 21:26:04 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , "'Vijay Devarapalli'" Cc: Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 21:29:32 +0900 Message-ID: <000001c3714d$dc9ad160$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Please see inline. > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > Sent: Tuesday, September 02, 2003 6:59 PM > To: Jongkeun Na; Vijay Devarapalli > Cc: nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) > > > > Thanks for your explanation. > > > > > > The remote end may be on the visited link or some hops away. The key > > is whether > > > the route to the remote end is via the MRHA or not. If the route is > > via MRHA, then > > > the home address should be used as the global address on that link, > > that's all I'm > > > saying. > > Yes, I agree. But, how can MR decide to choose it's CoA of visited > link > > to send some packets to a node on some hops away? If MR can be > > configured by static routes, it's possible. However, I don't think > that > > is a thing we really want to find. There is something we should think > > about. There is some benefit if MR can use it's CoA for the outgoing > > connection that has the destination node on global internet, not just > > some hops away. That is because most of applications of Mobile Network > > will be client type except sort of emerging services like VoIP that is > > required to accept an incoming connection. Is there any problem in > using > > it's CoA for outgoing connections? Any difference in doing for nodes > on > > some hops away? > > > > I meant hops away but known by a local routing protocol (eg MANET). In > that case, a routing protocol has injected a best match than whatever > goes via MRHA (usually ::/0). Note that a MR could be configured with a > route via MRHA that's not ::/0 (for instance just your company's > prefix), in which case ::/0 would be via the access router using the > CareOf. > > If you mean that packet sourced by MR over MRHA may use CareOf as > source, yes, it's possible but it violates SAS. It may be interesting > for some application in a Mobile Host, but I do not perceive any point > for MRs. I believe that the SAS I described in a generic MN thing, not > just a MR thing. This is what I said at last IETF. > I meant just for local and short-lived outgoing connection and in case having best matched routes other than MRHA tunnel(default route ::/0). I can see your point generally. One comment regarding to SAS, in respect of MN, we need some sort of user preference about applying or not SAS for outgoing connection because doing it means no guarantee of session continuity. In some scenarios with no MRHA tunnel or unreachable HA, this option maybe helpful to user. In other words, my point is that applying SAS without considering mobility or user preference would break the continuity of session for Mobile Node. /Jongkeun > > > > > > > The MR has a connected route to the prefix of the CareOf. In your > case > > 2 (LFN to > > > end node in the visited network) the packets will not be routed via > > MRHA because > > > there is a better prefix match. Consequence the packets from the LFN > > will reach > > > the destination. But the end node will not have a route to the LFN > so > > the return > > > connectivity will be broken if there's no MRHA tunnel. > > > > > > We still have to find a solution for that. Maybe some proxy by the > MR, > > or some > > > advertisement of its MNP on the visited link? > > > > Yes, I agree. There are some points we need to come up with for route > > optimization. > > > > It's a very open question with many options. MR RA's and proxies MNP on > the visited link, MR RA's visited link in MNet and proxies the visited > prefix, etc... We need to think whether we want just one level of > bridging or if we can cover a mobile tree. And to which extend this goes > before global RO (MR-CN tunnel) takes over. I do not think it's a > priority for the WG at the moment, though. > > Pascal > > From nemo-admin@ietf.org Tue Sep 2 13:11:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16011 for ; Tue, 2 Sep 2003 13:11:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEgI-00034z-BA; Tue, 02 Sep 2003 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEfp-00034C-S2 for nemo@optimus.ietf.org; Tue, 02 Sep 2003 13:10:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15861 for ; Tue, 2 Sep 2003 13:10:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEfn-0000Li-00 for nemo@ietf.org; Tue, 02 Sep 2003 13:10:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19uEfn-0000Ka-00 for nemo@ietf.org; Tue, 02 Sep 2003 13:10:31 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h82H9qd29876; Tue, 2 Sep 2003 10:09:52 -0700 X-mProtect: <200309021709> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQlrFd7; Tue, 02 Sep 2003 10:09:50 PDT Message-ID: <3F54CEDF.79EE1B5C@iprg.nokia.com> Date: Tue, 02 Sep 2003 10:09:51 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Pascal, how about this? The Home Address is considered as the global address on the MR-HA tunnel. Consequently, the Home Address will be selected as the source address if and only if the interface through which the packet is sent out is the MR-HA tunnel. If the destination of a packet sent through the MR-HA tunnel is set to Home Agent's link local address, then the source address must be set to the link local address of the Mobile Router. The source address MUST NOT bet set to the Home Address if the packets are sent to the visited link. Vijay "Pascal Thubert (pthubert)" wrote: > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: lundi 1 septembre 2003 22:17 > > To: Pascal Thubert (pthubert) > > Cc: nemo@ietf.org > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > For any packet, if the interface through which the packet > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > be selected as the source address. The source must be set > > > > to the link local address, if the destination of the packet > > > > is a link local address. The Mobile Router MUST NOT set the > > > > source address to Home Address if the packets are sent to > > > > the visited link. > > > > > > > > > > I agree with that text, but there's something missing to the last > sentence. The Mobile > > > Router may have other routes than via the MRHA tunnel. > > > > ofcourse. > > > > > For instance running a routing > > > protocol locally in the visited network. For all these routes, the > interface out will not > > > he the MRHA tunnel, and SAS must select the appropriate address as > it does normally as if > > > Nemo was not there. > > > > right. the CoA should be used. > > > > > This is all normal SAS, considering that the global address on the > > > MRHA is the home address. Can you please reword the last sentence? > > > > what specific text are you looking for? I am not sure I understood > > that from your email. we just want to place restriction on the use > > of home address when the MR is on a visited link, which the > > paragraph I proposed above does. > > > > I'm looking for some text that says that SAS works as defined in RFCs, > with the Home Address considered as the global address on the MRHA > tunnel. Your text gives examples of that, but the best is to refer to > the existing definition. The first sentence of your text is the key > example. I'd turn it into: > > " > For Source Address Selection purposes, the Home Address is considered as > the global address on the MRHA tunnel. Consequently, in most cases, the > Home Address will be selected as the source address if and only if the > interface through which the packet is sent out is the MR-HA tunnel. > " > > What do you think? > > Pascal From exim@www1.ietf.org Tue Sep 2 13:12:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16214 for ; Tue, 2 Sep 2003 13:12:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEgy-000385-W8 for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 13:11:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82HBiTh012025 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 13:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEgy-00037s-Po for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 13:11:44 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16010 for ; Tue, 2 Sep 2003 13:11:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEgI-00034z-BA; Tue, 02 Sep 2003 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEfp-00034C-S2 for nemo@optimus.ietf.org; Tue, 02 Sep 2003 13:10:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15861 for ; Tue, 2 Sep 2003 13:10:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEfn-0000Li-00 for nemo@ietf.org; Tue, 02 Sep 2003 13:10:31 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19uEfn-0000Ka-00 for nemo@ietf.org; Tue, 02 Sep 2003 13:10:31 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h82H9qd29876; Tue, 2 Sep 2003 10:09:52 -0700 X-mProtect: <200309021709> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQlrFd7; Tue, 02 Sep 2003 10:09:50 PDT Message-ID: <3F54CEDF.79EE1B5C@iprg.nokia.com> Date: Tue, 02 Sep 2003 10:09:51 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pascal, how about this? The Home Address is considered as the global address on the MR-HA tunnel. Consequently, the Home Address will be selected as the source address if and only if the interface through which the packet is sent out is the MR-HA tunnel. If the destination of a packet sent through the MR-HA tunnel is set to Home Agent's link local address, then the source address must be set to the link local address of the Mobile Router. The source address MUST NOT bet set to the Home Address if the packets are sent to the visited link. Vijay "Pascal Thubert (pthubert)" wrote: > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: lundi 1 septembre 2003 22:17 > > To: Pascal Thubert (pthubert) > > Cc: nemo@ietf.org > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > For any packet, if the interface through which the packet > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > be selected as the source address. The source must be set > > > > to the link local address, if the destination of the packet > > > > is a link local address. The Mobile Router MUST NOT set the > > > > source address to Home Address if the packets are sent to > > > > the visited link. > > > > > > > > > > I agree with that text, but there's something missing to the last > sentence. The Mobile > > > Router may have other routes than via the MRHA tunnel. > > > > ofcourse. > > > > > For instance running a routing > > > protocol locally in the visited network. For all these routes, the > interface out will not > > > he the MRHA tunnel, and SAS must select the appropriate address as > it does normally as if > > > Nemo was not there. > > > > right. the CoA should be used. > > > > > This is all normal SAS, considering that the global address on the > > > MRHA is the home address. Can you please reword the last sentence? > > > > what specific text are you looking for? I am not sure I understood > > that from your email. we just want to place restriction on the use > > of home address when the MR is on a visited link, which the > > paragraph I proposed above does. > > > > I'm looking for some text that says that SAS works as defined in RFCs, > with the Home Address considered as the global address on the MRHA > tunnel. Your text gives examples of that, but the best is to refer to > the existing definition. The first sentence of your text is the key > example. I'd turn it into: > > " > For Source Address Selection purposes, the Home Address is considered as > the global address on the MRHA tunnel. Consequently, in most cases, the > Home Address will be selected as the source address if and only if the > interface through which the packet is sent out is the MR-HA tunnel. > " > > What do you think? > > Pascal From nemo-admin@ietf.org Tue Sep 2 18:19:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13400 for ; Tue, 2 Sep 2003 18:19:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJUM-0004LO-PO; Tue, 02 Sep 2003 18:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJUF-0004Kj-PT for nemo@optimus.ietf.org; Tue, 02 Sep 2003 18:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13321 for ; Tue, 2 Sep 2003 18:18:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJUC-0001Na-00 for nemo@ietf.org; Tue, 02 Sep 2003 18:18:52 -0400 Received: from puppet.cs.toronto.edu ([128.100.3.169] helo=cs.toronto.edu) by ietf-mx with esmtp (Exim 4.12) id 19uJUC-0001NX-00 for nemo@ietf.org; Tue, 02 Sep 2003 18:18:52 -0400 Received: from localhost (delara@localhost) by cs.toronto.edu (8.11.6/8.11.6) with ESMTP id h82MIq906838 for ; Tue, 2 Sep 2003 18:18:52 -0400 Date: Tue, 2 Sep 2003 18:18:52 -0400 (EDT) From: Eyal de Lara X-X-Sender: delara@puppet.cs To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] MobiCom 2003 additional hotel available Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Please excuse us if you get multiple copies of this announcement. ---------------------------------------------------------------------- MobiCom 2003 additional hotel available Rooms at the main hotel for MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, are now fully sold out on some nights of the conference, and we have arranged an additional nearby hotel to handle the overflow. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in San Diego, California. We have now arranged an additional block of rooms for MobiCom attendees at the same rate at the U.S. Grant, a Wyndham Historic Hotel, which is located one block from the Westin Horton Plaza. MobiCom is the premier international forum addressing research in all areas of mobile computing and wireless and mobile networking at the link layer and above. For more information on MobiCom 2003, including hotel details and details on how to register to attend, please see the MobiCom 2003 web pages at http://www.sigmobile.org/mobicom/2003/ We have a very strong program this year, including 27 technical papers describing the best of recent research in mobile computing and networking, plus exciting research demos, a panel discussion on security and privacy in mobile and wireless systems, a student poster session, and a conference dinner banquet cruise. MobiCom 2003 will also feature 2 invited talks: - Keynote Speaker: Dr. Paul J. Kolodzy, Director of the Wireless Network Security Center (WiNSeC) at Stevens Institute of Technology, and previously Senior Spectrum Policy Advisor and Director of the Spectrum Policy Task Force at the United States FCC, and Program Manager at DARPA. - Luncheon Speaker: Dr. Ian F. Akyildiz, Ken Byers Distinguished Chair Professor in Telecommunications, School of Electrical and Computer Engineering, Georgia Institute of Technology. Professor Akyildiz will speak on "InterPlaNetary Internet: State-of-the-Art and Research Challenges". The conference will also include 5 tutorials on the latest research areas and background topics in mobile computing and networking: - Secure Routing in Ad Hoc Networks - Public-Area Wireless Networks - Mobile Ad Hoc Networking - IP Mobility Support in a Mobile Internet - Topology Control in Wireless Ad Hoc Networks MobiCom will also have 6 full-day workshops on emerging topics related to mobile computing and networking: - DIALM-POMC 2003 Joint Workshop on Foundations of Mobile Computing - MobiDE 2003: The Third ACM International Workshop on Data Engineering for Wireless and Mobile Access - MSWiM 2003: The Sixth ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems - WiSe 2003: The Second ACM International Workshop on Wireless Security - WMASH 2003: The First ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots - WSNA 2003: The Second ACM International Workshop on Wireless Sensor Networks and Applications We look forward to seeing you in San Diego for MobiCom 2003! ---------------------------------------------------------------------- From exim@www1.ietf.org Tue Sep 2 18:19:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13416 for ; Tue, 2 Sep 2003 18:19:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJUZ-0004Nz-IW for nemo-archive@odin.ietf.org; Tue, 02 Sep 2003 18:19:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82MJFHc016859 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 18:19:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJUZ-0004Nq-DI for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 18:19:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13351 for ; Tue, 2 Sep 2003 18:19:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJUW-0001Ny-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 18:19:12 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uJUW-0001Nv-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 18:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJUM-0004LO-PO; Tue, 02 Sep 2003 18:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uJUF-0004Kj-PT for nemo@optimus.ietf.org; Tue, 02 Sep 2003 18:18:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13321 for ; Tue, 2 Sep 2003 18:18:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uJUC-0001Na-00 for nemo@ietf.org; Tue, 02 Sep 2003 18:18:52 -0400 Received: from puppet.cs.toronto.edu ([128.100.3.169] helo=cs.toronto.edu) by ietf-mx with esmtp (Exim 4.12) id 19uJUC-0001NX-00 for nemo@ietf.org; Tue, 02 Sep 2003 18:18:52 -0400 Received: from localhost (delara@localhost) by cs.toronto.edu (8.11.6/8.11.6) with ESMTP id h82MIq906838 for ; Tue, 2 Sep 2003 18:18:52 -0400 Date: Tue, 2 Sep 2003 18:18:52 -0400 (EDT) From: Eyal de Lara X-X-Sender: delara@puppet.cs To: nemo@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] MobiCom 2003 additional hotel available Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Please excuse us if you get multiple copies of this announcement. ---------------------------------------------------------------------- MobiCom 2003 additional hotel available Rooms at the main hotel for MobiCom 2003, the Ninth Annual International Conference on Mobile Computing and Networking, are now fully sold out on some nights of the conference, and we have arranged an additional nearby hotel to handle the overflow. MobiCom 2003 will be held September 14-19, 2003, at the Westin Horton Plaza Hotel in San Diego, California. We have now arranged an additional block of rooms for MobiCom attendees at the same rate at the U.S. Grant, a Wyndham Historic Hotel, which is located one block from the Westin Horton Plaza. MobiCom is the premier international forum addressing research in all areas of mobile computing and wireless and mobile networking at the link layer and above. For more information on MobiCom 2003, including hotel details and details on how to register to attend, please see the MobiCom 2003 web pages at http://www.sigmobile.org/mobicom/2003/ We have a very strong program this year, including 27 technical papers describing the best of recent research in mobile computing and networking, plus exciting research demos, a panel discussion on security and privacy in mobile and wireless systems, a student poster session, and a conference dinner banquet cruise. MobiCom 2003 will also feature 2 invited talks: - Keynote Speaker: Dr. Paul J. Kolodzy, Director of the Wireless Network Security Center (WiNSeC) at Stevens Institute of Technology, and previously Senior Spectrum Policy Advisor and Director of the Spectrum Policy Task Force at the United States FCC, and Program Manager at DARPA. - Luncheon Speaker: Dr. Ian F. Akyildiz, Ken Byers Distinguished Chair Professor in Telecommunications, School of Electrical and Computer Engineering, Georgia Institute of Technology. Professor Akyildiz will speak on "InterPlaNetary Internet: State-of-the-Art and Research Challenges". The conference will also include 5 tutorials on the latest research areas and background topics in mobile computing and networking: - Secure Routing in Ad Hoc Networks - Public-Area Wireless Networks - Mobile Ad Hoc Networking - IP Mobility Support in a Mobile Internet - Topology Control in Wireless Ad Hoc Networks MobiCom will also have 6 full-day workshops on emerging topics related to mobile computing and networking: - DIALM-POMC 2003 Joint Workshop on Foundations of Mobile Computing - MobiDE 2003: The Third ACM International Workshop on Data Engineering for Wireless and Mobile Access - MSWiM 2003: The Sixth ACM International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems - WiSe 2003: The Second ACM International Workshop on Wireless Security - WMASH 2003: The First ACM International Workshop on Wireless Mobile Applications and Services on WLAN Hotspots - WSNA 2003: The Second ACM International Workshop on Wireless Sensor Networks and Applications We look forward to seeing you in San Diego for MobiCom 2003! ---------------------------------------------------------------------- From nemo-admin@ietf.org Wed Sep 3 03:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11770 for ; Wed, 3 Sep 2003 03:51:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSPw-000604-3w; Wed, 03 Sep 2003 03:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSPM-0005yK-Kx for nemo@optimus.ietf.org; Wed, 03 Sep 2003 03:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11605 for ; Wed, 3 Sep 2003 03:50:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSPJ-0000Zh-00 for nemo@ietf.org; Wed, 03 Sep 2003 03:50:25 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19uSPI-0000YC-00 for nemo@ietf.org; Wed, 03 Sep 2003 03:50:24 -0400 Received: from fonoll.ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h837npZv011272 for ; Wed, 3 Sep 2003 09:49:51 +0200 (MET DST) Received: (from ew2004@localhost) by fonoll.ac.upc.es (8.12.8/8.12.8) id h837npjm000592 for nemo@ietf.org; Wed, 3 Sep 2003 09:49:51 +0200 (MET DST) Date: Wed, 3 Sep 2003 09:49:51 +0200 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20030903074951.GA589@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roura.ac.upc.es id h837npZv011272 Content-Transfer-Encoding: quoted-printable Subject: [nemo] European Wireless'04 CFP reminder Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Dear Colleague, We would like to remind you that the submission deadline for EW2004 is 10th of September, 2003! All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. ------------------------------------------------------------------------- EW2004 The 5th European Wireless Conference Mobile and Wireless Systems beyond 3G http://www.ac.upc.es/EW2004=20 February 24-27, 2004 Technical University of Catalonia (UPC) - Barcelona, Spain CONFERENCE SCOPE In order to be able to be connected anywhere and at anytime a seamless ac= cess to the various access technologies is needed providing the adequate QoS t= o=20 diverse applications.=20 The 5th European Wireless Conference focuses on technologies, protocols,=20 services and applications that will enable a full seamless and nomadic us= er=20 access to new classes of person to person, device to device and device=20 to person applications. TOPICS Technical papers describing original, previously unpublished research are= solicited.=20 Specific topics of interest include, but are not limited to, the followin= g: * Adaptive Antennas * Base Station Technology * Indoor Channel Modeling( Wave Propagation and Measurements * Integration of Radio Localization Systems into Wireless User Terminals * Integration of Terrestrial and Satellite Networks * Interference Mitigation and Management Techniques * Power and Interference Control * Power Management for small terminals * Protocols for Air Interfaces and Networks * Short Range Communication Systems * Signal Processing Techniques for Communications * Analysis( Simulation and Measurements of Mobile and Wireless Systems * High Altitude Platforms and Satellites * Internetworking between Different Access Technologies * Mobile Agents * Mobile and Wireless Applications * Mobility Management * Multiple Access Schemes * Positioning=20 * QoS in Mobile and Wireless Networks * Routing in Ad hoc Networks * Security and robustness in wireless networks * Sensor Network Planning and Deployment * Wireless Ad hoc Networks * Wireless LANs PAPER SUBMISSION INSTRUCTIONS Papers for the conference should be written in English and with a limit o= f 12 double=20 spaced pages. All paper submissions will be handled electronically, following the instr= uctions at: http://www.ac.upc.es/EW2004 All papers will be reviewed by the program committee members. Accepted papers will be published in the conference proceedings.=20 IMPORTANT DATES Full papers due: September 10th 2003 Notification of Acceptance: November 14th 2003 Camera Ready due: December 12th 2003 GENERAL CHAIR:=20 Olga Casals, (Technical University of Catalonia, UPC, Spain) Jorge Garcia-Vidal (Technical University of Catalonia, UPC, Spain) STEERING COMMITTEE CHAIR:=20 Bernhard Walke (Aachen University of Technology, Germany) TECHNICAL PROGRAM CO-CHAIRS: Miguel A. Lagunas (CTTC, Spain) Ioannis Stavrakakis (University of Athens, Greece) TUTORIAL CHAIR: Jorge Garc=EDa-Vidal (UPC, Spain) LOCAL ARRANGEMENTS CO-CHAIRS: Carles Ant=F3n (CTTC, Spain) Jose M. Barcel=F3 (UPC, Spain) Lloren=E7 Cerd=E0 (UPC, Spain) TECHNICAL PROGRAM COMMITTEE: R. Agust=ED (UPC, Spain) I. Akyildiz (Georgia Ins. of Technology, USA) E. Altman (INRIA, France) A. Art=E9s (Univ. Carlos III, Spain) S. Benedetto (Politecnico de Torino, Italy) C. Blondia (Univ. of Antwerp, Belgium) E. Bonek (TU of Viena, Austria) A. Campbell (Columbia University, USA) V. Casares (UPV, Spain) E. Casilari (Univ. de Malaga, Spain) L. Castedo (Univ. de La Coru=F1a, Spain) M. Conti (IIT/CNR, Italy) L. Correia (IST, Portugal) L. Cuthbert (Univ. of London, UK) J. Dunlop (Univ. of Strathclyde, UK) S. Giordano (EPFL, Switzerland) H. Kawashima (Tokio Univ. of Agriculture & Technology, Japan) U. K=F6rner (Univ. of Lund, Sweden) P. Kuehn (Univ. of Stuttgart, Germany) L. Lenzini (Univ. of Pisa, Italy) J. M. Paez Borrallo (UPM, Spain) J. Paradells (UPC, Spain) C. Rosenberg (Purdue University, USA) H. St=FCttgen (NEC, Germany) A. Svensson (Chalmers, Sweden) R. Tafazolli (Univ. of Surrey, UK) Y. Takahashi (Kyoto University, Japan) L. Tassiulas (Univ. of Maryland, USA) S. Tohme (ENST, France) P. Tran-Gia (Univ. of W=FCrzburg, Germany) M. Uylat (Univ. of Waterloo, Canada) A. Valko (Ericsson, Sweden) A. Vilavaara (Nokia Research Center, Finland) A. Wolisz (Univ. of Berlin, Germany) J. Zander (KTH Stockholm, Sweden) M. Zukerman (Univ. of Melbourne, Australia) EW2004 CONTACT e-mail: ew2004@ac.upc.es FINANCE CHAIR Volker Schanz, VDE/ITG, Germany CONFERENCE SECRETARIAT VDE-Conference Department Stresemannallee 1560596 Frankfurt-Main Germany Phone: +49-69-6308-202 Fax: +49-69-97315213 e-mail: vde-conferences@vde.com URL: www.vde.com=20 From exim@www1.ietf.org Wed Sep 3 03:51:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11812 for ; Wed, 3 Sep 2003 03:51:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSQ4-000622-TJ for nemo-archive@odin.ietf.org; Wed, 03 Sep 2003 03:51:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h837pB8P023179 for nemo-archive@odin.ietf.org; Wed, 3 Sep 2003 03:51:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSQ2-00061j-Mg for nemo-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 03:51:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11716 for ; Wed, 3 Sep 2003 03:51:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSQ0-0000cd-00 for nemo-web-archive@ietf.org; Wed, 03 Sep 2003 03:51:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uSPy-0000cY-00 for nemo-web-archive@ietf.org; Wed, 03 Sep 2003 03:51:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSPw-000604-3w; Wed, 03 Sep 2003 03:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uSPM-0005yK-Kx for nemo@optimus.ietf.org; Wed, 03 Sep 2003 03:50:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11605 for ; Wed, 3 Sep 2003 03:50:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uSPJ-0000Zh-00 for nemo@ietf.org; Wed, 03 Sep 2003 03:50:25 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19uSPI-0000YC-00 for nemo@ietf.org; Wed, 03 Sep 2003 03:50:24 -0400 Received: from fonoll.ac.upc.es (fonoll.ac.upc.es [147.83.32.14]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h837npZv011272 for ; Wed, 3 Sep 2003 09:49:51 +0200 (MET DST) Received: (from ew2004@localhost) by fonoll.ac.upc.es (8.12.8/8.12.8) id h837npjm000592 for nemo@ietf.org; Wed, 3 Sep 2003 09:49:51 +0200 (MET DST) Date: Wed, 3 Sep 2003 09:49:51 +0200 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20030903074951.GA589@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by roura.ac.upc.es id h837npZv011272 Content-Transfer-Encoding: quoted-printable Subject: [nemo] European Wireless'04 CFP reminder Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Dear Colleague, We would like to remind you that the submission deadline for EW2004 is 10th of September, 2003! All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. ------------------------------------------------------------------------- EW2004 The 5th European Wireless Conference Mobile and Wireless Systems beyond 3G http://www.ac.upc.es/EW2004=20 February 24-27, 2004 Technical University of Catalonia (UPC) - Barcelona, Spain CONFERENCE SCOPE In order to be able to be connected anywhere and at anytime a seamless ac= cess to the various access technologies is needed providing the adequate QoS t= o=20 diverse applications.=20 The 5th European Wireless Conference focuses on technologies, protocols,=20 services and applications that will enable a full seamless and nomadic us= er=20 access to new classes of person to person, device to device and device=20 to person applications. TOPICS Technical papers describing original, previously unpublished research are= solicited.=20 Specific topics of interest include, but are not limited to, the followin= g: * Adaptive Antennas * Base Station Technology * Indoor Channel Modeling( Wave Propagation and Measurements * Integration of Radio Localization Systems into Wireless User Terminals * Integration of Terrestrial and Satellite Networks * Interference Mitigation and Management Techniques * Power and Interference Control * Power Management for small terminals * Protocols for Air Interfaces and Networks * Short Range Communication Systems * Signal Processing Techniques for Communications * Analysis( Simulation and Measurements of Mobile and Wireless Systems * High Altitude Platforms and Satellites * Internetworking between Different Access Technologies * Mobile Agents * Mobile and Wireless Applications * Mobility Management * Multiple Access Schemes * Positioning=20 * QoS in Mobile and Wireless Networks * Routing in Ad hoc Networks * Security and robustness in wireless networks * Sensor Network Planning and Deployment * Wireless Ad hoc Networks * Wireless LANs PAPER SUBMISSION INSTRUCTIONS Papers for the conference should be written in English and with a limit o= f 12 double=20 spaced pages. All paper submissions will be handled electronically, following the instr= uctions at: http://www.ac.upc.es/EW2004 All papers will be reviewed by the program committee members. Accepted papers will be published in the conference proceedings.=20 IMPORTANT DATES Full papers due: September 10th 2003 Notification of Acceptance: November 14th 2003 Camera Ready due: December 12th 2003 GENERAL CHAIR:=20 Olga Casals, (Technical University of Catalonia, UPC, Spain) Jorge Garcia-Vidal (Technical University of Catalonia, UPC, Spain) STEERING COMMITTEE CHAIR:=20 Bernhard Walke (Aachen University of Technology, Germany) TECHNICAL PROGRAM CO-CHAIRS: Miguel A. Lagunas (CTTC, Spain) Ioannis Stavrakakis (University of Athens, Greece) TUTORIAL CHAIR: Jorge Garc=EDa-Vidal (UPC, Spain) LOCAL ARRANGEMENTS CO-CHAIRS: Carles Ant=F3n (CTTC, Spain) Jose M. Barcel=F3 (UPC, Spain) Lloren=E7 Cerd=E0 (UPC, Spain) TECHNICAL PROGRAM COMMITTEE: R. Agust=ED (UPC, Spain) I. Akyildiz (Georgia Ins. of Technology, USA) E. Altman (INRIA, France) A. Art=E9s (Univ. Carlos III, Spain) S. Benedetto (Politecnico de Torino, Italy) C. Blondia (Univ. of Antwerp, Belgium) E. Bonek (TU of Viena, Austria) A. Campbell (Columbia University, USA) V. Casares (UPV, Spain) E. Casilari (Univ. de Malaga, Spain) L. Castedo (Univ. de La Coru=F1a, Spain) M. Conti (IIT/CNR, Italy) L. Correia (IST, Portugal) L. Cuthbert (Univ. of London, UK) J. Dunlop (Univ. of Strathclyde, UK) S. Giordano (EPFL, Switzerland) H. Kawashima (Tokio Univ. of Agriculture & Technology, Japan) U. K=F6rner (Univ. of Lund, Sweden) P. Kuehn (Univ. of Stuttgart, Germany) L. Lenzini (Univ. of Pisa, Italy) J. M. Paez Borrallo (UPM, Spain) J. Paradells (UPC, Spain) C. Rosenberg (Purdue University, USA) H. St=FCttgen (NEC, Germany) A. Svensson (Chalmers, Sweden) R. Tafazolli (Univ. of Surrey, UK) Y. Takahashi (Kyoto University, Japan) L. Tassiulas (Univ. of Maryland, USA) S. Tohme (ENST, France) P. Tran-Gia (Univ. of W=FCrzburg, Germany) M. Uylat (Univ. of Waterloo, Canada) A. Valko (Ericsson, Sweden) A. Vilavaara (Nokia Research Center, Finland) A. Wolisz (Univ. of Berlin, Germany) J. Zander (KTH Stockholm, Sweden) M. Zukerman (Univ. of Melbourne, Australia) EW2004 CONTACT e-mail: ew2004@ac.upc.es FINANCE CHAIR Volker Schanz, VDE/ITG, Germany CONFERENCE SECRETARIAT VDE-Conference Department Stresemannallee 1560596 Frankfurt-Main Germany Phone: +49-69-6308-202 Fax: +49-69-97315213 e-mail: vde-conferences@vde.com URL: www.vde.com=20 From nemo-admin@ietf.org Thu Sep 4 05:22:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05632 for ; Thu, 4 Sep 2003 05:22:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqJY-0005FO-ML; Thu, 04 Sep 2003 05:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqJC-0005Ek-0j for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:21:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05567 for ; Thu, 4 Sep 2003 05:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqJ8-0004HC-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:21:38 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19uqJ7-0004Fs-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:21:37 -0400 Received: from huez (wifi-139-152.sfc.wide.ad.jp [203.178.139.152]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id C8EB25D0E0 for ; Thu, 4 Sep 2003 18:21:06 +0900 (JST) Date: Thu, 4 Sep 2003 18:15:41 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) Message-Id: <20030904181541.779d2a80.ernst@sfc.wide.ad.jp> In-Reply-To: <3F54CEDF.79EE1B5C@iprg.nokia.com> References: <3F54CEDF.79EE1B5C@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > how about this? > > The Home Address is considered as the global address on the > MR-HA tunnel. Consequently, the Home Address will be selected > as the source address if and only if the interface through > which the packet is sent out is the MR-HA tunnel. If the > destination of a packet sent through the MR-HA tunnel is set > to Home Agent's link local address, then the source address > must be set to the link local address of the Mobile Router. > The source address MUST NOT bet set to the Home Address if > the packets are sent to the visited link. The text is clear, but, if I understand the issue well, didn't we have: R03: All traffic exchanged between a MNN and a CN in the global Internet MUST transit through the bidirectional tunnel. in "Network Mobility Support Goals and Requirements" So, it seems to me that we are diverging from what we have agreed on. Doesn't look like Basic Support to me. Thierry. > > Vijay > > > "Pascal Thubert (pthubert)" wrote: > > > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > Sent: lundi 1 septembre 2003 22:17 > > > To: Pascal Thubert (pthubert) > > > Cc: nemo@ietf.org > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > For any packet, if the interface through which the packet > > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > > be selected as the source address. The source must be set > > > > > to the link local address, if the destination of the packet > > > > > is a link local address. The Mobile Router MUST NOT set the > > > > > source address to Home Address if the packets are sent to > > > > > the visited link. > > > > > > > > > > > > > I agree with that text, but there's something missing to the last > > sentence. The Mobile > > > > Router may have other routes than via the MRHA tunnel. > > > > > > ofcourse. > > > > > > > For instance running a routing > > > > protocol locally in the visited network. For all these routes, the > > interface out will not > > > > he the MRHA tunnel, and SAS must select the appropriate address as > > it does normally as if > > > > Nemo was not there. > > > > > > right. the CoA should be used. > > > > > > > This is all normal SAS, considering that the global address on the > > > > MRHA is the home address. Can you please reword the last sentence? > > > > > > what specific text are you looking for? I am not sure I understood > > > that from your email. we just want to place restriction on the use > > > of home address when the MR is on a visited link, which the > > > paragraph I proposed above does. > > > > > > > I'm looking for some text that says that SAS works as defined in RFCs, > > with the Home Address considered as the global address on the MRHA > > tunnel. Your text gives examples of that, but the best is to refer to > > the existing definition. The first sentence of your text is the key > > example. I'd turn it into: > > > > " > > For Source Address Selection purposes, the Home Address is considered as > > the global address on the MRHA tunnel. Consequently, in most cases, the > > Home Address will be selected as the source address if and only if the > > interface through which the packet is sent out is the MR-HA tunnel. > > " > > > > What do you think? > > > > Pascal > > From exim@www1.ietf.org Thu Sep 4 05:22:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05651 for ; Thu, 4 Sep 2003 05:22:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqJj-0005GM-3q for nemo-archive@odin.ietf.org; Thu, 04 Sep 2003 05:22:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h849MFwN020229 for nemo-archive@odin.ietf.org; Thu, 4 Sep 2003 05:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqJi-0005GC-18 for nemo-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 05:22:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05601 for ; Thu, 4 Sep 2003 05:22:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqJe-0004Hk-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:22:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uqJd-0004Hg-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:22:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqJY-0005FO-ML; Thu, 04 Sep 2003 05:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqJC-0005Ek-0j for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:21:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05567 for ; Thu, 4 Sep 2003 05:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqJ8-0004HC-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:21:38 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19uqJ7-0004Fs-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:21:37 -0400 Received: from huez (wifi-139-152.sfc.wide.ad.jp [203.178.139.152]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id C8EB25D0E0 for ; Thu, 4 Sep 2003 18:21:06 +0900 (JST) Date: Thu, 4 Sep 2003 18:15:41 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) Message-Id: <20030904181541.779d2a80.ernst@sfc.wide.ad.jp> In-Reply-To: <3F54CEDF.79EE1B5C@iprg.nokia.com> References: <3F54CEDF.79EE1B5C@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > how about this? > > The Home Address is considered as the global address on the > MR-HA tunnel. Consequently, the Home Address will be selected > as the source address if and only if the interface through > which the packet is sent out is the MR-HA tunnel. If the > destination of a packet sent through the MR-HA tunnel is set > to Home Agent's link local address, then the source address > must be set to the link local address of the Mobile Router. > The source address MUST NOT bet set to the Home Address if > the packets are sent to the visited link. The text is clear, but, if I understand the issue well, didn't we have: R03: All traffic exchanged between a MNN and a CN in the global Internet MUST transit through the bidirectional tunnel. in "Network Mobility Support Goals and Requirements" So, it seems to me that we are diverging from what we have agreed on. Doesn't look like Basic Support to me. Thierry. > > Vijay > > > "Pascal Thubert (pthubert)" wrote: > > > > > -----Original Message----- > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > Sent: lundi 1 septembre 2003 22:17 > > > To: Pascal Thubert (pthubert) > > > Cc: nemo@ietf.org > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > For any packet, if the interface through which the packet > > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > > be selected as the source address. The source must be set > > > > > to the link local address, if the destination of the packet > > > > > is a link local address. The Mobile Router MUST NOT set the > > > > > source address to Home Address if the packets are sent to > > > > > the visited link. > > > > > > > > > > > > > I agree with that text, but there's something missing to the last > > sentence. The Mobile > > > > Router may have other routes than via the MRHA tunnel. > > > > > > ofcourse. > > > > > > > For instance running a routing > > > > protocol locally in the visited network. For all these routes, the > > interface out will not > > > > he the MRHA tunnel, and SAS must select the appropriate address as > > it does normally as if > > > > Nemo was not there. > > > > > > right. the CoA should be used. > > > > > > > This is all normal SAS, considering that the global address on the > > > > MRHA is the home address. Can you please reword the last sentence? > > > > > > what specific text are you looking for? I am not sure I understood > > > that from your email. we just want to place restriction on the use > > > of home address when the MR is on a visited link, which the > > > paragraph I proposed above does. > > > > > > > I'm looking for some text that says that SAS works as defined in RFCs, > > with the Home Address considered as the global address on the MRHA > > tunnel. Your text gives examples of that, but the best is to refer to > > the existing definition. The first sentence of your text is the key > > example. I'd turn it into: > > > > " > > For Source Address Selection purposes, the Home Address is considered as > > the global address on the MRHA tunnel. Consequently, in most cases, the > > Home Address will be selected as the source address if and only if the > > interface through which the packet is sent out is the MR-HA tunnel. > > " > > > > What do you think? > > > > Pascal > > From nemo-admin@ietf.org Thu Sep 4 05:30:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06171 for ; Thu, 4 Sep 2003 05:30:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqRF-0005X3-Hk; Thu, 04 Sep 2003 05:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqQP-0005Vr-8g for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:29:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06070 for ; Thu, 4 Sep 2003 05:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqQL-0004Xe-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:29:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19uqQL-0004Wy-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:29:05 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2003 11:27:36 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h849Q8p0017081; Thu, 4 Sep 2003 11:26:15 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Sep 2003 10:28:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Thu, 4 Sep 2003 10:28:28 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNyxieh3j5sy5CGQUix76P8q2PVlQAAIj5A From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 04 Sep 2003 09:28:29.0267 (UTC) FILETIME=[E67EDA30:01C372C6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Well, no, since this applies only to traffic between MR and CN :) Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 4 septembre 2003 11:16 > To: nemo@ietf.org > Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 >=20 > > how about this? > > > > The Home Address is considered as the global address on the > > MR-HA tunnel. Consequently, the Home Address will be selected > > as the source address if and only if the interface through > > which the packet is sent out is the MR-HA tunnel. If the > > destination of a packet sent through the MR-HA tunnel is set > > to Home Agent's link local address, then the source address > > must be set to the link local address of the Mobile Router. > > The source address MUST NOT bet set to the Home Address if > > the packets are sent to the visited link. >=20 > The text is clear, but, if I understand the issue well, didn't we have: >=20 > R03: All traffic exchanged between a MNN and a CN in the global > Internet MUST transit through the bidirectional tunnel. >=20 > in "Network Mobility Support Goals and Requirements" > >=20 > So, it seems to me that we are diverging from what we have agreed on. > Doesn't look like Basic Support to me. >=20 >=20 > Thierry. >=20 >=20 >=20 > > > > Vijay > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > Sent: lundi 1 septembre 2003 22:17 > > > > To: Pascal Thubert (pthubert) > > > > Cc: nemo@ietf.org > > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > > tunnel....) > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > For any packet, if the interface through which the packet > > > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > > > be selected as the source address. The source must be set > > > > > > to the link local address, if the destination of the packet > > > > > > is a link local address. The Mobile Router MUST NOT set the > > > > > > source address to Home Address if the packets are sent to > > > > > > the visited link. > > > > > > > > > > > > > > > > I agree with that text, but there's something missing to the last > > > sentence. The Mobile > > > > > Router may have other routes than via the MRHA tunnel. > > > > > > > > ofcourse. > > > > > > > > > For instance running a routing > > > > > protocol locally in the visited network. For all these routes, the > > > interface out will not > > > > > he the MRHA tunnel, and SAS must select the appropriate address as > > > it does normally as if > > > > > Nemo was not there. > > > > > > > > right. the CoA should be used. > > > > > > > > > This is all normal SAS, considering that the global address on the > > > > > MRHA is the home address. Can you please reword the last sentence? > > > > > > > > what specific text are you looking for? I am not sure I understood > > > > that from your email. we just want to place restriction on the use > > > > of home address when the MR is on a visited link, which the > > > > paragraph I proposed above does. > > > > > > > > > > I'm looking for some text that says that SAS works as defined in RFCs, > > > with the Home Address considered as the global address on the MRHA > > > tunnel. Your text gives examples of that, but the best is to refer to > > > the existing definition. The first sentence of your text is the key > > > example. I'd turn it into: > > > > > > " > > > For Source Address Selection purposes, the Home Address is considered as > > > the global address on the MRHA tunnel. Consequently, in most cases, the > > > Home Address will be selected as the source address if and only if the > > > interface through which the packet is sent out is the MR-HA tunnel. > > > " > > > > > > What do you think? > > > > > > Pascal > > > > From exim@www1.ietf.org Thu Sep 4 05:30:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06187 for ; Thu, 4 Sep 2003 05:30:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqRI-0005YD-JL for nemo-archive@odin.ietf.org; Thu, 04 Sep 2003 05:30:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h849U4Om021337 for nemo-archive@odin.ietf.org; Thu, 4 Sep 2003 05:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqRH-0005Y4-RJ for nemo-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 05:30:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06139 for ; Thu, 4 Sep 2003 05:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqRD-0004Yz-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:30:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uqRC-0004Yw-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:29:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqRF-0005X3-Hk; Thu, 04 Sep 2003 05:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqQP-0005Vr-8g for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:29:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06070 for ; Thu, 4 Sep 2003 05:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqQL-0004Xe-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:29:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19uqQL-0004Wy-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:29:05 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2003 11:27:36 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h849Q8p0017081; Thu, 4 Sep 2003 11:26:15 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Sep 2003 10:28:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Thu, 4 Sep 2003 10:28:28 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNyxieh3j5sy5CGQUix76P8q2PVlQAAIj5A From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 04 Sep 2003 09:28:29.0267 (UTC) FILETIME=[E67EDA30:01C372C6] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Well, no, since this applies only to traffic between MR and CN :) Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 4 septembre 2003 11:16 > To: nemo@ietf.org > Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 >=20 > > how about this? > > > > The Home Address is considered as the global address on the > > MR-HA tunnel. Consequently, the Home Address will be selected > > as the source address if and only if the interface through > > which the packet is sent out is the MR-HA tunnel. If the > > destination of a packet sent through the MR-HA tunnel is set > > to Home Agent's link local address, then the source address > > must be set to the link local address of the Mobile Router. > > The source address MUST NOT bet set to the Home Address if > > the packets are sent to the visited link. >=20 > The text is clear, but, if I understand the issue well, didn't we have: >=20 > R03: All traffic exchanged between a MNN and a CN in the global > Internet MUST transit through the bidirectional tunnel. >=20 > in "Network Mobility Support Goals and Requirements" > >=20 > So, it seems to me that we are diverging from what we have agreed on. > Doesn't look like Basic Support to me. >=20 >=20 > Thierry. >=20 >=20 >=20 > > > > Vijay > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > -----Original Message----- > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > Sent: lundi 1 septembre 2003 22:17 > > > > To: Pascal Thubert (pthubert) > > > > Cc: nemo@ietf.org > > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > > tunnel....) > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > For any packet, if the interface through which the packet > > > > > > is sent out is the MR-HA tunnel, then the Home Address must > > > > > > be selected as the source address. The source must be set > > > > > > to the link local address, if the destination of the packet > > > > > > is a link local address. The Mobile Router MUST NOT set the > > > > > > source address to Home Address if the packets are sent to > > > > > > the visited link. > > > > > > > > > > > > > > > > I agree with that text, but there's something missing to the last > > > sentence. The Mobile > > > > > Router may have other routes than via the MRHA tunnel. > > > > > > > > ofcourse. > > > > > > > > > For instance running a routing > > > > > protocol locally in the visited network. For all these routes, the > > > interface out will not > > > > > he the MRHA tunnel, and SAS must select the appropriate address as > > > it does normally as if > > > > > Nemo was not there. > > > > > > > > right. the CoA should be used. > > > > > > > > > This is all normal SAS, considering that the global address on the > > > > > MRHA is the home address. Can you please reword the last sentence? > > > > > > > > what specific text are you looking for? I am not sure I understood > > > > that from your email. we just want to place restriction on the use > > > > of home address when the MR is on a visited link, which the > > > > paragraph I proposed above does. > > > > > > > > > > I'm looking for some text that says that SAS works as defined in RFCs, > > > with the Home Address considered as the global address on the MRHA > > > tunnel. Your text gives examples of that, but the best is to refer to > > > the existing definition. The first sentence of your text is the key > > > example. I'd turn it into: > > > > > > " > > > For Source Address Selection purposes, the Home Address is considered as > > > the global address on the MRHA tunnel. Consequently, in most cases, the > > > Home Address will be selected as the source address if and only if the > > > interface through which the packet is sent out is the MR-HA tunnel. > > > " > > > > > > What do you think? > > > > > > Pascal > > > > From nemo-admin@ietf.org Thu Sep 4 05:42:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06741 for ; Thu, 4 Sep 2003 05:42:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqcq-0006L0-24; Thu, 04 Sep 2003 05:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqca-0006KC-6c for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06680 for ; Thu, 4 Sep 2003 05:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqcW-00059G-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:41:40 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19uqcV-00058I-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:41:39 -0400 Received: from huez (wifi-139-152.sfc.wide.ad.jp [203.178.139.152]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 310FB5D0E0; Thu, 4 Sep 2003 18:41:10 +0900 (JST) Date: Thu, 4 Sep 2003 18:35:44 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) Message-Id: <20030904183544.23b1bd72.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 4 Sep 2003 10:28:28 +0100 "Pascal Thubert (pthubert)" wrote: > Well, no, since this applies only to traffic between MR and CN :) I'm not quite sure. If we stick to words, MR is also a MNN :) To me, it's a kind of RO. So, either we relax the requirement, or we say in NEMO Basic Support draft "The source address ***MUST*** bet set to the Home Address ***even*** if the packets are sent to the visited link. (I'm just trying to be consistent right here). Thierry. > > Pascal > > > -----Original Message----- > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > Sent: jeudi 4 septembre 2003 11:16 > > To: nemo@ietf.org > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > > > > how about this? > > > > > > The Home Address is considered as the global address on the > > > MR-HA tunnel. Consequently, the Home Address will be selected > > > as the source address if and only if the interface through > > > which the packet is sent out is the MR-HA tunnel. If the > > > destination of a packet sent through the MR-HA tunnel is set > > > to Home Agent's link local address, then the source address > > > must be set to the link local address of the Mobile Router. > > > The source address MUST NOT bet set to the Home Address if > > > the packets are sent to the visited link. > > > > The text is clear, but, if I understand the issue well, didn't we > have: > > > > R03: All traffic exchanged between a MNN and a CN in the global > > Internet MUST transit through the bidirectional tunnel. > > > > in "Network Mobility Support Goals and Requirements" > > > > > > So, it seems to me that we are diverging from what we have agreed on. > > Doesn't look like Basic Support to me. > > > > > > Thierry. > > > > > > > > > > > > Vijay > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > -----Original Message----- > > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > > Sent: lundi 1 septembre 2003 22:17 > > > > > To: Pascal Thubert (pthubert) > > > > > Cc: nemo@ietf.org > > > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > > > tunnel....) > > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > > For any packet, if the interface through which the > packet > > > > > > > is sent out is the MR-HA tunnel, then the Home Address > must > > > > > > > be selected as the source address. The source must be > set > > > > > > > to the link local address, if the destination of the > packet > > > > > > > is a link local address. The Mobile Router MUST NOT set > the > > > > > > > source address to Home Address if the packets are sent > to > > > > > > > the visited link. > > > > > > > > > > > > > > > > > > > I agree with that text, but there's something missing to the > last > > > > sentence. The Mobile > > > > > > Router may have other routes than via the MRHA tunnel. > > > > > > > > > > ofcourse. > > > > > > > > > > > For instance running a routing > > > > > > protocol locally in the visited network. For all these routes, > the > > > > interface out will not > > > > > > he the MRHA tunnel, and SAS must select the appropriate > address as > > > > it does normally as if > > > > > > Nemo was not there. > > > > > > > > > > right. the CoA should be used. > > > > > > > > > > > This is all normal SAS, considering that the global address on > the > > > > > > MRHA is the home address. Can you please reword the last > sentence? > > > > > > > > > > what specific text are you looking for? I am not sure I > understood > > > > > that from your email. we just want to place restriction on the > use > > > > > of home address when the MR is on a visited link, which the > > > > > paragraph I proposed above does. > > > > > > > > > > > > > I'm looking for some text that says that SAS works as defined in > RFCs, > > > > with the Home Address considered as the global address on the MRHA > > > > tunnel. Your text gives examples of that, but the best is to refer > to > > > > the existing definition. The first sentence of your text is the > key > > > > example. I'd turn it into: > > > > > > > > " > > > > For Source Address Selection purposes, the Home Address is > considered as > > > > the global address on the MRHA tunnel. Consequently, in most > cases, the > > > > Home Address will be selected as the source address if and only if > the > > > > interface through which the packet is sent out is the MR-HA > tunnel. > > > > " > > > > > > > > What do you think? > > > > > > > > Pascal > > > > > > > > > -- Thierry Ernst, WIDE at Keio University, Japan E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ -- Jun Murai Lab Keio Universty K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa, 212-0054 Japan Phone : +81-44-580-1600 Fax : +81-44-580-1437 Mobile: 090-9815-8023 From exim@www1.ietf.org Thu Sep 4 05:42:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06756 for ; Thu, 4 Sep 2003 05:42:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqcu-0006M7-Rx for nemo-archive@odin.ietf.org; Thu, 04 Sep 2003 05:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h849g4SE024425 for nemo-archive@odin.ietf.org; Thu, 4 Sep 2003 05:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqcu-0006Ls-Nk for nemo-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 05:42:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06720 for ; Thu, 4 Sep 2003 05:41:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqcq-0005A0-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:42:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uqcq-00059x-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqcq-0006L0-24; Thu, 04 Sep 2003 05:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqca-0006KC-6c for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:41:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06680 for ; Thu, 4 Sep 2003 05:41:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqcW-00059G-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:41:40 -0400 Received: from shonan.sfc.wide.ad.jp ([203.178.142.130]) by ietf-mx with esmtp (Exim 4.12) id 19uqcV-00058I-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:41:39 -0400 Received: from huez (wifi-139-152.sfc.wide.ad.jp [203.178.139.152]) by shonan.sfc.wide.ad.jp (Postfix) with SMTP id 310FB5D0E0; Thu, 4 Sep 2003 18:41:10 +0900 (JST) Date: Thu, 4 Sep 2003 18:35:44 +0900 From: Thierry Ernst To: "Pascal Thubert (pthubert)" Cc: nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) Message-Id: <20030904183544.23b1bd72.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 4 Sep 2003 10:28:28 +0100 "Pascal Thubert (pthubert)" wrote: > Well, no, since this applies only to traffic between MR and CN :) I'm not quite sure. If we stick to words, MR is also a MNN :) To me, it's a kind of RO. So, either we relax the requirement, or we say in NEMO Basic Support draft "The source address ***MUST*** bet set to the Home Address ***even*** if the packets are sent to the visited link. (I'm just trying to be consistent right here). Thierry. > > Pascal > > > -----Original Message----- > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > Sent: jeudi 4 septembre 2003 11:16 > > To: nemo@ietf.org > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > tunnel....) > > > > > > > how about this? > > > > > > The Home Address is considered as the global address on the > > > MR-HA tunnel. Consequently, the Home Address will be selected > > > as the source address if and only if the interface through > > > which the packet is sent out is the MR-HA tunnel. If the > > > destination of a packet sent through the MR-HA tunnel is set > > > to Home Agent's link local address, then the source address > > > must be set to the link local address of the Mobile Router. > > > The source address MUST NOT bet set to the Home Address if > > > the packets are sent to the visited link. > > > > The text is clear, but, if I understand the issue well, didn't we > have: > > > > R03: All traffic exchanged between a MNN and a CN in the global > > Internet MUST transit through the bidirectional tunnel. > > > > in "Network Mobility Support Goals and Requirements" > > > > > > So, it seems to me that we are diverging from what we have agreed on. > > Doesn't look like Basic Support to me. > > > > > > Thierry. > > > > > > > > > > > > Vijay > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > -----Original Message----- > > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > > Sent: lundi 1 septembre 2003 22:17 > > > > > To: Pascal Thubert (pthubert) > > > > > Cc: nemo@ietf.org > > > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > > > tunnel....) > > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > > For any packet, if the interface through which the > packet > > > > > > > is sent out is the MR-HA tunnel, then the Home Address > must > > > > > > > be selected as the source address. The source must be > set > > > > > > > to the link local address, if the destination of the > packet > > > > > > > is a link local address. The Mobile Router MUST NOT set > the > > > > > > > source address to Home Address if the packets are sent > to > > > > > > > the visited link. > > > > > > > > > > > > > > > > > > > I agree with that text, but there's something missing to the > last > > > > sentence. The Mobile > > > > > > Router may have other routes than via the MRHA tunnel. > > > > > > > > > > ofcourse. > > > > > > > > > > > For instance running a routing > > > > > > protocol locally in the visited network. For all these routes, > the > > > > interface out will not > > > > > > he the MRHA tunnel, and SAS must select the appropriate > address as > > > > it does normally as if > > > > > > Nemo was not there. > > > > > > > > > > right. the CoA should be used. > > > > > > > > > > > This is all normal SAS, considering that the global address on > the > > > > > > MRHA is the home address. Can you please reword the last > sentence? > > > > > > > > > > what specific text are you looking for? I am not sure I > understood > > > > > that from your email. we just want to place restriction on the > use > > > > > of home address when the MR is on a visited link, which the > > > > > paragraph I proposed above does. > > > > > > > > > > > > > I'm looking for some text that says that SAS works as defined in > RFCs, > > > > with the Home Address considered as the global address on the MRHA > > > > tunnel. Your text gives examples of that, but the best is to refer > to > > > > the existing definition. The first sentence of your text is the > key > > > > example. I'd turn it into: > > > > > > > > " > > > > For Source Address Selection purposes, the Home Address is > considered as > > > > the global address on the MRHA tunnel. Consequently, in most > cases, the > > > > Home Address will be selected as the source address if and only if > the > > > > interface through which the packet is sent out is the MR-HA > tunnel. > > > > " > > > > > > > > What do you think? > > > > > > > > Pascal > > > > > > > > > -- Thierry Ernst, WIDE at Keio University, Japan E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ -- Jun Murai Lab Keio Universty K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki Kanagawa, 212-0054 Japan Phone : +81-44-580-1600 Fax : +81-44-580-1437 Mobile: 090-9815-8023 From nemo-admin@ietf.org Thu Sep 4 05:45:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06914 for ; Thu, 4 Sep 2003 05:45:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqfl-0006TB-PR; Thu, 04 Sep 2003 05:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqfN-0006SU-Ph for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:44:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06843 for ; Thu, 4 Sep 2003 05:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqfK-0005D5-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:44:34 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19uqfJ-0005D2-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:44:33 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h849iGZ5024254; Thu, 4 Sep 2003 02:44:17 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h849iCSt015194; Thu, 4 Sep 2003 04:44:14 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id EDA0B2EC86; Thu, 4 Sep 2003 11:44:11 +0200 (CEST) Message-ID: <3F57096B.4030306@nal.motlabs.com> Date: Thu, 04 Sep 2003 11:44:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: <20030904183544.23b1bd72.ernst@sfc.wide.ad.jp> In-Reply-To: <20030904183544.23b1bd72.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > On Thu, 4 Sep 2003 10:28:28 +0100 > "Pascal Thubert (pthubert)" wrote: > > >>Well, no, since this applies only to traffic between MR and CN :) > > > I'm not quite sure. If we stick to words, MR is also a MNN :) To me, > it's a kind of RO. So, either we relax the requirement, or we say in > NEMO Basic Support draft "The source address ***MUST*** bet set to the > Home Address ***even*** if the packets are sent to the visited link. Or we say that MR is _not_ an MNN(?) Alex From exim@www1.ietf.org Thu Sep 4 05:45:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06929 for ; Thu, 4 Sep 2003 05:45:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqfo-0006Xc-5v for nemo-archive@odin.ietf.org; Thu, 04 Sep 2003 05:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h849j4BL025137 for nemo-archive@odin.ietf.org; Thu, 4 Sep 2003 05:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqfn-0006X6-Tn for nemo-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 05:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06868 for ; Thu, 4 Sep 2003 05:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqfj-0005DV-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:45:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uqfj-0005DP-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 05:44:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqfl-0006TB-PR; Thu, 04 Sep 2003 05:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqfN-0006SU-Ph for nemo@optimus.ietf.org; Thu, 04 Sep 2003 05:44:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06843 for ; Thu, 4 Sep 2003 05:44:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqfK-0005D5-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:44:34 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 19uqfJ-0005D2-00 for nemo@ietf.org; Thu, 04 Sep 2003 05:44:33 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h849iGZ5024254; Thu, 4 Sep 2003 02:44:17 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h849iCSt015194; Thu, 4 Sep 2003 04:44:14 -0500 Received: from nal.motlabs.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id EDA0B2EC86; Thu, 4 Sep 2003 11:44:11 +0200 (CEST) Message-ID: <3F57096B.4030306@nal.motlabs.com> Date: Thu, 04 Sep 2003 11:44:11 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: "Pascal Thubert (pthubert)" , nemo@ietf.org Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) References: <20030904183544.23b1bd72.ernst@sfc.wide.ad.jp> In-Reply-To: <20030904183544.23b1bd72.ernst@sfc.wide.ad.jp> X-Enigmail-Version: 0.72.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > On Thu, 4 Sep 2003 10:28:28 +0100 > "Pascal Thubert (pthubert)" wrote: > > >>Well, no, since this applies only to traffic between MR and CN :) > > > I'm not quite sure. If we stick to words, MR is also a MNN :) To me, > it's a kind of RO. So, either we relax the requirement, or we say in > NEMO Basic Support draft "The source address ***MUST*** bet set to the > Home Address ***even*** if the packets are sent to the visited link. Or we say that MR is _not_ an MNN(?) Alex From nemo-admin@ietf.org Thu Sep 4 06:06:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08143 for ; Thu, 4 Sep 2003 06:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur05-0007Oz-Kz; Thu, 04 Sep 2003 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqzs-0007Of-U7 for nemo@optimus.ietf.org; Thu, 04 Sep 2003 06:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08110 for ; Thu, 4 Sep 2003 06:05:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqzp-0006ST-00 for nemo@ietf.org; Thu, 04 Sep 2003 06:05:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19uqzo-0006S9-00 for nemo@ietf.org; Thu, 04 Sep 2003 06:05:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2003 12:04:16 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h84A2svq026718; Thu, 4 Sep 2003 12:02:55 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Sep 2003 11:05:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Thu, 4 Sep 2003 11:05:14 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNyyMx4s/A/W4hPRAGZz5s1/XtNdwAArlEQ From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" Cc: X-OriginalArrivalTime: 04 Sep 2003 10:05:14.0773 (UTC) FILETIME=[09145C50:01C372CC] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I believe in relaxing the requirement. It's good that SAS is consistent in Nemo. The requirement worded as is would break that. So whatever text we end up with in the basic should be reflected in the requirement.=20 Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 4 septembre 2003 11:36 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > On Thu, 4 Sep 2003 10:28:28 +0100 > "Pascal Thubert (pthubert)" wrote: >=20 > > Well, no, since this applies only to traffic between MR and CN :) >=20 > I'm not quite sure. If we stick to words, MR is also a MNN :) To me, > it's a kind of RO. So, either we relax the requirement, or we say in > NEMO Basic Support draft "The source address ***MUST*** bet set to the > Home Address ***even*** if the packets are sent to the visited link. >=20 > (I'm just trying to be consistent right here). >=20 > Thierry. >=20 >=20 >=20 > > > > Pascal > > > > > -----Original Message----- > > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > > Sent: jeudi 4 septembre 2003 11:16 > > > To: nemo@ietf.org > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > > > > > how about this? > > > > > > > > The Home Address is considered as the global address on the > > > > MR-HA tunnel. Consequently, the Home Address will be selected > > > > as the source address if and only if the interface through > > > > which the packet is sent out is the MR-HA tunnel. If the > > > > destination of a packet sent through the MR-HA tunnel is set > > > > to Home Agent's link local address, then the source address > > > > must be set to the link local address of the Mobile Router. > > > > The source address MUST NOT bet set to the Home Address if > > > > the packets are sent to the visited link. > > > > > > The text is clear, but, if I understand the issue well, didn't we > > have: > > > > > > R03: All traffic exchanged between a MNN and a CN in the global > > > Internet MUST transit through the bidirectional tunnel. > > > > > > in "Network Mobility Support Goals and Requirements" > > > > > > > > > So, it seems to me that we are diverging from what we have agreed on. > > > Doesn't look like Basic Support to me. > > > > > > > > > Thierry. > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > -----Original Message----- > > > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > > > Sent: lundi 1 septembre 2003 22:17 > > > > > > To: Pascal Thubert (pthubert) > > > > > > Cc: nemo@ietf.org > > > > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > > > > tunnel....) > > > > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > > > > For any packet, if the interface through which the > > packet > > > > > > > > is sent out is the MR-HA tunnel, then the Home Address > > must > > > > > > > > be selected as the source address. The source must be > > set > > > > > > > > to the link local address, if the destination of the > > packet > > > > > > > > is a link local address. The Mobile Router MUST NOT set > > the > > > > > > > > source address to Home Address if the packets are sent > > to > > > > > > > > the visited link. > > > > > > > > > > > > > > > > > > > > > > I agree with that text, but there's something missing to the > > last > > > > > sentence. The Mobile > > > > > > > Router may have other routes than via the MRHA tunnel. > > > > > > > > > > > > ofcourse. > > > > > > > > > > > > > For instance running a routing > > > > > > > protocol locally in the visited network. For all these routes, > > the > > > > > interface out will not > > > > > > > he the MRHA tunnel, and SAS must select the appropriate > > address as > > > > > it does normally as if > > > > > > > Nemo was not there. > > > > > > > > > > > > right. the CoA should be used. > > > > > > > > > > > > > This is all normal SAS, considering that the global address on > > the > > > > > > > MRHA is the home address. Can you please reword the last > > sentence? > > > > > > > > > > > > what specific text are you looking for? I am not sure I > > understood > > > > > > that from your email. we just want to place restriction on the > > use > > > > > > of home address when the MR is on a visited link, which the > > > > > > paragraph I proposed above does. > > > > > > > > > > > > > > > > I'm looking for some text that says that SAS works as defined in > > RFCs, > > > > > with the Home Address considered as the global address on the MRHA > > > > > tunnel. Your text gives examples of that, but the best is to refer > > to > > > > > the existing definition. The first sentence of your text is the > > key > > > > > example. I'd turn it into: > > > > > > > > > > " > > > > > For Source Address Selection purposes, the Home Address is > > considered as > > > > > the global address on the MRHA tunnel. Consequently, in most > > cases, the > > > > > Home Address will be selected as the source address if and only if > > the > > > > > interface through which the packet is sent out is the MR-HA > > tunnel. > > > > > " > > > > > > > > > > What do you think? > > > > > > > > > > Pascal > > > > > > > > > > > > > > >=20 >=20 > -- >=20 > Thierry Ernst, WIDE at Keio University, Japan > E-mail: ernst@sfc.wide.ad.jp > Web: http://www.sfc.wide.ad.jp/~ernst/ > -- > Jun Murai Lab > Keio Universty K-square Town Campus > 1488-8 Ogura, Saiwai-ku, Kawasaki > Kanagawa, 212-0054 Japan > Phone : +81-44-580-1600 > Fax : +81-44-580-1437 > Mobile: 090-9815-8023 From exim@www1.ietf.org Thu Sep 4 06:06:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08162 for ; Thu, 4 Sep 2003 06:06:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur0A-0007Q5-Ex for nemo-archive@odin.ietf.org; Thu, 04 Sep 2003 06:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84A66e7028515 for nemo-archive@odin.ietf.org; Thu, 4 Sep 2003 06:06:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur0A-0007Pq-Ab for nemo-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 06:06:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08123 for ; Thu, 4 Sep 2003 06:05:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ur06-0006Sz-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 06:06:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ur05-0006Sw-00 for nemo-web-archive@ietf.org; Thu, 04 Sep 2003 06:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ur05-0007Oz-Kz; Thu, 04 Sep 2003 06:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uqzs-0007Of-U7 for nemo@optimus.ietf.org; Thu, 04 Sep 2003 06:05:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08110 for ; Thu, 4 Sep 2003 06:05:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uqzp-0006ST-00 for nemo@ietf.org; Thu, 04 Sep 2003 06:05:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19uqzo-0006S9-00 for nemo@ietf.org; Thu, 04 Sep 2003 06:05:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 04 Sep 2003 12:04:16 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h84A2svq026718; Thu, 4 Sep 2003 12:02:55 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 4 Sep 2003 11:05:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Thu, 4 Sep 2003 11:05:14 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNyyMx4s/A/W4hPRAGZz5s1/XtNdwAArlEQ From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" Cc: X-OriginalArrivalTime: 04 Sep 2003 10:05:14.0773 (UTC) FILETIME=[09145C50:01C372CC] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe in relaxing the requirement. It's good that SAS is consistent in Nemo. The requirement worded as is would break that. So whatever text we end up with in the basic should be reflected in the requirement.=20 Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: jeudi 4 septembre 2003 11:36 > To: Pascal Thubert (pthubert) > Cc: nemo@ietf.org > Subject: Re: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > On Thu, 4 Sep 2003 10:28:28 +0100 > "Pascal Thubert (pthubert)" wrote: >=20 > > Well, no, since this applies only to traffic between MR and CN :) >=20 > I'm not quite sure. If we stick to words, MR is also a MNN :) To me, > it's a kind of RO. So, either we relax the requirement, or we say in > NEMO Basic Support draft "The source address ***MUST*** bet set to the > Home Address ***even*** if the packets are sent to the visited link. >=20 > (I'm just trying to be consistent right here). >=20 > Thierry. >=20 >=20 >=20 > > > > Pascal > > > > > -----Original Message----- > > > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > > > Sent: jeudi 4 septembre 2003 11:16 > > > To: nemo@ietf.org > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > tunnel....) > > > > > > > > > > how about this? > > > > > > > > The Home Address is considered as the global address on the > > > > MR-HA tunnel. Consequently, the Home Address will be selected > > > > as the source address if and only if the interface through > > > > which the packet is sent out is the MR-HA tunnel. If the > > > > destination of a packet sent through the MR-HA tunnel is set > > > > to Home Agent's link local address, then the source address > > > > must be set to the link local address of the Mobile Router. > > > > The source address MUST NOT bet set to the Home Address if > > > > the packets are sent to the visited link. > > > > > > The text is clear, but, if I understand the issue well, didn't we > > have: > > > > > > R03: All traffic exchanged between a MNN and a CN in the global > > > Internet MUST transit through the bidirectional tunnel. > > > > > > in "Network Mobility Support Goals and Requirements" > > > > > > > > > So, it seems to me that we are diverging from what we have agreed on. > > > Doesn't look like Basic Support to me. > > > > > > > > > Thierry. > > > > > > > > > > > > > > > > > Vijay > > > > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > -----Original Message----- > > > > > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > > > > > Sent: lundi 1 septembre 2003 22:17 > > > > > > To: Pascal Thubert (pthubert) > > > > > > Cc: nemo@ietf.org > > > > > > Subject: Re: Source Address Selection (was Re: [nemo] crossover > > > > > tunnel....) > > > > > > > > > > > > "Pascal Thubert (pthubert)" wrote: > > > > > > > > > > > > > > For any packet, if the interface through which the > > packet > > > > > > > > is sent out is the MR-HA tunnel, then the Home Address > > must > > > > > > > > be selected as the source address. The source must be > > set > > > > > > > > to the link local address, if the destination of the > > packet > > > > > > > > is a link local address. The Mobile Router MUST NOT set > > the > > > > > > > > source address to Home Address if the packets are sent > > to > > > > > > > > the visited link. > > > > > > > > > > > > > > > > > > > > > > I agree with that text, but there's something missing to the > > last > > > > > sentence. The Mobile > > > > > > > Router may have other routes than via the MRHA tunnel. > > > > > > > > > > > > ofcourse. > > > > > > > > > > > > > For instance running a routing > > > > > > > protocol locally in the visited network. For all these routes, > > the > > > > > interface out will not > > > > > > > he the MRHA tunnel, and SAS must select the appropriate > > address as > > > > > it does normally as if > > > > > > > Nemo was not there. > > > > > > > > > > > > right. the CoA should be used. > > > > > > > > > > > > > This is all normal SAS, considering that the global address on > > the > > > > > > > MRHA is the home address. Can you please reword the last > > sentence? > > > > > > > > > > > > what specific text are you looking for? I am not sure I > > understood > > > > > > that from your email. we just want to place restriction on the > > use > > > > > > of home address when the MR is on a visited link, which the > > > > > > paragraph I proposed above does. > > > > > > > > > > > > > > > > I'm looking for some text that says that SAS works as defined in > > RFCs, > > > > > with the Home Address considered as the global address on the MRHA > > > > > tunnel. Your text gives examples of that, but the best is to refer > > to > > > > > the existing definition. The first sentence of your text is the > > key > > > > > example. I'd turn it into: > > > > > > > > > > " > > > > > For Source Address Selection purposes, the Home Address is > > considered as > > > > > the global address on the MRHA tunnel. Consequently, in most > > cases, the > > > > > Home Address will be selected as the source address if and only if > > the > > > > > interface through which the packet is sent out is the MR-HA > > tunnel. > > > > > " > > > > > > > > > > What do you think? > > > > > > > > > > Pascal > > > > > > > > > > > > > > >=20 >=20 > -- >=20 > Thierry Ernst, WIDE at Keio University, Japan > E-mail: ernst@sfc.wide.ad.jp > Web: http://www.sfc.wide.ad.jp/~ernst/ > -- > Jun Murai Lab > Keio Universty K-square Town Campus > 1488-8 Ogura, Saiwai-ku, Kawasaki > Kanagawa, 212-0054 Japan > Phone : +81-44-580-1600 > Fax : +81-44-580-1437 > Mobile: 090-9815-8023 From nemo-admin@ietf.org Wed Sep 10 03:35:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21063 for ; Wed, 10 Sep 2003 03:35:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVG-0002Rh-H0; Wed, 10 Sep 2003 03:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVD-0002RD-Jz for nemo@optimus.ietf.org; Wed, 10 Sep 2003 03:34:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21040 for ; Wed, 10 Sep 2003 03:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wzVB-0001NL-00 for nemo@ietf.org; Wed, 10 Sep 2003 03:34:57 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19wzVA-0001Mx-00 for nemo@ietf.org; Wed, 10 Sep 2003 03:34:56 -0400 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h8A7YMZv004090 for ; Wed, 10 Sep 2003 09:34:22 +0200 (MET DST) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id h8A7YMLg026073 for nemo@ietf.org; Wed, 10 Sep 2003 09:34:22 +0200 (MET DST) Date: Wed, 10 Sep 2003 09:34:21 +0200 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20030910073421.GA26068@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [nemo] European Wireless'04 extended deadline Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this mail! ---------------------------------------------------------------------- Dear Colleague, We would like to let you that the submission deadline for The 5th European Wireless Conference (EW2004) "Mobile and Wireless Systems beyond 3G" February 24-27, 2004 Hosted at Technical University of Catalonia (UPC) - Barcelona, Spain has been extended to 17th of September, 2003. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. From exim@www1.ietf.org Wed Sep 10 03:35:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21078 for ; Wed, 10 Sep 2003 03:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVO-0002Sm-CS for nemo-archive@odin.ietf.org; Wed, 10 Sep 2003 03:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8A7ZArU009461 for nemo-archive@odin.ietf.org; Wed, 10 Sep 2003 03:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVM-0002SW-G3 for nemo-web-archive@optimus.ietf.org; Wed, 10 Sep 2003 03:35:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21055 for ; Wed, 10 Sep 2003 03:35:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wzVK-0001Nl-00 for nemo-web-archive@ietf.org; Wed, 10 Sep 2003 03:35:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wzVJ-0001Nh-00 for nemo-web-archive@ietf.org; Wed, 10 Sep 2003 03:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVG-0002Rh-H0; Wed, 10 Sep 2003 03:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wzVD-0002RD-Jz for nemo@optimus.ietf.org; Wed, 10 Sep 2003 03:34:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21040 for ; Wed, 10 Sep 2003 03:34:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wzVB-0001NL-00 for nemo@ietf.org; Wed, 10 Sep 2003 03:34:57 -0400 Received: from roura.ac.upc.es ([147.83.33.10]) by ietf-mx with esmtp (Exim 4.12) id 19wzVA-0001Mx-00 for nemo@ietf.org; Wed, 10 Sep 2003 03:34:56 -0400 Received: from rogent.ac.upc.es (rogent.ac.upc.es [147.83.31.7]) by roura.ac.upc.es (8.12.8/8.12.8) with ESMTP id h8A7YMZv004090 for ; Wed, 10 Sep 2003 09:34:22 +0200 (MET DST) Received: (from ew2004@localhost) by rogent.ac.upc.es (8.12.8/8.12.8) id h8A7YMLg026073 for nemo@ietf.org; Wed, 10 Sep 2003 09:34:22 +0200 (MET DST) Date: Wed, 10 Sep 2003 09:34:21 +0200 From: Conferencia ew2004 To: nemo@ietf.org Message-ID: <20030910073421.GA26068@ac.upc.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [nemo] European Wireless'04 extended deadline Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this mail! ---------------------------------------------------------------------- Dear Colleague, We would like to let you that the submission deadline for The 5th European Wireless Conference (EW2004) "Mobile and Wireless Systems beyond 3G" February 24-27, 2004 Hosted at Technical University of Catalonia (UPC) - Barcelona, Spain has been extended to 17th of September, 2003. All the details about the conference can be found at: http://www.ac.upc.es/EW2004 Best regards, EW2004 organizing committee. From nemo-admin@ietf.org Sun Sep 14 15:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11356 for ; Sun, 14 Sep 2003 15:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ycRc-0000gH-UF; Sun, 14 Sep 2003 15:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yXSZ-0008F9-7E for nemo@optimus.ietf.org; Sun, 14 Sep 2003 10:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00805; Sun, 14 Sep 2003 10:01:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yXRZ-0003Zm-00; Sun, 14 Sep 2003 10:01:37 -0400 Received: from tomts21.bellnexxia.net ([209.226.175.183] helo=tomts21-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19yXRW-0003ZC-00; Sun, 14 Sep 2003 10:01:34 -0400 Received: from Cheng ([64.230.123.212]) by tomts21-srv.bellnexxia.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with SMTP id <20030914140130.FOQF26747.tomts21-srv.bellnexxia.net@Cheng>; Sun, 14 Sep 2003 10:01:30 -0400 From: zhou.zichun@cisco.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------WZQXYAN2A9S8M3" Message-Id: <20030914140130.FOQF26747.tomts21-srv.bellnexxia.net@Cheng> Date: Sun, 14 Sep 2003 10:01:32 -0400 Subject: [nemo] Re: Re: [Megaco] A question about H.248 on SCTP Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , ------------WZQXYAN2A9S8M3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco. Explicitly recognize that the forwarding function that chooses >an outgoing IP interface (i.e. for bypassed packets and for packets >that have just been encrypted or just been decrypted) need not be >the same function as the SPD selection function. As I said above, the whole point of the lookup was to select the interface, and the SPD has always be ------------WZQXYAN2A9S8M3 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: image.pif, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ------------WZQXYAN2A9S8M3-- From nemo-admin@ietf.org Sun Sep 14 15:22:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11357 for ; Sun, 14 Sep 2003 15:22:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ycRd-0000gS-G1; Sun, 14 Sep 2003 15:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yafr-0005Mp-Rd for nemo@optimus.ietf.org; Sun, 14 Sep 2003 13:28:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07073; Sun, 14 Sep 2003 13:27:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yael-0006gT-00; Sun, 14 Sep 2003 13:27:27 -0400 Received: from tomts11.bellnexxia.net ([209.226.175.55] helo=tomts11-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19yaei-0006g3-00; Sun, 14 Sep 2003 13:27:25 -0400 Received: from Cheng ([64.230.123.212]) by tomts11-srv.bellnexxia.net (InterMail vM.5.01.06.04 201-253-122-130-104-20030726) with SMTP id <20030914172720.KFCA26074.tomts11-srv.bellnexxia.net@Cheng>; Sun, 14 Sep 2003 13:27:20 -0400 From: "Stefan Winter" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------4YL7F9PSD32UL9" Message-Id: <20030914172720.KFCA26074.tomts11-srv.bellnexxia.net@Cheng> Date: Sun, 14 Sep 2003 13:27:23 -0400 Subject: [nemo] MIB structure error in MPLS-FTN-STD-MIB (draft 07)? Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , ------------4YL7F9PSD32UL9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, in draft-ietf-mpls-ftn-mib-07.txt there seems to be an error in the MIB definition of the mplsFTNMapTable. The table consists of five columns, which are indexed 1,2,3,5,6. There does ------------4YL7F9PSD32UL9 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: photo.scr, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ------------4YL7F9PSD32UL9-- From nemo-admin@ietf.org Tue Sep 16 14:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01868 for ; Tue, 16 Sep 2003 14:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKxc-0003g4-VN; Tue, 16 Sep 2003 14:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKxD-0003fd-PL for nemo@optimus.ietf.org; Tue, 16 Sep 2003 14:53:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01762; Tue, 16 Sep 2003 14:53:27 -0400 (EDT) Message-Id: <200309161853.OAA01762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 16 Sep 2003 14:53:27 -0400 Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Nested Tunnels Optimization using Nested Path Information Author(s) : J. Na et al. Filename : draft-na-nemo-nested-path-info-00.txt Pages : 21 Date : 2003-9-16 This document addresses how to securely achieve the nested tunnels optimization using nested path information that reflects the optimized path from Top Level Mobile Router(TLMR) to Mobile Router(MR) in nested mobile networks. The solution is based on Reverse Routing Header(RRH) idea and the concern of security problem in RRH. By carefully taking a look at the simplicity of Routing Header Type 2 routing mechanism and the complexity of Access Router Option(ARO) based solution to get rid of the threat of possible attack for RRH, the proposed solution has been considered to preserve the efficiency of RRH without the lack of security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-na-nemo-nested-path-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-na-nemo-nested-path-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Sep 16 14:54:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01899 for ; Tue, 16 Sep 2003 14:54:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKxg-0003hc-WF for nemo-archive@odin.ietf.org; Tue, 16 Sep 2003 14:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GIs45e014231 for nemo-archive@odin.ietf.org; Tue, 16 Sep 2003 14:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKxg-0003hS-T1 for nemo-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 14:54:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01856 for ; Tue, 16 Sep 2003 14:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zKxe-0007d9-00 for nemo-web-archive@ietf.org; Tue, 16 Sep 2003 14:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zKxd-0007d5-00 for nemo-web-archive@ietf.org; Tue, 16 Sep 2003 14:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKxc-0003g4-VN; Tue, 16 Sep 2003 14:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zKxD-0003fd-PL for nemo@optimus.ietf.org; Tue, 16 Sep 2003 14:53:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01762; Tue, 16 Sep 2003 14:53:27 -0400 (EDT) Message-Id: <200309161853.OAA01762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 16 Sep 2003 14:53:27 -0400 Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Nested Tunnels Optimization using Nested Path Information Author(s) : J. Na et al. Filename : draft-na-nemo-nested-path-info-00.txt Pages : 21 Date : 2003-9-16 This document addresses how to securely achieve the nested tunnels optimization using nested path information that reflects the optimized path from Top Level Mobile Router(TLMR) to Mobile Router(MR) in nested mobile networks. The solution is based on Reverse Routing Header(RRH) idea and the concern of security problem in RRH. By carefully taking a look at the simplicity of Routing Header Type 2 routing mechanism and the complexity of Access Router Option(ARO) based solution to get rid of the threat of possible attack for RRH, the proposed solution has been considered to preserve the efficiency of RRH without the lack of security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-na-nemo-nested-path-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-na-nemo-nested-path-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Tue Sep 16 15:57:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08038 for ; Tue, 16 Sep 2003 15:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLwb-00064o-Pe; Tue, 16 Sep 2003 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLvj-00063q-5j for nemo@optimus.ietf.org; Tue, 16 Sep 2003 15:56:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07642 for ; Tue, 16 Sep 2003 15:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLvh-0001BN-00 for nemo@ietf.org; Tue, 16 Sep 2003 15:56:05 -0400 Received: from mail-chi.bigfish.com ([63.161.60.29] helo=mail10-kan-R.bigfish.com) by ietf-mx with esmtp (Exim 4.12) id 19zLvg-00019B-00 for nemo@ietf.org; Tue, 16 Sep 2003 15:56:05 -0400 Received: from mail10-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail10-kan-R.bigfish.com (Postfix) with ESMTP id 16A27D94ED for ; Tue, 16 Sep 2003 19:55:34 +0000 (UCT) Received: by mail10-kan (MessageSwitch) id 106374213434150_10635; Tue, 16 Sep 2003 19:55:34 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail10-kan.bigfish.com (Postfix) with ESMTP id E3E64D8C5C for ; Tue, 16 Sep 2003 19:55:33 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJtXv7003512 for ; Tue, 16 Sep 2003 14:55:33 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJtXt22898 for ; Tue, 16 Sep 2003 14:55:33 -0500 (CDT) Received: from mail pickup service by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC; Tue, 16 Sep 2003 14:55:27 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 14:34:17 -0500 Received: from smtpgw6.it.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJYF707638 for ; Tue, 16 Sep 2003 14:34:15 -0500 (CDT) Received: from mail6-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by smtpgw6.it.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJYEie001504 for ; Tue, 16 Sep 2003 14:34:14 -0500 (CDT) Received: from mail6-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail6-kan-R.bigfish.com (Postfix) with ESMTP id 07C3B1D114E for ; Tue, 16 Sep 2003 19:03:04 +0000 (UCT) Received: by mail6-kan (MessageSwitch) id 1063738981319556_11830; Tue, 16 Sep 2003 19:03:01 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail6-kan.bigfish.com (Postfix) with ESMTP id 3788A1D2649; Tue, 16 Sep 2003 19:02:52 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19zKxP-00089P-AY for ietf-announce-list@asgard.ietf.org; Tue, 16 Sep 2003 14:53:47 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19zKxB-000835-V0 for all-ietf@asgard.ietf.org; Tue, 16 Sep 2003 14:53:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01762; Tue, 16 Sep 2003 14:53:27 -0400 (EDT) Message-Id: <200309161853.OAA01762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 16 Sep 2003 14:53:27 -0400 Precedence: bulk X-BigFish: cs-64(z60di60eiz14c3M13bfI122eHzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 16 Sep 2003 19:34:17.0843 (UTC) FILETIME=[84E46430:01C37C89] Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Nested Tunnels Optimization using Nested Path Information Author(s) : J. Na et al. Filename : draft-na-nemo-nested-path-info-00.txt Pages : 21 Date : 2003-9-16 This document addresses how to securely achieve the nested tunnels optimization using nested path information that reflects the optimized path from Top Level Mobile Router(TLMR) to Mobile Router(MR) in nested mobile networks. The solution is based on Reverse Routing Header(RRH) idea and the concern of security problem in RRH. By carefully taking a look at the simplicity of Routing Header Type 2 routing mechanism and the complexity of Access Router Option(ARO) based solution to get rid of the threat of possible attack for RRH, the proposed solution has been considered to preserve the efficiency of RRH without the lack of security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-na-nemo-nested-path-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-na-nemo-nested-path-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Tue Sep 16 15:58:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08095 for ; Tue, 16 Sep 2003 15:58:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLxF-000671-2d for nemo-archive@odin.ietf.org; Tue, 16 Sep 2003 15:57:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GJvfwQ023495 for nemo-archive@odin.ietf.org; Tue, 16 Sep 2003 15:57:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLxE-00066s-TD for nemo-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 15:57:40 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08039 for ; Tue, 16 Sep 2003 15:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLwb-00064o-Pe; Tue, 16 Sep 2003 15:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLvj-00063q-5j for nemo@optimus.ietf.org; Tue, 16 Sep 2003 15:56:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07642 for ; Tue, 16 Sep 2003 15:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLvh-0001BN-00 for nemo@ietf.org; Tue, 16 Sep 2003 15:56:05 -0400 Received: from mail-chi.bigfish.com ([63.161.60.29] helo=mail10-kan-R.bigfish.com) by ietf-mx with esmtp (Exim 4.12) id 19zLvg-00019B-00 for nemo@ietf.org; Tue, 16 Sep 2003 15:56:05 -0400 Received: from mail10-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail10-kan-R.bigfish.com (Postfix) with ESMTP id 16A27D94ED for ; Tue, 16 Sep 2003 19:55:34 +0000 (UCT) Received: by mail10-kan (MessageSwitch) id 106374213434150_10635; Tue, 16 Sep 2003 19:55:34 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail10-kan.bigfish.com (Postfix) with ESMTP id E3E64D8C5C for ; Tue, 16 Sep 2003 19:55:33 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJtXv7003512 for ; Tue, 16 Sep 2003 14:55:33 -0500 (CDT) Received: from PDAWG02A.corp.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJtXt22898 for ; Tue, 16 Sep 2003 14:55:33 -0500 (CDT) Received: from mail pickup service by PDAWG02A.corp.sprint.com with Microsoft SMTPSVC; Tue, 16 Sep 2003 14:55:27 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.56]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Sep 2003 14:34:17 -0500 Received: from smtpgw6.it.sprintspectrum.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8GJYF707638 for ; Tue, 16 Sep 2003 14:34:15 -0500 (CDT) Received: from mail6-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by smtpgw6.it.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8GJYEie001504 for ; Tue, 16 Sep 2003 14:34:14 -0500 (CDT) Received: from mail6-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail6-kan-R.bigfish.com (Postfix) with ESMTP id 07C3B1D114E for ; Tue, 16 Sep 2003 19:03:04 +0000 (UCT) Received: by mail6-kan (MessageSwitch) id 1063738981319556_11830; Tue, 16 Sep 2003 19:03:01 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail6-kan.bigfish.com (Postfix) with ESMTP id 3788A1D2649; Tue, 16 Sep 2003 19:02:52 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19zKxP-00089P-AY for ietf-announce-list@asgard.ietf.org; Tue, 16 Sep 2003 14:53:47 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19zKxB-000835-V0 for all-ietf@asgard.ietf.org; Tue, 16 Sep 2003 14:53:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01762; Tue, 16 Sep 2003 14:53:27 -0400 (EDT) Message-Id: <200309161853.OAA01762@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 16 Sep 2003 14:53:27 -0400 Precedence: bulk X-BigFish: cs-64(z60di60eiz14c3M13bfI122eHzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 16 Sep 2003 19:34:17.0843 (UTC) FILETIME=[84E46430:01C37C89] Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Nested Tunnels Optimization using Nested Path Information Author(s) : J. Na et al. Filename : draft-na-nemo-nested-path-info-00.txt Pages : 21 Date : 2003-9-16 This document addresses how to securely achieve the nested tunnels optimization using nested path information that reflects the optimized path from Top Level Mobile Router(TLMR) to Mobile Router(MR) in nested mobile networks. The solution is based on Reverse Routing Header(RRH) idea and the concern of security problem in RRH. By carefully taking a look at the simplicity of Routing Header Type 2 routing mechanism and the complexity of Access Router Option(ARO) based solution to get rid of the threat of possible attack for RRH, the proposed solution has been considered to preserve the efficiency of RRH without the lack of security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-na-nemo-nested-path-info-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-na-nemo-nested-path-info-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-16115419.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Thu Sep 18 02:27:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28814 for ; Thu, 18 Sep 2003 02:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsFr-0006ff-8G; Thu, 18 Sep 2003 02:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsFc-0006f3-Db for nemo@optimus.ietf.org; Thu, 18 Sep 2003 02:26:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28801 for ; Thu, 18 Sep 2003 02:26:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zsFY-0001Q3-00 for nemo@ietf.org; Thu, 18 Sep 2003 02:26:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19zsFY-0001Pj-00 for nemo@ietf.org; Thu, 18 Sep 2003 02:26:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2003 08:24:49 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8I6Q45u008480; Thu, 18 Sep 2003 08:26:05 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 07:26:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Thu, 18 Sep 2003 07:26:04 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN8hA1sCzD7NaXHRCeX2iIJu6gplwBJc+Dw From: "Pascal Thubert (pthubert)" To: , , , , , Cc: X-OriginalArrivalTime: 18 Sep 2003 06:26:05.0396 (UTC) FILETIME=[BD392940:01C37DAD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jongkeun (and all) First, thanks for this piece of work and for the in-depth study you are making. Also it seems to me it's OK discuss the RRH in the ML since the basic draft is pretty advanced now... I have few issues about the first version of draft: 1) I'm not sure what the security issue is exactly; after Chan-Wah and Takeshi published their draft, we spent quite some time discussing the possible attacks against RRH. I talked again about that with Hiroyuki Ohnishi from NTT on the same subject. We have not identified an attack against RRH that could not be done more easily otherwise. Could you please consider the threat analysis in more depth so we understand which issue you address exactly? 2) TIO has a hash of the nested CareOf. This is used to discover a branch level mobility somewhere between the MR and the AR. It seems to me that this information alone would be enough if we wanted to proactively sign the RRH. But then this delays the movement tracking, since we need to wait for the MR to learn about the movement. This is why we did not do it. Again, we need a threat analysis that would uncover a threat against the current draft. 3) Note that the RH type 2 in RRH can only go down the tree, why protects against a rogue within the tree from bombing outside the tree. The rogue will get the traffic back anyway. IPSec is recommended to protect the packets. Seems that the worst that can happen is blacking (or graying) out. Which could be done easily at the radio level or by discarding the packets.=20 4) For an attacker in the infrastructure (between AR and HA), the threat may be different since it could bomb any place at will. But a router placed like this could do a lot more than changing RRH. It could forge topology correct packets (source and dest) and generate the attck itself. We expect that these (core) routers are secure. 5) If a path is not working, the MR should try another one. Our view is that MR should overtime build several CareOf via several ARs, and select the best path based on metrics such as bandwidth. What's the difference between a bad guy blacking you out and a good one with no upstream bandwidth? What do you think? Pascal > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: mardi 16 septembre 2003 20:53 > Cc: nemo@ietf.org > Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : Secure Nested Tunnels Optimization using Nested Path > Information > Author(s) : J. Na et al. > Filename : draft-na-nemo-nested-path-info-00.txt > Pages : 21 > Date : 2003-9-16 >=20 > This document addresses how to securely achieve the nested tunnels > optimization using nested path information that reflects the > optimized path from Top Level Mobile Router(TLMR) to Mobile > Router(MR) in nested mobile networks. The solution is based on > Reverse Routing Header(RRH) idea and the concern of security problem in RRH. By carefully > taking a look at the simplicity of > Routing Header Type 2 routing mechanism and the complexity of > Access Router Option(ARO) based solution to get rid of the threat > of possible attack for RRH, the proposed solution has been > considered to preserve the efficiency of RRH without the lack of > security. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.tx t >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-na-nemo-nested-path-info-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From exim@www1.ietf.org Thu Sep 18 02:27:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28829 for ; Thu, 18 Sep 2003 02:27:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsFy-0006gc-3z for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 02:27:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I6RAZr025702 for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 02:27:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsFx-0006gT-IN for nemo-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 02:27:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28810 for ; Thu, 18 Sep 2003 02:27:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zsFu-0001QC-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 02:27:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zsFt-0001Q8-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 02:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsFr-0006ff-8G; Thu, 18 Sep 2003 02:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zsFc-0006f3-Db for nemo@optimus.ietf.org; Thu, 18 Sep 2003 02:26:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28801 for ; Thu, 18 Sep 2003 02:26:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zsFY-0001Q3-00 for nemo@ietf.org; Thu, 18 Sep 2003 02:26:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19zsFY-0001Pj-00 for nemo@ietf.org; Thu, 18 Sep 2003 02:26:44 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2003 08:24:49 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8I6Q45u008480; Thu, 18 Sep 2003 08:26:05 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 07:26:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Thu, 18 Sep 2003 07:26:04 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN8hA1sCzD7NaXHRCeX2iIJu6gplwBJc+Dw From: "Pascal Thubert (pthubert)" To: , , , , , Cc: X-OriginalArrivalTime: 18 Sep 2003 06:26:05.0396 (UTC) FILETIME=[BD392940:01C37DAD] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jongkeun (and all) First, thanks for this piece of work and for the in-depth study you are making. Also it seems to me it's OK discuss the RRH in the ML since the basic draft is pretty advanced now... I have few issues about the first version of draft: 1) I'm not sure what the security issue is exactly; after Chan-Wah and Takeshi published their draft, we spent quite some time discussing the possible attacks against RRH. I talked again about that with Hiroyuki Ohnishi from NTT on the same subject. We have not identified an attack against RRH that could not be done more easily otherwise. Could you please consider the threat analysis in more depth so we understand which issue you address exactly? 2) TIO has a hash of the nested CareOf. This is used to discover a branch level mobility somewhere between the MR and the AR. It seems to me that this information alone would be enough if we wanted to proactively sign the RRH. But then this delays the movement tracking, since we need to wait for the MR to learn about the movement. This is why we did not do it. Again, we need a threat analysis that would uncover a threat against the current draft. 3) Note that the RH type 2 in RRH can only go down the tree, why protects against a rogue within the tree from bombing outside the tree. The rogue will get the traffic back anyway. IPSec is recommended to protect the packets. Seems that the worst that can happen is blacking (or graying) out. Which could be done easily at the radio level or by discarding the packets.=20 4) For an attacker in the infrastructure (between AR and HA), the threat may be different since it could bomb any place at will. But a router placed like this could do a lot more than changing RRH. It could forge topology correct packets (source and dest) and generate the attck itself. We expect that these (core) routers are secure. 5) If a path is not working, the MR should try another one. Our view is that MR should overtime build several CareOf via several ARs, and select the best path based on metrics such as bandwidth. What's the difference between a bad guy blacking you out and a good one with no upstream bandwidth? What do you think? Pascal > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: mardi 16 septembre 2003 20:53 > Cc: nemo@ietf.org > Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directories. >=20 >=20 > Title : Secure Nested Tunnels Optimization using Nested Path > Information > Author(s) : J. Na et al. > Filename : draft-na-nemo-nested-path-info-00.txt > Pages : 21 > Date : 2003-9-16 >=20 > This document addresses how to securely achieve the nested tunnels > optimization using nested path information that reflects the > optimized path from Top Level Mobile Router(TLMR) to Mobile > Router(MR) in nested mobile networks. The solution is based on > Reverse Routing Header(RRH) idea and the concern of security problem in RRH. By carefully > taking a look at the simplicity of > Routing Header Type 2 routing mechanism and the complexity of > Access Router Option(ARO) based solution to get rid of the threat > of possible attack for RRH, the proposed solution has been > considered to preserve the efficiency of RRH without the lack of > security. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.tx t >=20 > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-na-nemo-nested-path-info-00.txt". >=20 > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From nemo-admin@ietf.org Thu Sep 18 11:11:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16931 for ; Thu, 18 Sep 2003 11:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00Qx-0008QI-UU; Thu, 18 Sep 2003 11:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00Qm-0008Pb-UD for nemo@optimus.ietf.org; Thu, 18 Sep 2003 11:10:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16860 for ; Thu, 18 Sep 2003 11:10:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00Qk-0007Hs-00 for nemo@ietf.org; Thu, 18 Sep 2003 11:10:50 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1A00Qi-0007HT-00 for nemo@ietf.org; Thu, 18 Sep 2003 11:10:49 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h8IF7492022618; Fri, 19 Sep 2003 00:07:04 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , , , , , Cc: Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Fri, 19 Sep 2003 00:10:15 +0900 Message-ID: <014001c37df6$f6dcd400$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pascal, Thanks for your interest. I also think it's a good time to discuss RO issue. > I have few issues about the first version of draft: > > 1) I'm not sure what the security issue is exactly; after Chan-Wah and > Takeshi published their draft, we spent quite some time discussing the > possible attacks against RRH. I talked again about that with Hiroyuki > Ohnishi from NTT on the same subject. We have not identified an attack > against RRH that could not be done more easily otherwise. Could you > please consider the threat analysis in more depth so we understand which > issue you address exactly? > Basically I mean the spoofing attack for RRH in which some intermediate MR(faked or one victim of attacker) can easily insert arbitrary address in arbitrary slot. In other words, that can cause the redirection of the forward routing path under no detection in both HA and MR during some period time. The packet redirection by the spoofing attack means that the attacker can give us the following threats. 1) Information Disclosed - if the packets forwarded by HA are redirected to the node(which is a repository for capturing some information for the attacker) on Internet, that information will be used to do the second or third attack. I think that it will be still helpful to the owner even if it is encrypted because it can be an input to the traffic analysis or to decrypt the cipertext. 2) Active Denial of Service - if all packets sent from HA(/CNs) can be redirected to some targeted server(as a victim) on Internet, it becomes one of holes for DOS attack. Above two cases are just all of my instant thinking but I expect another cases apparently exist in the real world. We should try to find more threats. Are above mentioned threats reasonable or not? It needs more discussion. > 2) TIO has a hash of the nested CareOf. This is used to discover a > branch level mobility somewhere between the MR and the AR. It seems to > me that this information alone would be enough if we wanted to > proactively sign the RRH. But then this delays the movement tracking, > since we need to wait for the MR to learn about the movement. This is > why we did not do it. Again, we need a threat analysis that would > uncover a threat against the current draft. > Good insight. If I knew in advance your intention about this, it would help me. At first while I was reading your draft, I wondered why TIO is only limited used.:) About movement tracking delay, I agree it need more delay than RRH based per-packet. But, I think some delay is tolerable for the security because nested relationship is unlikely changed too frequently. > 3) Note that the RH type 2 in RRH can only go down the tree, why > protects against a rogue within the tree from bombing outside the tree. > The rogue will get the traffic back anyway. IPSec is recommended to > protect the packets. Seems that the worst that can happen is blacking > (or graying) out. Which could be done easily at the radio level or by > discarding the packets. > If TLMR is a faked one, it's possible. Is'nt? And an intermediate MR(which is controlled by the local attacker) can make the packets to redirect to some information processing node in the same local link. > 4) For an attacker in the infrastructure (between AR and HA), the threat > may be different since it could bomb any place at will. But a router > placed like this could do a lot more than changing RRH. It could forge > topology correct packets (source and dest) and generate the attck > itself. We expect that these (core) routers are secure. > In our draft, one MR can be AR to MR which is in one level down. In here, AR means one of nested MRs, not true fixed access router in the infrastructure. We should suspect the nested MR is correct for above threats I mentioned. In contrary, RRH is fully depend on the trust relationship among nested MRs. How to get that MR-MR relationship of trustworthy if MRs do not have the same administrative domain? This maybe out of scope of our disccusion. For this, at least we need to protect the integrity of the routing path between TLMR and MR to which MR designates. > 5) If a path is not working, the MR should try another one. Our view is > that MR should overtime build several CareOf via several ARs, and select > the best path based on metrics such as bandwidth. What's the difference > between a bad guy blacking you out and a good one with no upstream > bandwidth? > The selection problem of best path is another point we should consider. I think MR can choice the best path by its own policy or simply information which can be provided by the upper-level MRs/ARs. Particularly it is more valuable feature under the multi-homed nested environment. /Jongkeun > What do you think? > > Pascal > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: mardi 16 septembre 2003 20:53 > > Cc: nemo@ietf.org > > Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Secure Nested Tunnels Optimization using > Nested Path > > Information > > Author(s) : J. Na et al. > > Filename : draft-na-nemo-nested-path-info-00.txt > > Pages : 21 > > Date : 2003-9-16 > > > > This document addresses how to securely achieve the nested tunnels > > optimization using nested path information that reflects the > > optimized path from Top Level Mobile Router(TLMR) to Mobile > > Router(MR) in nested mobile networks. The solution is based on > > Reverse Routing Header(RRH) idea and the concern of security problem > in RRH. By carefully > > taking a look at the simplicity of > > Routing Header Type 2 routing mechanism and the complexity of > > Access Router Option(ARO) based solution to get rid of the threat > > of possible attack for RRH, the proposed solution has been > > considered to preserve the efficiency of RRH without the lack of > > security. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.tx > t > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-na-nemo-nested-path-info-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. From exim@www1.ietf.org Thu Sep 18 11:11:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16987 for ; Thu, 18 Sep 2003 11:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00RJ-0008W8-8P for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 11:11:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IFBP4C032734 for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 11:11:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00RJ-0008Vt-2G for nemo-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 11:11:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16911 for ; Thu, 18 Sep 2003 11:11:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00R1-0007IS-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 11:11:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A00R0-0007IP-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 11:11:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00Qx-0008QI-UU; Thu, 18 Sep 2003 11:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A00Qm-0008Pb-UD for nemo@optimus.ietf.org; Thu, 18 Sep 2003 11:10:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16860 for ; Thu, 18 Sep 2003 11:10:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A00Qk-0007Hs-00 for nemo@ietf.org; Thu, 18 Sep 2003 11:10:50 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1A00Qi-0007HT-00 for nemo@ietf.org; Thu, 18 Sep 2003 11:10:49 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h8IF7492022618; Fri, 19 Sep 2003 00:07:04 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , , , , , Cc: Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Fri, 19 Sep 2003 00:10:15 +0900 Message-ID: <014001c37df6$f6dcd400$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pascal, Thanks for your interest. I also think it's a good time to discuss RO issue. > I have few issues about the first version of draft: > > 1) I'm not sure what the security issue is exactly; after Chan-Wah and > Takeshi published their draft, we spent quite some time discussing the > possible attacks against RRH. I talked again about that with Hiroyuki > Ohnishi from NTT on the same subject. We have not identified an attack > against RRH that could not be done more easily otherwise. Could you > please consider the threat analysis in more depth so we understand which > issue you address exactly? > Basically I mean the spoofing attack for RRH in which some intermediate MR(faked or one victim of attacker) can easily insert arbitrary address in arbitrary slot. In other words, that can cause the redirection of the forward routing path under no detection in both HA and MR during some period time. The packet redirection by the spoofing attack means that the attacker can give us the following threats. 1) Information Disclosed - if the packets forwarded by HA are redirected to the node(which is a repository for capturing some information for the attacker) on Internet, that information will be used to do the second or third attack. I think that it will be still helpful to the owner even if it is encrypted because it can be an input to the traffic analysis or to decrypt the cipertext. 2) Active Denial of Service - if all packets sent from HA(/CNs) can be redirected to some targeted server(as a victim) on Internet, it becomes one of holes for DOS attack. Above two cases are just all of my instant thinking but I expect another cases apparently exist in the real world. We should try to find more threats. Are above mentioned threats reasonable or not? It needs more discussion. > 2) TIO has a hash of the nested CareOf. This is used to discover a > branch level mobility somewhere between the MR and the AR. It seems to > me that this information alone would be enough if we wanted to > proactively sign the RRH. But then this delays the movement tracking, > since we need to wait for the MR to learn about the movement. This is > why we did not do it. Again, we need a threat analysis that would > uncover a threat against the current draft. > Good insight. If I knew in advance your intention about this, it would help me. At first while I was reading your draft, I wondered why TIO is only limited used.:) About movement tracking delay, I agree it need more delay than RRH based per-packet. But, I think some delay is tolerable for the security because nested relationship is unlikely changed too frequently. > 3) Note that the RH type 2 in RRH can only go down the tree, why > protects against a rogue within the tree from bombing outside the tree. > The rogue will get the traffic back anyway. IPSec is recommended to > protect the packets. Seems that the worst that can happen is blacking > (or graying) out. Which could be done easily at the radio level or by > discarding the packets. > If TLMR is a faked one, it's possible. Is'nt? And an intermediate MR(which is controlled by the local attacker) can make the packets to redirect to some information processing node in the same local link. > 4) For an attacker in the infrastructure (between AR and HA), the threat > may be different since it could bomb any place at will. But a router > placed like this could do a lot more than changing RRH. It could forge > topology correct packets (source and dest) and generate the attck > itself. We expect that these (core) routers are secure. > In our draft, one MR can be AR to MR which is in one level down. In here, AR means one of nested MRs, not true fixed access router in the infrastructure. We should suspect the nested MR is correct for above threats I mentioned. In contrary, RRH is fully depend on the trust relationship among nested MRs. How to get that MR-MR relationship of trustworthy if MRs do not have the same administrative domain? This maybe out of scope of our disccusion. For this, at least we need to protect the integrity of the routing path between TLMR and MR to which MR designates. > 5) If a path is not working, the MR should try another one. Our view is > that MR should overtime build several CareOf via several ARs, and select > the best path based on metrics such as bandwidth. What's the difference > between a bad guy blacking you out and a good one with no upstream > bandwidth? > The selection problem of best path is another point we should consider. I think MR can choice the best path by its own policy or simply information which can be provided by the upper-level MRs/ARs. Particularly it is more valuable feature under the multi-homed nested environment. /Jongkeun > What do you think? > > Pascal > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: mardi 16 septembre 2003 20:53 > > Cc: nemo@ietf.org > > Subject: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Secure Nested Tunnels Optimization using > Nested Path > > Information > > Author(s) : J. Na et al. > > Filename : draft-na-nemo-nested-path-info-00.txt > > Pages : 21 > > Date : 2003-9-16 > > > > This document addresses how to securely achieve the nested tunnels > > optimization using nested path information that reflects the > > optimized path from Top Level Mobile Router(TLMR) to Mobile > > Router(MR) in nested mobile networks. The solution is based on > > Reverse Routing Header(RRH) idea and the concern of security problem > in RRH. By carefully > > taking a look at the simplicity of > > Routing Header Type 2 routing mechanism and the complexity of > > Access Router Option(ARO) based solution to get rid of the threat > > of possible attack for RRH, the proposed solution has been > > considered to preserve the efficiency of RRH without the lack of > > security. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-na-nemo-nested-path-info-00.tx > t > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-na-nemo-nested-path-info-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-na-nemo-nested-path-info-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. From nemo-admin@ietf.org Thu Sep 18 12:20:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20968 for ; Thu, 18 Sep 2003 12:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01Vj-000490-G6; Thu, 18 Sep 2003 12:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxuk-0002WM-Dr for nemo@optimus.ietf.org; Thu, 18 Sep 2003 08:29:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09174; Thu, 18 Sep 2003 08:29:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zxuj-0005Ck-00; Thu, 18 Sep 2003 08:29:37 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19zxui-0005Cc-00; Thu, 18 Sep 2003 08:29:36 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 22AA76BA7F; Thu, 18 Sep 2003 08:29:06 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.9/8.12.9) with ESMTP id h8ICT5op023478; Thu, 18 Sep 2003 08:29:05 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h8ICT4RT026301; Thu, 18 Sep 2003 08:29:04 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030918081421.01822670@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 18 Sep 2003 08:29:03 -0400 To: mip4@ietf.org, nemo@ietf.org From: William D Ivancic Cc: sharon Gowan In-Reply-To: <5.1.0.14.2.20030911083507.03b53850@po2.bbn.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_587616718==.ALT" Subject: [nemo] Secure Mobile Networking Deployment Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_587616718==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable We recently / currently have secure mobile networking deployed in and=20 "experimental" operational setting onboard a US Coast Guard Cutter. The=20 system is described in the following paper, "Securing Mobile Networks in an= =20 Operational Setting." This may be of interest to mip4 and nemo regarding= =20 multihoming and security issues and actual problems that needed to be=20 solved to deploy this over the Open Internet. http://roland.grc.nasa.gov/~ivancic/papers_presentations/IEEE_PID24402.pdf Abstract=97This paper describes a network demonstration three month field trial of mobile networking using IPv4. The network was implemented as part of the Guard operational network which is a ".mil" network requires stringent levels of security. The initial demonstrations took place in November 2002 and a three month field place from July through September of 2003. The network utilized encryptors capable of NSA-approved algorithms, mobile router from Cisco Systems and 802.11 satellite wireless links. This paper also describes a conceptual architecture for wide-scale deployment of secure networking in operational environments where both and public infrastructure is used. Additional issues include link costs, placement of encryptors and routing protocols over layer-3 encryption devices. We are currently working with T-Mobile and then Verison Wireless in the US= =20 to be able to deploy mobile-IPv4 over GPRS (56 kbps) and CDMA (114=20 kbps). There appears to be a lot of NAT / PAT and administrative=20 filtering issues that we are trying to resolve. Hopefully, what we learn=20 with IPv4 can be applied to IPv6. We will pass whatever useful information= =20 we can on to these groups. Another area we just completed was deploying and IPv4 mobile network that=20 can move between the NASA Private address space and the public address=20 space. This wasn't terribly difficult, but required a lot of coordination= =20 with the security personnel controlling the firewalls. We are trying to=20 understand how the firewall rule impact features like dynamic home agent=20 deployment. Once completed, we will document this and pass the=20 information on. Will --=====================_587616718==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We recently / currently have secure mobile networking deployed in and "experimental" operational setting onboard a US Coast Guard Cutter.  The system is described in the following paper, "Securing Mobile Networks in an Operational Setting."   This may be of interest to mip4 and nemo regarding multihoming and security issues and actual problems that needed to be solved to deploy this over the Open Internet. 

http://roland.grc.nasa.gov/~ivancic/papers_presentations= /IEEE_PID24402.pdf

Abstract=97This paper describes a network demonstration
three month field trial of mobile networking using
IPv4. The network was implemented as part of the
Guard operational network which is a ".mil" network
requires stringent levels of security. The initial demonstrations
took place in November 2002 and a three month field
place from July through September of 2003. The
network utilized encryptors capable of NSA-approved
algorithms, mobile router from Cisco Systems and 802.11
satellite wireless links. This paper also describes a conceptual
architecture for wide-scale deployment of secure
networking in operational environments where both
and public infrastructure is used. Additional issues
include link costs, placement of encryptors and
routing protocols over layer-3 encryption devices.

We are currently working with T-Mobile and then Verison Wireless in the US to be able to deploy mobile-IPv4 over GPRS (56 kbps) and CDMA (114 kbps).   There appears to be a lot of NAT / PAT and administrative filtering issues that we are trying to resolve.  Hopefully, what we learn with IPv4 can be applied to IPv6.  We will pass whatever useful information we can on to these groups.

Another area we just completed was deploying and IPv4 mobile network that can move between the NASA Private address space and the public address space.  This wasn't terribly difficult, but required a lot of coordination with the security personnel controlling the firewalls.  We are trying to understand how the firewall rule impact features like dynamic home agent deployment.   Once completed, we will document this and pass the information on. 


Will
--=====================_587616718==.ALT-- From exim@www1.ietf.org Thu Sep 18 12:20:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20985 for ; Thu, 18 Sep 2003 12:20:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01Vr-00049w-02 for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 12:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IGKABC015982 for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 12:20:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01Vn-00049h-HH for nemo-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 12:20:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20954 for ; Thu, 18 Sep 2003 12:19:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01Vm-0000t0-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 12:20:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A01Vl-0000sx-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 12:20:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01Vj-000490-G6; Thu, 18 Sep 2003 12:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxuk-0002WM-Dr for nemo@optimus.ietf.org; Thu, 18 Sep 2003 08:29:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09174; Thu, 18 Sep 2003 08:29:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zxuj-0005Ck-00; Thu, 18 Sep 2003 08:29:37 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19zxui-0005Cc-00; Thu, 18 Sep 2003 08:29:36 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 22AA76BA7F; Thu, 18 Sep 2003 08:29:06 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.9/8.12.9) with ESMTP id h8ICT5op023478; Thu, 18 Sep 2003 08:29:05 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h8ICT4RT026301; Thu, 18 Sep 2003 08:29:04 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030918081421.01822670@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 18 Sep 2003 08:29:03 -0400 To: mip4@ietf.org, nemo@ietf.org From: William D Ivancic Cc: sharon Gowan In-Reply-To: <5.1.0.14.2.20030911083507.03b53850@po2.bbn.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_587616718==.ALT" Subject: [nemo] Secure Mobile Networking Deployment Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --=====================_587616718==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable We recently / currently have secure mobile networking deployed in and=20 "experimental" operational setting onboard a US Coast Guard Cutter. The=20 system is described in the following paper, "Securing Mobile Networks in an= =20 Operational Setting." This may be of interest to mip4 and nemo regarding= =20 multihoming and security issues and actual problems that needed to be=20 solved to deploy this over the Open Internet. http://roland.grc.nasa.gov/~ivancic/papers_presentations/IEEE_PID24402.pdf Abstract=97This paper describes a network demonstration three month field trial of mobile networking using IPv4. The network was implemented as part of the Guard operational network which is a ".mil" network requires stringent levels of security. The initial demonstrations took place in November 2002 and a three month field place from July through September of 2003. The network utilized encryptors capable of NSA-approved algorithms, mobile router from Cisco Systems and 802.11 satellite wireless links. This paper also describes a conceptual architecture for wide-scale deployment of secure networking in operational environments where both and public infrastructure is used. Additional issues include link costs, placement of encryptors and routing protocols over layer-3 encryption devices. We are currently working with T-Mobile and then Verison Wireless in the US= =20 to be able to deploy mobile-IPv4 over GPRS (56 kbps) and CDMA (114=20 kbps). There appears to be a lot of NAT / PAT and administrative=20 filtering issues that we are trying to resolve. Hopefully, what we learn=20 with IPv4 can be applied to IPv6. We will pass whatever useful information= =20 we can on to these groups. Another area we just completed was deploying and IPv4 mobile network that=20 can move between the NASA Private address space and the public address=20 space. This wasn't terribly difficult, but required a lot of coordination= =20 with the security personnel controlling the firewalls. We are trying to=20 understand how the firewall rule impact features like dynamic home agent=20 deployment. Once completed, we will document this and pass the=20 information on. Will --=====================_587616718==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We recently / currently have secure mobile networking deployed in and "experimental" operational setting onboard a US Coast Guard Cutter.  The system is described in the following paper, "Securing Mobile Networks in an Operational Setting."   This may be of interest to mip4 and nemo regarding multihoming and security issues and actual problems that needed to be solved to deploy this over the Open Internet. 

http://roland.grc.nasa.gov/~ivancic/papers_presentations= /IEEE_PID24402.pdf

Abstract=97This paper describes a network demonstration
three month field trial of mobile networking using
IPv4. The network was implemented as part of the
Guard operational network which is a ".mil" network
requires stringent levels of security. The initial demonstrations
took place in November 2002 and a three month field
place from July through September of 2003. The
network utilized encryptors capable of NSA-approved
algorithms, mobile router from Cisco Systems and 802.11
satellite wireless links. This paper also describes a conceptual
architecture for wide-scale deployment of secure
networking in operational environments where both
and public infrastructure is used. Additional issues
include link costs, placement of encryptors and
routing protocols over layer-3 encryption devices.

We are currently working with T-Mobile and then Verison Wireless in the US to be able to deploy mobile-IPv4 over GPRS (56 kbps) and CDMA (114 kbps).   There appears to be a lot of NAT / PAT and administrative filtering issues that we are trying to resolve.  Hopefully, what we learn with IPv4 can be applied to IPv6.  We will pass whatever useful information we can on to these groups.

Another area we just completed was deploying and IPv4 mobile network that can move between the NASA Private address space and the public address space.  This wasn't terribly difficult, but required a lot of coordination with the security personnel controlling the firewalls.  We are trying to understand how the firewall rule impact features like dynamic home agent deployment.   Once completed, we will document this and pass the information on. 


Will
--=====================_587616718==.ALT-- From nemo-admin@ietf.org Thu Sep 18 12:41:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22396 for ; Thu, 18 Sep 2003 12:41:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q1-0005MA-Jf; Thu, 18 Sep 2003 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01pI-0005Gt-S0 for nemo@optimus.ietf.org; Thu, 18 Sep 2003 12:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22176 for ; Thu, 18 Sep 2003 12:40:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01pH-0001Tb-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:40:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A01pG-0001Qa-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:40:14 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2003 18:38:26 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8IGdfdY001195 for ; Thu, 18 Sep 2003 18:39:43 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 17:39:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Thu, 18 Sep 2003 17:39:22 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN99y4Q6gcRywIeQUKJR+MxOw1kvQAClcYA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: X-OriginalArrivalTime: 18 Sep 2003 16:39:42.0833 (UTC) FILETIME=[76203610:01C37E03] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > > issue you address exactly? > > > Basically I mean the spoofing attack for RRH in which some intermediate > MR(faked or one victim of attacker) can easily insert arbitrary address > in arbitrary slot. In other words, that can cause the redirection of the > forward routing path under no detection in both HA and MR during some > period time. The packet redirection by the spoofing attack means that > the attacker can give us the following threats. >=20 Well, there's the RH type 2 forwarding rules that make the attacker get The packets back to him, if the attacker is in the nested structure, as we explain in the draft. I expect that in general the TLMR will be=20 actually the AR, in order to prevent faking the Source of the packet as seen by the HA. I believe that the result is the same exactly if the TIO extension you propose is faked. And I agree with your conclusion that the attacks that this opens to could be done in an easier fashion by other means. Same exactly for RRH :) > 1) Information Disclosed - if the packets forwarded by HA are redirected > to the node(which is a repository for capturing some information for the > attacker) on Internet, that information will be used to do the second or > third attack. I think that it will be still helpful to the owner even if > it is encrypted because it can be an input to the traffic analysis or to > decrypt the cipertext. Again, RH2 will not let the packet leave the nested structure once it is in. If you want, the nested structure is seen globally as a black bow. Once the packet is in, it will never get out. Always down the tree. > 2) Active Denial of Service - if all packets sent from HA(/CNs) can be > redirected to some targeted server(as a victim) on Internet, it becomes > one of holes for DOS attack. >=20 > Above two cases are just all of my instant thinking but I expect another > cases apparently exist in the real world. We should try to find more > threats. Are above mentioned threats reasonable or not? It needs more > discussion. If the access router is not TLMR and if it does not check tke topological Coreectedness of the source, it may happen that an attacker forges the=20 Source of the packet. But then you do not need all the MIP thing to do that. 1) I expect AR to check the source address (per standard) 2) I expect AR to actually be the TLMR and the source of the packets as seen by HA 3) I expect that the infrastructure is safe (if it is not, again, there are other simpler attacks for a rogue on axis So the threat you mention is covered.... for both drafts. Again, I do not see what the RH6 adds there since the info you have may be faked for all you know... What do you think? Pascal From exim@www1.ietf.org Thu Sep 18 12:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22412 for ; Thu, 18 Sep 2003 12:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q8-0005OY-Ry for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 12:41:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IGf8ZR020732 for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 12:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q8-0005OJ-Mo for nemo-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 12:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22287 for ; Thu, 18 Sep 2003 12:41:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01q7-0001Zh-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 12:41:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A01q6-0001Zc-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 12:41:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01q1-0005MA-Jf; Thu, 18 Sep 2003 12:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01pI-0005Gt-S0 for nemo@optimus.ietf.org; Thu, 18 Sep 2003 12:40:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22176 for ; Thu, 18 Sep 2003 12:40:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01pH-0001Tb-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:40:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A01pG-0001Qa-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:40:14 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2003 18:38:26 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8IGdfdY001195 for ; Thu, 18 Sep 2003 18:39:43 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 17:39:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Thu, 18 Sep 2003 17:39:22 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN99y4Q6gcRywIeQUKJR+MxOw1kvQAClcYA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: X-OriginalArrivalTime: 18 Sep 2003 16:39:42.0833 (UTC) FILETIME=[76203610:01C37E03] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > issue you address exactly? > > > Basically I mean the spoofing attack for RRH in which some intermediate > MR(faked or one victim of attacker) can easily insert arbitrary address > in arbitrary slot. In other words, that can cause the redirection of the > forward routing path under no detection in both HA and MR during some > period time. The packet redirection by the spoofing attack means that > the attacker can give us the following threats. >=20 Well, there's the RH type 2 forwarding rules that make the attacker get The packets back to him, if the attacker is in the nested structure, as we explain in the draft. I expect that in general the TLMR will be=20 actually the AR, in order to prevent faking the Source of the packet as seen by the HA. I believe that the result is the same exactly if the TIO extension you propose is faked. And I agree with your conclusion that the attacks that this opens to could be done in an easier fashion by other means. Same exactly for RRH :) > 1) Information Disclosed - if the packets forwarded by HA are redirected > to the node(which is a repository for capturing some information for the > attacker) on Internet, that information will be used to do the second or > third attack. I think that it will be still helpful to the owner even if > it is encrypted because it can be an input to the traffic analysis or to > decrypt the cipertext. Again, RH2 will not let the packet leave the nested structure once it is in. If you want, the nested structure is seen globally as a black bow. Once the packet is in, it will never get out. Always down the tree. > 2) Active Denial of Service - if all packets sent from HA(/CNs) can be > redirected to some targeted server(as a victim) on Internet, it becomes > one of holes for DOS attack. >=20 > Above two cases are just all of my instant thinking but I expect another > cases apparently exist in the real world. We should try to find more > threats. Are above mentioned threats reasonable or not? It needs more > discussion. If the access router is not TLMR and if it does not check tke topological Coreectedness of the source, it may happen that an attacker forges the=20 Source of the packet. But then you do not need all the MIP thing to do that. 1) I expect AR to check the source address (per standard) 2) I expect AR to actually be the TLMR and the source of the packets as seen by HA 3) I expect that the infrastructure is safe (if it is not, again, there are other simpler attacks for a rogue on axis So the threat you mention is covered.... for both drafts. Again, I do not see what the RH6 adds there since the info you have may be faked for all you know... What do you think? Pascal From nemo-admin@ietf.org Thu Sep 18 12:53:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23374 for ; Thu, 18 Sep 2003 12:53:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A021d-0007JL-FJ; Thu, 18 Sep 2003 12:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A021V-0007IY-3x for nemo@optimus.ietf.org; Thu, 18 Sep 2003 12:52:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23354 for ; Thu, 18 Sep 2003 12:52:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A021T-0002jP-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:52:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A021S-0002go-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:52:51 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2003 18:51:03 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8IGqI14003750; Thu, 18 Sep 2003 18:52:19 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 17:52:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Thu, 18 Sep 2003 17:51:41 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN99y4Q6gcRywIeQUKJR+MxOw1kvQADBJbA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: , "Marco Molteni (mmolteni)" X-OriginalArrivalTime: 18 Sep 2003 16:52:19.0291 (UTC) FILETIME=[39028AB0:01C37E05] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > > 2) TIO has a hash of the nested CareOf. This is used to discover a > > branch level mobility somewhere between the MR and the AR. It seems to > > me that this information alone would be enough if we wanted to > > proactively sign the RRH. But then this delays the movement tracking, > > since we need to wait for the MR to learn about the movement. This is > > why we did not do it. Again, we need a threat analysis that would > > uncover a threat against the current draft. > > > Good insight. If I knew in advance your intention about this, it would > help me. > At first while I was reading your draft, I wondered why TIO is only > limited used.:) There's MUCHO more to it. Eg AR selection, loop avoidance :) > About movement tracking delay, I agree it need more delay than RRH based > per-packet. But, I think some delay is tolerable for the security > because nested relationship is unlikely changed too frequently. >=20 If you prove me that you bring any additional security where there was a threat, right?=20 > > 3) Note that the RH type 2 in RRH can only go down the tree, why > > protects against a rogue within the tree from bombing outside the > tree. > > The rogue will get the traffic back anyway. IPSec is recommended to > > protect the packets. Seems that the worst that can happen is blacking > > (or graying) out. Which could be done easily at the radio level or by > > discarding the packets. > > > If TLMR is a faked one, it's possible. Is'nt? And an intermediate > MR(which is controlled by the local attacker) can make the packets to > redirect to some information processing node in the same local link. >=20 Same with your draft, or did I miss something? But then again, it's easy to prevent this by having plain ingress filtering rules at the AR and optionally by placing a TLMR there. > > 4) For an attacker in the infrastructure (between AR and HA), the > threat > > may be different since it could bomb any place at will. But a router > > placed like this could do a lot more than changing RRH. It could forge > > topology correct packets (source and dest) and generate the attck > > itself. We expect that these (core) routers are secure. > > > In our draft, one MR can be AR to MR which is in one level down. In > here, AR means one of nested MRs, not true fixed access router in the > infrastructure. We should suspect the nested MR is correct for above > threats I mentioned. In contrary, RRH is fully depend on the trust > relationship among nested MRs. How to get that MR-MR relationship of > trustworthy if MRs do not have the same administrative domain? This > maybe out of scope of our disccusion. For this, at least we need to > protect the integrity of the routing path between TLMR and MR to which > MR designates. >=20 You do not know that path for sure so how would you protect it?=20 The info you get in TIO may be all faked as well. I do not understand your point of RRH being dependent on the MR-MR trust. Can you please detail? In my mind there's no such a thing. =20 > > 5) If a path is not working, the MR should try another one. Our view > is > > that MR should overtime build several CareOf via several ARs, and > select > > the best path based on metrics such as bandwidth. What's the > difference > > between a bad guy blacking you out and a good one with no upstream > > bandwidth? > > >=20 > The selection problem of best path is another point we should consider. > I think MR can choice the best path by its own policy or simply > information which can be provided by the upper-level MRs/ARs. > Particularly it is more valuable feature under the multi-homed nested > environment. >=20 Fully agreed. And TIO is a powerful tool for that selection, as you realized for sure. Add a few dynamic metrics to evaluate, say, the bandwidth of alternate path, and there you go. Pascal From exim@www1.ietf.org Thu Sep 18 12:53:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23389 for ; Thu, 18 Sep 2003 12:53:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A021g-0007KZ-Ug for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 12:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IGr4Dv028173 for nemo-archive@odin.ietf.org; Thu, 18 Sep 2003 12:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A021g-0007KK-PS for nemo-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 12:53:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23359 for ; Thu, 18 Sep 2003 12:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A021e-0002kQ-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 12:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A021e-0002kN-00 for nemo-web-archive@ietf.org; Thu, 18 Sep 2003 12:53:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A021d-0007JL-FJ; Thu, 18 Sep 2003 12:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A021V-0007IY-3x for nemo@optimus.ietf.org; Thu, 18 Sep 2003 12:52:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23354 for ; Thu, 18 Sep 2003 12:52:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A021T-0002jP-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:52:51 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A021S-0002go-00 for nemo@ietf.org; Thu, 18 Sep 2003 12:52:51 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2003 18:51:03 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8IGqI14003750; Thu, 18 Sep 2003 18:52:19 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 18 Sep 2003 17:52:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Thu, 18 Sep 2003 17:51:41 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN99y4Q6gcRywIeQUKJR+MxOw1kvQADBJbA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: , "Marco Molteni (mmolteni)" X-OriginalArrivalTime: 18 Sep 2003 16:52:19.0291 (UTC) FILETIME=[39028AB0:01C37E05] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > > 2) TIO has a hash of the nested CareOf. This is used to discover a > > branch level mobility somewhere between the MR and the AR. It seems to > > me that this information alone would be enough if we wanted to > > proactively sign the RRH. But then this delays the movement tracking, > > since we need to wait for the MR to learn about the movement. This is > > why we did not do it. Again, we need a threat analysis that would > > uncover a threat against the current draft. > > > Good insight. If I knew in advance your intention about this, it would > help me. > At first while I was reading your draft, I wondered why TIO is only > limited used.:) There's MUCHO more to it. Eg AR selection, loop avoidance :) > About movement tracking delay, I agree it need more delay than RRH based > per-packet. But, I think some delay is tolerable for the security > because nested relationship is unlikely changed too frequently. >=20 If you prove me that you bring any additional security where there was a threat, right?=20 > > 3) Note that the RH type 2 in RRH can only go down the tree, why > > protects against a rogue within the tree from bombing outside the > tree. > > The rogue will get the traffic back anyway. IPSec is recommended to > > protect the packets. Seems that the worst that can happen is blacking > > (or graying) out. Which could be done easily at the radio level or by > > discarding the packets. > > > If TLMR is a faked one, it's possible. Is'nt? And an intermediate > MR(which is controlled by the local attacker) can make the packets to > redirect to some information processing node in the same local link. >=20 Same with your draft, or did I miss something? But then again, it's easy to prevent this by having plain ingress filtering rules at the AR and optionally by placing a TLMR there. > > 4) For an attacker in the infrastructure (between AR and HA), the > threat > > may be different since it could bomb any place at will. But a router > > placed like this could do a lot more than changing RRH. It could forge > > topology correct packets (source and dest) and generate the attck > > itself. We expect that these (core) routers are secure. > > > In our draft, one MR can be AR to MR which is in one level down. In > here, AR means one of nested MRs, not true fixed access router in the > infrastructure. We should suspect the nested MR is correct for above > threats I mentioned. In contrary, RRH is fully depend on the trust > relationship among nested MRs. How to get that MR-MR relationship of > trustworthy if MRs do not have the same administrative domain? This > maybe out of scope of our disccusion. For this, at least we need to > protect the integrity of the routing path between TLMR and MR to which > MR designates. >=20 You do not know that path for sure so how would you protect it?=20 The info you get in TIO may be all faked as well. I do not understand your point of RRH being dependent on the MR-MR trust. Can you please detail? In my mind there's no such a thing. =20 > > 5) If a path is not working, the MR should try another one. Our view > is > > that MR should overtime build several CareOf via several ARs, and > select > > the best path based on metrics such as bandwidth. What's the > difference > > between a bad guy blacking you out and a good one with no upstream > > bandwidth? > > >=20 > The selection problem of best path is another point we should consider. > I think MR can choice the best path by its own policy or simply > information which can be provided by the upper-level MRs/ARs. > Particularly it is more valuable feature under the multi-homed nested > environment. >=20 Fully agreed. And TIO is a powerful tool for that selection, as you realized for sure. Add a few dynamic metrics to evaluate, say, the bandwidth of alternate path, and there you go. Pascal From nemo-admin@ietf.org Fri Sep 19 13:10:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15139 for ; Fri, 19 Sep 2003 13:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Olk-0002HF-Sb; Fri, 19 Sep 2003 13:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkt-000140-Dw for nemo@optimus.ietf.org; Fri, 19 Sep 2003 12:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05940 for ; Fri, 19 Sep 2003 12:04:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0FDN-0000qy-00 for nemo@ietf.org; Fri, 19 Sep 2003 02:58:01 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1A0EzA-0006bn-00 for nemo@ietf.org; Fri, 19 Sep 2003 02:43:20 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h8J6du92025764; Fri, 19 Sep 2003 15:39:56 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , , , , , Cc: Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Fri, 19 Sep 2003 15:43:06 +0900 Message-ID: <015301c37e79$483e4950$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pascal, > > > issue you address exactly? > > > > > Basically I mean the spoofing attack for RRH in which some > intermediate > > MR(faked or one victim of attacker) can easily insert arbitrary > address > > in arbitrary slot. In other words, that can cause the redirection of > the > > forward routing path under no detection in both HA and MR during some > > period time. The packet redirection by the spoofing attack means that > > the attacker can give us the following threats. > > > > Well, there's the RH type 2 forwarding rules that make the attacker get > The packets back to him, if the attacker is in the nested structure, > as we explain in the draft. I expect that in general the TLMR will be > actually the AR, in order to prevent faking the Source of the packet as > seen > by the HA. > I do not think that TLMR will be the AR. If not, we assume that all of AR in the infrastructure should include the functionality of processing RRH. It's not realistic. I am sure that RRH is valid only in the context of mobile network. > I believe that the result is the same exactly if the TIO extension you > propose > is faked. And I agree with your conclusion that the attacks that this > opens to > could be done in an easier fashion by other means. Same exactly for RRH > :) > The result is not the same. In our extended scheme, the nested path information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not mutable, so that information can be protected by AH using SA established between HA and MR. If the path information is forged, it will be promptly detected by HA. The HA will discard the forged path information by checking AH integrity and will never send the packets using RH2 which contains that forged path. In case of the original RRH, the slot information is mutable that means AH cannot be applied. So HA cannot detect whether that slot information is valid or not. > > 1) Information Disclosed - if the packets forwarded by HA are > redirected > > to the node(which is a repository for capturing some information for > the > > attacker) on Internet, that information will be used to do the second > or > > third attack. I think that it will be still helpful to the owner even > if > > it is encrypted because it can be an input to the traffic analysis or > to > > decrypt the cipertext. > > Again, RH2 will not let the packet leave the nested structure once it is > in. > If you want, the nested structure is seen globally as a black bow. Once > the > packet is in, it will never get out. Always down the tree. I understand RH2's routing property you are now mentioning. However, to my knowledge, there will be still a threat that redirects the RH2 routed traffic to the outside of tree if TLMR can forge the slot information in RRH. > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) can be > > redirected to some targeted server(as a victim) on Internet, it > becomes > > one of holes for DOS attack. > > > > Above two cases are just all of my instant thinking but I expect > another > > cases apparently exist in the real world. We should try to find more > > threats. Are above mentioned threats reasonable or not? It needs more > > discussion. > > If the access router is not TLMR and if it does not check tke > topological > Coreectedness of the source, it may happen that an attacker forges the > Source of the packet. But then you do not need all the MIP thing to do > that. > Actually the attacker in the nested RO context does not forge the source address of the packet. The attack point is in the RRH information that will be used to do RH2 by HA. > 1) I expect AR to check the source address (per standard) So do I. > 2) I expect AR to actually be the TLMR and the source of the packets as > seen by HA Why do you think TLMR will be AR(in the infrastructure)? I think TLMR is just one of MRs that aware/understand the network mobility. > 3) I expect that the infrastructure is safe (if it is not, again, there > are other > simpler attacks for a rogue on axis > I agree. Let's assume the infrastructure is safe in this discussion. The threats I said are not depend on the assumption that the infrastructure is unsafe. /Jongkeun. > So the threat you mention is covered.... for both drafts. Again, I do > not see what the > RH6 adds there since the info you have may be faked for all you know... > > What do you think? > > Pascal From nemo-admin@ietf.org Fri Sep 19 13:53:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17065 for ; Fri, 19 Sep 2003 13:53:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkr-00012V-OB; Fri, 19 Sep 2003 12:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NkA-0000mi-Mz for nemo@optimus.ietf.org; Fri, 19 Sep 2003 12:04:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05310 for ; Fri, 19 Sep 2003 12:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0HQa-0001AL-00 for nemo@ietf.org; Fri, 19 Sep 2003 05:19:48 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A0HB5-0006NJ-00 for nemo@ietf.org; Fri, 19 Sep 2003 05:03:47 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 19 Sep 2003 11:01:57 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8J93CpL005627; Fri, 19 Sep 2003 11:03:13 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 19 Sep 2003 10:03:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Fri, 19 Sep 2003 10:02:03 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN+eVQ5GVLiF8P+Ro2/hQZy+i+dOwADmXwQ From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: X-OriginalArrivalTime: 19 Sep 2003 09:03:11.0397 (UTC) FILETIME=[D9F88550:01C37E8C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi: I'd like to focus on the attacks you have in mind and make a scenario.=20 For instance attacker is TLMR, forges source or RRH, and then what happens. >=20 > The result is not the same. In our extended scheme, the nested path > information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not > mutable, so that information can be protected by AH using SA established > between HA and MR. If the path information is forged, it will be > promptly detected by HA. The HA will discard the forged path information > by checking AH integrity and will never send the packets using RH2 which > contains that forged path. In case of the original RRH, the slot > information is mutable that means AH cannot be applied. So HA cannot > detect whether that slot information is valid or not. I understand that the RH6 as you describe is non mutable.=20 Note that in my mind, it should not work exactly as you describe but rather the reverse way of RH0 and RH2, with a swapping of the source. =20 <--------------- outer IPv6 header --------------->=20 +-------+-------++ -- ++----+---+--------+---------++--------=20 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || iPACKET=20 | | |: :| 6 | | | ||=20 +-------+-------++ -- ++----+---+--------+---------++--------=20 =20 <--------------- outer IPv6 header --------------->=20 +-------+-------++ -- ++----+---+--------+---------++--------=20 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET=20 | | |: :| 6 | | | ||=20 +-------+-------++ -- ++----+---+--------+---------++-------- Now it's mutable but predictable. I believe it's cleaner and that may=20 Make the HA MIP extension simpler. Now, my point is that the Nested Path Information may be forged all the same. So you sign something that you believe but can not verify? Or can you?=20 I'm still missing the threat against RRH. If we find one, we'll see whether It does or does not translate equivalently in a threat against NPI. My current understanding is the added security is but an illusion, at a cost... > I understand RH2's routing property you are now mentioning. However, to > my knowledge, there will be still a threat that redirects the RH2 routed > traffic to the outside of tree if TLMR can forge the slot information in > RRH. >=20 Well, the TLMR will get the response traffic back to it. So what's the point? > > > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) can > be > > > redirected to some targeted server(as a victim) on Internet, it > > becomes > > > one of holes for DOS attack. > > > > > > Above two cases are just all of my instant thinking but I expect > > another > > > cases apparently exist in the real world. We should try to find more > > > threats. Are above mentioned threats reasonable or not? It needs > more > > > discussion. > > > > If the access router is not TLMR and if it does not check tke > > topological > > Coreectedness of the source, it may happen that an attacker forges the > > Source of the packet. But then you do not need all the MIP thing to do > > that. > > >=20 > Actually the attacker in the nested RO context does not forge the source > address of the packet. The attack point is in the RRH information that > will be used to do RH2 by HA. As above. The HA sends the packet to whom he sees as the source of the packet, with a RH2 that's the reversed RH (4 or 6). So the response packet is directed to the TLMR CoA, which topological correctness was checked by the AR. It's bombing itself... or at least someone on its link. A bit of a complex method for a simple result. >=20 > > 1) I expect AR to check the source address (per standard) > So do I. > > 2) I expect AR to actually be the TLMR and the source of the packets > as > > seen by HA >=20 > Why do you think TLMR will be AR(in the infrastructure)? I think TLMR is > just one of MRs that aware/understand the network mobility. >=20 It's a deployment issue. There's added value for doing it. Security is one. Value added services such as HMIP, HA, DHCP-PD can be indicated in TIO. Not the core of the discussion anyway. > > 3) I expect that the infrastructure is safe (if it is not, again, > there > > are other > > simpler attacks for a rogue on axis > > > I agree. Let's assume the infrastructure is safe in this discussion. > The threats I said are not depend on the assumption that the > infrastructure is unsafe. >=20 Agreed.=20 > /Jongkeun. >=20 > > So the threat you mention is covered.... for both drafts. Again, I do > > not see what the > > RH6 adds there since the info you have may be faked for all you > know... > > >=20 > > What do you think? > > > > Pascal From exim@www1.ietf.org Fri Sep 19 22:37:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04728 for ; Fri, 19 Sep 2003 22:37:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhGF020140 for ; Fri, 19 Sep 2003 21:37:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82Dc1wi007608 for nemo-archive@odin.ietf.org; Tue, 2 Sep 2003 09:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBM8-0001yZ-HX for nemo-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:38:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23947 for ; Tue, 2 Sep 2003 09:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBM6-0007bo-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:37:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBM5-0007bf-00 for nemo-web-archive@ietf.org; Tue, 02 Sep 2003 09:37:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uAKG-0000I9-L3; Tue, 02 Sep 2003 08:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u7wj-0005Dm-2p for nemo@optimus.ietf.org; Tue, 02 Sep 2003 05:59:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05803 for ; Tue, 2 Sep 2003 05:59:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u7we-0007NE-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:59:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 19u7wd-0007Js-00 for nemo@ietf.org; Tue, 02 Sep 2003 05:59:27 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 02 Sep 2003 11:58:00 +0200 Received: from xbe-lon-302.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h829uaEo026916; Tue, 2 Sep 2003 11:56:37 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Sep 2003 10:58:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) Date: Tue, 2 Sep 2003 10:58:55 +0100 Message-ID: Thread-Topic: Source Address Selection (was Re: [nemo] crossover tunnel....) Thread-Index: AcNxMqT0iASqZD0bTMGsEvAfbAq8DAABGPCA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , "Vijay Devarapalli" Cc: X-OriginalArrivalTime: 02 Sep 2003 09:58:56.0020 (UTC) FILETIME=[D27FBD40:01C37138] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: mardi 2 septembre 2003 11:14 > To: Pascal Thubert (pthubert); 'Vijay Devarapalli' > Cc: nemo@ietf.org > Subject: RE: Source Address Selection (was Re: [nemo] crossover tunnel....) >=20 > Thanks for your explanation. > > > > The remote end may be on the visited link or some hops away. The key > is whether > > the route to the remote end is via the MRHA or not. If the route is > via MRHA, then > > the home address should be used as the global address on that link, > that's all I'm > > saying. > Yes, I agree. But, how can MR decide to choose it's CoA of visited link > to send some packets to a node on some hops away? If MR can be > configured by static routes, it's possible. However, I don't think that > is a thing we really want to find. There is something we should think > about. There is some benefit if MR can use it's CoA for the outgoing > connection that has the destination node on global internet, not just > some hops away. That is because most of applications of Mobile Network > will be client type except sort of emerging services like VoIP that is > required to accept an incoming connection. Is there any problem in using > it's CoA for outgoing connections? Any difference in doing for nodes on > some hops away? >=20 I meant hops away but known by a local routing protocol (eg MANET). In that case, a routing protocol has injected a best match than whatever goes via MRHA (usually ::/0). Note that a MR could be configured with a route via MRHA that's not ::/0 (for instance just your company's prefix), in which case ::/0 would be via the access router using the CareOf. If you mean that packet sourced by MR over MRHA may use CareOf as source, yes, it's possible but it violates SAS. It may be interesting for some application in a Mobile Host, but I do not perceive any point for MRs. I believe that the SAS I described in a generic MN thing, not just a MR thing. This is what I said at last IETF. > > > > The MR has a connected route to the prefix of the CareOf. In your case > 2 (LFN to > > end node in the visited network) the packets will not be routed via > MRHA because > > there is a better prefix match. Consequence the packets from the LFN > will reach > > the destination. But the end node will not have a route to the LFN so > the return > > connectivity will be broken if there's no MRHA tunnel. > > > > We still have to find a solution for that. Maybe some proxy by the MR, > or some > > advertisement of its MNP on the visited link? >=20 > Yes, I agree. There are some points we need to come up with for route > optimization. >=20 It's a very open question with many options. MR RA's and proxies MNP on the visited link, MR RA's visited link in MNet and proxies the visited prefix, etc... We need to think whether we want just one level of bridging or if we can cover a mobile tree. And to which extend this goes before global RO (MR-CN tunnel) takes over. I do not think it's a priority for the WG at the moment, though. Pascal From exim@www1.ietf.org Sat Sep 20 09:53:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04250 for ; Sat, 20 Sep 2003 09:53:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PWS-00076u-OH for nemo-archive@odin.ietf.org; Fri, 19 Sep 2003 13:58:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHwO83027330 for nemo-archive@odin.ietf.org; Fri, 19 Sep 2003 13:58:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0PWS-00076Y-Cp for nemo-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 13:58:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17282 for ; Fri, 19 Sep 2003 13:58:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0PWO-00075c-00 for nemo-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0PWG-000747-01 for nemo-web-archive@ietf.org; Fri, 19 Sep 2003 13:58:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkr-00012V-OB; Fri, 19 Sep 2003 12:05:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NkA-0000mi-Mz for nemo@optimus.ietf.org; Fri, 19 Sep 2003 12:04:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05310 for ; Fri, 19 Sep 2003 12:04:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0HQa-0001AL-00 for nemo@ietf.org; Fri, 19 Sep 2003 05:19:48 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A0HB5-0006NJ-00 for nemo@ietf.org; Fri, 19 Sep 2003 05:03:47 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 19 Sep 2003 11:01:57 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8J93CpL005627; Fri, 19 Sep 2003 11:03:13 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 19 Sep 2003 10:03:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Fri, 19 Sep 2003 10:02:03 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcN+eVQ5GVLiF8P+Ro2/hQZy+i+dOwADmXwQ From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: X-OriginalArrivalTime: 19 Sep 2003 09:03:11.0397 (UTC) FILETIME=[D9F88550:01C37E8C] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi: I'd like to focus on the attacks you have in mind and make a scenario.=20 For instance attacker is TLMR, forges source or RRH, and then what happens. >=20 > The result is not the same. In our extended scheme, the nested path > information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not > mutable, so that information can be protected by AH using SA established > between HA and MR. If the path information is forged, it will be > promptly detected by HA. The HA will discard the forged path information > by checking AH integrity and will never send the packets using RH2 which > contains that forged path. In case of the original RRH, the slot > information is mutable that means AH cannot be applied. So HA cannot > detect whether that slot information is valid or not. I understand that the RH6 as you describe is non mutable.=20 Note that in my mind, it should not work exactly as you describe but rather the reverse way of RH0 and RH2, with a swapping of the source. =20 <--------------- outer IPv6 header --------------->=20 +-------+-------++ -- ++----+---+--------+---------++--------=20 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || iPACKET=20 | | |: :| 6 | | | ||=20 +-------+-------++ -- ++----+---+--------+---------++--------=20 =20 <--------------- outer IPv6 header --------------->=20 +-------+-------++ -- ++----+---+--------+---------++--------=20 |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET=20 | | |: :| 6 | | | ||=20 +-------+-------++ -- ++----+---+--------+---------++-------- Now it's mutable but predictable. I believe it's cleaner and that may=20 Make the HA MIP extension simpler. Now, my point is that the Nested Path Information may be forged all the same. So you sign something that you believe but can not verify? Or can you?=20 I'm still missing the threat against RRH. If we find one, we'll see whether It does or does not translate equivalently in a threat against NPI. My current understanding is the added security is but an illusion, at a cost... > I understand RH2's routing property you are now mentioning. However, to > my knowledge, there will be still a threat that redirects the RH2 routed > traffic to the outside of tree if TLMR can forge the slot information in > RRH. >=20 Well, the TLMR will get the response traffic back to it. So what's the point? > > > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) can > be > > > redirected to some targeted server(as a victim) on Internet, it > > becomes > > > one of holes for DOS attack. > > > > > > Above two cases are just all of my instant thinking but I expect > > another > > > cases apparently exist in the real world. We should try to find more > > > threats. Are above mentioned threats reasonable or not? It needs > more > > > discussion. > > > > If the access router is not TLMR and if it does not check tke > > topological > > Coreectedness of the source, it may happen that an attacker forges the > > Source of the packet. But then you do not need all the MIP thing to do > > that. > > >=20 > Actually the attacker in the nested RO context does not forge the source > address of the packet. The attack point is in the RRH information that > will be used to do RH2 by HA. As above. The HA sends the packet to whom he sees as the source of the packet, with a RH2 that's the reversed RH (4 or 6). So the response packet is directed to the TLMR CoA, which topological correctness was checked by the AR. It's bombing itself... or at least someone on its link. A bit of a complex method for a simple result. >=20 > > 1) I expect AR to check the source address (per standard) > So do I. > > 2) I expect AR to actually be the TLMR and the source of the packets > as > > seen by HA >=20 > Why do you think TLMR will be AR(in the infrastructure)? I think TLMR is > just one of MRs that aware/understand the network mobility. >=20 It's a deployment issue. There's added value for doing it. Security is one. Value added services such as HMIP, HA, DHCP-PD can be indicated in TIO. Not the core of the discussion anyway. > > 3) I expect that the infrastructure is safe (if it is not, again, > there > > are other > > simpler attacks for a rogue on axis > > > I agree. Let's assume the infrastructure is safe in this discussion. > The threats I said are not depend on the assumption that the > infrastructure is unsafe. >=20 Agreed.=20 > /Jongkeun. >=20 > > So the threat you mention is covered.... for both drafts. Again, I do > > not see what the > > RH6 adds there since the info you have may be faked for all you > know... > > >=20 > > What do you think? > > > > Pascal From exim@www1.ietf.org Sat Sep 20 09:53:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04358 for ; Sat, 20 Sep 2003 09:53:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OmB-0002TM-JZ for nemo-archive@odin.ietf.org; Fri, 19 Sep 2003 13:10:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHAZMw009500 for nemo-archive@odin.ietf.org; Fri, 19 Sep 2003 13:10:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Om1-0002QK-4u for nemo-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 13:10:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15100 for ; Fri, 19 Sep 2003 13:10:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Olz-0006SL-00 for nemo-web-archive@ietf.org; Fri, 19 Sep 2003 13:10:23 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0Olt-0006Rc-00 for nemo-web-archive@ietf.org; Fri, 19 Sep 2003 13:10:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Olk-0002HF-Sb; Fri, 19 Sep 2003 13:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkt-000140-Dw for nemo@optimus.ietf.org; Fri, 19 Sep 2003 12:05:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05940 for ; Fri, 19 Sep 2003 12:04:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0FDN-0000qy-00 for nemo@ietf.org; Fri, 19 Sep 2003 02:58:01 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1A0EzA-0006bn-00 for nemo@ietf.org; Fri, 19 Sep 2003 02:43:20 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h8J6du92025764; Fri, 19 Sep 2003 15:39:56 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , , , , , Cc: Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Fri, 19 Sep 2003 15:43:06 +0900 Message-ID: <015301c37e79$483e4950$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pascal, > > > issue you address exactly? > > > > > Basically I mean the spoofing attack for RRH in which some > intermediate > > MR(faked or one victim of attacker) can easily insert arbitrary > address > > in arbitrary slot. In other words, that can cause the redirection of > the > > forward routing path under no detection in both HA and MR during some > > period time. The packet redirection by the spoofing attack means that > > the attacker can give us the following threats. > > > > Well, there's the RH type 2 forwarding rules that make the attacker get > The packets back to him, if the attacker is in the nested structure, > as we explain in the draft. I expect that in general the TLMR will be > actually the AR, in order to prevent faking the Source of the packet as > seen > by the HA. > I do not think that TLMR will be the AR. If not, we assume that all of AR in the infrastructure should include the functionality of processing RRH. It's not realistic. I am sure that RRH is valid only in the context of mobile network. > I believe that the result is the same exactly if the TIO extension you > propose > is faked. And I agree with your conclusion that the attacks that this > opens to > could be done in an easier fashion by other means. Same exactly for RRH > :) > The result is not the same. In our extended scheme, the nested path information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not mutable, so that information can be protected by AH using SA established between HA and MR. If the path information is forged, it will be promptly detected by HA. The HA will discard the forged path information by checking AH integrity and will never send the packets using RH2 which contains that forged path. In case of the original RRH, the slot information is mutable that means AH cannot be applied. So HA cannot detect whether that slot information is valid or not. > > 1) Information Disclosed - if the packets forwarded by HA are > redirected > > to the node(which is a repository for capturing some information for > the > > attacker) on Internet, that information will be used to do the second > or > > third attack. I think that it will be still helpful to the owner even > if > > it is encrypted because it can be an input to the traffic analysis or > to > > decrypt the cipertext. > > Again, RH2 will not let the packet leave the nested structure once it is > in. > If you want, the nested structure is seen globally as a black bow. Once > the > packet is in, it will never get out. Always down the tree. I understand RH2's routing property you are now mentioning. However, to my knowledge, there will be still a threat that redirects the RH2 routed traffic to the outside of tree if TLMR can forge the slot information in RRH. > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) can be > > redirected to some targeted server(as a victim) on Internet, it > becomes > > one of holes for DOS attack. > > > > Above two cases are just all of my instant thinking but I expect > another > > cases apparently exist in the real world. We should try to find more > > threats. Are above mentioned threats reasonable or not? It needs more > > discussion. > > If the access router is not TLMR and if it does not check tke > topological > Coreectedness of the source, it may happen that an attacker forges the > Source of the packet. But then you do not need all the MIP thing to do > that. > Actually the attacker in the nested RO context does not forge the source address of the packet. The attack point is in the RRH information that will be used to do RH2 by HA. > 1) I expect AR to check the source address (per standard) So do I. > 2) I expect AR to actually be the TLMR and the source of the packets as > seen by HA Why do you think TLMR will be AR(in the infrastructure)? I think TLMR is just one of MRs that aware/understand the network mobility. > 3) I expect that the infrastructure is safe (if it is not, again, there > are other > simpler attacks for a rogue on axis > I agree. Let's assume the infrastructure is safe in this discussion. The threats I said are not depend on the assumption that the infrastructure is unsafe. /Jongkeun. > So the threat you mention is covered.... for both drafts. Again, I do > not see what the > RH6 adds there since the info you have may be faked for all you know... > > What do you think? > > Pascal From nemo-admin@ietf.org Sun Sep 21 10:19:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28347 for ; Sun, 21 Sep 2003 10:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A153F-0001bv-34; Sun, 21 Sep 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A152H-0001YW-S8 for nemo@optimus.ietf.org; Sun, 21 Sep 2003 10:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28274 for ; Sun, 21 Sep 2003 10:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A152A-00039h-00 for nemo@ietf.org; Sun, 21 Sep 2003 10:17:54 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1A151t-00039W-00 for nemo@ietf.org; Sun, 21 Sep 2003 10:17:38 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h8LEDk92005864; Sun, 21 Sep 2003 23:13:46 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , , , , , Cc: Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Sun, 21 Sep 2003 23:16:51 +0900 Message-ID: <019f01c3804b$00d334d0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Pascal, > I'd like to focus on the attacks you have in mind and make a scenario. > For instance attacker is TLMR, forges source or RRH, and then what > happens. Understood. It will not happen to send RH2 packet out to the outside of tree if the followings are guaranteed. - The AR's ingress filtering - The RH2 and IPv6 Hierarchical Address semantics In that case, I also do not see any difference in RRH whether it is RH4 or RH6. Right, I'm sure that we agreed with this point. IMHO, you need to revise your draft that saying " It is still an issue how to validate that the source of the outer packet is the actual TLMR as opposed to a forged IP address put by an on-axis attacker outside the Mobile Network." In section 11.2. because that statement had suggested to me to have the elements of threat like as we discussed. However, I have still a doubt in the possibility of packet redirection through RRH attacking in the tree. For instance, 1) A faked MR on the path of Tree makes the RH2 to be redirected to a node as a sink one by forging the RRH's slot information. 2) HA should not detect so sends the packets with RH2 as the intention of an attacker. In that situation, if HA can detect the unauthorized changes in RRH using AH integrity protection like our approach, HA will never respond. Well, those kinds of threat do not severely effect on an important network node but can bring some adverse result on the tree network itself such as the exhaustion of network bandwidth. What do you think for those kinds of attack? By virus code, MR may be one in WPAN. Regardless of its importance, I'm just saying the possibility that can cause the adverse effect by having no RRH integrity protection. This may still an illusion to you. But, I think that the security consideration on any protocols/mechanism is very critical, so some level of over-thinking is necessary. Through the discussion, I've realized some flaws in our draft. Your comments were very valuable so I'd like to sincerely thank you at this time. And also I believe that RRH idea is getting more resistible for the potential security threats through our discussion. Best Regards, /Jongkeun > > > > The result is not the same. In our extended scheme, the nested path > > information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not > > mutable, so that information can be protected by AH using SA > established > > between HA and MR. If the path information is forged, it will be > > promptly detected by HA. The HA will discard the forged path > information > > by checking AH integrity and will never send the packets using RH2 > which > > contains that forged path. In case of the original RRH, the slot > > information is mutable that means AH cannot be applied. So HA cannot > > detect whether that slot information is valid or not. > > > I understand that the RH6 as you describe is non mutable. > > Note that in my mind, it should not work exactly as you describe but > rather the reverse way of RH0 and RH2, with a swapping of the source. > > <--------------- outer IPv6 header ---------------> > +-------+-------++ -- ++----+---+--------+---------++-------- > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || iPACKET > | | |: :| 6 | | | || > +-------+-------++ -- ++----+---+--------+---------++-------- > > <--------------- outer IPv6 header ---------------> > +-------+-------++ -- ++----+---+--------+---------++-------- > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET > | | |: :| 6 | | | || > +-------+-------++ -- ++----+---+--------+---------++-------- > > > Now it's mutable but predictable. I believe it's cleaner and that may > Make the HA MIP extension simpler. > > Now, my point is that the Nested Path Information may be forged all the > same. > So you sign something that you believe but can not verify? Or can you? > > I'm still missing the threat against RRH. If we find one, we'll see > whether > It does or does not translate equivalently in a threat against NPI. > > My current understanding is the added security is but an illusion, at a > cost... > > > I understand RH2's routing property you are now mentioning. However, > to > > my knowledge, there will be still a threat that redirects the RH2 > routed > > traffic to the outside of tree if TLMR can forge the slot information > in > > RRH. > > > > Well, the TLMR will get the response traffic back to it. So what's the > point? > > > > > > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) > can > > be > > > > redirected to some targeted server(as a victim) on Internet, it > > > becomes > > > > one of holes for DOS attack. > > > > > > > > Above two cases are just all of my instant thinking but I expect > > > another > > > > cases apparently exist in the real world. We should try to find > more > > > > threats. Are above mentioned threats reasonable or not? It needs > > more > > > > discussion. > > > > > > If the access router is not TLMR and if it does not check tke > > > topological > > > Coreectedness of the source, it may happen that an attacker forges > the > > > Source of the packet. But then you do not need all the MIP thing to > do > > > that. > > > > > > > Actually the attacker in the nested RO context does not forge the > source > > address of the packet. The attack point is in the RRH information that > > will be used to do RH2 by HA. > > As above. The HA sends the packet to whom he sees as the source of the > packet, with a RH2 that's the reversed RH (4 or 6). So the response > packet is directed to the TLMR CoA, which topological correctness was > checked by the AR. It's bombing itself... or at least someone on its > link. A bit of a complex method for a simple result. > > > > > > 1) I expect AR to check the source address (per standard) > > So do I. > > > 2) I expect AR to actually be the TLMR and the source of the packets > > as > > > seen by HA > > > > Why do you think TLMR will be AR(in the infrastructure)? I think TLMR > is > > just one of MRs that aware/understand the network mobility. > > > > It's a deployment issue. There's added value for doing it. Security is > one. Value added services such as HMIP, HA, DHCP-PD can be indicated in > TIO. Not the core of the discussion anyway. > > > > 3) I expect that the infrastructure is safe (if it is not, again, > > there > > > are other > > > simpler attacks for a rogue on axis > > > > > I agree. Let's assume the infrastructure is safe in this discussion. > > The threats I said are not depend on the assumption that the > > infrastructure is unsafe. > > > > Agreed. > > > /Jongkeun. > > > > > So the threat you mention is covered.... for both drafts. Again, I > do > > > not see what the > > > RH6 adds there since the info you have may be faked for all you > > know... > > > > > > > > What do you think? > > > > > > Pascal From exim@www1.ietf.org Sun Sep 21 10:19:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28373 for ; Sun, 21 Sep 2003 10:19:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A153Z-0001cv-A8 for nemo-archive@odin.ietf.org; Sun, 21 Sep 2003 10:19:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8LEJLQH006249 for nemo-archive@odin.ietf.org; Sun, 21 Sep 2003 10:19:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A153T-0001cg-TH for nemo-web-archive@optimus.ietf.org; Sun, 21 Sep 2003 10:19:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28337 for ; Sun, 21 Sep 2003 10:19:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A153R-0003B1-00 for nemo-web-archive@ietf.org; Sun, 21 Sep 2003 10:19:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A153M-0003As-00 for nemo-web-archive@ietf.org; Sun, 21 Sep 2003 10:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A153F-0001bv-34; Sun, 21 Sep 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A152H-0001YW-S8 for nemo@optimus.ietf.org; Sun, 21 Sep 2003 10:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28274 for ; Sun, 21 Sep 2003 10:17:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A152A-00039h-00 for nemo@ietf.org; Sun, 21 Sep 2003 10:17:54 -0400 Received: from popeye.snu.ac.kr ([147.46.240.214]) by ietf-mx with esmtp (Exim 4.12) id 1A151t-00039W-00 for nemo@ietf.org; Sun, 21 Sep 2003 10:17:38 -0400 Received: from JONGKN02 (chaesira.snu.ac.kr [147.46.240.219]) by popeye.snu.ac.kr (8.12.2/8.12.2) with ESMTP id h8LEDk92005864; Sun, 21 Sep 2003 23:13:46 +0900 From: "Jongkeun Na" To: "'Pascal Thubert \(pthubert\)'" , , , , , Cc: Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Sun, 21 Sep 2003 23:16:51 +0900 Message-ID: <019f01c3804b$00d334d0$dbf02e93@JONGKN02> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pascal, > I'd like to focus on the attacks you have in mind and make a scenario. > For instance attacker is TLMR, forges source or RRH, and then what > happens. Understood. It will not happen to send RH2 packet out to the outside of tree if the followings are guaranteed. - The AR's ingress filtering - The RH2 and IPv6 Hierarchical Address semantics In that case, I also do not see any difference in RRH whether it is RH4 or RH6. Right, I'm sure that we agreed with this point. IMHO, you need to revise your draft that saying " It is still an issue how to validate that the source of the outer packet is the actual TLMR as opposed to a forged IP address put by an on-axis attacker outside the Mobile Network." In section 11.2. because that statement had suggested to me to have the elements of threat like as we discussed. However, I have still a doubt in the possibility of packet redirection through RRH attacking in the tree. For instance, 1) A faked MR on the path of Tree makes the RH2 to be redirected to a node as a sink one by forging the RRH's slot information. 2) HA should not detect so sends the packets with RH2 as the intention of an attacker. In that situation, if HA can detect the unauthorized changes in RRH using AH integrity protection like our approach, HA will never respond. Well, those kinds of threat do not severely effect on an important network node but can bring some adverse result on the tree network itself such as the exhaustion of network bandwidth. What do you think for those kinds of attack? By virus code, MR may be one in WPAN. Regardless of its importance, I'm just saying the possibility that can cause the adverse effect by having no RRH integrity protection. This may still an illusion to you. But, I think that the security consideration on any protocols/mechanism is very critical, so some level of over-thinking is necessary. Through the discussion, I've realized some flaws in our draft. Your comments were very valuable so I'd like to sincerely thank you at this time. And also I believe that RRH idea is getting more resistible for the potential security threats through our discussion. Best Regards, /Jongkeun > > > > The result is not the same. In our extended scheme, the nested path > > information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not > > mutable, so that information can be protected by AH using SA > established > > between HA and MR. If the path information is forged, it will be > > promptly detected by HA. The HA will discard the forged path > information > > by checking AH integrity and will never send the packets using RH2 > which > > contains that forged path. In case of the original RRH, the slot > > information is mutable that means AH cannot be applied. So HA cannot > > detect whether that slot information is valid or not. > > > I understand that the RH6 as you describe is non mutable. > > Note that in my mind, it should not work exactly as you describe but > rather the reverse way of RH0 and RH2, with a swapping of the source. > > <--------------- outer IPv6 header ---------------> > +-------+-------++ -- ++----+---+--------+---------++-------- > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || iPACKET > | | |: :| 6 | | | || > +-------+-------++ -- ++----+---+--------+---------++-------- > > <--------------- outer IPv6 header ---------------> > +-------+-------++ -- ++----+---+--------+---------++-------- > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || iPACKET > | | |: :| 6 | | | || > +-------+-------++ -- ++----+---+--------+---------++-------- > > > Now it's mutable but predictable. I believe it's cleaner and that may > Make the HA MIP extension simpler. > > Now, my point is that the Nested Path Information may be forged all the > same. > So you sign something that you believe but can not verify? Or can you? > > I'm still missing the threat against RRH. If we find one, we'll see > whether > It does or does not translate equivalently in a threat against NPI. > > My current understanding is the added security is but an illusion, at a > cost... > > > I understand RH2's routing property you are now mentioning. However, > to > > my knowledge, there will be still a threat that redirects the RH2 > routed > > traffic to the outside of tree if TLMR can forge the slot information > in > > RRH. > > > > Well, the TLMR will get the response traffic back to it. So what's the > point? > > > > > > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) > can > > be > > > > redirected to some targeted server(as a victim) on Internet, it > > > becomes > > > > one of holes for DOS attack. > > > > > > > > Above two cases are just all of my instant thinking but I expect > > > another > > > > cases apparently exist in the real world. We should try to find > more > > > > threats. Are above mentioned threats reasonable or not? It needs > > more > > > > discussion. > > > > > > If the access router is not TLMR and if it does not check tke > > > topological > > > Coreectedness of the source, it may happen that an attacker forges > the > > > Source of the packet. But then you do not need all the MIP thing to > do > > > that. > > > > > > > Actually the attacker in the nested RO context does not forge the > source > > address of the packet. The attack point is in the RRH information that > > will be used to do RH2 by HA. > > As above. The HA sends the packet to whom he sees as the source of the > packet, with a RH2 that's the reversed RH (4 or 6). So the response > packet is directed to the TLMR CoA, which topological correctness was > checked by the AR. It's bombing itself... or at least someone on its > link. A bit of a complex method for a simple result. > > > > > > 1) I expect AR to check the source address (per standard) > > So do I. > > > 2) I expect AR to actually be the TLMR and the source of the packets > > as > > > seen by HA > > > > Why do you think TLMR will be AR(in the infrastructure)? I think TLMR > is > > just one of MRs that aware/understand the network mobility. > > > > It's a deployment issue. There's added value for doing it. Security is > one. Value added services such as HMIP, HA, DHCP-PD can be indicated in > TIO. Not the core of the discussion anyway. > > > > 3) I expect that the infrastructure is safe (if it is not, again, > > there > > > are other > > > simpler attacks for a rogue on axis > > > > > I agree. Let's assume the infrastructure is safe in this discussion. > > The threats I said are not depend on the assumption that the > > infrastructure is unsafe. > > > > Agreed. > > > /Jongkeun. > > > > > So the threat you mention is covered.... for both drafts. Again, I > do > > > not see what the > > > RH6 adds there since the info you have may be faked for all you > > know... > > > > > > > > What do you think? > > > > > > Pascal From nemo-admin@ietf.org Mon Sep 22 03:23:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04160 for ; Mon, 22 Sep 2003 03:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1L2C-0003TZ-FZ; Mon, 22 Sep 2003 03:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1L1V-0003SX-BX for nemo@optimus.ietf.org; Mon, 22 Sep 2003 03:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04125 for ; Mon, 22 Sep 2003 03:22:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1L1T-0003Y1-00 for nemo@ietf.org; Mon, 22 Sep 2003 03:22:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A1L1I-0003XO-00 for nemo@ietf.org; Mon, 22 Sep 2003 03:22:04 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2003 09:19:29 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8M7KlLO011921; Mon, 22 Sep 2003 09:20:48 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Sep 2003 08:20:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Mon, 22 Sep 2003 08:20:48 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcOASwskqyCQ5dLeTwm3JpnM8gzNNAAi+WZA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: X-OriginalArrivalTime: 22 Sep 2003 07:20:49.0215 (UTC) FILETIME=[0C2F2CF0:01C380DA] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: dimanche 21 septembre 2003 16:17 > To: Pascal Thubert (pthubert); shcho@popeye.snu.ac.kr; ckim@popeye.snu.ac.kr; > steve.lee@samsung.com; hyunjeong.kang@samsung.com; chkoo@samsung.com > Cc: nemo@ietf.org > Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt >=20 > Hi Pascal, >=20 > > I'd like to focus on the attacks you have in mind and make a scenario. > > For instance attacker is TLMR, forges source or RRH, and then what > > happens. >=20 > Understood. It will not happen to send RH2 packet out to the outside of > tree if the followings are guaranteed. > - The AR's ingress filtering > - The RH2 and IPv6 Hierarchical Address semantics > In that case, I also do not see any difference in RRH whether it is RH4 > or RH6. > Right, I'm sure that we agreed with this point. IMHO, you need to revise > your draft that saying " It is still an issue how to validate that the > source of the outer > packet is the actual TLMR as opposed to a forged IP address put by an > on-axis attacker outside the Mobile Network." In section 11.2. > because that statement had suggested to me to have the elements of > threat like as we discussed. Oups: yes I need to make that clearer. Also to make clear that such an on axis Attacker may have better ways to kill the traffic. =20 >=20 > However, I have still a doubt in the possibility of packet redirection > through RRH attacking in the tree. For instance, > 1) A faked MR on the path of Tree makes the RH2 to be redirected to a > node as a sink one by forging the RRH's slot information. Why not just drop the egress packets? Or scramble the radio? The results is=20 that the binding flow does not complete and the tunnel is not established. > 2) HA should not detect so sends the packets with RH2 as the intention > of an attacker. > In that situation, if HA can detect the unauthorized changes in RRH > using AH integrity protection like our approach, HA will never respond. > Well, those kinds of threat do not severely effect on an important > network node but can bring some adverse result on the tree network > itself such as the exhaustion of network bandwidth. I wonder what happens if the same attacker tricks the NPI. For instance, pokes an address that is not his careof? Isn't this leading to the same thing? Note that each MR on the path should do ingress filtering, for both solutions. In my mind the 2 are not so different, fundamentally. Say that NPI precomputes=20 the Path and that RRH discovers it on the way.=20 The main difference is the latency of discovery but I'm pretty confident that=20 both are safe enough for the purpose. There's no perfection in network security is there? >=20 > What do you think for those kinds of attack? By virus code, MR may be > one in WPAN. > Regardless of its importance, I'm just saying the possibility that can > cause the adverse effect by having no RRH integrity protection. This may > still an illusion to you. But, I think that the security consideration > on any protocols/mechanism is very critical, so some level of > over-thinking is necessary. >=20 Right, this is why I'm very opened to this form of discussion. RRH gives a false impression of unsafety, and this lead people in the past to complex=20 solutions to fix an unclear threat. On the other hand, NPI seems safer but=20 if it is truly an illusion, then it's a bit deceptive and dangerous, isn't it? > Through the discussion, I've realized some flaws in our draft. Your > comments were very valuable so I'd like to sincerely thank you at this > time. And also I believe that RRH idea is getting more resistible for > the potential security threats through our discussion. Thank you too. Your comments on RRH draft are very welcome also :)=20 >=20 > Best Regards, > /Jongkeun >=20 > > > > > > The result is not the same. In our extended scheme, the nested path > > > information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not > > > mutable, so that information can be protected by AH using SA > > established > > > between HA and MR. If the path information is forged, it will be > > > promptly detected by HA. The HA will discard the forged path > > information > > > by checking AH integrity and will never send the packets using RH2 > > which > > > contains that forged path. In case of the original RRH, the slot > > > information is mutable that means AH cannot be applied. So HA cannot > > > detect whether that slot information is valid or not. > > > > > > I understand that the RH6 as you describe is non mutable. > > > > Note that in my mind, it should not work exactly as you describe but > > rather the reverse way of RH0 and RH2, with a swapping of the source. > > > > <--------------- outer IPv6 header ---------------> > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > > > MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || > iPACKET > > | | |: :| 6 | | | || > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > > > <--------------- outer IPv6 header ---------------> > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > > > MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || > iPACKET > > | | |: :| 6 | | | || > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > > > > > Now it's mutable but predictable. I believe it's cleaner and that may > > Make the HA MIP extension simpler. > > > > Now, my point is that the Nested Path Information may be forged all > the > > same. > > So you sign something that you believe but can not verify? Or can you? > > > > I'm still missing the threat against RRH. If we find one, we'll see > > whether > > It does or does not translate equivalently in a threat against NPI. > > > > My current understanding is the added security is but an illusion, at > a > > cost... > > > > > I understand RH2's routing property you are now mentioning. However, > > to > > > my knowledge, there will be still a threat that redirects the RH2 > > routed > > > traffic to the outside of tree if TLMR can forge the slot > information > > in > > > RRH. > > > > > > > Well, the TLMR will get the response traffic back to it. So what's the > > point? > > > > > > > > > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) > > can > > > be > > > > > redirected to some targeted server(as a victim) on Internet, it > > > > becomes > > > > > one of holes for DOS attack. > > > > > > > > > > Above two cases are just all of my instant thinking but I expect > > > > another > > > > > cases apparently exist in the real world. We should try to find > > more > > > > > threats. Are above mentioned threats reasonable or not? It needs > > > more > > > > > discussion. > > > > > > > > If the access router is not TLMR and if it does not check tke > > > > topological > > > > Coreectedness of the source, it may happen that an attacker forges > > the > > > > Source of the packet. But then you do not need all the MIP thing > to > > do > > > > that. > > > > > > > > > > Actually the attacker in the nested RO context does not forge the > > source > > > address of the packet. The attack point is in the RRH information > that > > > will be used to do RH2 by HA. > > > > As above. The HA sends the packet to whom he sees as the source of the > > packet, with a RH2 that's the reversed RH (4 or 6). So the response > > packet is directed to the TLMR CoA, which topological correctness was > > checked by the AR. It's bombing itself... or at least someone on its > > link. A bit of a complex method for a simple result. > > > > > > > > > 1) I expect AR to check the source address (per standard) > > > So do I. > > > > 2) I expect AR to actually be the TLMR and the source of the > packets > > > as > > > > seen by HA > > > > > > Why do you think TLMR will be AR(in the infrastructure)? I think > TLMR > > is > > > just one of MRs that aware/understand the network mobility. > > > > > > > It's a deployment issue. There's added value for doing it. Security is > > one. Value added services such as HMIP, HA, DHCP-PD can be indicated > in > > TIO. Not the core of the discussion anyway. > > > > > > 3) I expect that the infrastructure is safe (if it is not, again, > > > there > > > > are other > > > > simpler attacks for a rogue on axis > > > > > > > I agree. Let's assume the infrastructure is safe in this discussion. > > > The threats I said are not depend on the assumption that the > > > infrastructure is unsafe. > > > > > > > Agreed. > > > > > /Jongkeun. > > > > > > > So the threat you mention is covered.... for both drafts. Again, I > > do > > > > not see what the > > > > RH6 adds there since the info you have may be faked for all you > > > know... > > > > > > > > > > > What do you think? > > > > > > > > Pascal >=20 From exim@www1.ietf.org Mon Sep 22 03:23:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04181 for ; Mon, 22 Sep 2003 03:23:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1L2R-0003WA-Km for nemo-archive@odin.ietf.org; Mon, 22 Sep 2003 03:23:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8M7NF0k013522 for nemo-archive@odin.ietf.org; Mon, 22 Sep 2003 03:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1L2R-0003W1-Do for nemo-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 03:23:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04155 for ; Mon, 22 Sep 2003 03:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1L2K-0003ZB-00 for nemo-web-archive@ietf.org; Mon, 22 Sep 2003 03:23:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1L2F-0003Z8-00 for nemo-web-archive@ietf.org; Mon, 22 Sep 2003 03:23:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1L2C-0003TZ-FZ; Mon, 22 Sep 2003 03:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1L1V-0003SX-BX for nemo@optimus.ietf.org; Mon, 22 Sep 2003 03:22:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04125 for ; Mon, 22 Sep 2003 03:22:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1L1T-0003Y1-00 for nemo@ietf.org; Mon, 22 Sep 2003 03:22:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1A1L1I-0003XO-00 for nemo@ietf.org; Mon, 22 Sep 2003 03:22:04 -0400 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 22 Sep 2003 09:19:29 +0200 Received: from xbe-lon-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h8M7KlLO011921; Mon, 22 Sep 2003 09:20:48 +0200 (MET DST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 22 Sep 2003 08:20:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Date: Mon, 22 Sep 2003 08:20:48 +0100 Message-ID: Thread-Topic: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt Thread-Index: AcOASwskqyCQ5dLeTwm3JpnM8gzNNAAi+WZA From: "Pascal Thubert (pthubert)" To: "Jongkeun Na" , , , , , Cc: X-OriginalArrivalTime: 22 Sep 2003 07:20:49.0215 (UTC) FILETIME=[0C2F2CF0:01C380DA] Content-Transfer-Encoding: quoted-printable Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Jongkeun Na [mailto:jkna@popeye.snu.ac.kr] > Sent: dimanche 21 septembre 2003 16:17 > To: Pascal Thubert (pthubert); shcho@popeye.snu.ac.kr; ckim@popeye.snu.ac.kr; > steve.lee@samsung.com; hyunjeong.kang@samsung.com; chkoo@samsung.com > Cc: nemo@ietf.org > Subject: RE: [nemo] I-D ACTION:draft-na-nemo-nested-path-info-00.txt >=20 > Hi Pascal, >=20 > > I'd like to focus on the attacks you have in mind and make a scenario. > > For instance attacker is TLMR, forges source or RRH, and then what > > happens. >=20 > Understood. It will not happen to send RH2 packet out to the outside of > tree if the followings are guaranteed. > - The AR's ingress filtering > - The RH2 and IPv6 Hierarchical Address semantics > In that case, I also do not see any difference in RRH whether it is RH4 > or RH6. > Right, I'm sure that we agreed with this point. IMHO, you need to revise > your draft that saying " It is still an issue how to validate that the > source of the outer > packet is the actual TLMR as opposed to a forged IP address put by an > on-axis attacker outside the Mobile Network." In section 11.2. > because that statement had suggested to me to have the elements of > threat like as we discussed. Oups: yes I need to make that clearer. Also to make clear that such an on axis Attacker may have better ways to kill the traffic. =20 >=20 > However, I have still a doubt in the possibility of packet redirection > through RRH attacking in the tree. For instance, > 1) A faked MR on the path of Tree makes the RH2 to be redirected to a > node as a sink one by forging the RRH's slot information. Why not just drop the egress packets? Or scramble the radio? The results is=20 that the binding flow does not complete and the tunnel is not established. > 2) HA should not detect so sends the packets with RH2 as the intention > of an attacker. > In that situation, if HA can detect the unauthorized changes in RRH > using AH integrity protection like our approach, HA will never respond. > Well, those kinds of threat do not severely effect on an important > network node but can bring some adverse result on the tree network > itself such as the exhaustion of network bandwidth. I wonder what happens if the same attacker tricks the NPI. For instance, pokes an address that is not his careof? Isn't this leading to the same thing? Note that each MR on the path should do ingress filtering, for both solutions. In my mind the 2 are not so different, fundamentally. Say that NPI precomputes=20 the Path and that RRH discovers it on the way.=20 The main difference is the latency of discovery but I'm pretty confident that=20 both are safe enough for the purpose. There's no perfection in network security is there? >=20 > What do you think for those kinds of attack? By virus code, MR may be > one in WPAN. > Regardless of its importance, I'm just saying the possibility that can > cause the adverse effect by having no RRH integrity protection. This may > still an illusion to you. But, I think that the security consideration > on any protocols/mechanism is very critical, so some level of > over-thinking is necessary. >=20 Right, this is why I'm very opened to this form of discussion. RRH gives a false impression of unsafety, and this lead people in the past to complex=20 solutions to fix an unclear threat. On the other hand, NPI seems safer but=20 if it is truly an illusion, then it's a bit deceptive and dangerous, isn't it? > Through the discussion, I've realized some flaws in our draft. Your > comments were very valuable so I'd like to sincerely thank you at this > time. And also I believe that RRH idea is getting more resistible for > the potential security threats through our discussion. Thank you too. Your comments on RRH draft are very welcome also :)=20 >=20 > Best Regards, > /Jongkeun >=20 > > > > > > The result is not the same. In our extended scheme, the nested path > > > information(eg. MR1_COA->MR2-_COA..) which carried in RH6 is not > > > mutable, so that information can be protected by AH using SA > > established > > > between HA and MR. If the path information is forged, it will be > > > promptly detected by HA. The HA will discard the forged path > > information > > > by checking AH integrity and will never send the packets using RH2 > > which > > > contains that forged path. In case of the original RRH, the slot > > > information is mutable that means AH cannot be applied. So HA cannot > > > detect whether that slot information is valid or not. > > > > > > I understand that the RH6 as you describe is non mutable. > > > > Note that in my mind, it should not work exactly as you describe but > > rather the reverse way of RH0 and RH2, with a swapping of the source. > > > > <--------------- outer IPv6 header ---------------> > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > > > MR2: |MR2_CoA| HA3 |:oEXT:|type| 1 |MR1-CoA | MR3-CoA || > iPACKET > > | | |: :| 6 | | | || > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > > > <--------------- outer IPv6 header ---------------> > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > |oSRC |oDST |: :|oRH |IDX|Addr[1] | Addr[2] || > > > > MR1: |MR1_CoA| HA3 |:oEXT:|type| 0 |MR2-CoA | MR3-CoA || > iPACKET > > | | |: :| 6 | | | || > > +-------+-------++ -- > ++----+---+--------+---------++-------- > > > > > > Now it's mutable but predictable. I believe it's cleaner and that may > > Make the HA MIP extension simpler. > > > > Now, my point is that the Nested Path Information may be forged all > the > > same. > > So you sign something that you believe but can not verify? Or can you? > > > > I'm still missing the threat against RRH. If we find one, we'll see > > whether > > It does or does not translate equivalently in a threat against NPI. > > > > My current understanding is the added security is but an illusion, at > a > > cost... > > > > > I understand RH2's routing property you are now mentioning. However, > > to > > > my knowledge, there will be still a threat that redirects the RH2 > > routed > > > traffic to the outside of tree if TLMR can forge the slot > information > > in > > > RRH. > > > > > > > Well, the TLMR will get the response traffic back to it. So what's the > > point? > > > > > > > > > > > 2) Active Denial of Service - if all packets sent from HA(/CNs) > > can > > > be > > > > > redirected to some targeted server(as a victim) on Internet, it > > > > becomes > > > > > one of holes for DOS attack. > > > > > > > > > > Above two cases are just all of my instant thinking but I expect > > > > another > > > > > cases apparently exist in the real world. We should try to find > > more > > > > > threats. Are above mentioned threats reasonable or not? It needs > > > more > > > > > discussion. > > > > > > > > If the access router is not TLMR and if it does not check tke > > > > topological > > > > Coreectedness of the source, it may happen that an attacker forges > > the > > > > Source of the packet. But then you do not need all the MIP thing > to > > do > > > > that. > > > > > > > > > > Actually the attacker in the nested RO context does not forge the > > source > > > address of the packet. The attack point is in the RRH information > that > > > will be used to do RH2 by HA. > > > > As above. The HA sends the packet to whom he sees as the source of the > > packet, with a RH2 that's the reversed RH (4 or 6). So the response > > packet is directed to the TLMR CoA, which topological correctness was > > checked by the AR. It's bombing itself... or at least someone on its > > link. A bit of a complex method for a simple result. > > > > > > > > > 1) I expect AR to check the source address (per standard) > > > So do I. > > > > 2) I expect AR to actually be the TLMR and the source of the > packets > > > as > > > > seen by HA > > > > > > Why do you think TLMR will be AR(in the infrastructure)? I think > TLMR > > is > > > just one of MRs that aware/understand the network mobility. > > > > > > > It's a deployment issue. There's added value for doing it. Security is > > one. Value added services such as HMIP, HA, DHCP-PD can be indicated > in > > TIO. Not the core of the discussion anyway. > > > > > > 3) I expect that the infrastructure is safe (if it is not, again, > > > there > > > > are other > > > > simpler attacks for a rogue on axis > > > > > > > I agree. Let's assume the infrastructure is safe in this discussion. > > > The threats I said are not depend on the assumption that the > > > infrastructure is unsafe. > > > > > > > Agreed. > > > > > /Jongkeun. > > > > > > > So the threat you mention is covered.... for both drafts. Again, I > > do > > > > not see what the > > > > RH6 adds there since the info you have may be faked for all you > > > know... > > > > > > > > > > > What do you think? > > > > > > > > Pascal >=20 From nemo-admin@ietf.org Thu Sep 25 14:40:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13121 for ; Thu, 25 Sep 2003 14:40:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2b22-0005IO-2Q; Thu, 25 Sep 2003 14:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2b1s-0005Hn-Sf for nemo@optimus.ietf.org; Thu, 25 Sep 2003 14:39:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13079 for ; Thu, 25 Sep 2003 14:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2b1q-0003l4-00 for nemo@ietf.org; Thu, 25 Sep 2003 14:39:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2b1p-0003kk-00 for nemo@ietf.org; Thu, 25 Sep 2003 14:39:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8PIdIb06624; Thu, 25 Sep 2003 11:39:18 -0700 X-mProtect: <200309251839> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLbhYuH; Thu, 25 Sep 2003 11:39:17 PDT Message-ID: <3F733656.CE35252C@iprg.nokia.com> Date: Thu, 25 Sep 2003 11:39:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: nemo-base-dt@nal.motlabs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 5 resolution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, Issue 5 was about the Extended Home Network concept. the resolution is to remove the section from the draft and write up a separate informational/BCP draft. this draft will contain some practical scenarios and issues when deploying Mobile Routers. it will also talk about how to deploy home links to support mobile routers. it is upto the WG and WG chairs to decide if this informational/BCP draft should be a WG document. the details are at http://people.nokia.net/vijayd/nemo/issues.html comments? Vijay  From exim@www1.ietf.org Thu Sep 25 14:40:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13158 for ; Thu, 25 Sep 2003 14:40:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2b2A-0005Jf-Ns for nemo-archive@odin.ietf.org; Thu, 25 Sep 2003 14:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PIe9jQ020426 for nemo-archive@odin.ietf.org; Thu, 25 Sep 2003 14:40:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2b28-0005JN-Mc for nemo-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 14:40:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13097 for ; Thu, 25 Sep 2003 14:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2b25-0003lR-00 for nemo-web-archive@ietf.org; Thu, 25 Sep 2003 14:40:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2b25-0003lL-00 for nemo-web-archive@ietf.org; Thu, 25 Sep 2003 14:40:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2b22-0005IO-2Q; Thu, 25 Sep 2003 14:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2b1s-0005Hn-Sf for nemo@optimus.ietf.org; Thu, 25 Sep 2003 14:39:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13079 for ; Thu, 25 Sep 2003 14:39:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2b1q-0003l4-00 for nemo@ietf.org; Thu, 25 Sep 2003 14:39:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2b1p-0003kk-00 for nemo@ietf.org; Thu, 25 Sep 2003 14:39:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8PIdIb06624; Thu, 25 Sep 2003 11:39:18 -0700 X-mProtect: <200309251839> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLbhYuH; Thu, 25 Sep 2003 11:39:17 PDT Message-ID: <3F733656.CE35252C@iprg.nokia.com> Date: Thu, 25 Sep 2003 11:39:18 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org CC: nemo-base-dt@nal.motlabs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Issue 5 resolution Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, Issue 5 was about the Extended Home Network concept. the resolution is to remove the section from the draft and write up a separate informational/BCP draft. this draft will contain some practical scenarios and issues when deploying Mobile Routers. it will also talk about how to deploy home links to support mobile routers. it is upto the WG and WG chairs to decide if this informational/BCP draft should be a WG document. the details are at http://people.nokia.net/vijayd/nemo/issues.html comments? Vijay  From nemo-admin@ietf.org Fri Sep 26 03:37:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24190 for ; Fri, 26 Sep 2003 03:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2n9x-0004Qq-Ud; Fri, 26 Sep 2003 03:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2n9A-0004PO-Ba for nemo@optimus.ietf.org; Fri, 26 Sep 2003 03:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24142 for ; Fri, 26 Sep 2003 03:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2n97-0004tT-00 for nemo@ietf.org; Fri, 26 Sep 2003 03:36:09 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A2n97-0004tQ-00 for nemo@ietf.org; Fri, 26 Sep 2003 03:36:09 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8Q7a831002105; Fri, 26 Sep 2003 09:36:09 +0200 (MEST) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id TN54A4XH; Fri, 26 Sep 2003 09:38:25 +0200 Message-ID: <3F73EC65.3030502@ericsson.com> Date: Fri, 26 Sep 2003 09:36:05 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org, nemo-base-dt@nal.motlabs.com Subject: Re: [nemo] Issue 5 resolution References: <3F733656.CE35252C@iprg.nokia.com> In-Reply-To: <3F733656.CE35252C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi all, > > Issue 5 was about the Extended Home Network concept. the > resolution is to remove the section from the draft and > write up a separate informational/BCP draft. this draft > will contain some practical scenarios and issues when > deploying Mobile Routers. it will also talk about how to > deploy home links to support mobile routers. it is upto > the WG and WG chairs to decide if this informational/BCP > draft should be a WG document. > > the details are at http://people.nokia.net/vijayd/nemo/issues.html > > comments? It is a very good idea to remove it from the draft. The section was very confusing. To quote your conclusion: "bottomline is we dont need separate terminology for something which has been assumed to the normal case (atleast by me)." /Mattias > > Vijay > >  > From exim@www1.ietf.org Fri Sep 26 03:37:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24205 for ; Fri, 26 Sep 2003 03:37:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2nA6-0004TG-Ba for nemo-archive@odin.ietf.org; Fri, 26 Sep 2003 03:37:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8Q7bAvW017178 for nemo-archive@odin.ietf.org; Fri, 26 Sep 2003 03:37:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2nA5-0004Sr-2S for nemo-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 03:37:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24159 for ; Fri, 26 Sep 2003 03:37:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2nA2-0004ts-00 for nemo-web-archive@ietf.org; Fri, 26 Sep 2003 03:37:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2nA2-0004tp-00 for nemo-web-archive@ietf.org; Fri, 26 Sep 2003 03:37:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2n9x-0004Qq-Ud; Fri, 26 Sep 2003 03:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2n9A-0004PO-Ba for nemo@optimus.ietf.org; Fri, 26 Sep 2003 03:36:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24142 for ; Fri, 26 Sep 2003 03:36:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2n97-0004tT-00 for nemo@ietf.org; Fri, 26 Sep 2003 03:36:09 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A2n97-0004tQ-00 for nemo@ietf.org; Fri, 26 Sep 2003 03:36:09 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8Q7a831002105; Fri, 26 Sep 2003 09:36:09 +0200 (MEST) Received: from ericsson.com (research-jhtluz.ki.sw.ericsson.se [147.214.181.237]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id TN54A4XH; Fri, 26 Sep 2003 09:38:25 +0200 Message-ID: <3F73EC65.3030502@ericsson.com> Date: Fri, 26 Sep 2003 09:36:05 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Mattias Pettersson Organization: Ericsson Research User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: nemo@ietf.org, nemo-base-dt@nal.motlabs.com Subject: Re: [nemo] Issue 5 resolution References: <3F733656.CE35252C@iprg.nokia.com> In-Reply-To: <3F733656.CE35252C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > hi all, > > Issue 5 was about the Extended Home Network concept. the > resolution is to remove the section from the draft and > write up a separate informational/BCP draft. this draft > will contain some practical scenarios and issues when > deploying Mobile Routers. it will also talk about how to > deploy home links to support mobile routers. it is upto > the WG and WG chairs to decide if this informational/BCP > draft should be a WG document. > > the details are at http://people.nokia.net/vijayd/nemo/issues.html > > comments? It is a very good idea to remove it from the draft. The section was very confusing. To quote your conclusion: "bottomline is we dont need separate terminology for something which has been assumed to the normal case (atleast by me)." /Mattias > > Vijay > >  > From nemo-admin@ietf.org Fri Sep 26 14:19:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16629 for ; Fri, 26 Sep 2003 14:19:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xBE-0001wr-Ma; Fri, 26 Sep 2003 14:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xAS-0001wa-DQ for nemo@optimus.ietf.org; Fri, 26 Sep 2003 14:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16598 for ; Fri, 26 Sep 2003 14:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2xAP-00040V-00 for nemo@ietf.org; Fri, 26 Sep 2003 14:18:09 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2xAP-00040A-00 for nemo@ietf.org; Fri, 26 Sep 2003 14:18:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8QIHb522015 for ; Fri, 26 Sep 2003 11:17:37 -0700 X-mProtect: <200309261817> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWF4BIf; Fri, 26 Sep 2003 11:17:36 PDT Message-ID: <3F7482BF.EF95D4E2@iprg.nokia.com> Date: Fri, 26 Sep 2003 11:17:35 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Legacy MIPv6 HAs - Issue 15 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hi all, when a legacy MIPv6 HA (with no Mobile Router support) receives a BU with the Mobile Router flag set, it just ignores the flag. it also ignores any mobility options that it does not understand. therefore the mobility options introduced by Nemo will be ignored. the legacy HA will just process the BU and return 0 (Binding Update accepted) in the BAck. the Mobile Router does not know that the HA didn't setup forwarding for the Mobile Network. this issue was discussed in the design team. the discussion is at http://people.nokia.net/vijayd/nemo/issue15.txt. a proposal to resolve this: introduce a new Binding Ack status value that indicates success for a Binding Update from a Mobile Router. so we will have the following success status values. 0 Binding Update accepted 1 Accepted but prefix discovery necessary 2 Mobile Router Binding Update accepted legacy MIPv6 HAs will return 0. Nemo HAs will return 2. status values 0 and 1 are defined in the MIPv6 spec. 2 will be defined in the Nemo basic support draft. comments? Vijay From exim@www1.ietf.org Fri Sep 26 14:20:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16644 for ; Fri, 26 Sep 2003 14:20:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xBp-0001z7-Hx for nemo-archive@odin.ietf.org; Fri, 26 Sep 2003 14:19:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8QIJbXc007623 for nemo-archive@odin.ietf.org; Fri, 26 Sep 2003 14:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xBp-0001ys-D2 for nemo-web-archive@optimus.ietf.org; Fri, 26 Sep 2003 14:19:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16620 for ; Fri, 26 Sep 2003 14:19:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2xBm-00040g-00 for nemo-web-archive@ietf.org; Fri, 26 Sep 2003 14:19:35 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2xBm-00040d-00 for nemo-web-archive@ietf.org; Fri, 26 Sep 2003 14:19:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xBE-0001wr-Ma; Fri, 26 Sep 2003 14:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2xAS-0001wa-DQ for nemo@optimus.ietf.org; Fri, 26 Sep 2003 14:18:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16598 for ; Fri, 26 Sep 2003 14:18:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2xAP-00040V-00 for nemo@ietf.org; Fri, 26 Sep 2003 14:18:09 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A2xAP-00040A-00 for nemo@ietf.org; Fri, 26 Sep 2003 14:18:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8QIHb522015 for ; Fri, 26 Sep 2003 11:17:37 -0700 X-mProtect: <200309261817> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWF4BIf; Fri, 26 Sep 2003 11:17:36 PDT Message-ID: <3F7482BF.EF95D4E2@iprg.nokia.com> Date: Fri, 26 Sep 2003 11:17:35 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [nemo] Legacy MIPv6 HAs - Issue 15 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi all, when a legacy MIPv6 HA (with no Mobile Router support) receives a BU with the Mobile Router flag set, it just ignores the flag. it also ignores any mobility options that it does not understand. therefore the mobility options introduced by Nemo will be ignored. the legacy HA will just process the BU and return 0 (Binding Update accepted) in the BAck. the Mobile Router does not know that the HA didn't setup forwarding for the Mobile Network. this issue was discussed in the design team. the discussion is at http://people.nokia.net/vijayd/nemo/issue15.txt. a proposal to resolve this: introduce a new Binding Ack status value that indicates success for a Binding Update from a Mobile Router. so we will have the following success status values. 0 Binding Update accepted 1 Accepted but prefix discovery necessary 2 Mobile Router Binding Update accepted legacy MIPv6 HAs will return 0. Nemo HAs will return 2. status values 0 and 1 are defined in the MIPv6 spec. 2 will be defined in the Nemo basic support draft. comments? Vijay From nemo-admin@ietf.org Mon Sep 29 15:39:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06754 for ; Mon, 29 Sep 2003 15:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43rJ-0006pr-M8; Mon, 29 Sep 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qY-0006at-Si for nemo@optimus.ietf.org; Mon, 29 Sep 2003 15:38:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06546; Mon, 29 Sep 2003 15:38:07 -0400 (EDT) Message-Id: <200309291938.PAA06546@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 29 Sep 2003 15:38:06 -0400 Subject: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Nemo Basic Support Protocol Author(s) : V. Devarapalli et al. Filename : draft-ietf-nemo-basic-support-01.txt Pages : 33 Date : 2003-9-29 This document describes the Nemo Basic Support protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol is based on extensions to Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-basic-support-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-basic-support-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29153026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29153026.I-D@ietf.org> --OtherAccess-- --NextPart-- From exim@www1.ietf.org Mon Sep 29 15:39:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06778 for ; Mon, 29 Sep 2003 15:39:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43rR-0006tp-SS for nemo-archive@odin.ietf.org; Mon, 29 Sep 2003 15:39:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TJd9Pr026515 for nemo-archive@odin.ietf.org; Mon, 29 Sep 2003 15:39:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43rR-0006ta-Ox for nemo-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 15:39:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06712 for ; Mon, 29 Sep 2003 15:39:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A43rQ-0003ay-00 for nemo-web-archive@ietf.org; Mon, 29 Sep 2003 15:39:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A43rP-0003ar-00 for nemo-web-archive@ietf.org; Mon, 29 Sep 2003 15:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43rJ-0006pr-M8; Mon, 29 Sep 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A43qY-0006at-Si for nemo@optimus.ietf.org; Mon, 29 Sep 2003 15:38:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06546; Mon, 29 Sep 2003 15:38:07 -0400 (EDT) Message-Id: <200309291938.PAA06546@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: nemo@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 29 Sep 2003 15:38:06 -0400 Subject: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-01.txt Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Nemo Basic Support Protocol Author(s) : V. Devarapalli et al. Filename : draft-ietf-nemo-basic-support-01.txt Pages : 33 Date : 2003-9-29 This document describes the Nemo Basic Support protocol to support network mobility as the mobile network attaches to different points in the Internet. The protocol is based on extensions to Mobile IPv6 and allows for session continuity for every node in the mobile network as the network moves. It also allows every node in the mobile network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed in such a way that network mobility is transparent to the nodes inside the mobile network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-basic-support-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-basic-support-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-basic-support-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-29153026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-basic-support-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-basic-support-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29153026.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@ietf.org Mon Sep 29 16:03:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08145 for ; Mon, 29 Sep 2003 16:03:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44EY-00087Q-6h; Mon, 29 Sep 2003 16:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zi2-00085c-OX for nemo@optimus.ietf.org; Mon, 29 Sep 2003 11:13:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20380 for ; Mon, 29 Sep 2003 11:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zi1-00079h-00 for nemo@ietf.org; Mon, 29 Sep 2003 11:13:09 -0400 Received: from lisa.cityu.edu.hk ([144.214.5.205]) by ietf-mx with esmtp (Exim 4.12) id 1A3zi1-00079e-00 for nemo@ietf.org; Mon, 29 Sep 2003 11:13:09 -0400 Received: from conversion-daemon.alumni.cityu.edu.hk by alumni.cityu.edu.hk (iPlanet Messaging Server 5.1 HotFix 1.12 (built Mar 11 2003)) id <0HLZ00F01BK7DX@alumni.cityu.edu.hk> for nemo@ietf.org; Mon, 29 Sep 2003 23:12:24 +0800 (CST) Received: from albany (albany.cityu.edu.hk [144.214.2.75]) by alumni.cityu.edu.hk (iPlanet Messaging Server 5.1 HotFix 1.12 (built Mar 11 2003)) with ESMTP id <0HLZ0020CDX8VZ@alumni.cityu.edu.hk> for nemo@ietf.org; Mon, 29 Sep 2003 23:05:32 +0800 (CST) Received: from stdwebmail.cityu.edu.hk (faye.cityu.edu.hk [144.214.5.25]) by student.cityu.edu.hk (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLZ001ZXDX8E9@student.cityu.edu.hk> for nemo@ietf.org; Mon, 29 Sep 2003 23:05:32 +0800 (CST) Date: Mon, 29 Sep 2003 23:04:43 +0800 From: Annie Ng <50330537@student.cityu.edu.hk> To: nemo@ietf.org Message-id: <3F787E6F@stdwebmail.cityu.edu.hk> MIME-version: 1.0 X-Mailer: InterChange (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-WebMail-UserId: 50330537 X-EXP32-SerialNo: 50000161 Content-Transfer-Encoding: 7BIT Subject: [nemo] some inquiries Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Dear Sir, I am annie, an university student in HK. I am very interesting in mobile networking. Therefore, i am reading the NEMO basic protocol recently. However, there exist a double crossing over tunnel problem which happens when local fixed node(LFN) communicate with visiting mobile node(VMN) in the same mobile network. Its becasue the LFN need to send packets to mobile router which need to establish the tunnel with the home agent of it. Howerver, the home agent of the mobile router will send back packets to the mobile agent which then send to VMN. So, is there any solution for that double crossing problem? can u tell me the solution ? or give me some useful link for analysis it? thank you very much! Annie From exim@www1.ietf.org Mon Sep 29 16:03:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08164 for ; Mon, 29 Sep 2003 16:03:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44Ep-00089B-SW for nemo-archive@odin.ietf.org; Mon, 29 Sep 2003 16:03:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TK3JYk031310 for nemo-archive@odin.ietf.org; Mon, 29 Sep 2003 16:03:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44En-00088j-Ba for nemo-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 16:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08106 for ; Mon, 29 Sep 2003 16:03:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44El-000416-00 for nemo-web-archive@ietf.org; Mon, 29 Sep 2003 16:03:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A44El-000413-00 for nemo-web-archive@ietf.org; Mon, 29 Sep 2003 16:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44EY-00087Q-6h; Mon, 29 Sep 2003 16:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zi2-00085c-OX for nemo@optimus.ietf.org; Mon, 29 Sep 2003 11:13:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20380 for ; Mon, 29 Sep 2003 11:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zi1-00079h-00 for nemo@ietf.org; Mon, 29 Sep 2003 11:13:09 -0400 Received: from lisa.cityu.edu.hk ([144.214.5.205]) by ietf-mx with esmtp (Exim 4.12) id 1A3zi1-00079e-00 for nemo@ietf.org; Mon, 29 Sep 2003 11:13:09 -0400 Received: from conversion-daemon.alumni.cityu.edu.hk by alumni.cityu.edu.hk (iPlanet Messaging Server 5.1 HotFix 1.12 (built Mar 11 2003)) id <0HLZ00F01BK7DX@alumni.cityu.edu.hk> for nemo@ietf.org; Mon, 29 Sep 2003 23:12:24 +0800 (CST) Received: from albany (albany.cityu.edu.hk [144.214.2.75]) by alumni.cityu.edu.hk (iPlanet Messaging Server 5.1 HotFix 1.12 (built Mar 11 2003)) with ESMTP id <0HLZ0020CDX8VZ@alumni.cityu.edu.hk> for nemo@ietf.org; Mon, 29 Sep 2003 23:05:32 +0800 (CST) Received: from stdwebmail.cityu.edu.hk (faye.cityu.edu.hk [144.214.5.25]) by student.cityu.edu.hk (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLZ001ZXDX8E9@student.cityu.edu.hk> for nemo@ietf.org; Mon, 29 Sep 2003 23:05:32 +0800 (CST) Date: Mon, 29 Sep 2003 23:04:43 +0800 From: Annie Ng <50330537@student.cityu.edu.hk> To: nemo@ietf.org Message-id: <3F787E6F@stdwebmail.cityu.edu.hk> MIME-version: 1.0 X-Mailer: InterChange (Hydra) SMTP v3.62 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-WebMail-UserId: 50330537 X-EXP32-SerialNo: 50000161 Content-Transfer-Encoding: 7BIT Subject: [nemo] some inquiries Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Dear Sir, I am annie, an university student in HK. I am very interesting in mobile networking. Therefore, i am reading the NEMO basic protocol recently. However, there exist a double crossing over tunnel problem which happens when local fixed node(LFN) communicate with visiting mobile node(VMN) in the same mobile network. Its becasue the LFN need to send packets to mobile router which need to establish the tunnel with the home agent of it. Howerver, the home agent of the mobile router will send back packets to the mobile agent which then send to VMN. So, is there any solution for that double crossing problem? can u tell me the solution ? or give me some useful link for analysis it? thank you very much! Annie From nemo-admin@ietf.org Mon Sep 29 16:08:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08500 for ; Mon, 29 Sep 2003 16:08:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44JN-00009f-Rf; Mon, 29 Sep 2003 16:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44JE-00007U-0R for nemo@optimus.ietf.org; Mon, 29 Sep 2003 16:07:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08470 for ; Mon, 29 Sep 2003 16:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44JC-00046g-00 for nemo@ietf.org; Mon, 29 Sep 2003 16:07:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A44JB-00046K-00 for nemo@ietf.org; Mon, 29 Sep 2003 16:07:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8TK79p13766; Mon, 29 Sep 2003 13:07:09 -0700 X-mProtect: <200309292007> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd4SLuDB; Mon, 29 Sep 2003 13:07:08 PDT Message-ID: <3F7890EC.59BC9981@kniveton.com> Date: Mon, 29 Sep 2003 13:07:08 -0700 From: "T.J. Kniveton" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Annie Ng <50330537@student.cityu.edu.hk> CC: nemo@ietf.org Subject: Re: [nemo] some inquiries References: <3F787E6F@stdwebmail.cityu.edu.hk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Annie Ng wrote: > > Dear Sir, > > I am annie, an university student in HK. I am very interesting in mobile > networking. Therefore, i am reading the NEMO basic protocol recently. > However, there exist a double crossing over tunnel problem which happens when > local fixed node(LFN) communicate with visiting mobile node(VMN) in the same > mobile network. Its becasue the LFN need to send packets to mobile router > which need to establish the tunnel with the home agent of it. Howerver, the > home agent of the mobile router will send back packets to the mobile agent > which then send to VMN. > > So, is there any solution for that double crossing problem? > can u tell me the solution ? > or give me some useful link for analysis it? > > thank you very much! > > Annie Hi Annie, This seems to be a general Mobile IPv6 issue, which in essence is RO. If the VMN can establish route optimization with the CN (which is the LFN) under Mobile IP, the CN (LFN) will use the VMN's CoA, which is an address in the mobile network, and the MR will route the packet directly on the local link. Otherwise, the packet has to go back to the VMN's HA, which will require a trip back to the MR's HA as well. TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From exim@www1.ietf.org Mon Sep 29 16:08:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08515 for ; Mon, 29 Sep 2003 16:08:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44JP-0000B4-DC for nemo-archive@odin.ietf.org; Mon, 29 Sep 2003 16:08:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TK831t000671 for nemo-archive@odin.ietf.org; Mon, 29 Sep 2003 16:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44JO-0000Ac-TA for nemo-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 16:08:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08489 for ; Mon, 29 Sep 2003 16:07:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44JN-000473-00 for nemo-web-archive@ietf.org; Mon, 29 Sep 2003 16:08:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A44JM-000470-00 for nemo-web-archive@ietf.org; Mon, 29 Sep 2003 16:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44JN-00009f-Rf; Mon, 29 Sep 2003 16:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A44JE-00007U-0R for nemo@optimus.ietf.org; Mon, 29 Sep 2003 16:07:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08470 for ; Mon, 29 Sep 2003 16:07:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A44JC-00046g-00 for nemo@ietf.org; Mon, 29 Sep 2003 16:07:50 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A44JB-00046K-00 for nemo@ietf.org; Mon, 29 Sep 2003 16:07:49 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8TK79p13766; Mon, 29 Sep 2003 13:07:09 -0700 X-mProtect: <200309292007> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpd4SLuDB; Mon, 29 Sep 2003 13:07:08 PDT Message-ID: <3F7890EC.59BC9981@kniveton.com> Date: Mon, 29 Sep 2003 13:07:08 -0700 From: "T.J. Kniveton" X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Annie Ng <50330537@student.cityu.edu.hk> CC: nemo@ietf.org Subject: Re: [nemo] some inquiries References: <3F787E6F@stdwebmail.cityu.edu.hk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Annie Ng wrote: > > Dear Sir, > > I am annie, an university student in HK. I am very interesting in mobile > networking. Therefore, i am reading the NEMO basic protocol recently. > However, there exist a double crossing over tunnel problem which happens when > local fixed node(LFN) communicate with visiting mobile node(VMN) in the same > mobile network. Its becasue the LFN need to send packets to mobile router > which need to establish the tunnel with the home agent of it. Howerver, the > home agent of the mobile router will send back packets to the mobile agent > which then send to VMN. > > So, is there any solution for that double crossing problem? > can u tell me the solution ? > or give me some useful link for analysis it? > > thank you very much! > > Annie Hi Annie, This seems to be a general Mobile IPv6 issue, which in essence is RO. If the VMN can establish route optimization with the CN (which is the LFN) under Mobile IP, the CN (LFN) will use the VMN's CoA, which is an address in the mobile network, and the MR will route the packet directly on the local link. Otherwise, the packet has to go back to the VMN's HA, which will require a trip back to the MR's HA as well. TJ -- T.J. Kniveton Communication Systems Lab Nokia Research Center From nemo-admin@ietf.org Tue Sep 30 03:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10104 for ; Tue, 30 Sep 2003 03:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EXG-0005H0-1S; Tue, 30 Sep 2003 03:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EXD-0005GT-K8 for nemo@optimus.ietf.org; Tue, 30 Sep 2003 03:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10089 for ; Tue, 30 Sep 2003 03:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EX9-00032R-00 for nemo@ietf.org; Tue, 30 Sep 2003 03:02:55 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 1A4EX8-00031v-00 for nemo@ietf.org; Tue, 30 Sep 2003 03:02:54 -0400 Received: from sait1000 (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h8U72IAV026906 for ; Tue, 30 Sep 2003 16:02:18 +0900 (KST) Message-ID: <007a01c38720$c8687ce0$ed2f024b@sait1000> Reply-To: "Jung-Hoon Cheon" From: "Jung-Hoon Cheon" To: References: <200309291938.PAA06546@ietf.org> Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-01.txt Date: Tue, 30 Sep 2003 16:02:16 +0900 Organization: Samsung AIT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHJlYWQgYSBuZXcgdmVyc2lvbiBvZiBORU1PIEJhc2ljIHN1cHBvcnQgcHJv dG9jb2wuDQoNCkkgYXBwcmVjaWF0ZSBhbiBlZmZvcnQgb2YgdGhlIGRlc2lnbiB0ZWFtLg0KDQoN CkkgaGF2ZSBhIHF1ZXN0aW9uIGFzIGZvbGxvd2luZy4NCg0KUHJlZml4IHRhYmxlIGlzIGFuIG9w dGlvbmFsIGRhdGEgc3RydWN0dXJlIGFuZCB1c2VkIG9ubHkgZm9yIGV4cGxpY2l0IG1vZGUuDQoN CkkgdGhpbmsgdGhhdCBpZiBIQSBpbXBsaWNpdGx5IGhhcyBhIHByZS1jb25maWd1cmVkIHJvdXRl cyB0byB0aGUgbW9iaWxlIG5ldHdvcmssDQoNCnRoZSBwcmUtY29uZmlndXJlZCByb3V0ZXMgbG9v a3MgbGlrZSBhcyBhIHByZWZpeCB0YWJsZS4NCg0KRm9yIGV4YW1wbGUsIHdoZW4gQ04gc2VuZHMg YSBwYWNrZXQgZGVzdGluZWQgZm9yIG1vYmlsZSBuZXR3b3JrLCBIQSBpbnRlcmNlcHRzIHRoZSBw YWNrZXQuDQoNCkF0IHRoYXQgdGltZSwgdGhlIEhBIGNhbiBkbyBieSBzZXJjaGluZyB0aGUgQkNF IG9yIGFzc29jaWF0ZWQgcHJlZml4ZXMuDQoNCnVzdWFsbHkgTkVNTyBwZXJmb3JtcyBpbiBpbXBs aWNpdCBtb2RlIHNpbmNlIHRoZSBNTlAgaXMgYXNzb2NpYXRlZCB3aXRoIGhvbWUgYWRkcmVzcyBv ZiBtb2JpbGUgcm91dGVyLg0KDQpBbnl3YXksIHdlIGFzc3VtIHRoYXQgcHJlLWNvbmZpZ3VyZWQg cm91dGVzIHVzZWQgaW4gaW1wbGljaXQgbW9kZSBoYXMgYSBjb25jZXB0dWFsIHN0cnVjdHVyZSwN Cg0KYmVjYXVzZSBvZiBtYW51YWwgY29uZmlndXJhdGlvbiBhdCB0aGUgSG9tZSBBZ2VudCBtYXBw aW5nIHRoZSBNb2JpbGUgUm91dGVyJ3MgaG9tZSBhZGRyZXNzIA0KDQp0byB0aGUgaW5mb3JtYXRp b24gcmVxdWlyZWQgZm9yIHNldHRpbmcgdXAgZm9yd2FyZGluZyBmb3IgdGhlIE1vYmlsZSBOZXR3 b3JrLg0KDQpJcyB0aGF0IHJpZ2h0PyANCg0KTWF5YmUgaXQgd2lsbCBiZSBhbiBpbXBsZW1lbnRh dGlvbiBpc3N1ZS4NCg0KIA0KQWxzbywgSEEgTVVTVCBzdXBwb3J0IGFsbCBtb2RlcyBhbmQgU0hP VUxEIHVzZSBQcmVmaXggVGFibGUgb25seSBmb3IgdmVyaWZpY2F0aW9uIGluIGV4cGxpY2l0IG1v ZGUuDQoNCnN0aWxsIHByZWZpeCB0YWJsZSBpcyBhbiBvcHRpb25hbCBzdHJ1Y3R1cmU/IA0KDQpC ZXN0IFJlZ2FyZHMuDQpKdW5nLUhvb24gQ2hlb24= From exim@www1.ietf.org Tue Sep 30 03:03:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10119 for ; Tue, 30 Sep 2003 03:03:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EXJ-0005I4-QO for nemo-archive@odin.ietf.org; Tue, 30 Sep 2003 03:03:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8U735CQ020335 for nemo-archive@odin.ietf.org; Tue, 30 Sep 2003 03:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EXJ-0005Hu-L3 for nemo-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 03:03:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10096 for ; Tue, 30 Sep 2003 03:02:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EXF-00032j-00 for nemo-web-archive@ietf.org; Tue, 30 Sep 2003 03:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4EXF-00032g-00 for nemo-web-archive@ietf.org; Tue, 30 Sep 2003 03:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EXG-0005H0-1S; Tue, 30 Sep 2003 03:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4EXD-0005GT-K8 for nemo@optimus.ietf.org; Tue, 30 Sep 2003 03:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10089 for ; Tue, 30 Sep 2003 03:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4EX9-00032R-00 for nemo@ietf.org; Tue, 30 Sep 2003 03:02:55 -0400 Received: from ns.sait.samsung.co.kr ([202.20.142.13]) by ietf-mx with esmtp (Exim 4.12) id 1A4EX8-00031v-00 for nemo@ietf.org; Tue, 30 Sep 2003 03:02:54 -0400 Received: from sait1000 (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.9/8.12.1) with SMTP id h8U72IAV026906 for ; Tue, 30 Sep 2003 16:02:18 +0900 (KST) Message-ID: <007a01c38720$c8687ce0$ed2f024b@sait1000> Reply-To: "Jung-Hoon Cheon" From: "Jung-Hoon Cheon" To: References: <200309291938.PAA06546@ietf.org> Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-01.txt Date: Tue, 30 Sep 2003 16:02:16 +0900 Organization: Samsung AIT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHJlYWQgYSBuZXcgdmVyc2lvbiBvZiBORU1PIEJhc2ljIHN1cHBvcnQgcHJv dG9jb2wuDQoNCkkgYXBwcmVjaWF0ZSBhbiBlZmZvcnQgb2YgdGhlIGRlc2lnbiB0ZWFtLg0KDQoN CkkgaGF2ZSBhIHF1ZXN0aW9uIGFzIGZvbGxvd2luZy4NCg0KUHJlZml4IHRhYmxlIGlzIGFuIG9w dGlvbmFsIGRhdGEgc3RydWN0dXJlIGFuZCB1c2VkIG9ubHkgZm9yIGV4cGxpY2l0IG1vZGUuDQoN CkkgdGhpbmsgdGhhdCBpZiBIQSBpbXBsaWNpdGx5IGhhcyBhIHByZS1jb25maWd1cmVkIHJvdXRl cyB0byB0aGUgbW9iaWxlIG5ldHdvcmssDQoNCnRoZSBwcmUtY29uZmlndXJlZCByb3V0ZXMgbG9v a3MgbGlrZSBhcyBhIHByZWZpeCB0YWJsZS4NCg0KRm9yIGV4YW1wbGUsIHdoZW4gQ04gc2VuZHMg YSBwYWNrZXQgZGVzdGluZWQgZm9yIG1vYmlsZSBuZXR3b3JrLCBIQSBpbnRlcmNlcHRzIHRoZSBw YWNrZXQuDQoNCkF0IHRoYXQgdGltZSwgdGhlIEhBIGNhbiBkbyBieSBzZXJjaGluZyB0aGUgQkNF IG9yIGFzc29jaWF0ZWQgcHJlZml4ZXMuDQoNCnVzdWFsbHkgTkVNTyBwZXJmb3JtcyBpbiBpbXBs aWNpdCBtb2RlIHNpbmNlIHRoZSBNTlAgaXMgYXNzb2NpYXRlZCB3aXRoIGhvbWUgYWRkcmVzcyBv ZiBtb2JpbGUgcm91dGVyLg0KDQpBbnl3YXksIHdlIGFzc3VtIHRoYXQgcHJlLWNvbmZpZ3VyZWQg cm91dGVzIHVzZWQgaW4gaW1wbGljaXQgbW9kZSBoYXMgYSBjb25jZXB0dWFsIHN0cnVjdHVyZSwN Cg0KYmVjYXVzZSBvZiBtYW51YWwgY29uZmlndXJhdGlvbiBhdCB0aGUgSG9tZSBBZ2VudCBtYXBw aW5nIHRoZSBNb2JpbGUgUm91dGVyJ3MgaG9tZSBhZGRyZXNzIA0KDQp0byB0aGUgaW5mb3JtYXRp b24gcmVxdWlyZWQgZm9yIHNldHRpbmcgdXAgZm9yd2FyZGluZyBmb3IgdGhlIE1vYmlsZSBOZXR3 b3JrLg0KDQpJcyB0aGF0IHJpZ2h0PyANCg0KTWF5YmUgaXQgd2lsbCBiZSBhbiBpbXBsZW1lbnRh dGlvbiBpc3N1ZS4NCg0KIA0KQWxzbywgSEEgTVVTVCBzdXBwb3J0IGFsbCBtb2RlcyBhbmQgU0hP VUxEIHVzZSBQcmVmaXggVGFibGUgb25seSBmb3IgdmVyaWZpY2F0aW9uIGluIGV4cGxpY2l0IG1v ZGUuDQoNCnN0aWxsIHByZWZpeCB0YWJsZSBpcyBhbiBvcHRpb25hbCBzdHJ1Y3R1cmU/IA0KDQpC ZXN0IFJlZ2FyZHMuDQpKdW5nLUhvb24gQ2hlb24= From nemo-admin@ietf.org Tue Sep 30 13:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03221 for ; Tue, 30 Sep 2003 13:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OFB-0004rh-Br; Tue, 30 Sep 2003 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OER-0004qu-FM for nemo@optimus.ietf.org; Tue, 30 Sep 2003 13:24:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03137 for ; Tue, 30 Sep 2003 13:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OEP-0001zL-00 for nemo@ietf.org; Tue, 30 Sep 2003 13:24:13 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A4OEO-0001yx-00 for nemo@ietf.org; Tue, 30 Sep 2003 13:24:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8UHNck04830; Tue, 30 Sep 2003 10:23:38 -0700 X-mProtect: <200309301723> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAzQgsm; Tue, 30 Sep 2003 10:23:37 PDT Message-ID: <3F79BC3C.9090301@iprg.nokia.com> Date: Tue, 30 Sep 2003 10:24:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jung-Hoon Cheon CC: nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-01.txt References: <200309291938.PAA06546@ietf.org> <007a01c38720$c8687ce0$ed2f024b@sait1000> In-Reply-To: <007a01c38720$c8687ce0$ed2f024b@sait1000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jung-Hoon Cheon wrote: >Prefix table is an optional data structure and used only for explicit mode. > >I think that if HA implicitly has a pre-configured routes to the mobile network, > >the pre-configured routes looks like as a prefix table. > yes it could. Prefix Table could be one of the ways for storing per MR configuration information at the HA. see issue 12. >Also, HA MUST support all modes and SHOULD use Prefix Table only for verification in explicit mode. > the HA MAY use Prefix Table for verification in explicit mode. I dont think the draft says SHOULD anywhere. Vijay From exim@www1.ietf.org Tue Sep 30 13:25:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03236 for ; Tue, 30 Sep 2003 13:25:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OFI-0004uC-Vp for nemo-archive@odin.ietf.org; Tue, 30 Sep 2003 13:25:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UHP8FO018850 for nemo-archive@odin.ietf.org; Tue, 30 Sep 2003 13:25:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OFI-0004tx-QL for nemo-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 13:25:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03216 for ; Tue, 30 Sep 2003 13:25:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OFG-00020O-00 for nemo-web-archive@ietf.org; Tue, 30 Sep 2003 13:25:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4OFG-00020L-00 for nemo-web-archive@ietf.org; Tue, 30 Sep 2003 13:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OFB-0004rh-Br; Tue, 30 Sep 2003 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OER-0004qu-FM for nemo@optimus.ietf.org; Tue, 30 Sep 2003 13:24:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03137 for ; Tue, 30 Sep 2003 13:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OEP-0001zL-00 for nemo@ietf.org; Tue, 30 Sep 2003 13:24:13 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1A4OEO-0001yx-00 for nemo@ietf.org; Tue, 30 Sep 2003 13:24:12 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h8UHNck04830; Tue, 30 Sep 2003 10:23:38 -0700 X-mProtect: <200309301723> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAzQgsm; Tue, 30 Sep 2003 10:23:37 PDT Message-ID: <3F79BC3C.9090301@iprg.nokia.com> Date: Tue, 30 Sep 2003 10:24:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jung-Hoon Cheon CC: nemo@ietf.org Subject: Re: [nemo] I-D ACTION:draft-ietf-nemo-basic-support-01.txt References: <200309291938.PAA06546@ietf.org> <007a01c38720$c8687ce0$ed2f024b@sait1000> In-Reply-To: <007a01c38720$c8687ce0$ed2f024b@sait1000> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: nemo-admin@ietf.org Errors-To: nemo-admin@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: NEMO Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jung-Hoon Cheon wrote: >Prefix table is an optional data structure and used only for explicit mode. > >I think that if HA implicitly has a pre-configured routes to the mobile network, > >the pre-configured routes looks like as a prefix table. > yes it could. Prefix Table could be one of the ways for storing per MR configuration information at the HA. see issue 12. >Also, HA MUST support all modes and SHOULD use Prefix Table only for verification in explicit mode. > the HA MAY use Prefix Table for verification in explicit mode. I dont think the draft says SHOULD anywhere. Vijay