From nemo-bounces@ietf.org Thu Jun 01 11:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp2b-0007x5-FM; Thu, 01 Jun 2006 11:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp2Y-0007Z9-1W for nemo@ietf.org; Thu, 01 Jun 2006 11:24:50 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Floye-0006GV-HX for nemo@ietf.org; Thu, 01 Jun 2006 11:20:49 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 268A72007D7E; Thu, 1 Jun 2006 17:21:06 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09905-10; Thu, 1 Jun 2006 17:21:06 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 13ED620001B6; Thu, 1 Jun 2006 17:21:06 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Deployment Requirements Date: Thu, 1 Jun 2006 17:20:47 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE400873650B45@venus.office> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC023C8D35@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Deployment Requirements thread-index: AcaDB+X6p5SVbZ/ATn2A1w/qtM/cdAAE6XZgAANc3UAAJM0sUABqhzQg From: "Roberto Baldessari" To: "Pascal Thubert (pthubert)" , "Chan-Wah Ng" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nemo@ietf.org, Thierry Ernst , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, >=20 > [Pascal] MRs own Mobile Networks. As MRs form a nested NEMO=20 > dynamically, don't they form a MANET of Mobile Networks?=20 > [Roberto] In my opinion, MRs forming a nested NEMO dynamically is not necessary in every kind of scenario, at least not in the one I'm talking about. Anyway, we will reconsider TD carefully and contact you offline to understand whether it applies to intervehicle scenario of C2C Consortium. For the WG, according to your interest we will keep you informed about C2C activities. A first pubblication will be released by the consortium within a few months. >From NEC side, we are also considering to formalize scenarios and requirements in a draft (but no time schedule yet...). Regards Roberto From nemo-bounces@ietf.org Thu Jun 01 11:49:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpPw-0005wV-At; Thu, 01 Jun 2006 11:49:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpPu-0005wQ-OU for nemo@ietf.org; Thu, 01 Jun 2006 11:48:58 -0400 Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpPu-00008n-7g for nemo@ietf.org; Thu, 01 Jun 2006 11:48:58 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 813955F7; Thu, 1 Jun 2006 17:48:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdPdic5ogpyi; Thu, 1 Jun 2006 17:48:56 +0200 (CEST) Received: from [137.194.160.211] (dhcp160-211.enst.fr [137.194.160.211]) by smtp2.enst.fr (Postfix) with ESMTP id BF2895A4; Thu, 1 Jun 2006 17:48:55 +0200 (CEST) Message-ID: <447F0C65.3060705@enst.fr> Date: Thu, 01 Jun 2006 17:48:53 +0200 From: LIN hai User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: nemo@ietf.org, Roberto.Baldessari@netlab.nec.de References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Subject: [nemo] RE: Deployment Requirements X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org >Message: 1 >Date: Tue, 30 May 2006 09:27:39 +0200 >From: "Roberto Baldessari" >Subject: RE: [nemo] Deployment Requirements >To: "Pascal Thubert (pthubert)" , "Chan-Wah Ng" > >Cc: nemo@ietf.org, Thierry Ernst , Ryuji > Wakikawa >Message-ID: <6D28EBC684A4D94096217AD2FE400873650863@venus.office> >Content-Type: text/plain; charset=3D"us-ascii" > >Hi all, > >I try to summarize answers in one mail. >Please see comments inline. >=20 > > =20 > >>1) we started a similar discussion on the thread called:=20 >>"Distributing the Mobile Prefix in the visited network" last November. >> >>2) I pointed out to Roberto that there is a MANEMO ML. Since=20 >>that thread, no big news on MANEMO; we are still working on=20 >>the Problem statement, and version 03 of Tree Discovery was published: >>http://www.ietf.org/internet-drafts/draft-thubert-tree-discove >>ry-03.txt >> =20 >> > >Thanks Pascal. >I think that at that time I didn't understand that MANEMO targets a >slightly different scenario: > >- In our scenario, we don't focus on nested NEMO (MANET inside a mobile >network) but on MANETs formed by mobile networks. As far as I >understand, MANEMO and TD focus on nested NEMO. Do you see applications >of the TD strategy in the scenario we consider? > >- In our opinion, the adhoc routing should be indipendent from the NEMO >protocol. We assume that a routing protocol takes care of delivering >packets from node A to node B in the adhoc domain, so that node A and >node B are 'logically' on the same link, even if they communicate >through multihop. This can be achieved with various strategies. It is, >maybe, an implementation related concept. Nevertheless, we think it >allows to keep NEMO (or other mobility management approaches) >indipendent from the specific routing protocol of the MANET > > =20 > >>>Specifically why NEMO-BS (i.e. RFC3963) does not meet the=20 >>> =20 >>> >>requirements? >> =20 >> > >NEMO BS, being essentially derived from Mobile IP, is an >infrastructure-based mobility protocol. In intervehicle communications, >the infrastructure access via 802.11 will be rather limited (i.e. urban >areas). It is still not clear whether vehicles will be equipped with >additional interfaces (Wifi, 3+ G etc.). At the moment, and also because >car companies have concerns about costs, we focus on 802.11, which is >the basis of the system for road safety. > >Considering that, what Intervehicle Communication would like to have is: >- global mobility when the infrastructure is available (and NEMO BS >offers already that) >- "RO with infrastructure" >- exchanging packets directly from a vehicle network to another one when >the Infrastructure is not available, or, in other words, "RO without >infrastructure". But still assuming, as I said before, that the two MRs >are "logically" on the same link. > =20 > Hi , I have a question related to the vehicle deployment requirements. In addition to the mentioned requirements, I would like to know if the=20 maintained QoS during handover (from an Access Rout to another) and the=20 resources reservation (along the route between CN and MN) to provide QoS=20 may be among the expected requirements of the vehicle deployment scenario= s? As I work on these topics, I would like to have your feedback. Hai Lin Ecole Nationale Sup=E9rieure des T=E9t=E9communication (ENST)/ /INFRES Department/ /46 rue Barrault, 75634 Paris Cedex, France/ / Tel : +33(0)1.45.81.78.97 Fax : +33(0)1.45.81.31.19 // > =20 > >>>Based on your scenario, I would expect that cars to talk to cars in=20 >>>ad-moc mode, but with in each car a NEMO is formed, being=20 >>> =20 >>> >>using the CAN=20 >> =20 >> >>>protocol, Ethernet or Bluetooth. >>> =20 >>> > >We are not considering how the packets are routed inside the mobile >network. >We don't think that adhoc mode inside the car will be used. This >simplifies a bit the scenario. > > =20 > >>>I think NEMO will be involved when the components within a=20 >>> =20 >>> >>car network=20 >> =20 >> >>>need to talk to (A) another component in the another car, or=20 >>> =20 >>> >>(B) some=20 >> =20 >> >>>other nodes in the global internet (possibly using other=20 >>> =20 >>> >>cars as relay=20 >> =20 >> >>>to the base station). >>> >>>>From the route optimization standpoint, I guess for (A),=20 >>> =20 >>> >>you need some >> =20 >> >>>form intra-nested NEMO optimization. It would be, I imagine,=20 >>>unacceptable to go through the nested tunnels if the communications=20 >>>involves accident prevention signalling, where any extra=20 >>> =20 >>> >>delay would be=20 >> =20 >> >>>fatal. >>> >>>For (B), I suspect you need a form of nested tunnel optimization, or=20 >>>maybe a way to flatten the NEMO. Would a global HA-HA=20 >>> =20 >>> >>solution be of=20 >> =20 >> >>>any help here? >>> =20 >>> > >For (B), as we assume that there is already a routing protocol that >takes care of routing the packets from the vehicle to the infrastructure >point of attachment, we have not considered this kind of solution. >Anyway, global HA-HA is interesting and introduces a Mobile IP Proxy in >the Infrastructure.=20 >We have been working on a slightly different concept with the same name: >essentially running a MIP Proxy in the MR. But there are Ipsec security >issues in this approach that discourage us. > >Roberto=20 > =20 > From nemo-bounces@ietf.org Thu Jun 01 12:06:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flph9-000868-Pg; Thu, 01 Jun 2006 12:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flph8-00085G-C5 for nemo@ietf.org; Thu, 01 Jun 2006 12:06:46 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flph6-0001vG-VD for nemo@ietf.org; Thu, 01 Jun 2006 12:06:46 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k51G6hHv027629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Jun 2006 18:06:44 +0200 Date: Thu, 1 Jun 2006 18:08:11 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RE: Deployment Requirements Message-Id: <20060601180811.437b4839.thierry.ernst@inria.fr> In-Reply-To: <447F0C65.3060705@enst.fr> References: <447F0C65.3060705@enst.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at concorde with ID 447F1093.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k51G6hHv027629 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear Lin, If some people think these are important deployment requirements, I don't see any reason why it should be dismissed.=20 Could you refine this requirement in more technical terms ? Do you mean fast horizontal handovers (this could merely mean to check FMIPv6 is appropriate for mobile routers operating NEMO BS) or vertical handovers ?= =20 For the resource reservation between CN and MNN, do you consider an optimized path, or a path through the HA ?=20 Thierry. > Hi , >=20 > I have a question related to the vehicle deployment requirements. > In addition to the mentioned requirements, I would like to know if the=20 > maintained QoS during handover (from an Access Rout to another) and the= =20 > resources reservation (along the route between CN and MN) to provide Qo= S=20 > may be among the expected requirements of the vehicle deployment scenar= ios? > As I work on these topics, I would like to have your feedback. >=20 > Hai Lin > Ecole Nationale Sup=E9rieure des T=E9t=E9communication (ENST)/ > /INFRES Department/ > /46 rue Barrault, 75634 Paris Cedex, France/ > / > Tel : +33(0)1.45.81.78.97 >=20 > Fax : +33(0)1.45.81.31.19 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Thu Jun 01 12:16:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpqN-00055h-9i; Thu, 01 Jun 2006 12:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpqL-00052R-NC for nemo@ietf.org; Thu, 01 Jun 2006 12:16:17 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpqK-0002fk-B6 for nemo@ietf.org; Thu, 01 Jun 2006 12:16:17 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k51GGFA9028894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jun 2006 18:16:15 +0200 Date: Thu, 1 Jun 2006 18:17:42 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060601181742.6e2252e5.thierry.ernst@inria.fr> In-Reply-To: <6D28EBC684A4D94096217AD2FE400873650B45@venus.office> References: <7892795E1A87F04CADFCCF41FADD00FC023C8D35@xmb-ams-337.emea.cisco.com> <6D28EBC684A4D94096217AD2FE400873650B45@venus.office> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 447F12CF.000 on concorde : j-chkmail score : XX : 5/20 0 X-Miltered: at concorde with ID 447F12CF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear Roberto, Thank you for this very useful feedback. I'm glad to hear that people from the C2C are monitoring this list. What we would expect from an organization such as C2C is a list of requirements sent to the NEMO WG as an input. Of course, the list of requirements may probably cover other IETF WGs, so it would serve as an input to the entire Internet Areaf of the IETF. Of course, if there are specific NEMO requirements, this would be even better, but I suspect that real deployment will require work not only in the NEMO WG. Ideally, we would receive similar input from other groups/organizations working on IPv6 communications for intelligent systems transportations (e.g. ISO, CVIS) Then, with we could discuss this list on this mailing list, and check with the aviation industry and other industries what are the commonalities. If we receive input by the next IETF (in the form of a internet-draft would be nice, but is not mandatory), we could have this topic discussed at length during our NEMO slot. Thierry. On Thu, 1 Jun 2006 17:20:47 +0200 "Roberto Baldessari" wrote: > Hi, > > > > > [Pascal] MRs own Mobile Networks. As MRs form a nested NEMO > > dynamically, don't they form a MANET of Mobile Networks? > > > > [Roberto] In my opinion, MRs forming a nested NEMO dynamically is not > necessary in every kind of scenario, at least not in the one I'm talking > about. > Anyway, we will reconsider TD carefully and contact you offline to > understand whether it applies to intervehicle scenario of C2C > Consortium. > > For the WG, according to your interest we will keep you informed about > C2C activities. > A first pubblication will be released by the consortium within a few > months. > >From NEC side, we are also considering to formalize scenarios and > requirements in a draft (but no time schedule yet...). > > Regards > > Roberto > > -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Thu Jun 01 12:22:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpwH-000796-4m; Thu, 01 Jun 2006 12:22:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpwG-000791-Ip for nemo@ietf.org; Thu, 01 Jun 2006 12:22:24 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpwG-00038i-54 for nemo@ietf.org; Thu, 01 Jun 2006 12:22:24 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k51GMHZU029682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jun 2006 18:22:17 +0200 Date: Thu, 1 Jun 2006 18:23:44 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060601182344.3cb5219b.thierry.ernst@inria.fr> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC023C8D35@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC023C8D35@xmb-ams-337.emea.cisco.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 447F1439.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Pascal, The scenario you describe is one potential scenario (and also one potential solution), but there exist others. I see at least 2 classes: - A MANET formed of NEMO nodes - A NEMO formed of MANET nodes Nesting them is one (possibly good) solution. Depending on the issues, it may fall into what you define as MANEMO, but I'm not sure most people on this list who follow the discussion understand what MANEMO is. Thierry. On Tue, 30 May 2006 10:05:49 +0200 "Pascal Thubert \(pthubert\)" wrote: > >> 1) we started a similar discussion on the thread called: > >> "Distributing the Mobile Prefix in the visited network" last > November. > >> > >> 2) I pointed out to Roberto that there is a MANEMO ML. Since > >> that thread, no big news on MANEMO; we are still working on > >> the Problem statement, and version 03 of Tree Discovery was > published: > >> http://www.ietf.org/internet-drafts/draft-thubert-tree-discove > >> ry-03.txt > > > >Thanks Pascal. > > [Pascal] Hi Roberto > > >I think that at that time I didn't understand that MANEMO targets a > >slightly different scenario: > >- In our scenario, we don't focus on nested NEMO (MANET inside a mobile > >network) but on MANETs formed by mobile networks. As far as I > >understand, MANEMO and TD focus on nested NEMO. Do you see applications > >of the TD strategy in the scenario we consider? > > [Pascal] MRs own Mobile Networks. As MRs form a nested NEMO dynamically, > don't they form a MANET of Mobile Networks? I'm sorry I fail to see the > distinction. Could you please elaborate? > Please note that when routers move together as a solid, this is a single > NEMO not a nested one. > > >- In our opinion, the adhoc routing should be indipendent from the NEMO > >protocol. We assume that a routing protocol takes care of delivering > >packets from node A to node B in the adhoc domain, so that node A and > >node B are 'logically' on the same link, even if they communicate > >through multihop. This can be achieved with various strategies. It is, > >maybe, an implementation related concept. Nevertheless, we think it > >allows to keep NEMO (or other mobility management approaches) > >indipendent from the specific routing protocol of the MANET > > [Pascal] Using a number of routing protocols is a usual thing. At the > extreme, NEMO will inject a default route in the RIB while MANET will > inject host routes. In fact, there is a fuzzy zone where both a MANET > and NEMO-RO can inject prefixes and potentially cause the conflict. The > redistribution rules will take care of the precedence in such a case, > based on security policies and costs. > > Then again, I'm not sure what you mean by independent. It is a single > router and sharing the RIB is a form of interaction. MANET can provide a > structure to the nested NEMO (like TD does) and find the default route > to the Internet so that MRs can bind Home over one another. MANET can > even locate a HA for NEMO in the case of a Mobile Home. > > IMHO, there is value in understanding such interactions. The interaction > between TD and RRH for instance, is a proof of such a value. This > enables to design a simple MANET that provides for the nested NEMO > needs. As a result, the MR gets both local and global routing integrated > in its RIB. > > This is the MANEMO concept, at the end of the day. > > What do you think? > > Pascal > > -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Thu Jun 01 20:25:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlxU5-0002Mf-4N; Thu, 01 Jun 2006 20:25:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlxU3-0002LG-94 for nemo@ietf.org; Thu, 01 Jun 2006 20:25:47 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlxU1-00088k-U2 for nemo@ietf.org; Thu, 01 Jun 2006 20:25:47 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id RAA14615; Thu, 1 Jun 2006 17:25:35 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k520PY314333; Thu, 1 Jun 2006 19:25:34 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 17:25:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [nemo] RE: Deployment Requirements Date: Thu, 1 Jun 2006 17:25:32 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21C1B6@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <20060601180811.437b4839.thierry.ernst@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] RE: Deployment Requirements Thread-Index: AcaFlXIC5YdGsAAiT3+/WKW2Rt4TtgARUNaA From: "Davis, Terry L" To: "Thierry Ernst" , X-OriginalArrivalTime: 02 Jun 2006 00:25:32.0282 (UTC) FILETIME=[0F02EDA0:01C685DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Lin When we get the first draft of the aviation industry requirements in; you will see some of this. I am hoping to have it by Montreal. Take care Terry Davis Boeing Commercial Airplanes > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Thursday, June 01, 2006 9:08 AM > To: nemo@ietf.org > Subject: Re: [nemo] RE: Deployment Requirements > > > Dear Lin, > > If some people think these are important deployment requirements, I > don't see any reason why it should be dismissed. > > Could you refine this requirement in more technical terms ? Do you mean > fast horizontal handovers (this could merely mean to check FMIPv6 is > appropriate for mobile routers operating NEMO BS) or vertical handovers ? > > For the resource reservation between CN and MNN, do you consider an > optimized path, or a path through the HA ? > > Thierry. > > > > Hi , > > > > I have a question related to the vehicle deployment requirements. > > In addition to the mentioned requirements, I would like to know if the > > maintained QoS during handover (from an Access Rout to another) and the > > resources reservation (along the route between CN and MN) to provide QoS > > may be among the expected requirements of the vehicle deployment > scenarios? > > As I work on these topics, I would like to have your feedback. > > > > Hai Lin > > Ecole Nationale Sup駻ieure des T騁馗ommunication (ENST)/ > > /INFRES Department/ > > /46 rue Barrault, 75634 Paris Cedex, France/ > > / > > Tel : +33(0)1.45.81.78.97 > > > > Fax : +33(0)1.45.81.31.19 > > > > > > -- > Thierry ERNST, PhD > INRIA Rocquencourt Project-Team IMARA > +33 1 39 63 59 30 > From nemo-bounces@ietf.org Fri Jun 02 06:53:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7Gv-0000Dj-4R; Fri, 02 Jun 2006 06:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7Gs-0008VR-VV for nemo@ietf.org; Fri, 02 Jun 2006 06:52:50 -0400 Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm7Gr-0008J1-N0 for nemo@ietf.org; Fri, 02 Jun 2006 06:52:50 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id ED181260; Fri, 2 Jun 2006 12:52:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObFwtpPNVZVI; Fri, 2 Jun 2006 12:52:48 +0200 (CEST) Received: from [137.194.160.211] (dhcp160-211.enst.fr [137.194.160.211]) by smtp2.enst.fr (Postfix) with ESMTP id 1F2FE24D; Fri, 2 Jun 2006 12:52:48 +0200 (CEST) Message-ID: <4480187D.6000301@enst.fr> Date: Fri, 02 Jun 2006 12:52:45 +0200 From: LIN hai User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: thierry.ernst@inria.fr, nemo@ietf.org References: <44800F31.6040004@enst.fr> <4480121B.6080407@enst.fr> <44801485.30803@enst.fr> In-Reply-To: <44801485.30803@enst.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [nemo] RE: Deployment Requirements X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear Ernst, > Hi the.... > > If some people think these are important deployment requirements, I > don't see any reason why it should be dismissed. > Could you refine this requirement in more technical terms ? Do you mean > fast horizontal handovers (this could merely mean to check FMIPv6 is > appropriate for mobile routers operating NEMO BS) or vertical handovers ? In our work, we focus on horizontal handover but we think also vertical handover can be investigated. The aim of our work is to decrease the packet loss and delay during handover by taking benefits from the NEMO architecture (multiple MRs can be located in a mobile network). We also intend to enhance the handover performance for nested mobile networks. > For the resource reservation between CN and MNN, do you consider an > optimized path, or a path through the HA ? We consider a path through the HA. We propose to make use of the common route between MR and HA to ensure a scalable resource reservation based on the aggregation of per-flow reservations. From nemo-bounces@ietf.org Mon Jun 05 20:57:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPsu-00008x-Vq; Mon, 05 Jun 2006 20:57:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnPst-00008s-Gm for nemo@ietf.org; Mon, 05 Jun 2006 20:57:27 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnPss-0002lv-3p for nemo@ietf.org; Mon, 05 Jun 2006 20:57:27 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k560vPTn025942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Jun 2006 17:57:25 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k560vODX008345 for ; Mon, 5 Jun 2006 17:57:25 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 17:57:24 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68904.2C6F70E5" Date: Mon, 5 Jun 2006 17:57:19 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002D30A43@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEMOv4 extension I-Ds Thread-Index: AcaJBCmOXmG2e1ufTGCgUZZp1rnkkA== From: "Tsirtsis, George" To: X-OriginalArrivalTime: 06 Jun 2006 00:57:24.0338 (UTC) FILETIME=[2C568520:01C68904] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [nemo] NEMOv4 extension I-Ds X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C68904.2C6F70E5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 The following I-Ds just appeared on the IETF directory: =20 "FA extensions to NEMOv4 Base"=20 http://www.ietf.org/internet-drafts/draft-tsirtsis-nemov4-fa-00.txt =20 "Dynamic Prefix Allocation for NEMOv4" http://www.ietf.org/internet-drafts/draft-tsirtsis-nemov4-dynamic-00.txt =20 Comments welcome George ------_=_NextPart_001_01C68904.2C6F70E5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

The following I-Ds just appeared on the IETF directory:

 

“FA extensions to NEMOv4 Base” =

http://www.ietf.org/internet-drafts/draft-tsirtsis-nemov4-fa-00.txt

 

“Dynamic Prefix Allocation for = NEMOv4”

http://www.ietf.org/internet-drafts/draft-tsirtsis-nemov4-dynami= c-00.txt

 

Comments welcome

George

------_=_NextPart_001_01C68904.2C6F70E5-- From nemo-bounces@ietf.org Wed Jun 14 06:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSLq-0007ZL-Ni; Wed, 14 Jun 2006 06:11:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSLo-0007XP-Ug for nemo@ietf.org; Wed, 14 Jun 2006 06:11:52 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqSLn-0002eK-2t for nemo@ietf.org; Wed, 14 Jun 2006 06:11:52 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0U00JY3I3UMG@szxga02-in.huawei.com> for nemo@ietf.org; Wed, 14 Jun 2006 18:21:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0U00HMYI3U64@szxga02-in.huawei.com> for nemo@ietf.org; Wed, 14 Jun 2006 18:21:30 +0800 (CST) Received: from y52774 ([10.164.44.184]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0U005YSHUW3J@szxml04-in.huawei.com> for nemo@ietf.org; Wed, 14 Jun 2006 18:16:16 +0800 (CST) Date: Wed, 14 Jun 2006 18:05:33 +0800 From: Michael Ye Subject: [NEMO]:draft-ietf-nemo-terminology-05 To: nemo@ietf.org Message-id: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, In section 2.1, the term "Mobile Network " is An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. I think NEMO should refer to network mobilily. But in this draft , its abbreviation of Mobile Network is NEMO.I am not sure if it is right. BR Michael Ye From nemo-bounces@ietf.org Wed Jun 14 06:30:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSdR-0005jK-Rx; Wed, 14 Jun 2006 06:30:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqSdQ-0005jD-V5 for nemo@ietf.org; Wed, 14 Jun 2006 06:30:04 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqSdP-0004O9-H5 for nemo@ietf.org; Wed, 14 Jun 2006 06:30:04 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 98206212C5D; Wed, 14 Jun 2006 13:30:02 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 602F9212C4A; Wed, 14 Jun 2006 13:30:02 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 25D3EBDC40; Wed, 14 Jun 2006 13:30:02 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id E3BE8BDC38; Wed, 14 Jun 2006 13:30:01 +0300 (EEST) In-Reply-To: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> References: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05 Date: Wed, 14 Jun 2006 13:30:00 +0300 To: Michael Ye X-Mailer: Apple Mail (2.624) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Michael, in page 3 of the aforementioned draft you can find: Note that the abbreviation NEMO stands for either "a NEtwork that is MObile" or "NEtwork MObility". The former (see Section 2.1) is used as a noun, e.g. "a NEMO" meaning "a mobile network". The latter = (see Section 7) refers to the concept of "network mobility" as in "NEMO Basic Support" and is also the working group's name. regards, marcelo El 14/06/2006, a las 13:05, Michael Ye escribi=F3: > > Hi, > In section 2.1, the term "Mobile Network " is An entire network, > moving as a unit, which dynamically changes its point of attachment to > the Internet and thus its reachability in the topology. I think NEMO > should refer to network mobilily. But in this draft , its abbreviation > of Mobile Network is NEMO.I am not sure if it is right. > BR > Michael Ye > > > > > From nemo-bounces@ietf.org Wed Jun 14 07:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTEN-0008Qd-7v; Wed, 14 Jun 2006 07:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqTEL-0008QW-BW for nemo@ietf.org; Wed, 14 Jun 2006 07:08:13 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqTEI-0006tV-UL for nemo@ietf.org; Wed, 14 Jun 2006 07:08:13 -0400 Received: from iseran-2.local (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k5EB85eG010549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jun 2006 13:08:06 +0200 Date: Wed, 14 Jun 2006 13:08:11 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05 Message-Id: <20060614130811.673e2dc3.thierry.ernst@inria.fr> In-Reply-To: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> References: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 448FEE15.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org If you read the section that says what is the meaning of NEMO, doesn't it clarify your concern ? NEMO has 2 meanings; 1. used as a noun it means a NEtwork that is MOving), i.e. the same as the definition below. So, one can either write "a NEMO" or "a mobile network", but we recommend the use of "a NEMO" as it avoids confusion with the other meaning of a mobile network in the cellular context. 2. used as an adjective, it means "network mobility", i.e. the concept. Hope that helps, Thierry On Wed, 14 Jun 2006 18:05:33 +0800 Michael Ye wrote: > > Hi, > In section 2.1, the term "Mobile Network " is An entire network, > moving as a unit, which dynamically changes its point of attachment to > the Internet and thus its reachability in the topology. I think NEMO > should refer to network mobilily. But in this draft , its abbreviation > of Mobile Network is NEMO.I am not sure if it is right. > BR > Michael Ye > > > > > -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Thu Jun 15 03:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmbx-0004W8-V2; Thu, 15 Jun 2006 03:49:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmbx-0004Va-13 for nemo@ietf.org; Thu, 15 Jun 2006 03:49:53 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqmZH-0001l6-Ss for nemo@ietf.org; Thu, 15 Jun 2006 03:47:09 -0400 Received: (qmail 2288 invoked from network); 15 Jun 2006 16:40:25 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 15 Jun 2006 16:40:25 +0900 To: nemo@ietf.org From: "K.Kawaguchi" Message-Id: <200606151640.HJD39566.VHLJBBXU@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 15 Jun 2006 16:40:23 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [nemo] MR received the HAAD Reply (R flag=0) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, I have a question about RFC3963 section 5.3, 7.2. The HAAD Reply indicates that the MR Support (R) Flag is 0 and the list of HA Addresses include many HAs. How to process the Mobile Prefix Registration when MR received the HAAD Reply. I assumed the following processing. Is there the correct one? Or, another one? 1. MR tries the Mobile Prefix Registration to HAs in order of list of HA Addresses. 2. Almost same as above 1. But MR skips the HA that sent the HAAD Reply. 3. MR send the HAAD Requiest again until finding NEMO-HA. 4. MR doesn't try the Mobile Prefix Registration. 5. In fact, there are no matter since this situation is avoided by the following some solution. eg, - MIP Home Link and NEMO Home Link should be separated. - If MIP Home Link and NEMO Home Link are the same link. - It should be configure to reply by NEMO-HA rather than by MIP-HA. (The HAAD Reply function of MIP-HA isn't enabled.) - Even if HA don't support MR, HA should support the RFC3963. (This MIP-HA supports the RFC3963. MIP-HA makes the (R) flag 1 and the list of HA Addresses except for MIP-HA.) Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp From nemo-bounces@ietf.org Thu Jun 15 09:54:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsIm-0007Iu-Nc; Thu, 15 Jun 2006 09:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqsIl-0007Ip-A7 for nemo@ietf.org; Thu, 15 Jun 2006 09:54:27 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqsIj-00005D-Oz for nemo@ietf.org; Thu, 15 Jun 2006 09:54:27 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0W001BNMAFXU@szxga01-in.huawei.com> for nemo@ietf.org; Thu, 15 Jun 2006 21:47:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0W00B7KMAE41@szxga01-in.huawei.com> for nemo@ietf.org; Thu, 15 Jun 2006 21:47:03 +0800 (CST) Received: from h50541 ([10.164.45.206]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0W00FAKL50B1@szxml04-in.huawei.com> for nemo@ietf.org; Thu, 15 Jun 2006 21:22:14 +0800 (CST) Date: Thu, 15 Jun 2006 21:11:35 +0800 From: Andy Huang Subject: Re: [nemo] MR received the HAAD Reply (R flag=0) To: "K.Kawaguchi" , nemo@ietf.org Message-id: <027f01c6907d$3ae7cf60$ce2da40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200606151640.HJD39566.VHLJBBXU@ysknet.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org According to RFC3963, it mean that there is no HA which can support MR on the home link. And I think it's useless for MR to get MIP-HA list from the DHAAD reply when R Flag in the packet is 0. ----- Original Message ----- From: "K.Kawaguchi" To: Sent: Thursday, June 15, 2006 3:40 PM Subject: [nemo] MR received the HAAD Reply (R flag=0) > Hi, > > I have a question about RFC3963 section 5.3, 7.2. > > The HAAD Reply indicates that the MR Support (R) Flag is 0 > and the list of HA Addresses include many HAs. > How to process the Mobile Prefix Registration when MR received > the HAAD Reply. > > I assumed the following processing. > Is there the correct one? Or, another one? > > 1. MR tries the Mobile Prefix Registration to HAs in order > of list of HA Addresses. > 2. Almost same as above 1. But MR skips the HA that sent the > HAAD Reply. > 3. MR send the HAAD Requiest again until finding NEMO-HA. > 4. MR doesn't try the Mobile Prefix Registration. > 5. In fact, there are no matter since this situation is avoided > by the following some solution. > eg, > - MIP Home Link and NEMO Home Link should be separated. > - If MIP Home Link and NEMO Home Link are the same link. > - It should be configure to reply by NEMO-HA rather than by MIP-HA. > (The HAAD Reply function of MIP-HA isn't enabled.) > - Even if HA don't support MR, HA should support the RFC3963. > (This MIP-HA supports the RFC3963. MIP-HA makes the (R) flag 1 > and the list of HA Addresses except for MIP-HA.) > > > Best regards > --- > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp > > Best regards > --- > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp > > > From nemo-bounces@ietf.org Thu Jun 15 11:55:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquBz-0001FH-5y; Thu, 15 Jun 2006 11:55:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FquBs-00017X-Ef for nemo@ietf.org; Thu, 15 Jun 2006 11:55:28 -0400 Received: from isis.lip6.fr ([132.227.60.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqtz2-0003YO-Uq for nemo@ietf.org; Thu, 15 Jun 2006 11:42:14 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.13.6/jtpda-5.4+mv) with ESMTP id k5FFgC89022633 ; Thu, 15 Jun 2006 17:42:12 +0200 X-pt: isis.lip6.fr Received: from [10.0.2.4] (hoori [132.227.111.221]) by tibre.lip6.fr (8.13.3p0/8.13.3) with ESMTP id k5FFhxIB015848; Thu, 15 Jun 2006 17:44:00 +0200 (MEST) In-Reply-To: <20060614130811.673e2dc3.thierry.ernst@inria.fr> References: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> <20060614130811.673e2dc3.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <01F11131-B683-4FBC-9FC5-D3BD672EA216@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05 Date: Thu, 15 Jun 2006 17:41:40 +0200 To: Thierry Ernst X-Mailer: Apple Mail (2.750) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (isis.lip6.fr [132.227.60.2]); Thu, 15 Jun 2006 17:42:12 +0200 (CEST) X-Scanned-By: isis.lip6.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Thierry Isn't it confusable?? I still don't like to use a NEMO as a mobile network. And only few people use this abbreviation... ryuji On 2006/06/14, at 13:08, Thierry Ernst wrote: > > > If you read the section that says what is the meaning of NEMO, doesn't > it clarify your concern ? > > NEMO has 2 meanings; > > 1. used as a noun it means a NEtwork that is MOving), i.e. the same as > the definition below. So, one can either write "a NEMO" or "a mobile > network", but we recommend the use of "a NEMO" as it avoids confusion > with the other meaning of a mobile network in the cellular context. > > 2. used as an adjective, it means "network mobility", i.e. the > concept. > > Hope that helps, > Thierry > > > > > On Wed, 14 Jun 2006 18:05:33 +0800 > Michael Ye wrote: > >> >> Hi, >> In section 2.1, the term "Mobile Network " is An entire network, >> moving as a unit, which dynamically changes its point of >> attachment to >> the Internet and thus its reachability in the topology. I think NEMO >> should refer to network mobilily. But in this draft , its >> abbreviation >> of Mobile Network is NEMO.I am not sure if it is right. >> BR >> Michael Ye >> >> >> >> >> > > > -- > Thierry ERNST, PhD > INRIA Rocquencourt Project-Team IMARA > +33 1 39 63 59 30 (office) > From nemo-bounces@ietf.org Thu Jun 15 13:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvGF-0005rX-BL; Thu, 15 Jun 2006 13:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqvGD-0005rS-EM for nemo@ietf.org; Thu, 15 Jun 2006 13:04:01 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqvGC-0003yy-6X for nemo@ietf.org; Thu, 15 Jun 2006 13:04:01 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5FH3vSn028752; Thu, 15 Jun 2006 10:03:59 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5FH3uqY016468; Thu, 15 Jun 2006 12:03:56 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 36394865980; Thu, 15 Jun 2006 19:03:56 +0200 (CEST) Message-ID: <449192FB.9050004@motorola.com> Date: Thu, 15 Jun 2006 19:03:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05 References: <000001c68f9a$167e2860$b82ca40a@china.huawei.com> <20060614130811.673e2dc3.thierry.ernst@inria.fr> <01F11131-B683-4FBC-9FC5-D3BD672EA216@sfc.wide.ad.jp> In-Reply-To: <01F11131-B683-4FBC-9FC5-D3BD672EA216@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > Hi Thierry > > Isn't it confusable?? I still don't like to use a NEMO as a mobile > network. And only few people use this abbreviation... The use of NEMO as object "NEtwork in MOvement" is confusing to me too. I prefer the use as concept "NEtwork MObility" (which is also a noun btw, not an abjective :-) Alex > > ryuji > > On 2006/06/14, at 13:08, Thierry Ernst wrote: > >> >> >> If you read the section that says what is the meaning of NEMO, >> doesn't it clarify your concern ? >> >> NEMO has 2 meanings; >> >> 1. used as a noun it means a NEtwork that is MOving), i.e. the same >> as the definition below. So, one can either write "a NEMO" or "a >> mobile network", but we recommend the use of "a NEMO" as it avoids >> confusion with the other meaning of a mobile network in the >> cellular context. >> >> 2. used as an adjective, it means "network mobility", i.e. the >> concept. >> >> Hope that helps, Thierry >> >> >> >> >> On Wed, 14 Jun 2006 18:05:33 +0800 Michael Ye >> wrote: >> >>> >>> Hi, In section 2.1, the term "Mobile Network " is An entire >>> network, moving as a unit, which dynamically changes its point of >>> attachment to the Internet and thus its reachability in the >>> topology. I think NEMO should refer to network mobilily. But in >>> this draft , its abbreviation of Mobile Network is NEMO.I am not >>> sure if it is right. BR Michael Ye >>> >>> >>> >>> >>> >> >> >> --Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 >> 63 59 30 (office) >> > > From nemo-bounces@ietf.org Thu Jun 15 17:02:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyzM-0000LX-Al; Thu, 15 Jun 2006 17:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqyzL-0000LS-04 for nemo@ietf.org; Thu, 15 Jun 2006 17:02:51 -0400 Received: from web60316.mail.yahoo.com ([209.73.178.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FqyzJ-0003ZY-LU for nemo@ietf.org; Thu, 15 Jun 2006 17:02:50 -0400 Received: (qmail 8045 invoked by uid 60001); 15 Jun 2006 21:02:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=45E3QftxHiPhCtmjIOaSmVVNupwpENLkQv4Q52JeNv22TirhDaztGncENR4GDdT35pqZ7BunW7NR1MgQMsKPFVXwdEPcR5CbSKV7usPZpJmnu7HPUVgc1b0hPvPYj8z1SaAe71v91OdL3oqMPBK65VFNz888a80wwTme07P0XX4= ; Message-ID: <20060615210249.8043.qmail@web60316.mail.yahoo.com> Received: from [12.129.211.52] by web60316.mail.yahoo.com via HTTP; Thu, 15 Jun 2006 14:02:49 PDT Date: Thu, 15 Jun 2006 14:02:49 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05 To: Alexandru Petrescu , Ryuji Wakikawa In-Reply-To: <449192FB.9050004@motorola.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-270014862-1150405369=:7948" X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --0-270014862-1150405369=:7948 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Alexandru Petrescu To: Ryuji Wakikawa Cc: nemo@ietf.org; Thierry Ernst Sent: Thursday, June 15, 2006 12:03:55 PM Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05 Ryuji Wakikawa wrote: > Hi Thierry > > Isn't it confusable?? I still don't like to use a NEMO as a mobile > network. And only few people use this abbreviation... The use of NEMO as object "NEtwork in MOvement" is confusing to me too. I prefer the use as concept "NEtwork MObility" (which is also a noun btw, not an abjective :-) Alex >>This WG's original name was monet, short for MObile NETwork, later on nemo was >>adopted and I think "NEtwork in MOvement" was used because it meant like MObile NETwork. >> >>Behcet > > ryuji > > On 2006/06/14, at 13:08, Thierry Ernst wrote: > >> >> >> If you read the section that says what is the meaning of NEMO, >> doesn't it clarify your concern ? >> >> NEMO has 2 meanings; >> >> 1. used as a noun it means a NEtwork that is MOving), i.e. the same >> as the definition below. So, one can either write "a NEMO" or "a >> mobile network", but we recommend the use of "a NEMO" as it avoids >> confusion with the other meaning of a mobile network in the >> cellular context. >> >> 2. used as an adjective, it means "network mobility", i.e. the >> concept. >> >> Hope that helps, Thierry >> >> >> >> >> On Wed, 14 Jun 2006 18:05:33 +0800 Michael Ye >> wrote: >> >>> >>> Hi, In section 2.1, the term "Mobile Network " is An entire >>> network, moving as a unit, which dynamically changes its point of >>> attachment to the Internet and thus its reachability in the >>> topology. I think NEMO should refer to network mobilily. But in >>> this draft , its abbreviation of Mobile Network is NEMO.I am not >>> sure if it is right. BR Michael Ye >>> >>> >>> >>> >>> >> >> >> --Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 >> 63 59 30 (office) >> > > --0-270014862-1150405369=:7948 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
To: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
Cc: nemo@ietf.org; Thierry Ernst <thierry.ernst@inria.fr>
Sent: Thursday, June 15, 2006 12:03:55 PM
Subject: Re: [NEMO]:draft-ietf-nemo-terminology-05

Ryuji Wakikawa wrote:
> Hi Thierry
>
> Isn't it confusable?? I still don't like to use a NEMO as a mobile
> network. And only few people use this abbreviation...

The use of NEMO as object "NEtwork in MOvement" is confusing to me too.
  I prefer the use as concept "NEtwork MObility" (which is also a noun
btw, not an abjective :-)

Alex

>>This WG's original name was monet, short for MObile NETwork, later on nemo was
>>adopted and I think "NEtwork in MOvement" was used because it meant like MObile NETwork.
>>
>>Behcet



>
> ryuji
>
> On 2006/06/14, at 13:08, Thierry Ernst wrote:
>
>>
>>
>> If you read the section that says what is the meaning of NEMO,
>> doesn't it clarify your concern ?
>>
>> NEMO has 2 meanings;
>>
>> 1. used as a noun it means a NEtwork that is MOving), i.e. the same
>> as the definition below. So, one can either write "a NEMO" or "a
>> mobile network", but we recommend the use of "a NEMO" as it avoids
>> confusion with the other meaning of a mobile network in the
>> cellular context.
>>
>> 2. used as an adjective, it means "network mobility", i.e. the
>> concept.
>>
>> Hope that helps, Thierry
>>
>>
>>
>>
>> On Wed, 14 Jun 2006 18:05:33 +0800 Michael Ye
>> <yechengping@huawei.com> wrote:
>>
>>>
>>> Hi, In section 2.1, the term "Mobile Network " is An entire
>>> network, moving as a unit, which dynamically changes its point of
>>> attachment to the Internet and thus its reachability in the
>>> topology. I think NEMO should refer to network mobilily. But in
>>> this draft , its abbreviation of  Mobile Network is NEMO.I am not
>>> sure if it is right. BR Michael Ye
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39
>> 63 59 30 (office)
>>
>
>



--0-270014862-1150405369=:7948-- From nemo-bounces@ietf.org Thu Jun 15 20:36:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2KN-0004Zw-7w; Thu, 15 Jun 2006 20:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2KM-0004Zr-JQ for nemo@ietf.org; Thu, 15 Jun 2006 20:36:46 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fr2KK-0001pJ-UV for nemo@ietf.org; Thu, 15 Jun 2006 20:36:46 -0400 Received: (qmail 2527 invoked from network); 16 Jun 2006 09:36:43 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 16 Jun 2006 09:36:43 +0900 To: hpanda@huawei.com, nemo@ietf.org Subject: Re: [nemo] MR received the HAAD Reply (R flag=0) From: "K.Kawaguchi" References: <200606151640.HJD39566.VHLJBBXU@ysknet.co.jp> <027f01c6907d$3ae7cf60$ce2da40a@china.huawei.com> In-Reply-To: <027f01c6907d$3ae7cf60$ce2da40a@china.huawei.com> Message-Id: <200606160936.FBJ81207.JHVLUBBX@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Fri, 16 Jun 2006 09:36:40 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, Do you mean to exclude the possibility that RFC3775-HA includes NEMO-HA in the HA List with (R) flag=0? I also think that RFC3775-HA should be excluded from NEMO Home Link. In　a word, all HA supports RFC3963. However, I was anxious about this possibility. Need not MR basically deal with this possibility? Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp In message <027f01c6907d$3ae7cf60$ce2da40a@china.huawei.com> "Re: [nemo] MR received the HAAD Reply (R flag=0)" "Andy Huang " wrote: > According to RFC3963, it mean that there is no HA which can support MR on > the home link. > And I think it's useless for MR to get MIP-HA list from the DHAAD reply when > R Flag in the packet is 0. > > ----- Original Message ----- > From: "K.Kawaguchi" > To: > Sent: Thursday, June 15, 2006 3:40 PM > Subject: [nemo] MR received the HAAD Reply (R flag=0) > > > > Hi, > > > > I have a question about RFC3963 section 5.3, 7.2. > > > > The HAAD Reply indicates that the MR Support (R) Flag is 0 > > and the list of HA Addresses include many HAs. > > How to process the Mobile Prefix Registration when MR received > > the HAAD Reply. > > > > I assumed the following processing. > > Is there the correct one? Or, another one? > > > > 1. MR tries the Mobile Prefix Registration to HAs in order > > of list of HA Addresses. > > 2. Almost same as above 1. But MR skips the HA that sent the > > HAAD Reply. > > 3. MR send the HAAD Requiest again until finding NEMO-HA. > > 4. MR doesn't try the Mobile Prefix Registration. > > 5. In fact, there are no matter since this situation is avoided > > by the following some solution. > > eg, > > - MIP Home Link and NEMO Home Link should be separated. > > - If MIP Home Link and NEMO Home Link are the same link. > > - It should be configure to reply by NEMO-HA rather than by MIP-HA. > > (The HAAD Reply function of MIP-HA isn't enabled.) > > - Even if HA don't support MR, HA should support the RFC3963. > > (This MIP-HA supports the RFC3963. MIP-HA makes the (R) flag 1 > > and the list of HA Addresses except for MIP-HA.) > > > > > > Best regards > > --- > > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp > > > > Best regards > > --- > > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp > > > > > > > > > > Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp From nemo-bounces@ietf.org Thu Jun 15 23:07:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr4fx-0002bK-EO; Thu, 15 Jun 2006 23:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr4fv-0002S1-Iy for nemo@ietf.org; Thu, 15 Jun 2006 23:07:11 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr4ft-0000UV-QX for nemo@ietf.org; Thu, 15 Jun 2006 23:07:11 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X00IZMND6DF@szxga01-in.huawei.com> for nemo@ietf.org; Fri, 16 Jun 2006 11:07:54 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X00HVSND62G@szxga01-in.huawei.com> for nemo@ietf.org; Fri, 16 Jun 2006 11:07:54 +0800 (CST) Received: from h50541 ([10.164.45.206]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0X001O5NCXZ8@szxml03-in.huawei.com> for nemo@ietf.org; Fri, 16 Jun 2006 11:07:46 +0800 (CST) Date: Fri, 16 Jun 2006 11:06:19 +0800 From: Andy Huang Subject: Re: [nemo] MR received the HAAD Reply (R flag=0) To: "K.Kawaguchi" , nemo@ietf.org Message-id: <03b301c690f1$d78e8ec0$ce2da40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-2022-jp; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200606151640.HJD39566.VHLJBBXU@ysknet.co.jp> <027f01c6907d$3ae7cf60$ce2da40a@china.huawei.com> <200606160936.FBJ81207.JHVLUBBX@ysknet.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I wonder whether any HA can work as RFC3775-HA and RFC3963-HA at the same time. It seems that there are no constraints on this point. ----- Original Message ----- From: "K.Kawaguchi" To: ; Sent: Friday, June 16, 2006 8:36 AM Subject: Re: [nemo] MR received the HAAD Reply (R flag=0) > Hi, > > Do you mean to exclude the possibility that RFC3775-HA includes NEMO-HA > in the HA List with (R) flag=0? I also think that RFC3775-HA should be > excluded from NEMO Home Link. In　a word, all HA supports RFC3963. > However, I was anxious about this possibility. Need not MR basically deal > with this possibility? > > > Best regards > --- > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp > > > > In message <027f01c6907d$3ae7cf60$ce2da40a@china.huawei.com> > "Re: [nemo] MR received the HAAD Reply (R flag=0)" > "Andy Huang " wrote: > >> According to RFC3963, it mean that there is no HA which can support MR on >> the home link. >> And I think it's useless for MR to get MIP-HA list from the DHAAD reply >> when >> R Flag in the packet is 0. >> >> ----- Original Message ----- >> From: "K.Kawaguchi" >> To: >> Sent: Thursday, June 15, 2006 3:40 PM >> Subject: [nemo] MR received the HAAD Reply (R flag=0) >> >> >> > Hi, >> > >> > I have a question about RFC3963 section 5.3, 7.2. >> > >> > The HAAD Reply indicates that the MR Support (R) Flag is 0 >> > and the list of HA Addresses include many HAs. >> > How to process the Mobile Prefix Registration when MR received >> > the HAAD Reply. >> > >> > I assumed the following processing. >> > Is there the correct one? Or, another one? >> > >> > 1. MR tries the Mobile Prefix Registration to HAs in order >> > of list of HA Addresses. >> > 2. Almost same as above 1. But MR skips the HA that sent the >> > HAAD Reply. >> > 3. MR send the HAAD Requiest again until finding NEMO-HA. >> > 4. MR doesn't try the Mobile Prefix Registration. >> > 5. In fact, there are no matter since this situation is avoided >> > by the following some solution. >> > eg, >> > - MIP Home Link and NEMO Home Link should be separated. >> > - If MIP Home Link and NEMO Home Link are the same link. >> > - It should be configure to reply by NEMO-HA rather than by >> > MIP-HA. >> > (The HAAD Reply function of MIP-HA isn't enabled.) >> > - Even if HA don't support MR, HA should support the RFC3963. >> > (This MIP-HA supports the RFC3963. MIP-HA makes the (R) flag 1 >> > and the list of HA Addresses except for MIP-HA.) >> > >> > >> > Best regards >> > --- >> > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp >> > >> > Best regards >> > --- >> > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp >> > >> > >> > >> >> >> >> > > > Best regards > --- > Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp > > From nemo-bounces@ietf.org Tue Jun 20 05:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FscYt-0001XQ-Au; Tue, 20 Jun 2006 05:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FscYs-0001XI-0n for nemo@ietf.org; Tue, 20 Jun 2006 05:30:18 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FscYp-0006of-C0 for nemo@ietf.org; Tue, 20 Jun 2006 05:30:17 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k5K9UAwj028612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Jun 2006 11:30:10 +0200 Date: Tue, 20 Jun 2006 11:30:09 +0200 From: Thierry Ernst To: ml-nemo Message-Id: <20060620113009.61c493df.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4497C022.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Subject: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4 (mip4) X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Relaying the same message on this list since we had related discussion last month. Thierry Begin forwarded message: Date: Thu, 15 Jun 2006 17:49:38 +0300 From: Jari Arkko To: Mobile IPv6 Mailing List Cc: Peter McCann , Henrik Levkowetz Subject: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4 (mip4) FYI -- MIP4 wants to recharter to include work on dual stack Mobile IPv4 support (item 10 below). Given that MIP6 also works on related issues I wanted to point you to this update. Comments welcome. --Jari IESG Secretary wrote: >A new charter for the Mobility for IPv4 (mip4) working group in the Internet >Area of the IETF is being considered. The draft charter is provided below for >your review and comment. > >Review time is one week. > >The IETF Secretariat > >+++ > >Mobility for IPv4 (mip4) >========================== > >Last Modified: 2006-06-13 > >Current Status: Active Working Group > >Chair(s): >Peter McCann >Henrik Levkowetz > >Internet Area Director(s): >Jari Arkko >Mark Townsley > >Internet Area Advisor: >Jari Arkko > >Mailing Lists: >General Discussion: mip4@ietf.org >To Subscribe: mip4-request@ietf.org >In Body: subscribe >Archive: http://www.ietf.org/mail-archive/web/mip4/index.html > >Description of Working Group: > >IP mobility support for IPv4 nodes (hosts and routers) is specified in >RFC3344. RFC 3344 mobility allows a node to continue using >its "permanent" home address as it moves around the Internet. The >Mobile IP protocols support transparency above the IP layer, including >maintenance of active TCP connections and UDP port bindings.Besides >the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal >with concerns such as optimization, security, extensions, AAA support, >and deployment issues. > >MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 >networks). The scope of the deployment is on a fairly large scale and >accordingly, the MIP4 WG will focus on deployment issues and on >addressing known deficiencies and shortcomings in the protocol that >have come up as a result of deployment experience. Specifically, the >working group will complete the work items to facilitate interactions >with AAA environments, interactions with enterprise environments when >MIPv4 is used therein, and updating existing protocol specifications >in accordance with deployment needs and advancing those protocols that >are on the standards track. > >Work expected to be done by the MIP4 WG as proposed by this charter is >as follows: > >1. MIPv4 has been a proposed standard for several years. It has been >adopted by other standard development organizations and has been >deployed commercially. One of the next steps for the WG is to advance >the protocol to draft standard status. As part of advancing base >Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised >to reflect implementation experience > >2. Work items that are pending from the previous Mobile IP WG, which >will be completed by the MIP4 WG, are: > >- completion of the MIB for the revised base Mobile IP >specification (2006bis) > >- regional registration draft. > >3. The MIP4 WG will also complete the work on MIPv4 interactions >in VPN scenarios. This work will involve identifying the requirements >and a solution development for MIPv4 operation in the presence >of IPsec VPNs. > >4. Additionally, a proposal has been made for how MOBIKE could work >together with MIPv4. This proposal does not describe any new protocol, >but formulates a best current practice for deploying MOBIKE together >with MIPv4. The working group will adopt and complete this document. > >5. Some issues have been raised with respect to RFC3519. These will be >identified and addressed as appropriate, through errata, revision >of RFC 3519, and/or supplemental documents as needed. > >6. It has been proposed that the FMIP protocol, which has been >standardised for MIPv6 in the MIPSHOP working group, should also be >published as an experimental protocol for MIPv4. A draft for this >exists. The working group will take up and carry this work forward >to publication > >7. An extension to carry generic strings in the Registration Reply >message has been proposed. The purpose is to supply supplemental >human-readable information intended to the MN user. The working >group will complete the specification and applicability statement of >such an extension. > >8. RADIUS attributes for MIP4. A set of RADIUS attributes has >been proposed for MIPv4. > >The working group will first produce a requirements specification, >describing how the work differs from the requirements in RFC 2977 >and the functionality provided by RFC 4004 (the MIPv4 Diameter App). >The reason why this first step is required is that RFC 3127 pretty >clearly shows that full 2977 functionality can't be provided by even >a considerably extended RADIUS, so we need to match the requirements >to what can be done within RADIUS. > >Provided the requirements work finds approval with ADs and radext, >the workgroup will complete the specification of MIPv4 RADIUS >attributes, solicit feedback from the Radius Extensions WG, adjust, >and submit this for publication. > >9. MIPv4 Extension for Configuration Options. > >Several drafts have proposed extensions to help improve configuration >of MIPv4 clients. The latest proposal is for a general configuration >option extension which could carry information such as e.g., DNS >address and DHCP server address. The working group will take on >and complete one proposal for a configuration option extension. > >10. Dual-stack Support > >There have been several proposals for how to enable an IPv6 >connection over a network that supports Mobile IPv4. The >basic idea is to include an IPv6 address in the Mobile IPv4 >signaling messages. The working group will take on and complete >one proposal for IPv6 over Mobile IPv4. > >Goals and Milestones: > >Done AAA Keys for MIPv4 to IESG >Done MIPv4 VPN interaction problem statement to IESG >Done Low latency handover to experimental >Done Experimental MIPv4 message and extensions draft to IESG >Done Dynamic Home Agent assignment protocol solution to IESG >Done Revised MIPv4 Challenge/Response (3012bis) to IESG >Done Regional registration document to IESG >Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT WG for comment >Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG >May 2006 MIPv4 Mobike interaction (BCP) to the IESG >May 2006 MIPv4 VPN interaction (BCP) to the IESG >May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment >Jun 2006 Revised MIPv4 specification to IESG for Draft Std. >Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG >Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG >Sep 2006 FMIPv4 (Experimental) to the IESG >Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG >Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG >Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG >Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Tue Jun 20 09:23:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgCH-0005L6-0L; Tue, 20 Jun 2006 09:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsgCF-0005L1-P4 for nemo@ietf.org; Tue, 20 Jun 2006 09:23:11 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsgCE-0007rN-CE for nemo@ietf.org; Tue, 20 Jun 2006 09:23:11 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.6/8.13.6) with ESMTP id k5KDN5Sr008410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 15:23:05 +0200 Date: Tue, 20 Jun 2006 15:23:04 +0200 From: Thierry Ernst To: ml-nemo Message-Id: <20060620152304.29a7a21e.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4497F6B9.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tj Subject: [nemo] NEMO Meeting X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear all, The NEMO WG meeting is scheduled on > TUESDAY, July 11, 2006 > 1850-1950 Afternoon Session IV > Room 513C-F INT nemo Network Mobility WG As you can see, we only requested 1 hour this time. Requests will be allocated based on WG priorities and interest shown on the ML. If you want to get some time, please do so and provide: 1. Title 2. Speaker 3. Expected Time, Q&A included 4. related draft or ML discussion topics Note that TJ will not attend the meeting, so make sure all queries are at least addressed to me. Regards, Thierry. -- Thierry ERNST, PhD INRIA Rocquencourt Project-Team IMARA +33 1 39 63 59 30 (office) From nemo-bounces@ietf.org Tue Jun 20 15:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslZA-0000PU-6a; Tue, 20 Jun 2006 15:07:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FslZ9-0000OD-B6 for nemo@ietf.org; Tue, 20 Jun 2006 15:07:11 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FslZ8-0006ej-QY for nemo@ietf.org; Tue, 20 Jun 2006 15:07:11 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5KJ79bg011591; Tue, 20 Jun 2006 12:07:10 -0700 (MST) Received: from [10.129.40.231] ([10.129.40.231]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5KJ77Sa000651; Tue, 20 Jun 2006 14:07:08 -0500 (CDT) Message-ID: <4498475B.3070909@motorola.com> Date: Tue, 20 Jun 2006 21:07:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4 (mip4) References: <20060620113009.61c493df.thierry.ernst@inria.fr> In-Reply-To: <20060620113009.61c493df.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: ml-nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Relaying the same message on this list since we had related > discussion last month. Thierry, thanks for the forward. What's the significance of that discussion for this WG? The MIP4 re-chartering in question is about the MIP4 WG taking on developping MIPv4 extensions to support mobility for IPv6 as well. MIP4 currently doesn't have that in its Charter. A proposed solution is "DS-MIPv4", in draft-tsirtsis-v4v6-mipv4-01.txt. For this WG, would it mean that it should advise the DS-MIPv4 work to extend the IPv4 Prefix Table (described in the NEMOv4 base spec) to also contain IPv6 prefixes? If MIP4 WG DS-MIPv4 (or similar) work goes Standards Track with DS-MIP4, would it suggest that NEMOv4 should go same way? Alex > Thierry > > > Begin forwarded message: > > Date: Thu, 15 Jun 2006 17:49:38 +0300 From: Jari Arkko > To: Mobile IPv6 Mailing List > Cc: Peter McCann , Henrik Levkowetz > Subject: [Mip6] FW: Internal WG Review: > Recharter of Mobility for IPv4 (mip4) > > > > FYI -- MIP4 wants to recharter to include work on dual stack Mobile > IPv4 support (item 10 below). Given that MIP6 also works on related > issues I wanted to point you to this update. Comments welcome. > > --Jari > > IESG Secretary wrote: > >> A new charter for the Mobility for IPv4 (mip4) working group in the >> Internet Area of the IETF is being considered. The draft charter >> is provided below for your review and comment. >> >> Review time is one week. >> >> The IETF Secretariat >> >> +++ >> >> Mobility for IPv4 (mip4) ========================== >> >> Last Modified: 2006-06-13 >> >> Current Status: Active Working Group >> >> Chair(s): Peter McCann Henrik Levkowetz >> >> >> Internet Area Director(s): Jari Arkko Mark >> Townsley >> >> Internet Area Advisor: Jari Arkko >> >> Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: >> mip4-request@ietf.org In Body: subscribe Archive: >> http://www.ietf.org/mail-archive/web/mip4/index.html >> >> Description of Working Group: >> >> IP mobility support for IPv4 nodes (hosts and routers) is specified >> in RFC3344. RFC 3344 mobility allows a node to continue using its >> "permanent" home address as it moves around the Internet. The >> Mobile IP protocols support transparency above the IP layer, >> including maintenance of active TCP connections and UDP port >> bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several >> other drafts deal with concerns such as optimization, security, >> extensions, AAA support, and deployment issues. >> >> MIPv4 is currently being deployed on a wide basis (e.g., in >> cdma2000 networks). The scope of the deployment is on a fairly >> large scale and accordingly, the MIP4 WG will focus on deployment >> issues and on addressing known deficiencies and shortcomings in the >> protocol that have come up as a result of deployment experience. >> Specifically, the working group will complete the work items to >> facilitate interactions with AAA environments, interactions with >> enterprise environments when MIPv4 is used therein, and updating >> existing protocol specifications in accordance with deployment >> needs and advancing those protocols that are on the standards >> track. >> >> Work expected to be done by the MIP4 WG as proposed by this charter >> is as follows: >> >> 1. MIPv4 has been a proposed standard for several years. It has >> been adopted by other standard development organizations and has >> been deployed commercially. One of the next steps for the WG is to >> advance the protocol to draft standard status. As part of >> advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will >> be revised to reflect implementation experience >> >> 2. Work items that are pending from the previous Mobile IP WG, >> which will be completed by the MIP4 WG, are: >> >> - completion of the MIB for the revised base Mobile IP >> specification (2006bis) >> >> - regional registration draft. >> >> 3. The MIP4 WG will also complete the work on MIPv4 interactions in >> VPN scenarios. This work will involve identifying the requirements >> and a solution development for MIPv4 operation in the presence of >> IPsec VPNs. >> >> 4. Additionally, a proposal has been made for how MOBIKE could work >> together with MIPv4. This proposal does not describe any new >> protocol, but formulates a best current practice for deploying >> MOBIKE together with MIPv4. The working group will adopt and >> complete this document. >> >> 5. Some issues have been raised with respect to RFC3519. These will >> be identified and addressed as appropriate, through errata, >> revision of RFC 3519, and/or supplemental documents as needed. >> >> 6. It has been proposed that the FMIP protocol, which has been >> standardised for MIPv6 in the MIPSHOP working group, should also be >> published as an experimental protocol for MIPv4. A draft for this >> exists. The working group will take up and carry this work forward >> to publication >> >> 7. An extension to carry generic strings in the Registration Reply >> message has been proposed. The purpose is to supply supplemental >> human-readable information intended to the MN user. The working >> group will complete the specification and applicability statement >> of such an extension. >> >> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been >> proposed for MIPv4. >> >> The working group will first produce a requirements specification, >> describing how the work differs from the requirements in RFC 2977 >> and the functionality provided by RFC 4004 (the MIPv4 Diameter >> App). The reason why this first step is required is that RFC 3127 >> pretty clearly shows that full 2977 functionality can't be provided >> by even a considerably extended RADIUS, so we need to match the >> requirements to what can be done within RADIUS. >> >> Provided the requirements work finds approval with ADs and radext, >> the workgroup will complete the specification of MIPv4 RADIUS >> attributes, solicit feedback from the Radius Extensions WG, adjust, >> and submit this for publication. >> >> 9. MIPv4 Extension for Configuration Options. >> >> Several drafts have proposed extensions to help improve >> configuration of MIPv4 clients. The latest proposal is for a >> general configuration option extension which could carry >> information such as e.g., DNS address and DHCP server address. The >> working group will take on and complete one proposal for a >> configuration option extension. >> >> 10. Dual-stack Support >> >> There have been several proposals for how to enable an IPv6 >> connection over a network that supports Mobile IPv4. The basic idea >> is to include an IPv6 address in the Mobile IPv4 signaling >> messages. The working group will take on and complete one proposal >> for IPv6 over Mobile IPv4. >> >> Goals and Milestones: >> >> Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem >> statement to IESG Done Low latency handover to experimental Done >> Experimental MIPv4 message and extensions draft to IESG Done >> Dynamic Home Agent assignment protocol solution to IESG Done >> Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional >> registration document to IESG Mar 2006 MIPv4 RADIUS Extensions >> Requirements to RADEXT WG for comment Apr 2006 Revised rfc2794bis >> (NAI extension) (Draft Std.) to the IESG May 2006 MIPv4 Mobike >> interaction (BCP) to the IESG May 2006 MIPv4 VPN interaction (BCP) >> to the IESG May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG >> for comment Jun 2006 Revised MIPv4 specification to IESG for Draft >> Std. Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the >> IESG Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) >> to the IESG Sep 2006 FMIPv4 (Experimental) to the IESG Sep 2006 >> MIPv4 RADIUS Extensions Requirements to the IESG Sep 2006 RADIUS >> Extensions for MIPv4 (Proposed Std.) to the IESG Dec 2006 Revised >> MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 Dual-stack MIPv4 >> (Proposed Std.) to IESG >> >> > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > > > From nemo-bounces@ietf.org Tue Jun 20 21:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsrxG-0005gZ-CA; Tue, 20 Jun 2006 21:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsrxF-0005gO-QC for nemo@ietf.org; Tue, 20 Jun 2006 21:56:29 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsrxE-0000LC-Fq for nemo@ietf.org; Tue, 20 Jun 2006 21:56:29 -0400 Received: by nf-out-0910.google.com with SMTP id c29so29004nfb for ; Tue, 20 Jun 2006 18:56:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=JacWuzy9YoPZxte0uE4qyzh3eckaZIXVp/NWNr2rQYfbxaQkErQ4LAoKC+2EUI7E8aHfiolaZMDn/P2OnJBtmxUGMXqzGwx7JaL+CW8+2MJAeeIG3u28zMHTAoNvY4KMfc1YmEg7RwfDqvtXMD1u8djNDaIGspc5a1anVQdjIA4= Received: by 10.49.4.17 with SMTP id g17mr80072nfi; Tue, 20 Jun 2006 18:56:27 -0700 (PDT) Received: by 10.48.235.18 with HTTP; Tue, 20 Jun 2006 18:56:27 -0700 (PDT) Message-ID: Date: Wed, 21 Jun 2006 10:56:27 +0900 From: "Jiho Ryu" To: nemo@ietf.org Subject: [nemo] New draft submitted:draft-ryu-nemo-ingress-filtering-00.txt MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2987_13388378.1150854987593" X-Google-Sender-Auth: e2454481e81ef665 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org ------=_Part_2987_13388378.1150854987593 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all, We have submitted a new draft about solution of ingress filtering in multihomed NEMO. Here is an abstract: In this draft, a solution of the ingress filtering problem is proposed for a NEMO with multiple mobile routers. Extending the multiple care-of address registration mechanism and introducing a "prefix peer" relationship among the mobile routers, we can solve the ingress filtering problem in a NEMO with multiple mobile routers. A URL for this draft is: http://www.ietf.org/internet-drafts/draft-ryu-nemo-ingress-filtering-00.txt Any questions and comments are welcome at anytime. :-) Regards Jiho. -- Ryu, Jiho Master Course Multimedia and Mobile Communications Lab., School of Computer Science and Engineering Seoul National University ------=_Part_2987_13388378.1150854987593 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear all,

We have submitted a new draft about solution of ingress filtering in multihomed NEMO.

Here is an abstract:

 
   In this draft, a solution of the ingress filtering problem is
   proposed for a NEMO with multiple mobile routers.  Extending the
   multiple care-of address registration mechanism and introducing a

   "prefix peer" relationship among the mobile routers, we can solve the
   ingress filtering problem in a NEMO with multiple mobile routers.

A URL for this draft is:

http://www.ietf.org/internet-drafts/draft-ryu-nemo-ingress-filtering-00.txt

Any questions and comments are welcome at anytime.  :-) 


Regards
Jiho.



-- 
Ryu, Jiho
Master Course
Multimedia and Mobile Communications Lab.,
School of Computer Science and Engineering
Seoul National University


------=_Part_2987_13388378.1150854987593-- From nemo-bounces@ietf.org Wed Jun 21 08:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1iT-0006rG-HA; Wed, 21 Jun 2006 08:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1iS-0006rB-Ir for nemo@ietf.org; Wed, 21 Jun 2006 08:21:52 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft1iR-0006Hv-Vv for nemo@ietf.org; Wed, 21 Jun 2006 08:21:52 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LCLnJa032151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 05:21:49 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LCLmWE029548; Wed, 21 Jun 2006 05:21:48 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 05:21:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4(mip4) Date: Wed, 21 Jun 2006 05:21:44 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA3C@NAEX14.na.qualcomm.com> In-Reply-To: <4498475B.3070909@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4(mip4) Thread-Index: AcaUnMeM/nigJ/8CT9mgUvQjNxi8OQAj5NuA From: "Tsirtsis, George" To: "Alexandru Petrescu" , "Thierry Ernst" X-OriginalArrivalTime: 21 Jun 2006 12:21:48.0255 (UTC) FILETIME=[44893EF0:01C6952D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: ml-nemo X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex, The DS-MIPv4 draft you point to in fact defines IPv6 prefix extensions to MIPv4 so it includes support for v6 networks. Since we had to add an extension to carry in IPv6 address, it made sense to make the extension able to carry prefixes too. The draft also includes FA support and dynamic prefix allocation and it has been written with NEMOv4 in mind so the mechanics are very similar. BTW, are you planning to submit an updated version of NEMOv4 draft?=20 Regards George > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Tuesday, June 20, 2006 3:07 PM > To: Thierry Ernst > Cc: ml-nemo > Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility for > IPv4(mip4) >=20 > Thierry Ernst wrote: > > Relaying the same message on this list since we had related > > discussion last month. >=20 > Thierry, thanks for the forward. What's the significance of that > discussion for this WG? >=20 > The MIP4 re-chartering in question is about the MIP4 WG taking on > developping MIPv4 extensions to support mobility for IPv6 as well. MIP4 > currently doesn't have that in its Charter. >=20 > A proposed solution is "DS-MIPv4", in draft-tsirtsis-v4v6-mipv4-01.txt. >=20 > For this WG, would it mean that it should advise the DS-MIPv4 work to > extend the IPv4 Prefix Table (described in the NEMOv4 base spec) to also > contain IPv6 prefixes? >=20 > If MIP4 WG DS-MIPv4 (or similar) work goes Standards Track with DS-MIP4, > would it suggest that NEMOv4 should go same way? >=20 > Alex >=20 > > Thierry > > > > > > Begin forwarded message: > > > > Date: Thu, 15 Jun 2006 17:49:38 +0300 From: Jari Arkko > > To: Mobile IPv6 Mailing List > > Cc: Peter McCann , Henrik Levkowetz > > Subject: [Mip6] FW: Internal WG Review: > > Recharter of Mobility for IPv4 (mip4) > > > > > > > > FYI -- MIP4 wants to recharter to include work on dual stack Mobile > > IPv4 support (item 10 below). Given that MIP6 also works on related > > issues I wanted to point you to this update. Comments welcome. > > > > --Jari > > > > IESG Secretary wrote: > > > >> A new charter for the Mobility for IPv4 (mip4) working group in the > >> Internet Area of the IETF is being considered. The draft charter > >> is provided below for your review and comment. > >> > >> Review time is one week. > >> > >> The IETF Secretariat > >> > >> +++ > >> > >> Mobility for IPv4 (mip4) = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > >> > >> Last Modified: 2006-06-13 > >> > >> Current Status: Active Working Group > >> > >> Chair(s): Peter McCann Henrik Levkowetz > >> > >> > >> Internet Area Director(s): Jari Arkko Mark > >> Townsley > >> > >> Internet Area Advisor: Jari Arkko > >> > >> Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: > >> mip4-request@ietf.org In Body: subscribe Archive: > >> http://www.ietf.org/mail-archive/web/mip4/index.html > >> > >> Description of Working Group: > >> > >> IP mobility support for IPv4 nodes (hosts and routers) is specified > >> in RFC3344. RFC 3344 mobility allows a node to continue using its > >> "permanent" home address as it moves around the Internet. The > >> Mobile IP protocols support transparency above the IP layer, > >> including maintenance of active TCP connections and UDP port > >> bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several > >> other drafts deal with concerns such as optimization, security, > >> extensions, AAA support, and deployment issues. > >> > >> MIPv4 is currently being deployed on a wide basis (e.g., in > >> cdma2000 networks). The scope of the deployment is on a fairly > >> large scale and accordingly, the MIP4 WG will focus on deployment > >> issues and on addressing known deficiencies and shortcomings in the > >> protocol that have come up as a result of deployment experience. > >> Specifically, the working group will complete the work items to > >> facilitate interactions with AAA environments, interactions with > >> enterprise environments when MIPv4 is used therein, and updating > >> existing protocol specifications in accordance with deployment > >> needs and advancing those protocols that are on the standards > >> track. > >> > >> Work expected to be done by the MIP4 WG as proposed by this charter > >> is as follows: > >> > >> 1. MIPv4 has been a proposed standard for several years. It has > >> been adopted by other standard development organizations and has > >> been deployed commercially. One of the next steps for the WG is to > >> advance the protocol to draft standard status. As part of > >> advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will > >> be revised to reflect implementation experience > >> > >> 2. Work items that are pending from the previous Mobile IP WG, > >> which will be completed by the MIP4 WG, are: > >> > >> - completion of the MIB for the revised base Mobile IP > >> specification (2006bis) > >> > >> - regional registration draft. > >> > >> 3. The MIP4 WG will also complete the work on MIPv4 interactions in > >> VPN scenarios. This work will involve identifying the requirements > >> and a solution development for MIPv4 operation in the presence of > >> IPsec VPNs. > >> > >> 4. Additionally, a proposal has been made for how MOBIKE could work > >> together with MIPv4. This proposal does not describe any new > >> protocol, but formulates a best current practice for deploying > >> MOBIKE together with MIPv4. The working group will adopt and > >> complete this document. > >> > >> 5. Some issues have been raised with respect to RFC3519. These will > >> be identified and addressed as appropriate, through errata, > >> revision of RFC 3519, and/or supplemental documents as needed. > >> > >> 6. It has been proposed that the FMIP protocol, which has been > >> standardised for MIPv6 in the MIPSHOP working group, should also be > >> published as an experimental protocol for MIPv4. A draft for this > >> exists. The working group will take up and carry this work forward > >> to publication > >> > >> 7. An extension to carry generic strings in the Registration Reply > >> message has been proposed. The purpose is to supply supplemental > >> human-readable information intended to the MN user. The working > >> group will complete the specification and applicability statement > >> of such an extension. > >> > >> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been > >> proposed for MIPv4. > >> > >> The working group will first produce a requirements specification, > >> describing how the work differs from the requirements in RFC 2977 > >> and the functionality provided by RFC 4004 (the MIPv4 Diameter > >> App). The reason why this first step is required is that RFC 3127 > >> pretty clearly shows that full 2977 functionality can't be provided > >> by even a considerably extended RADIUS, so we need to match the > >> requirements to what can be done within RADIUS. > >> > >> Provided the requirements work finds approval with ADs and radext, > >> the workgroup will complete the specification of MIPv4 RADIUS > >> attributes, solicit feedback from the Radius Extensions WG, adjust, > >> and submit this for publication. > >> > >> 9. MIPv4 Extension for Configuration Options. > >> > >> Several drafts have proposed extensions to help improve > >> configuration of MIPv4 clients. The latest proposal is for a > >> general configuration option extension which could carry > >> information such as e.g., DNS address and DHCP server address. The > >> working group will take on and complete one proposal for a > >> configuration option extension. > >> > >> 10. Dual-stack Support > >> > >> There have been several proposals for how to enable an IPv6 > >> connection over a network that supports Mobile IPv4. The basic idea > >> is to include an IPv6 address in the Mobile IPv4 signaling > >> messages. The working group will take on and complete one proposal > >> for IPv6 over Mobile IPv4. > >> > >> Goals and Milestones: > >> > >> Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem > >> statement to IESG Done Low latency handover to experimental Done > >> Experimental MIPv4 message and extensions draft to IESG Done > >> Dynamic Home Agent assignment protocol solution to IESG Done > >> Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional > >> registration document to IESG Mar 2006 MIPv4 RADIUS Extensions > >> Requirements to RADEXT WG for comment Apr 2006 Revised rfc2794bis > >> (NAI extension) (Draft Std.) to the IESG May 2006 MIPv4 Mobike > >> interaction (BCP) to the IESG May 2006 MIPv4 VPN interaction (BCP) > >> to the IESG May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG > >> for comment Jun 2006 Revised MIPv4 specification to IESG for Draft > >> Std. Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the > >> IESG Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) > >> to the IESG Sep 2006 FMIPv4 (Experimental) to the IESG Sep 2006 > >> MIPv4 RADIUS Extensions Requirements to the IESG Sep 2006 RADIUS > >> Extensions for MIPv4 (Proposed Std.) to the IESG Dec 2006 Revised > >> MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 Dual-stack MIPv4 > >> (Proposed Std.) to IESG > >> > >> > > > > > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > >=20 From nemo-bounces@ietf.org Wed Jun 21 09:19:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2bv-0001fh-Fs; Wed, 21 Jun 2006 09:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2bt-0001fZ-87 for nemo@ietf.org; Wed, 21 Jun 2006 09:19:09 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2bs-0002Kw-14 for nemo@ietf.org; Wed, 21 Jun 2006 09:19:09 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LDJ3sD003800; Wed, 21 Jun 2006 06:19:03 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k5LDJ2rS005862; Wed, 21 Jun 2006 08:19:02 -0500 (CDT) Message-ID: <44994744.4050901@motorola.com> Date: Wed, 21 Jun 2006 15:19:00 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA3C@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA3C@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > Alex, > > The DS-MIPv4 draft you point to in fact defines IPv6 prefix > extensions to MIPv4 so it includes support for v6 networks. Since we > had to add an extension to carry in IPv6 address, it made sense to > make the extension able to carry prefixes too. Makes sense. How about adding IPv6 prefixes in the Prefix Table too (not only in the MIP4 messaging and in the IPv4 Registration Table)? The Prefix Table is an essential data structure for guaranteeing security between MR and HA. The NEMOv4 draft describes the Prefix Table for IPv4. For NEMOv4 to work over IPv6 networks it would need to have an extended Prefix Table such that it contains the IPv6 prefixes too (not only IPv4 prefixes). > BTW, are you planning to submit an updated version of NEMOv4 draft? YEs, soon. Alex From nemo-bounces@ietf.org Wed Jun 21 09:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2zo-00085t-5p; Wed, 21 Jun 2006 09:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft2zm-00085o-T0 for nemo@ietf.org; Wed, 21 Jun 2006 09:43:50 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft2zl-0004kj-II for nemo@ietf.org; Wed, 21 Jun 2006 09:43:50 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LDhmer004607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 06:43:48 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LDhkN0017770; Wed, 21 Jun 2006 06:43:47 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 06:43:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4(mip4) Date: Wed, 21 Jun 2006 06:43:45 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA4D@NAEX14.na.qualcomm.com> In-Reply-To: <44994744.4050901@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4(mip4) Thread-Index: AcaVNVU0SCHj3BAMQEesUVVWAGv7MAAAthlA From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 13:43:46.0052 (UTC) FILETIME=[B7C58440:01C69538] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Yes the draft already indicates that the DS-MIPv4 HA should maintain the table of registered IPv6 prefixes. Is there something more you want me to say? You seem to be making a distinction between the registration table and the prefixes table which I am not sure I follow. George > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 9:19 AM > To: Tsirtsis, George > Cc: Thierry Ernst; ml-nemo > Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility for > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > Alex, > > > > The DS-MIPv4 draft you point to in fact defines IPv6 prefix > > extensions to MIPv4 so it includes support for v6 networks. Since we > > had to add an extension to carry in IPv6 address, it made sense to > > make the extension able to carry prefixes too. >=20 > Makes sense. How about adding IPv6 prefixes in the Prefix Table too > (not only in the MIP4 messaging and in the IPv4 Registration Table)? > The Prefix Table is an essential data structure for guaranteeing > security between MR and HA. >=20 > The NEMOv4 draft describes the Prefix Table for IPv4. For NEMOv4 to > work over IPv6 networks it would need to have an extended Prefix Table > such that it contains the IPv6 prefixes too (not only IPv4 prefixes). >=20 > > BTW, are you planning to submit an updated version of NEMOv4 draft? >=20 > YEs, soon. >=20 > Alex From nemo-bounces@ietf.org Wed Jun 21 09:55:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3BG-0000mt-HO; Wed, 21 Jun 2006 09:55:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3BF-0000ml-1Y for nemo@ietf.org; Wed, 21 Jun 2006 09:55:41 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3BD-0006M7-LI for nemo@ietf.org; Wed, 21 Jun 2006 09:55:41 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5LDtdIL005951; Wed, 21 Jun 2006 06:55:39 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5LDtWOL028492; Wed, 21 Jun 2006 08:55:33 -0500 (CDT) Message-ID: <44994FD2.7020007@motorola.com> Date: Wed, 21 Jun 2006 15:55:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility for IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA4D@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA4D@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > Yes the draft already indicates that the DS-MIPv4 HA should maintain > the table of registered IPv6 prefixes. Is there something more you > want me to say? You seem to be making a distinction between the > registration table and the prefixes table which I am not sure I > follow. The Prefix Table is a data structure different than the Registration Table. It is pre-configured at the Home Agent saying what Home Address can use what Mobile Network Prefix. It's only for security verification. It must be there. Alex > > George > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June 21, >> 2006 9:19 AM To: Tsirtsis, George Cc: Thierry Ernst; ml-nemo >> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility >> for IPv4(mip4) >> >> Tsirtsis, George wrote: >>> Alex, >>> >>> The DS-MIPv4 draft you point to in fact defines IPv6 prefix >>> extensions to MIPv4 so it includes support for v6 networks. Since >>> we had to add an extension to carry in IPv6 address, it made >>> sense to make the extension able to carry prefixes too. >> Makes sense. How about adding IPv6 prefixes in the Prefix Table >> too (not only in the MIP4 messaging and in the IPv4 Registration >> Table)? The Prefix Table is an essential data structure for >> guaranteeing security between MR and HA. >> >> The NEMOv4 draft describes the Prefix Table for IPv4. For NEMOv4 >> to work over IPv6 networks it would need to have an extended Prefix >> Table such that it contains the IPv6 prefixes too (not only IPv4 >> prefixes). >> >>> BTW, are you planning to submit an updated version of NEMOv4 >>> draft? >> YEs, soon. >> >> Alex > > From nemo-bounces@ietf.org Wed Jun 21 10:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3Ga-0003Ln-Gp; Wed, 21 Jun 2006 10:01:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3GY-0003LY-Ev for nemo@ietf.org; Wed, 21 Jun 2006 10:01:10 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3GX-0006gT-3R for nemo@ietf.org; Wed, 21 Jun 2006 10:01:10 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LE179d005629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:01:07 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LE16K5016430; Wed, 21 Jun 2006 07:01:06 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:01:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) Date: Wed, 21 Jun 2006 07:01:04 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA52@NAEX14.na.qualcomm.com> In-Reply-To: <44994FD2.7020007@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) Thread-Index: AcaVOpgyxpPw7zOgRfeuIyS6bhSpqwAADXJA From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 14:01:06.0081 (UTC) FILETIME=[23AD5910:01C6953B] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Oh you are talking about the implicit mode in NEMO. Yes, I could add some words to that effect. Since DS-MIPv4 supports dynamic prefix allocation, however, the HA simply has a pool of IPv6 addresses/prefixes which it allocates as per DS-MIPv4. What you are asking for, however, is also possible as a configuration option. George=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 9:56 AM > To: Tsirtsis, George > Cc: ml-nemo; Thierry Ernst > Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > Yes the draft already indicates that the DS-MIPv4 HA should maintain > > the table of registered IPv6 prefixes. Is there something more you > > want me to say? You seem to be making a distinction between the > > registration table and the prefixes table which I am not sure I > > follow. >=20 > The Prefix Table is a data structure different than the Registration > Table. It is pre-configured at the Home Agent saying what Home Address > can use what Mobile Network Prefix. It's only for security > verification. It must be there. >=20 > Alex >=20 > > > > George > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June 21, > >> 2006 9:19 AM To: Tsirtsis, George Cc: Thierry Ernst; ml-nemo > >> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobility > >> for IPv4(mip4) > >> > >> Tsirtsis, George wrote: > >>> Alex, > >>> > >>> The DS-MIPv4 draft you point to in fact defines IPv6 prefix > >>> extensions to MIPv4 so it includes support for v6 networks. Since > >>> we had to add an extension to carry in IPv6 address, it made > >>> sense to make the extension able to carry prefixes too. > >> Makes sense. How about adding IPv6 prefixes in the Prefix Table > >> too (not only in the MIP4 messaging and in the IPv4 Registration > >> Table)? The Prefix Table is an essential data structure for > >> guaranteeing security between MR and HA. > >> > >> The NEMOv4 draft describes the Prefix Table for IPv4. For NEMOv4 > >> to work over IPv6 networks it would need to have an extended Prefix > >> Table such that it contains the IPv6 prefixes too (not only IPv4 > >> prefixes). > >> > >>> BTW, are you planning to submit an updated version of NEMOv4 > >>> draft? > >> YEs, soon. > >> > >> Alex > > > > >=20 From nemo-bounces@ietf.org Wed Jun 21 10:23:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3cE-0001y0-JP; Wed, 21 Jun 2006 10:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3cD-0001tn-IO for nemo@ietf.org; Wed, 21 Jun 2006 10:23:33 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3cC-0007uA-81 for nemo@ietf.org; Wed, 21 Jun 2006 10:23:33 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k5LENRJs021055; Wed, 21 Jun 2006 07:23:29 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5LENPrn022470; Wed, 21 Jun 2006 09:23:26 -0500 (CDT) Message-ID: <4499565B.3060802@motorola.com> Date: Wed, 21 Jun 2006 16:23:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA52@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA52@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > Oh you are talking about the implicit mode in NEMO. Prefix Table is used for both explicit and implicit modes. Yes, I could add > some words to that effect. Since DS-MIPv4 supports dynamic prefix > allocation, however, the HA simply has a pool of IPv6 addresses/prefixes > which it allocates as per DS-MIPv4. What you are asking for, however, is > also possible as a configuration option. Essential is for HA to verify that a HoA received in RegReq is allowed to use a certain MNP (be it in the RegRep, or allocated by the HA itself). HAven't read ds-mipv4 allocation, but I guess it's done with DHCPv4 PRefix Delegation. Alex From nemo-bounces@ietf.org Wed Jun 21 10:34:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3my-0000CE-HJ; Wed, 21 Jun 2006 10:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3mw-0000Au-Nn for nemo@ietf.org; Wed, 21 Jun 2006 10:34:38 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3mv-0000au-Cs for nemo@ietf.org; Wed, 21 Jun 2006 10:34:38 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEYaUW008316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:34:36 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEYZN8027873; Wed, 21 Jun 2006 07:34:35 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:34:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) Date: Wed, 21 Jun 2006 07:34:33 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA5A@NAEX14.na.qualcomm.com> In-Reply-To: <4499565B.3060802@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) Thread-Index: AcaVPnuQOqOIrnvFQFe38KEOnVLEHAAANeVw From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 14:34:34.0998 (UTC) FILETIME=[D115C160:01C6953F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 10:23 AM > To: Tsirtsis, George > Cc: ml-nemo; Thierry Ernst > Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > Oh you are talking about the implicit mode in NEMO. >=20 > Prefix Table is used for both explicit and implicit modes. >=20 > Yes, I could add > > some words to that effect. Since DS-MIPv4 supports dynamic prefix > > allocation, however, the HA simply has a pool of IPv6 addresses/prefixes > > which it allocates as per DS-MIPv4. What you are asking for, however, is > > also possible as a configuration option. >=20 > Essential is for HA to verify that a HoA received in RegReq is allowed > to use a certain MNP (be it in the RegRep, or allocated by the HA itself). > MIPv4 has a number of ways that the HA can use to determine what HoA a given MN is supposed to use. These include static configuration of HoA, mapping of NAI to HoA, dynamic allocation of HoA. The IP address pools used may also be locally configured or be retrieved by the HA on demand based on DHCP or other mechanisms. I am not sure why we would want to treat prefixes (v4 or v6) any different. =20 > HAven't read ds-mipv4 allocation, but I guess it's done with DHCPv4 > PRefix Delegation. >=20 Maybe you should read it before we have this discussion. Prefix deligation is something that an HA can use to get an address pool. IMO this is independent of how the HA allocates the addresses in the pool to MNs. George From nemo-bounces@ietf.org Wed Jun 21 10:45:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3wu-0007m1-UU; Wed, 21 Jun 2006 10:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft3wt-0007lw-JI for nemo@ietf.org; Wed, 21 Jun 2006 10:44:55 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft3ws-0002BU-8J for nemo@ietf.org; Wed, 21 Jun 2006 10:44:55 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LEirkE022934; Wed, 21 Jun 2006 07:44:53 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5LEiqie029048; Wed, 21 Jun 2006 09:44:52 -0500 (CDT) Message-ID: <44995B62.7000002@motorola.com> Date: Wed, 21 Jun 2006 16:44:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA5A@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA5A@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June 21, >> 2006 10:23 AM To: Tsirtsis, George Cc: ml-nemo; Thierry Ernst >> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of >> Mobilityfor IPv4(mip4) >> >> Tsirtsis, George wrote: >>> Oh you are talking about the implicit mode in NEMO. >> Prefix Table is used for both explicit and implicit modes. >> >> Yes, I could add >>> some words to that effect. Since DS-MIPv4 supports dynamic prefix >>> allocation, however, the HA simply has a pool of IPv6 > addresses/prefixes >>> which it allocates as per DS-MIPv4. What you are asking for, > however, is >>> also possible as a configuration option. >> Essential is for HA to verify that a HoA received in RegReq is >> allowed to use a certain MNP (be it in the RegRep, or allocated by >> the HA > itself). > > MIPv4 has a number of ways that the HA can use to determine what HoA > a given MN is supposed to use. These include static configuration of > HoA, mapping of NAI to HoA, dynamic allocation of HoA. The IP address > pools used may also be locally configured or be retrieved by the HA > on demand based on DHCP or other mechanisms. I am not sure why we > would want to treat prefixes (v4 or v6) any different. Simply because the address is for a MH while the prefix is actually used by the fixed hosts behind MR to make addresses. So MR can guarantee for the HoA it uses but can't guarantee for all addresses that can be derived from a prefix. I.e. if MR uses NAI for its home address can't use same NAI for the addresses of LFNs behind it. They should use their own NAIs. >> HAven't read ds-mipv4 allocation, but I guess it's done with DHCPv4 >> PRefix Delegation. >> > > Maybe you should read it before we have this discussion. Prefix > deligation is something that an HA can use to get an address pool. > IMO this is independent of how the HA allocates the addresses in the > pool to MNs. The way HA allocates a prefix to MR should be the same whether MR is at home or not. When MR is at home (no MR-HA tunnel) most straighforward way is DHCP prefix delegation, spec'ed and implemented. I will read the draft. NEMOv6 has ongoing DHCPv6 prefix delegation WG item between HA and MR. I don't see why NEMOv4 would do it different than NEMOv6. Alex From nemo-bounces@ietf.org Wed Jun 21 10:53:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft44t-0006TZ-MQ; Wed, 21 Jun 2006 10:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft44s-0006TU-Qc for nemo@ietf.org; Wed, 21 Jun 2006 10:53:10 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft44r-0005Ih-FY for nemo@ietf.org; Wed, 21 Jun 2006 10:53:10 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEr8vl009429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 07:53:08 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LEr5QM024704; Wed, 21 Jun 2006 07:53:07 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 07:52:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) Date: Wed, 21 Jun 2006 07:52:16 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FA63@NAEX14.na.qualcomm.com> In-Reply-To: <44995B62.7000002@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) Thread-Index: AcaVQUtffl6GXZblRyutCWbWSS3KzwAAGHSg From: "Tsirtsis, George" To: "Alexandru Petrescu" X-OriginalArrivalTime: 21 Jun 2006 14:52:17.0407 (UTC) FILETIME=[4A5480F0:01C69542] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, June 21, 2006 10:45 AM > To: Tsirtsis, George > Cc: ml-nemo; Thierry Ernst > Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor > IPv4(mip4) >=20 > Tsirtsis, George wrote: > > > >> -----Original Message----- From: Alexandru Petrescu > >> [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June 21, > >> 2006 10:23 AM To: Tsirtsis, George Cc: ml-nemo; Thierry Ernst > >> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of > >> Mobilityfor IPv4(mip4) > >> > >> Tsirtsis, George wrote: > >>> Oh you are talking about the implicit mode in NEMO. > >> Prefix Table is used for both explicit and implicit modes. > >> > >> Yes, I could add > >>> some words to that effect. Since DS-MIPv4 supports dynamic prefix > >>> allocation, however, the HA simply has a pool of IPv6 > > addresses/prefixes > >>> which it allocates as per DS-MIPv4. What you are asking for, > > however, is > >>> also possible as a configuration option. > >> Essential is for HA to verify that a HoA received in RegReq is > >> allowed to use a certain MNP (be it in the RegRep, or allocated by > >> the HA > > itself). > > > > MIPv4 has a number of ways that the HA can use to determine what HoA > > a given MN is supposed to use. These include static configuration of > > HoA, mapping of NAI to HoA, dynamic allocation of HoA. The IP address > > pools used may also be locally configured or be retrieved by the HA > > on demand based on DHCP or other mechanisms. I am not sure why we > > would want to treat prefixes (v4 or v6) any different. >=20 > Simply because the address is for a MH while the prefix is actually used > by the fixed hosts behind MR to make addresses. So MR can guarantee for > the HoA it uses but can't guarantee for all addresses that can be > derived from a prefix. >=20 > I.e. if MR uses NAI for its home address can't use same NAI for the > addresses of LFNs behind it. They should use their own NAIs. >=20 How do you know what the MR is using the addresses for? And why does it matter to the HA?? When the HA agrees to redirect traffic for a prefix to the MR it agrees to do so for all the addresses inside the prefix. The signaling is between MR and HA and the HA has not clue and should not care what is behind the MR. =20 From nemo-bounces@ietf.org Wed Jun 21 11:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Wn-0000Wn-Dh; Wed, 21 Jun 2006 11:22:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4Wm-0000Wc-Ea for nemo@ietf.org; Wed, 21 Jun 2006 11:22:00 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4Wl-0008Dv-5G for nemo@ietf.org; Wed, 21 Jun 2006 11:22:00 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5LFLsJD001869; Wed, 21 Jun 2006 08:21:54 -0700 (MST) Received: from [10.19.252.31] (mvp-10-19-252-31.corp.mot.com [10.19.252.31]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k5LFLrkW009399; Wed, 21 Jun 2006 10:21:53 -0500 (CDT) Message-ID: <4499640E.8020102@motorola.com> Date: Wed, 21 Jun 2006 17:21:50 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] FYI: Internal WG Review: Recharter of Mobilityfor IPv4(mip4) References: <7EB20EA0938B4D42A2D82689365C9B7A04FA63@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FA63@NAEX14.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ml-nemo , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June 21, >> 2006 10:45 AM To: Tsirtsis, George Cc: ml-nemo; Thierry Ernst >> Subject: Re: [nemo] FYI: Internal WG Review: Recharter of >> Mobilityfor IPv4(mip4) >> >> Tsirtsis, George wrote: >>>> -----Original Message----- From: Alexandru Petrescu >>>> [mailto:alexandru.petrescu@motorola.com] Sent: Wednesday, June >>>> 21, 2006 10:23 AM To: Tsirtsis, George Cc: ml-nemo; Thierry >>>> Ernst Subject: Re: [nemo] FYI: Internal WG Review: Recharter of >>>> Mobilityfor IPv4(mip4) >>>> >>>> Tsirtsis, George wrote: >>>>> Oh you are talking about the implicit mode in NEMO. >>>> Prefix Table is used for both explicit and implicit modes. >>>> >>>> Yes, I could add >>>>> some words to that effect. Since DS-MIPv4 supports dynamic >>>>> prefix allocation, however, the HA simply has a pool of IPv6 >>> addresses/prefixes >>>>> which it allocates as per DS-MIPv4. What you are asking for, >>> however, is >>>>> also possible as a configuration option. >>>> Essential is for HA to verify that a HoA received in RegReq is >>>> allowed to use a certain MNP (be it in the RegRep, or allocated >>>> by the HA >>> itself). >>> >>> MIPv4 has a number of ways that the HA can use to determine what >>> HoA a given MN is supposed to use. These include static >>> configuration of HoA, mapping of NAI to HoA, dynamic allocation >>> of HoA. The IP > address >>> pools used may also be locally configured or be retrieved by the >>> HA on demand based on DHCP or other mechanisms. I am not sure >>> why we would want to treat prefixes (v4 or v6) any different. >> Simply because the address is for a MH while the prefix is actually >> >> >> > used >> by the fixed hosts behind MR to make addresses. So MR can >> guarantee > for >> the HoA it uses but can't guarantee for all addresses that can be >> derived from a prefix. >> >> I.e. if MR uses NAI for its home address can't use same NAI for the >> addresses of LFNs behind it. They should use their own NAIs. >> > > > How do you know what the MR is using the addresses for? That's the danger, with routers mobile and HA giving prefixes to them there should be some security. > And why does it matter to the HA?? When the HA agrees to redirect > traffic for a prefix to the MR it agrees to do so for all the > addresses inside the prefix. The signaling is between MR and HA and > the HA has not clue and should not care what is behind the MR. MR gives access to an MH whose HA is different than MR's. MH uses a CoA from the MR's HA. In case MH does troubles with that CoA, MR's HA should be responsible for that, not the MR (which is mobile and more difficult to find physically). Anyways, there was a debate between DHCPv6-PD-based prefix allocation and MIP6-based prefix allocation. Currently only one is a WG item. Maybe both should be. Alex From nemo-bounces@ietf.org Wed Jun 21 22:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFHk-0005vp-2V; Wed, 21 Jun 2006 22:51:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFHj-0005vh-1H for nemo@ietf.org; Wed, 21 Jun 2006 22:51:11 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFHh-0005Dd-5V for nemo@ietf.org; Wed, 21 Jun 2006 22:51:11 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800MQFQZ3X5@szxga03-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 10:59:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1800L7PQZ3WJ@szxga03-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 10:59:27 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J18006L3R1HH9@szxml04-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 11:00:56 +0800 (CST) Date: Thu, 22 Jun 2006 10:50:07 +0800 From: Michael Ye Subject: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt To: hscho@mmlab.snu.ac.kr Message-id: <001901c695a6$9265c250$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaVppIlSWo95QcRQ5SXPwewTJxe3Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hosik Cho, I just wonder at your draft. In section 2.1, One possible solution is to adopt mobile IPv6 style route optimization by sending BU to CN. However, this approach can result in the massively occurred binding update messages at the same time, so called binding update storm (BU storm) since there will be many MNNs inside the NEMO. =>According to RFC3775, a MN must send BU to CN if it handles route optimization. =>So many MNNs does not derectly lead the "BU storm" you called. In section 2.2 The nested NEMO optimization does not seek to solve the inefficiency of the NEMO basic support protocol. In the nested NEMO, the inefficiency is proportional to the nested level of the NEMO without any measure. The nested NEMO can have arbitrary levels of nesting. It is thought that there are two types of nesting: physical nesting and logical nesting. physical nesting means a NEMO getting into another NEMO (e.g. a PAN inside a vehicle). On the other hand, the logical nesting is not assuming the physical containing relation between the NEMOs. For example, in an area where a NEMO cannot access to the Internet like a tunnel, the NEMO may be attached to its neighbor NEMO to access to the Internet. This situation will cause logical nesting of NEMOs. Therefore, the degree of nesting can be increased to more than two levels, and nested NEMO optimization should be achieved for commercial deployment of NEMO. This memo is especially interested in nested NEMO optimization. =>I don't understand the logical nesting. In this draft ,you give a exampl for explaining it , =>and I am mazed because of your the example. Regards Michael From nemo-bounces@ietf.org Wed Jun 21 23:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFT5-0006FH-IR; Wed, 21 Jun 2006 23:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFT3-0006FC-S5 for nemo@ietf.org; Wed, 21 Jun 2006 23:02:53 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFT2-0005yT-2P for nemo@ietf.org; Wed, 21 Jun 2006 23:02:53 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J180040AR1RXS@szxga01-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 11:01:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J180069WR1Q70@szxga01-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 11:01:03 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J18006EJRGSMM@szxml04-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 11:10:07 +0800 (CST) Date: Thu, 22 Jun 2006 10:59:18 +0800 From: Michael Ye Subject: RE: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt In-reply-to: <001901c695a6$9265c250$c92ca40a@china.huawei.com> To: hscho@mmlab.snu.ac.kr Message-id: <001d01c695a7$dac8af20$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaVppIlSWo95QcRQ5SXPwewTJxe3QAAMl5Q X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Hosik Cho, In section 3, One of the basic concept of network mobility is the mobiltity transparency. The mobility transparency means that an MR hides its movement to the MNNs. The only entity that knows the movement of NEMO is MR and it aggregate the location registration of underlaying VMNs and sub-MRs. However, as we take care of the nested NEMO, the mobility transparency makes the route optimization of nested NEMO too difficult. Therefore, it is needed to compare the pros and cons about holding the mobilty transparency. => Perhaps it is good idea,but it is not good realization or it is an impossible realization. Regards Michael -----Original Message----- From: Michael Ye [mailto:yechengping@huawei.com] Sent: Thursday, June 22, 2006 10:50 AM To: hscho@mmlab.snu.ac.kr Cc: nemo@ietf.org Subject: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt Hi Hosik Cho, I just wonder at your draft. In section 2.1, One possible solution is to adopt mobile IPv6 style route optimization by sending BU to CN. However, this approach can result in the massively occurred binding update messages at the same time, so called binding update storm (BU storm) since there will be many MNNs inside the NEMO. =>According to RFC3775, a MN must send BU to CN if it handles route optimization. =>So many MNNs does not derectly lead the "BU storm" you called. In section 2.2 The nested NEMO optimization does not seek to solve the inefficiency of the NEMO basic support protocol. In the nested NEMO, the inefficiency is proportional to the nested level of the NEMO without any measure. The nested NEMO can have arbitrary levels of nesting. It is thought that there are two types of nesting: physical nesting and logical nesting. physical nesting means a NEMO getting into another NEMO (e.g. a PAN inside a vehicle). On the other hand, the logical nesting is not assuming the physical containing relation between the NEMOs. For example, in an area where a NEMO cannot access to the Internet like a tunnel, the NEMO may be attached to its neighbor NEMO to access to the Internet. This situation will cause logical nesting of NEMOs. Therefore, the degree of nesting can be increased to more than two levels, and nested NEMO optimization should be achieved for commercial deployment of NEMO. This memo is especially interested in nested NEMO optimization. =>I don't understand the logical nesting. In this draft ,you give a exampl for explaining it , =>and I am mazed because of your the example. Regards Michael From happy50jetkool@yahoo.co.uk Wed Jun 21 23:32:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtFvV-0003Em-8C for NEMO-ARCHIVE@LISTS.IETF.ORG; Wed, 21 Jun 2006 23:32:17 -0400 Received: from [218.8.141.61] (helo=ocn.ne.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtFvT-0000mU-1S for NEMO-ARCHIVE@LISTS.IETF.ORG; Wed, 21 Jun 2006 23:32:17 -0400 Subject: =?iso-2022-jp?B?GyRCMEI/NCEmTkk8QSEmN2MwQiROTiIbKEJEVkQgGyRCSE5HZBsoQg==?= From: =?gb2312?B?MjAwMy0wNi0xNCAwMTowMDo0Ng==?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C6922E.BE7E7FB0" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C6922E.BE7E7FB0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 貴方のお探しのタイトル＆お好みの作品きっとみつかります！ 物凄いDVDが満載の無修正アダルト映像販売専門店です。 人気女優「及川奈央」「平井まりあ」「藤井彩」桜田さくら」 援交・ロリータ・アメリカンポルノ・盗撮・アニメなどなど他にも新作が沢山！ マニアを唸らす超激安店、新作入荷次第随時更新中！！ 業界最速のお届けで、画質良好、高品質です！ 他店のものと比べてみてください！！自信があります！ 11時までにご注文していただくと即日配送致します。 在庫10本、業界NO.1 <<安心のお値段です>> 価格　１枚　１０００円　　（５枚お買い上げ毎に１枚サービス） 送料　全国一律１０００円　（手数料込み） ↓ぜひ一度、覗いてみて下さい↓ http://www.acmade.net ------=_NextPart_000_0008_01C6922E.BE7E7FB0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B5.J}$N$*C5$7$N%?%$%H%k!u$*9%$_$N:nIJ$-$C$H$_$D$+$j$^$9!*=1B= (B
=1B$BJ*@($$=1B(BDVD=1B$B$,K~:\$NL5=3D$@5%"%@%k%H1GA|HNGd@lLgE9$G= $9!#=1B(B
=1B$B?M5$=3DwM%!V5Z@nF`1{!W!VJ?0f$^$j$"!W!VF#0f:L!W:yED$5$/$i!W=1B= (B
=1B$B1g8r!&%m%j!<%?!&%"%a%j%+%s%]%k%N!&Ep;#!&%"%K%a$J$I$J$IB>$K$= b?7:n$,Bt;3!*=1B(B
=1B$B%^%K%"$rS9$i$9D67c0BE9!"?7:nF~2Y
=1B$B6H3&:GB.$N$*FO$1$G!"2h
=1B$BB>E9$N$b$N$HHf$Y$F$_$F$/$@$5$$!*!*<+?.$,$"$j$^$9!*=1B(B
11=1B$B;~$^$G$K$4CmJ8$7$F$$$?$@$/$HB(F|G[AwCW$7$^$9!#=1B(B
=1B$B:_8K=1B(B10=1B$BK\!"6H3&=1B(BNO.1
 
<<=1B$B0B?4$N$*CMCJ$G$9=1B(B>>
=1B$B2A3J!!#1Kg!!#1#0#0#01_!!!!!J#5Kg$*Gc$$>e$2Kh$K#1Kg%5!<%S%9!K=1B= (B
=1B$BAwNA!!A49q0lN'#1#0#0#01_!!!J
 
=1B$B"-$<$R0lEY!"GA$$$F$_$F2<$5$$"-=1B(B
http://www.acmade.net
------=_NextPart_000_0008_01C6922E.BE7E7FB0-- From nemo-bounces@ietf.org Thu Jun 22 00:40:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGzJ-0003Yq-52; Thu, 22 Jun 2006 00:40:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtGzH-0003Ye-NB for nemo@ietf.org; Thu, 22 Jun 2006 00:40:15 -0400 Received: from mmlab.snu.ac.kr ([147.46.114.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtGzF-0005Mv-RJ for nemo@ietf.org; Thu, 22 Jun 2006 00:40:15 -0400 Received: from mmlabcydream ([147.46.216.65]) by mmlab.snu.ac.kr (8.13.5/8.12.10) with ESMTP id k5M4dE8e093465; Thu, 22 Jun 2006 13:39:15 +0900 (KST) (envelope-from hscho@mmlab.snu.ac.kr) From: "Hosik Cho" To: "'Michael Ye'" References: <001901c695a6$9265c250$c92ca40a@china.huawei.com> In-Reply-To: <001901c695a6$9265c250$c92ca40a@china.huawei.com> Subject: RE: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt Date: Thu, 22 Jun 2006 13:39:28 +0900 Message-ID: <02d301c695b5$dc3751f0$94a5f5d0$@snu.ac.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcaVppIlSWo95QcRQ5SXPwewTJxe3QACcBcA Content-Language: ko X-Spam-Score: 1.1 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, Please, find in lines. > -----Original Message----- > From: Michael Ye [mailto:yechengping@huawei.com] > Sent: Thursday, June 22, 2006 11:50 AM > To: hscho@mmlab.snu.ac.kr > Cc: nemo@ietf.org > Subject: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt > > > > Hi Hosik Cho, > > I just wonder at your draft. > In section 2.1, > One possible solution is to adopt mobile IPv6 > style route optimization by sending BU to CN. However, this > approach > can result in the massively occurred binding update messages at the > same time, so called binding update storm (BU storm) since there > will > be many MNNs inside the NEMO. > > =>According to RFC3775, a MN must send BU to CN if it handles route > optimization. > =>So many MNNs does not derectly lead the "BU storm" you called. > In my opinion, the mobile IPv6 "style" route optimization in the NEMO context means that the MR send BU directly to the CNs (communicating with its MNNs) as well as its HA to optimize the path from the CN to the MNN. The MR has a responsibility to send BU to the CNs since the MNNs (both VMN and LFN) do not know the mobility of the mobile network (mobility transparency). So if there are N connections through an MR, the MR may send N+1 BUs simultaneously when it changes its point of attachment. The MR is a mobility proxy for the MNNs. > In section 2.2 > > The nested NEMO optimization does not seek to solve the > inefficiency > of the NEMO basic support protocol. In the nested NEMO, the > inefficiency is proportional to the nested level of the NEMO > without > any measure. The nested NEMO can have arbitrary levels of nesting. > It is thought that there are two types of nesting: physical > nesting > and logical nesting. physical nesting means a NEMO getting into > another NEMO (e.g. a PAN inside a vehicle). On the other hand, the > logical nesting is not assuming the physical containing relation > between the NEMOs. For example, in an area where a NEMO cannot > access to the Internet like a tunnel, the NEMO may be attached to > its > neighbor NEMO to access to the Internet. This situation will cause > logical nesting of NEMOs. Therefore, the degree of nesting can be > increased to more than two levels, and nested NEMO optimization > should be achieved for commercial deployment of NEMO. This memo is > especially interested in nested NEMO optimization. > > =>I don't understand the logical nesting. In this draft ,you give a > exampl for explaining it , > =>and I am mazed because of your the example. > I'm so sorry for my insufficient explanation. :-) The physical nesting is reasonable since it is the usual meaning of the nesting. The logical nesting (I'm also not sure the expression is proper.) means that an MR uses the nearby MR to get an access to the Internet (without any concerns about authentication). If there are two PANs, each PAN can be connected to the AR by itself or one PAN can be a sub-NEMO of another PAN. In latter scenario, there are no physical nesting like taking a vehicle. However, the two PANs are logically nested. I hope it has been explained more clearly. > Regards > Michael > Regards, Hosik From nemo-bounces@ietf.org Thu Jun 22 01:50:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtI5c-00079N-KM; Thu, 22 Jun 2006 01:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtI5a-0006z5-9n for nemo@ietf.org; Thu, 22 Jun 2006 01:50:50 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtI5X-00033k-9v for nemo@ietf.org; Thu, 22 Jun 2006 01:50:50 -0400 Received: (qmail 30505 invoked from network); 22 Jun 2006 14:50:43 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 22 Jun 2006 14:50:43 +0900 To: nemo@ietf.org From: "K.Kawaguchi" Message-Id: <200606221450.GEI26061.HJBUBXLV@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Thu, 22 Jun 2006 14:50:41 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [nemo] IPv6 Ready Logo Phase-2 NEMO Public Review X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello. I inform of "IPv6 Ready Logo Phase-2 NEMO". As you know, we have been executing 'IPv6 Ready Logo Phase-2 MIPv6'. Now, we are newly advancing the preparation for 'IPv6 Ready Logo Phase-2 NEMO'. This time, we began the public review of NEMO program. This test conforms to RFC3963. The test content is 'MUST' and 'SHOULD' in RFC. We will reflect the opinion from you and begin 'IPv6 Ready Logo Phase-2 NEMO'. Please visit by all means if it is interested. IPv6 Ready Logo front page: http://www.ipv6ready.org/frames.html NEMO public review page: http://www.ipv6ready.org/announcement/public_review20060621_nemo.html Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp From nemo-bounces@ietf.org Thu Jun 22 02:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIc0-0000Pt-PJ; Thu, 22 Jun 2006 02:24:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIbz-0000Po-Vx for nemo@ietf.org; Thu, 22 Jun 2006 02:24:19 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIbx-0004xe-Kd for nemo@ietf.org; Thu, 22 Jun 2006 02:24:19 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1900DL80H83X@szxga01-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 14:24:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J19002Y00H8AS@szxga01-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 14:24:44 +0800 (CST) Received: from y52774 ([10.164.44.201]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J19002680H02Q@szxml03-in.huawei.com> for nemo@ietf.org; Thu, 22 Jun 2006 14:24:39 +0800 (CST) Date: Thu, 22 Jun 2006 14:22:58 +0800 From: Michael Ye Subject: RE: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt In-reply-to: <02d301c695b5$dc3751f0$94a5f5d0$@snu.ac.kr> To: 'Hosik Cho' Message-id: <002e01c695c4$4e8fbf90$c92ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcaVppIlSWo95QcRQ5SXPwewTJxe3QACcBcAAATJY6A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Cho, -----Original Message----- From: Hosik Cho [mailto:hscho@mmlab.snu.ac.kr] Sent: Thursday, June 22, 2006 12:39 PM To: 'Michael Ye' Cc: nemo@ietf.org Subject: RE: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt Hi, Please, find in lines. > -----Original Message----- > From: Michael Ye [mailto:yechengping@huawei.com] > Sent: Thursday, June 22, 2006 11:50 AM > To: hscho@mmlab.snu.ac.kr > Cc: nemo@ietf.org > Subject: [nemo]:draft-cho-nemo-ro-expected-properties-00.txt > > > > Hi Hosik Cho, > > I just wonder at your draft. > In section 2.1, > One possible solution is to adopt mobile IPv6 > style route optimization by sending BU to CN. However, this > approach > can result in the massively occurred binding update messages at the > same time, so called binding update storm (BU storm) since there > will > be many MNNs inside the NEMO. > > =>According to RFC3775, a MN must send BU to CN if it handles route > optimization. > =>So many MNNs does not derectly lead the "BU storm" you called. > In my opinion, the mobile IPv6 "style" route optimization in the NEMO context means that the MR send BU directly to the CNs (communicating with its MNNs) as well as its HA to optimize the path from the CN to the MNN. The MR has a responsibility to send BU to the CNs since the MNNs (both VMN and LFN) do not know the mobility of the mobile network (mobility transparency). So if there are N connections through an MR, the MR may send N+1 BUs simultaneously when it changes its point of attachment. The MR is a mobility proxy for the MNNs. ==============> You should present your RO method clearly. Your method maybe lead to BU storm, but Not ALL RO methods leads to it, I think. > In section 2.2 > > The nested NEMO optimization does not seek to solve the inefficiency > of the NEMO basic support protocol. In the nested NEMO, the > inefficiency is proportional to the nested level of the NEMO > without > any measure. The nested NEMO can have arbitrary levels of nesting. > It is thought that there are two types of nesting: physical > nesting > and logical nesting. physical nesting means a NEMO getting into > another NEMO (e.g. a PAN inside a vehicle). On the other hand, the > logical nesting is not assuming the physical containing relation > between the NEMOs. For example, in an area where a NEMO cannot > access to the Internet like a tunnel, the NEMO may be attached to > its > neighbor NEMO to access to the Internet. This situation will cause > logical nesting of NEMOs. Therefore, the degree of nesting can be > increased to more than two levels, and nested NEMO optimization > should be achieved for commercial deployment of NEMO. This memo is > especially interested in nested NEMO optimization. > > =>I don't understand the logical nesting. In this draft ,you give a > exampl for explaining it , > =>and I am mazed because of your the example. > I'm so sorry for my insufficient explanation. :-) The physical nesting is reasonable since it is the usual meaning of the nesting. The logical nesting (I'm also not sure the expression is proper.) means that an MR uses the nearby MR to get an access to the Internet (without any concerns about authentication). If there are two PANs, each PAN can be connected to the AR by itself or one PAN can be a sub-NEMO of another PAN. In latter scenario, there are no physical nesting like taking a vehicle. However, the two PANs are logically nested. I hope it has been explained more clearly. ===========> :-) > Regards > Michael > Regards, Hosik Regards Michael From nemo-bounces@ietf.org Thu Jun 22 15:02:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtURP-0000hy-Bg; Thu, 22 Jun 2006 15:02:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtURN-0000gI-S9 for nemo@ietf.org; Thu, 22 Jun 2006 15:02:09 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtURM-00024F-DD for nemo@ietf.org; Thu, 22 Jun 2006 15:02:09 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7022F95C3C; Thu, 22 Jun 2006 21:02:07 +0200 (CEST) Received: from [163.117.203.126] (unknown [163.117.203.126]) by smtp02.uc3m.es (Postfix) with ESMTP id D595895C03; Thu, 22 Jun 2006 21:02:05 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <588f90fb7d6c00c8f4ed71a1720e0488@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] New draft submitted:draft-ryu-nemo-ingress-filtering-00.txt Date: Thu, 22 Jun 2006 22:02:03 +0300 To: "Jiho Ryu" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, one question about this draft... are the the ideas presented in the =20 draft basically those described in Appendix B. Nested Tunneling for =20= Fault Tolerance of draft-ietf-nemo-multihoming-issues-05? Regards, marcelo El 21/06/2006, a las 4:56, Jiho Ryu escribi=F3: > Dear all, > > We have submitted a new draft about solution of ingress filtering in =20= > multihomed NEMO. > > Here is an abstract: > > > In this draft, a solution of the ingress filtering problem is > proposed for a NEMO with multiple mobile routers. Extending the > multiple care-of address registration mechanism and introducing a > > =A0"prefix peer" relationship among the mobile routers, we can solve = =20 > the > ingress filtering problem in a NEMO with multiple mobile routers. > > A URL for this draft is: > > http://www.ietf.org/internet-drafts/draft-ryu-nemo-ingress-filtering=20= > -00.txt > > Any questions and comments are welcome at anytime. :-) > > > Regards > Jiho. > > > > --=20 > Ryu, Jiho > Master Course > Multimedia and Mobile Communications Lab., > School of Computer Science and Engineering > Seoul National University > > From nemo-bounces@ietf.org Thu Jun 22 19:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY8C-0001NQ-96; Thu, 22 Jun 2006 18:58:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXzz-000414-L5; Thu, 22 Jun 2006 18:50:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXzz-0003Gi-Ii; Thu, 22 Jun 2006 18:50:07 -0400 Received: from pine.neustar.com ([209.173.57.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtXzu-0006il-TC; Thu, 22 Jun 2006 18:50:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Hp029341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007ts-Ax; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-06.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-multihoming-issues-06.txt Pages : 46 Date : 2006-6-22 This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-06.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: <2006-6-22161506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22161506.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Sat Jun 24 09:10:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu7uX-0006X6-Nm; Sat, 24 Jun 2006 09:10:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu7uW-0006X1-He for nemo@ietf.org; Sat, 24 Jun 2006 09:10:52 -0400 Received: from [2001:660:7301:3192:211:43ff:fea3:7e4b] (helo=laposte.rennes.enst-bretagne.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu7uT-00072G-VC for nemo@ietf.org; Sat, 24 Jun 2006 09:10:52 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.10.03) with ESMTP id k5ODAifb019637; Sat, 24 Jun 2006 15:10:44 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.13.4/8.13.4/2004.09.01) with ESMTP id k5ODAdtf019625; Sat, 24 Jun 2006 15:10:39 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k5ODAZeO051592; Sat, 24 Jun 2006 15:10:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200606241310.k5ODAZeO051592@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "K.Kawaguchi" Subject: Re: [nemo] IPv6 Ready Logo Phase-2 NEMO Public Review In-reply-to: Your message of Thu, 22 Jun 2006 14:50:41 +0900. <200606221450.GEI26061.HJBUBXLV@ysknet.co.jp> Date: Sat, 24 Jun 2006 15:10:35 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: -2.8 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: nemo@ietf.org, ipv6ready-tech@ipv6ready.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In your previous mail you wrote: NEMO public review page: http://www.ipv6ready.org/announcement/public_review20060621_nemo.html => just a simple statement: it is a shame that the dynamic IPsec keying is not included (IMHO it should be required but it is not even in advanced features). Regards Francis.Dupont@point6.net From nemo-bounces@ietf.org Mon Jun 26 04:16:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumGJ-0003PJ-Ck; Mon, 26 Jun 2006 04:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumGI-0003PE-C8 for nemo@ietf.org; Mon, 26 Jun 2006 04:16:02 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumGF-00082B-Nq for nemo@ietf.org; Mon, 26 Jun 2006 04:16:02 -0400 Received: by nf-out-0910.google.com with SMTP id d4so829184nfe for ; Mon, 26 Jun 2006 01:15:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Hdg/Uqi7W+v5fuJAHEdjgrWNh8uwH4MQARfWdZg4Yi8GC1PBNQ05IvzT9sXuWrsg5X+WKJsf/tudQfJqoRBc8qmLzoNuNSexdus60REVBKmP/trUGVcdSTOOM8FzyO7gr1KCuP6RokQcaId6kOXPqzL8Iz1tPjJ4stt5R2J0Gqk= Received: by 10.48.232.15 with SMTP id e15mr4606801nfh; Mon, 26 Jun 2006 01:15:58 -0700 (PDT) Received: by 10.48.199.17 with HTTP; Mon, 26 Jun 2006 01:15:58 -0700 (PDT) Message-ID: Date: Mon, 26 Jun 2006 17:15:58 +0900 From: "Jiho Ryu" To: "marcelo bagnulo braun" , nemo@ietf.org Subject: Re: [nemo] New draft submitted:draft-ryu-nemo-ingress-filtering-00.txt In-Reply-To: <588f90fb7d6c00c8f4ed71a1720e0488@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_45_3335277.1151309758065" References: <588f90fb7d6c00c8f4ed71a1720e0488@it.uc3m.es> X-Google-Sender-Auth: 30ad94b4119c52f0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org ------=_Part_45_3335277.1151309758065 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIG1hcmNlbG8uCgpTb3JyeSBhYm91dCBteSBsYXp5IHJlc3BvbnNlLgpJIHRoaW5rIHRoZSBi YXNpYyBpZGVhIGlzIHNpbWlsYXIgdG8gdGhhdC4KT3VyIHByb3Bvc2VkIHNjaGVtZSBjYW4gYmUg dXNlZCBub3Qgb25seSBhbiBpbnRlcmZhY2UgZG93biBjYXNlIGJ1dCBhbHNvCmhhbmRvdmVyIGNh c2UgZm9yIGJ5cGFzc2luZyBpbmdyZXNzIGZpbHRlcmluZy4KSWYgeW91IGhhdmUgYW55IG90aGVy IHF1ZXRpb25zLCBJIGRvbid0IG1pbmQgYW5zd2VyaW5nIHRoZW0uCgpSZWdhcmRzLCBKaWhvLgoK CjIwMDYvNi8yMywgbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+Ogo+ Cj4gSGksCj4KPiBvbmUgcXVlc3Rpb24gYWJvdXQgdGhpcyBkcmFmdC4uLiBhcmUgdGhlIHRoZSBp ZGVhcyBwcmVzZW50ZWQgaW4gdGhlCj4gZHJhZnQgYmFzaWNhbGx5IHRob3NlIGRlc2NyaWJlZCBp biAgQXBwZW5kaXggQi4gIE5lc3RlZCBUdW5uZWxpbmcgZm9yCj4gRmF1bHQgVG9sZXJhbmNlIG9m IGRyYWZ0LWlldGYtbmVtby1tdWx0aWhvbWluZy1pc3N1ZXMtMDU/Cj4KPiBSZWdhcmRzLCBtYXJj ZWxvCj4KPgo+IEVsIDIxLzA2LzIwMDYsIGEgbGFzIDQ6NTYsIEppaG8gUnl1IGVzY3JpYmnDszoK Pgo+ID4gRGVhciBhbGwsCj4gPgo+ID4gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgYWJv dXQgc29sdXRpb24gb2YgaW5ncmVzcyBmaWx0ZXJpbmcgaW4KPiA+IG11bHRpaG9tZWQgTkVNTy4K PiA+Cj4gPiBIZXJlIGlzIGFuIGFic3RyYWN0Ogo+ID4KPiA+Cj4gPiAgICBJbiB0aGlzIGRyYWZ0 LCBhIHNvbHV0aW9uIG9mIHRoZSBpbmdyZXNzIGZpbHRlcmluZyBwcm9ibGVtIGlzCj4gPiAgICBw cm9wb3NlZCBmb3IgYSBORU1PIHdpdGggbXVsdGlwbGUgbW9iaWxlIHJvdXRlcnMuICBFeHRlbmRp bmcgdGhlCj4gPiAgICBtdWx0aXBsZSBjYXJlLW9mIGFkZHJlc3MgcmVnaXN0cmF0aW9uIG1lY2hh bmlzbSBhbmQgaW50cm9kdWNpbmcgYQo+ID4KPiA+ICAgInByZWZpeCBwZWVyIiByZWxhdGlvbnNo aXAgYW1vbmcgdGhlIG1vYmlsZSByb3V0ZXJzLCB3ZSBjYW4gc29sdmUKPiA+IHRoZQo+ID4gICAg aW5ncmVzcyBmaWx0ZXJpbmcgcHJvYmxlbSBpbiBhIE5FTU8gd2l0aCBtdWx0aXBsZSBtb2JpbGUg cm91dGVycy4KPiA+Cj4gPiBBIFVSTCBmb3IgdGhpcyBkcmFmdCBpczoKPiA+Cj4gPiBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yeXUtbmVtby1pbmdyZXNzLWZpbHRl cmluZwo+ID4gLTAwLnR4dAo+ID4KPiA+IEFueSBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSB3 ZWxjb21lIGF0IGFueXRpbWUuICA6LSkKPiA+Cj4gPgo+ID4gUmVnYXJkcwo+ID4gSmloby4KPiA+ Cj4gPgo+ID4KPiA+IC0tCj4gPiBSeXUsIEppaG8KPiA+IE1hc3RlciBDb3Vyc2UKPiA+IE11bHRp bWVkaWEgYW5kIE1vYmlsZSBDb21tdW5pY2F0aW9ucyBMYWIuLAo+ID4gU2Nob29sIG9mIENvbXB1 dGVyIFNjaWVuY2UgYW5kIEVuZ2luZWVyaW5nCj4gPiBTZW91bCBOYXRpb25hbCBVbml2ZXJzaXR5 Cj4gPgo+ID4KPgo+CgoKLS0gCi3sp4DtmLgg65Oc66a8LQo= ------=_Part_45_3335277.1151309758065 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIG1hcmNlbG8uPGJyPjxicj5Tb3JyeSBhYm91dCBteSA8c3BhbiBzdHlsZT0id2lkdGg6IDUw MHB4OyI+PGZvbnQgc2l6ZT0iLTEiPjxzcGFuPmxhenk8L3NwYW4+IHJlc3BvbnNlLjwvZm9udD48 L3NwYW4+PGJyPkkgdGhpbmsgdGhlIGJhc2ljIGlkZWEgaXMgc2ltaWxhciB0byB0aGF0LiA8YnI+ T3VyIHByb3Bvc2VkIHNjaGVtZSBjYW4gYmUgdXNlZCBub3Qgb25seSBhbiBpbnRlcmZhY2UgZG93 biBjYXNlIGJ1dCBhbHNvIGhhbmRvdmVyIGNhc2UgZm9yIGJ5cGFzc2luZyBpbmdyZXNzIGZpbHRl cmluZy4KPGJyPklmIHlvdSBoYXZlIGFueSBvdGhlciBxdWV0aW9ucywgPGZvbnQgc2l6ZT0iLTEi PiAKSSBkb24ndCBtaW5kIGFuc3dlcmluZyB0aGVtLjxicj48YnI+PC9mb250PlJlZ2FyZHMsIEpp aG8uPGJyPjxicj48YnI+PGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMDYvNi8yMywg bWFyY2VsbyBiYWdudWxvIGJyYXVuICZsdDs8YSBocmVmPSJtYWlsdG86bWFyY2Vsb0BpdC51YzNt LmVzIj5tYXJjZWxvQGl0LnVjM20uZXM8L2E+Jmd0Ozo8L3NwYW4+PGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQs IDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+Ckhp LDxicj48YnI+b25lIHF1ZXN0aW9uIGFib3V0IHRoaXMgZHJhZnQuLi4gYXJlIHRoZSB0aGUgaWRl YXMgcHJlc2VudGVkIGluIHRoZTxicj5kcmFmdCBiYXNpY2FsbHkgdGhvc2UgZGVzY3JpYmVkIGlu Jm5ic3A7Jm5ic3A7QXBwZW5kaXggQi4mbmJzcDsmbmJzcDtOZXN0ZWQgVHVubmVsaW5nIGZvcjxi cj5GYXVsdCBUb2xlcmFuY2Ugb2YgZHJhZnQtaWV0Zi1uZW1vLW11bHRpaG9taW5nLWlzc3Vlcy0w NT88YnI+PGJyPlJlZ2FyZHMsIG1hcmNlbG8KPGJyPjxicj48YnI+RWwgMjEvMDYvMjAwNiwgYSBs YXMgNDo1NiwgSmlobyBSeXUgZXNjcmliacOzOjxicj48YnI+Jmd0OyBEZWFyIGFsbCw8YnI+Jmd0 Ozxicj4mZ3Q7IFdlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGFib3V0IHNvbHV0aW9uIG9m IGluZ3Jlc3MgZmlsdGVyaW5nIGluPGJyPiZndDsgbXVsdGlob21lZCBORU1PLjxicj4mZ3Q7PGJy PiZndDsgSGVyZSBpcyBhbiBhYnN0cmFjdDoKPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4gdGhpcyBkcmFmdCwgYSBzb2x1dGlvbiBvZiB0aGUgaW5ncmVz cyBmaWx0ZXJpbmcgcHJvYmxlbSBpczxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJv cG9zZWQgZm9yIGEgTkVNTyB3aXRoIG11bHRpcGxlIG1vYmlsZSByb3V0ZXJzLiZuYnNwOyZuYnNw O0V4dGVuZGluZyB0aGU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO211bHRpcGxlIGNh cmUtb2YgYWRkcmVzcyByZWdpc3RyYXRpb24gbWVjaGFuaXNtIGFuZCBpbnRyb2R1Y2luZyBhCjxi cj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsgJnF1b3Q7cHJlZml4IHBlZXImcXVvdDsgcmVsYXRp b25zaGlwIGFtb25nIHRoZSBtb2JpbGUgcm91dGVycywgd2UgY2FuIHNvbHZlPGJyPiZndDsgdGhl PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpbmdyZXNzIGZpbHRlcmluZyBwcm9ibGVt IGluIGEgTkVNTyB3aXRoIG11bHRpcGxlIG1vYmlsZSByb3V0ZXJzLjxicj4mZ3Q7PGJyPiZndDsg QSBVUkwgZm9yIHRoaXMgZHJhZnQgaXM6Cjxicj4mZ3Q7PGJyPiZndDsgPGEgaHJlZj0iaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcnl1LW5lbW8taW5ncmVzcy1maWx0 ZXJpbmciPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJ5dS1uZW1v LWluZ3Jlc3MtZmlsdGVyaW5nPC9hPjxicj4mZ3Q7IC0wMC50eHQ8YnI+Jmd0Ozxicj4mZ3Q7IEFu eSBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lIGF0IGFueXRpbWUuJm5ic3A7Jm5i c3A7Oi0pCjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBSZWdhcmRzPGJyPiZndDsgSmloby48YnI+ Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyAtLTxicj4mZ3Q7IFJ5dSwgSmlobzxicj4mZ3Q7 IE1hc3RlciBDb3Vyc2U8YnI+Jmd0OyBNdWx0aW1lZGlhIGFuZCBNb2JpbGUgQ29tbXVuaWNhdGlv bnMgTGFiLiw8YnI+Jmd0OyBTY2hvb2wgb2YgQ29tcHV0ZXIgU2NpZW5jZSBhbmQgRW5naW5lZXJp bmcKPGJyPiZndDsgU2VvdWwgTmF0aW9uYWwgVW5pdmVyc2l0eTxicj4mZ3Q7PGJyPiZndDs8YnI+ PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+Leyn gO2YuCDrk5zrprwtCg== ------=_Part_45_3335277.1151309758065-- From nemo-bounces@ietf.org Mon Jun 26 12:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutzD-0000Mu-4v; Mon, 26 Jun 2006 12:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutzB-0000Mm-SW for nemo@ietf.org; Mon, 26 Jun 2006 12:30:53 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futz8-00068I-Lr for nemo@ietf.org; Mon, 26 Jun 2006 12:30:53 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k5QGUoND010753 for ; Mon, 26 Jun 2006 09:30:50 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k5QGUlw5017771 for ; Mon, 26 Jun 2006 11:30:48 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AB2AE865980 for ; Mon, 26 Jun 2006 18:30:44 +0200 (CEST) Message-ID: <44A00BB1.1000404@motorola.com> Date: Mon, 26 Jun 2006 18:30:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ml-nemo WG Content-Type: multipart/mixed; boundary="------------010006030804090505050003" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9afae6ba567a505fffabb76c1477f305 Subject: [nemo] Submitted NEMOv4 draft-ietf-nemo-v4-base-01.txt, with changelog X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. --------------010006030804090505050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear NEMO WG members, I've just submitted draft-ietf-nemo-v4-base-01.txt. Following discussions since last meeting the modifications are minor, here's the changelog: -removed error code HA_MOBNET_UNSUPPORTED. -changed all values to be assigned by IANA, from specific numbers to "TBA" (To Be Assigned). -substituted "egress interface" for "roaming interface". -changed HA behaviour upon reception of MNPs. In 00 the HA replied positively only if all MNPs in RegReq were valid, in 01 a reply is constructed specifying which MNP was valid and which not. -clarified a 3-line paragraph saying that RegRep may contain both implicit and explicit acknowledgements. A confirmation from the people who raised these issues would be great (namely GT and HL). Alex --------------010006030804090505050003 Content-Type: text/plain; name="draft-ietf-nemo-v4-base-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-nemo-v4-base-01.txt" Network Working Group K. Leung Internet-Draft G. Dommety Expires: December 26, 2006 Cisco Systems V. Narayanan QUALCOMM, Inc. A. Petrescu Motorola June 26, 2006 IPv4 Network Mobility (NEMO) Basic Support Protocol draft-ietf-nemo-v4-base-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. Leung, et al. Expires December 26, 2006 [Page 1] Internet-Draft Mobile Router June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 4 4.1. Mobile Network Request Extension . . . . . . . . . . . . . 4 4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 5 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 6 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 7 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 7 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 8 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 8 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 8 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 9 6.4. Advertising Mobile Network Reachability . . . . . . . . .10 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . .10 6.6. Sending Registration Replies . . . . . . . . . . . . . . .10 6.7. Mobile Network Prefix De-registration . . . . . . . . . .11 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . .11 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . .11 9. Security Considerations . . . . . . . . . . . . . . . . . . .12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .13 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . .14 12.1. Normative References . . . . . . . . . . . . . . . . . . .14 12.2. Informative References . . . . . . . . . . . . . . . . . .14 13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .15 Intellectual Property and Copyright Statements . . . . . . . . . .16 1. Introduction This document describes protocol extensions to Mobile IPv4 ([RFC3344]) to enable support for Mobile Networks. A Mobile Network is defined as a network segment or subnet that can change its point of attachment to the routing infrastructure. Such movement is performed by a Mobile Router, which is the mobility entity that provides connectivity and reachability as well as session continuity for all the nodes in the Mobile Network. The Mobile Router typically serves as the default gateway for the devices on the Mobile Network. Mobility for the Mobile Network is supported by the Mobile Router registering the point of attachment to its Home Agent. This signaling sets up the tunnel between the two entities. The Mobile Networks (either implicitly configured on the Home Agent or explicitly identified by the Mobile Router) are advertised by the Home Agent for route propagation. Traffic to and from nodes in the Mobile Network are tunneled by the Home Agent to the Mobile Router, and vice versa. Though packets from the Mobile Network can be forwarded directly without tunneling when reverse tunneling is not enabled, reachability is still subject to ingress filtering conditions for the path in this case. Leung, et al. Expires December 26, 2006 [Page 2] Internet-Draft Mobile Router June 2006 This document specifies an additional tunnel between Mobile Router's Home Address and the Home Agent. This tunnel is encapsulated within the normal tunnel between the Care-of Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel between the Mobile Router and Home Agent is needed to allow the Foreign Agent to direct the decapsulated packet to the proper visiting Mobile Router. However, in Collocated CoA mode, the additional tunnel is not essential and can be eliminated because the Mobile Router is the recipient of the encapsulated packets for the Mobile Network. All traffic between the nodes in the Mobile Network and Correspondent Nodes passes through the Home Agent. This document does not cover route optimization of this traffic. A similar protocol has been documented in [RFC3963] for supporting IPv6 moving networks with Mobile IPv6 extensions. Multihoming for Mobile Routers is outside of scope of this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Terminology for network mobility support is defined in [RFC3344]. In addition, this document defines the following terms. Mobile Network Prefix The network prefix of the subnet delegated to a Mobile Router as the Mobile Network. Prefix Table A list of Mobile Network Prefixes indexed by the Home Address of a Mobile Router. The Home Agent manages and uses Prefix Table to determine which Mobile Network Prefixes belong to a particular Mobile Router. 3. Requirements Although Mobile IPv4 stated that Mobile Network can be supported by the Mobile Router and Home Agent using static configuration or running a routing protocol, there is no solution for explicit registration of the Mobile Networks served by the Mobile Router. The following requirements for Mobile Network support are enumerated: o A Mobile Router should be able to operate in explicit or implicit mode. A Mobile Router may explicitly inform the Home Agent which Mobile Network(s) need to be propagated via routing protocol. A Mobile Router may also function in implicit mode, where the Home Agent may learn the mobile networks through other means, such as from the AAA server or via pre-configuration. Leung, et al. Expires December 26, 2006 [Page 3] Internet-Draft Mobile Router June 2006 o The Mobile Network should be supported using Foreign Agents that are compliant to RFC 3344 without any changes. o The mobile network should allow Fixed nodes, Mobile Nodes, or Mobile Routers to be on it. 4. Mobile Network Extensions 4.1. Mobile Network Request Extension For Explicit Mode, the Mobile Router informs the Home Agent about the Mobile Network Prefixes during registration. The Registration Request contains zero, one or several Mobile Network Request extensions in addition to any other extensions defined by or in the context of ([RFC3344]). When several Mobile Networks are needed to be registered, each is included in a separate Mobile Network Request extension, with its own Type, Length, Sub-Type, Prefix Length and Prefix fields. A Mobile Network Request extension is encoded in Type-Length-Value (TLV) format and respects the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Mobile Network Extension (skippable type range to be assigned by IANA) Length: 6 Sub-Type: 1 (Mobile Network Request) Prefix Length: 8-bit unsigned integer indicating the number of bits covering the network part of the address contained in the Prefix field. Prefix: 32-bit unsigned integer in network byte-order containing an IPv4 address whose first Prefix Length bits make up the Mobile Network Prefix. Leung, et al. Expires December 26, 2006 [Page 4] Internet-Draft Mobile Router June 2006 4.2. Mobile Network Acknowledgement Extension The Registration Reply contains zero, one or several Mobile Network Acknowledgement extensions in addition to any other extensions defined by or in the context of ([RFC3344]). For Implicit Mode, the Mobile Network Acknowledgement informs the Mobile Router the prefixes served by the Home Agent. Policies such as permitting only traffic from these Mobile Networks to be tunneled to the Home Agent may be applied by the Mobile Router. For Explicit Mode, when several Mobile Networks are needed to be acknowledged explicitly, each is included in a separate Mobile Network Acknowledgement extension, with its own Type, Sub-Type, Length and Prefix Length fields. Optionally, all requested Mobile Networks could be acknowledged using only one Mobile Network Acknowledgement extension with "Prefix Length" and "Prefix" fields set to zero. At least one Mobile Network Acknowledgement extension MUST be in a successful Registration Reply to indicate to the Mobile Router that the Mobile Network Request extension was processed, thereby not skipped by the Home Agent. A Registration Reply may contain any non-zero number of Explicit Mode and Implicit Mode Acknowledgements sub-types. Both sub-types can be present in a single Registration Reply. A Mobile Network Acknowledgement extension is encoded in Type-Length-Value (TLV) format and respects the following format: When the registration is denied with code HA_MOBNET_ERROR, the Code field in the extension provides the reason for the failure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Reserved | Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: Mobile Network Extension (skippable type range to be assigned by IANA) Length: 8 Sub-Type: TBA (Explicit Mode Acknowledgement) TBA (Implicit Mode Acknowledgement) Leung, et al. Expires December 26, 2006 [Page 5] Internet-Draft Mobile Router June 2006 Code: Value indicating success or failure. 0 Success TBA Invalid prefix (MOBNET_INVALID_PREFIX_LEN) TBA MR is not authorized for prefix (MOBNET_UNAUTHORIZED) TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) Prefix Length: 8-bit unsigned integer indicating the number of bits covering the network part of the address contained in the Prefix field. Reserved: Sent as zero; ignored on reception. Prefix: 32-bit unsigned integer in network byte-order containing an IPv4 address whose first Prefix Length bits make up the Mobile Network Prefix. 5. Mobile Router Operation A Mobile Router's operation is generally derived from the behavior of a Mobile Node, as set in ([RFC3344]). In addition to maintaining mobility bindings for its Home Address, the Mobile Router, together with the Home Agent, maintains forwarding information for the Mobile Network Prefix(es) assigned to the Mobile Router. A Mobile Router SHOULD set the 'T' bit to 1 in all Registration Request messages it sends to indicate the need for reverse tunnels for all traffic. Without reverse tunnels, all the traffic from the mobile network will be subject to ingress filtering in the visited networks. Upon reception of successful registration reply, the Mobile Router processes the registration in accordance to RFC 3344. In addition, the following steps are taken: o Check for Mobile Network Acknowledgement extension(s) in Registration Reply o Create tunnel to the Home Agent if registered in reverse tunneling mode o Set up default route via this tunnel or egress interface when registered with or without reverse tunneling, respectively In accordance with this specification, a Mobile Router may operate in one of the following two modes: explicit and implicit. In explicit mode, the Mobile Router includes Mobile Network Prefix information in Leung, et al. Expires December 26, 2006 [Page 6] Internet-Draft Mobile Router June 2006 all Registration Requests (as Mobile Network Request extensions), while in implicit mode it does not include this information in any Registration Request. In this latter case, the Home Agent obtains the Mobile Network Prefixes by other means than Mobile IP. A Mobile Router can obtain a Collocated or Foreign Agent Care-of- Address while operating in explicit or implicit modes. For de-registration, the Mobile Router sends a registration request with lifetime set to zero without any Mobile Network Request extensions. 5.1. Error Processing A Mobile Router interprets the values of the Code field in Mobile Network Acknowledgement Extension of the Registration Reply in order to identify any error related to managing the Mobile Network Prefixes by the Home Agent. If the value of the Code field in the Registration Reply is set to HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending Registration Requests with any Mobile Network Prefix extensions to that Home Agent. If the value of the Code field in the Registration Reply is set to HA_MOBNET_ERROR then the Mobile Router MUST stop sending Registration Requests that contain any of the Mobile Network Prefixes that are defined by the values of the fields Prefix and Prefix Length in the Mobile Network Acknowledgement extension. Note that the registration is denied in this case and no forwarding for any Mobile Network Prefixes would be set up by the Home Agent for the Mobile Router. It is possible that the Mobile Router receives a registration reply with no mobile network extensions if the registration was processed by a Mobile IPv4 home agent that does not support this specification at all. In that case, the absence of mobile network extensions must be interpreted by the Mobile Router as the case where the Home Agent does not support mobile networks. All the error code values are TBA (To Be Assigned) subject to IANA allocation. 6. Home Agent Operation 6.1. Summary A Home Agent MUST support all the operations specified in ([RFC3344]) for mobile node support. The Home Agent MUST support both implicit and explicit modes of operation for a Mobile Router. The Home Agent processes the registration in accordance to RFC 3344, which includes route set up to the Mobile Router's home address via the tunnel to the Care-of Address. In addition, for a Mobile Router registering in explicit mode, the following steps are taken: Leung, et al. Expires December 26, 2006 [Page 7] Internet-Draft Mobile Router June 2006 1. Check that the subnet information is valid 2. Ensure such subnet is authorized to be on the Mobile Router 3. Create tunnel to the Mobile Router if it does not already exist 4. Set up route for the subnets via this tunnel 5. Propagate subnet routes via routing protocol 6. Send the Registration Reply with the Mobile Network Acknowledgement extension(s) If there are any subnet routes via the tunnel to the Mobile Router that are not specified in the Mobile Network extensions, these routes are removed. In the case where the Mobile Node is not permitted to act as a Mobile Router, the Home Agent sends a registration denied message with error code HA_MOBNET_DISALLOWED. For a Mobile Router registering in implicit mode, the Home Agent performs steps 3-6 above, once the registration request is processed successfully. For deregistration, the Home Agent removes the tunnel to the Mobile Router and all routes using this tunnel. The Mobile Network extensions are ignored. 6.2. Data Structures 6.2.1. Registration Table The registration table in the Home Agent, in accordance with ([RFC3344]), contains binding information for every mobile node registered with it. In addition to all the parameters specified by ([RFC3344]), the home agent MUST store the mobile network prefixes associated with the Mobile Router in the corresponding registration entry, when the corresponding registration was performed in explicit mode. When the Home Agent is advertising reachability to mobile network prefixes served by a Mobile Router, this information stored in the registration table can be used. 6.2.2. Prefix Table The Home Agent must be able to authorize a Mobile Router for use of mobile network prefixes when the Mobile Router is operating in explicit mode. Also, when the Mobile Router operates in implicit mode, the Home Agent must be able to locate the mobile network prefixes associated with that Mobile Router. The Home Agent may store the home address of the Mobile Router along with the mobile network prefixes associated with that Mobile Router. If the Mobile Router does not have a home address assigned, this table may store the NAI ([RFC2794]) of the Mobile Router that will be used in dynamic home address assignment. Leung, et al. Expires December 26, 2006 [Page 8] Internet-Draft Mobile Router June 2006 6.3. Mobile Network Prefix Registration The Home Agent must process registration requests coming from Mobile Routers in accordance with this section. ([RFC3344]) specifies that the home address of a mobile node registering with a Home Agent must belong to a prefix advertised on the home network. In accordance with this specification, however, the home address must be configured from a prefix that is served by the Home Agent, not necessarily the one on the home network. If the registration request is valid, the Home Agent checks to see if there are any Mobile Network Prefix extensions included in the Registration Request. If so, the Mobile Network Prefix information is obtained from the included extensions, and the Home Address from the Home Address field of the UDP header Registration Request. For every Mobile Network Prefix extension included in the registration request, the Home Agent MUST perform a check against the Prefix Table. If the Prefix Table does not contain at least one entry pairing that Home Address to that Mobile Network Prefix then the check fails, otherwise it succeeds. Following this check against the Prefix Table, the Home Agent MUST construct a Registration Reply containing Mobile Network Acknowledgement extensions. For a Mobile Network Prefix for which the check was unsuccessfull the Code field in the corresponding Mobile Network Acknowledgement extension should be set to MOBNET_UNAUTHORIZED. For a Mobile Network Prefix for which the check was successfull the Code field in the respective Mobile Network Acknowledgement extensions should be set to 0. The Home Agent MUST attempt to set up forwarding for each Mobile Network Prefix extension for which the Prefix Table check was successfull. If the forwarding setup fails for a particular Mobile Network Prefix (for reasons like not enough memory available, or not enough devices available, or other similar) the Code field in the respective Mobile Network Acknowledgement extension should be set to MOBNET_FWDING_SETUP_FAILED. If forwarding and setup was successful for at least one Mobile Network Prefix then the Code field of the Registration Reply message should be set to 0. Otherwise that Code should be HA_MOBNET_ERROR. If the registration request is sent in implicit mode, i.e., without any Mobile Network Request extension, the Home Agent may use pre- configured mobile network prefix information for the Mobile Router to set up forwarding. If the Home Agent is updating an existing binding entry for the Mobile Router, it MUST check all the prefixes in the registration table against the prefixes included in the registration request. If one or more mobile network prefix is missing from the included information in the registration request, it MUST delete those prefixes from the registration table. Also, the Home Agent MUST disable forwarding for those prefixes. Leung, et al. Expires December 26, 2006 [Page 9] Internet-Draft Mobile Router June 2006 If all checks are successful, the Home Agent either creates a new entry(ies) for the Mobile Router or updates an existing binding entry(ies) for it and returns a successful registration reply back to the Mobile Router or the Foreign Agent (if the registration request was received from a Foreign Agent). In accordance with ([RFC3344]), the Home Agent does proxy ARP for the Mobile Router home address, when the Mobile Router home address is derived from the home network. If the 'T' bit is set, the Home Agent creates a bi-directional tunnel for the corresponding mobile network prefixes or updates the existing bi-directional tunnel. This tunnel is maintained independent of the reverse tunnel for the Mobile Router home address itself. 6.4. Advertising Mobile Network Reachability If the mobile network prefixes served by the Home Agent are aggregated with the home network prefix and if the Home Agent is the default router on the home network, the Home Agent does not have to do anything different than normal. The routes for the mobile network prefix are automatically aggregated into the home network prefix. If the Mobile Router updates the mobile network prefix routes via a dynamic routing protocol, the Home Agent SHOULD propagate the routes on the appropriate networks. 6.5. Establishment of Bi-directional Tunnel The Home Agent creates and maintains a bi-directional tunnel for the mobile network prefixes of a Mobile Router registered with it. A home agent supporting IPv4 Mobile Router operation MUST be able to forward packets destined to the mobile network prefixes served by the mobile router to its care-of-address. Also, the Home Agent MUST be able to accept packets tunneled by the Mobile Router with the source address of the outer header is set to the care-of-address of the mobile router and that of the inner header is set to the Mobile Router's home address or an address from one of the registered mobile network prefixes. 6.6. Sending Registration Replies The Home Agents MUST set the status code in the registration reply to 0 to indicate successful processing of the registration request and successful set up of forwarding for all the mobile network prefixes served by the Mobile Router. The registration reply MUST contain at least one Mobile Network Acknowledgement extension. If the Home Agent is unable to set up forwarding for one of more mobile network prefixes served by the Mobile Router, it MUST set the Mobile Network Acknowledgement Extension status code in the registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix length is zero or greater than 32, the status code MUST be set to MOBNET_INVALID_PREFIX_LEN. Leung, et al. Expires December 26, 2006 [Page 10] Internet-Draft Mobile Router June 2006 If the Mobile Router is not authorized to forward packets to one or mobile network prefixes included in the request, the Home Agent MUST set the code to MOBNET_UNAUTHORIZED_MR. 6.7. Mobile Network Prefix De-registration If the received registration request is for de-registration of the care-of-address, the Home Agent, upon successful processing of it, MUST delete the entry(ies) from its registration table. The home agent tears down the bi-directional tunnel and stops forwarding any packets to/from the Mobile Router. The Home Agent MUST ignore any included Mobile Network Request extension in a de-registration request. 7. Data Forwarding Operation For traffic to the nodes in the Mobile Network, the Home Agent MUST perform double tunneling of the packet, if the Mobile Router had registered with a Foreign Agent care-of-address. In this case, the Home Agent MUST encapsulate the packet with tunnel header (source IP address set to Home Agent and destination IP address set to Mobile Router's home address) and then encapsulate one more time with tunnel header (source IP address set to Home Agent and destination IP address set to CoA). For optimization, the Home Agent SHOULD only encapsulate the packet with the tunnel header (source IP address set to Home Agent and destination IP address set to CoA) for Collocated CoA mode. When a Home Agent receives a packet from the mobile network prefix in the bi-directional tunnel, it MUST de-encapsulate the packet and route it as a normal IP packet. It MUST verify that the incoming packet has the source IP address set to the care-of-address of the Mobile Router. The packet MUST be dropped if the source address is not set to the care-of-address of the Mobile Router. For traffic from the nodes in the Mobile Network, the Mobile Router encapsulates the packet with tunnel header (source IP address set to Mobile Router's home address and destination IP address set to Home Agent) if reverse tunnel is enabled. Otherwise, the packet is routed directly to the Foreign Agent or access router. In Collocated CoA mode, the Mobile Router MAY encapsulate one more time with tunnel header (source IP address set to the CoA and destination IP address set to Home Agent). For optimization, the Mobile Router SHOULD encapsulate the packet only with the tunnel header (source IP address set to CoA and destination IP address set to the Home Agent). 8. Nested Mobile Networks Nested Network Mobility is a scenario where a Mobile Router allows another Mobile Router to attach to its Mobile Network. There could be arbitrary levels of nested mobility. The operation of each Mobile Leung, et al. Expires December 26, 2006 [Page 11] Internet-Draft Mobile Router June 2006 Router remains the same whether the Mobile Router attaches to another Mobile Router or to a fixed Access Router on the Internet. The solution described here does not place any restriction on the number of levels for nested mobility. But note that this might introduce significant overhead on the data packets as each level of nesting introduces another tunnel header encapsulation. 9. Security Considerations The Mobile Network extension is protected by the same rules for Mobile IP extensions in registration messages. See the Security Considerations section in RFC 3344. The Home Agent MUST be able to verify that the Mobile Router is authorized to provide mobility service for the Mobile Networks in the registration request, before anchoring these subnets on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be set up without successful authorization of the Mobile Router for those prefixes. A registration failure MUST be notified to the mobile router when it cannot be successfully authorized for prefixes requested by it. All registration requests and replies MUST be authenticated by the MN-HA Authentication Extension as specified in ([RFC3344]). When the registration request is sent in explicit mode, i.e., with one or more Mobile Network Prefix extensions, all the Mobile Network Prefix extensions MUST be included before the MN-HA Authentication extension. Also, these extensions MUST be included in the calculation of the MN-HA authenticator value. The Mobile Router should perform ingress filtering on all the packets received on the mobile network prior to reverse tunneling them to the Home Agent. The Mobile Router MUST drop any packets that do not have a source address belonging to the mobile network. The Mobile Router MUST also ensure that the source address of packets arriving on the mobile network is not the same as the Mobile Router's IP address on any interface. These checks will protect against nodes attempting to launch IP spoofing attacks through the bi-directional tunnel. The Home Agent, upon receiving packets through the bi-directional tunnel, MUST verify that the source addresses of the outer IP header of the packets are set to the Mobile Router's care-of-address. Also, it MUST ensure that the source address of the inner IP header is a topologically correct address on the mobile network. This will prevent nodes from using the Home Agent to launch attacks inside the protected network. If a dynamic routing protocol is used between the Mobile Router and the Home Agent to propagate the mobile network information into the home network, the routing updates SHOULD be protected with IPsec ESP confidentiality between the Mobile Router and Home Agent, to prevent information about home network topology from being visible to eavesdroppers. Leung, et al. Expires December 26, 2006 [Page 12] Internet-Draft Mobile Router June 2006 10. IANA Considerations IANA to modify rules for the existing registry "Mobile IPv4 numbers - per RFC 3344". The numbering space for Extensions that may appear in Mobile IP control messages (those sent to and from UDP port number 434) should be modified. The new Values and Names for the Type for Extensions appearing in Mobile IP control messages are the following: Value Name ----- ------------------------------------------ TBA Mobile Network Extension (To Be Assigned by IANA) The new Values and Names for the Sub-Type for Mobile Network Extension are the following: Value Name ----- ------------------------------------------ TBA Mobile Network Request Extension TBA Explicit Mode Acknowledgement Extension TBA Implicit Mode Acknowledgement Extension The new Code values for Mobile IP Registration Reply messages are the following: Code Values for Mobile IP Registration Reply messages ----------------------------------------------------- Registration denied by the Home Agent: (To Be Assigned by IANA) TBA Mobile Network Prefix operation error (HA_MOBNET_ERROR) TBA MR operation is not permitted (HA_MOBNET_DISALLOWED) The new Code Values for Mobile IP Registration Reply messages are the following: Code Values for Mobile Network Acknowledgement Extension -------------------------------------------------------- Registration denied by the Home Agent: TBA Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) TBA MR is not authorized for prefix (MOBNET_UNAUTHORIZED) TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) The current (non-modified) numbering spaces could be consulted at the following URL: http://www.iana.org/assignments/mobileip-numbers Leung, et al. Expires December 26, 2006 [Page 13] Internet-Draft Mobile Router June 2006 11. Acknowledgements The authors would like to thank Christophe Janneteau, George Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji Wakikawa, George Tsirtsis and Henrik Levkowetz for their helpful discussions, reviews and comments. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. 12.2. Informative References [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. 13. Changelog From version 00 to 01: -removed error code HA_MOBNET_UNSUPPORTED. -changed all values to be assigned by IANA, from specific numbers to "TBA" (To Be Assigned). -substituted "egress interface" for "roaming interface". -changed HA behaviour upon reception of MNPs. In 00 the HA replied positively only if all MNPs in RegReq were valid, in 01 a reply is constructed specifying which MNP was valid and which not. -clarified a 3-line paragraph saying that RegRep may contain both implicit and explicit acknowledgements. Leung, et al. Expires December 26, 2006 [Page 14] Internet-Draft Mobile Router June 2006 Authors' Addresses Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 Email: kleung@cisco.com Gopal Dommety Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-525-1404 Email: gdommety@cisco.com Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Alexandru Petrescu Motorola Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France Email: Alexandru.Petrescu@motorola.com Leung, et al. Expires December 26, 2006 [Page 15] Internet-Draft Mobile Router June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Leung, et al. Expires December 26, 2006 [Page 16] --------------010006030804090505050003-- From nemo-bounces@ietf.org Tue Jun 27 01:26:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv65r-0000zk-6A; Tue, 27 Jun 2006 01:26:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv65p-0000zf-Po for nemo@ietf.org; Tue, 27 Jun 2006 01:26:33 -0400 Received: from yskfw1.ysknet.co.jp ([210.169.255.3] helo=ksns.ks.ysknet.co.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv65n-0002eX-3V for nemo@ietf.org; Tue, 27 Jun 2006 01:26:33 -0400 Received: (qmail 23106 invoked from network); 27 Jun 2006 14:26:28 +0900 Received: from (HELO MIP6-236) (@) by with SMTP; 27 Jun 2006 14:26:28 +0900 To: Francis.Dupont@point6.net Subject: Re: [ipv6ready-tech: 2170] Re: [nemo] IPv6 Ready Logo Phase-2 NEMO Public Review From: "K.Kawaguchi" References: <200606221450.GEI26061.HJBUBXLV@ysknet.co.jp> <200606241310.k5ODAZeO051592@givry.rennes.enst-bretagne.fr> In-Reply-To: <200606241310.k5ODAZeO051592@givry.rennes.enst-bretagne.fr> Message-Id: <200606271426.AAI69719.JLVUBHXB@ysknet.co.jp> X-Mailer: Winbiff [Version 2.43 PL1] X-Accept-Language: ja,en Date: Tue, 27 Jun 2006 14:26:26 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, ipv6ready-tech@ipv6ready.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, At present, these tests pays attention to the main body of the protocol of NEMO. Minimum static IPsec is included. As for dynamic IPsec keying, it is still undecided. We were making the test specification of MIPv6 with IKEv1. (MIPv6 with IKEv1 opened the experimental test specification.) But, the concern has already been shifted to IKEv2. Sorry, We have not started anything about latest IPsec and dynamic keying yet. This time, please look as a basic test of NEMO Protol. Best regards --- Kiyoaki KAWAGUCHI kawaguti@ysknet.co.jp "[ipv6ready-tech: 2170] Re: [nemo] IPv6 Ready Logo Phase-2 NEMO Public Review " "Francis Dupont " wrote: > NEMO public review page: > http://www.ipv6ready.org/announcement/public_review20060621_nemo.html > > => just a simple statement: it is a shame that the dynamic IPsec keying > is not included (IMHO it should be required but it is not even in > advanced features). > > Regards > > Francis.Dupont@point6.net From nemo-bounces@ietf.org Thu Jun 29 15:50:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2XK-0006Gv-TV; Thu, 29 Jun 2006 15:50:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2WZ-0004kM-8d; Thu, 29 Jun 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2WY-0001YZ-VT; Thu, 29 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo2UA025391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WY-0003Tv-Bu; Thu, 29 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 29 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-v4-base-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : IPv4 Network Mobility (NEMO) Basic Support Protocol Author(s) : K. Leung, et al. Filename : draft-ietf-nemo-v4-base-01.txt Pages : 16 Date : 2006-6-29 This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-v4-base-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-v4-base-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29113121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-v4-base-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-v4-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29113121.I-D@ietf.org> --OtherAccess-- --NextPart--