From nemo-bounces@ietf.org Mon May 02 07:57:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZYZ-0004VA-O4; Mon, 02 May 2005 07:57:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSZYY-0004Ul-AL for nemo@megatron.ietf.org; Mon, 02 May 2005 07:57:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06197 for ; Mon, 2 May 2005 07:57:45 -0400 (EDT) From: kang@icu.ac.kr Received: from sniper.icu.ac.kr ([210.107.128.51]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSZmA-0001Ra-5G for nemo@ietf.org; Mon, 02 May 2005 08:11:54 -0400 Received: (snipe 23264 invoked by alias); 2 May 2005 20:57:57 +0900 Received: from kang@icu.ac.kr with Spamsniper 2.91.12 (Processed in 0.030479 secs); Received: from unknown (HELO user98yc8es3up) (kang@icu.ac.kr@220.69.185.93) by unknown with SMTP; 2 May 2005 20:57:57 +0900 X-RCPTTO: nemo@ietf.org Message-ID: <002801c54f0d$e2429270$5db945dc@user98yc8es3up> To: Date: Mon, 2 May 2005 20:55:49 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C54F59.51D4A060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.5 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [nemo] service discovery in 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C54F59.51D4A060 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gbmV3IGNvbW1lciBpbiBORU1PLg0KDQpJIGFtIHZlcnkgaW50ZXJlc3RlZCBp biBzZXJ2aWNlIChvciByZXNvdXJjZSkgZGlzY292ZXJ5IGluIE1BTkVULg0KSW4gTkVNTywgYXJl IHRoZXJlIGFueSBzcGVjaWFsIHNlcnZpY2UgZGlzY292ZXJ5IGlzc3VlcyBkaWZmZXJlbnQgZnJv bSBNQU5FVD8NCkF0IHByZXNlbnQsIEkgdGhpbmsgaXQgaXMgYWxtb3N0IHNhbWUgaW4gTUFORVQu DQpJcyB0aGVyZSBhbnlvbmUgd2hvIGhhcyBkaWZmZXJlbnQgb3Bpbmlvbj8NCklmIHlvdSBrbm93 IHNvbWUgcmVmZXJlbmNlIHNpdGUsIHBsZWFzZSBsZXQgbWUga25vdy4NCg0KUmVncmFkcywNCg0K U2FlIEhvb24gS2FuZw0KDQo= ------=_NextPart_000_0025_01C54F59.51D4A060 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjYyNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLDwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPkkgYW0gbmV3IGNvbW1lciBpbiBORU1PLjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgYW0gdmVy eSBpbnRlcmVzdGVkIGluIHNlcnZpY2UgKG9yIHJlc291cmNlKSZuYnNwO2Rpc2NvdmVyeSANCmlu IE1BTkVULjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkluIE5FTU8sIGFyZSB0aGVy ZSBhbnkmbmJzcDtzcGVjaWFsIHNlcnZpY2UgDQpkaXNjb3ZlcnkmbmJzcDtpc3N1ZXMgZGlmZmVy ZW50Jm5ic3A7ZnJvbSZuYnNwO01BTkVUPzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PkF0IHByZXNlbnQsIEkgdGhpbmsgaXQgaXMgYWxtb3N0IHNhbWUgaW4gTUFORVQuPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+SXMgdGhlcmUgYW55b25lIHdobyBoYXMgZGlmZmVyZW50 IG9waW5pb24/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SWYgeW91Jm5ic3A7a25v dyBzb21lIHJlZmVyZW5jZSBzaXRlLCBwbGVhc2UgbGV0IG1lIA0Ka25vdy48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj5SZWdyYWRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxCUj5TYWUgSG9vbiBL YW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0025_01C54F59.51D4A060-- From nemo-bounces@ietf.org Tue May 03 05:39:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSts8-0002YI-Ge; Tue, 03 May 2005 05:39:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSts5-0002Xp-So for nemo@megatron.ietf.org; Tue, 03 May 2005 05:39:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23098 for ; Tue, 3 May 2005 05:39:15 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSu5t-0003Pn-Eb for nemo@ietf.org; Tue, 03 May 2005 05:53:35 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 May 2005 11:39:03 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j439cG5g005813; Tue, 3 May 2005 11:38:58 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 May 2005 11:38:41 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] service discovery in nemo Date: Tue, 3 May 2005 11:38:37 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCDF7051@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] service discovery in nemo Thread-Index: AcVPDpilZ9fUwqXKTmq6oMKHsKZWkQArVVWw From: "Pascal Thubert \(pthubert\)" To: , , X-OriginalArrivalTime: 03 May 2005 09:38:41.0880 (UTC) FILETIME=[E4626D80:01C54FC3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Kang We discussed at P2PRG to have a WG session in Paris on Friday. You might = want to attend it.=20 Note that Service Discovery is not really a NEMO topic. But it might be = a sub-problem of MANEMO (MANET for NEMO) which studies the applicability = of a MANET to structure a nested NEMO and provide internal Route = Optimization. There is a mailing list for MANEMO: To post to this list, send your email to: manemo@mobileip.jp General information about the mailing list is at: http://www.mobileip.jp/mailman/listinfo/manemo Pascal ________________________________________ From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of = kang@icu.ac.kr Sent: Monday, May 02, 2005 1:56 PM To: nemo@ietf.org Subject: [nemo] service discovery in nemo Hi, =A0 I am new commer in NEMO. =A0 I am very interested in service (or resource)=A0discovery in MANET. In NEMO, are there any=A0special service discovery=A0issues = different=A0from=A0MANET? At present, I think it is almost same in MANET. Is there anyone who has different opinion? If you=A0know some reference site, please let me know. =A0 Regrads, Sae Hoon Kang =A0 =A0 From nemo-bounces@ietf.org Tue May 03 11:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSz9s-0007GF-Ur; Tue, 03 May 2005 11:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSz9q-0007G8-No for nemo@megatron.ietf.org; Tue, 03 May 2005 11:17:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29378 for ; Tue, 3 May 2005 11:17:56 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DSzNk-0003uk-NK for nemo@ietf.org; Tue, 03 May 2005 11:32:21 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j43FK2qW021204; Tue, 3 May 2005 08:20:08 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id j43FKgxd021586; Tue, 3 May 2005 10:20:43 -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 0E801865980; Tue, 3 May 2005 17:17:31 +0200 (CEST) Message-ID: <4277960A.8050307@motorola.com> Date: Tue, 03 May 2005 17:17:30 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] service discovery in nemo References: <7892795E1A87F04CADFCCF41FADD00FCDF7051@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCDF7051@xmb-ams-337.emea.cisco.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, manemo@mobileip.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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Kang > > We discussed at P2PRG to have a WG session in Paris on Friday. You > might want to attend it. > > Note that Service Discovery is not really a NEMO topic. I agree, terminology-wise "service discovery" sounds related to SLP (Service Location Protocol) in my oppinion. If however the "service" is a "network service" that MR needs, and if that "network service" is the MNP MR needs, "service discovery" may mean DHCP Prefix Delegation for MR, and that would be NEMO stuff I believe... Alex From nemo-bounces@ietf.org Tue May 03 13:51:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1Yl-0002DP-5J; Tue, 03 May 2005 13:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DT1Yk-0002DK-6W for nemo@megatron.ietf.org; Tue, 03 May 2005 13:51:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14811 for ; Tue, 3 May 2005 13:51:48 -0400 (EDT) Received: from losangeles.ucdavis.edu ([169.237.104.159]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DT1md-0008Am-AG for nemo@ietf.org; Tue, 03 May 2005 14:06:14 -0400 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by losangeles.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j43HpgAh000248 for ; Tue, 3 May 2005 10:51:43 -0700 (PDT) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j43HpgdS007014 for ; Tue, 3 May 2005 10:51:42 -0700 (PDT) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id j43Hpg1a007011; Tue, 3 May 2005 10:51:42 -0700 (PDT) Date: Tue, 3 May 2005 10:51:42 -0700 (PDT) Message-Id: <200505031751.j43Hpg1a007011@tremex.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [nemo] Call for Paper: JSAC-MRNM 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com From nemo-bounces@ietf.org Mon May 09 03:38:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV2qU-0002CE-Ie; Mon, 09 May 2005 03:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV2qT-0002C9-1T for nemo@megatron.ietf.org; Mon, 09 May 2005 03:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10663 for ; Mon, 9 May 2005 03:38:27 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV35V-00044i-RF for nemo@ietf.org; Mon, 09 May 2005 03:54:03 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 568D84C6D8 for ; Mon, 9 May 2005 16:37:52 +0900 (JST) Date: Mon, 9 May 2005 16:43:05 +0900 From: Thierry Ernst To: nemo Message-Id: <20050509164305.78a07dc1.ernst@sfc.wide.ad.jp> Organization: Keio University 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-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Subject: [nemo] Routing Optimization WG Drafts 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Dear all, You can check the entire discussion about NEMO RO on the minutes of Minneapolis meeting ( http://www3.ietf.org/proceedings/05mar/index.html or http://www.mobilenetworks.org/nemo/ietf62/nemo-ietf62-minutes.txt ). Here is the end of the discussion: - CWN: What has been said today is that the first part of draft-thubert will be used as basis of problem statement? - TE: use draft-thubert, split in two, 1 for PS, 1 for taxonomy. - TE: let's take this to the ML to make sure of the consensus So, unless people not present to the meeting have a strong argument against the decision, the conclusion we reached at the meeting is that draft-thubert-nemo-ro-taxonomy would be split in 2 parts (pb statement, and solution analysis). We decided to confirm this on the list. (1) draft-ietf-nemo-ro-problem-statement: - would contain the short concise description of the RO problem - use Section 2 of draft-thubert-nemo-ro-taxonomy-04.txt as the base document, and merge in other missing contents outlined in the other individual drafts. - likely authors: ChanWah Ng, Pascal Thubert, Fan Zhao, Masafumi Watari (2) draft-ietf-nemo-ro-space-analysis: would contain the more extensive analysis of the RO problem and solution space, describing the general issues and tradeoffs of different RO approaches, and also security/threat analysis. - the remainder of draft-thubert-04 be used as the base and merged in contents from other drafts as well. - likely authors: ChanWah, Pascal, Fan. Thierry. From nemo-bounces@ietf.org Mon May 09 06:12:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV5Fy-0004cL-BL; Mon, 09 May 2005 06:12:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV42p-0003Lq-Ue for nemo@megatron.ietf.org; Mon, 09 May 2005 04:55:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16297 for ; Mon, 9 May 2005 04:55:18 -0400 (EDT) Received: from smtp.irisa.fr ([131.254.254.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV4Ht-0006fu-UN for nemo@ietf.org; Mon, 09 May 2005 05:10:55 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id CE5BFFAC4 for ; Mon, 9 May 2005 10:55:14 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04207-04 for ; Mon, 9 May 2005 10:55:12 +0200 (CEST) Received: from [131.254.100.3] (powerbook.irisa.fr [131.254.100.3]) by smtp.irisa.fr (Postfix) with ESMTP id D89B6FAC6 for ; Mon, 9 May 2005 10:55:12 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nemo@ietf.org From: Bruno Deniaud Date: Mon, 9 May 2005 10:55:11 +0200 X-Mailer: Apple Mail (2.728) X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 09 May 2005 06:12:57 -0400 Subject: [nemo] Some mistakes on RFC 3963 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello all, Thierry Ernst asked me to report mistakes found on RFC 3963 on this list, so here there are : - Index, page 2 : 7.1 "Modified Dynamic Home Agent Discovery Request" => "Modified Dynamic Home Agent Address Discovery Request" (which appears on page 20) - Index page 2 : 7.2 and page 20 "Modified Dynamic Home Agent Discovery Address Request" => "Modified Dynamic Home Agent Address Discovery Reply" - Page 7 : 4.1 In the Binding Update figure, there is a bit M which is explicited neither in this RFC nor in the RFC referenced (MIPv6). Seems to come from HMIPv6 (?) Hope this will help ! -- Bruno Deniaud ARMOR/Point6 IRISA/INRIA Rennes From nemo-bounces@ietf.org Mon May 09 12:02:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAiW-0007ub-Qg; Mon, 09 May 2005 12:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVAiV-0007uW-LL for nemo@megatron.ietf.org; Mon, 09 May 2005 12:02:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00104 for ; Mon, 9 May 2005 12:02:45 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVAxe-0006T7-Am for nemo@ietf.org; Mon, 09 May 2005 12:18:26 -0400 Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 18:02:29 +0200 Received: from PXPELLAFOL ([10.193.161.117]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 18:02:29 +0200 From: "Jean-Michel COMBES" To: Date: Mon, 9 May 2005 18:02:28 +0200 Organization: France Telecom R&D Message-ID: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 09 May 2005 16:02:29.0059 (UTC) FILETIME=[80219930:01C554B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Subject: [nemo] RFC 3963: Clarifications if the MR is MN too 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, The RFC 3963 says in: (1) Section 3, p5 "When the Mobile Router moves away from the home link and attaches to a = new access router, it acquires a Care-of Address from the visited link. The Mobile Router can at any time act either as a Mobile Host or as a Mobile Router. It acts as a Mobile Host as defined in [1] for sessions it originates and provides connectivity to the Mobile Network. As soon as = the Mobile Router acquires a Care-of Address, it immediately sends a Binding Update to its Home Agent as described in [1]. When the Home Agent = receives this Binding Update, it creates a cache entry binding the Mobile = Router's Home Address to its Care-of Address at the current point of attachment." (2) Section 4.1, p7 "A new flag (R) is included in the Binding Update to indicate to the = Home Agent whether the Binding Update is coming from a Mobile Router and not = from a mobile node. The rest of the Binding Update format remains the same = as defined in [1]." (3) Section 4.1, p7 "Mobile Router Flag (R) The Mobile Router Flag is set to indicate to the Home Agent that the = Binding Update is from a Mobile Router. If the flag is set to 0, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node, and it MUST = NOT forward packets destined for the Mobile Network to the Mobile Router. Assuming that a MR is MN too, as described in (1), my questions are:=20 - (2) seems to indicate that such a MR has to send 2 BU: one with R=3D0 = for MIPv6 and one with R=3D1 for MIPv6. Am I wrong? - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. Am I = wrong? Thanks for your help. Regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 From nemo-bounces@ietf.org Tue May 10 10:17:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVY7-00073q-IG; Tue, 10 May 2005 10:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVY5-00073g-W9 for nemo@megatron.ietf.org; Tue, 10 May 2005 10:17:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29814 for ; Tue, 10 May 2005 10:17:23 -0400 (EDT) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVnP-00033p-4B for nemo@ietf.org; Tue, 10 May 2005 10:33:16 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j4AEMwFh025046; Tue, 10 May 2005 07:22:58 -0700 (MST) Received: from [10.161.194.68] (zuk02-5022.ea.mot.com [10.161.194.68]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id j4AEJr8M005679; Tue, 10 May 2005 09:19:54 -0500 (CDT) Message-ID: <4280C269.6020204@motorola.com> Date: Tue, 10 May 2005 16:17:13 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Bruno Deniaud Subject: Re: [nemo] Some mistakes on RFC 3963 References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Bruno Deniaud wrote: > Hello all, > > Thierry Ernst asked me to report mistakes found on RFC 3963 on this > list, so here there are : > > - Index, page 2 : 7.1 "Modified Dynamic Home Agent Discovery Request" > => "Modified Dynamic Home Agent Address Discovery Request" (which > appears on page 20) > > - Index page 2 : 7.2 and page 20 "Modified Dynamic Home Agent > Discovery Address Request" => "Modified Dynamic Home Agent Address > Discovery Reply" Yes, thanks, let's keep those aside for further revisions. > - Page 7 : 4.1 In the Binding Update figure, there is a bit M which > is explicited neither in this RFC nor in the RFC referenced (MIPv6). > Seems to come from HMIPv6 (?) Yes, 'M's position was historically first used in the HMIPv6 drafts. Maybe that should be referenced in the 3963 text as Informative Reference. I do not currently know the plan for the HMIPv6 draft. Alex From nemo-bounces@ietf.org Tue May 10 10:25:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVfX-0008Ak-Up; Tue, 10 May 2005 10:25:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVfW-0008AZ-Go for nemo@megatron.ietf.org; Tue, 10 May 2005 10:25:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00807 for ; Tue, 10 May 2005 10:25:04 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVur-0003gb-2w for nemo@ietf.org; Tue, 10 May 2005 10:40:57 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4AEWXxN005766; Tue, 10 May 2005 07:32:33 -0700 (MST) Received: from [10.161.194.68] (zuk02-5022.ea.mot.com [10.161.194.68]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4AESKai002182; Tue, 10 May 2005 09:28:21 -0500 (CDT) Message-ID: <4280C43D.7040102@motorola.com> Date: Tue, 10 May 2005 16:25:01 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Jean-Michel COMBES Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too References: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> In-Reply-To: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Jean-Michel COMBES wrote: > Hi, > > The RFC 3963 says in: > > (1) Section 3, p5 "When the Mobile Router moves away from the home > link and attaches to a new access router, it acquires a Care-of > Address from the visited link. The Mobile Router can at any time act > either as a Mobile Host or as a Mobile Router. It acts as a Mobile > Host as defined in [1] for sessions it originates and provides > connectivity to the Mobile Network. As soon as the Mobile Router > acquires a Care-of Address, it immediately sends a Binding Update to > its Home Agent as described in [1]. When the Home Agent receives this > Binding Update, it creates a cache entry binding the Mobile Router's > Home Address to its Care-of Address at the current point of > attachment." > > (2) Section 4.1, p7 "A new flag (R) is included in the Binding Update > to indicate to the Home Agent whether the Binding Update is coming > from a Mobile Router and not from a mobile node. The rest of the > Binding Update format remains the same as defined in [1]." > > (3) Section 4.1, p7 "Mobile Router Flag (R) The Mobile Router Flag is > set to indicate to the Home Agent that the Binding Update is from a > Mobile Router. If the flag is set to 0, the Home Agent assumes that > the Mobile Router is behaving as a Mobile Node, and it MUST NOT > forward packets destined for the Mobile Network to the Mobile Router. > > > Assuming that a MR is MN too, as described in (1), my questions are: > - (2) seems to indicate that such a MR has to send 2 BU: one with > R=0 for MIPv6 and one with R=1 for MIPv6. Am I wrong? In our implementation one R-BU is sufficient to "bind" both the HoA and the complete MNP. It was not in the intention to have two BUs sent one for MH and one for MR. > - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. Am I > wrong? Terminology-wise, "If the flag is set to 0, the Home Agent assumes that the Mobile Router is behaving as a Mobile Node" should probably better say "Mobile Host" instead of "Mobile Node". That would clarify things I believe. Implementations that I know of have a HA that either supports MH or both MH/MR (a MN is an MH and MR actually, by the RFC3775 definitions I believe). My oppinion, Alex From nemo-bounces@ietf.org Tue May 10 10:29:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVkD-0000Au-Nw; Tue, 10 May 2005 10:29:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVkC-00009T-1c for nemo@megatron.ietf.org; Tue, 10 May 2005 10:29:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01100 for ; Tue, 10 May 2005 10:29:54 -0400 (EDT) Received: from smtp.irisa.fr ([131.254.254.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVzU-0003tR-Lf for nemo@ietf.org; Tue, 10 May 2005 10:45:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id D3322FAC6; Tue, 10 May 2005 16:29:47 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05576-07; Tue, 10 May 2005 16:29:46 +0200 (CEST) Received: from [131.254.100.3] (powerbook.irisa.fr [131.254.100.3]) by smtp.irisa.fr (Postfix) with ESMTP id 1190DFAB1; Tue, 10 May 2005 16:29:46 +0200 (CEST) In-Reply-To: <4280C269.6020204@motorola.com> References: <4280C269.6020204@motorola.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <02662F5B-2D30-4846-955B-64680FA5AC17@irisa.fr> Content-Transfer-Encoding: quoted-printable From: Bruno Deniaud Subject: Re: [nemo] Some mistakes on RFC 3963 Date: Tue, 10 May 2005 16:29:45 +0200 To: Alexandru Petrescu X-Mailer: Apple Mail (2.728) X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Le 10 mai 05 =E0 16:17, Alexandru Petrescu a =E9crit : > Bruno Deniaud wrote: > >> Hello all, >> Thierry Ernst asked me to report mistakes found on RFC 3963 on this >> list, so here there are : >> - Index, page 2 : 7.1 "Modified Dynamic Home Agent Discovery Request" >> =3D> "Modified Dynamic Home Agent Address Discovery Request" (which >> appears on page 20) >> - Index page 2 : 7.2 and page 20 "Modified Dynamic Home Agent >> Discovery Address Request" =3D> "Modified Dynamic Home Agent Address >> Discovery Reply" >> > > Yes, thanks, let's keep those aside for further revisions. No problem ;) > > >> - Page 7 : 4.1 In the Binding Update figure, there is a bit M which >> is explicited neither in this RFC nor in the RFC referenced (MIPv6). >> Seems to come from HMIPv6 (?) >> > > Yes, 'M's position was historically first used in the HMIPv6 drafts. > Maybe that should be referenced in the 3963 text as Informative > Reference. I do not currently know the plan for the HMIPv6 draft. > I think it may be usefull to add this for people who are not familiar =20= with HMIPv6 (like me). Or just mark it as "Reserved" ? Thanks --- Bruno DENIAUD, ARMOR/Point6/TIPI IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France Tel: +33 (0) 2 99 84 75 74, Fax: +33 (0) 2 99 84 71 71 From nemo-bounces@ietf.org Wed May 11 02:07:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkNK-0002mi-ER; Wed, 11 May 2005 02:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVkNI-0002md-A2 for nemo@megatron.ietf.org; Wed, 11 May 2005 02:07:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05868 for ; Wed, 11 May 2005 02:07:14 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVkck-0001gI-Vj for nemo@ietf.org; Wed, 11 May 2005 02:23:15 -0400 Received: from iseran.local (bmdi6051.bmobile.ne.jp [202.32.82.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 4210B4D8FB for ; Wed, 11 May 2005 15:06:35 +0900 (JST) Date: Wed, 11 May 2005 15:11:46 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too Message-Id: <20050511151146.67f0f069.ernst@sfc.wide.ad.jp> In-Reply-To: <4280C43D.7040102@motorola.com> References: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> <4280C43D.7040102@motorola.com> Organization: Keio University 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-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, Yes, the HA supports both operation, but I think the question is about doing this simultaneously. On the MN side, the current text in RFC 3963 doesn't mean the MN can act simultaneously both as a MH and a MR ; and, if it does, does it need to send only 1 BU or 2 BUs. I think the authors of the RFC should clarify this point (i.e. what is the correct interpretation, from an implementation point of view, of the possibility for a MN to act both as a MH and a MR). Thierry > > The RFC 3963 says in: > > > > (1) Section 3, p5 "When the Mobile Router moves away from the home > > link and attaches to a new access router, it acquires a Care-of > > Address from the visited link. The Mobile Router can at any time > > act either as a Mobile Host or as a Mobile Router. It acts as a > > Mobile Host as defined in [1] for sessions it originates and > > provides connectivity to the Mobile Network. As soon as the Mobile > > Router acquires a Care-of Address, it immediately sends a Binding > > Update to its Home Agent as described in [1]. When the Home Agent > > receives this Binding Update, it creates a cache entry binding the > > Mobile Router's Home Address to its Care-of Address at the current > > point of attachment." > > > > (2) Section 4.1, p7 "A new flag (R) is included in the Binding > > Update to indicate to the Home Agent whether the Binding Update is > > coming from a Mobile Router and not from a mobile node. The rest of > > the Binding Update format remains the same as defined in [1]." > > > > (3) Section 4.1, p7 "Mobile Router Flag (R) The Mobile Router Flag > > is set to indicate to the Home Agent that the Binding Update is from > > a Mobile Router. If the flag is set to 0, the Home Agent assumes > > that the Mobile Router is behaving as a Mobile Node, and it MUST NOT > > forward packets destined for the Mobile Network to the Mobile > > Router. > > > > > > Assuming that a MR is MN too, as described in (1), my questions are: > > - (2) seems to indicate that such a MR has to send 2 BU: one with > > R=0 for MIPv6 and one with R=1 for MIPv6. Am I wrong? > > In our implementation one R-BU is sufficient to "bind" both the HoA > and the complete MNP. It was not in the intention to have two BUs > sent one for MH and one for MR. > > > - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. Am I > > wrong? > > Terminology-wise, "If the flag is set to 0, the Home Agent assumes > that the Mobile Router is behaving as a Mobile Node" should probably > better say "Mobile Host" instead of "Mobile Node". That would clarify > things I believe. > > Implementations that I know of have a HA that either supports MH or > both MH/MR (a MN is an MH and MR actually, by the RFC3775 definitions > I believe). From nemo-bounces@ietf.org Wed May 11 03:08:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVlKy-0005wA-MJ; Wed, 11 May 2005 03:08:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVlKw-0005w5-FC for nemo@megatron.ietf.org; Wed, 11 May 2005 03:08:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08502 for ; Wed, 11 May 2005 03:08:52 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVlaP-0004hV-6n for nemo@ietf.org; Wed, 11 May 2005 03:24:54 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 11 May 2005 09:08:40 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4B78DVw013284; Wed, 11 May 2005 09:08:37 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 09:08:24 +0200 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] RFC 3963: Clarifications if the MR is MN too Date: Wed, 11 May 2005 09:08:03 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCE726BB@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RFC 3963: Clarifications if the MR is MN too Thread-Index: AcVV8CgT0vTNdQxXQ3awla1gf0lNBgABRV0g From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 11 May 2005 07:08:24.0925 (UTC) FILETIME=[392A48D0:01C555F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org As I remember, the intent is that: 1) The Home address is a unique id for a registration.=20 2) R bit and ~R bit are mutually exclusive. So a binding is for either one but not both. NEMO says: =20 If the Mobile Router has a valid binding cache entry at the Home Agent, subsequent Binding Updates for the same Home Address should have the same value as the value in the binding cache for the Mobile Router Flag (R). In other words, if a MN needs to maintain 2 bindings, then it needs 2 home addresses. This would be the only way to have both types of binding. 3) A MR that binds with R bit is reachable at its home address with the full service set of an MN. R bit only adds functionality to the MRHA tunnel. 4) NEMO basic does not cover route optimization. So the behavior of a HA should a CN attempt RR test for an MR binding is undefined. I suspect that by default, most implementations would act as if the MR was a MH.=20 To answer a specific question from the original mail, the term "Mobile Node" is inherited from RFC 3775. When RFC 3963 says Mobile Node, it means as defined by RFC 3775. The term Mobile Host was previously undefined and we used it in NEMO to point out the difference. But an RFC 3775 Mobile Node is really a Host and I agree it's misleading. The Cisco implementation supports concurrent bindings for MRs and MNs but a single binding per Home Address. Do I miss anything? Pascal | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Thierry Ernst | Sent: Wednesday, May 11, 2005 8:12 AM | To: nemo@ietf.org | Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too |=20 |=20 | Hi, |=20 | Yes, the HA supports both operation, but I think the question is | about doing this simultaneously. |=20 | On the MN side, the current text in RFC 3963 doesn't mean the MN can act | simultaneously both as a MH and a MR ; and, if it does, does it need to | send only 1 BU or 2 BUs. |=20 | I think the authors of the RFC should clarify this point (i.e. what is | the correct interpretation, from an implementation point of view, of the | possibility for a MN to act both as a MH and a MR). |=20 | Thierry |=20 |=20 | > > The RFC 3963 says in: | > > | > > (1) Section 3, p5 "When the Mobile Router moves away from the home | > > link and attaches to a new access router, it acquires a Care-of | > > Address from the visited link. The Mobile Router can at any time | > > act either as a Mobile Host or as a Mobile Router. It acts as a | > > Mobile Host as defined in [1] for sessions it originates and | > > provides connectivity to the Mobile Network. As soon as the Mobile | > > Router acquires a Care-of Address, it immediately sends a Binding | > > Update to its Home Agent as described in [1]. When the Home Agent | > > receives this Binding Update, it creates a cache entry binding the | > > Mobile Router's Home Address to its Care-of Address at the current | > > point of attachment." | > > | > > (2) Section 4.1, p7 "A new flag (R) is included in the Binding | > > Update to indicate to the Home Agent whether the Binding Update is | > > coming from a Mobile Router and not from a mobile node. The rest of | > > the Binding Update format remains the same as defined in [1]." | > > | > > (3) Section 4.1, p7 "Mobile Router Flag (R) The Mobile Router Flag | > > is set to indicate to the Home Agent that the Binding Update is from | > > a Mobile Router. If the flag is set to 0, the Home Agent assumes | > > that the Mobile Router is behaving as a Mobile Node, and it MUST NOT | > > forward packets destined for the Mobile Network to the Mobile | > > Router. | > > | > > | > > Assuming that a MR is MN too, as described in (1), my questions are: | > > - (2) seems to indicate that such a MR has to send 2 BU: one with | > > R=3D0 for MIPv6 and one with R=3D1 for MIPv6. Am I wrong? | > | > In our implementation one R-BU is sufficient to "bind" both the HoA | > and the complete MNP. It was not in the intention to have two BUs | > sent one for MH and one for MR. | > | > > - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. Am I | > > wrong? | > | > Terminology-wise, "If the flag is set to 0, the Home Agent assumes | > that the Mobile Router is behaving as a Mobile Node" should probably | > better say "Mobile Host" instead of "Mobile Node". That would clarify | > things I believe. | > | > Implementations that I know of have a HA that either supports MH or | > both MH/MR (a MN is an MH and MR actually, by the RFC3775 definitions | > I believe). From nemo-bounces@ietf.org Wed May 11 03:10:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVlMD-00065F-3i; Wed, 11 May 2005 03:10:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVlMB-000656-3b for nemo@megatron.ietf.org; Wed, 11 May 2005 03:10:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08713 for ; Wed, 11 May 2005 03:10:08 -0400 (EDT) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVlbd-0004pT-Te for nemo@ietf.org; Wed, 11 May 2005 03:26:10 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IGB00BWDD8J6Q@mailout1.samsung.com> for nemo@ietf.org; Wed, 11 May 2005 16:09:55 +0900 (KST) Received: from wable ([107.108.71.65]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IGB00D98D8BDL@mmp2.samsung.com> for nemo@ietf.org; Wed, 11 May 2005 16:09:55 +0900 (KST) Date: Wed, 11 May 2005 12:38:13 +0530 From: Ranjitsinh Wable Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too To: Thierry Ernst , nemo@ietf.org Message-id: <056a01c555f8$37549e70$41476c6b@sisodomain.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: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> <4280C43D.7040102@motorola.com> <20050511151146.67f0f069.ernst@sfc.wide.ad.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7BIT 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi, I have one point to mention on this. Whether it is really need to explicitly mentioning the simultaneous working of the MN as MH and MR. MN is working as MR operation is superset of MN working as MH. So once the working of MR is explained there is no need of mentioning the how MH work simultenously. Also there is no need of separate BU for the same. IMHO it is implicit. Let me know your views on the same. Regards, Wable ----- Original Message ----- From: "Thierry Ernst" To: Sent: Wednesday, May 11, 2005 11:41 AM Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too > > Hi, > > Yes, the HA supports both operation, but I think the question is > about doing this simultaneously. > > On the MN side, the current text in RFC 3963 doesn't mean the MN can act > simultaneously both as a MH and a MR ; and, if it does, does it need to > send only 1 BU or 2 BUs. > > I think the authors of the RFC should clarify this point (i.e. what is > the correct interpretation, from an implementation point of view, of the > possibility for a MN to act both as a MH and a MR). > > Thierry > > >> > The RFC 3963 says in: >> > >> > (1) Section 3, p5 "When the Mobile Router moves away from the home >> > link and attaches to a new access router, it acquires a Care-of >> > Address from the visited link. The Mobile Router can at any time >> > act either as a Mobile Host or as a Mobile Router. It acts as a >> > Mobile Host as defined in [1] for sessions it originates and >> > provides connectivity to the Mobile Network. As soon as the Mobile >> > Router acquires a Care-of Address, it immediately sends a Binding >> > Update to its Home Agent as described in [1]. When the Home Agent >> > receives this Binding Update, it creates a cache entry binding the >> > Mobile Router's Home Address to its Care-of Address at the current >> > point of attachment." >> > >> > (2) Section 4.1, p7 "A new flag (R) is included in the Binding >> > Update to indicate to the Home Agent whether the Binding Update is >> > coming from a Mobile Router and not from a mobile node. The rest of >> > the Binding Update format remains the same as defined in [1]." >> > >> > (3) Section 4.1, p7 "Mobile Router Flag (R) The Mobile Router Flag >> > is set to indicate to the Home Agent that the Binding Update is from >> > a Mobile Router. If the flag is set to 0, the Home Agent assumes >> > that the Mobile Router is behaving as a Mobile Node, and it MUST NOT >> > forward packets destined for the Mobile Network to the Mobile >> > Router. >> > >> > >> > Assuming that a MR is MN too, as described in (1), my questions are: >> > - (2) seems to indicate that such a MR has to send 2 BU: one with >> > R=0 for MIPv6 and one with R=1 for MIPv6. Am I wrong? >> >> In our implementation one R-BU is sufficient to "bind" both the HoA >> and the complete MNP. It was not in the intention to have two BUs >> sent one for MH and one for MR. >> >> > - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. Am I >> > wrong? >> >> Terminology-wise, "If the flag is set to 0, the Home Agent assumes >> that the Mobile Router is behaving as a Mobile Node" should probably >> better say "Mobile Host" instead of "Mobile Node". That would clarify >> things I believe. >> >> Implementations that I know of have a HA that either supports MH or >> both MH/MR (a MN is an MH and MR actually, by the RFC3775 definitions >> I believe). > > > From nemo-bounces@ietf.org Wed May 11 04:19:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVmQq-0000K1-4T; Wed, 11 May 2005 04:19:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVmQn-0000Jn-Qe for nemo@megatron.ietf.org; Wed, 11 May 2005 04:19:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12223 for ; Wed, 11 May 2005 04:18:59 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVmgF-0008EL-HJ for nemo@ietf.org; Wed, 11 May 2005 04:35:02 -0400 Received: from iseran.local (bmdi6051.bmobile.ne.jp [202.32.82.51]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E76D64D8A1 for ; Wed, 11 May 2005 17:18:32 +0900 (JST) Date: Wed, 11 May 2005 17:23:44 +0900 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too Message-Id: <20050511172344.04fae05f.ernst@sfc.wide.ad.jp> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FCE726BB@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FCE726BB@xmb-ams-337.emea.cisco.com> Organization: Keio University 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-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > As I remember, the intent is that: > > 1) The Home address is a unique id for a registration. > > 2) R bit and ~R bit are mutually exclusive. So a binding is for either > one but not both. NEMO says: > If the Mobile Router has a valid binding cache entry at the Home > Agent, subsequent Binding Updates for the same Home Address should > have the same value as the value in the binding cache for the > Mobile Router Flag (R). > > In other words, if a MN needs to maintain 2 bindings, then it needs 2 > home addresses. This would be the only way to have both types of > binding. Make sense. Shouldn't this be enforced, and clarified in the spec ? I mean, the question raised in this thread clearly shows that implementers don't know how to interpret the spec. > 3) A MR that binds with R bit is reachable at its home address with > the full service set of an MN. R bit only adds functionality to the > MRHA tunnel. That's the point. > 4) NEMO basic does not cover route optimization. So the behavior of a > HA should a CN attempt RR test for an MR binding is undefined. I > suspect that by default, most implementations would act as if the MR > was a MH. > > To answer a specific question from the original mail, the term "Mobile > Node" is inherited from RFC 3775. When RFC 3963 says Mobile Node, it > means as defined by RFC 3775. The term Mobile Host was previously > undefined and we used it in NEMO to point out the difference. But an > RFC 3775 Mobile Node is really a Host and I agree it's misleading. Yes, very missleading since the definition of a node is "either a host or a router", so a MN is either a mobile host or a mobile router per definition. But RFC 3775 is only about MH. May be the revised RFC 3775 should change the wording too. > The Cisco implementation supports concurrent bindings for MRs and MNs > but a single binding per Home Address. What do you mean, using 2 HoAs then ? > Do I miss anything? Thierry From nemo-bounces@ietf.org Wed May 11 05:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVnSO-0005St-CU; Wed, 11 May 2005 05:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVnSM-0005Sj-Ph for nemo@megatron.ietf.org; Wed, 11 May 2005 05:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16242 for ; Wed, 11 May 2005 05:24:40 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVnhq-00032F-TA for nemo@ietf.org; Wed, 11 May 2005 05:40:43 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 11 May 2005 11:24:33 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4B9OBVw028373; Wed, 11 May 2005 11:24:29 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 11 May 2005 11:24:25 +0200 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] RFC 3963: Clarifications if the MR is MN too Date: Wed, 11 May 2005 11:24:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FCE727C7@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RFC 3963: Clarifications if the MR is MN too Thread-Index: AcVWAkdTOTQ1JkWYRN2HpSKN/Z2aiwABr3gQ From: "Pascal Thubert \(pthubert\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 11 May 2005 09:24:25.0235 (UTC) FILETIME=[3916C630:01C5560B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org | -----Original Message----- | From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of | Thierry Ernst | Sent: Wednesday, May 11, 2005 10:24 AM | To: nemo@ietf.org | Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too |=20 |=20 | > As I remember, the intent is that: | > | > 1) The Home address is a unique id for a registration. | > | > 2) R bit and ~R bit are mutually exclusive. So a binding is for either | > one but not both. NEMO says: | > If the Mobile Router has a valid binding cache entry at the Home | > Agent, subsequent Binding Updates for the same Home Address should | > have the same value as the value in the binding cache for the | > Mobile Router Flag (R). | > | > In other words, if a MN needs to maintain 2 bindings, then it needs 2 | > home addresses. This would be the only way to have both types of | > binding. |=20 | Make sense. Shouldn't this be enforced, and clarified in the spec ? |=20 | I mean, the question raised in this thread clearly shows that | implementers don't know how to interpret the spec. |=20 | > 3) A MR that binds with R bit is reachable at its home address with | > the full service set of an MN. R bit only adds functionality to the | > MRHA tunnel. |=20 | That's the point. |=20 | > 4) NEMO basic does not cover route optimization. So the behavior of a | > HA should a CN attempt RR test for an MR binding is undefined. I | > suspect that by default, most implementations would act as if the MR | > was a MH. | > | > To answer a specific question from the original mail, the term "Mobile | > Node" is inherited from RFC 3775. When RFC 3963 says Mobile Node, it | > means as defined by RFC 3775. The term Mobile Host was previously | > undefined and we used it in NEMO to point out the difference. But an | > RFC 3775 Mobile Node is really a Host and I agree it's misleading. |=20 | Yes, very missleading since the definition of a node is "either a host | or a router", so a MN is either a mobile host or a mobile router per | definition. But RFC 3775 is only about MH. May be the revised RFC 3775 | should change the wording too. |=20 | > The Cisco implementation supports concurrent bindings for MRs and MNs | > but a single binding per Home Address. |=20 | What do you mean, using 2 HoAs then ? |=20 [|PT>] I expect they are different physical machines, with their own Home Addresses.=20 It could be a same machine maintaining two sessions but I'm not sure it would work with a single careof address. The specific problem is for the HA to identify the tunnel when it receives a packet. Some implementations might use the careof as index, though nothing guarantees that it is a unique ID. With MIP, the source of the inner packet is the Home Address so it is pretty easy to figure out the binding. With NEMO, the packet has to be topologically correct, meaning that the source of the packet is routed over the MRHA tunnel. For a router that supports a large panel of tunnel types, recognizing that this packet is for that MRHA tunnel is a bit complex and involves routing table lookups. This is what our implementation does. I remember that we discussed putting a Home Address Option in the tunnel outer header but the suggestion was rejected. Pascal From nemo-bounces@ietf.org Wed May 11 14:28:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvwF-0007fG-No; Wed, 11 May 2005 14:28:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvwE-0007fB-Ck for nemo@megatron.ietf.org; Wed, 11 May 2005 14:28:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00926 for ; Wed, 11 May 2005 14:28:04 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwBl-0006Y2-U5 for nemo@ietf.org; Wed, 11 May 2005 14:44:11 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4BHuwh18501; Wed, 11 May 2005 10:56:58 -0700 X-mProtect: <200505111756> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdnMhXc5; Wed, 11 May 2005 10:56:56 PDT Message-ID: <42824E9B.5060109@iprg.nokia.com> Date: Wed, 11 May 2005 11:27:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Michel COMBES Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too References: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> In-Reply-To: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Jean-Michel COMBES wrote: > Hi, > > The RFC 3963 says in: > > (1) Section 3, p5 > "When the Mobile Router moves away from the home link and attaches to a new > access router, it acquires a Care-of Address from the visited link. The > Mobile Router can at any time act either as a Mobile Host or as a Mobile > Router. It acts as a Mobile Host as defined in [1] for sessions it > originates and provides connectivity to the Mobile Network. As soon as the > Mobile Router acquires a Care-of Address, it immediately sends a Binding > Update to its Home Agent as described in [1]. When the Home Agent receives > this Binding Update, it creates a cache entry binding the Mobile Router's > Home Address to its Care-of Address at the current point of attachment." > > (2) Section 4.1, p7 > "A new flag (R) is included in the Binding Update to indicate to the Home > Agent whether the Binding Update is coming from a Mobile Router and not from > a mobile node. The rest of the Binding Update format remains the same as > defined in [1]." > > (3) Section 4.1, p7 > "Mobile Router Flag (R) > The Mobile Router Flag is set to indicate to the Home Agent that the Binding > Update is from a Mobile Router. If the flag is set to 0, the Home Agent > assumes that the Mobile Router is behaving as a Mobile Node, and it MUST NOT > forward packets destined for the Mobile Network to the Mobile Router. > > Assuming that a MR is MN too, as described in (1), my questions are: > - (2) seems to indicate that such a MR has to send 2 BU: one with R=0 for > MIPv6 and one with R=1 for MIPv6. Am I wrong? nope. just one BU is enough. when the HA processes the R bit in the BU, it sets up forwarding for the MNP in addition to creating a binding cache for the home address as described in RFC 3775. > - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. nope. the HA can at the same time support MIPv6 MNs and NEMO MRs. if the R bit in the BU is not set, the HA just creates a binding cache for the home address, defends the home address and tunnels packets meant for the home address to the current CoA. if the R bit in the BU is set, the HA does the above *and* sets up forwarding for the MNP. Vijay From nemo-bounces@ietf.org Wed May 11 22:17:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3GA-0003x2-Cm; Wed, 11 May 2005 22:17:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW3G8-0003wx-7N for nemo@megatron.ietf.org; Wed, 11 May 2005 22:17:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20283 for ; Wed, 11 May 2005 22:17:05 -0400 (EDT) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW3Vl-0001E8-7f for nemo@ietf.org; Wed, 11 May 2005 22:33:18 -0400 Received: from [203.178.139.197] (wifi-139-197.sfc.wide.ad.jp [203.178.139.197]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id j4C2GZFj032732; Thu, 12 May 2005 11:16:36 +0900 In-Reply-To: <42824E9B.5060109@iprg.nokia.com> References: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> <42824E9B.5060109@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v728) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92C33F4F-C2D7-4EA4-95A0-4AD1B106E3F7@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too Date: Thu, 12 May 2005 11:16:32 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.728) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Jean-Michel COMBES 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all On 2005/05/12, at 3:27, Vijay Devarapalli wrote: > Jean-Michel COMBES wrote: > >> Hi, >> The RFC 3963 says in: >> (1) Section 3, p5 >> "When the Mobile Router moves away from the home link and attaches >> to a new >> access router, it acquires a Care-of Address from the visited >> link. The >> Mobile Router can at any time act either as a Mobile Host or as a >> Mobile >> Router. It acts as a Mobile Host as defined in [1] for sessions it >> originates and provides connectivity to the Mobile Network. As >> soon as the >> Mobile Router acquires a Care-of Address, it immediately sends a >> Binding >> Update to its Home Agent as described in [1]. When the Home Agent >> receives >> this Binding Update, it creates a cache entry binding the Mobile >> Router's >> Home Address to its Care-of Address at the current point of >> attachment." >> (2) Section 4.1, p7 >> "A new flag (R) is included in the Binding Update to indicate to >> the Home >> Agent whether the Binding Update is coming from a Mobile Router >> and not from >> a mobile node. The rest of the Binding Update format remains the >> same as >> defined in [1]." >> (3) Section 4.1, p7 >> "Mobile Router Flag (R) >> The Mobile Router Flag is set to indicate to the Home Agent that >> the Binding >> Update is from a Mobile Router. If the flag is set to 0, the Home >> Agent >> assumes that the Mobile Router is behaving as a Mobile Node, and >> it MUST NOT >> forward packets destined for the Mobile Network to the Mobile Router. >> Assuming that a MR is MN too, as described in (1), my questions >> are: - (2) seems to indicate that such a MR has to send 2 BU: one >> with R=0 for >> MIPv6 and one with R=1 for MIPv6. Am I wrong? >> > > nope. just one BU is enough. when the HA processes the R bit in > the BU, it sets up forwarding for the MNP in addition to creating > a binding cache for the home address as described in RFC 3775. Yes, HA can create a binding for HoA by the NEMO BU, but I want to clarify whether MR can start Route Optimization for the MR's HoA with the registered binding? I think possible, but this should not be mandated. regards, ryuji > >> - (3) seems to indicate that a HA cannot manage NEMO and MIPv6. >> > > nope. the HA can at the same time support MIPv6 MNs and NEMO MRs. > if the R bit in the BU is not set, the HA just creates a binding > cache for the home address, defends the home address and tunnels > packets meant for the home address to the current CoA. if the R > bit in the BU is set, the HA does the above *and* sets up forwarding > for the MNP. > > Vijay > From nemo-bounces@ietf.org Thu May 12 19:42:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWNKR-0005pK-RN; Thu, 12 May 2005 19:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWNKP-0005pE-VK for nemo@megatron.ietf.org; Thu, 12 May 2005 19:42:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20944 for ; Thu, 12 May 2005 19:42:50 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWNaD-0001Hv-K1 for nemo@ietf.org; Thu, 12 May 2005 19:59:15 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4CNBXg23646; Thu, 12 May 2005 16:11:33 -0700 X-mProtect: <200505122311> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141133.americas.nokia.com (172.18.141.133, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdZ2tk3s; Thu, 12 May 2005 16:11:32 PDT Message-ID: <4283E9DA.3050201@iprg.nokia.com> Date: Thu, 12 May 2005 16:42:18 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] RFC 3963: Clarifications if the MR is MN too References: <02eb01c554b0$80108230$75a1c10a@rd.francetelecom.fr> <42824E9B.5060109@iprg.nokia.com> <92C33F4F-C2D7-4EA4-95A0-4AD1B106E3F7@sfc.wide.ad.jp> In-Reply-To: <92C33F4F-C2D7-4EA4-95A0-4AD1B106E3F7@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Jean-Michel COMBES 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: >> nope. just one BU is enough. when the HA processes the R bit in >> the BU, it sets up forwarding for the MNP in addition to creating >> a binding cache for the home address as described in RFC 3775. > > Yes, HA can create a binding for HoA by the NEMO BU, but I want to > clarify > whether MR can start Route Optimization for the MR's HoA with the > registered binding? yes. everything the MN can do in RFC 3775, the MR can do for sessions started by itself using its own HoA. > I think possible, but this should not be mandated. thats correct. the MR can always use reverse tunneling for its own sessions as well. Vijay From nemo-bounces@ietf.org Fri May 13 21:29:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWlSs-0003U6-5l; Fri, 13 May 2005 21:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWlSq-0003TV-Qs; Fri, 13 May 2005 21:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29496; Fri, 13 May 2005 21:29:10 -0400 (EDT) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWlit-0006SL-AR; Fri, 13 May 2005 21:45:47 -0400 Received: from lombok-fi.grc.nasa.gov (seraph4.grc.nasa.gov [128.156.10.13]) by mx2.grc.nasa.gov (Postfix) with ESMTP id 8FAF2C327; Fri, 13 May 2005 21:29:03 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j4E1T3K9006899; Fri, 13 May 2005 21:29:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4E1T2OG029141; Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 09960-29; Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4E1T2r l029136;Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 09B8F33800F; Fri, 13 May 2005 21:29:02 -0400 (EDT) Received: from grc.nasa.gov (oh-northolmstead1-16-134.clvhoh.adelphia.net [6 8.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTPid 7612A33800D; F ri, 13 May 2005 21:29:00 -0400 (EDT) Message-ID: <42855467.8090606@grc.nasa.gov> Date: Fri, 13 May 2005 21:29:11 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo , mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.19 X-imss-result: Passed X-imss-approveListMatch: *@*.NASA.GOV X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] Space-based deployment of NEMO (IPv4 version) 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Sorry I have not been to active on the lists. Hopefully, that will change. At the last IETF meeting I had many requests for information on deployment of mobile networking onboard a satellite. I have finally completed the full detailed report and some executive summaries. The full report describes the deployment including how the network is set up, how the satellite network operates and even includes router configurations for the home agent, foreign agent and mobile router. An interesting note is that triangular routing or route optimization is definitely preferred over bidirectional tunneling due to rate mismatches - see the powerpoint presentation. The final report and executive summaries are available at the following URL: http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html A presentation that has animation of the data flow is available at the same URL - pick or move down to the "Presentations" section. "Secure, Network-Centric Operations of a Space-Based Asset: Cisco Router in Low-Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)" Net-Centric Operations 2005, May 10-11, 2005 Washington, DC ( Powerpoint) file size 5,871,616 bytes Sorry I have not been to active on the lists. Hopefully, that will change soon. Will From nemo-bounces@ietf.org Sun May 22 16:08:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwk7-0003A0-SW; Sun, 22 May 2005 16:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwk6-00038t-91 for nemo@megatron.ietf.org; Sun, 22 May 2005 16:08:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21560 for ; Sun, 22 May 2005 16:08:08 -0400 (EDT) Received: from losangeles.ucdavis.edu ([169.237.104.159]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZx1v-0001dq-Va for nemo@ietf.org; Sun, 22 May 2005 16:26:36 -0400 Received: from diometes.ucdavis.edu (diometes.ucdavis.edu [169.237.104.180]) by losangeles.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j4MK85Do024284 for ; Sun, 22 May 2005 13:08:05 -0700 (PDT) Received: from diometes.ucdavis.edu (localhost [127.0.0.1]) by diometes.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j4MK85uA008833 for ; Sun, 22 May 2005 13:08:05 -0700 (PDT) Received: (from www@localhost) by diometes.ucdavis.edu (8.12.10/8.12.9/Submit) id j4MK84Dt008832; Sun, 22 May 2005 13:08:04 -0700 (PDT) Date: Sun, 22 May 2005 13:08:04 -0700 (PDT) Message-Id: <200505222008.j4MK84Dt008832@diometes.ucdavis.edu> To: nemo@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [nemo] Call for Paper: JSAC-MRNM (The deadline is approaching.) 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com From nemo-bounces@ietf.org Fri May 27 17:06:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbm2k-0006w7-E8; Fri, 27 May 2005 17:06:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbm2i-0006ve-FR for nemo@megatron.ietf.org; Fri, 27 May 2005 17:06:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04262 for ; Fri, 27 May 2005 17:06:54 -0400 (EDT) Received: from mx1.grc.nasa.gov ([128.156.11.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbmLZ-0002cF-DK for nemo@ietf.org; Fri, 27 May 2005 17:26:26 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx1.grc.nasa.gov (Postfix) with ESMTP id 03336C303 for ; Fri, 27 May 2005 17:06:42 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j4RL6fK9027347 for ; Fri, 27 May 2005 17:06:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4RL6fg0026578 for ; Fri, 27 May 2005 17:06:41 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 13805-28 for ;Fri, 27 May 2005 17:06:41 -0400 (EDT) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j4RL6e7f026564for ; Fri, 27 May 2005 17:06:40 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 57EE233800F; Fri, 27 May 2005 17:06:40 -0400 (EDT) Received: from grc.nasa.gov (oh-northolmstead1-16-134.clvhoh.adelphia.net [68.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTP id CCD7433800Dfor ; Fri, 27 May 2005 17:06:39 -0400 (EDT) Message-ID: <42978BE1.3090900@grc.nasa.gov> Date: Fri, 27 May 2005 17:06:41 -0400 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.025 X-imss-result: Passed X-imss-approveListMatch: *@*.NASA.GOV X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Subject: [nemo] Space-based deployment of NEMO (IPv4 version) - 2nd transmission 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Please excuse me if this is the second transmission. I never saw the 1st sending on this list. At the last IETF meeting I had many requests for information on deployment of mobile networking onboard a satellite. I have finally completed the full detailed report and some executive summaries. The full report describes the deployment including how the network is set up, how the satellite network operates and even includes router configurations for the home agent, foreign agent and mobile router. An interesting note is that triangular routing or route optimization is definitely preferred over bidirectional tunneling due to rate mismatches - see the powerpoint presentation. The final report and executive summaries are available at the following URL: http://roland.grc.nasa.gov/~ivancic/papers_presentations/papers.html A presentation that has animation of the data flow is available at the same URL - pick or move down to the "Presentations" section. "Secure, Network-Centric Operations of a Space-Based Asset: Cisco Router in Low-Earth Orbit (CLEO) and Virtual Mission Operations Center (VMOC)" Net-Centric Operations 2005, May 10-11, 2005 Washington, DC ( Powerpoint) file size 5,871,616 bytes Sorry I have not been to active on the lists. Hopefully, that will change soon. Will From nemo-bounces@ietf.org Wed Jun 01 10:57:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUey-00012J-Vn; Wed, 01 Jun 2005 10:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaF30-0003Ee-1h; Mon, 23 May 2005 11:40:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06402; Mon, 23 May 2005 11:40:51 -0400 (EDT) Received: from xenia3-in0.renault.fr ([193.194.133.17] helo=xenia3.mc2.renault.fr) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaFKz-0000Jm-Nj; Mon, 23 May 2005 11:59:30 -0400 Received: from univers4.mc2.renault.fr (univers4-in0.mc2.renault.fr [10.210.68.9]) by xenia3.mc2.renault.fr (8.13.1/8.13.1) with ESMTP id j4NFej9C028255; Mon, 23 May 2005 17:40:45 +0200 (MEST) Received: from hepatite1.mc2.renault.fr (hepatite1.mc2.renault.fr [10.210.68.19]) by univers4.mc2.renault.fr (8.13.4/8.13.4) with SMTP id j4NFeXAD014342; Mon, 23 May 2005 17:40:33 +0200 (MEST) Received: from univers3-in0.mc2.renault.fr(10.210.68.1) by hepatite1.mc2.renault.fr via csmap id be9f74cc_cba0_11d9_8377_0002b3cb50ff_12410; Mon, 23 May 2005 17:38:43 +0200 (CEST) Received: from su356aos (su356aos.mc2.renault.fr [138.21.107.59]) by univers3.mc2.renault.fr (8.13.1/8.13.1) with ESMTP id j4NFboWZ026089; Mon, 23 May 2005 17:37:50 +0200 (MEST) Received: from su358aos (su358aos.mc2.renault.fr [138.21.107.206]) by wsmtp54.mc2.renault.fr (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IGY00J3U8R250@wsmtp54.mc2.renault.fr>; Mon, 23 May 2005 17:37:50 +0200 (MEST) Received: from FR20016868 ([10.230.213.114]) by wsmtpin57.mc2.renault.fr (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with SMTP id <0IGY00MD08R2KL@wsmtpin57.mc2.renault.fr>; Mon, 23 May 2005 17:37:50 +0200 (MEST) Date: Mon, 23 May 2005 17:37:41 +0200 From: LASNIER-REDDAN Edouard To: mip6@ietf.org, nemo@ietf.org Message-id: <02b701c55fad$5b8f3520$72d5e60a@corp.noxiane.net> Organization: Renault MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/mixed; boundary="Boundary_(ID_13UhgGNevmVhLRQsXXC+KA)" X-Priority: 3 X-MSMail-priority: Normal X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd X-Mailman-Approved-At: Wed, 01 Jun 2005 10:57:30 -0400 Cc: HORKAY Francois Subject: [nemo] Requirement of a Car Manufacturer for real MIPv6 large deployments (IPv4 NAT traversal feature) 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format... --Boundary_(ID_13UhgGNevmVhLRQsXXC+KA) Content-type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by univers3.mc2.renault.fr id j4NFboWZ026089 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear NEMO WG participants, The car manufacturer RENAULT is involved in several research projects dealing with IP mobility since 2001. One of our major achievements was the RENAULT Laguna "IPv6 Car", supporting Mobile IPv6. This telematic concept car received the "Murai Award" in 2003 in Tokyo for its capability to support GPRS (2G European cellular network) / Wifi vertical handover, using Mobile IPv6 with IPv4 NAT traversal feature (the NAT traversal function, called "DOORS", was developed by Cisco Systems, it did provide efficient results and is compatible with our deployment constraints for further commercial exploitations). Mobile IPv6 is considered by the car manufacturers as a key technology for the deployment of next generation Telematic services, such as remote diagnosis, fleet management, etc. This trend has been confirmed by the current work of the research project GST - Global System for Telematics, in which RENAULT, BMW, DAIMLER CHRYSLER, FIAT and many other actors of the Telematic Industry work on standardization convergence : IPv6 is now part of the core specification for a European standard for telematics, mainly because of its mobility features. If it is agreed by the automotive industry that IPv6 paves the future of the telematic market, the existing constraints on the deployment of Mobile IPv6 makes the finalization of the standard very sensitive: 1. For the car manufacturers, Mobile IPv6 will have to be deployed soon on top of existing cellular networks, such as GPRS, EDGE or UMTS, all based on IPv4. In order to remain independent from the mobile telecom operator, it is mandatory to deploy Mobile IPv6 with a NAT traversal support. Deploying MIPv6 without a NAT traversal feature would be a non sense: if the car manufacturers have to setup technical agreements with the mobile telecom operators to deploy MIPv6, then many other solutions can be considered, and MIPv6 leads to a situation of dependence toward the mobile telecom operators, which is not acceptable. MIPv6 should not limit the possible business models : it should enable the actors of the value chain to define their business model, and in this MIPv6 context, it means that MIPv6 should be flexible and not compel the Home Agent to be directly connected to the Internet. 2. Having NAT traversal feature is a required feature but the technical solution defined at the IETF should take into consideration the deployment constraints. In the next 18 months, MIPv6 will be mainly deployed for pilot experiments, for validation before a wider deployment. In this context, the Home Agent is in many cases in existing small networks dedicated to pilot experiments initially designed for IPv4, with NAT boxes on the Internet interface. This constraint is a fact, and is valid for many projects. 3. On a long term perspective, the car manufacturers - or any actors from the telematic industry supplying IP mobility support for the cars - will deploy MIPv6 on their enterprise networks. Those networks are secured, designed for IPv4, and most probably the Home Agent will not be directly interfaced with the Internet, it will be a secured equipment in the core of the network, behind NATs. This problem is in fact very common as enterprise networks are connected to the Internet behind NATs in general. If the deployment of Mobile IPv6 requires re-designing the car manufacturers networks because security policies and existing NAT features are not supported, then Mobile IPv6 will remain a beautiful idea that no company will be able to deploy. Mobile IPv6 should support multiple IPv4 Network Address Translation (in the access networks, and in front of the Home network). The Home Agent may be deployed on IPv4 networks behind NAT access to the Internet. I have currently several industrial projects for which I could deploy MIPv6 _for real_ if the IPv4 NAT traversal would be normalized and enable Home Agent to be connected to the internet behind NATs and other boxes. Edouard LASNIER REDDAN, Telecom Solution for Telematics, RENAULT, on May 2nd, 2005 ************** Cordialement / Best Regards / Mit Freundlichen Gr=FCssen Edouard Lasnier Reddan. edouard.lasnier-reddan@renault.com Office : + 33 (0)1 76 84 71 93 / Fax : + 33 (0)1 76 84 91 16 RENAULT 13 avenue Paul Langevin / API : FR EQV NOV 3 32 92359 Le Plessis Robinson Cedex France --Boundary_(ID_13UhgGNevmVhLRQsXXC+KA) Content-type: text/x-vcard; name="Edouard LASNIER REDDAN.vcf" Content-Disposition: attachment; filename="Edouard LASNIER REDDAN.vcf" Content-Transfer-Encoding: 7BIT BEGIN:VCARD VERSION:2.1 N:LASNIER REDDAN;Edouard FN:Edouard LASNIER REDDAN ORG:Renault;DTSI - T2IA / 50820 TITLE:IT & Telematic Engineer TEL;WORK;VOICE:+33 (0)1 76 84 71 93 TEL;CELL;VOICE:+ 33 (0)6 07 26 87 20 TEL;WORK;FAX:+33 (0)1 76 84 91 16 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Novadis, 3=E8me =E9tage, Module 1;13 avenue Paul Langevin =0D=0AAPI : FR EQ= V NOV 3 32=0D=0A=0D=0AFrance=0D=0A;Le Plessis Robinson Cedex;92;92359;France LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Novadis, 3=E8me =E9tage, Module 1=0D=0A13 avenue Paul Langevin =0D=0AAPI : F= R EQV NOV 3 32=0D=0A=0D=0AFrance=0D=0A=0D=0ALe Plessis Robinson Cedex, 92 92= 359=0D=0AFrance ADR;HOME:;;;;;;France LABEL;HOME:France X-WAB-GENDER:2 EMAIL;PREF;INTERNET:edouard.lasnier-reddan@renault.com REV:20050523T153741Z END:VCARD --Boundary_(ID_13UhgGNevmVhLRQsXXC+KA) Content-Type: text/plain; name="disclaimer.txt" Content-Disposition: inline; filename="disclaimer.txt" MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) Content-Transfer-Encoding: 7bit -- Disclaimer ------------------------------------ Ce message ainsi que les eventuelles pieces jointes constituent une correspondance privee et confidentielle a l'attention exclusive du destinataire designe ci-dessus. Si vous n'etes pas le destinataire du present message ou une personne susceptible de pouvoir le lui delivrer, il vous est signifie que toute divulgation, distribution ou copie de cette transmission est strictement interdite. Si vous avez recu ce message par erreur, nous vous remercions d'en informer l'expediteur par telephone ou de lui retourner le present message, puis d'effacer immediatement ce message de votre systeme. *** This e-mail and any attachments is a confidential correspondence intended only for use of the individual or entity named above. If you are not the intended recipient or the agent responsible for delivering the message to the intended recipient, you are hereby notified that any disclosure, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender by phone or by replying this message, and then delete this message from your system. --Boundary_(ID_13UhgGNevmVhLRQsXXC+KA)--