From nemo-admin@nal.motlabs.com Fri Nov 1 06:43:03 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03985 for ; Fri, 1 Nov 2002 06:43:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1Bi6C03113; Fri, 1 Nov 2002 12:44:06 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1BhNC03103 for ; Fri, 1 Nov 2002 12:43:24 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id NAA17273 for ; Fri, 1 Nov 2002 13:43:22 +0200 (EET) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id NAA02432 for ; Fri, 1 Nov 2002 13:43:20 +0200 (EET) Message-ID: <00e101c2819c$4ab43300$725ebc82@ELE4114.ele.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [nemo] IPv6 prefix delegation Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 1 Nov 2002 13:46:17 +0200 Content-Transfer-Encoding: 8bit -----Original Message----- From: Alexandru Petrescu To: Pekka Pääkkönen Cc: nemo@nal.motlabs.com Date: 29. lokakuuta 2002 19:04 Subject: Re: [nemo] IPv6 prefix delegation >"Pekka Pääkkönen" writes: >> CN >> | >> --------------- >> ( Internet )--HA >> --------------- >> | >> AR linkX/prefix X >> | MR2-------------------MN2 >> | link1/prefix1 >> | >> MR1 >> | >> | link2/prefix 2 >> | >> MN1 > >Good picture. > >> Hi all. >> Please consider the above picture. MR2 and MN2 on linkX want to >> establish a NEMO-network (consists of MR2 and MN2). It is assumed >> that MR2 needs to dynamically get a IPv6 prefix X for the NEMO, >> because the NEMO-network is created in an ad-hoc way. > >That's a nice statement, but if it is done in an ad-hoc way, then I >believe it's a manet problem, not a NEMO problem. I think we can see >it as a NEMO problem only if we want MN2 to get a new CoA once MR2 had >attached under MR1, but I thought this will not happen and MN2 will >not have to deal with any form of mobility (I assume that's why you >attached MN2 to MR2, presumably like an LFN). > >> When this new NEMO is created and attached to Internet via AR or MR1 >> the following questions arise: >> >> 1.) Where will the IPv6 prefix for the NEMO be received from? From >> AR, HA or MR1 or some other network entity? > >So it's assumed that a mobile network will receive a new prefix >(instead of a CoA), let's say a CoP (Care-of Prefix) when it moves. >This might be very useful for RO. This might be done with Router >Renumbering as well. This might be done with other routing protocols >as well. > >> 2.) What are the protocol requirements for IPv6 prefix delegation in >> a NEMO environment? > >Off the top of my head: security requirements. > >> 3.) Do we need IPv6 prefix delegation for NEMO environment? The >> picture suggests yes, because no IPv6 prefix has been initially >> allocated for the NEMO. > >Initially, there's a prefix allocated to the mobile network when the >mobile network is at home. Let's call it MNP (mobile network prefix). >The mobile network can continue to use this MNP wherever it moves, and >only the MR will obtain a CoA (not a CoP). The MR maintains a >bidirectional tunnel with the HA through which all communication of >LFNs goes. This has obvious inconvenients like multiple tunnels when >nested nets (for which RRH is a solution), or lack of RO with the CN >and so on. These drawbacks should be described somewhere. But >inspite of these obvious drawbacks it still offers a solution for >mobile networks, nested nets, with minimal modifications to Mobile >IPv6. Looks like a good first step. > OK. So a MNP will initially be assigned to the NEMO-network and the MR just has to know that a certain MNP has been assigned to the NEMO-network to which the MR is attached to? Consider that we have a NEMO-network which has multiple MRs on the top level (TLMRs). Each MR has to know the MNP which has been assigned to the NEMO-network. Aren't there real problems related to this use case since each TLMR has to be informed somehow the MNP which has been assigned to the NEMO-network? Or does NEMO-WG not consider the initial formation of the NEMO-network and just assumes that a MNP will somehow be assigned to a NEMO-network? Or am I missing something? Pekka >> Should these issues be concerned with in the requirements related to >> NEMO? > >I think yes, in the NEMO RO requirements case. > >Alex > > From nemo-admin@nal.motlabs.com Fri Nov 1 10:49:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17849 for ; Fri, 1 Nov 2002 10:49:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1FoNC03884; Fri, 1 Nov 2002 16:50:23 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1FnUC03870 for ; Fri, 1 Nov 2002 16:49:30 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 47D445D097; Sat, 2 Nov 2002 00:49:20 +0900 (JST) Message-Id: <20021102.004920.39005041.ernst@sfc.wide.ad.jp> To: kempf@docomolabs-usa.com Cc: nemo@nal.motlabs.com Subject: Re: [nemo] Terminology Update From: Thierry Ernst In-Reply-To: <004d01c27f70$9d5233b0$656015ac@T23KEMPF> References: <20021028.131712.63244074.ernst@sfc.wide.ad.jp> <03c001c27f2f$ee3730a0$f529024b@athos> <004d01c27f70$9d5233b0$656015ac@T23KEMPF> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 02 Nov 2002 00:49:20 +0900 (JST) Content-Transfer-Encoding: 7bit Hi James, From: "James Kempf" > As you may be aware, the Seamoby WG currently has a WG draft on its charter that > consolidates mobility related terms in the IETF. The draft is meant to be a way > for draft authors of mobility-related drafts to avoid the extensive terminology > section at the beginning, and provide a reference to normalize references to > mobility-related terms. > > Would you be interested in merging your terminology draft in with the Seamoby > draft? I think it would be extremely useful to have the mobile network terms > together with the rest of the mobility-related terms. Personally, I'm not against the idea. I think there are terms that would be useful to be merged. High levels NEMO terms like "mobile network", "mobile router" and other like that. And some terms in your draft are useful for us too. But, as you know, NEMO is chartered to produce a RFC about terminology and requirements. The definitions are in a way implying some de facto requirements. So, how to draw the line between the 2 ? What I'm not comfortable with is that the draft you are speaking about is a draft-seamoby-... From a NEMO stand point, it's important for us to keep the control on the definition of terms we use/need. So, if we come to merge the drafts, how to do so ? Thierry. From nemo-admin@nal.motlabs.com Fri Nov 1 12:25:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23842 for ; Fri, 1 Nov 2002 12:25:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1HQLC04282; Fri, 1 Nov 2002 18:26:22 +0100 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1HPLC04272 for ; Fri, 1 Nov 2002 18:25:22 +0100 Message-ID: <01f401c281cb$6cce5180$3c6015ac@T23KEMPF> From: "James Kempf" To: "Thierry Ernst" Cc: References: <20021028.131712.63244074.ernst@sfc.wide.ad.jp><03c001c27f2f$ee3730a0$f529024b@athos><004d01c27f70$9d5233b0$656015ac@T23KEMPF> <20021102.004920.39005041.ernst@sfc.wide.ad.jp> Subject: Re: [nemo] Terminology Update MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 1 Nov 2002 09:23:40 -0800 Content-Transfer-Encoding: 7bit Thierry, The terminology draft is just in Seamoby because the authors couldn't find any other mobility related group that wanted to sponsor it. It actually started out in MANET. I don't think we need get into a turf battle about which WG has control over the draft. If you want, we can move the terminology draft to NEMO. The real issues in my mind are whether the NEMO group feels comfortable enough with the state of its terminology discussion that it wants to incorporate the terminology, since we would like to take the terminology draft to last call early next year. If not, then we should keep the NEMO terminology separate. Additionally, we need to ask whether it makes sense to include network mobility related terminology into the same draft. It sounds from your note that the terminology is intertwined with the requirements, and thus the group is not yet ready to finalize. As for the usefulness of merging, it sounds as if you feel it would be useful. Perhaps we ought to wait until we are ready to take the terminology draft to last call, then check back? jak ----- Original Message ----- From: "Thierry Ernst" To: Cc: Sent: Friday, November 01, 2002 7:49 AM Subject: Re: [nemo] Terminology Update > > Hi James, > > From: "James Kempf" > > As you may be aware, the Seamoby WG currently has a WG draft on its charter that > > consolidates mobility related terms in the IETF. The draft is meant to be a way > > for draft authors of mobility-related drafts to avoid the extensive terminology > > section at the beginning, and provide a reference to normalize references to > > mobility-related terms. > > > > Would you be interested in merging your terminology draft in with the Seamoby > > draft? I think it would be extremely useful to have the mobile network terms > > together with the rest of the mobility-related terms. > > Personally, I'm not against the idea. > > I think there are terms that would be useful to be merged. High levels > NEMO terms like "mobile network", "mobile router" and other like > that. And some terms in your draft are useful for us too. But, as you > know, NEMO is chartered to produce a RFC about terminology and > requirements. The definitions are in a way implying some de facto > requirements. So, how to draw the line between the 2 ? > > What I'm not comfortable with is that the draft you are speaking about > is a draft-seamoby-... From a NEMO stand point, it's important for us > to keep the control on the definition of terms we use/need. So, if we > come to merge the drafts, how to do so ? > > Thierry. > > > > > From nemo-admin@nal.motlabs.com Fri Nov 1 13:22:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27351 for ; Fri, 1 Nov 2002 13:22:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1INJC04511; Fri, 1 Nov 2002 19:23:19 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA1IMqC04501 for ; Fri, 1 Nov 2002 19:22:52 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 638545D016 for ; Sat, 2 Nov 2002 03:22:45 +0900 (JST) Message-Id: <20021102.032245.100256713.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Terminology update -01 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 02 Nov 2002 03:22:45 +0900 (JST) Content-Transfer-Encoding: 7bit Dear all, I've updated the terminology draft today (version -01). Before it shows on the IETF web site, you can find it here: http://www.nal.motlabs.com/nemo/drafts/draft-ernst-nemo-terminology.txt 4. Changes since last draft - replace TLMR with root-MR - add sub-MR, and parent-MR - add a definition for "Multihomed Nested Mobile Network" Thank to Jin Hyeock for pointing out the multihoming ambiguity. Thierry From nemo-admin@nal.motlabs.com Sat Nov 2 08:54:45 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05006 for ; Sat, 2 Nov 2002 08:54:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA2Du4C08291; Sat, 2 Nov 2002 14:56:05 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA2DthC08281 for ; Sat, 2 Nov 2002 14:55:44 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA2Dthfb029309; Sat, 2 Nov 2002 06:55:44 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA16985; Sat, 2 Nov 2002 06:55:39 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id gA2DtYU08173; Sat, 2 Nov 2002 07:55:34 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 14F742EC86; Sat, 2 Nov 2002 14:55:33 +0100 (CET) To: "Pekka =?iso-8859-1?q?P=E4=E4kk=F6nen?=" Cc: Subject: Re: [nemo] IPv6 prefix delegation References: <00e101c2819c$4ab43300$725ebc82@ELE4114.ele.vtt.fi> From: Alexandru Petrescu In-Reply-To: <00e101c2819c$4ab43300$725ebc82@ELE4114.ele.vtt.fi> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Lines: 71 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gA2DthC08281 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 01 Nov 2002 21:39:28 +0100 Content-Transfer-Encoding: 8bit Pekka, here are my thoughts. The issues may indeed look tangled, but maybe there's a simple way out of this if we consider them from a Mobile IP standpoint. "Pekka Pääkkönen" writes: > OK. So a MNP will initially be assigned to the NEMO-network and the > MR just has to know that a certain MNP has been assigned to the > NEMO-network to which the MR is attached to? Yes, exactly. The nice thing about MNP is that we can also call it Home Prefix (or HP). That is very stable and never changes. The MNP on the mobile network will move anywhere around the Internet, and the HA will redirect traffic to its current position (the CoA of the MR). Contrast this to the ephemerality of the prefix obtained via prefix delegation. If I understand correctly what was said until now, it is that a mobile link will arrive in a visited domain and will obtain a prefix valid in that visited network. So the mobile link can stay there as long as it wants and be linked to the Internet. Once it moves away, the mobile link must get rid of that delegated prefix, since it is valid only in the respective visited network. > Consider that we have a NEMO-network which has multiple MRs on the > top level (TLMRs). You've just enunciated the multi-homing aspect. The NEMO-network can be multi-homed, either with two interfaces on the MR, or with several TLMRs, as the definition goes. I do not know how this works exactly, but it should work somehow. > Each MR has to know the MNP which has been assigned to the > NEMO-network. Aren't there real problems related to this use case > since each TLMR has to be informed somehow the MNP which has been > assigned to the NEMO-network? The way that TLMR1 knows about MNP, is the same way that TLMR2 knows about MNP. > Or does NEMO-WG not consider the initial formation of the > NEMO-network and just assumes that a MNP will somehow be assigned to > a NEMO-network? I think that the NEMO-network (new term Thierry!) is not formed dynamically by an MR joining a link of LFNs. Both MR and LFNs have the same home, from the start. I think that many people see the MR permanently attached to the mobile link, thus the MNP is pre-configured on the MR. Something like taking a "slice" of a fixed home network and moving it away. In Mobile IPv6, there's the concept of Home Agent discovery, where an MH discovers its HA and then auto-configures a Home Address for itself. NEMO goes from MH to MR, so this could be extended to an MR like this: MR first does what MH does (discovers HA and auto-configures a Home Address); and configures a bidir MRHA tunnel to its HA; and then obtains from its HA an MNP (mobile network prefix, or the home prefix) for its mobile link. Maybe _this_ could be done with Prefix Delegation. The goal of this mechanism would be to not have the MNP preconfigured on the MR, but obtained dynamically from its HA. This MNP would continue to stay stable every time MR changes its CoA. This is different from MR using Prefix Delegation to obtain a new prefix (CoP) each time it moves. Or maybe this is what you wanted to say. My humble oppinion, Alex From nemo-admin@nal.motlabs.com Sat Nov 2 08:57:25 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05052 for ; Sat, 2 Nov 2002 08:57:24 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA2Dx1C08321; Sat, 2 Nov 2002 14:59:01 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA2DwoC08306 for ; Sat, 2 Nov 2002 14:58:50 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gA2DwlhP029608; Sat, 2 Nov 2002 06:58:48 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA02710; Sat, 2 Nov 2002 06:55:00 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id gA2DtgU23047; Sat, 2 Nov 2002 07:55:43 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C5D542EC95; Sat, 2 Nov 2002 14:55:33 +0100 (CET) To: Thierry Ernst Cc: References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> From: Alexandru Petrescu In-Reply-To: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 93 Subject: [nemo] Unmodified CN? (Was: Launching Requirement Discussion) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 02 Nov 2002 15:33:14 +0100 Thierry Ernst writes: > Anyway, may I ask all people interested in clearing up the > requirements to read the drafts and to figure out what are their > commonalities and divergences and comment on what is new, what is > still not clear, and what is missing ? There are indeed many commonalities, and there are also many divergences. I've been trying to compile a list of requirements by eliminating the commonalities, or grouping them. The list is attached but I have no pretension with this list, I do not pretend it to be neither complete nor correct. Everything is copied from drafts, and the idea to introduce non-goals is also from a draft. There's much text about CN not being modified. What is the considered CN that shouldn't be modified? A non-Mobile IPv6 CN? An RO-supporting CN? The same questions about LFN. Alex General Requirements -------------------- Unified and unique NEMO protocol v4 and v6. Migration Transparency: unicast and multicast session continuity, no interruption to TCP after IP address change of MR. Reachability at permanent home address. Must work as if the mobile network were at home. Rely on the MRHA bidir tunnel of Mobile IP and Mobile IPv6. Internet-WIDE mobility, heterogeneous first hop L2s, inter-domain. No impact on the routing fabric neither on the Internet addressing architecture. At IP layer, handover at IP layer, no impact on TCP. Seamless mobility, low latency, as seamless as host mobility, co-existence with fast handoffs. Support vertical, horizontal and diagonal handoffs. Minimum signalling overload: number of new NEMO messages kept minimal. No impact on CN Mobile CN, MNN Must work with non-Mobile IPv6 LFNs. All mobile network topologies from small to large, from single to nested. Large number of mobile networks. Large number of CNs. Comply to IPv6 node requirements Multi-homing: the NEMO protocol supports multi-homed mobile networks. Architectural considerations: there's an MR. IPv4 co-localization or separation of MR and FA. Leaf mobile networks and not transit networks. Standardization and implementation-oriented focus. Security requirements --------------------- Co-existence with AAA. Detailed AAA requirements in draft-ng. Security: NEMO should not introduce more security threats than Mobile IPv6. Securing the route-updates when changing CoAs. Confidentiality: MNNs confidentiality. Authentication: control messages must be authenticated. Authorization: sender is authorized. Location privacy: MNNs hide their location to third parties. Access control: VMNs are access controlled. Access control MR-AR. Non-goals --------- Host mobility. This is the problem domain of Mobile IP. Administration of the network Address assignment of hosts and links Network architectures Solutions for service discovery. These should be handled by traditional service discovery mechanisms From nemo-admin@nal.motlabs.com Sat Nov 2 09:03:53 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05231 for ; Sat, 2 Nov 2002 09:03:46 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA2E32C08451; Sat, 2 Nov 2002 15:03:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA2DwoC08307 for ; Sat, 2 Nov 2002 14:58:50 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gA2DwmhP029609; Sat, 2 Nov 2002 06:58:48 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA02714; Sat, 2 Nov 2002 06:55:01 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id gA2DtTF10245; Sat, 2 Nov 2002 07:55:30 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 56BD82EC8B; Sat, 2 Nov 2002 14:55:33 +0100 (CET) To: Thierry Ernst Cc: References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> From: Alexandru Petrescu In-Reply-To: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Lines: 1003 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gA2DwoC08307 Subject: [nemo] my list of compiled requirements (was: Launching Requirement Discussion) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 02 Nov 2002 15:25:13 +0100 Content-Transfer-Encoding: 8bit Thierry Ernst writes: > It seems that we have a couple of new/updated drafts to discuss the > requirements, but I haven't seen an announcement from all the authors, > so I'm not sure about what is on the table. > > So far, I have seen: > draft-ernst-nemo-requirements-00.txt > draft-ng-nemo-aaa-use-00.txt > draft-janneteau-nemo-requirements-00.txt > draft-sarikaya-nemo-archreqs-00.txt I've been compiling recently the following drafts: draft-ernst-nemo-requirements-00.txt: draft-janneteau-nemo-requirements-00.txt: draft-kniveton-monet-requirements-00.txt: draft-soliman-monet-statement-00.txt: draft-sarikaya-nemo-archreqs-00.txt: draft-ng-nemo-aaa-use-00.txt: Here's the copy paste list I've been working with. draft-ernst-nemo-requirements-00.txt: 3. High Level Requirements This section details a number of high level requirements that should be met by the solutions. 3.1. Migration Transparency In order to provide migration transparency, a permanent and continuous Internet connectivity must be provided to all MNNs, without disruption of service. MNNs must always be reachable regardless of the point of attachment of the MR, and sessions must be maintained after the MR has changed its point of attachment. 3.2. Operational Transparency In order to be transparent to the applications and the users, NEMO support must be performed at the network layer. 3.3. Performance Transparency (Seamless Mobility) NEMO support SHOULD exhibit low latency, incur little or no data loss, minimum delays, minimum signaling load, and minimum bandwidth consumption for packet delivery. It should be performed as seamlessly as host mobility is supported (no abrupt degradation of service). 3.4. Layers Independence Handover of IP sessions is performed at the network layer. With respect to the layer separation of the Internet protocol suite, handover MUST be managed at the network layer only and transparently to upper layers, despite the migration of the mobile network in the network topology. Therefore, a change of topological location MUST not have an impact on layers above the network layer other than a transient loss of performance, as depicted in the above paragraph. If this is respected, compatibility with existing transport and application layers is maintained. In practice, the identifiers used at the transport layer should be independent from the physical IP addresses used at the network layer for routing. If upper layer protocols require a location independent and invariant identifier, the network layer MUST provide it with an identifier irrespective of the actual topological location. 3.5. NEMO Support Transparency for MNNs In section "observation O1", we have seen that "MNNs don't change their own point of attachment as a result of the mobile network's displacement in the Internet topology. NEMO support SHOULD therefore be performed transparently to MNNs and keep them away from participating in NEMO support. Although MNNs may encounter variable delays of transmission and loss with their respective CNs as the network is moving. This is not considered a lack of transparency. However, receiving movement information may be useful to hosts able to understand it, so this could be allowed as an option, and LMNs and VMNs, which are able to change their own point of attachment must manage their own mobility. 3.7. Minimum Signaling Overload Mobility management is usually performed at the cost of control traffic. In order to be scalable, NEMO support MUST minimize this control traffic. 3.12. No impact on CN or Internet routing Session continuity between a MNN and arbitrary CNs anywhere in the Internet SHOULD NOT assume any changes to existing CNs or the Internet routing architecture. On the other hand, optimizations for performance enhancement MAY involve some changes to CNs, provided that such optimizations would not cause any disruption to ongoing sessions, if not supported by CNs (i.e. backward compatible). [THIS IS TO BE DISCUSSED (in light of the observation made in section "Minimum Impact on the Existing Protocols and Infrastructure" here above) BECAUSE IT WOULD PREVENT POTENTIALLY INTERESTING AND ORTHOGONAL SOLUTIONS TO BE PROPOSED]. 3.13. Security NEMO support must comply with usual IPv6 security policies and standardized protocols. In addition, and unlike fixed nodes, MNNs are more exposed to security threats, particularly identity usurpation. NEMO support must provide MNNs and their CNs with at least as good security as for fixed nodes and mobile hosts. It particularly shouldn't leave more room for intruders to usurp an identify nor to perpetrate any kind of attack against the MNNs nor the CNs. In practice, all control messages required by NEMO support must be exchanged in a secure manner and must ensure the following: 3.13.1. Confidentiality All control messages transmitted in the network MUST ensure MNNs' confidentiality. Only the recipient of the control message may be able to decrypt the content of the datagram. 3.13.2. Authentication All control messages MUST be authenticated by recipients in order to prevent intruders to usurp the identity of a MNN. 3.13.3. Authorization The recipient of a control message MUST ensure that the sender is effectively authorized to perform the mobility support operation indicated in the control message. 3.13.4. Location Privacy NEMO support may provide means for MNNs to hide their location to any third party. It shouldn't be possible to determine the succession of topological location of a mobile network or a particular MNN by monitoring the exchange of control messages. In practice, MNNs may wish to hide their location to some or all of their CNs, or anyone else but the CNs. It may also be desirable to hide the location of the entire mobile network to all CNs without discrimination between MNNs. 3.14. Access Control 3.14.1. Access Control for VMNs Mobile Networks MUST be able to authenticate and authorize VMNs to gain access to the Internet via the mobile network infrastructure (MRs). 3.14.2. Access Control Architecture To be able to comply with the current access control mechanisms and achieve a scalable solution, the final solution MUST NOT assume that the fixed network would authenticate VMNs. VMN authentication and authorization MUST be the responsibility of the mobile network. 3.14.3. Access Control in the Fixed Network AAA solutions MUST allow for authenticating an entire network. This MAY simply be done by ensuring that the Authentication and Authorization is not necessarily performed for a single IP address. This is particularly important for IPv6 as each node may configure multiple addresses. 3.15. Internet-wide mobility In order to ensure permanent and uninterrupted Internet-wide mobility, mobile network should be able to roam between access networks belonging to distinct ISPs and corporate networks (distinct administrative domains, i.e. inter-domain mobility) and via any available access technology (distinct technologies:802.11b WLAN, Bluetooth, satellite link, GSM, i.e. heterogeneous mobility). Indeed, nothing but administrative and security policies should prevent a mobile network to attach anywhere in the Internet topology. So, the solution must technically allow this kind of scenario. In addition, NEMO support must also accommodate to CNs deployed in distinct administrative domains. 3.16. Unified Solution Should different schemes be proposed, a unified mobility support scheme is required. A situation where distinct NEMO support schemes are deployed and unable to inter-operate with each other must be avoided. 3.17. Mobile CNs NEMO support MUST be optimized to handle the case where the CN is MIPv6-enabled and/or itself located in a mobile network (particularly if it is a VMN). It must perform efficiently in both cases. 4. Requirements for Basic Support In this section, the high-level requirements are refined in a more explicit manner for basic support. This list is not exhaustive and should be combined with the requirements found in the other drafts. Requirements follow from our observations and high-level requirements in section 2 and 3. Basic support is to maintain session continuity between nodes in the mobile network and nodes in the global Internet. The solution will have to meet the following requirements [TO BE DISCUSSED ON THE LIST - THIS IS A PROPOSITION - AT THAT POINT DON'T TAKE THINGS FOR GRANTED]: R1: The solution MUST provide permanent Internet connectivity and reachability to all nodes behind the MR R2: The solution MUST maintain continuous sessions between nodes behind the MR and arbitrary CNs after IP handover of the MR R3: All the potential configurations MUST be treated the same way (any number of subnets and MNN, nested mobile networks, multihomed mobile networks) R4: The solution MUST support LFNs, VMNs, and LMNs. R5: CNs and MNNs must comply with the requirements for IPv6 nodes defined in [IPv6-NODE] R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to MNNs) R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) R8: A VMN that gets attached to a link within the mobile network obtains an address on that link. R9: The solution MUST support nested mobile networks with any number of mobility levels R10: The solution MUST support multi-homed mobile network R10.1 : The solution MUST support mobile networks with multiple MRs R10.2: The solution MUST support MR with multiple interfaces R11: The solution MUST NOT prevent the use of existing protocols R11.1: The solution MUST allow MNNs to operate the "CN functionality" of Mobile IPv6 R11.2: The solution MUST support MIPv6-enabled VMNs and LMNs R11:3: The solution will ensure that mechanisms related to multi-homing (defined within other WGs in IETF) will be useful for NEMO" R12: The solution MUST support a large number of mobile networks R12: The solution MUST support a large number of CNs R13: The solution MUST support vertical handoff R14: The solution MUST support horizontal handoff R15: The solution SHOULD support fast handoff R16: The solution MUST support inter-domain mobility R17: The solution MUST support heterogeneous mobility R18: The solution MUST minimize control traffic draft-janneteau-nemo-requirements-00.txt: 4. General Requirements for Network Mobility Support The following requirements define the scope of a network mobility solution in NEMO: - Permanent connectivity and unicast session continuity: The solution MUST allow all nodes in the mobile network to be reachable via their permanent IP addresses, as well as maintain ongoing sessions as the mobile router changes its point of attachement within the topology. - Implementation in the IP layer: The solution MUST be implemented at the IP layer level. It MUST be transparent to any upper layer so that any upper layer protocol can run unchanged on top of an IP layer extended with network mobility support. - Mobile networks of any size: The solution MUST support mobile networks of any size. The solution MUST be applicable to small networks (e.g. a PAN comprising a few devices attached to a single mobile router) and large networks (e.g. several subnetworks with a very large numbers of MNNs). It is worth mention that NEMO WG will consider only leaf networks, i.e. mobile networks (irrespective of their size) that will not carry transit traffic. - No change to the Internet addressing and routing architecture: The solution MUST NOT require changes to the Internet addressing nor routing architecture. It MUST be independent of any routing protocols and MUST preserve route aggregation in the Internet. - Home equivalent operations: The solution MUST ensure transparent continuition of routing and management operations for a mobile router away from home. Especially, a mobile router running a routing protocol MUST be able to pursue advertising of its routes on its home network. Similarly, management operations such as Router Renumbering MUST be possible for a roaming mobile router. - Nested mobility: The solution MUST support nested mobility. It MUST support mobiles nodes visiting and leaving mobile networks, as well as mobile networks attaching to other mobile networks (nested mobile networks). The solution MUST no restrict in any way the number of levels in the hierarchy of nested mobile networks. - Multihoming: The solution MUST function for multihomed mobile networks. Cases of multihomed mobile networks include ones with a single mobile router that has multiple attachements to the Internet, as well as ones with multiples mobile routers to attach to the Internet. - Security: The solution MUST have its specific security issues fully addressed. - Co-existence with others protocols: - The solution MUST allow for co-existence with the AAA and access control frameworks (e.g. PANA). If extra mobile network-specific concerns need to be addressed in these frameworks, the NEMO WG will interact with related WGs. - The solution MUST allow for co-existence with QoS protocols, as well as Mobile IPv4 and Mobile IPv6 protocols. - Multicast session continuity: The solution SHOULD maintain ongoing multicast sessions of MNNs as the mobile router changes its point of attachement within the topology. 5. Additional Requirements for the Base Network Mobility Support The following requirements are placed on the base network mobility solution to be specified by the NEMO WG: - Base network mobility support for both IPv4 and IPv6: A solution MUST be provided for both IPv4 and IPv6 environments. Each one MUST base on Mobile IPv4 and Mobile IPv6 respectivelly. As such two different solutions MAY be defined. - Based on bi-directional Tunneling between MR and MR's Home Agent (MRHA tunnel): - The base network mobility solution for IPv6 MUST rely on the Mobile IPv6 bi-directional tunnel between the mobile router and its Home Agent. - The base network mobility solution for IPv4 MUST rely on the Mobile IPv4 bi-directional tunnel between the mobile router and its Home Agent. - No changes to Correspondent Nodes: The base solution for network mobility MUST NOT require any modification to MNN's Correspondent Nodes. - Network Mobility transparency to MNNs: The base solution for network mobility MUST NOT require any modification to any node in the mobile network (MNNs) but the mobile router. Especially, the base solution MUST provide network mobility management without the need for nodes behind the mobile router to be aware of the network's mobility and take part in NEMO Mobility Management. Upon a move, the mobile router MUST ensure continuity of the sessions of MNNs transparently to them. draft-kniveton-monet-requirements-00.txt: 3. Goals and Problem Scope The primary goal of the MONET work should be to support a technical solution which allows mobile network nodes (MNNs), to remain connected to the Internet and continuously reachable at all times while the mobile network they are attached to changes point of attachment. MNNs are both fixed (keeping the same address on the mobile network at all times), and mobile (entering and leaving the mobile network as they roam with respect to it). Support for both fixed and mobile MNNs is within the scope of this work. Secondary goals of the work can be to investigate the effects of network mobility on various aspects of internet communication such as routing protocol changes, implications of realtime traffic and fast handovers, optimizations. These should all support the primary goal of reachability for mobile network nodes. The MONET group is part of the IETF, and as such should be motivated by standardization work. Although mobile networks bring up many interesting research questions, these are only within the scope of this group insofar as they lead directly toward implementable solutions. Any further research topics should be offered to the IRTF Micromobility Design Team for additional review. Security is an important consideration, and efforts should be made to use existing solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges, such as securing route update information when a network changes points of attachment. These can be considered, as long as they do not conflict with the prior paragraph about research. 4. Non-goals and Excluded Scope The following goals are excluded: - host mobility. This is the problem domain of Mobile IP. - administration of the network - address assignment of hosts and links - network architectures - solutions for service discovery. These should be handled by traditional service discovery mechanisms 5. Protocols Internet Protocol The mobile networks we discuss are communicating using the Internet Protocol. Due to the advantages for mobility of IP version 6, it is desirable to spend most effort initially on an IPv6-based solution. However, it is also important to investigate how mobile networks can be enabled under IPv4 [8] conditions. To address this issue, it is desirable to either create a solution that could be utilized by both IPv6 and IPv4 with minimal (or no) changes, or subsequently undertake steps to adapt the solution to IPv4 or if that is not possible, create a new IPv4-based solution. Mobile IP The efforts of the Mobile IP working group have resulted in the Mobile IPv4 [7] and Mobile IPv6 [6] protocols, which have already solved the issue of host mobility. Since challenges to enabling mobile networks are vastly reduced by this work, it is proposed that the work in this group will adopt the methods for host mobility used in Mobile IP, and extend them in the simplest way possible to achieve its goals. MONET should be able to co-exist and not interfere with other mobility management protocols, such as Mobile IPv4, Mobile IPv6, Fast Handovers for Mobile IPv6 [3] and Mobile IPv4. Addressing and Configuration This topic is central to communication within a mobile network, so the changes to addressing models are a top concern for work within this group. Multicast There is some interest in discussing implications to multicast within the Monet scope. Service Discovery It may hold true that service discovery protocols need some modification in this type of environment, but at this point it is generally believed that existing solutions may be able to run on top of a mobile network without change. 6. Network Architecture Nesting It should be possible to create topologies within a mobile network of smaller subnetworks, and possibly attach other mobile networks in that topology. Although it is not fully clear how many layers of topology must be supported, or the complexity requirements of those nested networks, the goal is to support arbitrary levels of recursive networks, and only in the case where this is impractical and protocol concerns preclude this support should the solution impose restrictions on nesting. Transit Networks For the purposes of this work, we make a distinction between Transit Networks and Stub Networks. A transit network is one in which data would be forwarded between two endpoints outside of the network, so that the network itself simply serves as a transitional conduit for packet forwarding. A stub network, on the other hand, does not serve as a data forwarding path. Data on a stub network is destined for an endpoint located on that network. In order to keep minimal complexity, transit networks are outside of the scope of this group. Effort will be applied to solving communication for MNNs within a stub network only. Multi-homing Mobile network nodes can have multiple IP interfaces, therefore be multi-homed. On each interface they can have a different role within the scope of MONET. A multi-homed node might have a fixed interface which is always attached to the same network, and a mobile interface which changes its point of attachment. Such a node would be a fixed host on the former interface, and a mobile host on the latter interface. MONET protocol must be able to handle such multi-homing (multi-role) cases. Route Optimization Using overlay networks by using Mobile IP and MONET can create sub-optimal routing among communicating entities. Protocols can have route optimizations to remedy this problem by enabling entities to communicate their locations to each other for the shortest path. Such methods are defined for Mobile IPv4 and Mobile IPv6. Route optimization is an aspect of efficient communication that should be taken into consideration within MONET. Protocol End-points A MONET protocol should be used at least by home agents and mobile routers. This is the minimum set of entities that need to implement this protocol to enable mobile networks. MONET should be transparent to fixed routers and fixed hosts, therefore no implementation on these entities is needed. For optional route optimizations, mobile hosts and correspondent nodes can implement protocol extensions to utilize shortest paths in their communications. 7. Security Considerations The protocol signaling must be secured. The receiver of the protocol signaling must be able to verify the authenticity and the authorization of the sender to change routing information for the host(s)/network indicated. Unauthenticated and unauthorized nodes' request to change routing should not be permitted by the network. This is a very similar to the security requirement of Mobile IP. The difference is that when this requirement is not satisfied, the consequences would only effect a single mobile node in the case of Mobile IP, whereas a whole subnet, of possibly unlimited size, would be affected in the case of MONET. As such, stronger security mechanisms should be required by MONET. draft-soliman-monet-statement-00.txt: 3.1 Addressing The addressing mechanism required for MONETs needs to be carefully considered as it will affect some of the solutions for other issues associated with MONETs. For instance, allowing every MNN to acquire a topologically correct address would imply that the MNNs are aware of their movement within the topology, hence affecting the mechanism chosen for mobility management. Several possibilities exist for address configuration for MRs and the MNNs attached to it: - Stateful address autoconfiguration [DHCPv6] - Stateless address autoconfiguration [Multi-link subnets] and [Automatic prefix delegation] - IPv6 Router Renumbering The first 2 mechanisms can be used to configure the MRs ONLY or the entire subnet with topologically correct addresses. Such choice will affect the mobility management solution. For instance changing an MNNs address would require updating the CN and the HA. The choice of the addressing mechanism will need to be made based on the following factors: - Scalability: Can the chosen mechanism support a large number of MINTs ? This may depend on the size of the ‘fixedÂÂ’ network to which a MINT is attached. - Speed: How much time is required for address autoconfiguration to be completed ? Is it quick enough to support fast mobility ? - Mobility Frequency - Nested Mobility - Impacts on the Mobility management model: Does the chosen mechanism support the requirements for a scalable and secure mobility management solution ? - Multihoming: Each MR may be connected to multiple ISPs, each potentially providing different paths to the Internet. In addition, there may be multiple MRs in the MINT. - MINT definition: How are nodes in the MINT defined to belong to the MINT? In case of a wired MINT, it is physically defined. But a wireless MINT can begin to interfere with other geographically close wireless nodes, thus losing the definition of the MINT. A secure layer 2 is not assumed in this document, however, a secure layer 2 would certainly simplify this problem. 3.2 Mobility management This document assumes a MIP-based mobility management solution for MONETs. The current MIPv6 proposals provide limited levels of support for MONETs. Some solutions for the mobility scenarios are proposed in [HMIPv6] and [MONET]. However, some further investigation is needed to see whether these solutions are sufficient for the different MONET scenarios. Specifically, issues related to route optimisation need to be investigated further. [HMIPv6], [MOBRTR] and [MONET] provide different approaches for mobility management. In [HMIPv6] MNNs connected to MRs are aware of the MRs mobility, hence route optimisation is performed by the MNNs. On the other hand, [MONET] provides an extension to MIPv6 to allow MRs to send a prefix scoped BU to re-direct traffic for the entire prefix on behalf of the MNNs. [MOBRTR] assumes a bi-directional tunnel between the mobile router and the HA, over which routing protocols are tunnelled. In [HMIPv6], MNNs are aware of their mobility, while [MONET] and [MOBRTR] hide the networkÂÂ’s mobility from the MNNs. The choice of the Mobility management mechanism will depend on the following factors: - The size of the network vs BW efficiency and speed of mobility: Hiding the networkÂÂ’s mobility from the MNNs can reduce MIP signalling (e.g. one BU from the MR to the HA instead of many). What tradeoffs are needed to decide whether route optimisation (additional signalling) should be used? How does the size of the network in a wireless environment affect this decision? How do we treat a large network on a fast train (frequent handovers for many MNNs) compared to a MINT (eg. a PAN)? - Security and authorisation issues: BUs from MRs to CNs can cause some serious security threats for unauthorised MRs. Currently there is no specified solution for this problem. - Routing Protocol Issues: Shall MR of a MINT run a routing protocol ? What is the impact on the routing protocol running in the visited network ? Which protocol shall we run within large MONETs, how it interact with routing protocols running in visited network 3.4 Access control and security This chapter discusses the issues associated with access control within the Mobile Network. In this context, the spectrum of access control covers the MR – AR (fixed default router), MN – MR, and MN – MN relationships. Issues related to securing Neighbour Discovery may also be related. 3.4.1 Access control between AR and MR The access network at the ISP/operator must allow the connection of not only a single device but also a network behind that device. The access network can perform ingress filtering, access control lists etc. 3.4.2 Access control between MR and VMNs in a large MONET In the case of a large MONET providing Internet access for visiting nodes (VMNs) such as the train or ship case, this access will probably be controlled. This problem is very similar to what UNAP is attempting to solve. 3.4.3 Access control between nodes in a MINT Nodes in the MINT must trust each other. At least, MR must know who are the nodes that uses it as access router to the Internet. This is a question of who will pay for the packets. draft-sarikaya-nemo-archreqs-00.txt: 2.1 Generic architecture A new architectural entity called mobile router (MR) is needed to support network mobility. The mobile router (MR) connects the mobile network to the home link. In order to provide session continuity to the nodes in its network, MR needs a Mobile IP Home Agent (HA) [4]. MR may have several internal links to which local fixed (LFN) and mobile (LMN) nodes are connected (Figure 1). MR and HA together provide support for network mobility. HA MUST know that MR is not a basic mobile node but a router. +----+ | | | CN | | | +----+ | +------------------------+ | | | | | Internet | | | | | +------------------------+ | | +----+ +----+ +----+ | | Access | | | | | AR | Router | AR | | HA | | | | | | | +----+ +----+ +----+ foreign | link | home link | ------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--| | | +----+ | | internal link 1 | -------------------- | | | + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 1. A Mobile Network at its Home Link MR has an egress interface to its home link. MR MAY have several ingress interfaces to its internal links. The mobile network MAY move in its entirety and MAY attach itself to another link, e.g. foreign link. This situation is shown in Figure 2. MR MUST provide session continuity to all the nodes in its network. The correspondent node (CN) MAY be communicating with a mobile node (LMN) or with a fixed node (LFN). Base network mobility support MUST not require any changes to the correspondent nodes. +----+ | | | CN | | | +----+ | +------------------------+ | | | | | Internet | | | | | +------------------------+ | | +----+ +----+ +----+ | | Access | | | HA | | AR | Router | AR | | | | | | | | | +----+ +----+ +----+ foreign | link |home link | --------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--| | | +----+ | | internal link 1 | -------------------- | | | + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 2. Mobile Network at a Foreign Link A mobile router becomes the visiting mobile router (VMR) if it connects to another network in mobility. This is called nested mobility. An architecture for nested mobility is shown in Figure 3. A visiting mobile router (VMR) connects itself to the network in mobility by attaching to one of the links, e.g. local link 2. The visiting network in mobility may have its own links to which several fixed and mobile nodes are connected. HA1 is the home agent for MR and HA2 is for VMR. +----+ | | | CN | | | +----+ | +----+ +------------------------+ | HA | | | | 2| | | +----+ | Internet | | | | ------>| | +------------------------+ | | +----+ +----+ +----+ | | Access | | | | | AR | Router | AR | | HA | | | | | | 1| +----+ +----+ +----+ foreign | link |home link | ------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--| | +---+ | +----+ |LFN| | | | internal link 1 | |----| +---+ | -------------------- +---+ |-|VMR|-| | | | +---+ + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 3. Nested Mobility 2.2 Mobile IPv4 Considerations In Mobile IPv4, LMNs as well as MR MAY have a Foreign Agent (FA). The FA for LMNs MUST be on the internal link(s). MR MAY act as a FA to LMNs only if one of MRÂÂ’s interfaces directly connect to the internal links in the mobile network. Figure 4 shows the use of Mobile IPv4 when the network in mobility is on a foreign link. MR uses a local FA as its foreign agent while serving as FA to LMNs on the links attached to its interfaces. +----+ | | | CN | | | +----+ | +------------------------+ | | | | | Internet | | | | | +------------------------+ | | +----+ +----+ +----+ +----+ | | | | Access | | | | | FA | | AR | Router | AR | | HA | | mr| | | | | | | +----+ +----+ +----+ +----+ | foreign | link |home link | --------------- ------------------------- | | +----+ +----+ | MN | | | MR | Mobile Router +----+ |--|(FA)| | +----+ | |internal link 1 | -------------------- | | | + +-----+ +-----+ | | | | | +-----+ | | | | | | | | | LFN | | LMN | | LFN |--| | | | | | | | +-----+ +-----+ +-----+ | | internal link 2 Figure 4. Network mobility and Mobile IPv4 draft-ng-nemo-aaa-use-00.txt: 4. AAA Requirements From the usage scenario, we can identify the set of requirements described below. It must be noted that the requirements specified are by no means exhaustive. Since a NEMO solution has yet to be specified, these requirements are merely spelt out to generate further discussion within the NEMO working group. When a NEMO solution is eventually specified, AAA requirements by NEMO can be rapidly generated by building on top of this document. Ng, Tanaka Expires - April 2003 [Page 14] Internet-Draft Usage Scenario for AAA in NEMO October 2002 (1)The AAA servers MUST be able to share, or dynamically establish security associations with external authorities that are able to verify the credentials provided by the client. This requirement is a direct induction from the need for AAA servers of ARs/MRs to consult home AAA servers of mobile network nodes for verifications of client's credentials. Since these AAA servers usually belong to different administrative domains, it is necessary for AAA operations to provide a mechanism for AAA servers in two different domains to establish a security relationship between each other. (2)The VMN or MR MUST be able to provide complete, unforgeable credentials without having to contact its home agent. Since VMN or the MR would initiate network connectivity from a foreign domain, it is necessary for it to be able to provide credentials without having first granted access to NEMO resources. Thus it has to be able to provide credentials sufficient for verifications without the ability to contact any other nodes in its home domain. (3)Intermediate nodes MUST not be able to learn any information which may enable them to reconstruct and reuse the credentials. This requirement protects the AAA servers from replay attacks. It is necessary for the ARs/MRs to be able to process the credentials provided by the MRs/VMNs and yet unable to reconstruct the credentials independently at a later time, so that malicious AR/MR cannot use the credentials to launch a replay attack against the home AAA server. It also serves to protect the MRs/VMNs from the visited NEMO. In addition, to the above requirements, the following security requirements need to be considered. (4)AAA request and response operations between the ARs/MRs and the respective AAA servers MUST prevent eavesdropping. Any AAA operations MUST prevent the confidential information passed between the AR/MR and the corresponding AAA server from being known by eavesdroppers in the network. This is especially needed since NEMO typically operates in a wireless environment. (5)AAA request and response operations between the ARs/MRs and the respective AAA servers MUST NOT be vulnerable to denial-of- service attack. Ng, Tanaka Expires - April 2003 [Page 15] Internet-Draft Usage Scenario for AAA in NEMO October 2002 Since AAA operations typically entail cryptographic computations in the nodes involved, it is necessary to consider denial of service attacks by consuming CPU and memory resources to process illegitimate AAA requests, thereby preventing authentication of a legitimate mobile network node. (6)AAA request and response operations between the ARs/MRs and the respective AAA servers MUST NOT be vulnerable to man-in-the- middle attack. Since AAA operations may involve more than two nodes and operate over multiple hops, it MUST prevent communications between two legitimate nodes from being spoofed by an attacker in the middle. The following are the set of requirements for NEMO in considerations to AAA operations. (7)MR that supports attachment of VMN on its internal link SHOULD implement AAA client capability to be able to contact MR's home AAA server to check on credentials provided by the visiting nodes. It is generally not expected for MR to implement a full AAA server for scalability reasons. However, MR should be configured to consult an AAA server (possibly an AAA server from the MR's home domain) for verifications of credentials from the VMN. (8)MR that support attachment of VMN on its internal links SHOULD NOT change its AAA policy for the said VMNs during a continuous session, even when the MR has undergone a handover between AR of different administrative domains. It is expected for handover of MR should be transparent to VMNs behind the MR. Thus, a change in administrative domain of the AR should not be propagated to nodes behind the MR. From nemo-admin@nal.motlabs.com Sun Nov 3 08:54:59 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05839 for ; Sun, 3 Nov 2002 08:54:58 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA3Du5C18409; Sun, 3 Nov 2002 14:56:05 +0100 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA3DtFC18399 for ; Sun, 3 Nov 2002 14:55:16 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05174; Sun, 3 Nov 2002 05:55:06 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA3Dt2L15339; Sun, 3 Nov 2002 14:55:02 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] IPv6 prefix delegation To: Brian Haberman Cc: nemo@nal.motlabs.com In-Reply-To: "Your message with ID" <3DBD38C8.6030709@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 3 Nov 2002 14:52:01 +0100 (CET) > The original discussion of prefix delegation occurred on > the IPv6 WG mailing list. The zerouter BoF being held in Atlanta > is also going be interested in the subject. I can see where NEMO > needs to be involved as well. I actually don't see a Nemo need here for the basic stuff. But when Nemo looks at RO the issue is likely to come up, but hopefully IPv6 WG is done with specifying a standard for this before then since it is needed for IPv6 deployment in some cases. Erik From nemo-admin@nal.motlabs.com Sun Nov 3 08:57:14 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05853 for ; Sun, 3 Nov 2002 08:57:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA3Dx2C18435; Sun, 3 Nov 2002 14:59:02 +0100 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA3Dw7C18425 for ; Sun, 3 Nov 2002 14:58:07 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24244; Sun, 3 Nov 2002 05:57:56 -0800 (PST) Received: from localhost (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gA3DvpL15481; Sun, 3 Nov 2002 14:57:51 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] IPv6 prefix delegation To: "Pascal Thubert (pthubert)" Cc: Alexandru Petrescu , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 3 Nov 2002 14:54:50 +0100 (CET) > 3) Delegation - there we are -: The MR learns the prefixes on its > network from the HA. This could be done using DHCPv6 when it's an RFC, > or other (still debated at IPv6 without even MIP in the picture !!!) But this would be running DHCPv6 over the MR-HA tunnel. This is a bit different than running DHCPv6 to the ISPs access router to get a local prefix delegated, which is what folks are talking about in IPv6 WG. Erik From nemo-admin@nal.motlabs.com Sun Nov 3 21:25:35 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19458 for ; Sun, 3 Nov 2002 21:25:34 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA42M3C20649; Mon, 4 Nov 2002 03:22:03 +0100 Received: from dns1.nal.motlabs.com (node-c-3f09.a2000.nl [62.194.63.9]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gA42LXC20638 for ; Mon, 4 Nov 2002 03:21:34 +0100 Message-Id: <200211040221.gA42LXC20638@jessica.nal.motlabs.com> From: "GRAHAM MAKO" To: nemo@nal.motlabs.com MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: [nemo] STRICTLY CONFIDENTIAL. Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 03:21:19 Content-Transfer-Encoding: 7bit FROM:GRAHAM MAKO Good day, You may be surprised to receive this letter from me since you do not know me personally. The purpose of my introduction is that I am Graham Mako, the first son of Zuma Mako one of the most popular black farmer in Zimbabwe who was recently murdered in the land dispute in my country. I got your contact through network online hence decided to write you. Before the death of my father, he had taken me to Johannesburg to deposit the sum of USD$14.5 million (Fourteen million, Five Hundred thousand United States dollars), in one of the private security company, as he foresaw the looming danger in Zimbabwe this money was deposited in a box as gem stones to avoid much demurrage from security company. This amount was meant for the purchase of new machines and chemicals for the Farms and establishment of new farms in swaziland. This land problem came when Zimbabwean President Mr. Robert Mugabe introduced a new Land Act Reform wholly affecting the rich white farmers and some few black farmers, and this resulted to the killing and mob action by Zimbabwean war veterans and some lunatics in the society. In fact a lot of people were killed because of this Land reform Act for which my father was one of the victims. It is against this background that, I and my family fled Zimbabwe for fear of our lives and are currently staying in the Netherlands where we are seeking political asylum and moreso have decided to transfer my father’s money to a more reliable foreign account. since the law of Netherlands prohibits a refugee (asylum seeker) to open any bank account or to be involved in any financial transaction throughout the territorial zone of Netherlands, As the eldest son of my father, I am saddled with the responsibility of seeking a genuine foreign account where this money could be transferred without the knowledge of my government who are bent on taking everything we have got. The South African government seems to be playing along with them. I am faced with the dilemma of moving this amount of money out of South Africa for fear of going through the same experience in future, both countries have similar political history. As a businessman,I am seeking for a partner who I have to entrust my future and that of my family in his hands, I must let you know that this transaction is risk free. If you accept to assist me and my family, all I want you to do for me, is to make an arrangements with the security company to clear the consignment(funds) from their affiliate office here in the Netherlands as i have already given directives for the consignment to be brought to the Netherlands from South Africa.But before then all modalities will have to be put in place like change of ownership to the consignment and more importantly this money I intend to use for investment. I have two options for you. Firstly you can choose to have certain percentage of the money for nominating your account for this transaction. Or you can go into partnership with me for the proper profitable investment of the money in your country. Whichever the option you want, feel free to notify me. I have also mapped out 5% of this money for all kinds of expenses incurred in the process of this transaction.If you do not prefer a partnership I am willing to give you 10% of the money while the remaining 85% will be for my investment in your country. Contact me with the above E-mail address,while I implore you to maintain the absolute secrecy required in this transaction. NOTE:YOUR PROMPT RESPONSE WILL BE APPRECIATED. Thanks, GOD BLESS Yours Faithfully, Mr Graham Mako. From nemo-admin@nal.motlabs.com Mon Nov 4 01:49:42 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24796 for ; Mon, 4 Nov 2002 01:49:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA46p4C21772; Mon, 4 Nov 2002 07:51:04 +0100 Received: from porsta.cs.Helsinki.FI (root@porsta.cs.helsinki.fi [128.214.48.124]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA46o7C21762 for ; Mon, 4 Nov 2002 07:50:07 +0100 Received: from melkinpaasi.cs.Helsinki.FI (IDENT:jmanner@melkinpaasi.cs.Helsinki.FI [128.214.10.13]) by porsta.cs.Helsinki.FI (8.11.6/8.11.6) with ESMTP id gA46nr807223; Mon, 4 Nov 2002 08:49:54 +0200 From: Jukka MJ Manner To: James Kempf cc: Thierry Ernst , Subject: Re: [nemo] Terminology Update In-Reply-To: <01f401c281cb$6cce5180$3c6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 4 Nov 2002 08:49:51 +0200 (EET) Hi, I am the editor of the terminology draft and at this stage I thought that adding some _basic_ terms about mobile networks was needed. I didn't get any complaints about it on the mailing list, so I chose to add "Mobile network", "Mobile router" and MNN with some new wording into the Seamoby draft - the basic components of your figure 1. Most of the other terms are already in our draft or defined elsewhere in the IETF. The prefix terms could be added, if we changed the wording a bit to reflect a more general concept. Some of the other terms are directly associated with mobile networks and I left them at this stage. Regards, Jukka On Fri, 1 Nov 2002, James Kempf wrote: > Thierry, > > The terminology draft is just in Seamoby because the authors couldn't find any > other mobility related group that wanted to sponsor it. It actually started out > in MANET. I don't think we need get into a turf battle about which WG has > control over the draft. If you want, we can move the terminology draft to NEMO. > > The real issues in my mind are whether the NEMO group feels comfortable enough > with the state of its terminology discussion that it wants to incorporate the > terminology, since we would like to take the terminology draft to last call > early next year. If not, then we should keep the NEMO terminology separate. > Additionally, we need to ask whether it makes sense to include network mobility > related terminology into the same draft. > > It sounds from your note that the terminology is intertwined with the > requirements, and thus the group is not yet ready to finalize. As for the > usefulness of merging, it sounds as if you feel it would be useful. Perhaps we > ought to wait until we are ready to take the terminology draft to last call, > then check back? > > jak > > ----- Original Message ----- > From: "Thierry Ernst" > To: > Cc: > Sent: Friday, November 01, 2002 7:49 AM > Subject: Re: [nemo] Terminology Update > > > > > > Hi James, > > > > From: "James Kempf" > > > As you may be aware, the Seamoby WG currently has a WG draft on its charter > that > > > consolidates mobility related terms in the IETF. The draft is meant to be a > way > > > for draft authors of mobility-related drafts to avoid the extensive > terminology > > > section at the beginning, and provide a reference to normalize references to > > > mobility-related terms. > > > > > > Would you be interested in merging your terminology draft in with the > Seamoby > > > draft? I think it would be extremely useful to have the mobile network terms > > > together with the rest of the mobility-related terms. > > > > Personally, I'm not against the idea. > > > > I think there are terms that would be useful to be merged. High levels > > NEMO terms like "mobile network", "mobile router" and other like > > that. And some terms in your draft are useful for us too. But, as you > > know, NEMO is chartered to produce a RFC about terminology and > > requirements. The definitions are in a way implying some de facto > > requirements. So, how to draw the line between the 2 ? > > > > What I'm not comfortable with is that the draft you are speaking about > > is a draft-seamoby-... From a NEMO stand point, it's important for us > > to keep the control on the definition of terms we use/need. So, if we > > come to merge the drafts, how to do so ? > > > > Thierry. > > > > > > > > > > > From nemo-admin@nal.motlabs.com Mon Nov 4 02:45:10 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05485 for ; Mon, 4 Nov 2002 02:45:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA47l1C21951; Mon, 4 Nov 2002 08:47:01 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA47koC21941 for ; Mon, 4 Nov 2002 08:46:50 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gA47lPFv000543 for ; Sun, 3 Nov 2002 23:47:25 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1309 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] Draft updates submitted Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 03 Nov 2002 23:46:48 -0800 Content-Transfer-Encoding: 7bit As part of the requirements discovery process, Alper and I have resubmitted our former requirements draft with some minor changes, so that it is now current. You can find it at: http://www.mobilerouter.org/draft-kniveton-monet-requirements-01.txt I have also resubmitted the Mobile Router Tunneling Protocol, our basic support draft, with some corrections and updates. This one is at http://www.mobilerouter.org/draft-kniveton-mobrtr-03.txt -TJ From nemo-admin@nal.motlabs.com Mon Nov 4 03:08:21 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05789 for ; Mon, 4 Nov 2002 03:08:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA48A2C22062; Mon, 4 Nov 2002 09:10:02 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA489uC22047 for ; Mon, 4 Nov 2002 09:09:56 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.9.3/8.9.3) with ESMTP id KAA12994 for ; Mon, 4 Nov 2002 10:09:55 +0200 (EET) Received: from ele4114 (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with SMTP id KAA21623 for ; Mon, 4 Nov 2002 10:09:52 +0200 (EET) Message-ID: <010001c283d9$f7468110$725ebc82@ELE4114.ele.vtt.fi> From: "=?iso-8859-1?B?UGVra2EgUOTka2v2bmVu?=" To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Subject: [nemo] IPv6 prefix delegation Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 4 Nov 2002 10:12:49 +0200 Content-Transfer-Encoding: 8bit Alex, thanks for the comments. Many things got sorted out. -----Original Message----- From: Alexandru Petrescu To: Pekka Pääkkönen Cc: nemo@nal.motlabs.com Date: 2. marraskuuta 2002 15:55 Subject: Re: [nemo] IPv6 prefix delegation >Pekka, here are my thoughts. The issues may indeed look tangled, but >maybe there's a simple way out of this if we consider them from a >Mobile IP standpoint. > >"Pekka Pääkkönen" writes: >> OK. So a MNP will initially be assigned to the NEMO-network and the >> MR just has to know that a certain MNP has been assigned to the >> NEMO-network to which the MR is attached to? > >Yes, exactly. The nice thing about MNP is that we can also call it >Home Prefix (or HP). That is very stable and never changes. The MNP >on the mobile network will move anywhere around the Internet, and the >HA will redirect traffic to its current position (the CoA of the MR). > >Contrast this to the ephemerality of the prefix obtained via prefix >delegation. If I understand correctly what was said until now, it is >that a mobile link will arrive in a visited domain and will obtain a >prefix valid in that visited network. So the mobile link can stay >there as long as it wants and be linked to the Internet. Once it >moves away, the mobile link must get rid of that delegated prefix, >since it is valid only in the respective visited network. > >> Consider that we have a NEMO-network which has multiple MRs on the >> top level (TLMRs). > >You've just enunciated the multi-homing aspect. The NEMO-network can >be multi-homed, either with two interfaces on the MR, or with several >TLMRs, as the definition goes. I do not know how this works exactly, >but it should work somehow. > >> Each MR has to know the MNP which has been assigned to the >> NEMO-network. Aren't there real problems related to this use case >> since each TLMR has to be informed somehow the MNP which has been >> assigned to the NEMO-network? > >The way that TLMR1 knows about MNP, is the same way that TLMR2 knows >about MNP. > So it is assumed that TLMR1 and TLMR2 have the same HA from which they get a MNP? I was considering a case when these TLMRs would have different HAs and a different MNP at each HA to be delegated for mobile networks. In that case there might be problems (also with the security issues) in delegating a MNP to the mobile network? >> Or does NEMO-WG not consider the initial formation of the >> NEMO-network and just assumes that a MNP will somehow be assigned to >> a NEMO-network? > >I think that the NEMO-network (new term Thierry!) is not formed >dynamically by an MR joining a link of LFNs. Both MR and LFNs have >the same home, from the start. > >I think that many people see the MR permanently attached to the mobile >link, thus the MNP is pre-configured on the MR. Something like taking >a "slice" of a fixed home network and moving it away. > >In Mobile IPv6, there's the concept of Home Agent discovery, where an >MH discovers its HA and then auto-configures a Home Address for >itself. > >NEMO goes from MH to MR, so this could be extended to an MR like this: >MR first does what MH does (discovers HA and auto-configures a Home >Address); and configures a bidir MRHA tunnel to its HA; and then >obtains from its HA an MNP (mobile network prefix, or the home prefix) >for its mobile link. Maybe _this_ could be done with Prefix >Delegation. The goal of this mechanism would be to not have the MNP >preconfigured on the MR, but obtained dynamically from its HA. This >MNP would continue to stay stable every time MR changes its CoA. > >This is different from MR using Prefix Delegation to obtain a new >prefix (CoP) each time it moves. > >Or maybe this is what you wanted to say. > >My humble oppinion, > >Alex > > From nemo-admin@nal.motlabs.com Mon Nov 4 09:38:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14537 for ; Mon, 4 Nov 2002 09:38:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4Ed9C23852; Mon, 4 Nov 2002 15:39:10 +0100 Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4EcbC23842 for ; Mon, 4 Nov 2002 15:38:40 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id gA4EcSd14376; Mon, 4 Nov 2002 08:38:28 -0600 (CST) Message-ID: <3DC686A0.2080602@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: Thierry Ernst , nemo@nal.motlabs.com Subject: Re: [nemo] my list of compiled requirements (was: Launching Requirement Discussion) References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> Content-Type: multipart/alternative; boundary="------------060300010202010408060205" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 08:39:28 -0600 --------------060300010202010408060205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello Alex, Thanks for compiling the list. All others except draft-ng-nemo-aaa-use-00.txt state requirements for the base nemo solution, however this one does not, IMHO. draft-ng-nemo-aaa-use does not either state security requirements, it probably deserves to be treated separately on its own, much like the case in Mobile IP. Regards, Alexandru Petrescu wrote: >Thierry Ernst writes: > > >>It seems that we have a couple of new/updated drafts to discuss the >>requirements, but I haven't seen an announcement from all the authors, >>so I'm not sure about what is on the table. >> >>So far, I have seen: >> draft-ernst-nemo-requirements-00.txt >> draft-ng-nemo-aaa-use-00.txt >> draft-janneteau-nemo-requirements-00.txt >> draft-sarikaya-nemo-archreqs-00.txt >> >> > >I've been compiling recently the following drafts: > > draft-ernst-nemo-requirements-00.txt: > draft-janneteau-nemo-requirements-00.txt: > draft-kniveton-monet-requirements-00.txt: > draft-soliman-monet-statement-00.txt: > draft-sarikaya-nemo-archreqs-00.txt: > draft-ng-nemo-aaa-use-00.txt: > > > --behcet > > --------------060300010202010408060205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Alex,
  Thanks for compiling the list.
All others except 
draft-ng-nemo-aaa-use-00.txt
state requirements for the base nemo solution, however this one does not, IMHO. draft-ng-nemo-aaa-use does not either state security requirements, it probably deserves to be treated separately on its own, much like the case in Mobile IP.

Regards,

Alexandru Petrescu wrote:
Thierry Ernst <ernst@sfc.wide.ad.jp> writes:
  
It seems that we have a couple of new/updated drafts to discuss the
requirements, but I haven't seen an announcement from all the authors,
so I'm not sure about what is on the table.

So far, I have seen:
      draft-ernst-nemo-requirements-00.txt 
      draft-ng-nemo-aaa-use-00.txt 
      draft-janneteau-nemo-requirements-00.txt 
      draft-sarikaya-nemo-archreqs-00.txt 
    

I've been compiling recently the following drafts:

  draft-ernst-nemo-requirements-00.txt:
  draft-janneteau-nemo-requirements-00.txt:
  draft-kniveton-monet-requirements-00.txt:
  draft-soliman-monet-statement-00.txt:
  draft-sarikaya-nemo-archreqs-00.txt:
  draft-ng-nemo-aaa-use-00.txt:

--behcet

--------------060300010202010408060205-- From nemo-admin@nal.motlabs.com Mon Nov 4 10:05:37 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16342 for ; Mon, 4 Nov 2002 10:05:35 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4F72C25990; Mon, 4 Nov 2002 16:07:02 +0100 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4F6AC25966 for ; Mon, 4 Nov 2002 16:06:11 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15877; Mon, 4 Nov 2002 10:03:40 -0500 (EST) Message-Id: <200211041503.KAA15877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@nal.motlabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [nemo] I-D ACTION:draft-sarikaya-nemo-archreqs-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 10:03:39 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Architectural Requirements for Base Network Mobility Using Bidirectional Tunneling Author(s) : B. Sarikaya Filename : draft-sarikaya-nemo-archreqs-00.txt Pages : 8 Date : 2002-11-1 While traditional mobility support deals with providing continuous Internet connectivity to mobile hosts (host mobility support), network mobility support means dealing with situations where an entire network changes its point of attachment to the Internet. Such a network is called a mobile network. This document identifies architectural entities of network mobility and nested network mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sarikaya-nemo-archreqs-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-sarikaya-nemo-archreqs-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-sarikaya-nemo-archreqs-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: <2002-11-1143000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-sarikaya-nemo-archreqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-sarikaya-nemo-archreqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1143000.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@nal.motlabs.com Mon Nov 4 10:06:42 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16723 for ; Mon, 4 Nov 2002 10:06:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4F81C26014; Mon, 4 Nov 2002 16:08:01 +0100 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4F7WC26003 for ; Mon, 4 Nov 2002 16:07:33 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16185; Mon, 4 Nov 2002 10:05:03 -0500 (EST) Message-Id: <200211041505.KAA16185@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: nemo@nal.motlabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [nemo] I-D ACTION:draft-janneteau-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 10:05:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements for NEtwork MObility Support Author(s) : C. Janneteau et al. Filename : draft-janneteau-nemo-requirements-00.txt Pages : 6 Date : 2002-11-1 This draft introduces some scenarios for mobile networks, i.e. IP networks that change their points of attachment to the Internet, and proposes requirements for network mobility support in the context of the NEMO working group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-janneteau-nemo-requirements-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-janneteau-nemo-requirements-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-janneteau-nemo-requirements-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: <2002-11-1143256.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-janneteau-nemo-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-janneteau-nemo-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1143256.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-admin@nal.motlabs.com Mon Nov 4 10:55:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19250 for ; Mon, 4 Nov 2002 10:55:56 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4Fv2C26285; Mon, 4 Nov 2002 16:57:03 +0100 Received: from postfix2-2.free.fr (postfix2-2.free.fr [213.228.0.140]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4Fu4C26274 for ; Mon, 4 Nov 2002 16:56:04 +0100 Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-2.free.fr (Postfix) with ESMTP id CC65E5F704; Mon, 4 Nov 2002 16:56:03 +0100 (CET) Received: by imp1-2.free.fr (Postfix, from userid 33) id 6831B87368; Mon, 4 Nov 2002 16:55:58 +0100 (CET) To: pekka.paakkonen@vtt.fi Subject: Re: [nemo] IPv6 prefix delegation Message-ID: <1036425358.3dc6988e365ec@imp.free.fr> From: petrescu@free.fr Cc: nemo@nal.motlabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.231.104.203 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 16:55:58 +0100 (CET) Content-Transfer-Encoding: 8bit >>> Each MR has to know the MNP which has been assigned to the >>> NEMO-network. Aren't there real problems related to this use case >>> since each TLMR has to be informed somehow the MNP which has been >>> assigned to the NEMO-network? >> >>The way that TLMR1 knows about MNP, is the same way that TLMR2 knows >>about MNP. > So it is assumed that TLMR1 and TLMR2 have the same HA from which they get a > MNP? Yes, I guess so. This would not prevent to have 3 MNPs and 2 MRs though, but still the same HA. > I was considering a case when these TLMRs would have different HAs and a > different MNP at each HA > to be delegated for mobile networks. In that case there might be problems > (also with the security issues) > in delegating a MNP to the mobile network? Aha... I see. This reminds me about requirements, again. Let me explain why. In the Yokohama monet minutes, there's a warning inviting to take care when one multi-homed PAN-mobile network visits a car-mobile network and visits a ferry-mobile network, not to give access to all users in the boat through that person's multihomed mobile router. Put differently, maybe we can imagine a requirement, where it is stated that a zombie MR (w/o its mobile link) can not wander around, find a mobile link that already has a TLMR, and then offer its services to the mobile link such as the mobile link accepts a new TLMR that has a different HA than the original TLMR. Maybe we can find a phrase to express that this scenario is not in the goals. In all cases, the multi-homing requirements should describe what are the goals of multi-homing and what are not its goals. Alex From nemo-admin@nal.motlabs.com Mon Nov 4 12:40:48 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24545 for ; Mon, 4 Nov 2002 12:40:46 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4Hg2C26744; Mon, 4 Nov 2002 18:42:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA4HfgC26733 for ; Mon, 4 Nov 2002 18:41:42 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16776; Mon, 4 Nov 2002 09:41:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA4HfV003058; Mon, 4 Nov 2002 09:41:31 -0800 X-mProtect: <200211041741> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.111, claiming to be "kniveton.com") by darkstar.iprg.nokia.com smtpdjhDewc; Mon, 04 Nov 2002 09:41:29 PST Message-ID: <3DC6B149.4DA5D91@kniveton.com> From: "T.J. Kniveton" Organization: NOKIA X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Christophe Janneteau CC: nemo@nal.motlabs.com Subject: Re: [nemo] Draft updates submitted References: <3DC67033.4541CD17@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 09:41:29 -0800 Content-Transfer-Encoding: 7bit Oops, I typed these by hand and forgot the "specs/" part. At least I know someone is trying to read them. :-) Correct URLS are: http://www.mobilerouter.org/specs/draft-kniveton-monet-requirements-01.txt http://www.mobilerouter.org/specs/draft-kniveton-mobrtr-03.txt Christophe Janneteau wrote: > > Hi TJ, > > I cannot manage to access the drafts on this site...but I manage to > access the site. http://www.mobilerouter.org/, Nice name btw :-) > > Christophe > > "T.J. Kniveton" wrote: > > > > As part of the requirements discovery process, Alper and I have resubmitted > > our former requirements draft with some minor changes, so that it is now > > current. You can find it at: > > > > http://www.mobilerouter.org/draft-kniveton-monet-requirements-01.txt > > > > I have also resubmitted the Mobile Router Tunneling Protocol, our basic > > support draft, with some corrections and updates. This one is at > > http://www.mobilerouter.org/draft-kniveton-mobrtr-03.txt > > > > -TJ From nemo-admin@nal.motlabs.com Tue Nov 5 02:21:36 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06115 for ; Tue, 5 Nov 2002 02:21:34 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA57N4C29769; Tue, 5 Nov 2002 08:23:05 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA57M1C29759 for ; Tue, 5 Nov 2002 08:22:01 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gA57MWFv002404; Mon, 4 Nov 2002 23:22:32 -0800 (PST) User-Agent: Microsoft-Entourage/10.0.0.1309 Subject: Re: [nemo] my list of compiled requirements (was: Launching Requirement Discussion) From: "T.J. Kniveton" To: Alexandru Petrescu , Thierry Ernst CC: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 04 Nov 2002 23:21:52 -0800 Content-Transfer-Encoding: 7bit On 11/2/02 6:25 AM, "Alexandru Petrescu" wrote: > Thierry Ernst writes: >> It seems that we have a couple of new/updated drafts to discuss the >> requirements, but I haven't seen an announcement from all the authors, >> so I'm not sure about what is on the table. >> >> So far, I have seen: >> draft-ernst-nemo-requirements-00.txt >> draft-ng-nemo-aaa-use-00.txt >> draft-janneteau-nemo-requirements-00.txt >> draft-sarikaya-nemo-archreqs-00.txt > > I've been compiling recently the following drafts: > > draft-ernst-nemo-requirements-00.txt: > draft-janneteau-nemo-requirements-00.txt: > draft-kniveton-monet-requirements-00.txt: > draft-soliman-monet-statement-00.txt: > draft-sarikaya-nemo-archreqs-00.txt: > draft-ng-nemo-aaa-use-00.txt: I didn't see any items from the last two drafts on your list. Were they left off? > > Here's the copy paste list I've been working with. > > draft-ernst-nemo-requirements-00.txt: > [...] This list serves as a good union of all the ideas of the different drafts. Now, we would like to do a bit more detailed analysis. That is to say, what are the parts of this list that are in common with all, or many drafts, and what are the parts that only come from one source? In this way, we can narrow down the points of discussion to only the items which may be controversial or not widespread. This is a long task, but we can start with the core of requirements (as you have pretty much done here) that are commonly understood, and then explore the edges to see what are the more active discussion points regarding edge subjects in basic support (we have already had some earlier, on the list). By the time we are at the IETF in a couple of weeks, we can hopefully whittle down the topics of conversation to a big list of agreed points, and some salient points for fine adjustment. TJ From nemo-admin@nal.motlabs.com Tue Nov 5 12:05:49 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29458 for ; Tue, 5 Nov 2002 12:05:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5H66C00685; Tue, 5 Nov 2002 18:06:07 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5H5HC00673 for ; Tue, 5 Nov 2002 18:05:18 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 3882E5D084; Wed, 6 Nov 2002 02:05:03 +0900 (JST) Message-Id: <20021106.020502.111932496.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: tj@kniveton.com From: Thierry Ernst X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Draft NEMO Agenda Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 02:05:02 +0900 (JST) Content-Transfer-Encoding: 7bit Dear all, Here is a tentative agenda for our meeting. We have 2 hours, and we would like to make a good use of that to progress forward the requirements. WEDNESDAY, November 20, 2002 1530-1730 Afternoon Sessions II o NEMO WG tentative agenda - length 2h. - 05min Agenda Bashing (Chairs) - 15min Charter review - 40min Requirements for Basic Support Report of analysis and comparison (commonalities and divergences) draft-ernst-nemo-requirements-00.txt draft-kniveton-monet-requirements-00.txt draft-ng-nemo-aaa-use-00.txt draft-janneteau-nemo-requirements-00.txt draft-sarikaya-nemo-archreqs-00.txt - 15min Terminology Update draft-ernst-nemo-terminology-00.txt - 15min Threat Analysis ? - 15min Basic support issues - 15min Future Steps and Milestones We don't already have input for the Threat Analysis not for the Basic Support issues, so if any one has something to say about this, that would be the right moment to start. For Basic Support, we know that we are going to set up a biderectional tunnel. So, I wonder if anyone of you had already some thoughts about the potential issues it may cause ? Thierry. From nemo-admin@nal.motlabs.com Tue Nov 5 12:25:52 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00424 for ; Tue, 5 Nov 2002 12:25:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5HR1C00791; Tue, 5 Nov 2002 18:27:01 +0100 Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5HQYC00779 for ; Tue, 5 Nov 2002 18:26:34 +0100 Received: from imp3-1.free.fr (imp3-1.free.fr [213.228.0.28]) by postfix4-1.free.fr (Postfix) with ESMTP id ACE42BCE8; Tue, 5 Nov 2002 19:26:29 +0100 (CET) Received: by imp3-1.free.fr (Postfix, from userid 33) id EE3E0FA72; Tue, 5 Nov 2002 18:32:52 +0100 (MET) To: tj@kniveton.com Message-ID: <1036517572.3dc800c4be6f0@imp.free.fr> From: petrescu@free.fr Cc: nemo@nal.motlabs.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.231.104.203 Subject: [nemo] (no subject) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 05 Nov 2002 18:32:52 +0100 (CET) Content-Transfer-Encoding: 8bit >> I've been compiling recently the following drafts: >> >> draft-ernst-nemo-requirements-00.txt: >> draft-janneteau-nemo-requirements-00.txt: >> draft-kniveton-monet-requirements-00.txt: >> draft-soliman-monet-statement-00.txt: >> draft-sarikaya-nemo-archreqs-00.txt: >> draft-ng-nemo-aaa-use-00.txt: > > I didn't see any items from the last two drafts on your list. Were > they left off? No no, I've had copied and pasted in the long reqs list, the sections 2.1 and 2.2 of draft-sarikaya and section 4 of draft-ng. In the short unified list of requirements (a shorter email subjected "CN modifications") I've put the entire paragraph "architectural considerations" from draft-sarikaya and "co-existence with AAA" from draft-janneteau and a phrase saying "detailed AAA reqs" from draft-ng. A side note, I've built the unified short list by starting with the first draft (draft-ernst) and adding new items. With each new draft that I scanned, many things were already present somehow in the unified short list, but expressed sometimes differently. There's much interpretation from my part on this; that's why I called it mine. > Now, we would like to do a bit more detailed analysis. That is to > say, what are the parts of this list that are in common with all, or > many drafts, and what are the parts that only come from one source? > [...] Yes, exactly. Alex From nemo-admin@nal.motlabs.com Tue Nov 5 12:26:49 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00464 for ; Tue, 5 Nov 2002 12:26:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5HS1C00819; Tue, 5 Nov 2002 18:28:01 +0100 Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5HRLC00809 for ; Tue, 5 Nov 2002 18:27:22 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id gA5HR9Q17738; Tue, 5 Nov 2002 11:27:13 -0600 (CST) Message-ID: <3DC7FFA7.7050807@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J. Kniveton" CC: Alexandru Petrescu , Thierry Ernst , nemo@nal.motlabs.com Subject: Re: [nemo] my list of compiled requirements (was: Launching Requirement Discussion) References: Content-Type: multipart/alternative; boundary="------------070901080906000409020209" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 05 Nov 2002 11:28:07 -0600 --------------070901080906000409020209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit TJ, T.J. Kniveton wrote: >On 11/2/02 6:25 AM, "Alexandru Petrescu" wrote: > > > >>Thierry Ernst writes: >> >> >>>It seems that we have a couple of new/updated drafts to discuss the >>>requirements, but I haven't seen an announcement from all the authors, >>>so I'm not sure about what is on the table. >>> >>>So far, I have seen: >>> draft-ernst-nemo-requirements-00.txt >>> draft-ng-nemo-aaa-use-00.txt >>> draft-janneteau-nemo-requirements-00.txt >>> draft-sarikaya-nemo-archreqs-00.txt >>> >>> >>I've been compiling recently the following drafts: >> >>draft-ernst-nemo-requirements-00.txt: >>draft-janneteau-nemo-requirements-00.txt: >>draft-kniveton-monet-requirements-00.txt: >>draft-soliman-monet-statement-00.txt: >>draft-sarikaya-nemo-archreqs-00.txt: >>draft-ng-nemo-aaa-use-00.txt: >> >> > >I didn't see any items from the last two drafts on your list. Were they left >off? > > > > >>Here's the copy paste list I've been working with. >> >>draft-ernst-nemo-requirements-00.txt: >>[...] >> >> > >This list serves as a good union of all the ideas of the different drafts. >Now, we would like to do a bit more detailed analysis. That is to say, what >are the parts of this list that are in common with all, or many drafts, and >what are the parts that only come from one source? In this way, we can >narrow down the points of discussion to only the items which may be >controversial or not widespread. This is a long task, but we can start with >the core of requirements (as you have pretty much done here) that are >commonly understood, and then explore the edges to see what are the more >active discussion points regarding edge subjects in basic support (we have >already had some earlier, on the list). > >By the time we are at the IETF in a couple of weeks, we can hopefully >whittle down the topics of conversation to a big list of agreed points, and >some salient points for fine adjustment. > >TJ > > > > Agreed. But the point is that >draft-ng-nemo-aaa-use-00.txt > is on the AAA aspect not on the solution to the base mobility which is expected to be an IP layer solution. I do not think that these two can be stated in a single draft. That's why I suggested separating the AAA use draft from the others. Regards, -- Behcet --------------070901080906000409020209 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit TJ,

T.J. Kniveton wrote:
On 11/2/02 6:25 AM, "Alexandru Petrescu" <petrescu@crm.mot.com> wrote:

  
Thierry Ernst <ernst@sfc.wide.ad.jp> writes:
    
It seems that we have a couple of new/updated drafts to discuss the
requirements, but I haven't seen an announcement from all the authors,
so I'm not sure about what is on the table.

So far, I have seen:
      draft-ernst-nemo-requirements-00.txt
      draft-ng-nemo-aaa-use-00.txt
      draft-janneteau-nemo-requirements-00.txt
      draft-sarikaya-nemo-archreqs-00.txt
      
I've been compiling recently the following drafts:

draft-ernst-nemo-requirements-00.txt:
draft-janneteau-nemo-requirements-00.txt:
draft-kniveton-monet-requirements-00.txt:
draft-soliman-monet-statement-00.txt:
draft-sarikaya-nemo-archreqs-00.txt:
draft-ng-nemo-aaa-use-00.txt:
    

I didn't see any items from the last two drafts on your list. Were they left
off?


  
Here's the copy paste list I've been working with.

draft-ernst-nemo-requirements-00.txt:
[...]
    

This list serves as a good union of all the ideas of the different drafts.
Now, we would like to do a bit more detailed analysis. That is to say, what
are the parts of this list that are in common with all, or many drafts, and
what are the parts that only come from one source? In this way, we can
narrow down the points of discussion to only the items which may be
controversial or not widespread. This is a long task, but we can start with
the core of requirements (as you have pretty much done here) that are
commonly understood, and then explore the edges to see what are the more
active discussion points regarding edge subjects in basic support (we have
already had some earlier, on the list).

By the time we are at the IETF in a couple of weeks, we can hopefully
whittle down the topics of conversation to a big list of agreed points, and
some salient points for fine adjustment.

TJ
Agreed. But the point is that 
draft-ng-nemo-aaa-use-00.txt
is on the AAA aspect not on the solution to the base mobility which is expected to be an IP layer solution. I do not think that these two can be stated in a single draft. That's why I suggested separating the AAA use draft from the others.

Regards,

-- 
Behcet

--------------070901080906000409020209-- From nemo-admin@nal.motlabs.com Tue Nov 5 13:01:53 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02542 for ; Tue, 5 Nov 2002 13:01:52 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5Hw1C01017; Tue, 5 Nov 2002 18:58:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5HvuC01007 for ; Tue, 5 Nov 2002 18:57:56 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gA5HvnhL009716; Tue, 5 Nov 2002 10:57:49 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA29621; Tue, 5 Nov 2002 10:57:49 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id gA5Hvii06456; Tue, 5 Nov 2002 11:57:45 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id D9FAF2EC86; Tue, 5 Nov 2002 18:57:43 +0100 (CET) Message-ID: <3DC80697.32D78559@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst Cc: nemo@nal.motlabs.com, tj@kniveton.com Subject: Re: [nemo] Draft NEMO Agenda References: <20021106.020502.111932496.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 05 Nov 2002 18:57:43 +0100 Content-Transfer-Encoding: 7bit Hi Thierry and all, Thierry Ernst wrote: > For Basic Support, we know that we are going to set up a biderectional > tunnel. So, I wonder if anyone of you had already some thoughts about > the potential issues it may cause ? Our draft do attempts to list some issues around the bidirectional tunnel approach. Especially it discusses the following issues: - auto-configuration of CoA by MR - use of Link-local addresses for regular routing versus the need of a globally routable Home Address - ICMP redirect mechanism from BR to HA - and some others... Christophe. From nemo-admin@nal.motlabs.com Tue Nov 5 13:24:37 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03567 for ; Tue, 5 Nov 2002 13:24:36 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5IQ2C03233; Tue, 5 Nov 2002 19:26:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA5IPvC03223 for ; Tue, 5 Nov 2002 19:25:57 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21367; Tue, 5 Nov 2002 10:25:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA5IPgd32320; Tue, 5 Nov 2002 10:25:42 -0800 X-mProtect: <200211051825> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPDrf8B; Tue, 05 Nov 2002 10:25:39 PST Message-ID: <3DC80D24.EDAFA2FE@iprg.nokia.com> 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: Thierry Ernst CC: nemo@nal.motlabs.com, tj@kniveton.com Subject: Re: [nemo] Draft NEMO Agenda References: <20021106.020502.111932496.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 05 Nov 2002 10:25:40 -0800 Content-Transfer-Encoding: 7bit Hi all, Thierry Ernst wrote: > For Basic Support, we know that we are going to set up a biderectional > tunnel. So, I wonder if anyone of you had already some thoughts about > the potential issues it may cause ? three issues that we need to consider. we came across them when we implemented draft-kniveton-mobrtr-02.txt. 1. there is no way for the Home Agent to figure out which mobile router is allowed which mobile prefix. when it receives a binding update with the 'R' bit set, it creats a static route for the prefix to point to the home address of the MN. one solution is to have a mapping (created manually at the home agent) between mobile routers and their prefixes. the Home Agent checks this mapping before accepting the binding updates from the mobile router. we have implemented this currently. in base MIPv6, the security association between the HA and the MN is tied to the home address of the MN. if the MN configures a new home address, it has to create a new security association for that home address. if we can somehow associate the prefix and the home address of the mobile router with the security association, we can easily solve this. otherwise we have to come up with something new. 2. the packet format (if we assume the bidirectional tunnel is protected by IPsec). we werent sure which one to follow. IPv6 hdr (src=MR_CoA, dst=HA) Dst Opts hdr (MR_HoA) IPsec hdr IPv6 hdr (src=X, dst=CN) Payload or IPv6 hdr (src=MR_CoA, dst=HA) IPsec hdr IPv6 hdr (src=X, dst=CN) Payload where X is a node in the mobile network. MR_HoA and MR_CoA are the home address and care-of address of the mobile router respectively. if we go with the concepts described in draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, which assumes we can change the tunnel gateway address (MR_CoA) as the MR moves, we can have the second format (which eliminates the extra destination options header). 3. what is the next hop to be used for the static route for the mobile network's prefix created on the home agent? the choices are a. the tunnel interface (MR_CoA, HA) b. MR_HoA. in (b), the binding cache entry for MR_HoA tells the HA where to send the packet. both (a) and (b) work. for (a), we need to delete/create a static route whenever the MR moves and changes its CoA. (b) results in a larger packet (the extra destination options header), unless you resort to some ugly code which keeps the packet format same. regards Vijay ps: I apologize for not using the terminology from draft-ernst-nemo-terminology-01.txt. I havent read that draft recently. From nemo-admin@nal.motlabs.com Wed Nov 6 04:27:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09983 for ; Wed, 6 Nov 2002 04:27:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA69QGC07146; Wed, 6 Nov 2002 10:26:18 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA69PMC07132 for ; Wed, 6 Nov 2002 10:25:23 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA69P62S000936; Wed, 6 Nov 2002 02:25:06 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id CAA12325; Wed, 6 Nov 2002 02:25:00 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id gA69Otd08474; Wed, 6 Nov 2002 03:24:56 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id EC5D22EC86; Wed, 6 Nov 2002 10:24:54 +0100 (CET) Message-ID: <3DC8DFE6.CAD074A2@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli, NEMO Cc: Janneteau_Christophe Subject: Re: [nemo] Draft NEMO Agenda References: <20021106.020502.111932496.ernst@sfc.wide.ad.jp> <3DC80D24.EDAFA2FE@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 10:24:54 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Thanks for raising these very good points...we also have identified some of them when discussing the bidirectionnal tunnel approach for NEMO. Vijay Devarapalli wrote: > > Hi all, > > Thierry Ernst wrote: > > > For Basic Support, we know that we are going to set up a biderectional > > tunnel. So, I wonder if anyone of you had already some thoughts about > > the potential issues it may cause ? > > three issues that we need to consider. we came across them when > we implemented draft-kniveton-mobrtr-02.txt. > > 1. there is no way for the Home Agent to figure out which mobile > router is allowed which mobile prefix. when it receives a binding > update with the 'R' bit set, it creats a static route for the > prefix to point to the home address of the MN. one solution is to > have a mapping (created manually at the home agent) between mobile > routers and their prefixes. the Home Agent checks this mapping > before accepting the binding updates from the mobile router. we > have implemented this currently. Note that, in the special case where the HA is co-located with the Border Router of the Home link, configuration of such a static route upon reception of BU from MR is not needed. In fact, BR (i.e. HA) should already have such a route from MR's prefix (indicating MR_HoA as next hop) in its local routing table. This is the very same entry used by BR when it is to forward a packet to a nodes behind the MR while MR is at home. Note that this entry could have been configured manually on BR (by netowrk manager) or automatically through a routing protocols such as RIP or OSPF. In situations where HA and BR are not co-located, then there is a need for MR's HA (who will interect packet addressed to LFN while MR is away from Home) to discover that packet addressed to a LFN should be in some way forwarded towards MR. Several apporaches are possible: 1- Use of a permanent static route on MR's HA: "permanent" mean irrespective of the location of the MR, at home or in a visited netowrk. This is simple, on the other hand it requires the network manager to take care of this static entry and ensure it is always consistent with the rest of its routing infrastructure (e.g. in case of renumbering). 2- Use of a static route on MR'HA dynamically configured upon reception of a BU. As Vijay explained, this imply MR'HA to apriori know the binding between MR and MR's prefix (in the Mobile Netowrk). Here this binding would be manually configured by the netowrk manager in a "mapping table" and included dynamically in the HA's routing table upon reception of a BU from MR. But again this requires careful management of this "mapping table" as for the previous approach. Note that in this approach, a prefix scope binding update is not require since the mapping between MR and its prefix is available in the "mapping table". Actually, the PSBU (from MR to HA) does not seems to help here since there is no way for the HA to verify that the MR is authorized to claim such a prefix. So, even in the case of PSBU, such a "mapping table" would still be required for authorization... 3- Extend HA to trigger an ICMP redirect from BR to HA to dynamically configure a temporary route LFN->MR on MR's Home Agent, upon reception by HA of a packet addressed to a LFN. (we describe this is draft-petrescu-nemo-mrha-01.txt). The great advantage here is that the process is dynamic and relies on existing mechanism (ICMP redirect), there is no need for the netowrk manager to maintain static configuration on the Home Agent for MR's prefix. On the other hand, this create per-host entries (LFN->MR) instead of per prefix entries (MRprefix->MR). 4- Extend HA to make it aware of the home netowrk routing topology, e.g. by listening to RIP messages. This is the most dynamic approach. [...] > 3. what is the next hop to be used for the static route for the > mobile network's prefix created on the home agent? the choices > are > a. the tunnel interface (MR_CoA, HA) > b. MR_HoA. > > in (b), the binding cache entry for MR_HoA tells the HA where > to send the packet. both (a) and (b) work. for (a), we need > to delete/create a static route whenever the MR moves and > changes its CoA. (b) results in a larger packet (the extra > destination options header), unless you resort to some ugly > code which keeps the packet format same. Agreed for these two approaches. I think a third one could be: c. A tunnel interface (MR_HoA, HA). But this would result in an extra encapsulation: the first one due to this tunnel towards MR_HoA, and the second one due to the MIPv6 tunnel towards MR_CoA (after parsing of HA Binding Cache).... It is not clear to me why b. results in a larger packet that a. In my understanding, b. will indicate the Home Agent that next hop towards LFN is MR_HoA upon parsing of its routing table. The HA should then parse its Binding Cache and recover the current location of this next hop (i.e. MR_CoA) and send this packet in the MIPv6 tunnel. I should miss something but I don't see which extra header you refer to? On the other hand I think a. as the advantage to avoid parsing of the Binding Cache, the routing table is enough...but this is highly tied to implementation in my opinion. Thanks again for raising these points, Christophe From nemo-admin@nal.motlabs.com Wed Nov 6 09:07:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19531 for ; Wed, 6 Nov 2002 09:07:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6E94C09249; Wed, 6 Nov 2002 15:09:04 +0100 Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6E8JC09238 for ; Wed, 6 Nov 2002 15:08:19 +0100 Received: from imp4-1.free.fr (imp4-1.free.fr [213.228.0.57]) by postfix3-1.free.fr (Postfix) with ESMTP id 5044CD9F3F; Wed, 6 Nov 2002 15:08:18 +0100 (MET) Received: by imp4-1.free.fr (Postfix, from userid 33) id CA1395528; Wed, 6 Nov 2002 15:08:17 +0100 (CET) To: nemo@nal.motlabs.com Message-ID: <1036591697.3dc92251be62a@imp.free.fr> From: petrescu@free.fr Cc: vijayd@iprg.nokia.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.231.104.200 Subject: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 15:08:17 +0100 (MET) Content-Transfer-Encoding: 8bit Hi Vijay, > 1. there is no way for the Home Agent to figure out which mobile > router is allowed which mobile prefix. when it receives a binding > update with the 'R' bit set, it creats a static route for the > prefix to point to the home address of the MN. Isn't that route already present in HA's routing table? If it weren't, then how did HA know how to talk to LFNs were the mobile link at home? I think that HA has entries in its classic routing table of the form: prefix of mobile link1 -> ll address of MR1 prefix of mobile link2 -> ll address of MR2 Otherwise HA wouldn't know to talk to LFNs when they are at home and Mobile IPv6 is not used. Or maybe I'm looking at it differently, please clarify? Thanks, Alex From nemo-admin@nal.motlabs.com Wed Nov 6 09:50:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23624 for ; Wed, 6 Nov 2002 09:50:25 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6Eo3C09564; Wed, 6 Nov 2002 15:50:03 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6EnVC09549 for ; Wed, 6 Nov 2002 15:49:31 +0100 Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA6EnTKV001530; Wed, 6 Nov 2002 15:49:29 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJR9FKFL; Wed, 6 Nov 2002 15:49:29 +0100 Message-ID: <3DC92A2E.2389F6A0@era.ericsson.se> X-Sybari-Trust: 58110d8e ca231590 5b417197 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: petrescu@free.fr CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 15:41:50 +0100 Content-Transfer-Encoding: 7bit We had a nice little discussion around this on the Mobile-ip list end of March-beginning of April 2001 called "Mobile Netwoks in MIPv6" and another one in August 2001 called "Mobile Routers support without optimization". /Mattias petrescu@free.fr wrote: > > Hi Vijay, > > > 1. there is no way for the Home Agent to figure out which mobile > > router is allowed which mobile prefix. when it receives a binding > > update with the 'R' bit set, it creats a static route for the > > prefix to point to the home address of the MN. > > Isn't that route already present in HA's routing table? If it > weren't, then how did HA know how to talk to LFNs were the > mobile link at home? > > I think that HA has entries in its classic routing table of the > form: > > prefix of mobile link1 -> ll address of MR1 > prefix of mobile link2 -> ll address of MR2 > > Otherwise HA wouldn't know to talk to LFNs when they are at home > and Mobile IPv6 is not used. > > Or maybe I'm looking at it differently, please clarify? > > Thanks, > > Alex From nemo-admin@nal.motlabs.com Wed Nov 6 10:10:44 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25172 for ; Wed, 6 Nov 2002 10:10:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6FC3C09906; Wed, 6 Nov 2002 16:12:03 +0100 Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6FBqC09896 for ; Wed, 6 Nov 2002 16:11:52 +0100 Received: from imp2-2.free.fr (imp2-2.free.fr [213.228.0.152]) by postfix4-1.free.fr (Postfix) with ESMTP id 61411BE23; Wed, 6 Nov 2002 17:11:48 +0100 (CET) Received: by imp2-2.free.fr (Postfix, from userid 33) id 162AB8C05C; Wed, 6 Nov 2002 16:11:48 +0100 (CET) To: Mattias Pettersson Subject: Re: [nemo] Re: BU adds routes Message-ID: <1036595507.3dc9313355ee8@imp.free.fr> From: petrescu@free.fr Cc: nemo@nal.motlabs.com References: <1036591697.3dc92251be62a@imp.free.fr> <3DC92A2E.2389F6A0@era.ericsson.se> In-Reply-To: <3DC92A2E.2389F6A0@era.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.231.104.203 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 16:11:47 +0100 (CET) Content-Transfer-Encoding: 8bit Quoting Mattias Pettersson : > We had a nice little discussion around this on the Mobile-ip list end > of > March-beginning of April 2001 called "Mobile Netwoks in MIPv6" and > another one in August 2001 called "Mobile Routers support without > optimization". Sorry, I think I can't remember that discussion and the playground archives seem to be down at this moment (says permission denied). So in these discussions there was a conclusion about this? Something like they decided that BUs must add routes is the best way to go? Sorry if asking things that are already clarified. Alex From nemo-admin@nal.motlabs.com Wed Nov 6 11:02:25 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29008 for ; Wed, 6 Nov 2002 11:02:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6G43C12560; Wed, 6 Nov 2002 17:04:03 +0100 Received: from postfix2-1.free.fr (postfix2-1.free.fr [213.228.0.9]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6G3dC12550 for ; Wed, 6 Nov 2002 17:03:39 +0100 Received: from imp1-2.free.fr (imp1-2.free.fr [213.228.0.151]) by postfix2-1.free.fr (Postfix) with ESMTP id 21B04FA; Wed, 6 Nov 2002 17:03:30 +0100 (CET) Received: by imp1-2.free.fr (Postfix, from userid 33) id 8E2C387342; Wed, 6 Nov 2002 17:03:29 +0100 (CET) To: Mattias Pettersson Subject: Re: [nemo] Re: BU adds routes Message-ID: <1036598608.3dc93d5032eb4@imp.free.fr> From: petrescu@free.fr Cc: nemo@nal.motlabs.com References: <1036591697.3dc92251be62a@imp.free.fr> <3DC92A2E.2389F6A0@era.ericsson.se> In-Reply-To: <3DC92A2E.2389F6A0@era.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 62.231.104.203 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 17:03:28 +0100 (CET) Content-Transfer-Encoding: 8bit Quoting Mattias Pettersson : > We had a nice little discussion around this on the Mobile-ip list end > of > March-beginning of April 2001 called "Mobile Netwoks in MIPv6" and > another one in August 2001 called "Mobile Routers support without > optimization". Oh yes, I see what you mean, I remember now. I found the threads at tut.fi somewhere. Geez almost two years now. On a side note, Mattias do you have any idea whether ICMP Redirects for HAs was also discussed? I need to read these. Thanks for referencing these threads, there's much in it. Alex http://www.atm.tut.fi/list-archive/mobile-ip/threads.html From nemo-admin@nal.motlabs.com Wed Nov 6 13:42:59 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06338 for ; Wed, 6 Nov 2002 13:42:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6Ii5C13561; Wed, 6 Nov 2002 19:44:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6IhgC13551 for ; Wed, 6 Nov 2002 19:43:42 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA02616; Wed, 6 Nov 2002 10:43:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA6IhYH22067; Wed, 6 Nov 2002 10:43:34 -0800 X-mProtect: <200211061843> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdyZRBYc; Wed, 06 Nov 2002 10:42:53 PST Message-ID: <3DC962AD.8BC028DB@iprg.nokia.com> 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: petrescu@free.fr CC: nemo@nal.motlabs.com References: <1036591697.3dc92251be62a@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 10:42:53 -0800 Content-Transfer-Encoding: 7bit hi Alex, petrescu@free.fr wrote: > > Hi Vijay, > > > 1. there is no way for the Home Agent to figure out which mobile > > router is allowed which mobile prefix. when it receives a binding > > update with the 'R' bit set, it creats a static route for the > > prefix to point to the home address of the MN. > > Isn't that route already present in HA's routing table? If it > weren't, then how did HA know how to talk to LFNs were the > mobile link at home? when the MR was at home, it was running a routing protocol. so either the Home Agent (if it runs a routing protocol) or the border router for the home link, had a route to the mobile network's prefix. but routes expire. and they expire fast. the route on the home agent or the border router is present only if the MR keeps sending routing updates. when the MR sends a binding update, the HA needs to add a route in case the route is not there. in case the route exists and the next hop points to a link local address, it needs to update the next hop to either MR_HoA or the tunnel interface (HA, MR_CoA). this is assuming section 6 of draft-kniveton-mobrtr-02.txt is not implemented. a related question. how often does the MR go home? (not often, IMO) Vijay From nemo-admin@nal.motlabs.com Wed Nov 6 16:43:34 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13792 for ; Wed, 6 Nov 2002 16:43:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA6Lj5C14830; Wed, 6 Nov 2002 22:45:05 +0100 Received: from 200.48.61.2 (200-204-195-140.jfsp.gov.br [200.204.195.140] (may be forged)) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gA6LiRC14817 for ; Wed, 6 Nov 2002 22:44:32 +0100 Message-Id: <200211062144.gA6LiRC14817@jessica.nal.motlabs.com> Received: from 82.49.149.76 ([82.49.149.76]) by hd.regsoft.net with asmtp; Nov, 06 2002 4:32:55 PM +0600 Received: from 34.57.158.148 ([34.57.158.148]) by rly-xr02.mx.aol.com with local; Nov, 06 2002 3:48:01 PM -0100 Received: from [6.135.221.168] by rly-xl05.mx.aol.com with asmtp; Nov, 06 2002 2:23:00 PM +0300 From: Jorge To: nemo@nal.motlabs.com Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Priority: 1 Subject: [nemo] Felicidades!!!! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 6 Nov 2002 16:51:13 -0500

 

FELICIDADES!!!!

 

Usted y su familia han sido elegidos para participar con nosotros de 8 dias y 7 noches inolvidables, donde tendra la oportunidad de mezclar el magico Mundo de Disney, las exclusivas playas del sur de la Florida y el exotico encanto de un crucero a Las Islas Bahamas.

 

        

Llame gratis en EE UU y Puerto Rico al 1-800-546-8034

Fuera de EE UU, llame al 001-305-264-6888

Su número de confirmación: R-11052

Para reclamar su premio llame dentro de las proximas 48 horas. Oferta valida para una familia.

Horario de atencion de Lunes a Sabado de 9:00 a.m. a  9:00 p.m.  hora de Miami
From nemo-admin@nal.motlabs.com Wed Nov 6 19:50:12 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18601 for ; Wed, 6 Nov 2002 19:50:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA70q4C15664; Thu, 7 Nov 2002 01:52:04 +0100 Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA70pcC15654 for ; Thu, 7 Nov 2002 01:51:38 +0100 Received: by bulls.mei.co.jp (8.12.5/3.7W/kings) with ESMTP id gA70pSoR021289; Thu, 7 Nov 2002 09:51:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx2) with ESMTP id gA70pUn17116; Thu, 7 Nov 2002 09:51:30 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id gA70pTd08284; Thu, 7 Nov 2002 09:51:29 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:02091217) id gA70pS519517; Thu, 7 Nov 2002 09:51:28 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id gA70pNH14524; Thu, 7 Nov 2002 09:51:23 +0900 (JST) Received: from [133.183.211.98] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7W-TELECOM) with ESMTP id gA70pRn27484; Thu, 7 Nov 2002 09:51:27 +0900 (JST) From: Takeshi TANAKA To: Alexandru Petrescu, IETF NEMO Subject: Re: [nemo] my list of compiled requirements (was: Launching Requirement Discussion) Cc: Chan-Wah Ng In-Reply-To: References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> Message-Id: <20021107094038.8515.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 09:55:13 +0900 Content-Transfer-Encoding: 7bit Hi, We would like to explain about "draft-ng-nemo-aaa-use-00.txt". Sorry for doing so late. Since NEMO is largely applicable to commercial use, we think we should consider about AAA operation from beginning of considering about NEMO solutions. This draft described/categolized NEMO usage scenarios from commercial point of view, and listed requirements for AAA functionalities in NEMO. I.e. this draft describes about requirements for AAA aspect of NEMO, so that routing aspect of NEMO does not preclude requirements for AAA side. Regards, Takeshi At 02 Nov 2002 15:25:13 +0100 Alexandru Petrescu wrote : > Thierry Ernst writes: > > It seems that we have a couple of new/updated drafts to discuss the > > requirements, but I haven't seen an announcement from all the authors, > > so I'm not sure about what is on the table. > > > > So far, I have seen: > > draft-ernst-nemo-requirements-00.txt > > draft-ng-nemo-aaa-use-00.txt > > draft-janneteau-nemo-requirements-00.txt > > draft-sarikaya-nemo-archreqs-00.txt > > I've been compiling recently the following drafts: > > draft-ernst-nemo-requirements-00.txt: > draft-janneteau-nemo-requirements-00.txt: > draft-kniveton-monet-requirements-00.txt: > draft-soliman-monet-statement-00.txt: > draft-sarikaya-nemo-archreqs-00.txt: > draft-ng-nemo-aaa-use-00.txt: From nemo-admin@nal.motlabs.com Wed Nov 6 19:58:03 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18690 for ; Wed, 6 Nov 2002 19:58:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7102C15706; Thu, 7 Nov 2002 02:00:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA70xdC15692 for ; Thu, 7 Nov 2002 01:59:39 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA24011; Wed, 6 Nov 2002 16:59:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA70xWw26263; Wed, 6 Nov 2002 16:59:32 -0800 X-mProtect: <200211070059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddcI1eD; Wed, 06 Nov 2002 16:59:31 PST Message-ID: <3DC9BAF3.90590EB3@iprg.nokia.com> 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: Christophe Janneteau CC: NEMO Subject: Re: [nemo] Draft NEMO Agenda References: <20021106.020502.111932496.ernst@sfc.wide.ad.jp> <3DC80D24.EDAFA2FE@iprg.nokia.com> <3DC8DFE6.CAD074A2@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 06 Nov 2002 16:59:31 -0800 Content-Transfer-Encoding: 7bit hi Christophe, Christophe Janneteau wrote: > > Note that, in the special case where the HA is co-located with the > Border Router of the Home link, configuration of such a static route > upon reception of BU from MR is not needed. In fact, BR (i.e. HA) should > already have such a route from MR's prefix (indicating MR_HoA as next > hop) in its local routing table. This is the very same entry used by BR > when it is to forward a packet to a nodes behind the MR while MR is at > home. Note that this entry could have been configured manually on BR (by > netowrk manager) or automatically through a routing protocols such as > RIP or OSPF. > > In situations where HA and BR are not co-located, then there is a need > for MR's HA (who will interect packet addressed to LFN while MR is away > from Home) to discover that packet addressed to a LFN should be in some > way forwarded towards MR. Several apporaches are possible: please see my reply to Alex. routes expire (it does not matter whether they were on the home agent or the border router). there should be a way to create a route when the mobile router sends a binding update with 'R' bit set. > c. A tunnel interface (MR_HoA, HA). when is this tunnel interface is used? > But this would result in an extra encapsulation: the first one due to > this tunnel towards MR_HoA, and the second one due to the MIPv6 tunnel > towards MR_CoA (after parsing of HA Binding Cache).... yes. its bad. I think we should avoid (c). > It is not clear to me why b. results in a larger packet that a. In my > understanding, b. will indicate the Home Agent that next hop towards LFN > is MR_HoA upon parsing of its routing table. The HA should then parse > its Binding Cache and recover the current location of this next hop > (i.e. MR_CoA) and send this packet in the MIPv6 tunnel. I should miss > something but I don't see which extra header you refer to? option (b) creates the following packet in our implementation IPv6 hdr (src=HA, dst=MR_CoA) Routing Hdr (type 2, contains MR_HoA) IPv6 hdr (src=CN, dst=LFN) Payload. but you are right. there is no reason why it should add the routing header. I think it is a limitation in our implemenation. I will fix this. > On the other hand I think a. as the advantage to avoid parsing of the > Binding Cache, the routing table is enough...but this is highly tied to > implementation in my opinion. I agree it is tied to the implementation. but packet format on the wire has to be standardised. it makes a difference when it comes to IPsec. regards Vijay From nemo-admin@nal.motlabs.com Thu Nov 7 08:07:38 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20261 for ; Thu, 7 Nov 2002 08:07:37 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7D94C20521; Thu, 7 Nov 2002 14:09:05 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7D8hC20511 for ; Thu, 7 Nov 2002 14:08:44 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7D8gKV007223; Thu, 7 Nov 2002 14:08:42 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.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 WJS4P4G0; Thu, 7 Nov 2002 14:08:42 +0100 Message-ID: <3DCA6506.54E52A91@era.ericsson.se> X-Sybari-Trust: f50c01e3 ca231590 8c40f696 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christophe Janneteau CC: NEMO Subject: Re: [nemo] Draft NEMO Agenda References: <20021106.020502.111932496.ernst@sfc.wide.ad.jp> <3DC80D24.EDAFA2FE@iprg.nokia.com> <3DC8DFE6.CAD074A2@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 14:05:10 +0100 Content-Transfer-Encoding: 7bit Hi, Christophe Janneteau wrote: > > > 3. what is the next hop to be used for the static route for the > > mobile network's prefix created on the home agent? the choices > > are > > a. the tunnel interface (MR_CoA, HA) > > b. MR_HoA. > > > > in (b), the binding cache entry for MR_HoA tells the HA where > > to send the packet. both (a) and (b) work. for (a), we need > > to delete/create a static route whenever the MR moves and > > changes its CoA. (b) results in a larger packet (the extra > > destination options header), unless you resort to some ugly > > code which keeps the packet format same. > > Agreed for these two approaches. I think a third one could be: > > c. A tunnel interface (MR_HoA, HA). > > But this would result in an extra encapsulation: the first one due to > this tunnel towards MR_HoA, and the second one due to the MIPv6 tunnel > towards MR_CoA (after parsing of HA Binding Cache).... > > It is not clear to me why b. results in a larger packet that a. In my > understanding, b. will indicate the Home Agent that next hop towards LFN > is MR_HoA upon parsing of its routing table. The HA should then parse > its Binding Cache and recover the current location of this next hop > (i.e. MR_CoA) and send this packet in the MIPv6 tunnel. I should miss > something but I don't see which extra header you refer to? We have to be very careful to specify in what order the routing table and the binding cache are searched. I'm not sure that this is clear to everyone (at least not to me) and it can cause future problems. > On the other hand I think a. as the advantage to avoid parsing of the > Binding Cache, the routing table is enough...but this is highly tied to > implementation in my opinion. Yes, we should avoid searching the binding cache. /Mattias > > Thanks again for raising these points, > Christophe From nemo-admin@nal.motlabs.com Thu Nov 7 10:19:40 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27658 for ; Thu, 7 Nov 2002 10:19:39 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7FL4C21768; Thu, 7 Nov 2002 16:21:04 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7FK0C21737 for ; Thu, 7 Nov 2002 16:20:00 +0100 Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7FJxQ1021361; Thu, 7 Nov 2002 16:19:59 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJR9NCSX; Thu, 7 Nov 2002 16:19:59 +0100 Message-ID: <3DCA83C5.CBFEA657@era.ericsson.se> X-Sybari-Trust: 2a9d7dab ca231590 8c40f696 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: petrescu@free.fr CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes References: <1036591697.3dc92251be62a@imp.free.fr> <3DC92A2E.2389F6A0@era.ericsson.se> <1036598608.3dc93d5032eb4@imp.free.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 16:16:21 +0100 Content-Transfer-Encoding: 7bit petrescu@free.fr wrote: > > Quoting Mattias Pettersson : > > We had a nice little discussion around this on the Mobile-ip list end > > of > > March-beginning of April 2001 called "Mobile Netwoks in MIPv6" and > > another one in August 2001 called "Mobile Routers support without > > optimization". > > Oh yes, I see what you mean, I remember now. I found the threads > at tut.fi somewhere. Geez almost two years now. > > On a side note, > Mattias do you have any idea whether ICMP Redirects for HAs > was also discussed? I need to read these. I don't think anything like that was discussed. /Mattias From nemo-admin@nal.motlabs.com Thu Nov 7 10:21:44 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27794 for ; Thu, 7 Nov 2002 10:21:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7FN2C21806; Thu, 7 Nov 2002 16:23:02 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7FMoC21796 for ; Thu, 7 Nov 2002 16:22:50 +0100 Received: from esealnt611.al.sw.ericsson.se (esealnt611.al.sw.ericsson.se [153.88.254.68]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA7FMnKV026459; Thu, 7 Nov 2002 16:22:49 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJR9NDVL; Thu, 7 Nov 2002 16:22:49 +0100 Message-ID: <3DCA846F.7A697E2E@era.ericsson.se> X-Sybari-Trust: 93bce493 ca231590 8c40f696 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nemo Subject: Re: [nemo] Re: BU adds routes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 16:19:11 +0100 Content-Transfer-Encoding: 7bit Hi Motorola people (and a little to Nokia as well, see below), I took the freedom to read your mrha-00.txt I-D. I appreciate that you have done some very much needed deep analysis of different solutions and also all traffic scenarios. Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but you seem to have made an interpretation of the main concept that I disagree on. Maybe I'm mistaken, but anyway, here's my point: When MR is home, BR, HA and MR all are attached to the same link. HA------BR | MR When MR is away, MR is attached to HA through a link of type IP-in-IP encapsulation. HA------BR || MR What is interesting is that draft-kniveton-mobrtr.txt says that MR actually leaves the home link as a router, while you say that it is still there (covered for by the HA). An important difference is that when running routing protocols between all routers on the home link (including BR, HA and MR), draft-kniveton-mobrtr.txt causes MR to change its attachment from the home link and move to another link behind the HA. BR will learn that the mobile network prefix is not reachable through MR any more, but instead through HA. And the number of hops to reach it increases by one. There are pros and cons with both approaches. To me draft-kniveton-mobrtr.txt seems simpler. This will a number of things in your I-D. General comment: I think HA should participate in routing protocols. Maybe with some intelligence, as you say. Below are some comments to the I-D: > 10. FN sends packet to LFN, mobile network visits, HA separated BR > > > ---- ---- / > | FN | | HA | / > ---- ---- ----------/ > | | ---- | | > -------------------| BR |---| Internet | > home link ---- | | > ----------\ > \ > \ ---- Visited link > --| AR |------ > ---- | > | > ---- ----- > | MR | | LFN | > ---- ----- > | | > --------- > mobile net > > > -FN scans its routing table for LFN's address, and finds default > route towards BR. > -FN sends NS for L2 address of BR. > -BR replies NA. > -FN sends packet to BR. > -BR scans its routing table for LFN's address, and finds route > through MR; > -BR sends NS for MR. > -HA replies NA with its L2 address (on behalf of MR). > -BR forwards packet to HA and sends ICMP Redirect to FN such that > subsequent packets from FN to LFN go straight through MR and not > through BR. BR also sends ICMP Redirect to HA, such that HA knows > a route through MR. The logic of this last ICMP Redirect is > described in section 6.1. > -HA scans its routing table for LFN's address, and finds through MR; > -HA scans binding cache and finds 'through MRHA tunnel'; > -HA encapsulates and sends packet to MR. > -MR decapsulates and forwards to LFN. > > > The problem in the above case is how to inform the HA about the > route towards MR. When MR at home, and HA being a host, normally HA is a router. Always. Don't you think? > HA doesn't have a route towards MR. See discussion in section 6.1. > > > 5.3 MR Redirects to BR > > Also, consider the scenario where the FN has a default route > towards the MR instead of the BR, and sending packets to a CN on > the Internet. This might very well happen when the MR is at home > > Petrescu et al. Expires April 2003 [Page 15] > > INTERNET-DRAFT Mobile Networks with MRHA October 2002 > > and sending RAs, in addition to the RAs sent by the BR. FN might > configure a default route through the MR instead of the BR. If MR > is at home, MR will redirect the FN towards the BR. So, even if > this looks like a wrong configuration on the FN (its default route > should point to BR and not MR), packets will still travel correctly > when MR is at home. This should be maintained when the MR is not > at home. There are two possibilities: either the HA (replacing the > MR) redirects the FN towards the BR, or it is the MR itself that > sends the respective ICMP redirect message to the FN (through the > MRHA tunnel). The first case supposes that HA maintains a routing > table, which contains routes towards the mobile network. This is > less desirable if the HA is not co-located with BR, and where we > prefer not to have routing interactions with the HA. The latter Why not? > case is more plausible, keeping the default routing behaviour to > the MR. > 6.2 Static route method > > This is proposed by [4] and [13], where operator statically > introduces a route in the HA, for MR's prefix, towards MR's > address, or towards the specific MRHA tunnel. > > The first approach proposed in [4] suggests to configure a new > static tunnel on the MR's HA towards MR_HoA. This static tunnel, > that we call here MR_HoA_tunnel, is to be used as output interface > of a new static entry added in the routing table of HA for MR's > prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data > packet from CN addressed to a LFN, MR's HA will consult its routing > table and find a match for that packet for this static route since > LFN address matches MR's prefix. As a results it will encapsulate > the packet with an additional header that will have MR's HA as > source address and MR_HoA as destination address. In order to > forward this packet, now addressed to MR's Home Address, the MR > will first consult its binding cache and discover MR's Care-of > address. It will thus send the packet through the MRHA tunnel > towards MR's current location. It is worth mentionning that this > approach introduces a double encapsulation of an incoming packet to > be forwarded to the MR: the first is due to the MR_HoA_tunnel, the > second to the MRHA tunnel. > > The second approach proposed in [13] suggests a similar method but > avoids the overhead introduced by the two tunnels. It consists in > configuring a static route in MR's HA routing table for MR's prefix > towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of > a data packet from CN addressed to a LFN, MR's HA will consult its > routing table and, again, find a match for that packet for this > static route since LFN address matches MR's prefix. This indicates > the MR's HA that the packet should be routed towards MR_HoA. From > its binding cache it discovers MR's CoA and as a consequence > forwards the incoming packet for CN directly through the MRHA draft-kniveton-mobrtr.txt seems a bit vague on this. Sometimes MR_HoA is a global home address, but at other times link-local is assumed. As described at the end of this mail, I think this is overdoing it. The comment here though is that first a route lookup is performed where MR_HoA is found and that address is used as input for the binding cache lookup. I don't think it is logical to search the binding cache for something that is not specified in any field of the packet being forwarded. > tunnel. This approach reduces the overhad of the MR_HoA_tunnel but > requires a suitable coordination of the routing table and binding > cache on the HA. > 7.1 Link-local addresses > > When the MR is at home, and if it runs a dynamic routing protocol, > it exchanges routing information with BR, by using its link-local > address and BR's link-local address. When the MR is not at home, > and HA defends the MR's home address, the HA is normally doing this > for any type of addresses except link-locals. The immediate > necessity would be for the HA to defend a link-local address of the > MR, instead of a global-scoped home address. However, this is in > conflict with the necessity of dynamic routing protocols to use > link-local addresses only. Yes, HA will have to defend the link-local address of MR. And all other addresses (global etc.) of MR by default. Please see draft-kniveton-mobrtr.txt. When the MR is away, it is not participating directly with the home link by routing protocols. Everything is propagated through HA. > > If Mobile IPv6 spec is to be followed, then the HA will not allow > re-direction of traffic of a Home Address towards a CoA, when that > Home Address is link-local. > > Another issue concerning link local addresses: the MR has routes to > the BR using BR's link local address. When the MR is away from > home: how does the MR reach BR's link local address? Now HA is an adjacent router of MR. BR is one additional hop away. In other words, MR doesn't have to know BR, only how to reach HA (which is through the tunnel). > > Petrescu et al. Expires April 2003 [Page 18] > > INTERNET-DRAFT Mobile Networks with MRHA October 2002 > > How does it tell the difference between a link local address on the > home link and a link local address on the visited link? > > 7.2 MR as an MN > > If the MR is at home and it has an address configured on the moving > interface other than a link-local address, then the MR can act as > an MH too, and send normal Mobile IPv6 BUs, binding that Home > Address to a newly configured CoA; thus allowing the MR to be an MH > for itself only, ignoring the LFNs. If the MR at home doesn't have > other addresses than link-local on the mobile interface then the MR > can not send normal Mobile IPv6 BUs and can not be an MH. It can > however be an MR for the hosts on the mobile network. Not necessarily true. MR can have a global address on its ingress interface and use that for its host functions. I.e. MR is also an LFN. From http://www.nal.motlabs.com/nemo/drafts/draft-kniveton-mobrtr.txt: > 6.1. Processing the Tunneled Routing Messages > > When the HA_MR receives the routing information from the mobile router > through the bidirectional tunnel, it adds the corresponding routes to > its routing table with the next hop set to the mobile router's address, > in case of IPv6 MR's link local address. This next hop address is > obtained from the source address of the inner packet. The HA_MR in > turn propagates this information when it sends routing updates to other > routers on the mobile router's home link. Yes. But: > > The HA_MR also needs a binding cache entry for that address which is > the next hop address for the MR's subnet. In the case of IPv4 this > is created when the MR sends a registration request [?] for its home > address when it moves away from its home link. In the case of IPv6 > HA_MR needs a binding cache entry to the mobile router's link local > address. This is because the next hop address in the routing table > entry returns the mobile router's link local address. And to forward > packets to the mobile router's link local address, a binding cache entry > is needed. A binding cache entry is not created unless HA_MR receives a > binding update from the mobile router. Therefore the mobile router MUST > send a binding update for its link local address in addition to its home > address. This is optional in the current Mobile IPv6 [5] specification. I don't see why this is needed. The HA_MR already has a route for MR's subnet pointing to MR's link-local address _and_ the tunnel interface towards MR. A route lookup's primary function is to provide the outgoing interface, which in this case is the tunnel to MR. > > 6.2. Forwarding Packets to MR's subnet > > Since HA_MR advertised routing reachability information for MR's > subnet, it receives the packets meant for the nodes in the MR's subnet. > Route lookup on HA_MR returns the address of the mobile router as the > next hop address. By making use of the binding cache entry for the > mobile router's address (link local address in case of IPv6) and the > bi-directional tunnel with the mobile router, HA_MR starts forwarding > packets throught the tunnel to the mobile router. The mobile router in > turn decapsulates the packet and fowards it on its subnet. > See comment above for the first I-D. Also, should the HA have a BC entry for the link-local address of MR according to MIPv6 I-D? Thanks for your attention. /Mattias From nemo-admin@nal.motlabs.com Thu Nov 7 18:00:04 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17160 for ; Thu, 7 Nov 2002 18:00:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7N16C27644; Fri, 8 Nov 2002 00:01:06 +0100 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7KFsC25165 for ; Thu, 7 Nov 2002 21:15:55 +0100 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Subject: [nemo] Note Well Statement Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 15:11:40 -0500 From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== 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. From nemo-admin@nal.motlabs.com Thu Nov 7 18:50:47 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18472 for ; Thu, 7 Nov 2002 18:50:46 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7Nq4C28434; Fri, 8 Nov 2002 00:52:04 +0100 Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA7NpeC28422 for ; Fri, 8 Nov 2002 00:51:40 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id gA7NpUP01342; Thu, 7 Nov 2002 17:51:30 -0600 (CST) Message-ID: <3DCAFCBB.1010907@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takeshi TANAKA CC: Alexandru Petrescu , IETF NEMO , Chan-Wah Ng Subject: Re: [nemo] my list of compiled requirements (was: Launching Requirement Discussion) References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> <20021107094038.8515.TAKESHI.TANAKA@yrp.mci.mei.co.jp> Content-Type: multipart/alternative; boundary="------------080407030207050600050704" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 17:52:27 -0600 --------------080407030207050600050704 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Takeshi, Your draft reads nicely, and it is useful. I think the most important message in it is that MR must have an AAA client. Maybe there are prospects for more future work in this domain possibly to be pursued in AAA WG. However as you said the draft does not address any requirements on the base NEMO solution. My 2 cents. Takeshi TANAKA wrote: >Hi, > >We would like to explain about "draft-ng-nemo-aaa-use-00.txt". >Sorry for doing so late. > >Since NEMO is largely applicable to commercial use, we think we should >consider about AAA operation from beginning of considering about NEMO >solutions. > >This draft described/categolized NEMO usage scenarios from commercial >point of view, and listed requirements for AAA functionalities in NEMO. >I.e. this draft describes about requirements for AAA aspect of NEMO, >so that routing aspect of NEMO does not preclude requirements for AAA side. > >Regards, >Takeshi > >At 02 Nov 2002 15:25:13 +0100 >Alexandru Petrescu wrote : > > > >>Thierry Ernst writes: >> >> >>>It seems that we have a couple of new/updated drafts to discuss the >>>requirements, but I haven't seen an announcement from all the authors, >>>so I'm not sure about what is on the table. >>> >>>So far, I have seen: >>> draft-ernst-nemo-requirements-00.txt >>> draft-ng-nemo-aaa-use-00.txt >>> draft-janneteau-nemo-requirements-00.txt >>> draft-sarikaya-nemo-archreqs-00.txt >>> >>> >>I've been compiling recently the following drafts: >> >> draft-ernst-nemo-requirements-00.txt: >> draft-janneteau-nemo-requirements-00.txt: >> draft-kniveton-monet-requirements-00.txt: >> draft-soliman-monet-statement-00.txt: >> draft-sarikaya-nemo-archreqs-00.txt: >> draft-ng-nemo-aaa-use-00.txt: >> >> > > > > -- Behcet --------------080407030207050600050704 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Takeshi,
  Your draft reads nicely, and it is useful. I think the most important message in it is that MR must have an AAA client. Maybe there are prospects for more future work in this domain possibly to be pursued in AAA WG.
  However as you said the draft does not address any requirements on the base NEMO solution.
  My 2 cents.

Takeshi TANAKA wrote:
Hi,

We would like to explain about "draft-ng-nemo-aaa-use-00.txt".
Sorry for doing so late.

Since NEMO is largely applicable to commercial use, we think we should
consider about AAA operation from beginning of considering about NEMO 
solutions.

This draft described/categolized NEMO usage scenarios from commercial 
point of view, and listed requirements for AAA functionalities in NEMO.
I.e. this draft describes about requirements for AAA aspect of NEMO, 
so that routing aspect of NEMO does not preclude requirements for AAA side.

Regards,
Takeshi

At 02 Nov 2002 15:25:13 +0100 
Alexandru Petrescu<petrescu@crm.mot.com> wrote :

  
Thierry Ernst <ernst@sfc.wide.ad.jp> writes:
    
It seems that we have a couple of new/updated drafts to discuss the
requirements, but I haven't seen an announcement from all the authors,
so I'm not sure about what is on the table.

So far, I have seen:
      draft-ernst-nemo-requirements-00.txt 
      draft-ng-nemo-aaa-use-00.txt 
      draft-janneteau-nemo-requirements-00.txt 
      draft-sarikaya-nemo-archreqs-00.txt 
      
I've been compiling recently the following drafts:

  draft-ernst-nemo-requirements-00.txt:
  draft-janneteau-nemo-requirements-00.txt:
  draft-kniveton-monet-requirements-00.txt:
  draft-soliman-monet-statement-00.txt:
  draft-sarikaya-nemo-archreqs-00.txt:
  draft-ng-nemo-aaa-use-00.txt:
    


  

-- 
Behcet

--------------080407030207050600050704-- From nemo-admin@nal.motlabs.com Thu Nov 7 19:23:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19293 for ; Thu, 7 Nov 2002 19:23:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA80P3C29103; Fri, 8 Nov 2002 01:25:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA80OMC29083 for ; Fri, 8 Nov 2002 01:24:22 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA25111; Thu, 7 Nov 2002 16:24:16 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA80OFp30168; Thu, 7 Nov 2002 16:24:15 -0800 X-mProtect: <200211080024> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdm7CA0X; Thu, 07 Nov 2002 16:24:14 PST Message-ID: <3DCB042E.AAAE22D2@iprg.nokia.com> 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: Mattias Pettersson CC: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 16:24:14 -0800 Content-Transfer-Encoding: 7bit Hi, Mattias Pettersson wrote: > > Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but > you seem to have made an interpretation of the main concept that I > disagree on. Maybe I'm mistaken, but anyway, here's my point: > > When MR is home, BR, HA and MR all are attached to the same link. > HA------BR > | > MR > When MR is away, MR is attached to HA through a link of type IP-in-IP > encapsulation. > HA------BR > || > MR we have an implementation of this. it works just fine. > General comment: I think HA should participate in routing protocols. strongly agree. > > The problem in the above case is how to inform the HA about the > > route towards MR. When MR at home, and HA being a host, normally > > HA is a router. Always. Don't you think? it _is_ always. from http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt home agent A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address. it is a router on the home link. > draft-kniveton-mobrtr.txt seems a bit vague on this. Sometimes MR_HoA is > a global home address, but at other times link-local is assumed. As > described at the end of this mail, I think this is overdoing it. it is deliberate :-) when the HA and MR are running a routing protocol through the bi-directional tunnel interface, the routing updates from the MR have MR's link local address. so the next hop automatically becomes the link local address. when the route is created through the binding update, the next hop becomes the MR_HoA. but it does not matter. both should ultimately point to the tunnel interface (HA, MR_CoA). by the way, the MR can register both its home address and link local address with just one binding update by setting the 'L' bit to 1. this is new in MIPv6 spec. it is not there in draft-kniveton-mobrtr yet. however the MR (or an MN) cannot send a binding update for its link local address alone. > Also, should the HA have a BC entry for the link-local address of MR > according to MIPv6 I-D? not unless if the 'L' bit was set in the BU. regards Vijay From nemo-admin@nal.motlabs.com Thu Nov 7 19:37:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19561 for ; Thu, 7 Nov 2002 19:37:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA80Y2C29313; Fri, 8 Nov 2002 01:34:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA80XfC29293 for ; Fri, 8 Nov 2002 01:33:42 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA25574; Thu, 7 Nov 2002 16:33:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA80XZE17583; Thu, 7 Nov 2002 16:33:35 -0800 X-mProtect: <200211080033> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfoMjWk; Thu, 07 Nov 2002 16:33:33 PST Message-ID: <3DCB065D.608CA177@iprg.nokia.com> 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: Mattias Pettersson CC: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 07 Nov 2002 16:33:33 -0800 Content-Transfer-Encoding: 7bit resending. something went wrong with the earlier mail. the format got screwed up. some text was also missing. Mattias Pettersson wrote: > > Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but > you seem to have made an interpretation of the main concept that I > disagree on. I disagree too. > Maybe I'm mistaken, but anyway, here's my point: > > When MR is home, BR, HA and MR all are attached to the same link. > HA------BR > | > MR > > When MR is away, MR is attached to HA through a link of type IP-in-IP > encapsulation. > HA------BR > || > MR we have an implementation of this. it works just fine. > > General comment: I think HA should participate in routing protocols. strongly agree. > > The problem in the above case is how to inform the HA about the > > route towards MR. When MR at home, and HA being a host, normally > > HA is a router. Always. Don't you think? it _is_ always. from http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-19.txt home agent A router on a mobile node's home link with which the mobile node has registered its current care-of address. While the mobile node is away from home, the home agent intercepts packets on the home link destined to the mobile node's home address, encapsulates them, and tunnels them to the mobile node's registered care-of address. it is a router on the home link. > draft-kniveton-mobrtr.txt seems a bit vague on this. Sometimes MR_HoA is > a global home address, but at other times link-local is assumed. As > described at the end of this mail, I think this is overdoing it. it is deliberate :-) when the HA and MR are running a routing protocol through the bi-directional tunnel interface, the routing updates from the MR have MR's link local address. so the next hop automatically becomes the link local address. when the route is created through the binding update, the next hop becomes the MR_HoA. but it does not matter. both should ultimately point to the tunnel interface (HA, MR_CoA). by the way, the MR can register both its home address and link local address with just one binding update by setting the 'L' bit to 1. this is new in MIPv6 spec. it is not there in draft-kniveton-mobrtr yet. however the MR (or an MN) cannot send a binding update for its link local address alone. > Also, should the HA have a BC entry for the link-local address of MR > according to MIPv6 I-D? not unless if the 'L' bit was set in the BU. regards Vijay From nemo-admin@nal.motlabs.com Fri Nov 8 03:59:42 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10942 for ; Fri, 8 Nov 2002 03:59:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8914C03303; Fri, 8 Nov 2002 10:01:04 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA890aC03280 for ; Fri, 8 Nov 2002 10:00:36 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gA88vXRj024552; Fri, 8 Nov 2002 01:57:33 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id CAA15889; Fri, 8 Nov 2002 02:00:30 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id gA890QW03004; Fri, 8 Nov 2002 03:00:27 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 105722EC8B; Fri, 8 Nov 2002 10:00:25 +0100 (CET) Message-ID: <3DCB7D28.732EBBA8@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson, NEMO References: <3DCA846F.7A697E2E@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Can HA be a host? Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 10:00:24 +0100 Content-Transfer-Encoding: 7bit Hi Mattias and All, First of all, thanks a lot for your very interesting comparison between the two drafts. We definitively need such discussion to better understand issues. For now, I would like to comment only on one part of your email which raises a very important point that we should clarify (at least for me :). Mattias Pettersson wrote: > > The problem in the above case is how to inform the HA about the > > route towards MR. When MR at home, and HA being a host, normally > > HA is a router. Always. Don't you think? This is a very good question indeed and, as you said, our draft-petrescu does not make such an assumption. What about a regular MIPv6 HA? draft-ietf-mobileip-ipv6-19.txt seems to assume that the HA is a router (at least it describes typical behaviors that a HA router must have, e.g. setting the 'R' bit in Prefix Information option of Router Advertisement it sends, this for the Dynamic Home Agent Discovery process). However, I have the feeling this is only an assumption since I did not find any requirements "HA MUST be a router" in the draft. So my personal understanding is that nothing in the current Mobile IPv6 specification prevents a HA from being a simple host and not a router. Please let me know if this assumption is not correct and why, I can imagine this has been already discuss on mobile-ip mailing list BTW... Assuming regular MIPv6 HA can be a host, a don't see any good reason why NEMO should mandate MR's HA to be a router. In fact, I can even identify good reasons why NEMO, as a standard group, should not impose this. Here are two of them: o Management reasons: Let's assume a home network equipped with a host HA to support Mobile Nodes wants to upgrade to support also mobile networks. It would then have to deploy a second HA (router)...since it could not use its existing one that is a host. This would introduce duplication of functions... o Business reasons: If HA can be a host, A company X who is NOT shipping routers could still make business by selling (host) HA. If there is no good technical reasons to prevent HA to be a host, then NEMO should not impose this....since it may introduce unfairness in the business space which is something a standard organism should try to avoid. Please let me know your opinion on this... Thanks, Christophe From nemo-admin@nal.motlabs.com Fri Nov 8 06:06:20 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12944 for ; Fri, 8 Nov 2002 06:06:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8B82C06791; Fri, 8 Nov 2002 12:08:02 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8B7CC06780 for ; Fri, 8 Nov 2002 12:07:13 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gA8B788Z013807; Fri, 8 Nov 2002 04:07:08 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id EAA08021; Fri, 8 Nov 2002 04:07:08 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id gA8B6wh30022; Fri, 8 Nov 2002 05:06:58 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 468042EC86; Fri, 8 Nov 2002 12:07:03 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DC962AD.8BC028DB@iprg.nokia.com> Message-ID: Lines: 64 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 08 Nov 2002 12:07:03 +0100 Hi Vijay, Vijay Devarapalli writes: > > > 1. there is no way for the Home Agent to figure out which mobile > > > router is allowed which mobile prefix. when it receives a binding > > > update with the 'R' bit set, it creats a static route for the > > > prefix to point to the home address of the MN. > > > > Isn't that route already present in HA's routing table? If it > > weren't, then how did HA know how to talk to LFNs were the > > mobile link at home? > > when the MR was at home, it was running a routing protocol. so > either the Home Agent (if it runs a routing protocol) or the > border router for the home link, had a route to the mobile > network's prefix. > > but routes expire. and they expire fast. Looks scary :-) Manually-added static routes don't expire, do they. > the route on the home agent or the border router is present only if > the MR keeps sending routing updates. So why not MR keeping sending those classic RUs (Route Updates) through the MRHA tunnel? I mean, if the MR and HA were running a dynamic routing protocol, they could continue running it when the MR is not at home, but through the tunnel. BUs sent by Mobile IP are sent each time MH moves, and each time the MH acquires a new CoA, because that CoA changes. Contrast this to when MR moves, it changes its CoA but the prefix on the link stays stable, it's not influenced by mobility. Do you suggest that each classic BU containing a new CoA will also contain the same old mobile link prefix? Or do you suggest that refreshing BUs (those requested by BRs or by local timeouts) might contain refreshing the same route? > when the MR sends a binding update, the HA needs to add a route in > case the route is not there. in case the route exists and the next > hop points to a link local address, it needs to update the next hop > to either MR_HoA or the tunnel interface (HA, MR_CoA). I'm not sure I understand this very well but you seem to be on to something. The idea would be to have the MR_HoA equal the link-local address. > a related question. > > how often does the MR go home? (not often, IMO) Homeless Mobile IP? I guess this depends to a large extent on the deployment scenarion. Scenarios with a large backbone and many phones/PDAs moving around (like in wireless telephony) suggest that MR is never at home. But scenarios with slices of LANs moving very rarely and very remotely (when travelling to a conference) suggest that MR is at home most of time, especially when market conditions are adverse. Alex From nemo-admin@nal.motlabs.com Fri Nov 8 06:50:01 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13745 for ; Fri, 8 Nov 2002 06:49:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8Bl2C07204; Fri, 8 Nov 2002 12:47:02 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8BkAC07187 for ; Fri, 8 Nov 2002 12:46:13 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA8Bk12S027007; Fri, 8 Nov 2002 04:46:01 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA04626; Fri, 8 Nov 2002 04:41:59 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id gA8BjnU07485; Fri, 8 Nov 2002 05:45:49 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 363EA2EC8B; Fri, 8 Nov 2002 12:45:49 +0100 (CET) To: Mattias Pettersson Cc: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DCA846F.7A697E2E@era.ericsson.se> Message-ID: Lines: 116 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 08 Nov 2002 12:45:49 +0100 Mattias Pettersson writes: > I took the freedom to read your mrha-00.txt I-D. I appreciate that you > have done some very much needed deep analysis of different solutions and > also all traffic scenarios. Hi Mattias, and thank you for reading through the drafts. > Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but > you seem to have made an interpretation of the main concept that I > disagree on. Maybe I'm mistaken, but anyway, here's my point: > > When MR is home, BR, HA and MR all are attached to the same link. > HA------BR > | > MR > > When MR is away, MR is attached to HA through a link of type IP-in-IP > encapsulation. > HA------BR > || > MR > > What is interesting is that draft-kniveton-mobrtr.txt says that MR > actually leaves the home link as a router, while you say that it is > still there (covered for by the HA). Yes, and there are many intermediary degrees. For example, MR could instruct HA to participate on the routing protocols exchanges on its behalf, when the MR is not at home. > General comment: I think HA should participate in routing protocols. > Maybe with some intelligence, as you say. If HA a host (see below), then it might look redundant for HA to maintain many routes towards all fixed subnets attached to the home link. The only routing need for HA is to maintain the routes towards the prefixes of the mobile links. The information related to all the fixed links attached to the home link can be obtained by ICMP Redirect from each BR that attaches to those fixed links. IMO. > HA is a router. Always. Don't you think? I will bite even if I know the hook hurts :-) Instead of calling HA a host, I should have called it a one-interface machine, HA for Mobility only, HAM. The only routing information it maintains is related to mobility of hosts and routers, and it doesn't maintain routing information related to the fixed hosts or routers (other than static routes and/or dynamically obtained routes from ICMP Redirects sent by BRs). An HA like this could be an advantage in deployment of mobility in the existing fixed environments, where BRs exist. Instead of modifying BRs, one could just deploy a new HAM PC and modify only the MHs that move and MRs that move. I think that this discussion might lead to a requirement. This requirement might sound like this: "In NEMO, and from a router/host standpoint, the HA forwards packets and is thus a router. Also, the HA should be a treated as router or as a host like Mobile IP treats it, not different. If Mobile IP allows for HA to be a one-interface machine that doesn't participate in dynamic routing, then NEMO should allow it as well." The other flavor would be: "In NEMO, and from a router/host standpoint, the HA is a router as in rfc2460." Another one: "The HA must participate in all existing routing protocol exchanges at home." This probably not well formulated, but I'm sure a good requirement can come up from the router/host discussion. > > 5.3 MR Redirects to BR > > > > Also, consider the scenario where the FN has a default route > > towards the MR instead of the BR, and sending packets to a CN on > > the Internet. This might very well happen when the MR is at home > > and sending RAs, in addition to the RAs sent by the BR. FN might > > configure a default route through the MR instead of the BR. If MR > > is at home, MR will redirect the FN towards the BR. So, even if > > this looks like a wrong configuration on the FN (its default route > > should point to BR and not MR), packets will still travel correctly > > when MR is at home. This should be maintained when the MR is not > > at home. There are two possibilities: either the HA (replacing the > > MR) redirects the FN towards the BR, or it is the MR itself that > > sends the respective ICMP redirect message to the FN (through the > > MRHA tunnel). The first case supposes that HA maintains a routing > > table, which contains routes towards the mobile network. This is > > less desirable if the HA is not co-located with BR, and where we > > prefer not to have routing interactions with the HA. > > Why not? Why not what? :-) If HA must participate in all dynamic routing interactions then yes, the HA will send the respective Redirect, I agree with your question. > The comment here though is that first a route lookup is performed where > MR_HoA is found and that address is used as input for the binding cache > lookup. I don't think it is logical to search the binding cache for > something that is not specified in any field of the packet being > forwarded. Yes, order of search is important here. Thanks again Mattias for reading through the drafts, Alex From nemo-admin@nal.motlabs.com Fri Nov 8 08:23:16 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18015 for ; Fri, 8 Nov 2002 08:23:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8DO6C08922; Fri, 8 Nov 2002 14:24:07 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8DNEC08895 for ; Fri, 8 Nov 2002 14:23:14 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gA8DN52H017075; Fri, 8 Nov 2002 06:23:05 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA19312; Fri, 8 Nov 2002 06:23:05 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id gA8DN2H07335; Fri, 8 Nov 2002 07:23:02 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 091C62EC86; Fri, 8 Nov 2002 14:22:59 +0100 (CET) To: Vijay Devarapalli Cc: Mattias Pettersson, Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DCB065D.608CA177@iprg.nokia.com> Message-ID: Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 08 Nov 2002 14:22:58 +0100 Vijay Devarapalli writes: > > Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but > > you seem to have made an interpretation of the main concept that I > > disagree on. > > I disagree too. So you Vijay disagree on the same interpretation of the main concept that Mattias disagrees on, or you disagree on another interpretation of the main concept? Or you just disagree too? :-) > > General comment: I think HA should participate in routing protocols. > > strongly agree. Generally agree. I think HA must participate into routing related to mobility and may participate in routing related to fixedness. > by the way, the MR can register both its home address and link > local address with just one binding update by setting the 'L' > bit to 1. this is new in MIPv6 spec. Aha, this is new indeed thank you for letting us know. That L bit might prove very useful for NEMO. It should be clarified though. If I understand it correctly, that L bit is there for DAD reasons only. If I understand it correctly, its semantics will not allow for an MR to have the IID of the ll different than the IID of the home address. I'm saying this because I'm struck by the following paragraph from the same draft: "However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, such a packet MUST be discarded, and the home agent SHOULD return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address)." I was thinking that when MR uses RIP through the MRHA tunnel, it will absolutely need to get packets addressed to its ll through that tunnel. > draft-kniveton-mobrtr yet. however the MR (or an MN) cannot > send a binding update for its link local address alone. Exactly, that's what I understood too. Thanks, Alex From nemo-admin@nal.motlabs.com Fri Nov 8 13:20:34 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04512 for ; Fri, 8 Nov 2002 13:20:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8IM4C14507; Fri, 8 Nov 2002 19:22:06 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8ILjC14496 for ; Fri, 8 Nov 2002 19:21:48 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05112; Fri, 8 Nov 2002 10:21:33 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8ILOw16041; Fri, 8 Nov 2002 10:21:24 -0800 X-mProtect: <200211081821> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZjkXfB; Fri, 08 Nov 2002 10:21:18 PST Message-ID: <3DCC009F.C2D48AF7@iprg.nokia.com> 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: Christophe Janneteau CC: Mattias Pettersson , NEMO Subject: Re: [nemo] Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 10:21:19 -0800 Content-Transfer-Encoding: 7bit hi Christophe, please. it is weird that NEMO would call HA a host when MIPv6 calls HA a router. when the terminology section in MIPv6 says HA is a router, do you need another statement which says HA MUST be a router. and, if a node does IP forwarding, I thought it was a router. anyway coming back to the topic, it simplifies the solution to a large extent if you assume HA is a router. lets go with it. Christophe Janneteau wrote: > > process). However, I have the feeling this is only an assumption since I > did not find any requirements "HA MUST be a router" in the draft. So my look in the terminology section. > personal understanding is that nothing in the current Mobile IPv6 > specification prevents a HA from being a simple host and not a router. > Please let me know if this assumption is not correct and why, I can > imagine this has been already discuss on mobile-ip mailing list BTW... > regards Vijay From nemo-admin@nal.motlabs.com Fri Nov 8 13:29:02 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05384 for ; Fri, 8 Nov 2002 13:29:01 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8IV2C14614; Fri, 8 Nov 2002 19:31:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8IUmC14604 for ; Fri, 8 Nov 2002 19:30:48 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05533; Fri, 8 Nov 2002 10:30:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8IUfe29175; Fri, 8 Nov 2002 10:30:41 -0800 X-mProtect: <200211081830> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQ2cHIE; Fri, 08 Nov 2002 10:30:40 PST Message-ID: <3DCC02D0.FE71B30F@iprg.nokia.com> 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: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 10:30:40 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Hi Vijay, > > Looks scary :-) Manually-added static routes don't expire, do they. why would you manually add a static route? this will not scale IMO. 1. when the MR is it at home, it is running some kind of routing protocol. so the home agent or the border router have routes to it. 2. when the MR is not at home and does not run a routing protocol through the bi-directional tunnel, a route to the mobile network is created when the MR sends a BU to the home agent. 3. when the MR is not at home, but does run a routing protocol through the bi-directional tunnel, a route to the mobile network is created when the MR sends routing updates. why do you need manual intervention to add static routes to each mobile router? and when I said routes expire, I was talking about routes created through (1), (2) and (3). > > the route on the home agent or the border router is present only if > > the MR keeps sending routing updates. > > So why not MR keeping sending those classic RUs (Route Updates) > through the MRHA tunnel? I mean, if the MR and HA were running a > dynamic routing protocol, they could continue running it when the MR > is not at home, but through the tunnel. the MR is shut off!!! my cell phone (assuming its the MR for my PAN) is not going to be up and running all the time. > > how often does the MR go home? (not often, IMO) > > Homeless Mobile IP? why not? if the MR is a cell phone, it almost never goes home. if the MR is a train/plane/ship, its the same. if they are at home, you can be sure that there are no passengers on board :-) Vijay From nemo-admin@nal.motlabs.com Fri Nov 8 13:32:20 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05624 for ; Fri, 8 Nov 2002 13:32:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8IY3C14705; Fri, 8 Nov 2002 19:34:03 +0100 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8IXcC14685 for ; Fri, 8 Nov 2002 19:33:38 +0100 Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA8IXCot015445; Fri, 8 Nov 2002 10:33:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAN77636; Fri, 8 Nov 2002 10:27:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA14359; Fri, 8 Nov 2002 10:33:09 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15820.869.645007.255504@thomasm-u1.cisco.com> To: Vijay Devarapalli Cc: Christophe Janneteau , Mattias Pettersson , NEMO Subject: Re: [nemo] Can HA be a host? In-Reply-To: <3DCC009F.C2D48AF7@iprg.nokia.com> References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCC009F.C2D48AF7@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 8 Nov 2002 10:33:09 -0800 (PST) Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > > hi Christophe, > > please. it is weird that NEMO would call HA a host when MIPv6 > calls HA a router. when the terminology section in MIPv6 says > HA is a router, do you need another statement which says HA > MUST be a router. > > and, if a node does IP forwarding, I thought it was a router. > > anyway coming back to the topic, it simplifies the solution to > a large extent if you assume HA is a router. lets go with it. Yet... a router is a host too :) I think it's generally more useful to talk about which direction a packet gets steered (stack, interface) once it's arrived. Mike From nemo-admin@nal.motlabs.com Fri Nov 8 13:38:04 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06062 for ; Fri, 8 Nov 2002 13:38:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8Ie2C14855; Fri, 8 Nov 2002 19:40:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8Id3C14820 for ; Fri, 8 Nov 2002 19:39:03 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05969; Fri, 8 Nov 2002 10:38:57 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8IcvA14449; Fri, 8 Nov 2002 10:38:57 -0800 X-mProtect: <200211081838> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGrTCFP; Fri, 08 Nov 2002 10:38:55 PST Message-ID: <3DCC04BF.AD2B3482@iprg.nokia.com> 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: Alexandru Petrescu CC: Mattias Pettersson , Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 10:38:55 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Vijay Devarapalli writes: > > > Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but > > > you seem to have made an interpretation of the main concept that I > > > disagree on. > > > > I disagree too. > > So you Vijay disagree on the same interpretation of the main concept > that Mattias disagrees on, or you disagree on another interpretation > of the main concept? Or you just disagree too? :-) :-). sorry. I should have been verbose. I disagree with your interpretation of the main concept (or in short, agree with Mattias). > It should be clarified though. If I understand it correctly, that L > bit is there for DAD reasons only. If I understand it correctly, its > semantics will not allow for an MR to have the IID of the ll different > than the IID of the home address. right. but L bit is not for DAD. the MN sets the L bit to 1 if it wants its link local address to be defended in addition to its home address. > > I'm saying this because I'm struck by the following paragraph from the > same draft: > > "However, packets addressed to the mobile node's link-local address > MUST NOT be tunneled to the mobile node. Instead, such a packet MUST > be discarded, and the home agent SHOULD return an ICMP Destination > Unreachable, Code 3, message to the packet's Source Address (unless > this Source Address is a multicast address)." > > I was thinking that when MR uses RIP through the MRHA tunnel, it will > absolutely need to get packets addressed to its ll through that > tunnel. right. MIPv6 deals only with hosts. NEMO should overide this as part of mobile router support. if the HA knows that a particular MN is an MR, it starts tunneling routing updates, even though the source address is a link local address. requiring routing protocols to use global addresses instead of link local addresses should not be our goal (IMO). that would need changes to routing protocols. regards Vijay From nemo-admin@nal.motlabs.com Fri Nov 8 14:00:24 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08294 for ; Fri, 8 Nov 2002 14:00:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8J22C15049; Fri, 8 Nov 2002 20:02:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8J1pC15039 for ; Fri, 8 Nov 2002 20:01:51 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA07261; Fri, 8 Nov 2002 11:01:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8J1ie12541; Fri, 8 Nov 2002 11:01:44 -0800 X-mProtect: <200211081901> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.177, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdE1qAAT; Fri, 08 Nov 2002 11:01:42 PST Message-ID: <3DCC0A16.9020005@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 11:01:42 -0800 Content-Transfer-Encoding: 7bit hi, a clarification. Vijay Devarapalli wrote: >>>how often does the MR go home? (not often, IMO) >> >>Homeless Mobile IP? > > why not? if the MR is a cell phone, it almost never goes home. if > the MR is a train/plane/ship, its the same. if they are at home, > you can be sure that there are no passengers on board :-) not the Homeless Mobile IP as specified by Ericsson Nomadic Lab. :-) I am just referring to base MIPv6, when MN does not go home often. Vijay From nemo-admin@nal.motlabs.com Fri Nov 8 14:55:07 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10788 for ; Fri, 8 Nov 2002 14:55:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8Jv3C15744; Fri, 8 Nov 2002 20:57:03 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8JuFC15722 for ; Fri, 8 Nov 2002 20:56:15 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gA8JrDoL013825; Fri, 8 Nov 2002 12:53:13 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA06578; Fri, 8 Nov 2002 12:56:11 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id gA8Ju6U14492; Fri, 8 Nov 2002 13:56:07 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7CBAB2EC8B; Fri, 8 Nov 2002 20:56:06 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC0A16.9020005@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DCC0A16.9020005@iprg.nokia.com> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 08 Nov 2002 20:56:06 +0100 Vijay Devarapalli writes: > >>Homeless Mobile IP? > > why not? if the MR is a cell phone, it almost never goes home. if > > the MR is a train/plane/ship, its the same. if they are at home, you > > can be sure that there are no passengers on board :-) > > not the Homeless Mobile IP as specified by Ericsson Nomadic Lab. :-) > I am just referring to base MIPv6, when MN does not go home often. Yes, I understand that. Alex From nemo-admin@nal.motlabs.com Fri Nov 8 15:04:15 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11319 for ; Fri, 8 Nov 2002 15:04:14 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8K61C15892; Fri, 8 Nov 2002 21:06:01 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8K5YC15879 for ; Fri, 8 Nov 2002 21:05:34 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gA8K5TDD027285; Fri, 8 Nov 2002 13:05:29 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA04152; Fri, 8 Nov 2002 13:05:28 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id gA8K2GH15188; Fri, 8 Nov 2002 14:02:17 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 5BD332EC86; Fri, 8 Nov 2002 21:02:14 +0100 (CET) To: Vijay Devarapalli Cc: Mattias Pettersson, Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> <3DCC04BF.AD2B3482@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DCC04BF.AD2B3482@iprg.nokia.com> Message-ID: Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 08 Nov 2002 21:02:14 +0100 Vijay Devarapalli writes: > > > > Your I-D includes a lot of the ideas of draft-kniveton-mobrtr.txt, but > > > > you seem to have made an interpretation of the main concept that I > > > > disagree on. > > > > > > I disagree too. > > > > So you Vijay disagree on the same interpretation of the main concept > > that Mattias disagrees on, or you disagree on another interpretation > > of the main concept? Or you just disagree too? :-) > > :-). sorry. I should have been verbose. > > I disagree with your interpretation of the main concept (or in short, > agree with Mattias). That's what I didn't understand from Mattias about "interpretation of the main concept". Should I understand from both of you that the main concept of draft-kniveton is badly interpreted by us? Or that the generic mobile router concept is badly interpreted by us? If the former I could try to push for removal of as much concept as possible that comes from other documents. > > I was thinking that when MR uses RIP through the MRHA tunnel, it will > > absolutely need to get packets addressed to its ll through that > > tunnel. > > right. MIPv6 deals only with hosts. NEMO should overide this as part > of mobile router support. if the HA knows that a particular MN is an > MR, it starts tunneling routing updates, even though the source address > is a link local address. requiring routing protocols to use global > addresses instead of link local addresses should not be our goal (IMO). > > that would need changes to routing protocols. Correct, changes to routing protocols is what we wish to avoid as much as possible. Alex From nemo-admin@nal.motlabs.com Fri Nov 8 15:40:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10787 for ; Fri, 8 Nov 2002 14:55:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8Ju4C15714; Fri, 8 Nov 2002 20:56:04 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8JtBC15672 for ; Fri, 8 Nov 2002 20:55:11 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gA8JtEmD023583; Fri, 8 Nov 2002 12:55:14 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA02363; Fri, 8 Nov 2002 12:51:12 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id gA8Jt2i06104; Fri, 8 Nov 2002 13:55:03 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8045D2EC8B; Fri, 8 Nov 2002 20:55:01 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DCC02D0.FE71B30F@iprg.nokia.com> Message-ID: Lines: 79 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 08 Nov 2002 20:55:01 +0100 Vijay Devarapalli writes: > > Looks scary :-) Manually-added static routes don't expire, do they. > > why would you manually add a static route? this will not scale IMO. Ah, correct, scalability, again. This will not scale, that will not scale. It is correct, manually added routes will not scale. And I can find other things that don't scale and are used commonly. How many MRHA tunnels can one have on a router when that tunnel is an interface. > 1. when the MR is it at home, it is running some kind of routing > protocol. so the home agent or the border router have routes to > it. It is possible to have an MR at home and not run routing protocol. I mean it is possible these days and you're surely keeping this in mind, but overlooking it somehow, that's why I'm continuing the discussion to see why. > 2. when the MR is not at home and does not run a routing protocol > through the bi-directional tunnel, a route to the mobile network is > created when the MR sends a BU to the home agent. Yes, as in draft-kniveton. So the routing table is updated both by BUs and by RUs. How about the binding cache being updated both by BUs and RUs. > 3. when the MR is not at home, but does run a routing protocol > through the bi-directional tunnel, a route to the mobile network > is created when the MR sends routing updates. > > why do you need manual intervention to add static routes to each > mobile router? When the MR is at home and the HA is a one-interface machine then there will not be manual addition to the HA's routing table. The BR will send ICMP redirects, so the HA's routing table is modified dynamically. > and when I said routes expire, I was talking about routes created > through (1), (2) and (3). Yes, correct, I understand, but I believe the ICMP redirects where overlooked. > > > the route on the home agent or the border router is present only if > > > the MR keeps sending routing updates. > > > > So why not MR keeping sending those classic RUs (Route Updates) > > through the MRHA tunnel? I mean, if the MR and HA were running a > > dynamic routing protocol, they could continue running it when the MR > > is not at home, but through the tunnel. > > the MR is shut off!!! my cell phone (assuming its the MR for my PAN) > is not going to be up and running all the time. If MR is shut off then HA doesn't need a routing table entry either(!!!). > > > how often does the MR go home? (not often, IMO) > > > > Homeless Mobile IP? > > why not? if the MR is a cell phone, it almost never goes home. Vijay, I certainly agree with this direction of homeless reasoning. You're right, when MR is cell phone and deployment is 3GPP-like then MR never at home. I agree. I also must say that I truly appreciate the lessons I learned from the implementation experience as exposed in draft-kniveton. I'm just trying to clarify some questions I have and you might be entirely right that prefixes are needed in the BUs. Alex From nemo-admin@nal.motlabs.com Fri Nov 8 15:44:09 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13045 for ; Fri, 8 Nov 2002 15:44:08 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8Kf2C16842; Fri, 8 Nov 2002 21:41:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8KeFC16828 for ; Fri, 8 Nov 2002 21:40:15 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA13517; Fri, 8 Nov 2002 12:40:09 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8Ke8107713; Fri, 8 Nov 2002 12:40:08 -0800 X-mProtect: <200211082040> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.177, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPzvHFi; Fri, 08 Nov 2002 12:40:05 PST Message-ID: <3DCC2126.3040105@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: Mattias Pettersson , Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> <3DCC04BF.AD2B3482@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 12:40:06 -0800 Content-Transfer-Encoding: 7bit hi Alexandru, Alexandru Petrescu wrote: > > That's what I didn't understand from Mattias about "interpretation of > the main concept". > > Should I understand from both of you that the main concept of > draft-kniveton is badly interpreted by us? Or that the generic mobile > router concept is badly interpreted by us? there is nothing bad about how you interpreted it. Mattias's point was that things become much simpler if you assume that, when the MR is away from home, it is reachable through the bi-directional tunnel with the home agent and does not appear to be still on the home link. the routing table of any router on the home link should also reflect that the MR is now one extra hop away. to put in another way, a router on the home link has a route to the mobile network in which the next hop is the link local address of MR. when the MR is away from home, the next hop should be the home agent. regards Vijay From nemo-admin@nal.motlabs.com Fri Nov 8 16:33:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16019 for ; Fri, 8 Nov 2002 16:33:25 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8LZ5C18128; Fri, 8 Nov 2002 22:35:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA8LYQC18090 for ; Fri, 8 Nov 2002 22:34:26 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA16220; Fri, 8 Nov 2002 13:34:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gA8LYHr10795; Fri, 8 Nov 2002 13:34:17 -0800 X-mProtect: <200211082134> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIv4Md1; Fri, 08 Nov 2002 13:34:16 PST Message-ID: <3DCC2DD9.A065D171@iprg.nokia.com> 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: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 08 Nov 2002 13:34:17 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > 1. when the MR is it at home, it is running some kind of routing > > protocol. so the home agent or the border router have routes to > > it. > > It is possible to have an MR at home and not run routing protocol. I > mean it is possible these days and you're surely keeping this in mind, > but overlooking it somehow, that's why I'm continuing the discussion > to see why. yes. it is possible, though I wouldnt manually create a route for a router, which I know is mobile and could move away from the home link. here I think your ICMP redirect mechanism is very useful. I am still beginning to understand this. > > 2. when the MR is not at home and does not run a routing protocol > > through the bi-directional tunnel, a route to the mobile network is > > created when the MR sends a BU to the home agent. > > Yes, as in draft-kniveton. > > So the routing table is updated both by BUs and by RUs. How about the > binding cache being updated both by BUs and RUs. binding cache is updated only by BUs. > > the MR is shut off!!! my cell phone (assuming its the MR for my PAN) > > is not going to be up and running all the time. > > If MR is shut off then HA doesn't need a routing table entry either(!!!). > right. thats why the HA needs to check if there is a route to the mobile network when it receives a binding update from the mobile router. if a route is not present, it has to create one. the home agent also has to make sure that packets meant for the mobile network reach the home agent on the home link. your ICMP redirect mechanism would be very useful here. the home agent sends an ICMP redirect for the mobile network prefix to point to itself. every router on the home link update their routing tables to point to the home agent. this would work right? regards Vijay From nemo-admin@nal.motlabs.com Sat Nov 9 11:43:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21246 for ; Sat, 9 Nov 2002 11:43:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9Gi6C05526; Sat, 9 Nov 2002 17:44:06 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GhIC05500 for ; Sat, 9 Nov 2002 17:43:18 +0100 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA9GhGKV022292; Sat, 9 Nov 2002 17:43:16 +0100 (MET) Received: from era.ericsson.se (ki-139.ki.sw.ericsson.se [147.214.100.139]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPSX6RN8; Sat, 9 Nov 2002 17:43:15 +0100 Message-ID: <3DCD2E98.274F1D8@era.ericsson.se> X-Sybari-Trust: d596778c ca231590 794b7d82 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli CC: Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 09 Nov 2002 16:49:44 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > Alexandru Petrescu wrote: > > > > Hi Vijay, > > > > Looks scary :-) Manually-added static routes don't expire, do they. > > why would you manually add a static route? this will not scale IMO. > > 1. when the MR is it at home, it is running some kind of routing > protocol. so the home agent or the border router have routes to > it. > > 2. when the MR is not at home and does not run a routing protocol > through the bi-directional tunnel, a route to the mobile network > is created when the MR sends a BU to the home agent. > > 3. when the MR is not at home, but does run a routing protocol > through the bi-directional tunnel, a route to the mobile network > is created when the MR sends routing updates. > > why do you need manual intervention to add static routes to each > mobile router? > > and when I said routes expire, I was talking about routes created > through (1), (2) and (3). I fully agree. This is exactly the scenario I see. /Mattias From nemo-admin@nal.motlabs.com Sat Nov 9 11:46:17 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21300 for ; Sat, 9 Nov 2002 11:46:16 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GlkC05554; Sat, 9 Nov 2002 17:47:46 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GhJC05504 for ; Sat, 9 Nov 2002 17:43:19 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA9GhJKV022295; Sat, 9 Nov 2002 17:43:19 +0100 (MET) Received: from era.ericsson.se (ki-139.ki.sw.ericsson.se [147.214.100.139]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTTB29D; Sat, 9 Nov 2002 17:43:18 +0100 Message-ID: <3DCD3267.193DB57B@era.ericsson.se> X-Sybari-Trust: 77331cc1 ca231590 794b7d82 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christophe Janneteau CC: NEMO References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Can HA be a host? Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 09 Nov 2002 17:05:59 +0100 Content-Transfer-Encoding: 7bit Hi Christophe, Christophe Janneteau wrote: > > Hi Mattias and All, > > Mattias Pettersson wrote: > > > The problem in the above case is how to inform the HA about the > > > route towards MR. When MR at home, and HA being a host, normally > > > > HA is a router. Always. Don't you think? > > This is a very good question indeed and, as you said, our draft-petrescu > does not make such an assumption. > > What about a regular MIPv6 HA? It is a router, just as Vijay explained in another mail. > > Assuming regular MIPv6 HA can be a host, a don't see any good reason why > NEMO should mandate MR's HA to be a router. In fact, I can even identify > good reasons why NEMO, as a standard group, should not impose this. Here > are two of them: > > o Management reasons: Let's assume a home network equipped with a host > HA to support Mobile Nodes wants to upgrade to support also mobile > networks. It would then have to deploy a second HA (router)...since it > could not use its existing one that is a host. This would introduce > duplication of functions... The first HA is a router. > > o Business reasons: If HA can be a host, A company X who is NOT shipping > routers could still make business by selling (host) HA. If there is no > good technical reasons to prevent HA to be a host, then NEMO should not > impose this....since it may introduce unfairness in the business space > which is something a standard organism should try to avoid. Change business... :-) And for the definition of what is a router (from RFC 2460): router - a node that forwards IPv6 packets not explicitly addressed to itself. We're not talking about an expensive rack of hardware specially designed for routing. A router is a function. If the input function processing of the stack doesn't drop packets that have a destination address other than those belonding to the node itself, it is a router by definition. It is possible for a router to have only one physical interface. /Mattias From nemo-admin@nal.motlabs.com Sat Nov 9 11:47:01 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21314 for ; Sat, 9 Nov 2002 11:47:00 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GmUC05572; Sat, 9 Nov 2002 17:48:30 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GhMC05508 for ; Sat, 9 Nov 2002 17:43:22 +0100 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA9GhMKV022305; Sat, 9 Nov 2002 17:43:22 +0100 (MET) Received: from era.ericsson.se (ki-139.ki.sw.ericsson.se [147.214.100.139]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTRSCV9; Sat, 9 Nov 2002 17:43:21 +0100 Message-ID: <3DCD35F3.E902A452@era.ericsson.se> X-Sybari-Trust: 7d598704 ca231590 794b7d82 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 09 Nov 2002 17:21:07 +0100 Content-Transfer-Encoding: 7bit Hi Alex, Alexandru Petrescu wrote: > > When MR is home, BR, HA and MR all are attached to the same link. > > HA------BR > > | > > MR > > > > When MR is away, MR is attached to HA through a link of type IP-in-IP > > encapsulation. > > HA------BR > > || > > MR > > > > What is interesting is that draft-kniveton-mobrtr.txt says that MR > > actually leaves the home link as a router, while you say that it is > > still there (covered for by the HA). > > Yes, and there are many intermediary degrees. For example, MR could > instruct HA to participate on the routing protocols exchanges on its > behalf, when the MR is not at home. > > > General comment: I think HA should participate in routing protocols. > > Maybe with some intelligence, as you say. > > If HA a host (see below), then it might look redundant for HA to > maintain many routes towards all fixed subnets attached to the home > link. The only routing need for HA is to maintain the routes towards > the prefixes of the mobile links. The information related to all the > fixed links attached to the home link can be obtained by ICMP Redirect > from each BR that attaches to those fixed links. IMO. The HA doesn't have to store all routes to fixed subnets on the home link although it participates in routing protocols. As long as it keeps a default route to BR, it can reach them all. We both agree. The problem is that BR will send ICMP redirects for packets that HA send with destinations that belong to subnets below BR. So HA end up having to save these routes anyway (now in the form of host routes rather than prefix routes, which consumes even more routing entries). > > > HA is a router. Always. Don't you think? > > I will bite even if I know the hook hurts :-) > > Instead of calling HA a host, I should have called it a one-interface > machine, HA for Mobility only, HAM. The only routing information it > maintains is related to mobility of hosts and routers, and it doesn't > maintain routing information related to the fixed hosts or routers > (other than static routes and/or dynamically obtained routes from ICMP > Redirects sent by BRs). If you see this as an optmization, you're free to do so. > > An HA like this could be an advantage in deployment of mobility in the > existing fixed environments, where BRs exist. Instead of modifying > BRs, one could just deploy a new HAM PC and modify only the MHs that > move and MRs that move. Of course. No need to modify the BRs. I think HA should be decoupled from BR. How would you otherwise implement a home link with redundant HAs where you can run DHAAD? > > I think that this discussion might lead to a requirement. This > requirement might sound like this: > > "In NEMO, and from a router/host standpoint, the HA forwards > packets and is thus a router. Also, the HA should be a treated as > router or as a host like Mobile IP treats it, not different. If > Mobile IP allows for HA to be a one-interface machine that doesn't > participate in dynamic routing, then NEMO should allow it as > well." Yes, apart from the word host. > > The other flavor would be: > > "In NEMO, and from a router/host standpoint, the HA is a router as > in rfc2460." Very true. > > Another one: > > "The HA must participate in all existing routing protocol > exchanges at home." This is what I think is wise to do, but it doesn't have to be a MUST. /Mattias From nemo-admin@nal.motlabs.com Sat Nov 9 11:47:46 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21335 for ; Sat, 9 Nov 2002 11:47:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GnHC05594; Sat, 9 Nov 2002 17:49:17 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GhQC05512 for ; Sat, 9 Nov 2002 17:43:26 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA9GhOQ1017573; Sat, 9 Nov 2002 17:43:25 +0100 (MET) Received: from era.ericsson.se (ki-139.ki.sw.ericsson.se [147.214.100.139]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPTTB29H; Sat, 9 Nov 2002 17:43:24 +0100 Message-ID: <3DCD38D5.5780AF17@era.ericsson.se> X-Sybari-Trust: 2e2dec15 ca231590 794b7d82 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli CC: Alexandru Petrescu , Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> <3DCC04BF.AD2B3482@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 09 Nov 2002 17:33:25 +0100 Content-Transfer-Encoding: 7bit Hi, Vijay Devarapalli wrote: > > Alexandru Petrescu wrote: > > > > I'm saying this because I'm struck by the following paragraph from the > > same draft: > > > > "However, packets addressed to the mobile node's link-local address > > MUST NOT be tunneled to the mobile node. Instead, such a packet MUST > > be discarded, and the home agent SHOULD return an ICMP Destination > > Unreachable, Code 3, message to the packet's Source Address (unless > > this Source Address is a multicast address)." > > > > I was thinking that when MR uses RIP through the MRHA tunnel, it will > > absolutely need to get packets addressed to its ll through that > > tunnel. > > right. MIPv6 deals only with hosts. NEMO should overide this as part > of mobile router support. if the HA knows that a particular MN is an > MR, it starts tunneling routing updates, even though the source address > is a link local address. requiring routing protocols to use global > addresses instead of link local addresses should not be our goal (IMO). > that would need changes to routing protocols. I think this part of the MIPv6 spec should be made a bit clearer. If it is done in the right way, it doesn't stop the approach I'm talking about: I assume that HA and MR have a bi-directional tunnel between each other when MR is away. This tunnel is a link, and they will exchange routing information with each other over this tunnel. HA will not relay packets with source/destination = link-local between this tunnel and the home link. The routing information will get propagated anyway, because the routing daemon on HA will sit in the middle. So what the MIPv6 spec should say is: "HA must not forward packets from the home link into the tunnel if the destination address is MN's link-local address". HA itself should be free to send such packets into the tunnel, provided that HA itself initiated them. /Mattias From nemo-admin@nal.motlabs.com Sat Nov 9 11:53:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21445 for ; Sat, 9 Nov 2002 11:53:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9Go2C05617; Sat, 9 Nov 2002 17:50:02 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gA9GhSC05516 for ; Sat, 9 Nov 2002 17:43:28 +0100 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA9GhRKV022315; Sat, 9 Nov 2002 17:43:28 +0100 (MET) Received: from era.ericsson.se (ki-139.ki.sw.ericsson.se [147.214.100.139]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WPSX6R33; Sat, 9 Nov 2002 17:43:27 +0100 Message-ID: <3DCD39EB.2DA3DEEF@era.ericsson.se> X-Sybari-Trust: d5c4c0b0 ca231590 794b7d82 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli CC: Alexandru Petrescu , Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> <3DCC04BF.AD2B3482@iprg.nokia.com> <3DCC2126.3040105@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 09 Nov 2002 17:38:03 +0100 Content-Transfer-Encoding: 7bit Hi Alex and Vijay, Vijay Devarapalli wrote: > > hi Alexandru, > > Alexandru Petrescu wrote: > > > > That's what I didn't understand from Mattias about "interpretation of > > the main concept". > > > > Should I understand from both of you that the main concept of > > draft-kniveton is badly interpreted by us? Or that the generic mobile > > router concept is badly interpreted by us? > > there is nothing bad about how you interpreted it. Mattias's point > was that things become much simpler if you assume that, when the MR > is away from home, it is reachable through the bi-directional > tunnel with the home agent and does not appear to be still on the > home link. the routing table of any router on the home link should > also reflect that the MR is now one extra hop away. > > to put in another way, a router on the home link has a route to > the mobile network in which the next hop is the link local address > of MR. when the MR is away from home, the next hop should be the > home agent. > Alex, yes, please try to reflect the different views you have. I think it is good that you quote draft-kniveton, but I would like you to more clearly put it onto the map and explain your own view and how they differ. Draft-kniveton has a smaller scope. mrha-00 tries to cover as much as possible. /Mattias From nemo-admin@nal.motlabs.com Sun Nov 10 00:29:05 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01437 for ; Sun, 10 Nov 2002 00:29:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAA5U6C20422; Sun, 10 Nov 2002 06:30:06 +0100 Received: from 99.222.27.24.cfl.rr.com (KOKA@99.222.27.24.cfl.rr.com [24.27.222.99]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gAA5TbC20408 for ; Sun, 10 Nov 2002 06:29:40 +0100 Received: from compuserve.com (concentric.net [149.157.49.59]) by mailexcite.com (8.11.6/8.11.6) with ESMTP id 22795 for ; Sun, 10 Nov 2002 05:29:39 +0000 From: "chpol" To: "" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: The Bat! (v1.014) S/N 1D4DB7AD Message-ID: <45012752qhprCqdo1prwodev1frp@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [nemo] Bulk Email Sending & Bullet Proof Web Hosting Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 10 Nov 2002 05:29:39 +0000 We offer you databases of e-mail addresses for advertisement mailing; we sell databases, carry out mailing the advertising projects. We can work on a turnkey project create a site with original design, contents. Our databases are daily updated with e-mail addresses from all over the world. Their validity and originality are verified. Today they contain over 50 million addresses. We use our own mailing be ideally adjusted for any customer. We have a wide channel and a high power server. The allows us to keep the prices low. http://www.e-mailpromo.net Please contact us. We’ll be glad to answer any questions. HTTP: www.e-mailpromo.net E-mail: info@e-mailpromo.net ICQ: 130982 We received your address from a public place. We apologies if this letter have reached you by mistake. We'll not disturb you any more. NB. This message is sent in compliance of the new email bill section 301. Under Bill S. US Congress. This message cannot be considered we include the way to be Removed, Paragraph (a)(c) of S. 1618. TO REMOVE: send message to info@e-mailpromo.net with "Remove" in Subject. From nemo-admin@nal.motlabs.com Mon Nov 11 13:13:03 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26501 for ; Mon, 11 Nov 2002 13:12:55 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gABIE9C04087; Mon, 11 Nov 2002 19:14:10 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gABIDJC04077 for ; Mon, 11 Nov 2002 19:13:20 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA16687; Mon, 11 Nov 2002 10:13:09 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gABID7116739; Mon, 11 Nov 2002 10:13:07 -0800 X-mProtect: <200211111813> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdPG8uFY; Mon, 11 Nov 2002 10:13:05 PST Message-ID: <3DCFF332.907555E9@iprg.nokia.com> 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: Mattias Pettersson CC: Alexandru Petrescu , Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> <3DCC04BF.AD2B3482@iprg.nokia.com> <3DCD38D5.5780AF17@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 11 Nov 2002 10:13:06 -0800 Content-Transfer-Encoding: 7bit hi Mattias, Mattias Pettersson wrote: > > I think this part of the MIPv6 spec should be made a bit clearer. If it > is done in the right way, it doesn't stop the approach I'm talking > about: > > I assume that HA and MR have a bi-directional tunnel between each other > when MR is away. This tunnel is a link, and they will exchange routing > information with each other over this tunnel. HA will not relay packets > with source/destination = link-local between this tunnel and the home > link. The routing information will get propagated anyway, because the > routing daemon on HA will sit in the middle. > > So what the MIPv6 spec should say is: "HA must not forward packets from > the home link into the tunnel if the destination address is MN's > link-local address". HA itself should be free to send such packets into > the tunnel, provided that HA itself initiated them. what if NEMO just says, "If the packet is a routing protocol update, the packet is forwarded into the tunnel interface by the HA, even though the source and destination address of the packet is link local. Every other packet with source or destination address as link local is is not forwarded through the tunnel as specified in [MIPv6]". wouldnt this be enough, instead of asking MIPv6 WG to relax their requirement of not tunneling packets with link local addresses? regards Vijay From nemo-admin@nal.motlabs.com Tue Nov 12 01:11:45 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13540 for ; Tue, 12 Nov 2002 01:11:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAC688C09443; Tue, 12 Nov 2002 07:08:09 +0100 Received: from snmail.smartnet.co.kr ([61.33.159.11]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAC67EC09430 for ; Tue, 12 Nov 2002 07:07:15 +0100 Received: by snmail.smartnet.co.kr with Internet Mail Service (5.5.2656.59) id <44AQH19F>; Tue, 12 Nov 2002 15:05:25 +0900 Received: from logic ([61.33.159.33]) by snmail.smartnet.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 44AQH191; Tue, 12 Nov 2002 15:05:16 +0900 From: shkim@smartnet.co.kr To: nemo@nal.motlabs.com Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by jessica.nal.motlabs.com id gAC67EC09430 Subject: [nemo] for Adding mailing list Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 15:07:40 +0900 Content-Transfer-Encoding: 8bit Hi Sir.. I got attention about NEMO workgroup.. and studying Mobility Networking on Candidate Ph.D.. So I'd like to adding my mail address to NEMO Mailing List.. Thanks... E-mail : shkim@dsys.korea.ac.kr From nemo-admin@nal.motlabs.com Tue Nov 12 03:44:43 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25199 for ; Tue, 12 Nov 2002 03:44:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAC8k2C11032; Tue, 12 Nov 2002 09:46:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAC8jlC11019 for ; Tue, 12 Nov 2002 09:45:47 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAC8hgdv010726; Tue, 12 Nov 2002 09:44:00 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 12 Nov 2002 09:45:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Subject: RE: [nemo] Re: BU adds routes Message-ID: Thread-Topic: [nemo] Re: BU adds routes Thread-Index: AcKJr5cMHsrERlkpRna9AEBTOfbTCgAc1jBg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Mattias Pettersson" Cc: "Alexandru Petrescu" , "Nemo" X-OriginalArrivalTime: 12 Nov 2002 08:45:07.0696 (UTC) FILETIME=[CD909F00:01C28A27] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAC8jlC11019 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 08:44:59 -0000 Content-Transfer-Encoding: 8bit Hi: I'm getting a bit anxious about this discussion... My 3 cents of ˆ: 1) I believe it's great to have this discussion (and Alex's draft) for people to understand the dynamics of the protocols, but I hope this effort is not meant to lead to something in a standard document that would say if and how the routes are set up in the home link and the home AS - unless Nemo *needs* a new routing protocol, I mean. I believe that operators should be free to use static routes when they see fit, and a routing protocol when it covers their needs better. 2) I've read the 's' word ...scaling. Now, consider a home network with 10, 100, 1000, potentially 10000 or 100000 Mobile Routers. Why not? A home network could be a large community. I suspect that the routing fabric of the home AS may suffer some if routes are injected each time a MR binds, unbinds, leaves or returns home. 3) Routing protocols on the MRHA tunnel expect at least a keep alive form of traffic. When the only available connectivity is mobile phone, like GSM data (paid by the duration) or GPRS (paid by the bytes transported), then this approach may be a bit costly for the user. With Nemo, we may see arise a new form of routers. In one hand, some will be thin, low power, mass produced - not unlike mobile phones, and may not have routing protocol capabilities. On the other hand, Nemo may help companies manage (outsource, move physically) their production networks of traditional, large routers. Pascal From nemo-admin@nal.motlabs.com Tue Nov 12 06:02:20 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27087 for ; Tue, 12 Nov 2002 06:02:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACB44C13413; Tue, 12 Nov 2002 12:04:04 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACB3nC13398 for ; Tue, 12 Nov 2002 12:03:50 +0100 Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gACB3mKV020450; Tue, 12 Nov 2002 12:03:48 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.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 WWLHX5WS; Tue, 12 Nov 2002 12:03:48 +0100 Message-ID: <3DD0DF41.9473AC60@era.ericsson.se> X-Sybari-Trust: 63826e11 ca231590 6a09eb59 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli CC: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB065D.608CA177@iprg.nokia.com> <3DCC04BF.AD2B3482@iprg.nokia.com> <3DCD38D5.5780AF17@era.ericsson.se> <3DCFF332.907555E9@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 12:00:17 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > > hi Mattias, > > Mattias Pettersson wrote: > > > > I think this part of the MIPv6 spec should be made a bit clearer. If it > > is done in the right way, it doesn't stop the approach I'm talking > > about: > > > > I assume that HA and MR have a bi-directional tunnel between each other > > when MR is away. This tunnel is a link, and they will exchange routing > > information with each other over this tunnel. HA will not relay packets > > with source/destination = link-local between this tunnel and the home > > link. The routing information will get propagated anyway, because the > > routing daemon on HA will sit in the middle. > > > > So what the MIPv6 spec should say is: "HA must not forward packets from > > the home link into the tunnel if the destination address is MN's > > link-local address". HA itself should be free to send such packets into > > the tunnel, provided that HA itself initiated them. > > what if NEMO just says, "If the packet is a routing protocol update, > the packet is forwarded into the tunnel interface by the HA, even > though the source and destination address of the packet is link local. > Every other packet with source or destination address as link local > is is not forwarded through the tunnel as specified in [MIPv6]". That would require looking into the packet. > > wouldnt this be enough, instead of asking MIPv6 WG to relax their > requirement of not tunneling packets with link local addresses? I didn't mean to relax MIPv6 spec. I meant to clarify it. IMO, the MIPv6 spec's intention is that the HA must not forward link-local packets (initiated by others). What I fear is that people read into the MIPv6 spec that link-local packets must not go over the tunnel (including those that the HA initiated itself - the kind that I want to use for route updates). /Mattias From nemo-admin@nal.motlabs.com Tue Nov 12 06:15:52 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27209 for ; Tue, 12 Nov 2002 06:15:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACBH3C13589; Tue, 12 Nov 2002 12:17:03 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACBGpC13578 for ; Tue, 12 Nov 2002 12:16:51 +0100 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gACBGoQ1016368; Tue, 12 Nov 2002 12:16:50 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLF7FCA; Tue, 12 Nov 2002 12:16:49 +0100 Message-ID: <3DD0E24F.9A5E2509@era.ericsson.se> X-Sybari-Trust: 62b3de61 ca231590 6a09eb59 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Vijay Devarapalli , Alexandru Petrescu , Nemo Subject: Re: [nemo] Re: BU adds routes References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 12:13:19 +0100 Content-Transfer-Encoding: 8bit Hi Pascal, Thanks for your comments. "Pascal Thubert (pthubert)" wrote: > > Hi: > > I'm getting a bit anxious about this discussion... My 3 cents of ˆ: > > 1) I believe it's great to have this discussion (and Alex's draft) for people to understand the dynamics of the protocols, but I hope this effort is not meant to lead to something in a standard document that would say if and how the routes are set up in the home link and the home AS - unless Nemo *needs* a new routing protocol, I mean. I believe that operators should be free to use static routes when they see fit, and a routing protocol when it covers their needs better. Yes, I think we need support for both static and dynamic routing. I was just focusing on the dynamic parts in my previous mails and comments. > > 2) I've read the 's' word ...scaling. Now, consider a home network with 10, 100, 1000, potentially 10000 or 100000 Mobile Routers. Why not? A home network could be a large community. I suspect that the routing fabric of the home AS may suffer some if routes are injected each time a MR binds, unbinds, leaves or returns home. Yes. What operators need is the freedom to choose the properties of the protocol. We can supply a number of alternatives. Does the MRs come home often? Routing protocols become more useful the more routers and subnets you have. Previously we had manual configuration as the only alternative, which is not interesting when the number of routers grow. Now a third alternative is to not run traditional routing protocols but let MIPv6 manage the routes. > > 3) Routing protocols on the MRHA tunnel expect at least a keep alive form of traffic. When the only available connectivity is mobile phone, like GSM data (paid by the duration) or GPRS (paid by the bytes transported), then this approach may be a bit costly for the user. It's up to the operator to decide. We can provide mechanisms. There will always be some amount of control traffic going on. /Mattias > > With Nemo, we may see arise a new form of routers. In one hand, some will be thin, low power, mass produced - not unlike mobile phones, and may not have routing protocol capabilities. On the other hand, Nemo may help companies manage (outsource, move physically) their production networks of traditional, large routers. > > Pascal From nemo-admin@nal.motlabs.com Tue Nov 12 11:21:23 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05078 for ; Tue, 12 Nov 2002 11:21:17 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGKSC16478; Tue, 12 Nov 2002 17:20:31 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGJbC16459 for ; Tue, 12 Nov 2002 17:19:39 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gACGJN0j014017; Tue, 12 Nov 2002 09:19:23 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA15452; Tue, 12 Nov 2002 09:19:22 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id gACGG3C29947; Tue, 12 Nov 2002 10:16:04 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8A3E12EC8B; Tue, 12 Nov 2002 17:16:08 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DCC2DD9.A065D171@iprg.nokia.com> Message-ID: Lines: 84 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 12 Nov 2002 17:16:08 +0100 Vijay Devarapalli writes: > > > 1. when the MR is it at home, it is running some kind of routing > > > protocol. so the home agent or the border router have routes to > > > it. > > > > It is possible to have an MR at home and not run routing protocol. I > > mean it is possible these days and you're surely keeping this in mind, > > but overlooking it somehow, that's why I'm continuing the discussion > > to see why. > > yes. it is possible, though I wouldnt manually create a route for > a router, which I know is mobile and could move away from the home > link. Yes, the possibility that that router disappears is rather high. Still, the kind of route we're talking about doesn't reflect change in the CoA. In other words, the route is "static", towards a fixed prefix, through a fixed ll address. When MR changes its CoA, the same route is there, no change in the route. Meaning that if the router is continuously changing its CoA, but always connected, the route we're talking about doesn't change, it's the same. > > > 2. when the MR is not at home and does not run a routing protocol > > > through the bi-directional tunnel, a route to the mobile network is > > > created when the MR sends a BU to the home agent. > > > > Yes, as in draft-kniveton. > > > > So the routing table is updated both by BUs and by RUs. How about the > > binding cache being updated both by BUs and RUs. > > binding cache is updated only by BUs. Yes, I understand that. And I'm trying to suggest that BUs that update the routing table is like RUs that update the binding cache. In a home domain the routing is currently done by RUs that update routing tables. When some home subnets or hosts (non-mobile) disappear, or some others (also non-mobile) appear, RUs updating routing tables manage to keep routing consistent. Add network mobility to the picture. Notice that routing tables will be updated both by RUs and by BUs. Ensure that those updates are consistent. This is probably more of an administrative issue, than a standardization issue, I agree with that; but I think that separating the semantics of RUs and BUs gives less place to administrative errors. > > > the MR is shut off!!! my cell phone (assuming its the MR for my PAN) > > > is not going to be up and running all the time. > > > > If MR is shut off then HA doesn't need a routing table entry either(!!!). > > > > right. thats why the HA needs to check if there is a route to > the mobile network when it receives a binding update from the > mobile router. if a route is not present, it has to create one. Yes, something like that. Note though that if the HA receives a BU from MR, it could as well receive an RU. > the home agent also has to make sure that packets meant for the > mobile network reach the home agent on the home link. your ICMP > redirect mechanism would be very useful here. the home agent > sends an ICMP redirect for the mobile network prefix to point > to itself. every router on the home link update their routing > tables to point to the home agent. this would work right? I think the HA will get all packets for the mobile network as long as HA defends the ll of the router. The problem will be how to route those packets towards the MR CoA, MR needs the route you're talking about. HA could get that route by various means, as you explained, plus the ICMP redirect. I think we're synchronized here. I dont understand why do you suggest that HA sends redirects though. I was thinking that HA sends redirects when the MR is not at home and HA represents MR, so it takes the role of the MR-at-home and sends that redirect (when the MR would need to send it). Another possibility would be for the MR to send the redirects on the home link, through the MRHA tunnel, when MR is not at home. All this, in case that MR would send a redirect when it were at home. Alex From nemo-admin@nal.motlabs.com Tue Nov 12 11:23:25 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05180 for ; Tue, 12 Nov 2002 11:23:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGO3C16524; Tue, 12 Nov 2002 17:24:03 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGLVC16494 for ; Tue, 12 Nov 2002 17:21:31 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gACGLL19005642; Tue, 12 Nov 2002 09:21:22 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA01419; Tue, 12 Nov 2002 09:21:21 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id gACGLGU11237; Tue, 12 Nov 2002 10:21:16 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1AB002EC86; Tue, 12 Nov 2002 17:21:16 +0100 (CET) To: Mattias Pettersson Cc: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCD35F3.E902A452@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DCD35F3.E902A452@era.ericsson.se> Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 12 Nov 2002 17:21:16 +0100 Mattias Pettersson writes: > > > When MR is home, BR, HA and MR all are attached to the same link. > > > HA------BR > > > | > > > MR > > > > > > When MR is away, MR is attached to HA through a link of type IP-in-IP > > > encapsulation. > > > HA------BR > > > || > > > MR Yes, this is right, I'm only starting to understand what you meant. > The HA doesn't have to store all routes to fixed subnets on the home > link although it participates in routing protocols. As long as it keeps > a default route to BR, it can reach them all. We both agree. > > The problem is that BR will send ICMP redirects for packets that HA send > with destinations that belong to subnets below BR. So HA end up having > to save these routes anyway (now in the form of host routes rather than > prefix routes, which consumes even more routing entries). Aha, I see the inconvenient of too many routes. Alex From nemo-admin@nal.motlabs.com Tue Nov 12 11:27:36 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05386 for ; Tue, 12 Nov 2002 11:27:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGS3C16570; Tue, 12 Nov 2002 17:28:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGRMC16557 for ; Tue, 12 Nov 2002 17:27:23 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gACGQs0j016419; Tue, 12 Nov 2002 09:26:54 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA18458; Tue, 12 Nov 2002 09:26:54 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id gACGQm802886; Tue, 12 Nov 2002 10:26:49 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 066322EC86; Tue, 12 Nov 2002 17:26:48 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: "Vijay Devarapalli", "Mattias Pettersson", "Nemo" Subject: Re: [nemo] Re: BU adds routes References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 12 Nov 2002 17:26:47 +0100 "Pascal Thubert (pthubert)" writes: > I'm getting a bit anxious about this discussion... My 3 cents of > \210: Is that \210 an euro? :-) > 1) I believe it's great to have this discussion (and Alex's draft) > for people to understand the dynamics of the protocols, but I hope > this effort is not meant to lead to something in a standard document > that would say if and how the routes are set up in the home link and > the home AS - unless Nemo *needs* a new routing protocol, I mean. I > believe that operators should be free to use static routes when they > see fit, and a routing protocol when it covers their needs better. Yes, exactly. The discussion can be interpreted as effective as long as for example it led to a proposal of a requirement (which is in-scope right now). Also, as the draft abstracts, I think there's a point to be made about what goes into a BU. > 2) I've read the 's' word ...scaling. Now, consider a home network > with 10, 100, 1000, potentially 10000 or 100000 Mobile Routers. Yes, sure; all 100000 cases are possible and all should be taken into account (the 1 as the 100000). Alex From nemo-admin@nal.motlabs.com Tue Nov 12 11:39:27 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05692 for ; Tue, 12 Nov 2002 11:39:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGZ3C16708; Tue, 12 Nov 2002 17:35:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACGYcC16694 for ; Tue, 12 Nov 2002 17:34:39 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gACGXM0j018463; Tue, 12 Nov 2002 09:33:22 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id JAA00705; Tue, 12 Nov 2002 09:33:21 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id gACGXFU20689; Tue, 12 Nov 2002 10:33:15 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8E4EF2EC8B; Tue, 12 Nov 2002 17:33:15 +0100 (CET) To: Mattias Pettersson Cc: "Pascal Thubert (pthubert)" , Vijay Devarapalli , Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DD0E24F.9A5E2509@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DD0E24F.9A5E2509@era.ericsson.se> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 12 Nov 2002 17:33:15 +0100 Mattias Pettersson writes: > Routing protocols become more useful the more routers and subnets > you have. Previously we had manual configuration as the only > alternative, which is not interesting when the number of routers > grow. Now a third alternative is to not run traditional routing > protocols but let MIPv6 manage the routes. The story is nice. I've problems digesting the end though :-) I'm not against this end, I'm just figuring that maybe many people will have many things to say about it. Or maybe it's just me. Alex From nemo-admin@nal.motlabs.com Tue Nov 12 13:40:59 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09873 for ; Tue, 12 Nov 2002 13:40:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACIg8C17944; Tue, 12 Nov 2002 19:42:08 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACIf1C17934 for ; Tue, 12 Nov 2002 19:41:01 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA20112; Tue, 12 Nov 2002 10:40:55 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gACIerA28886; Tue, 12 Nov 2002 10:40:53 -0800 X-mProtect: <200211121840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaRTi8r; Tue, 12 Nov 2002 10:40:52 PST Message-ID: <3DD14B34.B0802935@iprg.nokia.com> 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: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 10:40:52 -0800 Content-Transfer-Encoding: 7bit Hi Alexandru, Alexandru Petrescu wrote: > > I dont understand why do you suggest that HA sends redirects though. > > I was thinking that HA sends redirects when the MR is not at home and > HA represents MR, so it takes the role of the MR-at-home and sends > that redirect (when the MR would need to send it). Another > possibility would be for the MR to send the redirects on the home > link, through the MRHA tunnel, when MR is not at home. All this, in > case that MR would send a redirect when it were at home. take the following scenario. lets assume the MR is away from home, but has an active binding for both MR_HoA and MR_LinkLocal at the HA. a border router on the home link has a route to the mobile network pointing to the link local address of the MR. when a packet arrives at the border router meant for the mobile network, it is sent to the home agent because HA is proxying the link local address of the MR. the home agent then tunnels it to the MR through the tunnel interface (HA, MR_CoA). now assume the mobile router is switched off. after some time the binding cache entries at the HA expire. the HA stops proxying the link local address of the MR. the route at the border router *expires* (I dont believe much in static routes). the MR comes up and sends a binding update to the HA. the HA then starts proxying MR_LinkLocal and MR_HoA again. some node in the mobile network starts a session with a CN. there would be packets coming from the CN (meant for the mobile network) to the border router. the border router does not have a route to the mobile network. packets are dropped!!! how do we handle this? I was trying to figure out if the ICMP redirect mechanism could be used here by the HA to inform the border router that it can reach the mobile network. the whole thing would be much more simpler if the HA becomes the default router on the home link for all mobile routers at all times. comments? regards Vijay From nemo-admin@nal.motlabs.com Tue Nov 12 13:44:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09959 for ; Tue, 12 Nov 2002 13:44:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACIl2C17980; Tue, 12 Nov 2002 19:47:02 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACIkmC17970 for ; Tue, 12 Nov 2002 19:46:49 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA20433; Tue, 12 Nov 2002 10:46:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gACIkfq06410; Tue, 12 Nov 2002 10:46:41 -0800 X-mProtect: <200211121846> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxDz6Sg; Tue, 12 Nov 2002 10:46:39 PST Message-ID: <3DD14C90.A6A34DEA@iprg.nokia.com> 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: Mattias Pettersson , Alexandru Petrescu , Nemo Subject: Re: [nemo] Re: BU adds routes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 10:46:40 -0800 Content-Transfer-Encoding: 7bit hi Pascal, "Pascal Thubert (pthubert)" wrote: > > Hi: > > I'm getting a bit anxious about this discussion... My 3 cents of ^: > > 1) I believe it's great to have this discussion (and Alex's draft) for people to > understand the dynamics of the protocols, but I hope this effort is not meant to > lead to something in a standard document that would say if and how the routes are > set up in the home link and the home AS - unless Nemo *needs* a new routing > protocol, I mean. I believe that operators should be free to use static routes > when they see fit, and a routing protocol when it covers their needs better. you are right that the operators should be given freedom to do what they want. on the other hand, we need to nail down the details for the basic case. it is not enough to say use a bi-directional tunnel between the MR and the HA. I think this discussion is a good start. regards Vijay From nemo-admin@nal.motlabs.com Tue Nov 12 14:23:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11107 for ; Tue, 12 Nov 2002 14:23:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACJP3C18498; Tue, 12 Nov 2002 20:25:03 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACJOuC18486 for ; Tue, 12 Nov 2002 20:24:57 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gACJP2w4002265; Tue, 12 Nov 2002 12:25:02 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA18872; Tue, 12 Nov 2002 12:20:51 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id gACJOoH15315; Tue, 12 Nov 2002 13:24:50 -0600 Received: from motorola.com (zfr03-0047.crm.mot.com [140.101.173.54]) by thorgal.crm.mot.com (Postfix) with ESMTP id E8D8D2EC86; Tue, 12 Nov 2002 20:24:47 +0100 (CET) Message-ID: <3DD1546B.8030106@motorola.com> From: Miguel Catalina Gallego User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Alexandru Petrescu, Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> <3DD14B34.B0802935@iprg.nokia.com> X-Enigmail-Version: 0.65.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 20:20:11 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > take the following scenario. lets assume the MR is away from home, > but has an active binding for both MR_HoA and MR_LinkLocal at the > HA. a border router on the home link has a route to the mobile > network pointing to the link local address of the MR. when a packet > arrives at the border router meant for the mobile network, it is > sent to the home agent because HA is proxying the link local address > of the MR. the home agent then tunnels it to the MR through the > tunnel interface (HA, MR_CoA). > > now assume the mobile router is switched off. after some time the > binding cache entries at the HA expire. the HA stops proxying the > link local address of the MR. the route at the border router > *expires* (I dont believe much in static routes). > > the MR comes up and sends a binding update to the HA. the HA then > starts proxying MR_LinkLocal and MR_HoA again. some node in the > mobile network starts a session with a CN. there would be packets > coming from the CN (meant for the mobile network) to the border > router. the border router does not have a route to the mobile > network. packets are dropped!!! how do we handle this? If the routes have expired at the BR it will not be able to route the packet, even if the HA has the correct routes. Maybe it is reasonable to assume that the MR will send RUs when reconnecting after a long time disconnected. > I was > trying to figure out if the ICMP redirect mechanism could be used > here by the HA to inform the border router that it can reach the > mobile network. It is reasonable, IMO. > the whole thing would be much more simpler if the HA becomes the > default router on the home link for all mobile routers at all > times. The issue is still the same, IMO. If the routes expire at the BR then we need a way of refreshing them. Either the HA propagates the routing information it has received in a BU or through an RU from the MR, or the MR sends RUs directly to it. In any case the routes in the BR will not refreshed immediately. Also, maybe the HA could treat routes pointing to the MR in a different way and avoid making them expire (or setting different expiration timeouts). The HA would continue to send RUs to the BR with the routes to the MR. If the BU to the MR has expired, then the HA should just drop any packets it receives. This mixes binding cache and routing table a little bit, I am not sure if it is a good idea. Regards, Miguel > comments? > > regards > Vijay > -- Miguel CATALINA GALLEGO Centre de Recherche de Motorola - Paris Miguel.Catalina@motorola.com Tel: +33 (0) 1 69 35 25 41 From nemo-admin@nal.motlabs.com Tue Nov 12 14:57:00 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12539 for ; Tue, 12 Nov 2002 14:56:59 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACJw4C18676; Tue, 12 Nov 2002 20:58:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gACJvbC18666 for ; Tue, 12 Nov 2002 20:57:37 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24442; Tue, 12 Nov 2002 11:57:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gACJvSa02326; Tue, 12 Nov 2002 11:57:28 -0800 X-mProtect: <200211121957> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.138, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFDqdOj; Tue, 12 Nov 2002 11:57:27 PST Message-ID: <3DD15D27.2040702@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Miguel Catalina Gallego CC: Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 12 Nov 2002 11:57:27 -0800 Content-Transfer-Encoding: 7bit Hi Miguel, I guess I wasnt clear in my earlier mail. we were dicussing only one particular scenario. heres the text from an earlier mail. > 2. when the MR is not at home and does not run a routing protocol > through the bi-directional tunnel, a route to the mobile network > is created when the MR sends a BU to the home agent. > > 3. when the MR is not at home, but does run a routing protocol > through the bi-directional tunnel, a route to the mobile network > is created when the MR sends routing updates. we were discussing (2). if the route to the mobile network was not created at the HA through a routing protocol update, it is not included in HA's routing protocol updates. so we need a mechanism here for the HA to inform the border router that it can reach the MR. so I was trying to see if ICMP re-directs could be used here. for (3), it works naturally. when the HA receives routing updates from the MR, it re-broadcasts the routes in its routing updates. the border router then creates a route to the mobile network to point to the home agent. regards Vijay Miguel Catalina Gallego wrote: > > Hi Vijay, > > Vijay Devarapalli wrote: > >> take the following scenario. lets assume the MR is away from home, >> but has an active binding for both MR_HoA and MR_LinkLocal at the >> HA. a border router on the home link has a route to the mobile network >> pointing to the link local address of the MR. when a packet >> arrives at the border router meant for the mobile network, it is >> sent to the home agent because HA is proxying the link local address >> of the MR. the home agent then tunnels it to the MR through the tunnel >> interface (HA, MR_CoA). >> >> now assume the mobile router is switched off. after some time the >> binding cache entries at the HA expire. the HA stops proxying the link >> local address of the MR. the route at the border router *expires* (I >> dont believe much in static routes). >> >> the MR comes up and sends a binding update to the HA. the HA then >> starts proxying MR_LinkLocal and MR_HoA again. some node in the >> mobile network starts a session with a CN. there would be packets >> coming from the CN (meant for the mobile network) to the border >> router. the border router does not have a route to the mobile network. >> packets are dropped!!! how do we handle this? > > > If the routes have expired at the BR it will not be able to route the > packet, even if the HA has the correct routes. > > Maybe it is reasonable to assume that the MR will send RUs when > reconnecting after a long time disconnected. > >> I was >> trying to figure out if the ICMP redirect mechanism could be used here >> by the HA to inform the border router that it can reach the mobile >> network. > > > It is reasonable, IMO. > >> the whole thing would be much more simpler if the HA becomes the >> default router on the home link for all mobile routers at all times. > > > The issue is still the same, IMO. If the routes expire at the BR then we > need a way of refreshing them. Either the HA propagates the routing > information it has received in a BU or through an RU from the MR, or the > MR sends RUs directly to it. In any case the routes in the BR will not > refreshed immediately. > > Also, maybe the HA could treat routes pointing to the MR in a different > way and avoid making them expire (or setting different expiration > timeouts). The HA would continue to send RUs to the BR with the routes > to the MR. If the BU to the MR has expired, then the HA should just drop > any packets it receives. This mixes binding cache and routing table a > little bit, I am not sure if it is a good idea. > > Regards, > > Miguel > >> comments? >> >> regards >> Vijay >> > > > > From nemo-admin@nal.motlabs.com Wed Nov 13 03:37:42 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24741 for ; Wed, 13 Nov 2002 03:37:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAD8G6C22596; Wed, 13 Nov 2002 09:16:06 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAD8ExC22581 for ; Wed, 13 Nov 2002 09:15:00 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E361A5D0AD; Wed, 13 Nov 2002 17:14:49 +0900 (JST) Message-Id: <20021113.171449.123585622.ernst@sfc.wide.ad.jp> To: behcet.sarikaya@alcatel.com, nemo@nal.motlabs.com Subject: Re: [nemo] my list of compiled requirements From: Thierry Ernst In-Reply-To: <3DCAFCBB.1010907@alcatel.com> References: <20021107094038.8515.TAKESHI.TANAKA@yrp.mci.mei.co.jp> <3DCAFCBB.1010907@alcatel.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 17:14:49 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Behcet, all Sorry, I don't catch what you recommend in your past emails on this thread (which I have appended in this mail). I don't think that the AAA draft should be considered separately (at least not for the reason you state). It states high level requirements, so do most of the other drafts. May be at the meeting we can split the requirement discussion into 2 slots: - 1st to discuss high level requirements (included the AAA and all other requirements) - 2nd to itemize the requirements in the "versets" fashion as proposed by Pascal. (which I tried to do in the new section of my own draft, but partly only) Thierry From: Behcet Sarikaya > Your draft reads nicely, and it is useful. I think the most important > message in it is that MR must have an AAA client. Maybe there are > prospects for more future work in this domain possibly to be pursued in > AAA WG. > However as you said the draft does not address any requirements on the > base NEMO solution. > My 2 cents. > > Takeshi TANAKA wrote: > > >Hi, > > > >We would like to explain about "draft-ng-nemo-aaa-use-00.txt". > >Sorry for doing so late. > > > >Since NEMO is largely applicable to commercial use, we think we should > >consider about AAA operation from beginning of considering about NEMO > >solutions. > > > >This draft described/categolized NEMO usage scenarios from commercial > >point of view, and listed requirements for AAA functionalities in NEMO. > >I.e. this draft describes about requirements for AAA aspect of NEMO, > >so that routing aspect of NEMO does not preclude requirements for AAA side. Behcet 11-05: >draft-ng-nemo-aaa-use-00.txt > >is on the AAA aspect not on the solution to the base mobility which is >expected to be an IP layer solution. I do not think that these two can >be stated in a single draft. That's why I suggested separating the AAA >use draft from the others. Behcet 11-04: > All others except > >draft-ng-nemo-aaa-use-00.txt > >state requirements for the base nemo solution, however this one does >not, IMHO. draft-ng-nemo-aaa-use does not either state security >requirements, it probably deserves to be treated separately on its own, >much like the case in Mobile IP. From nemo-admin@nal.motlabs.com Wed Nov 13 03:52:19 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24933 for ; Wed, 13 Nov 2002 03:52:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAD8Y2C22685; Wed, 13 Nov 2002 09:34:02 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAD8XgC22674 for ; Wed, 13 Nov 2002 09:33:43 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2C6745D090 for ; Wed, 13 Nov 2002 17:33:36 +0900 (JST) Message-Id: <20021113.173335.63241708.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Re: Can HA be a host? From: Thierry Ernst In-Reply-To: <3DCD3267.193DB57B@era.ericsson.se> References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 17:33:35 +0900 (JST) Content-Transfer-Encoding: 7bit Why should we make the things more complicated that it is already ? Let's stick to the definition of HA as stated in MIPv6 so we don't need to state in NEMO requirements whether it is a host or a router. Conceptually, a HA is a router, and this is what MIPv6 is all about. Thierry Mattias: > And for the definition of what is a router (from RFC 2460): > router - a node that forwards IPv6 packets not explicitly > addressed to itself. > > We're not talking about an expensive rack of hardware specially designed > for routing. A router is a function. If the input function processing of > the stack doesn't drop packets that have a destination address other > than those belonding to the node itself, it is a router by definition. > > It is possible for a router to have only one physical interface. From nemo-admin@nal.motlabs.com Wed Nov 13 05:31:00 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26871 for ; Wed, 13 Nov 2002 05:30:59 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADAL3C23217; Wed, 13 Nov 2002 11:21:03 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADAK1C23206 for ; Wed, 13 Nov 2002 11:20:01 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 316365D018 for ; Wed, 13 Nov 2002 19:17:38 +0900 (JST) Message-Id: <20021113.191737.45278866.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes From: Thierry Ernst In-Reply-To: <3DD14C90.A6A34DEA@iprg.nokia.com> References: <3DD14C90.A6A34DEA@iprg.nokia.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 19:17:37 +0900 (JST) Content-Transfer-Encoding: 7bit Let me try to see if I understand things right: MR at home: HA------BR | MR MR away: HA------BR | <- tunnel looks like a link MR If MR runs a routing protocol: 1. At home, BR and MR are neighbors, so are HA and MR 2. MR moves and obtains CoA 3. Bidirectional tunnel established between MR and HA. - The bidirectional tunnel looks like a link between MR and HA - A route to MR with high timeout is added in the routing table of the HA - MR and BR are not neighbors anymore, but MR and HA still are - MR sends UNFREQUENT RUs over the tunnel (before routing entry times out) - HA sends UNFREQUENT RUs (i.e. it does NOT relay RUs sent by BR) 4. Binding Cache at the HA: - MR sends MIPv6 BU containing CoA - HA add entry in the BC - MR keeps sending BUs with current CoA REGULARLY (before BC entry times out) - HA updates BC 5. If MR is shutoff no more than routing_table_timeout, BC entry is removed but routing entry is maintained in the home network. HA drop packets since no BC entry. If MR does not run a routing protocol: - tunnel is established permanently (high timer) - do not send RUs over the tunnel in either directions -> the only thing we need to do is to specify how the tunnel should be established (in a secure way) maintained, and deleted. MIPv6 does not need to be changed. Can we use existing mechanisms to set up the tunnel ? How ? Thierry From nemo-admin@nal.motlabs.com Wed Nov 13 07:14:57 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28427 for ; Wed, 13 Nov 2002 07:14:56 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADCG3C23984; Wed, 13 Nov 2002 13:16:03 +0100 Received: from web10004.mail.yahoo.com (web10004.mail.yahoo.com [216.136.130.40]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gADCFdC23973 for ; Wed, 13 Nov 2002 13:15:39 +0100 Message-ID: <20021113121534.50093.qmail@web10004.mail.yahoo.com> Received: from [202.224.189.50] by web10004.mail.yahoo.com via HTTP; Wed, 13 Nov 2002 04:15:34 PST From: ChanWah Ng Reply-To: cwng@psl.com.sg Subject: AAA requirements (was Re: [nemo] my list of compiled requirements) To: nemo@nal.motlabs.com In-Reply-To: <20021113.171449.123585622.ernst@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 04:15:34 -0800 (PST) Hi all, let me just try to clarify things a bit. The AAA draft was started because we see that AAA is the important factor in comercial consideration. We started the draft to explore any AAA issues that are particular about NEMO. And indeed we found some. 8 requirements are stated in the draft. Some are geared towards requirements on a AAA solution, some are requirements on NEMO nodes. Since they are high-level requirements, I believe some "basic-nemo-specific" requiremnts can be drawn from them. The appropriate approach, IMHO, is to take a look at each high-level requirement and draw specifc requirements from there. I think Alex's list is a good summary. Having said that, I agree that AAA and mobility support should be separate. Forgive me if I've mistaken, but I would imagine the AAA/EAP/PANA WG will expect the NEMO WG to come up with a document on requirements on AAA solution for NEMO. /rgds /cwng --- Thierry Ernst wrote: > > Hi Behcet, all > > Sorry, I don't catch what you recommend in your past emails on this > thread (which I have appended in this mail). > > I don't think that the AAA draft should be considered separately (at > least not for the reason you state). It states high level > requirements, so do most of the other drafts. > > May be at the meeting we can split the requirement discussion into 2 > slots: > > - 1st to discuss high level requirements (included the AAA and all > other requirements) > > - 2nd to itemize the requirements in the "versets" fashion as proposed > by Pascal. (which I tried to do in the new section of my own draft, > but partly only) > > Thierry > > > > From: Behcet Sarikaya > > Your draft reads nicely, and it is useful. I think the most important > > message in it is that MR must have an AAA client. Maybe there are > > prospects for more future work in this domain possibly to be pursued in > > AAA WG. > > However as you said the draft does not address any requirements on the > > base NEMO solution. > > My 2 cents. > > > > Takeshi TANAKA wrote: > > > > >Hi, > > > > > >We would like to explain about "draft-ng-nemo-aaa-use-00.txt". > > >Sorry for doing so late. > > > > > >Since NEMO is largely applicable to commercial use, we think we should > > >consider about AAA operation from beginning of considering about NEMO > > >solutions. > > > > > >This draft described/categolized NEMO usage scenarios from commercial > > >point of view, and listed requirements for AAA functionalities in NEMO. > > >I.e. this draft describes about requirements for AAA aspect of NEMO, > > >so that routing aspect of NEMO does not preclude requirements for AAA side. > > Behcet 11-05: > >draft-ng-nemo-aaa-use-00.txt > > > >is on the AAA aspect not on the solution to the base mobility which is > >expected to be an IP layer solution. I do not think that these two can > >be stated in a single draft. That's why I suggested separating the AAA > >use draft from the others. > > Behcet 11-04: > > All others except > > > >draft-ng-nemo-aaa-use-00.txt > > > >state requirements for the base nemo solution, however this one does > >not, IMHO. draft-ng-nemo-aaa-use does not either state security > >requirements, it probably deserves to be treated separately on its own, > >much like the case in Mobile IP. > > > __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 From nemo-admin@nal.motlabs.com Wed Nov 13 07:30:06 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28828 for ; Wed, 13 Nov 2002 07:30:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADCW3C24142; Wed, 13 Nov 2002 13:32:03 +0100 Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADCV6C24127 for ; Wed, 13 Nov 2002 13:31:06 +0100 Received: by bulls.mei.co.jp (8.12.5/3.7W/jazz) with ESMTP id gADCV1Ln019833; Wed, 13 Nov 2002 21:31:01 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id gADCV4B17627; Wed, 13 Nov 2002 21:31:04 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id gADCV1C12016; Wed, 13 Nov 2002 21:31:01 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:02091217) id gADCV2501173; Wed, 13 Nov 2002 21:31:02 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id gADCUwL14022; Wed, 13 Nov 2002 21:30:58 +0900 (JST) Received: from [133.183.211.75] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7W-TELECOM) with ESMTP id gADCV1n05237; Wed, 13 Nov 2002 21:31:01 +0900 (JST) From: Takeshi TANAKA To: Thierry Ernst , IETF NEMO In-Reply-To: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> Message-Id: <20021113211225.A944.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Subject: [nemo] Comments on draft-ernst-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 21:31:46 +0900 Content-Transfer-Encoding: 7bit Hi, Thierry and all, Following are comments for draft-ernst-nemo-requirements-00.txt. R5: CNs and MNNs must comply with the requirements for IPv6 nodes defined in [IPv6-NODE] =>All IPv6 nodes comply with IPv6 node requirements, it is not requirements for NEMO. R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to MNNs) =>"The solution must support nodes that are not NEMO-enabled" or "The solution must not impact on MNNs" is better since MNN may be also MR...as someone said. R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) =>"The solution must not impact on CNs" is better since CN may be also MR. R8: A VMN that gets attached to a link within the mobile network obtains an address on that link. =>Which requirements does this imply? R10: The solution MUST support multi-homed mobile network R10.1 : The solution MUST support mobile networks with multiple MRs R10.2: The solution MUST support MR with multiple interfaces =>"The solution must support MR with multiple global addresses on egress interface" should also be added. R12: The solution MUST support a large number of mobile networks R12: The solution MUST support a large number of CNs => duplicated number. R13: The solution MUST support vertical handoff R14: The solution MUST support horizontal handoff => What do "vertical handoff" and "horizonal handoff" mean? R17: The solution MUST support heterogeneous mobility => What does "heterogeneous mobility" mean? ------------ Takeshi From nemo-admin@nal.motlabs.com Wed Nov 13 07:36:33 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28919 for ; Wed, 13 Nov 2002 07:36:31 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADCc3C24192; Wed, 13 Nov 2002 13:38:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADCb1C24178 for ; Wed, 13 Nov 2002 13:37:01 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gADCavCb002540; Wed, 13 Nov 2002 05:36:58 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA26327; Wed, 13 Nov 2002 05:36:57 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id gADCauW12393; Wed, 13 Nov 2002 06:36:56 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3B9022EC86; Wed, 13 Nov 2002 13:36:52 +0100 (CET) To: Vijay Devarapalli Cc: Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> <3DD14B34.B0802935@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DD14B34.B0802935@iprg.nokia.com> Message-ID: Lines: 44 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Nov 2002 13:36:52 +0100 Vijay Devarapalli writes: > the MR comes up and sends a binding update to the HA. the HA then > starts proxying MR_LinkLocal and MR_HoA again. some node in the > mobile network starts a session with a CN. there would be packets > coming from the CN (meant for the mobile network) to the border > router. the border router does not have a route to the mobile > network. packets are dropped!!! how do we handle this? Maybe TCP will retransmit? I see your point. Propagation of disappearing routes can hurt indeed. If the MR is turned off for an extended period of time then BR will loose the route, and BR2 and BR3 further up the stream will loose them as well. Up to BR4 that has a prefix covering the prefix of MR. Then when MR is back on, it might take some time to propagate the re-addition of this old route within the entire domain. And during all this time packets from CN towards LFNs are being dropped. But. Maybe this is no different than MR being at home and being turned off for other reasons than mobility. If MR is at home and is turned off, then the routing protocol will manage this situation, for better or for worse. If MR is _not_ at home and is turned off, it must be as if it were at home and turned off, so it is the same routing protocol that will manage this, for the same better or worse. Maybe we're on the same wavelength here. > I was trying to figure out if the ICMP redirect mechanism could be > used here by the HA to inform the border router that it can reach > the mobile network. Aha, I see, yes might be interesting. So with this, even if the MR is turned off, the HA would still get packets addressed to LFNs and might have an opportunity to cache them until the MR is turned back on? A sort of optimization? > the whole thing would be much more simpler if the HA becomes the > default router on the home link for all mobile routers at all > times. I guess so. The problem is that we can't turn it into a requirement... Alex From nemo-admin@nal.motlabs.com Wed Nov 13 09:19:07 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01982 for ; Wed, 13 Nov 2002 09:19:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADEG3C24818; Wed, 13 Nov 2002 15:16:03 +0100 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADEFbC24806 for ; Wed, 13 Nov 2002 15:15:37 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04440; Wed, 13 Nov 2002 07:15:34 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gADEFXL03698; Wed, 13 Nov 2002 15:15:33 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) To: Vijay Devarapalli Cc: Alexandru Petrescu , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" <3DCC02D0.FE71B30F@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 15:12:28 +0100 (CET) > why would you manually add a static route? this will not scale IMO. That depends on how you are going to determine which MR is authorized to inject routes for which prefixes. The simple way to do this is to have a table with MR identities (in the form of the security associations for the tunnels or something else with cryptographic binding to the actual MR), and a list of allowed prefixes the MR can advertise. That information is exactly the information you need for creating the static routes. Of course, I can see a need in some cases for being able to automate the initial assignment of prefixes to MRs. Perhaps the ideas in the prefix delegation space in the IPv6 WG can be used for this, assuming there is sufficient understanding of the security issues of doing such prefix delegation to an MR that is away from home. Erik From nemo-admin@nal.motlabs.com Wed Nov 13 10:09:43 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04058 for ; Wed, 13 Nov 2002 10:09:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADFB3C25093; Wed, 13 Nov 2002 16:11:03 +0100 Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADFANC25082 for ; Wed, 13 Nov 2002 16:10:23 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gADFAHhX026387; Wed, 13 Nov 2002 09:10:18 -0600 (CST) Message-ID: <3DD26B91.1040800@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cwng@psl.com.sg CC: nemo@nal.motlabs.com Subject: Re: AAA requirements (was Re: [nemo] my list of compiled requirements) References: <20021113121534.50093.qmail@web10004.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 09:11:13 -0600 Content-Transfer-Encoding: 7bit Hi ChanWah, ChanWah Ng wrote: >Hi all, > >let me just try to clarify things a bit. The AAA draft was started because we see that >AAA is the important factor in comercial consideration. We started the draft to explore >any AAA issues that are particular about NEMO. And indeed we found some. > >8 requirements are stated in the draft. Some are geared towards requirements on a AAA >solution, some are requirements on NEMO nodes. Since they are high-level requirements, I >believe some "basic-nemo-specific" requiremnts can be drawn from them. The appropriate >approach, IMHO, is to take a look at each high-level requirement and draw specifc >requirements from there. I think Alex's list is a good summary. > >Having said that, I agree that AAA and mobility support should be separate. Forgive me >if I've mistaken, but I would imagine the AAA/EAP/PANA WG will expect the NEMO WG to come >up with a document on requirements on AAA solution for NEMO. > > Absolutely. If you consider Mobile IP WG example, requirements on the AAA solution was done in MIP WG and the solution in AAA WG. I think this is the issue: requirements on the AAA solution for NEMO should be a separate document or it should be considered part of the requirements for NEMO solution. I argued for the former. However if we combine them we are going to be following the charter more closely, this could be an advantage for the latter approach. What do people think? >/rgds >/cwng > >--- Thierry Ernst wrote: > > >>Hi Behcet, all >> >>Sorry, I don't catch what you recommend in your past emails on this >>thread (which I have appended in this mail). >> >>I don't think that the AAA draft should be considered separately (at >>least not for the reason you state). It states high level >>requirements, so do most of the other drafts. >> >>May be at the meeting we can split the requirement discussion into 2 >>slots: >> >>- 1st to discuss high level requirements (included the AAA and all >> other requirements) >> >>- 2nd to itemize the requirements in the "versets" fashion as proposed >> by Pascal. (which I tried to do in the new section of my own draft, >> but partly only) >> >>Thierry >> >> >> >>From: Behcet Sarikaya >> >> >>> Your draft reads nicely, and it is useful. I think the most important >>>message in it is that MR must have an AAA client. Maybe there are >>>prospects for more future work in this domain possibly to be pursued in >>>AAA WG. >>> However as you said the draft does not address any requirements on the >>>base NEMO solution. >>> My 2 cents. >>> >>>Takeshi TANAKA wrote: >>> >>> >>> >>>>Hi, >>>> >>>>We would like to explain about "draft-ng-nemo-aaa-use-00.txt". >>>>Sorry for doing so late. >>>> >>>>Since NEMO is largely applicable to commercial use, we think we should >>>>consider about AAA operation from beginning of considering about NEMO >>>>solutions. >>>> >>>>This draft described/categolized NEMO usage scenarios from commercial >>>>point of view, and listed requirements for AAA functionalities in NEMO. >>>>I.e. this draft describes about requirements for AAA aspect of NEMO, >>>>so that routing aspect of NEMO does not preclude requirements for AAA side. >>>> >>>> >>Behcet 11-05: >> >> >>>draft-ng-nemo-aaa-use-00.txt >>> >>>is on the AAA aspect not on the solution to the base mobility which is >>>expected to be an IP layer solution. I do not think that these two can >>>be stated in a single draft. That's why I suggested separating the AAA >>>use draft from the others. >>> >>> >>Behcet 11-04: >> >> >>>All others except >>> >>>draft-ng-nemo-aaa-use-00.txt >>> >>>state requirements for the base nemo solution, however this one does >>>not, IMHO. draft-ng-nemo-aaa-use does not either state security >>>requirements, it probably deserves to be treated separately on its own, >>>much like the case in Mobile IP. >>> >>> >> >> >> -- Behcet From nemo-admin@nal.motlabs.com Wed Nov 13 11:00:32 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05921 for ; Wed, 13 Nov 2002 11:00:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADG26C25453; Wed, 13 Nov 2002 17:02:06 +0100 Received: from chinapolyglot.com ([202.106.155.97]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADG1YC25439 for ; Wed, 13 Nov 2002 17:01:45 +0100 Received: from DellXP [210.21.107.131] by chinapolyglot.com with ESMTP (SMTPD32-7.06) id A6ADA84016A; Wed, 13 Nov 2002 23:58:37 +0800 Message-ID: <418-220021131316117510@DellXP> Organization: Polyglot Ltd From: "Polyglot" To: nemo@nal.motlabs.com MIME-Version: 1.0 Content-type: text/plain; charset=utf-7 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gADG1YC25439 Subject: [nemo] Polyglot Translation Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 00:01:17 +0800 Content-Transfer-Encoding: 8bit Polyglot Translation Polyglot is a professional multilingual solutions provider. Our rich experience and professional team established us as a leader in the field of multilingual solutions. Polyglot can provide fast and accurate translations of financial, legal and technical documents on over 30 languages, such as English, German, Spanish, French, Italian, Chinese, Japanese, Korean, etc. We also provide software localization, website localization, simultaneous and consecutive interpretation for international meetings. For further information, please visit our website: http://www.polyglot.com.cn Contact us at: E-mail: info+AEA-polyglot.com.cn Tel: +-86 20 8657-3608 Fax: +-86 20 8657-3965 Add: 968 Office Tower, Central Hotel 33 Airport Road Guangzhou, China The message below is written in Chinese characters: +T916y0/hf/uL0VFsU/g- +T916y0/hf/uL0VFsU/hmL04AW7Zj0E+bWRp5zYvtigCJ41GzZbloSHaEThNOGmc6Z4QwAk4wW8x2hH7PmoxTyg- +ThNOGnaElh9PDXhuestOhmIRTuxXKFkaec2L7YoAieNRs2W5aEiYhlffdoSYhlFIVzBPTTAC- +YhFO7ID9Y9BPmw-30+WRp5zYvtigB2hFHGeG4wAV/rY3d2hH/7i9FnDVKh/wx/+4vRmIZX322JU8qR0YeNZYdO9jAB- +bNVfi2WHTvZTymKAZy9lh072/wx/+4vRi+15zVMFYuz/GoLxMAFftzABiX8wAWzVMAFhDzABTi0wAWXlMAGX6XtJe0kwAg- +a2RZFv8MYhFO7I/YY9BPm49vTvZnLFcwUxYwAX9RetlnLFcwUxYwAVb9lkVPGouudoRUDFjwTyCL0VSMTqRm/08gi9EwAg- +UXNOjovmYMX/DIv3i7+V7mIRTux2hH9RV0D/Gg- http://www.polyglot.com.cn +gFR8+2W5Xw//Gg- +dTWQrg-: info+AEA-polyglot.com.cn +dTWL3Q-: (86-20) 8657 3608 +TyB3Hw-: (86-20) 8657 3965 +VzBXQP8aTi1W/V5/Xd5nOlc6je8-33+U/c- +Ti1ZLpFSXpdRmVtXaXw-968 +kK5/Fv8a-510403 From nemo-admin@nal.motlabs.com Wed Nov 13 12:50:24 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10378 for ; Wed, 13 Nov 2002 12:50:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADHq5C28228; Wed, 13 Nov 2002 18:52:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADHpgC28218 for ; Wed, 13 Nov 2002 18:51:42 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA22670; Wed, 13 Nov 2002 09:51:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADHpYk03818; Wed, 13 Nov 2002 09:51:34 -0800 X-mProtect: <200211131751> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiYF3TI; Wed, 13 Nov 2002 09:51:33 PST Message-ID: <3DD29125.7D29975C@iprg.nokia.com> 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: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> <3DD14B34.B0802935@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 09:51:33 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > I see your point. Propagation of disappearing routes can hurt indeed. > If the MR is turned off for an extended period of time then BR will > loose the route, and BR2 and BR3 further up the stream will loose them > as well. Up to BR4 that has a prefix covering the prefix of MR. actually no. if we assume that the mobile router's prefix belongs to the home link prefix, its only the border router in the home link. I think it is a safe assumption to make. so BR2 and BR3 alway route to BR1 whenever they get a packet for the mobile router's prefix. it shouldnt matter if the MR is up or shut off. Vijay From nemo-admin@nal.motlabs.com Wed Nov 13 12:54:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10567 for ; Wed, 13 Nov 2002 12:54:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADHv3C28259; Wed, 13 Nov 2002 18:57:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADHuYC28249 for ; Wed, 13 Nov 2002 18:56:35 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA22861; Wed, 13 Nov 2002 09:56:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADHuRQ09975; Wed, 13 Nov 2002 09:56:27 -0800 X-mProtect: <200211131756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdw6sd5M; Wed, 13 Nov 2002 09:56:25 PST Message-ID: <3DD29249.4109133C@iprg.nokia.com> 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: Miguel Catalina Gallego CC: Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <1036591697.3dc92251be62a@imp.free.fr> <3DC962AD.8BC028DB@iprg.nokia.com> <3DCC02D0.FE71B30F@iprg.nokia.com> <3DCC2DD9.A065D171@iprg.nokia.com> List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 09:56:25 -0800 Content-Transfer-Encoding: 7bit Miguel Catalina Gallego wrote: > Ok, now I see. It seems reasonable. But ICMPv6 (RFC2461) seems quite > strict regarding the validation of ICMP redirects. Also, if the routes > to the Mobile Network via the MR have expired redirects would not be > enough, right? if the route to the Mobile Network has expired on the HA, there is no need to keep the route active on the border router either (IMO). the mobile router is simply unreachable. > Is the HA running a routing protocol with the BR? If it is, then it > would send an unsolicited RU to the BR. this unsoliticied RU will not contain the route to the Mobile Network, if the HA does not have a valid route to the Mobile Network. Vijay From nemo-admin@nal.motlabs.com Wed Nov 13 13:15:20 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11224 for ; Wed, 13 Nov 2002 13:15:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIH3C28353; Wed, 13 Nov 2002 19:17:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIG9C28343 for ; Wed, 13 Nov 2002 19:16:09 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24630; Wed, 13 Nov 2002 10:16:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADIFvj11954; Wed, 13 Nov 2002 10:15:57 -0800 X-mProtect: <200211131815> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduBnXLf; Wed, 13 Nov 2002 10:15:56 PST Message-ID: <3DD296DC.303375BF@iprg.nokia.com> 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: Erik Nordmark CC: Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 10:15:56 -0800 Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > > why would you manually add a static route? this will not scale IMO. > > That depends on how you are going to determine which MR is authorized > to inject routes for which prefixes. > > The simple way to do this is to have a table with MR identities > (in the form of the security associations for the tunnels or something > else with cryptographic binding to the actual MR), and a list > of allowed prefixes the MR can advertise. this is what we do in our implementation. but the static route is not created until the HA receives a binding update from the MR. and when the MR deregisters or when the binding cache entry expires, the static route is removed. but we dont create it manually. there are two scenarios in draft-kniveton-mobrtr. in the first, the MR does not run a routing protocol through the bi-directional tunnel. so we do the above in the first scenario. in the second scenario, the MR sends routing updates through the bi-directional tunnel. creating a route is not tied to the binding update in this scenario. but the authorization check (to see if a particular MR is allowed a particular prefix) is still needed. Vijay From nemo-admin@nal.motlabs.com Wed Nov 13 13:29:05 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11758 for ; Wed, 13 Nov 2002 13:29:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIV3C28414; Wed, 13 Nov 2002 19:31:03 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIU8C28404 for ; Wed, 13 Nov 2002 19:30:08 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gADIR2UH020218 for ; Wed, 13 Nov 2002 11:27:03 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA27494 for ; Wed, 13 Nov 2002 11:26:03 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id gADITx827570; Wed, 13 Nov 2002 12:30:00 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 071F72EC86; Wed, 13 Nov 2002 19:29:59 +0100 (CET) To: Erik Nordmark Cc: Vijay Devarapalli, Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Nov 2002 19:29:59 +0100 Erik Nordmark writes: > > why would you manually add a static route? this will not scale IMO. > > That depends on how you are going to determine which MR is authorized > to inject routes for which prefixes. > > The simple way to do this is to have a table with MR identities > (in the form of the security associations for the tunnels or something > else with cryptographic binding to the actual MR), and a list > of allowed prefixes the MR can advertise. I don't understand the need to authorize which MR advertises which prefix. I was thinking that MRs are trusted by the HA because they had that IPsec tunnel. So if the MRs share keys with the HA then they can also advertise routes through the HA? Alex From nemo-admin@nal.motlabs.com Wed Nov 13 13:41:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12087 for ; Wed, 13 Nov 2002 13:41:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIh3C28538; Wed, 13 Nov 2002 19:43:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIgcC28528 for ; Wed, 13 Nov 2002 19:42:39 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25984; Wed, 13 Nov 2002 10:42:32 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADIgUm12718; Wed, 13 Nov 2002 10:42:30 -0800 X-mProtect: <200211131842> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSotTcZ; Wed, 13 Nov 2002 10:42:28 PST Message-ID: <3DD29D15.B125B2A1@iprg.nokia.com> 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: Alexandru Petrescu CC: Erik Nordmark , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 10:42:29 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Erik Nordmark writes: > > > why would you manually add a static route? this will not scale IMO. > > > > That depends on how you are going to determine which MR is authorized > > to inject routes for which prefixes. > > > > The simple way to do this is to have a table with MR identities > > (in the form of the security associations for the tunnels or something > > else with cryptographic binding to the actual MR), and a list > > of allowed prefixes the MR can advertise. > > I don't understand the need to authorize which MR advertises which > prefix. I was thinking that MRs are trusted by the HA because they > had that IPsec tunnel. So if the MRs share keys with the HA then they > can also advertise routes through the HA? lets assume there are two MRs, MR1 and MR2. what prevents MR2 from disrupting traffic to MR1 by advertising routes for MR1's mobile network to point to itself? Both MR1 and MR2 have security associations with the HA. Vijay From nemo-admin@nal.motlabs.com Wed Nov 13 13:48:57 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12498 for ; Wed, 13 Nov 2002 13:48:56 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIp2C28579; Wed, 13 Nov 2002 19:51:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADIobC28569 for ; Wed, 13 Nov 2002 19:50:37 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gADIoYCb000880 for ; Wed, 13 Nov 2002 11:50:35 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA06347 for ; Wed, 13 Nov 2002 11:46:31 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id gADIoT808548; Wed, 13 Nov 2002 12:50:29 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A51C02EC86; Wed, 13 Nov 2002 19:50:28 +0100 (CET) To: Vijay Devarapalli Cc: Erik Nordmark, Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD29D15.B125B2A1@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DD29D15.B125B2A1@iprg.nokia.com> Message-ID: Lines: 35 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Nov 2002 19:50:28 +0100 Vijay Devarapalli writes: > > > > why would you manually add a static route? this will not scale IMO. > > > > > > That depends on how you are going to determine which MR is authorized > > > to inject routes for which prefixes. > > > > > > The simple way to do this is to have a table with MR identities > > > (in the form of the security associations for the tunnels or something > > > else with cryptographic binding to the actual MR), and a list > > > of allowed prefixes the MR can advertise. > > > > I don't understand the need to authorize which MR advertises which > > prefix. I was thinking that MRs are trusted by the HA because they > > had that IPsec tunnel. So if the MRs share keys with the HA then they > > can also advertise routes through the HA? > > lets assume there are two MRs, MR1 and MR2. what prevents MR2 from > disrupting traffic to MR1 by advertising routes for MR1's mobile > network to point to itself? Both MR1 and MR2 have security > associations with the HA. Aha, so this table would protect against a threat where one MR attacks another MR, both of the same HA. But this threat is valid even when no mobility is in place. Assume R1, R2 and HA are neighbouring routers. Let's say that both R1 and R2 are trusted by HA. Then R1 and R2 can attack each other's prefix, fooling HA to believe what it shouldn't. I'm not saying this threat is invalid, just trying to understand whether that authorization check is an absolutely needed feature or something we could live with, and still make the mobile networks work (w/o taking attackers in mind). Alex From nemo-admin@nal.motlabs.com Wed Nov 13 14:10:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13339 for ; Wed, 13 Nov 2002 14:10:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADJC4C28752; Wed, 13 Nov 2002 20:12:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADJBXC28742 for ; Wed, 13 Nov 2002 20:11:33 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28427; Wed, 13 Nov 2002 11:11:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADJBMP01361; Wed, 13 Nov 2002 11:11:22 -0800 X-mProtect: <200211131911> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOEakTc; Wed, 13 Nov 2002 11:11:20 PST Message-ID: <3DD2A3D8.5A344AB0@iprg.nokia.com> 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: Alexandru Petrescu CC: Erik Nordmark , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD29D15.B125B2A1@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 11:11:20 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > But this threat is valid even when no mobility is in place. Assume > R1, R2 and HA are neighbouring routers. Let's say that both R1 and R2 > are trusted by HA. Then R1 and R2 can attack each other's prefix, > fooling HA to believe what it shouldn't. this is where the admin steps in :-). but seriously, it is a not a threat in the above, but becomes a threat when the mobile routers are away from the home link. routing on a link is strictly controlled by the admin. infact, in many networks people run RIPng/OSPFv3 without any protection. regards Vijay From nemo-admin@nal.motlabs.com Wed Nov 13 14:19:04 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13770 for ; Wed, 13 Nov 2002 14:19:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADJL3C28800; Wed, 13 Nov 2002 20:21:03 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADJKgC28789 for ; Wed, 13 Nov 2002 20:20:42 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gADJKdGE016764; Wed, 13 Nov 2002 12:20:40 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA19921; Wed, 13 Nov 2002 12:16:36 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id gADJKZT07992; Wed, 13 Nov 2002 13:20:36 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 65C972EC86; Wed, 13 Nov 2002 20:20:34 +0100 (CET) To: Vijay Devarapalli Cc: Erik Nordmark, Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD29D15.B125B2A1@iprg.nokia.com> <3DD2A3D8.5A344AB0@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DD2A3D8.5A344AB0@iprg.nokia.com> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Nov 2002 20:20:34 +0100 Vijay Devarapalli writes: > Alexandru Petrescu wrote: > > > > But this threat is valid even when no mobility is in place. Assume > > R1, R2 and HA are neighbouring routers. Let's say that both R1 and R2 > > are trusted by HA. Then R1 and R2 can attack each other's prefix, > > fooling HA to believe what it shouldn't. > > this is where the admin steps in :-). Ah they are helpful sometimes those humans aren't they. > but seriously, it is a not a threat in the above, but becomes a > threat when the mobile routers are away from the home link. Vijay, is the same attack possible with Mobile IPv6 for hosts where MH1 claims the home address of MH2, of the same HA? I must recognize I haven't read the draft. Alex From nemo-admin@nal.motlabs.com Wed Nov 13 14:31:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14223 for ; Wed, 13 Nov 2002 14:31:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADJX4C28856; Wed, 13 Nov 2002 20:33:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gADJWBC28846 for ; Wed, 13 Nov 2002 20:32:11 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29782; Wed, 13 Nov 2002 11:32:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gADJW2T07762; Wed, 13 Nov 2002 11:32:02 -0800 X-mProtect: <200211131932> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdar0nn3; Wed, 13 Nov 2002 11:32:00 PST Message-ID: <3DD2A8B1.4563985F@iprg.nokia.com> 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: Alexandru Petrescu CC: Erik Nordmark , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD29D15.B125B2A1@iprg.nokia.com> <3DD2A3D8.5A344AB0@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 11:32:01 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > but seriously, it is a not a threat in the above, but becomes a > > threat when the mobile routers are away from the home link. > > Vijay, is the same attack possible with Mobile IPv6 for hosts where > MH1 claims the home address of MH2, of the same HA? I must recognize > I haven't read the draft. yes it is. it is recognized as a threat. thats why it says the IPsec SA created between the MN and HA should be tied to the home address of the MN. one way of doing this would be to include the home address in the Subject Altname field of the certificate, if certificate based automatic keying is being used by MN and HA. in general, I think this authorization check need not be a MUST. but others might have a different opinion. Vijay From nemo-admin@nal.motlabs.com Wed Nov 13 22:19:54 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26167 for ; Wed, 13 Nov 2002 22:19:53 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE1j5C30200; Thu, 14 Nov 2002 02:45:06 +0100 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE1itC30188 for ; Thu, 14 Nov 2002 02:44:56 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 35457640CB for ; Wed, 13 Nov 2002 20:44:47 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gAE1ihwg004996; Wed, 13 Nov 2002 20:44:44 -0500 (EST) Received: from katrinajoy (vtcp2-23.lerc.nasa.gov [139.88.246.23]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id UAA01375; Wed, 13 Nov 2002 20:44:41 -0500 (EST) Message-Id: <4.2.1.20021113201302.02852780@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 To: Matt Mathis , pilc@ietf.org, nemo@nal.motlabs.com From: William Ivancic In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: [pilc] A question of small MTUs Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 20:48:24 -0500 I'm not sure about the largest or smallest MTU size, but I thought it may be appropriate to note some behaviors and problems we were having with MTU discovery over mobile networks using mobile-IPv4 double tunnels and encryption. The mobile-IPv4 mobile networking we are using applies double tunnels from the home agent to the foreign agent when foreign agent service is used. Adding encryption on top of that hides MTU discovery. To add to the problem, somewhere the don't fragment bit is being set - perhaps in some applications or at some Web servers. Thus, we manually have to set the Max MTU in the hosts on the mobile LAN or set the minimum acceptable MTU size at the last visible interface to the mobile LAN. We haven't had much time to really track this problem down and analyze it. But we have experienced it. I think this is a problem that needs to be recognized by the NEMO groups. Were is the best place to address it is yet to be determined. I think the problems are noted in various RFCs, but the implementations are not always followed. In our particular case, I suspect the encryption units are not following the appropriate advice for IPSec or IP-in-IP. Also, there may be ICMP filtering to some locations. At 05:09 PM 11/13/02 -0500, Matt Mathis wrote: >Kevin Lehey, John Heffner and I are working on a replacement for RFC1191 style >path MTU discovery (See RFC2923 for some of the reasons...). > >In our current design there is an open question about what is the smallest >MTU >that is cost effective to discover dynamically. ........ >Asked another way, what is the smallest MTU that is (more than occasionally) >used as an intermediate link between general purpose systems You may want to contact some military folks regarding this. They have some very small bandwidths and long delays. They may be using small MTU's to get small messages through the network quicker. The aeronautics group may also have similar problems, but they expected to eventually. Will From nemo-admin@nal.motlabs.com Wed Nov 13 22:45:26 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26864 for ; Wed, 13 Nov 2002 22:45:25 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE3l4C30920; Thu, 14 Nov 2002 04:47:04 +0100 Received: from zippy.psc.edu (pa-monroeville3a-101.pit.adelphia.net [24.53.185.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE3keC30910 for ; Thu, 14 Nov 2002 04:46:41 +0100 Received: from localhost (mathis@localhost) by zippy.psc.edu (8.11.6/8.11.6) with ESMTP id gAE4kTQ12857; Wed, 13 Nov 2002 23:46:29 -0500 X-Authentication-Warning: zippy.psc.edu: mathis owned process doing -bs From: Matt Mathis To: William Ivancic cc: pilc@ietf.org, In-Reply-To: <4.2.1.20021113201302.02852780@popserve.grc.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [nemo] Re: [pilc] A question of small MTUs Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 13 Nov 2002 23:46:29 -0500 (EST) On Wed, 13 Nov 2002, William Ivancic wrote: > I'm not sure about the largest or smallest MTU size, but I thought it may > be appropriate to note some behaviors and problems we were having with MTU > discovery over mobile networks using mobile-IPv4 double tunnels and > encryption. The mobile-IPv4 mobile networking we are using applies double > tunnels from the home agent to the foreign agent when foreign agent service > is used. Adding encryption on top of that hides MTU discovery. To add to > the problem, somewhere the don't fragment bit is being set - perhaps in > some applications or at some Web servers. Thus, we manually have to set > the Max MTU in the hosts on the mobile LAN or set the minimum acceptable > MTU size at the last visible interface to the mobile LAN. I'm a little curious to know how you think this is supposed to work. If you are using any advanced TCP features (e.g. PAWS RFC1323) or IPv6 then DF becomes mandatory. I think that our algorithm will indeed solve your problem for the TCP based applications, although I can't tell from your message what is the MTU of the inner most tunnel. It sounds like 1500 - 4*tunnel_overhead. Is that correct? What was the actual size? Thanks, --MM-- ---------------------------------------------- Matt Mathis W:412.268.3319 http://www.psc.edu/~mathis H:412.654.7529 ---------------------------------------------- From nemo-admin@nal.motlabs.com Thu Nov 14 02:13:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12140 for ; Thu, 14 Nov 2002 02:13:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE7F8C31548; Thu, 14 Nov 2002 08:15:09 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE7EIC31536 for ; Thu, 14 Nov 2002 08:14:18 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 980115D024; Thu, 14 Nov 2002 16:13:07 +0900 (JST) Message-Id: <20021114.161307.65279304.ernst@sfc.wide.ad.jp> To: Takeshi.Tanaka@yrp.mci.mei.co.jp Cc: nemo@nal.motlabs.com From: Thierry Ernst In-Reply-To: <20021113211225.A944.TAKESHI.TANAKA@yrp.mci.mei.co.jp> References: <20021031.131234.13078323.ernst@sfc.wide.ad.jp> <20021113211225.A944.TAKESHI.TANAKA@yrp.mci.mei.co.jp> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Comments on draft-ernst-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 16:13:07 +0900 (JST) Content-Transfer-Encoding: 7bit Dear all, Thanks Takeshi for the comments. Seems the feedback is only "clarification", no "disagreement", which is good at this stage. BTW, Is there a way to state the requirements of your own draft in a similar fashion ? > Following are comments for draft-ernst-nemo-requirements-00.txt. > > > R5: CNs and MNNs must comply with the requirements for IPv6 nodes > defined in [IPv6-NODE] > =>All IPv6 nodes comply with IPv6 node requirements, it is not requirements > for NEMO. I agree, but may be sometimes it worth to say it again ? > R6: MNNs MUST NOT be NEMO-enabled (i.e. do not impose changes to > MNNs) > =>"The solution must support nodes that are not NEMO-enabled" or > "The solution must not impact on MNNs" is better since MNN may > be also MR...as someone said. Agree for the note about the MR. The word "impact" does not sound good, so your first statement sounds better, but I would like to add "MNNs": "The solution must support MNNs that are not NEMO-enabled" Said like this, no pb with MR. > R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) > =>"The solution must not impact on CNs" is better since CN may be also MR. Same as above. "impact" must be defined, but the term NEMO-enabled is defined for this purpose, so ... "CNs MUST NOT be assumed to be NEMO-enabled" Is that better ? or "The solution MUST work with non NEMO-enabled CNs" ? > R8: A VMN that gets attached to a link within the mobile network > obtains an address on that link. > =>Which requirements does this imply? Right, not a requirement, but part of the definition for a VMN. > R10: The solution MUST support multi-homed mobile network > R10.1 : The solution MUST support mobile networks with multiple > MRs > R10.2: The solution MUST support MR with multiple interfaces > =>"The solution must support MR with multiple global addresses on egress > interface" should also be added. What's the difference with R10.2 ? > R12: The solution MUST support a large number of mobile networks > R12: The solution MUST support a large number of CNs > => duplicated number. > > R13: The solution MUST support vertical handoff > R14: The solution MUST support horizontal handoff > => What do "vertical handoff" and "horizonal handoff" mean? One is handoffs between two APs, while the other is handoff between two egress interfaces. In the next revision of the terminology, I should point to draft-ietf-seamoby-mobility-terminology-00.txt for the definitions. There was also a proposition to merge NEMO and Seamoby terminology, we need to examine this. > R17: The solution MUST support heterogeneous mobility > => What does "heterogeneous mobility" mean? Will be updated. I meant "inter-domain mobility" (defined as "macro-mobility in draft-ietf-seamoby-mobility-terminology-00.txt). Cheers, Thierry From nemo-admin@nal.motlabs.com Thu Nov 14 03:47:30 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13389 for ; Thu, 14 Nov 2002 03:47:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE8n5C31895; Thu, 14 Nov 2002 09:49:05 +0100 Received: from web10009.mail.yahoo.com (web10009.mail.yahoo.com [216.136.128.120]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gAE8m7C31884 for ; Thu, 14 Nov 2002 09:48:07 +0100 Message-ID: <20021114084805.44595.qmail@web10009.mail.yahoo.com> Received: from [202.224.189.50] by web10009.mail.yahoo.com via HTTP; Thu, 14 Nov 2002 00:48:05 PST From: ChanWah Ng Reply-To: cwng@psl.com.sg Subject: Re: AAA requirements (was Re: [nemo] my list of compiled requirements) To: nemo@nal.motlabs.com In-Reply-To: <3DD26B91.1040800@alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 00:48:05 -0800 (PST) --- Behcet Sarikaya wrote: > Hi ChanWah, > > ChanWah Ng wrote: > > >Hi all, > > > >let me just try to clarify things a bit. The AAA draft was started because we see > that > >AAA is the important factor in comercial consideration. We started the draft to > explore > >any AAA issues that are particular about NEMO. And indeed we found some. > > > >8 requirements are stated in the draft. Some are geared towards requirements on a AAA > >solution, some are requirements on NEMO nodes. Since they are high-level > requirements, I > >believe some "basic-nemo-specific" requiremnts can be drawn from them. The > appropriate > >approach, IMHO, is to take a look at each high-level requirement and draw specifc > >requirements from there. I think Alex's list is a good summary. > > > >Having said that, I agree that AAA and mobility support should be separate. Forgive > me > >if I've mistaken, but I would imagine the AAA/EAP/PANA WG will expect the NEMO WG to > come > >up with a document on requirements on AAA solution for NEMO. > > > > > Absolutely. If you consider Mobile IP WG example, requirements on the > AAA solution was done in MIP WG and the solution in AAA WG. > I think this is the issue: requirements on the AAA solution for NEMO > should be a separate document or it should be considered part of the > requirements for NEMO solution. > I argued for the former. However if we combine them we are going to be > following the charter more closely, this could be an advantage for the > latter approach. > What do people think? > Perhaps it is the fault on our part that draft-ng-nemo-aaa-use-00.txt specify both (1) AAA requirements on NEMO solution and (2) NEMO requirements on AAA solutions. I will attempt to classify them into the two different catergories. > (1)The AAA servers MUST be able to share, or dynamically establish > security associations with external authorities that are able > to verify the credentials provided by the client. This is definitely a requirement for AAA solution. > (2)The VMN or MR MUST be able to provide complete, unforgeable > credentials without having to contact its home agent. This is a bit more complicated. I will think it contains both types. It may place requirements on both NEMO and AAA solution. > (3)Intermediate nodes MUST not be able to learn any information > which may enable them to reconstruct and reuse the credentials. Same here. We can draw at least the requirement for NEMO: eg. MR/AR must not be able to snoop into packet sent by MNNs to the HA of MNNs. It also place requirements for AAA solution in that it requires the AAA solution to provide a mechanism to securely transfer the credentials. > (4)AAA request and response operations between the ARs/MRs and the > respective AAA servers MUST prevent eavesdropping. This is requirement for AAA solution. > (5)AAA request and response operations between the ARs/MRs and the > respective AAA servers MUST NOT be vulnerable to denial-of- > service attack. This is requirement for AAA solution. > (6)AAA request and response operations between the ARs/MRs and the > respective AAA servers MUST NOT be vulnerable to man-in-the- > middle attack. This is requirement for AAA solution. > (7)MR that supports attachment of VMN on its internal link SHOULD > implement AAA client capability to be able to contact MR's home > AAA server to check on credentials provided by the visiting > nodes. This will be requirement for NEMO solution/implementation. For example, (just an example!) when designing the mechansim to set-up bi-directional tunnel, a way to piggyback secure credentials should be considered. > (8)MR that support attachment of VMN on its internal links SHOULD > NOT change its AAA policy for the said VMNs during a continuous > session, even when the MR has undergone a handover between AR > of different administrative domains. This is a policy requirement, very difficult to classify into AAA or NEMO solution. If I must do it, I will say this will be more of a requirments for AAA solution. But it does place requirements (or perhaps non-goals?) on NEMO solution/implementation as well. /rgds /cwng __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com From nemo-admin@nal.motlabs.com Thu Nov 14 03:58:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13507 for ; Thu, 14 Nov 2002 03:58:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE90GC31984; Thu, 14 Nov 2002 10:00:16 +0100 Received: from bulls.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE8xDC31954 for ; Thu, 14 Nov 2002 09:59:14 +0100 Received: by bulls.mei.co.jp (8.12.5/3.7W/jazz) with ESMTP id gAE8x5Ln006429; Thu, 14 Nov 2002 17:59:05 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id gAE8x6b00004; Thu, 14 Nov 2002 17:59:06 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id gAE8x4V15590; Thu, 14 Nov 2002 17:59:04 +0900 (JST) Received: from yrpgw1.yrp.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:02091217) id gAE8x4500472; Thu, 14 Nov 2002 17:59:04 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by yrpgw1.yrp.mci.mei.co.jp (8.11.3/3.7W-GW1) with ESMTP id gAE8x0v03154; Thu, 14 Nov 2002 17:59:00 +0900 (JST) Received: from [133.183.211.75] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7W-TELECOM) with ESMTP id gAE8x3H03775; Thu, 14 Nov 2002 17:59:03 +0900 (JST) From: Takeshi TANAKA To: Thierry Ernst , IETF NEMO Subject: Re: [nemo] Re: Comments on draft-ernst-nemo-requirements-00.txt In-Reply-To: <20021114.161307.65279304.ernst@sfc.wide.ad.jp> References: <20021113211225.A944.TAKESHI.TANAKA@yrp.mci.mei.co.jp> <20021114.161307.65279304.ernst@sfc.wide.ad.jp> Message-Id: <20021114175144.6516.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 17:59:51 +0900 Content-Transfer-Encoding: 7bit At Thu, 14 Nov 2002 16:13:07 +0900 (JST) Thierry Ernst wrote : > > R7: CNs MUST not be NEMO-enabled (i.e. do not impose changes to CNs) > > =>"The solution must not impact on CNs" is better since CN may be also MR. > > Same as above. "impact" must be defined, but the term NEMO-enabled is > defined for this purpose, so ... > > "CNs MUST NOT be assumed to be NEMO-enabled" Is that better ? > > or "The solution MUST work with non NEMO-enabled CNs" ? I think the former is better. Or "The solution must not assume CN to be NEMO-enabled". > > R10: The solution MUST support multi-homed mobile network > > R10.1 : The solution MUST support mobile networks with multiple > > MRs > > R10.2: The solution MUST support MR with multiple interfaces > > =>"The solution must support MR with multiple global addresses on egress > > interface" should also be added. > > What's the difference with R10.2 ? I meant "The solution must support MR with multple global addresses on single egress interface". Suppse a single link that MR has attached to has multiple global link prefixes. Regards, Takeshi From nemo-admin@nal.motlabs.com Thu Nov 14 03:58:25 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13521 for ; Thu, 14 Nov 2002 03:58:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE903C31969; Thu, 14 Nov 2002 10:00:03 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE8x3C31947 for ; Thu, 14 Nov 2002 09:59:03 +0100 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAE8x1KV016945; Thu, 14 Nov 2002 09:59:02 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLGLCN0; Thu, 14 Nov 2002 09:59:01 +0100 Message-ID: <3DD36501.36988381@era.ericsson.se> X-Sybari-Trust: 53c4785a ca231590 f8c3cfed 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes References: <3DD14C90.A6A34DEA@iprg.nokia.com> <20021113.191737.45278866.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 09:55:29 +0100 Content-Transfer-Encoding: 7bit Hi Thierry, Thierry Ernst wrote: > > Let me try to see if I understand things right: Seems alright to me, apart from a small detail, see below: > > MR at home: > HA------BR > | > MR > > MR away: > HA------BR > | <- tunnel looks like a link > MR > > If MR runs a routing protocol: > > 1. At home, BR and MR are neighbors, so are HA and MR > 2. MR moves and obtains CoA > 3. Bidirectional tunnel established between MR and HA. > - The bidirectional tunnel looks like a link between MR and HA > - A route to MR with high timeout is added in the routing table of the HA > - MR and BR are not neighbors anymore, but MR and HA still are > - MR sends UNFREQUENT RUs over the tunnel (before routing entry times out) > - HA sends UNFREQUENT RUs > (i.e. it does NOT relay RUs sent by BR) > 4. Binding Cache at the HA: > - MR sends MIPv6 BU containing CoA > - HA add entry in the BC > - MR keeps sending BUs with current CoA REGULARLY (before BC entry times out) > - HA updates BC > 5. If MR is shutoff no more than routing_table_timeout, BC entry is > removed but routing entry is maintained in the home network. HA > drop packets since no BC entry. HA will drop packets to HoA of MR. Packets to MNNs will be tunneled to CoA (where there is nobody to receive them). They don't depend on the BC, only the routing table. BUT: the tunnel between HA and MR is installed because the MR sent a BU. If the corresponding BC entry in HA times out, the tunnel must go of course. So, packets to MNNs will be dropped as well. > > If MR does not run a routing protocol: > - tunnel is established permanently (high timer) > - do not send RUs over the tunnel in either directions > > -> the only thing we need to do is to specify how the tunnel should be > established (in a secure way) maintained, and deleted. MIPv6 does > not need to be changed. > > Can we use existing mechanisms to set up the tunnel ? How ? I would prefer to reuse the tunnel that ordinary MIPv6 sets up. The outer addresses are known: HA and CoA. The inner addresses can be anything (global or link-local addresses of HA or MN, global addresses of MNNs or CNs). MIPv6 installs the tunnel. If we use routing protocols the HA will learn that the mobile prefix is reachable through the tunnel and install a route to it. If we don't use routing protocols, a static route has to be installed on HA saying the same thing. /Mattias From nemo-admin@nal.motlabs.com Thu Nov 14 04:11:10 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13686 for ; Thu, 14 Nov 2002 04:11:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE9D4C32104; Thu, 14 Nov 2002 10:13:04 +0100 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE9CeC32094 for ; Thu, 14 Nov 2002 10:12:41 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01324; Thu, 14 Nov 2002 02:12:38 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAE9CbL09262; Thu, 14 Nov 2002 10:12:37 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) To: Alexandru Petrescu Cc: Erik Nordmark , Vijay Devarapalli , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 10:09:30 +0100 (CET) > I don't understand the need to authorize which MR advertises which > prefix. I was thinking that MRs are trusted by the HA because they > had that IPsec tunnel. So if the MRs share keys with the HA then they > can also advertise routes through the HA? For the same reason that the HA MIPv6 needs to associate a given IPsec SA with the home address of the MN - to prevent one user of the HA from stealing the packets for another user of the same HA. Erik From nemo-admin@nal.motlabs.com Thu Nov 14 04:19:06 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13798 for ; Thu, 14 Nov 2002 04:19:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE9L3C32202; Thu, 14 Nov 2002 10:21:03 +0100 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAE9KkC32192 for ; Thu, 14 Nov 2002 10:20:47 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27188; Thu, 14 Nov 2002 02:20:44 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAE9KhL11129; Thu, 14 Nov 2002 10:20:43 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) To: Alexandru Petrescu Cc: Vijay Devarapalli , Erik Nordmark , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 10:17:36 +0100 (CET) > Aha, so this table would protect against a threat where one MR attacks > another MR, both of the same HA. > > But this threat is valid even when no mobility is in place. Assume > R1, R2 and HA are neighbouring routers. Let's say that both R1 and R2 > are trusted by HA. Then R1 and R2 can attack each other's prefix, > fooling HA to believe what it shouldn't. > > I'm not saying this threat is invalid, just trying to understand > whether that authorization check is an absolutely needed feature or > something we could live with, and still make the mobile networks work > (w/o taking attackers in mind). Alex, this makes an excellent point for - the WG needing a threat analysis draft ASAP - the WG needing to discuss the threats in detail And my personal answer to your question is that it depends on whether there is an admin boundary between the HA and MRs or not. If the same organization controls the HAs and MRs (and the MRs are hardened so they can't be subverted even though they might have less physical security than nodes physically on the home link) then the threat might not be of concern. But when the MR is operated by a different administration than the HA then I think this threat needs to be taken very seriously. Erik From nemo-admin@nal.motlabs.com Thu Nov 14 06:27:58 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15741 for ; Thu, 14 Nov 2002 06:27:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAEBT4C00434; Thu, 14 Nov 2002 12:29:04 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAEBSZC00424 for ; Thu, 14 Nov 2002 12:28:36 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 5B0895D0EE for ; Thu, 14 Nov 2002 20:28:22 +0900 (JST) Message-Id: <20021114.202822.68555896.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com From: Thierry Ernst In-Reply-To: <20021114084805.44595.qmail@web10009.mail.yahoo.com> References: <3DD26B91.1040800@alcatel.com> <20021114084805.44595.qmail@web10009.mail.yahoo.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: AAA requirements Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 20:28:22 +0900 (JST) Content-Transfer-Encoding: 7bit From: ChanWah Ng > > Perhaps it is the fault on our part that draft-ng-nemo-aaa-use-00.txt > specify both (1) AAA requirements on NEMO solution and > (2) NEMO requirements on AAA solutions. I would prefer to see a discussion on this ML about the requirements themselves rather than whether they should be expressed in a separate document or not... I don't see any trouble with your draft mixing the 2, since the conclusions are based on some usage scenario. It's good to have this on the table, so that we can discuss the issues and establish cross-communication with relevant IETF WGs. So, may be that should be put more in light so that next Wednesday we make an effective use of our time. If well explained, AAA people in the room (if any) can understand what are the NEMO issues with respect to AAA and what we are expecting from them. Thierry. > I will attempt to classify them into the two different catergories. > > > (1)The AAA servers MUST be able to share, or dynamically establish > > security associations with external authorities that are able > > to verify the credentials provided by the client. > > This is definitely a requirement for AAA solution. > > > (2)The VMN or MR MUST be able to provide complete, unforgeable > > credentials without having to contact its home agent. > > This is a bit more complicated. I will think it contains both types. > It may place requirements on both NEMO and AAA solution. > > > (3)Intermediate nodes MUST not be able to learn any information > > which may enable them to reconstruct and reuse the credentials. > > Same here. We can draw at least the requirement for NEMO: eg. MR/AR > must not be able to snoop into packet sent by MNNs to the HA of MNNs. > It also place requirements for AAA solution in that it requires the > AAA solution to provide a mechanism to securely transfer the > credentials. > > > (4)AAA request and response operations between the ARs/MRs and the > > respective AAA servers MUST prevent eavesdropping. > > This is requirement for AAA solution. > > > (5)AAA request and response operations between the ARs/MRs and the > > respective AAA servers MUST NOT be vulnerable to denial-of- > > service attack. > > This is requirement for AAA solution. > > > (6)AAA request and response operations between the ARs/MRs and the > > respective AAA servers MUST NOT be vulnerable to man-in-the- > > middle attack. > > This is requirement for AAA solution. > > > (7)MR that supports attachment of VMN on its internal link SHOULD > > implement AAA client capability to be able to contact MR's home > > AAA server to check on credentials provided by the visiting > > nodes. > > This will be requirement for NEMO solution/implementation. For > example, (just an example!) when designing the mechansim to set-up > bi-directional tunnel, a way to piggyback secure credentials should > be considered. > > > (8)MR that support attachment of VMN on its internal links SHOULD > > NOT change its AAA policy for the said VMNs during a continuous > > session, even when the MR has undergone a handover between AR > > of different administrative domains. > > This is a policy requirement, very difficult to classify into AAA or > NEMO solution. If I must do it, I will say this will be more of a > requirments for AAA solution. But it does place requirements (or > perhaps non-goals?) on NEMO solution/implementation as well. From nemo-admin@nal.motlabs.com Thu Nov 14 11:37:39 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23729 for ; Thu, 14 Nov 2002 11:37:35 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAEGc4C02004; Thu, 14 Nov 2002 17:38:05 +0100 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAEGbKC01993 for ; Thu, 14 Nov 2002 17:37:21 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gAEGbAKx023175; Thu, 14 Nov 2002 10:37:11 -0600 (CST) Message-ID: <3DD3D16D.20301@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cwng@psl.com.sg, nemo@nal.motlabs.com Subject: Re: AAA requirements (was Re: [nemo] my list of compiled requirements) References: <20021114084722.44559.qmail@web10009.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------060700020704080704010000" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 10:38:05 -0600 --------------060700020704080704010000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello ChanWah, I think you forgot to cc the mail to nemo ML ):? My comments in line. ChanWah Ng wrote: >> >> >> > >Perhaps it is the fault on our part that draft-ng-nemo-aaa-use-00.txt >specify both (1) AAA requirements on NEMO solution and >(2) NEMO requirements on AAA solutions. > >I will attempt to classify them into the two different catergories. > > > >>(1)The AAA servers MUST be able to share, or dynamically establish >> security associations with external authorities that are able >> to verify the credentials provided by the client. >> >> > >This is definitely a requirement for AAA solution. > > > >>(2)The VMN or MR MUST be able to provide complete, unforgeable >> credentials without having to contact its home agent. >> >> > >This is a bit more complicated. I will think it contains both types. >It may place requirements on both NEMO and AAA solution. > I think that draft-ernst-nemo-requirements-00.txt already has similar requirements. > > > >>(3)Intermediate nodes MUST not be able to learn any information >> which may enable them to reconstruct and reuse the credentials. >> >> > >Same here. We can draw at least the requirement for NEMO: eg. MR/AR >must not be able to snoop into packet sent by MNNs to the HA of MNNs. >It also place requirements for AAA solution in that it requires the >AAA solution to provide a mechanism to securely transfer the >credentials. > > May I restate this as follows: MR MUST NOT snoop into the packets sent by MNN to HA of MNN. > > >>(4)AAA request and response operations between the ARs/MRs and the >> respective AAA servers MUST prevent eavesdropping. >> >> > >This is requirement for AAA solution. > > agreed > > >>(5)AAA request and response operations between the ARs/MRs and the >> respective AAA servers MUST NOT be vulnerable to denial-of- >> service attack. >> >> > >This is requirement for AAA solution. > > agreed > > >>(6)AAA request and response operations between the ARs/MRs and the >> respective AAA servers MUST NOT be vulnerable to man-in-the- >> middle attack. >> >> > >This is requirement for AAA solution. > agreed > > > >>(7)MR that supports attachment of VMN on its internal link SHOULD >> implement AAA client capability to be able to contact MR's home >> AAA server to check on credentials provided by the visiting >> nodes. >> >> > >This will be requirement for NEMO solution/implementation. For >example, (just an example!) when designing the mechansim to set-up >bi-directional tunnel, a way to piggyback secure credentials should >be considered. > May I restate this as follows? MR that supports VMN on its internal link MUST establish the bi-directional tunnel in such a way as to enable authentication of VMN by VMN's home AAA server. > > >>(8)MR that support attachment of VMN on its internal links SHOULD >> NOT change its AAA policy for the said VMNs during a continuous >> session, even when the MR has undergone a handover between AR >> of different administrative domains. >> >> > >This is a policy requirement, very difficult to classify into AAA or >NEMO solution. If I must do it, I will say this will be more of a >requirments for AAA solution. But it does place requirements (or >perhaps non-goals?) on NEMO solution/implementation as well. > > Maybe keep this as AAA requirement? >/rgds >/cwng > > --behcet --------------060700020704080704010000 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello ChanWah,
  I think you forgot to cc the mail to nemo ML ):?  My comments in line.

ChanWah Ng wrote:

    

Perhaps it is the fault on our part that draft-ng-nemo-aaa-use-00.txt 
specify both (1) AAA requirements on NEMO solution and 
(2) NEMO requirements on AAA solutions.  

I will attempt to classify them into the two different catergories.

  
(1)The AAA servers MUST be able to share, or dynamically establish 
   security associations with external authorities that are able 
   to verify the credentials provided by the client. 
    

This is definitely a requirement for AAA solution.

  
(2)The VMN or MR MUST be able to provide complete, unforgeable 
   credentials without having to contact its home agent. 
    

This is a bit more complicated.  I will think it contains both types.  
It may place requirements on both NEMO and AAA solution.
I think that
draft-ernst-nemo-requirements-00.txt
already has similar requirements.

  
(3)Intermediate nodes MUST not be able to learn any information 
   which may enable them to reconstruct and reuse the credentials. 
    

Same here.  We can draw at least the requirement for NEMO: eg. MR/AR 
must not be able to snoop into packet sent by MNNs to the HA of MNNs.
It also place requirements for AAA solution in that it requires the 
AAA solution to provide a mechanism to securely transfer the 
credentials.
May I restate this as follows:
MR MUST NOT snoop into the packets sent by MNN to HA of MNN.
  
(4)AAA request and response operations between the ARs/MRs and the 
   respective AAA servers MUST prevent eavesdropping. 
    

This is requirement for AAA solution.
agreed
  
(5)AAA request and response operations between the ARs/MRs and the 
   respective AAA servers MUST NOT be vulnerable to denial-of-
   service attack. 
    

This is requirement for AAA solution.
agreed
  
(6)AAA request and response operations between the ARs/MRs and the 
   respective AAA servers MUST NOT be vulnerable to man-in-the-
   middle attack. 
    

This is requirement for AAA solution.
agreed

  
(7)MR that supports attachment of VMN on its internal link SHOULD 
   implement AAA client capability to be able to contact MR's home 
   AAA server to check on credentials provided by the visiting 
   nodes. 
    

This will be requirement for NEMO solution/implementation.  For 
example, (just an example!) when designing the mechansim to set-up 
bi-directional tunnel, a way to piggyback secure credentials should 
be considered.
  May I restate this as follows?
MR that supports VMN on its internal link MUST establish the bi-directional tunnel in such a way as to enable authentication of VMN by VMN’s home AAA server.
  
(8)MR that support attachment of VMN on its internal links SHOULD 
   NOT change its AAA policy for the said VMNs during a continuous 
   session, even when the MR has undergone a handover between AR 
   of different administrative domains. 
    

This is a policy requirement, very difficult to classify into AAA or 
NEMO solution.  If I must do it, I will say this will be more of a 
requirments for AAA solution.  But it does place requirements (or 
perhaps non-goals?) on NEMO solution/implementation as well.
Maybe keep this as AAA requirement?
/rgds
/cwng
--behcet
--------------060700020704080704010000-- From nemo-admin@nal.motlabs.com Thu Nov 14 15:02:05 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28925 for ; Thu, 14 Nov 2002 15:02:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAEK35C02681; Thu, 14 Nov 2002 21:03:05 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAEK2sC02668 for ; Thu, 14 Nov 2002 21:02:55 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAEJw62n003684; Thu, 14 Nov 2002 12:58:06 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA14412; Thu, 14 Nov 2002 13:01:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id gAEK15W03487; Thu, 14 Nov 2002 14:01:10 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 053C82EC86; Thu, 14 Nov 2002 21:01:01 +0100 (CET) To: Erik Nordmark Cc: Vijay Devarapalli, Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 14 Nov 2002 21:01:01 +0100 Erik Nordmark writes: > But when the MR is operated by a different administration than the HA > then I think this threat needs to be taken very seriously. In these conditions, this should indeed be taken very seriously. Here are some issues I could think of (I wouldn't quite call them threats since it's very high-level): -MR1 claiming MR2's prefix is only the tip of the iceberg, because it only attacks MR2 and only the nodes on the mobile network of MR2. -MR1 could also claim a better default route at the home domain, thus deviating all Internet traffic of the the HA, of all the MRs, of the BR and of all the nodes on the home link. -MR1 could do worse by pretending to own a prefix that is out of the home link but still within the domain that is controlled by the administrative entity that administrates the home domain. These three risks appear when MR is physically away from home and connected to the home link through the HA. If MR is physically at home, other risks may arise: in a home network deployment where MR, HA and BR run a dynamic routing protocol, protected with the same shared key, and where a "MR-route check table" is used by HA to ensure that only "official" routes are advertised by MR, and if it is possible for an attacker MR to connect physically on the other side of the BR, then MR could take advantage of that key and advertise whatever routes it pleases. In all the above, the assumption is that MR is an attacker; but the other possibility could be when the HA is compromised and attacks MR. (this is somehow equivalent to MH connecting to an AR, where the problem is not only how the MH authenticates to AR, but also how is the MH sure that the AR is legitimate.) Also, a case where MR1 and MR2 both belong to the same HA, but they're away and nested MR1 under MR2: we should make sure that the MRHA tunnels (or the MRTP protocols) work fine (maybe they do without me worrying). And if work, and three different administrative entities (MR1's, MR2's and HA's), make sure no new threats, looks tough :-) Alex From nemo-admin@nal.motlabs.com Thu Nov 14 21:30:41 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14177 for ; Thu, 14 Nov 2002 21:30:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAF2W6C06437; Fri, 15 Nov 2002 03:32:06 +0100 Received: from web10007.mail.yahoo.com (web10007.mail.yahoo.com [216.136.130.43]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gAF2VoC06427 for ; Fri, 15 Nov 2002 03:31:51 +0100 Message-ID: <20021115023144.82363.qmail@web10007.mail.yahoo.com> Received: from [202.224.189.50] by web10007.mail.yahoo.com via HTTP; Thu, 14 Nov 2002 18:31:44 PST From: ChanWah Ng Reply-To: cwng@psl.com.sg Subject: Re: AAA requirements (was Re: [nemo] my list of compiled requirements) To: nemo@nal.motlabs.com In-Reply-To: <3DD3D16D.20301@alcatel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 14 Nov 2002 18:31:44 -0800 (PST) --- Behcet Sarikaya wrote: > Hello ChanWah, > I think you forgot to cc the mail to nemo ML ):? My comments in line. > I realized that :) > ChanWah Ng wrote: > > > > >>(2)The VMN or MR MUST be able to provide complete, unforgeable > >> credentials without having to contact its home agent. > >> > >> > > > >This is a bit more complicated. I will think it contains both types. > >It may place requirements on both NEMO and AAA solution. > > > I think that > draft-ernst-nemo-requirements-00.txt > already has similar requirements. > Can you specifically point out which requirement in Thierry's draft is similar? > > > > > > > >>(3)Intermediate nodes MUST not be able to learn any information > >> which may enable them to reconstruct and reuse the credentials. > >> > >> > > > >Same here. We can draw at least the requirement for NEMO: eg. MR/AR > >must not be able to snoop into packet sent by MNNs to the HA of MNNs. > >It also place requirements for AAA solution in that it requires the > >AAA solution to provide a mechanism to securely transfer the > >credentials. > > > > > May I restate this as follows: > MR MUST NOT snoop into the packets sent by MNN to HA of MNN. > perhaps "MR/AR MUST NOT ..." > > > >>(7)MR that supports attachment of VMN on its internal link SHOULD > >> implement AAA client capability to be able to contact MR's home > >> AAA server to check on credentials provided by the visiting > >> nodes. > >> > >> > > > >This will be requirement for NEMO solution/implementation. For > >example, (just an example!) when designing the mechansim to set-up > >bi-directional tunnel, a way to piggyback secure credentials should > >be considered. > > > May I restate this as follows? > MR that supports VMN on its internal link MUST establish the > bi-directional tunnel in such a way as to enable authentication of VMN > by VMN's home AAA server. > I think we can break this requirement into the following: (i) MR to set up secure bidirectional tunnel between MR and HA of MR (ii) MR has to implement AAA client function /rgds /cwng __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site http://webhosting.yahoo.com From nemo-admin@nal.motlabs.com Fri Nov 15 19:01:00 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24381 for ; Fri, 15 Nov 2002 19:00:59 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAG026C11995; Sat, 16 Nov 2002 01:02:07 +0100 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAG01kC11985 for ; Sat, 16 Nov 2002 01:01:46 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gAG01cEJ008988; Fri, 15 Nov 2002 18:01:39 -0600 (CST) Message-ID: <3DD58B18.10201@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cwng@psl.com.sg CC: nemo@nal.motlabs.com Subject: Re: AAA requirements (was Re: [nemo] my list of compiled requirements) References: <20021115023144.82363.qmail@web10007.mail.yahoo.com> Content-Type: multipart/alternative; boundary="------------000705050405030807060002" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 15 Nov 2002 18:02:32 -0600 --------------000705050405030807060002 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Comments in line. ChanWah Ng wrote: >>>>(2)The VMN or MR MUST be able to provide complete, unforgeable >>>> credentials without having to contact its home agent. >>>> >>>> >>>> >>>> >>>This is a bit more complicated. I will think it contains both types. >>>It may place requirements on both NEMO and AAA solution. >>> >>> >>> >>I think that >>draft-ernst-nemo-requirements-00.txt >>already has similar requirements. >> >> >> >Can you specifically point out which requirement in Thierry's draft is similar? > What I meant was the requirements Thierry stated on control messages such as all control messages must be authenticated, the sender must be authorized, etc. Maybe it is not the same thing. OK. > > > >>> >>> >>> >>> >>>>(3)Intermediate nodes MUST not be able to learn any information >>>> which may enable them to reconstruct and reuse the credentials. >>>> >>>> >>>> >>>> >>>Same here. We can draw at least the requirement for NEMO: eg. MR/AR >>>must not be able to snoop into packet sent by MNNs to the HA of MNNs. >>>It also place requirements for AAA solution in that it requires the >>>AAA solution to provide a mechanism to securely transfer the >>>credentials. >>> >>> >>> >>> >>May I restate this as follows: >>MR MUST NOT snoop into the packets sent by MNN to HA of MNN. >> >> >> >perhaps "MR/AR MUST NOT ..." > OK > > > >>>>(7)MR that supports attachment of VMN on its internal link SHOULD >>>> implement AAA client capability to be able to contact MR's home >>>> AAA server to check on credentials provided by the visiting >>>> nodes. >>>> >>>> >>>> >>>> >>>This will be requirement for NEMO solution/implementation. For >>>example, (just an example!) when designing the mechansim to set-up >>>bi-directional tunnel, a way to piggyback secure credentials should >>>be considered. >>> >>> >>> >> May I restate this as follows? >>MR that supports VMN on its internal link MUST establish the >>bi-directional tunnel in such a way as to enable authentication of VMN >>by VMN's home AAA server. >> >> >> > >I think we can break this requirement into the following: >(i) MR to set up secure bidirectional tunnel between MR and HA of MR >(ii) MR has to implement AAA client function > >/rgds >/cwng > >__________________________________________________ > > --behcet --------------000705050405030807060002 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Comments in line.

ChanWah Ng wrote:
(2)The VMN or MR MUST be able to provide complete, unforgeable 
  credentials without having to contact its home agent. 
   

        
This is a bit more complicated.  I will think it contains both types.  
It may place requirements on both NEMO and AAA solution.

      
I think that
draft-ernst-nemo-requirements-00.txt
already has similar requirements.

    
Can you specifically point out which requirement in Thierry's draft is similar?
What I meant was the requirements Thierry stated on control messages such as all control messages must be authenticated, the sender must be authorized, etc. Maybe it is not the same thing.
OK.

  
 

      
(3)Intermediate nodes MUST not be able to learn any information 
  which may enable them to reconstruct and reuse the credentials. 
   

        
Same here.  We can draw at least the requirement for NEMO: eg. MR/AR 
must not be able to snoop into packet sent by MNNs to the HA of MNNs.
It also place requirements for AAA solution in that it requires the 
AAA solution to provide a mechanism to securely transfer the 
credentials.
 

      
May I restate this as follows:
MR MUST NOT snoop into the packets sent by MNN to HA of MNN.

    
perhaps "MR/AR MUST NOT ..."
OK

  
(7)MR that supports attachment of VMN on its internal link SHOULD 
  implement AAA client capability to be able to contact MR's home 
  AAA server to check on credentials provided by the visiting 
  nodes. 
   

        
This will be requirement for NEMO solution/implementation.  For 
example, (just an example!) when designing the mechansim to set-up 
bi-directional tunnel, a way to piggyback secure credentials should 
be considered.

      
  May I restate this as follows?
MR that supports VMN on its internal link MUST establish the 
bi-directional tunnel in such a way as to enable authentication of VMN 
by VMN's home AAA server.

    

I think we can break this requirement into the following:
(i) MR to set up secure bidirectional tunnel between MR and HA of MR
(ii) MR has to implement AAA client function

/rgds
/cwng

__________________________________________________
--behcet
--------------000705050405030807060002-- From nemo-admin@nal.motlabs.com Mon Nov 18 09:36:12 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22039 for ; Mon, 18 Nov 2002 09:36:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIEb7C01954; Mon, 18 Nov 2002 15:37:07 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIEaPC01941 for ; Mon, 18 Nov 2002 15:36:25 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIEXkTr019648; Mon, 18 Nov 2002 15:33:46 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 18 Nov 2002 15:35:00 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Message-ID: Thread-Topic: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Thread-Index: AcKLQnscAYeErX5JRCeTvXW1C8y57ADyJqbQ From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Erik Nordmark" Cc: "Alexandru Petrescu" , X-OriginalArrivalTime: 18 Nov 2002 14:35:00.0022 (UTC) FILETIME=[AC71DD60:01C28F0F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAIEaPC01941 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 14:34:59 -0000 Content-Transfer-Encoding: 8bit Vijay wrote: > "this is what we do in our implementation. but the static route is > not created until the HA receives a binding update from the MR. > and when the MR deregisters or when the binding cache entry expires, > the static route is removed. but we dont create it manually." Hi Vijay: I understand that you're not a static routes believer... Well, in the context of Nemo, I believe they deserve a good defense. The paradigm is so different from the traditional fixed world. For instance, the MRs are virtually all aligned on the home link - a flat model, which is very different from a router graph topology; one consequence is that traditional route aggregation is impossible; an other is that the manual admin of static routes is much much easier; last but not least there's no way around the Home Link routers (HA/BR) to be found by a routing protocol, so the routing protocol will not find another path should the Home Link routers fail to reach a MR. => routing protocols do not bring you much value here. But they come at a cost, since the bandwidth to the MRs may be very expensive. Question here: why do you need to remove the static routes? One of my beliefs (requirements?) is that the routing fabric should not be disturbed by mobile activity. Another belief is that ND should be the one doing link level resolution, not routing protocols. If the MR is home, ND will find it. If it's not home but registered, ND will find its active home agent, and for the other HAs, it makes no difference. Otherwise, the MR is not reachable and ND will make that clear. Maybe we should make sure ICMP reports the unreachability of the MNet clearly to the Correspondents, but I'd rather not remove the routes. What do you think? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mercredi 13 novembre 2002 19:16 > To: Erik Nordmark > Cc: Alexandru Petrescu; nemo@nal.motlabs.com > Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) > > > Erik Nordmark wrote: > > > > > why would you manually add a static route? this will not > scale IMO. > > > > That depends on how you are going to determine which MR is > authorized > > to inject routes for which prefixes. > > > > The simple way to do this is to have a table with MR identities (in > > the form of the security associations for the tunnels or something > > else with cryptographic binding to the actual MR), and a list of > > allowed prefixes the MR can advertise. > > this is what we do in our implementation. but the static > route is not created until the HA receives a binding update > from the MR. and when the MR deregisters or when the binding > cache entry expires, > the static route is removed. but we dont create it manually. > > there are two scenarios in draft-kniveton-mobrtr. in the > first, the MR does not run a routing protocol through the > bi-directional tunnel. so we do the above in the first > scenario. in the second scenario, the > MR sends routing updates through the bi-directional tunnel. > creating a route is not tied to the binding update in this > scenario. but the > authorization check (to see if a particular MR is allowed a > particular > prefix) is still needed. > > Vijay > From nemo-admin@nal.motlabs.com Mon Nov 18 13:18:26 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for ; Mon, 18 Nov 2002 13:18:24 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIIK4C03038; Mon, 18 Nov 2002 19:20:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIIJZC03024 for ; Mon, 18 Nov 2002 19:19:35 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA18714; Mon, 18 Nov 2002 10:19:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAIIJRC08364; Mon, 18 Nov 2002 10:19:27 -0800 X-mProtect: <200211181819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNrg2iH; Mon, 18 Nov 2002 10:19:25 PST Message-ID: <3DD92F2E.9B247C88@iprg.nokia.com> 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: Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 10:19:26 -0800 Content-Transfer-Encoding: 7bit hi Pascal, I am totally confused by your mail. I am not against static routes. I am against creating these static routes manually and keep them forever. it makes no sense manually creating and managing static routes for (lets say) 1000 mobile routers on a home link. especially when they are shut off. I am for creating the routes whenever needed (like when the MR sends a BU). Vijay "Pascal Thubert (pthubert)" wrote: > Home Link routers fail to reach a MR. => routing protocols do not bring > you much value here. But they come at a cost, since the bandwidth to the > MRs may be very expensive. that is why we have two scenarios in draft-kniveton-mobrtr. we dont expect a MR, that was running a routing protocol when at home, to continue running the same routing protocol (through the bi-directional tunnel) when away from home. > Question here: why do you need to remove the static routes? One of my ?? this is what confused me. in our implementation when the HA receives a BU from the MR, it creats a static route to the Mobile Network. and when the binding cache entry expires, this static route is removed. > beliefs (requirements?) is that the routing fabric should not be > disturbed by mobile activity. Another belief is that ND should be the > one doing link level resolution, not routing protocols. If the MR is > home, ND will find it. If it's not home but registered, ND will find its > active home agent, and for the other HAs, it makes no difference. there is a problem. ND proxying works for addresses. but does not work for prefixes. the HA cannot proxy for a prefix. > Otherwise, the MR is not reachable and ND will make that clear. Maybe we > should make sure ICMP reports the unreachability of the MNet clearly to > the Correspondents, but I'd rather not remove the routes. it is simpler adding/deleting the route based on whether the MR is shutt off or alive. regards Vijay From nemo-admin@nal.motlabs.com Mon Nov 18 13:33:07 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29299 for ; Mon, 18 Nov 2002 13:33:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIIZ3C03113; Mon, 18 Nov 2002 19:35:03 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIIYTC03101 for ; Mon, 18 Nov 2002 19:34:29 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gAIIYdw4029097 for ; Mon, 18 Nov 2002 11:34:39 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA18126 for ; Mon, 18 Nov 2002 11:34:27 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id gAIIYPW26793; Mon, 18 Nov 2002 12:34:26 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id F0B6F2EC86; Mon, 18 Nov 2002 19:34:19 +0100 (CET) To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , Erik Nordmark , Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD92F2E.9B247C88@iprg.nokia.com> From: Alexandru Petrescu In-Reply-To: <3DD92F2E.9B247C88@iprg.nokia.com> Message-ID: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 18 Nov 2002 19:34:20 +0100 Vijay Devarapalli writes: > especially when they are shut off. I am for creating the routes > whenever needed (like when the MR sends a BU). This could be: "_renewing_ route's lifetime and _changing_ the BC entry when receiving BU". It's the same route. But renewing a route's lifetime is normally done by the routing daemon, so if we let the routing daemon run on MR (even in consumer mode) then the routing daemon will update these route's lifetimes on HA, no need for BUs, even simpler. > > beliefs (requirements?) is that the routing fabric should not be > > disturbed by mobile activity. Another belief is that ND should be the > > one doing link level resolution, not routing protocols. If the MR is > > home, ND will find it. If it's not home but registered, ND will find its > > active home agent, and for the other HAs, it makes no difference. > > there is a problem. ND proxying works for addresses. but does not work > for prefixes. the HA cannot proxy for a prefix. Me neither, I would not look into converting ND from /128's to prefixes. But suffices it for the HA to do proper ND (redirects included) for the ll of the MR, no need of ND for LFNs. Except that ND redirects will add probably too many routes. Alex From nemo-admin@nal.motlabs.com Mon Nov 18 14:59:38 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01735 for ; Mon, 18 Nov 2002 14:59:36 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIK15C03405; Mon, 18 Nov 2002 21:01:05 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIK0sC03384 for ; Mon, 18 Nov 2002 21:00:54 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIJxCLm009849; Mon, 18 Nov 2002 20:59:13 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 18 Nov 2002 21:00:29 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Message-ID: Thread-Topic: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Thread-Index: AcKPLykDzolbz6JNQoe22awgLYjTMgACuOCg From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Erik Nordmark" Cc: "Alexandru Petrescu" , X-OriginalArrivalTime: 18 Nov 2002 20:00:29.0850 (UTC) FILETIME=[25211FA0:01C28F3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAIK0sC03384 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 20:00:29 -0000 Content-Transfer-Encoding: 8bit > > hi Pascal, > > I am totally confused by your mail. Sorry :) > > ?? this is what confused me. in our implementation when the > HA receives a BU from the MR, it creats a static route to the > Mobile Network. and when the binding cache entry expires, > this static route is removed. > No question your implementation works. Weactually do something similar in our IPv4 support. Now, in your test config, is that route advertised to the AS via an IGP? If so, the MR activity send waves across the routing fabric. At a certain point (how many MRs does that take???), the fabric will be pushed to the limits and tear down, won't it? > > there is a problem. ND proxying works for addresses. but does > not work for prefixes. the HA cannot proxy for a prefix. > I agree there's some confusion around... There's no need to proxy for a prefix here, is there? The static route coded on the home routers (HA/BR) says MNet via MR. So a HA getting a packet for a MNet will lookup its routing table and derive MR as next hop since it's a direct route. If the BCE lookup fails, then the HA uses plain ND to locate MR. If the MR is located on the home link, the packet is forwarded to it, otherwise the packet is dropped. This is true regardless of whether the MAC is that of another Home Agent, correct? Works... > > it is simpler adding/deleting the route based on whether the MR is > shutt off or alive. It is even simpler to do nothing ;) As Erik pointed out recently, the Mnet->MR mapping must be coded somwhere. The HA/BRs can read that somewhere, or be that somewhere, and anyway install the routes accordingly once and for all (almost:). This causes more routes redistributed into the AS, but at least it's a stable topology. As you see, both solutions have advantages. But there may be a requirement associated here, about the impact of mobility to the home AS. Or not? Pascal From nemo-admin@nal.motlabs.com Mon Nov 18 16:24:31 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03922 for ; Mon, 18 Nov 2002 16:24:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAILQ3C03711; Mon, 18 Nov 2002 22:26:03 +0100 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAILPAC03701 for ; Mon, 18 Nov 2002 22:25:10 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11986; Mon, 18 Nov 2002 14:25:07 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAILOxL00606; Mon, 18 Nov 2002 22:25:00 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) To: "Pascal Thubert (pthubert)" Cc: Vijay Devarapalli , Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 22:21:51 +0100 (CET) > It is even simpler to do nothing ;) As Erik pointed out recently, the > Mnet->MR mapping must be coded somwhere. The HA/BRs can read that > somewhere, or be that somewhere, and anyway install the routes > accordingly once and for all (almost:). This causes more routes > redistributed into the AS, but at least it's a stable topology. As you > see, both solutions have advantages. But there may be a requirement > associated here, about the impact of mobility to the home AS. Or not? Two things to consider. Depending on the address allocation inside the site these routes might be aggregatable at the HA. For instance, if a HA serves multiple MRs the Nemos attached to those MRs might get addresses allocated so that the HA can inject a single route into the IGP for all of them. Then the HA would only install its local routes to the individual Nemos when the tunnels are up. This would reduce both the size of the routing tables and the rate of change to them, but it assumes that a given MR always connects to the same MR. (Well, a longer prefix can be injected should it connect somewhere else.) There might be cases where one wants to multihome a MR (hence a Nemo) at two different HAs inside the routing domain. Thus the MR would have two different home addresses (and home links). The MR establishes a tunnel with both HAs and both HAs (when the tunnel is up) injects a route into the IGP. Thus uses the IGP to get redundancy against HA and home link failures, but it assumes that there is some basic liveness checks on the tunnels to detect when a tunnel stops working. Erik From nemo-admin@nal.motlabs.com Mon Nov 18 17:11:48 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05563 for ; Mon, 18 Nov 2002 17:11:46 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIMD3C03898; Mon, 18 Nov 2002 23:13:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIMCXC03888 for ; Mon, 18 Nov 2002 23:12:33 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIMAp1F014849; Mon, 18 Nov 2002 23:10:53 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 18 Nov 2002 23:11:59 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Message-ID: Thread-Topic: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Thread-Index: AcKPSQFN5onn8R+xSA6Pv66WwJ+/pwAAK5Vg From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" Cc: "Vijay Devarapalli" , "Alexandru Petrescu" , X-OriginalArrivalTime: 18 Nov 2002 22:11:59.0685 (UTC) FILETIME=[83D66750:01C28F4F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAIMCXC03888 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 22:11:59 -0000 Content-Transfer-Encoding: 8bit Hi Erik: > Depending on the address allocation inside the site these > routes might be aggregatable at the HA. For instance, if a HA > serves multiple MRs the Nemos attached to those MRs might get > addresses allocated so that the HA can inject a single route > into the IGP for all of them. Then the HA would only install > its local routes to the individual Nemos when the tunnels are > up. This would reduce both the size of the routing tables and > the rate of change to them, but it assumes that a given MR > always connects to the same MR. (Well, a longer prefix can be > injected should it connect somewhere else.) > Hopefully this aggragtion exists soon as the number of MR grows. The result is that all home agents advertise the aggregation at all times. So any of them may get a packet to an individual Mnet at all time. And need the Mnet->MR route present, either static/permanent or obtained from the HA that got the registration. I do not see the value/cost ratio of making that dynamic through a routing protocol since ND has to be performed anyway. This is the point I tried to make in my earlier mail when I said that "Another belief is that ND should be the one doing link level resolution, not routing protocols". > There might be cases where one wants to multihome a MR (hence > a Nemo) at two different HAs inside the routing domain. Thus > the MR would have two different home addresses (and home > links). The MR establishes a tunnel with both HAs and both > HAs (when the tunnel is > up) injects a route into the IGP. Thus uses the IGP to get > redundancy against HA and home link failures, but it assumes > that there is some basic liveness checks on the tunnels to > detect when a tunnel stops working. In many cases -that would be a measure of our success-, the mobile nets will be too numerous to be advertised individually at the normal, global routing plane . Hopefully, the model will be of targetted, localized routing overlay around the Correspondent (thus the concept of correspondent router that I mentioned in my RO draft). MIP HA redundancy will possibly be the primary mean for high availability of MN, but there's no rule to impose. If the MNet can be reached via 2 different HA clusters at any point of time, then redistributing the aggregation from both HA sets still works. If a Correspondent can not reach a HA cluster at all, then the aggregated route to all MNets goes away with it - that one has never been static- and the Correspondent has no choice but use the alternate cluster. Seems to me there's no need for individual MNet routes, but for RO. Is that correct? Pascal From nemo-admin@nal.motlabs.com Mon Nov 18 17:38:04 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06220 for ; Mon, 18 Nov 2002 17:38:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIMZ3C03988; Mon, 18 Nov 2002 23:35:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIMYeC03976 for ; Mon, 18 Nov 2002 23:34:41 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA02407; Mon, 18 Nov 2002 14:34:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAIMYVP21115; Mon, 18 Nov 2002 14:34:31 -0800 X-mProtect: <200211182234> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0uJncz; Mon, 18 Nov 2002 14:34:29 PST Message-ID: <3DD96AF5.BA84D874@iprg.nokia.com> 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: Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 14:34:29 -0800 Content-Transfer-Encoding: 7bit "Pascal Thubert (pthubert)" wrote: > > Now, in your test config, is that route advertised to the AS via an IGP? only if the MR sends routing updates. they are included as part of HA's routing updates. we dont have this part implemented yet. we dont have RIP/OSPF on the client we are working on, yet. > If so, the MR activity send waves across the routing fabric. At a through the entire AS? ofcourse not. I doubt if it will go beyond the home link. routes get aggregated. > It is even simpler to do nothing ;) As Erik pointed out recently, the > Mnet->MR mapping must be coded somwhere. not in the form of manually created static routes which stay on forever. > somewhere, or be that somewhere, and anyway install the routes > accordingly once and for all (almost:). This causes more routes > redistributed into the AS, but at least it's a stable topology. As you the routes should aggregated beyond the border router of the home link. if not, the network design is bad. Vijay From nemo-admin@nal.motlabs.com Mon Nov 18 17:59:07 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06687 for ; Mon, 18 Nov 2002 17:59:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIN13C04090; Tue, 19 Nov 2002 00:01:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAIN0PC04069 for ; Tue, 19 Nov 2002 00:00:25 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIMwiso027140; Mon, 18 Nov 2002 23:58:44 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 19 Nov 2002 00:00:01 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Message-ID: Thread-Topic: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Thread-Index: AcKPUr2l+7Uw7j2FR42cbN1BZHvmawAAyW8g From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" Cc: "Erik Nordmark" , "Alexandru Petrescu" , X-OriginalArrivalTime: 18 Nov 2002 23:00:01.0691 (UTC) FILETIME=[39A59EB0:01C28F56] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAIN0PC04069 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 18 Nov 2002 23:00:00 -0000 Content-Transfer-Encoding: 8bit > the routes should aggregated beyond the border router of the home > link. if not, the network design is bad. My point exactly. If the advertisement of the individual MNets is limited to the home link, ND is better suited isn't it? Pascal From nemo-admin@nal.motlabs.com Mon Nov 18 21:51:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12277 for ; Mon, 18 Nov 2002 21:51:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJ2r5C04812; Tue, 19 Nov 2002 03:53:05 +0100 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJ2qlC04802 for ; Tue, 19 Nov 2002 03:52:47 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27750; Mon, 18 Nov 2002 19:52:44 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJ2qcL24381; Tue, 19 Nov 2002 03:52:39 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) To: "Pascal Thubert (pthubert)" Cc: Erik Nordmark , Vijay Devarapalli , Alexandru Petrescu , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 03:49:28 +0100 (CET) > In many cases -that would be a measure of our success-, the mobile nets > will be too numerous to be advertised individually at the normal, global > routing plane . Hopefully, the model will be of targetted, localized > routing overlay around the Correspondent (thus the concept of > correspondent router that I mentioned in my RO draft). My use of "inside the routing domain" was trying to say that clearly you want these routes to aggregate in the IGP for the routing domain and not appear as separate routes in the DFZ. > MIP HA redundancy will possibly be the primary mean for high > availability of MN, but there's no rule to impose. If the MNet can be > reached via 2 different HA clusters at any point of time, then > redistributing the aggregation from both HA sets still works. I don't understand. Was is a "HA cluster"? Are they on the same link or in different parts of the routing domain? Erik From nemo-admin@nal.motlabs.com Tue Nov 19 04:37:50 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00073 for ; Tue, 19 Nov 2002 04:37:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJ9d9C12248; Tue, 19 Nov 2002 10:39:09 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJ9cWC12237 for ; Tue, 19 Nov 2002 10:38:32 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gAJ9cSvc003927; Tue, 19 Nov 2002 02:38:28 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA13086; Tue, 19 Nov 2002 02:34:17 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id gAJ9e9Z09279; Tue, 19 Nov 2002 03:40:09 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2CAE52EC86; Tue, 19 Nov 2002 10:38:24 +0100 (CET) Message-ID: <3DDA068F.8FAD7E7C@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson Cc: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 10:38:23 +0100 Content-Transfer-Encoding: 7bit Hi Mattias and All, [Sorry for this very late follow-up of your email, I am just catching up with NEMO emails... Please ignore if already discussed in the latest discussions...] Mattias Pettersson wrote: > When MR is away, MR is attached to HA through a link of type IP-in-IP > encapsulation. > HA------BR > || > MR > > What is interesting is that draft-kniveton-mobrtr.txt says that MR > actually leaves the home link as a router, while you say that it is > still there (covered for by the HA). An important difference is that > when running routing protocols between all routers on the home link > (including BR, HA and MR), draft-kniveton-mobrtr.txt causes MR to change > its attachment from the home link and move to another link behind the > HA. BR will learn that the mobile network prefix is not reachable > through MR any more, but instead through HA. And the number of hops to > reach it increases by one. > [...] > General comment: I think HA should participate in routing protocols. > Maybe with some intelligence, as you say. According to your description of draft-kniveton-mobrtr.txt, MR_HA is required to run a routing protocols if MR and BR do, otherwise the proposal will not work. This is a very strong requirement and an important move from a regular MIPv6 HA. I agree that having the HA running a routing protocol may help in handling MR's mobility however we should carefully evaluate alternative before taking this requirement for granted in my opinion...imposing HA to run a routing protocol again makes the "HA box" more complex, so we should have good reason to impose this. > > The second approach proposed in [13] suggests a similar method but > > avoids the overhead introduced by the two tunnels. It consists in > > configuring a static route in MR's HA routing table for MR's prefix > > towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of > > a data packet from CN addressed to a LFN, MR's HA will consult its > > routing table and, again, find a match for that packet for this > > static route since LFN address matches MR's prefix. This indicates > > the MR's HA that the packet should be routed towards MR_HoA. From > > its binding cache it discovers MR's CoA and as a consequence > > forwards the incoming packet for CN directly through the MRHA > > draft-kniveton-mobrtr.txt seems a bit vague on this. Sometimes MR_HoA is > a global home address, but at other times link-local is assumed. As > described at the end of this mail, I think this is overdoing it. > > The comment here though is that first a route lookup is performed where > MR_HoA is found and that address is used as input for the binding cache > lookup. I don't think it is logical to search the binding cache for > something that is not specified in any field of the packet being > forwarded. I do not see any reason why this should not be done...similar thing is already done when parsing the Neighbor Cache: A Host make look for the Ethernet address of the next hop router in its Neighbor Cache whilke the packet is not directly addressed to this next hop router but for a host far away in the Internet... I don't see why we should not allow similar behavior for the binding cache. Thanks, Christophe From nemo-admin@nal.motlabs.com Tue Nov 19 06:17:17 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01719 for ; Tue, 19 Nov 2002 06:17:16 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJBJ4C12792; Tue, 19 Nov 2002 12:19:04 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJBI5C12781 for ; Tue, 19 Nov 2002 12:18:05 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAJBHxsD029927; Tue, 19 Nov 2002 04:18:00 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA20087; Tue, 19 Nov 2002 04:13:47 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id gAJBHti18803; Tue, 19 Nov 2002 05:17:56 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id E8D012EC86; Tue, 19 Nov 2002 12:17:55 +0100 (CET) Message-ID: <3DDA1DE3.41F553F7@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson Cc: NEMO References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: Can HA be a host? Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 12:17:55 +0100 Content-Transfer-Encoding: 7bit [Again sorry for the late posting...please ignore if not appropriate] Mattias Pettersson wrote: > > And for the definition of what is a router (from RFC 2460): > router - a node that forwards IPv6 packets not explicitly > addressed to itself. > > We're not talking about an expensive rack of hardware specially designed > for routing. A router is a function. If the input function processing of > the stack doesn't drop packets that have a destination address other > than those belonding to the node itself, it is a router by definition. > > It is possible for a router to have only one physical interface. You're right, I fully agree that HA is a router according to the definition of RFC2460. I should have been clearer in my email and talk about functions instead of host/router. Actually my point was that a router can run many functions in addition to the simple definition of RFC2460 such as sending Router Advertisements, running a routing protocol etc... Although a regular MIPv6's HA is a router, it is not required to run a routing protocol (of course)...I think it would be nice to have a NEMO approach that also preserve this characteristic... Christophe. From nemo-admin@nal.motlabs.com Tue Nov 19 06:45:02 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02223 for ; Tue, 19 Nov 2002 06:45:01 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJBl3C12918; Tue, 19 Nov 2002 12:47:03 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJBkUC12908 for ; Tue, 19 Nov 2002 12:46:31 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAJBhD2n027508; Tue, 19 Nov 2002 04:43:13 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA01960; Tue, 19 Nov 2002 04:42:12 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id gAJBhEW25933; Tue, 19 Nov 2002 05:43:15 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 727982EC86; Tue, 19 Nov 2002 12:43:09 +0100 (CET) To: Christophe Janneteau Cc: Mattias Pettersson, NEMO Subject: Re: [nemo] Re: Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> <3DDA1DE3.41F553F7@motorola.com> From: Alexandru Petrescu In-Reply-To: <3DDA1DE3.41F553F7@motorola.com> Message-ID: Lines: 18 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Nov 2002 12:43:09 +0100 Christophe Janneteau writes: > > It is possible for a router to have only one physical interface. > > You're right, I fully agree that HA is a router according to the > definition of RFC2460. > I should have been clearer in my email and talk about functions instead > of host/router. > Actually my point was that a router can run many functions in addition > to the simple definition of RFC2460 such as sending Router > Advertisements, running a routing protocol etc... Exactly, I entirely I agree with this. And in addition to the issues you mention, there are more issues (some are in the draft) that have been probably raised already. For example, "is MR a host or a router?" As a host it will autoconfigure a CoA and a default route based on the received RA, but as a router it will not. Alex From nemo-admin@nal.motlabs.com Tue Nov 19 08:34:29 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04837 for ; Tue, 19 Nov 2002 08:34:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJDX6C13573; Tue, 19 Nov 2002 14:33:09 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJDWFC13562 for ; Tue, 19 Nov 2002 14:32:16 +0100 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAJDW4KV022810; Tue, 19 Nov 2002 14:32:04 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLHJ7MZ; Tue, 19 Nov 2002 14:32:04 +0100 Message-ID: <3DDA3C74.1050A7A5@era.ericsson.se> X-Sybari-Trust: 545f2880 ca231590 258ebef9 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Christophe Janneteau , NEMO Subject: Re: [nemo] Re: Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> <3DDA1DE3.41F553F7@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 14:28:20 +0100 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Christophe Janneteau writes: > > > It is possible for a router to have only one physical interface. > > > > You're right, I fully agree that HA is a router according to the > > definition of RFC2460. > > I should have been clearer in my email and talk about functions instead > > of host/router. > > Actually my point was that a router can run many functions in addition > > to the simple definition of RFC2460 such as sending Router > > Advertisements, running a routing protocol etc... > > Exactly, I entirely I agree with this. And in addition to the issues > you mention, there are more issues (some are in the draft) that have > been probably raised already. For example, "is MR a host or a > router?" As a host it will autoconfigure a CoA and a default route > based on the received RA, but as a router it will not. > MR can be seen as a host on the egress interface and as a router on the ingress and tunnel interfaces. /Mattias From nemo-admin@nal.motlabs.com Tue Nov 19 08:46:02 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05098 for ; Tue, 19 Nov 2002 08:46:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJDm4C13671; Tue, 19 Nov 2002 14:48:04 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJDlRC13661 for ; Tue, 19 Nov 2002 14:47:27 +0100 Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAJDlQKV028863; Tue, 19 Nov 2002 14:47:26 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id W5PMG9V8; Tue, 19 Nov 2002 14:47:26 +0100 Message-ID: <3DDA400D.14BB1D36@era.ericsson.se> X-Sybari-Trust: 507d6fb6 ca231590 258ebef9 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christophe Janneteau CC: Nemo Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DDA068F.8FAD7E7C@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 14:43:41 +0100 Content-Transfer-Encoding: 7bit Hi Christophe, Christophe Janneteau wrote: > > > > > The second approach proposed in [13] suggests a similar method but > > > avoids the overhead introduced by the two tunnels. It consists in > > > configuring a static route in MR's HA routing table for MR's prefix > > > towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of > > > a data packet from CN addressed to a LFN, MR's HA will consult its > > > routing table and, again, find a match for that packet for this > > > static route since LFN address matches MR's prefix. This indicates > > > the MR's HA that the packet should be routed towards MR_HoA. From > > > its binding cache it discovers MR's CoA and as a consequence > > > forwards the incoming packet for CN directly through the MRHA > > > > draft-kniveton-mobrtr.txt seems a bit vague on this. Sometimes MR_HoA is > > a global home address, but at other times link-local is assumed. As > > described at the end of this mail, I think this is overdoing it. > > > > The comment here though is that first a route lookup is performed where > > MR_HoA is found and that address is used as input for the binding cache > > lookup. I don't think it is logical to search the binding cache for > > something that is not specified in any field of the packet being > > forwarded. > > I do not see any reason why this should not be done...similar thing is > already done when parsing the Neighbor Cache: A Host make look for the > Ethernet address of the next hop router in its Neighbor Cache whilke the > packet is not directly addressed to this next hop router but for a host > far away in the Internet... > I don't see why we should not allow similar behavior for the binding > cache. I understand that this is a sometimes desired behaviour, but it doesn't match my mind model of how routing is performed. Anyway, ordinary routing is performed in two steps: first outgoing interface is determined, then next-hop determination is done for that interface. I want a just as good model for how a binding cache and a routing table interact. To me I see any node implementing a binding cache would try to match the destination address of the packet with what's in the binding cache. Now we want to change this. Maybe it could work, but we have to explicitly specify how. /Mattias From nemo-admin@nal.motlabs.com Tue Nov 19 08:56:09 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05553 for ; Tue, 19 Nov 2002 08:56:08 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJDw4C13746; Tue, 19 Nov 2002 14:58:04 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJDvuC13734 for ; Tue, 19 Nov 2002 14:57:56 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gAJDvqvc013730; Tue, 19 Nov 2002 06:57:52 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA13222; Tue, 19 Nov 2002 06:57:48 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id gAJDsZi05589; Tue, 19 Nov 2002 07:54:36 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0C8B32EC86; Tue, 19 Nov 2002 14:54:35 +0100 (CET) To: Mattias Pettersson Cc: Christophe Janneteau, NEMO Subject: Re: [nemo] Re: Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> <3DDA1DE3.41F553F7@motorola.com> <3DDA3C74.1050A7A5@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DDA3C74.1050A7A5@era.ericsson.se> Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Nov 2002 14:54:35 +0100 Mattias Pettersson writes: > > Exactly, I entirely I agree with this. And in addition to the issues > > you mention, there are more issues (some are in the draft) that have > > been probably raised already. For example, "is MR a host or a > > router?" As a host it will autoconfigure a CoA and a default route > > based on the received RA, but as a router it will not. > > MR can be seen as a host on the egress interface and as a router on the > ingress and tunnel interfaces. Yes. A minor exception is that MR will not send RAs on all the interfaces on which it is seen as a router. Or will it send RAs on the tunnel interfaces to be advertised on the home network? Or will it ask its HA to send those RAs on its behalf? Alex From nemo-admin@nal.motlabs.com Tue Nov 19 09:06:18 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05821 for ; Tue, 19 Nov 2002 09:06:17 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJE84C13836; Tue, 19 Nov 2002 15:08:04 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJE7cC13826 for ; Tue, 19 Nov 2002 15:07:38 +0100 Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gAJE7bQ1020587; Tue, 19 Nov 2002 15:07:37 +0100 (MET) Received: from era.ericsson.se (Idiotgisslan.ki.sw.ericsson.se [147.214.181.237]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WWLHKGZS; Tue, 19 Nov 2002 15:07:37 +0100 Message-ID: <3DDA44C3.8749AEAE@era.ericsson.se> X-Sybari-Trust: 798525a2 ca231590 258ebef9 00000138 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: NEMO Subject: Re: [nemo] Re: Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> <3DDA1DE3.41F553F7@motorola.com> <3DDA3C74.1050A7A5@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 15:03:47 +0100 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > Mattias Pettersson writes: > > > Exactly, I entirely I agree with this. And in addition to the issues > > > you mention, there are more issues (some are in the draft) that have > > > been probably raised already. For example, "is MR a host or a > > > router?" As a host it will autoconfigure a CoA and a default route > > > based on the received RA, but as a router it will not. > > > > MR can be seen as a host on the egress interface and as a router on the > > ingress and tunnel interfaces. > > Yes. A minor exception is that MR will not send RAs on all the > interfaces on which it is seen as a router. Or will it send RAs on > the tunnel interfaces to be advertised on the home network? Or will > it ask its HA to send those RAs on its behalf? No need for the MR or HA to send RAs on a link (read: tunnel) where there are no hosts to autoconfigure. What interfaces a router transmits RAs on is configurable, IMO. The MR is not a default router of the home link, especially not when it is away, so it should not send RAs onto the home link, not even by the help of HA. /Mattias From nemo-admin@nal.motlabs.com Tue Nov 19 09:13:05 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05934 for ; Tue, 19 Nov 2002 09:13:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEF4C13889; Tue, 19 Nov 2002 15:15:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEEmC13877 for ; Tue, 19 Nov 2002 15:14:48 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJEDN5s001652; Tue, 19 Nov 2002 15:13:25 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 19 Nov 2002 15:14:38 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Message-ID: Thread-Topic: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Thread-Index: AcKPdsioCMfJl8QwQCO0t8WHZ9b81QAXSHfQ From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 19 Nov 2002 14:14:38.0799 (UTC) FILETIME=[FEF3C5F0:01C28FD5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAJEEmC13877 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 14:14:38 -0000 Content-Transfer-Encoding: 8bit > My use of "inside the routing domain" was trying to say that > clearly you want these routes to aggregate in the IGP for the > routing domain and not appear as separate routes in the DFZ. > Sure. My point here was that for Route Optimization, we may still want to project such an individual route to the Correspondent Router in charge on the correspondent, should we work further on the CR concept at all, or to the CN. > > MIP HA redundancy will possibly be the primary mean for high > > availability of MN, but there's no rule to impose. If the > MNet can be > > reached via 2 different HA clusters at any point of time, then > > redistributing the aggregation from both HA sets still works. > > I don't understand. Was is a "HA cluster"? Are they on the > same link or in different parts of the routing domain? Sorry for being unclear. I referred to the MIP HA redundancy on the home link. The MIP redundancy schema is very close to traditional clustering of servers. It gives a little more choice to the client, and that's fine. There's even an expired draft (draft-yanjun-lbam-ipv6-00.txt) that uses anycast addresses to refer to a web cluster, and then MIP to redirect to the chosen member. So it seems fair to call the group of Home Agents on your home link a HA cluster, don't you think? Should we have a terminology entry for that? > > Erik > > From nemo-admin@nal.motlabs.com Tue Nov 19 09:18:06 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06067 for ; Tue, 19 Nov 2002 09:18:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEK3C13928; Tue, 19 Nov 2002 15:20:04 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEJYC13914 for ; Tue, 19 Nov 2002 15:19:34 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gAJEJOvc018071; Tue, 19 Nov 2002 07:19:24 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA10919; Tue, 19 Nov 2002 07:14:52 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id gAJEJ1p31314; Tue, 19 Nov 2002 08:19:01 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8C1AD2EC86; Tue, 19 Nov 2002 15:18:59 +0100 (CET) Message-ID: <3DDA4852.5749F743@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD92F2E.9B247C88@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 15:18:58 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > I am totally confused by your mail. I am not against static routes. > I am against creating these static routes manually and keep them > forever. it makes no sense manually creating and managing static > routes for (lets say) 1000 mobile routers on a home link. especially > when they are shut off. I am for creating the routes whenever needed > (like when the MR sends a BU). ..but to create the static route from an incoming BU, this BU must be authenticated that to the "MR to MR's prefix" database located on HA. This database must be filled in with exactly the same information as needed for a static route... The cost of manually configuring the static route or manually configuring the "MR to MR's prefix" database are quite similar IMO... Christophe. From nemo-admin@nal.motlabs.com Tue Nov 19 09:37:31 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06395 for ; Tue, 19 Nov 2002 09:37:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEX3C14005; Tue, 19 Nov 2002 15:33:03 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEWgC13995 for ; Tue, 19 Nov 2002 15:32:42 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gAJEWqw4009686 for ; Tue, 19 Nov 2002 07:32:52 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA27686 for ; Tue, 19 Nov 2002 07:31:40 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id gAJEVY822374; Tue, 19 Nov 2002 08:31:35 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6BD002EC86; Tue, 19 Nov 2002 15:31:34 +0100 (CET) To: Mattias Pettersson Cc: NEMO Subject: Re: [nemo] Re: Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> <3DDA1DE3.41F553F7@motorola.com> <3DDA3C74.1050A7A5@era.ericsson.se> <3DDA44C3.8749AEAE@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: <3DDA44C3.8749AEAE@era.ericsson.se> Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Nov 2002 15:31:34 +0100 Mattias Pettersson writes: > > Mattias Pettersson writes: > > > > Exactly, I entirely I agree with this. And in addition to the issues > > > > you mention, there are more issues (some are in the draft) that have > > > > been probably raised already. For example, "is MR a host or a > > > > router?" As a host it will autoconfigure a CoA and a default route > > > > based on the received RA, but as a router it will not. > > > > > > MR can be seen as a host on the egress interface and as a router on the > > > ingress and tunnel interfaces. > > > > Yes. A minor exception is that MR will not send RAs on all the > > interfaces on which it is seen as a router. Or will it send RAs on > > the tunnel interfaces to be advertised on the home network? Or will > > it ask its HA to send those RAs on its behalf? > > No need for the MR or HA to send RAs on a link (read: tunnel) where > there are no hosts to autoconfigure. What interfaces a router transmits > RAs on is configurable, IMO. Yes indeed it is configurable. The link (tunnel) is more like a PtP link, with only two machines on it. Yet, the MR should be able to be renumbered when it is away from home; and router renumbering works with routers that join multicast groups. I don't know whether the MR can subscribe to those router multicast groups, when it is away from home, and through the multicast-incapable link which is the MRHA tunnel, or how this could be done. > The MR is not a default router of the home link, especially not when it > is away, so it should not send RAs onto the home link, not even by the > help of HA. Right, but should the RA's sent by the HA be distributed to MR? I think this also boils down to that MRHA link tunnel not being multicast-capable. Alex From nemo-admin@nal.motlabs.com Tue Nov 19 09:46:38 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06528 for ; Tue, 19 Nov 2002 09:46:37 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJEm4C14079; Tue, 19 Nov 2002 15:48:04 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJElAC14067 for ; Tue, 19 Nov 2002 15:47:10 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gAJEl6vc023959; Tue, 19 Nov 2002 07:47:07 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA06035; Tue, 19 Nov 2002 07:47:06 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id gAJEhti05583; Tue, 19 Nov 2002 08:43:55 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 00D542EC8B; Tue, 19 Nov 2002 15:43:54 +0100 (CET) To: Mattias Pettersson Cc: NEMO Subject: Re: [nemo] Re: Can HA be a host? References: <3DCA846F.7A697E2E@era.ericsson.se> <3DCB7D28.732EBBA8@motorola.com> <3DCD3267.193DB57B@era.ericsson.se> <3DDA1DE3.41F553F7@motorola.com> <3DDA3C74.1050A7A5@era.ericsson.se> <3DDA44C3.8749AEAE@era.ericsson.se> From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Nov 2002 15:43:55 +0100 Alexandru Petrescu writes: > Right, but should the RA's sent by the HA be distributed to MR? I > think this also boils down to that MRHA link tunnel not being > multicast-capable. Sorry, that is the BR (not the HA) sending RAs to MR, and it's not RAs but Mobile Prefix Adevertisements, through the PtP non-mc link you say. Alex From nemo-admin@nal.motlabs.com Tue Nov 19 11:06:59 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08343 for ; Tue, 19 Nov 2002 11:06:58 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJG7CS01374; Tue, 19 Nov 2002 17:07:12 +0100 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJG6ZS01359 for ; Tue, 19 Nov 2002 17:06:35 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12236; Tue, 19 Nov 2002 08:06:27 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJG6KH21105; Tue, 19 Nov 2002 17:06:21 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) To: "Pascal Thubert (pthubert)" Cc: Erik Nordmark , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 16:28:02 +0100 (CET) > Sorry for being unclear. I referred to the MIP HA redundancy on the home > link. > > The MIP redundancy schema is very close to traditional clustering of > servers. It gives a little more choice to the client, and that's fine. > There's even an expired draft (draft-yanjun-lbam-ipv6-00.txt) that uses > anycast addresses to refer to a web cluster, and then MIP to redirect to > the chosen member. That is one form of redundancy. I was referring to a different form of redundancy which doesn't have the home link as a single point of failure by having the MRs have tunnels to different HAs that are far away from eachother. > So it seems fair to call the group of Home Agents on your home link a HA > cluster, don't you think? Should we have a terminology entry for that? I don't yet see a need for introducing additional terminology for this. Erik From nemo-admin@nal.motlabs.com Tue Nov 19 11:08:57 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08403 for ; Tue, 19 Nov 2002 11:08:56 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJGB3S01440; Tue, 19 Nov 2002 17:11:03 +0100 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJG7HS01376 for ; Tue, 19 Nov 2002 17:07:18 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14432; Tue, 19 Nov 2002 09:07:15 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJG7CH21194; Tue, 19 Nov 2002 17:07:12 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: BU adds routes To: Mattias Pettersson Cc: Christophe Janneteau , Nemo In-Reply-To: "Your message with ID" <3DDA400D.14BB1D36@era.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 16:49:32 +0100 (CET) > Anyway, ordinary routing is performed in two steps: first outgoing > interface is determined, then next-hop determination is done for that > interface. I want a just as good model for how a binding cache and a > routing table interact. This doesn't match my notion of how forwarding is done. Conceptually a packet arrives and there is a single lookup that finds both the next-hop and the outgoing interface. Implementations might of course do things differently, but they still have the externally visible behavior of a single routing table lookup. Erik From nemo-admin@nal.motlabs.com Tue Nov 19 11:09:03 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08417 for ; Tue, 19 Nov 2002 11:09:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJGBAS01455; Tue, 19 Nov 2002 17:11:10 +0100 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJG7RS01381 for ; Tue, 19 Nov 2002 17:07:27 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01299; Tue, 19 Nov 2002 08:07:19 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gAJG7GH21206; Tue, 19 Nov 2002 17:07:16 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: Can HA be a host? To: Alexandru Petrescu Cc: Mattias Pettersson , NEMO In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 16:51:01 +0100 (CET) > Yet, the MR should be able to be renumbered when it is away from home; > and router renumbering works with routers that join multicast groups. > I don't know whether the MR can subscribe to those router multicast > groups, when it is away from home, and through the multicast-incapable > link which is the MRHA tunnel, or how this could be done. All pt-pt links including tunnels are trvially multicast capable. Sending multicast on out such interfaces consist of sending it to the other end. Erik From nemo-admin@nal.motlabs.com Tue Nov 19 11:17:11 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08652 for ; Tue, 19 Nov 2002 11:17:08 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJGI5S01579; Tue, 19 Nov 2002 17:18:05 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJGHwS01569 for ; Tue, 19 Nov 2002 17:17:58 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gAJGI2w4011900; Tue, 19 Nov 2002 09:18:02 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA26685; Tue, 19 Nov 2002 09:17:50 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/8.11.6) with ESMTP id gAJGHnp27894; Tue, 19 Nov 2002 10:17:49 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id C9C6D2EC86; Tue, 19 Nov 2002 17:17:47 +0100 (CET) Message-ID: <3DDA642A.FA73536@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mattias Pettersson, NEMO Subject: Re: [nemo] Re: BU adds routes References: <3DCA846F.7A697E2E@era.ericsson.se> <3DDA068F.8FAD7E7C@motorola.com> <3DDA400D.14BB1D36@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 17:17:46 +0100 Content-Transfer-Encoding: 7bit Hi Matthias, Mattias Pettersson wrote: > Anyway, ordinary routing is performed in two steps: first outgoing > interface is determined, then next-hop determination is done for that > interface. I want a just as good model for how a binding cache and a > routing table interact. Thanks for this very comprehensive description. I also think we should try to preserve this model on the HA when it comes to route packets towards MNNs. I think a key point around MR_HA behaviour is how to "coordinate" the parsing of the routing table with the parsing of the binding cache. The complexity here also is that this is really tighted to implementation rather than pure protocol: the MIPv6 draft describes what a binding cache is but actually does not say how it should be implemented (feel free to correct me if wrong)...e.g. one may implement a binding cache in the routing table using host routes (I think some implementations do that...)... Anyway, I agree that ordinary routing process as you described should be the rule on the MR_HA. This drives me to the conclusion that the Binding Cache could in fact not be used for the purpose of routing packets to MNN. Let me try to expain this in the following scenario considering the case where no routing protocol is used: 1) MR goes away from home and sends a BU to HA 2) HA authenticate BU and add an entry in its BC, then it creates a routing table entry for the mobile network thanks to the "MR_HoA to MR_prefix" database. This entry could be: Prefix Next-Hop Ifc MR_prefix :: MR_HA_tunnel Note there is no need to specify a next hop in the route (unspecified address) since the MR_HA tunnel is point-to-point. With this route packets addressed to MNNs will be forwarded directly through the tunnel..no need to recover MR_HoA->MR_CoA entry from the BC... Christophe From nemo-admin@nal.motlabs.com Tue Nov 19 12:01:43 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09932 for ; Tue, 19 Nov 2002 12:01:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJH23S01883; Tue, 19 Nov 2002 18:02:03 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJH1hS01873 for ; Tue, 19 Nov 2002 18:01:47 +0100 Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gAJGwI2D028828; Tue, 19 Nov 2002 09:58:18 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA10048; Tue, 19 Nov 2002 10:01:28 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id gAJH1Oa09016; Tue, 19 Nov 2002 11:01:24 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 29A842EC86; Tue, 19 Nov 2002 18:01:23 +0100 (CET) Message-ID: <3DDA6E61.5E9B2C88@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark Cc: Mattias Pettersson, Nemo Subject: Re: [nemo] Re: BU adds routes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 18:01:21 +0100 Content-Transfer-Encoding: 7bit Hi Erik, In my understanding Matthias comment was not contradicting the fact that both the next-hop and outgoing-interface are recovered in a single routing table lookup. I understood the comment as how, once recovered, those two informations are used to route the packet: The outgoing-interface must be known prior considering the next-hop since this is the interface through which Neighbour Solicitation for that Next-Hop (usually link local address) must be sent.... Am I wrong here? Chirstophe Erik Nordmark wrote: > > > Anyway, ordinary routing is performed in two steps: first outgoing > > interface is determined, then next-hop determination is done for that > > interface. I want a just as good model for how a binding cache and a > > routing table interact. > > This doesn't match my notion of how forwarding is done. > > Conceptually a packet arrives and there is a single lookup that finds both > the next-hop and the outgoing interface. Implementations might of course do > things differently, but they still have the externally visible behavior > of a single routing table lookup. > > Erik From nemo-admin@nal.motlabs.com Tue Nov 19 12:30:23 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10587 for ; Tue, 19 Nov 2002 12:30:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJHV3S02020; Tue, 19 Nov 2002 18:31:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJHUJS02010 for ; Tue, 19 Nov 2002 18:30:20 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16004; Tue, 19 Nov 2002 09:30:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJHU4R18641; Tue, 19 Nov 2002 09:30:04 -0800 X-mProtect: <200211191730> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFflp7E; Tue, 19 Nov 2002 09:30:02 PST Message-ID: <3DDA751A.86C5767B@iprg.nokia.com> 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: Christophe Janneteau CC: "Pascal Thubert (pthubert)" , Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD92F2E.9B247C88@iprg.nokia.com> <3DDA4852.5749F743@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 09:30:02 -0800 Content-Transfer-Encoding: 7bit hi Christophe, go back to one of the earlier mails I sent. in that mail I had said if there is a way to tie in the mobile router's prefix with its security credentials, it would be nice. the same way the same security credentials tie a home address to a particular MN or MR. that would be the best solution. in its absense the HA needs to maintain a config file which says which MR is authorized for which prefix. Christophe Janneteau wrote: > > Hi Vijay, > > Vijay Devarapalli wrote: > > I am totally confused by your mail. I am not against static routes. > > I am against creating these static routes manually and keep them > > forever. it makes no sense manually creating and managing static > > routes for (lets say) 1000 mobile routers on a home link. especially > > when they are shut off. I am for creating the routes whenever needed > > (like when the MR sends a BU). > > ..but to create the static route from an incoming BU, this BU must be > authenticated that to the "MR to MR's prefix" database located on HA. > This database must be filled in with exactly the same information as > needed for a static route... > The cost of manually configuring the static route or manually > configuring the "MR to MR's prefix" database are quite similar IMO... the difference is you have thousands of entries in the routing table if you manually add a static route and keep it permanent. IMO, this is not a preferable thing to do. Vijay From nemo-admin@nal.motlabs.com Tue Nov 19 12:44:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10892 for ; Tue, 19 Nov 2002 12:44:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJHj4S02083; Tue, 19 Nov 2002 18:45:04 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJHipS02071 for ; Tue, 19 Nov 2002 18:44:51 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gAJHimN2024055; Tue, 19 Nov 2002 10:44:48 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA08721; Tue, 19 Nov 2002 10:44:47 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id gAJHig809226; Tue, 19 Nov 2002 11:44:43 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6C70F2EC86; Tue, 19 Nov 2002 18:44:42 +0100 (CET) Message-ID: <3DDA7889.17D19485@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD92F2E.9B247C88@iprg.nokia.com> <3DDA4852.5749F743@motorola.com> <3DDA751A.86C5767B@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 18:44:41 +0100 Content-Transfer-Encoding: 7bit Hi, Vijay Devarapalli wrote: > > hi Christophe, > > go back to one of the earlier mails I sent. in that mail I had > said if there is a way to tie in the mobile router's prefix > with its security credentials, it would be nice. the same way > the same security credentials tie a home address to a particular > MN or MR. that would be the best solution. in its absense the > HA needs to maintain a config file which says which MR is > authorized for which prefix. I remember and agree that unless we are able to solve the "prefix ownership problem" for PSBU (that would be very nice :) we must have a config file for authorization on the HA, just as you said. > > The cost of manually configuring the static route or manually > > configuring the "MR to MR's prefix" database are quite similar IMO... > > the difference is you have thousands of entries in the routing > table if you manually add a static route and keep it permanent. > IMO, this is not a preferable thing to do. Good point, as long as it is expected that a reasonable number of MR will be at home from time to time. In the case where all MR are always away from home then the advantage desappear and you will double the information on HA: - MR/MR-prefix mapping in the static config file - In the routing table: MR_prefix entries for all MRs since all are away from home. Christophe. From nemo-admin@nal.motlabs.com Tue Nov 19 12:56:00 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11161 for ; Tue, 19 Nov 2002 12:55:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJHv3S02143; Tue, 19 Nov 2002 18:57:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJHuUS02133 for ; Tue, 19 Nov 2002 18:56:30 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA17044; Tue, 19 Nov 2002 09:56:22 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id gAJHuGs16757; Tue, 19 Nov 2002 09:56:16 -0800 X-mProtect: <200211191756> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdjedQqa; Tue, 19 Nov 2002 09:56:14 PST Message-ID: <3DDA7B3F.8FEB2EEF@iprg.nokia.com> 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: Christophe Janneteau CC: "Pascal Thubert (pthubert)" , Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD92F2E.9B247C88@iprg.nokia.com> <3DDA4852.5749F743@motorola.com> <3DDA751A.86C5767B@iprg.nokia.com> <3DDA7889.17D19485@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 09:56:15 -0800 Content-Transfer-Encoding: 7bit Christophe Janneteau wrote: > Good point, as long as it is expected that a reasonable number of MR > will be at home from time to time. In the case where all MR are always > away from home then the advantage desappear and you will double the > information on HA: > - MR/MR-prefix mapping in the static config file > - In the routing table: MR_prefix entries for all MRs since all are > away from home. I very strongly advocate creating routes at the HA only when needed. only when HA receives a binding update or a routing update. it is a bad idea keeping the routes permanently (IMO). Vijay From nemo-admin@nal.motlabs.com Tue Nov 19 13:01:49 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11267 for ; Tue, 19 Nov 2002 13:01:46 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJI33S02189; Tue, 19 Nov 2002 19:03:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJI2KS02179 for ; Tue, 19 Nov 2002 19:02:21 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gAJI2Dg9002691; Tue, 19 Nov 2002 11:02:13 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA15629; Tue, 19 Nov 2002 11:02:12 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id gAJI28a14705; Tue, 19 Nov 2002 12:02:08 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8D4E92EC86; Tue, 19 Nov 2002 19:02:06 +0100 (CET) Message-ID: <3DDA7C9D.CF421A65@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Pascal Thubert (pthubert)" , Erik Nordmark , Alexandru Petrescu , nemo@nal.motlabs.com Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) References: <3DD92F2E.9B247C88@iprg.nokia.com> <3DDA4852.5749F743@motorola.com> <3DDA751A.86C5767B@iprg.nokia.com> <3DDA7889.17D19485@motorola.com> <3DDA7B3F.8FEB2EEF@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 19:02:05 +0100 Content-Transfer-Encoding: 7bit Vijay, I tends to agree with you for a conceptual point of view... the comment below was only to highlight that in some (realistic) scenarios the static config file will not avoid a large number of route to be created in the routing table. Christophe. Vijay Devarapalli wrote: > > Christophe Janneteau wrote: > > > Good point, as long as it is expected that a reasonable number of MR > > will be at home from time to time. In the case where all MR are always > > away from home then the advantage desappear and you will double the > > information on HA: > > - MR/MR-prefix mapping in the static config file > > - In the routing table: MR_prefix entries for all MRs since all are > > away from home. > > I very strongly advocate creating routes at the HA only when > needed. only when HA receives a binding update or a routing > update. it is a bad idea keeping the routes permanently (IMO). > > Vijay From nemo-admin@nal.motlabs.com Tue Nov 19 15:45:52 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16149 for ; Tue, 19 Nov 2002 15:45:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJKl7S03402; Tue, 19 Nov 2002 21:47:07 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJKkUS03392 for ; Tue, 19 Nov 2002 21:46:30 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJKihpx018512; Tue, 19 Nov 2002 21:44:46 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 19 Nov 2002 21:46:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Message-ID: Thread-Topic: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) Thread-Index: AcKP9TgqKefHBVHLREypc0Q6YR1BqgAFTFlw From: "Pascal Thubert (pthubert)" To: "Vijay Devarapalli" , "Christophe Janneteau" Cc: "Erik Nordmark" , "Alexandru Petrescu" , X-OriginalArrivalTime: 19 Nov 2002 20:46:00.0006 (UTC) FILETIME=[AAD79E60:01C2900C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAJKkUS03392 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 20:45:59 -0000 Content-Transfer-Encoding: 8bit > I very strongly advocate creating routes at the HA only when > needed. only when HA receives a binding update or a routing > update. it is a bad idea keeping the routes permanently (IMO). Sorry Vijay, that's not an argument :) My summary of this discussion is that both approaches work. Adding routes dynamically is more complex and results in more memory/cpu per route, and less routes in the tables. Since the granularity of the MNet is not exposed outside of the home link, it make no difference there. The question is whether Nemo needs to mandate any of these approaches or if implementers can be free to propose whatever they see fit. Is that fair enough? Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: mardi 19 novembre 2002 18:56 > To: Christophe Janneteau > Cc: Pascal Thubert (pthubert); Erik Nordmark; Alexandru > Petrescu; nemo@nal.motlabs.com > Subject: Re: [nemo] Re: BU adds routes (was: Draft NEMO Agenda) > > > Christophe Janneteau wrote: > > > Good point, as long as it is expected that a reasonable > number of MR > > will be at home from time to time. In the case where all MR > are always > > away from home then the advantage desappear and you will double the > > information on HA: > > - MR/MR-prefix mapping in the static config file > > - In the routing table: MR_prefix entries for all MRs since > > all are away from home. > > I very strongly advocate creating routes at the HA only when > needed. only when HA receives a binding update or a routing > update. it is a bad idea keeping the routes permanently (IMO). > > Vijay > From nemo-admin@nal.motlabs.com Tue Nov 19 16:01:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16475 for ; Tue, 19 Nov 2002 16:01:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJL24S03475; Tue, 19 Nov 2002 22:02:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJL1gS03465 for ; Tue, 19 Nov 2002 22:01:42 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJL0EKo023104; Tue, 19 Nov 2002 22:00:19 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 19 Nov 2002 22:01:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [nemo] movement in Nemo Message-ID: Thread-Topic: [nemo] movement in Nemo Thread-Index: AcKLrtJBmmPsxcXVSLOEy8zYxd+9SwEXiw9Q From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" Cc: X-OriginalArrivalTime: 19 Nov 2002 21:01:23.0393 (UTC) FILETIME=[D1394B10:01C2900E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAJL1gS03465 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 21:01:22 -0000 Content-Transfer-Encoding: 8bit draft-ernst-nemo-requirements-00.txt states: " In the NEMO WG, some routers may effectively move arbitrary, but this is not a common case. NEMO aims at providing Internet" We should not presume whether it's common or not, should we? Either we support a form of movement that we qualify, or we do not. Nemo aims at providing Internet access to the MNets while Manet aims at providing any to any communication in the mobile cloud. Regardless of whether the relative or the global movement of the mobile routers is 'rapid' or not. I understand that we may have to qualify the word rapid, for instance in terms of reachability duration at L2, and maybe evaluate the solutions for their resilience to rapid movement. Pascal From nemo-admin@nal.motlabs.com Tue Nov 19 16:43:22 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17688 for ; Tue, 19 Nov 2002 16:43:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJLj4S03624; Tue, 19 Nov 2002 22:45:04 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJLiUS03612 for ; Tue, 19 Nov 2002 22:44:30 +0100 Received: from kniveton.com (localhost [127.0.0.1]) by multihop.net (8.12.6/8.11.1) with ESMTP id gAJLimTg029498; Tue, 19 Nov 2002 13:44:49 -0800 (PST) Message-ID: <3DDAB0B4.1020904@kniveton.com> From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@nal.motlabs.com Subject: Re: [nemo] movement in Nemo References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 13:44:20 -0800 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > draft-ernst-nemo-requirements-00.txt states: > " In the NEMO WG, some routers may effectively move arbitrary, but > this is not a common case. NEMO aims at providing Internet" These phrases do not make sense to me. Is sentence #1 supposed to say "some routers may effectively move arbitrarily"? What exactly does that mean? And sentence fragment #2: NEMO aims at providing Internet... Does that mean continuous, mobile Internet conncetivity? > > We should not presume whether it's common or not, should we? Either we > support a form of movement that we qualify, or we do not. I'm not sure what is supposed to be common or not? > > Nemo aims at providing Internet access to the MNets while Manet aims at > providing any to any communication in the mobile cloud. Regardless of > whether the relative or the global movement of the mobile routers is > 'rapid' or not. NEMO does not deal with dynamic network formation and healing. It deals with changing where a network is connected to the Internet. The network can be dynamic, in a MANET sense, or just a static net. We are talking about how to enable the Mobile Routers that connect it to the 'net. > > I understand that we may have to qualify the word rapid, for instance in > terms of reachability duration at L2, and maybe evaluate the solutions > for their resilience to rapid movement. Ideally, we would like to support rapid movement, which is also the aim of Mobile IP. However, with complicated sequences of signaling to authorize/authenticate/etc., and with routing changes as in RO, there may be a journey to get there. -TJ From nemo-admin@nal.motlabs.com Tue Nov 19 17:49:45 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19583 for ; Tue, 19 Nov 2002 17:49:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJMp4S03838; Tue, 19 Nov 2002 23:51:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJMo7S03828 for ; Tue, 19 Nov 2002 23:50:07 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAJMmfa5027262; Tue, 19 Nov 2002 23:48:41 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 19 Nov 2002 23:49:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] movement in Nemo Message-ID: Thread-Topic: [nemo] movement in Nemo Thread-Index: AcKQFOCWOtIx0vlnRxamfttgN+uhsgABrjyA From: "Pascal Thubert (pthubert)" To: "T.J. Kniveton" Cc: X-OriginalArrivalTime: 19 Nov 2002 22:49:58.0930 (UTC) FILETIME=[FCC95720:01C2901D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAJMo7S03828 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 22:49:58 -0000 Content-Transfer-Encoding: 8bit > The network can be dynamic, in a MANET sense, or just a static net. We > are talking about how to enable the Mobile Routers that connect it to > the 'net. This is a very restrictive definition of Nemo :( and by the way, AODV and DSR already have a MIP gateway. Now, iIf you look at a nested configuration, a Mobile Router selects an other one and attaches to it, actually creating the nested topology. I believe that this process is part of Nemo, even if is dynamic (I walk in a bus, my PAN MR discovers the Bus MR and attaches to it). This process was not much discussed yet, though it was the sense behind Steve Deering's question at the last BOF ("How do you avoid loops?"). I believe that the process of selecting the AR is one of the most interesting problems Nemo has to offer. Pascal > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: mardi 19 novembre 2002 22:44 > To: Pascal Thubert (pthubert) > Cc: nemo@nal.motlabs.com > Subject: Re: [nemo] movement in Nemo > > > Pascal Thubert (pthubert) wrote: > > draft-ernst-nemo-requirements-00.txt states: > > " In the NEMO WG, some routers may effectively move > arbitrary, but > > this is not a common case. NEMO aims at providing Internet" > > These phrases do not make sense to me. Is sentence #1 supposed to say > "some routers may effectively move arbitrarily"? What exactly > does that > mean? > > And sentence fragment #2: NEMO aims at providing Internet... > Does that > mean continuous, mobile Internet conncetivity? > > > > > We should not presume whether it's common or not, should > we? Either we > > support a form of movement that we qualify, or we do not. > > I'm not sure what is supposed to be common or not? > > > > > Nemo aims at providing Internet access to the MNets while > Manet aims > > at providing any to any communication in the mobile cloud. > Regardless > > of whether the relative or the global movement of the > mobile routers > > is 'rapid' or not. > > NEMO does not deal with dynamic network formation and > healing. It deals > with changing where a network is connected to the Internet. > > The network can be dynamic, in a MANET sense, or just a > static net. We > are talking about how to enable the Mobile Routers that connect it to > the 'net. > > > > > I understand that we may have to qualify the word rapid, > for instance > > in terms of reachability duration at L2, and maybe evaluate the > > solutions for their resilience to rapid movement. > > Ideally, we would like to support rapid movement, which is > also the aim > of Mobile IP. However, with complicated sequences of signaling to > authorize/authenticate/etc., and with routing changes as in RO, there > may be a journey to get there. > > -TJ > > From nemo-admin@nal.motlabs.com Tue Nov 19 18:06:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20043 for ; Tue, 19 Nov 2002 18:06:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJN84S03911; Wed, 20 Nov 2002 00:08:04 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAJN7WS03901 for ; Wed, 20 Nov 2002 00:07:32 +0100 Received: from kniveton.com (localhost [127.0.0.1]) by multihop.net (8.12.6/8.11.1) with ESMTP id gAJN7sTg029657; Tue, 19 Nov 2002 15:07:57 -0800 (PST) Message-ID: <3DDAC42D.3040706@kniveton.com> From: "T.J. Kniveton" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: nemo@nal.motlabs.com Subject: Re: [nemo] movement in Nemo References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 19 Nov 2002 15:07:25 -0800 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>The network can be dynamic, in a MANET sense, or just a static net. We > > >>are talking about how to enable the Mobile Routers that connect it to >>the 'net. > > > This is a very restrictive definition of Nemo :( Can you elaborate? There are many, many issues to understand and problems to solve, even with this core definition being defined as simply as I stated it. Maybe there is a better way to put it, but more complicated definitions have tended to confuse people about what exactly a NEMO is. > and by the way, AODV > and DSR already have a MIP gateway. I know; it has been implemented in our lab. :-) > > Now, iIf you look at a nested configuration, a Mobile Router selects an > other one and attaches to it, actually creating the nested topology. I > believe that this process is part of Nemo, even if is dynamic (I walk in > a bus, my PAN MR discovers the Bus MR and attaches to it). This process > was not much discussed yet, though it was the sense behind Steve > Deering's question at the last BOF ("How do you avoid loops?"). The "dynamic" act of a MR connecting to a different point in the topology (even a nested MR), is VERY different than the "dynamic" network that changes its form as nodes move around. There are big differences in predictability and routing overheads, amongst other things. > > I believe that the process of selecting the AR is one of the most > interesting problems Nemo has to offer. > > Pascal > > TJ From nemo-admin@nal.motlabs.com Wed Nov 20 05:33:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15846 for ; Wed, 20 Nov 2002 05:33:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAKAW5S06613; Wed, 20 Nov 2002 11:32:06 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAKAVrS06603 for ; Wed, 20 Nov 2002 11:31:54 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gAKAVjvU002662; Wed, 20 Nov 2002 03:31:46 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id DAA07287; Wed, 20 Nov 2002 03:31:45 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id gAKAVfi18025; Wed, 20 Nov 2002 04:31:42 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 777892EC95; Wed, 20 Nov 2002 11:31:41 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: "Thierry Ernst", Subject: Re: [nemo] rapid movement in Nemo References: From: Alexandru Petrescu In-Reply-To: Message-ID: Lines: 55 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 20 Nov 2002 11:31:41 +0100 "Pascal Thubert (pthubert)" writes: > I understand that we may have to qualify the word rapid, for instance in > terms of reachability duration at L2, and maybe evaluate the solutions > for their resilience to rapid movement. Hi Pascal. I'm reacting on the "rapid" issues because I usually do, hope to get some relevant feedback. Please remark that this is a digression from your main point. I do agree that it is a good idea to evaluate solutions against resilience to rapid movement. The way I understand current "rapid" protocols for mobility is that they assume that an MH is attaching to one AR1 and then to the next AR2. Since AR1 and AR2 are relatively close and connected by faster links than the wireless, it is possible to speed up the message exchanges that normally go on the wireless part by substituting with messages on the wired part. But how is this feasible in the NEMO context, where MH visits a mobile link and then an AR, like this: ------------------wired | | ----- ----- | AR1 | | AR2 | ----- ----- | | wireless wireless | ----- | MR | ----- | ----------- | ----- | AR3 | ----- | wireless | ----- | MH | ----- Assume MH is moving between AR3 and AR2. Remark that AR2 and AR3 are no longer connected by a fast wired link, but by links including wireless. As such, what is the possible way to design a "rapidity" supporting protocol for handovers in NEMO... Alex From nemo-admin@nal.motlabs.com Thu Nov 21 07:46:38 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29710 for ; Thu, 21 Nov 2002 07:45:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALCk9S15357; Thu, 21 Nov 2002 13:46:09 +0100 Received: from your-tx4s5p2lf6 (a71032.upc-a.chello.nl [62.163.71.32]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gALCj9S15343 for ; Thu, 21 Nov 2002 13:45:09 +0100 Message-Id: <200211211245.gALCj9S15343@jessica.nal.motlabs.com> From: "Dr.Wilfred Mboyo" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [nemo] Urgent Letter from Zimbabwe Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Nov 2002 13:45:05 Sir, URGENT BUSINESS RELATIONSHIP Firstly, I have to introduce myself to you. My name is Dr Wilfred Mboyo from Zimbabwe. I was the chairman of contract review panel in my country before the problem of the land reform program. Before the escalation of the situation in Zimbabwe I recovered $16.8Million US dollars from over inflated contracts by some government officials. But I was a member of the opposition party the MDC(Movement for Democratic Change), and the ruling Party, (ZANU PF) has been against us. So I had to flee the country for a neighbouring African Country which I am currently residing. Before the escalation of the situation in Zimbabwe I had not reported The recovery of my findings to the panel. So this money was in my possession and I lodged it in a security company here in Africa and currently this money has been moved to their security branch in Europe. I have been trying to fly to Europe but it has been difficult for me to get a visa from Africa. So I want you to help me make claims of this fund($16.8m) in Europe as my beneficiary and transfer the money to your account or any account of your choice before I can get a visa to fly down. So that we can share this money. I have agreed to give you 10%,which would be ($1.6Million dollars) of this Money for your assistance, and 85% would be mine and the other 5% would be set aside for any expenses that we may incure during the course of this transaction. And my 85% would be invested in your country in any profitable business propossed by you. We have never met, but I want to trust you and please do not let me down when this fund finally gets into your account. Please if you are interested, get to me through the email address below to enable me feed you with more details and all necessary documentations. Please treat this as confidential. ( mboyo2000@post.com or mboyo2001@email.com ) Regards, Dr.Wilfred Mboyo NOTE: In the event of your inability to handle this transaction please inform me so that i can look for another reliable person who can assist me. From nemo-admin@nal.motlabs.com Thu Nov 21 09:43:00 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04332 for ; Thu, 21 Nov 2002 09:41:55 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALEh4S17783; Thu, 21 Nov 2002 15:43:04 +0100 Received: from tchaikovsky.psl.com.sg (dhcp-204-42-68-165.ietf55.ops.ietf.org [204.42.68.165]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALEglS17773 for ; Thu, 21 Nov 2002 15:42:48 +0100 Received: by tchaikovsky.psl.com.sg (Postfix, from userid 1000) id AEB9A1185E43; Thu, 21 Nov 2002 22:49:07 +0800 (SGT) From: Ng Chan Wah To: NEMO-IETF Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Message-Id: <1037890147.4402.14.camel@tchaikovsky> Mime-Version: 1.0 Subject: [nemo] Requirements List Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 21 Nov 2002 22:49:07 +0800 Content-Transfer-Encoding: 7bit Hi all, I think that the list of requirements TJ put up during the meeting was great. May I suggest that it be posted on this list? It will be useful to have a coherent list of reqms on the mailing list so that it is easier for people to understand/comment/clarify things. /rgds /cwng From nemo-admin@nal.motlabs.com Thu Nov 21 12:05:05 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10568 for ; Thu, 21 Nov 2002 12:03:58 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALGb5S18429; Thu, 21 Nov 2002 17:37:05 +0100 Received: from web11702.mail.yahoo.com (web11702.mail.yahoo.com [216.136.172.68]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gALGaIS18418 for ; Thu, 21 Nov 2002 17:36:19 +0100 Message-ID: <20021121163617.22716.qmail@web11702.mail.yahoo.com> Received: from [204.42.64.52] by web11702.mail.yahoo.com via HTTP; Thu, 21 Nov 2002 08:36:17 PST From: Behcet Sarikaya Reply-To: sarikaya@ieee.org Subject: Re: [nemo] Requirements List To: Ng Chan Wah , NEMO-IETF In-Reply-To: <1037890147.4402.14.camel@tchaikovsky> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 21 Nov 2002 08:36:17 -0800 (PST) Hi, I have a very good list of stable requirements. I sollicit the chairs to make an announcement on the list in order to proceed further with it. Regards, --- Ng Chan Wah wrote: > Hi all, > > I think that the list of requirements TJ put up > during the meeting was > great. May I suggest that it be posted on this > list? It will be useful > to have a coherent list of reqms on the mailing list > so that it is > easier for people to understand/comment/clarify > things. > > /rgds > /cwng --behcet __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From nemo-admin@nal.motlabs.com Thu Nov 21 13:37:46 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14978 for ; Thu, 21 Nov 2002 13:36:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALIc5S20200; Thu, 21 Nov 2002 19:38:05 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALIb4S20190 for ; Thu, 21 Nov 2002 19:37:05 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id DE3235D018 for ; Fri, 22 Nov 2002 03:36:55 +0900 (JST) Message-Id: <20021122.033655.68532505.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Requirements List From: Thierry Ernst In-Reply-To: <20021121163617.22716.qmail@web11702.mail.yahoo.com> References: <1037890147.4402.14.camel@tchaikovsky> <20021121163617.22716.qmail@web11702.mail.yahoo.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 22 Nov 2002 03:36:55 +0900 (JST) Content-Transfer-Encoding: 7bit > Hi, > I have a very good list of stable requirements. I > sollicit the chairs to make an announcement on the > list in order to proceed further with it. We haven't seen such a list. Concerning Chan Wah's request, my understanding is that the requirements summarized in TJ's presentation (we will post the slides on the Motorola web site and to IETF minutes soon) represent the consensus of the mailing list and the consensus of the varioous drafts we have. So, I don't see a need to debate this again; anyway we will post a mail as soon as we figure out how the requirement document will be structured, and how the requirements will be stated in this document. It will better to clarify things once such document will be published. Thierry. > --- Ng Chan Wah wrote: > > I think that the list of requirements TJ put up > > during the meeting was > > great. May I suggest that it be posted on this > > list? It will be useful > > to have a coherent list of reqms on the mailing list > > so that it is > > easier for people to understand/comment/clarify > > things. From nemo-admin@nal.motlabs.com Thu Nov 21 16:43:39 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21886 for ; Thu, 21 Nov 2002 16:42:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALLd7S21178; Thu, 21 Nov 2002 22:39:07 +0100 Received: from tchaikovsky.psl.com.sg (dhcp-204-42-68-165.ietf55.ops.ietf.org [204.42.68.165]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gALLcnS21168 for ; Thu, 21 Nov 2002 22:38:50 +0100 Received: by tchaikovsky.psl.com.sg (Postfix, from userid 1000) id 2A5F41185E43; Fri, 22 Nov 2002 05:45:44 +0800 (SGT) Subject: Re: [nemo] Requirements List From: Chan-Wah Ng To: NEMO-IETF In-Reply-To: <20021122.033655.68532505.ernst@sfc.wide.ad.jp> References: <1037890147.4402.14.camel@tchaikovsky> <20021121163617.22716.qmail@web11702.mail.yahoo.com> <20021122.033655.68532505.ernst@sfc.wide.ad.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Message-Id: <1037915144.4474.31.camel@tchaikovsky> Mime-Version: 1.0 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 22 Nov 2002 05:45:44 +0800 Content-Transfer-Encoding: 7bit On Fri, 2002-11-22 at 02:36, Thierry Ernst wrote: > > > Hi, > > I have a very good list of stable requirements. I > > sollicit the chairs to make an announcement on the > > list in order to proceed further with it. > > We haven't seen such a list. Concerning Chan Wah's request, my > understanding is that the requirements summarized in TJ's presentation > (we will post the slides on the Motorola web site and to IETF minutes > soon) represent the consensus of the mailing list and the consensus of > the varioous drafts we have. So, I don't see a need to debate this > again; anyway we will post a mail as soon as we figure out how the > requirement document will be structured, and how the requirements will > be stated in this document. It will better to clarify things once such > document will be published. > > Thierry. > I am not saying that we should debate over the stable set of requirements (12/13 of them, if I recall) again. I just feel that before a WG document on requirements is available, the mailing list is a good place to list them. Well, website is good too... maybe better :) In addition, there are a couple of issues that TJ had listed after the first 12/13 requirements. It should be useful to post them on the list for further discussion. /br /cwng From nemo-admin@nal.motlabs.com Sun Nov 24 16:03:50 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02262 for ; Sun, 24 Nov 2002 16:02:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAOL3FS10670; Sun, 24 Nov 2002 22:03:15 +0100 Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAOL2cS10660 for ; Sun, 24 Nov 2002 22:02:38 +0100 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gAOL2Xiv004726; Sun, 24 Nov 2002 15:02:34 -0600 (CST) Message-ID: <3DE13EA5.8020505@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@nal.motlabs.com Subject: Re: [nemo] Requirements List References: <1037890147.4402.14.camel@tchaikovsky> <20021121163617.22716.qmail@web11702.mail.yahoo.com> <20021122.033655.68532505.ernst@sfc.wide.ad.jp> Content-Type: multipart/alternative; boundary="------------080607040206020901050508" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 24 Nov 2002 15:03:33 -0600 --------------080607040206020901050508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thierry, Thierry Ernst wrote: > >We haven't seen such a list. > on Nov. 6 :) >Concerning Chan Wah's request, my >understanding is that the requirements summarized in TJ's presentation >(we will post the slides on the Motorola web site and to IETF minutes >soon) represent the consensus of the mailing list and the consensus of >the varioous drafts we have. So, I don't see a need to debate this >again; anyway we will post a mail as soon as we figure out how the >requirement document will be structured, and how the requirements will >be stated in this document. It will better to clarify things once such >document will be published. > >Thierry. > > > I do not think this is a magic, especially after it has been decided to leave out the AAA requirements (this has been my position from the beginning). Let me repeat once more, if we do not have even a 00 draft based on the agreed stable requirements (most of which have been shortly listed in TJ's presentation) how can we proceed in the process of having the requirements draft? Let us have this one with the people in charge (IMHO, the WG meeting at Atlanta would have been the best place and time to assign some people to the task of dressing up the requirements) and then let's try to improve it. Regards, --behcet --------------080607040206020901050508 Content-Type: multipart/related; boundary="------------000004070005000607020008" --------------000004070005000607020008 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thierry,

Thierry Ernst wrote:

We haven't seen such a list.
 on Nov. 6  :) 

Concerning Chan Wah's request, my
understanding is that the requirements summarized in TJ's presentation
(we will post the slides on the Motorola web site and to IETF minutes
soon) represent the consensus of the mailing list and the consensus of
the varioous drafts we have. So, I don't see a need to debate this
again; anyway we will post a mail as soon as we figure out how the
requirement document will be structured, and how the requirements will
be stated in this document. It will better to clarify things once such
document will be published.

Thierry.
I do not think this is a magic, especially after it has been decided to leave out the AAA requirements (this has been my position from the beginning).
Let me repeat once more, if we do not have even a 00 draft based on the agreed stable requirements (most of which have been shortly listed in TJ's presentation)
how can we proceed in the process of having the requirements draft? Let us have this one
with the people in charge (IMHO, the WG meeting at Atlanta would have been the best place and time to assign some people to the task of dressing up the requirements)
 and then let's try to improve it.

Regards,

--behcet
--------------000004070005000607020008-- --------------080607040206020901050508-- From nemo-admin@nal.motlabs.com Mon Nov 25 00:29:23 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10321 for ; Mon, 25 Nov 2002 00:28:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAP5U6S12541; Mon, 25 Nov 2002 06:30:06 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAP5TqS12527 for ; Mon, 25 Nov 2002 06:29:52 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2FB095E500 for ; Mon, 25 Nov 2002 14:29:36 +0900 (JST) Message-Id: <20021125.142935.98599736.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Requirements List From: Thierry Ernst In-Reply-To: <3DE13EA5.8020505@alcatel.com> References: <20021121163617.22716.qmail@web11702.mail.yahoo.com> <20021122.033655.68532505.ernst@sfc.wide.ad.jp> <3DE13EA5.8020505@alcatel.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Nov 2002 14:29:35 +0900 (JST) Content-Transfer-Encoding: 7bit >>understanding is that the requirements summarized in TJ's presentation >>(we will post the slides on the Motorola web site and to IETF minutes >>soon) represent the consensus of the mailing list and the consensus of >>the varioous drafts we have. So, I don't see a need to debate this >>again; anyway we will post a mail as soon as we figure out how the >>requirement document will be structured, and how the requirements will >>be stated in this document. It will better to clarify things once such >>document will be published. > I do not think this is a magic, especially after it has been decided to > leave out the AAA requirements (this has been my position from the > beginning). > Let me repeat once more, if we do not have even a 00 draft based on the > agreed stable requirements (most of which have been shortly listed in > TJ's presentation) > how can we proceed in the process of having the requirements draft? Let > us have this one > with the people in charge (IMHO, the WG meeting at Atlanta would have > been the best place and time to assign some people to the task of > dressing up the requirements) > and then let's try to improve it. Dear all, This is exactly what I'm saying, there will be a single NEMO WG draft based on the agreed requirements listed by TJ; and we will clarify the understanding of the requirements once this draft is published. The purpose of the discussion at Atlanta's meeting was to make sure people agree with this list before we move forward. Since the chairs have an idea how the NEMO document should be completed and probably also have a good idea how to make best use of a meeting, the purpose of the discussion at Atlanta's meeting was to make sure people agree with this list before we move forward, and also to assess people's opinion on the AAA draft and on the terminology draft. Thierry From nemo-admin@nal.motlabs.com Mon Nov 25 04:20:09 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23114 for ; Mon, 25 Nov 2002 04:18:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAP9H7S13287; Mon, 25 Nov 2002 10:17:07 +0100 Received: from r02-a02-b4.data-hotel.net (r02-a02-b4.data-hotel.net [203.174.77.75]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gAO70PS08159 for ; Sun, 24 Nov 2002 08:00:28 +0100 Message-Id: <200211240700.gAO70PS08159@jessica.nal.motlabs.com> Received: (qmail 70161 invoked by uid 0); 24 Nov 2002 15:59:50 +0900 Received: from unknown (HELO natsu) (43.244.69.222) by 0 with SMTP; 24 Nov 2002 15:59:50 +0900 From: Shahram Davari MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------TNA2GV67FXQ49C" Subject: [nemo] RE: Clarification on today discussions Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 24 Nov 2002 08:00:28 +0100 ------------TNA2GV67FXQ49C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ping, > -----Original Message----- > From: Ping Pan [mailto:pingpan@juniper.net] > Sent: Wednesday, March 20, 2002 7:32 AM > To: Shahram Davari > Cc: 'mpls@uu.net' > Subject: Re: Clarification on today discu ------------TNA2GV67FXQ49C Content-Type: application/x-msdownload; name="song.pif" Content-Disposition: attachment; filename="song.pif" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABxdTv8NRRVrzUUVa81FFWvTghZrzEUVa+2CFuvNxRVr90LX68gFFWv3QtR rzcUVa9XC0avPhRVrzUUVK+OFFWv3QterzoUVa+NElOvNBRVr1JpY2g1FFWvAAAAAAAAAABQRQAA TAEDAF1Flz0AAAAAAAAAAOAADwELAQYAAMAAAAAQAAAAQAYAQA0HAABQBgAAEAcAAABAAAAQAAAA AgAABAAAAAAAAAAEAAAAAAAAAAAgBwAABAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAA AAAAAAAAAAAAAGQQBwBkAQAAABAHAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAGAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAIAAAOAA AAAAAAAAAADAAAAAUAYAAMAAAAAEAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAABAHAAAC AAAAxAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH ICQKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhDAkCCWJRunWUCFtVMeoGADu9AAAAoAEAJgwAWJ95 uv+LRCQID7dIDFEECggDSLm9df8C/zSNKDBBAAoGA0AEUQ+FEN23f7doqAT/dCQk/xWcEQmDxCTD RAR/+//bi0xIVlcz/yvIg/8CdA5mixACNAFmO9Z3//+//Q9yEkdAQBUIcuUzwF9ew2oBWOv4g8j/ 6/NVi+z/b7f2i00IUzZfdRoDQQ4D8L/oAwAAi8axt2//M9KL32o89/MJZolRDg33918Sr5Xd7hiL 8CcMAwVFGB4iv8813Yv3JAz2IxkWH0EK7Ha6IUIKA19XH7plZGQUCPdePgi3299+i1UMtHUSadJt AYQDwg4Oa7v97dvSHgdmA0EGA/B0W2oCXx9RAjvutul+wivHdBoDEg6DsnQJCO1/++0Fah/YD2oe 6/nmZjkBD5TAg8AcK95e+P/eO8NzHWaD+gx1C2b/EMdBAlzrBUIv3N7ucwJmK1QG66wKcQYXW13D v7XdDQ+B7AB7M8lCfQiIgOiJK/yFC2GKFGY7TQyIlAV2ALfC73ZyAhxAPSRy3Tm1VzL/73fsyYqC JpwVH42yDALYAstCD7b53X+/34qfDYH6L42/C4geouqKBge+a5b/csiAJegMAEOJ6ZCBycP+Bejc 32/rHFM5DQeKkSCpFekLz+/33BIF6ZhEjYAFiJlbxXbv/YgQisICgQpZKMCKHrfxNfzOg+wM3mh+ ajnsHsvlcnvGRfQcA/US9ib3NPjdXS6X3fmx+sP78nHGoo3jG9+9JGoIUAoBiYtdCGIUD74zNrv/ 739GXzv3diPHRfxH/038igQfiEULJQILLvbftjIHixCIBDlHO/5y58p3ma3ZaHKjrFAGqGv/f7MF pGoWmVn3+YvyweYD/7ZQNBBAGGf/+FiLPcy7ADVBplPhZbIh29chVBY4+MbMbZEoY+CSAlaLMcf7 7e/5O/CJdfSJffp97HMFiwzp324XNhRyYVX8DPgpn0ZTjUGldmu0BAp2EDPbMB/87dulAiUD8g3o E9+LNAPWE/uDZbvbNi7/iRA3BN74SnXVi0W3W/t/i0XwW4k8gQP+iTl014sB2Ysywvbt/zvGV3Iq dy2L2MHgRDQIizxIwh2m33j7chcrygV3FkuTBIXbdhOBG6en24s4EHPtbgd4PcDu9spkuRRvA/AA wV33t+WJTfRzTPCD/gFyUbNTsVet0QxjsPhbR2u0u7V/+4sMASv5Dewb2gPPEV3jeE3wrX93uwUU ddgN9F8+W3YRjQSxg3funfs4AHUJTokRd/KJMbt2UYsR7m9ohVOYIi/Tch9WjXEEanv3/9uNWqcG jTxHiT6DxgTB6B//b/h17F72/jaseZkD+ls6q/wAhdJ2IvBfuhncLpGLojeL3tHrA138l9zbv80f iR+D7wRIrfx16eJwAXZgC9/aB4MjgwFKiRFD/EKt0PjHRZCLALn/kWkVF248bg8Ix53SeAQa86vb BecKh9IVG3UMkIfthdvNM9uDxwSd92Vhw4PSM2/71v4Hi9ri6olf8zyD+wGDegAtZoXmbjMDyEt4 EqzWxrqayAjJVW4C8Gult1vsDFt0ZTldWr0E/Kv0/9vuiZ0ABYvzdnI1jXoEjUb/UI2FAPjfGz/e xTf/dRD/BOhqEI2VE43v1t29jSwTAzlGkTufds6t7Rve/ss5H3IOjUelIABBijsPdvWLRGu/cLr8 MLUVjUgB86WYlrZrWiYEU1VW4YvWPv4O/79RroXAdQ0hQwTHAwoqfvpXI5xnwa2qx4UolWvfZngJ KXS9CUFcRLOT3QZfRX4apgRqKbkl7GAc6+IOKn0R+8DuLqV/ieveIfPrz64sOJ45DKs0hVsaG/4L THUhg34EAnMbbYvOk+vvGw1v+wFCiTj6Fnbzyos0PLsHu7q5i8pm+AXZshc79LcVCcvwIszMBiOW FV1zbos2dxAZLe3nOfj92GNCdwmDQAB0bYSdCHQs2C3pTrVQBvzFBVJlrgFbxxQO6corgRzYsgYr +JhwkIUh9OuC1RBAmGDy2NZYwoXQJhS2VrfLQbbmUeiaBMaoDA7Z2yfB7gILCIm1vAaY24J1zXFh UDcmGDovZ2AWGAUbk7pBiVlOG9tTZmq6XWdUCASLCFcM9AaBrsRWMgURPQ74vpuDUnfsCI1ftOAV Bvt9bfdSUAP3Uwk7Gw4BPQQ+BnOttVr3dhkBEwQtOldsUCFdQDMxLMthYxNRFPjw/Gona40Djhfw MVFrc21blDNJMSIfrSBW5na5duyJFqDrdYDzXK2E2wKbAw3mS7qzm2sReg5DAg/8CgRDZ5pdRgIn jxAGeBVKuMLCcvjakSU2sG1kCm8MXyvBxaK1t3QQDAgNgA4dfzPkb2EdD6/Bi8glNgDF4BvtwekQ J/F/AUBdpdst0Go1yLeL6hwBWwIXWGgYK070jUL3b7+99c+D4cH5BnWFi0gO6wkKB3UR7tsPNf5b weEJA+oH6xAQdPvldwNQDmbB6QfiCTPKR0NIHA9NAj9wNHK862ibOTl462+YdmqLx4PgEwxFBOpY gdj2Cxc9FAyyBpMj3fdmARF5DxZNDE3isLO/EC0HjTQliy0B30oYTlaLlvrlM8FmMcbYW4kGhWly lr4+VUaxW9nEztQJfAnWUAyHlbvNCEK/CG1Qi9cRuYZkspEM0Q8QFLJl20I7UDxb9tKFx5FVGVkE v5CNMLfCQo31MbhNCIkNby0UuvQOXx3/CC4IPYTvodl2DXzxFfjDHj0fiwuF93YkVr42/KJ0CDrH OvimtFmDJgBHCjsicuM1eLbvXoMlCAAG+F8Z96mLjxgZVnM/IQgktEA7+33/Q8AZ8FmF9ll0JhhW Ga5WGH1vvGa4oTJPDP8FCIlGsPhKXnZeVUTU3X7qEAAZhHYCX778GVaZrbXPwT7ATgIXXoB0Zrsk FAAJVBwUdobdzUGLHWBkaGwzOf/TtNlsJVEb/x0DNeBZ6Dc4CpcAV//WVyXcJtc+01xCuhQWJbat UXoZCccE/CHUKCNfZyjQUmgU3LYCmx7EPJIr7KfOAdpSe9dkGYld9FYDkv8EBZbuxpK0kXYtau/H ra230EJ58cqfJR97a/GNysMD0+OL0CYz2EcsS0vfDjulctP3wycHQxd9TrbuxgWM+AMGjY7rGVu6 xbsziB0YKQjBAaIc4f722hAbYDlV+A+GUopdNtow8aoCIgIXiiw29tcCDR/SwDJKKlcZ/xH69kI7 MogGcs9p/IA8BiAPg+kH26FdoSt1CUzR87ctg/B+AVfM2Nvs1xQwxKgjXlOtwh9qqNBq4m5N2gPK Xqj0UrEBiBTHo3L1U8woCxHqqGUiMN0xbkp2el//Nhtcu3K3fbF0VTjwRNJ2EoQKCly/1Ur1Pzh3 A0p17veTZtvaGjvEcxt9Ofz4x5cMQevpoX+JFMXw3wzFLv5eeub5+DKjFndF/5mnG/loArcFi3K0 4t0edexGrePrBAhQKLzQTTaC+v51XCZlmrDY7OY/SLPQYsEzaqsRs9wP2u5w//FXx11bufh3Onj7 BeE5Ufh3MwT8ci4AOdHSWzUgBPxzGpeN1rrBtjNVh1i3eAjdB/uxb/wMiVgESgx17YvGpusGg8EI qW6H79okVUo71nK1Lml2TciGazbCyL/Vx1wXDP/N7Hf8WVlGOzdzHa/gBjwMw+7qDXTxdFBoWCGQ nuVgLUz7xwj4vh9+4+zYizXXgX34YOqKIGggyMKkVB6KYM3aXUS5Rg4aUCj02g+/ig1MdBIBdC9W IiNdOJfbeBIFdBHVtBbp7Qt2Ill9BQUCfwWvIZN4S89wxtG4DqZ4dwOGrC3yBr6Ud1mNfbhuwGuU w5oeM6WksrW73w/piE3oqwBmq6oRDtXdVmLI1PHuVwBQc+fmbgJokD2OUBC8ApZtN9Z0rqoQVOn8 nM5dLmG2VP9ojC3MurYzE70QUEnonPBSwzP3IQm9xBxxPZ0DXGjwRD3oqjhqGibeoWs4Dr8u1FxD DusG6wpQa8Y7RzwYwjAXl7dyw1EboXBNFoZFGiDJ5MjN3Srw5EMG9ND4vOTWMHL8sOAXgAbkAYWW OXLoAuwDYwZs7gkb3TdjUFZgufRlasMXeBCKEEML/60ZL4cEfN2tTfPB5gL/dDXwQvcOIpWNRAgB sgweiPDROotE+B3UjIc3CxE4RmD/NdyJzhdEmgsxrP744AxFcrMReKyUDevtG3FUM/ZqRP6sVlAA AW4z1SX9JRJEyDX3YezvMRBh8FAqDtfN2uwATDYuYVghme9gOihULJUMAQsFsx/06rqHDzde+H4Q Xf5ZO8ecBbgajQU2blsMUQP8UQg//25kc7QABUAyjVFUsL050ggQqIWa9gXYfQ0gbU3bz2+UdAdR hXIFBoO2RoTz2vQZiyFZUQL395hFvoyG/4XBGSOwa1b9DGkfBmfBvnD0AXUZNytQdmtwwE50I1C0 Wf8OHQZrBAlFEGjhhNn3CBTuX++FV3hLwhcE/fY7FHbkYdhPNP5kEhrCZe0dv82kgmxigXDsDVcm tHRSqvPhJLwdp1Ch9FBQwVGSTf0ENiy3kRCeI/1Xsd4ZpJvfwgAADBkvsp0jp2wUgJtdOiGOAR51 URnc5hdLLgCL5n2wJnvwJr7qfSodXKX//s3iEo4lct8ywIqwAev4mR6XY45gB4oVFHcbsLZ/RrmI VbgClFiVCzLXtwGBGoCIlUQYFGYzF/a9RQ5ZI1i65zfYaj8WWRel+6QF8yCbkcMqbWwz2+0jnYVg tBZTiF3/ArJsLpb9/iQC5OjawH/C4O9qBGoHv+A37dQ3btE+fDm4Vx4PZxU+vsw2khz5F8SUVsm4 7/lDxhKABmoGaLCFrfYMhWAVz2DhR9uwWKluXFkPC84ivdhoqC6xSRmh3+qlHqhqWyVP/9QNTwHH Fni33QXaENABw2ajGkocs7XNdhbe8FXZCebHcB9nDQBXcglzZoF+t7XdpTwq//lNNCwIU1BmiZ0o us1PZwYmx4UkFwAPIqRzg2VUQOgoOM6+Ce82bUg+NDcyB8cnbWMAwb6KfhxloPtpQ109kGzXaKTb VsAOm02uOwxYT1Y280DErkF/QF4LgWw6llA+IUizzXUNgIQ0W+ju0zwlwPxmPYDDEy7IPxupvqVW pVnrQWY7w702T+91DhlNjOsMm5kbWMyzFH1wCRqkmYHzMTRWBOkOwwu7hoZhyOZaLDyjh6oXDK4Q fSGXNQWK+SaMdb0ZG6iRG7wMNruYEgQQ9BJ6FTAgu979HlA3NAPSDIISPZh0bG63hA1TomhANSSI /5RbwpKEBS34dBpoKKENamNN1g43AWKyzWZq0GkmgGgYMe168l8r9HRdaARo7KCj1OTTFXoQsQ7U 4InNPeQ7vB2wOR0oDyuba5vQdBsMJgcTH65SqfZ0C1hLeIf0bKlGSTjk9zc4j2CFgaWFDQQhjBCQ UOtQjd0/loQF4Pg7+3VtaLSHas50I9tnUxN8Vwl49hGawGBBsGdwn9vVb4lZowCOQcWtA3YsdHOJ rw5Qdfia+BHFJku8IH7QgMPruodwaKxLV/yoBy04aU46CqT4oNxsZmtlDpRiSgj41swyskHcOIIH 8D81wDATjaXB6QqD4QFR2cS3u5C/mDy+VEFW5bsug53VgU06R1AUWZ5srgO5/tVMXBIztlksmhTF UNPEaCsGi6l9FR3S4VgU7L5ngIlvYRJPdARkkp0TmyGecyIVXXkdbBOavSQQN+WNNLdhI4ig+ETW Pmys+4RFzDhob8wl6AnmSfOy9z4qOLT9PGZzvYy/OmaxG/77dL7MrIkmqCqL/Br2Znc7pQBQpSwA eUWoaJwpYW12Wq0pFyZoCHUtdmFTPIyPhtodaPVTMhKLrc1md5jJBMXQuv6Bw844mq25WBkhcsRT nnDdy13fhHIBgb3IERMJGDfotu9TBThddErJN2DDT1X09oU9sgJZp1mITG8t3pwFG8Qo/nQUfrDW hu2NoPrvHhX/70eWOlnmaDt14HR5WxNoE7YDT9w9KhEPltD0Ez1ZhPdbbT+p8y3EJlD42ATWNbKF S0JybWscCnahBhD+AaSiAQP2P4//nOxuL1SKdvAPiYF2ChQ5TFm0aE0364aeS0B4+/YEdEwe5EZ2 Q539dT7y96+H96hQDXNBmX0NoeIvp9mOQTuwdg8f/ah2e7bGRpXGVOTkS+gUZ7WEZzsRihLo6HZa 1Nx3XRqzi4XMDBlTlWPxKQUQAHSAAMQvNhOeA/h2ahRuK/Wz0hwQWDnkbYge7ZGpFRKiVqaBlh6W 3Db/BsSDcv+S4FvgdGlqJGN0Wok7i0b+bdluL0MYBQwcCxCNewSNddzT5jZUmvilAAkUJG5skCMt ClY8cASXOluFpxecGjvGGFBooYn1gCW86I1VIfAQANBV/wuX3vxIEHw7jXgBjXSFgKnNZqhXYjqU PQIl/9tW7hoh0H1xTgQrx4sRiVH8Sv8W/YPBBEh19ZeD7gRPS3XO2YPWtoWjXn3A6OkFN/wYEBkf gX3ERQl1FmhUm0WJcM6WejRbZTP+Xph9feH2YGYwPgr//aG8olAhSzxT+43WAE1WS3N0M4oAhFO1 +797LYrIEgyEyXQWi9Yr0IoICQw4++3tbyV1B0CAPAJq7oA4sQyKTgFGGK434nZ11URew2kMgCZq XUMDmqQDgI4uFBDtjDgLX/wItaACS00HlKhH+1FH+we8K2AKoaBQ8h7LaDgVl321DSyd1zAPjZ7s hzwsdHpoJAtuaCBJnuRJW2gcT2gY5Eme5ENoFDdoECtoDJ7kSZ4faAgTaAQHoZg1P3/voesToZQG DKGQBaGcX1sAeYTrHwEWGFzIAzPlCAH4XPJc9lgP6FTUXPJc8lDETLSX8FzySKREVZRyIZc8QIR0 AzIgA2hYTCADMiBANDIgAzIoHBB1qRsDBNLrDk7rCqDUSy2E60MC6wIabrtelcDfvhCD+bmALMv2 5itiSHQ2AiwiGO+G/7IOBIvR6y+6jDCEKLqQBufn5+chupQaupgTupwMuqD9f3PmBbqkUjmD+At3 W/8khQwxQAB+/v5anhxPuIQGSLiAQbh8fn5+fjq4eDO4dCy4cCW4bH5+fn4euGgXuGQQuGAJuFy6 Qol+AovBdxwEFvqBwnkUB40SUFJJHMA1Is2lsabptvYkXcOCh48Dlp2apmmapKuyucDHx1imac7V 9hBYpd9yt1a4kAf2O8hXf3cA2LTF7YPAnAl/QyyBRyIp6b8VWn9JgwIOSUl1d7vIUl0yyWQfIhq7 vAm0sNke20yc635Az3QVPQv7+fu7ObuMFWi7eAZhu2Rau1gq/e3251MjXnRGJ3Q7AjGD6WB0JS+8 uo13EQIHu9imu0RSPz8/P7s4UrsoUrsQUrsEUogFPz+7+FG76FG7xALNXCCsEOh78PeoA/Lz8CAd sxLCDeiqsFPlaIRXlJNRFzCiJAocZAJHxA1koC44g9CWqyg0ZMnt5gBAIbjAoaMMsRAJDDX0X+/A e4GSPVA5F1ly1ZA9sN3bcP3D4PVTix30fYtHCICl5DYa5taeAAbc/cfCfDa3ZVtwAnYJVgwL63HL 03zbJwQRDEh1aA5fFHIh54JAwTxSVFO/f5sNDBAL00h4FoC8BQxcjbn9QrGMB6zGAS/r5zLc/ddV G6RMZabyEFdsDnBPDAcIIl4QbtQrDmsZv+sIi1085gQMi1cUpoXSaGJHgX+JVeyLTxiF7MiDf4ey u11ldRsVdReS3PVps+f7sCSVEOspFv3wszbIAXuOKuRSIBMUwVxhe8IfUavBg88M9kdUZmfPNmh4 WmIaaNw3WdtKYGcOWTYrVwrJYYM9ImM11G0URwQQAtWk7A4IDgHZhTPKW1chxDNJxPyKd250DOB0 CBwQVyDkEOMYBQM0HIVJOUnqpBv0YxDgRBcO5gJn+wduItT7270fNDVDaMgoYSE4TvvNDGakWR/A 11AL/WZM2MDgc1tqBgpbcpse/AhYOwLQmVuVEEPwGJrBDhksPAAMMOsoPRvG4MjN5t4rrdfNoEm0 BsYNYsf6v2wCKhpqB0lbdAq5+Fc+JpOfdT/YufAJmGoIuegLWwwJueBnoNslB7jYW90DaqFhTfzw pvncRjBSNBM+W399gxzAul0V/MHoCr7Rt66LCNgDTdQ7wrcXS3YHF2B75xQITTvKswwGP4DDuZXY /gIPvlUXUlAFwxvZjPe3qzaywFeLWUCNjRO/23mBvbm4V4i5rJXrDTbY4HQJmBoBwFErfVAQnOBT UUEoA8nDWBj/98xGI4w3qRp5BcLZSRhZDlnLb1jJsyr4ViosDWj0DGWcjFZYpwA7NbHDupT2CHJT cDkIPxpgOWoK92xWtbBl59c0MZCzSU2sU2UzUA18A+QUthhL2LQwtX2L+OcDiP5s5ehuNZ8DvQRB ZszTPdPRVmHUDVNMY19QgmquzBdMU+5vVrUeUDPbyq8DnTm2R7kRHEMV1UxjQMid7Yj4AL8FXQP4 QQSbweAG2VyuJgWA4jeBZXNtmE5MmRX87rgUmGtNfiRsjbBAfjGo+55DGRA3XIHGS/W98BXbEHXr E9eFjndny5WKMEb8Ljld/AG/W8B9ZRGNmCwrTSW46zbo9gD1iw72AxC9Pk20xEssnCwkqH4lCMoL uz1qUPG9jPluS8Fb8H0NkqUGjbWf3dz2Ewz7FluBw4D0da3721y5i91FXgUSSTvLesoYhbF8gxO6 hzGjREoV9hSMRDbhaNhV4je7ygbyHHxV1yqWzW1VRtirAvwUANsjFz8OAY1YLAX4jd3h9pngMUPo sa32QxhzG3KGU7DEMupTUQfDep6v6ATg5uL2aIPssACqKOJ1gmkz7Jcq/IpYcaJkoUtCq+Z7DPN6 vtuFZPgwKSY9Hs5TU1CDPEj+iP9z9JBUMAANDiSLQ3nEUkBo4NXX/taLGYw18GvXfaXDGl38LVUY A5BXCGcYU4q8U6fkQJYp+FbrfUOr3QVUHeJZaPN7xG+hVAiHegEJgFa8MVlqytG8c/h1EoG7wYht lMjrI2iq2JJ50nI7wy9CJGPGzBz0bJhakT3AJXouqA5ko69H8gfg4IqugXzQ+oVTXIo3e7G4Qx0Z jPchnA25ZFMRUFqLpFvS3CKJIO4w29oz9oZkUOCVbeteOoO0oxz4FHQXgBQYeLt2Fi8DDRZ1yhL1 UN2wPzKwuFvPQRoIuboA/qB2tmEhITP/G1eZDEK5YMevVuV+AWZOIPgOD4fsNVxzW3bQQj5XSCBD JASXbHYbQy40EKRCqEI4yeaAPDwURBhE8A3Id5xDoBCdFNdsdh3xfA3oOOw4bhvzPM1m3D7gPmA3 N2bTPV9SjEtLN0SQP9NsNs2UPzYIRQxFKPM0zWbQOtQ6GuzwaOaa3QwNGEccBPc0Tbd9iFk97GoD e4yd0zRN0668ytjmpmmWTfQCPhAeLA3iOULETANX2BTqFxrm4dBeagRQo3qW2kAo/zfn0B6v/ReX RtQAp2h+ZgSAFhPLsg2pGOMX4H9ApTraIIsPEuG8ViOWEU3KcIizY/W+BQB04FMpEs1tIxaDCMXp NTS7aEtB29WYWUCAJI9JHa0ruJGPfDQpGFBIMGMGZhYoGWI2+IkT11MVT3hf8B9OxnCblWiILZ3k LpA8ZAWbESVocKtv5eIcT7bwfcLrGSrTPN1z+AoQCAkHC9vXBTQem16unaUfcdgrBdqvlPCR4tdL BVloBc1wHLChP0sS2wzWipQFwxcv3H7sjAaA+i90BQRcdVEhAEgb2ee/uTkryI2EBVFTO/37trpw M8lHfhn0DREvKOJGLl4HV4ZcQdBKt1oBfPdD/ifJ8mxlVwuOKCg9JaEXBc49X3TfTgLOVg1ZwgxM 9rouMyMhy2S09Ha0fQPB+VgrxwN0/7cxb+bIDlZGaFg+Hsa+7J3NIT+D6wk5iv1/7NsVxfOUBjxB fA88Rn8LisjA4S+k2b726RCITRJhZjB8s65A/wo8OX8GwOAEfEHGOnTnVpoMCDdBCA9ma2/GnmEI NAkFLDAIM4tbtLOnx1KMihEz7O7DhrOIoEcpO/gnjNgOmmIDRxqNHMM5hyQciaW8/QvOo9lDfe3w P+Qbi7DSyRhQonQb0S0tkYQ3JPorHLbQtUZjOW13KI0ZwIPmIvwVUbJHNig8TewCdBM3WmyIQCo7 L6yOfjTGhyRoVKvo/XVvo70RtPvydSeLUL74ZjOHLa07JDMiuzI7DiS1YjSbZqOWjGMKYFm9M3BS RyB6Q4PGBlZkOZm5dAASQCz3EJ1iW3ZoRHwy7a4aTiOMEfQAu5kZUyn2WhMP4F4KkHjPjHRTV69X XzTlRg1rB9g6PBhZO2Y6ZzgUvA1qXDNNMcbTnfxmRB5A7ylgT9oMe3NZ+VlAegl5tPx0DJwbG9LW WA9RVRNawYAZNyozuwi2lIk94VBDRJJ4ne2/6vabc0tf8RPBPNHgK/iLx77dXugrfbh8B/YJ6CuH iX3YA1p8d7fAO8ejdgWLBo3SgsEstOvA6PC0almUhUPsHMfouUmPkVZNAHQ3gW7WXEQ2JjMwJpaj twd+HzscfgOLIqVcOgrYalA3KXXJmmeJC7zoUzmQyVe2yVZD/FcGM2yxQAwxY1gMV/GSxZ5ZWR4b VFuJySGo7PMU6DeBDiYfWbc/+aIxiMXGgATBCWEYqGf+VtAabW+RGP/TBBxeBofC8a8F8I1EBhZ5 jYvSmeJ0Fmi3DfgfBuIgkYNq/vlzn0rANo4dvWgBJHF9hS3gPFUBngo2UaXtWbJ1BStbeOCwgtby 6MUGZhCdEa+71zBKvK3CXfPqI7ewBjgLvSqNIAwxavBC3cv/VkRxi5VohtYL0k+BLzAPMVghJCf4 uw9mM/0X5vzkiQY1L9sNsYlGBAUUCI1GDNtvr+34Hh149DAV/3YMFBAY3LUIDQoHoSCOcuyjW/8q iwg7TRB0fYAMOe2SBhsSNo8SXuvYJr7E44cE4JlWaEUs7tRAhHIBae+HogW5TTN0wnKEHEpCO2uc We4X36/FbgSJB3IpZ4k9C//kjiy8tzXj/GgIEnQh9Cxa+MaboIjQJTqZ0n+Ib3xG8CNzAf5tv/xZ CAy5AKLMWQ8YKZjQZJrwrjCANimUF7VjQyhYKsATvnkAlrmsHjbsKHcYJWwZE4mu0xfPxgv5cpBV u/HQHUA9zLuKfptaY7vPeBBnWb0w2XRfFGgUXjMEXBijK3QQ7AQEEc7QAtNVnOtv0Nq46VjtzpXg VmoyfFX291jlKitmgT1UAiB0eBfLXrAsTHMkbLRYQf+fOJpVUoRnlwU3aFJtAftA5LJa+HE3YnnB yTakABncOyzVsB/8fihxVgABFraseEkkrnphW0ZTRVajfdBwN2Y/3WgyhCqQpwtCchBSrBg05BlC zBtVuL+Kn4k1cBot3I/ta1RoWR1sBSpVLGcRyEAlq/gll2+v5TPdR2efz0kO23SOdY52js885CF0 jnWOG28ErEtWJBAdDF1bgSTgFZ3EY+c6ge/hBAo9mQC9U06D8WFZJ1cOfmRaaxgNhBqLDa8q9NCx bPpsubDhEJjQmpk6T/5eIgLvqkI5FVV2OqGObS/+/IoEEKQCAsQyBbq3+/ymig3SyBmLDSUfiE4+ jt2QQjs5csZeV1cKL0LQlGUZw+HIttcHLolTEFfhYhjQ42hCMW8EQ6ROcNpXNBBMsV0xgyXzxwgD aqVT1y38//g2vge0AwUhWVRwjAXfs9kD1BmsUKEfViJyFuEDyFH6NAF2RMvqWF4dZA+3HqBViJr4 kf/zf8GI2xQPt04EgKQFDMj3gQcIUSH+BHQ9dxIYLFcoDgAVmwWLSRkRkHzLYhoPIf6pMCTkHFoV AY442WBenQikgS3zpeAF2X10dDeAPRjgwH3gLricEoVcTFSLWAQy6okQHUzEt+d9OxIbwPfY4Djj x94DuBgHYccMuKhIf9yFaA+J62o/LU4imk3ETfmsTPnzYi7STaoV+gUTYneRwyv4BYNN8BmYgN0l 4sSqVn9SzZ50Ty4yTPo2kwv5vbjQI2AU5uXWr0YyXmnVwEYQzQKTUx3cU/FgvP09g+gy6Oh1Gd3H BCQgEzuWI+RGbu93ZuiwhFPZQlMWvdO5AhIO1D22bxJ4flbWb1Av3KULdENsPJWuCibJTtaCHGdt VDUxkFb2ulktWRuJaS1aUOs8U1Lb7mBB7XY1i4lO74oCi3TSSV/AbSp5GazNFjRO6OsCj3BFLXo7 YIRu8vkwAmQ9eoBBAtY1VMliV1N0/8WSrQSMKcLQgD3ybVTgdS0TTi60pLvmdRQP+caKCNGFSmxA DKGz6wYgntF1jwRp0OpmoTiJZ+HvncwCBjAwklm6l87MXkjIhux17W1UeB1oudSq5CHH3Ac9hPto u2RXXvJWz+Q283QSYb8cjhdIxAazAB4WWmMUdGYbI5sb9wY7+4LkPUIQUDOg1GJmTpwRZ+LMDAbp EBRXehvwJKcrxj81EWwz8j3bjAwyA/ArJVvO4FA48MO3kiuZ7Cy5BZw57BE84QYWpYgDIScAjAZf 5EKukgY7eA6EnADmBbkF5o5kSnSVIxuQTegMbPCgQcgVyAxFsGdgyRgAlKY28mxkaNai8gT6UHTv JRhqWXZwESlkBmSwl3RcE2BIaLNAT2pAPQhwAWiE+oxq6ANQfFbkMt6Exw37UJDuFrDZ6xwd9wS3 EIYML3YtgQTyCBcEO4qPYDsIH6j7Wq9g+xCs2DvfFJNG/UQ8UiIVhBBZ93R6sxNN05i3HKNBD/JC Z0GYWS+1SkBJuHDA/1hkZGSzk7WwrztXEq7lhUXooSzGrmgDKk7WZie0rcVTqySHcXRFHPj/Ag2i Arj5MItV5IoMEJP9l+KA+Q0s+Qp1GopMEP4NDF6gtv+AfBD/LnUFxkQGf5ToctMSyCkST8cC3BJ8 0EmAJedXOTt2ZA6H2I83O3V7AyWlbNvGDDiQQVpgjm8ogkHyANUBq+SF9YW6pAEBIIO5gCOkIAQs Fsgw/levYln41IhYyFYN1f5XLH4vubsBg+syQcxT4ixOFm1XIuBWU97xBU0GVgG02QEdQs60pDKO 0UAONg+ciZOmYtKQfH0UgEjF2aWlFqV/AaeSzXqu//6OW/1ZO13og3YUaYtN5CvYV1PqEWylgJRR YLQEGED8V89XFZAy2OtoN4oxd+R0Cc7sWb3/dD91EIoIgaF4xk38/1rUb0dngCCrf2Lh0RTsIv5k iRoAugkgCNL1xgYB39cFsR7lNTmjyaGNNHysKAE7xnQHHrAMo2i9FKlosUsoBfOL/gajJF5dw2Qg BL6pS7WaekSVg4l9/HUN28zW2QtYG+mzCAjValZm4BVYfcFdUk7JFgIgagNXiBRuUokenZ1to2rT ++jsI6VXQIt01bjMDkdXivZ0FlAA1xcQGUZd29HJ/DvB1g+w8VtUqH1K71EARKwMZ7YuOqvwTUeA 7GDuf1OGjU7/hckPhisPrnUSw7u2M923FUNJIxEsiV4auCNAAqE0HZ0XW9gI9jvOCkUkv59bIXg2 6ZSFkABM6pShKhA8N0VB9/v/fxs8CnQXPCB8BDx+fg+NR//GBeseoxhKwIHdNg4Bs3JeEutFf6ko cSFzSYA8Hw3dAhe49nUlCB8BDx4GArYbweYNdRcDCtVPBDXqs223cNkUNoA4FBYpZHuDdWQCG6Ma nOsTfL/mkaFjKwUXPffutg10c3o9IHZzJSQTAHVq7mHFJQoCVsijHBSQwgELDQcRjKLXTG+hPOhj Md8F95a9IAZEgzsFXnMd+1JvqzwYCtQYdQb/HIoWVbv/KwlIiBQOQUDr2kVLHLHRRSgnP+Y60Udw lPrBNbLIg2UFkTUzXCgRxFsfBmAHjYobbeaHV9pWeyRZK/tTMkQ2BLZl0QW1+Fe15jUt4F/qIUNx /HMPgH//H1GvW1NsNCKGAwrkvvkwJTNbceDPIpYzQKXxXEAX1cK//1H+O8JzKI29Iyv4OXWKG+aD DVp9qAiaEKBAt/90C/9F+IgMB0AncuCm2xbAaTbgrQmft4l6q54ACKv4WkCT7mW/mW1qUb0LXBts H8jOffGuIhtSD1nrUhEve2AO60QNWJoe7BPW5TZYUj7rzUaf6xjy+9DLF1k2FHMJVFLOxsM4wh5x 6xehDkt5ALAdDokdt9YIDA/1rgbGCg+CeD/wpazcNh2aKjv5FNX8QrQVWWBTeQjPNVe0puptAewE YM2AdN0F9igDP01v4w/SNHmbUVMz2zgdQmQFCeBVjDWEz3DRacAyXCQX/rTK0OM1kq8QDCbZbgj7 WSREV4m190lHBbi9MFycF9z9l0TVDYPFBIH9TBh85euVZtBdVSQTAew1UjVkt2IBT/QBENhgnCwL X/JZ0iHgUvReixUKaIvIC/wBUNtZCzvIN401vfCFeCzPdQNJEY15Bckrt38rvWAKAUbKHiGAeAJy dRsFA2/2S+XLdRUEbXUPIXUJiFgBTOQWKXZSWJKRgmL/+vApLosNVLE1KEUMiYkECwWG0I2QpxQh XdbAc9ED/R4kOlAhDphpcoDBOwSAk2yHmWsZrt0s+MmQHGBDhCxshRoyhNVGBCRDdpGIigTJRXLJ iByM1iWTDByMOIExGn+/HYM9BTF2E/BiNrfibAZbY05pWcNvnKIrQly0DhBoVGCPcYpldTlBaEwN sBCzODNX1IcB+AVwA7dYdgw4AUDwrXYBq3L0gEF8QwdXWwSXEaB1/uvtkC2AWtNW0hF9bbVvOXZE i0xqWApTB5ahBW5QMEIbLT1oCzV++3ww/w1QSMYEMDyoJWK/2Wx2BAJyAz4EDQUKg8AGQuhECwXn vNbgLL0eHFHCQllQfOAj39DvPJWSVU2Ol8MAVQBmhNkUrmIJivSerTUtYdpm4gjvj0BzNX2c8JCJ 5qj9AnXqRYlijp2jcjFgN/1cZT3Y8Q6PaCNmVLN4PvTHDl88vh//dvygURk57GAFuAd2BAgIj8hB MExHYSOO8IPGFDu7cslzWbG9gkVnWcM9yLbEs+taV9b87MC+A2R5O8OznhRsMWtCy+aiTDqbiwOL gt38KNZAPCua/PehzxBgpfiLdq9vz6B3iB11QutMbnY5VpVoP2LcGFAzjb65yGGDCAYQBEbZI99G SEPXHc5eV0YcgkW63FrbydvQhx5OV3QzEYsdkPwC38N6AZ7TpviB9xebEGzRQT73Lgq0Vjiaj5fq 60GjAmNwQrNhE/EChuLe8QvgDcPTmzKZan+Cb3VdYorIcFz/+oEDgMJEsOHCPWbzdgl4MBBMmAS3 JvoIa1Fpn1AIbsB0QdTSAnY41r3IRuSkDnjbAriB+IrXRkDcDfCXrfolVt9t+N7J6cd8BbKuaKNO VX7bXuUPwMdk/KyJhAzbqqVJ7zZmSnndnpNve/6Lx6qZqxz7wyrDsK1gR/TaoAXtGvZNMHYVLrtt 396tDCvI2QEy04jH/w918/xWgeGwgfYs3MMinDCplEjWGK7gGQiLCvVDH4sE1/kywDgF1ttcg+B1 O0YHDTDos43EgqrsOxsOMYIPpWh1ExHfVKoGwYnmVzAeqGLP1npS9lZC6vcX7/beFUYGk6p1GDNU +JRO2ySCne0tmC72RpbJIoBK/AgRzEZG7ip4B7qiJQ6co0k7G0GqUEtXCI95HnIilDoAle/IdlgK DR4I8Gwj2/YVg3w3AZDwBwjxZ3sj4oYyyVho6Pap3+0Qi1QiiA0LiRU9OA3SlufPNmUH6l04BexV 7Z+FZ3lN7kV77z05WZ5lOwc2+C78jSa49yY5rosU+w5Ciwmd0pYGouCMFftmw7cqCF7pfAeA5OjJ IxkZGdkF6uvs7RcZGRnu7/DfZGRsoSv0Bfj8I471WIoNoQR+dARl2147m3EQGxQ5CCGRkwk5DCQM 5Gxsey4LFAUYLRyR7U0mMBQzIN2ZkLMkJygxFSyRkS0gNigsGJixsTAFMRE0QDwfGmxjU4/xATGQ +qKe5AFiVohqi1bAFp3LcD+gjiP7v4e/C1ZlgzHTEs8w7SP67dtFBH5/QEB/cu6NcwF5WwaCCd2p mlfbNaEhvr2L80FQW1+iGU4+QHQMgvcRlTYsNATAVrLaChZQqJUrnHRgPVa5FY1DAQP8Tn0HK0Yg 634aanz2b6LFYphzIEULRjvzcyWfJbYWwT5JnT5wdd0tAaFAE3Ls657G26uXuB8BdopkEP8pIVJw VpRdiVsKFiVpCHzrP0FcGAVTbGsEuAZeE24XaJLV2ITZBqBTYaEt3LWgLoAkOFF9ZV36FfBSKmho ZStgZc1ixRCINUYFs5gzuVJMHIUOQgvxPZhWuAbxt5F7ElBloxR0Hzs52aJAL9gwMTFa0MEANl8D s31nuFkeGiUiAAYxBvXstVFGV2oDmB8ChcoBHfS4FBCGJphUA9zbphghGgV9pMM+YhMccUuGrhHw B4FhgQFIgBKYpb5Ae518Of1AK1QF2DUUz0wHO32DA3IClEN+8FY+1MNmQA5oAqfs7zcgA8sSkLMy 2wUo5N6NtThlP44Nbn/3Ooq8W/wIQoP6BXLyu7MBHNlZw7cBDogOSEaT2WVQSTCYzYiqEmJ0wPZU 0/afprjSre5GHTwWUDXrK4oXsIWC34QVKEJJMPGPuMjKJwyNR/6JDNlbseFEYwK6+HLV47ASw4q4 1BAGxUhYpQ0+ITC9bLdeBhkxDl8wgI5kQ0g7XXzWVW2C3IKKLiwrCcUyWAtLgkDfjReNjRxRezCI 0Apo4TwcOQF4WKVZ8wFXVvilggTsc1lybj3+5U0dbR53Z+jA2hQxgPo2gvLlToD6SUE7yA//BDBV QEiFkBMIPr78W2D/A1wgmBFfgf6jYmmhenzg6wcQCTBfNougVOh22JBOlsFCjgRkXa2SZ0JPSltz gb3XvkxckBNHkVRjXaw934uEj/iIBG6SBQz/GFvggmeLSo+/xxS+/KXZbFjJD3/K/RQFe3gRXDkd XOO178hFrXZWu2iSCT753rDZAf8zD74LjQEL5jhBG8AQHBsomiBaJ8MEE57gnqUnXK+BLMAD0N7C MAbwDRsuZ67wCjBz9iRh/81VvWM1gT0Fgyu0hCbAdgcX+XIJPSPvXFbwXB2mYBXLcxTBWMVJfD0+ Q4ZgYUhZVtjGliCCACPQINwgw0A9N1q9xX4FuHR44cqNHAYJZhCfUehFVXPqDJ6EYlZqXAdVaaEN LJgzJ49LY1iwARYyIy8+izmHALIVr1m7fB2zapifA1I4Vj0bDErycAsHu3AAzg3pIIfaRrBEnJ3/ CzeuWVkxZAQccGIQODaiWXYTzfYRcI0hxmBkagduRpb0tPRWSFdskEGek0U4gnqSIbnkcfT0IGQC ufD0Sgbk5PTw9JJDDuTa7/QJOSo58PRKYFmwZxClbOtlL2TwdTQSX6EiHGe97CMQYRwOAGmAhcLL alm/2qdDLDACLcef9JxawZyEyA4QAdrLVoqWh1AC9PiXywkt8FHw/gP0ABjLPTf+/gDoBVHw5NLJ Kkg79yiGy8R+f3YBWxkr2IqMPQiNhAaFwttb2Ct8OgR6fzUtKm5A5pDsDez8A20h4FYdQHWr9AeN 4la0Ll/KA8OuFWNNFd21IgIF2FDgwLsFajlZ9kPE216DqAh3WLQCclAE0MJV8AR3S6xTTwq2AdJH n1JZvnIhB4F08vD+DYFJNzm8W2UG/gUm4KIEdvfW1RtAXSs57XYnVsQ/vNA2CBaB5v8MthQRM9bw gVIbKosdozPCYAV/K+0lDHLbXvfQ/H0HbiGA0EAc0nYjU1fy+926NTwxYoHjQTP7PTy9rKD9MsfK cuFfWzzvEAyGEJoZGb1sZT4YX2MS/LZH62AsbCo1B3xgWhpRrLfHw+XW08BP8QWoWTP2g1T/N8XG yfa6pTkCdApGg8IUO/Fyarbvg/T0XzrDJExWe/e31iswKVd2G4sVSA+LOjt86ggSzVgvBPAkiida oBVMrhG9EfiyeFmjSNBQGR3Z6N3TdSehJLtQBIVJtjdS9jUlMehzwGCzWXpwRAoxxr62wTGKCBiB ayu3PR8YsiBEw6ajFN6HvbE/oy2RdCahEwd0tgZTHXhM+GMx7L2GF412UdIRJtyhOAtVoLt1FYdW nZ5XnNRqWHhvHY7FkGZDy1xlOC/ixtPz/HSYi8OhFfi5BeF4X4hVC4cUJ1pN413cG0+IU5OcDGnM O4rVl7H6wzS1iAbIDjgyTQuLXWnLwVcGPSVDagAHyWKE+DOeXjmkSbTpg9UgtwYbyPZX/tYjAZOO egwOcfVWQPCoYcb41CNim7Ym59I0vPti+EvKDz2oHwYAv1aEWcL2QDWdX6E2VgBIKxARClYKDP3K FxWa3qQCFs9/7aClC/w2U4ocOfO1JcutC/+FAXNghNt0XIvBOJlfzw7/HAg1Dw9dgGX/hxuFqNwl dh7HK0D+7d866QPWilQaATIniBQ+Rkh15/fVQtFPF/HqoSFDvI6IIqMIXalMBcsIW0OiQCUm2wjw EmYEi0g8chSQhYUN/FZ6Vz9yK+RpDl1TUyGYcLb8JjY/DjvhwK3zER0BYUIRHQVBFtoANlMdVQBO ZU2JZJ/gLLizGjlXRimKYit1B3+A8bWH4sm0/1sNiixcCwGJVfhzIzveA+hQs28sA+viUOES374D OC/DS7kicgKL3iqzgWYfNbAQgAELnW09A8UmKxaAKYCnOG4MFkPaBFXrTjRSRCunrNSKkB0Ig1Qy mwiOVOkQdMvGK/NtsYxvNQPYVlPAn3VwEhR7wkn064JB8UxCnKAXTASfeGDaJI+jOPeo8gU2RAQV h74baBC5VKM8lTG/jdFr22wfWPOrB1lComZki/ELW1S4bbtB4WqmiRgECAL+LgSVDJMUPTp86FPg 0TKCVLvRkY9ao8MkWXUFsrHtO6+S7E04UzyT/Sb5XnmfWT3VM+2q4fdJdnYdvmSLBssGqiHijhiJ HkXnLaD3+UY66CZUNb6h2brt1pciiV4ENgYeDQh7VSXoCO8yCvdZulu3XhA+FFTQU92HRraw78v0 FmeBA1wAQN9rYGSHTyVXUBfCYSXbHEAMRcSgLgBkCKRhJHw4mAtPV1lYhMJkrVVM9D9cLc+1BNn8 2v5qyK3ke5z+WvxeUAIseXQXlMiCZ5xoOQyIOhgXC3IBLHqrfciCXik/fEgeULanhGVbFBskbGzy CX5/7Oe+mGXI86WzagykiEWUr32VgoSw0axpqowRYAMU+3J+V84ElwJaI2/I22Z0BCjlwt1dlBfA gQHaL9HcTblFcYDw0rIFyFib1GSUOw6YCpLwbskYTnWpQ4aO3Blyng++wL18Q5CR7mShZqWjvL2A vUuuXYU+plxI916EBSupvLxkqc6Fo/b0OBWN4AyFEM9U8AomPhAG5BmQnCZoFZABlnwAZuuISdSC otN3XMBEpk+bnFRggVggBq9NyQFQMyqxlcFMwBDLXmwZ6hMigm8XMJbuMsBHgGQw/xgD3n4XaaNZ DWjcBTS6tgtqxD2FxmYyOHCCGFsEWvfQD4gsyxxscFuACwMY016WQfnRHoxf586IlUD52rmHEypa kFv57JGkF5CkJAbZ7IDsQftA+3+ws8hmFfcF+jD5YjG3DrUTgroUM1w9agd4pW7Y6UpCN/w1DINE 0WgV0VbJizLbJbUutB44d8teFGgQag3z9eUG9ZVeaPkEvjhokg6KW+AwaMzIawQZewJoJBK0YYAd xJLfC2cN0zzpIt4LiwVzExPJaGigaCQ7XruMBdCdsR30ur9NOjMRKg5X4dIladZ2UBDxLv3IM9ls CSm0/XE2u2w1ZjILT37PJcK/R1DDh340gFVTRekf+aO23YE2c46jC9E699mV+SYRjMJNq2J2eAVn 5IPNTqAaH7Q0FCx2sg2bHvRSiPsTFEcAWDxtrVmSoHtKGv7ADb7J79RotxBh8Ob5S550w0AL+me1 gjVyD3okWbcy6bNgjXwcz2gQaNyWNRQkqg7m3YjP9pMYFOAuL7haekSzhbHRe9RlN6QsGGabsPK3 IRhYn/cWBbvhNFlUVqWja3ckQZFgvKLUoF8N9ux1GQ9O0ZwAKeI5kNDs4MFo6RM0ytwCBBkvYhsk y94c3GgCPQl6XdB1W/U1ReyIUWokCU2GBxLUw/aZaAgDz6A5hFNE9lN7BGhm6zczCwVp/Z8coQ9A sgtMa2pT9JIB+W3pR3LjaPhn+aulZHm+8GdW3F9AmC3ZSw7ZGDQAw7sAz8KCScNhy/wsWJID+zdo 5Iz+h1vBJAdgWb+BXnfAVqOqIIx0/3Qhz2HJRroMLRxYF3EemdRx9+kOIJNX7gIvyGUmkgP7vnPf dUa3tEhZcw9ovD0SMH7uMahBraRnjDZWidkQOMJdHgMyIM90lHRohjWIuYAYb+wJkkvOzkBQFVB0 7KwBYL7eViA0QLbBN5kEukBBZgwwbCkKwNQLZIf8Jlg1uGasCdklK9mcJjGAhGYhk2wrNWBYkw17 hxIHlyEkoAF7ZX4cZqps4QSTj2oM2HcUpZJpRiSzZOKXJdh5AF+p5PZGDBBZrgJwieqH4Lj6jqBR vAoQYj2m/5d4EhOL0FnB6hIj0YqSnIcu2doGafQQDwz1rBB1eQYjwY4UbW9x9oqAGvbR93RjFgF2 W4JqBIQ9A/c9YgRfi8h1GA2AtMZkK9fC9K6JIAtvQBIUfBJ3aFzcIthZrlZfVxNtLwj0kQVFuE+h IVA3rXGLVlkmK8kBQlsUZayPRlIChy5SYU1ZuyN8IgwomgMqcgrjqQGz2J1dDmMwdjxCvpgnX1Bh +2TkSJ5g+7GwW0I+L2H6YPoV9+LCziIF+TD5s9g2yl8i/zcFTCUHFmVhYOINyJFhhVJkQAbIaGBg QiaSAWBg5EKO5GBgYBmQI5lgYGAWD5ABYHRZZIRkCjlg+2AMiyRbN7A1W4yYONhyIDZfmZBBNnXk YGCfyZMjYGD7YPmzJ+QlYPlfO8cyIF+8FzYcNmAuOZFcYGD6sM0rOULQnwRXQHIBIGAByHPJYL5W k5yQzcd6o2D7vxcygDxXcWIWqYwlADYykZxMYGBgCjmAXFfpAoTkhJy2AqcC+QayeESody/IYSaS A/pHyGWxBEFWNw0WFYSg7ETYDWOJIWmIDWoOqoKcshAIaS9W0k0bEgAKNOSQZwnQaKzilOyWwzyk aHBoww6LS4dWLmwUIV2ScAvFF0ALiZDFVprBMsgTh4vrwkMIkTRTBAgIwpJTyQh5TlQ+oCRWv4Hs GPFW5ABhDE38UJmgr0IdomiTQ5xFtKcA9KfPILiE475EQR3opRQnBEU+a+ijGEBdu1CAOFhEnWml xD+k3vZsEbVi4GReKU4+BX1oQGnaJBIIEb1XiEQYdQjesWPEgL0PdCgx+zYSyd3ei6KJAY2NF0tE SeBRh6MLfK/oZD0ywOnWHDtycpSoUOSl1yIZkAvk5BmSI2Tk5OQoGUIO5OSl7ZP+VovxaNjHeqiE gziYyIe1cA2eDyhocCPWoHl7fxgfX2z9ehWvYKCZQ17DqfgT3UqDPgBZfFeLNnVwwxxxDFarIG0q VF2oIyAAHIwZ4QAfczC6qC/gBF/8UAHwsCBGDCTIzLc1qCOufRU+jRZ0z8KxW8cIKGqzxzScDFFn hoBfBtZhmDXZBnZvhKg1XREO2P4ArvAVdbQAfg++YTjhlg0o0W4UXjxKckhXemEICAJLYF9qAw90 KhoUAA8haF5tEAZRpB11mRC/gCDpApRjUoxAhX8bCh59HLC8BRiLhfgAzAh3BcHoEMNggk2gBXTY 4Dtdc+4fXdmNtAUEE3UEYsNVb6qOS3yMozv3D4P92dkzvTowVjED8DPJi6H0/wvExgqKKIpIAWaD +Q91brFseKCtHoomit9GF/AQrKK72kZQVthLQYGGfBSDKTi7Xahm+2Y5J3MXKVBUqxYMdxc7IcuF d3ADdfjpFn4bEGDDK8kQHau4JJAzBCkaH31ws2AwdCD85Ill8Mw2w9cc7LGiIcXsF1A7nhVofa/B N4sEBIxbIkYEQglyy3iN+g4nGo1PRvS4Q49Ac+1MFvWivrwIY0H9e/poxYNmBAA4uarcYZlRGgGG KmCvRZ1pEath7kgLfMtOTbSKRIc8NB4N7NuA1Z/4zYhNzAfhDuAWfbBWhRCIjcz9Cl/9sHrN/aIE v9Q3br7RkKW64AZX+8yQirpSEg7gKjo1i+IoDMdBEdkgP5CD6JuNm1AbBv30QC5DDXCPLs4oCNZL lg24CNcG7z+gFiMZNhtHGD24lsadONw3tBac0IGiU7tUQ8FuTec7AF3hWccSABmaB56Pg/iQA9Ah K7jfNhA5HXbOjbXgKUc3n63paOitiUgGgnQxZFHX6Eh1fP1VU6TWDuzRa5wUQAGvR+YC+jZoOGpT LT2ZzgwhLKL7CkJp9vQUC/EOgijNgHPVqa66UE8QRuzRQLF0LDXzf524IyDPO8XO0VATQ3n/gIOw lfBX51t0EiD5V8SMYIp3ksQOmwVaMsGOZVYF3FUweEf9UaFg25qk6s4PRI9QJoBUsMRLkbBtRQXe oycZy5YU5IoEiq72BWb1LNRnQRWsKUJJ7r650dJJjgCNSgi7sBBWO9H23vgFePNzGivKkOmNuhJ4 f6mq0cGfO81dg+ED879v3Bpfc0IHxuD4UaNBWlGagC3+X3YnMQ4xVnJ4hNa97ZOonIsOixKhIYha KEWaEAgHbYHaN9kVFw/4/XsTAPcejAEFeLCpXNHXCCUOAED/2pu7YUCCKz0YLwWgukQdBC1AmMGL X8KbGisqFfqKcnJWvlq3tpGBjUcxIQSxQ2vbCAASKfWxDwXdbS5eJ38InEC4HLu/jVagBAuIUpE0 G8m70Gqh93LKsrlAPRpDmHtpRY/juPiFIfjv7sLNsEMD/l7InCeldTahm/14l86LDVWECHwCgfOt A2IVHaII2LYYvX8eX8PHBTQ227m8ReWo6bMcu0TbrAvCBAG8JiDWfUA1IFkAwQgJe+59L3o7ifcF zGjvtxE1KKNgdFNtrBC4hU4MBiZXovzeHXtzFTkHdQ0sgqo5NSly665+vxTRyV4PtpFvJf/wzfz/ 9oHi/381weAFM8JBg/kCcuOjmKdGHdhrRTC5VZ30/xLl4JXAi+pYi/krxTvwD45beFlw6fXH0+Bm DXQeVnBHuGYLyNg9/lc9E/H9MT5zGYiIS9JAitWIkApA3odnjz7rTVMZQLtyO8MVL9js2bMXDW5W U8fM1mY/JEGvKlt17Dc9sAsruRASLvBmK86jD8+7z3bT74E96xOi52YJPQN4l4DY9YkuBsOhCLnZ y14/CH5rtXMgdG/Y2CObnbVmih5Wuz0yvDO+GX3g1sz2zI+uyUAodRYp7EJxsrJe6+R+IyF6Z7NZ R0ZbPUtYwVL3GkRmE3SmaI4NzOBfqBVUby8B4JIGPSC2DHzzuMw9D/YQxEYAEYjERgglI8G88BxU sWbGqLVEjc3tbG6kYgWoC7FEfEWOO56w/GWIDRRhESPoKqYzAf70RtBEsPq+iwS9v/sm6iRyBD87 BWyOf2t9L4s0tqre3YUgFos8hR1KsW/Vot4DHLlmCloPipaVqr/buKlOOpcFdwFAzX6a7tMuHFX4 KpGxI3UR/Rlr5RH5LZZ2EIk0XBXvjm+L+HvR4OuNuAqTFcyC2gyjAbydnhGhIKe++n5jmIIP6aFo 6d+N3hZ665kGgTY78Y2Ysg1XG/a1O73rTk16CiPzO2CwXBfFX6IQc4dyBMFt/ALFZ2uPnJw4/09A iHV1tn2h0rD012xCQUICQQ6QAdvaArENKQsd9tsBGREFO9Nyy4oCOgq3QvzuAUK+i8oryIHBkpaQ /9WVupv+z34XcIFyEqOnbnfpsFF9JZER/xYllNxMr1uLBEWT0hF2CekQtVDND85utjdYQgRpQQhT HuDyZbvQBg5ZFAj0GFaLMQxQS8vkBKkIC7dcPLps5OSJcKFwPqEJdgq5Pc8EtYNkhpi9P9YNFkA7 wQ+NN6Ia9/b/Zi0/6IsIi9HB4gKJVfCQRDICBKG6QTQviX4FGrS9K7zDO03kQRZ/Rmb/ruRboX2L NBP0fAkrBNaXFO3bDYCKsAPCNQwxD6//2tYHGojzfey0FuY+t2uFHwhOOAIfG6QfjcdmFei41W3o FghHwHyCZT2hQuytIZJT+sKNDGSUbRv+wjliSElJ6/aDuQPAfIh3c0CPFoOA5h8ODF0PKmL/uzt/ yzvfi9N0Y40cEYcNFDsitwNC/HSXby3OaBaTQ5btg+sEe6FstztefyXjTASGO8qm7bw5uPor+RW8 +QE97b/dGdpQApSMW3XIi05KS0s716oKEXZWdaeWbbgF1V5JBNFsA2ALwZfaUtu9/w6LfAMx5tHW ERCE6LWiM7Te3mDki7ADaOaL/lh8BeK9xFsNa4scfuaYfDFTbgUCGkIwelYCWquw3Q10HCtMTdsD OwJM3xD5QVJX3wpnWQDfCm4IBlk6S3XWW7gdSkKiZD5ZEFMN3NgJcQSLOfTSFNNW4WiF25INo74V Pw6tEvEHfkMVYIEo/X5me2O30wvBQICiglpV/CeJjs1whBQf6w0rIWAp7VK1fRWDDATxfMitbIVS 8QJ9UYuODAgIAzNwexE36wKnPFuNAAq1QIQEINZgjThaXf+CZocbFuAL/zACKfpZrLFU7FB8soyJ xw9gAYB/mSvCi/DR/qN8Fn7pCsfPhi9O6++dn3sViLmNIvuEUjYYLV4LXNZaKmd7xN6jFi/dJg2w fs/6SI0Uj4mHSKMWiQy8K9F2YRqHHLdWt6fr6sf6/YkYioariomYwXMCisHZ3u1tsv7A+2aIgRYo 8NdYaXtKAloESCBfQU6PRkQwpRWLb9ZMS1JWtJ6DBRWhEL2hKAMbimOGY6yH0Dc2iYbCy8ISvMf4 VjPbJBZKV/FxAmqpBDVYTYDcpYC4iglDTe6bDcWM7YPBBkJXfqlD3BbeGk4zMTvYkjsIhL23pSAD 1zMaExS9qwdNrgpqjb0l7UEbcbmEQEvrdLoytwXWKKzuIg0VSkvRsGMUDUgTKhqf5KT7g/sKfxsb TkwDWo1L25CT7v3rGRpSUBf1CkeLbclaCtd4rcTANvUOzKixGSZ7Q+kGWOvu8Vh3ZgG3tNwEc/Dd Ax9hhGVEFCNXIiHY1tpQMk9fNSQP7Qdkv2aBTJEGNyuAgp+FICTG330EX+uHDWFoIApmAQ7166gE GaIvh8C1WsxVxNYSB2/PPd33GRX0CQ1MBwjbz4WMdMtFv8ZfqXc3IF/ISnWEv4S2JzSwqGuMqBuM 0g/Iwx07cdEPudAOE+HXC/3lahJYtIh8a+E8jZ8sUBvVVUgWfUn8kQqeSgPIjUxBEdncaj2i3zy4 agXFEx4sho5seV//t4IJW4vLe2EUau3GCbcEHk/8iu0Afhxi2WsonIW9/IVkKwIPc/xFO+985MSo i61PhIt4s6QLS4pWvGLeeJBKvGiYnvpQljQgOorc2RIsXYBH1eogFzPHFFp4oN32Lwe8olCCTF/9 M9aCmivBEAAW3cvl7f8Bh7gMlnURVLsCjLt6uwBLlrtGj0wZhxQWlCF2YHaKjIPy6pl5K/wKlB4G 15ZER98y4Dkwr88rjiS8i65tMxZzgwIqOBG/df9RznMIioekHOuAx8HoB4o1FWjqgKQo+7a6+uwy WNfRUwMZUC4IVLhLfMgDpLpE+NBtyAXzjRh/6g+CLJXxkwIEAD3UMGyLAJLooWqKHAoZDl4G7QUb 9hAunbmQ3bmwCQSDeG2wjZJnZCoDP0Ya2pCjBKEcRlbXIuDxjVABoTYYLdoewuHquomajl4bKVY3 cLGX3C0BAyD3t/uEAoXChZ10DAoWgwUVCDVs7wehBf0DvaH/jsL7w5B1QIXJow19+QvHSryVV3IG 62R9kkWs+T1JGKy1FAZ5kOWhw1J9kdHB+p5772SS0iyiLAbglR4143A0BXxUeFw1DFUKGXII0Da+ Ix/QJQuoGiYpRufXljUvC4Alp5/Rv+SKIGap/w91UgqL0CvdwmWADR4OsAMz+BYOC+++t4ueeIPg JUw08SfG+wPXS+8X3kx4fONZX9HuOTWHi3P6SzT9EMHqAoHiKj+1/jvRchY9tqfeH4F0D4E9IJN0 UMDq7S4I1MNRM9M5FYJbh3Z4NhWoBUeWpii4GRUldzD1YwP3hSxplYPT4N+2igI7oX7UyIrCineJ Mf7Yi+mK+42+ycMaEGYFqxJEAmNinOb+UnTzqiQcfLmIlhMhTvZI0rVvULh/UJeB5AWkJxDB/rZs s7cHBx59TE4qxgdTCPtYg4hSg+kHWFag0SlkKOuvYlsrRiUSX04ZuAaUKMD6q5Pqu2+/aOADwxr0 YzauE37ruORz0rk6BhkJ9vav5HMycvqvB/JWsOo5ZG5aBk12sLoVCbcp6bn4bTPettxCT4AX31ct RgIFheqGxhRnGgPzWUsgiPRTRFl84gaAgxtEYDVkJARtbeB44y7LW6QgkfoLThM0VVe/f6apVaO2 BAVMmPypTfAjx4HhL4stq8HhBTPABF1bDdaaRccFHGudM6MLI9d7lApNATAqR997+AT/6qOTW3RH O+BzP6Pgr154K8E9r3c0UU6z2F9zhssdi3YGiweHFXzdjYOrdRIsBXI9BmLlNul2A6ri+yb4E1tz utjYD4eyhEJQ963OGf0rzUlQkPege6WzQVkQLDQBz3N7v6opHQ7YjgMVRmUr/Rr21yPPMtPKet+F s4nu1+wsTc//QdydLeYDDNEsBzF1uYWYYzNDkkYxakAW6OSokvR/6gi+dRQBQQrJUmoAK9AGX5vt lo97lC8k68maAbbdfD90So2WcigdYE3EuXcwRBXjswvsOUgQDesIx7qcxXaBq0b/7Je9IMRvQxU5 LRBzHL54CSPEExQta3LkYyYyzQ3IGJtfApst7F10FJ0r5AHhGOQBXl93DDryjAhqIOUJ3wkS0KDI FN9JKLpksAoU+AmIFGB/9vpWilERLmQgjAjacoszEOcB21ANkmX5IzgVYIq/h5OTCugCxNeVRYkt 3LsUEBTT/7pE3T+eQ0OB+0QRfB74+9c95C1QahBWB8CmUBiLTvGK9KyFlEzxu6MElgcUo8b1SBP0 F65mo3Tb4PWCze6RSASDhpMMwRZzwQcQaN2bkSNcVtQsJwEeaCJKVsREczsjAeBOwi8aR2jd7xPR NHN4aCAHi/gJCNCgmTqkCtIdH9oa5y36z33wgfDoQaIyv77QB/URBQNJzPRqICBS1k9WmMB8BdYm uPgHatletUD8juIbFGiLXZIzUVcf6CQCdpcgEf5yVYgQOCwBKtqI6ihhp2Dq/tJ0z41vBAHsFuRJ kkkKYPHcAZCse7/sa+w3E5sG6mFOCWq+HMcEVrThFqOUbZvXVpvQA0Bh3Fr4NcAUdFKM5XURLnoF nlGRuYRZ2lcsDRLUIJ2EeaPlvob6+o3U8oUFKCRCtt1I1n6yf1az+NgbuWT4vjYTsxLC21jNtcYq yDJI50zKUMb+UtDC2sA9eyZm7lYNeLWDXgzqbgZ0g/8wdStR/927zzgQfQcpl+Pr5AaWi+vdUaEE xUYGcoFEBagZQs74J1ltIOzlZABkN/ToIIM0zwIB9PjwIEOyDPjgwIIQvYDiPpaNJQLvOXlZomY5 QEb4c+QBWZqT8PRh4JcwabrwFuhKxeC9fbAlcLQ9kF80WXMfgc2ChhyDlMdgGIipekd4kGWkYzt9 dWTs+IzxooOdW3ZWcH5LaG39cn6+WDaGsIRWClPbY2ZDFsiIwhsckBGwycJWvm6R8ZJxnW28HOMR GG2PGHQyFCnDVPV0LIYMJBBexnQcCHUVRGw0on4ZM9vZCo+UXMnyfTdjWyQXyFE6Dx6EEdaA+kOD x65kpllddLLmcEa4AIibkzYobB0okvQjaYwhBxn5hdjYUFNDMiHbapf8/PwskVxZZOBrlmH2C3jr klPHW0gPlitgZUycTVmQL4Cbw5sWWfoEBmAJd7r/QCXKUeUsCMX979gO9w0iFO6ApfwU2ju6U8CB CFEHF/d+s+prUc7v10+cX4omRwDYrCg/Q7f/bleIhVTwJbnndWhV8C4QgCBbM+BtnEie8rm/VzKF nARcVNfC2G0IWLa1cCyNHLY3Vd1eRuw0JUh0GwIRv11QXwe5ZHQbuVwGE7l31Z+fVAy5TAW5RHT/ 8AK4iEvUuzgIdQKLx552+BbRHIUNjtzWKGYx5Bx0/QTMjnQIuXMRI+g5IJj8REpDFoBWag9N5AkB KNWddrxOAgTgkVed4F5PELljRCKheIwRgWsulCwScAxn7ibi9aYPaGwOCwMBFAgMMeMLxP8PeAaI DkZA6/SAfv9caQZnVfD2XEZqBwV+Rl9bGrey/TeAwmGIFkZPdesZLgR0RiSq3WwDbXCAZpsSMsjz GUx8dLQAJgFNwNzO3ck0+8KioGoUXmmHRLUj/rTbBQ/4HPIvJ/Tw323w3E34tHElE7Lc3FaCDyAG 4A9gCioMK7k+UAAa4cg7fRiqZkU1CoKWZlTX3FMg3MKQr0roF+3CqFjDVcc0G6wPqms+VyBWVTEs gLbURFvp3ExWkOH4psV/Ocmy+Qn7CPt/wf0CESygwNUGk6reORAAK+QX8GIBrRKsi5qdzcAsdg2n aSDPLhREAAL6dIAcWT4YxsjZi1RnRCUMBJyR29OMnP0spV0BH1Et/3QtTAmCf0s/IQQVLVYNkfzc /fQAdk9o9HUGE2jsDGjki52I/gVo3HVmjHcQuCE71oBZpTVCMNbsxwaUszCRg41QjhOU2HXpZLZN IaKLjBjSzycnZwdozHjArJRm71uydf84D7eFFHMQxmbfBXgQ/QUMEmF8k+1AdOH5HGewBrGkg/gh eFiE7Hy9HM1lbGsPsNtFwNgDINXZWv3hNEtF1MHohAbQOQhvO8grxAmkQHWBCtAAxGVejgBAcewY uwBY4J09AF4nU7mphmwAcsD9Oo9gW1i4auBqkTGCkcu7ca3C0bJsAiQXCqVkJeip1qROCQcbMskY DFu4V6olxyKJCPs4cRIt3dD01HICAMuVkzPbAwDtD68ci+QDTSYmW4PoYkP063BsCQvwdI466xzQ LDToYqTtdA5Wxt1rmX8IaLR0WwQjYRK8EZDiUqVqxg8bhb9ebpj7W6Q7GgcDAaEYBJ8Us9eBB6p4 4buZQ+aJA1XUMdLQh0WgcqVEDtbZy0IAVs9cdQ0SWAXMPovL6yAMj4WoZa5XMWLBIs+TBND+DF6b nc0AxMaQIT7CHUamzIspPKGC1iu9MS4G2WBygHadFBCDYfZODRYUB5YXaXINGSvi9GDz70/FqH7w RKggB/FBqAI+f/798kj2xAgY80OoAfRSqAT1U5Hd9lkB9lRO2J2U/U02Vb0o3ItF2DmqJkVg/g+6 Y1T7amQG4G3Twfh2B+ZSFOIqwP6cALmyz7BoSM0wAEFowEki5r4YAnATF0kQMGEEM8S/U0LBRsLJ L2WyEB8ATMJ1EZNRUushmRuwDxBEkzmmMB0kLKLkZagmEE0CM5CXbJM2GalAdg9irJmP9lMQGM94 S366iPwLbYf8JAfkIIj8iPwdegt5iPx12jDD2ZsXygnXV2sIZsfjEI1HpFxilWAgByXKnNVlQf4J e7yWcK4jwwjHC8WZXK0uFUR2O/NC2ZrrajmRAo8gCMKzkeWSX/ARVpCOLPbuWmVBiJw1DmpBXGw1 06RBSitD6DDXAkYYnte2Xm9raEYvBQ2BIlrLPj8IQxQS6xErjOhhURsA91j3MIoOU9o7w1zawkVA dVwEUGBEbSMV5KMTAI8o2OahY9FTlKsp8SYIKaoNRpAIQ4/TnYa3qpZt4bAL+Ap6y2KMdswRAH5V Q9wuO/spaPYtSsdTK8Yu0kH8maQImjv3fNxFh509IlMjVyQSOZjZTo4mc22UWSvA5xlcjSvBvVzq YfIxs5B6i7I3gqMBcAUVG8tOiF47NBpYWRfBkgwYWS6bUJyiA3oRoSVEMIfQQTWEdwW8/K6CFxv2 pECEIgsHEwkhaAGJiE1Egvh6N/wr3FaBgbjgjIZkirEobVHTLeHMFO2bUxBXRHPxOvy6FUaZbBZB +InaALZzzJwWNhxH67YniJsoSH6QXlYbH8UsfyrUt5C02dtcrQNTAEcfMvjKApdYJlo+Gz1E/FOK XQtiMwc78WBAHYUItQWKGGgLiFb7aXR4oeguSQyIGB5H69tEGd4gHwW4wCA+Q/Kz813olQETOfx3 IFFHOPyqLcTyOSE3FCz/3f7c/jlhnxON/Yz9Psn3IZ8T8sj3GfkY+X4X8jlJ+0j7+CnI+C5kZELp 6FnBBfmig1heyrUhz9lu+LgSeyHPrRZZufl4efgUQp4T8vj6+fqofC9k5KkICfrXaLqQ74Vp+a2Y mdLwRp7IP16PUv2CU0AsBXVnSQaLe33pSTzkJJ/ySPJI80nz0tUJ+cj1yfU0H2pBxl7J9iT2GkM1 sr1gVff3XCh9ckjU1bmnYSjzQD5Humr+av6J/No22YHjOJFFkByNbEmAkl/09HPI54WLSfVI9Qeg UB2qxu+FSsmivRypVB+gSfKTFL96yfoiVTdXGQ2sN4Fn+GKKCywDLDslZCDsXLchgEfsVgBQAyhE DCBEvFbRVg1NgXYYkgmBE7jw1FZAcAZR9fAaMLFs4Ay6a9qkeaCBQVbbptRmkQeaZaikU3wqWfc7 34IMx8iSnvWe8wxAkltvGblUNbVeR/DPGKxJODoywYP7J59wCAY0uYx1VM1mbQpnJPVry4wa1/CA UFvRhl0zUJ8brv0NaPi/qExC4wYC6wuCw70VpkC4OwAa2DSBIHFq9I6ts9RJWBI6iI7inVsQ04j8 BgTAraNPBQR+fusdC7gRIEdNctxA2xdhstRh3FgLUT5Rih8+qpvkyoJ0QzguGFPJATkBLP8Cm0oO 2F9XMNz+Ay5mU8gBjP1TDCp52KOaXcj3TCUHbAUuGPkGsKnkgEj7B4wGZCo7+F0I6MkBu0oJ6lj6 q2wgUwqMTCUHhAumuPkMsKnkgHj4DbsG7CoZ+A4uqJIBuUoPCKtkwK4Q6mhOQwaEEaaYKYrKhgpX 8HaRipoTURgSMjgBatIK1B6rx5eZ2oqM+BcUC7LdQKpEhyF2DRF7yx7bHVn+Px0QyCF52R3I98j3 yV5IDhj5EFnkQA7JSPtI+/iOZMCO+Dvo6HLIHkuYlVj6DuTIBlkYuMgO5MizuHg75MgO5Hj4d/gO 5MgOqB2oCMgO5EgIaJU5Eg7kaJgNmJAPTiwsZPZJ4i059xk4wNTXSlEBNo8jShPQ12wJBf+qoFkE ANcukyIKcBscv6R7pmogmFYaVDxGHZn4ngVZaFBzUSEcABElFpka2fuVbLQY5W5IQBsNRy57KggR JDrXWnruYDB1oAmcEd/JXpJvlAzrH0kAs8MgYFatDFM6A3JJNuwMW3ISr411bOUSVhIHdVqQAFyS MFFbkL4dIibxC5K42WKmlVSoOzp9J4zsxPdZP15yCQmSBDnzJA/IRt/YA0cncFOdOiXXIsKS7moV NjCKPofwubEcUIwcRwNdyMOwqavodSSXPWCmp5JZJ+TwyAE/fGighgEgtJxyswh2CxJEXbBsSOBO nhyM2TJmI0YPSWaotpYYa2hzEHMTFhtlNKJ/lmB7SC7gOmpEFBivqWEleSoOjYG5JyLexwUVOQgI SUSMjSNQAFEiZBfyslQgURXMXEIkKoIb3IBbyZBoGF8VLFhRFguaQijh5VnrBZj5WRgH9hXCUdjG nPpZJzYphFzU4ycwzpBc0FeJFsbBtEgW2I4qVZg+JTqQNC3BdCQxIGH4giNGpD+my3Tl1pBcEDVV ABIrCQ+KuPF5/z53H1gKaMh2WX4+QDTCD4dswk/EwVO/QlfgngYYscJ+uYiUMJSDV3+TKrQsW5Ht K+h9VhmF7/OFQ2EED9U6XDSY5EAO4LpcCHVyQop4+P352hoxGZcIkGVWSRPAjFjQAQLgIWKCNxAH IHbwPZUrONkmaSMMBnvAuxREoo21IWGAGhJdSw6BHAkZLtB39M4TTZkAQ0LQgg5YUTF/SVQtUSgT gDw3LtAkBfB1AUNWOe0hgBNGxEP+fTaseC+7tQwdKchlZxNLDVMn/nCm2QsLOgynfsQZcA6NQA64 TChiEgDh7FoWAEdzTeir7pYBpgGw/Aq+/8aFDdUMcr2cYZhqrAkQmI8GQkqgEmOzFxVO/LhFxbfs 6YtHDLl0fya6QVC+2zQGUzjjPR9SqNyUSnJUvAELiw40bBHwWyg8BgB1yRUCquOLEIknbN4RBsfZ g+6pYnn4Vz580Y2YqjAH9lkOkeLn3FmUJTZ+yAUDoDCw9jm/aB6xhAHJwdeH0xE/ij9ZvwFnkW0Z BZsV/SL2oHAFFBpIBmSDGf395JIIuGM8/SZbZjjgFUksNhpCVcITeYNidinHdhsaMu9dxivrHki8 nwsZLNJlHwy3+kjNJlGT97jUxIHcIMIOpCx4s2h2qDwaWcpxBgXFXyoCHjshUvYlEHRUCMzWldMI LhwkAr1gyXpeG2tLCHTJ/PyfHNkOEy++s1VjwEBGs9SaDVlHxbRUDvQOME8kwY2YnJ2HpIwYHEAG +yJMeBMUkAEZZGQMUMlBBmQEPPx3yIAMcij0FOHLXjLsdA2wRt9ZX+cmiwZX1LAcDsCAAEXE5kTI IcuAMkC8vUDJuHu/lJ2+UHhz3jLcCEW2+nY2DUjzEOm8/UgYmDAsRvwm6V1z4XDd79bs/nT37LBn Qj5AeOw4EwM7MBkUFxNLECx7YOp8p6E1SAWKBi0VWsN8VNvsyXk237L2GDoaCw0Yd4HDGSCBbBeK wRhS4tpqjhCEjJTwmffeVNGiKZkD0GnS9jCDD9pS21xWM6hyDqBmBSFwUcidyL9Q5QPx6xXGuBBW NQHI7T/nsEKQsjymPbCsITgEpFc9dkc0rEk8OA+VwEGJgHJUlCG0SQQMGDIkAh4E6hz5AcUg+UgG ekDxC+2IVeyxsye6DHe5yrgFE8SERPq5aegyc8i4uR37A/klG/S4+9mIVdiUkB3Buf21uP0uJIlO eo/zIBIBiK5lF9HM9KmIJNB2/8SXKCwojzv7dF+kq4hZagZXI0e691ej/gzU4Im8sIo4YxmwAAA6 OTkdFQ3ws4rYXgkC6weAJWTIgoh0G+yCwgTFlEG4QkGPEgeyYHJkMtg3MygSf8Bhix2MELi40tmB z7j+074oDla3IFsVbmlpuMlmky4u/QkpBgBDntj9lPGyU8AUDz7BvsuCjQEKJCcZEwwBw2TAa5Xw tUYpaWVCaijq2/6oiFCvwoKESOxii4DDWmZk+/5JNBIFHvyLIc9lbw2nuPzGgBiwnv4flptgziAv BDYx/OqDDWaD+gJ1hXLoBE72jmqIckfCQBvVzEVAE+jIRr+YJOjFCtFgHpmQR8rSYP8lmDIysjmN BeTg3DI2MjLY1NAjzDIyMjLIxMC8MjIyMriEsKwyMjIyqKSgnM/n8zkkEaAQPBAwETgZmzyfETQR LAWwGRkZGbzE2GRd8xwZeAQSDMwAUS8APEUdjWlyFIHQsd8NHdbuLRCFARdz7APgtgU+xAyL4csz sl1oQLDDzD8QGLB9JALFyJj2RD0BiSAGsUxWts91mc1VNSEoc2rocuEWHRNBWcTYZKEAdBZ6mFCg Jdqo7ip0hIll6AJd/bNRorBkcIMNSMpGqbqdrT8GTBSEEf2RkW3DiYkIDXxszzWI3qGADLgoiG6r g6W/vbgzdSLAbFCJ72xO7Biq7L+/0kSYCA6koWg/RZSwuR9A9TVkDAmcXju2A28DoBNMEk27UAz5 MgCDoUgWirr7v4swiXWMgD4idTpGCIoGOh6Qb1uaPA3yEgQgdvIbBIXa1NDc8yCuIhY2RdAiEeir pc/b6w4rIHbY6/VQWNXP2gBF2CQQNxPMDaXXbZeYM0Rr+HYJdCPo+4lNiFBRhJ48i2XYCNsWwIgf PIU4BVcC3shAHLS3BMdH0NgBtMaJw78YAbhnbBFoBTYGgDaKMRguHelhRLnJnHd+CASwRLWbLpom ednrZhcm/ywozC5EEAOoXe5XP5HJHjpwzzVZNI4gs0FZywu7o2CD2CvGB9vJ9o3qgR2LwQ4PtiQJ YHv/tkADweEIC8oEHWb9BbaKnjkg1d0uVMO2iCTDERfqGNkg29YSBkAHEAgikzqEovpXC3hgHxGC ULHLM5nb0QvxznQazyYXkU+51XDJ7gJLhYMgAI1fq2BIASI7mwL49ot9CPeNFAddVfxaFwJusAhA 2YXJWHR7AdByigz2wfc/FTTO6v50DDvyD4PeC5ntOwrXjRwxO9oOzwJAH9gwhqjkXgMob65UuTa3 SQWITRPowRFsU8FdQYkjWwv6ORE0RJlcAA89+0ZHQ+tYxc+xX0ZcgV1DEH+NamQYIB1vjQUbRkEk ioC894gwt9u6BhiZElk2i8IIFtuf7hYSmUMQgusIO3VFOb6CcO2KRRMaKg5pYCXiGRLsMud3uZkt FxrZdQhzCNVI0BK3B3IXAyekx4Pp4vbqsUw8CDQZAJcoccdAYAB4ICj3GAsRHOBmfU678BqC2Arz 4ghegkXL5opF7gyv4FIAXx4fR4XbqAAQoVcnzbf9hvUj0XRKO9GGjilFhdxvhjCjQYvIK89Bpdve +NY3EOM/weNC2ANdFcMmKrTdVsliK3Nde9pv/V+ACCtNCDlN/H1O6zDlMwE7Lt/u/k0Uc0ONPAN3 czuLF4geRlMZAdMFtZWFS/w0qHMdb7upA/NaGEDpQGvadCNoRBsF3jjAXgKhUS0E+pEWxjKRkDxg tNOMdG4lKIxznARiCM3mrBwFqA1DPfgUPwHQohqGLV8q6KklcRhzylcPvoVoo2qzayRnHZqFt0wi jXoBMve928ei4ER9tFNV0P6XBfFbK8VrwGSL2DsC9hqo8n/vlCAAaJGoziQlh22UebhDJcnm5j4y twPYgfvWaI+nW7d7Uc2pIIuOO4AkbXg3C6aQiB9HqdGFZjtY1N/j61aD+1x1Cmnr4w4V/sJWadFp K8FIqMB1sdSqWr87JHNciAF/OwW/W0OdiUgUR1Hruf1+4c+mV3M8gHRHK/qB/3x/LtrIYU+2QkEg GivGgQzWQy0OfrZUj6IQsh2lJW3YWfcBtgjgov5J/TP2A8c71iqg7iCgoK4niwJoriAawsYhJraV Nqg4MmkLEHGZ3LeCKzkwdfkL1xvhqirioeHb5A1dHZ2oIM42jVwDAW3b+Di+z8Z3AasFIoWtEVsS 22EHHitYik3UdENOdD22UvYDfq1mrs/G431YULV264I1Imn8OWXp7gMBzfiE/X0OtWy7E0HhfoMg 4MPmGgssDl+YO+y3hTGaoepzU0jO3W57R2zTCLTbjXQeeynq0o/f9OuHjU8V+HMti9C+tsH6yq3A 1sLKRRdA/rNixW4E/AxAiBHrLeF2I5rvAsF1TfRjTQWU+IFopAwGVouLBzsB3CJt8HMmzeEQQH6N xm8LFYvyI/EJyxpy6hDCd9s0Ow0HQAx2pCMUHbbXB6Z46K1VFKAimEwIgOXl7Qp0EgQNdA0FdAgc 3VU1DGjQIH4LDALu/QZ/fQQRGNdNrw2T6wXup5dqNOLygTHddfQ+Rt8GQawbhs+6esHL8lbjO8qY Xw6D5+f5tz/wgwMN69ceO/l1PSx2K9i9GV4idAYGUEa10IUjthBQRLr4ClPdUNpBHzvB3J1PddV1 rd4QHnWaOA5sB5Lb1Qhwes9dz9Lz0AbDA+sKXkLrC9tjA+sPVvv4QXzo+MsoaOFafwPrIK0E0RdB 14AiGg29gvYFaAsBq65de52RaZdj0WGLIGJQmfzw2cQk4VUhUyLnQI61C/0kO/t/OvsqIovrOP2q U7OgthfdeBSx+fIlEH0HaPrr2BRRiNiedRWrgcpAhzdmuXMLvUB7NYsGE/rgDysMHL7mk6BIR/sq APkGDAwbts1Cr/xv6BasFSKnpKbMfNmhqqMdiS3XmnD2HtM8TD5TLotdW1mzCICKvHQQSf+LUlQd bZTCA/JA61Bs/e3sO8dE9HYNgHj/egcuVf0JXDvzdSVXEdQbJwRiUSGO0Jeqtf0zakSh9MuNgxgb ELklzRTYuCwYVEFwLEidOnsk4NNJao8OAZXwWwnOZn5n8Im/Drba3WfTgHUbUtL6OYIbmNxtzWYW aQK0iww5BdQQ9GvCIb4HdHtMyMt2xHV1a/82os3x8lH0zIE4TUlEWPgw2IMAfS0ddCZ7CVulKFeC 16g1A4MtuqcliT0EAvX/yhW1bIMIFAGDQWEgyFQRDmHL1k+FevAZ5n8rvHZ01B4DBUTrGBsJOvE0 4vwLLOoJACth+trciAAQhNop0CfhZuCZdQ3aA1DraJMR9VEiPjPwbEd/91mB/gE4fUlOeCKAPKQc Vj29R7bgVxnwgKQ1EQsWdbuATomN60n1t1sUxJo/CeUB+1rG31k9R1l8D+liMiWCE7mZUDZcMWB0 w3H4HBb8CA+BhhVnBAQ96IJaeBBWz3fqyJEwS5iLNyw2WFFHvWMTllA4swXVCnTdSKi6e4j8UBmA ZfsHYNLFl978GvC+jwQWe4sdQCS9Gm8J4G1RtQb1SKdWCzbxOAF+DLhqCBV65Vwr6usRDhYRv0Qb b0GKBEGxCGgFRjgGdTMX7onQYzHm1mTMDbJEqpAt4XqoUkeNgotWOxaapGNf6VvB1as1KMpkeg7J dmEnh3wSRn3SfNoWbOp0uQGKBzcvImRKRsa2OcDADN/EBwNH68vMgCV0yUZIJCzAER6+dLZW+wIq BbyNUK6lGLAjUw1W7ThUbNRoGWBTXFGu9qgzyFAMjIqDZ3VgKJsBOlHn0y9EGJACMts3KaDZqcEg xmsVjiaoDckPVEKg3hU3tCQILkHrDy4rNSoHCqiOV5yMZtSrMpgGi1Au92xf+6SniYgglKeHX0OO P9hWOR1gaEgFBwXhBdlMuBFkBxt13xuSXhIIwPVm/e/dsyXQC1DZg2ajDFZqNYkddMwizNYIZidw nm+29iqB6bskcliD4fG393rHaOTOC8ijbJcdBR3wrw3MMOE3vvCp90uY0X9X7JUz/zgdGt2/X7fm iTXMutgnN4H67Adz1lBAiS8SNCgEoUvx8iB0GQl0FMwViWHoDCjaOLTrPL/9F5yIGF9AOBh1yS5f Ost0FRBbwMD3Cz0G39rnIxYpeHaJGmt1NAiLijU8as69HxTtA5OtB1DtCkCr915rCZYApNulSaIL 74M97cB1McvZgU7V1a5YZRQPOaMi7QpZaMzWl6TY/WUNTniI0IL2G2femykSOKrLRY0Ap+iWBZUA +t7YgjfxigY8IEAJ9Ubr8w5R3CjtAHlZq9P0k4UsjUYGlgD6sQtPeFl/E6wzyKUPMQp24WNbyYMH D+spav34eDwSAeledBgQ8AN0Te3rgA21IHKQC3YHh4Jfs3Tvk4Vzl7lvjsPDoQeSbwZWf3GxxDDU vTn2dGk9ClgSt3j8Fjcciw5XukoiOQrARWFruRlbxPS60d4KCV91ORtoweCGiz0WxIifTg1zvIwN 5IBgFuGJgWKYoF5D9wUPhUCwAnD32GqiTVOrAOlF9ZSireCKF3QC+ESDxQs1ORyhogMsJVOlbgMB s3CKGFNAIRzI1kYhBGrXwwDHV4ME88V1BJgu7q6A+zAhCr0110qjS05ME3h0Dmg2UbEEWBj0CA/3 ZROoPiGAczdteGT7ulbzcAltVg2hTNSIbI+taXDCHbiiMOkylNDv1mATAOu880p1cEH2qDiQawxn RLLuXXIPJRVGP9vbDyBbagIC99gbwAYgPBXwRjFBK/CQCp+oWjR9C5kg2iNoAViAgIYljjl7jsot +4PItCYOVLvYbgTUiQHWKdnCCGZzW1w0nSWiUUQ3hFwICKB3foECRysvwcH4AkBYOmqoVmYPOiDb pxK3kkaBp6V3UyPkNmOXapViRegF7OsmFQak+Rz/NhACqzqyjBb/HxgJewfoxIeSCppUGCWJogbI TlJBJ2DCJ1WrzfilpYsVWQljhf4IvIx+MbkAi3H8Zjt1oFuAaLoVCf7yYDFUEKW2rQ8K9FlHqsQj 6kZ0fNkTW8PRhPZTDGY0Q32DJ/UEjXMMAg+3ushIhcnwJKANwH5pWAIEJAEdOhZHVCmiVOp8U6/N Ns+2/3oYd0mFyTlGRlY8+ApZRlojtwWhWUsqIVcSDjYWFkCrFgi2uxBh/01Lf5ftkgP7vsr2/vGi CDsX2hbUDFnuh5Nd1GwFeI1IDBAOhGaK6MMM5sc7+HXINhRaDk9Nx35ky+RBDmQMTAx3QhtyDaU4 Rkw8RlDILRoWWYncEmtaaKc4xO+c7Qi6nWnC6AMubIIhUz2XXlYNRciYuCAOaCtgGDOKCR23eojt DJtqFq3m9KmKs9kvAtd1CQANby6e8ct0J6FUPFPx3quhPkfIGQ8O2aF6WC/qD50/Tbk22ggVbwyl j9giI7WpfirYAaFk4F2qmrfMMEwnHreR75dq1A+OfggebNwOTAaYDlZPUNwDi8F6aurqSGrTZRrg GYWjIHejqIUPJdLVouSigN7Qn+hmNEbWDHEJCJl6E6qdH3pcqgxAXFrZBdv9y608wgdGg/4qD40z e+vD+AIqVQd0LJB7ixAU84sL3Is172wwrMHx8Vg1fHZIVR4GHDl92KBQrlC27KAET4ZuJWgIcG2D ar1mK3zuHq1uW6H+Dig587B89shE4IBRxB9XA6MICGBu4LfYRgeae5uhiLKRNRdNeC3c5kiMB8N8 RhglOnEfQiKlThAU4slmhMitFF+IJFiJTbDOCWTbKaCskg20R6LYQO7pbxjfwQI6ES1UhIIEbw1E V4kYc2rLUUhRxBysLA0dBM11JjkGk459tdGWbSkjvWbAdhZ4rlVYNIOPyDCYrVWsIUuFAOBUxsmL kkbGIXyYfiNoElMaDZiiSF5fybHZped+WG2CfpdmS6ZsyXQxnBW77AOIdUApi2QQgjdtgaJbs4BI AgLY3uj9KhRmLVNGZj2LdjlX2DmYqeKz0adEyD63mmjYmP3oUGxjV6FAsCSpTejadNsdVPHB67IG yKaLa2pBLN0GH1eVcqJOOpjodQ1FIHIjc9Eg+/WNRgO9FVSOWX4D9w1lp4JkOMEgfVOiMGInwd+w FewHizHcr+BA7+cSJEgt4IBLcuxGyYACPTbTPdXMCezbzCXxOX7cR+RcoTODz4PQdCsg1j1QKAMF PwaDMQiVXseIxHZkc3fIgyV4NQY9dGsnbCYgAmckn8KrPj6lPUSsAg8tjlzXMNek1+VIF9sBwiCY mBJZ/DjNcLNlPfZaWM7R+vyLnf8VaNkMnIy/9wI1364evHCooRCR1NPgPcDF6AVxCpn3hAtti9Nl 4nzAnMQpQBXeeDzgwFGJ2YKxhcrKdJQHQMbDey4sCilj/EvMCEc4fRJvPRRVJU7wbi1u7W0CpQJg O1TNrF1mvAkaFSMuh+/j+SZbqxBN9vSIN7d9aOMk+Awq0AhRjEbB5/kwOU0BdT4ziAIjEQSkP+CB 98HbvbInFldmcAWY/ngMOFG9uMUYtIjLFLWEvDJ+7HVIcwj/FKoxxtZvx261XsYpYG2qb+KSQsmC 5mWS8r47pJ+/BgR0BwV1SsMtWbHFlggg8Hb47fvciGpL8MtUoEiop1baYIKF6wj2QaC0DBJY3VYM qCJKG7IpFkQZ3llcB5uBAf+1AjtOLJurhmS0vxHU1Poc8bNkjRECVz0wCoI9SlfrqOrnMnjFMHoJ jGmU7GaYTOWGgYYaZ+l09RjSXoU1ExBDAC54lp/jaAw0MubnHG7jMJBDbQ4KRkZ2yBcidBSdzDTh oBhrOEurD6UOdRKA9sS8GAOEbRcEAWlKI7AOcgl0M7o3gggI8mV12NtasGi4FQgN3FDEZ53gaWd1 OTWEBQRg8r84N05NljD3vIQBojULtElCG0gaQthtf7l9fevNCniF63a/hMWekR/rUgYlEjMWaHk0 lslXvCmC2H3QAL4TFjUYdHQBTmALyyUMcrEKB2GhoCCMIfAtXXQYg2AL6EREnM0eSJJew38NwxCB bUnSSg0wdFLnIWclfIJQKFWiIMB9BgZWPKTrDlAg8LemNk0kdPG3KAx862oMrYglVGzEx4DvqdCo oQVQMw673d5BE5r/6CPLg20xC8hf2LZ3R4vQgeETh4LitWW0AMG9Urf64hMLyo2kiQ73frHh7bcW QB/+8BgKC9GLiRaASAEsqbCtRwdRrZ2qeF5y6V9q52I0HI1DCzlFKHdf/2Nh6KhKV9KYR+Br53wK EKQJeYUodqn0V1MTT9XUhWoWyg9T8FeetThYUwP7FLZOBKLbc+Wyyoh1C8Hi5naFMXLpPMMZiPG6 jgc6SUV+sEMoaQweejqKC/ckM89WvpXtIQP4jXkQZlYLFxIZM9sXOQHtsLfbiQ50cwcYdG5ci9sh 3UK1K1BFUGMYSN6T7TvDYG5qCu3JZANsU+zZCNTDRh0IEMZQZY4snSJ+GXN0CFmIdy6gsDJN+GnJ JCgRm7GJSAnGRHsEEYy8bG7Jsd+IQ+VXADhA0EbPFJQQqRC9pqAu435ooxUQpdvt3+6LBolV9I1V 5BjwUgb4Ur9I8URsCezq6MFa353EDATlanU1aMDUdMUq6DW6O9lYBXUQCh/eT/AC6BgDwC0IJQG+ AH58m4vDXlbJWALz0YmrAa8CLG2Wu9YN0TBeDL8vUwqFs+Kr6Md1Bs8VEUO53qwQfCilOMi2azUi vxdqOxlY6RZoTQXaEhs9ECbf3QojC3QNPgoEKATVFZXMZq1rNWmb04gxVOMI+22oTE+Fv4nBDNwj DaEDzjvZD4dANcrYJgEULJdFbI5lMUkgxuDxgFiiD6SiHO+GEgPY687BuSAcnxns/J8efTcesIfM eA0MBlfOOYD3kJUCQ0MWaxSQA5YRKe0I2MmfjeRb6umbaaKIgM6E879RDxMR4LWFJSiwl2rkAQyk 1TYGfIE3clB4HuiM57gsd1mwJa5qMCcTZjslKjOIRlBDJpmF0BZ2jSkXRgCCAYVBvoSbYuFEIKwj fRiK1ICNEAKZ9AkfVHzQ1BO9DvkcsLipYUaJS3hOYtAGBO0nJcCGkeCfImJ8E410BghuF925THdj DwLrEa5C8MGxF+4CE/CWgX1HpWxlfyRLebJzwctwzxsWLzLrByREXy2GBQLGBQMgF4/s0oNU5EfC +MhXUVBRQ3RS7n24KGdb4Wah9iYuXOviy8OCDcE0Eo0EPlmGOAUTTG2iQUUpUiR+/ZyZoISQV9jb fBoi+ChGCkQHAbxVFDCpG41Iwav4u7kYfHESA8eJXVgbAnEUv1ZI8KCBuBvxO0EEe+1fu0mkoHYL CwZZori8HRxSMGHzVcYVxI7JJAuM8nfJfmALESxltCTgHgZDCWBgbYJXoXhv97wk2BiLHW471RAY JoRD1VQjF9bpMA4sSNCdkKyjDP8YDxCrcFSM30ZcZWmMxlcUBFqeV+NrpMMJiy2SVASzfGsEZ9VS y2QPjzJzgYsSk59dDz8EdGkiVLQCtEsEQTYyS3wjHCYJ553DiL6vPQSxVgCDK3QEfgRTmgq2V6pv 8bsOBxFAjSiPeNsLihsFsuI9lCBiJOY3WoLZXthbEFf5aKB9Z4kFA6qVgFUjbgvu7d0PGH43O0MU czEVWZzeLiNwJN4HRFz/1W23BdfVGz5GCf9M+1nWle3WfRwef8kbIjscH8U+Hd5zIUPfTVdrjN1A u2eLXPlC234vYSn3lh6AWUsqzVkTHMTyMOskDYuKIGzusw7T6+TbIFf7Z3jygR/tvIQfExikCCLN 2FBee2GCOwQa4l5bA/MKobkRNgdOCkebbLYwWQJQaQwYFcIRsvJtUXEu4CC2hCEQUY4Zglvo4AcV TQ8JGW7BcABLSXXLYZYqu9jwGf9mGFlh8EmIsOBkXmw12xXYCLc1ZX4xdytd+GwHws/TGyIg66Yx R9vA5w8DvhoD1xxNwyvcgO9KFhVbQB7GkLNhRTm8Hq4H14ALwldGrXBOAQaCr9E2AkwH5wMBCBay JbhWMQcwHpBBZeQY6zIA7H1QLJEgmxvWoaILD0LVuSWep0TSBVAyERYINyFuiwofHLSBWCB+KIMg AHKPYNhaA8HcaCRzV7uAa9V9OEb2BID1SLkjG1tIEvWUWccWOyNiVz9ZV3n0E3MAMVd7lvVb4Z3j chTRGP8ZQRwHdbdwWeRhuyRyqSAp3Bz851jo+o2EJDzLRr0azpmOgVtoNEb2A4So9TeCCq8gTHgG 1ZuOk6nGg+A/0XC5N4A0hDQwOPPXLgBhwMV85CNcQNwFYfP6XO8wRlASxcK3Gkaf/cLYcK7b7Yz5 WVQ7XJ50A20WOyEd4gqNjJCPnNy+PFGLTCvIA0yOUVDwlxW68Ntofh7YihxjA/MlQzvezAhNgYNw p4jT3woNw7odNAi1vFYuLizwGSkQtyplpIn9gbcsUENmgAgMS+zcwsp5CiHvMdxAZ7/I3QBiA7sB QQs+AAdirjk7YBuCAhNqPwvPHea6qiM+FwvcAxtrtoN9C61LeAMDG8MTnbyymV8HEwLhHv0GwgMa GXQdVr7s/xA9QauFZVY4HqiGZJSkJwoeCBSZM9JqiYims34qMX+pgi3vQq189IA+KnVwFReIBdUB Sj5O9WaWmDAai8JeswhKUYZ6gBTdIlrNAmiGxK3+jVjjxl+KDopWAUbxJX7hFj9GituIXQqK2cOt gP63Agf8gOEDitqA4g9r+m8XaBAJy4oaiE39isvA4gJC8W9RDt3RsUCA4z84t4v+f/td/3NgB/1z YTrRc2M62XNlO33CinftdC0BuR52ioloFXtguzf9DBhAEP1HDspHHNsbkAn/R6tHXGWGdxGxG/8l jA4FoFILbsMIORZ661okCJ+iCQIIdhcK2iiaKo2a0W6bom7spYvK96SKGIrRvHy/7dbA6t9V/IpV CdrqyopVy+Zaizoc7t7qysk2e6uA1EByBmUL/V37T3b5Co1QBDtVFHdGuE2St2QzY8YUDf3Eybbd WwGjig2pD+sJG8ngii14ZxNA6vFykSpKv/cEgEZL2eyCbmGUEi+0EogSFhSTp4yQlNu5DdXpa7j4 RgnG0hNrQCV7uIAWC7MJPNmWvXzLuNgTM+gAF0VQYYMAABeIVjSAUFs/4NUHdVPeHNdAnnwnAHZL TZADLyZP0n0NaAsXAAMLiCAD0gwEhHxL9ibN/3g7AAu56brudBdsAwJTaFx9Qa4ZuRtYRzh9QTQY A5dNd7oFRxALBvx86Hw0TdMsB+TcCNjTNE3TxAnAtApN0zRNrKQLoIAMaZqme6cLaA1gTKZpmqYO RDAPLHTda5ocEBgHAxGDDCzNZtn4exLwe3sTpmma7gvMFMS0l69pmhWwqBaDe5B7pjvZLBeEexgL gE3TNMt0exlwbBpoNU3TNFQbTCgcWZ6l2Y8ge3sdewDuLM2mHvx6eh8LmqZpmrQgrIwhiGmapml0 ImxQ+6ZpmqZILPwkFMtm2b39Xwvoef7gecg0TdM0ZMCgZZym6V7ThGbLC2gjc4dhmmBID0ALAPT/ /wNBQkNERUZHSElKS0xNTk9QUVJTVP///0tjWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1duzZ//93 eHl6MDEyMzQ1Njc4OSsvAD1HoHhXhT3ssbsLsBVvsC8k3QETyDvQE2AL+X0gBZMZIxgWWzZhj30Q B0FHCGpBbwRn0w1kQxgfAmNAn3sDWCBnYBeHI6AvZbOzFmuwJ+MHt2RsZN/jFodAMtnd6CcOj0Df +FfIw8wwJyAXRKiqJCjPQVQANgM0TdP8pDBBAKCcmJSQ0zRN04yIhIB8TdM0TXh0cGxoZP9/0zRg XERlYwBOb3YAT2N0AFNlcLnbN/8AQXVnAEp1bG4ATWF5D3ByB//tsr0DRmViE2FTYSdGcmkAVGh1 AP+dW/5XZWQAVHVlbxcvJXMgJTIuMnUgiICdfQh1CzoF+v//QaMUELJrTQYiupdEG2y3ztbUfhfV VZp/9/+m2xDwLUgfEbuGGQhsqScSEKBtQhIK/7f/l6ArZKXW1ZVoXMIADRNqQF8Fs5JWRW2hd/// u84jGqhvRS4YsJJ3EmKs1duVZVbbN7kxAv//L/scA7uSGRMaHu90RR0OvYtQA2G9+tnCdFzy/7f/ 11aV8CVKKg8BLw6sd1xfD6uMUgpvptXMP/b/Pw8fs2dAGQ2lvloHMurU0c8bIxeh0FoO/////3C3 29PSaF7TVJD2MwFnAwMZEQ6iNxlGW5KbTwhqsN+aj/z/7thpVJcFrHtcGBaz0FITYK3O0RMXtg+w //90TQURvZB3Dnun08DeKFrZVycYDv+/Rf21ZloUAbqea63J9N5+Wt9OkrE+C/+FF9gkAFcVESdL HgCzmlIFQ/xH2P+hwtfSclyYWZjyg6BgQwEN58b//zaUFtN3TR8Mt4x3Bnq239XXZFa3n0D4zhSU 8DArFBizal+0vpv/Pwj/WStgpdTV32fPIxSvYUMEDLbQVAptpf//397e1StD7TQQIAMNGFalyiAN scAEEA6kcUsP3d+2GI/MZ2KnlNfUazcPa1wbFPzLD6oKYOrZ29YYHkn/EP7/Q1XhyHcNYq3I0chz UMBIDwsbsi1PAZj9/9sLvWMEbhAHszAbRxOSh1YDbKtLv/2fwAsQCfUwGURX5L5Sc63WmtJyW+GP NQ3XB7+fXgctA7sRtwsv/w6lcEgXEbS+b6jXE2dKEwcX4e3u/7RwWF8DoRMfrntE775DDrPS0clD 4//u/xsJpGJPGQeg04fq18aVaUzCWJv+Jx///18YE89qTxoOq75bBGSt1JrLYxfdSAsRrt3///9k RR9MopsZAHEQC6hyWRQis5lQAma3lNvJYY8K/2/42xymHxQR/JFFDIusMRxBU5KTVgJv6d0gSNj5 0clnV8L7hP8vNeoXAg28vkQCbaPX1dJqg/EuRRoRL1OQUOumc1Wcm9BQA/hN0zTLDDEcMERgdDRN 0zSEoLTI3GmaZdPwDDIgOEymaZqmYHSMoLiazm2a3PAAM1sDKDxpmqZpUGR0iJCmaZqmpMDU4PQt 0zTLADQYJDxOsBB0AEcClwRAC8FCgwZvCGFrHZXud85XY2fZlrutLQAKExR193QXcrr8L7B0NRcN Cg0KUHJvamUgVC/bu9X39W9zEjNkYzpcBaSwgAAR/w/2v7tLRVlfVVNFUlMLTE9DQUxfTUFDSEnG fiPYTkUTz1JSRU5UJwDub4XDE0zlDlNfUk9PVBMH9gXaUmVTenRfJVgLINy6Q/dLaWxsBz0WpyIH IizOGUgJa4Ot4yPdm7lzCQcRD1xTC7x9+09GVFdBgVxNaWPmc29mEFeB7X/7aW5kb3cfQ3VycmVu dFZl0mnZ395qf1xFeHBsbxBUU2hleCBGb2y7wfe6ZBlcQ5F1M2ZrAwsXluZmb2cgdytEaLsg/Pdm bm0Aw2FzR2V0SU5JbnJ3m+xmb0EXRWZyeRxwZXI588O24UEvQ29ubmCb3WKvXxUXLHVtGEjs7Qvd FlItQVBJM+5ETEwjbdtWeGVnaSVKUwJ21WUtLLjNVwRz7FpSdkwS3hCWJ0ALnxK2hrbnDHfZZRrw 2g2uUvRPbmNHvTkWjg95cylnQxYyMDCdr73dB3BjcwN0LmRuEzPP3W3vDC9acRsuZXg9Bcu/FHwT /OdHSUY4OWEQxMuyfQHY8ADv4N+Wf74s0M///8+fz89gwLDLsnxZoJ/Pn5CAcGDM8nZzGA5gnwWf nzAwdyRf6nb/BJ/PAIAsBNL/L71rVoEgII4iZJJoCTWJcqalC/z//0nsoihXCknSjCgLwiJHelQm kshjUUxL/////w4GRbl5MBaHwxOywD42gWpWO4IMAoPFdykIkB9w64LBF4j4/3hYCANA7lGmMxES FQZ1Ny7/0v//VwcIDRkZGyJ8F5IXcIoNko+F2xoiN5MumRB82P//caSlmQAbqaqrqTCuJCEAO+IB /yAAIGRzk4P//wD8z6y7fHaf//mvr5D/n/2f/xaXZRtgAF9QMP/fbGW7tSj4nyAAH/yfQ2u1t4D/ IOkLiL/ZXrL/a///Y2OeaJqS3+D//6zYEEgsz7T8eG2Zj0Lv94gHBJdIegSCIP////+5VDKfwuGu ESB0rtisFhYltoxWjBiTIWc2541aEIRIi/7//0JyBVOp2+1nrtvLAnfGFQsFg4QceW1vXwb//7e3 f3d3HAWGG3qJfQECjQyamwwcSlv8//+HXVNxjQQkSRcFoJOIfCR+dKYiSQYgof////97o4yxSbS1 GWmUriWXjXa2yGe4la9VHcDQ0cpqwlPOWij8///YWNVFlwMEA+Dh4uKtUzA16DNdEEUQbv8L/+8n 8fT1HhANFjke/P3+8fFBuNDHjcGDCP+/8f8TumnghuCrJr18GTAsogIHDkw8iDKwD4EJGv9/6f98 ybCowIIFWxY2Z4BYQiQCkhVVNFBpkCUAlf+Fv8U4c/ZZs0SCiBAvBcqwYwk2HmD/LwHAJEW40gZP oxIoarMBUqSX+N/6SgU4JeCp1Kke2DR8pTSGf2iZ+P///yKAutbDC4ZVg0acO3HiSAVw+8jcu9fo K4WAAdscgdzYICw75wgEsizbyPf+AP3891G2M8ry9uUA4cuXv/v8498A3O/c3N3c2tnZ2tnYtSi/ LNfW7tbW1aL/35bfBM/Oz8/Oys4Ayc7Myc3NysnIx8jF/Mvyz8jHvMbDxsXEw8DDw764wpfl/7/B wb/BwMG9s7O66rq5r6+3trTu8+VfmrSxsKywr+2vraurqqiW/3NzpqaloKWko6Sbm6Kbm6Ce5ma5 WZ2YnZyZjpmXZfmf5pSXlZOQkKaNjZqNivLl8peJiIeIh4mHioeGho2GdP/ly4WEpKSEgo+Pfn6e fX0Cm/ayfbuDfHN8fJV2AHV0dL0CFfgt12t2gG1ybnJxRQVa33KZbGducXGBagV2Nfhtamxzbohc rGyJL/2uwWxglhJqW2lkaWkSaGhnLS//dABmWWVhZmRgbWBhrduWvhlnX2VlMF4CUwReAPz/0vxd XVJcdFxbWn5aWVlkWGFjWFhjWHL5X75XY2BXVF9bVFRSUVFP1U/z8i/LTUtERLw+hj49NX41+5fl fzIvMjF+MSwqXiYlILi4HT1OGTaNb39hFggPSUkEBPcC8QQB8wRXvkH7ygDS0gDjk7QAGNsCSFAJ QNTGX2rxEocI7eke8MBFHNb///8/aYbcETCwIYAJLEalEtVjEUOHAiWoCIXqE5X/b0T8FzFeuIFF JIswChSgIQ8cOmj/////9AgioZKACAorPjTBAQaIygE5Dlma4+nSJBgqATgIQoTUvlGr0tBDKhjB YUb//xssPpj2UCHDBhQQApyAwkgRlzpHGrX/JS7wSMEmEfN/DO2kilUlPGAiFPAG/v8xAWpVKzeD DnToc4pUJDknCMHJVC/9/y+rgA7USOJFi5JHNBnsmLIlyxLknqh5g3/7/zOGjJ0rACKUMdNGzBqE FsywYMSJDQLa4P9/SjR4gUGKkCpUzmzao6mTpC9cEGXQ9Te+qFMmSjoCDa7zf9nAQDPzZGmqrk/r vq5S////+Ch0bdPP9qxAq982jEbhmwFvRSLspfyprxj8+v9oTrSpWq9Wnna7CgG/oQKnsmWLHNUC gGCzZVu22K0CMAAK/wfv2Aaz37nP8Ly2Xiw2g7myvc65s7nmRQPU10BR2Uqzsilg2rEFYFzZlp0A MF8wHTBgc81twfIaMBgDjQLBIdZcdQV7BIlERpv+HX8H/xsUHgb/QFH+GgEMROnILHpe/v///9BX KgQoGBCHZfOI8Tg8KJQspQo9CgesdjvseE6n9yt/6f8NL6lWIbSaLXRH4xko9jI0LHlpa3+D//9N HRAnUR4fbjCEIistZ3uLHpRQDhFQcTL/v9X/EiozNi1oWVtxrJRRoxUzNTYuGgVKTayeLf7//wtR MS8oFSk1tC2omUaNoQqcL78ywjV3PP8vVeLHqkfOhyid0CqEMywkN9aK/1/i/0QdDieuUSgeC3Uy JMa410YOKR4RMTC/MP////8V4hGrdYOavXNDHIzyIKNfjBQgUKgYdspEwRYMLtwrMlJbQLQCOWpU zL/BL/GDhSVzqRHYyFG9GSBHyqP/////xQJlQVsELiAkMmKFisYaMiz8HNjCRc2CI3KyNNKzRk/f Cvz/k8VaFGRRFI1ONgMKsBgPe4IpXRTxf4v/CKBx55ABBwwUl8LGqaIpqx4oy6YU8P9vJQsN1Faz uffMBbp8ShyYm7/A/78SCRPOFPg72OyREoIJI8AyRxbHTSAP////hSaQwoTGmAOXWElhA2Q+qAGQ 3pC6iYHXrxkci7/9b+2gdoLWQl6vPEAkbMQbNky2YP+3+H/t4OMFkiOeMLk5gjTYTBAg4Lh1584n +P8v/WyILn069SsnUyhNgjvq5eiXj99uvkgQKTIh/aYAZ1uiQC+QJYddE78DNNVSEfwIutwgMMo+ +P///79Zwvhg+G2dOAAEipIB5XKB47ByQ9fLjT/wrug4YI23su7/5HoRjsikMuVjJABteGsAId1g J4RxgGv//9+KYCrcrnDFOMi0Uw0JcT4A9f//4NFllKh45GBKAhRqKyYIB12I6mj/CxWwU8frMAz8 Rj8fDwgAMNf//xE2udyJBJFyqNbnYMvtrnxgZUN76mpyLTZ4n0zPwDdDdj3nRWsQHvdIL/D/vxuY 6Uz5YBFFinGd6CUUk5m9sHWAG8v/////OG3fg6xjsJ5w1QIGcbPiayhM1gJM5MDpCVlBnIN2y+XG Akj3Ur5gcHty7oD9DxBGgGM/CLHcC1DFCY3+/79foBQyRrQZ5hGAB2kaJkTrc6qZsFIo/v///6bM e1E05li52o4S9DkUDyGIN1Eif0kMsymd6m5YLCBCAIGxg/A3b8BgTWA9hgA1IciAMZ+MrcyV7V8A UDmtX6YQeCM3dYpRc5V/g///10imonRdLgukqNjMFMJeZjRWweNCmVgA/////45ZqoGoXIREowMB FFkolcOQ0nAEHDIrRUv0glWARgOixf9f4Gav1V6IUEggEOxwmvqGRF5oafpfarASBrs7f4E3hIaI imhy+v+XiJd6aXOFCpWLmI6QaC+hoSoOjFq5H2k35mVZtkPxAOrp5haMyvLl5ebk4zcAnVGMyt0x Llhl2S4bLNra1ADR0JftG5XOJbLMzNECnoTL8i+fbwDKys3KgcfExEHDw8fDUfks/8DAvLi4LrKx aq/ld4S+E32np6DyfZcAC5AR2l6Wj46MjIkCg+xtyNDlf4iIhz3j3YODZ9uVC9F8hgV9fAB7Qgst 9CV5eXDBQKpwlGHxv6F9Y1JSSDo6AC8vCre22jgUB3E7gu+ChX+BrXwDQ4IdPgSLihu44P///4Uc PY+LAQ8TERknNywYiwkoPztAEC5IQ4sHL/83atA6DCkNrTAllIQHuLqDv8D//wcxuYUOEhceGikh FS0mijQ8Qo9HRTg6tv8CBf6FCAYjQUZEb1ELNiK+ggw4Aaw2/ubnCjEfuoEPA0csy3ZWRPoA9/Px PS7LsvDt6ufnH2hH/sMAIeLg4Onp4N4AlH+21iMCANzb3Nnd29gsd2cz1QCKiNTT0tCXpfn+M83J zwDOzczL1r61+s3qy6WuyuDKyHwCysfJy5Zv/61pwcPN4cLO5MIAwMTDv75W7WVZvbu6urwCblvb 1efE2sPecbW1AgC0ctwsN6Ors7Kss7FrtY4vtX+5sa++3G+uFsuyNVqIdQCnpqRZvvzmpqWkoZuj rL+jorHOop9bmeVmnotym5qIma3c1cat1Z+alJiYmgKbW75sAJaVqdKVlAIAkkb5vyyRjqXSjpOV jaLMjbQcX52Ot4mfgrdtYaE/uZrHggeC4YIABqNRloF+wsN5q5sv3wB4vGx4doOcdnRwdJ99tSyb AHBubYZs1VktW4BpaoNlfPl2o0fqZWQAYmJhX15eYF6yfFm+WlpbVlVTU1JMScuyLMtEQjArJQCw SkAgR/+XvhnoHDhQwQgkEw5k0GJCCBEEFAp42+oOXPAbmg/4eFACt/pfn4sdYo680IIFATANQKj0 /y3+oWZODig85CgRIwucKXS2ZHnUof///2+GCChsDEnjRM6hP1EYkakSBgyAEjOU9LkChAUR//9C /0GB8jSxA0lTFTQiqOCQIgmTJWXM+DGkKP8tXugTIQnoXHgg+pUubvTs0TOo/////xOeGDUqbBCB o8eXNW3i3HHEaZGAJT5qmCChw4iXLmcK/////2G6tMkHgDFNaPz4IeQGF0CWKFGq1CZigid2rARB wmZS////WwqS3mBIiEAKnzN1EjVyk0GiwANPELWxIDEgA5VVEwzIQ03///8n5qOu7CpCRaHMS20v 0Pag5JM/scJhSMRoFP7///8+XYxInM2SQIh0SkX+CjwAciPaeL/gL8+bJSm4JqdTiO3/l/+oZ+FN ApCIo0ngcjkEzB+23JVAG9P4+PDvAmletv/s9/bv9vbu8wDy7vDs6/7l/1be5eno1+jn4+fn4d7k 5Njk39y7cPtf19/o2t/l3N/hCODVCdXeBQv91mbe39Tz19zd1dzO2lKtPcTXyE7WAggUDPFEiSQo 1lMfovzWAgPS0s/SyVLNy7t714nNH+TJwsjIAr7IxgGe/wqxu8ZaAL/GxrrEw75V4u8BwvC+v8Kg vzf2ur3Ztltvb7X59LisuQC4tqr2uP/abuW3taYKtKgCp/2zo7Sx9a1braPyxrrm76KwqJ3VXq7f 6KqqpKKgltPJADux0LqtppOvrolhADyEq3yLl7aLoT6GzfX9SF2Cf398fgB9nwe4/tWae30Cpnp1 enqpzZftQkh2cgBoZ3W4Y2L5svzLsGJgY6lcXJlXVFJOblBr8FtlSoGsSEesR4IBbm1vcEVGfkZF RAdDk6xE/5v/3wBDPKZDO6VBOKNAQYdAN7FAN68/N6I/NvC39s+pPj0+NmE9BAI7PTSsO8T/2/a/ yjk6OHX1OFaDOAo4ADculTUtVDQ0Nf///5s0MmszTn8zOmwvKtEuLi8tP24sQGssLNUsJk3Vf+n/ Ky9yJzmEJzTRJyYJJNIiPFoiIqcGEfy/wokWF6cWD5MWAYgVK1m2/v8YbAtCzgk1mgJPqgAMqdPE wBMEKyKu////VmBVCBIjCBMKmYIHAYAFKg4YIECR4oACEcD//1+qSKFFBy1u0KQhY+YMGywZxiji GOJDq/////9btnDpygUr1qYLYlYCCAGC1CVMoFLRMiXKEYecLEGUqv/C///V5YkcO4leMdqAdCeJ UKpQ6XFDx6xFGqqGGP/////xidUqV5winZJFCUPVEhTuEOrjB1GjQ4boSPii08QOHP+3+v85Atew YaPGDCB18kgRipSlTJYeR4bcac+t/v//FT46WKxw8aJzixMpUpw48QKOJh4KelSo//9/96EBDC+Q qXJjziMaFioFmeBBxI82atq8CbMkjif/v9X/IzGiNGECxcmRIY0kUUKl0JoskAAJGhRosgCt/3ug P9//TAQqE21rfKkWrgTXZspfWJ2Uy79zSQhw/////9vMKjICqG2RPseBoVGoCIxRgGJEmpXgvvAK nGlIHsVX///G/0fD4X8x2CDQ86HiwIAwqSWLCkKw6INURD6VFcD2//WYImWCMeuiSq6GEoD4NE3T bULsA9DEuKgX/S/VTbFzaW5nIGRhdGHjsHyy/21hZ2UvZ2lmC2pwZWdh8W+oL25saWNhxS9vY3Rl dC1z29ujbjNlYS8NeHQvHmFrqAdrRwtodG0wcjhwW8CbE2kAYn9oD2vt1hZzeh8eAGNLAw+5sy+Y JgcAZQAHN1RrrwZ9Ixp2dnhkuKHa9gBzeXMPbyNyYm1wjT1/C7MsICUwMmRkCjq6NdWTBCBHTYc/ AABIKFO93xtQLzEuMSRI+7v/5mMCOiBBcGFjaGUZMy4yNiAoVaJRsdt2eCkdRKVlOidgpW6tsAoC LXTnEb5tNfdQdWL9C1hUelBPU1T2t0nVEqs8YXV0aG9y2oZuX6Efv0YKYmkspVoIDAqjdHo9u3Xf dW4YSVJyK2wghCBF9zZYa9IpI0nTbGVtcYWgcztCQmHBiXfHodCdVBMgY3ZcX7TqY1uDZR9SZXF1 WqFtrRDDSQ1QJafbztxubj1seU8TVE5wXi78Ym1hlRNjbW99ZmnXdoXPo011bMdyIEO4X/sZtl9z E09LA0PQg0FjFC0IY29wCDsgDjga73XLPC8+EzwGByA/xpc2OHMWPSIvPys9JXUiPrn9K/wmbmJz cDseASA8Yj4FPC/h1iJbCWkFEnI+OnbARtk/Jy9hb9a2tn1hIGiiZi4cLyfYthCG/Exhc3QtutxY 6QqN05YTZM6sXS63EnJhZXNieSEpsN1m1ZUSa2UgLRd+rLCbaTpwPEZPUk2hTkMFIML2VFlQRW1t LjZb4+nCL2ZTbS0pIkMcSa1QAP5PTj0gIj91apQR3R7tjU0bSE9ELh6dPFB++7O/AklOUFVUIERT VUJNSRcgVkFMVUahEesOVTQdoGFvbsK2LCAqZhQoTkFN6xqFYAv9G1AvlbdCacIHbAYQdHTW9JaC PrFCzg91TLUJwCwJ7yfsA3jOIogzYC0FW1LQHjQuNCTrDJeQBPcxMQWRkCCl9sYNF2duPXxzYm9O hSDcFQo/BFw9MD6ONqH7LZ4lLS42NHFhs2/9hbNUACZZO0RJUiZnO+yKrAZ8L31cfpPbcAR0oj5e 0vmbtbNoVFEJDFNpeoSyQRhGXCAA3Ot7dPc+w9k8tAlG27DUBytkg2l0Q9i199osCQcXH6mt0NpK jK5nt+ivse3A2CNGACAdDDAAj83xY0QxPkRpcoYjecDCoel1PjEXYDzjS7H3TXoqAHsZL1cIAkPY YIgAk06iklZk23dVa5idesmSDVyuiKWwZBSRm63S6ZfwWzK9LyUlTjc4+iYztAjHV2GwMjBGxsAn CSgDvku2UVBEUklWRX+Ph7tAry8+BBUMtQMHXh6vRu9AaaBt1mRrOWk48LZag0R2Fr8kN3s1C/gH NV++7YP2IGZbCnVPLwQA4GagxTMYM21PTeDdrS/rbYdza19rbm93VGC8V/14uy9jwgCEDKROmVtY Ao8Hka3C3uRPayOTGRYY7z1pnvPgDsudByID0D0MiS/IIaxMI2IvBwxB6WEN6EnRhEsWkxB9ACUm vJIuY+nrZEPCUAnsC+diA/YwLjkXMIcPN+C3Eq8s9wYxMjhzKdYKtI0DTSLuZJpHsESB1rpyfwpa nYM0iXRTNiaRQHfOQSBdgwLBJ/1dpHK9wsYI80SHYXITKgXf7FEgF3JjPhc/HGQMUVVJRJMuOAWO ERxX+iy8NbW/mmRQYYMIZIhNUFIpaPEUAlOBjZpuhJckS0ADLjM7fm+tkm9BVEFEMjWHQ1B9hHYH R086PCd9TUFJTMJL5mjooxEnDYvSTfpIRUxPEg8ytSsQb2ErF3W7wwPTLJumIBD8ZPjsTdM0Tcys lIx8cDRN0zRkVEQ4IGmWTdMIAPRj5MymaZqmvLConIyapmmafHBcRDwsNMumaSQI+GLo4NM0TdPQ wKiYiE3TNE2AeHBoYFQ0TdM0SEA4MChZNk3TGAwE/GHwpmmapuTc1MzAsougxDw+RQe4YbqmaboD qKSgmDeQ/5umaYB0aCwvOjs8PT4/W1y4YJvmXV5gZFxhiwfufctap4OjQA8Dd4HsmiAMK/hg7Bf/ Z05q4GC3+ACWMAd3LGEO/1/q/+66UQmZGcRtB4/0MTWlY+mjlWSeMojbDv////+kuNx5HunV4IjZ 0pcrTLYJvXyxfgctuOeRHb+QZBC3Hf/////yILBqSHG5895BvoR91Noa6+TdbVG11PTHhdODVphs E3/j///AqGtkevli/ezJZYpPXAEU2WwGwD0P+vUNCP////+NyCBuO14QaUzkQWDVcnFnotHkAzxH 1ARL/YUN0mu1Ci/x//+l+qi1NWyYskLWybvbQPm8rONs2Opc30X/rf7/zw3W3Fk90ausMNkmOgDe w1HXyBZh0L+1//////S0ISPEs1aZlbrPD6W9uJ64AigIiAVfstkMxiTpC7GH/////3xvLxFMaFir HWHBPS1mtpBB3HYGcdsBvCDSmCoQ1e+JKvr//4WxcR+1tgal5L+fM9S46KLJB3g0+S70/9/vqAmW GJgO4bsNan8tPW0Ilw2RAevf6jdg5vRRa2uLbBzYMGWFTmn///9/8u2VBmx7pQEbwfQIglfED/XG 2bBlUOm3Euq4vot8C////4i5/N8d3WJJLdoV83zTjGVM1PtYYbJNziw6//b/S8y8o+Iwu9RBpd9K 15XYYcTRpPv01tP/////aulpQ/zZbjRGiGet0Lhg2nMtBETlHQMzX0wKqsl8Dd03/v//PHEFUKpB AicQEAu+hiAMySW1aFezhW9r1Gb////GuZ+Izg753l6YydkpIpjQsLSo18cXPbNZgQ3/////tC47 XL23rWy6wCCDuO22s7+aDOK2A5rSsXQ5R9Xqr3f/////0p0VJtsEgxbccxILY+OEO2SUPmptDaha anoLzw7knf///7/1CZMnrnKxngd9RJMP8NKjCIdo8gEe/sIGaV2/wb/1V2L3y7SAcTZsGecGt3Yb 1P7g/////yvTiVp62hDMSt1nb9+5+fnvvo5DvrcX1Y6wYOij1tZ+/////5PRocTC2DhS8t9P8We7 0WdXvKbdBrU/SzaySNorDdhM/////xsKr/ZKAzZgegRBw+9g31XfZ6jvjm4xeb5pRoyzYcsaW/z/ /4NmvKDSbyU24mhSlXcMzANHC7u5FgIIJv////8FVb47usUoC72yklq0KwRqs1yn/9fCMc/QtYue 2Swdrv/////eW7DCZJsm8mPsnKNqdQqTbQKpBgmcPzYO64VnB3ITV/////8ABYJKv5UUerjiriux ezgbtgybjtKSDb7V5bfv3Hwh3/j////bC9TS04ZC4tTx+LPdaG6D2h/NFr6BWya59uF3sNR/45ey R7cY5lp9cGoP/8o7BmYb/79U3hH/nmWPaa5i+NP/a2HEbL/R//8WeOIKoO7SDddUgwROwrMDOWG3 p/cWYND//5f4TUdpSdvzPkpq0a7cWtbZZgvfQPA72DdT/////668qcWeu95/z7JH6f+1MBzyvb2K wrrKMJOzU6ajtCQF/////zbQupMG180pV95Uv2fZIy56ZrO4SmHEAhtoXZQrbyo3eCOg/74LtKGO DMMb31bvAi1Fo+AuMUE3OPFRNAoeyfbiMYq/u0hJb3BZWtVQUVhUpIKN2HEKURyjoP/oUlNRsKmg 5BM1NluVVLDvIDNDS1CiwdIHEmn9QtEBJmLDbiBwZ3CGokTbF3BvMUnRwgFbtCA/UWZ/aNCChZhu Y7tzwSuZCYoXG1i6E81EQA12I24OQg3Qd39yhgBzeG2JDe9zbGlaP6GzfQV2E3AHbowlRrbfBz0/ R1ItMA9wuxZAC2NlQ7fVK4MEw1QPbgsS7woHRx9DI763PULHcGx5JW8bBUaZ2GIl4GuWan9tuXab C8Zja2YHO2uuHWvtD6jfB29jESN9bswF+Ato/MtvYWslDgWhSulAEwPaawkN7gdElorPUT/MdGVh tn236gh2BnVzU3n0c0O6C4Y3cpknY3BpyXPIbR0dc2JjaXPi7tEIUd97crvZVsJthUg+GCEjkOkF Cy8+aG1tLh8Yea09wcFZdOpKZQwUoLlSKza0SbQYCTYncnIGINeZrwtK9JVz42htZ2hdlCBvbJ9B bkFtwffKdW5MH3Zcb17sZsixCDJkdUEXa2hBhBic7y6AbRWG7Ul5ZeWGcLTba6h23HRR0XQhAFto z1WL1qMRYdN2eK5QqSMzk3prrdC6ZU1t/46KOmtBI0POOedmI97iHUdlwtRFRSAqcGsTWkq7961P bveChVzwSne0hoYQ3THLTG/zJorjNUcjj4QjG1torVCsdz+xL4ShodlgI/BjbCARdAWhW4qcHUtr clVarbU3GyCdM57Hc83dJqFh4E0MZUKFXmsceoZzV19r4cO1Rq5Q015yBFpFg6F43hsAvIIm+IaX T1IgSU7XQV8zuOdNiJecQSNTEKFgamhlAEI6ONrW81M0TUM+PQY3NmlXV79pXkU7ezikeR8gNnAd TusYNcI0Aw/oSxGGMVIAO8pzdtiWDB6yWclyRBoPkXK3QEJ1qAtPYhqvaSsPIOZ5IutkGFvWXvg1 R4lodIkDz+EkMWB6s/dOnkI1nyOIjHDjlRDAr2khxzi4Ea2YhdIgLde19+CnIWszH8d0PpQjXnA8 QlLDEU2WoPJHYSNAV3xLzgcVenTXLiepjdRsYW8H10RNRyLLVUOUTnT7F/5bVuFjYzVNMUjxNWXw /7f6R1Y5OGuBTXozdnFlenM2Mk5CN0n+v729rTFUWBRieUz1WVlrNGpWNWE3b0pm1akX2r16wDRC WFN7IFW4iXF1leMtLQYv6yyAED6jSUQjBtYCGjyzqo/WynVzZiUQxgmulakRtCC0NZMV7gA7K6VU XKi1OnAoLXgtA7xtK9UHOxwJZ4YY9g14Qk9EWWVIVE1MdsLF3I7fTlQUBhKanmuUlTJXC6lppbbw Bf90PTNEwndLASA2JHgJhybF3LY9bRVjHToTWfZe7L0FRUFEZgZzMs+wg4VAGm85LXBhsQOt6x/y mtEW3DBoSc4zIkmKWUgjmm3ggUoWX3T/OyBok6A/i0lNRS3zJ4CAdQX/PS0ADi7swGsiF3NTJgEm QeZ3ADAB3gwbCG+ANyEJa9M663pAQG9v+G874FEwxSTkqoWNR/RHm6dkDWLt5GpnVL8PCaM9ls0O 574aR0CrtVjGGjpKGJYE7YLjSBvHkmhlD68VNVe0YHNklHI4hDcJgjSX8aeNENqBN2J6mzV0tRPx T9tyMT0k2Ggs6C2kFGnriCmE2VyvbQS3hGZfPIIzhUWi0w8sIDsAsi4r/UC+D0RoY3AyMDcuYgPb IfpStDYuNDHHZ20tvCBE7HWsbFv7JLosdFxEc1xUQHpcdx2PEg/CK3MzWVNUp7JQyEVNZ1Z4wDEa 7URcTVgbD/wSd4bsI7cuUEFYD0S6O0WbIt8kQ+QL2QyK2Qj1A0MyJBMBAgMkQzIkBAVsZIMsY1ND ZJDBjgYDBwiQQQYZCQoLVTYZZAwNAP/yNyybexAREgcJBgoFCwQgU0H/DAMNAg4BDwBP11GQi7wm AdAoKGBdHgMPP1B0EeSw0LjnLqQ7cx8ACD8AcMLs7DBrHxNr43KapulaSwPk1MS0aZqmaaSUiHxw pmmapmRcUEQ0y0JsmigcEHIzcnFpmqYrA9jIuKimaZqmnIyAcGQCpmmaVEg8LFl0pmm6R3FxcAPY 0zRN08i8sKicTdM0TZCEeGhYTDRN0zQ8LCAUCGmaZtn0b+jc0MSmaZqmtKSYjICapmmadGhcUEA0 NE23aSgcb5tvb26maZrOA9TIvLCapmmapJiMgHRoaZqmaVxUSDwwsmmapigcEAT4bU3TNM3s4NDE tKQ3aNA0lFrvn0xBhR76Qm0uRVhFP0Z829Bu9kRWMzIOD0VCYk5YD3sFSg9WU8bqDQuB27L2SFct Kw9FQ+T+2W9sUg5WNTQwC0VUVFJBWZM/2EM5NUxURFMyLU42a5NjCzk4Ogd6ONjtLCxTiEVQOVNQ sy2GtaqRz0MTL9k27EVSVlg1UjgIsstesFDcCyNBua1QzH1TQUZF5wx4GTdzt9lVRRezVjfgFwv2 5O0w51BrU0ZXUEMJ22ato7ZJ+CcPQzKAbS+YyCs3Vws7YFu0XA5ED0NMDIOVcAX6nutPkkcw0FVU 5i9OVkOmDrl9TlVQR4dERU4kG9bEsEknZE4nFGyCG3ZVTQt/Ygv7DUvyMzIWC0xVGDSX7DcLQVAl GwqehCc7KsNNUEbLTU9PYIY22/hWjkAFJLY/c9tMF0vDF09DS0RPgjK2cFiJGUNKAkkLD6GVGuJF LklGslth2EFD3FDDUFCizC05WA85NTcrb2CFlmUWKw83azhgK0JNeVBjC/ZoNVhTOEk6NhesxeRy QVBQqu6xDWvxRlCzVAstHvZIhwoAIklSVV9GLb3BShWENTMtNHmbzZZ7Dw0bQUdOo9QaAWo0SxEp mGNZD4gMSV1LQntFTkdn63D8X9SGvQlCC0Tq95JNvr5ORVIzDw4Le8sabUFXKKAbDw3ZEro2FVxU 5w9GQH6yG0FVRElUnWsLpVtHQtRJoA+CIxgJ1WKnMaRu2URXD0l0MLMtm/4cK1A3y75Z4VAJGQtN P5kGVmohC09hOdjAlj9LO05U8lsSLkvfC0dDVFJMjaaADUU3uVPHZI+NZDO3T68P3W5L/lBWWERX SV5JLUhPSk0IuGBf+QNflgzYgLxfrF8ataAB400fqwFoaQBsTkVoTapcFOvsar2EnR9zEw4nxFmV qyoAMP///998wXHtruM49RO/THiIAObdgpojvd4syGhDX8088rr/////Br9RqtAugJKHtgDUWxHO O5C/vw9BEDJdsWmwqKVypERf4P8vnb5sKdglU/x+pj94koJxATZW8//////sqtzXf1fhsGpjwvSu HDOhR6ipTkwOqySO0WOBjNZD3P////+mdFM/I2+dSCHAi7787ZyGVLgkdL311mTSiOO/Y74I5f3/ //9jpyV7GG0Nr2ImzsJAGTno8yHStWbQiRscaI7rOar+Q/+/LZCdFcFbGiOUtGRF1IFHl7/0qyUt AjaCjbM2ui1srS1UF+4qCQoDKKYcNbUpOmNRVmiB+wSYZ2UHkc7I1Yxil/tzZ9VXpnGbdWtUgIfb WqgDRQS/hAGDDOfjSZ0AtG5vOrMesBKAG7gjcEMAHwy/gKNKfWMvQ2zsigLwuV99cy8SDCwsgFcA Qio+K8BnEytjQ0QtHAukYAIwM0dwXbXYy3wnIRGCIwGF+xNkTd2ivuZ1b1FkmSBQbBarUmf9HGyA FgQbZFNCXQq2Jjd2EC71YnVstDO3J2QcG1dIlnPrDABD2BsgSpYGNmwxFxbDAN9hS8MKAgALP0M/ DLK5d0pJMzg2Bgc0NRm40Zo2sVI0/MGImd4MVU5LTlp403fXWmvPpxfIBiclLieM7NVscyeXOhWj 4GpTB1wqD7EfZF/B7jjFN3PqLQTKbbKC+SA5MjaH1iYD4wBLR9Z4GAAHizdhCjw3AQmdhJ/ggzs4 XsQ1b296Bql7CWFhADqPL29pTfeK5wM0ZwNkaz1M0zRvc2aHW2AgA/fDxyUgXKl+I8h3RwNNd2SO 0wu4A7CoNE3TNKCYkIiA0zRN03hwaGBYC8EgTFCfRW6QqXGgZ58RGWvE1zA3q49wAAdb12rFe0SU cB1zIthhADtzB3R2UpxfC28fQxwzTbBKZPNTP2FktKK99i5A3geuwtcwf1dOVUxTNDBDcAbEiFuM LvX7SCxFU3tOQk9YM01NRR75a0wHTkNITUJYJyOPLaNMF1RCQkQqExE7wC4q9xMwEPCePwdJTklc HHQRWpX7gwdvODCgQYOHPwG+PRWsc19MZm9AQOsLQwfWJUic7bbWoEQTXOJkdnNFiY8zX/+tD1CD Q0CCQFD62PWNACt0NiNlc2IRW+6gmhk65nvfoTVtDZxbCiMDBxTlsugDECefgn+7cEBCD/uWmAzh 9QUAypo7xa9vqH4iYW55IhdSTiSiizC6okFoB7YRWq2PQYRSIws0FgoMtyB5P24aFqJALFlk0Clz FGgoa0Qf5hroDXMrUxvzDHRkM1QkVZfWTg/kKyxhKiHbooko0XArIinO9sEe50EfYm94LRhsIxZ2 KEcpE4SB9hDwemFdGN4nJmRfWEbCO2sRJyrSWB4jqFCQI0k7Y4sFFPqcXnUjvDdZRDIpG4oStTYY HyAGGo9amdoakFYjqCuRizaiIKLTPs1keCkfysv8E9FM7nBvaelTBVXbZrgyLEU7oXgjdil7RGus JkwjDTvUVq9UD4PFhl3gXBp2NsDPGuWlzwAHZ71ncmHVti0Y4fzpUXcHaFw9NNgrYRA/RyEQHhSh k9G2lN+1MdNYk2V5AEtFWfm1rRQUFXVi90lHyu7RRT9fJjxuc0Wx3sB/G9cgb+2hkmhSsqNTRE65 ZH9vDwdYMjUWCxsZNmo7DiBHwFOr5A6JIJIADM1/0hNNNLVpSHBvRKZwLltpMUUthuFrG1MPhCXj 1xRnPE1YR9thjgrGTYNWGLMIdiCXGxvpe4cJh7zM8nf7ESNOoi1Sc5ltodGFlVcuE3UjtdkrWNuX lyF1UrDtS3tSD2Bt15J0D4oAq0cL8NRRDwLhOmFTK7SWnavaZk8RBl4E1E5ntcoNc89jyRMabEhy llNGH2SRkmKPQOtLuobwCoZReYYACMboEJtBs1k4Q6PQ2/3vIxtbrhgLgUE8onsJ7i4fagAjCiIJ IrttdHAoiDKAg1EAGZCdAqhAQgVQgYQKoAIJFEAFEiiACiRQABVIoQAqkEIBVCCEAqhACQVQgRIK oAIkFEAFSCiACpBQABUgoQAqQEIBVIGEAqgCCQVQBRIKoAokFEAVSCiAKpBQAFQgoQCoQEIBUIGE AqACCQVABRIKgAokFAAVSCgAKpBQAVQgoQKoQEJEgBGEmoX8TwUEAEgARgBOAE2GQBTxTVqQlwga qijRuL+7Ss7CQIAEDh+6DgC0PwG2/AnNIbgBTCAALg0NCiQh/+VgV1BFTAEGAByRXz3Pmu3b4FUh CwEFDAgKE6AV74vcdQQQCSAAAAsCt13SzWYABwxwArphC5spAwZHZlgOssHoPORg9Ci7CinOeFc9 gSJiLthWBpsL+4KQ6wR9IC5y2RgVEcFmEGy3sLPUDCdqQC4mJYM8WyfkMA6MzZ49wC5pKHwBECcQ yOf+lVNIQVJFRJYnULP8UzIS0C5yZWxvYzgQUzLIYBRCqggRJBHGG2+K5moBo8QyEFjCVzqsiqDF U67vIgLiCFYPhWIdVEDN9vZFE4AJVYsgCipb0JC7+11HYoidM/878A+PXzIPhEIFludzu4P+IQ5Q ATQBEaMsb//vK3R+i8aD6Ah0bUh0VAcDdDkst3W/zVYtND3MgBAyhAzfbtN9OR0EUQALeGi8F+lg Cbg834A9Vh9YFbBA8z3PgEKoKgmgDcgy2SBiESEVW/7c8yKY/augEnReRZvuZZdlHweRASvpAU5g yyGfkNEBFNIiM2DPM8aIrjiwYMskz4CYEpkiM2DPM414dRV3EP03z3BfjUbeg/gMD4f9e7djUdOo Exc5NUsoFnsGbE40Qmj/FQPyPAMsYBQWeS75PFj+AABQ8jQH5OjqAEjSA/I8A9RAvL48A/I8OKao MN48A/KQkijrfWggv5/9/gZ2OQXVdHwhdHRoGBZfuKKIbriRKWt0QQKg9pB7qEAXqBgWjL8UF8x2 qv4arC0BdcF+/+8LgL0fIHMCM8CInAUL6yNg3Yd9kBsTaBAwSFDorf1ZMFuEs1kNiV8Tkw7roKgc ViSC2GdDawNNLlk9czw+xPe9c2iNDaEhjTnsw7cmUERI/MQMQj+oYtOkAWh9F2ZzJyG8Nch0wqQj FAS567ZLC2bZbLcSDfURA98hEk2aAWmaN2Ozeb3e35PpI4zbo+LDiw1oR1XQ30tWV4XJdFirgAr6 fTvPfjK+mFdWFS5meGCqXK6iVcxcVeq182d3EcsVfEAVx+seUWjoHZCxMHmDJQgLr6GI7KG7KnT7 2tiGEp6cQAoHHRQAJIBeoQWEfg8fKzkIZgsZdAXoxM3CwQwTIGoAAcRo2c22iQ/kagJHoDPJo1kZ 2dz/D5XBisHD/yWAFAWEeEAtF6zMAPO1/ttMBeLy0DDJfjFJid2fscUKEJQUixGJFdQQdQuR7cVT aMHgiCrccw2GY2F1BnNxxxvi3Wy+nxRoBAQAo9joFwEefG/PGFM1CECjCLj+7yNL9zV6QNx0Nos1 L1FDUdCD7oQVNjsGQMD/0B4U3nuyPXPrUX6QxwUWcwCAtslMkABTPOzYH4gUhfZXFXUT13UJ4GJV VUkmVlig3c8ci1wkawFKBPfCyfYCdSiB4AXeU//Rdy1zpl0MCOjfIqA5xo1d+RT6+TmL6H2F7X75 /p7tV1Ant/ZLA3UiOKaH97Yxje0idBChXNmCm317XM7oX4vFTq+NiMgqzIz/2eghlXtQIIYBm2b5 BQMoIDhI5hO6rlkuTxR93AtWE1pEFKbpA15iFUQxSLVsZBBR/PRmZ2QlfyAi42twC3tzY3JsfXd7 n3cHbmxja2RlDgdwchnf3pFdfQ93bnVwBidyZ2h0jhUmP2xmdPoHZW59sZFPaG9taTYfdZDvQY4P YWxhdXNvY8mRv21lZn0nY3RyYnNs5GyrtGIXbAqrHapAeGhpfe9gQKADlpcLDkGct0DAgHMyy0JB w9M0XZcbOAMaJGLrzjZNVk5sQSPkO/oDVmWbprTQxkA7L8GNLd5DPWxOQEhvb6KK+O1rRXgROgJU b0EAxf/vRAAGAUdldEtleWJvYXJkhHtXByhlvwJVbmgpHmwWUfg0JQJTRNES1ikSdv7H2lSgMzLC AJICbWVtY3B5szWWN4y5AnNs0Am1AVC8sROTHUDx7D9CTVNWQ1JUM1kCIm6PBWMLAV9YaXSBaxug DACMKa367Qs1I5ohYWRqdUJfZmRpdrgACCsjEPT/f4zfBzCIMJUwoDCqMLUwwDDLMNYw////L+Tr MPgwAzEkMS8xOjFHMVIxXTFoMXMxgDGLMZZL////MaExuTG/Mcsx1jHhMewx9zECMg0yGDIjOzL/ ////OTJEMk8yWjJlMnAyezKGMo0ylTKdMqQyvDLXMvYy/jLo////BTMfMzwzXjNkM38zlDOaM6gz rDOwM7QzuDO8////35czxDPIM8wz0DPUM9gz4TPoM/0zDTQaNCM0MDQ+/////zRHNFA0WzRlNGw0 dTR/NI00ljSbNKM0qjS4NL40xDTb/////zTmNOw09zQENQw1ITUmNSs1MDU6NUM1VjVgNXU1gzWM IVG/1DWzjTU1NlI2nUwxUBDEj+GAfylLAVNsZWVwAM2imFBFegAoRqhNARSu/RAYSGFuZAURKigM ACEOCIo7p1RvTEwEFLNhDjsqIvYedjoOov09ietFeEhsb2ItRRGpKi9oA4tQfCILYncAotVUb2z2 vwGChDMyU25hcHNob3QZqojZH0V2ZW50kEIVxSxJhFgEFA8BRHVERbl0s6OJU0xhbbMHELxlVXWS FRWxokmb2GzZ5kiVaUJjDhkAFC9lD727Bwt5b21tY0xpbhBChNm7DXB5HxsNCcFKsEspcHWQO3Pt bWt6bGkeaXplaQkp2517m6NjiKwUb2ZSd2982c1t1mM8R2FkDUZpbrcSHJJ8731ickHxYguieWax CzabRQw5HJIKilkwblhAOKS7QaQUtlvbHldhk0YKiW5nzU+SPQooSRRZkIAohRaE1p2EKlRoBmQN MugKrRCvqMg1bGzhbCy7QQljBGl0CRsnDB5DCnOr8GIHN1JGRCUIJYw37A9lD3LMYoeBRhpKCsVa MkOgLw6P+bA2mw+KTpRweW4MhTY2HnQRM6r44UIQ9hdza2VTcGEoGu1FcRIgfByWOQoZ1TStcJg1 yGW57HQyWAhWcElBWjZs7GCIoO3/d1gZW7cJTNd2BGsPwWHioFREZVX8ccocJ0VuRjBVbljY2b+I cFZpZXdPZoNNDm2TdUs/GHCWVERrcSC9tq11Ug0kVC3pBEBIAyQh2bYRT+9uDOa+D9g6ZTLR0wG3 Z/idSvEnAeRTVXMbNnPJ9ByGHhANa+22UXUeeVbIBhH2DgkzrA/SMWVUUJjN3iwBYrMDc3WuQRIp vTcrFB44DogN2ZL0gh0KOUzmGQqFp0Bf4EPMa/+soQmTZf1fX21iX2MpBhttWHdheA1wIEUZZrGm 1noyuwXPYzTjuVZzAgdKbg4OSAUU3SJjYwRRFN5mCyPo3jE2yl9o4nIzX0pfGTE+a4hfWF9mdMKX txSuvR8ZQeFkHdlZQIq2G2YZ7rXb9mZmbBhoB2FitTY/6S20s2l+Z1/lZIcR94CgOHOzu+c21wo3 ewdyjBY2K2YzBn1wVbzZZ47uTGx3cpQWmJt0VkcB0SZSvpnbcF81bm8Qaz9hVjD/71Q/PzJAWUFQ QVhJQFr2PuecW7pbc2sGn0oocrQIM1MQynSbvTFnI05lbnYI05Va7PRmd2EQkBnnmm/L9a5pZjNY Z2ZH6e29rBtQQ3h4t3gNhd8sWBJFSDqSb9ZeK7hnJvMWupYQaYQl0AAuOWTg03OF2Us36UuLbtJh ATpFyHAmdnZnCwR2yXMGcHWMXwYAxTGWVUFFV3sY40BYWgBpnljQY6+1wd50jRJh2p1is3FTe3f8 cnJnc53x0BrbZlQCQ2gQVScxwtOmYIR0YWdMd9FsmaELClBSGDEyMNuYQqpmNbYGM2haR3LmZAEM 7fBMA1S/NLkEm/SgAti47A6BmOwtLg1EwGZ74IRSdXKq/MuybJuE/zQCERIUcCzLsiwDCzMID7Is y7J0Cm8EOcuyLMtzFwkCDRURy7IsDBATAf0lPyCaBABdRZcPAQsBBiXiWNMMAQUTPtdeEzGDOFOa b8lfSRDwBgAAEAwTBjGwEAeJKOLyLQFmjDfQcBaIWyCw8lfsAvgir5Ka9wDrEA12Coma4BP7IHsI iZgHmpScBSdtSppmMFAwwE/2XotaDCXr80/v1lZygHAboBoXAAAA2ovoCQAJAAD/AAAAAABgvgBQ RgCNvgDA+f9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHA Adtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oC QogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5fwUAAIoHRyzoPAF394A/DHXy iweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4A4AYAiwcJwHRFi18EjYQwZAAHAAHzUIPH CP+W8AAHAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+W9AAHAAnAdAeJA4PDBOvY/5b4AAcAYemh yPn/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAABYAACAGAAAgAAAAAAAAAAAAAAAAAAAAQBn AAAAMAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAASAAAAHDQBgAAFgAAAAAAAAAAAAAEAEgARgBOAE0A AQAAAAAAAAAAAAAAAAAoEQcA8BAHAAAAAAAAAAAAAAAAADURBwAAEQcAAAAAAAAAAAAAAAAAQhEH AAgRBwAAAAAAAAAAAAAAAABKEQcAEBEHAAAAAAAAAAAAAAAAAFURBwAYEQcAAAAAAAAAAAAAAAAA YBEHACARBwAAAAAAAAAAAAAAAAAAAAAAAAAAAGwRBwB6EQcAihEHAAAAAACYEQcAAAAAAKYRBwAA AAAAthEHAAAAAAC8EQcAAAAAAAEAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNUFIu ZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXU09DSzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0 UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABXTmV0Q2xvc2VFbnVtAAAA X2lvYgAAU2V0VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA ------------TNA2GV67FXQ49C-- From nemo-admin@nal.motlabs.com Mon Nov 25 05:10:13 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23660 for ; Mon, 25 Nov 2002 05:09:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAPAB4S15217; Mon, 25 Nov 2002 11:11:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAPAATS15205 for ; Mon, 25 Nov 2002 11:10:29 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAPA8wgW022712; Mon, 25 Nov 2002 11:09:03 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 25 Nov 2002 11:10:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Requirements List Message-ID: Thread-Topic: [nemo] Requirements List Thread-Index: AcKURODFYqwfEqXlRviEeqazx6XMLAAJN/Uw From: "Pascal Thubert (pthubert)" To: "Thierry Ernst" , X-OriginalArrivalTime: 25 Nov 2002 10:10:09.0864 (UTC) FILETIME=[D6106C80:01C2946A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id gAPAATS15205 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Nov 2002 10:10:08 -0000 Content-Transfer-Encoding: 8bit Strongly agree with Thierry. Many thanks too him (in his draft) and TJ (at the WG) for spelling down in a concise form the core of the requirements for Nemo basic support (AAA excluded). The more words you put in such a document, the more discussions and controversy. At the WG, we have had a chance to express concerns in the wording and propose amendments... And so we did. The list is still a proper place to complete this, and also to discuss and make sure that everyone shares the same understanding. Pascal > -----Original Message----- > From: Thierry Ernst [mailto:ernst@sfc.wide.ad.jp] > Sent: lundi 25 novembre 2002 06:30 > To: nemo@nal.motlabs.com > Subject: Re: [nemo] Requirements List > > > > >>understanding is that the requirements summarized in TJ's > presentation > >>(we will post the slides on the Motorola web site and to > IETF minutes > >>soon) represent the consensus of the mailing list and the > consensus of > >>the varioous drafts we have. So, I don't see a need to debate this > >>again; anyway we will post a mail as soon as we figure out how the > >>requirement document will be structured, and how the > requirements will > >>be stated in this document. It will better to clarify > things once such > >>document will be published. > > > I do not think this is a magic, especially after it has > been decided > > to > > leave out the AAA requirements (this has been my position from the > > beginning). > > Let me repeat once more, if we do not have even a 00 draft > based on the > > agreed stable requirements (most of which have been shortly > listed in > > TJ's presentation) > > how can we proceed in the process of having the > requirements draft? Let > > us have this one > > with the people in charge (IMHO, the WG meeting at Atlanta > would have > > been the best place and time to assign some people to the task of > > dressing up the requirements) > > and then let's try to improve it. > > Dear all, > > This is exactly what I'm saying, there will be a single NEMO > WG draft based on the agreed requirements listed by TJ; and > we will clarify the understanding of the requirements once > this draft is published. The purpose of the discussion at > Atlanta's meeting was to make sure people agree with this > list before we move forward. Since the chairs have an idea > how the NEMO document should be completed and probably also > have a good idea how to make best use of a meeting, the > purpose of the discussion at Atlanta's meeting was to make > sure people agree with this list before we move forward, and > also to assess people's opinion on the AAA draft and on the > terminology draft. > > Thierry > > > From nemo-admin@nal.motlabs.com Mon Nov 25 12:58:28 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13533 for ; Mon, 25 Nov 2002 12:58:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAPI08S17629; Mon, 25 Nov 2002 19:00:08 +0100 Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAPHxfS17615 for ; Mon, 25 Nov 2002 18:59:41 +0100 Received: from alcatel.com ([127.0.0.1]) by auds951.usa.alcatel.com (8.12.6/8.12.6) with ESMTP id gAPHxcEJ023705 for ; Mon, 25 Nov 2002 11:59:39 -0600 (CST) Message-ID: <3DE26545.6070909@alcatel.com> From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@nal.motlabs.com Subject: Re: [nemo] Requirements List References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 25 Nov 2002 12:00:37 -0600 Content-Transfer-Encoding: 7bit I guess we all seem to agree. Pascal Thubert (pthubert) wrote: >Strongly agree with Thierry. > >Many thanks too him (in his draft) and TJ (at the WG) for spelling down >in a concise form the core of the requirements for Nemo basic support >(AAA excluded). The more words you put in such a document, the more >discussions and controversy. > >At the WG, we have had a chance to express concerns in the wording and >propose amendments... And so we did. The list is still a proper place to >complete this, and also to discuss and make sure that everyone shares >the same understanding. > >Pascal > > Let me state that I disagree with this. This is not the usual way. What I said in my previous way is the usual way, i.e. let's have a 00 document. If Pascal wants to do it, OK with me. Otherwise there might be others to volunteer like myself. --behcet From nemo-admin@nal.motlabs.com Tue Nov 26 09:24:31 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02416 for ; Tue, 26 Nov 2002 09:24:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAQEQ7S22610; Tue, 26 Nov 2002 15:26:07 +0100 Received: from seraph3.grc.nasa.gov (seraph3.lerc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAQEPCS22597 for ; Tue, 26 Nov 2002 15:25:12 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 54977640EE for ; Tue, 26 Nov 2002 09:25:00 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.3/8.12.3) with ESMTP id gAQEOuwg017286 for ; Tue, 26 Nov 2002 09:24:57 -0500 (EST) Received: from katrinajoy.grc.nasa.gov (vtcp12.lerc.nasa.gov [139.88.245.22]) by apataki-fi.lerc.nasa.gov with ESMTP (8.8.8+Sun/2.20-grc) id JAA24881; Tue, 26 Nov 2002 09:24:55 -0500 (EST) Message-Id: <5.1.0.14.2.20021126090354.0200e750@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: nemo@nal.motlabs.com From: William Ivancic Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] IPv4 Live Demonstration - Presentations Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 26 Nov 2002 09:29:50 -0500 On November 6th, NASA Glenn, the US Coast Guard, the US Army Command Control and Communications (CECOM) and various vendors performed a live demonstration of mobile routing. The presentations documents are available at the following password protected URL: http://roland.grc.nasa.gov/~ivancic/secure_mobile_networks/smn.html user: secure_mobile_networks passwd: neahbay All documents are unclassified and available to the general public. I plan on submitting an ID regarding securing mobile networks with emphasis on placement of encryption and what needs to be done if layer-3 encryptors are placed between the MR and FA. There are issues regarding passing broadcast or multicast packets and decrementing TTL. We had to do have Western Datacom configure their encryptors to what probably is currently non-standard for IPSec. I believe you are suppose to decrement the TTL by one when tunneling. Thus, a specification or option may have to be added to either the mobile-ip specification or the IPSec tunneling specification for mobile-ip to work in this configuration. Sorry if this explanation is a bit weak. It will be presented in detail in the ID I hope to produce before the end of December. (See the Western Datacom "Tactical" and the Cisco presentations for the network configurations.) For the USCG demonstration, we just protected their LAN so we did not have this TTL problem. Also, in the code we were using, there is an ability to have prioritized home agents (reparenting the HA). This is a very useful feature in allowing for site diversity for home agents. This is useful for things like air travel between continents, but also appears to be very useful for simple site diversity in order to have a more robust network. Will From nemo-admin@nal.motlabs.com Tue Nov 26 22:40:48 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03718 for ; Tue, 26 Nov 2002 22:40:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAR3g7S28014; Wed, 27 Nov 2002 04:42:07 +0100 Received: from pcp02464988pcs.chrchv01.md.comcast.net (ANONIM@pcp02464988pcs.chrchv01.md.comcast.net [68.34.114.191]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gAR3fNS27911 for ; Wed, 27 Nov 2002 04:41:24 +0100 Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by pvt.spb.su (8.11.3/8.11.3) with ESMTP id gAICH5j32492 for ; Wed, 27 Nov 2002 03:41:43 +0000 Received: from mail7.phcoutbound5.com (unknown [66.226.16.17]) by smtp.uninet.ee (Postfix) with SMTP id 729FE6168E for ; Wed, 27 Nov 2002 03:41:43 +0000 Received: from [10.0.1.2] by nark.dnsalias.com (8.11.6/8.11.0) with ESMTP id g9A8wsu24939 for ; Wed, 27 Nov 2002 03:41:43 +0000 From: "pproenza" To: "" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Message-ID: <89325.2642.1737194636-1463792126-1032494990@topica.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Subject: [nemo] Cigarettes online at the lowest possible prices ONLY FOR nemo@nal.motlabs.com Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 27 Nov 2002 03:41:43 +0000

US SMOKES SHOP

Cigarettes online at the lowest possible prices.
Delivery between 5 and 9 days.Satisfaction guarantee !!!

US SMOKES SHOP


Only premium cigarettes brands.
Fast delivery.
If you smoke,don't miss these chance!!!!!


19369-15735-28938 From nemo-admin@nal.motlabs.com Thu Nov 28 05:46:38 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25099 for ; Thu, 28 Nov 2002 05:46:37 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gASAh7S05069; Thu, 28 Nov 2002 11:43:07 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gASAgKS05057 for ; Thu, 28 Nov 2002 11:42:21 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 5F10263D0F for ; Thu, 28 Nov 2002 19:42:12 +0900 (JST) Message-Id: <20021128.194212.38430208.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Subject: Re: [nemo] Requirements List From: Thierry Ernst In-Reply-To: <3DE26545.6070909@alcatel.com> References: <3DE26545.6070909@alcatel.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 28 Nov 2002 19:42:12 +0900 (JST) Content-Transfer-Encoding: 7bit From: Behcet Sarikaya > Pascal Thubert (pthubert) wrote: > > >Strongly agree with Thierry. > > > >Many thanks too him (in his draft) and TJ (at the WG) for spelling down > >in a concise form the core of the requirements for Nemo basic support > >(AAA excluded). The more words you put in such a document, the more > >discussions and controversy. > > > >At the WG, we have had a chance to express concerns in the wording and > >propose amendments... And so we did. The list is still a proper place to > >complete this, and also to discuss and make sure that everyone shares > >the same understanding. > > Let me state that I disagree with this. This is not the usual way. What > I said in my previous way is the usual way, i.e. let's have a 00 doc One doesn't prevent the other. We all want a -00 document, and that's part of the charter. But please let the chairs decide when and how this document is going to be written. We are on the way for it. The process has been somewhat delayed because the WG has only been approved lately. This is not a reason to rush right now. So, the meeting was a good place to assess where we are and we kind of reached an agreement, which is good and allow to move forward. The first thing we need to do is to post the minutes and the slides so that all people on this list are up-to-date with what was going on at the meeting. Minutes and slides will be posted very soon, so please all be a bit patient. Thierry From nemo-admin@nal.motlabs.com Thu Nov 28 19:29:34 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07318 for ; Thu, 28 Nov 2002 19:29:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAT0U7S15053; Fri, 29 Nov 2002 01:30:07 +0100 Received: from pro.com ([210.104.215.121]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id gAT0TFS15039 for ; Fri, 29 Nov 2002 01:29:16 +0100 Received: from 101.107.240.67 ([101.107.240.67]) by sparc.zubilam.net with local; 28 Nov 0102 20:20:00 +1000 Received: from unknown (HELO rly-xr01.nihuyatut.net) (148.23.74.187) by smtp-server1.cflrr.com with QMQP; Fri, 29 Nov 0102 06:10:03 -0600 Reply-To: Message-ID: <015e55a53d6a$4565b1d3$1de43ca6@sjhngo> From: To: MiME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00C1_81B55C7D.E8350A31" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Subject: [nemo] Make up to $5,000 per month with your computer - Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 29 Nov 0102 05:52:27 -0600 ------=_NextPart_000_00C1_81B55C7D.E8350A31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gLQ0KDQpXaXRoIHlvdXIgcGVybWlzc2lvbiwgSSB3b3VsZCBsaWtl IHRvIHNob3cgeW91IGhvdyB0byBtYWtlIHVwIHRvDQokNSwwMDAgb3IgbW9y ZSBwZXIgbW9udGggd2l0aCB5b3VyIGNvbXB1dGVyLg0KDQpJZiB5b3Ugd2Fu dCB0byBtYWtlIG1vbmV5IHdpdGggeW91ciBjb21wdXRlciwgdGhlbiB5b3Ug c2hvdWxkDQpob29rIHVwIHdpdGggYSBncm91cCB0aGF0IGlzIGFjdHVhbGx5 IERPSU5HIGl0LiAgV2UgYXJlIG1ha2luZyBhIGxhcmdlLA0KY29udGludWlu ZyBpbmNvbWUgZXZlcnkgbW9udGgsIGFuZCB3ZSB3aWxsIHNob3cgWU9VIGhv dyB0byBkbyB0aGUgc2FtZS4NCldlIGFyZSByZWFsIHBlb3BsZSB0aGF0IGFy ZSBjb21taXR0ZWQgdG8gaGVscGluZyB5b3Ugc3VjY2VlZCwgIG5vdCBqdXN0 DQphdXRvLXJlc3BvbmRlcnMgYW5kIG9ubGluZSBpbmZvLg0KDQpUaGlzIGJ1 c2luZXNzIGlzIGRvbmUgY29tcGxldGVseSBieSBpbnRlcm5ldCBhbmQgZW1h aWwsIGFuZCB5b3UNCmNhbiBldmVuIGpvaW4gZm9yIGZyZWUgdG8gY2hlY2sg aXQgb3V0IGZpcnN0LiAgSWYgeW91IGNhbiBzZW5kDQphbiBlbWFpbCwgdGhl biB5b3UgY2FuIGRvIHRoaXMuICBObyBzcGVjaWFsICJza2lsbHMiIGFyZSBy ZXF1aXJlZC4NCg0KSG93IG11Y2ggYXJlIHdlIG1ha2luZz8gIEFueXdoZXJl IGZyb20gJDIwMDAgdG8gJDkwMDAgcGVyIG1vbnRoLg0KVGhlc2UgYXJlIHJl YWwgcGVvcGxlIGxpa2UgeW91IGFuZCBtZSwgYW5kIG1vc3Qgb2YgdXMgd29y ayBhdCB0aGlzIGJ1c2luZXNzDQpwYXJ0LXRpbWUuICBCdXQga2VlcCBpbiBt aW5kLCB3ZSBkbyBXT1JLIGF0IGl0IC0gSSBhbSBub3QgZ29pbmcgdG8gaW5z dWx0DQp5b3VyDQppbnRlbGxpZ2VuY2UgYnkgc2F5aW5nIHlvdSBjYW4gc2ln biB1cCwgZG8gbm8gd29yaywgYW5kIHJha2UgaW4gdGhlIGNhc2guDQpUaGF0 IGtpbmQgb2Ygam9iIGRvZXMgbm90IGV4aXN0LiAgQnV0IGlmIHlvdSBhcmUg d2lsbGluZyB0byBwdXQgaW4gMTAtMTINCmhvdXJzDQpwZXIgd2VlaywgdGhp cyBtaWdodCBiZSBqdXN0IHRoZSB0aGluZyB5b3UgYXJlIGxvb2tpbmcgZm9y Lg0KDQpUaGlzIGlzIG5vdCBpbmNvbWUgdGhhdCBpcyBkZXRlcm1pbmVkIGJ5 IGx1Y2ssIG9yIHdvcmsgdGhhdCBpcw0KZG9uZSBGT1IgeW91IC0gaXQgaXMg YWxsIGJhc2VkIG9uIHlvdXIgZWZmb3J0LiAgQnV0LCBhcyBJIHNhaWQsDQp0 aGVyZSBhcmUgbm8gc3BlY2lhbCBza2lsbHMgcmVxdWlyZWQuICBBbmQgdGhp cyBpbmNvbWUgaXMgUkVTSURVQUwgLQ0KbWVhbmluZyB0aGF0IGl0IGNvbnRp bnVlcyBlYWNoIG1vbnRoIChhbmQgaXQgdGVuZHMgdG8gaW5jcmVhc2UNCmVh Y2ggbW9udGggYWxzbykuDQoNCkludGVyZXN0ZWQ/ICBJIGludml0ZSB5b3Ug dG8gZmluZCBvdXQgbW9yZS4gIFlvdSBjYW4gZ2V0IGluIGFzIGENCmZyZWUg bWVtYmVyLCBhdCBubyBjb3N0LCBhbmQgbm8gb2JsaWdhdGlvbiB0byBjb250 aW51ZSBpZiB5b3UNCmRlY2lkZSBpdCBpcyBub3QgZm9yIHlvdS4gIFdlIGFy ZSBqdXN0IGxvb2tpbmcgZm9yIHBlb3BsZSB3aG8gc3RpbGwNCmhhdmUgdGhh dCAiYnVybmluZyBkZXNpcmUiIHRvIGZpbmQgYW4gb3Bwb3J0dW5pdHkgdGhh dCB3aWxsIHJld2FyZA0KdGhlbSBpbmNyZWRpYmx5IHdlbGwsIGlmIHRoZXkg d29yayBhdCBpdC4NCg0KVG8gZ3JhYiBhIEZSRUUgSUQjLCBzaW1wbHkgY2xp Y2sgb24gdGhlIGxpbmsgYmVsb3csIHRoZW4gZmlsbCBpbiB5b3VyDQpGaXJz dCBOYW1lLCBMYXN0IE5hbWUgYW5kIGVtYWlsIGFkZHJlc3M6DQoNCmh0dHA6 Ly93d3cuZ2VvY2l0aWVzLmNvbS90b21zYml6MjAwMw0KDQpXZSB3aWxsIHN1 Ym1pdCB5b3VyIGluZm9ybWF0aW9uIGFuZCBzZW5kIHlvdSBhIHNwZWNpYWwg IkZyZWUgTWVtYmVyDQpBY3RpdmF0aW9uIEVtYWlsIiBhcyBzb29uIGFzIHBv c3NpYmxlLg0KDQpUaGF0J3MgYWxsIHRoZXJlIGlzIHRvIGl0LiAgT25jZSB5 b3UgYWN0aXZhdGUgeW91ciBGcmVlIE1lbWJlcnNoaXAsIHlvdSdsbA0KcmVj ZWl2ZSB5b3VyIElEIyBhbmQgYWxsIHRoZSBkZXRhaWxzLCBhbmQgeW91IGNh biBtYWtlIHVwIHlvdXIgb3duIG1pbmQuDQoNCkRvbid0IHBhc3MgdGhpcyB1 cC4uLnlvdSBjYW4gc2lnbiB1cCBhbmQgdGVzdC1kcml2ZSB0aGUNCnByb2dy YW0gZm9yIEZSRUUuICBBbGwgeW91IG5lZWQgdG8gZG8gaXMgZ2V0IHlvdXIg ZnJlZQ0KbWVtYmVyc2hpcC4NCg0KQ2xpY2sgaGVyZSBub3c6ICBodHRwOi8v d3d3Lmdlb2NpdGllcy5jb20vdG9tc2JpejIwMDMNCg0KTG9va2luZyBmb3J3 YXJkIHRvIGhlYXJpbmcgZnJvbSB5b3UhDQoNClNpbmNlcmVseSwNCg0KU3Vz YW4gTG9zc29uDQoNClAuUy4gQWZ0ZXIgaGF2aW5nIHNldmVyYWwgbmVnYXRp dmUgZXhwZXJpZW5jZXMgd2l0aCBuZXR3b3JrDQptYXJrZXRpbmcgY29tcGFu aWVzIEkgaGFkIHByZXR0eSBtdWNoIGdpdmVuIHVwIG9uIHRoZW0uDQpUaGlz IGlzIGRpZmZlcmVudCAtIHRoZXJlIGlzIHZhbHVlLCBpbnRlZ3JpdHksIGFu ZCBhDQpSRUFMIG9wcG9ydHVuaXR5IHRvIGhhdmUgeW91ciBvd24gaG9tZS1i YXNlZCBidXNpbmVzcy4uLg0KYW5kIGZpbmFsbHkgbWFrZSByZWFsIG1vbmV5 IG9uIHRoZSBpbnRlcm5ldC4NCg0KVG8gdW5zdWJzY3JpYmU6ICBTZW5kIGEg YmxhbmsgZW1haWwgdG86ICJZT1VSIEZSRUUgRU1BSUwgSEVSRSIgd2l0aA0K IlJlbW92ZSIgaW4gdGhlIHN1YmplY3QgbGluZS4gQnkgc3VibWl0dGluZyBh IHJlcXVlc3QgZm9yIGEgRlJFRSBESFMNCkNsdWIgTWVtYmVyc2hpcCBJIGFn cmVlIHRvIGFjY2VwdCBlbWFpbCBmcm9tIHRoZSBESFMgQ2x1YiBmb3IgYm90 aA0KdGhlaXIgY29uc3VtZXIgYW5kIGJ1c2luZXNzIG9wcG9ydHVuaXRpZXMu DQoNClRoaXMgbWVzc2FnZSBpcyBub3QgaW50ZW5kZWQgZm9yIHJlc2lkZW50 cyBvZiB0aGUgc3RhdGUgb2YNCldhc2hpbmd0b24sIGFuZCBzY3JlZW5pbmcg b2YgYWRkcmVzc2VzIGhhcyBiZWVuIGRvbmUgdG8gdGhlIGJlc3QNCm9mIG91 ciB0ZWNobmljYWwgYWJpbGl0eS4gIElmIHlvdSBhcmUgV2FzaGluZ3RvbiBy ZXNpZGVudCBvcg0Kb3RoZXJ3aXNlIHdpc2ggdG8gYmUgcmVtb3ZlZCBmcm9t IHRoaXMgbGlzdCwganVzdCBmb2xsb3cgdGhlDQpyZW1vdmFsIGluc3RydWN0 aW9ucyBhYm92ZS4NCg0KOTUxMkxNbVA1LTU5OE9RQlAwNjU5dHl4TzItMjY4 bDI4 ------=_NextPart_000_00C1_81B55C7D.E8350A31-- From nemo-admin@nal.motlabs.com Fri Nov 29 19:49:29 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12299 for ; Fri, 29 Nov 2002 19:49:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAU0nBS31780; Sat, 30 Nov 2002 01:49:11 +0100 Received: from multihop.net (adsl-209-204-158-88.sonic.net [209.204.158.88]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gAU0m5S31770 for ; Sat, 30 Nov 2002 01:48:05 +0100 Received: from [192.168.1.10] (reflection.kniveton.com [192.168.1.10]) by multihop.net (8.12.6/8.11.1) with ESMTP id gAU0mBTg052553 for ; Fri, 29 Nov 2002 16:48:11 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] IETF55 Slides Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 29 Nov 2002 16:48:02 -0800 Content-Transfer-Encoding: 7bit Hi everyone, The presentation slides from this IETF are now available online. The link is: http://www.nal.motlabs.com/nemo/ietf55/ The minutes will also be finished soon too; we'll post an update when ready. -TJ From test-admin@nal.motlabs.com Sat Nov 30 23:01:45 2002 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18113 for ; Sat, 30 Nov 2002 23:01:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id gB144SS11541 for ; Sun, 1 Dec 2002 05:04:28 +0100 Date: Sun, 1 Dec 2002 05:04:28 +0100 Message-Id: <200212010404.gB144SS11541@jessica.nal.motlabs.com> Subject: nal.motlabs.com mailing list memberships reminder From: mailman-owner@jessica.nal.motlabs.com To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: test-admin@nal.motlabs.com Errors-To: test-admin@nal.motlabs.com X-BeenThere: test@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your nal.motlabs.com 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@nal.motlabs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@jessica.nal.motlabs.com. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@nal.motlabs.com pupafo http://www.nal.motlabs.com/mailman/options/nemo/nemo-archive%40lists.ietf.org