From nemo-bounces@ietf.org Fri Feb 03 10:18:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52ht-0006uC-6I; Fri, 03 Feb 2006 10:18:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52e5-0005lS-Tj for nemo@megatron.ietf.org; Fri, 03 Feb 2006 10:14:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08536 for ; Fri, 3 Feb 2006 10:13:07 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F52pe-0006DI-Pz for nemo@ietf.org; Fri, 03 Feb 2006 10:26:45 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2006 16:14:33 +0100 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 k13FEU5i027242; Fri, 3 Feb 2006 16:14:31 +0100 (MET) 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); Fri, 3 Feb 2006 16:14:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: Home Network models update Date: Fri, 3 Feb 2006 16:14:08 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01C2BDBB@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: Home Network models update Thread-Index: AcYdvvHLa20SP0UDT8aMQ4nkH7BHLwLFRKCQ From: "Pascal Thubert \(pthubert\)" To: "Pekka Savola" , "Alexandru Petrescu" X-OriginalArrivalTime: 03 Feb 2006 15:14:30.0451 (UTC) FILETIME=[87E16030:01C628D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Pekka, Alex: I understand the concern.=20 For the last 2 weeks, nobody else voiced an advice.=20 My take is that if I had to do it again, I'd follow your recommendation. But now it's all done, checked (I deployed it on hardware) and things like fitting the ascii art would require quite some work if I had to change.=20 So I wish to leave it as is. Pascal >-----Original Message----- >From: Pekka Savola [mailto:pekkas@netcore.fi] >Sent: Friday, January 20, 2006 1:42 PM >To: Alexandru Petrescu >Cc: Pascal Thubert (pthubert); nemo@ietf.org >Subject: Re: [nemo] RE: Home Network models update > >On Thu, 19 Jan 2006, Alexandru Petrescu wrote: >> Pekka Savola wrote: >>> On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: >>>> "To illustrate this configuration, we make up the prefixes to >>>> reflect their role, like CAB:C0::/32 for the Home Network:" >>> ... >>>> Is that OK with you? >>> >>> OK. >> >> Otherwise maybe make example 2001:DB8:cabc:0::/56 and then refer it into >> the text as "the Cab Co prefix"? > >Let me expand on my feelings on this. > >ID-Checklist makes it quite clear that other than 2001:DB8::/32 should >not be used. But that is just a guideline, and there have been cases >in the past (I've written one myself: see RFC 3964) where it has been >reasonable to use other prefixes instead. > >In such cases, documenting the justification (and placing a warning) >has been required. > >Personally, I'm not really convinced that using CAB:C0::/32 brings >enough value (I don't think it can be confused because it's only used >in one section of the document, and other prefixes aren't mentioned in >that part of the document). But given that I don't think this issue >is major and at least some reason has been proposed, I think this >issue should be decided by the WG and the AD (Margaret). > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Fri Feb 03 10:28:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52rI-000355-Ri; Fri, 03 Feb 2006 10:28:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52r5-0002ts-9b for nemo@megatron.ietf.org; Fri, 03 Feb 2006 10:28:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10708 for ; Fri, 3 Feb 2006 10:26:33 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F532g-00075Q-UV for nemo@ietf.org; Fri, 03 Feb 2006 10:40:11 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k13FgW69025190; Fri, 3 Feb 2006 08:42:32 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k13FdDO6029410; Fri, 3 Feb 2006 09:39:14 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 12432865980; Fri, 3 Feb 2006 16:27:55 +0100 (CET) Message-ID: <43E3767A.8080107@motorola.com> Date: Fri, 03 Feb 2006 16:27:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: Home Network models update References: <7892795E1A87F04CADFCCF41FADD00FC01C2BDBB@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01C2BDBB@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Pekka Savola 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: > Pekka, Alex: > > I understand the concern. > > For the last 2 weeks, nobody else voiced an advice. > > My take is that if I had to do it again, I'd follow your > recommendation. But now it's all done, checked (I deployed it on > hardware) Pascal, I think that anybody who advised you can go ahead assign cab:c0::/64 to your hardware is completely wrong. That hardware will never connect to the Internet. > and things like fitting the ascii art would require quite some work > if I had to change. I don't think there's any hurry to set in stone some document saying that, for example, some hardware actually uses cab:co::/64. I also understand the concern that modifying text may involve more re-checking beyond the already done check. Alex > > So I wish to leave it as is. > > Pascal > >> -----Original Message----- From: Pekka Savola >> [mailto:pekkas@netcore.fi] Sent: Friday, January 20, 2006 1:42 PM >> To: Alexandru Petrescu Cc: Pascal Thubert (pthubert); nemo@ietf.org >> Subject: Re: [nemo] RE: Home Network models update >> >> On Thu, 19 Jan 2006, Alexandru Petrescu wrote: >>> Pekka Savola wrote: >>>> On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: >>>>> "To illustrate this configuration, we make up the prefixes to >>>>> reflect their role, like CAB:C0::/32 for the Home Network:" >>>> ... >>>>> Is that OK with you? >>>> >>>> OK. >>> >>> Otherwise maybe make example 2001:DB8:cabc:0::/56 and then refer >>> it > into >>> the text as "the Cab Co prefix"? >> >> Let me expand on my feelings on this. >> >> ID-Checklist makes it quite clear that other than 2001:DB8::/32 >> should not be used. But that is just a guideline, and there have >> been cases in the past (I've written one myself: see RFC 3964) >> where it has been reasonable to use other prefixes instead. >> >> In such cases, documenting the justification (and placing a >> warning) has been required. >> >> Personally, I'm not really convinced that using CAB:C0::/32 brings >> enough value (I don't think it can be confused because it's only >> used in one section of the document, and other prefixes aren't >> mentioned in that part of the document). But given that I don't >> think this issue is major and at least some reason has been >> proposed, I think this issue should be decided by the WG and the AD >> (Margaret). >> >> -- Pekka Savola "You each name yourselves king, yet >> the Netcore Oy kingdom bleeds." Systems. >> Networks. Security. -- George R.R. Martin: A Clash of Kings > From nemo-bounces@ietf.org Fri Feb 03 10:32:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52v6-0006Pe-72; Fri, 03 Feb 2006 10:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F52v4-0006Mr-LA for nemo@megatron.ietf.org; Fri, 03 Feb 2006 10:32:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10972 for ; Fri, 3 Feb 2006 10:30:40 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F536c-0007Ca-RD for nemo@ietf.org; Fri, 03 Feb 2006 10:44:18 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2006 16:32:05 +0100 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 k13FVe5w001556; Fri, 3 Feb 2006 16:32:02 +0100 (MET) 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); Fri, 3 Feb 2006 16:31:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: Home Network models update Date: Fri, 3 Feb 2006 16:31:52 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01C2BDCF@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: Home Network models update Thread-Index: AcYo1mvWdmp2ryabTsWtSSS/GrhukgAAFemQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 03 Feb 2006 15:31:59.0569 (UTC) FILETIME=[F9341410:01C628D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, Pekka Savola 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: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] >Sent: Friday, February 03, 2006 4:28 PM >To: Pascal Thubert (pthubert) >Cc: Pekka Savola; nemo@ietf.org >Subject: Re: [nemo] RE: Home Network models update > >Pascal Thubert \(pthubert\) wrote: >> Pekka, Alex: >> >> I understand the concern. >> >> For the last 2 weeks, nobody else voiced an advice. >> >> My take is that if I had to do it again, I'd follow your >> recommendation. But now it's all done, checked (I deployed it on >> hardware) > >Pascal, I think that anybody who advised you can go ahead assign >cab:c0::/64 to your hardware is completely wrong. That hardware will >never connect to the Internet. [] Sure, that was just a demo. But it proved that the set up was correct > >> and things like fitting the ascii art would require quite some work >> if I had to change. > >I don't think there's any hurry to set in stone some document saying >that, for example, some hardware actually uses cab:co::/64. > >I also understand the concern that modifying text may involve more >re-checking beyond the already done check. > [] Yes, that's the whole point. I do not have the time to do it all over again. Pascal From nemo-bounces@ietf.org Sun Feb 05 20:28:00 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5vAe-0001pX-5Z; Sun, 05 Feb 2006 20:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5vAa-0001ns-Si for nemo@megatron.ietf.org; Sun, 05 Feb 2006 20:27:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01219 for ; Sun, 5 Feb 2006 20:26:03 -0500 (EST) Received: from f.csce.kyushu-u.ac.jp ([133.5.33.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1F5vMR-0001ku-AU for nemo@ietf.org; Sun, 05 Feb 2006 20:40:14 -0500 Received: (qmail 18681 invoked from network); 6 Feb 2006 01:27:37 -0000 Received: from unknown (HELO ?172.17.3.211?) (192.168.77.254) by 192.168.77.101 with SMTP; 6 Feb 2006 01:27:37 -0000 Date: Mon, 06 Feb 2006 10:27:25 +0900 From: Teruaki Kitasuka To: manet@ietf.org, mip4@ietf.org, mip6@ietf.org, mipshop@ietf.org, monami6@ietf.org, nemo@ietf.org Message-Id: <20060206102247.07A8.KITASUKA@f.csce.kyushu-u.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [ja] X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: Subject: [nemo] CfP - 3rd Int. Conf. on Mobile Computing and Ubiquitous Networking (ICMU2006) at London, UK 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 (Apologies if you receive multiple copies of this message) ======================================================================== C A L L F O R P A P E R S ======================================================================== The Third International Conference on Mobile Computing and Ubiquitous Networking (ICMU2006) October 11-13, 2006 BCS London Office, London, UK http://www.icmu.org/icmu2006/ Sponsored by: IPSJ SIG-MBL (Information Processing Society of Japan, Special Interest Group of Mobile Computing and Ubiquitous Networking) Technically co-sponsored by: BCS (British Computer Society) and IEE (Institution of Electrical Engineers) Supported by: ICF (International Communications Foundation) SCOPE: Mobile computing aims at ubiquitous user access to computer application. To make it possible, networking technology which enables Internet access anytime and everywhere, i.e. ubiquitous networking is necessary. It is obvious that with the accelerating trends towards mobile networks, ad-hoc networks, and wireless networks, mobile computing and ubiquitous networking will play an important role in future network. This conference is aimed at providing researchers and practitioners in this hot research area a forum for discussion and collaboration. Authors are invited to submit papers addressing, but not limited to, the following topics: - Network management for ubiquitous networking - Data management for mobile computing - Mobile device management - Performance evaluation for mobile computing and ubiquitous networking systems - Broadcast communications - Network architectures, protocols, or service models for ubiquitous networking - Security in mobile computing and ubiquitous networking - Mobile OS - Wireless and mobile communications - 4G wireless communications - Mobile Internetworking - Ad-hoc networks - Network mobility - Mesh networks - Sensor networks - Location-based services SUBMISSION INSTRUCTIONS: Papers are solicited as full papers of no more than 6 pages, each of which will be subject to a full review process. Submission should already follow the author guidelines as specified in the web site below. An electronic, PDF-based submission of papers is mandatory. Please check the web site of the conference http://www.icmu.org/icmu2006/ for further submission instructions. After the conference, a selected number of papers will be published as special issues in IPSJ journal and IPSJ Digital Courier. Please check the web site of IPSJ http://www.ipsj.or.jp/08editt/dc/index.html for the details of IPSJ Digital Coulier. IMPORTANT DATES: ########################################################## # Deadline for submissions: April 22, 2006 # # Notification of acceptance: July 8, 2006 # # Camera ready due: July 31, 2006 # ########################################################## ORGANIZING COMMITTEE: General Chair: Chai-Keong Toh (Queen Mary University of London, UK) Technical Program Committee Co-Chairs: Susumu Ishihara (Shizuoka University, Japan) Eiji Kamioka (National Institute of Informatics, Japan) Publication Co-Chairs: Gen Kitagata (Tohoku University, Japan) Yang Yang (University College London, UK) Publicity Co-Chairs: Teruaki Kitasuka (Kyushu University, Japan) Kun Yang (University of Essex, UK) Local Arrangement Chair: David Martland (Kingston University London, UK) Treasurers: Tomohiko Yagyu (NEC, Japan) David Martland (Kingston University London, UK) Registration Chair: David Martland (Kingston University London, UK) ICMU STEERING COMMITTEE: Tadanori Mizuno (Shizuoka University, Japan) Osamu Takahashi (Future University-Hakodate, Japan) Takashi Watanabe (Shizuoka University, Japan) Miki Yamamoto (Kansai University, Japan) TECHNICAL PROGRAM COMMITTEE: Mohammed Atiquzzaman (University of Oklahoma, USA) Xiuzhen Cheng (George Washington University, USA) We Duke Cho (Ajou University, Korea) Terry Dodgson (SAMSUNG, UK) John Gardiner (Bradford University, UK) Teruo Higashino (Osaka University, Japan) Choong Seon Hong (Kyung Hee University, Korea) Russell Hsing (Telcordia Technologies, USA) Chung Ming Huang (National Cheng Kung University, Taiwan) Joseph Hui (Arizona State University, USA) Masugi Inoue (NICT, Japan) Masahiro Ishiyama (Toshiba Corporation, Japan) Holger Karl (University of Paderborn, Germany) Hughes Kester (Qinetiq Ltd, UK) Dongkyun Kim (Kyungpook National University, Korea) Peter Langendoerfer (IHP Microelectronics, Germany) Madjid Merabti (Liverpool John Moores University, UK) Isabelle Moreau (Mitsubishi Electric ITE, France) Hiroyuki Morikawa (University of Tokyo, Japan) Yasuto Nakanishi (Keio University, Japan) Ken Ohta (NTT DoCoMo, Japan) Ryouji Ono (Mitsubishi Electric, Japan) Mohamed Ould-Khaoua (University of Glasgow, UK) Antonio Pescape (University of Napoli, Italy) Petar Popovski (Aalborg University, Denmark) Jeremy Randles (British Telecom, UK) Ichiro Satoh (National Institute of Informatics, Japan) Winston Seah (Institute for Infocomm Research, Singapore) Hiroshi Shigeno (Keio University, Japan) Biplab Sikdar (Rensselaer Polytechnic Institute, USA) David Simplot-Ryl (University of Lille 1, France) Tatsuya Suda (University of California Irvine, USA) Shinta Sugimoto (Nippon Ericsson, Japan) Keisuke Suwa (Musashi Institute of Technology, Japan) Kevin W. Tsai (University of California, Irvine, USA) Xin Wang (Fudan University, China) Neil Williams (ERA Technology Ltd, UK) Nik Van den Wingaert (University of Antwerp, Belgium) Hirozumi Yamaguchi (Osaka University, Japan) Kun Yang (Essex University, UK) Yang Yang (University College London, UK) Masashi Yano (Hitachi Ltd, Japan) Hidetoshi Yokota (KDDI R&D Laboratories, Japan) Ekio Yoneki (Cambridge University, UK) Qing-An Zeng (University of Cincinnati, USA) --------------------- Original Message Ends -------------------- From nemo-bounces@ietf.org Thu Feb 09 06:36:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7A60-000443-VV; Thu, 09 Feb 2006 06:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7A5w-00042Y-J9 for nemo@megatron.ietf.org; Thu, 09 Feb 2006 06:36:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11851 for ; Thu, 9 Feb 2006 06:34:24 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7AIa-0003Yc-Im for nemo@ietf.org; Thu, 09 Feb 2006 06:49:21 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Feb 2006 12:35:57 +0100 Received: from xbh-ams-331.emea.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 k19BZQ65004178; Thu, 9 Feb 2006 12:35:54 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Feb 2006 12:35:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Feb 2006 12:35:32 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDC697@xmb-ams-337.emea.cisco.com> Thread-Topic: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYUC2FOSanpE3A4SiaIAQWIA4c2bAZYLJEg From: "Pascal Thubert \(pthubert\)" To: "Margaret Wasserman" , , , , X-OriginalArrivalTime: 09 Feb 2006 11:35:38.0353 (UTC) FILETIME=[F304BE10:01C62D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: draft-ietf-nemo-home-network-models-05 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: At IESG review, a number of questions and issues were raised against the home network models draft. A pre-version 6 of the draft was edited to address them. It is available at: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-xx.txt=20 Issue list: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-issues.html In particular, issue 9 was a "discuss" item. In fact, the text did not appear particularly useful, and would have lead to discussion going above and beyond the scope of the draft; so the text was simply removed. Comments welcome :) Pascal=20 >-----Original Message----- >From: Margaret Wasserman [mailto:MRW@devicescape.com] >Sent: Sunday, January 08, 2006 5:24 AM >To: Pascal Thubert (pthubert); ryuji@sfc.wide.ad.jp; vijay.devarapalli@nokia.com; tj@kniveton.com; >ernst@sfc.wide.ad.jp >Subject: draft-ietf-nemo-home-network-models-05 > > >Hi All, > >I wanted to check on the status of >draft-ietf-nemo-home-network-models-05... This document was reviewed by >the IESG on 12/1/2005, and there was one blocking issue ("discuss") >raised by Ted. There were also some comments from other ADs. I have >included Ted's discuss and the other comments below for reference. > >Authors, have you had a chance to look at Ted's discuss and the other >comments? Do you have any questions about these issues and/or do you >have a plan to update the document to address them? > >Theirry and TJ, which one of you is serving as the PROTO shepherd for >this document? Please let me know, so that I can include a comment in >the tracker. And, also, could whichever one of you is shepherding the >document please make sure that these issues get resolved? > >I am going to put the document into the "Revised ID Needed" substate and >wait for an update. If it turns out that no document update is needed >to address these concerns, please let me know. > >Thanks, >Margaret > >--- > > >Ted Hardie: >Discuss: >[2005-11-29] In 6.4.1, the document says: > > Thus, on the Home Link, the Home Agent must intercept all the packets > to ALL the Mobile Network Nodes on the registered prefixes. In order > to do so, the Home Agent might perform some form of ND proxying for > all addresses in all registered Mobile Network Prefixes. The Home > Agent must also protect the MNP space from autoconfiguration by > uncontrolled visitors at Neighbor Discovery level. > > Alternatives based on a routing protocol or ICMP redirect may apply > in some cases. > >The second paragraph is not clear to me. Is the intent to say that ICMP >redirect >or some routing protocol behavior will substitute for ND proxying? > >Comment: >[2005-11-29] The document uses this example: > >"Cab Co is a taxi Company that owns a /32 prefix" > >The phrase "owns a /NN prefix" might be better put as "uses". The >question of ownership and >address prefixes has been the subject of non-technical debate over the >years, and skipping it >might make sense. > >Scott Hollenbeck: >Comment: >[2005-11-29] The citation "[8]" should be removed from the Abstract and >the technical summary portion of the ballot write-up. > >David Kessens: >Comment: >[2005-11-30] Comments from the Ops directorate by Pekka Savola: > >I found this document reasonably clear. I do not think there are any >blocking issues, but there seem to be suitably many editorial >clarifications that could help. As the doc has normative refs to work >that is still at WG, there should be time to revise it. > >semi-editorial issues >--------------------- > > > If the Mobile Router returns Home by Egress, a specific support is > required to control the bridging operation depending on whether a > Mobile Router is at Home or not. This support might not be present > in all implementations. > >=3D=3D> in a number of places you say "present in ... implementations" = .. >but what about the specifications? Do specifications provide with >sufficient mechanisms to convey which mechanism should be used by >mobile routers in each of the scenarios so that they would pick an >interoperable and/or working approach? (As I haven't studied the >specs in detail, I don't know the answer -- this is just something >that was not apparent from reading the doc.) > >13.1 normative reference >... > [9] Ernst, T. and H. Lach, "Network Mobility Support Terminology", > draft-ietf-nemo-terminology-03 (work in progress), > February 2005. > > [10] Ernst, T., "Network Mobility Support Goals and Requirements", > draft-ietf-nemo-requirements-04 (work in progress), > February 2005. > >=3D=3D> these two are normative references but are still at WG. The >publication of this document will be blocked until these are published >as well... I hope the WG is aware of this. > >editorial >--------- > >=3D=3D> examples used the prefixes A:B:C::/48 and CAB:C0::/32. You = should >use 2001:db8::/32 instead as it's specifically meant as a doc prefix -- >unless you have strong reasons for otherwise. > > >=3D=3D> a number of terms weren't spelled out, such as MNP, MNN, ... > >Abstract > > This paper documents some usage patterns and the associated issues > when deploying a Home Network for NEMO-enabled Mobile Routers, > conforming the NEMO Basic Support draft [8]. > >=3D=3D> no refs in the abstract. Don't use the word, "draft" = especially if >it's >an RFC ;-). > > The following terms used in this document are defined in the IPv6 > Addressing Architecture document [5]: > > link-local unicast address > > link-local scope multicast address > >=3D=3D> these terms are in fact not used in this doc, so this can be >removed. > >6.2 [Aggregated Home Network - Returning home] >... > Since the Home Network prefix is an aggregation that encompasses all > the MNPs, the Home Address that an MR forms from one of its Mobile > Network Prefixes will actually match both the Home Network prefix and > its Mobile Network prefix. To properly identify the Home Network, > the MR must expect a shorter prefix than that of the Mobile Network > from which the Home Address was formed. > > When the Mobile Router forms its Home Address out of one of its > Mobile Network Prefixes, since the Home Network prefix is an > aggregation that encompasses all the MNPs, the Home Address actually > matches both prefixes. As a result, the MR must expect a shorter > prefix than that of the Mobile Network from which the Home Address > was formed. > >=3D=3D> Isn't the 2nd paragraph baiscally text duplication of the = first, or >was >there a separate point there? I had hard time following this. In any >case, >I'd suggest rewording. > >Please > refer to the NEMO multihoming issues [13] draft for more on this. > >=3D=3D remove or reword "draft" > > One should check with the product specifications of an Home Agent to > see whether the implementation actually supports a Virtual Home > Network, and if so, whether in that cases, it is optimized for faster > DAD-less bindings. > >=3D=3D> remove "with". Is the present wording even good for an IETF = doc? From nemo-bounces@ietf.org Thu Feb 09 08:15:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Bdz-0006J0-Up; Thu, 09 Feb 2006 08:15:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7Bdr-0006Gm-O3 for nemo@megatron.ietf.org; Thu, 09 Feb 2006 08:15:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19558 for ; Thu, 9 Feb 2006 08:13:39 -0500 (EST) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Bqb-00079W-7L for nemo@ietf.org; Thu, 09 Feb 2006 08:28:35 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k19DYOrG007254; Thu, 9 Feb 2006 06:34:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k19DPi7K024124; Thu, 9 Feb 2006 07:25:45 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id ACD57865980; Thu, 9 Feb 2006 14:14:47 +0100 (CET) Message-ID: <43EB4047.1090709@motorola.com> Date: Thu, 09 Feb 2006 14:14:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01CDC697@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01CDC697@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert \(pthubert\) wrote: [...] > In fact, the text did not appear particularly useful, and would have > lead to discussion going above and beyond the scope of the draft; so > the text was simply removed. If that ICMP Redirect text (between HA and MR) did not appear to be particularly useful then I wonder how proxy ND by HA for _all_ addresses in the moving network is of any use at all. By RFC3963 the HA does proxy ND only for MR's Home Address. draft-ietf-nemo-home-network-models-xx.txt: > Thus, on the Home Link, the Home Agent must intercept all the packets > to ALL the Mobile Network Nodes on the registered prefixes. In > order to do so, the Home Agent might perform some form of ND proxying > for all addresses in all registered Mobile Network Prefixes. This above paragraph makes no particular sense at all, since a HA doing proxy ND for a LFN node which is below MR will intercept packets from all the neighbours of HA addressed to LFN, even though it is the MR who should intercept or receive those packets. There can be no "proxy ND" for an LFN on HA's link as long as the normal ND of same LFN is not happening on the home link. Alex > > Comments welcome :) > > Pascal > >> -----Original Message----- From: Margaret Wasserman >> [mailto:MRW@devicescape.com] Sent: Sunday, January 08, 2006 5:24 AM >> To: Pascal Thubert (pthubert); ryuji@sfc.wide.ad.jp; > vijay.devarapalli@nokia.com; tj@kniveton.com; >> ernst@sfc.wide.ad.jp Subject: >> draft-ietf-nemo-home-network-models-05 >> >> >> Hi All, >> >> I wanted to check on the status of >> draft-ietf-nemo-home-network-models-05... This document was >> reviewed > by >> the IESG on 12/1/2005, and there was one blocking issue ("discuss") >> raised by Ted. There were also some comments from other ADs. I >> have included Ted's discuss and the other comments below for >> reference. >> >> Authors, have you had a chance to look at Ted's discuss and the >> other comments? Do you have any questions about these issues >> and/or do you have a plan to update the document to address them? >> >> Theirry and TJ, which one of you is serving as the PROTO shepherd >> for this document? Please let me know, so that I can include a >> comment in the tracker. And, also, could whichever one of you is >> shepherding the document please make sure that these issues get >> resolved? >> >> I am going to put the document into the "Revised ID Needed" >> substate > and >> wait for an update. If it turns out that no document update is >> needed to address these concerns, please let me know. >> >> Thanks, Margaret >> >> --- >> >> >> Ted Hardie: Discuss: [2005-11-29] In 6.4.1, the document says: >> >> Thus, on the Home Link, the Home Agent must intercept all the >> packets to ALL the Mobile Network Nodes on the registered prefixes. >> In order to do so, the Home Agent might perform some form of ND >> proxying for all addresses in all registered Mobile Network >> Prefixes. The Home Agent must also protect the MNP space from >> autoconfiguration by uncontrolled visitors at Neighbor Discovery >> level. >> >> Alternatives based on a routing protocol or ICMP redirect may apply >> in some cases. >> >> The second paragraph is not clear to me. Is the intent to say that >> >> > ICMP >> redirect or some routing protocol behavior will substitute for ND >> proxying? >> >> Comment: [2005-11-29] The document uses this example: >> >> "Cab Co is a taxi Company that owns a /32 prefix" >> >> The phrase "owns a /NN prefix" might be better put as "uses". The >> question of ownership and address prefixes has been the subject of >> non-technical debate over the years, and skipping it might make >> sense. >> >> Scott Hollenbeck: Comment: [2005-11-29] The citation "[8]" should >> be removed from the Abstract and the technical summary portion of >> the ballot write-up. >> >> David Kessens: Comment: [2005-11-30] Comments from the Ops >> directorate by Pekka Savola: >> >> I found this document reasonably clear. I do not think there are >> any blocking issues, but there seem to be suitably many editorial >> clarifications that could help. As the doc has normative refs to >> work that is still at WG, there should be time to revise it. >> >> semi-editorial issues --------------------- >> >> >> If the Mobile Router returns Home by Egress, a specific support is >> required to control the bridging operation depending on whether a >> Mobile Router is at Home or not. This support might not be >> present in all implementations. >> >> ==> in a number of places you say "present in ... implementations" >> .. but what about the specifications? Do specifications provide >> with sufficient mechanisms to convey which mechanism should be used >> by mobile routers in each of the scenarios so that they would pick >> an interoperable and/or working approach? (As I haven't studied >> the specs in detail, I don't know the answer -- this is just >> something that was not apparent from reading the doc.) >> >> 13.1 normative reference ... [9] Ernst, T. and H. Lach, "Network >> Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work >> in progress), February 2005. >> >> [10] Ernst, T., "Network Mobility Support Goals and Requirements", >> draft-ietf-nemo-requirements-04 (work in progress), February 2005. >> >> >> >> ==> these two are normative references but are still at WG. The >> publication of this document will be blocked until these are >> published as well... I hope the WG is aware of this. >> >> editorial --------- >> >> ==> examples used the prefixes A:B:C::/48 and CAB:C0::/32. You >> should use 2001:db8::/32 instead as it's specifically meant as a >> doc prefix -- unless you have strong reasons for otherwise. >> >> >> ==> a number of terms weren't spelled out, such as MNP, MNN, ... >> >> Abstract >> >> This paper documents some usage patterns and the associated issues >> when deploying a Home Network for NEMO-enabled Mobile Routers, >> conforming the NEMO Basic Support draft [8]. >> >> ==> no refs in the abstract. Don't use the word, "draft" >> especially if it's an RFC ;-). >> >> The following terms used in this document are defined in the IPv6 >> Addressing Architecture document [5]: >> >> link-local unicast address >> >> link-local scope multicast address >> >> ==> these terms are in fact not used in this doc, so this can be >> removed. >> >> 6.2 [Aggregated Home Network - Returning home] ... Since the Home >> Network prefix is an aggregation that encompasses all the MNPs, the >> Home Address that an MR forms from one of its Mobile Network >> Prefixes will actually match both the Home Network prefix and its >> Mobile Network prefix. To properly identify the Home Network, the >> MR must expect a shorter prefix than that of the Mobile Network >> from which the Home Address was formed. >> >> When the Mobile Router forms its Home Address out of one of its >> Mobile Network Prefixes, since the Home Network prefix is an >> aggregation that encompasses all the MNPs, the Home Address >> actually matches both prefixes. As a result, the MR must expect a >> shorter prefix than that of the Mobile Network from which the Home >> Address was formed. >> >> ==> Isn't the 2nd paragraph baiscally text duplication of the >> first, or was there a separate point there? I had hard time >> following this. In any case, I'd suggest rewording. >> >> Please refer to the NEMO multihoming issues [13] draft for more on >> this. >> >> == remove or reword "draft" >> >> One should check with the product specifications of an Home Agent >> to see whether the implementation actually supports a Virtual Home >> Network, and if so, whether in that cases, it is optimized for >> faster DAD-less bindings. >> >> ==> remove "with". Is the present wording even good for an IETF >> doc? > From nemo-bounces@ietf.org Fri Feb 10 03:05:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7THv-0001fO-VQ; Fri, 10 Feb 2006 03:05:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7THj-0001em-NN for nemo@megatron.ietf.org; Fri, 10 Feb 2006 03:05:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27293 for ; Fri, 10 Feb 2006 03:03:52 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7TUX-00076u-8K for nemo@ietf.org; Fri, 10 Feb 2006 03:18:59 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 09:05:21 +0100 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 k1A85E5i004177; Fri, 10 Feb 2006 09:05:17 +0100 (MET) 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); Fri, 10 Feb 2006 09:05:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Fri, 10 Feb 2006 09:05:04 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDC9D4@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYteuaxCKQXTfihQ0aDS63vOdkttwAnLpIQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Feb 2006 08:05:14.0174 (UTC) FILETIME=[B8D5A5E0:01C62E18] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Alex >> In fact, the text did not appear particularly useful, and would have >> lead to discussion going above and beyond the scope of the draft; so >> the text was simply removed. > >If that ICMP Redirect text (between HA and MR) did not appear to be >particularly useful then I wonder how proxy ND by HA for _all_ addresses >in the moving network is of any use at all. By RFC3963 the HA does >proxy ND only for MR's Home Address. [Pascal] We removed it because some nodes (including routers) will not react to the redirect, see=20 http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-issue9.txt so we can not see that as an absolute solution, making it hard to recommend. Routing Information will not affect the Hosts/MNs on the Home Links, so it is also a problem. We end up with a pure L2 solution, and since the MR is reachable over a tunnel, it boils down to proxying techniques. > >draft-ietf-nemo-home-network-models-xx.txt: >> Thus, on the Home Link, the Home Agent must intercept all the packets >> to ALL the Mobile Network Nodes on the registered prefixes. In >> order to do so, the Home Agent might perform some form of ND proxying >> for all addresses in all registered Mobile Network Prefixes. > >This above paragraph makes no particular sense at all, since a HA doing >proxy ND for a LFN node which is below MR will intercept packets from >all the neighbours of HA addressed to LFN, even though it is the MR who >should intercept or receive those packets. > >There can be no "proxy ND" for an LFN on HA's link as long as the normal >ND of same LFN is not happening on the home link. [Pascal] Please read again. The "Nodes on the registered prefixes" means nodes (eg. LFNs) attached to MRs that are away from home. Thus MRs can not intercept the packets to the LFN over the Home Link. If MR was at home, then section 6.2.1 or 6.2.2 would apply. 6.2.1 describes your point, and yes, in that case the MR does the interception, not the HA. Pascal From nemo-bounces@ietf.org Fri Feb 10 06:02:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7W2M-00086u-68; Fri, 10 Feb 2006 06:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7W2H-00084I-N5 for nemo@megatron.ietf.org; Fri, 10 Feb 2006 06:02:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08579 for ; Fri, 10 Feb 2006 06:00:03 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7WF4-0004AJ-6R for nemo@ietf.org; Fri, 10 Feb 2006 06:15:13 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k1ABCxnp020925; Fri, 10 Feb 2006 04:12:59 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k1ABB3bD016998; Fri, 10 Feb 2006 05:11:04 -0600 (CST) Message-ID: <43EC727D.6050505@motorola.com> Date: Fri, 10 Feb 2006 12:01:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01CDC9D4@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01CDC9D4@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert \(pthubert\) wrote: > Hi Alex > >>> In fact, the text did not appear particularly useful, and would >>> have lead to discussion going above and beyond the scope of the >>> draft; so the text was simply removed. >> >> If that ICMP Redirect text (between HA and MR) did not appear to be >> particularly useful then I wonder how proxy ND by HA for _all_ >> addresses in the moving network is of any use at all. By RFC3963 >> the HA does proxy ND only for MR's Home Address. > > [Pascal] We removed it because some nodes (including routers) will > not react to the redirect, see > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod > els-issue9.txt so we can not see that as an absolute solution, > making it hard to recommend. Routing Information will not affect the > Hosts/MNs on the Home Links, so it is also a problem. We end up with > a pure L2 solution, and since the MR is reachable over a tunnel, it > boils down to proxying techniques. Thanks for documenting that issue. Pascal: > ICMP redirect is a router to host thing. Right, and the Mobile Router acts as a Mobile Host too. Ryuji: > some nodes ignore ICMP redirect. Right and other nodes will never do proxy ND for addresses that are topologically incorrect on that link. >> draft-ietf-nemo-home-network-models-xx.txt: >>> Thus, on the Home Link, the Home Agent must intercept all the >>> packets to ALL the Mobile Network Nodes on the registered >>> prefixes. In order to do so, the Home Agent might perform some >>> form of ND proxying for all addresses in all registered Mobile >>> Network Prefixes. >> >> This above paragraph makes no particular sense at all, since a HA >> doing proxy ND for a LFN node which is below MR will intercept >> packets from all the neighbours of HA addressed to LFN, even though >> it is the MR who should intercept or receive those packets. >> >> There can be no "proxy ND" for an LFN on HA's link as long as the >> normal ND of same LFN is not happening on the home link. > > [Pascal] Please read again. The "Nodes on the registered prefixes" > means nodes (eg. LFNs) attached to MRs that are away from home. Thus > MRs can not intercept the packets to the LFN over the Home Link. For some reason "intercept" was perceived by you as something where MR must do proxy ND in order to receive. I didn't mean so, sorry. I meant MR should "receive" (or "intercept") packets for LFNs when away from home. This happens by MR receiving packets tunnelled by HA. The HA has "intercepted" those packets for LFNs by doing proxy ND for MR's Home Address exclusively, and not by doing proxy ND for any LFN address. It makes no sense for HA to do proxy ND for LFN address. Again, HA doing proxy ND for LFNs is something topologically invalid. Proxy ND of a host should be done on a link where the real ND for that host is topologically valid. Moreover, there are potentially 2^64 LFNs behind an MR with MNP /64. HA has no means to know which of those are active. So will it send 2^64 periodic NAs as part of its proxy ND for LFNs? > If MR was at home, then section 6.2.1 or 6.2.2 would apply. 6.2.1 > describes your point, and yes, in that case the MR does the > interception, not the HA. We agree on this. Pascal: > Thus, on the Home Link, the Home Agent must intercept all the packets > for ALL the Mobile Network Nodes on the registered prefixes - that > is for ALL nodes attached to Mobile Routers that are away from Home. > This should be a layer 2 operation, rather than layer 3. The Home > agent might, for example, perform some form of ND proxying for all > addresses in all registered Mobile Network Prefixes. The Home Agent > must also protect the MNP space from autoconfiguration by > uncontrolled visitors at Neighbor Discovery level. Is there a known implementation where the HA intercepts all the packets for ALL the Mobile Network Nodes by doing proxy ND for their addresses? Does anyone plan to write such an implementation? Alex From nemo-bounces@ietf.org Fri Feb 10 11:57:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7baC-0001fl-6Q; Fri, 10 Feb 2006 11:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7baA-0001dB-3x for nemo@megatron.ietf.org; Fri, 10 Feb 2006 11:57:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07542 for ; Fri, 10 Feb 2006 11:55:34 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7bnB-00004s-Ev for nemo@ietf.org; Fri, 10 Feb 2006 12:10:46 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 17:57:07 +0100 Received: from xbh-ams-331.emea.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 k1AGuw5m012480; Fri, 10 Feb 2006 17:57:03 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 10 Feb 2006 17:57:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Fri, 10 Feb 2006 17:56:50 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDCC3B@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYuMXEbEjtuoI/PQIKOyrEQX4fGPAAL/CcA From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Feb 2006 16:57:01.0416 (UTC) FILETIME=[03086680:01C62E63] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >>> This above paragraph makes no particular sense at all, since a HA >>> doing proxy ND for a LFN node which is below MR will intercept >>> packets from all the neighbours of HA addressed to LFN, even though >>> it is the MR who should intercept or receive those packets. >>> >>> There can be no "proxy ND" for an LFN on HA's link as long as the >>> normal ND of same LFN is not happening on the home link. >> >> [Pascal] Please read again. The "Nodes on the registered prefixes" >> means nodes (eg. LFNs) attached to MRs that are away from home. Thus >> MRs can not intercept the packets to the LFN over the Home Link. > >For some reason "intercept" was perceived by you as something where MR >must do proxy ND in order to receive. I didn't mean so, sorry. I meant >MR should "receive" (or "intercept") packets for LFNs when away from >home. This happens by MR receiving packets tunnelled by HA. The HA has >"intercepted" those packets for LFNs by doing proxy ND for MR's Home >Address exclusively, and not by doing proxy ND for any LFN address. It >makes no sense for HA to do proxy ND for LFN address. > >Again, HA doing proxy ND for LFNs is something topologically invalid. >Proxy ND of a host should be done on a link where the real ND for that >host is topologically valid. [Pascal] Are we off-sync? This chapter talks about the aggregated mode, so the whole /48 is topologically correct on the Home Link. That's section 6 of: http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod els-xx.txt The /48 is what the HA advertises in RA's on the Home Link. All nodes on the link think that the whole /48 is on that link. So they will have a connected route to the /48 over the home link, and lookup any node in the /48 at ND level. But in fact, (some of) the /48 space is partionned into MNPs affected to MRs. Thus the problem. Note: Personally, I do not favor the aggregated model, I prefer the extended. We discussed that long ago, remember? > >Moreover, there are potentially 2^64 LFNs behind an MR with MNP /64. HA >has no means to know which of those are active. So will it send 2^64 >periodic NAs as part of its proxy ND for LFNs? [Pascal] No, it will answer to NS coming from the Home Link for any address that matches a registered MNP, and then pass the packets over the tunnel. > >Pascal: >> Thus, on the Home Link, the Home Agent must intercept all the packets >> for ALL the Mobile Network Nodes on the registered prefixes - that >> is for ALL nodes attached to Mobile Routers that are away from Home. >> This should be a layer 2 operation, rather than layer 3. The Home >> agent might, for example, perform some form of ND proxying for all >> addresses in all registered Mobile Network Prefixes. The Home Agent >> must also protect the MNP space from autoconfiguration by >> uncontrolled visitors at Neighbor Discovery level. > >Is there a known implementation where the HA intercepts all the packets >for ALL the Mobile Network Nodes by doing proxy ND for their addresses? > >Does anyone plan to write such an implementation? > [Pascal] Dunno. Don't ask me if I like it... But something like that has to be done if MNs or hosts connect to the home link... Part of the price to pay to support aggregated mode. Pascal From nemo-bounces@ietf.org Fri Feb 10 12:36:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7cCH-0003pM-R7; Fri, 10 Feb 2006 12:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7cCE-0003p3-3J for nemo@megatron.ietf.org; Fri, 10 Feb 2006 12:36:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11171 for ; Fri, 10 Feb 2006 12:34:44 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7cP4-0001VF-Ph for nemo@ietf.org; Fri, 10 Feb 2006 12:49:57 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1AHotw0003475; Fri, 10 Feb 2006 10:50:55 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k1AHoViX029893; Fri, 10 Feb 2006 11:50:31 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A0246865980; Fri, 10 Feb 2006 18:36:06 +0100 (CET) Message-ID: <43ECCF05.70404@motorola.com> Date: Fri, 10 Feb 2006 18:36:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01CDCC3B@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01CDCC3B@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert \(pthubert\) wrote: >>>> This above paragraph makes no particular sense at all, since a >>>> HA doing proxy ND for a LFN node which is below MR will >>>> intercept packets from all the neighbours of HA addressed to >>>> LFN, even though it is the MR who should intercept or receive >>>> those packets. >>>> >>>> There can be no "proxy ND" for an LFN on HA's link as long as >>>> the normal ND of same LFN is not happening on the home link. >>> >>> [Pascal] Please read again. The "Nodes on the registered >>> prefixes" means nodes (eg. LFNs) attached to MRs that are away >>> from home. Thus MRs can not intercept the packets to the LFN over >>> the Home Link. >> >> For some reason "intercept" was perceived by you as something where >> MR must do proxy ND in order to receive. I didn't mean so, sorry. >> I > meant >> MR should "receive" (or "intercept") packets for LFNs when away >> from home. This happens by MR receiving packets tunnelled by HA. >> The HA > has >> "intercepted" those packets for LFNs by doing proxy ND for MR's >> Home Address exclusively, and not by doing proxy ND for any LFN >> address. It makes no sense for HA to do proxy ND for LFN address. >> >> Again, HA doing proxy ND for LFNs is something topologically >> invalid. Proxy ND of a host should be done on a link where the real >> ND for that host is topologically valid. > > [Pascal] Are we off-sync? This chapter talks about the aggregated > mode, so the whole /48 is topologically correct on the Home Link. > That's section 6 of: > http://www.mobilenetworks.org/~pthubert/draft-ietf-nemo-home-network-mod > els-xx.txt Thanks for pointing me to the section 6 about the aggregated mode. The entire section of aggregated mode makes no sense in implementation and it is not recommended for implementation. One thing that is not mentioned in the draft is that it's impossible for MR to become a "bridge" and at the same time forbid the LFNs to receive RAs from the AR, thus LFNs to configure themselves CoAs. The entire configuration where MR is a bridge is entirely out of scope for implementations of RFC3963 MR. > The /48 is what the HA advertises in RA's on the Home Link. All nodes > on the link think that the whole /48 is on that link. So they will > have a connected route to the /48 over the home link, and lookup any > node in the /48 at ND level. Ok. > But in fact, (some of) the /48 space is partionned into MNPs affected > to MRs. Thus the problem. Note: Personally, I do not favor the > aggregated model, I prefer the extended. We discussed that long ago, > remember? Yes I remember. Who favors the Aggregated Model? Who recommends the Aggregated Model? We would expect it to be the draft authors. You don't seem so. Does Ryuji? Does Vijay? >> >> Moreover, there are potentially 2^64 LFNs behind an MR with MNP >> /64. > HA >> has no means to know which of those are active. So will it send >> 2^64 periodic NAs as part of its proxy ND for LFNs? > > [Pascal] No, it will answer to NS coming from the Home Link for any > address that matches a registered MNP, and then pass the packets over > the tunnel. NS is addressed to a multicast group. In order for HA to receive that NS it should MLD JOIN it first, otherwise it doesn't receive it. HA would need to send as many MLD JOINs as there are potential LFNs behind MR. That's large, right? >> Pascal: >>> Thus, on the Home Link, the Home Agent must intercept all the >>> packets for ALL the Mobile Network Nodes on the registered >>> prefixes - that is for ALL nodes attached to Mobile Routers that >>> are away from Home. This should be a layer 2 operation, rather >>> than layer 3. The Home agent might, for example, perform some >>> form of ND proxying for all addresses in all registered Mobile >>> Network Prefixes. The Home Agent must also protect the MNP space >>> from autoconfiguration by uncontrolled visitors at Neighbor >>> Discovery level. >> >> Is there a known implementation where the HA intercepts all the >> packets for ALL the Mobile Network Nodes by doing proxy ND for >> their addresses? >> >> Does anyone plan to write such an implementation? >> > [Pascal] Dunno. Don't ask me if I like it... But something like that > has to be done if MNs or hosts connect to the home link... Part of > the price to pay to support aggregated mode. I am not sure the aggregated mode is needed in order to allow the MNNs to connect to MR's home link. It is sufficient to have an HA on the _MNN_ home link and when MNN connects to MR's home link it would send BU to its own HA. Alex From nemo-bounces@ietf.org Fri Feb 10 13:01:36 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7caM-0000Jw-2A; Fri, 10 Feb 2006 13:01:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7cZi-00008R-T5 for nemo@megatron.ietf.org; Fri, 10 Feb 2006 13:01:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13686 for ; Fri, 10 Feb 2006 12:59:02 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7cmc-0002LH-Rn for nemo@ietf.org; Fri, 10 Feb 2006 13:14:16 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Feb 2006 19:00:36 +0100 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 k1AI0V5i024517; Fri, 10 Feb 2006 19:00:32 +0100 (MET) 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); Fri, 10 Feb 2006 19:00:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Fri, 10 Feb 2006 19:00:24 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDCC8A@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYuaIMhvSb8tdD8SyeNT5QTvIwM3wAAWYGQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Feb 2006 18:00:31.0480 (UTC) FILETIME=[E2020780:01C62E6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >>> >>> Moreover, there are potentially 2^64 LFNs behind an MR with MNP >>> /64. >> HA >>> has no means to know which of those are active. So will it send >>> 2^64 periodic NAs as part of its proxy ND for LFNs? >> >> [Pascal] No, it will answer to NS coming from the Home Link for any >> address that matches a registered MNP, and then pass the packets over >> the tunnel. > >NS is addressed to a multicast group. In order for HA to receive that >NS it should MLD JOIN it first, otherwise it doesn't receive it. HA >would need to send as many MLD JOINs as there are potential LFNs behind >MR. That's large, right? > [Pascal] This goes beyond our draft. =20 The short answer is that a proxy interface operates in promiscuous mode. Dave Thaler has documented all this in chapter 4.1.3. "IPv6 ND Proxying" of=20 http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt that we reference as [12]. >>> Does anyone plan to write such an implementation? >>> >> [Pascal] Dunno. Don't ask me if I like it... But something like that >> has to be done if MNs or hosts connect to the home link... Part of >> the price to pay to support aggregated mode. > >I am not sure the aggregated mode is needed in order to allow the MNNs >to connect to MR's home link. It is sufficient to have an HA on the >_MNN_ home link and when MNN connects to MR's home link it would send BU >to its own HA. [Pascal] I'm not sure what you want to say there.=20 Do you mean a MNN that is also a MN? Pascal From nemo-bounces@ietf.org Fri Feb 10 18:50:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7i2D-0001gF-D5; Fri, 10 Feb 2006 18:50:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7i1e-0001EQ-0y; Fri, 10 Feb 2006 18:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14936; Fri, 10 Feb 2006 18:48:20 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7iEh-00078c-BN; Fri, 10 Feb 2006 19:03:36 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F7i1a-0002on-7l; Fri, 10 Feb 2006 18:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 10 Feb 2006 18:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-ro-space-analysis-02.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Solution Space Analysis Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-space-analysis-02.txt Pages : 43 Date : 2006-2-10 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-space-analysis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-10171721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-ro-space-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-10171721.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Sun Feb 12 12:44:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8LGh-00088m-67; Sun, 12 Feb 2006 12:44:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8LGe-00088V-JI for nemo@megatron.ietf.org; Sun, 12 Feb 2006 12:44:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02561 for ; Sun, 12 Feb 2006 12:42:27 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8LU2-0000kW-LG for nemo@ietf.org; Sun, 12 Feb 2006 12:58:07 -0500 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k1CIC6pU026423; Sun, 12 Feb 2006 11:12:07 -0700 (MST) Received: from [10.169.5.34] (mvp-10-169-5-34.corp.mot.com [10.169.5.34]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k1CI2CXG013100; Sun, 12 Feb 2006 12:02:13 -0600 (CST) Message-ID: <43EF73D3.3010300@motorola.com> Date: Sun, 12 Feb 2006 18:43:47 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01CDCC8A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01CDCC8A@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert \(pthubert\) wrote: >>>> >>>> Moreover, there are potentially 2^64 LFNs behind an MR with MNP >>>> /64. >>> HA >>>> has no means to know which of those are active. So will it >>>> send 2^64 periodic NAs as part of its proxy ND for LFNs? >>> >>> [Pascal] No, it will answer to NS coming from the Home Link for >>> any address that matches a registered MNP, and then pass the >>> packets over the tunnel. >> >> NS is addressed to a multicast group. In order for HA to receive >> that NS it should MLD JOIN it first, otherwise it doesn't receive >> it. HA would need to send as many MLD JOINs as there are potential >> LFNs behind MR. That's large, right? >> > > [Pascal] This goes beyond our draft. > > The short answer is that a proxy interface operates in promiscuous > mode. > > Dave Thaler has documented all this in chapter 4.1.3. "IPv6 ND > Proxying" of > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt > that we reference as [12]. Note that that draft proposes proxy ND with promiscuous mode for a subnet that is static, always attached to the same AP. It solves a problem someone may have in house with a network that stays there. In the mobility case, if the MR acts as a bridge and the MR and HA do Thaler promiscuous proxy ND (instead of rfc2461 proxy ND) I doubt the LFNs will not see the RAs sent either by the home AP or by all visited ARs. I.e. LFNs will receive RAs straight from the visited network. Which will make them auto-configure "CoA"s, loose their communications. This is completely against the NEMO requirement whereby LFNs are protected from CoA changes, not run MIP and still keep ongoing sessions. Mobile Thaler Proxy ND is something one can think about... >>>> Does anyone plan to write such an implementation? >>>> >>> [Pascal] Dunno. Don't ask me if I like it... But something like >>> that has to be done if MNs or hosts connect to the home link... >>> Part of the price to pay to support aggregated mode. >> >> I am not sure the aggregated mode is needed in order to allow the >> MNNs to connect to MR's home link. It is sufficient to have an HA >> on the _MNN_ home link and when MNN connects to MR's home link it >> would send > BU >> to its own HA. > [Pascal] I'm not sure what you want to say there. Do you mean a MNN > that is also a MN? Yes. I'm not sure what you mean by MNN? There's only "MH", "MR" and "MN" that are currently specified, they run Mobile IPv6. "MNN" is short for "an MNN can be anything". I was saying I don't see the need for aggregated mode. If the need is to allow nodes on the moving network to connect to the MR's home link then it is sufficient to put a HA on the link in the moving network where these nodes reside. So when such a "MNN" moves from its home link on the moving network to the MR's home link, it does BU with its HA (placed in the moving network). I think it would be fair to mention which home network models are doable with RFC3963 and which not. There are applicability sections. For section 6 "aggregated", it would be very easy to just say "rfc3963 is not implementable with the aggregated home model". Alex From nemo-bounces@ietf.org Mon Feb 13 07:55:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8dEz-0005yp-3K; Mon, 13 Feb 2006 07:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8dEx-0005wZ-7Q for nemo@megatron.ietf.org; Mon, 13 Feb 2006 07:55:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16607 for ; Mon, 13 Feb 2006 07:53:53 -0500 (EST) Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8dST-0007Nw-Py for nemo@ietf.org; Mon, 13 Feb 2006 08:09:43 -0500 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.10/3.7W/bulls) with ESMTP id k1DCtLcO008835 for ; Mon, 13 Feb 2006 21:55:21 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx1) with ESMTP id k1DCtL527139 for ; Mon, 13 Feb 2006 21:55:21 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/phillies) with ESMTP id k1DCtMC24439 for ; Mon, 13 Feb 2006 21:55:22 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Feb 2006 20:54:32 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id B18E6D5511; Mon, 13 Feb 2006 21:01:28 +0800 (SGT) From: Chan-Wah Ng To: IETF NEMO WG Content-Type: multipart/mixed; boundary="=-P8bgxwq4mu1prlF9aDC+" Date: Mon, 13 Feb 2006 21:01:28 +0800 Message-Id: <1139835688.9535.58.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 X-OriginalArrivalTime: 13 Feb 2006 12:54:32.0845 (UTC) FILETIME=[A2A5E3D0:01C6309C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [nemo] [Fwd: I-D ACTION:draft-ietf-nemo-ro-space-analysis-02.txt] X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --=-P8bgxwq4mu1prlF9aDC+ Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, all, A quick update on RO space analysis.: This is basically a maintenance update addressing issues in the issue list. - Change-log: o draft-ietf-nemo-ro-space-analysis-02: * Changed title of Sect 3.1 from "Basic NEMO Route Optimization" to "Non-Nested NEMO Route Optimization" * Added "Terminology" Sub-section [Issue #17] * Modifications to Sect 3.1 and 5.1.1 [Issues #18, #20] * Break "Mobility Transparency and Location Privacy" into Sect 4.7 and 4.8 [Issue #19] * Updated References [Issue #21] The issue list can be found at: http://www.mobilenetworks.org/~chanwah/rosa/issues.html Could the originator(s) of the issues please acknowledge if the changes have sufficiently/satisfactorily addressed your concerns, so that I could close them. Thanks. /rgds /cwng -------- Forwarded Message -------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Network Mobility Route Optimization Solution Space Analysis Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-ro-space-analysis-02.txt Pages : 43 Date : 2006-2-10 With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the MRHA tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO, and explores the benefits and tradeoffs in different aspects of NEMO Route Optimization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-ro-space-analysis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --=-P8bgxwq4mu1prlF9aDC+ Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA2LTItMTAxNzE3MjEuSS1E QGlldGYub3JnPgoKRU5DT0RJTkcgbWltZQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1uZW1vLXJvLXNwYWNlLWFuYWx5c2lzLTAyLnR4dAo= --=-P8bgxwq4mu1prlF9aDC+ Content-Type: Message/External-body; name="draft-ietf-nemo-ro-space-analysis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6IDwyMDA2LTItMTAxNzE3MjEuSS1E QGlldGYub3JnPgoK --=-P8bgxwq4mu1prlF9aDC+-- From nemo-bounces@ietf.org Mon Feb 13 10:56:52 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8g4K-0007j5-A4; Mon, 13 Feb 2006 10:56:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8g4I-0007iw-Pq for nemo@megatron.ietf.org; Mon, 13 Feb 2006 10:56:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02803 for ; Mon, 13 Feb 2006 10:55:05 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8gHu-00057n-L3 for nemo@ietf.org; Mon, 13 Feb 2006 11:10:57 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2006 16:56:39 +0100 Received: from xbh-ams-331.emea.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 k1DFtn6A011391; Mon, 13 Feb 2006 16:56:35 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Feb 2006 16:56:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Mon, 13 Feb 2006 16:56:09 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDD19D@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYv+/HAKE1aH4taSSyuhNC9/w6PRgAuVNsQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 13 Feb 2006 15:56:16.0926 (UTC) FILETIME=[05FC9BE0:01C630B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >>>>> Does anyone plan to write such an implementation? >>>>> >>>> [Pascal] Dunno. Don't ask me if I like it... But something like >>>> that has to be done if MNs or hosts connect to the home link... >>>> Part of the price to pay to support aggregated mode. >>> >>> I am not sure the aggregated mode is needed in order to allow the >>> MNNs to connect to MR's home link. It is sufficient to have an HA >>> on the _MNN_ home link and when MNN connects to MR's home link it >>> would send >> BU >>> to its own HA. >> [Pascal] I'm not sure what you want to say there. Do you mean a MNN >> that is also a MN? > >Yes. I'm not sure what you mean by MNN? There's only "MH", "MR" and >"MN" that are currently specified, they run Mobile IPv6. "MNN" is short >for "an MNN can be anything". > >I was saying I don't see the need for aggregated mode. If the need is >to allow nodes on the moving network to connect to the MR's home link >then it is sufficient to put a HA on the link in the moving network >where these nodes reside. So when such a "MNN" moves from its home link >on the moving network to the MR's home link, it does BU with its HA >(placed in the moving network). [Pascal] Aggregated mode is when you want to configure the whole Home Network on the Home Link, though it is an aggregation. Some people in the group found that model more natural as an evolution from MIP6. > >I think it would be fair to mention which home network models are doable >with RFC3963 and which not. There are applicability sections. For >section 6 "aggregated", it would be very easy to just say "rfc3963 is >not implementable with the aggregated home model". > [Pascal] I would disagree with the wording. I believe you mean that it takes more than RFC 3963 compliant MR and HA to implement aggregated. I would agree with that, and there's text about that. We're past removing this section now...=20 Pascal From nemo-bounces@ietf.org Tue Feb 14 05:31:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8xTE-0004QC-33; Tue, 14 Feb 2006 05:31:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8xTD-0004Q7-55 for nemo@megatron.ietf.org; Tue, 14 Feb 2006 05:31:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14505 for ; Tue, 14 Feb 2006 05:29:57 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8xgr-0004bf-JW for nemo@ietf.org; Tue, 14 Feb 2006 05:45:59 -0500 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4D28D4F004D; Tue, 14 Feb 2006 11:31:32 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 11:31:32 +0100 Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 11:31:31 +0100 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] RE: draft-ietf-nemo-home-network-models-05 Date: Tue, 14 Feb 2006 11:31:30 +0100 Message-ID: <2D8B78375B46EF4C85EE21B9EB64350A01DA1556@esealmw103.eemea.ericsson.se> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYv+/HAKE1aH4taSSyuhNC9/w6PRgAuVNsQACcTWeA= From: "Mattias Pettersson L \(LD/EAB\)" To: "Pascal Thubert \(pthubert\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 14 Feb 2006 10:31:31.0711 (UTC) FILETIME=[D24E80F0:01C63151] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org =20 > [Pascal] Aggregated mode is when you want to configure the=20 > whole Home Network on the Home Link, though it is an=20 > aggregation. Some people in the group found that model more=20 > natural as an evolution from MIP6. Pascal, does this mean that you configure something else than /64 prefixes on the home link? Is Neighbor Discovery/Address conf compatible with that? /Mattias From nemo-bounces@ietf.org Tue Feb 14 09:06:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90p3-0008Gf-S4; Tue, 14 Feb 2006 09:06:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F90p1-0008Fn-Mh for nemo@megatron.ietf.org; Tue, 14 Feb 2006 09:06:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28140 for ; Tue, 14 Feb 2006 09:04:40 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F912q-0002hO-4Q for nemo@ietf.org; Tue, 14 Feb 2006 09:20:45 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2006 15:06:16 +0100 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 k1EE5S6I021840; Tue, 14 Feb 2006 15:06:12 +0100 (MET) 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, 14 Feb 2006 15:06:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Tue, 14 Feb 2006 15:05:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01CDD586@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYv+/HAKE1aH4taSSyuhNC9/w6PRgAuVNsQACcTWeAABgrM8A== From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson L \(LD/EAB\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 14 Feb 2006 14:06:03.0369 (UTC) FILETIME=[CA69A590:01C6316F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Mattias; Yes, the idea is that the prefix is generally shorter than /64.=20 We had long discussions in this ML about autoconfigs with shorter prefixes (Alex?). But yes, NEMO should work in theory with a shorter prefix assigned to the Home Link. Note that NEMO does not require autoconf operations; and last that I know, a Cisco router will not auto-configure an address on a prefix that is shorter than 64.=20 So there might be some implementation specific issues to do at least autoconf. DAD should work, though, which is what we need. Would I, personally, recommend the aggregated mode? I don't think so. But if a good half of the population starts with that mode in mind, it's good to document the pro/cons, and hopefully, at the end the day, they will make the right deployment decision for their needs... Pascal >-----Original Message----- >From: Mattias Pettersson L (LD/EAB) [mailto:mattias.l.pettersson@ericsson.com] >Sent: Tuesday, February 14, 2006 11:32 AM >To: Pascal Thubert (pthubert); Alexandru Petrescu >Cc: nemo@ietf.org; tj@kniveton.com; Margaret Wasserman; vijay.devarapalli@nokia.com; >ryuji@sfc.wide.ad.jp; ernst@sfc.wide.ad.jp >Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 > > >> [Pascal] Aggregated mode is when you want to configure the >> whole Home Network on the Home Link, though it is an >> aggregation. Some people in the group found that model more >> natural as an evolution from MIP6. > >Pascal, does this mean that you configure something else than /64 >prefixes on the home link? Is Neighbor Discovery/Address conf compatible >with that? > >/Mattias From nemo-bounces@ietf.org Tue Feb 14 10:38:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92Fe-0003Gy-DV; Tue, 14 Feb 2006 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92Fa-0003GZ-0d for nemo@megatron.ietf.org; Tue, 14 Feb 2006 10:38:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05516 for ; Tue, 14 Feb 2006 10:36:12 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92TL-00061g-Vj for nemo@ietf.org; Tue, 14 Feb 2006 10:52:16 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k1EFuatc003794; Tue, 14 Feb 2006 08:56:40 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k1EFmfBW007887; Tue, 14 Feb 2006 09:48:42 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 317F5865980; Tue, 14 Feb 2006 16:37:33 +0100 (CET) Message-ID: <43F1F93A.4040108@motorola.com> Date: Tue, 14 Feb 2006 16:37:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01CDD586@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01CDD586@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, tj@kniveton.com, "Mattias Pettersson L \\\(LD/EAB\\\)" , Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pascal Thubert \(pthubert\) wrote: > Hi Mattias; > > Yes, the idea is that the prefix is generally shorter than /64. > > We had long discussions in this ML about autoconfigs with shorter > prefixes (Alex?). Yes, I agree that a host should auto-configure an address from an RA with a prefix shorter than /64 - fill the intermediary bits with '0'. However, capacity of auto-configuring an address from prefix shorter than /64 is not a support for the aggregated mode itself. I also support /56 on the home link and /64 on the moving network links. That's as natural as it gets. But this does not mean I support mixing the home link with the moving network links into an L2-VLAN-proxy-ND that may work in some single places but is by no means the standard at deployed Access Routers. The main reason why the aggregated mode is not supported by RFC3963 is that it breaks the scope of ND (LFN receiving RA from AR? and from HA?) and turns MR into an MR and a bridge at the same time. There's no software that allows a machine to dynamically change from bridge to router without loosing ongoing communications. > But yes, NEMO should work in theory with a shorter prefix assigned to > the Home Link. Yes, NEMOv6 as specified by RFC3963. But RFC3963 does not support the aggregated mode. > Note that NEMO does not require autoconf operations; and last that I > know, a Cisco router will not auto-configure an address on a prefix > that is shorter than 64. You seem to imply that a router _will_ auto-configure an address from an RA with prefix /64. YEs? A "router" fixed or mobile shouldn't statelessly auto-configure an IPv6 address at all, be it prefix /64 or shorter, no? > So there might be some implementation specific issues to do at least > autoconf. DAD should work, though, which is what we need. Would I, > personally, recommend the aggregated mode? I don't think so. But if a > good half of the population starts with that mode in mind, it's good > to document the pro/cons, and hopefully, at the end the day, they > will make the right deployment decision for their needs... Who recommends the aggregated mode? I don't. Alex From nemo-bounces@ietf.org Tue Feb 14 10:42:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92KN-0004A9-KQ; Tue, 14 Feb 2006 10:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92KM-00049a-8R for nemo@megatron.ietf.org; Tue, 14 Feb 2006 10:42:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05941 for ; Tue, 14 Feb 2006 10:41:08 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92YB-0006D8-JJ for nemo@ietf.org; Tue, 14 Feb 2006 10:57:12 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2006 16:42:43 +0100 Received: from xbh-ams-331.emea.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 k1EFgL5w022014; Tue, 14 Feb 2006 16:42:38 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Feb 2006 16:42:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Tue, 14 Feb 2006 16:42:31 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYxfJ248xfD90KvTlGbPNRYf/9U2gAAFyPQ From: "Pascal Thubert \(pthubert\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 14 Feb 2006 15:42:36.0906 (UTC) FILETIME=[47A13CA0:01C6317D] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, "Mattias Pettersson L \\\(LD/EAB\\\)" , Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org > >> Note that NEMO does not require autoconf operations; and last that I >> know, a Cisco router will not auto-configure an address on a prefix >> that is shorter than 64. > >You seem to imply that a router _will_ auto-configure an address from an >RA with prefix /64. YEs? A "router" fixed or mobile shouldn't >statelessly auto-configure an IPv6 address at all, be it prefix /64 or >shorter, no? > [Pascal] Alex, the Mobile Router needs to auto-configure an address on its egress interface as it roams...=20 Pascal From nemo-bounces@ietf.org Tue Feb 14 11:09:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92k6-0005JO-9a; Tue, 14 Feb 2006 11:09:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92k5-0005Ip-CS for nemo@megatron.ietf.org; Tue, 14 Feb 2006 11:09:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07355 for ; Tue, 14 Feb 2006 11:07:43 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F92xv-0006vi-Mv for nemo@ietf.org; Tue, 14 Feb 2006 11:23:48 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5A4004F0002; Tue, 14 Feb 2006 17:09:27 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 17:09:27 +0100 Received: from esealmw103.eemea.ericsson.se ([153.88.200.66]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 17:09:26 +0100 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] RE: draft-ietf-nemo-home-network-models-05 Date: Tue, 14 Feb 2006 17:09:25 +0100 Message-ID: <2D8B78375B46EF4C85EE21B9EB64350A01DA1559@esealmw103.eemea.ericsson.se> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYv+/HAKE1aH4taSSyuhNC9/w6PRgAuVNsQACcTWeAABgrM8AAFYPig From: "Mattias Pettersson L \(LD/EAB\)" To: "Pascal Thubert \(pthubert\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 14 Feb 2006 16:09:26.0800 (UTC) FILETIME=[07339100:01C63181] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pascal, > Yes, the idea is that the prefix is generally shorter than /64.=20 >=20 > We had long discussions in this ML about autoconfigs with=20 > shorter prefixes (Alex?). But yes, NEMO should work in theory=20 > with a shorter prefix assigned to the Home Link. Note that=20 > NEMO does not require autoconf operations; and last that I=20 > know, a Cisco router will not auto-configure an address on a=20 > prefix that is shorter than 64.=20 I'm not sure that ND will work for anything but /64. Maybe the intention was so, but as you say, not all implementations support different prefix lengths. Still you will need the address resolution parts of ND, even though the HA and MRs doesn't autoconfigure addresses on the home link. The big issue is the ambiguity of which link/subnet a specific address belongs to. For instance, given a packet destined to a specific MNN, does the HA know if it should route (via an MR) or send directly to the MNN (by using ND address resolution to get the MAC address)? ND proxy/MLSR according to Thaler extends a /64 subnet across multiple links. But the suggested behaviour here is different. /Mattias From nemo-bounces@ietf.org Tue Feb 14 11:32:16 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9368-0004lj-Ex; Tue, 14 Feb 2006 11:32:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9366-0004lE-VL for nemo@megatron.ietf.org; Tue, 14 Feb 2006 11:32:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08873 for ; Tue, 14 Feb 2006 11:30:28 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F93Jv-0007c3-4m for nemo@ietf.org; Tue, 14 Feb 2006 11:46:32 -0500 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k1EH0PCL017720; Tue, 14 Feb 2006 10:00:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k1EGhB84021839; Tue, 14 Feb 2006 10:43:12 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D5559865980; Tue, 14 Feb 2006 17:32:03 +0100 (CET) Message-ID: <43F20601.1040705@motorola.com> Date: Tue, 14 Feb 2006 17:32:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert \\(pthubert\\)" Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Mattias Pettersson L \\\\\(LD/EAB\\\\\)" 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: > >> >>> Note that NEMO does not require autoconf operations; and last >>> that I know, a Cisco router will not auto-configure an address on >>> a prefix that is shorter than 64. >> >> You seem to imply that a router _will_ auto-configure an address >> from an RA with prefix /64. YEs? A "router" fixed or mobile >> shouldn't statelessly auto-configure an IPv6 address at all, be it >> prefix /64 or shorter, no? >> > [Pascal] Alex, the Mobile Router needs to auto-configure an address > on its egress interface as it roams... Right... I meant so too... my remark was not necessary in this context. What stays clear to me about the aggregated mode is the following. The aggregated mode is something not supported by RFC3963 because RFC3963 works when the Home Address is derived from the prefix on the home link. draft-ietf-nemo-home-network-models-xx.txt: "it makes sense for a Mobile Router to register using a Home Address from one of its own MNPs." No, it makes no sense. Otherwise I agree with you. Alex From nemo-bounces@ietf.org Tue Feb 14 22:12:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9D5l-0001RS-1W; Tue, 14 Feb 2006 22:12:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9D5j-0001RE-D0 for nemo@megatron.ietf.org; Tue, 14 Feb 2006 22:12:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00038 for ; Tue, 14 Feb 2006 22:10:43 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9DJf-0006kR-BY for nemo@ietf.org; Tue, 14 Feb 2006 22:26:56 -0500 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 879BC4C7C2; Wed, 15 Feb 2006 12:12:17 +0900 (JST) Date: Wed, 15 Feb 2006 12:12:22 +0900 From: Thierry Ernst To: Alexandru Petrescu Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 Message-Id: <20060215121222.1dc6385f.ernst@sfc.wide.ad.jp> In-Reply-To: <43F20601.1040705@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> <43F20601.1040705@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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, pthubert@cisco.com, Ryuji Wakikawa , mattias.l.pettersson@ericsson.com 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 > What stays clear to me about the aggregated mode is the following. > > The aggregated mode is something not supported by RFC3963 because > RFC3963 works when the Home Address is derived from the prefix on the > home link. According to me, this is not so clear. RFC 3963 is a result of merging several ideas, including the idea from Ryuji that the MR's HoA can be taken from the MNP. This said, I don't have the technical deepth that you have to evaluate if RFC 3963 allow it ort not. So, I cced Ryuji regarding this point. > draft-ietf-nemo-home-network-models-xx.txt: > "it makes sense for a Mobile Router to register using a Home Address > from one of its own MNPs." > > No, it makes no sense. Well, to Alex it may not make sense. But it makes some sense for other authors of RFC 3963. > Otherwise I agree with you. Thierry. From nemo-bounces@ietf.org Wed Feb 15 03:53:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9IPv-0006W2-Ib; Wed, 15 Feb 2006 03:53:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9IPt-0006Vx-Cn for nemo@megatron.ietf.org; Wed, 15 Feb 2006 03:53:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21157 for ; Wed, 15 Feb 2006 03:51:53 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Idr-0000r6-NW for nemo@ietf.org; Wed, 15 Feb 2006 04:08:09 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 15 Feb 2006 09:53:30 +0100 Received: from xbh-ams-331.emea.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 k1F8rB5w013335; Wed, 15 Feb 2006 09:53:27 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 15 Feb 2006 09:53:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Wed, 15 Feb 2006 09:53:14 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01D29986@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo] RE: draft-ietf-nemo-home-network-models-05 Thread-Index: AcYv+/HAKE1aH4taSSyuhNC9/w6PRgAuVNsQACcTWeAABgrM8AAFYPigACMiEyA= From: "Pascal Thubert \(pthubert\)" To: "Mattias Pettersson L \(LD/EAB\)" , "Alexandru Petrescu" X-OriginalArrivalTime: 15 Feb 2006 08:53:19.0227 (UTC) FILETIME=[44868CB0:01C6320D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org, tj@kniveton.com, Margaret Wasserman , vijay.devarapalli@nokia.com, ryuji@sfc.wide.ad.jp, ernst@sfc.wide.ad.jp X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org >-----Original Message----- >From: Mattias Pettersson L (LD/EAB) [mailto:mattias.l.pettersson@ericsson.com] >Sent: Tuesday, February 14, 2006 5:09 PM >To: Pascal Thubert (pthubert); Alexandru Petrescu >Cc: nemo@ietf.org; tj@kniveton.com; Margaret Wasserman; vijay.devarapalli@nokia.com; >ryuji@sfc.wide.ad.jp; ernst@sfc.wide.ad.jp >Subject: RE: [nemo] RE: draft-ietf-nemo-home-network-models-05 > >Hi Pascal, > >> Yes, the idea is that the prefix is generally shorter than /64. >> >> We had long discussions in this ML about autoconfigs with >> shorter prefixes (Alex?). But yes, NEMO should work in theory >> with a shorter prefix assigned to the Home Link. Note that >> NEMO does not require autoconf operations; and last that I >> know, a Cisco router will not auto-configure an address on a >> prefix that is shorter than 64. > >I'm not sure that ND will work for anything but /64. Maybe the intention >was so, but as you say, not all implementations support different prefix >lengths. > >Still you will need the address resolution parts of ND, even though the >HA and MRs doesn't autoconfigure addresses on the home link. [Pascal] That should work. Do you know of an implementation that would not operate NS/NA correctly on a non /64 network?=20 I agree with you that HA and MRs doesn't autoconfigure addresses on the home link, it's good that you point it out. >The big issue is the ambiguity of which link/subnet a specific address >belongs to. For instance, given a packet destined to a specific MNN, >does the HA know if it should route (via an MR) or send directly to the >MNN (by using ND address resolution to get the MAC address)? > [Pascal] Well, the HA is a still a router.=20 For addresses that are part of an MNP, the HA should have an MNP route via the MR, and route accordingly via the MR, whether it is Home or not. The longest match in the routing table will be the connected route to the aggregated home network only for addresses that: - are not in an MNP =3D> then look up at ND level is what you want to do - are in an MNP of a MR that is away from home and not registered =3D> then ND lookup is still OK and it will fail, that's fine Again, I do not like it, but it works... >ND proxy/MLSR according to Thaler extends a /64 subnet across multiple >links. But the suggested behaviour here is different. > [Pascal] Nope. It's the same thing: HA is doing proxy for individual /64s that are identified as such because they are associated with a MR binding. Pascal From nemo-bounces@ietf.org Wed Feb 15 11:56:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Px4-0005lO-IS; Wed, 15 Feb 2006 11:56:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Px2-0005hT-HV for nemo@megatron.ietf.org; Wed, 15 Feb 2006 11:56:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11504 for ; Wed, 15 Feb 2006 11:54:38 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9QB1-0007My-4b for nemo@ietf.org; Wed, 15 Feb 2006 12:10:56 -0500 Received: from [IPv6:2001:200::8801:211:24ff:fe79:8e82] (unknown [IPv6:2001:200:0:8801:211:24ff:fe79:8e82]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id CAEE64DAB9; Thu, 16 Feb 2006 01:56:08 +0900 (JST) In-Reply-To: <20060215121222.1dc6385f.ernst@sfc.wide.ad.jp> References: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> <43F20601.1040705@motorola.com> <20060215121222.1dc6385f.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Thu, 16 Feb 2006 01:56:07 +0900 To: Thierry Ernst X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, pthubert@cisco.com, mattias.l.pettersson@ericsson.com, Alexandru Petrescu 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 Alex and Thierry Please check the RFC3964 section3 We said "A Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix aggregated and advertised by its Home Agent. The prefix could be either the prefix advertised on the home link or the prefix delegated to the Mobile Router. " Some advantages using HoA derived from MNP. The operators do not suffer from matching HoA from the home link and assigned MNP. We can save a prefix/64 for just assigning HoA to MRs. regards, ryuji On 2006/02/15, at 12:12, Thierry Ernst wrote: > >> What stays clear to me about the aggregated mode is the following. >> >> The aggregated mode is something not supported by RFC3963 because >> RFC3963 works when the Home Address is derived from the prefix on the >> home link. > > According to me, this is not so clear. RFC 3963 is a result of merging > several ideas, including the idea from Ryuji that the MR's HoA can be > taken from the MNP. This said, I don't have the technical deepth that > you have to evaluate if RFC 3963 allow it ort not. > > So, I cced Ryuji regarding this point. > >> draft-ietf-nemo-home-network-models-xx.txt: >> "it makes sense for a Mobile Router to register using a Home Address >> from one of its own MNPs." >> >> No, it makes no sense. > > Well, to Alex it may not make sense. But it makes some sense for other > authors of RFC 3963. > >> Otherwise I agree with you. > > Thierry. > From nemo-bounces@ietf.org Wed Feb 15 13:51:13 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Rk8-0007wm-Vb; Wed, 15 Feb 2006 13:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9Rk7-0007sW-1m for nemo@megatron.ietf.org; Wed, 15 Feb 2006 13:51:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22436 for ; Wed, 15 Feb 2006 13:49:23 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9Ry2-0003yO-7y for nemo@ietf.org; Wed, 15 Feb 2006 14:05:43 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id D007A8ABA70 for ; Wed, 15 Feb 2006 10:50:36 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50688-04 for ; Wed, 15 Feb 2006 10:50:36 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 858F48AB9C7; Wed, 15 Feb 2006 10:50:36 -0800 (PST) Received: from [192.103.16.119] (unknown [192.103.16.119]) by deimos.multihop.net (Postfix) with ESMTP id 420BA8AB90C for ; Wed, 15 Feb 2006 10:50:36 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: "T.J. Kniveton" Date: Wed, 15 Feb 2006 10:50:56 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [nemo] Working Group last call for Route Optimization 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 The authors feel that the two RO drafts (problem statement and space analysis) are almost complete, and are ready for WG Last Call. If you have any comments on these, please post them to the list or e-mail the authors. Thanks, TJ From nemo-bounces@ietf.org Thu Feb 16 11:38:19 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9m95-0001j2-PG; Thu, 16 Feb 2006 11:38:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9m94-0001ij-5k for nemo@megatron.ietf.org; Thu, 16 Feb 2006 11:38:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10390 for ; Thu, 16 Feb 2006 11:36:31 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F9mNG-0004Sp-35 for nemo@ietf.org; Thu, 16 Feb 2006 11:53:02 -0500 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k1GH6NLQ022961; Thu, 16 Feb 2006 10:06:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k1GGn8dw023420; Thu, 16 Feb 2006 10:49:09 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C2DB7865980; Thu, 16 Feb 2006 17:37:55 +0100 (CET) Message-ID: <43F4AA5F.9040602@motorola.com> Date: Thu, 16 Feb 2006 17:37:51 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> <43F20601.1040705@motorola.com> <20060215121222.1dc6385f.ernst@sfc.wide.ad.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, Thierry Ernst , mattias.l.pettersson@ericsson.com, pthubert@cisco.com 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: > Hi Alex and Thierry > > Please check the RFC3964 section3 We said "A Mobile Router has a > unique Home Address through which it is reachable when it is > registered with its Home Agent. The Home Address is configured from > a prefix aggregated and advertised by its Home Agent. The prefix > could be either the prefix advertised on the home link or the prefix > delegated to the Mobile Router. " Hi Ryuji, there can be no implementation that derives the HoA from MNP and simultaneously is defended by proxy ND by HA. Is there any? > Some advantages using HoA derived from MNP. The operators do not > suffer from matching HoA from the home link and assigned MNP. We can > save a prefix/64 for just assigning HoA to MRs. I'm not sure I understand how the matching hurts the operators. I don't think addresses or prefixes are saved, can you explain? Alex From nemo-bounces@ietf.org Sun Feb 19 14:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAuIv-0006ZY-Cq; Sun, 19 Feb 2006 14:33:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAuAL-0006LN-JX for nemo@ietf.org; Sun, 19 Feb 2006 14:24:17 -0500 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtxl-0002Cv-Vq for nemo@ietf.org; Sun, 19 Feb 2006 14:11:19 -0500 Received: from [192.168.0.8] (p2112-ipbf601marunouchi.tokyo.ocn.ne.jp [222.145.139.112]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id BDC814DE67; Mon, 20 Feb 2006 04:11:15 +0900 (JST) In-Reply-To: <43F4AA5F.9040602@motorola.com> References: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> <43F20601.1040705@motorola.com> <20060215121222.1dc6385f.ernst@sfc.wide.ad.jp> <43F4AA5F.9040602@motorola.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 Date: Mon, 20 Feb 2006 04:11:15 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: nemo@ietf.org, Thierry Ernst , mattias.l.pettersson@ericsson.com, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex On 2006/02/17, at 1:37, Alexandru Petrescu wrote: > Ryuji Wakikawa wrote: >> Hi Alex and Thierry >> Please check the RFC3964 section3 We said "A Mobile Router has a >> unique Home Address through which it is reachable when it is >> registered with its Home Agent. The Home Address is configured from >> a prefix aggregated and advertised by its Home Agent. The prefix >> could be either the prefix advertised on the home link or the prefix >> delegated to the Mobile Router. " > > Hi Ryuji, there can be no implementation that derives the HoA from MNP > and simultaneously is defended by proxy ND by HA. Is there any? I don't know how you can conclude like this.. SHISA can generate HoA from MNP. MR can return home in some configuration. When MR returns home, HA does not remove network route of MNP pointed to MR. Thus, without proxy ND, MR can return home. >> Some advantages using HoA derived from MNP. The operators do not >> suffer from matching HoA from the home link and assigned MNP. We can >> save a prefix/64 for just assigning HoA to MRs. > > I'm not sure I understand how the matching hurts the operators. > > I don't think addresses or prefixes are saved, can you explain? You need /64 or shorter prefix to assign HoA. regards, ryuji From nemo-bounces@ietf.org Mon Feb 20 12:07:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBEVf-0006L5-Va; Mon, 20 Feb 2006 12:07:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBEVe-0006Kx-NK for nemo@ietf.org; Mon, 20 Feb 2006 12:07:38 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBEVe-0005Qz-Fd for nemo@ietf.org; Mon, 20 Feb 2006 12:07:38 -0500 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k1KHMO8Q015265; Mon, 20 Feb 2006 10:22:27 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k1KHLPVW013328; Mon, 20 Feb 2006 11:21:26 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 14C5C8637E6; Mon, 20 Feb 2006 18:07:20 +0100 (CET) Message-ID: <43F9F743.20703@motorola.com> Date: Mon, 20 Feb 2006 18:07:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] RE: draft-ietf-nemo-home-network-models-05 References: <7892795E1A87F04CADFCCF41FADD00FC01D297BA@xmb-ams-337.emea.cisco.com> <43F20601.1040705@motorola.com> <20060215121222.1dc6385f.ernst@sfc.wide.ad.jp> <43F4AA5F.9040602@motorola.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Thierry Ernst , mattias.l.pettersson@ericsson.com, pthubert@cisco.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > Alex > > On 2006/02/17, at 1:37, Alexandru Petrescu wrote: > >> Ryuji Wakikawa wrote: >>> Hi Alex and Thierry Please check the RFC3964 section3 We said "A >>> Mobile Router has a unique Home Address through which it is reachable when it is registered with its Home Agent. The Home Address is configured from a prefix aggregated and advertised by >>> its Home Agent. The prefix could be either the prefix >>> advertised on the home link or the prefix delegated to the Mobile >>> Router. " >>> >> >> Hi Ryuji, there can be no implementation that derives the HoA from >> MNP and simultaneously is defended by proxy ND by HA. Is there any? > > I don't know how you can conclude like this.. > > SHISA can generate HoA from MNP. MR can return home in some configuration. When MR returns home, HA does not remove network route > of MNP pointed to MR. Thus, without proxy ND, MR can return home. Mobile IPv6 and NEMO require HA to do proxy ND for the Home Address. If some HA does not do proxy ND for the Home Address then it's a little bit incomplete. That's why I was saying that one can't implement a Mobile IPv6/NEMO HA doing proxy ND for a Home Address derived from the MNP. >>> Some advantages using HoA derived from MNP. The operators do not suffer from matching HoA from the home link and assigned MNP. We can save a prefix/64 for just assigning HoA to MRs. >> >> I'm not sure I understand how the matching hurts the operators. >> >> I don't think addresses or prefixes are saved, can you explain? > > You need /64 or shorter prefix to assign HoA. You need a /64 prefix for all the MRs and MHs (and maybe some LFNs too) present on the home link. It is at least needed to put something in the RAs the HA sends on its home link (otherwise MR can't realize it is back home). draft-xx: > To properly identify the Home Network, the MR must expect a shorter prefix than that of the Mobile Network from which the Home Address was formed. This is not implementable. Most prefix match in routing is a "longest-match". A shorter prefix can't be really matched unless a precise bound is specified, but then it's an "exact match". I.e. if a MR in "aggregated mode" attaches to a network whose first two bits match its Home Address, but all the other (3rd up to 63rd) bits don't match, will falsely believe it is at home. Alex From nemo-bounces@ietf.org Tue Feb 21 15:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBeSV-0003fV-Qt; Tue, 21 Feb 2006 15:50:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBeSQ-0003e0-Q3; Tue, 21 Feb 2006 15:50:02 -0500 Received: from [156.154.16.129] (helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBeSQ-0007ox-DX; Tue, 21 Feb 2006 15:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1LKo2vP020958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Feb 2006 20:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FBeSQ-0000Gr-16; Tue, 21 Feb 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 21 Feb 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-home-network-models-06.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : NEMO Home Network models Author(s) : P. Thubert, et al. Filename : draft-ietf-nemo-home-network-models-06.txt Pages : 23 Date : 2006-2-21 This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO related mailing lists. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-home-network-models-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-home-network-models-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-home-network-models-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-21143311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-home-network-models-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-home-network-models-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-21143311.I-D@ietf.org> --OtherAccess-- --NextPart-- From nemo-bounces@ietf.org Fri Feb 24 05:14:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZxq-0005lU-PK; Fri, 24 Feb 2006 05:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZxq-0005l3-1Y for nemo@ietf.org; Fri, 24 Feb 2006 05:14:18 -0500 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZxp-0005Sd-M9 for nemo@ietf.org; Fri, 24 Feb 2006 05:14:18 -0500 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 10:14:16 +0000 Received: from wangyaning ([131.227.76.238]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 10:14:16 +0000 Message-ID: <002c01c6392b$12477e10$71f3010a@wangyaning> From: "Wang Yaning" To: Date: Fri, 24 Feb 2006 10:14:17 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C6392B.11DB00A0" 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-OriginalArrivalTime: 24 Feb 2006 10:14:16.0591 (UTC) FILETIME=[117539F0:01C6392B] X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [nemo] About scheduling of NEMO X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C6392B.11DB00A0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all,=20 I am a PhD student researching scheduling of NEMO. I have some ideas but = need some comments from you experts. Could you please spend some time to = have a look and tell me if it is a significant problem or if there are = any related references. Thank you all very much! A scheduler is needed in MR, to schedule packets going out of NEMO = subnet. I find that current scheduling algorithms for wireless network = cannot be applied to NEMO directly because they assume that there are = constant network resources to be distributed. MR connects to the BS with = wireless link, which is time-varying and location-dependent, so the = available network resources to MR is varying fast. Therefore, we need a = scheduler that can adapt to the varying network resources. Specifically, = when the network resources, e.g. bandwidth is not enough for all the = flows of the NEMO, MR scheduler should hold some low priority flows = temporarily to keep guarantee the QoS of high priority flows. So an = adaptive scheduling algorithm needs to be designed for MR in NEMO.=20 I will appreciate to all comments and suggestions.=20 Regards, Mr Yaning Wang Centre for Communication Systems Research University of Surrey Guildford Surrey GU2 7XH United Kingdom Tel: +44-1483682292 ------=_NextPart_000_0029_01C6392B.11DB00A0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all,
I am a PhD student researching = scheduling of NEMO.=20 I have some ideas but need some comments from you experts. Could you = please=20 spend some time to have a look and tell me if it is a significant = problem or if=20 there are any related references. Thank you all very much!
 
A scheduler is needed in MR, to = schedule packets=20 going out of NEMO subnet. I find that current scheduling algorithms for = wireless=20 network cannot be applied to NEMO directly because they assume that = there are=20 constant network resources to be distributed. MR connects to the BS with = wireless link, which is time-varying and location-dependent, so the = available=20 network resources to MR is varying fast. Therefore, we need a scheduler = that can=20 adapt to the varying network resources. Specifically, when the network=20 resources, e.g. bandwidth is not enough for all the flows of the NEMO, = MR=20 scheduler should hold some low priority flows temporarily to keep = guarantee the=20 QoS of high priority flows. So an adaptive scheduling algorithm needs to = be=20 designed for MR in NEMO.
 
I will appreciate to all comments and = suggestions.=20
 
Regards,
Mr Yaning Wang
Centre = for=20 Communication Systems Research
University of = Surrey
Guildford
Surrey=20 GU2 7XH
United Kingdom
 
Tel: = +44-1483682292
------=_NextPart_000_0029_01C6392B.11DB00A0-- From nemo-bounces@ietf.org Fri Feb 24 19:08:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmiA-0003LF-2p; Fri, 24 Feb 2006 18:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCmhH-0001du-37; Fri, 24 Feb 2006 18:50:03 -0500 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCmhG-0006zH-9r; Fri, 24 Feb 2006 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k1ONo1BX010428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Feb 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCmhF-0003N7-Lr; Fri, 24 Feb 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Feb 2006 18:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-05.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-multihoming-issues-05.txt Pages : 46 Date : 2006-2-24 This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are then made as to whether the NEMO Working Group should solve these issues, or a solution should be sought elsewhere. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-24160148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-24160148.I-D@ietf.org> --OtherAccess-- --NextPart-- From allen@dotnet.com Mon Feb 27 05:50:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDfxS-0004nT-O3 for nemo-archive@lists.ietf.org; Mon, 27 Feb 2006 05:50:26 -0500 Received: from aaoc215.neoplus.adsl.tpnet.pl ([83.5.110.215]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FDfxQ-000596-MX for nemo-archive@lists.ietf.org; Mon, 27 Feb 2006 05:50:26 -0500 Received: from mail by microsoft.com with local id 6-94-78; Mon, 27 Feb 2006 09:38:49 -0500 Message-ID: <13256@phosphor> From: Candy Bravo To: nemo-archive@lists.ietf.org Subject: Your Order Date: Mon, 27 Feb 2006 10:05:30 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 24243443.869146.0363870.1239 X-MimeOLE: Produced By Microsoft MimeOLE 947794.57960364.9510686.2841 Content-Type: multipart/mixed; boundary="------=8988952765257" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 4.2 (++++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 --------=8988952765257 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Men of action are favored by the Goddess of luck.
The main thing about being a hero is to know when to die.Perpetual modernness is the measure of merit in every work of art. --------=8988952765257 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Your Order-> http://au.geocities.com/jenda2661stefa71624/ --------=8988952765257--