From nemo-admin@nal.motlabs.com Sat Mar 1 23:43:24 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24475 for ; Sat, 1 Mar 2003 23:43:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h224a9T05644; Sun, 2 Mar 2003 05:36:10 +0100 Received: from fep03-mail.bloor.is.net.cable.rogers.com (fep03-mail.bloor.is.net.cable.rogers.com [66.185.86.73]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h224ZrT05634 for ; Sun, 2 Mar 2003 05:35:53 +0100 Received: from ee.ryerson.ca ([24.112.78.44]) by fep03-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030302043530.ZSDJ81097.fep03-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Sat, 1 Mar 2003 23:35:30 -0500 Message-ID: <3E6189EF.6050209@ee.ryerson.ca> From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@nal.motlabs.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Sat, 1 Mar 2003 23:35:30 -0500 Subject: [nemo] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 10 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 01 Mar 2003 23:34:55 -0500 Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) From nemo-admin@nal.motlabs.com Mon Mar 3 01:50:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29134 for ; Mon, 3 Mar 2003 01:50:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h236n5T20469; Mon, 3 Mar 2003 07:49:05 +0100 Received: from mail.ict.ac.cn ([159.226.39.4]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id h236mOT20447 for ; Mon, 3 Mar 2003 07:48:24 +0100 Message-Id: <200303030648.h236mOT20447@jessica.nal.motlabs.com> Received: (qmail 28208 invoked from network); 3 Mar 2003 06:32:09 -0000 Received: from unknown (HELO zwj) (159.226.39.104) by 159.226.39.4 with SMTP; 3 Mar 2003 06:32:09 -0000 From: "Zhang Wenjie" To: "nemo-admin@nal.motlabs.com" , "nemo@nal.motlabs.com" , "nemo@nal.motlabs.com" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h236mOT20447 Subject: [nemo] different with ad hoc network? Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 3 Mar 2003 14:48:21 +0800 Content-Transfer-Encoding: 8bit Can we say mobile network is a wireless routing application? So it is a real application of ad hoc network? Thanks a lot! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Zhang Wenjie ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡zwj@ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-03-03 From nemo-admin@nal.motlabs.com Mon Mar 3 01:52:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29156 for ; Mon, 3 Mar 2003 01:52:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h236qdT20494; Mon, 3 Mar 2003 07:52:39 +0100 Received: from mail.ict.ac.cn ([159.226.39.4]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with SMTP id h236mOT20448 for ; Mon, 3 Mar 2003 07:48:24 +0100 Message-Id: <200303030648.h236mOT20448@jessica.nal.motlabs.com> Received: (qmail 28208 invoked from network); 3 Mar 2003 06:32:09 -0000 Received: from unknown (HELO zwj) (159.226.39.104) by 159.226.39.4 with SMTP; 3 Mar 2003 06:32:09 -0000 From: "Zhang Wenjie" To: "nemo-admin@nal.motlabs.com" , "nemo@nal.motlabs.com" , "nemo@nal.motlabs.com" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h236mOT20448 Subject: [nemo] different with ad hoc network? Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 3 Mar 2003 14:48:21 +0800 Content-Transfer-Encoding: 8bit Can we say mobile network is a wireless routing application? So it is a real application of ad hoc network? Thanks a lot! ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Zhang Wenjie ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡zwj@ict.ac.cn ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2003-03-03 From nemo-admin@nal.motlabs.com Mon Mar 3 08:31:02 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24467 for ; Mon, 3 Mar 2003 08:30:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h23DIJT24401; Mon, 3 Mar 2003 14:18:19 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h23DEjT24312 for ; Mon, 3 Mar 2003 14:14:46 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h23DFFfv012120; Mon, 3 Mar 2003 06:15:19 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA09579; Mon, 3 Mar 2003 06:12:36 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/il06exr01) with ESMTP id h23DEFp09031; Mon, 3 Mar 2003 07:14:15 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 6D3022EC86; Mon, 3 Mar 2003 14:14:16 +0100 (CET) Message-ID: <3E635528.5010501@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Content-Type: multipart/mixed; boundary="------------060003010808030405070708" Subject: [nemo] draft submission draft-petrescu-nemo-mrha-02.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 03 Mar 2003 14:14:16 +0100 This is a multi-part message in MIME format. --------------060003010808030405070708 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear RFC Editor, We would like to submit a new version of draft-petrescu-nemo-mrha-02.txt title: Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA) authors: Petrescu et alia. Thank you for taking this submission into consideration. In case attachment is wrong, the draft can be downloaded from: http://www.nal.motlabs.com/nemo/drafts/draft-petrescu-nemo-mrha-02.txt -- Message Classification: GBU --------------060003010808030405070708 Content-Type: text/plain; name="draft-petrescu-nemo-mrha-02.txt" Content-Disposition: inline; filename="draft-petrescu-nemo-mrha-02.txt" Content-Transfer-Encoding: 8bit Internet Draft A. Petrescu, ed. Document: draft-petrescu-nemo-mrha-02.txt M. Catalina-Gallego Expires: September 2003 C. Janneteau H.-Y. Lach A. Olivereau Motorola March 2003 Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA) Status of this Nemo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes several issues relevant to the design of a network mobility support solution that relies on the bi-directional tunnel between Mobile Router and Home Agent, with Mobile IP. Examples of issues are: conflicting Mobile IP and RIPng/OSPF requirements on link-local addresses, HA/BR co-location, and "cross-over" tunnels. Petrescu et al. Expires September 2003 [Page i] INTERNET-DRAFT Mobile Networks Issues March 2003 Table of Contents Status of this Nemo................................................i Abstract...........................................................i Conventions Used in this Document.................................ii 1. Introduction....................................................1 2. Definitions.....................................................1 3. NEMO "Basic" preliminary descriptions...........................1 4. Issues..........................................................2 4.1 Implementation-independent specification terms...............2 4.2 Allow for deployment flexibility.............................3 4.3 Dynamic routing protocol and the HA..........................3 4.4 Link-local addresses.........................................3 4.5 Mobile Router as a Mobile Host...............................4 4.6 Neighbour Discovery for MR's egress interface................4 4.7 Separation of routing and mobility for MR....................5 4.8 Prefix-based routing and host-based routing exceptions.......5 4.9 IPv4 Issues..................................................5 4.10 "Cross-over" tunnels........................................6 5. Security Considerations.........................................6 5.1 A tool: HA ingress filtering.................................6 Acknowledgements...................................................6 References.........................................................7 Changes............................................................9 A. Motivation for Full Addresses in Binding Updates................9 A.1 Description of a Home Network................................9 A.2 Scenarios...................................................10 A.2.1 Manual Mobile Networks..................................11 A.2.2 Scenarios with Co-located HA and BR.....................11 A.2.3 Scenarios with HA and BR Separated......................16 A.3 MR Redirects to BR..........................................20 A.4 Informing the HA about the Route to MR......................20 A.4.1 ICMP Redirect from BR to HA.............................21 A.4.2 Static Route Method.....................................21 A.4.3 Dynamic Route Method....................................23 B. Examples and Other Issues......................................23 B.1 Example of issue for Mobile Router as Mobile Host...........23 B.2 Multicast Subscriptions of the MR...........................23 B.3 Examples of issues for Neighbour Discovery for MR...........24 B.4 Router Renumbering..........................................24 B.5 Example of disconnected operation issue.....................25 B.6 Example for the "cross-over" tunnels issue..................25 B.7 Example of use of HA ingress filtering......................26 C. A Digression...................................................27 Intellectual Property Rights Considerations.......................27 Chairs' Addresses.................................................28 Authors' Addresses................................................28 Copyright Notice..................................................29 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Petrescu et al. Expires September 2003 [Page ii] INTERNET-DRAFT Mobile Networks Issues March 2003 1. Introduction This document describes several issues relevant to the design of a network mobility support solution that relies on the bi-directional tunnel between Mobile Router and Home Agent, with Mobile IP. Examples of issues are: conflicting Mobile IP and RIPng/OSPF requirements on link-local addresses, HA/BR co-location and "cross-over" tunnels. The Mobile Router is using Binding Updates, Binding Acknowledgments, Binding Requests and Binding Errors with the Home Agent to maintain the MRHA bidirectional tunnel. The document is organized as follows: the next section presents a short perspective on three preliminary proposals for a NEMO "Basic" type of solution; the following section lists the issues that appear in this type of protocols. Two additional sections, or appendices, give more detail of issues by way of motivations, examples and other related issues. 2. Definitions Complete NEMO terminology can be found in [9]. MH: a mobile host, which is a mobile node (MN) as defined by Mobile IPv6, except all router parts. In Mobile IPv6 terminology, MN can be either a host or a router. An MH can only be a host. MR_HoA: mobile router's Home Address, or the home address of the mobile (egress) interface of the mobile router. MNP: mobile network prefix, or the prefix of the link of the mobile network that will move away. Note that in the most general case a single MR may route multiple prefixes, in which case there would be multiples MNPs per one mobile network. FN: fixed node on the home link. It doesn't stand for fixed network. 3. NEMO "Basic" preliminary descriptions An exhaustive description of the proposals to support mobile networks or mobile routers with Mobile IP bi-directional tunnel can hardly fit in the usual space reserved for an Internet Draft, which is traditionally a short document. We retain three main descriptions: Cisco Mobile IPv4 for Mobile Routers [4], MRTP [13] and the "Basic" approach [22]. MRTP is a method of enabling mobile routers by using dynamic tunnel registrations between the AR's point of attachment and its HA. This tunnel allows the HA to tunnel all traffic for the mobile network prefix to the MR, and also lets the MR forward all mobile network traffic back to the home network, where it is topologically correct, and can avoid ingress routing in the visited network. Petrescu et al. Expires September 2003 [Page 1] INTERNET-DRAFT Mobile Networks Issues March 2003 MRTP does not suffer from the authorization problem of how to show that the MR owns the routing authority for the Mobile Network. The approach relies on the bidirectional tunnel between MR and HA. The solution proposed is valid for Mobile IPv6 as for Mobile IPv4. The MR and HA behaviours still represent a sensitive departure from the Mobile IPv6 protocol in that MR informs its HA directly about the tunnel interface and dynamically triggers additions of routing table entries in the HA's routing table for the MR's tunnel. In addition, the most recent version of the draft proposes usage of the PSBUs in order to inform the HA about the prefix of the mobile network (thus a combination with the PSBU approach). Moreover, the considerations about dynamic routing in this draft refer only to how dynamic routing would work with a MR, but not about the necessity of running a routing protocol between HA and MR. In the Mobile IPv4 case, the network mobility support with the MRHA tunnel has been reported at least by various teams at Cisco [4] and NASA [14]. The Basic protocol proposed in [22] takes a different tack at assigning the home addresses: it assigns it to the MR's ingress interface, instead of the egress interface. In addition, it proposes a two step approach for the search algorithm in the HA's binding cache: the first step is a search based on a key that is a full /128 address, while the second step is a search based on longest-prefix match. A new aspect is that this proposals relies also on a (yet to be developped) prefix delegation scheme where the HA assigns the mobile network prefix to MR, in a dynamic manner. For a more detailed analysis on the first two approaches (MRTP and Cisco Mobile Routers) see sections A.4.2 and A.4.3. 4. Issues The following is a list of issues that we believe might be relevant when designing a Basic type of solution by the NEMO WG. Some of the issues are exemplified in the Appendices. 4.1 Implementation-independent specification terms The specification of the basic network mobility support should be expressed with implementation-independent terms. In other words, clear distinction should be made between the specification of the protocol and a description of a possible implementation of this protocol. Especially, since it is to be based on Mobile IP(v6), the basic NEMO support specification should not make any assumption on how Mobile IP(v6) is implemented but instead re-use (and possibly extend) data structures from the Mobile IP(v6) specification (e.g. Binding Cache), and eventually introduce new ones if needed. Below are two examples of how attention should be payed in the specification of the protocol. Petrescu et al. Expires September 2003 [Page 2] INTERNET-DRAFT Mobile Networks Issues March 2003 The bi-directional approach requires MR's HA to configure a "forwarding information" for the mobile network prefix towards the mobile router. Since the Mobile IP(v6) specification introduces a dedicated structure, so-called Binding Cache, to store mobility-related "forwading information" on the HA, the specification of basic NEMO support should re-use/extend the Binding Cache to include the new mobility-related "forwarding information" for a mobile network. Even though a Binding Cache may be implemented as an extension of a routing table, the specification should relate to the Binding Cache and not the routing table. For instance, the specification should relate to the "forwading information" to be configured on MR's HA for the mobile network prefix in terms of a prefix entry in the Binding Cache instead of an entry in the routing table of MR's HA. Especially, Mobile IP(v6) specification does not specify any routing table for a HA. Similarly, the specification should not assume that a tunnel, e.g. the MRHA bi-directionnal tunnel, is visible as a virtual network interface on the MR or HA. This is an implementation-related consideration that may not be true for all IP(v6)/MobileIP(v6) stacks. Such considerations will allow to clearly draw the line between the specification and a description of a possible implementation, and as a result ease any future implementation of the basic NEMO support as an extention of an existing Mobile IPv6 implementation. 4.2 Allow for deployment flexibility The basic NEMO support specification should not assume MR's HA to be co-located with the Border Router (BR) of MR's home network. The HA should be allowed to be a one-interface machine, separated from BR, that does only NEMO HA functionalities (as a Mobile IP(v6) HA can be). This way, HA can be deployed in a home domain without the need to upgrade deployed BRs offering an easy deployment path. 4.3 Dynamic routing protocol and the HA Considering the case of a HA deployed as a one-interface machine not co-located with BR, the basic NEMO support specification should not mandate the HA to run a routing protocol, even in situation when MR runs a routing protocol. On the other hand, such HA should allow MR and BR to continue running the dynamic routing protocol as if MR was at home. Suffices it for the HA to: (1) join the corresponding multicast address, intercept all packets addressed to the link-local address of MR and encapsulate towards current MR CoA and (2) relay, or forward, towards BR all dynamic routing message exchanges coming from MR. 4.4 Link-local addresses According to section 10.4.2 of Mobile IPv6 spec [12] the HA will not allow re-direction of traffic of a Home Address towards a CoA, when that Home Address is link-local. Two relevant paragraphs: Petrescu et al. Expires September 2003 [Page 3] INTERNET-DRAFT Mobile Networks Issues March 2003 "However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node." "Multicast packets addressed to a multicast address with link-local scope [], to which the mobile node is subscribed, MUST NOT be tunneled to the mobile node;" which exposes, of course, the very nature of link-local addresses: they are local, not going anywhere. On another hand, OSPF for IPv6 [5] requires that: "On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as source." Moreover, RIPng [16] requires that: (1) next hop addresses in routing tables managed by RIPng be link-local and (2) a large part of RIPng messages be originated and adressed to link-local addresses: "An address specified as a next hop must be a link-local address." or "Response Messages: [...] the source of the datagram must be a link-local address." or "Generating Response messages: [...] The IPv6 source address must be a link-local address of the possible addresses of the sending router's interface, except when replying to a unicast Request Message from a port other than the RIPng port." Overall, keeping in mind that Mobile IPv6 is not dealing with link-local home addresses and that routing protocols and forwarding process make substantial use of link-local addresses, the issue is clearly how to make the routing protocols work together with Mobile IPv6. Basic NEMO support specification should enable redirection of traffic destined to MR's link-local addresses. 4.5 Mobile Router as a Mobile Host There are several scenarios that involve an MR that needs to act as a MH too, that is, send normal BUs and use existing Mobile IPv6. Applications running on the MR should take advantage of MR's session continuity and universal reachability at its home address. For more example issues see section B. 4.6 Neighbour Discovery for MR's egress interface Neighbour Discover on the MR's egress interface is particularly delicate in that Neighbour Discovery should act differently when MR Petrescu et al. Expires September 2003 [Page 4] INTERNET-DRAFT Mobile Networks Issues March 2003 is at home and when MR is in a foreign network. A simple example is that when MR is at home, it has little reason to listen to RAs. However, when MR is in a foreign network, receiving RAs is very important in order to have a good working of Mobile IPv6. For more example issues see section B. 4.7 Separation of routing and mobility for MR The necessity of the distinction between mobility vs. routing exchanges holds true irrespective to whether dynamic or static routing is used. If static routing is used, then BR has routes towards the mobile network through the MR, and MR has routes towards the Internet through the BR. If dynamic routing is used, then the MR and BR dynamically exchange routing information that is manually configured in the routing configuration files of MR and of BR, as well as routing information that is delivered by other routers external to the home network (be it beyond the BR or beyond the MR). The entities concerned with routing in the home network are only BR and MR. This behaviour should continue when network mobility is introduced, presumably by deploying an HA (but not touching the BR). MR and HA should exchange only the information related to mobility but not the information related to routing. 4.8 Prefix-based routing and host-based routing exceptions Prefix-based hierarchical routing (where the mobile network link has a prefix that is a subset of the home-network link) is the preferred type of routing for IPv6. Practically though, it is possible for the BR to have a routing table entry containing the prefix of the mobile network, as well as a host-based entry that points to a certain LFN also in the mobile network. Those two entries might or might not have the same common sub-prefix. With a MR at home, being a normal router, BR will know how to forward to all hosts behind the MR as well as only to the specific LFN of the host-based route. This behaviour should be maintained when the MR is no longer at home and when it has a bidirectional tunnel MRHA. 4.9 IPv4 Issues The mechanisms and issues described in this draft for IPv6 mobile networks can be applied for IPv4 network mobility as well. RFC 3344 [21] provides important intuititve support for IPv4 network mobility through the 'R' bit in Registration Requests/Replies. Some solutions have already been successfully tested in [4] and [14]. The support provided in RFC 3344 [21] as well as those solutions keep the HA co-located with the BR. In a general case in which the BR and HA are kept on separate machines (scenarios 9 to 16 in section A.2.3) the same issues as in IPv6 apply to the IPv4 case. Additionally, in Mobile IPv4 there is a distinction between the MN and FA functionality, and it is possible to have the FA separated from the MN, whereas in IPv6 MN and FA are always co-located. This gets us to the following additional cases: Petrescu et al. Expires September 2003 [Page 5] INTERNET-DRAFT Mobile Networks Issues March 2003 -When the MR is in a visited network it can send BU's using a co-located care-of address or a Foreing Agent care-of address if an FA is available. In the latter case, two reverse tunneling modes are possible: direct delivery style and encapsulated delivery style [17]. -The MR may be itself a FA for Leaf Mobile Nodes (LMNs), or the mobile network may contain a FA for LMNs. 4.10 "Cross-over" tunnels A rough definition: two MR-HA tunnels are "crossing over" each other when the path between one tunnel's endpoints includes only one of the other tunnel's endpoints. Support of nested mobile networks is possible only when the path from MR2 to MR1's HA does not go through MR1 (path considered when both mobile routers are at home and no tunnels are in place). An example of the dynamics of two MR-HA crossing tunnels is given in section B.6. 5. Security Considerations A detailed threat analysis is to be performed for a NEMO "Basic" type of solution. But that's what the Charter says anyways. One issue is related to when the MR runs a dynamic routing protocol. In that case, MR is able to inform the routers in the home domain about new routes (or "inject" routes in the home domain). Considering that MR might be a small device, not locked in a highly secured room, not a tamper-proof device, potentially being stolen, then it is clear that the ability to introduce routes in the home domain, and worse, propagating upper to backbones, is inducing serious risks. 5.1 A tool: HA ingress filtering Home Agents supporting mobile networks are normally able to perform ingress filtering, so that only topologically correct packets leave the HA. See section B.7 on how HA could do ingress filtering. Acknowledgements Authors of this document acknowledge the following WG members and non-members for their remarks, improvements to this draft and fruitful discussions: Tim Leinumeller for many insightful remarks and implementation aspects. Mattias Petterson. Vijay Devarapalli. Petrescu et al. Expires September 2003 [Page 6] INTERNET-DRAFT Mobile Networks Issues March 2003 TJ Kniveton. Pekka Pääkkönen. Mooi Choo Chuah. Erik Nordmark. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-03.txt, IETF Internet Draft, February 2003. (Work in Progress). [3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC 2082, January 1997. [4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed March 3rd, 2003 at http://www.cisco.com/univercd/cc/td/doc/product/software/ ios122/122newft/122t/122t4/ftmbrout.pdf [5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 2740, December 1999. [6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. [8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic, Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks Support in Mobile IPv6", draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft, March 2002. (Work in Progress). [9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support Terminology", draft-ernst-nemo-terminology-01.txt, IETF Internet Draft, November 2002. (Work in Progress). [10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark, E., Patil, B. and Roberts, P., "Threat Models introduced by Mobile IPv6 and Requirements for Security", draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet Draft, November 2001. (Work in Progress). [11] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1998. Petrescu et al. Expires September 2003 [Page 7] INTERNET-DRAFT Mobile Networks Issues March 2003 [12] Johnson, David B., Perkins, Charles E. and Arkko, Jari, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-20.txt, IETF Internet Draft, January 2003. (Work in Progress). [13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay, "Mobile Router Tunneling Protocol", draft-kniveton-mobrtr-03.txt, IETF Internet Draft, November 2003. (Work in Progress). [14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart, D. H. and Bell, T. L. and Kachmar, B. A., "Application of Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs of the Aerospace Conference, 2001. [15] Malkin, G., "RIP Version 2, Carrying Additional Information", RFC 1723, November 1994. [16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997. [17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [18] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. [22] Wakikawa, R., Uehara, K., Mitsuya, K. and Ernst, T., "Basic Network Mobility Support", draft-wakikawa-nemo-basic-00.txt, IETF Internet Draft, February 2003. (Work in Progress). Changes October 2002: revision 00 submitted. November 2002: revision 01: -added discussion on multicast addresses with link-local scope. -added Chairs' addresses. -modified the abstract to better express the fact that /128s are probably sufficient. -added section on v4 issues, and Mobile IPv4 issues. -added an empty IPR section. March 2003: revision 02: -major overhaul from revision 01: shorter, focused on main issues, integrated some ml discussions, moved large "Motivation" parts to appendices. -added MH definition and used MH instead of MN when MR acts as an MH. -added more detailed acknowledgements. -added "cross-over" tunnels discussion. -added HA ingress filtering. Petrescu et al. Expires September 2003 [Page 8] INTERNET-DRAFT Mobile Networks Issues March 2003 Appendix A: Motivation for Full Addresses in Binding Updates An initial remark is that traffic coming from outside the home link, or from other hosts on the home link, and directed to hosts in the mobile network (or behind the mobile router) only need to go through the L2 address of the mobile router (corresponding to its L3 address). With Proxy ND [19], it is the HA that pretends to own MR's L3 address by advertising new associations of the MR's L3 address to the its own L2 address, thus intercepting MR's home traffic and forwarding it to the current CoA of the MR. With this in mind, it can be stated that when the MR is in a foreign network, traffic coming from hosts in the mobile network and towards anywhere to the Internet, is first forwarded by the MR through the reverse tunnel MRHA to the HA. Then HA decapsulates and forwards to the address specified in the inner packet. A.1 Description of a Home Network When designing a NEMO solution with the MRHA tunnel, the first steps are to carefully consider the actual behaviour of the home network when the mobile network is at home, employing normal routing. Then this behaviour should be maintained as much as possible when the MR is not at home (e.g. MR should be able to send redirects through the MRHA tunnel); reciprocically, the normal behaviour of an FR at home should change when that FR is an MR and is at home (e.g. when MR at home, the MRHA tunnel should be torn down). When the MR is in a foreign network, its presence at home is simulated by the HA (as in Mobile IPv6 for hosts). Let us consider a simple case of a home network that supports movement of one of its links. The home network is made up of a home link and a mobile network link, separated by the Mobile Router. The home network is connected to the Internet via the Border Router, as presented in the figure: ---- | FN | ---- | ------- home link -------------------| HA/BR |---> Internet | ------- ---- ----- | MR | | LFN | ---- ----- | | mobile link --------- Current specification for Mobile IPv6 implies that the HA can be either co-located with the BR, or it can act as a separate one-interface machine (this is advantageous for deploying Mobile IPv6 without changing BRs). For mobile networks, the latter mode can be pictured like this: Petrescu et al. Expires September 2003 [Page 9] INTERNET-DRAFT Mobile Networks Issues March 2003 ---- ---- | FN | | HA | ---- ---- | | ---- home link -------------------| BR |------> Internet | ---- ---- ----- | MR | | LFN | ---- ----- | | mobile network link --------- It is assumed that routes outside the home link are managed by BR and MR, either in a static manner (operator fills in routing tables) or dynamic manner (application software partially manages routing tables). Remark that even when the dynamic style is used, it is still true that operator fills initial routing configuration files, where she/he puts the image of the network as being what the operator believes it to be. The dynamic behaviour of routing protocols intervenes when certain links come down or up due to failures, the operator view is no longer true, and the routers manage to find alternative paths. Also, the dynamic behaviour helps obtaining shortest paths over large networks, relying on several local operator's views of smaller sized networks. Addition of mobility should not change this. If static routing is used instead of dynamic routing, then static routes are added manually both on MR and on the BR. When considering adding *static* routes in a *dynamic* manner for prefixes shorter than /128 by Mobile IP, authors of this document realize (in truth, hopefully) that Mobile IP starts using semantics that are traditionally belonging to routing protocols. A.2 Scenarios For the sake of completetess, we first describe a simple "manual" scenario for mobile networks based on the MRHA tunnel, that exposes relative simplicity, that uses static routing and doesn't use Mobile IP. Then, adding the Mobile IP behaviour, we present detailed scenarios of communication between an FN on the home link and an LFN on the mobile network link and a CN on the Internet, when the mobile network is at home and away from home in a visited network, and when the HA is co-located with the BR and separated from the BR. All in all, 16 simple scenarios are presented. The scenarios where HA is co-located with BR (1 up to 8) expose that there is no need for MR to communicate prefixes to its HA via BUs. In a normal routing function, when the MR is at home, it exchanges routing information with the BR (co-located with the HA) and thus those prefixes are communicated by e.g. RIP or OSPF. When the MR is not at home, this behaviour continues, but through the MRHA tunnel. Petrescu et al. Expires September 2003 [Page 10] INTERNET-DRAFT Mobile Networks Issues March 2003 The scenarios where HA and BR are separated (9 up to 16) expose that HA needs an entry in its routing table in order to be capable of forwarding packets to the MR (when it is not at home). An additional scenario is then presented where MR at home is using ICMP Redirect, a functionality that might be needed even when the MR is not at home. A.2.1 Manual Mobile Networks Authors of this draft have experimented with "manual" mobile networks in IPv4, where the addition of routes and tunnels on the MR and on the BR are done manually, by operators talking on the phone. A home network was used that contains about 10 routers and about 12 subnets. That home network is connected to the Internet with a BR. All routers have static routes among them. Then, one slice of that home network (the mobile network) containing one "MR", one normal router and 6 subnets, was disconnected from home, and moved across the Atlantic. Once the "MR" was connected on the other side, it was manually configured with a new IPv4 address, mask and default route. Then a tunnel interface and a route were manually set up on the MR, a tunnel interface and a route were manually set up on the BR. All other routes on all other routers where not touched. Mobile IP software was not used. The entire network (the home and the mobile network) looked, and acted, as if the mobile slice were at home. During this, several applications were tested between hosts in the mobile network, hosts in the home network and hosts on the Internet (incidentally, one of the applications was relying on Mobile IPv4 for hosts, but in no relation with the mobile network moving). Again, this "manual" mobile networks scenario was not using any dynamic routing protocol, and the tunnel was not supporting any form of broadcast of multicast. A.2.2 Scenarios with Co-located HA and BR 1. FN sends packet to LFN, mobile network home, HA/BR colocated ---- | FN | ---- | ------- home link -------------------| HA/BR |---> Internet | ------- ---- ----- | MR | | LFN | ---- ----- | | mobile link --------- Petrescu et al. Expires September 2003 [Page 11] INTERNET-DRAFT Mobile Networks Issues March 2003 -FN scans its routing table for LFN's address, and finds default route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -HA scans its BC to find out whether MR is at home; BR scans its routing table for LFN's address, and finds route through MR; -BR sends NS for MR. -MR replies NA with its L2 address. -BR forwards packet to MR and sends ICMP Redirect to FN such that subsequent packets from FN to LFN go straight through MR and not through BR. -MR forwards packet to FN. The sensitive issue exposed here is the way in which initially the packet travels from FN to BR to MR, the dynamic addition of an entry in the routing table of the FN (even if FN doesn't run a routing protocol) and that subsequent packets will not go through BR, but from FN to MR to LFN. 2. FN sends packet to LFN, mobile network visits, HA/BR colocated ---- / | FN | / ---- ----------/ | ------- | | ----------------| HA/BR |---| Internet | home link ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -FN scans its routing table for LFN's address, and finds default route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR (being an HA) scans its BC and its routing table and finds it needs to encapsulate this packet towards MR's CoA. -BR encapsulates through the MRHA tunnel to MR's CoA. -MR decapsulates and forwards to LFN. 3. LFN sends packet to FN, mobile network home, HA/BR colocated Petrescu et al. Expires September 2003 [Page 12] INTERNET-DRAFT Mobile Networks Issues March 2003 ---- | FN | ---- | ------- home link -------------------| HA/BR |---> Internet | ------- ---- ----- | MR | | LFN | ---- ----- | | mobile link --------- -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. -MR replies NA. -LFN sends packet to MR. -MR scans its routing table for LFN's address, and finds route 'on-link'; -MR sends NS for FN. -FN replies NA with its L2 address. -MR forwards packet to FN. 4. LFN sends packet to FN, mobile network visits, HA/BR colocated ---- / | FN | / ---- ----------/ | ------- | | ----------------| HA/BR |---| Internet | home link ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. -MR replies NA. -LFN sends packet to MR. -MR encapsulates this packet through the MRHA tunnel and sends to HA. -HA receives this packet and decapsulates. -HA scans its routing table for FN's address, and finds route 'on-link'; -HA sends NS for FN. -FN replies NA with its L2 address. Petrescu et al. Expires September 2003 [Page 13] INTERNET-DRAFT Mobile Networks Issues March 2003 -HA forwards packet to FN (on behalf of the MR). 5. CN sends packet to LFN, mobile network home, HA/BR co-located ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ----------------| HA/BR |---| Internet | ---- | home link ------- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -BR receives packet from CN towards LFN. -HA scans its BC to see whether MR is at home; BR scans its routing table and finds dest through MR. -BR sends NS for L2 address of MR and MR replies NA. -BR forwards packet to MR. -MR forwards packet to LFN. 6. CN sends packet to LFN, mobile network visits, HA/BR colocated ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ---| HA/BR |---| Internet | ---- ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -BR receives packet from CN towards LFN. -BR scans its routing table and finds dest through MR. -BR scans its routing table and its BC and realizes it needs to send this through the MRHA tunnel. -BR sends the packet through the MRHA tunnel to MR. -MR decapsulates and forwards to LFN. (this is sometimes referred to as triangular routing, since the Petrescu et al. Expires September 2003 [Page 14] INTERNET-DRAFT Mobile Networks Issues March 2003 packet from CN to LFN travels artificially through BR) 7. LFN sends packet to CN, mobile network home, HA/BR colocated ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ----------------| HA/BR |---| Internet | ---- | home link ------- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -MR receives packet from LFN towards CN. -MR scans its routing table to and finds dest through BR. -BR forwards packet to Internet towards CN. -BR1 forwards packet to CN. 8. LFN sends packet to CN, mobile network visits, HA/BR colocated ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ---| HA/BR |---| Internet | ---- ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -MR receives packet from LFN towards CN. -MR scans its tables and finds it needs to send it through the MRHA tunnel. -BR receives this packet, decapsulates and forwards to Internet. -BR1 forwards this packet to CN. (this is sometimes referred to as triangular routing, since the packet from LFN to CN travels artificially through BR) Petrescu et al. Expires September 2003 [Page 15] INTERNET-DRAFT Mobile Networks Issues March 2003 A.2.3 Scenarios with HA and BR Separated 9. FN sends packet to LFN, mobile network home, HA separated BR ---- ---- | FN | | HA | ---- ---- | | ---- home link -------------------| BR |------> Internet | ---- ---- ----- | MR | | LFN | ---- ----- | | mobile network link --------- -FN scans its routing table for LFN's address, and finds default route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR sends NS for MR. -MR replies NA with its L2 address. -BR forwards packet to MR and sends ICMP Redirect to FN such that subsequent packets from FN to LFN go straight through MR and not through BR. -MR forwards packet to FN. 10. FN sends packet to LFN, mobile network visits, HA separated BR ---- ---- / | FN | | HA | / ---- ---- ----------/ | | ---- | | -------------------| BR |---| Internet | home link ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -FN scans its routing table for LFN's address, and finds default Petrescu et al. Expires September 2003 [Page 16] INTERNET-DRAFT Mobile Networks Issues March 2003 route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR sends NS for MR. -HA replies NA with its L2 address (on behalf of MR). -BR forwards packet to HA and sends ICMP Redirect to FN such that subsequent packets from FN to LFN go straight through MR and not through BR. BR also sends ICMP Redirect to HA, such that HA knows a route through MR. The logic of this last ICMP Redirect is described in section 6.1. -HA scans its routing table for LFN's address, and finds through MR; -HA scans binding cache and finds 'through MRHA tunnel'; -HA encapsulates and sends packet to MR. -MR decapsulates and forwards to LFN. The problem in the above case is how to inform the HA about the route towards MR. When MR at home, and HA being a host, normally HA doesn't have a route towards MR. 11. LFN sends packet to FN, mobile network home, HA separated BR ---- ---- | FN | | HA | ---- ---- | | ---- home link -------------------| BR |------> Internet | ---- ---- ----- | MR | | LFN | ---- ----- | | mobile network link --------- -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. -MR replies NA. -LFN sends packet to MR. -MR scans its routing table for LFN's address, and finds route 'on-link'; -MR sends NS for FN. -FN replies NA with its L2 address. -MR forwards packet to FN. 12. LFN sends packet to FN, mobile network visits, HA separated BR Petrescu et al. Expires September 2003 [Page 17] INTERNET-DRAFT Mobile Networks Issues March 2003 ---- ---- / | FN | | HA | / ---- ---- ----------/ | | ---- | | -------------------| BR |---| Internet | home link ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. MR replies NA. -LFN sends packet to MR. -MR encapsulates this packet through the MRHA tunnel and sends to HA. -HA receives this packet and decapsulates. -HA scans its routing table for FN's address, and finds route 'on-link'; -HA sends NS for FN. FN replies NA with its L2 address. -HA forwards packet to FN (on behalf of the MR). 13. CN sends packet to LFN, mobile network home, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | -----------------| BR |---| Internet | ---- | home link ---- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -BR receives packet from CN towards LFN. -BR scans its routing table to and finds dest through MR. -BR sends NS for L2 address of MR. -MR replies NA. -BR forwards packet to MR. -MR forwards packet to LFN. Petrescu et al. Expires September 2003 [Page 18] INTERNET-DRAFT Mobile Networks Issues March 2003 14. CN sends packet to LFN, mobile network visits, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | ---------| BR |---| Internet | ---- ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -BR receives packet from CN towards LFN. -BR scans its routing table to and finds dest through MR. -BR sends NS for L2 address of MR. HA replies NA on behalf of MR. -BR sends Redirect to HA informing it about a route towards MR. -Simultaneously with previous packet, BR forwards packet to HA. -HA scans its routing table and finds an entry to MR (added as a result to ICMP redirect), it also has a BC entry for MR, so it sends the packet through the MRHA tunnel. The problem in the above case is how to inform the HA about the route towards MR. When MR at home, and HA being a host, normally HA doesn't have a route towards MR. 15. LFN sends packet to CN, mobile network home, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | -------------------| BR |---| Internet | ---- | home link ---- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -MR receives packet from LFN towards CN. -MR scans its routing table and finds dest through BR. -BR sends packet to CN Petrescu et al. Expires September 2003 [Page 19] INTERNET-DRAFT Mobile Networks Issues March 2003 16. LFN sends packet to CN, mobile network visits, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | ----------| BR |---| Internet | ---- ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -MR receives packet from LFN towards CN. -MR encapsulates this packet through the MRHA tunnel. -HA receives this packet, decapsulates and sends to CN. A.3 MR Redirects to BR Also, consider the scenario where the FN has a default route towards the MR instead of the BR, and sending packets to a CN on the Internet. This might very well happen when the MR is at home and sending RAs, in addition to the RAs sent by the BR. FN might configure a default route through the MR instead of the BR. If MR is at home, MR will redirect the FN towards the BR. So, even if this looks like a wrong configuration on the FN (its default route should point to BR and not MR), packets will still travel correctly when MR is at home. This should be maintained when the MR is not at home. There are two possibilities: either the HA (replacing the MR) redirects the FN towards the BR, or it is the MR itself that sends the respective ICMP redirect message to the FN (through the MRHA tunnel). The first case supposes that HA maintains a routing table, which contains routes towards the mobile network. This is less desirable if the HA is not co-located with BR, and where we prefer not to have routing interactions with the HA. The latter case is more plausible, keeping the default routing behaviour to the MR. A.4 Informing the HA about the Route to MR In certain scenarios presented previously, with the HA dissociated from the BR and the MR in the visited network, there is a need for the HA to maintain in its routing table an entry towards the MR. A scenario where packets from CN towards LFN are looping between BR and HA has been described in detail in section 3.2.4 of [8]. Several solutions exist to avoid this looping, described below. Petrescu et al. Expires September 2003 [Page 20] INTERNET-DRAFT Mobile Networks Issues March 2003 A.4.1 ICMP Redirect from BR to HA One alternative for avoiding the loop problem is by using ICMP Redirects [19] sent by BR to HA in order to communicate to HA the route it misses towards the MR. ICMP Redirects are deployed and used in existing networks. The classic behaviour of ICMP Redirects is presented in scenario 1. Scenarios 10 and 14 with MR-not-at-home and BR dissociated from HA, present the fact that classic ICMP Redirects are not triggered normally and thus modifications are needed. In addition to the normal behaviour with ICMP Redirects, described in [19], it could be modified according to the following. The decision by BR to send ICMP Redirect towards HA can be taken in at least three ways: -allow a number of iterations of a packet looping between HA and BR and after this fixed number decide to send the Redirect to HA such as the looping stops. This modifies the normal behaviour of BR. -another possibility is for BR to react at the moment it receives the proxy NA from HA (on behalf of the MR), compare to the current entry it has in the Neighbour Cache for MR, and then decide that, because MR has moved away, send Redirect to HA to inform HA about the route to MR. This is the route (or set of routes) normally maintained by the BR with the MR, doesn't contain any form of the new position (CoA) of the MR. This route, or set of routes (in which case a set of Redirects are sent), is copied from BR's routing table. All routes that have destination the MR's home address need to be communicated to HA with ICMP Redirects. This modifies the normal behaviour of BR. -yet another possibility is to consider modifications on HA (from vanilla Mobile IPv6), but don't touch BR, such that HA generates a new packet, thus obtaining a classic ICMP Redirect from BR. When the HA receives a packet that is not for itself, it encapsulates it with an IP-in-IP tunnel, having the src address its own address and the destination address copied from the dst address of the original packet. Then try to route this packet and find the default route towards BR. Then BR sends a normal ICMP Redirect informing HA there is a better route for this packet towards MR. Thus HA acquires the MR route dynamically. The packet will be passed on by BR to HA again, and further details are needed here. Remark that this is equivalent to one iteration of the loop (a particular case of the fixed iterations loop mentioned previously). A.4.2 Static Route Method This is proposed by [4] and [13], where a route is statically introduced in the HA upon receiption of a Binding Update from MR. This route for MR's prefix may point towards MR's home address (next hop), towards a specific tunnel to MR's home address(output Petrescu et al. Expires September 2003 [Page 21] INTERNET-DRAFT Mobile Networks Issues March 2003 interface), or towards a specific tunnel to MR's care-of address (output interface). The first approach proposed in [4] suggests to configure a new static tunnel on the MR's HA towards MR_HoA. This static tunnel, that we call here MR_HoA_tunnel, is to be used as output interface of a new static entry added in the routing table of HA for MR's prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data packet from CN addressed to a LFN, MR's HA will consult its routing table and find a match for that packet for this static route since LFN address matches MR's prefix. As a results it will encapsulate the packet with an additional header that will have MR's HA as source address and MR_HoA as destination address. In order to forward this packet, now addressed to MR's Home Address, the MR will first consult its binding cache and discover MR's Care-of address. It will thus send the packet through the MRHA tunnel towards MR's current location. It is worth mentionning that this approach introduces a double encapsulation of an incoming packet to be forwarded to the MR: the first is due to the MR_HoA_tunnel, the second to the MRHA tunnel. The second approach proposed in [13] suggests a similar method but avoids the overhead introduced by the two tunnels. It consists in configuring a static route in MR's HA routing table for MR's prefix towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of a data packet from CN addressed to a LFN, MR's HA will consult its routing table and, again, find a match for that packet for this static route since LFN address matches MR's prefix. This indicates the MR's HA that the packet should be routed towards MR_HoA. From its binding cache it discovers MR's CoA and as a consequence forwards the incoming packet from the CN directly through the MRHA tunnel. This approach reduces the overhead of the MR_HoA_tunnel but requires a suitable coordination of the routing table and binding cache on the HA. A third possible approach is similar to the previous one but directly uses the MR's care-of address as the tunnel termination point instead of MR's home address. As such the new static entry added in the routing table of HA for MR's prefix is then MR prefix -> MRHA_tunnel. Analyzed from the perspective where HA is separated from BR, and where MR doesn't normally maintain routes with HA, then this addition might seem superfluous. Consider a situation where MR and BR maintain routing information and where that manual route is added on HA. When the MR is not at home, consider that administrator decides to add a new fixed subnet at home, with its own router neighbouring with BR on the home link. Consider the new subnet's prefix being a longer prefix derived from the prefix assigned to the MR's subnet. This is perfectly feasible by changing configurations on the MR and BR. That can work perfectly even if MR is not at home. But if HA doesn't participate in this exchange (which is the case if HA separated from BR) then the manual route added previously in the HA is no longer valid. Thus, a potential issue. Petrescu et al. Expires September 2003 [Page 22] INTERNET-DRAFT Mobile Networks Issues March 2003 Using PSBUs as proposed in [8] and [13] has many side-effects not clearly considered. When the mobile network is assigned several prefixes instead of one, then it is not clear whether several BUs are being sent or only one with several prefixes inside. Remark that in the vanilla Mobile IPv6 case, only one CoA can be sent with a BU (the alternative CoA is only an alternative not a substitute). A.4.3 Dynamic Route Method It is possible for the HA, being either separated or co-located with the BR, to run a specific routing protocol, participating in the routing interactions between BR and all other neighbouring routers on the home link. Thus, the HA always has the necessary route it needs to join the MR's network. If the HA is a one-interface machine, and separated from the BR, it seems that it maintains information that is not always necessary to its well working as a HA. For example, it will maintain routes to all neighbouring routers, be it fixed or mobile. The routes to the fixed neighbouring routers are not necessary for its working as a host, since it suffices to only have a default route towards a BR, that will normally dynamically Redirect it towards the other fixed routers. Moreover, if HA runs a dynamic routing protocol, its route updates will never be taken into account by other routers, since they will always be one hop further than the routes already known by them. Thus it might be possible to have the HA as a silent routing, only receiving route updates from the neighbouring routers, but never sending route updates, since it does not have a network behind it (it is a "host") whose reachability it needs to advertise. RIP [11] supports having a silent host that only listens to update messages, but does not advertise new routes. With OSPF [18] the "listening only" requirement is complicated by the fact that the HA would needs to participate in OSPF's HELLO protocol. The advantage of using this solution is that it does not require additional changes to Mobile IPv6, and PSBUs are not needed. The disadvantage is that if the MR does not run a routing protocol then we still need some way of telling the HA the routes to the MNPs. Appendix B: Examples and Other Issues B.1 Example of issue for Mobile Router as Mobile Host If the MR is at home and it has an address configured on the moving interface other than a link-local address, then the MR can act as an MH too, and send normal Mobile IPv6 BUs, binding that Home Address to a newly configured CoA; thus allowing the MR to be an MH for itself only, ignoring the LFNs. If the MR at home doesn't have other addresses than link-local on the mobile interface then the MR can not send normal Mobile IPv6 BUs and can not be an MH. It can however be an MR for the hosts on the mobile network. B.2 Multicast Subscriptions of the MR Petrescu et al. Expires September 2003 [Page 23] INTERNET-DRAFT Mobile Networks Issues March 2003 When the MR is at home, it normally joins certain multicast groups related to routing (e.g. all-routers multicast group with site scope). This is assumed by dynamic routing protocols, or by renumbering mechanisms. When the MR is no longer at home, its multicast subscription should continue as if it were at home. This can be achieved by "home subscription" techniques considered in relation with Mobile IPv6. B.3 Examples of issues for Neighbour Discovery for MR When MR is at home and sends RA towards the home link, it should not advertise itself as being capable of being a default router (Router Lifetime should be 0). When the MR is visiting, it should not respond to RSs sent on the visited link and it should not send RAs on the visited link. When the MR is at home, it doesn't normally use any information received from RAs sent by a neighbouring router, i.e. the BR. It has a link-local address and if it has a larger scope address configured on an interface, then that is normally done manually. Actually, routers are usually prohibited from using information received in RAs more than for logging and synchronization purposes. When the MR is in a foreign network, it needs a way to configure a Care-of Address. In the hosts case this is done by stateless or stateful autoconf. In the MR case, the stateful is possible, while the stateless is normally prohibited. A good way for address autococnfiguration for the MR should be identified, be it DHCP, or modified RAs, or modified router's behaviour to accept RAs. Assume the MR is at home and a non-link-local (site- or global) home address is configured on the interface connecting to the home link (supposedly the same interface that will change CoAs when visiting). The MR-at-home will do periodic NAs for this home address; this behaviour should stop when MR is visiting. This modified behaviour is already taken into consideration by Mobile IPv6 MN. In the particular MR case, most ND operations of MR are delegated to the HA, and such most entries of Neighbour Cache, Destination Cache that are related to the home link will disappear. New entries that are relevant in the foreign network will populate those tables. When coming back home, all ND entries should be replaced back with the entries related to the home network. Another specific case in point is the default route. As already presented with the router behaviour with respect to RAs, a default route is not normally configured by MR from a received RA. When the MR is in a foreign network, it should have a default route that points to its BR (but through the MRHA tunnel) and another non-tunnelled default route towards the current AR. Moreover, all MR's routing table entries that pointed to BR when the MR was at home, should still continue to point to BR (through the MRHA tunnel). The same is true for all routing table entries of the BR. B.4 Router Renumbering Petrescu et al. Expires September 2003 [Page 24] INTERNET-DRAFT Mobile Networks Issues March 2003 Router Renumbering for IPv6 [7] is a technique where routers of a home network are instructed to change the prefixes they advertise. In the context here, it should be possible for the MR to be re-numbered when it is at home as well as when it is visiting. The renumbering mechanisms provided by Mobile IPv6 (mobile prefix solicitations and advertisements) are not relevant for changing the prefixes advertised by the MR towards the mobile network; but these mechanisms should still be used for MR when MR is acting as an MH. In order for router renumbering to work for MR when acting as MR, the MR should at least be able to maintain its multicast subscription to all-routers group valid at home. B.5 Example of disconnected operation issue An example of an important inconvenient of using exclusively vanilla Mobile IPv6 with MRHA is when nesting: consider two mobile networks, each MR having its own HA in different domains. The first MR attaches to an AR and the second MR attaches under the first mobile network. In this case, two LFNs situated one on the first net and the second on the second net are capable to communicate with each other, but communication goes through both first MR's HA and through second's. In practice this exposes a paradox where if first MR loses connection to AR, then even if the two nets stay attached, the two LFNs can not communicate. B.6 Example for the "cross-over" tunnels issue Consider the following example, where both MRs are at home and where MR1's mobile network contains HA2. MR1 belongs to HA1 and MR2 belongs to HA2. ----------/ ------- | | -----------------------| HA1/BR|---| Internet | | ------- | | | ---------- ----- ----- | MR1 | | HA2 | ----- ----- | | ------------ | ----- ----- | MR2 | | LFN | ----- ----- | | ------------ In the next step, consider that the MR2's mobile network goes visit AR, like in the figure below: Petrescu et al. Expires September 2003 [Page 25] INTERNET-DRAFT Mobile Networks Issues March 2003 ----------/ ------- | | ---------------| HA1/BR|---| Internet | | ------- | | ----- ----- ----------\ | MR1 | | HA2 | \ ----- ----- ----- | | | AR | ------------ ----- | ----- ----- | MR2 | | LFN | ----- ----- | | ------------ The tunnel setup procedure of this movement is between MR2 and HA2. This tunnel can be easily setup; consider now the next movement: ----------/ ------- | | | HA1/BR|---| Internet | ------- | | ----------\ \ ----- | AR | ----- | ----- ----- | MR2 | | LFN | ----- ----- | | ------------ | ----- ----- | MR1 | | HA2 | ----- ----- | | ------------ After this movement, MR1 tries to setup its bidirectional tunnel with HA1, by sending a BU to HA1. This BU is encapsulated by MR2 towards HA2. However, HA2 is no longer at home (having moved together with MR1); thus the tunnel between MR1 and HA1 can not be set up, because if it were set up, it would have "crossed over" the tunnel between MR2 and HA2. If one were to draw the two tunnels in the above picture, a tunnel would be between MR2 and HA2 and the other between MR1 and HA1. The path MR1-HA1 includes only the MR2 endpoint of the tunnel MR2-HA2. B.7 Example of use of HA ingress filtering HA should verify that packets it receives from the MRHA tunnel have a source address that matches what's in HA's routing table. HA Petrescu et al. Expires September 2003 [Page 26] INTERNET-DRAFT Mobile Networks Issues March 2003 should have a route for the mobile prefix pointing into the MRHA tunnel, and the LFN should have use a source address derived from that prefix when sending its packets. Other packets will be dropped. Appendix C: A Digression Two types of approaches have been distinguished in designing a network mobility support with Mobile IPv6 and the bidirectional tunnel. Clean-slate Mobile IP-centric approach In this approach, it is assumed that a home network is in fact a new 1-link network. This home network connects to the Internet with one or more BRs. The BRs have HA functionality with Mobile IP for hosts. There are no other routers or hosts in the home network than the BRs and the MRs. MRs are seldom at home. MRs and BRs would presumably have little need to run a dynamic routing protocol. Most, if not all, routing information exhanges happen with Mobile IP BUs. Nodes in the mobile networks communicate with CNs. Those CNs are anywhere in the Internet, but not in the home network (there's no node in the home network than BRs and/or other MRs). Evolutionary approach In this type of approach, it is assumed that a home network is already deployed. The home network has several routers that run dynamic routing protocols (non-Mobile IP) to maintain connectivity between various endpoints. The home network is connected to the Internet with one or more BRs. From this, it is possible to "mobilize" some slices (or chunks of this network), maintaining session continuity and reachability at a permanent home address for fixed nodes of that slice. Consider that the slice that needs to be physically disconnected from the home network uses a router (called "MR") that connects the slice to the home network. A minimal deployment effort could be the following: (1) modify software on MR and (2) place a new box with new software on the link where MR was connecting the slice to the home network (this entity called "HA"). MR and the slice move away and HA stays in place. Intellectual Property Rights Considerations Consult Motorola on IPR (authors believe no IPR here, but depends who asks; the complete and authoritative answers can be found from IPD or Public Relations of Motorola, corelated with IPD of ECRL). Petrescu et al. Expires September 2003 [Page 27] INTERNET-DRAFT Mobile Networks Issues March 2003 Chairs' Addresses Thierry Ernst, Timothy J. Kniveton French National Institute for Communication Systems Lab Research in Computer Science and Nokia Research Center Control 313 Fairchild Drive Visiting Researcher at WIDE Mountain View, California 94043 Project USA Jun Murai lab. Faculty of Phone: +1 650 625-2025 Environmental Information, EMail: timothy.kniveton@nokia.com Keio University. Fax: +1 650 625-2502 5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan. Phone : +81-466-49-1100 Fax : +81-466-49-1395 E-mail: ernst@sfc.wide.ad.jp Web: http://www.sfc.wide.ad.jp/~ernst/ Authors' Addresses Alexandru Petrescu Miguel Catalina-Gallego Motorola Labs Motorola Labs Espace Technologique de St Aubin Espace Technologique de St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69354827 Phone: +33 1 69352541 Alexandru.Petrescu@motorola.com Miguel.Catalina@motorola.com Christophe Janneteau Hong-Yon Lach Motorola Labs Motorola Labs Espace Technologique de St Aubin Espace Technologique de St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69352548 Phone: +33 1 69352536 Christophe.Janneteau@motorola.com Hong-Yon.Lach@motorola.com Alexis Olivereau Motorola Labs Espace Technologique de St Aubin Gif-sur-Yvette 91193 France Phone: +33 1 69352516 Alexis@motorola.com Petrescu et al. Expires September 2003 [Page 28] INTERNET-DRAFT Mobile Networks Issues March 2003 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Funding for the RFC editor function is currently provided by the Internet Society. Petrescu et al. Expires September 2003 [Page 29] --------------060003010808030405070708-- From nemo-admin@nal.motlabs.com Mon Mar 3 13:50:06 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07340 for ; Mon, 3 Mar 2003 13:50:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h23If2T28136; Mon, 3 Mar 2003 19:41:02 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.11.2/8.11.2) with ESMTP id h23Ie6T28121 for ; Mon, 3 Mar 2003 19:40:06 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h23IdaYk016681 for ; Mon, 3 Mar 2003 11:39:36 -0700 (MST) Received: [from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA03683 for ; Mon, 3 Mar 2003 11:38:13 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/az33exr04) with ESMTP id h23Iacd04834 for ; Mon, 3 Mar 2003 12:36:38 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 53F782EC86 for ; Mon, 3 Mar 2003 19:36:49 +0100 (CET) Message-ID: <3E63A0C1.3000604@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] server down maintenance Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 03 Mar 2003 19:36:49 +0100 Content-Transfer-Encoding: 7bit So it seems that server will go down for maintenance, zoooom. Will let you know when coming up again. -- Message Classification: GBU From nemo-admin@nal.motlabs.com Mon Mar 3 14:27:37 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08811 for ; Mon, 3 Mar 2003 14:27:36 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h23JT3cx031067; Mon, 3 Mar 2003 20:29:03 +0100 Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h23JSNcx031022 for ; Mon, 3 Mar 2003 20:28:24 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h23JS0LH014012 for ; Mon, 3 Mar 2003 12:28:04 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA27794 for ; Mon, 3 Mar 2003 12:26:29 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (8.11.6/il06exr06) with ESMTP id h23JSFd01779 for ; Mon, 3 Mar 2003 13:28:15 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id DC9A72EC86 for ; Mon, 3 Mar 2003 20:28:13 +0100 (CET) Message-ID: <3E63ACCD.9010003@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] list back up again Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 03 Mar 2003 20:28:13 +0100 Content-Transfer-Encoding: 7bit The mailserver is back up and hope it works as before. The sudden interruption had to do with, err, maintenance that was unprovisioned for, some call it risks :-) Sorry for being verbose... From nemo-admin@nal.motlabs.com Tue Mar 4 00:59:38 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25363 for ; Tue, 4 Mar 2003 00:59:37 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2460791003629; Tue, 4 Mar 2003 07:00:08 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h245xa91003617 for ; Tue, 4 Mar 2003 06:59:37 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id C91BC5D0A5; Tue, 4 Mar 2003 14:59:27 +0900 (JST) Message-Id: <20030304.145927.08240438.ernst@sfc.wide.ad.jp> To: smilingfish1976@hotmail.com Cc: nemo@nal.motlabs.com Subject: Re: [nemo] [nemo]a question about "Multihomed Mobile Network" From: Thierry Ernst In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 04 Mar 2003 14:59:27 +0900 (JST) Content-Transfer-Encoding: 7bit > In the section 3.4(multihoming) of draft > "draft-ernst-nemo-terminology-01.txt", > illustrated through the figure 8, the draft said the mobile_network_1 is > single-homed to the Internet through MR1. > > I am confused here,because I don't know where AR1 attaches to . > if it attaches to the Internet ,then the mobile_network_1 is multihomed > bacause MR1 has two egress interfaces on distinct link,if not ,why it be a AR? AR1 is a fixed node (LFN) in mobile_network_1. AR1 is attached to mobile_network_1. It provides access to visiting mobile nodes, not to MR1. If a visiting MRi attaches below AR1, mobille_network_1 does not become multihomed (it is the root-NEMO). Does it answer the question ? Thierry > _____________________________ > | | > | | > | Internet | > | | > |_____________________________| > __|__ __|__ __|__ > | | | | | | > | ARx | | ARy | | ARz | > |_____| |_____| |_____| > ______|__ ____|___ ___|____ > __|__ __|___ ___|__ > | | | | | | > | MR1 | | MR2a | | MR2b | > |_____| |______| |______| > _____|____ ___|__________|___ > __|__ __|__ > | | | | > | AR1 | | AR2 | > |_____| |_____| > > Fig.8: Multihomed Nested Mobile Network > From nemo-admin@nal.motlabs.com Tue Mar 4 11:34:00 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29585 for ; Tue, 4 Mar 2003 11:33:59 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h24GZB91006349; Tue, 4 Mar 2003 17:35:11 +0100 Received: from send.nc.u-tokyo.ac.jp (send.nc.u-tokyo.ac.jp [133.11.119.246]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h24GYg91006338 for ; Tue, 4 Mar 2003 17:34:44 +0100 Received: from arten12.nc.u-tokyo.ac.jp (arten12.nc.u-tokyo.ac.jp [133.11.119.42]) by send.nc.u-tokyo.ac.jp (8.12.8/3.7W) with SMTP id BAA20981 for ; Wed, 5 Mar 2003 01:35:17 +0900 (JST) Received: from chamomile.mlab.t.u-tokyo.ac.jp ([133.11.236.1]) by arten12.nc.u-tokyo.ac.jp (NAVGW 2.5.1.18) with SMTP id M2003030501343709716 for ; Wed, 05 Mar 2003 01:34:37 +0900 Received: (qmail 4868 invoked from network); 4 Mar 2003 16:34:37 -0000 Received: from unknown (HELO sunflower.mlab.t.u-tokyo.ac.jp) (192.168.1.1) by 133.11.236.1 with SMTP; 4 Mar 2003 16:34:37 -0000 Received: (qmail 15559 invoked by alias); 4 Mar 2003 16:34:37 -0000 Received: (qmail 15552 invoked from network); 4 Mar 2003 16:34:36 -0000 Received: from unknown (HELO MORI-T30.mlab.t.u-tokyo.ac.jp) (192.168.1.104) by sunflower.mlab.t.u-tokyo.ac.jp with SMTP; 4 Mar 2003 16:34:36 -0000 Message-Id: <5.0.2.7.2.20030305013408.04139198@pop.mlab.t.u-tokyo.ac.jp> X-Sender: mori@pop.mlab.t.u-tokyo.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-Jr2 To: nemo@nal.motlabs.com From: Hiroyuki Morikawa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [nemo] Reminder -- MobiCom 2003 paper registration deadline March 5 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 05 Mar 2003 01:34:09 +0900 This is just a reminder that the deadline for registering papers for submission to MobiCom 2003, Ninth Annual International Conference on Mobile Computing and Networking, is this Wednesday, March 5, 2003. All papers must be registered by 11:59 PM PST (US Pacific timezone) on March 5. Registering a paper involves entering the paper's - title, - abstract, - author information, and - topic areas into the MobiCom 2003 EDAS web-based paper submission system. For more information on paper registration and submission for MobiCom 2003, please see the Call for Papers at http://www.sigmobile.org/mobicom/2003/cfp.html and the detailed submission instructions at http://www.sigmobile.org/mobicom/2003/submit.html Once you have registered your paper in this way by the March 5 deadline above, the deadline for then actually submitting the paper is Wednesday, March 12, at 11:59 PM PST (US Pacific timezone). Hiro From nemo-admin@nal.motlabs.com Wed Mar 5 13:44:07 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21109 for ; Wed, 5 Mar 2003 13:44:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h25IdW91015356; Wed, 5 Mar 2003 19:39:35 +0100 Received: from ds20.nudt.edu.cn ([61.187.56.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h25IH691015189 for ; Wed, 5 Mar 2003 19:17:10 +0100 Received: by ds20.nudt.edu.cn (Postfix, from userid 506) id C3A5C5A741; Wed, 5 Mar 2003 17:14:46 +0800 (HKT) From: Yu Wanrong To: nemo@nal.motlabs.com Reply-To: Yu Wanrong References: <200303030648.h236mOT20447@jessica.nal.motlabs.com> In-Reply-To: <200303030648.h236mOT20447@jessica.nal.motlabs.com> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: YH WebMail Program Version 1.5 X-Originating-IP: 172.31.100.22 Message-Id: <20030305091446.C3A5C5A741@ds20.nudt.edu.cn> Subject: [nemo] =?gb2312?B?UmU6IFtuZW1vXSBkaWZmZXJlbnQgd2l0aCBhZCBob2MgbmV0d29yaz8=?= Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 5 Mar 2003 17:14:46 +0800 (HKT) Content-Transfer-Encoding: 8bit Hi,Zhang Wenjie > Can we say mobile network is a wireless routing application? I don't think we can say NEMO is one kind of wireless routing applicatin,of course ,it's depending on the definition of wireless routing application :-) Network mobility support (NEMO support) deals with situations where an entire network changes its point of attachment to the Internet and thus its reachability in the topology. Currently, drafts and discussion are focused on the network layer of network protocol stack(IP layer of TCP/IP).Those submitted solutions all suggest one way to provide continuous and security Internetsessions to all nodes behinds the MR. All these is done at IP layer as an new extension of standard IPv6 (IPv4), thus the upper layer fell nothing but some loss of performance when the MR change its attach point to the Internet. >So it is a real application of ad hoc network? Also, I don't think NEMO is an application of ad hoc network,I think there are some difference between them and list parts of them below: 1.NEMO support both mobile and non mobile nodes 2.the internal structure of the mobile network is relatively stable (no dynamicchange of the topology), though this is not a general assumption . 3.in the mobile network, only MR and AR can perform routing 4.mobile network changes its point of attachment as an unit, so the nodes outside of the mobile can only see the mobility of whole mobile network, while not of single node ...... Does it answer the question? Yu Wanrong From nemo-admin@nal.motlabs.com Wed Mar 5 19:41:08 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08329 for ; Wed, 5 Mar 2003 19:41:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h260g891017022; Thu, 6 Mar 2003 01:42:08 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h260fu91017014 for ; Thu, 6 Mar 2003 01:41:58 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id E9BEE5D097; Thu, 6 Mar 2003 09:41:44 +0900 (JST) Message-Id: <20030306.094144.01429713.ernst@sfc.wide.ad.jp> To: Yu.Wanrong@nudt.edu.cn Cc: nemo@nal.motlabs.com Subject: Re: [nemo] Re: [nemo] different with ad hoc network? From: Thierry Ernst In-Reply-To: <20030305091446.C3A5C5A741@ds20.nudt.edu.cn> References: <200303030648.h236mOT20447@jessica.nal.motlabs.com> <20030305091446.C3A5C5A741@ds20.nudt.edu.cn> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 06 Mar 2003 09:41:44 +0900 (JST) Content-Transfer-Encoding: 7bit From: Yu Wanrong > >So it is a real application of ad hoc network? > > Also, I don't think NEMO is an application of ad hoc > network,I think there are some difference between them > and list parts of them below: > > 1.NEMO support both mobile and non mobile nodes > > 2.the internal structure of the mobile network is > relatively stable (no dynamicchange of the topology), > though this is not a general assumption . > > 3.in the mobile network, only MR and AR can perform > routing 3. is not true, it depends on the configuration of the mobile network. In the simple case, where the mobile network is a subnet, only the MR performs routing. But if the mobile network is bigger and contains several subnets, a RIP or OSPF or some other routing protocol is running inside the mobile network. This "some other" may possibly be an ad-hoc routing protocol. So, the mobile network, in some very specific cases, may be an ad-hoc network. But this is not a general assumption. > 4.mobile network changes its point of attachment as an > unit, so the nodes outside of the mobile can only see > the mobility of whole mobile network, while not of > single node Thierry From nemo-admin@nal.motlabs.com Thu Mar 6 00:17:56 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13435 for ; Thu, 6 Mar 2003 00:17:52 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h265ID91018633; Thu, 6 Mar 2003 06:18:13 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h265HM91018622; Thu, 6 Mar 2003 06:17:25 +0100 Received: by jazz.mei.co.jp (8.12.5/3.7W/jazz) with ESMTP id h265HDBp003863; Thu, 6 Mar 2003 14:17:13 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx2) with ESMTP id h265HDK17185; Thu, 6 Mar 2003 14:17:13 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id h265HDE00810; Thu, 6 Mar 2003 14:17:13 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h265HDf22604; Thu, 6 Mar 2003 14:17:13 +0900 (JST) Received: from [133.183.212.174] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h265HCj29234; Thu, 6 Mar 2003 14:17:12 +0900 (JST) From: Takeshi TANAKA To: Alexandru Petrescu, IETF NEMO Subject: Re: [nemo] draft submission draft-petrescu-nemo-mrha-02.txt In-Reply-To: <3E635528.5010501@nal.motlabs.com> References: <3E635528.5010501@nal.motlabs.com> Message-Id: <20030306135615.5DFB.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 06 Mar 2003 14:18:05 +0900 Content-Transfer-Encoding: 7bit Hello, Alexandru, On Mon, 03 Mar 2003 14:14:16 +0100 Alexandru Petrescu wrote : > Dear RFC Editor, > > We would like to submit a new version of draft-petrescu-nemo-mrha-02.txt > > title: Issues in Designing Mobile IPv6 Network Mobility with the MR-HA > Bidirectional Tunnel (MRHA) > > authors: Petrescu et alia. > 5. Security Considerations > One issue is related to when the MR runs a dynamic routing > protocol. In that case, MR is able to inform the routers in the > home domain about new routes (or "inject" routes in the home > domain). Considering that MR might be a small device, not locked > in a highly secured room, not a tamper-proof device, potentially > being stolen, then it is clear that the ability to introduce routes > in the home domain, and worse, propagating upper to backbones, is > inducing serious risks. I agree this is one of the most serious issues of NEMO when it deployed. HA should not accept or propagate routing information propagated from MR by dynamic routing protocol or reported by MR(like PSBU) IF either MR and HA are not in the same administrative domain or the case you described above. > A.2.2 Scenarios with Co-located HA and BR > 2. FN sends packet to LFN, mobile network visits, HA/BR colocated > -FN scans its routing table for LFN's address, and finds default > route towards BR. > A.2.3 Scenarios with HA and BR Separated > 10. FN sends packet to LFN, mobile network visits, HA separated BR > -FN scans its routing table for LFN's address, and finds default > route towards BR. If the case 2 or 10 is just after 1 or 9, then FN may already have a destination cache entry towards LFN with next-hop=MR. In that case, FN can resolve L2 addr for MR(, which will be proxyed by HA), or FN may learn it by receiving NA from HA with O-bit set, containing MR's L2 addr. Thanks, Takeshi From nemo-admin@nal.motlabs.com Thu Mar 6 00:21:57 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13544 for ; Thu, 6 Mar 2003 00:21:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h265Mi91018657; Thu, 6 Mar 2003 06:22:44 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h265HW91018625 for ; Thu, 6 Mar 2003 06:17:34 +0100 Received: by jazz.mei.co.jp (8.12.5/3.7W/jazz) with ESMTP id h265HQBp004106; Thu, 6 Mar 2003 14:17:26 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id h265HQK19586; Thu, 6 Mar 2003 14:17:26 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id h265HQY29689; Thu, 6 Mar 2003 14:17:26 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h265HQf22624; Thu, 6 Mar 2003 14:17:26 +0900 (JST) Received: from [133.183.212.174] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h265HPj29239; Thu, 6 Mar 2003 14:17:25 +0900 (JST) From: Takeshi TANAKA To: Chan-Wah Ng , IETF NEMO Subject: Re: [nemo] New draft on multihoming scenarios In-Reply-To: <1046313298.1702.7.camel@beethoven> References: <1046313298.1702.7.camel@beethoven> Message-Id: <20030306135918.5E01.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 06 Mar 2003 14:18:18 +0900 Content-Transfer-Encoding: 7bit On 27 Feb 2003 10:34:58 +0800 Chan-Wah Ng wrote : > http://www.psl.com.sg/draft-ng-nemo-multihoming-issues-00.txt > > This draft first describe various different configuration of multihomed > mobile network, and some deployment examples. Next, we identify issues > that arise in supporting multihomed mobile network, and discusses some > possible approaches to facilitate multi-homing. > > The objective of this document is to precipitate discussions in the > working group in issues regarding multihoming in NEMO. Hence all > comments and inputs are welcomed and greatly appreciated. This draft describes 3 scenarios of multihomed NEMO; - a MR with multiple egress interfaces bound to a single HA - a MR with multiple egress interfaces bound to different HAs - multiple MRs bound to different HAs We are missing the scenario where multiple MRs bound to a single HA which is described in draft-wakikawa-nemo-basic-00.txt These scenarios are based on the term draft; > Multihomed Mobile Network > From 3.4.1, a mobile network is multihomed when either: > - a MR has multiple egress interfaces on the same link, or > - a MR has multiple egress interfaces on distinct link, or > - there are more than one MR in the mobile network But does the second condition means 'multiple egress interfaces bound to distinct home link' ? Thanks, Takeshi From nemo-admin@nal.motlabs.com Thu Mar 6 07:00:35 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06771 for ; Thu, 6 Mar 2003 07:00:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h26C0E91020696; Thu, 6 Mar 2003 13:00:14 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h26Bxf91020684; Thu, 6 Mar 2003 12:59:43 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h26Bxb62008499; Thu, 6 Mar 2003 04:59:38 -0700 (MST) Received: [from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA28163; Thu, 6 Mar 2003 04:57:44 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h26BxKI27150; Thu, 6 Mar 2003 05:59:21 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 534352EC86; Thu, 6 Mar 2003 12:59:31 +0100 (CET) Message-ID: <3E673823.6000302@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takeshi TANAKA Cc: Alexandru Petrescu, IETF NEMO Subject: Re: [nemo] draft submission draft-petrescu-nemo-mrha-02.txt References: <3E635528.5010501@nal.motlabs.com> <20030306135615.5DFB.TAKESHI.TANAKA@yrp.mci.mei.co.jp> In-Reply-To: <20030306135615.5DFB.TAKESHI.TANAKA@yrp.mci.mei.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 06 Mar 2003 12:59:31 +0100 Content-Transfer-Encoding: 7bit Hello Takeshi, Takeshi TANAKA wrote: >> 5. Security Considerations One issue is related to when the MR >> runs a dynamic routing protocol. In that case, MR is able to >> inform the routers in the home domain about new routes (or >> "inject" routes in the home domain). Considering that MR might >> be a small device, not locked in a highly secured room, not a >> tamper-proof device, potentially being stolen, then it is clear >> that the ability to introduce routes in the home domain, and >> worse, propagating upper to backbones, is inducing serious risks. >> > > I agree this is one of the most serious issues of NEMO when it > deployed. HA should not accept or propagate routing information > propagated from MR by dynamic routing protocol or reported by > MR(like PSBU) IF either MR and HA are not in the same > administrative domain or the case you described above. Please clarify? I was mainly referring to the cases where MR and HA are both in the same administrative domain. I mean even if MR visits a foreign network, it is still in the same domain as HA (because of the tunnel "leap"). IMHO, HA should accept routing information updates from MR, even when MR is visiting a foreign network. What do you think? >> A.2.2 Scenarios with Co-located HA and BR 2. FN sends packet to >> LFN, mobile network visits, HA/BR colocated -FN scans its routing >> table for LFN's address, and finds default route towards BR. > > >> A.2.3 Scenarios with HA and BR Separated 10. FN sends packet to >> LFN, mobile network visits, HA separated BR -FN scans its routing >> table for LFN's address, and finds default route towards BR. > > If the case 2 or 10 is just after 1 or 9, then FN may already have > a destination cache entry towards LFN with next-hop=MR. Yes, that is entirely true, the DC would help there a lot. I was having problems expressing what you suggest. My problem was that there might be some time lapsing between scenario 1 and 2, and thus DC entries might expire, and they are not updated by Mobile IP. But if that time is very short, that is exactly what happens, as you say. I purposefully tried to avoid involving the DC in the description in order to keep the description short. I had the generous goal to describe all scenarios but I was almost ending with copying code sections into text :-) The complete scenarios would involve searches in NC, DC, Prefix List, BC, kernel RT and application daemon RT. So that looks awfully complex. That's why one idea, finely illustrated by CJ somewhere at the beginning of the draft, was to express this only in terms of a generic RT. But that looks like another ideal difficult to attain :-) -- Message Classification: GBU From nemo-admin@nal.motlabs.com Thu Mar 6 12:36:57 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01984 for ; Thu, 6 Mar 2003 12:36:55 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h26GO391022284; Thu, 6 Mar 2003 17:24:03 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h26GN691022266 for ; Thu, 6 Mar 2003 17:23:06 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h26GNwI5025081 for ; Thu, 6 Mar 2003 09:23:58 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA05289 for ; Thu, 6 Mar 2003 09:18:57 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h26GIfI21329 for ; Thu, 6 Mar 2003 10:18:42 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 7D0202EC8B for ; Thu, 6 Mar 2003 17:18:52 +0100 (CET) Message-ID: <3E6774EC.7010400@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO list down for maintenance Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 06 Mar 2003 17:18:52 +0100 Content-Transfer-Encoding: 7bit Again, NEMO list down for maintenance 9h30-10h00am Central Time (Chicago, IL, USA area). Reason is related to ISP switching and thus DNS invisibility of jessica. -- Message Classification: GBU From nemo-admin@nal.motlabs.com Fri Mar 7 00:29:47 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29967 for ; Fri, 7 Mar 2003 00:29:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h275Rb91000805; Fri, 7 Mar 2003 06:27:41 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h275Q491000785; Fri, 7 Mar 2003 06:26:10 +0100 Received: by jazz.mei.co.jp (8.12.5/3.7W/kings) with ESMTP id h275PojA017378; Fri, 7 Mar 2003 14:25:50 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx1) with ESMTP id h275Ppb08637; Fri, 7 Mar 2003 14:25:51 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id h275PoE09873; Fri, 7 Mar 2003 14:25:50 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h275Pof22139; Fri, 7 Mar 2003 14:25:50 +0900 (JST) Received: from [133.183.212.174] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h275Poj03614; Fri, 7 Mar 2003 14:25:50 +0900 (JST) From: Takeshi TANAKA To: Alexandru Petrescu, IETF NEMO Subject: Re: [nemo] draft submission draft-petrescu-nemo-mrha-02.txt In-Reply-To: <3E673823.6000302@nal.motlabs.com> References: <20030306135615.5DFB.TAKESHI.TANAKA@yrp.mci.mei.co.jp> <3E673823.6000302@nal.motlabs.com> Message-Id: <20030307113031.AF88.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 07 Mar 2003 14:26:44 +0900 Content-Transfer-Encoding: 7bit On Thu, 06 Mar 2003 12:59:31 +0100 Alexandru Petrescu wrote : > Hello Takeshi, > > Takeshi TANAKA wrote: > >> 5. Security Considerations One issue is related to when the MR > >> runs a dynamic routing protocol. In that case, MR is able to > >> inform the routers in the home domain about new routes (or > >> "inject" routes in the home domain). Considering that MR might > >> be a small device, not locked in a highly secured room, not a > >> tamper-proof device, potentially being stolen, then it is clear > >> that the ability to introduce routes in the home domain, and > >> worse, propagating upper to backbones, is inducing serious risks. > >> > > > > I agree this is one of the most serious issues of NEMO when it > > deployed. HA should not accept or propagate routing information > > propagated from MR by dynamic routing protocol or reported by > > MR(like PSBU) IF either MR and HA are not in the same > > administrative domain or the case you described above. > > Please clarify? I was mainly referring to the cases where MR and HA > are both in the same administrative domain. I mean even if MR visits > a foreign network, it is still in the same domain as HA (because of > the tunnel "leap"). > > IMHO, HA should accept routing information updates from MR, even when > MR is visiting a foreign network. Sorry, I meant "If MR and HA does not belong to the same administrative domain...", not meant it depends on where MR is. This is deployment issue, but it is very possible MR and HA belong to different administrative domains, such that owner of MR is subscriber(or roaming subscriber) of HA's domain and it is possible for users to modify setting/information in the MR, like PAN device with access-WLAN. If MR and HA belong to the same administrative domain, it may not be a problem for HA to accept routing information from MR if user of MR is always trustable, such as mass transit network. > >> A.2.2 Scenarios with Co-located HA and BR 2. FN sends packet to > >> LFN, mobile network visits, HA/BR colocated -FN scans its routing > >> table for LFN's address, and finds default route towards BR. > > > > > >> A.2.3 Scenarios with HA and BR Separated 10. FN sends packet to > >> LFN, mobile network visits, HA separated BR -FN scans its routing > >> table for LFN's address, and finds default route towards BR. > > > > If the case 2 or 10 is just after 1 or 9, then FN may already have > > a destination cache entry towards LFN with next-hop=MR. > > Yes, that is entirely true, the DC would help there a lot. I was > having problems expressing what you suggest. My problem was that > there might be some time lapsing between scenario 1 and 2, and thus DC > entries might expire, and they are not updated by Mobile IP. But if > that time is very short, that is exactly what happens, as you say. > > I purposefully tried to avoid involving the DC in the description in > order to keep the description short. I had the generous goal to > describe all scenarios but I was almost ending with copying code > sections into text :-) > > The complete scenarios would involve searches in NC, DC, Prefix List, > BC, kernel RT and application daemon RT. So that looks awfully > complex. That's why one idea, finely illustrated by CJ somewhere at > the beginning of the draft, was to express this only in terms of a > generic RT. But that looks like another ideal difficult to attain :-) Thanks for explanation. I wanted to say it works even if FN already has a DC towards LFN with next-hop=MR_HoA. Regards, Takeshi From nemo-admin@nal.motlabs.com Fri Mar 7 04:49:41 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16637 for ; Fri, 7 Mar 2003 04:49:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h279p791004068; Fri, 7 Mar 2003 10:51:07 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h279oG91004060; Fri, 7 Mar 2003 10:50:17 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h279p7EL021985; Fri, 7 Mar 2003 02:51:08 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA29669; Fri, 7 Mar 2003 02:48:21 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h279l1P09363; Fri, 7 Mar 2003 03:47:01 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 817CB2EC86; Fri, 7 Mar 2003 10:46:59 +0100 (CET) Message-ID: <3E686A93.803@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takeshi TANAKA Cc: Alexandru Petrescu, IETF NEMO Subject: Re: [nemo] draft submission draft-petrescu-nemo-mrha-02.txt References: <20030306135615.5DFB.TAKESHI.TANAKA@yrp.mci.mei.co.jp> <3E673823.6000302@nal.motlabs.com> <20030307113031.AF88.TAKESHI.TANAKA@yrp.mci.mei.co.jp> In-Reply-To: <20030307113031.AF88.TAKESHI.TANAKA@yrp.mci.mei.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 07 Mar 2003 10:46:59 +0100 Content-Transfer-Encoding: 7bit Takeshi TANAKA wrote: > This is deployment issue, but it is very possible MR and HA belong > to different administrative domains, such that owner of MR is > subscriber(or roaming subscriber) of HA's domain and it is possible > for users to modify setting/information in the MR, like PAN device > with access-WLAN. > > If MR and HA belong to the same administrative domain, it may not > be a problem for HA to accept routing information from MR if user > of MR is always trustable, such as mass transit network. Ah yes, I remember now. So you basically propose that when MR and HA are not in the same admin domain then HA will not accept route information from MR (other than Mobile IPv6). Which is probably a good idea. I think that the reverse is also true: if MR and HA in different admin domains then MR must not accept routing information from HA (other than Mobile IPv6 Binding Requests). -- Message Classification: GBU From nemo-admin@nal.motlabs.com Fri Mar 7 16:04:06 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03167 for ; Fri, 7 Mar 2003 16:04:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h27L5691011143; Fri, 7 Mar 2003 22:05:06 +0100 Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h27L4Q91011133 for ; Fri, 7 Mar 2003 22:04:27 +0100 Received: from ee.ryerson.ca ([24.112.78.44]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP id <20030307210418.FROM265409.fep04-mail.bloor.is.net.cable.rogers.com@ee.ryerson.ca> for ; Fri, 7 Mar 2003 16:04:18 -0500 Message-ID: <3E690948.1030902@ee.ryerson.ca> From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nemo@nal.motlabs.com References: <3E6189EF.6050209@ee.ryerson.ca> Content-Type: multipart/alternative; boundary="------------070100080906010901060502" X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.112.78.44] using ID at Fri, 7 Mar 2003 16:04:18 -0500 Subject: [nemo] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Approaching March 10 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 07 Mar 2003 16:04:08 -0500 --------------070100080906010901060502 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 10, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 10, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) --------------070100080906010901060502 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
Call for Papers - IP Mobility 2003
IEEE VTC Symposium on IP Mobility
October 4-9, 2003 Orlando, FL, USA

in Conjunction with IEEE VTC Fall 2003
Submission Deadline Extended: March 10, 2003

Scope
=====
Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: 
* Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance
* New approaches to wide-area and local mobility
* Quality of Service models, resource management, and provisioning
* Traffic Engineering in mobile wireless IP access networks
* Transport protocol design for mobile wireless networks
* Security including security threat models, threat analysis and their impact on routing
* Application level protocol design and performance
* Mobile and wireless applications, their service requirements and performance
* Content delivery support in IP network for mobile users
* Multicasting for mobile wireless services
* Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network)
* Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular)
* Inter-vehicular network architecture
* Mobile wireless IP access network deployment and management

Posters are also solicited on the projects related to **Support for Network Mobility**.

Submission Instructions
=======================
Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/.

Important Dates
Extended Abstract Due:  March 10, 2003
Acceptance Notification:  May 15, 2003
Camera Ready Copy of Full Paper Due:  July 15, 2003
Symposium Date:  October 4, 2003

Organization
============

Program Co-Chairs:

Muhammad Jaseemuddin (jaseem@ee.ryerson.ca)
Department of Electrical and Computer Engineering
Ryerson University
Toronto, Canada

Hongyi Li (hyli@nortelnetworks.com)
Wireless Technology Lab
Nortel Networks
Ottawa, Canada

Publicity Co-Chair:

Junaid Zubairi (junaid.zubairi@fredonia.edu)
Department of Mathematics and Computer Science
SUNY at Fredonia
Fredonia, NY, USA

Technical Program Committee
===========================
* Ahmed Helmy (U of Southern California, USA)
* Abdelsalam Helal (U of Florida, Gainesville, USA)
* Alan O'Neill (Flarion Technologies, USA)
* Behcet Sarikaya (Alcatel, USA)
* Christophe Janneteau (Motorola, France)
* Govindan Ravindran (Soma Networks, Canada)
* Haseeb Akhtar (inCode Telecom group, USA)
* Hany Elgebaly (Intel Corporation, USA)
* Hesham Soliman (Ericsson, Sweden)
* Lars Wolf (TU Braunschweig, Germany)
* Michael Wolf (Daimler-Chrysler, Germany)
* Raouf Boutaba (U of Waterloo, Canada)
* Sajal Das (The U of Texas at Arlington, USA)
* Samir R. Das (SUNY at Stony Brook, USA)
* Thiery Ernst (Wide, Keio U, Japan)
* Thomas Noel (U of Strasbourg, France)
* Yasser Rasheed (Intel Corporation, USA)
--------------070100080906010901060502-- From nemo-admin@nal.motlabs.com Sun Mar 9 06:25:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20872 for ; Sun, 9 Mar 2003 06:25:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h29BQ791000320; Sun, 9 Mar 2003 12:26:08 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h29BPO91000310 for ; Sun, 9 Mar 2003 12:25:24 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 29E254316C; Sun, 9 Mar 2003 12:25:16 +0100 (CET) Received: from [163.117.252.54] (unknown [163.117.252.54]) by smtp01.uc3m.es (Postfix) with ESMTP id CF51299E6C; Sun, 9 Mar 2003 12:25:04 +0100 (CET) From: marcelo bagnulo To: IETF NEMO , ernst@sfc.wide.ad.jp Content-Type: text/plain Organization: uc3m Message-Id: <1047208960.728.63.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Subject: [nemo] about draft-ietf-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 09 Mar 2003 12:24:59 +0100 Content-Transfer-Encoding: 7bit Hi, I have some comments/questions about draft-ietf-nemo-requirements-00.txt 1- About security features required to the basic solution and the extended solution: In section 4, General Purpose Guidelines... it is stated that "the following issues have to be addressed" Question: shouldn't a MUST be included in the above statement? (i.e. something like "the following security features MUST be provided") The issues included are: authentication, authorization, confidentiality, and location privacy. Later, requirement 12 of section 5. One-liner req... states that the basic solution MUST provide: authentication, authorization, anti-replay and that encryption SHOULD be provided. Question: I find that the both sets of requirements do not completely match. I mean, how is the location privacy requirement imposed to the basic solution? is it included in the encryption requirement? if this is so, why this is a SHOULD? The other difference is about anti-replay protection requirement, that it is not included in the general requirements but it is required for the basic solution, shouldn't this be required for all the solutions? 2- About multi-homing support In section 5. One-liner req... it is stated that the solution MUST function for multi-homed networks, more precisely: "R13.3: The solution must support MR with multiple global addresses on an egress interface." However, draft-ernst-nemo-terminology only includes the following cases: - a MR has multiple egress interfaces on the same link, or - a MR has multiple egress interfaces on distinct link, or - there are more than one MR in the mobile network IMHO, the case where multiple global addresses are configured to a mobile router egress interface should not be included. In this case, the MR has only one attachment point to the Internet, so the mobile network is not multi-homed. However, if the multiple addresses configured to the egress interface of the MR have different global prefixes (i.e. PA addresses that have been assigned by different ISPs),this means that the home network is multi-homed, not that the mobile network is multi-homed. In this case, it is my opinion that the communication between the HA and the MRR can be established using any of the global addresses available and using one or the other does not present benefits for the communication between the HA and the MR. I mean, if the communication fails using one address it will fail using the other one, since they are configured to the same interface. The difference between using one address or the other is related to which ISP will be used when exiting the home network. However, this issue is related to the multi-homing solution configured in the home network, and not to the multi-homing solution of the mobile network. For these reasons, IMO, the case of multiple addresses configured to a single interface should not be considered, since it should be solved by the multi-homing solution of the home network. 3- Multi-homing capabilities. I haven't found any requirements about the capabilities of the mobile network multi-homing solution. It is stated that the solution must function for multi-homed mobile networks, but it is not specified what benefits are expected. IMO a fault tolerance requirement should be included. I mean, suppose that a mobile network has two MRs, and suddenly one MR (MR1) becomes unavailable (MR1 crashes or the communication between MR1 and the HA is unavailable). I would say that all the connections that were being coursed through MR1 have to be preserved during the outage meaning that they have to be re-routed through the alternative MR, providing fault-tolerance capabilities. The same case can be applied to the case of a MR with multiple interfaces and one of them fails. Note that fault tolerance capabilities required to the multi-homing solution of the mobile network are limited to the communication between the MRs and the HA, and are not related to the multi-homing capabilities of the solution of the home network. 4- Other comments - IMO, at least some basic RFCs could be included in the Backward compatibility bullet in section 4. - I guess that the scalability bullet of section 4 attempts to highlight that scalability is important, but perhaps it is bit unspecific for a MUST requirements , i mean, What is a large number of mobile networks? 5- Editorial Numbering of one-liner requirements from number 12 till the end. Regards, marcelo -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Sun Mar 9 17:22:02 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17430 for ; Sun, 9 Mar 2003 17:22:01 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h29MN591007347; Sun, 9 Mar 2003 23:23:05 +0100 Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h29MMK91007339 for ; Sun, 9 Mar 2003 23:22:20 +0100 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 87A7B43135 for ; Sun, 9 Mar 2003 23:22:12 +0100 (CET) Received: from [163.117.252.51] (unknown [163.117.252.51]) by smtp03.uc3m.es (Postfix) with ESMTP id 0C56399E1B for ; Sun, 9 Mar 2003 23:22:11 +0100 (CET) From: marcelo bagnulo To: nemo@nal.motlabs.com Content-Type: text/plain Organization: uc3m Message-Id: <1047248443.1481.118.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Subject: [nemo] about draft-wakikawa-nemo-basic-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 09 Mar 2003 23:22:04 +0100 Content-Transfer-Encoding: 7bit Hi, I have found the draft to be a really interesting reading and I would like to make some comments about it. My first comment is about the new prefix sub-option. If i understood it correctly, this new sub-option replaces the original PSBU. The benefits are clear, less overhead since the prefix is not included. However,IMO this optimization also presents some drawbacks that should be considered in order to evaluate the trade-off that its adoption implies.IMO, Since the prefix is implicit in the MR-A carried in the BU message, the prefix sub-option is less flexible than the original PSBU. In the case that the mobile network is composed by a single subnet with only one prefix, both options are equivalent. However, when the mobile network is composed by multiple subnetworks, the usage of the prefix sub-option imposes additional conditions on the address range assigned to the subnets that compose the mobile network, since they must all obtain their address range from an aggregate that have to be susceptible to be expressed as a prefix of the MR-A. This imposes multiple constraints. First of all, it constraints the way addresses are assigned, i.e. the address administration within the home network. This, at least is an additional burden to address administrators. Additionally, this constraint may impose address lost. For example, suppose that the mobile network is composed by three subnetworks: Pref:0::/48, Pref:1::/48 and Pref:2::/48. In this case, if i understand this correctly, the prefix sub-option would indicate a 47 bits long prefix, imposing the waste of the Pref:3::/48. Additionally, its impact in the case of nested networks should be also considered, since it imposes similar constraints to address administration. My concern is whether the reduction of 64 bits in the BU messages is worth these additional costs. Moreover, it assumed that the HA is aware of the prefix that this particular MR is authorized to announce, because of security reasons. So, why is not enough with the N bit only? I mean, the MR sends a BU with the N bit set, and the HA already knows which prefix of the mobile network (implicit signaling). If i understand the rationale correctly, when PSBU are used, it is useful since the mobile network can have multiple prefixes, and the BU can refer to only some of them. If the prefix sub-option is used, this feature is more restricted since only aggregates containing the MR-A can be announced. I do not know if i am missing something, but IMO much flexibility is lost when replacing PSBU by prefix suboption. My second comment is about the location of the HA. I think that it is assumed that the HA is co-located with the only router present in the home-link. I could not find this assumption in the draft, but it is illustrated in the figure. This assumption is reflected in the behavior described in section 6.2.2 where it is assumed that all incoming packets pass through the HA. Is there any reason for this restriction? I think that the case where multiple routers are present in the home link is a reasonable case, and it can be easily supported, for instance by means of redirect from the HA pointing to the alternative router. Additionally, i think that, as i think it is suggested in draft-petrescu-nemo-mrha-02, the solution should support that the HA is a single interface node. I think that the solution can be extended to support this configurations. Additional comments: IPSec processing is included in section 5.2.2 and 6.1.1 but it is not described in section 5.2.1. Perhaps it would be clarifying to include it. I think that section 6.3 should include the location of the MR (home link or not) among the rules to decide whether HA has to tunnel or not packets to the MR. The fact that the authorization of which prefixes can be announced by a MR is performed by configuring them in the HA is somehow included in different sections in the draft but perhaps it would be relevant to explicitly mention it in the security consideration section. Regards, marcelo -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Sun Mar 9 17:37:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20217 for ; Sun, 9 Mar 2003 17:37:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h29Md391007404; Sun, 9 Mar 2003 23:39:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h29Mc691007394 for ; Sun, 9 Mar 2003 23:38:07 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h29Mbx05025813; Sun, 9 Mar 2003 15:38:00 -0700 (MST) Received: [from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA03729; Sun, 9 Mar 2003 15:36:02 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.66]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h29MbT825263; Sun, 9 Mar 2003 16:37:30 -0600 Message-ID: <3E6BD032.1050304@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo CC: IETF NEMO, Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt References: <1047208960.728.63.camel@presto.it.uc3m.es> In-Reply-To: <1047208960.728.63.camel@presto.it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 00:37:22 +0100 Content-Transfer-Encoding: 7bit Hola Marcelo, marcelo bagnulo wrote: > The issues included are: authentication, authorization, > confidentiality, > > Later, requirement 12 of section 5. One-liner req... states that > the basic solution MUST provide: authentication, authorization, > anti-replay and that encryption SHOULD be provided. > > Question: I find that the both sets of requirements do not > completely match. I agree it's incoherent from this security point of view. Maybe we can make it more coherent. > ... and location privacy. "Location privacy" hasn't been touched until now on the NEMO list, but now that you do, please allow me to reply. First, I think that Thierry has a good explanation for that requirement, we discussed a bit about that and I can't remember the conclusion. Off-topic out-of-scope digression from here on: As it prefigures now, "Location privacy" is a feature that can be provided by Mobile IPv6 itself and not by a NEMO protocol. To the extent that Mobile IPv6 does location privacy, then NEMO will implicitely use that Mobile IPv6 location privacy, but not develop a new scheme for location privacy here. For example, if Mobile IPv6 provides a means to hide (more or less) the MR CoA to CN, such that CN has difficulty in actually localizing MR, then that is enough for NEMO, I believe. If there's a "location privacy" problem very specific NEMO to be solved in the NEMO context, it is probably to hide the location knowledge inside a nested aggregation of mobile networks. I.e. consider three MRs nesting one under the other. The top-level MR must not have have access to knowledge indicating in which way are nested the two MRs below it. It could be that problem, as well as it couldn't. In all cases, "location privacy" is so very much loosely defined (to my knowledge and as far as I know) that it really deserves more work before knowing whether we can require it or not. Also, care must be taken with "location privacy" from too many perspectives. One is this: if the CN doesn't know the CoA of MR, how can it talk to MR at all. A CN that doesn't know the location of a fixed node is what happens with NAT mechanisms: host browses cnn.com, but cnn.com doesn't know host's address because host is behind NAT. And at the same time, CN can not contact host directly. Which it probably doesn't need. But when CN is a host that wants to "call" the other host, then it's exactly "location privacy" that you do _not_ want. I can't just tell you "call me later" w/o giving you my phone number. And once I give you that, you have a lot of information of where I am. An alternative (in the existing art): a CN must know a little bit of MR's location information, prove itself to MR that it's someone who behaves (have certificate) and then CN can know more. A two-step like this can probably work. However, there's a chicken-and-egg problem here (to borrow from SEND terminology). How can CN know even the "approximate" location of MR without MR first informing it about that approximate position? The only possible answer to this is that CN first writes to HA, which replies to CN with the approximate address, that is the address of an entity like an anchor point. So now we have a HA and and an entity between CN and MR that do so much more than simply forwarding packets: they encapsulate, do rounds of messages of security checks and sometimes even literally translate addresses (substitute address x for y). Which can be acceptable up to a point. Suppose CN is an NTP server and host is an NTP client: updating host's clock is a highly engineered message exchange, which allows a high precision of synchronicity over today's Internet. With such a "location privacy" scheme I described above that involves so many additional exchanges, an NTP client will have to choose between either keeping its location private or actually synchronizing its clock. A last aspect is this: Mobile IP has a "NAT traversal" action point in its agenda. That will eventually give a host the opportunity to be behind a NAT and still be reachable. Then "location privacy" will indicate that is not good because the caller can know where a callee is. So we can develop a new NAT2 over NAT traversal such that we can later block again the traversal of NAT, which will not be good enough, and later on make a NAT2-traversal. It's like firewalls: firewall, then splash a p2p ssh tunnel through the firewalls, then do p2p routing algorithms, then block those annoying p2p connections, then traverse those blockings and so on...one wonders what's left of that IP simplicity, I'm lost sometimes :-) And "location privacy" here is entirely different from the privacy concerns of users with browsers that browse sites (forbidden by a higher authority) and don't want to let that higher authority, neither the web sites, to really be able to localize them. Some privacy-concerned persons where telnetting through several intermediate servers before reaching the target, hoping that nobody can find where they came from (which in fact depends on how decided is an admin to corelate logs by time). New processes actually automate this "circling around before reaching target" with random things, and in the process introduce new entities between end user and server. "Location privacy" in mobility context is different than the above, but it has the same level of "elusiveness"... -- Message Classification: GBU From nemo-admin@nal.motlabs.com Sun Mar 9 19:39:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13265 for ; Sun, 9 Mar 2003 19:39:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A0f291007873; Mon, 10 Mar 2003 01:41:02 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A0eY91007865 for ; Mon, 10 Mar 2003 01:40:34 +0100 Received: from [203.178.143.62] (luna.sfc.wide.ad.jp [203.178.143.62]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id C8AE05D019; Mon, 10 Mar 2003 09:40:26 +0900 (JST) From: Ryuji Wakikawa To: marcelo bagnulo Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt Cc: nemo@nal.motlabs.com In-Reply-To: <1047248443.1481.118.camel@presto.it.uc3m.es> References: <1047248443.1481.118.camel@presto.it.uc3m.es> Message-Id: <20030310093043.9413.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 09:40:30 +0900 Content-Transfer-Encoding: 7bit # Some Requests to ML administrators # The SMTP server of NEMO WG has the AAAA record, but SMTP server do not # speak IPv6. Therefore, my SMTP server (IPv6 capable) fails to send email # to NEMO ML. If the SMTP server finds AAAA record, it tries to connect to the IPv6 # address first. and I got connection refused error. Is it possible to # remove AAAA record or to update SMTP server to support IPv6? # Thanks in advance. Hello Marcelo > I have found the draft to be a really interesting reading and I would > like to make some comments about it. Thanks! > My first comment is about the new prefix sub-option. If i understood it > correctly, this new sub-option replaces the original PSBU. The benefits > are clear, less overhead since the prefix is not included. However,IMO > this optimization also presents some drawbacks that should be considered > in order to evaluate the trade-off that its adoption implies.IMO, Since > the prefix is implicit in the MR-A carried in the BU message, the prefix > sub-option is less flexible than the original PSBU. In the case that the > mobile network is composed by a single subnet with only one prefix, both > options are equivalent. However, when the mobile network is composed by > multiple subnetworks, the usage of the prefix sub-option imposes > additional conditions on the address range assigned to the subnets that > compose the mobile network, since they must all obtain their address > range from an aggregate that have to be susceptible to be expressed as a > prefix of the MR-A. This imposes multiple constraints. First of all, it > constraints the way addresses are assigned, i.e. the address > administration within the home network. This, at least is an additional > burden to address administrators. Additionally, this constraint may > impose address lost. For example, suppose that the mobile network is > composed by three subnetworks: Pref:0::/48, Pref:1::/48 and Pref:2::/48. > In this case, if i understand this correctly, the prefix sub-option > would indicate a 47 bits long prefix, imposing the waste of the > Pref:3::/48. The first motivation of this prefix-suboption is optimization as you've notice already:) But, there are other reasons for this now. When a MR has multiple prefixes, the MR acquires multiple MR-A at the ingress interface. The MR have to send BU individually for each mobile prefix. This is because current MIP6 does not allow to update multiple binding caches by sending "single" BU (i.e. no optimization for this). Since the assignment of multiple mobile network prefixes is equal to the assignment of multiple home addresses on Mobile IPv6. I am not sure if it is possible to allow this optimization only for NEMO. There will be another issues if NEMO allows this optimization. PSBU allows to carry prefix and its length in BU, but the prefix stored in the suboption of BU is not secured and authorized. MIP6 security scheme only verify MR's home address, but not prefix itself. Our approach provides these verification by using IPsec encryption. SA is established between MR and HA by using MR-A (MR-A is used as the key of encryption), mobile network prefix is verified. I think this approach is well compliant with current MIP6 spec. Instead, PSBU store all the prefix information in the BU. PSBU needs another way to verify this prefix and also way to notify mapping of home address and mobile network prefixes. Your last scenario is a kinds of administrative issue. MR may sends BU w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length. In fact, I did not mention the situation when MR has multiple mobile network prefixes in the draft. I will add some texts at the next version. Thanks for pointing this out. > Additionally, its impact in the case of nested networks should be also > considered, since it imposes similar constraints to address > administration. My concern is whether the reduction of 64 bits in the BU > messages is worth these additional costs. Optimization is important, but I tried to keep compliance with current MIPv6 spec including security idea, because MIPv6 is fully discussed at the IETF and is very "sensitive" protocol indeed. If I added a lot of optimizations for NEMO, many new issues come up. Furthermore, NEMO has many kinds of configuration compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to provide a certain level of optimization by means of "network operation". (e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix length) > Moreover, it assumed that the HA is aware of the prefix that this > particular MR is authorized to announce, because of security reasons. > So, why is not enough with the N bit only? I mean, the MR sends a BU > with the N bit set, and the HA already knows which prefix of the mobile > network (implicit signaling). If i understand the rationale correctly, > when PSBU are used, it is useful since the mobile network can have > multiple prefixes, and the BU can refer to only some of them. If the > prefix sub-option is used, this feature is more restricted since only > aggregates containing the MR-A can be announced. I do not know if i am > missing something, but IMO much flexibility is lost when replacing PSBU > by prefix suboption. For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64 at the beginning. Then the MR sends BU w/ 64 prefix length instead of 48. Of course, this prefix is belong to the MR, HA can accept BU and intercepts and tunnels packets only for the prefix/64. For these operation, the prefix-suboption is needed. > > My second comment is about the location of the HA. I think that it is > assumed that the HA is co-located with the only router present in the > home-link. I could not find this assumption in the draft, but it is > illustrated in the figure. This assumption is reflected in the behavior > described in section 6.2.2 where it is assumed that all incoming packets > pass through the HA. Is there any reason for this restriction? I think > that the case where multiple routers are present in the home link is a > reasonable case, and it can be easily supported, for instance by means > of redirect from the HA pointing to the alternative router. > Additionally, i think that, as i think it is suggested in > draft-petrescu-nemo-mrha-02, the solution should support that the HA is > a single interface node. I think that the solution can be extended to > support this configurations. Good point, I did not mention this case enough. Delegated prefix is assigned to MR, and HA only advertises the prefix by routing protocol. "Routing protocol" means both IGP and BGP. If there are multiple routers at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in the home link. HA do not send RA of the delegated prefix at the home link, so that it becomes next hop router of the delegated prefix. (Other routers are not on-link of the mobile network prefix). Multiple HAs for single mobile network prefix is not considered yet in the draft. Although current MIP6 does not allow to register same binding to multiple HAs, I have rough solution for this. But I have to consider more before putting texts in the draft, because there are many issues for multiple HAs, how MR selects HA, how HAs manage same mobile network prefix at the home link, how to avoid inconsistency of binding for same prefix among HAs due to some accidents of MR for example. > Additional comments: > > IPSec processing is included in section 5.2.2 and 6.1.1 but it is not > described in section 5.2.1. Perhaps it would be clarifying to include > it. Thanks, I will fix this. > I think that section 6.3 should include the location of the MR (home > link or not) among the rules to decide whether HA has to tunnel or not > packets to the MR. Right. I did not notice this. I will fix this, too. > The fact that the authorization of which prefixes can be announced by a > MR is performed by configuring them in the HA is somehow included in > different sections in the draft but perhaps it would be relevant to > explicitly mention it in the security consideration section. We give the assumption for the prefix assignment and configuration at this moment. I am just wondering whether I should use DHCP prefix delegation for this protocol or not, now. I will think about this more. Thank you for your comments! regards, ryuji From nemo-admin@nal.motlabs.com Mon Mar 10 01:59:54 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22677 for ; Mon, 10 Mar 2003 01:59:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A71591009751; Mon, 10 Mar 2003 08:01:05 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A70Y91009729 for ; Mon, 10 Mar 2003 08:00:35 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 622935D019; Mon, 10 Mar 2003 16:00:26 +0900 (JST) Message-Id: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> To: marcelo@it.uc3m.es Cc: nemo@nal.motlabs.com From: Thierry Ernst In-Reply-To: <1047208960.728.63.camel@presto.it.uc3m.es> References: <1047208960.728.63.camel@presto.it.uc3m.es> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: about draft-ietf-nemo-requirements-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 16:00:26 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Marcelo, Thank you for your comments. Reply below. > I have some comments/questions about draft-ietf-nemo-requirements-00.txt > > 1- About security features required to the basic solution and the > extended solution: > In section 4, General Purpose Guidelines... it is stated that "the > following issues have to be addressed" > > Question: shouldn't a MUST be included in the above statement? (i.e. > something like "the following security features MUST be provided") > > The issues included are: authentication, authorization, confidentiality, > and location privacy. > > Later, requirement 12 of section 5. One-liner req... states that the > basic solution MUST provide: authentication, authorization, anti-replay > and that encryption SHOULD be provided. Probably I didn't explain it enough, but section 4 lists a number of higher level requirements, not the actual requirements. That's why I entitled the section "guidelines" and not requirements. I mean, section 4 presents our "wishes". Location privacy is one of them. So, in section 4 I deliberately removed words "MUST" or "SHOULD" to keep it as open as possible. In section 5 are listed actual requirements which are derived from the conclusion of the discussions of the point listed under section 4. > Question: I find that the both sets of requirements do not completely > match. I mean, how is the location privacy requirement imposed to the > basic solution? is it included in the encryption requirement? if this is > so, why this is a SHOULD? Yes, and the reason why is "this is tricky". Since the basic solution is to set up a tunnel and no routing optimization, location privacy to the CN is enforced from a Mobility point of view: the MR's CoA will never be present in packets sent to the CN. But, from a general point of view, the permanent address still tells that the MNN is in the home network, which does not strickly speaking provide the MNN with full privacy. Does it ? e.g CN knows that my prefix p_car/60 belongs to network "home/48" but it doesn't that p_car/60 is now in network road/48. If you can draft us some words that would allow to explain this clearly, in a sentence, that would be welcome. > The other difference is about anti-replay protection requirement, that > it is not included in the general requirements but it is required for > the basic solution, shouldn't this be required for all the solutions? Because anti-replay is an actual means to guarantee an acceptable level of security. I would not focus too much attention on section 4, but rather on section 5. Is there anything else we need to include in section 5 ? > 2- About multi-homing support > > In section 5. One-liner req... it is stated that the solution MUST > function for multi-homed networks, more precisely: "R13.3: The solution > must support MR with multiple global addresses on an egress interface." > However, draft-ernst-nemo-terminology only includes the following cases: > - a MR has multiple egress interfaces on the same link, or > - a MR has multiple egress interfaces on distinct link, or > - there are more than one MR in the mobile network > > IMHO, the case where multiple global addresses are configured to a > mobile router egress interface should not be included. In this case, > the MR has only one attachment point to the Internet, so the mobile > network is not multi-homed. However, if the multiple addresses > configured to the egress interface of the MR have different global > prefixes (i.e. PA addresses that have been assigned by different > ISPs),this means that the home network is multi-homed, not that the > mobile network is multi-homed. In this case, it is my opinion that the > communication between the HA and the MRR can be established using any of > the global addresses available and using one or the other does not > present benefits for the communication between the HA and the MR. I > mean, if the communication fails using one address it will fail using > the other one, since they are configured to the same interface. The > difference between using one address or the other is related to which > ISP will be used when exiting the home network. However, this issue is > related to the multi-homing solution configured in the home network, and > not to the multi-homing solution of the mobile network. For these > reasons, IMO, the case of multiple addresses configured to a single > interface should not be considered, since it should be solved by the > multi-homing solution of the home network. Interesting observation. Probably I wrote this too quickly. Does anyone disagree with what Marcelo is saying right here ? > 3- Multi-homing capabilities. > > I haven't found any requirements about the capabilities of the mobile > network multi-homing solution. It is stated that the solution must > function for multi-homed mobile networks, but it is not specified what > benefits are expected. IMO a fault tolerance requirement should be > included. I mean, suppose that a mobile network has two MRs, and > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > communication between MR1 and the HA is unavailable). I would say that > all the connections that were being coursed through MR1 have to be > preserved during the outage meaning that they have to be re-routed > through the alternative MR, providing fault-tolerance capabilities. The > same case can be applied to the case of a MR with multiple interfaces > and one of them fails. Note that fault tolerance capabilities required > to the multi-homing solution of the mobile network are limited to the > communication between the MRs and the HA, and are not related to the > multi-homing capabilities of the solution of the home network. I'm not sure that the draft should mention the purpose of multihoming. If it did, it could only serve as an example; it's hard to envision today what all the benefit of multihoming could be. So, I don't think we should mention anything about fault tolerance (but I agree it's one of the benefit). Comments from other ? > 4- Other comments > - IMO, at least some basic RFCs could be included in the Backward > compatibility bullet in section 4. We didn't do this on purpose. What RFCs should be listed ? We cannot list all. If we list some, it might be assumed that a non-listed one is not to be backward compatible. But, if you consider it's important, we should extablish an exhaustive list of RFCs. Comments ? > - I guess that the scalability bullet of section 4 attempts to highlight > that scalability is important, but perhaps it is bit unspecific for a > MUST requirements , i mean, What is a large number of mobile networks? What would a number bring here ? The debate "large" vs "thousands" already occured. The purpose of this bullet is awareness that signalling should be minimised as much as possible. That's the reason why it is listed under section 4. > 5- Editorial > > Numbering of one-liner requirements from number 12 till the end. Thanks, someone already pointed this out. Sorry about that. Thanks for your interesting comments again, Marcelo. I hope I will be able to address your concerns clearly enough in the next revision of the draft. Thierry From nemo-admin@nal.motlabs.com Mon Mar 10 03:16:34 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17649 for ; Mon, 10 Mar 2003 03:16:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A8I391010278; Mon, 10 Mar 2003 09:18:03 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A8HU91010270 for ; Mon, 10 Mar 2003 09:17:31 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 8E2395D019; Mon, 10 Mar 2003 17:17:23 +0900 (JST) Message-Id: <20030310.171723.100266580.ernst@sfc.wide.ad.jp> To: Takeshi.Tanaka@yrp.mci.mei.co.jp Cc: cwng@psl.com.sg, nemo@nal.motlabs.com Subject: Re: [nemo] New draft on multihoming scenarios From: Thierry Ernst In-Reply-To: <20030306135918.5E01.TAKESHI.TANAKA@yrp.mci.mei.co.jp> References: <1046313298.1702.7.camel@beethoven> <20030306135918.5E01.TAKESHI.TANAKA@yrp.mci.mei.co.jp> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 17:17:23 +0900 (JST) Content-Transfer-Encoding: 7bit Hi, Thanks for posting this draft. I didn't have time to comment yet, but it is interesting work put on the table. > > http://www.psl.com.sg/draft-ng-nemo-multihoming-issues-00.txt > This draft describes 3 scenarios of multihomed NEMO; > - a MR with multiple egress interfaces bound to a single HA > - a MR with multiple egress interfaces bound to different HAs > - multiple MRs bound to different HAs > We are missing the scenario where multiple MRs bound to a single HA > which is described in draft-wakikawa-nemo-basic-00.txt > > These scenarios are based on the term draft; > > Multihomed Mobile Network > > From 3.4.1, a mobile network is multihomed when either: > > - a MR has multiple egress interfaces on the same link, or > > - a MR has multiple egress interfaces on distinct link, or > > - there are more than one MR in the mobile network > But does the second condition means 'multiple egress interfaces bound to > distinct home link' ? I think we never assumed anything (so far), so it could be either cases. May be you need to consider the two cases differently in your draft ? Thierry From nemo-admin@nal.motlabs.com Mon Mar 10 04:54:09 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05771 for ; Mon, 10 Mar 2003 04:54:08 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A9t5Hp012252; Mon, 10 Mar 2003 10:55:05 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2A9s3Hp012188 for ; Mon, 10 Mar 2003 10:54:05 +0100 Received: by jazz.mei.co.jp (8.12.8/3.7W/kings) with ESMTP id h2A9rrPp025249; Mon, 10 Mar 2003 18:53:53 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx1) with ESMTP id h2A9ru605361; Mon, 10 Mar 2003 18:53:56 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/astros) with ESMTP id h2A9rtb07454; Mon, 10 Mar 2003 18:53:55 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h2A9rtf12783; Mon, 10 Mar 2003 18:53:55 +0900 (JST) Received: from [133.183.212.174] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h2A9rsj03353; Mon, 10 Mar 2003 18:53:54 +0900 (JST) From: Takeshi TANAKA To: Thierry Ernst , IETF NEMO Subject: Re: [nemo] New draft on multihoming scenarios In-Reply-To: <20030310.171723.100266580.ernst@sfc.wide.ad.jp> References: <20030306135918.5E01.TAKESHI.TANAKA@yrp.mci.mei.co.jp> <20030310.171723.100266580.ernst@sfc.wide.ad.jp> Message-Id: <20030310184445.8C6C.TAKESHI.TANAKA@yrp.mci.mei.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 18:54:52 +0900 Content-Transfer-Encoding: 7bit On Mon, 10 Mar 2003 17:17:23 +0900 (JST) Thierry Ernst wrote : > Thanks for posting this draft. I didn't have time to comment yet, but > it is interesting work put on the table. > > > > http://www.psl.com.sg/draft-ng-nemo-multihoming-issues-00.txt > > This draft describes 3 scenarios of multihomed NEMO; > > - a MR with multiple egress interfaces bound to a single HA > > - a MR with multiple egress interfaces bound to different HAs > > - multiple MRs bound to different HAs > > We are missing the scenario where multiple MRs bound to a single HA > > which is described in draft-wakikawa-nemo-basic-00.txt > > > > These scenarios are based on the term draft; > > > Multihomed Mobile Network > > > From 3.4.1, a mobile network is multihomed when either: > > > - a MR has multiple egress interfaces on the same link, or > > > - a MR has multiple egress interfaces on distinct link, or > > > - there are more than one MR in the mobile network > > But does the second condition means 'multiple egress interfaces bound to > > distinct home link' ? > > I think we never assumed anything (so far), so it could be either > cases. May be you need to consider the two cases differently in your > draft ? Ok, that is my misunderstanding. The second requirements means the case like this, doesn't it?; || MR1 | ---+-?-- | || R MR2 | | --?-----?-- Actually, we didn't consider the case explicitly. The possible solution in the draft can provide MR1 alterative route if MR2 can obtain an address from MR1, but it is main point for the draft to provide a solution. Thank you for comments! ----------------------------------------------- Takeshi TANAKA R&D center, Corporate Engineering Division, Panasonic Mobile Communications e-mail: tanaka.takeshi-n@jp.panasonic.com phone: +81-46-840-5494 / fax: +81-46-840-5222 ----------------------------------------------- From nemo-admin@nal.motlabs.com Mon Mar 10 05:10:46 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08894 for ; Mon, 10 Mar 2003 05:10:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AAC3bf013257; Mon, 10 Mar 2003 11:12:03 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AABvbf013240; Mon, 10 Mar 2003 11:11:57 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AABui4013491; Mon, 10 Mar 2003 03:11:56 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id DAA02227; Mon, 10 Mar 2003 03:11:55 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2AA8T815084; Mon, 10 Mar 2003 04:08:29 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0AA852EC86; Mon, 10 Mar 2003 11:08:41 +0100 (CET) Message-ID: <3E6C6428.5060701@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Cc: , References: <1047248443.1481.118.camel@presto.it.uc3m.es> <20030310093043.9413.RYUJI@sfc.wide.ad.jp> In-Reply-To: <20030310093043.9413.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: sendmail v6 (was: about draft-wakikawa-nemo-basic-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 11:08:40 +0100 Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > # Some Requests to ML administrators # The SMTP server of NEMO WG > has the AAAA record, but SMTP server do not # speak IPv6. > Therefore, my SMTP server (IPv6 capable) fails to send email # to > NEMO ML. If the SMTP server finds AAAA record, it tries to connect > to the IPv6 # address first. and I got connection refused error. Is > it possible to # remove AAAA record or to update SMTP server to > support IPv6? # Thanks in advance. Hi, I understand that. My problem is how to make sendmail speak v6. Do you know about how to do it? I've configured sendmail.cf to have this line: O DaemonPortOptions=Family=inet6, Addr=2002:c3d4:6ffd:1:201:2ff:fe6c:eff8 Do you think that is enough? I can not turn the AAAA entry off at this point because I want jessica's http server to be reachable in IPv6 now... -- Message Classification: GBU From nemo-admin@nal.motlabs.com Mon Mar 10 05:14:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09594 for ; Mon, 10 Mar 2003 05:14:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AAG2bf013298; Mon, 10 Mar 2003 11:16:02 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AAA0bf013208 for ; Mon, 10 Mar 2003 11:10:01 +0100 Received: by jazz.mei.co.jp (8.12.8/3.7W/bulls) with ESMTP id h2AA9YUM004035; Mon, 10 Mar 2003 19:09:34 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id h2AA9aQ28048; Mon, 10 Mar 2003 19:09:36 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id h2AA9YX15777; Mon, 10 Mar 2003 19:09:34 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h2AA9Yf15956; Mon, 10 Mar 2003 19:09:34 +0900 (JST) Received: from [133.183.212.174] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h2AA9Yj04132; Mon, 10 Mar 2003 19:09:34 +0900 (JST) From: Takeshi TANAKA To: Thierry Ernst , IETF NEMO , marcelo bagnulo Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt In-Reply-To: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> Message-Id: <20030310171021.8C66.TANAKA.TAKESHI-N@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Mailer: Becky! ver. 2.05.06 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2AAA0bf013208 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 19:10:31 +0900 Content-Transfer-Encoding: 8bit Hi Therry and Marcelo, On Mon, 10 Mar 2003 16:00:26 +0900 (JST) Thierry Ernst wrote : ... > > 2- About multi-homing support > > > > In section 5. One-liner req... it is stated that the solution MUST > > function for multi-homed networks, more precisely: "R13.3: The solution > > must support MR with multiple global addresses on an egress interface." > > However, draft-ernst-nemo-terminology only includes the following cases: > > - a MR has multiple egress interfaces on the same link, or > > - a MR has multiple egress interfaces on distinct link, or > > - there are more than one MR in the mobile network > > > > IMHO, the case where multiple global addresses are configured to a > > mobile router egress interface should not be included. In this case, > > the MR has only one attachment point to the Internet, so the mobile > > network is not multi-homed. However, if the multiple addresses > > configured to the egress interface of the MR have different global > > prefixes (i.e. PA addresses that have been assigned by different > > ISPs),this means that the home network is multi-homed, not that the > > mobile network is multi-homed. In this case, it is my opinion that the > > communication between the HA and the MRR can be established using any of > > the global addresses available and using one or the other does not > > present benefits for the communication between the HA and the MR. I > > mean, if the communication fails using one address it will fail using > > the other one, since they are configured to the same interface. The > > difference between using one address or the other is related to which > > ISP will be used when exiting the home network. However, this issue is > > related to the multi-homing solution configured in the home network, and > > not to the multi-homing solution of the mobile network. For these > > reasons, IMO, the case of multiple addresses configured to a single > > interface should not be considered, since it should be solved by the > > multi-homing solution of the home network. > > Interesting observation. Probably I wrote this too quickly. Does > anyone disagree with what Marcelo is saying right here ? I understand. That is the case where home link is multihomed and not specific to NEMO, isn't that? > > 3- Multi-homing capabilities. > > > > I haven't found any requirements about the capabilities of the mobile > > network multi-homing solution. It is stated that the solution must > > function for multi-homed mobile networks, but it is not specified what > > benefits are expected. IMO a fault tolerance requirement should be > > included. I mean, suppose that a mobile network has two MRs, and > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > communication between MR1 and the HA is unavailable). I would say that > > all the connections that were being coursed through MR1 have to be > > preserved during the outage meaning that they have to be re-routed > > through the alternative MR, providing fault-tolerance capabilities. The > > same case can be applied to the case of a MR with multiple interfaces > > and one of them fails. > > Note that fault tolerance capabilities required > > to the multi-homing solution of the mobile network are limited to the > > communication between the MRs and the HA, and are not related to the > > multi-homing capabilities of the solution of the home network. > I'm not sure that the draft should mention the purpose of > multihoming. If it did, it could only serve as an example; it's hard > to envision today what all the benefit of multihoming could be. So, I > don't think we should mention anything about fault tolerance (but I > agree it's one of the benefit). > > Comments from other ? I think some NEMO specific capability are required for multihoming NEMO to get fault tolerance from multihoming. For example, the mechanism he mentioned is not included in the current (experimental) multi-homing difinition; > all the connections that were being coursed through MR1 have to be > preserved during the outage meaning that they have to be re-routed > through the alternative MR, A router on a multi-homed link does not preserve connection that were being coursed through it if egress link of the router is disconnected. So I think fault tolerance should be described in the draft somehow as one of the benefits if the basic solution will provide a mechanism to get the benefit, but other people may think different. Regards, Takeshi From nemo-admin@nal.motlabs.com Mon Mar 10 05:21:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10851 for ; Mon, 10 Mar 2003 05:21:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AAN3bf013394; Mon, 10 Mar 2003 11:23:03 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AAM6bf013380 for ; Mon, 10 Mar 2003 11:22:07 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2AAMxn7010102 for ; Mon, 10 Mar 2003 03:22:59 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id DAA06497 for ; Mon, 10 Mar 2003 03:22:05 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h2AAJh027073 for ; Mon, 10 Mar 2003 04:19:44 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8B1D12EC86 for ; Mon, 10 Mar 2003 11:18:51 +0100 (CET) Message-ID: <3E6C668B.8050100@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Subject: Re: [nemo] Re: sendmail v6 (was: about draft-wakikawa-nemo-basic-00.txt) References: <1047248443.1481.118.camel@presto.it.uc3m.es> <20030310093043.9413.RYUJI@sfc.wide.ad.jp> <3E6C6428.5060701@nal.motlabs.com> In-Reply-To: <3E6C6428.5060701@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 11:18:51 +0100 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Ryuji Wakikawa wrote: > >> # Some Requests to ML administrators > sendmail Ah, sorry for cc'ing the list. From nemo-admin@nal.motlabs.com Mon Mar 10 07:47:09 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07778 for ; Mon, 10 Mar 2003 07:47:07 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AClSbf015986; Mon, 10 Mar 2003 13:47:28 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ACk4bf015962 for ; Mon, 10 Mar 2003 13:46:05 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2ACjti4014603; Mon, 10 Mar 2003 05:45:56 -0700 (MST) Received: [from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id FAA07089; Mon, 10 Mar 2003 05:43:57 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2ACjc806629; Mon, 10 Mar 2003 06:45:38 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D63602EC8B; Mon, 10 Mar 2003 13:45:49 +0100 (CET) Message-ID: <3E6C88FD.1080407@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: , References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> In-Reply-To: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: location privacy (was: Re: about draft-ietf-nemo-requirements-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 13:45:49 +0100 Content-Transfer-Encoding: 7bit Salut Thierry, Thierry Ernst wrote: > I mean, section 4 presents our "wishes". Location privacy is one of > them. I think it is good to say that location privacy is one wish, but I also think that we should detail more what kind of location privacy we want. And also see whether Mobile IPv6 will probably provide an inherent location privacy and so no need to develop new location privacy in NEMO. > Since the basic solution is to set up a tunnel and no routing > optimization, location privacy to the CN is enforced from a > Mobility point of view: the MR's CoA will never be present in > packets sent to the CN. Yes, exactly. > But, from a general point of view, the permanent address still > tells that the MNN is in the home network, which does not strickly > speaking provide the MNN with full privacy. Does it ? > > e.g CN knows that my prefix p_car/60 belongs to network "home/48" > but it doesn't that p_car/60 is now in network road/48. Yes, exactly. So do you think we should worry about CN knowing that p_car/60 belongs to network home/48? > If you can draft us some words that would allow to explain this > clearly, in a sentence, that would be welcome. I think that text should clearly answer this: -is Mobile IPv6 going to provide location privacy to MR? If yes, how will NEMO use it? -what entity tries to hide its location, is it MR? Is it LFN? -what is the "location" information that that entity tries to hide? Is it an address? Is it a prefix? Is it a corelation HoA-CoA? -what is the entity that must not get knowledge of that location information? Is it CN? Is it HA? Is it an attacker listening? For example, I've seen the following description: attackers that might intercept packets containing both HoA and CoA, so attacker can know that that HoA is at that CoA. In this specific case, the entity trying to hide its location is MH, the information to hide is both HoA and CoA and the attacker is someone intercepting packets (not necessarily CN). What you seem to describe above is: entity hiding its location is MR, location info to be protected is the corelation (MR's prefix - MR's home prefix) and the attacker is CN. -- Message Classification: GBU From nemo-admin@nal.motlabs.com Mon Mar 10 10:10:38 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28503 for ; Mon, 10 Mar 2003 10:10:36 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AFBCbf018091; Mon, 10 Mar 2003 16:11:13 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AFAcbf018080; Mon, 10 Mar 2003 16:10:39 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 65B7F431CF; Mon, 10 Mar 2003 16:10:32 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 8D8D199E14; Mon, 10 Mar 2003 16:10:29 +0100 (CET) Subject: Re: [nemo] Re: location privacy (was: Re: about draft-ietf-nemo-requirements-00.txt) From: marcelo bagnulo To: Alexandru Petrescu Cc: Thierry Ernst , nemo@nal.motlabs.com In-Reply-To: <3E6C88FD.1080407@nal.motlabs.com> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047309028.995.388.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 10 Mar 2003 16:10:28 +0100 Content-Transfer-Encoding: 7bit Hi Alexander, Thierry Really interesting comments, and also unexpected. When i read the draft, my interpretation of location privacy was that the MR wanted to hide its location from an unauthorized listener in the path between the HA and the MR. As you see it is really different from what Thierry meant. I think that the approach proposed by Alexander is very good. Let's try to answer these questions. I think we should change the order, though :-) I guess that we could start by clarifying who is not supposed to know the location of the MR. So, I would say that location privacy capabilities prevent unauthorized parties to have knowledge about the actual location of a mobile network. Since a mobile network is permanently identified by the mobile network prefix and/or its MR Home Address, and the mobile network current location is identified by the CoA assigned to the MR, location privacy is obtained by avoiding the disclosure of the information about the current binding between the mobile prefix (and/or the MR HoA) and MR CoA. Potential unauthorized parties include the CNs of communications maintained by the MNNs and any other party along the communication path between the MNN and the CN that can eavesdrop the communication. In the basic solution, CN is never aware of the current location of the MNN since all traffic is coursed through the HA which is fixed in the home network. The only location privacy concerns remaining refer to the eavesdroping of packets exchanged by the HA and the MR. A mobile network solution should provide the functions needed to conceal location information contained in these packets. This requirement is included in the requirement R13.4. In the extended solution, MNNs are capable to interact directly with CNs without including the HA in the communication, exposing its location to the CN. However, the usage of route optimization should always be the MNN choice. In this case, unknown CN always reach the MNN through the HA, using the MNN permanent address. Once the communication is in place and that the MNN is aware of the CN, the MNN may choose to make use of the Route Optimization capabilities provided by the extended solution. In this case, the MNN is benefiting from more optimal path but it is also disclosing its location to the CN. Other location privacy concerns refer to the disclosure of location information to eavesdroppers along the communication path. As long that the communication flows through the HA, the basic scenario applies. In the case that RO is being used, the conceal of location information implies the usage of encryption between the MNN and the CN. I do not know if we want to go there. I have tried to summarize the previous exchange, do you think this is it? Regards, marcelo On Mon, 2003-03-10 at 13:45, Alexandru Petrescu wrote: > Salut Thierry, > > Thierry Ernst wrote: > > I mean, section 4 presents our "wishes". Location privacy is one of > > them. > > I think it is good to say that location privacy is one wish, but I > also think that we should detail more what kind of location privacy we > want. And also see whether Mobile IPv6 will probably provide an > inherent location privacy and so no need to develop new location > privacy in NEMO. > > > Since the basic solution is to set up a tunnel and no routing > > optimization, location privacy to the CN is enforced from a > > Mobility point of view: the MR's CoA will never be present in > > packets sent to the CN. > > Yes, exactly. > > > But, from a general point of view, the permanent address still > > tells that the MNN is in the home network, which does not strickly > > speaking provide the MNN with full privacy. Does it ? > > > > e.g CN knows that my prefix p_car/60 belongs to network "home/48" > > but it doesn't that p_car/60 is now in network road/48. > > Yes, exactly. So do you think we should worry about CN knowing that > p_car/60 belongs to network home/48? > > > If you can draft us some words that would allow to explain this > > clearly, in a sentence, that would be welcome. > > I think that text should clearly answer this: > -is Mobile IPv6 going to provide location privacy to MR? If yes, how > will NEMO use it? > -what entity tries to hide its location, is it MR? Is it LFN? > -what is the "location" information that that entity tries to hide? > Is it an address? Is it a prefix? Is it a corelation HoA-CoA? > -what is the entity that must not get knowledge of that location > information? Is it CN? Is it HA? Is it an attacker listening? > > For example, I've seen the following description: attackers that might > intercept packets containing both HoA and CoA, so attacker can know > that that HoA is at that CoA. In this specific case, the entity > trying to hide its location is MH, the information to hide is both HoA > and CoA and the attacker is someone intercepting packets (not > necessarily CN). > > What you seem to describe above is: entity hiding its location is MR, > location info to be protected is the corelation (MR's prefix - MR's > home prefix) and the attacker is CN. -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Mon Mar 10 10:30:28 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29289 for ; Mon, 10 Mar 2003 10:30:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AFW3bf018207; Mon, 10 Mar 2003 16:32:03 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AFV8bf018197 for ; Mon, 10 Mar 2003 16:31:09 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 5F033431BC; Mon, 10 Mar 2003 16:31:03 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 1D6EA99E6C; Mon, 10 Mar 2003 16:31:00 +0100 (CET) Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Takeshi TANAKA Cc: Thierry Ernst , IETF NEMO In-Reply-To: <20030310171021.8C66.TANAKA.TAKESHI-N@jp.panasonic.com> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <20030310171021.8C66.TANAKA.TAKESHI-N@jp.panasonic.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047310258.995.416.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 10 Mar 2003 16:30:58 +0100 Content-Transfer-Encoding: 7bit Hi Takeshi, > I understand. That is the case where home link is multihomed and not > specific to NEMO, isn't that? > If a site has multiple provider and PA addressing is used, nodes within the multi-homed site will obtain multiple addresses per interface in order to be reachable through the multiple providers. So if the home network of a mobile network is multi-homed it is possible that MNN will have multiple addresses per interface associated to the multiple providers. However this is not a NEMO specific issue, and in this case, the mobile network is not multi-homed, but its home network is. So i think this case should not be considered in the NEMO solution space. > > > 3- Multi-homing capabilities. > > > > > > I haven't found any requirements about the capabilities of the mobile > > > network multi-homing solution. It is stated that the solution must > > > function for multi-homed mobile networks, but it is not specified what > > > benefits are expected. IMO a fault tolerance requirement should be > > > included. I mean, suppose that a mobile network has two MRs, and > > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > > communication between MR1 and the HA is unavailable). I would say that > > > all the connections that were being coursed through MR1 have to be > > > preserved during the outage meaning that they have to be re-routed > > > through the alternative MR, providing fault-tolerance capabilities. The > > > same case can be applied to the case of a MR with multiple interfaces > > > and one of them fails. > > > > Note that fault tolerance capabilities required > > > to the multi-homing solution of the mobile network are limited to the > > > communication between the MRs and the HA, and are not related to the > > > multi-homing capabilities of the solution of the home network. > > I'm not sure that the draft should mention the purpose of > > multihoming. If it did, it could only serve as an example; it's hard > > to envision today what all the benefit of multihoming could be. So, I > > don't think we should mention anything about fault tolerance (but I > > agree it's one of the benefit). > > > > Comments from other ? > I think some NEMO specific capability are required for multihoming NEMO > to get fault tolerance from multihoming. For example, the mechanism he > mentioned is not included in the current (experimental) multi-homing > difinition; > > all the connections that were being coursed through MR1 have to be > > preserved during the outage meaning that they have to be re-routed > > through the alternative MR, > A router on a multi-homed link Sorry what do you mean by multi-homed link? Regards, marcelo > does not preserve connection that were > being coursed through it if egress link of the router is disconnected. > > So I think fault tolerance should be described in the draft somehow as > one of the benefits if the basic solution will provide a mechanism to > get the benefit, but other people may think different. > > Regards, > Takeshi -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Mon Mar 10 10:46:44 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29902 for ; Mon, 10 Mar 2003 10:46:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AFm3bf018278; Mon, 10 Mar 2003 16:48:03 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AFlUbf018269 for ; Mon, 10 Mar 2003 16:47:31 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id BB5F2431F6; Mon, 10 Mar 2003 16:47:25 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 5A22599E6C; Mon, 10 Mar 2003 16:47:25 +0100 (CET) Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Thierry Ernst Cc: nemo@nal.motlabs.com In-Reply-To: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: uc3m Message-Id: <1047311243.995.435.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 10 Mar 2003 16:47:24 +0100 Content-Transfer-Encoding: 7bit Hello Thierry, Thanks for your reply, some more comments below... > Probably I didn't explain it enough, but section 4 lists a number of > higher level requirements, not the actual requirements. That's why I > entitled the section "guidelines" and not requirements. I mean, > section 4 presents our "wishes". Location privacy is one of them. So, > in section 4 I deliberately removed words "MUST" or "SHOULD" to keep > it as open as possible. So, MUST and SHOULDS of the section 4 will be removed? I think that the set of guidelines it is OK and they have to be considered when evaluating a solution, specially for the extended solution. Probably changing to lower case must and shoulds it's a good idea. > > In section 5 are listed actual requirements which are derived from the > conclusion of the discussions of the point listed under section 4. > > > > Question: I find that the both sets of requirements do not completely > > match. I mean, how is the location privacy requirement imposed to the > > basic solution? is it included in the encryption requirement? if this is > > so, why this is a SHOULD? > > Yes, and the reason why is "this is tricky". It is clear now, i follow this in the privacy location thread. [...] > > > The other difference is about anti-replay protection requirement, that > > it is not included in the general requirements but it is required for > > the basic solution, shouldn't this be required for all the solutions? > > Because anti-replay is an actual means to guarantee an acceptable > level of security. > > I would not focus too much attention on section 4, but rather on > section 5. Is there anything else we need to include in section 5 ? > > > 3- Multi-homing capabilities. > > > > I haven't found any requirements about the capabilities of the mobile > > network multi-homing solution. It is stated that the solution must > > function for multi-homed mobile networks, but it is not specified what > > benefits are expected. IMO a fault tolerance requirement should be > > included. I mean, suppose that a mobile network has two MRs, and > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > communication between MR1 and the HA is unavailable). I would say that > > all the connections that were being coursed through MR1 have to be > > preserved during the outage meaning that they have to be re-routed > > through the alternative MR, providing fault-tolerance capabilities. The > > same case can be applied to the case of a MR with multiple interfaces > > and one of them fails. Note that fault tolerance capabilities required > > to the multi-homing solution of the mobile network are limited to the > > communication between the MRs and the HA, and are not related to the > > multi-homing capabilities of the solution of the home network. > > I'm not sure that the draft should mention the purpose of > multihoming. If it did, it could only serve as an example; it's hard > to envision today what all the benefit of multihoming could be. So, I > don't think we should mention anything about fault tolerance (but I > agree it's one of the benefit). > If no specific benefit is obtained through multi-homing, what does it means that the solution MUST function with multi-homed networks? I guess that at least we are expecting that if multiple routers exist, all can be used to course traffic, for instance. I would say that it is also expected that if one router fails, new communications are established using the alternative one which is available. We could also discuss about established communications preservation. I mean, some basic benefits could be included in the section 4 at least as guidelines of what is expected from multi-homing solutions. > Comments from other ? > > > 4- Other comments > > - IMO, at least some basic RFCs could be included in the Backward > > compatibility bullet in section 4. > > We didn't do this on purpose. What RFCs should be listed ? We cannot > list all. If we list some, it might be assumed that a non-listed one > is not to be backward compatible. > > But, if you consider it's important, we should extablish an exhaustive > list of RFCs. I see your point. BTW, FMIPv6 is still an ID, is it ok to include it in here? > > Comments ? > > > - I guess that the scalability bullet of section 4 attempts to highlight > > that scalability is important, but perhaps it is bit unspecific for a > > MUST requirements , i mean, What is a large number of mobile networks? > > What would a number bring here ? The debate "large" vs "thousands" > already occured. The purpose of this bullet is awareness that > signalling should be minimised as much as possible. Perhaps rephrasing it this way may be clearer, but if you already discussed this, i do not want to reopen the discussion anyway. Thanks, marcelo > That's the reason > why it is listed under section 4. > > > 5- Editorial > > > > Numbering of one-liner requirements from number 12 till the end. > > Thanks, someone already pointed this out. Sorry about that. > > > Thanks for your interesting comments again, Marcelo. I hope I will be > able to address your concerns clearly enough in the next revision of > the draft. > > Thierry -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Mon Mar 10 11:00:36 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00394 for ; Mon, 10 Mar 2003 11:00:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AG23bf018358; Mon, 10 Mar 2003 17:02:03 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AG1gbf018350 for ; Mon, 10 Mar 2003 17:01:43 +0100 Received: from [203.178.143.62] (luna.sfc.wide.ad.jp [203.178.143.62]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id h2A0UD6m013446; Mon, 10 Mar 2003 09:30:14 +0900 From: Ryuji Wakikawa To: marcelo bagnulo Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt Cc: nemo@nal.motlabs.com In-Reply-To: <1047248443.1481.118.camel@presto.it.uc3m.es> References: <1047248443.1481.118.camel@presto.it.uc3m.es> Message-Id: <20030310075940.9410.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 09:30:19 +0900 Content-Transfer-Encoding: 7bit Hello Marcelo > I have found the draft to be a really interesting reading and I would > like to make some comments about it. Thanks! > My first comment is about the new prefix sub-option. If i understood it > correctly, this new sub-option replaces the original PSBU. The benefits > are clear, less overhead since the prefix is not included. However,IMO > this optimization also presents some drawbacks that should be considered > in order to evaluate the trade-off that its adoption implies.IMO, Since > the prefix is implicit in the MR-A carried in the BU message, the prefix > sub-option is less flexible than the original PSBU. In the case that the > mobile network is composed by a single subnet with only one prefix, both > options are equivalent. However, when the mobile network is composed by > multiple subnetworks, the usage of the prefix sub-option imposes > additional conditions on the address range assigned to the subnets that > compose the mobile network, since they must all obtain their address > range from an aggregate that have to be susceptible to be expressed as a > prefix of the MR-A. This imposes multiple constraints. First of all, it > constraints the way addresses are assigned, i.e. the address > administration within the home network. This, at least is an additional > burden to address administrators. Additionally, this constraint may > impose address lost. For example, suppose that the mobile network is > composed by three subnetworks: Pref:0::/48, Pref:1::/48 and Pref:2::/48. > In this case, if i understand this correctly, the prefix sub-option > would indicate a 47 bits long prefix, imposing the waste of the > Pref:3::/48. The first motivation of this prefix-suboption is optimization as you've notice already:) But, there are other reasons for this now. When a MR has multiple prefixes, the MR acquires multiple MR-A at the ingress interface. The MR have to send BU individually for each mobile prefix. This is because current MIP6 does not allow to update multiple binding caches by sending "single" BU (i.e. no optimization for this). Since the assignment of multiple mobile network prefixes is equal to the assignment of multiple home addresses on Mobile IPv6. I am not sure if it is possible to allow this optimization only for NEMO. There will be another issues if NEMO allows this optimization. PSBU allows to carry prefix and its length in BU, but the prefix stored in the suboption of BU is not secured and authorized. MIP6 security scheme only verify MR's home address, but not prefix itself. Our approach provides these verification by using IPsec encryption. SA is established between MR and HA by using MR-A (MR-A is used as the key of encryption), mobile network prefix is verified. I think this approach is well compliant with current MIP6 spec. Instead, PSBU store all the prefix information in the BU. PSBU needs another way to verify this prefix and also way to notify mapping of home address and mobile network prefixes. Your last scenario is a kinds of administrative issue. MR may sends BU w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length. In fact, I did not mention the situation when MR has multiple mobile network prefixes in the draft. I will add some texts at the next version. Thanks for pointing this out. > Additionally, its impact in the case of nested networks should be also > considered, since it imposes similar constraints to address > administration. My concern is whether the reduction of 64 bits in the BU > messages is worth these additional costs. Optimization is important, but I tried to keep compliance with current MIPv6 spec, because MIPv6 is fully discussed at the IETF and is very "sensitive" protocol indeed. If I added a lot of optimizations for NEMO, many new issues come up. Furthermore, NEMO has many kinds of configuration compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to provide a certain level of optimization by means of "network operation". (e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix length) > Moreover, it assumed that the HA is aware of the prefix that this > particular MR is authorized to announce, because of security reasons. > So, why is not enough with the N bit only? I mean, the MR sends a BU > with the N bit set, and the HA already knows which prefix of the mobile > network (implicit signaling). If i understand the rationale correctly, > when PSBU are used, it is useful since the mobile network can have > multiple prefixes, and the BU can refer to only some of them. If the > prefix sub-option is used, this feature is more restricted since only > aggregates containing the MR-A can be announced. I do not know if i am > missing something, but IMO much flexibility is lost when replacing PSBU > by prefix suboption. For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64 at the beginning. Then the MR sends BU w/ 64 prefix length instead of 48. Of course, this prefix is belong to the MR, HA can accept BU and intercepts and tunnels packets only for the prefix/64. For these operation, the prefix-suboption is needed. > > My second comment is about the location of the HA. I think that it is > assumed that the HA is co-located with the only router present in the > home-link. I could not find this assumption in the draft, but it is > illustrated in the figure. This assumption is reflected in the behavior > described in section 6.2.2 where it is assumed that all incoming packets > pass through the HA. Is there any reason for this restriction? I think > that the case where multiple routers are present in the home link is a > reasonable case, and it can be easily supported, for instance by means > of redirect from the HA pointing to the alternative router. > Additionally, i think that, as i think it is suggested in > draft-petrescu-nemo-mrha-02, the solution should support that the HA is > a single interface node. I think that the solution can be extended to > support this configurations. Good point, I did not mention this case enough. Delegated prefix is assigned to MR, and HA only advertises the prefix by routing protocol. "Routing protocol" means both IGP and BGP. If there are multiple routers at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in the home link. HA do not send RA of the delegated prefix at the home link, so that it becomes next hop router of the delegated prefix. (Other routers are not on-link of the mobile network prefix). Multiple HAs for single mobile network prefix is not considered yet in the draft. Although current MIP6 does not allow to register same binding to multiple HAs, I have rough solution for this. But I have to consider more before putting texts in the draft, because there are many issues for multiple HAs, how MR selects HA, how HAs manage same mobile network prefix at the home link, how to avoid inconsistency of binding for same prefix among HAs due to some accidents of MR for example. > Additional comments: > > IPSec processing is included in section 5.2.2 and 6.1.1 but it is not > described in section 5.2.1. Perhaps it would be clarifying to include > it. Thanks, I will fix this. > I think that section 6.3 should include the location of the MR (home > link or not) among the rules to decide whether HA has to tunnel or not > packets to the MR. Right. I did not notice this. I will fix this, too. > The fact that the authorization of which prefixes can be announced by a > MR is performed by configuring them in the HA is somehow included in > different sections in the draft but perhaps it would be relevant to > explicitly mention it in the security consideration section. We give the assumption for the prefix assignment and configuration at this moment. I am just wondering whether I should use DHCP prefix delegation for this protocol or not, now. I will think about this more. Thank you for your comments! regards, ryuji From nemo-admin@nal.motlabs.com Mon Mar 10 11:12:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00971 for ; Mon, 10 Mar 2003 11:12:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AGD6bf018441; Mon, 10 Mar 2003 17:13:06 +0100 Received: from eccles.ee.ryerson.ca (eccles.ee.ryerson.ca [141.117.1.2]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AGCrbf018429 for ; Mon, 10 Mar 2003 17:12:56 +0100 Received: from ee.ryerson.ca ([172.16.30.72]) by eccles.ee.ryerson.ca (8.12.8/8.12.8) with ESMTP id h2AGCk9o079257 for ; Mon, 10 Mar 2003 11:12:46 -0500 (EST) (envelope-from jaseem@ee.ryerson.ca) Message-ID: <3E6CB97E.9060700@ee.ryerson.ca> From: Muhammad Jaseemuddin Organization: Ryerson University User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: nemo@nal.motlabs.com References: <3E6189EF.6050209@ee.ryerson.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] CFP: IEEE VTC Symposium on IP Mobility -- Deadline Extended to March 24 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 11:12:46 -0500 Content-Transfer-Encoding: 7bit Call for Papers - IP Mobility 2003 IEEE VTC Symposium on IP Mobility October 4-9, 2003 Orlando, FL, USA in Conjunction with IEEE VTC Fall 2003 Submission Deadline Extended: March 24, 2003 Scope ===== Mobility support in IP network has been an area of active research and development. The impacts of mobility and wireless medium at all layers of Internet architecture have generated wide range of interest in the research community. IETF has been working on standardizing protocols for inter-domain and intra-domain mobility, context transfer, routing for network mobility and ad-hoc networks. This symposium is aimed at providing researchers and practitioners a forum for presenting their research at all layers of Internet architecture and sharing experiences. It will provide a unique opportunity to people from academia and industry to exchange their ideas on short-term and long-term research issues. The outcome of the symposium is expected to present a view on how close to reality is IP Mobility and set a direction for research to deal with emerging issues. The papers must discuss issues and solutions related to support for wireless medium and mobility in IP network. The symposium solicits papers related to but not limited to the following areas: * Routing for host (e.g. terminals) and network (e.g. trains, buses) mobility, protocols and performance * New approaches to wide-area and local mobility * Quality of Service models, resource management, and provisioning * Traffic Engineering in mobile wireless IP access networks * Transport protocol design for mobile wireless networks * Security including security threat models, threat analysis and their impact on routing * Application level protocol design and performance * Mobile and wireless applications, their service requirements and performance * Content delivery support in IP network for mobile users * Multicasting for mobile wireless services * Emerging network architectures (e.g. multi-hop ad-hoc network, sensor network) * Internetworking of different network types (e.g. ad-hoc to cellular, wireless LAN to cellular) * Inter-vehicular network architecture * Mobile wireless IP access network deployment and management Posters are also solicited on the projects related to **Support for Network Mobility**. Submission Instructions ======================= Authors MUST submit an extended abstract (up to 2 pages) through the EDAS web site (http://www.edas.info/), together with a short abstract (approximately 150 words) in the EDAS web site form. Please note that the potential authors should create their own accounts in the EDAS web site (http://www.edas.info/) before submitting paper(s). Although either MS Word or PDF file format is acceptable when submitting the extended abstracts, it is strongly suggested that authors should submit papers using PDF format. The submission(s) should include complete contacting information of the author(s), such as the name, mailing address, telephone and fax numbers, and email address. All submitted papers are subject to peer review. Submissions can also be made using the links of call for technical papers in the conference web site: http://www.vtc2003.org/. Important Dates Extended Abstract Due: March 24, 2003 Acceptance Notification: May 15, 2003 Camera Ready Copy of Full Paper Due: July 15, 2003 Symposium Date: October 4, 2003 Organization ============ Program Co-Chairs: Muhammad Jaseemuddin (jaseem@ee.ryerson.ca) Department of Electrical and Computer Engineering Ryerson University Toronto, Canada Hongyi Li (hyli@nortelnetworks.com) Wireless Technology Lab Nortel Networks Ottawa, Canada Publicity Co-Chair: Junaid Zubairi (junaid.zubairi@fredonia.edu) Department of Mathematics and Computer Science SUNY at Fredonia Fredonia, NY, USA Technical Program Committee =========================== * Ahmed Helmy (U of Southern California, USA) * Abdelsalam Helal (U of Florida, Gainesville, USA) * Alan O'Neill (Flarion Technologies, USA) * Behcet Sarikaya (Alcatel, USA) * Christophe Janneteau (Motorola, France) * Govindan Ravindran (Soma Networks, Canada) * Haseeb Akhtar (inCode Telecom group, USA) * Hany Elgebaly (Intel Corporation, USA) * Hesham Soliman (Ericsson, Sweden) * Lars Wolf (TU Braunschweig, Germany) * Michael Wolf (Daimler-Chrysler, Germany) * Raouf Boutaba (U of Waterloo, Canada) * Sajal Das (The U of Texas at Arlington, USA) * Samir R. Das (SUNY at Stony Brook, USA) * Thiery Ernst (Wide, Keio U, Japan) * Thomas Noel (U of Strasbourg, France) * Yasser Rasheed (Intel Corporation, USA) From nemo-admin@nal.motlabs.com Mon Mar 10 11:24:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01500 for ; Mon, 10 Mar 2003 11:24:14 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AGP4bf018580; Mon, 10 Mar 2003 17:25:04 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AGOabf018570 for ; Mon, 10 Mar 2003 17:24:39 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id BD9754321B; Mon, 10 Mar 2003 17:24:29 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id D9A9B99E73; Mon, 10 Mar 2003 17:24:27 +0100 (CET) Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt From: marcelo bagnulo To: Ryuji Wakikawa Cc: nemo@nal.motlabs.com In-Reply-To: <20030310075940.9410.RYUJI@sfc.wide.ad.jp> References: <1047248443.1481.118.camel@presto.it.uc3m.es> <20030310075940.9410.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain Organization: uc3m Message-Id: <1047313466.996.478.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 10 Mar 2003 17:24:26 +0100 Content-Transfer-Encoding: 7bit Hello Ryuji, On Mon, 2003-03-10 at 01:30, Ryuji Wakikawa wrote: > Hello Marcelo > > > > I have found the draft to be a really interesting reading and I would > > like to make some comments about it. > > Thanks! > > > My first comment is about the new prefix sub-option. If i understood it > > correctly, this new sub-option replaces the original PSBU. The benefits > > are clear, less overhead since the prefix is not included. However,IMO > > this optimization also presents some drawbacks that should be considered > > in order to evaluate the trade-off that its adoption implies.IMO, Since > > the prefix is implicit in the MR-A carried in the BU message, the prefix > > sub-option is less flexible than the original PSBU. In the case that the > > mobile network is composed by a single subnet with only one prefix, both > > options are equivalent. However, when the mobile network is composed by > > multiple subnetworks, the usage of the prefix sub-option imposes > > additional conditions on the address range assigned to the subnets that > > compose the mobile network, since they must all obtain their address > > range from an aggregate that have to be susceptible to be expressed as a > > prefix of the MR-A. This imposes multiple constraints. First of all, it > > constraints the way addresses are assigned, i.e. the address > > administration within the home network. This, at least is an additional > > burden to address administrators. Additionally, this constraint may > > impose address lost. For example, suppose that the mobile network is > > composed by three subnetworks: Pref:0::/48, Pref:1::/48 and Pref:2::/48. > > In this case, if i understand this correctly, the prefix sub-option > > would indicate a 47 bits long prefix, imposing the waste of the > > Pref:3::/48. > > The first motivation of this prefix-suboption is optimization as you've > notice already:) > But, there are other reasons for this now. > > When a MR has multiple prefixes, the MR acquires multiple MR-A at the > ingress interface. The MR have to send BU individually for each mobile > prefix. This is because current MIP6 does not allow to update multiple > binding caches by sending "single" BU (i.e. no optimization for this). Ok. But what happens if the router's interface is not connected to the network that contains the assigned prefix? I mean, more than one segment may exist within a mobile network and the MR do not have to have an interface in each of them. For example, the below configuration: +--+ |MR| +--+ | Pref1::/48 ---------------- | +--+ |R | +--+ | Pref2::/48 ----------------- If i understand correctly, you are proposing that MR ingress interface has two addresses configured i.e. Pref1:Router and Pref2:Router Now when the MR wants to send a packet addressed to Pref2, it will assume it is directly connected if no additional configuration is made, the same goes for R when trying to reach MR through the Pref2:Router address. How do deal with this? > Since the assignment of multiple mobile network prefixes is equal to > the assignment of multiple home addresses on Mobile IPv6. I am not sure > if it is possible to allow this optimization only for NEMO. There will > be another issues if NEMO allows this optimization. > > PSBU allows to carry prefix and its length in BU, but the prefix stored > in the suboption of BU is not secured Isn't it possible to secure it with IPSec? > and authorized. If i understand correctly, in both cases authorization is achieved through proper configuration of the HA. I mean, the HA knows which prefixes are assigned to each MR and the HA can securely communicate with the MR using preconfigured IPSec. This applies both to PSBU and the prefix sub-option, or there is a difference respecting to this in both approaches? > MIP6 security > scheme only verify MR's home address, but not prefix itself. > Our approach provides these verification by using IPsec encryption. SA > is established between MR and HA by using MR-A (MR-A is used as the key > of encryption), mobile network prefix is verified. Again, why this can not be used with PSBU messages? > I think this approach > is well compliant with current MIP6 spec. Instead, PSBU store all the > prefix information in the BU. PSBU needs another way to verify this > prefix and also way to notify mapping of home address and mobile network > prefixes. > I do not understand why this is so, could you explain it to me? > Your last scenario is a kinds of administrative issue. MR may sends BU > w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length. I see, however, the problem illustrated in the figure above remains. > In fact, I did not mention the situation when MR has multiple mobile > network prefixes in the draft. I will add some texts at the next version. > Thanks for pointing this out. > > > Additionally, its impact in the case of nested networks should be also > > considered, since it imposes similar constraints to address > > administration. My concern is whether the reduction of 64 bits in the BU > > messages is worth these additional costs. > > Optimization is important, but I tried to keep compliance with current > MIPv6 spec, because MIPv6 is fully discussed at the IETF and is very "sensitive" > protocol indeed. If I added a lot of optimizations for NEMO, many new > issues come up. Furthermore, NEMO has many kinds of configuration > compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to > provide a certain level of optimization by means of "network operation". > (e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix > length) > > > Moreover, it assumed that the HA is aware of the prefix that this > > particular MR is authorized to announce, because of security reasons. > > So, why is not enough with the N bit only? I mean, the MR sends a BU > > with the N bit set, and the HA already knows which prefix of the mobile > > network (implicit signaling). If i understand the rationale correctly, > > when PSBU are used, it is useful since the mobile network can have > > multiple prefixes, and the BU can refer to only some of them. If the > > prefix sub-option is used, this feature is more restricted since only > > aggregates containing the MR-A can be announced. I do not know if i am > > missing something, but IMO much flexibility is lost when replacing PSBU > > by prefix suboption. > > For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64 > at the beginning. I don't quite follow you. What do you mean by the beginning? Why this information cannot be preconfigured in the HA? Do you have in mind a possible scenario where the dynamic of configuring the HA with the prefix assigned to the mobile network is insufficient? > Then the MR sends BU w/ 64 prefix length instead of 48. > Of course, this prefix is belong to the MR, HA can accept BU and > intercepts and tunnels packets only for the prefix/64. For these > operation, the prefix-suboption is needed. > > > > My second comment is about the location of the HA. I think that it is > > assumed that the HA is co-located with the only router present in the > > home-link. I could not find this assumption in the draft, but it is > > illustrated in the figure. This assumption is reflected in the behavior > > described in section 6.2.2 where it is assumed that all incoming packets > > pass through the HA. Is there any reason for this restriction? I think > > that the case where multiple routers are present in the home link is a > > reasonable case, and it can be easily supported, for instance by means > > of redirect from the HA pointing to the alternative router. > > Additionally, i think that, as i think it is suggested in > > draft-petrescu-nemo-mrha-02, the solution should support that the HA is > > a single interface node. I think that the solution can be extended to > > support this configurations. > > Good point, I did not mention this case enough. Delegated prefix is > assigned to MR, and HA only advertises the prefix by routing protocol. > "Routing protocol" means both IGP and BGP. If there are multiple routers > at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in > the home link. HA do not send RA of the delegated prefix at the home > link, so that it becomes next hop router of the delegated prefix. (Other > routers are not on-link of the mobile network prefix). > Ok. however, how this works if the HA is not a router? i mean it only has one interface? The communication between the AR and the MR should not pass through the HA in this case. That is why my guess is that redirects should do the trick. The other similar case is when multiple routers exist. In this case, again, the communication between the other routers and the HA should not pass through the HA. Again, i think the redirects can solve this. Regards, marcelo > Multiple HAs for single mobile network prefix is not considered yet in > the draft. > Although current MIP6 does not allow to register same binding to > multiple HAs, I have rough solution for this. > But I have to consider more before putting texts in the draft, because > there are many issues for multiple HAs, how MR selects HA, how HAs > manage same mobile network prefix at the home link, how to avoid inconsistency > of binding for same prefix among HAs due to some accidents of MR for > example. > > > > Additional comments: > > > > IPSec processing is included in section 5.2.2 and 6.1.1 but it is not > > described in section 5.2.1. Perhaps it would be clarifying to include > > it. > > Thanks, I will fix this. > > > I think that section 6.3 should include the location of the MR (home > > link or not) among the rules to decide whether HA has to tunnel or not > > packets to the MR. > > Right. I did not notice this. I will fix this, too. > > > The fact that the authorization of which prefixes can be announced by a > > MR is performed by configuring them in the HA is somehow included in > > different sections in the draft but perhaps it would be relevant to > > explicitly mention it in the security consideration section. > > We give the assumption for the prefix assignment and configuration at > this moment. I am just wondering whether I should use DHCP prefix > delegation for this protocol or not, now. I will think about this more. > > Thank you for your comments! > > regards, > ryuji -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Mon Mar 10 11:46:24 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02442 for ; Mon, 10 Mar 2003 11:46:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AGl2bf018677; Mon, 10 Mar 2003 17:47:02 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AGkqbf018669; Mon, 10 Mar 2003 17:46:52 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2AGir63018253; Mon, 10 Mar 2003 17:44:56 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 10 Mar 2003 17:46:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) Thread-Index: AcLnGKY4bM+4oMBPS+KfLUxCrOPLowACWH5g From: "Pascal Thubert (pthubert)" To: "marcelo bagnulo" , "Alexandru Petrescu" Cc: "Thierry Ernst" , X-OriginalArrivalTime: 10 Mar 2003 16:46:34.0683 (UTC) FILETIME=[9C4B88B0:01C2E724] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2AGkqbf018669 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 16:46:26 -0000 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: marcelo bagnulo [mailto:marcelo@it.uc3m.es] > Sent: lundi 10 mars 2003 16:10 > To: Alexandru Petrescu > Cc: Thierry Ernst; nemo@nal.motlabs.com > Subject: Re: [nemo] Re: location privacy (was: Re: > aboutdraft-ietf-nemo-requirements-00.txt) > > > Hi Alexander, Thierry > > Really interesting comments, and also unexpected. > > When i read the draft, my interpretation of location privacy > was that the MR wanted to hide its location from an > unauthorized listener in the path between the HA and the MR. > As you see it is really different from what Thierry meant. > > I think that the approach proposed by Alexander is very good. > > Let's try to answer these questions. I think we should change > the order, though :-) > > I guess that we could start by clarifying who is not supposed > to know the location of the MR. So, I would say that location > privacy capabilities prevent unauthorized parties to have > knowledge about the actual location of a mobile network. > Since a mobile network is permanently identified by the > mobile network prefix and/or its MR Home Address, and the > mobile network current location is identified by the CoA > assigned to the MR, location privacy is obtained by avoiding > the disclosure of the information about the current binding > between the mobile prefix (and/or the MR HoA) and MR CoA. > Potential unauthorized parties include the CNs of > communications maintained by the MNNs and any other party > along the communication path between the MNN and the CN that > can eavesdrop the communication. > > In the basic solution, CN is never aware of the current > location of the MNN since all traffic is coursed through the > HA which is fixed in the home network. The only location > privacy concerns remaining refer to the eavesdroping of > packets exchanged by the HA and the MR. A mobile network > solution should provide the functions needed to conceal > location information contained in these packets. This > requirement is included in the requirement R13.4. > > In the extended solution, MNNs are capable to interact > directly with CNs without including the HA in the > communication, exposing its location to the CN. However, the > usage of route optimization should always be the MNN choice. > In this case, unknown CN always reach the MNN through the HA, > using the MNN permanent address. Once the communication is in > place and that the MNN is aware of the CN, the MNN may choose > to make use of the Route Optimization capabilities provided > by the extended solution. In this case, the MNN is benefiting > from more optimal path but it is also disclosing its location > to the CN. > Other location privacy concerns refer to the disclosure of > location information to eavesdroppers along the communication > path. As long that the communication flows through the HA, > the basic scenario applies. In the case that RO is being > used, the conceal of location information implies the usage > of encryption between the MNN and the CN. I do not know if we > want to go there. > > I have tried to summarize the previous exchange, do you think > this is it? > > I agree totally with the approach. As of the possible intrusions, there may more to look at. 1) If people around me can listen to my RAs then they hear the prefixes I advertises. For instance, fixed antennas listening to passerbys can know who has been around. On the other hand, crypting the RAs limits nested solutions. 2) If my home is my ISP, I may not want them to know where I am, either. As you mention, my CareOf gives that away to them, even if the MIP protocol is encrypted. > Regards, marcelo > > > On Mon, 2003-03-10 at 13:45, Alexandru Petrescu wrote: > > Salut Thierry, > > > > Thierry Ernst wrote: > > > I mean, section 4 presents our "wishes". Location privacy > is one of > > > them. > > > > I think it is good to say that location privacy is one wish, but I > > also think that we should detail more what kind of location > privacy we > > want. And also see whether Mobile IPv6 will probably provide an > > inherent location privacy and so no need to develop new location > > privacy in NEMO. > > > > > Since the basic solution is to set up a tunnel and no routing > > > optimization, location privacy to the CN is enforced from a > > > Mobility point of view: the MR's CoA will never be present in > > > packets sent to the CN. > > > > Yes, exactly. > > > > > But, from a general point of view, the permanent address still > > > tells that the MNN is in the home network, which does not strickly > > > speaking provide the MNN with full privacy. Does it ? > > > > > > e.g CN knows that my prefix p_car/60 belongs to network "home/48" > > > but it doesn't that p_car/60 is now in network road/48. > > > > Yes, exactly. So do you think we should worry about CN > knowing that > > p_car/60 belongs to network home/48? > > > > > If you can draft us some words that would allow to explain this > > > clearly, in a sentence, that would be welcome. > > > > I think that text should clearly answer this: > > -is Mobile IPv6 going to provide location privacy to MR? > If yes, how > > will NEMO use it? > > -what entity tries to hide its location, is it MR? Is it > LFN? -what > > is the "location" information that that entity tries to hide? > > Is it an address? Is it a prefix? Is it a corelation HoA-CoA? > > -what is the entity that must not get knowledge of that location > > information? Is it CN? Is it HA? Is it an attacker listening? > > > > For example, I've seen the following description: attackers > that might > > intercept packets containing both HoA and CoA, so attacker can know > > that that HoA is at that CoA. In this specific case, the entity > > trying to hide its location is MH, the information to hide > is both HoA > > and CoA and the attacker is someone intercepting packets (not > > necessarily CN). > > > > What you seem to describe above is: entity hiding its > location is MR, > > location info to be protected is the corelation (MR's prefix - MR's > > home prefix) and the attacker is CN. > -- > marcelo bagnulo > uc3m > > From nemo-admin@nal.motlabs.com Mon Mar 10 13:19:47 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06525 for ; Mon, 10 Mar 2003 13:19:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AIL7bf019174; Mon, 10 Mar 2003 19:21:07 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AIKBbf019161 for ; Mon, 10 Mar 2003 19:20:12 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2AIJY05010226; Mon, 10 Mar 2003 11:19:35 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA17987; Mon, 10 Mar 2003 11:17:35 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h2AIGGB18921; Mon, 10 Mar 2003 12:16:16 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 97C962EC86; Mon, 10 Mar 2003 19:16:18 +0100 (CET) Message-ID: <3E6CD671.4080504@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo Cc: Thierry Ernst, Subject: Re: [nemo] Re: location privacy (was: Re: about draft-ietf-nemo-requirements-00.txt) References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> In-Reply-To: <1047309028.995.388.camel@presto.it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 19:16:17 +0100 Content-Transfer-Encoding: 7bit Hola Marcelo, marcelo bagnulo wrote: > Let's try to answer these questions. I think we should change the > order, though :-) From your description I understand that the location privacy is highly relevant to the Extended mode, and very little relevant to the Basic mode. > location privacy capabilities prevent unauthorized parties to have > knowledge about the actual location of a mobile network. [location > is a triplet: home prefix, CoA of MR and HoA of MR] > > unauthorized parties include the CNs of communications maintained > by the MNNs and any other party along the communication path > between the MNN and the CN that can eavesdrop the communication. Ok, so the above is a generic description of the the "location privacy" problem... > In the basic solution, CN is never aware of the current location of > the MNN since all traffic is coursed through the HA which is fixed > in the home network. The only location privacy concerns remaining > refer to the eavesdroping of packets exchanged by the HA and the > MR. A mobile network solution should provide the functions needed > to conceal location information contained in these packets. One second here. Eavesdropping between MR and HA can be avoided by Mobile IPv6 using an ESP header or something like that between MR and HA. That ESP header is for other reasons, but it implicitely achieves location privacy as we defined it above. Any attacker between MR and HA will not be able to obtaine the entire location triplet, it will only get the MR_CoA. > This requirement is included in the requirement R13.4. If my explanation above is relevant, then requirement R13.4 is not needed, right? > In the extended solution, MNNs are capable to interact directly > with CNs without including the HA in the communication, exposing > its location to the CN. However, the usage of route optimization > should always be the MNN choice. In this case, unknown CN always > reach the MNN through the HA, using the MNN permanent address. Once > the communication is in place and that the MNN is aware of the CN, > the MNN may choose to make use of the Route Optimization > capabilities provided by the extended solution. In this case, the > MNN is benefiting from more optimal path but it is also disclosing > its location to the CN. Other location privacy concerns refer to > the disclosure of location information to eavesdroppers along the > communication path. As long that the communication flows through > the HA, the basic scenario applies. In the case that RO is being > used, the conceal of location information implies the usage of > encryption between the MNN and the CN. So, in the Extended solution, the entity trying to hide is MNN (is it an LFN or a VMN?), the location info to hide is MNN's CoA, and the entity that must not know that info is CN and any party in the communication path. This is still very vague; any party in the comm path is any router; forbid this router to see the CoA and basic communication stops. So maybe the RO location privacy requirement can be loosen. Anyways, as you seem to imply, extended mode with RO should probably further dissect the location privacy issue. > I have tried to summarize the previous exchange, do you think this > is it? You forgot the first question "is Mobile IPv6 going to provide location privacy and NEMO use it?" needs a sort of answer, I don't get it from your message. There was discussion on the mipcharter list recently. My personal oppinion is that if Mobile IPv6 does location privacy then NEMO just uses it. If Mobile IPv6 doesn't do it, maybe it's not for NEMO to do it; just an oppinion. Alexander :-) From nemo-admin@nal.motlabs.com Mon Mar 10 13:33:17 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07013 for ; Mon, 10 Mar 2003 13:33:17 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AIZ3bf019262; Mon, 10 Mar 2003 19:35:03 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2AIYIbf019247 for ; Mon, 10 Mar 2003 19:34:18 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2AIXcXR026744; Mon, 10 Mar 2003 11:33:39 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA13227; Mon, 10 Mar 2003 11:33:38 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h2AIUOP03572; Mon, 10 Mar 2003 12:30:25 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 62CA02EC86; Mon, 10 Mar 2003 19:30:23 +0100 (CET) Message-ID: <3E6CD9BD.6000703@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: marcelo bagnulo, Thierry Ernst, Subject: Re: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 19:30:21 +0100 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > I agree totally with the approach. As of the possible intrusions, > there may more to look at. > > 1) If people around me can listen to my RAs then they hear the > prefixes I advertises. For instance, fixed antennas listening to > passerbys can know who has been around. On the other hand, crypting > the RAs limits nested solutions. Yes, that sounds more like access control, right? > 2) If my home is my ISP, I may not want them to know where I am, > either. As you mention, my CareOf gives that away to them, even if > the MIP protocol is encrypted. Stated that way is still incomprehensible. How can one avoid telling home where s/he is and still ask home to forward packets to current location. Or maybe we don't want reachability at a permanent home address, and avoid telling home the current location, no need of Mobile IP at all in that case. From nemo-admin@nal.motlabs.com Mon Mar 10 18:30:59 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20690 for ; Mon, 10 Mar 2003 18:30:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ANW8bf021661; Tue, 11 Mar 2003 00:32:08 +0100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ANVabf021653; Tue, 11 Mar 2003 00:31:38 +0100 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTE8EFCCRG9BWIE4@vaxh.its.monash.edu.au>; Tue, 11 Mar 2003 10:29:57 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A2D2A12C002; Tue, 11 Mar 2003 10:29:56 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id C407F12C006; Tue, 11 Mar 2003 10:29:52 +1100 (EST) From: Greg Daley Subject: Re: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) To: "Pascal Thubert (pthubert)" Cc: marcelo bagnulo , Alexandru Petrescu , Thierry Ernst , nemo@nal.motlabs.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E6D1FF0.5080603@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 10:29:52 +1100 Content-Transfer-Encoding: 7BIT Hi Pascal, Just a quick comment Pascal Thubert (pthubert) wrote: > [previous context removed] > > I agree totally with the approach. As of the possible intrusions, there > may more to look at. > > 1) If people around me can listen to my RAs then they hear the prefixes > I advertises. For instance, fixed antennas listening to passerbys can > know who has been around. On the other hand, crypting the RAs limits > nested solutions. While this is a security issue, I'm not sure that it is really a location privacy issue, since to receive the RA you need to be able to receive radiation/sound from the NEMO. This in most situations requires that the eavesdropper is present at the location. Also, as an example, in wireless LAN, link-layer encryption solves this issue, except for the L2 Identity of the access points. Link Access controls who gains access to more sensitive information. (Of course, I'm not saying that all WLAN encryption systems are secure for this purpose). > 2) If my home is my ISP, I may not want them to know where I am, either. > As you mention, my CareOf gives that away to them, even if the MIP > protocol is encrypted. If the MNN can get a CoA on the visited fixed network, maybe they can get a HMIPv6 regional CoA, which they can use to provide some location privacy from the HA. Greg From nemo-admin@nal.motlabs.com Mon Mar 10 18:51:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21262 for ; Mon, 10 Mar 2003 18:51:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ANr3bf021735; Tue, 11 Mar 2003 00:53:03 +0100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ANqpbf021727; Tue, 11 Mar 2003 00:52:52 +0100 Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTE936IS3Q9BWIEL@vaxh.its.monash.edu.au>; Tue, 11 Mar 2003 10:49:54 +1100 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C314612C02D; Tue, 11 Mar 2003 10:48:19 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 4578912C01B; Tue, 11 Mar 2003 10:48:18 +1100 (EST) From: Greg Daley Subject: Re: [nemo] Re: location privacy (was: Re: about draft-ietf-nemo-requirements-00.txt) To: Alexandru Petrescu Cc: marcelo bagnulo , Thierry Ernst , nemo@nal.motlabs.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E6D2442.1000601@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <3E6CD671.4080504@nal.motlabs.com> Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 10:48:18 +1100 Content-Transfer-Encoding: 7BIT BuonGiorno Alex, Some comments below. Alexandru Petrescu wrote: > Hola Marcelo, > > marcelo bagnulo wrote: > >> Let's try to answer these questions. I think we should change the >> order, though :-) > > > From your description I understand that the location privacy is highly > relevant to the Extended mode, and very little relevant to the Basic mode. Indeed, the principle issue in extended mode is route optimization. For Basic solutions, even snooping traffic from the MNN's home network will only reveal which NEMO the MN is present on. Further work would be required (snooping traffic from that NEMO's home network) to try to determine the CoA of the NEMO. We're not talking about casual snooping here. >> location privacy capabilities prevent unauthorized parties to have >> knowledge about the actual location of a mobile network. [location is >> a triplet: home prefix, CoA of MR and HoA of MR] >> >> unauthorized parties include the CNs of communications maintained by >> the MNNs and any other party along the communication path between the >> MNN and the CN that can eavesdrop the communication. > > > Ok, so the above is a generic description of the the "location > privacy" problem... > >> In the basic solution, CN is never aware of the current location of >> the MNN since all traffic is coursed through the HA which is fixed >> in the home network. The only location privacy concerns remaining >> refer to the eavesdroping of packets exchanged by the HA and the MR. >> A mobile network solution should provide the functions needed to >> conceal location information contained in these packets. > > > One second here. Eavesdropping between MR and HA can be avoided by > Mobile IPv6 using an ESP header or something like that between MR and > HA. That ESP header is for other reasons, but it implicitely achieves > location privacy as we defined it above. Any attacker between MR and > HA will not be able to obtaine the entire location triplet, it will > only get the MR_CoA. I think that even if the MR and HA have an ESP tunnel there are still ways to narrow down the set of locations that the NEMO could be at by inspecting the outer destination address of the encrypted packets. There may only be a few absent NEMOs handled by a home agent, therefore only a few addresses to investigate. Also, if the MNN advertises the NEMO which it is using with a BU to a visited CoA on the NEMO, it is easy enough to identify the HA to snoop. This can be used recursively to determine the CoA of the root-MR. I'm not sure that this is so important anyway, Since this sort of analysis probably requires access to fixed routing infrastructure to identify the NEMO's CoA and the MNN's location (except if the MNN advertises it in a BU). People who have access to the fixed routing infrastructure are likely to get what they want in other ways. MNNs which advertise their location with BU's don't need privacy. The real issue with location privacy is when the MNN uses route optimization to get an address in the NEMO's visited fixed network. If it uses that address in a MIPv6 BU, then the location of that node (and possibly other devices co-located with it on the NEMO) is revealed to an untrusted CN or third party. This is an extended requirement, as you say, but any MNN which is concerned about location privacy can opt-out of route-optimization. The two are largely incompatible when talking to untrusted hosts. This means reverse tunnelling all packets to the MIPv6 HA, or using RFC3041 addresses for short term route optimized communications, which shouldn't reveal the host's permanent identity. > >> This requirement is included in the requirement R13.4. > > > If my explanation above is relevant, then requirement R13.4 is not > needed, right? You're right that using ESP on the NEMO's HA helps prevent identification of the NEMO's CoA, although when a router only has a few NEMOs it's possible to narrow down the location. (if the attacker can watch packets going out). >> In the extended solution, MNNs are capable to interact directly with >> CNs without including the HA in the communication, exposing its >> location to the CN. However, the usage of route optimization should >> always be the MNN choice. In this case, unknown CN always reach the >> MNN through the HA, using the MNN permanent address. Once >> the communication is in place and that the MNN is aware of the CN, >> the MNN may choose to make use of the Route Optimization capabilities >> provided by the extended solution. In this case, the MNN is benefiting >> from more optimal path but it is also disclosing >> its location to the CN. Other location privacy concerns refer to the >> disclosure of location information to eavesdroppers along the >> communication path. As long that the communication flows through the >> HA, the basic scenario applies. In the case that RO is being used, the >> conceal of location information implies the usage of encryption >> between the MNN and the CN. > > > So, in the Extended solution, the entity trying to hide is MNN (is it > an LFN or a VMN?), the location info to hide is MNN's CoA, and > the entity that must not know that info is CN and any party in the > communication path. This is still very vague; any party in the comm > path is any router; forbid this router to see the CoA and basic > communication stops. So maybe the RO location privacy requirement can > be loosen. > > Anyways, as you seem to imply, extended mode with RO should probably > further dissect the location privacy issue. > >> I have tried to summarize the previous exchange, do you think this >> is it? > > > You forgot the first question "is Mobile IPv6 going to provide > location privacy and NEMO use it?" needs a sort of answer, I > don't get it from your message. There was discussion on the > mipcharter list recently. My personal oppinion is that if Mobile IPv6 > does location privacy then NEMO just uses it. If Mobile IPv6 doesn't > do it, maybe it's not for NEMO to do it; just an oppinion. > > Alexander :-) > I'm pretty sure that in most cases, location privacy will be usable by the NEMO MNN's in the same fashion that MIPv6 privacy will be used. The CoA available from the NEMO for the MNN will be a CoA similar to MIPv6 (possibly with different assumptions though). The basic form of extended NEMO privacy will probably still be to tunnel back via the MNN's HA. Greg From nemo-admin@nal.motlabs.com Mon Mar 10 18:56:00 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21371 for ; Mon, 10 Mar 2003 18:55:58 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ANv2bf021777; Tue, 11 Mar 2003 00:57:02 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2ANuLbf021769 for ; Tue, 11 Mar 2003 00:56:22 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2ANtw05019484; Mon, 10 Mar 2003 16:56:00 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA02909; Mon, 10 Mar 2003 16:55:57 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.13]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2ANtf324119; Mon, 10 Mar 2003 17:55:42 -0600 Message-ID: <3E6D3405.3010004@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: CC: "Pascal Thubert (pthubert)" , marcelo bagnulo , Thierry Ernst , nemo@nal.motlabs.com References: <3E6D1FF0.5080603@eng.monash.edu.au> In-Reply-To: <3E6D1FF0.5080603@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 01:55:33 +0100 Content-Transfer-Encoding: 7bit Greg Daley wrote: >> 2) If my home is my ISP, I may not want them to know where I am, >> either. As you mention, my CareOf gives that away to them, even >> if the MIP protocol is encrypted. > > > If the MNN can get a CoA on the visited fixed network, maybe they > can get a HMIPv6 regional CoA, which they can use to provide some > location privacy from the HA. So one ends up revealing more approximate information about one's location, than the precise CoA, which can be considered as a gain in privacy. But that is still a Mobile IPv6 issue, not very much related to NEMO, in my oppinion humble. Isn't it? -- Message Classification: GBU From nemo-admin@nal.motlabs.com Mon Mar 10 19:17:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21856 for ; Mon, 10 Mar 2003 19:17:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B0J3bf022168; Tue, 11 Mar 2003 01:19:03 +0100 Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B0Iebf022160; Tue, 11 Mar 2003 01:18:41 +0100 Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTEA23ZX7A9AOIZM@vaxh.its.monash.edu.au>; Tue, 11 Mar 2003 11:17:22 +1100 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6222B12C095; Tue, 11 Mar 2003 11:13:19 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 23C7D12C0FE; Tue, 11 Mar 2003 11:13:16 +1100 (EST) From: Greg Daley To: Alexandru Petrescu Cc: "Pascal Thubert (pthubert)" , marcelo bagnulo , Thierry Ernst , nemo@nal.motlabs.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E6D2A1B.5060007@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3E6D1FF0.5080603@eng.monash.edu.au> <3E6D3405.3010004@nal.motlabs.com> Subject: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 11:13:15 +1100 Content-Transfer-Encoding: 7BIT Hi Alex, Alexandru Petrescu wrote: > Greg Daley wrote: > >>> 2) If my home is my ISP, I may not want them to know where I am, >>> either. As you mention, my CareOf gives that away to them, even if >>> the MIP protocol is encrypted. >> >> >> >> If the MNN can get a CoA on the visited fixed network, maybe they can >> get a HMIPv6 regional CoA, which they can use to provide some location >> privacy from the HA. > > > So one ends up revealing more approximate information about one's > location, than the precise CoA, which can be considered as a gain in > privacy. But they get near optimal routing performance ;) The tradeoffs are almost the same as in MIPv6, when the MNN has a CoA from the visited fixed network. > But that is still a Mobile IPv6 issue, not very much related to NEMO, > in my oppinion humble. Isn't it? > Indeed. Let's leave host privacy up to the host mobility people, if we can. Greg. From nemo-admin@nal.motlabs.com Tue Mar 11 01:57:04 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29354 for ; Tue, 11 Mar 2003 01:57:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B6w7bf024997; Tue, 11 Mar 2003 07:58:07 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B6vabf024985; Tue, 11 Mar 2003 07:57:37 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id BDE3D5D0AC; Tue, 11 Mar 2003 15:57:27 +0900 (JST) Message-Id: <20030311.155727.39026782.ernst@sfc.wide.ad.jp> To: marcelo@it.uc3m.es Cc: petrescu@nal.motlabs.com, nemo@nal.motlabs.com Subject: Re: [nemo] Re: location privacy From: Thierry Ernst In-Reply-To: <1047309028.995.388.camel@presto.it.uc3m.es> References: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 15:57:27 +0900 (JST) Content-Transfer-Encoding: 7bit Hi, From: marcelo bagnulo > Really interesting comments, and also unexpected. > > When i read the draft, my interpretation of location privacy was that > the MR wanted to hide its location from an unauthorized listener in the > path between the HA and the MR. As you see it is really different from > what Thierry meant. Probably because you saw the words "location privacy" in the context of "basic support" only (although the words "location privacy" are not explicitly stated in section 5) ? > I think that the approach proposed by Alexander is very good. > > Let's try to answer these questions. I think we should change the order, > though :-) > > I guess that we could start by clarifying who is not supposed to know > the location of the MR. So, I would say that location privacy > capabilities prevent unauthorized parties to have knowledge about the > actual location of a mobile network. Since a mobile network is > permanently identified by the mobile network prefix and/or its MR Home > Address, and the mobile network current location is identified by the > CoA assigned to the MR, location privacy is obtained by avoiding the > disclosure of the information about the current binding between the > mobile prefix (and/or the MR HoA) and MR CoA. > > Potential unauthorized parties include the CNs of communications > maintained by the MNNs and any other party along the communication path > between the MNN and the CN that can eavesdrop the communication. > > In the basic solution, CN is never aware of the current location of the > MNN since all traffic is coursed through the HA which is fixed in the > home network. The only location privacy concerns remaining refer to the > eavesdroping of packets exchanged by the HA and the MR. A mobile network > solution should provide the functions needed to conceal location > information contained in these packets. This requirement is included in > the requirement R13.4. I agree with your summary. > In the extended solution, MNNs are capable to interact directly with CNs > without including the HA in the communication, exposing its location to > the CN. However, the usage of route optimization should always be the > MNN choice. In this case, unknown CN always reach the MNN through the > HA, using the MNN permanent address. Once the communication is in place > and that the MNN is aware of the CN, the MNN may choose to make use of > the Route Optimization capabilities provided by the extended solution. > In this case, the MNN is benefiting from more optimal path but it is > also disclosing its location to the CN. > Other location privacy concerns refer to the disclosure of location > information to eavesdroppers along the communication path. As long that > the communication flows through the HA, the basic scenario applies. In > the case that RO is being used, the conceal of location information > implies the usage of encryption between the MNN and the CN. I do not > know if we want to go there. Provided you have an idea in mind how route optimization should be performed. IMHO, it's a bit early to do that kind of assumption. > I have tried to summarize the previous exchange, do you think this is > it? If we leave up the technical details of related to extended support, yes. So, my question is "is there a need to change the text in the draft" and if yes, what text would you propose ? Thierry From nemo-admin@nal.motlabs.com Tue Mar 11 02:01:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01108 for ; Tue, 11 Mar 2003 02:01:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B733bf025106; Tue, 11 Mar 2003 08:03:03 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B72fbf025094 for ; Tue, 11 Mar 2003 08:02:42 +0100 Received: by jazz.mei.co.jp (8.12.8/3.7W/kings) with ESMTP id h2B72TNn010130; Tue, 11 Mar 2003 16:02:29 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id h2B72Ti10574; Tue, 11 Mar 2003 16:02:29 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/dodgers) with ESMTP id h2B72Rv12940; Tue, 11 Mar 2003 16:02:27 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h2B72Sf10961; Tue, 11 Mar 2003 16:02:28 +0900 (JST) Received: from [133.183.212.174] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h2B72Rj29665; Tue, 11 Mar 2003 16:02:27 +0900 (JST) From: Takeshi TANAKA To: "marcelo bagnulo" , IETF NEMO Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt In-Reply-To: <1047310258.995.416.camel@presto.it.uc3m.es> References: <20030310171021.8C66.TANAKA.TAKESHI-N@jp.panasonic.com> <1047310258.995.416.camel@presto.it.uc3m.es> Message-Id: <20030311142733.624E.TANAKA.TAKESHI-N@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:03:26 +0900 Content-Transfer-Encoding: 7bit Hi Marcelo, On Mon, 10 Mar 2003 16:30:58 +0100 "marcelo bagnulo" wrote : > > I understand. That is the case where home link is multihomed and not > > specific to NEMO, isn't that? > If a site has multiple provider and PA addressing is used, nodes within > the multi-homed site will obtain multiple addresses per interface in > order to be reachable through the multiple providers. So if the home > network of a mobile network is multi-homed it is possible that MNN will > have multiple addresses per interface associated to the multiple > providers. However this is not a NEMO specific issue, and in this case, > the mobile network is not multi-homed, but its home network is. So i > think this case should not be considered in the NEMO solution space. I agree. The case where a mobile router has multiple mobile network prefixes from a single home link, is not NEMO specific. I hope we could discuss whether scenarios described in draft-ng-nemo-multihoming-issues are in NEMO solution space. > > > > 3- Multi-homing capabilities. > > > > > > > > I haven't found any requirements about the capabilities of the mobile > > > > network multi-homing solution. It is stated that the solution must > > > > function for multi-homed mobile networks, but it is not specified what > > > > benefits are expected. IMO a fault tolerance requirement should be > > > > included. I mean, suppose that a mobile network has two MRs, and > > > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > > > communication between MR1 and the HA is unavailable). I would say that > > > > all the connections that were being coursed through MR1 have to be > > > > preserved during the outage meaning that they have to be re-routed > > > > through the alternative MR, providing fault-tolerance capabilities. The > > > > same case can be applied to the case of a MR with multiple interfaces > > > > and one of them fails. > > > > > > Note that fault tolerance capabilities required > > > > to the multi-homing solution of the mobile network are limited to the > > > > communication between the MRs and the HA, and are not related to the > > > > multi-homing capabilities of the solution of the home network. > > > I'm not sure that the draft should mention the purpose of > > > multihoming. If it did, it could only serve as an example; it's hard > > > to envision today what all the benefit of multihoming could be. So, I > > > don't think we should mention anything about fault tolerance (but I > > > agree it's one of the benefit). > > > > > > Comments from other ? > > I think some NEMO specific capability are required for multihoming NEMO > > to get fault tolerance from multihoming. For example, the mechanism he > > mentioned is not included in the current (experimental) multi-homing > > difinition; > > > all the connections that were being coursed through MR1 have to be > > > preserved during the outage meaning that they have to be re-routed > > > through the alternative MR, > > A router on a multi-homed link > > Sorry what do you mean by multi-homed link? The link where there are multiple default-router-capable routers and they are advertising different prefixes. | | Router Router prefix1| |prefix2 -------+-------+------- <--- # which term should I use for the link like above? Regards, Takeshi > Regards, marcelo > > does not preserve connection that were > > being coursed through it if egress link of the router is disconnected. > > > > So I think fault tolerance should be described in the draft somehow as > > one of the benefits if the basic solution will provide a mechanism to > > get the benefit, but other people may think different. > > > > Regards, > > Takeshi > -- > marcelo bagnulo > uc3m > From nemo-admin@nal.motlabs.com Tue Mar 11 02:15:40 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10961 for ; Tue, 11 Mar 2003 02:15:39 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B7H3bf025340; Tue, 11 Mar 2003 08:17:03 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B7GDbf025316 for ; Tue, 11 Mar 2003 08:16:14 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 7AC125D095; Tue, 11 Mar 2003 16:16:07 +0900 (JST) Message-Id: <20030311.161607.126971730.ernst@sfc.wide.ad.jp> To: marcelo@it.uc3m.es Cc: nemo@nal.motlabs.com Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt From: Thierry Ernst In-Reply-To: <1047311243.995.435.camel@presto.it.uc3m.es> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <1047311243.995.435.camel@presto.it.uc3m.es> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:16:07 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Marcelo, From: marcelo bagnulo > > Probably I didn't explain it enough, but section 4 lists a number of > > higher level requirements, not the actual requirements. That's why I > > entitled the section "guidelines" and not requirements. I mean, > > section 4 presents our "wishes". Location privacy is one of them. So, > > in section 4 I deliberately removed words "MUST" or "SHOULD" to keep > > it as open as possible. > > So, MUST and SHOULDS of the section 4 will be removed? Basically, I wanted to remove such words from section 4. > I think that the set of guidelines it is OK and they have to be > considered when evaluating a solution, specially for the extended > solution. Probably changing to lower case must and shoulds it's a good > idea. Will do. > > > 3- Multi-homing capabilities. > > I'm not sure that the draft should mention the purpose of > > multihoming. If it did, it could only serve as an example; it's hard > > to envision today what all the benefit of multihoming could be. So, I > > don't think we should mention anything about fault tolerance (but I > > agree it's one of the benefit). > > > > If no specific benefit is obtained through multi-homing, what does it > means that the solution MUST function with multi-homed networks? I didn't say there isn't benefit, I just said I don't think the draft should list the benefits. This is a requirement for some scenarios. > I guess that at least we are expecting that if multiple routers exist, > all can be used to course traffic, for instance. I would say that it is > also expected that if one router fails, new communications are > established using the alternative one which is available. We could also > discuss about established communications preservation. > > I mean, some basic benefits could be included in the section 4 at least > as guidelines of what is expected from multi-homing solutions. But in this case we should also include benefits for all other bullets. I think most are common sense and thus don't need justification. The bullets in section 4 are justification for section 5, I don't think we should also justify the bullets in section 4. > > > Comments from other ? > > > > > 4- Other comments > > > - IMO, at least some basic RFCs could be included in the Backward > > > compatibility bullet in section 4. > > > > We didn't do this on purpose. What RFCs should be listed ? We cannot > > list all. If we list some, it might be assumed that a non-listed one > > is not to be backward compatible. > > > > But, if you consider it's important, we should extablish an exhaustive > > list of RFCs. > > I see your point. > > BTW, FMIPv6 is still an ID, is it ok to include it in here? Good point. My personal answer is that FMIPv6 should not be listed explicitly. The reason why FMIPv6 and other protocols like DHCP and ICMP are listed in the draft is because a few people point for a need to ensure NEMO support is compabible with them. So, there is an issue here: shall we list no protocols at all, a few examples, the few we have identified as necessary, or an exhaustive list ? > > > - I guess that the scalability bullet of section 4 attempts to highlight > > > that scalability is important, but perhaps it is bit unspecific for a > > > MUST requirements , i mean, What is a large number of mobile networks? > > > > What would a number bring here ? The debate "large" vs "thousands" > > already occured. The purpose of this bullet is awareness that > > signalling should be minimised as much as possible. > > Perhaps rephrasing it this way may be clearer, but if you already > discussed this, i do not want to reopen the discussion anyway. Any proposition ? To be honest, I don't know how to rephrase this to make it clearer. Generally speaking, I think that, at this point, we need concrete sentences if anyone is not really happy with the text. Thierry From nemo-admin@nal.motlabs.com Tue Mar 11 02:39:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11941 for ; Tue, 11 Mar 2003 02:39:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B7f2bf025580; Tue, 11 Mar 2003 08:41:03 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B7eibf025564; Tue, 11 Mar 2003 08:40:45 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id AD85A5D019; Tue, 11 Mar 2003 16:40:37 +0900 (JST) Message-Id: <20030311.164037.100286607.ernst@sfc.wide.ad.jp> To: petrescu@nal.motlabs.com Cc: marcelo@it.uc3m.es, nemo@nal.motlabs.com Subject: Re: [nemo] Re: location privacy From: Thierry Ernst In-Reply-To: <3E6CD671.4080504@nal.motlabs.com> References: <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <3E6CD671.4080504@nal.motlabs.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:40:37 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Alex, From: Alexandru Petrescu > > In the basic solution, CN is never aware of the current location of > > the MNN since all traffic is coursed through the HA which is fixed > > in the home network. The only location privacy concerns remaining > > refer to the eavesdroping of packets exchanged by the HA and the > > MR. A mobile network solution should provide the functions needed > > to conceal location information contained in these packets. > > One second here. Eavesdropping between MR and HA can be avoided by > Mobile IPv6 using an ESP header or something like that between MR and > HA. That ESP header is for other reasons, but it implicitely achieves > location privacy as we defined it above. Any attacker between MR and > HA will not be able to obtaine the entire location triplet, it will > only get the MR_CoA. > > > This requirement is included in the requirement R13.4. > > If my explanation above is relevant, then requirement R13.4 is not > needed, right? Why ? The fact that it might not be a problem to enforce by simply using MIPv6 doesn't mean it shouldn't be listed as a requirement. > > In the extended solution, MNNs are capable to interact directly > > with CNs without including the HA in the communication, exposing > > its location to the CN. However, the usage of route optimization > > should always be the MNN choice. In this case, unknown CN always > > reach the MNN through the HA, using the MNN permanent address. Once > > the communication is in place and that the MNN is aware of the CN, > > the MNN may choose to make use of the Route Optimization > > capabilities provided by the extended solution. In this case, the > > MNN is benefiting from more optimal path but it is also disclosing > > its location to the CN. Other location privacy concerns refer to > > the disclosure of location information to eavesdroppers along the > > communication path. As long that the communication flows through > > the HA, the basic scenario applies. In the case that RO is being > > used, the conceal of location information implies the usage of > > encryption between the MNN and the CN. > > So, in the Extended solution, the entity trying to hide is MNN (is it > an LFN or a VMN?), the location info to hide is MNN's CoA, and > the entity that must not know that info is CN and any party in the > communication path. This is still very vague; any party in the comm > path is any router; forbid this router to see the CoA and basic > communication stops. So maybe the RO location privacy requirement can > be loosen. > > Anyways, as you seem to imply, extended mode with RO should probably > further dissect the location privacy issue. > > > I have tried to summarize the previous exchange, do you think this > > is it? > > You forgot the first question "is Mobile IPv6 going to provide > location privacy and NEMO use it?" needs a sort of answer, I > don't get it from your message. There was discussion on the > mipcharter list recently. My personal oppinion is that if Mobile IPv6 > does location privacy then NEMO just uses it. If Mobile IPv6 doesn't > do it, maybe it's not for NEMO to do it; just an oppinion. Of course. See NEMO charter: "The WG will investigate reusing the existing Mobile IPv6 mechanisms for the tunnel management, or extend it if deemed necessary." Which doesn't prevent us for listing the requirements. Thierry From nemo-admin@nal.motlabs.com Tue Mar 11 04:28:51 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14113 for ; Tue, 11 Mar 2003 04:28:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B9T4bf026985; Tue, 11 Mar 2003 10:29:05 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2B9SObf026977; Tue, 11 Mar 2003 10:28:24 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2B9QOUO026686; Tue, 11 Mar 2003 10:26:29 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 11 Mar 2003 10:27:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) Thread-Index: AcLnXVyVVO8AXdw0RTSBPCJWiuOoswAUN2gw From: "Pascal Thubert (pthubert)" To: , "Alexandru Petrescu" Cc: "marcelo bagnulo" , "Thierry Ernst" , X-OriginalArrivalTime: 11 Mar 2003 09:27:09.0372 (UTC) FILETIME=[63C217C0:01C2E7B0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2B9SObf026977 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 09:27:01 -0000 Content-Transfer-Encoding: 8bit Hi Greg! > > > > 1) If people around me can listen to my RAs then they hear the > > prefixes I advertises. For instance, fixed antennas listening to > > passerbys can know who has been around. On the other hand, crypting > > the RAs limits nested solutions. > > While this is a security issue, I'm not sure that it is > really a location privacy issue, since to receive the RA you > need to be able to receive radiation/sound from the NEMO. > This in most situations requires that the eavesdropper is > present at the location. > Right, just like in the example. You can now place fixed tracers that registers whoever passes by. > Also, as an example, in wireless LAN, link-layer encryption > solves this issue, except for the L2 Identity of the access > points. Link Access controls who gains access to more > sensitive information. (Of course, I'm not saying that all > WLAN encryption systems are secure for this purpose). > Now, it's also a policy thing. In one hand, you'd like to open up the MN to accept anonymous visitors and optimize everybody's chance to connect to the infrastructure. On the other hand you have to close it down because of security threats at L2 (mostly at Neighbor Discovery level) and L3, and because of privacy. I'm looking for a model of anonymous access that would allow visitor to gain a limited L2 access (eg VLAN), and limited L3 access (only the visitors Route Optimized tunnel through with no access to the home tunnel) to get connectivity in a harmless way. Then comes the privacy issue. > > 2) If my home is my ISP, I may not want them to know where I am, > > either. As you mention, my CareOf gives that away to them, > even if the > > MIP protocol is encrypted. > > If the MNN can get a CoA on the visited fixed network, maybe > they can get a HMIPv6 regional CoA, which they can use to > provide some location privacy from the HA. > Greg, I expected you'd be proposing that solution. :) Yes, the concept of HMIP MAPs could be extended for privacy proxying purposes. Alex: you may accept to trade closeness for privacy and register to a MAP that's actually in a different country. > Greg > > From nemo-admin@nal.motlabs.com Tue Mar 11 05:38:16 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15193 for ; Tue, 11 Mar 2003 05:38:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BAd5bf027897; Tue, 11 Mar 2003 11:39:05 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BAcCbf027889 for ; Tue, 11 Mar 2003 11:38:13 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2BAc1Zj009951; Tue, 11 Mar 2003 03:38:02 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA12531; Tue, 11 Mar 2003 03:36:05 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h2BAcq006984; Tue, 11 Mar 2003 04:38:53 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A2C982EC86; Tue, 11 Mar 2003 11:37:58 +0100 (CET) Message-ID: <3E6DBC86.4090702@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: , Subject: Re: [nemo] Re: location privacy References: <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <3E6CD671.4080504@nal.motlabs.com> <20030311.164037.100286607.ernst@sfc.wide.ad.jp> In-Reply-To: <20030311.164037.100286607.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 11:37:58 +0100 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Of course. See NEMO charter: "The WG will investigate reusing the > existing Mobile IPv6 mechanisms for the tunnel management, or > extend it if deemed necessary." Which doesn't prevent us for > listing the requirements. Ah yes, I see what you mean, which seems to be right. There's a difference, see below. One of the premium requirements that is listed very early in the draft, is "mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable at all times". This is also a requirement towards which NEMO will not work, but _use_ what Mobile IPv6 provides as a tool. There is however a very important difference between that requirement and the location privacy requirement. The "reachability" requirement has a tool behind it that is the existing Mobile IPv6, draft21. Location privacy has no such tool behind it. Moreover, discussions up to now evidence (in my interpretation) that the location privacy problem itself is not very clear, at this moment. That says, there will be some time before mipcharter (nsim, next steps in IP mobility BoF) decides to work on location privacy, define a clear problem statement, and provide a solution (for NEMO to use :-). That's why i'm inclined to believe that location privacy is probably too early to be put in the reqs, what do you think. Of course, it is nice to say "we do location privacy", just as it is nice to say "we do access control". But for the former we don't yet have an idea what we want. Or do you think I'm wrong on this? -- Message Classification: GBU From nemo-admin@nal.motlabs.com Tue Mar 11 05:47:51 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15445 for ; Tue, 11 Mar 2003 05:47:49 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BAm2bf028099; Tue, 11 Mar 2003 11:48:02 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BAkqbf028075; Tue, 11 Mar 2003 11:46:58 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id A7EE543178; Tue, 11 Mar 2003 11:46:44 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id ADCA999F39; Tue, 11 Mar 2003 11:46:41 +0100 (CET) Subject: RE: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) From: marcelo bagnulo To: Pascal "Thubert (pthubert)" Cc: Alexandru Petrescu , Thierry Ernst , nemo@nal.motlabs.com In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1047379598.744.24.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 11:46:38 +0100 Content-Transfer-Encoding: 7bit Hi Pascal, > I agree totally with the approach. As of the possible intrusions, there > may more to look at. > > 1) If people around me can listen to my RAs then they hear the prefixes > I advertises. For instance, fixed antennas listening to passerbys can > know who has been around. On the other hand, crypting the RAs limits > nested solutions. > I am not sure if i understand this issue correctly, are you talking about RA announced through the ingress interface or through the egress interface? In the case of the ingress interface, are you assuming that this is a wireless link?, perhaps this is assuming too much? As Greg said, i would say that in this particular case, particular solutions like L2 encryption should be be considered, more than general solutions. In the case of the egress interface, RA advertised by the MR does have to contain location information? I mean if all traffic flows tunneled to the HA, the MR does not have to announce the mobile network prefix in the foreign link, right? > 2) If my home is my ISP, I may not want them to know where I am, either. > As you mention, my CareOf gives that away to them, even if the MIP > protocol is encrypted. > I would guess that nodes within the home network are included among the unauthorized parties along the path between the MR and the HA, or do you think that they deserve special consideration? I mean do they have a special advantage that other nodes along the path do not? Thanks, marcelo > > > Regards, marcelo > > > > > > On Mon, 2003-03-10 at 13:45, Alexandru Petrescu wrote: > > > Salut Thierry, > > > > > > Thierry Ernst wrote: > > > > I mean, section 4 presents our "wishes". Location privacy > > is one of > > > > them. > > > > > > I think it is good to say that location privacy is one wish, but I > > > also think that we should detail more what kind of location > > privacy we > > > want. And also see whether Mobile IPv6 will probably provide an > > > inherent location privacy and so no need to develop new location > > > privacy in NEMO. > > > > > > > Since the basic solution is to set up a tunnel and no routing > > > > optimization, location privacy to the CN is enforced from a > > > > Mobility point of view: the MR's CoA will never be present in > > > > packets sent to the CN. > > > > > > Yes, exactly. > > > > > > > But, from a general point of view, the permanent address still > > > > tells that the MNN is in the home network, which does not strickly > > > > speaking provide the MNN with full privacy. Does it ? > > > > > > > > e.g CN knows that my prefix p_car/60 belongs to network "home/48" > > > > but it doesn't that p_car/60 is now in network road/48. > > > > > > Yes, exactly. So do you think we should worry about CN > > knowing that > > > p_car/60 belongs to network home/48? > > > > > > > If you can draft us some words that would allow to explain this > > > > clearly, in a sentence, that would be welcome. > > > > > > I think that text should clearly answer this: > > > -is Mobile IPv6 going to provide location privacy to MR? > > If yes, how > > > will NEMO use it? > > > -what entity tries to hide its location, is it MR? Is it > > LFN? -what > > > is the "location" information that that entity tries to hide? > > > Is it an address? Is it a prefix? Is it a corelation HoA-CoA? > > > -what is the entity that must not get knowledge of that location > > > information? Is it CN? Is it HA? Is it an attacker listening? > > > > > > For example, I've seen the following description: attackers > > that might > > > intercept packets containing both HoA and CoA, so attacker can know > > > that that HoA is at that CoA. In this specific case, the entity > > > trying to hide its location is MH, the information to hide > > is both HoA > > > and CoA and the attacker is someone intercepting packets (not > > > necessarily CN). > > > > > > What you seem to describe above is: entity hiding its > > location is MR, > > > location info to be protected is the corelation (MR's prefix - MR's > > > home prefix) and the attacker is CN. > > -- > > marcelo bagnulo > > uc3m > > > > -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 05:52:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15539 for ; Tue, 11 Mar 2003 05:52:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BAs3bf028230; Tue, 11 Mar 2003 11:54:03 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BArmbf028218 for ; Tue, 11 Mar 2003 11:53:48 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2BAre05008023; Tue, 11 Mar 2003 03:53:41 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA24729; Tue, 11 Mar 2003 03:53:40 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2BAra308347; Tue, 11 Mar 2003 04:53:37 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3C9B62EC86; Tue, 11 Mar 2003 11:53:35 +0100 (CET) Message-ID: <3E6DC02F.8080302@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: , Subject: Re: [nemo] Re: location privacy References: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <20030311.155727.39026782.ernst@sfc.wide.ad.jp> In-Reply-To: <20030311.155727.39026782.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 11:53:35 +0100 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > If we leave up the technical details of related to extended > support, yes. So, my question is "is there a need to change the > text in the draft" and if yes, what text would you propose ? My first proposal is very simple and involves very little effort from editor: search replace "location privacy" with "". However, in order to leave the door open to "location privacy" aspects, I would suggest to first do the step above followed by: "Location privacy is a new security aspect in IP mobility contexts. It might be desirable for communicating parties to be able to hide their location to peers. However, a problem statement for location privacy was not clearly defined at the time of writing. It might be possible that, in the future, Mobile IPv6 will provide location privacy tools; NEMO will reuse those tools; NEMO protocols are not required to work on location privacy problem definition, nor to design new location privacy tools." What do you think? Does that catch our discussions? -- Message Classification: GBU From nemo-admin@nal.motlabs.com Tue Mar 11 06:30:54 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16166 for ; Tue, 11 Mar 2003 06:30:50 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BBV8bf028874; Tue, 11 Mar 2003 12:31:08 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BBURbf028856; Tue, 11 Mar 2003 12:30:27 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 251E6431DD; Tue, 11 Mar 2003 12:30:19 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id DF8BE99E67; Tue, 11 Mar 2003 12:30:16 +0100 (CET) Subject: Re: [nemo] Re: location privacy (was: Re: about draft-ietf-nemo-requirements-00.txt) From: marcelo bagnulo To: Alexandru Petrescu Cc: Thierry Ernst , nemo@nal.motlabs.com In-Reply-To: <3E6CD671.4080504@nal.motlabs.com> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <3E6CD671.4080504@nal.motlabs.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047382215.744.68.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 12:30:16 +0100 Content-Transfer-Encoding: 7bit Hi Alexander, On Mon, 2003-03-10 at 19:16, Alexandru Petrescu wrote: > Hola Marcelo, > > marcelo bagnulo wrote: > > Let's try to answer these questions. I think we should change the > > order, though :-) > > From your description I understand that the location privacy is highly > relevant to the Extended mode, and very little relevant to the Basic mode. > I do not know... I would say that it depends on the case. Note that the part of the path between the MR and the HA is probably wireless, and it may insecure. OTOH you may trust the CNs... I wouldn't assume much about which one is more relevant, but perhaps i am missing something? > > location privacy capabilities prevent unauthorized parties to have > > knowledge about the actual location of a mobile network. [location > > is a triplet: home prefix, CoA of MR and HoA of MR] > > > > unauthorized parties include the CNs of communications maintained > > by the MNNs and any other party along the communication path > > between the MNN and the CN that can eavesdrop the communication. > > Ok, so the above is a generic description of the the "location > privacy" problem... right > > > In the basic solution, CN is never aware of the current location of > > the MNN since all traffic is coursed through the HA which is fixed > > in the home network. The only location privacy concerns remaining > > refer to the eavesdroping of packets exchanged by the HA and the > > MR. A mobile network solution should provide the functions needed > > to conceal location information contained in these packets. > > One second here. Eavesdropping between MR and HA can be avoided by > Mobile IPv6 using an ESP header or something like that between MR and > HA. That ESP header is for other reasons, but it implicitely achieves > location privacy as we defined it above. Any attacker between MR and > HA will not be able to obtaine the entire location triplet, it will > only get the MR_CoA. > Correct. But you are already talking about solutions here :-) I was pointing the problem. The solution can be as simple as you pointed out, but i would say that problems should be pointed out so that solutions can address them. > > This requirement is included in the requirement R13.4. > > If my explanation above is relevant, then requirement R13.4 is not > needed, right? Not so sure. Thinking it over, i would say that R13.4 is a different requirement. It talks about encryption of *signaling* messages, so it addresses, in particular, location privacy issues related with this messages. However, other packets that do not carry signaling but just user traffic, also present location privacy issues, since they carry both the CoA and the permanent address of the MNN. Summarizing, R13.4 addresses part of the location privacy issue (restricted to signaling messages) but issues related to location privacy of user packets are not considered. The question is if they should be considered... > > > In the extended solution, MNNs are capable to interact directly > > with CNs without including the HA in the communication, exposing > > its location to the CN. However, the usage of route optimization > > should always be the MNN choice. In this case, unknown CN always > > reach the MNN through the HA, using the MNN permanent address. Once > > the communication is in place and that the MNN is aware of the CN, > > the MNN may choose to make use of the Route Optimization > > capabilities provided by the extended solution. In this case, the > > MNN is benefiting from more optimal path but it is also disclosing > > its location to the CN. Other location privacy concerns refer to > > the disclosure of location information to eavesdroppers along the > > communication path. As long that the communication flows through > > the HA, the basic scenario applies. In the case that RO is being > > used, the conceal of location information implies the usage of > > encryption between the MNN and the CN. > > So, in the Extended solution, the entity trying to hide is MNN (is it > an LFN or a VMN?) Is there any difference? > , the location info to hide is MNN's CoA, Actually, the CoA- permanent address binding. > and > the entity that must not know that info is CN and any party in the > communication path. This is still very vague; any party in the comm > path is any router; forbid this router to see the CoA and basic > communication stops. No, they do not have to be aware of the binding CoA permanent address. Clearly the must be able to see the CoA, contained in the esterior header. Location privacy is achieved by concealing the inner permanent address. > So maybe the RO location privacy requirement can > be loosen. > > Anyways, as you seem to imply, extended mode with RO should probably > further dissect the location privacy issue. > > > I have tried to summarize the previous exchange, do you think this > > is it? > > You forgot the first question "is Mobile IPv6 going to provide > location privacy and NEMO use it?" needs a sort of answer, I > don't get it from your message. There was discussion on the > mipcharter list recently. My personal oppinion is that if Mobile IPv6 > does location privacy then NEMO just uses it. If Mobile IPv6 doesn't > do it, maybe it's not for NEMO to do it; just an oppinion. > Agree Regards, marcelo > Alexander :-) -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 06:33:26 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16213 for ; Tue, 11 Mar 2003 06:33:22 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BBY2bf028942; Tue, 11 Mar 2003 12:34:02 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BBW4bf028887; Tue, 11 Mar 2003 12:32:06 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 76360431D9; Tue, 11 Mar 2003 12:32:00 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 6053699F27; Tue, 11 Mar 2003 12:32:00 +0100 (CET) Subject: Re: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) From: marcelo bagnulo To: Alexandru Petrescu Cc: Pascal "Thubert (pthubert)" , Thierry Ernst , nemo@nal.motlabs.com In-Reply-To: <3E6CD9BD.6000703@nal.motlabs.com> References: <3E6CD9BD.6000703@nal.motlabs.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047382319.744.71.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 12:32:00 +0100 Content-Transfer-Encoding: 7bit On Mon, 2003-03-10 at 19:30, Alexandru Petrescu wrote: > Pascal Thubert (pthubert) wrote: > > I agree totally with the approach. As of the possible intrusions, > > there may more to look at. > > > > 1) If people around me can listen to my RAs then they hear the > > prefixes I advertises. For instance, fixed antennas listening to > > passerbys can know who has been around. On the other hand, crypting > > the RAs limits nested solutions. > > Yes, that sounds more like access control, right? > > > 2) If my home is my ISP, I may not want them to know where I am, > > either. As you mention, my CareOf gives that away to them, even if > > the MIP protocol is encrypted. > > Stated that way is still incomprehensible. How can one avoid telling > home where s/he is and still ask home to forward packets to current > location. Yes, but in order to provide location privacy features this information should only be available to the HA and no other node in the home network. Regards, macrelo > > Or maybe we don't want reachability at a permanent home address, and > avoid telling home the current location, no need of Mobile IP at all > in that case. -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 07:13:35 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17034 for ; Tue, 11 Mar 2003 07:13:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BCF4bf029327; Tue, 11 Mar 2003 13:15:04 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BCE5bf029312; Tue, 11 Mar 2003 13:14:05 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2BCBu1Y002170; Tue, 11 Mar 2003 13:12:16 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 11 Mar 2003 13:13:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] Re: location privacy (was: Re:aboutdraft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] Re: location privacy (was: Re:aboutdraft-ietf-nemo-requirements-00.txt) Thread-Index: AcLnu6rZOtsjOHBUSje3JlqZn+6YYAACal9Q From: "Pascal Thubert (pthubert)" To: "marcelo bagnulo" Cc: "Alexandru Petrescu" , "Thierry Ernst" , X-OriginalArrivalTime: 11 Mar 2003 12:13:42.0123 (UTC) FILETIME=[A7E6E3B0:01C2E7C7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2BCE5bf029312 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 12:13:41 -0000 Content-Transfer-Encoding: 8bit > > I am not sure if i understand this issue correctly, are you > talking about RA announced through the ingress interface or > through the egress interface? In the case of the ingress > interface, are you assuming that this is a wireless link?, > perhaps this is assuming too much? As Greg said, i would say > that in this particular case, particular solutions like L2 > encryption should be be considered, more than general solutions. > > In the case of the egress interface, RA advertised by the MR > does have to contain location information? I mean if all > traffic flows tunneled to the HA, the MR does not have to > announce the mobile network prefix in the foreign link, right? > > I believe that the MR should not send RAs on the egress interfaces. We had that discussion that the MR is a host on the roaming (egress) interface and a router on the ingress interfaces, and it iseemde thye simplest and mostl reasonable approach. So I meantingress, where as you mentioned, the RAs are sent that identify the MR. Sure there are deployments were you want totally controlled L2 access. But in general, do you want that limitation? On the contrary, you may want to accept VMNs that you do not "know", in order to help them reach the infrastructure, but you would want to make sure they won't arm you, and you would want to keep private from each other. What I'm saying is that if we can avoid assumptions on the service that will be delivered, it's better. Here's a samll chat with Alper: " > If a host gains legitimate access to NEMO, it'll eventually > learn the perfix information and deduce whatever information > it can from that prefix. Are you suggesting both the host and > the NEMO should be anonymous to each other even when host is > getting service from the network? Yes... Since the Access Router is in my car and tells where my car is. They both should dialog with a tier party that says that this visit is authorized, but should not know each other. It is easy for the visitor to hide himself (RFC 3041 + ESP) but the protection and the privacy of the visited party should be considered as well. Note that even if my visitor is not ill-willing, since the careOf is based on my prefix, it is easy for someone at his home to figure out that I was where he was. " > > 2) If my home is my ISP, I may not want them to know where I am, > > either. As you mention, my CareOf gives that away to them, > even if the > > MIP protocol is encrypted. > > > > I would guess that nodes within the home network are included > among the unauthorized parties along the path between the MR > and the HA, or do you think that they deserve special > consideration? I mean do they have a special advantage that > other nodes along the path do not? > On the HA, you can dump the binding cache and get the CareOf. Other parties on the Home Net may not know you're roaming at all, unless they monitor the Link layer addresses. I can not say if it is important to hide the location from the HA, I guess it's the MR's owner decision. You may not be using privacy proxies every day, yet they exist. From nemo-admin@nal.motlabs.com Tue Mar 11 09:00:10 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19600 for ; Tue, 11 Mar 2003 09:00:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BE16bf029705; Tue, 11 Mar 2003 15:01:06 +0100 Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BE02bf029683; Tue, 11 Mar 2003 15:00:02 +0100 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 1E5384319F; Tue, 11 Mar 2003 15:00:02 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp03.uc3m.es (Postfix) with ESMTP id 2A32E99DED; Tue, 11 Mar 2003 14:59:59 +0100 (CET) Subject: Re: [nemo] Re: location privacy From: marcelo bagnulo To: Alexandru Petrescu Cc: Thierry Ernst , nemo@nal.motlabs.com In-Reply-To: <3E6DC02F.8080302@nal.motlabs.com> References: <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <20030311.155727.39026782.ernst@sfc.wide.ad.jp> <3E6DC02F.8080302@nal.motlabs.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047391198.745.465.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 14:59:58 +0100 Content-Transfer-Encoding: 7bit Hi Thierry, Alexander On Tue, 2003-03-11 at 11:53, Alexandru Petrescu wrote: > Thierry Ernst wrote: > > If we leave up the technical details of related to extended > > support, yes. So, my question is "is there a need to change the > > text in the draft" and if yes, what text would you propose ? > > My first proposal is very simple and involves very little effort from > editor: search replace "location privacy" with "". > > However, in order to leave the door open to "location privacy" > aspects, I would suggest to first do the step above followed by: > > "Location privacy is a new security aspect in IP mobility contexts. > It might be desirable for communicating parties to be able to hide > their location to peers. However, a problem statement for location > privacy was not clearly defined at the time of writing. It might > be possible that, in the future, Mobile IPv6 will provide location > privacy tools; NEMO will reuse those tools; NEMO protocols are not > required to work on location privacy problem definition, nor to > design new location privacy tools." > > What do you think? Does that catch our discussions? I am not sure... After this message exchange, i think the the group has a pretty good idea about what location privacy is. I also think that it is more than trivial to understand what location privacy means in the NEMO context, and that including a definition and how does the concept applies to NEMO is clarifying for the reader has missed this thread. However, what i still do not know is the impact of the location privacy may have in solutions, i mean perhaps there is no extended solution that can provide location privacy. About the MIPv6 support, i think that we should re-use existing standards, but if they do not exist, or some issues like location privacy are not currently addressed, we should try to solve if we think it is relevant. So, summarizing i would include a definition of the problem and its application to NEMO in the guidelines section 4, just as it is included. Perhaps i would add a sentence to clarify some issues like actual location and third parties, something like this: Location Privacy: means to hide the actual location of MNNS to third parties other than the HA if desired. In the NEMO context, location information is provided by the binding between the permanent address assigned to MNN and the CoA assigned to the MR. Third parties may include the CNs of communications maintained by the MNNs and any other party along the communication path between the MNN and the CN that can eavesdrop the communication. What do think? Regards, marcelo -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 09:14:50 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20086 for ; Tue, 11 Mar 2003 09:14:49 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BEG2bf029766; Tue, 11 Mar 2003 15:16:02 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BEF8bf029758 for ; Tue, 11 Mar 2003 15:15:08 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2BEDJuS026364 for ; Tue, 11 Mar 2003 15:13:21 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 11 Mar 2003 15:13:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: IPv4 traversal Thread-Index: AcLn2J8/9G/d7SrZTiuadjR+67tkNA== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 11 Mar 2003 14:13:58.0341 (UTC) FILETIME=[751A5F50:01C2E7D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2BEF8bf029758 Subject: [nemo] IPv4 traversal Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 14:13:57 -0000 Content-Transfer-Encoding: 8bit (Yet another) draft is born! I prepared a paper on Ipv4 traversal, draft-thubert-nemo-ipv4-traversal-00.txt, but it's too late to submit (cut off till 3/17). I can send direct copies in the meantime. Abstract Since IPv6 connectivity is not yet broadly available, there is a need in NEMO for a simple technology that allows a MIPv6 based Mobile Router to roam over IPv4 networks. The Doors Protocol proposed in this memo allows an arbitrary Mobile Node to roam even within private IPv4 address spaces, across both Network and Port Address Translations, in order to cope with existing of deployments of technologies such as GPRS. If the title subject raises interest in the ML, we could spend some time at the WG. What do you think? Pascal Thubert Software Engineer Technology Center Cisco Systems Europe From nemo-admin@nal.motlabs.com Tue Mar 11 10:22:14 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23360 for ; Tue, 11 Mar 2003 10:22:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BFKTbf030053; Tue, 11 Mar 2003 16:20:39 +0100 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BFBobf029975; Tue, 11 Mar 2003 16:11:53 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27835; Tue, 11 Mar 2003 08:11:45 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BFBiP06085; Tue, 11 Mar 2003 16:11:44 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) To: greg.daley@eng.monash.edu.au Cc: Alexandru Petrescu , "Pascal Thubert (pthubert)" , marcelo bagnulo , Thierry Ernst , nemo@nal.motlabs.com In-Reply-To: "Your message with ID" <3E6D2A1B.5060007@eng.monash.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:07:51 +0100 (CET) > > But that is still a Mobile IPv6 issue, not very much related to NEMO, > > in my oppinion humble. Isn't it? > > > > Indeed. > > Let's leave host privacy up to the host mobility people, > if we can. Agreed. Presumably Nemo only needs to think about location privacy for the MR (and the LFNs that move with the MR) - location privacy for MNNs is a MIPv6 issue. When there is no RO only nodes on the path between the LFN-MR-HA can snoop the packets to see the HoA/CoA relationship. And using ESP tunnels between MR-HA removes that capability for that part of the path. Erik From nemo-admin@nal.motlabs.com Tue Mar 11 10:25:10 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23475 for ; Tue, 11 Mar 2003 10:25:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BFQpbf030125; Tue, 11 Mar 2003 16:26:51 +0100 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BFC4bf029986 for ; Tue, 11 Mar 2003 16:12:05 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10153; Tue, 11 Mar 2003 08:12:00 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BFBxP06105; Tue, 11 Mar 2003 16:11:59 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt To: marcelo bagnulo Cc: IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: "Your message with ID" <1047208960.728.63.camel@presto.it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:08:06 +0100 (CET) > IMHO, the case where multiple global addresses are configured to a > mobile router egress interface should not be included. In this case, > the MR has only one attachment point to the Internet, so the mobile > network is not multi-homed. However, if the multiple addresses > configured to the egress interface of the MR have different global > prefixes (i.e. PA addresses that have been assigned by different > ISPs),this means that the home network is multi-homed, not that the > mobile network is multi-homed. In this case, it is my opinion that the > communication between the HA and the MRR can be established using any of > the global addresses available and using one or the other does not > present benefits for the communication between the HA and the MR. I > mean, if the communication fails using one address it will fail using > the other one, since they are configured to the same interface. The > difference between using one address or the other is related to which > ISP will be used when exiting the home network. However, this issue is > related to the multi-homing solution configured in the home network, and > not to the multi-homing solution of the mobile network. For these > reasons, IMO, the case of multiple addresses configured to a single > interface should not be considered, since it should be solved by the > multi-homing solution of the home network. I *think* the statement should be about the Nemo solution not *preventing* any form of multihoming, including when there are multiple home prefixes. It would be a bug is Nemo had to do something special to enable any form of multihoming - it just shouldn't prevent them from being used. > I haven't found any requirements about the capabilities of the mobile > network multi-homing solution. It is stated that the solution must > function for multi-homed mobile networks, but it is not specified what > benefits are expected. IMO a fault tolerance requirement should be > included. I mean, suppose that a mobile network has two MRs, and > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > communication between MR1 and the HA is unavailable). I would say that > all the connections that were being coursed through MR1 have to be > preserved during the outage meaning that they have to be re-routed > through the alternative MR, providing fault-tolerance capabilities. The > same case can be applied to the case of a MR with multiple interfaces > and one of them fails. Note that fault tolerance capabilities required > to the multi-homing solution of the mobile network are limited to the > communication between the MRs and the HA, and are not related to the > multi-homing capabilities of the solution of the home network. I understand the desire to state such requirements but I think this is orthogonal to the Nemo aspects of the solution. The fact that the Ethernet in my office has two routers connecting it to the rest of the network has exactly the same issues. Thus I think this is an issue of how Nemo and IGP routing interact; not about Nemo itself. Erik From nemo-admin@nal.motlabs.com Tue Mar 11 10:25:34 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23499 for ; Tue, 11 Mar 2003 10:25:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BFRHbf030140; Tue, 11 Mar 2003 16:27:17 +0100 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BFGobf030021 for ; Tue, 11 Mar 2003 16:16:51 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13188; Tue, 11 Mar 2003 08:16:47 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2BFGkP06563; Tue, 11 Mar 2003 16:16:46 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] IPv4 traversal To: "Pascal Thubert (pthubert)" Cc: nemo@nal.motlabs.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:12:53 +0100 (CET) > I prepared a paper on Ipv4 traversal, > draft-thubert-nemo-ipv4-traversal-00.txt, but it's too late to submit > (cut off till 3/17). I can send direct copies in the meantime. How does this relate to draft-parent-blanchet-ngtrans-tsp-teredo-00.txt and draft-ietf-mobileip-nat-traversal-07.txt? Erik From nemo-admin@nal.motlabs.com Tue Mar 11 11:49:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27111 for ; Tue, 11 Mar 2003 11:49:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BGp6bf032253; Tue, 11 Mar 2003 17:51:06 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BGofbf032241 for ; Tue, 11 Mar 2003 17:50:41 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2BGmLUV002277; Tue, 11 Mar 2003 17:48:53 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 11 Mar 2003 17:50:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] IPv4 traversal Message-ID: Thread-Topic: [nemo] IPv4 traversal Thread-Index: AcLn4VcQuV+v73pzQ+64bnbySwaxCQADFQqQ From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" Cc: X-OriginalArrivalTime: 11 Mar 2003 16:50:30.0870 (UTC) FILETIME=[537C8F60:01C2E7EE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2BGofbf032241 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:50:30 -0000 Content-Transfer-Encoding: 8bit Hi Erik: draft-ietf-mobileip-nat-traversal-07.txt is about allowing MIPv4 to go though NATs which it can't natively (though it could if the registration had been a little different). My draft USES MIPv6 to store the IPv4/UDP states. It all ends up in the binding cache, and nowhere else in the network (but the NAT itself). The PAT is maintained by MIP flows. The traversal only works for MIP MNs, not for any node like Teredo, and uses MIP to setup the tunnel, not TSP. The idea is simple: build an automatic tunnel based on a tag, very much like 6to4. But the tag does not point on an end point (end prefix) like 6to4, it points on a UDP/IPv4 tunnel. The ag is not a real IPv4 address but is enough to be used as a CareOf, long as the resulting packet is tunnelized in UDP/IPv4. It works with MIP, but it's better with RRH or HMIP, both allowing to separate the IPv4 end point from the HA. The rest is in the draft ;) Pascal > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: mardi 11 mars 2003 16:13 > To: Pascal Thubert (pthubert) > Cc: nemo@nal.motlabs.com > Subject: Re: [nemo] IPv4 traversal > > > > I prepared a paper on Ipv4 traversal, > > draft-thubert-nemo-ipv4-traversal-00.txt, but it's too late > to submit > > (cut off till 3/17). I can send direct copies in the meantime. > > How does this relate to > draft-parent-blanchet-ngtrans-tsp-teredo-00.txt > and draft-ietf-mobileip-nat-traversal-07.txt? > > Erik > > > From nemo-admin@nal.motlabs.com Tue Mar 11 12:01:42 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27806 for ; Tue, 11 Mar 2003 12:01:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BH34bf032610; Tue, 11 Mar 2003 18:03:04 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BH2Obf032593 for ; Tue, 11 Mar 2003 18:02:24 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id B0FB343137; Tue, 11 Mar 2003 18:02:18 +0100 (CET) Received: from vpn-252-72.uc3m.es (vpn-252-72.uc3m.es [163.117.252.72]) by smtp01.uc3m.es (Postfix) with ESMTP id 3CB4D99E68; Tue, 11 Mar 2003 18:02:16 +0100 (CET) Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Takeshi TANAKA Cc: IETF NEMO In-Reply-To: <20030311142733.624E.TANAKA.TAKESHI-N@jp.panasonic.com> References: <20030310171021.8C66.TANAKA.TAKESHI-N@jp.panasonic.com> <1047310258.995.416.camel@presto.it.uc3m.es> <20030311142733.624E.TANAKA.TAKESHI-N@jp.panasonic.com> Content-Type: text/plain Organization: uc3m Message-Id: <1047396556.899.26.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 18:02:12 +0100 Content-Transfer-Encoding: 7bit Hi Takeshi, > I hope we could discuss whether scenarios described in > draft-ng-nemo-multihoming-issues are in NEMO solution space. I will try to read it ASAP > > > > > 3- Multi-homing capabilities. > > > > > > > > > > I haven't found any requirements about the capabilities of the mobile > > > > > network multi-homing solution. It is stated that the solution must > > > > > function for multi-homed mobile networks, but it is not specified what > > > > > benefits are expected. IMO a fault tolerance requirement should be > > > > > included. I mean, suppose that a mobile network has two MRs, and > > > > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > > > > communication between MR1 and the HA is unavailable). I would say that > > > > > all the connections that were being coursed through MR1 have to be > > > > > preserved during the outage meaning that they have to be re-routed > > > > > through the alternative MR, providing fault-tolerance capabilities. The > > > > > same case can be applied to the case of a MR with multiple interfaces > > > > > and one of them fails. > > > > > > > > Note that fault tolerance capabilities required > > > > > to the multi-homing solution of the mobile network are limited to the > > > > > communication between the MRs and the HA, and are not related to the > > > > > multi-homing capabilities of the solution of the home network. > > > > I'm not sure that the draft should mention the purpose of > > > > multihoming. If it did, it could only serve as an example; it's hard > > > > to envision today what all the benefit of multihoming could be. So, I > > > > don't think we should mention anything about fault tolerance (but I > > > > agree it's one of the benefit). > > > > > > > > Comments from other ? > > > I think some NEMO specific capability are required for multihoming NEMO > > > to get fault tolerance from multihoming. For example, the mechanism he > > > mentioned is not included in the current (experimental) multi-homing > > > difinition; > > > > all the connections that were being coursed through MR1 have to be > > > > preserved during the outage meaning that they have to be re-routed > > > > through the alternative MR, > > > A router on a multi-homed link > > > > Sorry what do you mean by multi-homed link? > The link where there are multiple default-router-capable routers and > they are advertising different prefixes. > > | | > Router Router > prefix1| |prefix2 > --+--+-- <-- > > # which term should I use for the link like above? The term is ok, i just didn't understand which configuration you were considering. I am not so sure that i understand the impact of the two prefixes here. The two prefixes are available for the home link, right? but the mobile network has only one prefix, right? If this is the case, i don't see what difference does it makes whether there are one or multiple prefixes. I do see that there is a difference when multiple routers are available at the home link. However, i think this is more similar to the case where multiple HAs are available. Perhaps the case where multiple HAs are available can be considered something like multi-homing, since the MR will have multiple "links" (i.e. tunnels) to the home network. In this case, some of the multi-homing benefits can be achieved, for instance fault tolerance when one of the HA is down. At least i think the multi-homing mechanisms will probably be useful when dealing with multiple HAs configurations. Regards, marcelo > Regards, > Takeshi > > > Regards, marcelo > > > does not preserve connection that were > > > being coursed through it if egress link of the router is disconnected. > > > > > > So I think fault tolerance should be described in the draft somehow as > > > one of the benefits if the basic solution will provide a mechanism to > > > get the benefit, but other people may think different. > > > > > > Regards, > > > Takeshi > > -- > > marcelo bagnulo > > uc3m > > -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 12:04:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27947 for ; Tue, 11 Mar 2003 12:04:31 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BH5wbf032685; Tue, 11 Mar 2003 18:05:58 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BH2dbf032597 for ; Tue, 11 Mar 2003 18:02:39 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id E514B43194; Tue, 11 Mar 2003 18:02:33 +0100 (CET) Received: from vpn-252-72.uc3m.es (vpn-252-72.uc3m.es [163.117.252.72]) by smtp02.uc3m.es (Postfix) with ESMTP id 4A12199E14; Tue, 11 Mar 2003 18:02:23 +0100 (CET) Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Thierry Ernst Cc: nemo@nal.motlabs.com In-Reply-To: <20030311.161607.126971730.ernst@sfc.wide.ad.jp> References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <1047311243.995.435.camel@presto.it.uc3m.es> <20030311.161607.126971730.ernst@sfc.wide.ad.jp> Content-Type: text/plain Organization: uc3m Message-Id: <1047402084.904.120.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 18:02:18 +0100 Content-Transfer-Encoding: 7bit Hi Thierry On Tue, 2003-03-11 at 08:16, Thierry Ernst wrote: [...] > > > > 3- Multi-homing capabilities. > > > > I'm not sure that the draft should mention the purpose of > > > multihoming. If it did, it could only serve as an example; it's hard > > > to envision today what all the benefit of multihoming could be. So, I > > > don't think we should mention anything about fault tolerance (but I > > > agree it's one of the benefit). > > > > > > > If no specific benefit is obtained through multi-homing, what does it > > means that the solution MUST function with multi-homed networks? > > I didn't say there isn't benefit, I just said I don't think the draft > should list the benefits. This is a requirement for some scenarios. > > > I guess that at least we are expecting that if multiple routers exist, > > all can be used to course traffic, for instance. I would say that it is > > also expected that if one router fails, new communications are > > established using the alternative one which is available. We could also > > discuss about established communications preservation. > > > > I mean, some basic benefits could be included in the section 4 at least > > as guidelines of what is expected from multi-homing solutions. > > But in this case we should also include benefits for all other > bullets. Probably benefits was not the right word here, sorry for that. What i meant is that i do not fully understand what is the scope of the words "support" in R12. I mean, R12.1: The solution MUST support mobile networks with multiple MRs. What does support mean? For instance, suppose the case where a mobile network has 2 MRs (MR1 and MR2). A given solution just selects one MR (MR1) randomly and use it as MR. The other MR (MR2) is just a normal MNN behind the selected MR. The link between MR2 and the home network is never used, even if the link between MR1 and the Home network is not available. Does this solution supports multi-homing? If supporting means that the solution does not malfunction when two MR exist, then we could say that it is supported. Bu i do not think this what it is expected from the multi-homing support. Following your wish expressed in the last sentence (about concrete sentences) i would include the following sentences in R12 R12: The solution MUST function for multi-homed mobile networks. More precisely: R13.1: The solution MUST support mobile networks with multiple MRs. In particular, if the path through one MR becomes unavailable, the solution MUST be able to establish new communications between MNNs and CNs using an alternative available path through another MR. Additionally, if the path through one MR becomes unavailable, the solution SHOULD (or MAY?) preserve established communications by re-routing the packets of such communication through an alternative available MR. R13.2: The solution MUST support MR with multiple interfaces, In particular, if the path through one of the MR interfaces becomes unavailable, the solution MUST be able to establish new communications between MNNs and CNs using an alternative available interface of the MR. Additionally, if the path through one MR interfaces becomes unavailable, the solution MUST (or SHOULD?) preserve established communications by coursing packets of such communication through an alternative available interface of the MR. What do you think? > I think most are common sense and thus don't need > justification. > The bullets in section 4 are justification for section > 5, I don't think we should also justify the bullets in section 4. > > > > > > > Comments from other ? > > > > > > > 4- Other comments > > > > - IMO, at least some basic RFCs could be included in the Backward > > > > compatibility bullet in section 4. > > > > > > We didn't do this on purpose. What RFCs should be listed ? We cannot > > > list all. If we list some, it might be assumed that a non-listed one > > > is not to be backward compatible. > > > > > > But, if you consider it's important, we should extablish an exhaustive > > > list of RFCs. > > > > I see your point. > > > > BTW, FMIPv6 is still an ID, is it ok to include it in here? > > Good point. My personal answer is that FMIPv6 should not be listed > explicitly. > > The reason why FMIPv6 and other protocols like DHCP and ICMP are > listed in the draft is because a few people point for a need to ensure > NEMO support is compabible with them. > > So, there is an issue here: shall we list no protocols at all, a few > examples, the few we have identified as necessary, or an exhaustive > list ? I would say the the third option i.e. the few we have identified as necessary. I think so because some people in the wg probably have some ideas about what protocols are critical, (such as you said about FMIP). I think this is valuable knowledge that should be included in the doc and besides it gives a hint to solutions designers about what issues were detected as relevant or tricky by the group. > > > > > > - I guess that the scalability bullet of section 4 attempts to highlight > > > > that scalability is important, but perhaps it is bit unspecific for a > > > > MUST requirements , i mean, What is a large number of mobile networks? > > > > > > What would a number bring here ? The debate "large" vs "thousands" > > > already occured. The purpose of this bullet is awareness that > > > signalling should be minimised as much as possible. > > > > Perhaps rephrasing it this way may be clearer, but if you already > > discussed this, i do not want to reopen the discussion anyway. > > Any proposition ? To be honest, I don't know how to rephrase this to > make it clearer. > Ok. tried to do it and see your point :-( > Generally speaking, I think that, at this point, we need concrete > sentences if anyone is not really happy with the text. > I fully agree with this. I'll try to. (already started above :-) Regards, marcelo > Thierry > -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 12:09:46 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28176 for ; Tue, 11 Mar 2003 12:09:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BHB3bf032758; Tue, 11 Mar 2003 18:11:03 +0100 Received: from fridge.docomolabs-usa.com (fwuser@key1.docomolabs-usa.com [216.98.102.225]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BHA8bf032745; Tue, 11 Mar 2003 18:10:09 +0100 Message-ID: <00da01c2e7f0$d59a1f10$156015ac@T23KEMPF> From: "James Kempf" To: "Alexandru Petrescu" , "Thierry Ernst" Cc: , References: <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <3E6CD671.4080504@nal.motlabs.com> <20030311.164037.100286607.ernst@sfc.wide.ad.jp> <3E6DBC86.4090702@nal.motlabs.com> Subject: Re: [nemo] Re: location privacy MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 09:08:24 -0800 Content-Transfer-Encoding: 7bit > That says, there will be some time before mipcharter (nsim, next steps > in IP mobility BoF) decides to work on location privacy, define a > clear problem statement, and provide a solution (for NEMO to use :-). > That's why i'm inclined to believe that location privacy is probably > too early to be put in the reqs, what do you think. I think it would be much quicker if the MIPv6 work were to break into two groups, one core and one extensions. The extensions group could spin up an activity on location privacy right away. If that split is not made, I fear the group will once again get bogged down in something related to the core. jak From nemo-admin@nal.motlabs.com Tue Mar 11 13:25:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00726 for ; Tue, 11 Mar 2003 13:25:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BIR6bf002661; Tue, 11 Mar 2003 19:27:06 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BIQMbf002651; Tue, 11 Mar 2003 19:26:23 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2BIQ905017764; Tue, 11 Mar 2003 11:26:09 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA16479; Tue, 11 Mar 2003 11:24:09 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2BIMt309193; Tue, 11 Mar 2003 12:22:55 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0CBB62EC86; Tue, 11 Mar 2003 19:22:54 +0100 (CET) Message-ID: <3E6E297C.EBDC85AB@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: marcelo bagnulo Cc: Alexandru Petrescu, Thierry Ernst, Subject: Re: [nemo] Re: location privacy (was: Re:about draft-ietf-nemo-requirements-00.txt) References: <1047208960.728.63.camel@presto.it.uc3m.es> <20030310.160026.92605506.ernst@sfc.wide.ad.jp> <3E6C88FD.1080407@nal.motlabs.com> <1047309028.995.388.camel@presto.it.uc3m.es> <3E6CD671.4080504@nal.motlabs.com> <1047382215.744.68.camel@presto.it.uc3m.es> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 19:22:52 +0100 Content-Transfer-Encoding: 7bit Hi Marcelo, marcelo bagnulo wrote: > Not so sure. Thinking it over, i would say that R13.4 is a different > requirement. It talks about encryption of *signaling* messages, so it > addresses, in particular, location privacy issues related with this > messages. However, other packets that do not carry signaling but just > user traffic, also present location privacy issues, since they carry > both the CoA and the permanent address of the MNN. > Summarizing, R13.4 addresses part of the location privacy issue > (restricted to signaling messages) but issues related to location > privacy of user packets are not considered. Good point. > The question is if they should be considered... We may simply extend R14.4 with R14.4-bis to cover the case of user traffic (encapsulated by MR) disclosing MNN location. I would however recommand a MAY in that case, in order to align with MIPv6 draft (draft-ietf-mobileip-ipv6-21.txt, section 15.7, p153): "Home agents and mobile nodes may use IPsec ESP to protect payload packets tunneled between themselves. This is useful to protect communications against attackers on the path of the tunnel." Christophe. From nemo-admin@nal.motlabs.com Tue Mar 11 15:04:01 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08474 for ; Tue, 11 Mar 2003 15:03:59 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BK57bf004091; Tue, 11 Mar 2003 21:05:07 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BK4rbf004081 for ; Tue, 11 Mar 2003 21:04:53 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 9A8E2431F4; Tue, 11 Mar 2003 21:04:47 +0100 (CET) Received: from [163.117.252.58] (unknown [163.117.252.58]) by smtp02.uc3m.es (Postfix) with ESMTP id 9EC9B99F39; Tue, 11 Mar 2003 21:04:39 +0100 (CET) Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Erik Nordmark Cc: IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1047412357.899.255.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 11 Mar 2003 21:04:35 +0100 Content-Transfer-Encoding: 7bit Hi Erik, [...] > > I *think* the statement should be about the Nemo solution not *preventing* > any form of multihoming, including when there are multiple home prefixes. > It would be a bug is Nemo had to do something special to enable any form > of multihoming - it just shouldn't prevent them from being used. > I like this requirement. The problem is that currently there are no multi-homing solutions for IPv6 available, so we wouldn't know what features shouldn't be prevented :-( > > I haven't found any requirements about the capabilities of the mobile > > network multi-homing solution. It is stated that the solution must > > function for multi-homed mobile networks, but it is not specified what > > benefits are expected. IMO a fault tolerance requirement should be > > included. I mean, suppose that a mobile network has two MRs, and > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > communication between MR1 and the HA is unavailable). I would say that > > all the connections that were being coursed through MR1 have to be > > preserved during the outage meaning that they have to be re-routed > > through the alternative MR, providing fault-tolerance capabilities. The > > same case can be applied to the case of a MR with multiple interfaces > > and one of them fails. Note that fault tolerance capabilities required > > to the multi-homing solution of the mobile network are limited to the > > communication between the MRs and the HA, and are not related to the > > multi-homing capabilities of the solution of the home network. > > I understand the desire to state such requirements but I think this > is orthogonal to the Nemo aspects of the solution. > The fact that the Ethernet in my office has two routers connecting it > to the rest of the network has exactly the same issues. > Thus I think this is an issue of how Nemo and IGP routing interact; not > about Nemo itself. > I think that one difference between NEMO and an ethernet with multiple routers attached to it, it is the role of the HA. NEMO Multi-homing is essentially two paths to the HA (in the case of a single HA). So, I think that there may be some NEMO specific issues in multi-homing. For instance, suppose that a MR has two interfaces. A possible solution is to set up two tunnels with the HA. However, what information is contained in the binding cache? The mobile network prefix has two entries in the cache? and if one path becomes unavailable the correspondent entry is deleted?. The other option is that only one tunnel is established and when it becomes unavailable a new BU to that mobile network prefix is issued binding the prefix to the alternative CoA. I think that this kind of issues are NEMO specific and are related to multi-homing support. Perhaps this is what you meant by NEMO-IGP interaction. However, this interaction impact it the multi-homing support of the solution, so IMO we should include what level of support it is expected from multi-homing NEMO. Regards, marcelo > Erik -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Tue Mar 11 16:02:37 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12143 for ; Tue, 11 Mar 2003 16:02:36 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BKx4bf004697; Tue, 11 Mar 2003 21:59:04 +0100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2BKwBbf004688; Tue, 11 Mar 2003 21:58:12 +0100 Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTFHC7BYPY9BWIYL@vaxh.its.monash.edu.au>; Wed, 12 Mar 2003 07:57:02 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F2828130003; Wed, 12 Mar 2003 07:57:01 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 9BA22130006; Wed, 12 Mar 2003 07:56:59 +1100 (EST) From: Greg Daley Subject: Re: [nemo] Re: location privacy (was: Re: aboutdraft-ietf-nemo-requirements-00.txt) To: "Pascal Thubert (pthubert)" Cc: Alexandru Petrescu , marcelo bagnulo , Thierry Ernst , nemo@nal.motlabs.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E6E4D9B.2040409@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 07:56:59 +1100 Content-Transfer-Encoding: 7BIT Pascal Thubert (pthubert) wrote: [part snipped] >> >>If the MNN can get a CoA on the visited fixed network, maybe >>they can get a HMIPv6 regional CoA, which they can use to >>provide some location privacy from the HA. >> > > > Greg, I expected you'd be proposing that solution. :) Yes, the concept > of HMIP MAPs could be extended for privacy proxying purposes. Alex: you > may accept to trade closeness for privacy and register to a MAP that's > actually in a different country. You can't blame me for trying ;) I like HMIPv6. Greg From nemo-admin@nal.motlabs.com Tue Mar 11 20:32:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22161 for ; Tue, 11 Mar 2003 20:32:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2C1W7bf007726; Wed, 12 Mar 2003 02:32:07 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2C1VIbf007718 for ; Wed, 12 Mar 2003 02:31:19 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2C1VAXR026703; Tue, 11 Mar 2003 18:31:11 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id SAA24706; Tue, 11 Mar 2003 18:29:09 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.27]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h2C1UVD02727; Tue, 11 Mar 2003 19:30:32 -0600 Message-ID: <3E6E9BBE.8070307@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo CC: Erik Nordmark, IETF NEMO, References: <1047412357.899.255.camel@presto.it.uc3m.es> In-Reply-To: <1047412357.899.255.camel@presto.it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: multihoming (was: about draft-ietf-nemo-requirements-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 03:30:22 +0100 Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >> I *think* the statement should be about the Nemo solution not >> *preventing* any form of multihoming, including when there are >> multiple home prefixes. It would be a bug is Nemo had to do >> something special to enable any form of multihoming - it just >> shouldn't prevent them from being used. >> > I like this requirement. The problem is that currently there are no > multi-homing solutions for IPv6 available, so we wouldn't know > what features shouldn't be prevented :-( Are there solutions for IPv4 multi-homing? If yes, then they might exist for IPv6 too. > So, I think that there may be some NEMO specific issues in > multi-homing. For instance, suppose that a MR has two interfaces. Isn't this like an MH (mobile host) that has two interfaces? Can Mobile IPv6 handle this? Have you noticed any problem in having two active interfaces on MH and getting RAs on both? With the implementation I played there was no problem: I had two interfaces up on the MH and one communication stream between MH and CN, no RO. Each time that interface received an RA, it sent a BU to HA. The communication was continuously switched from one interface to the other. Do you think I can call this behaviour as multi-homing support for MH? If yes, then I suppose I can call it multi-homing support for an MR too. > A possible solution is to set up two tunnels with the HA. Yes, there are probably two tunnels if two egress interfaces of MR are up. Just like when there were two MHs belonging to the same HA. > However, what information is contained in the binding cache? The > mobile network prefix has two entries in the cache? and if one > path becomes unavailable the correspondent entry is deleted?. Yes, simply put, if one interface goes down then it won't reply to BReqs from HA, so the BC entry times out. I would say that if we assume (for a moment) that there is no prefix entry in the Binding Cache and have in the Binding Cache an entry for one HoA of one egress interface of MR and another entry for the other egress interface of MR, then everything will work fine for MR. When both entries are in the BC, we'll pick the first. When only one is present, well, we still pick the first. > The other option is that only one tunnel is established and when it > becomes unavailable a new BU to that mobile network prefix is > issued binding the prefix to the alternative CoA. I think that this > kind of issues are NEMO specific and are related to multi-homing > support. [Alternative CoA sounds too much like Alternate CoA which is not.] Assume a multi-homed fixed host with two interfaces. How does it choose between those two interfaces? Let's say it does so based on the destination address: if the destination address is site-local and one interface has a site-local address on it then use that interface, otherwise use the second interface. This is an example and is nothing new, it's in "default address selection". Assume now a multi-homed mobile host with two interfaces. If the destination is site local and one interface has a home address that is site local, then use that interface as _the_ tunnel. This is clearly Mobile IPv6-specific, and not NEMO specific. Assume now a multi-homed mobile router with two interfaces. If the destination is site local and one interface has a home address that is site local, then use that interface as _the_ tunnel. This is exactly like Mobile IPv6 for hosts, nothing new. In most other cases that I've seen discussed, it was an application (not the IP stack) decides to use interface 1, instead of interface 2. Then again, with a mobile router, an application on MR will decide to use interface 1 instead of 2, again nothing new. I mentioned "applications" because there are potentially too many additional types of indices a host will use to distinguish one interface instead of the other: -if the respective technology is available (e.g. receive WLAN beacon) and the other isn't. -if one interface gives higher bandwidth than the other. -if one interface gives cheaper bandwidth than the other. -if one interface gives more secure bandwidth than the other. -if one interface gives more private bandwidth than the other. -DiVX file on one interface and an MP3 on the other interface, simultaneously. -any mixture of the above. Imagine that we engage in designing a MR that uses all the above as a criterion to prefer one interface to the other. That's an enormous amount of work, involving coordination with a large number of groups. The alternative would be that we just make sure that MR works fine even if there are two active egress interfaces, or that the mobile network works fine even if it has two MR's connecting it to the Internet. "Works fine" means that the MNNs are reachable all the time at a permanent home address and that their communication with CNs is not interrupted when MRs change their CoA. So we can try to make sure it works fine. -- Message Classification: GBU From nemo-admin@nal.motlabs.com Wed Mar 12 03:42:01 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26277 for ; Wed, 12 Mar 2003 03:42:00 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2C8h9bf010798; Wed, 12 Mar 2003 09:43:09 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2C8gPbf010786 for ; Wed, 12 Mar 2003 09:42:25 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2C8e7nd012083 for ; Wed, 12 Mar 2003 09:40:38 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 12 Mar 2003 09:42:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: IPv4 traversal Thread-Index: AcLoc3GzBSL7qJEjS5ySgwOEUloqxQ== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 12 Mar 2003 08:42:14.0142 (UTC) FILETIME=[47B061E0:01C2E873] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2C8gPbf010786 Subject: [nemo] IPv4 traversal Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 08:42:13 -0000 Content-Transfer-Encoding: 8bit Hi: Alex was kind enough to publish my draft on the nemo server: http://www.nal.motlabs.com/nemo/drafts/draft-thubert-nemo-ipv4-traversal -00.txt Part of the initial discussion is whether this belongs to Nemo at all. Since the mechanism is totally MIPv6 based, I believe it's either Nemo or MIPv6. What do you think? Pascal Thubert From nemo-admin@nal.motlabs.com Wed Mar 12 09:46:04 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04739 for ; Wed, 12 Mar 2003 09:46:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CEl7bf013383; Wed, 12 Mar 2003 15:47:07 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CEkhbf013375 for ; Wed, 12 Mar 2003 15:46:44 +0100 Received: by jazz.mei.co.jp (8.12.8/3.7W/kings) with ESMTP id h2CEkVNn001916; Wed, 12 Mar 2003 23:46:31 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id h2CEkV320210; Wed, 12 Mar 2003 23:46:31 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id h2CEkV218600; Wed, 12 Mar 2003 23:46:31 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h2CEkUf04036; Wed, 12 Mar 2003 23:46:30 +0900 (JST) Received: from [133.183.212.158] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h2CEkTn29112; Wed, 12 Mar 2003 23:46:29 +0900 (JST) From: Takeshi TANAKA To: "Erik Nordmark" Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt Cc: "marcelo bagnulo" , "IETF NEMO" , ernst@sfc.wide.ad.jp In-Reply-To: References: <1047208960.728.63.camel@presto.it.uc3m.es> Message-Id: <20030312222614.E083.TANAKA.TAKESHI-N@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 23:47:31 +0900 Content-Transfer-Encoding: 7bit On Tue, 11 Mar 2003 16:08:06 +0100 (CET) "Erik Nordmark" wrote : > > IMHO, the case where multiple global addresses are configured to a > > mobile router egress interface should not be included. In this case, > > the MR has only one attachment point to the Internet, so the mobile > > network is not multi-homed. However, if the multiple addresses > > configured to the egress interface of the MR have different global > > prefixes (i.e. PA addresses that have been assigned by different > > ISPs),this means that the home network is multi-homed, not that the > > mobile network is multi-homed. In this case, it is my opinion that the > > communication between the HA and the MRR can be established using any of > > the global addresses available and using one or the other does not > > present benefits for the communication between the HA and the MR. I > > mean, if the communication fails using one address it will fail using > > the other one, since they are configured to the same interface. The > > difference between using one address or the other is related to which > > ISP will be used when exiting the home network. However, this issue is > > related to the multi-homing solution configured in the home network, and > > not to the multi-homing solution of the mobile network. For these > > reasons, IMO, the case of multiple addresses configured to a single > > interface should not be considered, since it should be solved by the > > multi-homing solution of the home network. > > I *think* the statement should be about the Nemo solution not *preventing* > any form of multihoming, including when there are multiple home prefixes. > It would be a bug is Nemo had to do something special to enable any form > of multihoming - it just shouldn't prevent them from being used. > > > I haven't found any requirements about the capabilities of the mobile > > network multi-homing solution. It is stated that the solution must > > function for multi-homed mobile networks, but it is not specified what > > benefits are expected. IMO a fault tolerance requirement should be > > included. I mean, suppose that a mobile network has two MRs, and > > suddenly one MR (MR1) becomes unavailable (MR1 crashes or the > > communication between MR1 and the HA is unavailable). I would say that > > all the connections that were being coursed through MR1 have to be > > preserved during the outage meaning that they have to be re-routed > > through the alternative MR, providing fault-tolerance capabilities. The > > same case can be applied to the case of a MR with multiple interfaces > > and one of them fails. Note that fault tolerance capabilities required > > to the multi-homing solution of the mobile network are limited to the > > communication between the MRs and the HA, and are not related to the > > multi-homing capabilities of the solution of the home network. > > I understand the desire to state such requirements but I think this > is orthogonal to the Nemo aspects of the solution. > The fact that the Ethernet in my office has two routers connecting it > to the rest of the network has exactly the same issues. > Thus I think this is an issue of how Nemo and IGP routing interact; not > about Nemo itself. Please correct me if the following is wrong. I think this is both multi-homed link and NEMO issue, and interaction with IGP routing may not be helpful. Suppose 2 routers(router_A, router_B) are on the multi-homed link, and prefix_A, prefix_B are assigned to them for each ingress link, and these routers are connected to ISP_A, ISP_B to connect to the Internet. When egress link of router_A goes down, then address derived from prefix_A can not be reachable from/to the Internet since the multi-homed link does not have connection to ISP_A. Router_A may be configured to set lifetime=0 in RA it advertises, or router_A is configured to reply ICMP reidrect to point out router_B and stop to include prefix_A in RA it advertises, when egress link of router_A goes down to let nodes on the multi-homed link know egress link down. Anyway, application session on the nodes on the multi-homed link has to switch source address. Now suppose router_A and router_B are replaced by MR_A and MR_B. In NEMO, egress link of MR_A, MR_B may go down frequently, and MR_A/MR_B may have to switch route frequently. Everytime MR_A/MR_B goes down, application session on the nodes on the multi-homed link has to switch source address... I'm not saying solution of this issue must be provided, but one of the issues of NEMO with multiple mobile network prefixes that should be considered. Regards, Takeshi From nemo-admin@nal.motlabs.com Wed Mar 12 10:41:04 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08411 for ; Wed, 12 Mar 2003 10:41:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CFg6bf013672; Wed, 12 Mar 2003 16:42:07 +0100 Received: from smtp.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CFf6bf013661; Wed, 12 Mar 2003 16:41:06 +0100 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id D167B431E9; Wed, 12 Mar 2003 16:41:02 +0100 (CET) Received: from it.uc3m.es (saltamontes.it.uc3m.es [163.117.140.51]) by smtp03.uc3m.es (Postfix) with ESMTP id D4C7499EAB; Wed, 12 Mar 2003 16:40:57 +0100 (CET) Message-ID: <3E6F550C.3020808@it.uc3m.es> From: Marcelo Bagnulo User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.16 i686; en-US; 0.7) Gecko/20010316 X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu Cc: Erik Nordmark , IETF NEMO , ernst@sfc.wide.ad.jp References: <1047412357.899.255.camel@presto.it.uc3m.es> <3E6E9BBE.8070307@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: multihoming (was: about draft-ietf-nemo-requirements-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 16:41:00 +0100 Content-Transfer-Encoding: 7bit Hi Alexander, Alexandru Petrescu wrote: > marcelo bagnulo wrote: > >>> I *think* the statement should be about the Nemo solution not >>> *preventing* any form of multihoming, including when there are >>> multiple home prefixes. It would be a bug is Nemo had to do >>> something special to enable any form of multihoming - it just >>> shouldn't prevent them from being used. >>> >> I like this requirement. The problem is that currently there are no >> multi-homing solutions for IPv6 available, so we wouldn't know what >> features shouldn't be prevented :-( > > > Are there solutions for IPv4 multi-homing? If yes, then they might > exist for IPv6 too. IPv4 end-site multi-homing is usually achieved by announcing the site prefix through all its providers, so that they announce it as well and the site becomes reachable through all its ISPs. This configuration provide the expected benefits. However, there are big scalability issues with this approach, esentially because each multi-homed site is visible in the Default Free Zone. The initial idea was that this will not be allowed for end sites in IPv6. So multi6 was created to find solutions for IPv6 thgat exhibited better scalability properties.(For more references, see the multi6 charter) However, this problem is proving to be extremely difficult to solve and no solution seem to be accepted (there are several proposals, though) So at this time, i think we can say that there are no accepted multi-homing solutions for IPv6. > > >> So, I think that there may be some NEMO specific issues in >> multi-homing. For instance, suppose that a MR has two interfaces. > I would like to first clarify what my initial point was: I was not trying to propose a multi-homing solution for NEMO in this mail. I was just trying to understand whether there were some NEMO specific issues in mobile network multi-homing, or not. In order to do that, i've considered a concrete example, to see some issues involved in NEMO multi-homing. So the question that Erik made is: Do you think that there are some NEMO specific issues in mobile networks multi-homing or it can simply be solved by routing protocols as any fixed network with several routers attached to it? Is there any difference between the two cases? My initial guess was that there are some specific NEMO issues but ... I will come back to you later about the rest of the message if it is OK for you (i will try to read the multi-homing draft in order to avoid re-inventing the wheel) Regards, marcelo > > Isn't this like an MH (mobile host) that has two interfaces? Can > Mobile IPv6 handle this? Have you noticed any problem in having two > active interfaces on MH and getting RAs on both? With the > implementation I played there was no problem: I had two interfaces up > on the MH and one communication stream between MH and CN, no RO. Each > time that interface received an RA, it sent a BU to HA. The > communication was continuously switched from one interface to the > other. Do you think I can call this behaviour as multi-homing support > for MH? If yes, then I suppose I can call it multi-homing support for > an MR too. > >> A possible solution is to set up two tunnels with the HA. > > > Yes, there are probably two tunnels if two egress interfaces of MR are > up. Just like when there were two MHs belonging to the same HA. > >> However, what information is contained in the binding cache? The >> mobile network prefix has two entries in the cache? and if one path >> becomes unavailable the correspondent entry is deleted?. > > > Yes, simply put, if one interface goes down then it won't reply to > BReqs from HA, so the BC entry times out. > > I would say that if we assume (for a moment) that there is no prefix > entry in the Binding Cache and have in the Binding Cache an entry for > one HoA of one egress interface of MR and another entry for the other > egress interface of MR, then everything will work fine for MR. When > both entries are in the BC, we'll pick the first. When only one is > present, well, we still pick the first. > >> The other option is that only one tunnel is established and when it >> becomes unavailable a new BU to that mobile network prefix is issued >> binding the prefix to the alternative CoA. I think that this >> kind of issues are NEMO specific and are related to multi-homing >> support. > > > [Alternative CoA sounds too much like Alternate CoA which is not.] > > Assume a multi-homed fixed host with two interfaces. How does it > choose between those two interfaces? Let's say it does so based on > the destination address: if the destination address is site-local and > one interface has a site-local address on it then use that interface, > otherwise use the second interface. This is an example and is nothing > new, it's in "default address selection". > > Assume now a multi-homed mobile host with two interfaces. If the > destination is site local and one interface has a home address that is > site local, then use that interface as _the_ tunnel. This is clearly > Mobile IPv6-specific, and not NEMO specific. > > Assume now a multi-homed mobile router with two interfaces. If the > destination is site local and one interface has a home address that is > site local, then use that interface as _the_ tunnel. This is exactly > like Mobile IPv6 for hosts, nothing new. > > In most other cases that I've seen discussed, it was an application > (not the IP stack) decides to use interface 1, instead of interface 2. > Then again, with a mobile router, an application on MR will decide to > use interface 1 instead of 2, again nothing new. > > I mentioned "applications" because there are potentially too many > additional types of indices a host will use to distinguish one > interface instead of the other: > -if the respective technology is available (e.g. receive WLAN beacon) > and the other isn't. > -if one interface gives higher bandwidth than the other. > -if one interface gives cheaper bandwidth than the other. > -if one interface gives more secure bandwidth than the other. > -if one interface gives more private bandwidth than the other. > -DiVX file on one interface and an MP3 on the other interface, > simultaneously. > -any mixture of the above. > > Imagine that we engage in designing a MR that uses all the above as a > criterion to prefer one interface to the other. That's an enormous > amount of work, involving coordination with a large number of groups. > > The alternative would be that we just make sure that MR works fine > even if there are two active egress interfaces, or that the mobile > network works fine even if it has two MR's connecting it to the > Internet. "Works fine" means that the MNNs are reachable all the time > at a permanent home address and that their communication with CNs is > not interrupted when MRs change their CoA. So we can try to make sure > it works fine. > From nemo-admin@nal.motlabs.com Wed Mar 12 11:06:11 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09467 for ; Wed, 12 Mar 2003 11:06:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CG7Abf013843; Wed, 12 Mar 2003 17:07:10 +0100 Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CG61bf013829 for ; Wed, 12 Mar 2003 17:06:04 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2CG5RTd001820; Wed, 12 Mar 2003 09:05:29 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA00087; Wed, 12 Mar 2003 09:05:47 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h2CG5ag11466; Wed, 12 Mar 2003 10:05:37 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 23D942EC86; Wed, 12 Mar 2003 17:05:38 +0100 (CET) Message-ID: <3E6F5AD1.5070208@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcelo Bagnulo Cc: Erik Nordmark, IETF NEMO, References: <1047412357.899.255.camel@presto.it.uc3m.es> <3E6E9BBE.8070307@nal.motlabs.com> <3E6F550C.3020808@it.uc3m.es> In-Reply-To: <3E6F550C.3020808@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: multihoming (was: about draft-ietf-nemo-requirements-00.txt) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 17:05:37 +0100 Content-Transfer-Encoding: 7bit Hi Marcelo, Marcelo Bagnulo wrote: >>>> I *think* the statement should be about the Nemo solution not >>>> *preventing* any form of multihoming, including when there >>>> are multiple home prefixes. It would be a bug is Nemo had to >>>> do something special to enable any form of multihoming - it >>>> just shouldn't prevent them from being used. >>>> >>> I like this requirement. The problem is that currently there >>> are no multi-homing solutions for IPv6 available, so we >>> wouldn't know what features shouldn't be prevented :-( >> >> Are there solutions for IPv4 multi-homing? If yes, then they >> might exist for IPv6 too. > > IPv4 end-site multi-homing is usually achieved by announcing the > site prefix through all its providers, so that they announce it as > well and the site becomes reachable through all its ISPs. This > configuration provide the expected benefits. However, there are big > scalability issues with this approach, esentially because each > multi-homed site is visible in the Default Free Zone. I guess the differences between our views lie in that I tend to see MR as a simple little multihomed MH and you might try to see it more like a big router connecting a site to two ISPs. At one moment I wanted to think that way and I realized I lack so much info to go any further that I switched back to see MR as a little small MR (it's not only because multi-homing but IGP too). Which doesn't prevent the group to develop common concepts on whether there's specific multihoming issues for MR. > I would like to first clarify what my initial point was: I was not > trying to propose a multi-homing solution for NEMO in this mail. I > was just trying to understand whether there were some NEMO specific > issues in mobile network multi-homing, or not. Which is perfectly ok. > I will come back to you later about the rest of the message if it > is OK for you (i will try to read the multi-homing draft in order > to avoid re-inventing the wheel) It is perfectly ok and multihoming discussion is perfectly relevant and the issue should be clarified, thank you for your contribution. Alexander From nemo-admin@nal.motlabs.com Wed Mar 12 15:37:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21237 for ; Wed, 12 Mar 2003 15:37:37 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CKbBbf015848; Wed, 12 Mar 2003 21:37:11 +0100 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CKXobf015801 for ; Wed, 12 Mar 2003 21:33:51 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03073; Wed, 12 Mar 2003 12:33:42 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2CKXbP11632; Wed, 12 Mar 2003 21:33:37 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt To: marcelo bagnulo Cc: Erik Nordmark , IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: "Your message with ID" <1047412357.899.255.camel@presto.it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 21:01:01 +0100 (CET) > The problem is that currently there are no multi-homing solutions for > IPv6 available, so we wouldn't know what features shouldn't be prevented > :-( You must be using the term "multihoming" to only mean "infinitely scalable site multihoming" - that particular aspect of multihoming doesn't have any easy solutions. But the use we are talking about in Nemo is about connecting a mobile network (whether one link or multiple) to different places in the Internet. This isn't that much different than attaching the Ethernet in my office to two parallel campus backbones for redundancy. And this works just fine in IPv4 and IPv6 - the IGP routing protocol takes care of it all. The same techniques could be applied in the Nemo context. For instance in figure 2.2 and 2.3 in draft-ng-nemo-multihoming-issues-00.txt when the two HAs are in the same IGP domain, there could be a single prefix assigned to the link (instead of 2 in the picture) and the MR(s) would inject routes for that prefix to both HAs and life is good. > I think that one difference between NEMO and an ethernet with multiple > routers attached to it, it is the role of the HA. NEMO Multi-homing is > essentially two paths to the HA (in the case of a single HA). So, I > think that there may be some NEMO specific issues in multi-homing. For > instance, suppose that a MR has two interfaces. A possible solution is > to set up two tunnels with the HA. However, what information is > contained in the binding cache? The mobile network prefix has two > entries in the cache? and if one path becomes unavailable the > correspondent entry is deleted?. The other option is that only one > tunnel is established and when it becomes unavailable a new BU to that > mobile network prefix is issued binding the prefix to the alternative > CoA. I think that this kind of issues are NEMO specific and are related > to multi-homing support. Perhaps this is what you meant by NEMO-IGP > interaction. However, this interaction impact it the multi-homing > support of the solution, so IMO we should include what level of support > it is expected from multi-homing NEMO. [I'll use the case of two MRs since it is easier to write about - since I don't have to say "both MR CoAs" but can instead say "both MRs"] If the MRs are not injecting routes over the tunnel there are several choices in addition to what you outline above. But there are actually two separable pieces: the MRs themself having a binding cache entry at their HA for their HoA, and the binding cache entry/routing entry for the prefix(es) assigned to the mobile links. One could have both MRs binding imply a route for the prefix thus this would be regular multipath routing. When one of the paths/tunnels fail you'd like both ends (the HA and MR side) to notice relatively soon. I guess that could be caused by the binding timing out on the HA and the MR noticing that it can't refresh its binding. But it might also make sense to have a separate tunnel quality protocol - that would look very much the IGP Hello protocol. If you don't have two routes for the mobile prefix(es) then it will probably take longer to fail over. First you have to detect that one tunnel has failed and then (the added time of) creating the route fro the other tunnel. Erik From nemo-admin@nal.motlabs.com Wed Mar 12 15:43:18 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21451 for ; Wed, 12 Mar 2003 15:43:17 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CKj4bf015952; Wed, 12 Mar 2003 21:45:04 +0100 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CKaIbf015837 for ; Wed, 12 Mar 2003 21:36:18 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20712; Wed, 12 Mar 2003 12:36:02 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2CKZuP11757; Wed, 12 Mar 2003 21:35:57 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt To: Takeshi TANAKA Cc: Erik Nordmark , marcelo bagnulo , IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: "Your message with ID" <20030312222614.E083.TANAKA.TAKESHI-N@jp.panasonic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 21:08:13 +0100 (CET) > I think this is both multi-homed link and NEMO issue, and interaction > with IGP routing may not be helpful. > > Suppose 2 routers(router_A, router_B) are on the multi-homed link, and > prefix_A, prefix_B are assigned to them for each ingress link, and these > routers are connected to ISP_A, ISP_B to connect to the Internet. There are two different cases you might be thinking about and I can;t tell which one. One case is that the mobile network itself has a single (home) prefix i.e. the Home Agents for it are part of the same "site" and they want it to have a single prefix. The other case is that the mobile network has two separate (home) prefixes because it is attached to HAs in two different sites. Note that this is independent of who hands out the CoAs to the MRs - could be from ISP_C and ISP_D. So I'm confused. Erik From nemo-admin@nal.motlabs.com Wed Mar 12 20:38:16 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03204 for ; Wed, 12 Mar 2003 20:38:15 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D1d7bf017510; Thu, 13 Mar 2003 02:39:07 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D1cMbf017502 for ; Thu, 13 Mar 2003 02:38:24 +0100 Received: by jazz.mei.co.jp (8.12.8/3.7W/kings) with ESMTP id h2D1cFNn012820; Thu, 13 Mar 2003 10:38:15 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx2) with ESMTP id h2D1cHF16246; Thu, 13 Mar 2003 10:38:17 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/astros) with ESMTP id h2D1cGk05494; Thu, 13 Mar 2003 10:38:16 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h2D1cFf06129; Thu, 13 Mar 2003 10:38:15 +0900 (JST) Received: from [133.183.212.158] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h2D1cEn23194; Thu, 13 Mar 2003 10:38:15 +0900 (JST) From: Takeshi TANAKA To: "Erik Nordmark" Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt Cc: "marcelo bagnulo" , "IETF NEMO" , ernst@sfc.wide.ad.jp In-Reply-To: References: <20030312222614.E083.TANAKA.TAKESHI-N@jp.panasonic.com> Message-Id: <20030313103620.A742.TANAKA.TAKESHI-N@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 10:39:16 +0900 Content-Transfer-Encoding: 7bit On Wed, 12 Mar 2003 21:08:13 +0100 (CET) "Erik Nordmark" wrote : > > I think this is both multi-homed link and NEMO issue, and interaction > > with IGP routing may not be helpful. > > > > Suppose 2 routers(router_A, router_B) are on the multi-homed link, and > > prefix_A, prefix_B are assigned to them for each ingress link, and these > > routers are connected to ISP_A, ISP_B to connect to the Internet. > > There are two different cases you might be thinking about and I can;t > tell which one. One case is that the mobile network itself > has a single (home) prefix i.e. the Home Agents for it are part of the same > "site" and they want it to have a single prefix. > The other case is that the mobile network has two separate (home) prefixes > because it is attached to HAs in two different sites. The latter case. Prefix_A given from ISP_A via router_A, prefix_B given from ISP_B via router_B. > Note that this is independent of who hands out the CoAs to the MRs - could > be from ISP_C and ISP_D. Yes. The case described first is general(?) ipv6 multihoming (multi-homed link) case. If each egress link is replaced by each tunneling to each (different) home agent, the case becomes multi-homed NEMO case(multiple MRs on a mobile network, and these MRs are managed by different HAs). Regards, Takeshi From nemo-admin@nal.motlabs.com Wed Mar 12 21:53:29 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04872 for ; Wed, 12 Mar 2003 21:53:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D2t4bf017860; Thu, 13 Mar 2003 03:55:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D2sZbf017850 for ; Thu, 13 Mar 2003 03:54:36 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA03999; Wed, 12 Mar 2003 18:54:29 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2D2sRO11065; Wed, 12 Mar 2003 18:54:27 -0800 X-mProtect: <200303130254> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFfJuTM; Wed, 12 Mar 2003 18:54:26 PST Message-ID: <3E6FF2E3.4830FCBD@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ernst@sfc.wide.ad.jp CC: nemo@nal.motlabs.com, Erik.Nordmark@sun.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] comments on the requirements draft Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 18:54:27 -0800 Content-Transfer-Encoding: 7bit hi Thierry, I have a few comments on draft-ietf-nemo-requirements-00.txt. I am not sure if words like MUST should be used in this document. this is already a requirements document. does the following requirement become weaker (?) if you say - Migration Transparency: a permanent connectivity to the Internet must be provided to all MNNs while continuous sessions must be maintained as the mobile router changes its point of attachment. For doing so, MNNs will be reachable via their permanent IP addresses. instead of > - Migration Transparency: a permanent connectivity to the Internet > MUST be provided to all MNNs while continuous sessions MUST be > maintained as the mobile router changes its point of attachment. > For doing so, MNNs will be reachable via their permanent IP > addresses. I dont know which word (MUST or must) is the right one here. Erik, any suggestions? > > R12: The solution MUST function for multi-homed mobile networks. > More precisely: > multihoming is a complex issue. there are issues even with multi-home mobile nodes. I think this requirement needs to be removed. or reworded to say the solution should not prevent a multi-home mobile network from functioning properly. > R14.4: The signaling messages SHOULD be encrypted R14.4 should be removed. why is it a requirement that the signaling messages be encrypted? even in Mobile IPv6, there is no requirement that binding update or binding ack need to be encryption. there is no harm in an attacker looking at these messages. OTOH, HoTi message (a Return Routability message) needs to be encrypted because an attacker can cause some harm if he/she sees this message. as far as the basic support goes, I dont see the need to encrypt any signaling message. this requirement should be removed. do we need all those scalability requirements? they cant be enforced anyway? Vijay From nemo-admin@nal.motlabs.com Wed Mar 12 22:01:48 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05000 for ; Wed, 12 Mar 2003 22:01:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D338bf018024; Thu, 13 Mar 2003 04:03:08 +0100 Received: from jazz.mei.co.jp (jazz.mei.co.jp [202.224.189.26]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D32Gbf017954 for ; Thu, 13 Mar 2003 04:02:17 +0100 Received: by jazz.mei.co.jp (8.12.8/3.7W/jazz) with ESMTP id h2D31p62003198; Thu, 13 Mar 2003 12:01:51 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6/3.7W/somlx3) with ESMTP id h2D31q429343; Thu, 13 Mar 2003 12:01:53 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id h2D31p214061; Thu, 13 Mar 2003 12:01:51 +0900 (JST) Received: from gaugin.telecom.mci.mei.co.jp by postman.mci.mei.co.jp (8.11.1/3.7Wpl2:mcihub1:03022617) id h2D31of24910; Thu, 13 Mar 2003 12:01:50 +0900 (JST) Received: from [133.183.212.158] by gaugin.telecom.mci.mei.co.jp (8.11.6/3.7Wpre-TELECOM(gaugin)) with ESMTP id h2D31nn28265; Thu, 13 Mar 2003 12:01:49 +0900 (JST) From: Takeshi TANAKA To: "marcelo bagnulo" Subject: Re: [nemo] Re: about draft-ietf-nemo-requirements-00.txt Cc: "Thierry Ernst" , nemo@nal.motlabs.com In-Reply-To: <1047402084.904.120.camel@presto.it.uc3m.es> References: <20030311.161607.126971730.ernst@sfc.wide.ad.jp> <1047402084.904.120.camel@presto.it.uc3m.es> Message-Id: <20030313115412.A751.TANAKA.TAKESHI-N@jp.panasonic.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.06 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 12:02:51 +0900 Content-Transfer-Encoding: 7bit On Tue, 11 Mar 2003 18:02:18 +0100 "marcelo bagnulo" wrote : [...] > On Tue, 2003-03-11 at 08:16, Thierry Ernst wrote: > [...] > > > > > 3- Multi-homing capabilities. > > > > > > I'm not sure that the draft should mention the purpose of > > > > multihoming. If it did, it could only serve as an example; it's hard > > > > to envision today what all the benefit of multihoming could be. So, I > > > > don't think we should mention anything about fault tolerance (but I > > > > agree it's one of the benefit). > > > > > > > > > > If no specific benefit is obtained through multi-homing, what does it > > > means that the solution MUST function with multi-homed networks? > > > > I didn't say there isn't benefit, I just said I don't think the draft > > should list the benefits. This is a requirement for some scenarios. > > > > > I guess that at least we are expecting that if multiple routers exist, > > > all can be used to course traffic, for instance. I would say that it is > > > also expected that if one router fails, new communications are > > > established using the alternative one which is available. We could also > > > discuss about established communications preservation. > > > > > > I mean, some basic benefits could be included in the section 4 at least > > > as guidelines of what is expected from multi-homing solutions. > > > > But in this case we should also include benefits for all other > > bullets. > > Probably benefits was not the right word here, sorry for that. > What i meant is that i do not fully understand what is the scope of the > words "support" in R12. > I mean, R12.1: The solution MUST support mobile networks with multiple > MRs. What does support mean? > For instance, suppose the case where a mobile network has 2 MRs (MR1 and > MR2). A given solution just selects one MR (MR1) randomly and use it as > MR. The other MR (MR2) is just a normal MNN behind the selected MR. The > link between MR2 and the home network is never used, even if the link > between MR1 and the Home network is not available. Does this solution > supports multi-homing? If supporting means that the solution does not > malfunction when two MR exist, then we could say that it is supported. > Bu i do not think this what it is expected from the multi-homing > support. > > Following your wish expressed in the last sentence (about concrete > sentences) i would include the following sentences in R12 > > R12: The solution MUST function for multi-homed mobile networks. > More precisely: > > R13.1: The solution MUST support mobile networks with multiple MRs. > In particular, if the path through one MR becomes unavailable, the solution MUST be > able to establish new communications between MNNs and CNs using an alternative available path through another MR. > Additionally, if the path through one MR becomes unavailable, the solution SHOULD (or MAY?) > preserve established communications by re-routing the packets of such communication > through an alternative available MR. > > > R13.2: The solution MUST support MR with multiple interfaces, > In particular, if the path through one of the MR interfaces becomes unavailable, > the solution MUST be able to establish new communications between MNNs and CNs using > an alternative available interface of the MR. > Additionally, if the path through one MR interfaces becomes unavailable, the solution > MUST (or SHOULD?) preserve established communications by coursing packets of such communication > through an alternative available interface of the MR. > What do you think? I'm not Thierry but I agree with what these requirements means. I was thinking just "support mobile network with multiple MRs" does not say how much basic solution will work on clearly. There should be 2 steps of multi-homing support when multiple MRs on mobile network. 1. The solution enables MNNs to use these MRs for communication Current ipv6 multihoming should be able to support this, however 2. The solution enables to preserve established communication through cursed MR. this may not be what ipv6 multihoming can support. (especially when each MNP is provided from different home network) I think requirements should represent how much NEMO basic solution will wotk on multihoming issue (and how much benefit NEMO basic solution will provide) > > I think most are common sense and thus don't need > > justification. > > The bullets in section 4 are justification for section > > 5, I don't think we should also justify the bullets in section 4. > > > > > > > > > > > Comments from other ? > > > > > > > > > 4- Other comments > > > > > - IMO, at least some basic RFCs could be included in the Backward > > > > > compatibility bullet in section 4. > > > > > > > > We didn't do this on purpose. What RFCs should be listed ? We cannot > > > > list all. If we list some, it might be assumed that a non-listed one > > > > is not to be backward compatible. > > > > > > > > But, if you consider it's important, we should extablish an exhaustive > > > > list of RFCs. > > > > > > I see your point. > > > > > > BTW, FMIPv6 is still an ID, is it ok to include it in here? > > > > Good point. My personal answer is that FMIPv6 should not be listed > > explicitly. > > > > The reason why FMIPv6 and other protocols like DHCP and ICMP are > > listed in the draft is because a few people point for a need to ensure > > NEMO support is compabible with them. > > > > So, there is an issue here: shall we list no protocols at all, a few > > examples, the few we have identified as necessary, or an exhaustive > > list ? > I would say the the third option i.e. the few we have identified as > necessary. I think so because some people in the wg probably have some > ideas about what protocols are critical, (such as you said about FMIP). > I think this is valuable knowledge that should be included in the doc > and besides it gives a hint to solutions designers about what issues > were detected as relevant or tricky by the group. > > > > > > > > > > - I guess that the scalability bullet of section 4 attempts to highlight > > > > > that scalability is important, but perhaps it is bit unspecific for a > > > > > MUST requirements , i mean, What is a large number of mobile networks? > > > > > > > > What would a number bring here ? The debate "large" vs "thousands" > > > > already occured. The purpose of this bullet is awareness that > > > > signalling should be minimised as much as possible. > > > > > > Perhaps rephrasing it this way may be clearer, but if you already > > > discussed this, i do not want to reopen the discussion anyway. > > > > Any proposition ? To be honest, I don't know how to rephrase this to > > make it clearer. > > > > Ok. tried to do it and see your point :-( > > > Generally speaking, I think that, at this point, we need concrete > > sentences if anyone is not really happy with the text. > > > I fully agree with this. I'll try to. (already started above :-) Sorry to bother again about requirements...and I'll try, too. Regards, Takeshi From nemo-admin@nal.motlabs.com Thu Mar 13 02:31:58 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22955 for ; Thu, 13 Mar 2003 02:31:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D7VEbf020674; Thu, 13 Mar 2003 08:31:15 +0100 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2CKkCbf015966 for ; Wed, 12 Mar 2003 21:46:13 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15578; Wed, 12 Mar 2003 13:46:09 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2CKk4P12685; Wed, 12 Mar 2003 21:46:04 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt To: marcelo bagnulo Cc: Erik Nordmark , IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: "Your message with ID" <1047412357.899.255.camel@presto.it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 21:01:01 +0100 (CET) > The problem is that currently there are no multi-homing solutions for > IPv6 available, so we wouldn't know what features shouldn't be prevented > :-( You must be using the term "multihoming" to only mean "infinitely scalable site multihoming" - that particular aspect of multihoming doesn't have any easy solutions. But the use we are talking about in Nemo is about connecting a mobile network (whether one link or multiple) to different places in the Internet. This isn't that much different than attaching the Ethernet in my office to two parallel campus backbones for redundancy. And this works just fine in IPv4 and IPv6 - the IGP routing protocol takes care of it all. The same techniques could be applied in the Nemo context. For instance in figure 2.2 and 2.3 in draft-ng-nemo-multihoming-issues-00.txt when the two HAs are in the same IGP domain, there could be a single prefix assigned to the link (instead of 2 in the picture) and the MR(s) would inject routes for that prefix to both HAs and life is good. > I think that one difference between NEMO and an ethernet with multiple > routers attached to it, it is the role of the HA. NEMO Multi-homing is > essentially two paths to the HA (in the case of a single HA). So, I > think that there may be some NEMO specific issues in multi-homing. For > instance, suppose that a MR has two interfaces. A possible solution is > to set up two tunnels with the HA. However, what information is > contained in the binding cache? The mobile network prefix has two > entries in the cache? and if one path becomes unavailable the > correspondent entry is deleted?. The other option is that only one > tunnel is established and when it becomes unavailable a new BU to that > mobile network prefix is issued binding the prefix to the alternative > CoA. I think that this kind of issues are NEMO specific and are related > to multi-homing support. Perhaps this is what you meant by NEMO-IGP > interaction. However, this interaction impact it the multi-homing > support of the solution, so IMO we should include what level of support > it is expected from multi-homing NEMO. [I'll use the case of two MRs since it is easier to write about - since I don't have to say "both MR CoAs" but can instead say "both MRs"] If the MRs are not injecting routes over the tunnel there are several choices in addition to what you outline above. But there are actually two separable pieces: the MRs themself having a binding cache entry at their HA for their HoA, and the binding cache entry/routing entry for the prefix(es) assigned to the mobile links. One could have both MRs binding imply a route for the prefix thus this would be regular multipath routing. When one of the paths/tunnels fail you'd like both ends (the HA and MR side) to notice relatively soon. I guess that could be caused by the binding timing out on the HA and the MR noticing that it can't refresh its binding. But it might also make sense to have a separate tunnel quality protocol - that would look very much the IGP Hello protocol. If you don't have two routes for the mobile prefix(es) then it will probably take longer to fail over. First you have to detect that one tunnel has failed and then (the added time of) creating the route fro the other tunnel. Erik From nemo-admin@nal.motlabs.com Thu Mar 13 02:58:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23303 for ; Thu, 13 Mar 2003 02:58:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D805bf021213; Thu, 13 Mar 2003 09:00:05 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D7xQbf021190 for ; Thu, 13 Mar 2003 08:59:26 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2D7vccJ024874 for ; Thu, 13 Mar 2003 08:57:39 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 13 Mar 2003 08:59:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] IPv4 traversal Message-ID: Thread-Topic: [nemo] IPv4 traversal Thread-Index: AcLof+9y0jEliXhOQfajw3IsclqWugAthgjg From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 13 Mar 2003 07:59:18.0601 (UTC) FILETIME=[72F5C390:01C2E936] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2D7xQbf021190 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 07:59:18 -0000 Content-Transfer-Encoding: 8bit > > Are the handles unique? How do you guarantee uniqueness? > > The handle actually points on a NAT/PAT tunnel, not an endpoint/endprefix like 6to4. There is a unique resource in the translator box associated to it. Some fields (depending on NAT/PAT technology)in the handle are the index on that resource. As a result, the NAT/PAT ensures the uniqueness of the handle. Pascal From nemo-admin@nal.motlabs.com Thu Mar 13 03:59:56 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24249 for ; Thu, 13 Mar 2003 03:59:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D914bf022021; Thu, 13 Mar 2003 10:01:04 +0100 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2D8mTbf021862 for ; Thu, 13 Mar 2003 09:48:29 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27735; Thu, 13 Mar 2003 01:48:20 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2D8mJP18261; Thu, 13 Mar 2003 09:48:19 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt To: Takeshi TANAKA Cc: Erik Nordmark , marcelo bagnulo , IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: "Your message with ID" <20030313103620.A742.TANAKA.TAKESHI-N@jp.panasonic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 09:44:23 +0100 (CET) > The latter case. > > Prefix_A given from ISP_A via router_A, prefix_B given from ISP_B via > router_B. > > > Note that this is independent of who hands out the CoAs to the MRs - could > > be from ISP_C and ISP_D. > But the fact that you use "A" and "B" instead of "C" and "D" is confusing. So let me try to generalize what I think is your "mobile site multihoming" configuration. There are two mobile routers: MR_A and MR_B They have separate home agents (HA_A and HA_B) that belong to two different sites (A/48 and B/48 for example). As a result of this the mobile network has two prefixes: A:x/64 and B:y/64. The MRs attach either to the same ISP or different ISP. For maximum expansion assume they are different. Thus the CoA for the MRs is C:1 and D:1 respectively. The first concern in this type of setup is how does routing work for the LMNs - is there or is there not an assumption that the MR selection (the 1st hop default router the LMNs use) needs to be tied to the source address they use or not? Thus would it work if the LMN sends a packet with source A:x:987 to first hop router MR_B? In the IPv4 and IPv6 models of a host the source address selection is a function of what interface the host is sending on, but not which 1st hop router it is using. So unless folks are proposing to change this the host should be able to use source A:x:987 while using router MR_B. Making this work requires some coordination between site A and B (to accept either source address). This is part of the general *site* multihoming issues when each host gets an address from each site's prefix. But the point is assuming independence between site A and B (and indirectly the HAs and MRs) is a non-starter. > The case described first is general(?) ipv6 multihoming (multi-homed > link) case. If each egress link is replaced by each tunneling to each > (different) home agent, the case becomes multi-homed NEMO case(multiple > MRs on a mobile network, and these MRs are managed by different HAs). In both of my cases above there can be different HAs for the two MRs. But the issue is whether they use a single prefix for the mobile link or not. Using a single prefix requires coordination between the HAs, but as I've shown above using two prefixes also requires coordination between the HAs. Erik From nemo-admin@nal.motlabs.com Thu Mar 13 07:41:28 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28370 for ; Thu, 13 Mar 2003 07:41:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DCa5bf025093; Thu, 13 Mar 2003 13:36:05 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DCYxbf025081 for ; Thu, 13 Mar 2003 13:35:00 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 2B3B55D0BE; Thu, 13 Mar 2003 21:34:51 +0900 (JST) Message-Id: <20030313.213450.26709026.ernst@sfc.wide.ad.jp> To: nemo@nal.motlabs.com Cc: tj@kniveton.com From: Thierry Ernst In-Reply-To: <20030310.172855.27008327.ernst@sfc.wide.ad.jp> References: <20030310.172855.27008327.ernst@sfc.wide.ad.jp> User-Agent: SquirrelMail/1.4.0 RC2a Importance: Normal X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] NEMO IETF56 Agenda Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 21:34:50 +0900 (JST) Content-Transfer-Encoding: 7bit Dear all, Here is a draft agenda. We still have time left if there are requests for more slots. Particularly, we would like to have contribution on: - threat analysis - issues in NEMO basic support - conclusion from the "AAA in NEMO" discussion - more discussion on the solutions for NEMO Basic Support Contrasting of the drafts, plans on how we are going to combine them and which features to include. o Agenda NEMO Working Group - 56th IETF San Francisco Reading list: all drafts available on http://www.nal.motlabs.com/nemo draft-ernst-nemo-terminology-01.txt draft-ietf-nemo-requirements-00.txt draft-ng-nemo-multihoming-issues-00.txt draft-wakikawa-nemo-basic-00.txt draft-petrescu-nemo-mrha-02.txt draft-thubert-nemo-ipv4-traversal-00.txt - Agenda bashing 5 mins TJ Kniveton / Thierry Ernst - Charter Update and Milestones 5 mins TJ Kniveton - NEMO Support Requirements 15mins Draft Update draft-ietf-nemo-requirements-00.txt Thierry Ernst - Multi-Homing Issues in Bi-Directional Tunneling 15mins draft-ng-nemo-multihoming-issues-00.txt Chan Wah and Takeshi Tanaka - Basic NEMO Support solutions draft-wakikawa-nemo-basic-00.txt others ? - IPv4 traversal for MIPv6 based Mobile Routers 15mins draft-thubert-nemo-ipv4-traversal-00.txt [get it from http://www.nal.motlabs.com/nemo] - Terminology 15mins Proposed terms to be inserted in draft-seamoby draft-ernst-nemo-terminology-01.txt Thierry Ernst The chairs. From nemo-admin@nal.motlabs.com Thu Mar 13 08:01:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28957 for ; Thu, 13 Mar 2003 08:01:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DD33bf025490; Thu, 13 Mar 2003 14:03:03 +0100 Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DD2Wbf025480 for ; Thu, 13 Mar 2003 14:02:32 +0100 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 1F9074315E; Thu, 13 Mar 2003 14:02:27 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp01.uc3m.es (Postfix) with ESMTP id 1D92B99E2D; Thu, 13 Mar 2003 14:02:23 +0100 (CET) Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Erik Nordmark Cc: Takeshi TANAKA , IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1047560542.782.20.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Mar 2003 14:02:22 +0100 Content-Transfer-Encoding: 7bit Hi Erik, Takeshi On Thu, 2003-03-13 at 09:44, Erik Nordmark wrote: [...] > > The case described first is general(?) ipv6 multihoming (multi-homed > > link) case. If each egress link is replaced by each tunneling to each > > (different) home agent, the case becomes multi-homed NEMO case(multiple > > MRs on a mobile network, and these MRs are managed by different HAs). > > In both of my cases above there can be different HAs for the two MRs. > But the issue is whether they use a single prefix for the mobile link > or not. Using a single prefix requires coordination between the > HAs, An additional issue in this configuration would be the following, i guess. If both ISPs are in different sites, and a single prefix is used, how is the traffic routed to both sites. This implies that the mobile prefix is announced though multiple ISPs which is not compatible with current current address provider agggregation. So i am not sure that when multiple HA in different site with different ISPs are used, a single prefix can be used within the mobile network. I guess that multiple prefixes will be needed or additional mechanisms. However, i am not sure that these issues are NEMO specific, specially since this is basically the site multihoming problem > but as I've shown above using two prefixes also requires coordination > between the HAs. Or additional mechanisms to support multi-homing I think that an important question is if those mechanisms are NEMO specific or general site multi-homing mechanisms? I would say that these can depend on the configuration considered. Perhaps a good approach is to consider the different configurations and evaluate which one presents NEMO specific issues and which one is efficiently addressed by general mechanisms (such IGP routing) where there is no need for a special optimization for the NEMO case. Do you think this is useful approach? Regards, marcelo > > Erik -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Thu Mar 13 10:16:30 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04923 for ; Thu, 13 Mar 2003 10:16:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DFGGbf027607; Thu, 13 Mar 2003 16:16:16 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DFFYbf027591 for ; Thu, 13 Mar 2003 16:15:38 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id BAA7A43182; Thu, 13 Mar 2003 16:15:27 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 0AD6C99F47; Thu, 13 Mar 2003 16:15:26 +0100 (CET) Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Erik Nordmark Cc: IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1047568521.792.153.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Mar 2003 16:15:22 +0100 Content-Transfer-Encoding: 7bit On Wed, 2003-03-12 at 21:01, Erik Nordmark wrote: > > The problem is that currently there are no multi-homing solutions for > > IPv6 available, so we wouldn't know what features shouldn't be prevented > > :-( > > You must be using the term "multihoming" to only mean "infinitely scalable > site multihoming" - that particular aspect of multihoming doesn't have any > easy solutions. > I think i misunderstood your initial statement where you said that "I *think* the statement should be about the Nemo solution not *preventing* any form of multihoming, including when there are multiple home prefixes..." I thought that we were considering the case of a multi-homed home network i.e. the site that contains the HA is multihomed, so the mobile network is just another network within the site and the NEMO solution should not prevent that the site multi-homing solution adopted works properly. (My answer to that is that i agree but there are no solutions for site multi-homing available right now) The other interpretation to your sentence refers to the mobile network multi-homing. i.e. there are some mechanisms to allow that a network has multiple routers attached (IGPs). So a NEMO solution should be compatible with these mechanisms. This seems a good approach. However, i think that there may be some NEMO specific issues to be considered, which is what is being currently discussed in other mail exchanges. Do i understand this correctly this time? Regards, marcelo > Erik -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Thu Mar 13 11:57:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08732 for ; Thu, 13 Mar 2003 11:57:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DGwCbf029368; Thu, 13 Mar 2003 17:58:13 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DGvJbf029346 for ; Thu, 13 Mar 2003 17:57:20 +0100 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8657.tkyoac00.ap.so-net.ne.jp [218.221.134.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2DGuw2t027809; Fri, 14 Mar 2003 01:57:03 +0900 Message-ID: From: Ryuji Wakikawa To: marcelo@it.uc3m.es Cc: nemo@nal.motlabs.com Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt In-Reply-To: <1047313466.996.478.camel@presto.it.uc3m.es> References: <1047248443.1481.118.camel@presto.it.uc3m.es> <20030310075940.9410.RYUJI@sfc.wide.ad.jp> <1047313466.996.478.camel@presto.it.uc3m.es> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 01:53:01 +0900 Hello Marcelo. Sorry for replying late. > > The first motivation of this prefix-suboption is optimization as you've > > notice already:) > > But, there are other reasons for this now. > > > > When a MR has multiple prefixes, the MR acquires multiple MR-A at the > > ingress interface. The MR have to send BU individually for each mobile > > prefix. This is because current MIP6 does not allow to update multiple > > binding caches by sending "single" BU (i.e. no optimization for this). > > Ok. But what happens if the router's interface is not connected to the > network that contains the assigned prefix? I mean, more than one segment > may exist within a mobile network and the MR do not have to have an > interface in each of them. > > For example, the below configuration: > > > +--+ > |MR| > +--+ > | Pref1::/48 > ---------------- > | > +--+ > |R | > +--+ > | Pref2::/48 > ----------------- > > If i understand correctly, you are proposing that MR ingress interface > has two addresses configured i.e. Pref1:Router and Pref2:Router > > Now when the MR wants to send a packet addressed to Pref2, it will > assume it is directly connected if no additional configuration is made, > the same goes for R when trying to reach MR through the Pref2:Router > address. How do deal with this? For this situation, we recommends that "R" becomes another MR which manage Pref2::/48. I treat this example as nested mobility. If R doesn't exist and a MR manages multiple prefixes with an ingress interface, MR assigns multiple MR-A to the ingress interface. > > Since the assignment of multiple mobile network prefixes is equal to > > the assignment of multiple home addresses on Mobile IPv6. I am not sure > > if it is possible to allow this optimization only for NEMO. There will > > be another issues if NEMO allows this optimization. > > > > PSBU allows to carry prefix and its length in BU, but the prefix stored > > in the suboption of BU is not secured > > Isn't it possible to secure it with IPSec? How HA verrify that the prefix in suboption belong to the MR? > > and authorized. > > If i understand correctly, in both cases authorization is achieved > through proper configuration of the HA. I mean, the HA knows which > prefixes are assigned to each MR and the HA can securely communicate > with the MR using preconfigured IPSec. This applies both to PSBU and the > prefix sub-option, or there is a difference respecting to this in both > approaches? > > MIP6 security > > scheme only verify MR's home address, but not prefix itself. > > Our approach provides these verification by using IPsec encryption. SA > > is established between MR and HA by using MR-A (MR-A is used as the key > > of encryption), mobile network prefix is verified. > > Again, why this can not be used with PSBU messages? There is slight difference. SA is established between HA and MR-A in our id. SA is established between HA and MR HoA in PSBU. As you say, if HA has mapping of HoA and prefix, same security can be provided to PSBU between HA and MR. We design protocol to support RO in the future, and our scheme is well-applied to Return Routability, too. For return routability, this difference becomes large, because PSBU cannot use RR scheme to protect BU including prefix. PSBU can not verify the prefix by using HoTI and HoT. But this RO discussion is currently out of scope at WG. > > I think this approach > > is well compliant with current MIP6 spec. Instead, PSBU store all the > > prefix information in the BU. PSBU needs another way to verify this > > prefix and also way to notify mapping of home address and mobile network > > prefixes. > > > > I do not understand why this is so, could you explain it to me? I mean HA should know which MR carry which prefix. > > Your last scenario is a kinds of administrative issue. MR may sends BU > > w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length. > > I see, however, the problem illustrated in the figure above remains. > > > In fact, I did not mention the situation when MR has multiple mobile > > network prefixes in the draft. I will add some texts at the next version. > > Thanks for pointing this out. > > > > > Additionally, its impact in the case of nested networks should be also > > > considered, since it imposes similar constraints to address > > > administration. My concern is whether the reduction of 64 bits in the BU > > > messages is worth these additional costs. > > > > Optimization is important, but I tried to keep compliance with current > > MIPv6 spec, because MIPv6 is fully discussed at the IETF and is very "sensitive" > > protocol indeed. If I added a lot of optimizations for NEMO, many new > > issues come up. Furthermore, NEMO has many kinds of configuration > > compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to > > provide a certain level of optimization by means of "network operation". > > (e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix > > length) > > > > > Moreover, it assumed that the HA is aware of the prefix that this > > > particular MR is authorized to announce, because of security reasons. > > > So, why is not enough with the N bit only? I mean, the MR sends a BU > > > with the N bit set, and the HA already knows which prefix of the mobile > > > network (implicit signaling). If i understand the rationale correctly, > > > when PSBU are used, it is useful since the mobile network can have > > > multiple prefixes, and the BU can refer to only some of them. If the > > > prefix sub-option is used, this feature is more restricted since only > > > aggregates containing the MR-A can be announced. I do not know if i am > > > missing something, but IMO much flexibility is lost when replacing PSBU > > > by prefix suboption. > > > > For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64 > > at the beginning. > > I don't quite follow you. What do you mean by the beginning? Why this > information cannot be preconfigured in the HA? Do you have in mind a > possible scenario where the dynamic of configuring the HA with the > prefix assigned to the mobile network is insufficient? "beginning" is just example. MR can change the prefix length in active use anytime. HA delegates prefix with certain length, but HA does not care which prefix length MR currently use (of course within delegated length). We also consider dynamic configuration. If MR needs larger prefix, MR tries prefix delegation operation, then generates MR-A from the appropriate prefix and assigns it to the ingress interface. MR have to establish SA somehow between HA, too. > > Then the MR sends BU w/ 64 prefix length instead of 48. > > Of course, this prefix is belong to the MR, HA can accept BU and > > intercepts and tunnels packets only for the prefix/64. For these > > operation, the prefix-suboption is needed. > > > > > > My second comment is about the location of the HA. I think that it is > > > assumed that the HA is co-located with the only router present in the > > > home-link. I could not find this assumption in the draft, but it is > > > illustrated in the figure. This assumption is reflected in the behavior > > > described in section 6.2.2 where it is assumed that all incoming packets > > > pass through the HA. Is there any reason for this restriction? I think > > > that the case where multiple routers are present in the home link is a > > > reasonable case, and it can be easily supported, for instance by means > > > of redirect from the HA pointing to the alternative router. > > > Additionally, i think that, as i think it is suggested in > > > draft-petrescu-nemo-mrha-02, the solution should support that the HA is > > > a single interface node. I think that the solution can be extended to > > > support this configurations. > > > > Good point, I did not mention this case enough. Delegated prefix is > > assigned to MR, and HA only advertises the prefix by routing protocol. > > "Routing protocol" means both IGP and BGP. If there are multiple routers > > at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in > > the home link. HA do not send RA of the delegated prefix at the home > > link, so that it becomes next hop router of the delegated prefix. (Other > > routers are not on-link of the mobile network prefix). > > > > Ok. however, how this works if the HA is not a router? i mean it only > has one interface? The communication between the AR and the MR should > not pass through the HA in this case. That is why my guess is that > redirects should do the trick. > The other similar case is when multiple routers exist. In this case, > again, the communication between the other routers and the HA should not > pass through the HA. Again, i think the redirects can solve this. Currently, HA is the router. HA is configured as the default router of the mobile network prefix. Even if the HA has a single interface, HA could receives packets. Am I missing something here? regards, ryuji From nemo-admin@nal.motlabs.com Thu Mar 13 12:36:09 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09850 for ; Thu, 13 Mar 2003 12:36:08 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DHb3bf030295; Thu, 13 Mar 2003 18:37:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DHaebf030276 for ; Thu, 13 Mar 2003 18:36:40 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA02169; Thu, 13 Mar 2003 09:36:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2DHaUa03330; Thu, 13 Mar 2003 09:36:30 -0800 X-mProtect: <200303131736> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8wU5id; Thu, 13 Mar 2003 09:36:28 PST Message-ID: <3E70C19D.6936B1F1@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Thierry Ernst CC: nemo@nal.motlabs.com, tj@kniveton.com Subject: Re: [nemo] NEMO IETF56 Agenda References: <20030310.172855.27008327.ernst@sfc.wide.ad.jp> <20030313.213450.26709026.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 09:36:29 -0800 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > - Basic NEMO Support solutions > draft-wakikawa-nemo-basic-00.txt > others ? draft-kniveton-mobrtr-03.txt? IMHO, it is not a great idea for people to present their solutions. others can read that from the respective drafts. it would be more useful to focus on the issues, differences between the solutions and what we really need for the basic nemo protocol. > > - IPv4 traversal for MIPv6 based Mobile Routers 15mins > draft-thubert-nemo-ipv4-traversal-00.txt > [get it from http://www.nal.motlabs.com/nemo] I havent read this draft yet. but do we need this now? we dont even have "IPv4 traversal for MIPv6 based Mobile Hosts". :-) we dont have this in the charter. maybe it belongs in v6ops? IMO, we should finish up the basic protocol (or atleast have a mature protocol) before we start taking up new charter items. Vijay From nemo-admin@nal.motlabs.com Thu Mar 13 12:57:42 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10666 for ; Thu, 13 Mar 2003 12:57:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DHv4bf030737; Thu, 13 Mar 2003 18:57:04 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DHu5bf030613 for ; Thu, 13 Mar 2003 18:56:06 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id BCCAE431B5; Thu, 13 Mar 2003 18:55:59 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 5483399E14; Thu, 13 Mar 2003 18:55:59 +0100 (CET) Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt From: marcelo bagnulo To: Ryuji Wakikawa Cc: nemo@nal.motlabs.com In-Reply-To: References: <1047248443.1481.118.camel@presto.it.uc3m.es> <20030310075940.9410.RYUJI@sfc.wide.ad.jp> <1047313466.996.478.camel@presto.it.uc3m.es> Content-Type: text/plain Organization: uc3m Message-Id: <1047578157.782.203.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 13 Mar 2003 18:55:57 +0100 Content-Transfer-Encoding: 7bit Hi Ryuji, On Thu, 2003-03-13 at 17:53, Ryuji Wakikawa wrote: > Hello Marcelo. > > Sorry for replying late. > > > > The first motivation of this prefix-suboption is optimization as you've > > > notice already:) > > > But, there are other reasons for this now. > > > > > > When a MR has multiple prefixes, the MR acquires multiple MR-A at the > > > ingress interface. The MR have to send BU individually for each mobile > > > prefix. This is because current MIP6 does not allow to update multiple > > > binding caches by sending "single" BU (i.e. no optimization for this). > > > > Ok. But what happens if the router's interface is not connected to the > > network that contains the assigned prefix? I mean, more than one segment > > may exist within a mobile network and the MR do not have to have an > > interface in each of them. > > > > For example, the below configuration: > > > > > > +--+ > > |MR| > > +--+ > > | Pref1::/48 > > ---------------- > > | > > +--+ > > |R | > > +--+ > > | Pref2::/48 > > ----------------- > > > > If i understand correctly, you are proposing that MR ingress interface > > has two addresses configured i.e. Pref1:Router and Pref2:Router > > > > Now when the MR wants to send a packet addressed to Pref2, it will > > assume it is directly connected if no additional configuration is made, > > the same goes for R when trying to reach MR through the Pref2:Router > > address. How do deal with this? > > For this situation, we recommends that "R" becomes another MR which > manage Pref2::/48. I treat this example as nested mobility. > Ok, i guess this would work... However, wouldn't this introduce additional overhead? I mean all packets addressed to Pref2 subnet will have 2 tunnels, right? This seems to be conflicting with the main goal of the modification of PSBU which was diminishing overhead. Perhaps you could consider an alternative option, such as configuring something like a router loopback address with Pref2 in MR. I mean, what if you configure in MR the address Pref2::routeriid with a 128 bit long prefix? would this break something? If you can do this, MR can send the BU using this address, and receive packets addressed to him, but all other addresses of Pref2 subnetwork could be forwarded to R. I am probably missing something here (besides that this seems a nasty hack) but this would reduce the overhead... > If R doesn't exist and a MR manages multiple prefixes with an ingress > interface, MR assigns multiple MR-A to the ingress interface. > > > > Since the assignment of multiple mobile network prefixes is equal to > > > the assignment of multiple home addresses on Mobile IPv6. I am not sure > > > if it is possible to allow this optimization only for NEMO. There will > > > be another issues if NEMO allows this optimization. > > > > > > PSBU allows to carry prefix and its length in BU, but the prefix stored > > > in the suboption of BU is not secured > > > > Isn't it possible to secure it with IPSec? > > How HA verrify that the prefix in suboption belong to the MR? > I think that there was a misunderstanding here.. using IPSec the HA knows for sure that the prefix contained in the packet it had received it is the same that the one the MR has included when creating the packet (this is what i called the BU sub option is secured) What IPSec does not provide to HA are tools to determine if this MR is allowed to announce this prefix (that is what i called authorization) I guess we agree then. > > > and authorized. > > > > If i understand correctly, in both cases authorization is achieved > > through proper configuration of the HA. I mean, the HA knows which > > prefixes are assigned to each MR and the HA can securely communicate > > with the MR using preconfigured IPSec. This applies both to PSBU and the > > prefix sub-option, or there is a difference respecting to this in both > > approaches? > > > MIP6 security > > > scheme only verify MR's home address, but not prefix itself. > > > Our approach provides these verification by using IPsec encryption. SA > > > is established between MR and HA by using MR-A (MR-A is used as the key > > > of encryption), mobile network prefix is verified. > > > > Again, why this can not be used with PSBU messages? > > There is slight difference. > SA is established between HA and MR-A in our id. > SA is established between HA and MR HoA in PSBU. > As you say, if HA has mapping of HoA and prefix, same security can be > provided to PSBU between HA and MR. > > We design protocol to support RO in the future, and our scheme is > well-applied to Return Routability, too. For return routability, this > difference becomes large, because PSBU cannot use RR scheme to protect > BU including prefix. PSBU can not verify the prefix by using HoTI and > HoT. But this RO discussion is currently out of scope at WG. > Ok, however it seems now that a main benefit of the new sub option is its extensibility to the RO case, right? > > > I think this approach > > > is well compliant with current MIP6 spec. Instead, PSBU store all the > > > prefix information in the BU. PSBU needs another way to verify this > > > prefix and also way to notify mapping of home address and mobile network > > > prefixes. > > > > > > > I do not understand why this is so, could you explain it to me? > > I mean HA should know which MR carry which prefix. > > > > > Your last scenario is a kinds of administrative issue. MR may sends BU > > > w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length. > > > > I see, however, the problem illustrated in the figure above remains. > > > > > In fact, I did not mention the situation when MR has multiple mobile > > > network prefixes in the draft. I will add some texts at the next version. > > > Thanks for pointing this out. > > > > > > > Additionally, its impact in the case of nested networks should be also > > > > considered, since it imposes similar constraints to address > > > > administration. My concern is whether the reduction of 64 bits in the BU > > > > messages is worth these additional costs. > > > > > > Optimization is important, but I tried to keep compliance with current > > > MIPv6 spec, because MIPv6 is fully discussed at the IETF and is very "sensitive" > > > protocol indeed. If I added a lot of optimizations for NEMO, many new > > > issues come up. Furthermore, NEMO has many kinds of configuration > > > compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to > > > provide a certain level of optimization by means of "network operation". > > > (e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix > > > length) > > > > > > > Moreover, it assumed that the HA is aware of the prefix that this > > > > particular MR is authorized to announce, because of security reasons. > > > > So, why is not enough with the N bit only? I mean, the MR sends a BU > > > > with the N bit set, and the HA already knows which prefix of the mobile > > > > network (implicit signaling). If i understand the rationale correctly, > > > > when PSBU are used, it is useful since the mobile network can have > > > > multiple prefixes, and the BU can refer to only some of them. If the > > > > prefix sub-option is used, this feature is more restricted since only > > > > aggregates containing the MR-A can be announced. I do not know if i am > > > > missing something, but IMO much flexibility is lost when replacing PSBU > > > > by prefix suboption. > > > > > > For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64 > > > at the beginning. > > > > I don't quite follow you. What do you mean by the beginning? Why this > > information cannot be preconfigured in the HA? Do you have in mind a > > possible scenario where the dynamic of configuring the HA with the > > prefix assigned to the mobile network is insufficient? > > "beginning" is just example. MR can change the prefix length in active > use anytime. > > HA delegates prefix with certain length, but HA does not care which > prefix length MR currently use (of course within delegated length). > > We also consider dynamic configuration. If MR needs larger prefix, MR tries > prefix delegation operation, then generates MR-A from the > appropriate prefix and assigns it to the ingress interface. > MR have to establish SA somehow between HA, too. > Do you have some specific application scenario in mind for this feature? > > > > Then the MR sends BU w/ 64 prefix length instead of 48. > > > Of course, this prefix is belong to the MR, HA can accept BU and > > > intercepts and tunnels packets only for the prefix/64. For these > > > operation, the prefix-suboption is needed. > > > > > > > > My second comment is about the location of the HA. I think that it is > > > > assumed that the HA is co-located with the only router present in the > > > > home-link. I could not find this assumption in the draft, but it is > > > > illustrated in the figure. This assumption is reflected in the behavior > > > > described in section 6.2.2 where it is assumed that all incoming packets > > > > pass through the HA. Is there any reason for this restriction? I think > > > > that the case where multiple routers are present in the home link is a > > > > reasonable case, and it can be easily supported, for instance by means > > > > of redirect from the HA pointing to the alternative router. > > > > Additionally, i think that, as i think it is suggested in > > > > draft-petrescu-nemo-mrha-02, the solution should support that the HA is > > > > a single interface node. I think that the solution can be extended to > > > > support this configurations. > > > > > > Good point, I did not mention this case enough. Delegated prefix is > > > assigned to MR, and HA only advertises the prefix by routing protocol. > > > "Routing protocol" means both IGP and BGP. If there are multiple routers > > > at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in > > > the home link. HA do not send RA of the delegated prefix at the home > > > link, so that it becomes next hop router of the delegated prefix. (Other > > > routers are not on-link of the mobile network prefix). > > > > > > > Ok. however, how this works if the HA is not a router? i mean it only > > has one interface? The communication between the AR and the MR should > > not pass through the HA in this case. That is why my guess is that > > redirects should do the trick. > > The other similar case is when multiple routers exist. In this case, > > again, the communication between the other routers and the HA should not > > pass through the HA. Again, i think the redirects can solve this. > > > Currently, HA is the router. HA is configured as the default router of > the mobile network prefix. Even if the HA has a single interface, HA > could receives packets. > > Am I missing something here? > No, i just meant that if the mobile network is in its home link, and the HA has a single interface, then HA shouldn't be involved in routing packets to the mobile network. In this case, other routers in the home link should send packets directly to the MR (which is on the home link) and the HA only have to stop intercepting packets. Regards, marcelo > regards, > ryuji -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Thu Mar 13 13:20:44 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11510 for ; Thu, 13 Mar 2003 13:20:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DIM4bf031284; Thu, 13 Mar 2003 19:22:04 +0100 Received: from multihop.net ([192.103.16.205]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DILpbf031276 for ; Thu, 13 Mar 2003 19:21:51 +0100 Received: from kniveton.com (localhost [127.0.0.1]) by multihop.net (8.12.8/8.12.8) with SMTP id h2DILh4E014606; Thu, 13 Mar 2003 10:21:43 -0800 (PST) (envelope-from tj@kniveton.com) Received: from 01-113.006.popsite.net ([66.248.81.113]) (SquirrelMail authenticated user tj) by www.kniveton.com with HTTP; Thu, 13 Mar 2003 10:21:44 -0800 (PST) Message-ID: <1394.66.248.81.113.1047579704.squirrel@www.kniveton.com> In-Reply-To: <3E70C19D.6936B1F1@iprg.nokia.com> References: <20030310.172855.27008327.ernst@sfc.wide.ad.jp> <20030313.213450.26709026.ernst@sfc.wide.ad.jp> <3E70C19D.6936B1F1@iprg.nokia.com> Subject: Re: [nemo] NEMO IETF56 Agenda From: "Timothy J. Kniveton" To: "Vijay Devarapalli" Cc: "Thierry Ernst" , nemo@nal.motlabs.com User-Agent: SquirrelMail/1.4.0 RC2a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 10:21:44 -0800 (PST) Hi Vijay, Vijay Devarapalli said: > Thierry Ernst wrote: >> >> - Basic NEMO Support solutions >> draft-wakikawa-nemo-basic-00.txt >> others ? > > draft-kniveton-mobrtr-03.txt? > > IMHO, it is not a great idea for people to present their > solutions. others can read that from the respective drafts. > it would be more useful to focus on the issues, differences > between the solutions and what we really need for the basic > nemo protocol. Thierry and I have discussed the basic solutions draft and how to handle the various aspects at IETF56. draft-kniveton-mobrtr was part of this discussion at all of the past NEMO meetings, and it should not have been left off the reading list, but I believe that simply didn't get edited into the agenda yet, not that it was excluded. Your point is valid about presenting individual solutions. It is best if people can briefly talk about the new drafts that have been submitted since the last IETF (which is why draft-wakikawa is there), and then we will have a discussion about how to combine them. For instance, we can talk about the similarities/differences between the drafts, and then discuss the process on how to come up with a unified solution draft. This is similar to what happened with the requirements draft discussion during the IETF meeting, where I presented all of the existing material, and then Thierry combined the information after the meeting which reflected WG consensus, and served as editor for the unified requirements document which we now have. This process seemed to work well, and we have a similar situation for the basic draft-nemo. But of course some aspects are different and we are dealing with bits and signaling so things are a bit more complicated, but the basic idea is the same. In preparation for the IETF, it is important that people read all of the current basic solution proposals that have already been discussed on the list, and they are available from the NEMO web page. We will revise the agenda item to allow some discussion of this, since it is currently the hot topic in the group's deliverables, so rest assured it will not just be one draft presented! > >> >> - IPv4 traversal for MIPv6 based Mobile Routers 15mins >> draft-thubert-nemo-ipv4-traversal-00.txt >> [get it from http://www.nal.motlabs.com/nemo] > > I havent read this draft yet. but do we need this now? we > dont even have "IPv4 traversal for MIPv6 based Mobile > Hosts". :-) we dont have this in the charter. maybe it > belongs in v6ops? Let's see what people's opinions are. During last meetings, we have had discussions about topics that are not necessarily tops on the to-do list, but I see it as being helpful for the overall discussion not to exclude these totally, as long as the perspective on priorities is kept. Perhaps we can adjust the time scheduling a bit. > > IMO, we should finish up the basic protocol (or atleast > have a mature protocol) before we start taking up new > charter items. > Good point; we will make sure that progress is made on that!! > Vijay > Thanks, TJ From nemo-admin@nal.motlabs.com Thu Mar 13 14:54:47 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15229 for ; Thu, 13 Mar 2003 14:54:45 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DJu4bf000760; Thu, 13 Mar 2003 20:56:04 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2DJt4bf000740 for ; Thu, 13 Mar 2003 20:55:05 +0100 Received: from [192.168.0.3] (pdd8657.tkyoac00.ap.so-net.ne.jp [218.221.134.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2DIwE2u028879; Fri, 14 Mar 2003 03:58:16 +0900 From: Ryuji Wakikawa To: marcelo bagnulo Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt Cc: nemo@nal.motlabs.com In-Reply-To: <1047578157.782.203.camel@presto.it.uc3m.es> References: <1047578157.782.203.camel@presto.it.uc3m.es> Message-Id: <20030314031931.8A9D.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 03:58:14 +0900 Content-Transfer-Encoding: 7bit Hello Marcelo > > On Thu, 2003-03-13 at 17:53, Ryuji Wakikawa wrote: > > Hello Marcelo. > > > > Sorry for replying late. > > > > > > The first motivation of this prefix-suboption is optimization as you've > > > > notice already:) > > > > But, there are other reasons for this now. > > > > > > > > When a MR has multiple prefixes, the MR acquires multiple MR-A at the > > > > ingress interface. The MR have to send BU individually for each mobile > > > > prefix. This is because current MIP6 does not allow to update multiple > > > > binding caches by sending "single" BU (i.e. no optimization for this). > > > > > > Ok. But what happens if the router's interface is not connected to the > > > network that contains the assigned prefix? I mean, more than one segment > > > may exist within a mobile network and the MR do not have to have an > > > interface in each of them. > > > > > > For example, the below configuration: > > > > > > > > > +--+ > > > |MR| > > > +--+ > > > | Pref1::/48 > > > ---------------- > > > | > > > +--+ > > > |R | > > > +--+ > > > | Pref2::/48 > > > ----------------- > > > > > > If i understand correctly, you are proposing that MR ingress interface > > > has two addresses configured i.e. Pref1:Router and Pref2:Router > > > > > > Now when the MR wants to send a packet addressed to Pref2, it will > > > assume it is directly connected if no additional configuration is made, > > > the same goes for R when trying to reach MR through the Pref2:Router > > > address. How do deal with this? > > > > For this situation, we recommends that "R" becomes another MR which > > manage Pref2::/48. I treat this example as nested mobility. > > > > Ok, i guess this would work... > However, wouldn't this introduce additional overhead? > I mean all packets addressed to Pref2 subnet will have 2 tunnels, right? > This seems to be conflicting with the main goal of the modification of > PSBU which was diminishing overhead. Actually, I did not expect this case. We can provide same kinds of network with other configuration (ex. MR provides Pref1 and Pref2 with multiple ingress interfaces.) > Perhaps you could consider an alternative option, such as configuring > something like a router loopback address with Pref2 in MR. I mean, what > if you configure in MR the address Pref2::routeriid with a 128 bit long > prefix? would this break something? > If you can do this, MR can send the BU using this address, and receive > packets addressed to him, but all other addresses of Pref2 subnetwork > could be to R. > I am probably misforwardedsing something here (besides that this seems a nasty > hack) but this would reduce the overhead... Wowoo, this could be additional solution for this case. I did not consider this yet, but this is interesting. I will consider this operation carefully and may put this into draft. > > If R doesn't exist and a MR manages multiple prefixes with an ingress > > interface, MR assigns multiple MR-A to the ingress interface. > > > > > > Since the assignment of multiple mobile network prefixes is equal to > > > > the assignment of multiple home addresses on Mobile IPv6. I am not sure > > > > if it is possible to allow this optimization only for NEMO. There will > > > > be another issues if NEMO allows this optimization. > > > > > > > > PSBU allows to carry prefix and its length in BU, but the prefix stored > > > > in the suboption of BU is not secured > > > > > > Isn't it possible to secure it with IPSec? > > > > How HA verrify that the prefix in suboption belong to the MR? > > > > I think that there was a misunderstanding here.. > using IPSec the HA knows for sure that the prefix contained in the > packet it had received it is the same that the one the MR has included > when creating the packet (this is what i called the BU sub option is > secured) > What IPSec does not provide to HA are tools to determine if this MR is > allowed to announce this prefix (that is what i called authorization) > I guess we agree then. OK, sorry for confusing you. > > > > > and authorized. > > > > > > If i understand correctly, in both cases authorization is achieved > > > through proper configuration of the HA. I mean, the HA knows which > > > prefixes are assigned to each MR and the HA can securely communicate > > > with the MR using preconfigured IPSec. This applies both to PSBU and the > > > prefix sub-option, or there is a difference respecting to this in both > > > approaches? > > > > MIP6 security > > > > scheme only verify MR's home address, but not prefix itself. > > > > Our approach provides these verification by using IPsec encryption. SA > > > > is established between MR and HA by using MR-A (MR-A is used as the key > > > > of encryption), mobile network prefix is verified. > > > > > > Again, why this can not be used with PSBU messages? > > > > There is slight difference. > > SA is established between HA and MR-A in our id. > > SA is established between HA and MR HoA in PSBU. > > As you say, if HA has mapping of HoA and prefix, same security can be > > provided to PSBU between HA and MR. > > > > We design protocol to support RO in the future, and our scheme is > > well-applied to Return Routability, too. For return routability, this > > difference becomes large, because PSBU cannot use RR scheme to protect > > BU including prefix. PSBU can not verify the prefix by using HoTI and > > HoT. But this RO discussion is currently out of scope at WG. > > > > Ok, however it seems now that a main benefit of the new sub option is > its extensibility to the RO case, right? and packet size becomes less than PSBU > > > > I think this approach > > > > is well compliant with current MIP6 spec. Instead, PSBU store all the > > > > prefix information in the BU. PSBU needs another way to verify this > > > > prefix and also way to notify mapping of home address and mobile network > > > > prefixes. > > > > > > > > > > I do not understand why this is so, could you explain it to me? > > > > I mean HA should know which MR carry which prefix. > > > > > > > > Your last scenario is a kinds of administrative issue. MR may sends BU > > > > w/ 47 prefix length or possibly sends 3 BU w/ 48 prefix length. > > > > > > I see, however, the problem illustrated in the figure above remains. > > > > > > > In fact, I did not mention the situation when MR has multiple mobile > > > > network prefixes in the draft. I will add some texts at the next version. > > > > Thanks for pointing this out. > > > > > > > > > Additionally, its impact in the case of nested networks should be also > > > > > considered, since it imposes similar constraints to address > > > > > administration. My concern is whether the reduction of 64 bits in the BU > > > > > messages is worth these additional costs. > > > > > > > > Optimization is important, but I tried to keep compliance with current > > > > MIPv6 spec, because MIPv6 is fully discussed at the IETF and is very "sensitive" > > > > protocol indeed. If I added a lot of optimizations for NEMO, many new > > > > issues come up. Furthermore, NEMO has many kinds of configuration > > > > compared to MIP6. IMHO, it is better to keep NEMO protocol simple and to > > > > provide a certain level of optimization by means of "network operation". > > > > (e.x. sending one BU w/ 47 prefix length vs multiple BU w/ 48 prefix > > > > length) > > > > > > > > > Moreover, it assumed that the HA is aware of the prefix that this > > > > > particular MR is authorized to announce, because of security reasons. > > > > > So, why is not enough with the N bit only? I mean, the MR sends a BU > > > > > with the N bit set, and the HA already knows which prefix of the mobile > > > > > network (implicit signaling). If i understand the rationale correctly, > > > > > when PSBU are used, it is useful since the mobile network can have > > > > > multiple prefixes, and the BU can refer to only some of them. If the > > > > > prefix sub-option is used, this feature is more restricted since only > > > > > aggregates containing the MR-A can be announced. I do not know if i am > > > > > missing something, but IMO much flexibility is lost when replacing PSBU > > > > > by prefix suboption. > > > > > > > > For example, if HA delegates a:b:/48 to a MR, but the MR only needs /64 > > > > at the beginning. > > > > > > I don't quite follow you. What do you mean by the beginning? Why this > > > information cannot be preconfigured in the HA? Do you have in mind a > > > possible scenario where the dynamic of configuring the HA with the > > > prefix assigned to the mobile network is insufficient? > > > > "beginning" is just example. MR can change the prefix length in active > > use anytime. > > > > HA delegates prefix with certain length, but HA does not care which > > prefix length MR currently use (of course within delegated length). > > > > We also consider dynamic configuration. If MR needs larger prefix, MR tries > > prefix delegation operation, then generates MR-A from the > > appropriate prefix and assigns it to the ingress interface. > > MR have to establish SA somehow between HA, too. > > > > Do you have some specific application scenario in mind for this feature? I do not have good example, but... For example, automobile has pre-assigned Pref::/48. Each automobile has a mobile newtork (Pref:1::/64) for control system of engine, car condition monitor. MR basically register the binding w/64 for Pref:1::/64. This network is managed by automobile company. Thus, automobile company may not want to run third-vendor applications on the network (Pref:1::/64). When a driver buy some entertainment box, the driver configures a new prefix for applications to MR. Then MR starts to register the binding with 63 prefix length. > > > > Then the MR sends BU w/ 64 prefix length instead of 48. > > > > Of course, this prefix is belong to the MR, HA can accept BU and > > > > intercepts and tunnels packets only for the prefix/64. For these > > > > operation, the prefix-suboption is needed. > > > > > > > > > > My second comment is about the location of the HA. I think that it is > > > > > assumed that the HA is co-located with the only router present in the > > > > > home-link. I could not find this assumption in the draft, but it is > > > > > illustrated in the figure. This assumption is reflected in the behavior > > > > > described in section 6.2.2 where it is assumed that all incoming packets > > > > > pass through the HA. Is there any reason for this restriction? I think > > > > > that the case where multiple routers are present in the home link is a > > > > > reasonable case, and it can be easily supported, for instance by means > > > > > of redirect from the HA pointing to the alternative router. > > > > > Additionally, i think that, as i think it is suggested in > > > > > draft-petrescu-nemo-mrha-02, the solution should support that the HA is > > > > > a single interface node. I think that the solution can be extended to > > > > > support this configurations. > > > > > > > > Good point, I did not mention this case enough. Delegated prefix is > > > > assigned to MR, and HA only advertises the prefix by routing protocol. > > > > "Routing protocol" means both IGP and BGP. If there are multiple routers > > > > at a home link, HA advertises the delegated prefix by IGP protocol(OSPF) in > > > > the home link. HA do not send RA of the delegated prefix at the home > > > > link, so that it becomes next hop router of the delegated prefix. (Other > > > > routers are not on-link of the mobile network prefix). > > > > > > > > > > Ok. however, how this works if the HA is not a router? i mean it only > > > has one interface? The communication between the AR and the MR should > > > not pass through the HA in this case. That is why my guess is that > > > redirects should do the trick. > > > The other similar case is when multiple routers exist. In this case, > > > again, the communication between the other routers and the HA should not > > > pass through the HA. Again, i think the redirects can solve this. > > > > > > Currently, HA is the router. HA is configured as the default router of > > the mobile network prefix. Even if the HA has a single interface, HA > > could receives packets. > > > > Am I missing something here? > > > No, i just meant that if the mobile network is in its home link, and the > HA has a single interface, then HA shouldn't be involved in routing > packets to the mobile network. In this case, other routers in the home > link should send packets directly to the MR (which is on the home link) > and the HA only have to stop intercepting packets. MR do not advertise route information of its mobile network prefix. HA still receives packets destined to the prefix. HA intercepts packets and forward them to the next-hop MR. In this case, redirect maybe happened. But I think HA should not issue ICMP redirect for mobile network prefix. Regards, ryuji > Regards, marcelo > > > > regards, > > ryuji > -- > marcelo bagnulo > uc3m regards, ryuji From nemo-admin@nal.motlabs.com Thu Mar 13 21:18:49 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29607 for ; Thu, 13 Mar 2003 21:18:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2E2KAbf005385; Fri, 14 Mar 2003 03:20:10 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2E2Jdbf005369 for ; Fri, 14 Mar 2003 03:19:40 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id EA97D5D01E; Fri, 14 Mar 2003 11:19:31 +0900 (JST) Message-Id: <20030314.111931.20495780.ernst@sfc.wide.ad.jp> To: tj@kniveton.com Cc: vijayd@IPRG.nokia.com, nemo@nal.motlabs.com Subject: Re: [nemo] NEMO IETF56 Agenda From: Thierry Ernst In-Reply-To: <1394.66.248.81.113.1047579704.squirrel@www.kniveton.com> References: <20030313.213450.26709026.ernst@sfc.wide.ad.jp> <3E70C19D.6936B1F1@iprg.nokia.com> <1394.66.248.81.113.1047579704.squirrel@www.kniveton.com> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 11:19:31 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Vijay, TJ, > >> - Basic NEMO Support solutions > >> draft-wakikawa-nemo-basic-00.txt > >> others ? > > > > draft-kniveton-mobrtr-03.txt? > > > > IMHO, it is not a great idea for people to present their > > solutions. others can read that from the respective drafts. > > it would be more useful to focus on the issues, differences > > between the solutions and what we really need for the basic > > nemo protocol. > Thierry and I have discussed the basic solutions draft and how to handle > the various aspects at IETF56. draft-kniveton-mobrtr was part of this > discussion at all of the past NEMO meetings, and it should not have been > left off the reading list, but I believe that simply didn't get edited > into the agenda yet, not that it was excluded. To add something to what TJ says, I didn't excluded drafts, I just listed the new one (draft-wakikawa). Also, during the call for slot, I didn't have any request to discuss the past drafts. I agree 100% with Vijay that we need to focus on issues and differences, but the pre-requisite for that is to have drafts authors to claim they have solutions complying the Basic NEMO Support requirements. At this point in time, it's not very clear what drafts for Basic NEMO Support are on the table. So, draft authors, please identify yourself and discuss this on the mailing so that we make an efficient use of our time during the meeting. And then, yes, we can have a discussion turning "how to combine the solutions". > In preparation for the IETF, it is important that people read all of the > current basic solution proposals that have already been discussed on the > list, and they are available from the NEMO web page. We will revise the > agenda item to allow some discussion of this, since it is currently the > hot topic in the group's deliverables, so rest assured it will not just be > one draft presented! > >> - IPv4 traversal for MIPv6 based Mobile Routers 15mins > >> draft-thubert-nemo-ipv4-traversal-00.txt > >> [get it from http://www.nal.motlabs.com/nemo] > > > > I havent read this draft yet. but do we need this now? we > > dont even have "IPv4 traversal for MIPv6 based Mobile > > Hosts". :-) we dont have this in the charter. maybe it > > belongs in v6ops? > > Let's see what people's opinions are. During last meetings, we have had > discussions about topics that are not necessarily tops on the to-do list, > but I see it as being helpful for the overall discussion not to exclude > these totally, as long as the perspective on priorities is kept. Perhaps > we can adjust the time scheduling a bit. > > > > IMO, we should finish up the basic protocol (or atleast > > have a mature protocol) before we start taking up new > > charter items. > Good point; we will make sure that progress is made on that!! I agree all with this, but it also all depends with the people committing to do the work and discuss on the mailing list. Thierry. From nemo-admin@nal.motlabs.com Fri Mar 14 00:54:50 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04441 for ; Fri, 14 Mar 2003 00:54:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2E5u6bf009426; Fri, 14 Mar 2003 06:56:06 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2E5t7bf009413; Fri, 14 Mar 2003 06:55:08 +0100 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8657.tkyoac00.ap.so-net.ne.jp [218.221.134.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2E34q2t000424; Fri, 14 Mar 2003 12:04:54 +0900 Message-ID: From: Ryuji Wakikawa To: petrescu@nal.motlabs.com Cc: marcelo@it.uc3m.es, Erik.Nordmark@sun.com, nemo@nal.motlabs.com, ernst@sfc.wide.ad.jp Subject: Re: [nemo] Re: multihoming (was: about draft-ietf-nemo-requirements-00.txt) In-Reply-To: <3E6E9BBE.8070307@nal.motlabs.com> References: <1047412357.899.255.camel@presto.it.uc3m.es> <3E6E9BBE.8070307@nal.motlabs.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 12:03:40 +0900 Hello Alex. I want to add one comment. At Wed, 12 Mar 2003 03:30:22 +0100, Alexandru Petrescu wrote: > > marcelo bagnulo wrote: > >> I *think* the statement should be about the Nemo solution not > >> *preventing* any form of multihoming, including when there are > >> multiple home prefixes. It would be a bug is Nemo had to do > >> something special to enable any form of multihoming - it just > >> shouldn't prevent them from being used. > >> > > I like this requirement. The problem is that currently there are no > > multi-homing solutions for IPv6 available, so we wouldn't know > > what features shouldn't be prevented :-( > > Are there solutions for IPv4 multi-homing? If yes, then they might > exist for IPv6 too. > > > So, I think that there may be some NEMO specific issues in > > multi-homing. For instance, suppose that a MR has two interfaces. > > Isn't this like an MH (mobile host) that has two interfaces? Can > Mobile IPv6 handle this? Have you noticed any problem in having two > active interfaces on MH and getting RAs on both? With the > implementation I played there was no problem: I had two interfaces up > on the MH and one communication stream between MH and CN, no RO. Each > time that interface received an RA, it sent a BU to HA. The > communication was continuously switched from one interface to the > other. Do you think I can call this behaviour as multi-homing support > for MH? If yes, then I suppose I can call it multi-homing support for > an MR too. I am not quite sure how multi-homing is defined in NEMO, but if multi-homing indicates MR uses multiple interfaces to acquire internet connectivity "simultaneously", please go ahead to read below texts:) If MN has multiple HoAs for each interface, it works. But if MN only has single HoA for all interfaces, it may not work as multihoming MN, because MIP does not allow to register multiple CoAs which are bindined to single HoA. When an interface goes down, MN still has another active interface. In the first case, communication flow can not reach to MN even if MN switches to an active interface, since HoA is changed. But MN can use all interfaces simultaneously. The second case can provide seamless connectivity when MN switches active interface. MN always register the active CoA to HA, but not all CoAs. (i.e. MN can not use multiple interfaces simultaneously) I am not sure if we can call the second case as multihoming MN. Although MN has multiple interfaces, MN just utilizes single interface by switching interface. This MN should be treated as normal MN. In NEMO case, is it acceptable that MR has multiple prefixes for all interfaces which installed in MR? Otherwise, MR may not utilize multiple network interfaces simultaneously. This may become a possible issue. I recently submitted the draft how to register multiple binding for single home address in MIP6 WG. (draft-wakikawa-mip6-multiplecoa-00.txt) If you look at the draft, we explain current problem and propose a simple solution for this. Regards, ryuji > > A possible solution is to set up two tunnels with the HA. > > Yes, there are probably two tunnels if two egress interfaces of MR are > up. Just like when there were two MHs belonging to the same HA. > > > However, what information is contained in the binding cache? The > > mobile network prefix has two entries in the cache? and if one > > path becomes unavailable the correspondent entry is deleted?. > > Yes, simply put, if one interface goes down then it won't reply to > BReqs from HA, so the BC entry times out. > > I would say that if we assume (for a moment) that there is no prefix > entry in the Binding Cache and have in the Binding Cache an entry for > one HoA of one egress interface of MR and another entry for the other > egress interface of MR, then everything will work fine for MR. When > both entries are in the BC, we'll pick the first. When only one is > present, well, we still pick the first. > > > The other option is that only one tunnel is established and when it > > becomes unavailable a new BU to that mobile network prefix is > > issued binding the prefix to the alternative CoA. I think that this > > kind of issues are NEMO specific and are related to multi-homing > > support. > > [Alternative CoA sounds too much like Alternate CoA which is not.] > > Assume a multi-homed fixed host with two interfaces. How does it > choose between those two interfaces? Let's say it does so based on > the destination address: if the destination address is site-local and > one interface has a site-local address on it then use that interface, > otherwise use the second interface. This is an example and is nothing > new, it's in "default address selection". > > Assume now a multi-homed mobile host with two interfaces. If the > destination is site local and one interface has a home address that is > site local, then use that interface as _the_ tunnel. This is clearly > Mobile IPv6-specific, and not NEMO specific. > > Assume now a multi-homed mobile router with two interfaces. If the > destination is site local and one interface has a home address that is > site local, then use that interface as _the_ tunnel. This is exactly > like Mobile IPv6 for hosts, nothing new. > > In most other cases that I've seen discussed, it was an application > (not the IP stack) decides to use interface 1, instead of interface 2. > Then again, with a mobile router, an application on MR will decide to > use interface 1 instead of 2, again nothing new. > > I mentioned "applications" because there are potentially too many > additional types of indices a host will use to distinguish one > interface instead of the other: > -if the respective technology is available (e.g. receive WLAN beacon) > and the other isn't. > -if one interface gives higher bandwidth than the other. > -if one interface gives cheaper bandwidth than the other. > -if one interface gives more secure bandwidth than the other. > -if one interface gives more private bandwidth than the other. > -DiVX file on one interface and an MP3 on the other interface, > simultaneously. > -any mixture of the above. > > Imagine that we engage in designing a MR that uses all the above as a > criterion to prefer one interface to the other. That's an enormous > amount of work, involving coordination with a large number of groups. > > The alternative would be that we just make sure that MR works fine > even if there are two active egress interfaces, or that the mobile > network works fine even if it has two MR's connecting it to the > Internet. "Works fine" means that the MNNs are reachable all the time > at a permanent home address and that their communication with CNs is > not interrupted when MRs change their CoA. So we can try to make sure > it works fine. > > -- > Message Classification: GBU From nemo-admin@nal.motlabs.com Fri Mar 14 04:20:28 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19884 for ; Fri, 14 Mar 2003 04:20:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2E9LVbf013634; Fri, 14 Mar 2003 10:21:32 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2E9KSbf013624 for ; Fri, 14 Mar 2003 10:20:28 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2E9Jju5014205; Fri, 14 Mar 2003 02:19:45 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA06173; Fri, 14 Mar 2003 02:18:16 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h2E9KCt17869; Fri, 14 Mar 2003 03:20:14 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A38B12EC86; Fri, 14 Mar 2003 10:20:10 +0100 (CET) Message-ID: <3E719ECA.5060408@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Cc: , , Subject: Re: [nemo] NEMO IETF56 Agenda References: <20030313.213450.26709026.ernst@sfc.wide.ad.jp> <3E70C19D.6936B1F1@iprg.nokia.com> <1394.66.248.81.113.1047579704.squirrel@www.kniveton.com> <20030314.111931.20495780.ernst@sfc.wide.ad.jp> In-Reply-To: <20030314.111931.20495780.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 10:20:10 +0100 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > I agree 100% with Vijay that we need to focus on issues and > differences, but the pre-requisite for that is to have drafts > authors to claim they have solutions complying the Basic NEMO > Support requirements. Thierry, thank you for asking. The annex of draft-petrescu-nemo-mrha-02.txt describes potential high-level behaviour of MR and HA that go along the lines of basic NEMO support requirements (that have minimal modifs to Mobile IPv6 for hosts). The draft itself is not a solution per se (if filename is nemo-mrha it's only because nemo-mrha-issues was too long). The 01 version of this draft was presented at last IETF so we don't feel a new slot is necessary, because changes are mainly cosmetic, with only these two relatively minor additions: -HA ingress filtering discussion; Vijay might know more. -cross-over tunnels issue. But we do welcome and are interested to see all discussion that compares draft-wakikawa vs draft-kniveton vs no-prefixes-in-BU vs any other issue. From nemo-admin@nal.motlabs.com Fri Mar 14 09:24:04 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25933 for ; Fri, 14 Mar 2003 09:24:02 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2EEP7bf019099; Fri, 14 Mar 2003 15:25:09 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2EEIobf019024; Fri, 14 Mar 2003 15:18:51 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2EEImIG016018; Fri, 14 Mar 2003 07:18:48 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA25167; Fri, 14 Mar 2003 07:16:44 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h2EEFXD08299; Fri, 14 Mar 2003 08:15:34 -0600 Received: from crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2BA2B2EC86; Fri, 14 Mar 2003 15:15:32 +0100 (CET) Message-ID: <3E71E403.60400@crm.mot.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Cc: , , , , Subject: Re: [nemo] Re: multihoming (was: about draft-ietf-nemo-requirements-00.txt) References: <1047412357.899.255.camel@presto.it.uc3m.es> <3E6E9BBE.8070307@nal.motlabs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 15:15:31 +0100 Content-Transfer-Encoding: 7bit Hi Ryuji, thanks for reply. Ryuji Wakikawa wrote: > If MN has multiple HoAs for each interface, it works. But if MN > only has single HoA for all interfaces, it may not work as > multihoming MN, because MIP does not allow to register multiple > CoAs which are bindined to single HoA. Yes, one HoA with 2 CoAs don't work, and the "alternate CoA" field is there but for other reasons. One should take care with this reasoning. Until now it went like this: one fixed HoA, but at different subsequent locations, so invent the CoA concept. It is risky to go on with this reasoning and arrive at a conclusion like this: one HoA with many CareOf-CoAs and with many many CoAs. One can't just say: permanent HoA, variable CareOf-CoA, hyper-variable CoA. Because, if we say so, then what is that permamentest entity to which you will assign the CareOf-CoA? It clearly is not an interface because you can have two interfaces of a machine (hence multi-homing). Is it a processor? No, because there are multi-processor machines, so if one processor goes down, then the other processor comes up, so you'll need CareOf-CareOf-CoAs. Whatever we say now that is permanent fixed an unique then we will need one day to duplicate it. What we can do for multi-homing is to have two HoAs each one with its own CoA, simple and comprehensible (to me, but remark that there others for whom even this is a radical departure). > When an interface goes down, MN still has another active interface. > > > > > > > > > > > > > This is the essence of all we're discussing here and is the motivation not only of "multi-homing" but of many other concepts. > In the first case, communication flow can not reach to MN even if > MN switches to an active interface, since HoA is changed. Hence a problem. But I don't see this as a Mobile IPv6 problem. Have one fixed host with two IP addresses on it, not mobile, not multi-homed. But have two IP addresses on it. Start a connection and then change choose the other address. Everything breaks. This has been so for centuries, right? :-) Again, put the MN at home, don't move it and assign two HoAs to it. Launch an application, change the HoA and everything breaks. You don't need to move for that to break, it just breaks. If it broked when the host moved, then it would have been a Mobile IPv6 problem. > I recently submitted the draft how to register multiple binding for > single home address in MIP6 WG. Ok, I need to read it, thanks for your message. -- Message Classification: MIUO From nemo-admin@nal.motlabs.com Fri Mar 14 09:27:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25976 for ; Fri, 14 Mar 2003 09:27:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2EET3bf019152; Fri, 14 Mar 2003 15:29:03 +0100 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2EERCbf019120 for ; Fri, 14 Mar 2003 15:27:13 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 6177A68A14 for ; Fri, 14 Mar 2003 09:27:05 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2EER47h005602; Fri, 14 Mar 2003 09:27:04 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (ras114.lerc.nasa.gov [139.88.123.114]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2EEQtcF016530; Fri, 14 Mar 2003 09:27:01 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030313233019.00b13ac8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Vijay Devarapalli From: William D Ivancic Subject: Re: [nemo] comments on the requirements draft Cc: nemo@nal.motlabs.com In-Reply-To: <3E6FF2E3.4830FCBD@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 13 Mar 2003 23:34:24 -0500 I believe this should be a MUST. Multihoming is my normal mode of operation. The systems I deal with want to connect to 802.11, multiple satellite networks, G3 wireless, wired and whatever else may be available. Will > > > > R12: The solution MUST function for multi-homed mobile networks. > > More precisely: > > > >multihoming is a complex issue. there are issues even with >multi-home mobile nodes. I think this requirement needs to >be removed. or reworded to say the solution should not prevent >a multi-home mobile network from functioning properly. From nemo-admin@nal.motlabs.com Fri Mar 14 20:10:53 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21839 for ; Fri, 14 Mar 2003 20:10:52 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2F1C9RC028277; Sat, 15 Mar 2003 02:12:10 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2F1BWRC028267; Sat, 15 Mar 2003 02:11:33 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA08623; Fri, 14 Mar 2003 17:11:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2F1BPa11588; Fri, 14 Mar 2003 17:11:25 -0800 X-mProtect: <200303150111> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9Sob1Z; Fri, 14 Mar 2003 17:11:23 PST Message-ID: <3E727DBC.9ABDB5C3@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Ryuji Wakikawa CC: petrescu@nal.motlabs.com, nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt References: <3E59FF2D.9040707@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 17:11:24 -0800 Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > > Hello Alex. > > > Maybe you have a more detailed view on how HA intercepts packets > > destined to the registered mobile network prefix. Is it something > > like HA snoops at those packets? Or is it more like HA uses > > unsolicited broadcasted NA to pretend having MNN's L3 address? > > Since HA is an end-router for the prefix on the Internet > (i.e. advertising mobile network prefix by routing protocol), HA will > receive all packets destined to a mobile network prefix. During IP > forwarding procedure, HA looks up binding cache and finds a prefix > binding. Therefore, HA can tunnel all these packets to MR. I dont agree with this. I think it is wrong to assume that packets meant for the mobile network will always reach the the HA which has the prefix scoped binding cache entry. you could have a border router in the home link which could receive the packets meant for the mobile network. if you want the border router to forward the packets to the HA, it needs to know that the HA can reach the mobile router. Vijay From nemo-admin@nal.motlabs.com Fri Mar 14 21:05:26 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22837 for ; Fri, 14 Mar 2003 21:05:24 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2F276RC029057; Sat, 15 Mar 2003 03:07:06 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2F26iRC029032 for ; Sat, 15 Mar 2003 03:06:45 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA10245; Fri, 14 Mar 2003 18:06:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2F26ZV09151; Fri, 14 Mar 2003 18:06:35 -0800 X-mProtect: <200303150206> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwfqr2U; Fri, 14 Mar 2003 18:06:33 PST Message-ID: <3E728AA9.E20C3941@iprg.nokia.com> From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: William D Ivancic CC: nemo@nal.motlabs.com Subject: Re: [nemo] comments on the requirements draft References: <5.1.1.5.2.20030313233019.00b13ac8@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 14 Mar 2003 18:06:33 -0800 Content-Transfer-Encoding: 7bit William D Ivancic wrote: > > I believe this should be a MUST. Multihoming is my normal mode of > operation. The systems I deal with want to connect to 802.11, multiple > satellite networks, G3 wireless, wired and whatever else may be available. ofcourse the system should be able to connect with whatever interface it wants to. but in your system, does the mobile network maintain two simultaneous uplinks (either through multiple interfaces on the MR, or through multiple MRs)? this is what I consider as multi-homing. it is not multi-homed just because the MR has more than one interface (or just because the mobile network can connect to an access network through two different mobile routers). if the MR maintains two simultaneous uplinks, which HoA does it register with the HA? with current MIPv6 spec, a HA cannot maintain more than one binding cache entry for the same HoA. lets assume the MR (or the mobile network) has different home addresses for the two uplinks. then it can create two binding cache entries. but which tunnel does the HA select if it wants to forward packets to the mobile network? Vijay From nemo-admin@nal.motlabs.com Sat Mar 15 15:05:33 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23887 for ; Sat, 15 Mar 2003 15:05:33 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2FK6TRC008710; Sat, 15 Mar 2003 21:06:29 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2FK4xRC008689 for ; Sat, 15 Mar 2003 21:05:02 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 60F73431A8; Sat, 15 Mar 2003 21:05:00 +0100 (CET) Received: from vpn-252-78.uc3m.es (vpn-252-78.uc3m.es [163.117.252.78]) by smtp02.uc3m.es (Postfix) with ESMTP id D410599F39; Sat, 15 Mar 2003 21:04:45 +0100 (CET) Subject: Re: [nemo] about draft-wakikawa-nemo-basic-00.txt From: marcelo bagnulo To: Ryuji Wakikawa Cc: nemo@nal.motlabs.com In-Reply-To: <20030314031931.8A9D.RYUJI@sfc.wide.ad.jp> References: <1047578157.782.203.camel@presto.it.uc3m.es> <20030314031931.8A9D.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain Organization: uc3m Message-Id: <1047728793.727.4.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 15 Mar 2003 21:04:39 +0100 Content-Transfer-Encoding: 7bit > > No, i just meant that if the mobile network is in its home link, and the > > HA has a single interface, then HA shouldn't be involved in routing > > packets to the mobile network. In this case, other routers in the home > > link should send packets directly to the MR (which is on the home link) > > and the HA only have to stop intercepting packets. > > MR do not advertise route information of its mobile network prefix. > HA still receives packets destined to the prefix. > HA intercepts packets and forward them to the next-hop MR Why is this? I would have thought that when the MR returns home, it announces so to the HA and starts advertising the mobile network prefix so that packets are directly coursed to the MR. This would provide a more efficient path. Am i missing something? > In this case, redirect maybe happened. But I think HA should not issue > ICMP redirect for mobile network prefix. Why is that? Regards, m > > > Regards, > ryuji > > > Regards, marcelo > > > > > > > regards, > > > ryuji > > -- > > marcelo bagnulo > > uc3m > > regards, > ryuji -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Sat Mar 15 19:23:37 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00485 for ; Sat, 15 Mar 2003 19:23:36 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2G0P7RC010446; Sun, 16 Mar 2003 01:25:07 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2G0O2RC010418 for ; Sun, 16 Mar 2003 01:24:03 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2G0KoT9020866; Sun, 16 Mar 2003 01:22:13 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 16 Mar 2003 01:22:45 +0100 content-class: urn:content-classes:message Subject: RE: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 Message-ID: Thread-Topic: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? Thread-Index: AcLqkFfHasItNIm/QaOYm+z/B0BUJAAv705g From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" Cc: X-OriginalArrivalTime: 16 Mar 2003 00:22:45.0497 (UTC) FILETIME=[2AA30E90:01C2EB52] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2G0O2RC010418 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 00:22:45 -0000 Content-Transfer-Encoding: 8bit Actually if you look at it, with this draft, there is no classical home network at all. So there is no concept of interception, of DAD for the home address etc... All you have is an aggregation that can be advertized at all time by the Has. Looks cool, but: - the binding cache acts as a second routing table, that actually has precedence over the classical one. I did not expect you'd do that. I thought that there'd be a route to the prefix via the home address, and that the binding would impact the tunnel, not the route. If it's really a routing table, then, IMHO, the way the binding routes are redistributed should be considered in more details in the next version. - additional work could be required to cover the case of multiple HAs. In MIPv6, the detection of multiple registration id done by DAD on the home network. Since there is no home network, the detection of double registration has to be done at the routing protocol level (When the same net is registered to a 2nd, different HA, it should reject it if it got a route from the first HA... Something like that. Note that as we discussed earlier, the fine grained info should be contained in the HAs. - as you see from both point above, the problems we are facing in MIP with the interaction of ND and MIP did not go away, they moved. Pascal > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: samedi 15 mars 2003 02:11 > To: Ryuji Wakikawa > Cc: petrescu@nal.motlabs.com; nemo@nal.motlabs.com > Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt > > > Ryuji Wakikawa wrote: > > > > Hello Alex. > > > > > Maybe you have a more detailed view on how HA intercepts packets > > > destined to the registered mobile network prefix. Is it > something > > > like HA snoops at those packets? Or is it more like HA uses > > > unsolicited broadcasted NA to pretend having MNN's L3 address? > > > > Since HA is an end-router for the prefix on the Internet (i.e. > > advertising mobile network prefix by routing protocol), HA will > > receive all packets destined to a mobile network prefix. During IP > > forwarding procedure, HA looks up binding cache and finds a prefix > > binding. Therefore, HA can tunnel all these packets to MR. > > I dont agree with this. I think it is wrong to assume that > packets meant for the mobile network will always reach the > the HA which has the prefix scoped binding cache entry. you > could have a border router in the home link which could > receive the packets meant for the mobile network. > > if you want the border router to forward the packets to the > HA, it needs to know that the HA can reach the mobile router. > > Vijay > From nemo-admin@nal.motlabs.com Sun Mar 16 01:05:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06621 for ; Sun, 16 Mar 2003 01:05:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2G667RC026140; Sun, 16 Mar 2003 07:06:08 +0100 Received: from multihop.net ([192.103.16.205]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2G65sRC026124 for ; Sun, 16 Mar 2003 07:05:55 +0100 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.8/8.12.8) with ESMTP id h2G65q4E025687 for ; Sat, 15 Mar 2003 22:05:52 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: NeMo Discussion Subscribers Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] Info about JABBER and request for a "scribe" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 15 Mar 2003 22:05:32 -0800 Content-Transfer-Encoding: 7bit During this IETF, there is once again a Jabber text conferencing capability which will be made available. This will allow the meeting scribe to record the activities and questions at the meeting, so that (a) people who are not present can know what's happening and possibly ask questions, and (b) minutes can be transcribed from the text conferencing session. Is there anyone on the list who has a Jabber client installed or has time to do so before the meeting, and wants to take notes in the Jabber session? Here is the information from Marshall Rose, for those who want to prepare to do this, or anyone who wants to watch the session: Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 2. At the meeting [...] Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: nemo Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/nemo/ NOTE: the logging facility will not be active until later this week... ####### Dean Willis says: But why struggle with Jabber when you can dance with something far more entertaining? Last meeting, several of the folks were successful at using SIP clients with Jiri Kuthan and iptel.orgs's Jabber/SIP gateway, which I think they will probably bring back for this meeting. Jiri's stuff is mostly available at www.iptel.org, so check it out . . . Thanks TJ From nemo-admin@nal.motlabs.com Sun Mar 16 12:30:26 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00087 for ; Sun, 16 Mar 2003 12:30:24 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GHVARC012524; Sun, 16 Mar 2003 18:31:10 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GHU7RC012450 for ; Sun, 16 Mar 2003 18:30:08 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2GHTFu5014478; Sun, 16 Mar 2003 10:29:16 -0700 (MST) Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA25078; Sun, 16 Mar 2003 10:29:53 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id h2GHTjg24036; Sun, 16 Mar 2003 11:29:45 -0600 Received: from nal.motlabs.com (t-il06ac-port14.corp.mot.com [129.188.170.128]) by thorgal.crm.mot.com (Postfix) with ESMTP id 2BF392EC86; Sun, 16 Mar 2003 18:29:43 +0100 (CET) Message-ID: <3E74C286.8070101@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: William D Ivancic, Subject: Re: [nemo] comments on the requirements draft References: <5.1.1.5.2.20030313233019.00b13ac8@popserve.grc.nasa.gov> <3E728AA9.E20C3941@iprg.nokia.com> In-Reply-To: <3E728AA9.E20C3941@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 19:29:26 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> I believe this should be a MUST. Multihoming is my normal mode >> of operation. The systems I deal with want to connect to >> 802.11, multiple satellite networks, G3 wireless, wired and >> whatever else may be available. > > [...] but which tunnel does the HA select if it wants to forward > packets to the mobile network? If there are two entries keyed by the same HoA, HA could select the tunnel of the first entry, why not. This is not to say that something better could not be done. From nemo-admin@nal.motlabs.com Sun Mar 16 12:49:44 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00633 for ; Sun, 16 Mar 2003 12:49:42 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GHp3RC013112; Sun, 16 Mar 2003 18:51:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GHotRC013092; Sun, 16 Mar 2003 18:50:57 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2GHmqi6013459; Sun, 16 Mar 2003 18:48:53 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sun, 16 Mar 2003 18:50:35 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] comments on the requirements draft X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 Message-ID: Thread-Topic: [nemo] comments on the requirements draft Thread-Index: AcLr4lKk1bVV879aRTu7ewZldedoegAATF2w From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: "William D Ivancic" , X-OriginalArrivalTime: 16 Mar 2003 17:50:35.0142 (UTC) FILETIME=[8BDD9260:01C2EBE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2GHotRC013092 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 17:50:34 -0000 Content-Transfer-Encoding: 8bit > Vijay Devarapalli wrote: > >> I believe this should be a MUST. Multihoming is my normal mode > >> of operation. The systems I deal with want to connect to > >> 802.11, multiple satellite networks, G3 wireless, wired and > >> whatever else may be available. > > > > [...] but which tunnel does the HA select if it wants to forward > > packets to the mobile network? > > If there are two entries keyed by the same HoA, HA could > select the tunnel of the first entry, why not. > > This is not to say that something better could not be done. > > I thought basic nemo was exempt of parallel tunnels. When we extend it, I'll be in favor of multiple CoA/tunnels in order to acquire more bandwidth, smoothen handovers and be more resilient to loss of connectivity. From nemo-admin@nal.motlabs.com Sun Mar 16 13:10:42 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01101 for ; Sun, 16 Mar 2003 13:10:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GIC4RC013493; Sun, 16 Mar 2003 19:12:04 +0100 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GIBkRC013483 for ; Sun, 16 Mar 2003 19:11:46 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22669; Sun, 16 Mar 2003 10:11:31 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIBTP05850; Sun, 16 Mar 2003 19:11:29 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt To: marcelo bagnulo Cc: Erik Nordmark , IETF NEMO , ernst@sfc.wide.ad.jp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 19:07:31 +0100 (CET) > I think i misunderstood your initial statement where you said that "I > *think* the statement should be about the Nemo solution not *preventing* > any form of multihoming, including when there are multiple home > prefixes..." > > I thought that we were considering the case of a multi-homed home > network i.e. the site that contains the HA is multihomed, so the mobile > network is just another network within the site and the NEMO solution > should not prevent that the site multi-homing solution adopted works > properly. > (My answer to that is that i agree but there are no solutions for site > multi-homing available right now) Sure there are - they are just far from ideal. IPv6 site multihoming can be done today the same way as in IPv4 - far from ideal because of scaling implications. We want something better for the size internet we are likely to see during the lifetime of IPv6. And IPv6 site multihoming can be done by having multiple prefixes resulting multiple addressses for every host. ALso far from ideal because the hosts and applications need to do address selection and there is a loss of policy control that exists when one prefix is used for the site. Thus there are no existing solutions to IPv6 multihoming which have reached nirvana status. But anyhow, I don't understand what your statements about the status of IPv6 multihoming are revelant to Nemo. Erik From nemo-admin@nal.motlabs.com Sun Mar 16 13:42:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02242 for ; Sun, 16 Mar 2003 13:42:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GIi6RC013969; Sun, 16 Mar 2003 19:44:06 +0100 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GIhjRC013950 for ; Sun, 16 Mar 2003 19:43:46 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15554; Sun, 16 Mar 2003 11:43:42 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2GIhdP07652; Sun, 16 Mar 2003 19:43:39 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] NEMO IETF56 Agenda To: Thierry Ernst Cc: tj@kniveton.com, vijayd@iprg.nokia.com, nemo@nal.motlabs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 19:39:41 +0100 (CET) > > > IMO, we should finish up the basic protocol (or atleast > > > have a mature protocol) before we start taking up new > > > charter items. > > Good point; we will make sure that progress is made on that!! > > I agree all with this, but it also all depends with the people > committing to do the work and discuss on the mailing list. But if people can't finish the foundation before they start building the 4th floor of the building, then I think the AD should prevent injuries from a collapsing building by closing the WG. We don't have to do everything serially, but let's focus the energy on the foundation pieces for now. Erik From nemo-admin@nal.motlabs.com Sun Mar 16 16:47:12 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09370 for ; Sun, 16 Mar 2003 16:47:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GLmVRC019390; Sun, 16 Mar 2003 22:48:32 +0100 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GLl7RC019329 for ; Sun, 16 Mar 2003 22:47:08 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 490876B9EF for ; Sun, 16 Mar 2003 16:47:01 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2GLl07h001814; Sun, 16 Mar 2003 16:47:00 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-21.lerc.nasa.gov [139.88.246.21]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2GLkwcB029342; Sun, 16 Mar 2003 16:46:59 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030316020541.022ebdc8@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Vijay Devarapalli From: William D Ivancic Subject: Re: [nemo] comments on the requirements draft Cc: nemo@nal.motlabs.com In-Reply-To: <3E728AA9.E20C3941@iprg.nokia.com> References: <5.1.1.5.2.20030313233019.00b13ac8@popserve.grc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 02:09:42 -0500 At 06:06 PM 3/14/2003 -0800, Vijay Devarapalli wrote: >William D Ivancic wrote: > > > > I believe this should be a MUST. Multihoming is my normal mode of > > operation. The systems I deal with want to connect to 802.11, multiple > > satellite networks, G3 wireless, wired and whatever else may be available. > >ofcourse the system should be able to connect with whatever >interface it wants to. but in your system, does the mobile >network maintain two simultaneous uplinks (either through >multiple interfaces on the MR, Yes. Two of more simultaneous uplinks via multiple interfaces on the MR. Only one HA. The interface used is the one of highest priority. Priority can be defined by cost in dollars, bandwidth, delay, IP address or just predefined preference. Will From nemo-admin@nal.motlabs.com Sun Mar 16 18:51:33 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13411 for ; Sun, 16 Mar 2003 18:51:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GNr6RC022182; Mon, 17 Mar 2003 00:53:06 +0100 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2GNqqRC022174 for ; Mon, 17 Mar 2003 00:52:53 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 8571B6B9D0 for ; Sun, 16 Mar 2003 18:52:46 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2GNqk7h014292 for ; Sun, 16 Mar 2003 18:52:46 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp1-20.lerc.nasa.gov [139.88.245.20]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2GNqicB012980 for ; Sun, 16 Mar 2003 18:52:45 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030316173044.022d9e60@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: nemo@nal.motlabs.com From: William D Ivancic Subject: RE: [nemo] IPv4 traversal "draft-thubert-nemo-ipv4-traversal-00" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 18:02:34 -0500 I definitely have a need for ipv4 transversal as well as NAT and PAT transversal. I am currently working on deploying a ipv6 nemos over both ipv6 and ipv4 networks. Today, ipv4 is much more prevalent than ipv6 and many wireless WAN providers such as satellite provides currently have not realized a business case to deploy ipv6. I believe providing for easy transversal and interoperability of ipv4 and ipv6 will greatly aid in deployment and adoption of ipv6. I am trying to work with the aeronautics community and hopefully Eurocontrol to demonstrate the usefulness of ipv6 nemos for there applications as well as use of multiple networks. I have posted both the mobile and home network concept architecture at the following URL: http://roland.grc.nasa.gov/~ivancic/nemo/ Note that to date, all the satellite providers and DSL providers I am aware of support ipv4 networks. Many of the satellite systems also utilize NATs. Thus, there is a need to transverse ipv4 networks in a automated fashion and to pass through both NATs and PATs. There is a movement toward use of IPv6 for air traffic command. This is happening in the European Aeronautical Telecommunication Network backbone. The next obvious step it to use IPv6 on the air/ground link. Eurocontrol is very interested in working with NASA to show mobile networking over IPv4 and IPv6. NASA has been working with industry partners on IPv4 and most recently IPv6. The refereced two drawings showing a potential network layout to test these concepts. Air traffic management is currently performed at VHF frequencies over a VHF Data Link (VDL) radio which has, at best, 8 kbps. I want to show that one can use IPv4 and IPv6 networks to move between various networks and that one could perform Quality-of -Service on the mobile router. I want to prove that we can pass air traffic management and other to an aircraft over both the VDL radios (and associated network) and other networks such as Globalstar, INMARSAT, Connexion by Boeing or some other mobile Ku-Band satellite system, 802.11 wireless networks and wired links. Will >draft-thubert-nemo-ipv4-traversal-00 >....draft USES MIPv6 to store the IPv4/UDP states. It all ends up in the >binding cache, and nowhere else in the network (but the NAT itself). The >PAT is maintained by MIP flows. The traversal only works for MIP MNs, >not for any node like Teredo, and uses MIP to setup the tunnel, not TSP. >....... >Pascal > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > > Sent: mardi 11 mars 2003 16:13 > > To: Pascal Thubert (pthubert) > > Cc: nemo@nal.motlabs.com > > Subject: Re: [nemo] IPv4 traversal > > > > > > > I prepared a paper on Ipv4 traversal, > > > draft-thubert-nemo-ipv4-traversal-00.txt, but it's too late > > to submit > > > (cut off till 3/17). I can send direct copies in the meantime. > > > > How does this relate to > > draft-parent-blanchet-ngtrans-tsp-teredo-00.txt > > and draft-ietf-mobileip-nat-traversal-07.txt? > > > > Erik > > > > > > From nemo-admin@nal.motlabs.com Sun Mar 16 20:20:44 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14885 for ; Sun, 16 Mar 2003 20:20:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2H1M7RC023655; Mon, 17 Mar 2003 02:22:07 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2H1LRRC023621; Mon, 17 Mar 2003 02:21:27 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA22166; Sun, 16 Mar 2003 17:21:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2H1L9P02174; Sun, 16 Mar 2003 17:21:09 -0800 X-mProtect: <200303170121> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd0nunhs; Sun, 16 Mar 2003 17:21:07 PST Message-ID: <3E752302.6090404@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: William D Ivancic , nemo@nal.motlabs.com Subject: Re: [nemo] comments on the requirements draft References: <5.1.1.5.2.20030313233019.00b13ac8@popserve.grc.nasa.gov> <3E728AA9.E20C3941@iprg.nokia.com> <3E74C286.8070101@nal.motlabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sun, 16 Mar 2003 17:21:06 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >>> I believe this should be a MUST. Multihoming is my normal mode of >>> operation. The systems I deal with want to connect to 802.11, >>> multiple satellite networks, G3 wireless, wired and whatever else may >>> be available. >> >> >> [...] but which tunnel does the HA select if it wants to forward >> packets to the mobile network? > > > If there are two entries keyed by the same HoA, HA could select the > tunnel of the first entry, why not. the first entry could result in a low bandwidth link. (?) Vijay From nemo-admin@nal.motlabs.com Sun Mar 16 20:24:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14941 for ; Sun, 16 Mar 2003 20:24:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2H1Q2RC023824; Mon, 17 Mar 2003 02:26:02 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2H1OSRC023757 for ; Mon, 17 Mar 2003 02:24:29 +0100 Received: from [130.129.132.211] (wl-132-211.wireless.ietf56.ietf.org [130.129.132.211]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2H1O12u031671; Mon, 17 Mar 2003 10:24:02 +0900 From: Ryuji Wakikawa To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? Cc: In-Reply-To: References: Message-Id: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.01 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 17 Mar 2003 10:24:04 +0900 Content-Transfer-Encoding: 7bit Hello Pascal. Thanks for the mail. There was misunderstanding of "returning home link". Pascal you are right, this id does not have actual home network. Home link is not general home network, but the link which HA is managing. > Actually if you look at it, with this draft, there is no classical home > network at all. So there is no concept of interception, of DAD for the > home address etc... All you have is an aggregation that can be > advertized at all time by the Has. Looks cool, but: > > - the binding cache acts as a second routing table, that actually has > precedence over the classical one. I did not expect you'd do that. I > thought that there'd be a route to the prefix via the home address, and > that the binding would impact the tunnel, not the route. If it's really > a routing table, then, IMHO, the way the binding routes are > redistributed should be considered in more details in the next version. I think I should clarify how the routes on HA are set up. HA has a route and a binding like Route destination -> next hop mobile network prefix -> gif0 Binding home prefix -> CoA MR-A/64(mobile network prefix) -> MR-CoA HA advertise route of mobile network to routers Thus, these routers will have the below route. Route destination -> next hop mobile network prefix -> HA Routers route packets meant for the mobile network to HA. Then,HA intercepts and conceptually routes them to MR-CoA via the tunnel interface, because HA has the route of mobile network prefix and the next hope is the tunnel interface. At protocol(implementation) point of view, HA searches binding cache and tunnel packets to MR-CoA. > - additional work could be required to cover the case of multiple HAs. > In MIPv6, the detection of multiple registration id done by DAD on the > home network. Since there is no home network, the detection of double > registration has to be done at the routing protocol level (When the same > net is registered to a 2nd, different HA, it should reject it if it got > a route from the first HA... Something like that. Note that as we > discussed earlier, the fine grained info should be contained in the HAs. MR can register MR-CoA several HAs simultaneously, because our id does not have "general Home Link". Furthermore, the below configuration is possible. HAs can be placed anywhere on the Internet. There is no restriction such as home network. MR can have either single egress interface or multiple egress interfaces. HA1 -------------Internet-------------------HA2 | | +==================== MR =====================+ tunnel 1 | tunnel2 ------------- mobile network If multiple HAs have binding of MR, each HA advertises the route of mobile network prefix with different "routing metric". This achieves redundancy of HA. If the primary HA goes down, all packets destined to mobile network prefix is routed to another HA, because the mobile network prefix route advertised by the primary HA is deleted. MR can register different CoA to each HA. MR can utilize multiple egress interfaces simultaneously. This provides multiple network interface support of MR (efficient bandwidth, low delay, etc). The decision of interface selection depends on route of mobile network prefix advertised by HAs. Consistency of binding on multiple HAs may be possible issues. Regards, ryuji > Pascal > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: samedi 15 mars 2003 02:11 > > To: Ryuji Wakikawa > > Cc: petrescu@nal.motlabs.com; nemo@nal.motlabs.com > > Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt > > > > > > Ryuji Wakikawa wrote: > > > > > > Hello Alex. > > > > > > > Maybe you have a more detailed view on how HA intercepts packets > > > > destined> > destined to the registered mobile network prefix. Is it > > something > > > > like HA snoops at those packets? Or is it more like HA uses > > > > unsolicited broadcasted NA to pretend having MNN's L3 address? > > > > > > Since HA is an end-router for the prefix on the Internet (i.e. > > > advertising mobile network prefix by routing protocol), HA will > > > receive all packets destined to a mobile network prefix. During IP > > > forwarding procedure, HA looks up binding cache and finds a prefix > > > binding. Therefore, HA can tunnel all these packets to MR. > > > > I dont agree with this. I think it is wrong to assume that > > packets meant for the mobile network will always reach the > > the HA which has the prefix scoped binding cache entry. you > > could have a border router in the home link which could > > receive the packets meant for the mobile network. > > > > if you want the border router to forward the packets to the > > HA, it needs to know that the HA can reach the mobile router. > > > > Vijay > > regards, ryuji From nemo-admin@nal.motlabs.com Mon Mar 17 05:00:11 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09067 for ; Mon, 17 Mar 2003 05:00:10 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HA09RC006678; Mon, 17 Mar 2003 11:00:09 +0100 Received: from smtp.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2H9xHRC006658 for ; Mon, 17 Mar 2003 10:59:19 +0100 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 3F4604312E; Mon, 17 Mar 2003 10:59:17 +0100 (CET) Received: from presto.it.uc3m.es (presto.it.uc3m.es [163.117.139.134]) by smtp02.uc3m.es (Postfix) with ESMTP id 02D9799E14; Mon, 17 Mar 2003 10:59:14 +0100 (CET) Subject: Re: [nemo] about draft-ietf-nemo-requirements-00.txt From: marcelo bagnulo To: Erik Nordmark Cc: IETF NEMO , ernst@sfc.wide.ad.jp In-Reply-To: References: Content-Type: text/plain Organization: uc3m Message-Id: <1047843679.789.412.camel@presto.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 17 Mar 2003 10:59:02 +0100 Content-Transfer-Encoding: 7bit On Sun, 2003-03-16 at 19:07, Erik Nordmark wrote: > > I think i misunderstood your initial statement where you said that "I > > *think* the statement should be about the Nemo solution not *preventing* > > any form of multihoming, including when there are multiple home > > prefixes..." > > > > I thought that we were considering the case of a multi-homed home > > network i.e. the site that contains the HA is multihomed, so the mobile > > network is just another network within the site and the NEMO solution > > should not prevent that the site multi-homing solution adopted works > > properly. > > (My answer to that is that i agree but there are no solutions for site > > multi-homing available right now) > > Sure there are - they are just far from ideal. > IPv6 site multihoming can be done today the same way as in IPv4 - far from > ideal because of scaling implications. We want something better for the size > internet we are likely to see during the lifetime of IPv6. > And IPv6 site multihoming can be done by having multiple prefixes resulting > multiple addressses for every host. ALso far from ideal because the hosts > and applications need to do address selection and there is a loss of policy > control that exists when one prefix is used for the site. > Thus there are no existing solutions to IPv6 multihoming which have reached > nirvana status. > But anyhow, I don't understand what your statements about the status of > IPv6 multihoming are revelant to Nemo. > I guess i was trying to understand what solutions did you had in mind when you suggested that NEMO shouldn't prevent any form of multi-homing. I think i do now, regards, marcelo > Erik -- marcelo bagnulo uc3m From nemo-admin@nal.motlabs.com Mon Mar 17 10:57:05 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18000 for ; Mon, 17 Mar 2003 10:57:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HFjARC018295; Mon, 17 Mar 2003 16:45:10 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HFiVRC018250 for ; Mon, 17 Mar 2003 16:44:32 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2HFgZFV010773; Mon, 17 Mar 2003 16:42:46 +0100 (MET) Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Mon, 17 Mar 2003 16:43:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? Message-ID: Thread-Topic: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? Thread-Index: AcLsI/MVm+NED7t6Q8GjDzejFKeFcwAd1wKQ From: "Pascal Thubert (pthubert)" To: "Ryuji Wakikawa" Cc: X-OriginalArrivalTime: 17 Mar 2003 15:43:32.0740 (UTC) FILETIME=[F6F91440:01C2EC9B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2HFiVRC018250 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 17 Mar 2003 15:43:32 -0000 Content-Transfer-Encoding: 8bit > > Furthermore, the below configuration is possible. > HAs can be placed anywhere on the Internet. There is no > restriction such as home network. MR can have either single > egress interface or multiple egress interfaces. > > > HA1 -------------Internet-------------------HA2 > | | > +==================== MR =====================+ > tunnel 1 | tunnel2 > ------------- > mobile network > > I > Yes, this is definitely an important feature for Nemo the Next generation, IMHO. Note that it's not unique to your draft though. The main questions are the coordination of the HAs (DAD like stuff) and the redistribution of the routes (scalability). We also have to figure out the policies for egress route selection... Pascal From nemo-admin@nal.motlabs.com Mon Mar 17 13:42:33 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24435 for ; Mon, 17 Mar 2003 13:42:31 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HIV6RC025166; Mon, 17 Mar 2003 19:31:06 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HIUSRC025156 for ; Mon, 17 Mar 2003 19:30:29 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2HIUH7q012797; Mon, 17 Mar 2003 11:30:18 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA05899; Mon, 17 Mar 2003 11:30:17 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.2]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h2HIU5d12475; Mon, 17 Mar 2003 12:30:06 -0600 Message-ID: <3E761434.7090707@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: William D Ivancic, Subject: Re: [nemo] comments on the requirements draft References: <5.1.1.5.2.20030313233019.00b13ac8@popserve.grc.nasa.gov> <3E728AA9.E20C3941@iprg.nokia.com> <3E74C286.8070101@nal.motlabs.com> <3E752302.6090404@iprg.nokia.com> In-Reply-To: <3E752302.6090404@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 17 Mar 2003 19:30:12 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > > Alexandru Petrescu wrote: > >> Vijay Devarapalli wrote: >> >>>> I believe this should be a MUST. Multihoming is my normal >>>> mode of operation. The systems I deal with want to connect >>>> to 802.11, multiple satellite networks, G3 wireless, wired >>>> and whatever else may be available. >>> >>> >>> >>> [...] but which tunnel does the HA select if it wants to >>> forward packets to the mobile network? >> >> >> >> If there are two entries keyed by the same HoA, HA could select >> the tunnel of the first entry, why not. > > > the first entry could result in a low bandwidth link. (?) Yes, low bandwidth but entirely private. From nemo-admin@nal.motlabs.com Mon Mar 17 16:53:22 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03727 for ; Mon, 17 Mar 2003 16:53:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HLm8RC031190; Mon, 17 Mar 2003 22:48:08 +0100 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2HLlgRC031177 for ; Mon, 17 Mar 2003 22:47:43 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id A14EC689BA for ; Mon, 17 Mar 2003 16:47:35 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2HLlZ7h001429 for ; Mon, 17 Mar 2003 16:47:35 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-27.lerc.nasa.gov [139.88.246.27]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2HLlWcB026035 for ; Mon, 17 Mar 2003 16:47:33 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030317142835.023ac100@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: nemo@nal.motlabs.com From: William D Ivancic Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_17217247==.ALT" Subject: [nemo] comments on draft-ng-nemo-multihoming-issues-00 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 17 Mar 2003 14:30:11 -0500 --=====================_17217247==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Many thanks to the authors of draft-ng-nemo-multihoming-issues-00 for taking time to describe in detail many of the various ways the multihoming may occur. I have a few comments regarding the described scenarios. ============================================================================== Regarding 2.1.1 Single Mobile Router with Multiple Egress Interfaces Bound to a Single Home Agent IMHO this scenario MUST be addressed. I believe this will be one of the more common scenarios. As both egress interfaces may be active simultaneously, I suggest the at least one interface MUST be utilized and could be selected by some prioritization. In addition, all interfaces MAY be utilized for load sharing, priority routing and numerous other reasons I cannot currently identify. I suggest, however that it would be well advised to allow for the first mode of operation for the following reason: Lets assume I have a satellite link on egress interface 1 at 64 kbps at a cost of $1 per minute and $10,000 per antenna/communication system (a bargain price) and a second 802.11b link at 11 Mbps on egress interface 2 at a cost of $80 per month and under $1,000 for the mobiles antenna system. I would surely like to not use the satellite when I have 802.11 connectivity. ============================================================================= Regarding 2.2.2 Single Mobile Router with Multiple Egress Interfaces Bound to Different Home Agents I think there are some definite security issues that must be addressed here as we are tying two administratively different networks together. Also, I am assuming or suggesting for this scenario the each HA is advertising a different network. That is the same mobile network is not advertised by two independent HAs in two geographically different locations by two independent ISPs. Otherwise, some type of communication would have to occur between the HAs in order to avoid routing loops. ================================================================================ Regarding 2.1.3. Multiple Mobile Routers Relative to the mobile network node, assuming it is attached to two MRs, it can either pick one as the default router, or perform load sharing or utilize both links in other ways. Here, the mobile network node is multihomed. I don't think this is much of an issue accept relative to security issues as again, we may be tying two independent networks together. It may be technically possible to allow one of the Mobile Routers (here MR-1) to utilize the others (MR-2) connectivity when MR-1 looses connectivity to its Access Router via its egress interface. I am not so sure that this would administratively be allowed. However, I think this could be a MAY, but not a MUST. Will --=====================_17217247==.ALT Content-Type: text/html; charset="us-ascii" Many thanks to the authors of draft-ng-nemo-multihoming-issues-00 for taking time to describe in detail many of the various ways the multihoming may occur.

I have a few comments regarding the described scenarios.


==============================================================================
Regarding 2.1.1 Single Mobile Router with Multiple Egress Interfaces Bound to a
                Single Home Agent

IMHO this scenario MUST be addressed.  I believe this will be one of the more common scenarios. As both egress interfaces may be active simultaneously, I suggest the at least one interface MUST be utilized and could be selected by some prioritization.  In addition, all interfaces MAY be utilized  for load sharing, priority routing and numerous other reasons I cannot currently identify.   I suggest, however that it would be well advised to allow for the first mode of operation for the following reason:  Lets assume I have a satellite link on egress interface 1 at 64 kbps at a cost of $1 per minute and $10,000 per antenna/communication system (a bargain price) and a second 802.11b link at 11 Mbps on egress interface 2 at a cost of $80 per month and under $1,000 for the mobiles antenna system.  I would surely like to not use the satellite when I have 802.11 connectivity. 

=============================================================================
Regarding 2.2.2 Single Mobile Router with Multiple Egress Interfaces Bound to
                Different Home Agents
   
I think there are some definite security issues that must be addressed here as we are tying two administratively different networks together.

Also, I am assuming or suggesting for this scenario the each HA is advertising a different network.  That is the same mobile network is not advertised by two independent HAs in two geographically different locations by two independent ISPs.  Otherwise, some type of communication would have to occur between the HAs in order to avoid routing loops.  


================================================================================
Regarding 2.1.3.  Multiple Mobile Routers
   
Relative to the mobile network node, assuming it is attached to two MRs, it can either pick one as the default router, or perform load sharing or utilize both links in other ways.  Here, the mobile network node is multihomed.  I don’t think this is much of an issue accept relative to security issues as again, we may be tying two independent networks together. 

It may be technically possible to allow one of the Mobile Routers (here MR-1) to utilize the others (MR-2) connectivity when MR-1 looses connectivity to its Access Router via its egress interface.  I am not so sure that this would administratively be allowed.  However, I think this could be a MAY, but not a MUST.

Will --=====================_17217247==.ALT-- From nemo-admin@nal.motlabs.com Mon Mar 17 21:35:13 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13571 for ; Mon, 17 Mar 2003 21:35:12 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2I2IWRC006933; Tue, 18 Mar 2003 03:18:32 +0100 Received: from ALPHA8.ITS.MONASH.EDU.AU (alpha8.its.monash.edu.au [130.194.1.8]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2I2HrRC006924 for ; Tue, 18 Mar 2003 03:17:54 +0100 Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KTO62K8VWI9BWUDH@vaxh.its.monash.edu.au> for nemo@nal.motlabs.com; Tue, 18 Mar 2003 13:11:02 +1100 Received: from splat.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 18A14130004; Tue, 18 Mar 2003 13:11:02 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 19279130003; Tue, 18 Mar 2003 13:11:01 +1100 (EST) From: Greg Daley Subject: Re: [nemo] comments on draft-ng-nemo-multihoming-issues-00 To: William D Ivancic Cc: nemo@nal.motlabs.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3E768034.1090502@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <5.1.1.5.2.20030317142835.023ac100@popserve.grc.nasa.gov> Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 18 Mar 2003 13:11:00 +1100 Content-Transfer-Encoding: 7BIT Hi Will, Just a quick comment on one of the scenarios. William D Ivancic wrote: [scenario snipped] > ====================== > Regarding 2.2.2 Single Mobile Router with Multiple Egress Interfaces > Bound to > Different Home Agents > > I think there are some definite security issues that must be addressed > here as we are tying two administratively different networks together. > > Also, I am assuming or suggesting for this scenario the each HA is > advertising a different network. That is the same mobile network is not > advertised by two independent HAs in two geographically different > locations by two independent ISPs. Otherwise, some type of > communication would have to occur between the HAs in order to avoid > routing loops. [scenario snipped] I think that the idea with NEMO was that no transit is provided between ASs by the NEMO (except for nested NEMOs lower in the DAG). This is especially important in IPv6 where this is not generally allowed anyway. Greg From nemo-admin@nal.motlabs.com Tue Mar 18 13:39:08 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22965 for ; Tue, 18 Mar 2003 13:39:05 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2IIdCRC022585; Tue, 18 Mar 2003 19:39:13 +0100 Received: from tchaikovsky.psl.com.sg (ca-77-241.wired.ietf56.ietf.org [130.129.77.241]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2IIcVRC022555 for ; Tue, 18 Mar 2003 19:38:38 +0100 Received: by tchaikovsky.psl.com.sg (Postfix, from userid 1000) id 51A8011177BC; Wed, 19 Mar 2003 02:55:31 +0800 (SGT) Subject: Re: [nemo] comments on draft-ng-nemo-multihoming-issues-00 From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: greg.daley@eng.monash.edu.au Cc: William D Ivancic , IETF-NEMO In-Reply-To: <3E768034.1090502@eng.monash.edu.au> References: <5.1.1.5.2.20030317142835.023ac100@popserve.grc.nasa.gov> <3E768034.1090502@eng.monash.edu.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1048013731.1656.13.camel@tchaikovsky> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Mar 2003 02:55:31 +0800 Content-Transfer-Encoding: 7bit On Tue, 2003-03-18 at 10:11, Greg Daley wrote: > Hi Will, > > Just a quick comment on one of the scenarios. > > William D Ivancic wrote: > [scenario snipped] > > > ====================== > > Regarding 2.2.2 Single Mobile Router with Multiple Egress Interfaces > > Bound to > > Different Home Agents > > > > I think there are some definite security issues that must be addressed > > here as we are tying two administratively different networks together. > > > > Also, I am assuming or suggesting for this scenario the each HA is > > advertising a different network. That is the same mobile network is not > > advertised by two independent HAs in two geographically different > > locations by two independent ISPs. Otherwise, some type of > > communication would have to occur between the HAs in order to avoid > > routing loops. > [scenario snipped] > > I think that the idea with NEMO was that no transit > is provided between ASs by the NEMO (except for > nested NEMOs lower in the DAG). > This is especially important in IPv6 where this is not > generally allowed anyway. What happen if the MR, say use two level of tunnelings, to forward packet to HA-1, via HA-2? Would you still consider this as disallowed? It will be something like this: MN send packet A, src=home-link-1 MR encapsulate packet A in packet B, dst=HA-1 MR encapsulate packet B in packet C, dst=HA-2 /cwng From nemo-admin@nal.motlabs.com Tue Mar 18 20:36:58 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11207 for ; Tue, 18 Mar 2003 20:36:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J1cBRC003043; Wed, 19 Mar 2003 02:38:12 +0100 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J1bKRC003035 for ; Wed, 19 Mar 2003 02:37:20 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id ABA5C6B9FC for ; Tue, 18 Mar 2003 20:37:13 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2J1bC7h003500; Tue, 18 Mar 2003 20:37:12 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-23.lerc.nasa.gov [139.88.246.23]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2J1b8cB017591; Tue, 18 Mar 2003 20:37:10 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030318202041.023b7e18@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: cwng@psl.com.sg From: William D Ivancic Subject: Re: [nemo] comments on draft-ng-nemo-multihoming-issues-00 Cc: nemo@nal.motlabs.com In-Reply-To: <1048013731.1656.13.camel@tchaikovsky> References: <3E768034.1090502@eng.monash.edu.au> <5.1.1.5.2.20030317142835.023ac100@popserve.grc.nasa.gov> <3E768034.1090502@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 18 Mar 2003 20:37:07 -0500 >What happen if the MR, say use two level of tunnelings, to forward >packet to HA-1, via HA-2? Would you still consider this as disallowed? > >It will be something like this: > >MN send packet A, src=home-link-1 >MR encapsulate packet A in packet B, dst=HA-1 >MR encapsulate packet B in packet C, dst=HA-2 > >/cwng Hello Chan-Wah, Let me take the liberty to add some numbering for clarity - I hope the intent of your question is unchanged. In referencing the diagrams of 2.2.2 of the multihoming draft, draft-ng-nemo-multihoming-issues-00 Single Mobile Router with Multiple Egress Interfaces Bound to Different Home Agents MN (attached to MR1 only) send packet A, src=home-link-1 MR1 encapsulate packet A in packet B, dst=HA-1 MR2 encapsulate packet B in packet C, dst=HA-2 HA-2 de-encapsulates packet C and forward B to HA-1 HA-1 de-encapsulates packet B and forwards to the corresponding node. I assume from this description presented as that the MN is attached to only MR1 and that MR1 looses its connection to its Access Router. Then if appropriate security mechanisms occur such that MR2 allows MR1 access to its network, than this should be permitted. If MN was attached to both MR1 and MR2, there would be no reason to use MR1 if MR1 looses connectivity to its Access Router(s). Will From nemo-admin@nal.motlabs.com Tue Mar 18 20:52:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11560 for ; Tue, 18 Mar 2003 20:52:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J1s4RC003171; Wed, 19 Mar 2003 02:54:04 +0100 Received: from tchaikovsky.psl.com.sg (ca-66-243.wired.ietf56.ietf.org [130.129.66.243]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J1ruRC003163 for ; Wed, 19 Mar 2003 02:53:57 +0100 Received: by tchaikovsky.psl.com.sg (Postfix, from userid 1000) id 8072711177CB; Wed, 19 Mar 2003 10:11:02 +0800 (SGT) Subject: Re: [nemo] comments on draft-ng-nemo-multihoming-issues-00 From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: William D Ivancic Cc: IETF-NEMO In-Reply-To: <5.1.1.5.2.20030318202041.023b7e18@popserve.grc.nasa.gov> References: <3E768034.1090502@eng.monash.edu.au> <5.1.1.5.2.20030317142835.023ac100@popserve.grc.nasa.gov> <3E768034.1090502@eng.monash.edu.au> <5.1.1.5.2.20030318202041.023b7e18@popserve.grc.nasa.gov> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1048039862.1653.11.camel@tchaikovsky> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 19 Mar 2003 10:11:02 +0800 Content-Transfer-Encoding: 7bit On Wed, 2003-03-19 at 09:37, William D Ivancic wrote: > >What happen if the MR, say use two level of tunnelings, to forward > >packet to HA-1, via HA-2? Would you still consider this as disallowed? > > > >It will be something like this: > > > >MN send packet A, src=home-link-1 > >MR encapsulate packet A in packet B, dst=HA-1 > >MR encapsulate packet B in packet C, dst=HA-2 > > > >/cwng > > Hello Chan-Wah, > Hi, William, > Let me take the liberty to add some numbering for clarity - I hope the > intent of your question is unchanged. > Great, thanks for improving it :). > In referencing the diagrams of 2.2.2 of the multihoming draft, > draft-ng-nemo-multihoming-issues-00 > Single Mobile Router with Multiple Egress Interfaces Bound to Different > Home Agents > > MN (attached to MR1 only) send packet A, src=home-link-1 > MR1 encapsulate packet A in packet B, dst=HA-1 > MR2 encapsulate packet B in packet C, dst=HA-2 > HA-2 de-encapsulates packet C and forward B to HA-1 > HA-1 de-encapsulates packet B and forwards to the corresponding node. > > I assume from this description presented as that the MN is attached to > only MR1 and that MR1 looses its connection to its Access Router. Then if > appropriate security mechanisms occur such that MR2 allows MR1 access to > its network, than this should be permitted. > If MN was attached to both MR1 and MR2, there would be no reason to use MR1 > if MR1 looses connectivity to its Access Router(s). > Agreed, in the steady-state MN should not. But see if me reasoning make sense: it takes time for MN to discover that MR-1 is no longer up, and to switch over to use MR-2 (plus getting Coa and sending BU). So for real time applications, MN may wish to continue using MR1 until the new binding update is set up. Make sense? /cwng From nemo-admin@nal.motlabs.com Tue Mar 18 23:53:06 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15861 for ; Tue, 18 Mar 2003 23:53:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J4qdRC006163; Wed, 19 Mar 2003 05:52:39 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J4pkRC006139 for ; Wed, 19 Mar 2003 05:51:47 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id UAA05955; Tue, 18 Mar 2003 20:51:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2J4pc126650; Tue, 18 Mar 2003 20:51:38 -0800 X-mProtect: <200303190451> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.52.34, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6ZWzkB; Tue, 18 Mar 2003 20:51:36 PST Message-ID: <3E77F757.3030608@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: "Pascal Thubert (pthubert)" , nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 18 Mar 2003 20:51:35 -0800 Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > Routers route packets meant for the mobile network to HA. Then,HA intercepts and > conceptually routes them to MR-CoA via the tunnel interface, because HA has the > route of mobile network prefix and the next hope is the tunnel > interface. At protocol(implementation) point of view, HA searches binding cache > and tunnel packets to MR-CoA. IMHO, it is a really inefficient way of routing packets. searching the binding cache for a route to the mobile network is a lot slower than having a routing entry in the HA's routing table. (route lookup is faster). > MR can register MR-CoA several HAs simultaneously, because our id does not have > "general Home Link". > > Furthermore, the below configuration is possible. > HAs can be placed anywhere on the Internet. There is no restriction such > as home network. MR can have either single egress interface or multiple > egress interfaces. this is good. but as Pascal said this is not unique to this draft. you can always assign the home address to a virtual interface and use the two egress interfaces simultaneously. some mipv6 MN implemenations also do this. (I am sure you know about this) > > > HA1 -------------Internet-------------------HA2 > | | > +==================== MR =====================+ > tunnel 1 | tunnel2 > ------------- > mobile network > > If multiple HAs have binding of MR, each HA advertises the route of > mobile network prefix with different "routing metric". This achieves redundancy > of HA. If the primary HA goes down, all packets destined to mobile > network prefix is routed to another HA, because the mobile network > prefix route advertised by the primary HA is deleted. again, nothing prevents you from having this type of configuration with draft-kniveton-mobrtr... Vijay From nemo-admin@nal.motlabs.com Wed Mar 19 01:16:19 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17883 for ; Wed, 19 Mar 2003 01:16:13 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J6FXRC007216; Wed, 19 Mar 2003 07:15:33 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J6EPRC007169 for ; Wed, 19 Mar 2003 07:14:34 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 888695D01E; Wed, 19 Mar 2003 15:14:02 +0900 (JST) Message-Id: <20030319.151402.01438587.ernst@sfc.wide.ad.jp> To: William.D.Ivancic@nasa.gov, nemo@nal.motlabs.com Subject: Re: [nemo] Aeronautics Requirements From: Thierry Ernst In-Reply-To: <3E515C45.9090100@eng.monash.edu.au> References: <3E501C32.10604@eng.monash.edu.au> <3E50F103.5030607@nal.motlabs.com> <3E515C45.9090100@eng.monash.edu.au> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 15:14:02 +0900 (JST) Content-Transfer-Encoding: 7bit Dear all, Thanks William from bringing this thread to this list. Actually, I was expecting you would question about requirements much earlier. This discussion was very interesting and brought a lot of information. Let me comment on it. From: Greg Daley > If we have a list of interested parties/documents, > should we approach a group/groups requirements doc, > maybe a bit similar to the 3GPP-IPv6wg reqs? > Should this be accounted for in the base reqs? > > I'm inclined to believe that the reqs should not > be combined with the basic NEMO reqs, since we're > not sure that the application areas will all be covered > with basic NEMO (low-latency communications for example). I think the aeronautic community should check to what extend draft-ietf-nemo-requirements meets the aeronautic requirements, and make sure affordable requirements are present in basic. For instance, multihoming is an affordable one. On the other hand, QoS is probably not an affordable one (in basic). So, it would be a shame if draft-ietf-nemo-requirements doesn't mention about an important and affordable aeronautic requirement. For other very specific requirements, this is an other issue. [Alex] > I tend to agree, so maybe we should remove ITS from > draft-requirements, but try to find out which are the scenarios that > are being considered both by ITS and by aeronautics and by 3gpp that > do need IP addresses and IP connectivity. And since William came up > with such an aeronautics scenario, we should consider it in more > detail. In ITS also, yes, IP technologies are considered, vehicles will soon contain tens of IP devices, and thus entire in-vehicle networks will appear. See for instance ISO TC 204 WG16 who is woking on the M5 architecture (all IPv6) and should most likely be interested in what NEMO is going to provide [instead of basing their specification on Mobile IPv6 to provide Internet connectivity to an IPv6 in-vehicle network, which is not supposed to work as you all know - otherwise NEMO WG wouldn't exist]. Also, see work done in Japan in InternetITS (http://www.internetits.org) and InternetCAR (http://www.sfc.wide.ad.jp/InternetCAR/) projects. ITS is cited in draft-iietf-nemo-requirements as an instance, but there are currently no ITS specific requirements in the draft. If that was the case, the draft would list one-liners about safety, QoS, fast handover, which is not the case. So, what should be removed and why ? Both aeronautic and ITS do have specific requirements. I think it would be useful for us to know what ones. The problem is that people in the aeronautic and ITS communities do not speak the same language as us. We first need to establish a cross communication to share our understanding of the problems and needs. This is not an easy task. In addition, requirements from those communities, once formalized, are most likely to span a number of working groups, not only NEMO. So, this must probably be dealt with at a higher level at the IETF. This remind me about the requirements from the cellular industry a while ago in mobiliity working groups. How was this dealt with ? Thierry, PS: A few years ago, Eurocontrol has investigated IPv6 mobility to carry air control traffic. I don't know if they carried their work, but they would probably have interesting discussions to share with us on this list and particularly on this thread. I guess Willian knows about their work. From nemo-admin@nal.motlabs.com Wed Mar 19 03:57:48 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16332 for ; Wed, 19 Mar 2003 03:57:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J8x7RC009067; Wed, 19 Mar 2003 09:59:08 +0100 Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J8wqRC009059 for ; Wed, 19 Mar 2003 09:58:53 +0100 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2J8wE0J003701; Wed, 19 Mar 2003 01:58:20 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2J8wIS12495; Wed, 19 Mar 2003 02:58:19 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 83B912EC86; Wed, 19 Mar 2003 09:58:31 +0100 (CET) Message-ID: <3E783137.5DFEBF31@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Ryuji Wakikawa , "Pascal Thubert (pthubert)" , nemo@nal.motlabs.com Subject: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 09:58:31 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > > Ryuji Wakikawa wrote: > > Routers route packets meant for the mobile network to HA. Then,HA intercepts and > > conceptually routes them to MR-CoA via the tunnel interface, because HA has the > > route of mobile network prefix and the next hope is the tunnel > > interface. At protocol(implementation) point of view, HA searches binding cache > > and tunnel packets to MR-CoA. > > IMHO, it is a really inefficient way of routing packets. searching > the binding cache for a route to the mobile network is a lot slower > than having a routing entry in the HA's routing table. (route lookup > is faster). Your point on performance may be true, but I think this is not relevant for the purpose of how the basic nemo specification should describe the forwarding of packets on the HA! I would say, that this type of performance (forwarding) is rather implementation dependent and, IMHO, should not impact on the way the HA-forwarding is specified. As explained in draft-petrescu-nemo-mrha-02.txt section 4.1, I tend to think the opposite and suggest that forwarding process on HA should better be expressed in term of the BC (even with a prefix entry) rather than a route entry on HA. I just copy here the relevant paragraph (sorry): > 4.1 Implementation-independent specification terms > > The specification of the basic network mobility support should be > expressed with implementation-independent terms. In other words, > clear distinction should be made between the specification of the > protocol and a description of a possible implementation of this > protocol. Especially, since it is to be based on Mobile IP(v6), the > basic NEMO support specification should not make any assumption on > how Mobile IP(v6) is implemented but instead re-use (and possibly > extend) data structures from the Mobile IP(v6) specification > (e.g. Binding Cache), and eventually introduce new ones if > needed. Below are two examples of how attention should be payed in > the specification of the protocol. > > The bi-directional approach requires MR's HA to configure a > "forwarding information" for the mobile network prefix towards the > mobile router. Since the Mobile IP(v6) specification introduces a > dedicated structure, so-called Binding Cache, to store > mobility-related "forwading information" on the HA, the > specification of basic NEMO support should re-use/extend the > Binding Cache to include the new mobility-related "forwarding > information" for a mobile network. Even though a Binding Cache may > be implemented as an extension of a routing table, the > specification should relate to the Binding Cache and not the > routing table. For instance, the specification should relate to > the "forwading information" to be configured on MR's HA for the > mobile network prefix in terms of a prefix entry in the Binding > Cache instead of an entry in the routing table of MR's HA. > Especially, Mobile IP(v6) specification does not specify any > routing table for a HA. > > Similarly, the specification should not assume that a tunnel, > e.g. the MRHA bi-directionnal tunnel, is visible as a virtual > network interface on the MR or HA. This is an > implementation-related consideration that may not be true for all > IP(v6)/MobileIP(v6) stacks. > > Such considerations will allow to clearly draw the line between the > specification and a description of a possible implementation, and > as a result ease any future implementation of the basic NEMO > support as an extention of an existing Mobile IPv6 implementation. The overall objective here is to ensure the WG will come up with a specification of basic nemo support, and not a description of one possible implementation. Would be interesting to get opinion from people on the list on this (or have this discussed during the meeting today :). Thanks, Christophe. From nemo-admin@nal.motlabs.com Wed Mar 19 04:55:36 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17371 for ; Wed, 19 Mar 2003 04:55:34 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J9v4RC009952; Wed, 19 Mar 2003 10:57:05 +0100 Received: from multihop.net ([192.103.16.205]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2J9umRC009938 for ; Wed, 19 Mar 2003 10:56:48 +0100 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.8/8.12.8) with ESMTP id h2J9tw4E040257; Wed, 19 Mar 2003 01:55:59 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) From: "T.J. Kniveton" To: Christophe Janneteau , Vijay Devarapalli CC: Ryuji Wakikawa , "Pascal Thubert (pthubert)" , Message-ID: In-Reply-To: <3E783137.5DFEBF31@motorola.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 01:55:29 -0800 Content-Transfer-Encoding: 7bit On 3/19/03 12:58 AM, "Christophe Janneteau" wrote: > Hi Vijay, > > Vijay Devarapalli wrote: >> >> Ryuji Wakikawa wrote: >>> Routers route packets meant for the mobile network to HA. Then,HA intercepts >>> and >>> conceptually routes them to MR-CoA via the tunnel interface, because HA has >>> the >>> route of mobile network prefix and the next hope is the tunnel >>> interface. At protocol(implementation) point of view, HA searches binding >>> cache >>> and tunnel packets to MR-CoA. I'm not sure I get that -- if the binding is from MR-A/64 to MR-CoA, why does it need to do a binding cache lookup? Is the binding really from MR-A/64 to HAddr? >> >> IMHO, it is a really inefficient way of routing packets. searching >> the binding cache for a route to the mobile network is a lot slower >> than having a routing entry in the HA's routing table. (route lookup >> is faster). > > Your point on performance may be true, but I think this is not relevant > for the purpose of how the basic nemo specification should describe the > forwarding of packets on the HA! I would say, that this type of > performance (forwarding) is rather implementation dependent and, IMHO, > should not impact on the way the HA-forwarding is specified. you are right, the basic draft should not dictate how to implement things. However, IETF philosophy also leaves room for implementation considerations to have a bearing on how the protocol will be described, so that it can actually be implemented in a fast way, on many modern OS's (especially by the author(s)), right? Ryuji was describing how his implementation works, so Vijay was commenting on that -- not on the spec. If there is an inefficiency identified in implementation, maybe it can lead to an improvement of the spec itself. > > As explained in draft-petrescu-nemo-mrha-02.txt section 4.1, I tend to > think the opposite and suggest that forwarding process on HA should > better be expressed in term of the BC (even with a prefix entry) rather > than a route entry on HA. I just copy here the relevant paragraph > (sorry): > >> 4.1 Implementation-independent specification terms >> >> The specification of the basic network mobility support should be >> expressed with implementation-independent terms. In other words, >> clear distinction should be made between the specification of the >> protocol and a description of a possible implementation of this >> protocol. Especially, since it is to be based on Mobile IP(v6), the >> basic NEMO support specification should not make any assumption on >> how Mobile IP(v6) is implemented but instead re-use (and possibly >> extend) data structures from the Mobile IP(v6) specification >> (e.g. Binding Cache), and eventually introduce new ones if >> needed. Below are two examples of how attention should be payed in >> the specification of the protocol. I'm not sure I catch your drift -- we probably all agree that a base spec should not dictate the implementation details. On the other hand, there is precedent for describing how one *can* implement it, or giving hints, including in Mobile IPv6, which you are citing and describing -- data structures hint at an implementation, right? And they are designed in a certain way, not arbitrarily, based on what will work well in practice. Maybe someone can correct me if I'm out in left field, but I believe in the IETF we are allowed to consider how something will be implemented before the spec is finished. After all, it has to be implemented sooner or later, and might as well be performant. With that said, of course our good design principles are going to make us try and keep the implementation details as open as possible. >> >> The bi-directional approach requires MR's HA to configure a >> "forwarding information" for the mobile network prefix towards the >> mobile router. Since the Mobile IP(v6) specification introduces a >> dedicated structure, so-called Binding Cache, to store >> mobility-related "forwading information" on the HA, the >> specification of basic NEMO support should re-use/extend the >> Binding Cache to include the new mobility-related "forwarding >> information" for a mobile network. Even though a Binding Cache may >> be implemented as an extension of a routing table, the >> specification should relate to the Binding Cache and not the >> routing table. For instance, the specification should relate to >> the "forwading information" to be configured on MR's HA for the >> mobile network prefix in terms of a prefix entry in the Binding >> Cache instead of an entry in the routing table of MR's HA. >> Especially, Mobile IP(v6) specification does not specify any >> routing table for a HA. >> >> Similarly, the specification should not assume that a tunnel, >> e.g. the MRHA bi-directionnal tunnel, is visible as a virtual >> network interface on the MR or HA. This is an >> implementation-related consideration that may not be true for all >> IP(v6)/MobileIP(v6) stacks. >> >> Such considerations will allow to clearly draw the line between the >> specification and a description of a possible implementation, and >> as a result ease any future implementation of the basic NEMO >> support as an extention of an existing Mobile IPv6 implementation. > > The overall objective here is to ensure the WG will come up with a > specification of basic nemo support, and not a description of one > possible implementation. Would be interesting to get opinion from people > on the list on this (or have this discussed during the meeting today :). Yes, we agree on this point -- the description must be abstracted away from the implementation. But, I guess my point is, not too far! TJ From nemo-admin@nal.motlabs.com Wed Mar 19 08:21:42 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20421 for ; Wed, 19 Mar 2003 08:21:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JDN8RC012244; Wed, 19 Mar 2003 14:23:08 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JDMERC012232 for ; Wed, 19 Mar 2003 14:22:17 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2JDM56m025752; Wed, 19 Mar 2003 06:22:06 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA18354; Wed, 19 Mar 2003 06:22:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2JDM6V18551; Wed, 19 Mar 2003 07:22:07 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 44F162EC8B; Wed, 19 Mar 2003 14:22:05 +0100 (CET) Message-ID: <3E786EFC.FDD9A800@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "T.J. Kniveton" Cc: Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 14:22:04 +0100 Content-Transfer-Encoding: 7bit Hi T.J., "T.J. Kniveton" wrote: > >> 4.1 Implementation-independent specification terms > >> > >> The specification of the basic network mobility support should be > >> expressed with implementation-independent terms. In other words, > >> clear distinction should be made between the specification of the > >> protocol and a description of a possible implementation of this > >> protocol. Especially, since it is to be based on Mobile IP(v6), the > >> basic NEMO support specification should not make any assumption on > >> how Mobile IP(v6) is implemented but instead re-use (and possibly > >> extend) data structures from the Mobile IP(v6) specification > >> (e.g. Binding Cache), and eventually introduce new ones if > >> needed. Below are two examples of how attention should be payed in > >> the specification of the protocol. > > I'm not sure I catch your drift -- we probably all agree that a base spec > should not dictate the implementation details. On the other hand, there is > precedent for describing how one *can* implement it, or giving hints, > including in Mobile IPv6, which you are citing and describing -- data > structures hint at an implementation, right? And they are designed in a > certain way, not arbitrarily, based on what will work well in practice. I have nothing against a protocol specification which would _also_ provide hints on how defined data structures (e.g. Mobile IPv6 BC) may be implemented (e.g. Mobile IPv6 BC implemented as host routes in a routing table). On the other hand, I think the protocol description ,on its own, should not base *too much* on implementation assumption. For instance, HA-forwarding process in Mobile IPv6 protocol could have been described in term of extensions to the HA's routing table (e.g. host routes) but the need has been foreseen to introduce the Binding Cache, which is the data structure used in the protocol specification. There may be several reasons for this (I am not aware of all of them but MIP pioneers may help here :), IMHO, one of them being to clearly separate routing functions from mobility functions. I think a similar separation should be preserved in NEMO, and thus suggest to describe MR's HA behavior in term of the BC and not in term of its routing table...(although a possible implementation may use the routing table). > Maybe someone can correct me if I'm out in left field, but I believe in the > IETF we are allowed to consider how something will be implemented before the > spec is finished. After all, it has to be implemented sooner or later, and > might as well be performant. I agree... Christophe From nemo-admin@nal.motlabs.com Wed Mar 19 11:58:40 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25846 for ; Wed, 19 Mar 2003 11:58:38 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JGu8RC013631; Wed, 19 Mar 2003 17:56:08 +0100 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JGtPRC013621 for ; Wed, 19 Mar 2003 17:55:26 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 82B396BA38 for ; Wed, 19 Mar 2003 11:55:19 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2JGtI7h005470; Wed, 19 Mar 2003 11:55:18 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-25.lerc.nasa.gov [139.88.246.25]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2JGtGcB015991; Wed, 19 Mar 2003 11:55:17 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030318202041.023b7e18@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: cwng@psl.com.sg From: William D Ivancic Subject: Re: [nemo] comments on draft-ng-nemo-multihoming-issues-00 Cc: nemo@nal.motlabs.com In-Reply-To: <1048013731.1656.13.camel@tchaikovsky> References: <3E768034.1090502@eng.monash.edu.au> <5.1.1.5.2.20030317142835.023ac100@popserve.grc.nasa.gov> <3E768034.1090502@eng.monash.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Tue, 18 Mar 2003 20:37:07 -0500 >What happen if the MR, say use two level of tunnelings, to forward >packet to HA-1, via HA-2? Would you still consider this as disallowed? > >It will be something like this: > >MN send packet A, src=home-link-1 >MR encapsulate packet A in packet B, dst=HA-1 >MR encapsulate packet B in packet C, dst=HA-2 > >/cwng Hello Chan-Wah, Let me take the liberty to add some numbering for clarity - I hope the intent of your question is unchanged. In referencing the diagrams of 2.2.2 of the multihoming draft, draft-ng-nemo-multihoming-issues-00 Single Mobile Router with Multiple Egress Interfaces Bound to Different Home Agents MN (attached to MR1 only) send packet A, src=home-link-1 MR1 encapsulate packet A in packet B, dst=HA-1 MR2 encapsulate packet B in packet C, dst=HA-2 HA-2 de-encapsulates packet C and forward B to HA-1 HA-1 de-encapsulates packet B and forwards to the corresponding node. I assume from this description presented as that the MN is attached to only MR1 and that MR1 looses its connection to its Access Router. Then if appropriate security mechanisms occur such that MR2 allows MR1 access to its network, than this should be permitted. If MN was attached to both MR1 and MR2, there would be no reason to use MR1 if MR1 looses connectivity to its Access Router(s). Will From nemo-admin@nal.motlabs.com Wed Mar 19 12:11:36 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26259 for ; Wed, 19 Mar 2003 12:11:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JHD4RC013825; Wed, 19 Mar 2003 18:13:04 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JHCORC013803 for ; Wed, 19 Mar 2003 18:12:24 +0100 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2JHCEHR007684; Wed, 19 Mar 2003 18:12:14 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 19 Mar 2003 18:12:14 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF76E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" , "'Takeshi TANAKA'" Cc: "'marcelo bagnulo'" , "'IETF NEMO'" , "'ernst@sfc.wide.ad.jp'" Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 18:12:09 +0100 > > But the fact that you use "A" and "B" instead of "C" and "D" > is confusing. > So let me try to generalize what I think is your "mobile > site multihoming" > configuration. > > There are two mobile routers: MR_A and MR_B > They have separate home agents (HA_A and HA_B) that belong > to two different > sites (A/48 and B/48 for example). > > As a result of this the mobile network has two prefixes: > A:x/64 and B:y/64. > > The MRs attach either to the same ISP or different ISP. For > maximum expansion > assume they are different. Thus the CoA for the MRs is C:1 and D:1 > respectively. > > > The first concern in this type of setup is how does routing > work for the > LMNs - is there or is there not an assumption that the MR selection > (the 1st hop default router the LMNs use) needs to be tied to the > source address they use or not? > > Thus would it work if the LMN sends a packet with source > A:x:987 to first hop > router MR_B? > > In the IPv4 and IPv6 models of a host the source address selection > is a function of what interface the host is sending on, but > not which > 1st hop router it is using. > So unless folks are proposing to change this the host > should be able to > use source A:x:987 while using router MR_B. > Making this work requires some coordination between site A > and B (to accept > either source address). This is part of the general *site* > multihoming issues > when each host gets an address from each site's prefix. > But the point is assuming independence between site A and B > (and indirectly > the HAs and MRs) is a non-starter. => What if the two MRs cooperate by forwarding traffic to the appropriate MR based on src address filtering? A MR can look at the src address of the packet and see whether it belongs to its Home prefix or another one. If it belongs to "another" prefix, it can forward the packet to the corresponding MR. Obviously this means that MRs will need to check other MRs RAs, which is not difficult. I can't see any security issues specific to nemo here (i.e. other than known ND threats). Is this handwaving a starter :) ? Hesham From nemo-admin@nal.motlabs.com Wed Mar 19 12:13:33 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26309 for ; Wed, 19 Mar 2003 12:13:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JH74RC013757; Wed, 19 Mar 2003 18:07:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JH6DRC013744 for ; Wed, 19 Mar 2003 18:06:14 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA28223; Wed, 19 Mar 2003 09:06:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2JH66u20954; Wed, 19 Mar 2003 09:06:06 -0800 X-mProtect: <200303191706> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.53.202, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdmIaY9t; Wed, 19 Mar 2003 09:06:04 PST Message-ID: <3E78A37C.6070408@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Janneteau CC: nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E783137.5DFEBF31@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 09:06:04 -0800 Content-Transfer-Encoding: 7bit Christophe Janneteau wrote: > Hi Vijay, > > Your point on performance may be true, but I think this is not relevant > for the purpose of how the basic nemo specification should describe the > forwarding of packets on the HA! you totally missed my point. I was comparing using binding cache for forwarding to a network prefix when you have something called a routing table for forwarding to a network prefix. my opinion is that it is very inefficient. FWIW I dont believe in specifications which dont consider the implementation aspects. Vijay From nemo-admin@nal.motlabs.com Wed Mar 19 12:55:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27936 for ; Wed, 19 Mar 2003 12:55:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JHv6RC014304; Wed, 19 Mar 2003 18:57:06 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JHuqRC014296 for ; Wed, 19 Mar 2003 18:56:53 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2JHumF9018753 for ; Wed, 19 Mar 2003 10:56:51 -0700 (MST) Received: [from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA08711 for ; Wed, 19 Mar 2003 10:54:37 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h2JHrYt16650; Wed, 19 Mar 2003 11:53:35 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id 10D432EC86; Wed, 19 Mar 2003 18:53:33 +0100 (CET) Message-ID: <3E78AE9C.F54A9C7@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E783137.5DFEBF31@motorola.com> <3E78A37C.6070408@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 18:53:32 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > Christophe Janneteau wrote: > > Hi Vijay, > > > > Your point on performance may be true, but I think this is not relevant > > for the purpose of how the basic nemo specification should describe the > > forwarding of packets on the HA! > > you totally missed my point. I was comparing using binding cache > for forwarding to a network prefix when you have something called > a routing table for forwarding to a network prefix. my opinion is > that it is very inefficient. I think I clearly understood what you wrote and reacted on that... But if you say no then... > FWIW I dont believe in specifications which dont consider the > implementation aspects. ...and I share this opinion as well! But also hope we can clearly distinguish between a spec and the description of _a_ possible implementation.... Please re-read my email or just forget about it :) Christophe From nemo-admin@nal.motlabs.com Wed Mar 19 13:44:53 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00232 for ; Wed, 19 Mar 2003 13:44:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JIk3RC014576; Wed, 19 Mar 2003 19:46:03 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JIjCRC014568 for ; Wed, 19 Mar 2003 19:45:13 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03502; Wed, 19 Mar 2003 10:45:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2JIj0T16213; Wed, 19 Mar 2003 10:45:00 -0800 X-mProtect: <200303191845> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.53.202, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJnPhlG; Wed, 19 Mar 2003 10:44:58 PST Message-ID: <3E78BAA9.5040106@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Janneteau CC: "T.J. Kniveton" , nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) References: <3E786EFC.FDD9A800@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 10:44:57 -0800 Content-Transfer-Encoding: 7bit Christophe Janneteau wrote: > Hi T.J., > > For instance, HA-forwarding process in Mobile IPv6 protocol could have > been described in term of extensions to the HA's routing table (e.g. > host routes) but the need has been foreseen to introduce the Binding > Cache, which is the data structure used in the protocol specification. > There may be several reasons for this (I am not aware of all of them but > MIP pioneers may help here :), IMHO, one of them being to clearly > separate routing functions from mobility functions. > > I think a similar separation should be preserved in NEMO, and thus > suggest to describe MR's HA behavior in term of the BC and not in term > of its routing table...(although a possible implementation may use the > routing table). disagree. MIPv6 uses binding cache for /128 addresses. and that is perfect. in NEMO basic support, you need to redirect traffic for a /64 prefix, which is exactly the same as having a network route with a next hop (or an outgoing interface). Vijay From nemo-admin@nal.motlabs.com Wed Mar 19 16:01:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07770 for ; Wed, 19 Mar 2003 16:01:19 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JL2ARC015973; Wed, 19 Mar 2003 22:02:10 +0100 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JL0lRC015935 for ; Wed, 19 Mar 2003 22:00:49 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27420; Wed, 19 Mar 2003 13:00:39 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2JL0ZK25865; Wed, 19 Mar 2003 22:00:35 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt To: "Hesham Soliman (EAB)" Cc: "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" , "'ernst@sfc.wide.ad.jp'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053807FEF76E@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 19 Mar 2003 21:56:36 +0100 (CET) > => What if the two MRs cooperate by forwarding traffic to > the appropriate MR based on src address filtering? > > A MR can look at the src address of the packet and see > whether it belongs to its Home prefix or another one. > If it belongs to "another" prefix, it can forward the packet > to the corresponding MR. What happens when one of the MRs, or the MR to HA tunnel, fails? Since one of the claimed benefits (perhaps the main one?) of multihoming is redundancy this requires consideration. Erik From nemo-admin@nal.motlabs.com Wed Mar 19 16:05:23 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08131 for ; Wed, 19 Mar 2003 16:05:22 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JL73RC016005; Wed, 19 Mar 2003 22:07:03 +0100 Received: from tchaikovsky.psl.com.sg (ca-66-243.wired.ietf56.ietf.org [130.129.66.243]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2JL61RC015995 for ; Wed, 19 Mar 2003 22:06:02 +0100 Received: by tchaikovsky.psl.com.sg (Postfix, from userid 1000) id 27B2C11177CC; Thu, 20 Mar 2003 05:23:11 +0800 (SGT) Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt From: Chan-Wah Ng Reply-To: cwng@psl.com.sg To: "Hesham Soliman (EAB)" Cc: "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" , "'ernst@sfc.wide.ad.jp'" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053807FEF76E@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053807FEF76E@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Panasonic Singapore Laboratories Message-Id: <1048108990.1636.6.camel@tchaikovsky> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1- Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: 20 Mar 2003 05:23:11 +0800 Content-Transfer-Encoding: 7bit On Thu, 2003-03-20 at 01:12, Hesham Soliman (EAB) wrote: > > > > But the fact that you use "A" and "B" instead of "C" and "D" > > is confusing. > > So let me try to generalize what I think is your "mobile > > site multihoming" > > configuration. > > > > There are two mobile routers: MR_A and MR_B > > They have separate home agents (HA_A and HA_B) that belong > > to two different > > sites (A/48 and B/48 for example). > > > > As a result of this the mobile network has two prefixes: > > A:x/64 and B:y/64. > > > > The MRs attach either to the same ISP or different ISP. For > > maximum expansion > > assume they are different. Thus the CoA for the MRs is C:1 and D:1 > > respectively. > > > > > > The first concern in this type of setup is how does routing > > work for the > > LMNs - is there or is there not an assumption that the MR selection > > (the 1st hop default router the LMNs use) needs to be tied to the > > source address they use or not? > > > > Thus would it work if the LMN sends a packet with source > > A:x:987 to first hop > > router MR_B? > > > > In the IPv4 and IPv6 models of a host the source address selection > > is a function of what interface the host is sending on, but > > not which > > 1st hop router it is using. > > So unless folks are proposing to change this the host > > should be able to > > use source A:x:987 while using router MR_B. > > Making this work requires some coordination between site A > > and B (to accept > > either source address). This is part of the general *site* > > multihoming issues > > when each host gets an address from each site's prefix. > > But the point is assuming independence between site A and B > > (and indirectly > > the HAs and MRs) is a non-starter. > > => What if the two MRs cooperate by forwarding traffic to > the appropriate MR based on src address filtering? > > A MR can look at the src address of the packet and see > whether it belongs to its Home prefix or another one. > If it belongs to "another" prefix, it can forward the packet > to the corresponding MR. > Yes, this is a good way to go when both MR's egress links are up. This allows MN to choose whichever prefixes it deems fit, and independently selects a default router regardless of which MR advertises the prefix. But it means that if the egress link of one MR (say MR_A) has failed, the packet sent from MN that is supposed to go through the MR_A will still not go through, altough MN happily thinks that it has forwarded to MR_B (which still has an active link), where actual fact MR_B re-forwarded the packet back to MR_A. /rgds /cwng > Obviously this means that MRs will need to check other > MRs RAs, which is not difficult. > > I can't see any security issues specific to nemo > here (i.e. other than known ND threats). > > Is this handwaving a starter :) ? > > Hesham > From nemo-admin@nal.motlabs.com Thu Mar 20 05:48:59 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14140 for ; Thu, 20 Mar 2003 05:48:43 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KAnaRC024235; Thu, 20 Mar 2003 11:49:36 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KAmlRC024226 for ; Thu, 20 Mar 2003 11:48:48 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2KAmkK5003814; Thu, 20 Mar 2003 03:48:46 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id DAA23325; Thu, 20 Mar 2003 03:48:44 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h2KAmVd24563; Thu, 20 Mar 2003 04:48:32 -0600 Received: from motorola.com (zfr03-0108.crm.mot.com [140.101.173.175]) by thorgal.crm.mot.com (Postfix) with ESMTP id E2AE22EC86; Thu, 20 Mar 2003 11:48:37 +0100 (CET) Message-ID: <3E799C85.699BA250@motorola.com> From: Christophe Janneteau X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "T.J. Kniveton", Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) References: <3E786EFC.FDD9A800@motorola.com> <3E78BAA9.5040106@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 11:48:37 +0100 Content-Transfer-Encoding: 7bit Hi Vijay, Vijay Devarapalli wrote: > > Christophe Janneteau wrote: > > Hi T.J., > > > > For instance, HA-forwarding process in Mobile IPv6 protocol could have > > been described in term of extensions to the HA's routing table (e.g. > > host routes) but the need has been foreseen to introduce the Binding > > Cache, which is the data structure used in the protocol specification. > > There may be several reasons for this (I am not aware of all of them but > > MIP pioneers may help here :), IMHO, one of them being to clearly > > separate routing functions from mobility functions. > > > > I think a similar separation should be preserved in NEMO, and thus > > suggest to describe MR's HA behavior in term of the BC and not in term > > of its routing table...(although a possible implementation may use the > > routing table). > > disagree. MIPv6 uses binding cache for /128 addresses. and that is > perfect. in NEMO basic support, you need to redirect traffic for > a /64 prefix, which is exactly the same as having a network route > with a next hop (or an outgoing interface). We agree on the fact that NEMO's HA must redirect traffic for a prefix (/64 or others). Now the question is how the specification should describe this, and here it seems we disagree. I would prefer to have the _specification_ (I am not talking about implementation here) describing the forwarding for the prefix with the sole use of the Binding Cache (i.e. prefix entry in the BC) since I can see the following problems if we go for the approach you suggest, i.e. use a /64 nemo prefix in the HA's routing table: o Case 1: This routing table entry would looks like: Prefix NextHop OutputIFC nemo/64 MR_HoA eth0 (inteface towards MR's home link) Then the specification should describe a coordination between the parsing of the routing table and the parsing of the BC (to recover MR-CoA from nexthop=MR_HoA). This would mix routing and mobility functions that I think make the protocol more complex. In addition, as said by someone earlier on the mailing list, this would suggest a departure from traditional parsing of the routing table since only NextHop but not outputIFC should be considered in that case... o Case 2: This routing table entry would looks like: Prefix NextHop OutputIFC nemo/64 :: MR_HA_tunnel_ifc No NextHop is specified but the output interface is directly said to be the MR-HA tunnel. Here we would not need anymore parsing of the BC (departure from Mobile IPv6) but would have to update the tunnel endpoint in the routing table each time MR moves. The problem with this approach is that it assumes a tunnel (e.g. MR-HA tunnel) is implemented as a virtual network interface....which is not true for all (currently used) IPv6 stack. This would make the spec too implementation specific in my opinion, and make porting of some existing Mobile IPv6 implementations to NEMO quite difficult... Again I have nothing against an implementation that would use approaches 1 or 2, but i think this should not be THE description of the protocol, but only a possible implemtation (e.g. in annex of the nemo spec). If you see good reasons to go for a description like 1 or 2 as the HA behavior, please let me know...I may miss something :) Thanks, Christophe From nemo-admin@nal.motlabs.com Thu Mar 20 11:27:58 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23578 for ; Thu, 20 Mar 2003 11:27:57 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGTORC026558; Thu, 20 Mar 2003 17:29:24 +0100 Received: from asama.sfc.wide.ad.jp (218-45-30-54.kamome.jp [218.45.30.54]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGSMRC026541 for ; Thu, 20 Mar 2003 17:28:23 +0100 Received: from localhost (localhost [127.0.0.1]) by asama.sfc.wide.ad.jp (8.12.6/8.12.6) with ESMTP id h2KGQsoE001699; Fri, 21 Mar 2003 01:26:56 +0900 (JST) (envelope-from kei@wide.ad.jp) Message-Id: <20030321.012151.1071434493.kei@wide.ad.jp> To: tj@kniveton.com Cc: Christophe.Janneteau@motorola.com, vijayd@iprg.nokia.com, ryuji@sfc.wide.ad.jp, pthubert@cisco.com, nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC From: Keisuke UEHARA In-Reply-To: References: <3E783137.5DFEBF31@motorola.com> X-Mailer: Mew version 2.2 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 01:21:51 +0900 (JST) Content-Transfer-Encoding: 7bit Hi TJ and all, I'm a co-author of the draft (draft-wakikawa-nemo-basic-00.txt). From: "T.J. Kniveton" Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) Date: Wed, 19 Mar 2003 01:55:29 -0800 > >> Ryuji Wakikawa wrote: > >>> interface. At protocol(implementation) point of view, HA searches binding > >>> cache > >>> and tunnel packets to MR-CoA. > > I'm not sure I get that -- if the binding is from MR-A/64 to MR-CoA, why > does it need to do a binding cache lookup? Is the binding really from > MR-A/64 to HAddr? The binding is from MR-A/64 to MR-CoA. The Ryuji's description is the conceptual one. You can implement this mechanism as followings: Case 1: When HA receives a BU (MR-A/64 -> MR-CoA) from MR, HA setups the tunnel and the route entry (MR-A/64 -> tunnel). Then, when HA receives a packet addressed to MR-A/64 (ex. MR-A), HA forwards it according to its routing table. Case 2: When HA recives a BU, HA creates BC. Then, when HA receives a packet addressed to MR-A/64, HA encapsulates it and resend to MR-CoA. Case 1 is more simple than Case 2. Because BC (Routing Table) setup and forwarding function are separated. Case 2 can be implemented as an extension of Mobile IPv6. It is possible to implement this mechanism with other way, of cause. This is a really implementation issue, NOT a protocol issue. Kei From nemo-admin@nal.motlabs.com Thu Mar 20 11:30:30 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23635 for ; Thu, 20 Mar 2003 11:30:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGW4RC026597; Thu, 20 Mar 2003 17:32:04 +0100 Received: from asama.sfc.wide.ad.jp (218-45-30-54.kamome.jp [218.45.30.54]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGT1RC026544 for ; Thu, 20 Mar 2003 17:29:02 +0100 Received: from localhost (localhost [127.0.0.1]) by asama.sfc.wide.ad.jp (8.12.6/8.12.6) with ESMTP id h2KGQsoF001699; Fri, 21 Mar 2003 01:27:00 +0900 (JST) (envelope-from kei@wide.ad.jp) Message-Id: <20030321.012616.468707223.kei@wide.ad.jp> To: Christophe.Janneteau@motorola.com Cc: vijayd@iprg.nokia.com, tj@kniveton.com, nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC From: Keisuke UEHARA In-Reply-To: <3E799C85.699BA250@motorola.com> References: <3E786EFC.FDD9A800@motorola.com> <3E78BAA9.5040106@iprg.nokia.com> <3E799C85.699BA250@motorola.com> X-Mailer: Mew version 2.2 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 01:26:16 +0900 (JST) Content-Transfer-Encoding: 7bit Hello, From: Christophe Janneteau Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) Date: Thu, 20 Mar 2003 11:48:37 +0100 > o Case 1: This routing table entry would looks like: > > Prefix NextHop OutputIFC > nemo/64 MR_HoA eth0 (inteface towards MR's home link) > > Then the specification should describe a coordination between the > parsing of the routing table and the parsing of the BC (to recover > MR-CoA from nexthop=MR_HoA). This would mix routing and mobility > functions that I think make the protocol more complex. In addition, as > said by someone earlier on the mailing list, this would suggest a > departure from traditional parsing of the routing table since only > NextHop but not outputIFC should be considered in that case... > > o Case 2: This routing table entry would looks like: > > Prefix NextHop OutputIFC > nemo/64 :: MR_HA_tunnel_ifc > > No NextHop is specified but the output interface is directly said to be > the MR-HA tunnel. Here we would not need anymore parsing of the BC > (departure from Mobile IPv6) but would have to update the tunnel > endpoint in the routing table each time MR moves. The problem with this > approach is that it assumes a tunnel (e.g. MR-HA tunnel) is implemented > as a virtual network interface....which is not true for all (currently > used) IPv6 stack. This would make the spec too implementation specific > in my opinion, and make porting of some existing Mobile IPv6 > implementations to NEMO quite difficult... Yes, this is exact that I want to say previous mail. Regards, Kei From nemo-admin@nal.motlabs.com Thu Mar 20 11:53:12 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24348 for ; Thu, 20 Mar 2003 11:53:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGs5RC026868; Thu, 20 Mar 2003 17:54:05 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGrHRC026860 for ; Thu, 20 Mar 2003 17:53:18 +0100 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8657.tkyoac00.ap.so-net.ne.jp [218.221.134.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2KGoO2t025819; Fri, 21 Mar 2003 01:50:24 +0900 Message-ID: From: Ryuji Wakikawa To: vijayd@iprg.nokia.com Cc: pthubert@cisco.com, nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? In-Reply-To: <3E77F757.3030608@iprg.nokia.com> References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 04:34:09 +0900 Hi Vijay At Tue, 18 Mar 2003 20:51:35 -0800, Vijay Devarapalli wrote: > > > > Ryuji Wakikawa wrote: > > Routers route packets meant for the mobile network to HA. Then,HA intercepts and > > conceptually routes them to MR-CoA via the tunnel interface, because HA has the > > route of mobile network prefix and the next hope is the tunnel > > interface. At protocol(implementation) point of view, HA searches binding cache > > and tunnel packets to MR-CoA. > > IMHO, it is a really inefficient way of routing packets. searching > the binding cache for a route to the mobile network is a lot slower > than having a routing entry in the HA's routing table. (route lookup > is faster). Can you elaborate on the performance difference between binding cache and routing table? Processing steps of searching are almost same. > > MR can register MR-CoA several HAs simultaneously, because our id does not have > > "general Home Link". > > > > Furthermore, the below configuration is possible. > > HAs can be placed anywhere on the Internet. There is no restriction such > > as home network. MR can have either single egress interface or multiple > > egress interfaces. > > this is good. but as Pascal said this is not unique to this draft. you > can always assign the home address to a virtual interface and use the > two egress interfaces simultaneously. some mipv6 MN implemenations also > do this. (I am sure you know about this) OK. Actually my MN implmentation can handle this:-) ryuji > > > > > > HA1 -------------Internet-------------------HA2 > > | | > > +==================== MR =====================+ > > tunnel 1 | tunnel2 > > ------------- > > mobile network > > > > If multiple HAs have binding of MR, each HA advertises the route of > > mobile network prefix with different "routing metric". This achieves redundancy > > of HA. If the primary HA goes down, all packets destined to mobile > > network prefix is routed to another HA, because the mobile network > > prefix route advertised by the primary HA is deleted. > > again, nothing prevents you from having this type of configuration > with draft-kniveton-mobrtr... > > Vijay From nemo-admin@nal.motlabs.com Thu Mar 20 11:54:24 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24404 for ; Thu, 20 Mar 2003 11:54:23 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGu3RC026888; Thu, 20 Mar 2003 17:56:03 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KGtIRC026880 for ; Thu, 20 Mar 2003 17:55:19 +0100 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8657.tkyoac00.ap.so-net.ne.jp [218.221.134.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2KGsm2t025832; Fri, 21 Mar 2003 01:54:48 +0900 Message-ID: From: Ryuji Wakikawa To: Christophe.Janneteau@motorola.com Cc: vijayd@iprg.nokia.com, ryuji@sfc.wide.ad.jp, pthubert@cisco.com, nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) In-Reply-To: <3E783137.5DFEBF31@motorola.com> References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E783137.5DFEBF31@motorola.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 04:39:29 +0900 Hi Christophe. At Wed, 19 Mar 2003 09:58:31 +0100, Christophe Janneteau wrote: > > Hi Vijay, > > Vijay Devarapalli wrote: > > > > Ryuji Wakikawa wrote: > > > Routers route packets meant for the mobile network to HA. Then,HA intercepts and > > > conceptually routes them to MR-CoA via the tunnel interface, because HA has the > > > route of mobile network prefix and the next hope is the tunnel > > > interface. At protocol(implementation) point of view, HA searches binding cache > > > and tunnel packets to MR-CoA. > > > > IMHO, it is a really inefficient way of routing packets. searching > > the binding cache for a route to the mobile network is a lot slower > > than having a routing entry in the HA's routing table. (route lookup > > is faster). > > Your point on performance may be true, but I think this is not relevant > for the purpose of how the basic nemo specification should describe the > forwarding of packets on the HA! I would say, that this type of > performance (forwarding) is rather implementation dependent and, IMHO, > should not impact on the way the HA-forwarding is specified. I totaly agree with you. > As explained in draft-petrescu-nemo-mrha-02.txt section 4.1, I tend to > think the opposite and suggest that forwarding process on HA should > better be expressed in term of the BC (even with a prefix entry) rather > than a route entry on HA. I just copy here the relevant paragraph > (sorry): > > > 4.1 Implementation-independent specification terms > > > > The specification of the basic network mobility support should be > > expressed with implementation-independent terms. In other words, > > clear distinction should be made between the specification of the > > protocol and a description of a possible implementation of this > > protocol. Especially, since it is to be based on Mobile IP(v6), the > > basic NEMO support specification should not make any assumption on > > how Mobile IP(v6) is implemented but instead re-use (and possibly > > extend) data structures from the Mobile IP(v6) specification > > (e.g. Binding Cache), and eventually introduce new ones if > > needed. Below are two examples of how attention should be payed in > > the specification of the protocol. > > > > The bi-directional approach requires MR's HA to configure a > > "forwarding information" for the mobile network prefix towards the > > mobile router. Since the Mobile IP(v6) specification introduces a > > dedicated structure, so-called Binding Cache, to store > > mobility-related "forwading information" on the HA, the > > specification of basic NEMO support should re-use/extend the > > Binding Cache to include the new mobility-related "forwarding > > information" for a mobile network. Even though a Binding Cache may > > be implemented as an extension of a routing table, the > > specification should relate to the Binding Cache and not the > > routing table. For instance, the specification should relate to > > the "forwading information" to be configured on MR's HA for the > > mobile network prefix in terms of a prefix entry in the Binding > > Cache instead of an entry in the routing table of MR's HA. > > Especially, Mobile IP(v6) specification does not specify any > > routing table for a HA. > > > > Similarly, the specification should not assume that a tunnel, > > e.g. the MRHA bi-directionnal tunnel, is visible as a virtual > > network interface on the MR or HA. This is an > > implementation-related consideration that may not be true for all > > IP(v6)/MobileIP(v6) stacks. > > > > Such considerations will allow to clearly draw the line between the > > specification and a description of a possible implementation, and > > as a result ease any future implementation of the basic NEMO > > support as an extention of an existing Mobile IPv6 implementation. > > The overall objective here is to ensure the WG will come up with a > specification of basic nemo support, and not a description of one > possible implementation. Would be interesting to get opinion from people > on the list on this (or have this discussed during the meeting today :). I think our id meets this texts. regards, ryuji > > Thanks, > Christophe. From nemo-admin@nal.motlabs.com Thu Mar 20 12:10:23 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25297 for ; Thu, 20 Mar 2003 12:10:22 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KHC4RC026975; Thu, 20 Mar 2003 18:12:04 +0100 Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KHAxRC026963 for ; Thu, 20 Mar 2003 18:11:00 +0100 Received: from monster.sfc.wide.ad.jp.sfc.wide.ad.jp (pdd8657.tkyoac00.ap.so-net.ne.jp [218.221.134.87]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.8/8.12.0) with ESMTP id h2KH9k2t025982; Fri, 21 Mar 2003 02:09:46 +0900 Message-ID: From: Ryuji Wakikawa To: tj@kniveton.com Cc: Christophe.Janneteau@motorola.com, vijayd@iprg.nokia.com, pthubert@cisco.com, nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no homenetwork ?) In-Reply-To: References: <3E783137.5DFEBF31@motorola.com> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/20.7 (i386--freebsd) MULE/4.1 (AOI) Organization: Keio University MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 04:56:36 +0900 Hi TJ. At Wed, 19 Mar 2003 01:55:29 -0800, T.J. Kniveton wrote: > > >> > >> IMHO, it is a really inefficient way of routing packets. searching > >> the binding cache for a route to the mobile network is a lot slower > >> than having a routing entry in the HA's routing table. (route lookup > >> is faster). > > > > Your point on performance may be true, but I think this is not relevant > > for the purpose of how the basic nemo specification should describe the > > forwarding of packets on the HA! I would say, that this type of > > performance (forwarding) is rather implementation dependent and, IMHO, > > should not impact on the way the HA-forwarding is specified. > > you are right, the basic draft should not dictate how to implement things. > However, IETF philosophy also leaves room for implementation considerations > to have a bearing on how the protocol will be described, so that it can > actually be implemented in a fast way, on many modern OS's (especially by > the author(s)), right? > > Ryuji was describing how his implementation works, so Vijay was commenting > on that -- not on the spec. If there is an inefficiency identified in > implementation, maybe it can lead to an improvement of the spec itself. We really don't know the performance difference between BC and routing table. Do you have any reasons that routing table search is much faster than searching BC? > > > > As explained in draft-petrescu-nemo-mrha-02.txt section 4.1, I tend to > > think the opposite and suggest that forwarding process on HA should > > better be expressed in term of the BC (even with a prefix entry) rather > > than a route entry on HA. I just copy here the relevant paragraph > > (sorry): > > > >> 4.1 Implementation-independent specification terms > >> > >> The specification of the basic network mobility support should be > >> expressed with implementation-independent terms. In other words, > >> clear distinction should be made between the specification of the > >> protocol and a description of a possible implementation of this > >> protocol. Especially, since it is to be based on Mobile IP(v6), the > >> basic NEMO support specification should not make any assumption on > >> how Mobile IP(v6) is implemented but instead re-use (and possibly > >> extend) data structures from the Mobile IP(v6) specification > >> (e.g. Binding Cache), and eventually introduce new ones if > >> needed. Below are two examples of how attention should be payed in > >> the specification of the protocol. > > I'm not sure I catch your drift -- we probably all agree that a base spec > should not dictate the implementation details. On the other hand, there is > precedent for describing how one *can* implement it, or giving hints, > including in Mobile IPv6, which you are citing and describing -- data > structures hint at an implementation, right? And they are designed in a > certain way, not arbitrarily, based on what will work well in practice. > > Maybe someone can correct me if I'm out in left field, but I believe in the > IETF we are allowed to consider how something will be implemented before the > spec is finished. After all, it has to be implemented sooner or later, and > might as well be performant. > > With that said, of course our good design principles are going to make us > try and keep the implementation details as open as possible. I think this section 4.1 does not point the implmenetation, but it also recommend that the base spec should not rely on an exisiting routing protocol. I want to say that the base spec should not assume a routing protocols at home link. Even if routes of a home network domain are configured "manually" (i.e. w/out any routing protocls running), MR must be able to return to the home network. regards, ryuji > >> > >> The bi-directional approach requires MR's HA to configure a > >> "forwarding information" for the mobile network prefix towards the > >> mobile router. Since the Mobile IP(v6) specification introduces a > >> dedicated structure, so-called Binding Cache, to store > >> mobility-related "forwading information" on the HA, the > >> specification of basic NEMO support should re-use/extend the > >> Binding Cache to include the new mobility-related "forwarding > >> information" for a mobile network. Even though a Binding Cache may > >> be implemented as an extension of a routing table, the > >> specification should relate to the Binding Cache and not the > >> routing table. For instance, the specification should relate to > >> the "forwading information" to be configured on MR's HA for the > >> mobile network prefix in terms of a prefix entry in the Binding > >> Cache instead of an entry in the routing table of MR's HA. > >> Especially, Mobile IP(v6) specification does not specify any > >> routing table for a HA. > >> > >> Similarly, the specification should not assume that a tunnel, > >> e.g. the MRHA bi-directionnal tunnel, is visible as a virtual > >> network interface on the MR or HA. This is an > >> implementation-related consideration that may not be true for all > >> IP(v6)/MobileIP(v6) stacks. > >> > >> Such considerations will allow to clearly draw the line between the > >> specification and a description of a possible implementation, and > >> as a result ease any future implementation of the basic NEMO > >> support as an extention of an existing Mobile IPv6 implementation. > > > > The overall objective here is to ensure the WG will come up with a > > specification of basic nemo support, and not a description of one > > possible implementation. Would be interesting to get opinion from people > > on the list on this (or have this discussed during the meeting today :). > > Yes, we agree on this point -- the description must be abstracted away from > the implementation. But, I guess my point is, not too far! > > TJ From nemo-admin@nal.motlabs.com Thu Mar 20 13:13:50 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27801 for ; Thu, 20 Mar 2003 13:13:49 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KIFARC027249; Thu, 20 Mar 2003 19:15:10 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KIEbRC027238 for ; Thu, 20 Mar 2003 19:14:37 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2KIEHIx001595; Thu, 20 Mar 2003 11:14:18 -0700 (MST) Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA20191; Thu, 20 Mar 2003 11:12:04 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.76]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h2KIECJ06455; Thu, 20 Mar 2003 12:14:12 -0600 Message-ID: <3E7A04F2.4040608@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: , , Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 19:14:10 +0100 Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: >> IMHO, it is a really inefficient way of routing packets. >> searching the binding cache for a route to the mobile network is >> a lot slower than having a routing entry in the HA's routing >> table. (route lookup is faster). > > > Can you elaborate on the performance difference between binding > cache and routing table? Processing steps of searching are almost > same. The only difference I can see is that an execution averages shorter times if you use an exact prefix instead of a variable longest-prefix match. Of course, it all depends on too many other factors that are very often overlooked in the implementation. I don't think we can use speed of search as a differentiator between styles of writing specs. Alex From nemo-admin@nal.motlabs.com Thu Mar 20 17:54:10 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11516 for ; Thu, 20 Mar 2003 17:54:09 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMo4RC028250; Thu, 20 Mar 2003 23:50:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMk2RC028218 for ; Thu, 20 Mar 2003 23:46:03 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA02799; Thu, 20 Mar 2003 14:45:56 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2KMjuo21737; Thu, 20 Mar 2003 14:45:56 -0800 X-mProtect: <200303202245> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.104, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdF4lqmu; Thu, 20 Mar 2003 14:45:54 PST Message-ID: <3E7A44A1.80306@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa CC: nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 14:45:53 -0800 Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > Can you elaborate on the performance difference between binding cache > and routing table? Processing steps of searching are almost same. I have a nice patricia tree for the routing table..... Vijay From nemo-admin@nal.motlabs.com Thu Mar 20 17:54:12 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11530 for ; Thu, 20 Mar 2003 17:54:11 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMjDRC028214; Thu, 20 Mar 2003 23:45:13 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMijRC028200; Thu, 20 Mar 2003 23:44:45 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2KMggUu013200; Thu, 20 Mar 2003 23:42:42 +0100 (MET) Received: from xbe-lon-312.cisco.com ([64.103.99.72]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 20 Mar 2003 23:43:32 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 20 Mar 2003 22:43:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] moving forward (was: no home network ?) Message-ID: Thread-Topic: [nemo] moving forward (was: no home network ?) Thread-Index: AcLvDJUTIkmDuGC2SnK3xb5QU2FmeQACIKvQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Ryuji Wakikawa" Cc: , X-OriginalArrivalTime: 20 Mar 2003 22:43:31.0979 (UTC) FILETIME=[22210DB0:01C2EF32] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2KMijRC028200 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 22:43:31 -0000 Content-Transfer-Encoding: 8bit Let me try to present it with an angle: The draft introduces a form of routing protocol. Somehow, you come up with new routes and you have to install and redistribute these routes. I believe there's quite a lot of work to get there. And that the issue will be highly controversial. Please refer to the "BU adds routes thread". My suggestion for the working group is to agree upon a barebones -by Michael's terms- solution for Basic Nemo based on TJ's consumer model. You know, something like a MIPv6 host on the egress and a router on the ingress, as someone (sorry I can't remember whom, was that Pekka?) put it on the list long ago. And static routes in the Home Agents to the Mobile Networks. Is that enough for a real large scale deployment, maybe not. But it's the common agreed upon ground based on which a solution will be assembled. In parallel, we can start listing the modules that we would need to top of that, and sort out the most wanted ones in the ML. My initial (unordered) list: * Routing protocol between MR and HA => new protocol? Adaptation of an existing protocol? * Mobile Prefix delegation * Multiple homing - Multiple registration => replacement of MIPv6-ND interaction by a multicast based HA-HA protocol. * RO inside the nested nemo * RO to the Correspondent Node => pinpoint mobile network routes distribution in the infrastructure, granularity problem => Correspondent Router * IPv4 PAT NAT traversal (YES;-) * Privacy * ... Thoughts? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@nal.motlabs.com] > Sent: jeudi 20 mars 2003 19:14 > To: Ryuji Wakikawa > Cc: vijayd@iprg.nokia.com; Pascal Thubert (pthubert); > nemo@nal.motlabs.com > Subject: Re: [nemo] comments on > draft-wakikawa-nemo-basic-00.txt -> no home network ? > > > Ryuji Wakikawa wrote: > >> IMHO, it is a really inefficient way of routing packets. searching > >> the binding cache for a route to the mobile network is a lot > >> slower than having a routing entry in the HA's routing table. > >> (route lookup is faster). > > > > > > Can you elaborate on the performance difference between binding > > cache and routing table? Processing steps of searching are almost > > same. > > The only difference I can see is that an execution averages > shorter times if you use an exact prefix instead of a > variable longest-prefix match. > > Of course, it all depends on too many other factors that are > very often overlooked in the implementation. I don't think > we can use speed of search as a differentiator between styles > of writing specs. > > Alex > > From nemo-admin@nal.motlabs.com Thu Mar 20 17:57:01 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11603 for ; Thu, 20 Mar 2003 17:56:59 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMqBRC028267; Thu, 20 Mar 2003 23:52:11 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMmnRC028229 for ; Thu, 20 Mar 2003 23:48:50 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA03030; Thu, 20 Mar 2003 14:48:44 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2KMmhT25341; Thu, 20 Mar 2003 14:48:43 -0800 X-mProtect: <200303202248> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.104, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGy3481; Thu, 20 Mar 2003 14:48:41 PST Message-ID: <3E7A4549.8040903@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Janneteau CC: Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) References: <3E786EFC.FDD9A800@motorola.com> <3E78BAA9.5040106@iprg.nokia.com> <3E799C85.699BA250@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 14:48:41 -0800 Content-Transfer-Encoding: 7bit jeez.. how did we get into this discussion? I guess I am partly to blame. anyway, for the rest of the WG, what we are discussing is highly implementation specific. Christophe has a point there. having said that, I prefer using a routing table entry to route to a /64 prefix instead of using the binding cache entry. one of the reasons is that in the platform that we use for MIPv6 HA, there is a highly efficient data structure for the routing table, but a not so efficient data structure (in terms of searching the data structure) for the binding cache. I think this would be true for most home agents. route lookups are fast on any router (otherwise who is going to use your router?), and they continue to improve. to forward packets to the mobile network prefix, one can use a combination of binding cache and routing table, only the routing table or only the binding cache. I agree with that. also, tunnel interface betwen the MR and the HA can be conceptual. what I would like to see is a routing table entry for the mobile router's network prefix with the outgoing interface pointing to the tunnel interface (MR_HA, MR_CoA). this works well with IPsec too (as shown in draft-ietf-mobileip-mipv6-ha-ipsec-03.txt). this however requires that we change the tunnel end point information whenever the MR changes its CoA. we already do this with MIPv6. the tunnel end point information inside the SADB is updated as the MN moves. we basically resuse IPsec in tunnel mode, where the MR - HA tunnel becomes a IPsec tunnel. we do the same here. if you implement the tunnel as a virtual interface it is easy to update the end point information in the interface data structure. if you implement it using the binding cache, it is again easy to update the information in the binding cache. now, onto your mail Christophe Janneteau wrote: > o Case 1: This routing table entry would looks like: > > Prefix NextHop OutputIFC > nemo/64 MR_HoA eth0 (inteface towards MR's home link) we dont want to use this. I dont like Case 1 either. > In addition, as > said by someone earlier on the mailing list, this would suggest a > departure from traditional parsing of the routing table since only > NextHop but not outputIFC should be considered in that case... noooo, you can have a routing table entry where only the outgoing interface is specified. > > o Case 2: This routing table entry would looks like: > > Prefix NextHop OutputIFC > nemo/64 :: MR_HA_tunnel_ifc > > No NextHop is specified but the output interface is directly said to be > the MR-HA tunnel. Here we would not need anymore parsing of the BC > (departure from Mobile IPv6) but would have to update the tunnel > endpoint in the routing table each time MR moves. uh... the tunnel information is not stored in the routing table. a tunnel is created as a separate interface and is given a name. then you enter the name of the interface as the outgoing interface in the route entry. when you do a lookup by the lname you get the actual tunnel information. > The problem with this > approach is that it assumes a tunnel (e.g. MR-HA tunnel) is implemented > as a virtual network interface....which is not true for all (currently > used) IPv6 stack. This would make the spec too implementation specific > in my opinion, and make porting of some existing Mobile IPv6 > implementations to NEMO quite difficult... thats the funny part. MIPv6 and MIPv6 ha-mn-ipsec draft kind of assume a tunnel interface between the MN_CoA and the HA. they also argue for updating the tunnel end point as the MN moves. I like this model..... > Again I have nothing against an implementation that would use approaches > 1 or 2, but i think this should not be THE description of the protocol, > but only a possible implemtation (e.g. in annex of the nemo spec). I agree with you here. the reason we are discussing this because there was claimed benefit (both on the mailing list and at the WG meeting) in using a prefix scoped binding cache entry instead of a routing entry. I am trying to figure out what it is. Vijay From nemo-admin@nal.motlabs.com Thu Mar 20 18:01:58 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11820 for ; Thu, 20 Mar 2003 18:01:56 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMs3RC028282; Thu, 20 Mar 2003 23:54:03 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KMnBRC028236; Thu, 20 Mar 2003 23:49:11 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2KJmUgm028679; Thu, 20 Mar 2003 20:48:59 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 20 Mar 2003 20:50:37 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Thu, 20 Mar 2003 19:50:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] moving forward (was: no home network ?) Message-ID: Thread-Topic: [nemo] moving forward (was: no home network ?) Thread-Index: AcLvDJUTIkmDuGC2SnK3xb5QU2FmeQACIKvQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Ryuji Wakikawa" Cc: , X-OriginalArrivalTime: 20 Mar 2003 19:50:36.0797 (UTC) FILETIME=[FA09EAD0:01C2EF19] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2KMnBRC028236 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 19:50:36 -0000 Content-Transfer-Encoding: 8bit Let me try to present it with an angle: The draft introduces a form of routing protocol. Somehow, you come up with new routes and you have to install and redistribute these routes. I believe there's quite a lot of work to get there. And that the issue will be highly controversial. Please refer to the "BU adds routes thread". My suggestion for the working group is a modular approach. Let us first agree upon a barebones -by Michael's terms- solution for Basic Nemo based on TJ's consumer model. You know, something like a MIPv6 host on the egress and a router on the ingress, as someone (sorry I can't remember whom, was that Pekka?) put it on the list long ago. And static routes in the Home Agents to the Mobile Networks. Is that enough for a real large scale deployment, maybe not. But it's the common agreed upon ground based on which further work can take place and a solution be assembled. In parallel, we can start listing the modules that we would need to top of that, and sort out the most wanted ones in the ML. My initial (unordered) list: * Routing protocol between MR and HA => new protocol? Adaptation of an existing protocol? * Multiple homing - Multiple registration => replacement of MIPv6-ND interaction by a multicast based HA-HA protocol. * RO inside the nested nemo * RO to the CR * IPv4 PAT NAT traversal (YES;-) * ... What do you think? Pascal > -----Original Message----- > From: Alexandru Petrescu [mailto:petrescu@nal.motlabs.com] > Sent: jeudi 20 mars 2003 19:14 > To: Ryuji Wakikawa > Cc: vijayd@iprg.nokia.com; Pascal Thubert (pthubert); > nemo@nal.motlabs.com > Subject: Re: [nemo] comments on > draft-wakikawa-nemo-basic-00.txt -> no home network ? > > > Ryuji Wakikawa wrote: > >> IMHO, it is a really inefficient way of routing packets. > >> searching the binding cache for a route to the mobile network is > >> a lot slower than having a routing entry in the HA's routing > >> table. (route lookup is faster). > > > > > > Can you elaborate on the performance difference between binding > > cache and routing table? Processing steps of searching are almost > > same. > > The only difference I can see is that an execution averages > shorter times if you use an exact prefix instead of a > variable longest-prefix match. > > Of course, it all depends on too many other factors that are > very often overlooked in the implementation. I don't think > we can use speed of search as a differentiator between styles > of writing specs. > > Alex > > From nemo-admin@nal.motlabs.com Thu Mar 20 18:03:45 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11949 for ; Thu, 20 Mar 2003 18:03:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KN24RC028366; Fri, 21 Mar 2003 00:02:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KN0vRC028339; Fri, 21 Mar 2003 00:00:58 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA03630; Thu, 20 Mar 2003 15:00:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2KN0oY08950; Thu, 20 Mar 2003 15:00:50 -0800 X-mProtect: <200303202300> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.104, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMt4QWy; Thu, 20 Mar 2003 15:00:48 PST Message-ID: <3E7A4820.90103@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Alexandru Petrescu , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] moving forward (was: no home network ?) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 15:00:48 -0800 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: > Let me try to present it with an angle: > > The draft introduces a form of routing protocol. Somehow, you come up > with new routes and you have to install and redistribute these routes. > > I believe there's quite a lot of work to get there. And that the issue > will be highly controversial. Please refer to the "BU adds routes > thread". > > My suggestion for the working group is to agree upon a barebones -by > Michael's terms- solution for Basic Nemo based on TJ's consumer model. > You know, something like a MIPv6 host on the egress and a router on the > ingress, as someone (sorry I can't remember whom, was that Pekka?) put > it on the list long ago. And static routes in the Home Agents to the > Mobile Networks. > > Is that enough for a real large scale deployment, maybe not. But it's > the common agreed upon ground based on which a solution will be > assembled. > > In parallel, we can start listing the modules that we would need to top > of that, and sort out the most wanted ones in the ML. My initial > (unordered) list: > > * Routing protocol between MR and HA > => new protocol? Adaptation of an existing protocol? I think a new routing protocol is not needed. if the MR is at a foriegn link, it turns off routing on the egress interface. instead it starts sending routing updates through the tunnel to the Home Agent. when it comes home, it turns on routing on the egress interface. the tunnel to the Home Agent no longer exists. routing updates from the MR (either through the bi-directional tunnel when on foreign link or the egress interface when on home link) automatically distributes routes to the Home Agent and other routers on the home link. the consumer case works perfectly for a PAN (personal area network). for a large network like a cruise ship or a train, when there are lots of mobile routers attached to it (and if each one wants to use some different prefix), running a routing protocol through the bi-directional tunnel is needed. I agree with the rest of your mail, though. Vijay > > * Mobile Prefix delegation > > * Multiple homing - Multiple registration > => replacement of MIPv6-ND interaction by a multicast based HA-HA > protocol. > > * RO inside the nested nemo > > * RO to the Correspondent Node > => pinpoint mobile network routes distribution in the infrastructure, > granularity problem > => Correspondent Router > > * IPv4 PAT NAT traversal (YES;-) > > * Privacy > > * ... > > Thoughts > > Pascal > > >>-----Original Message----- >>From: Alexandru Petrescu [mailto:petrescu@nal.motlabs.com] >>Sent: jeudi 20 mars 2003 19:14 >>To: Ryuji Wakikawa >>Cc: vijayd@iprg.nokia.com; Pascal Thubert (pthubert); >>nemo@nal.motlabs.com >>Subject: Re: [nemo] comments on >>draft-wakikawa-nemo-basic-00.txt -> no home network ? >> >> >>Ryuji Wakikawa wrote: >> >>>>IMHO, it is a really inefficient way of routing packets. searching >>>>the binding cache for a route to the mobile network is a lot >>>>slower than having a routing entry in the HA's routing table. >>>>(route lookup is faster). >>> >>> >>>Can you elaborate on the performance difference between binding >>>cache and routing table? Processing steps of searching are almost >>>same. >> >>The only difference I can see is that an execution averages >>shorter times if you use an exact prefix instead of a >>variable longest-prefix match. >> >>Of course, it all depends on too many other factors that are >>very often overlooked in the implementation. I don't think >>we can use speed of search as a differentiator between styles >>of writing specs. >> >>Alex >> >> > From nemo-admin@nal.motlabs.com Thu Mar 20 18:27:05 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13986 for ; Thu, 20 Mar 2003 18:27:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KNP5RC028454; Fri, 21 Mar 2003 00:25:05 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KNOpRC028444 for ; Fri, 21 Mar 2003 00:24:52 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2KNOoK5002318; Thu, 20 Mar 2003 16:24:51 -0700 (MST) Received: [from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA03710; Thu, 20 Mar 2003 16:22:35 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.50]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2KNOUI14737; Thu, 20 Mar 2003 17:24:31 -0600 Message-ID: <3E7A4DBB.7010106@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Ryuji Wakikawa, Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E7A44A1.80306@iprg.nokia.com> In-Reply-To: <3E7A44A1.80306@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 00:24:43 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > > Ryuji Wakikawa wrote: > > > Can you elaborate on the performance difference between binding cache > > and routing table? Processing steps of searching are almost same. > > I have a nice patricia tree for the routing table..... Which routing table? And who is Patricia for that matter anyways. Alex From nemo-admin@nal.motlabs.com Thu Mar 20 18:35:07 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14197 for ; Thu, 20 Mar 2003 18:35:06 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KNX4RC028490; Fri, 21 Mar 2003 00:33:04 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KNWfRC028482 for ; Fri, 21 Mar 2003 00:32:41 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2KNWcGv007671; Thu, 20 Mar 2003 16:32:39 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA09399; Thu, 20 Mar 2003 16:32:38 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.50]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2KNWJI20708; Thu, 20 Mar 2003 17:32:19 -0600 Message-ID: <3E7A4F8F.5060906@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: "Pascal Thubert (pthubert)" , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] moving forward (was: no home network ?) References: <3E7A4820.90103@iprg.nokia.com> In-Reply-To: <3E7A4820.90103@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 00:32:31 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> * Routing protocol between MR and HA => new protocol? Adaptation >> of an existing protocol? > > > I think a new routing protocol is not needed. Me too, a new rotuign protocol is not needed. Exactly per your paragraph below. There are more issues though on how to make an existing protocol work over the MRHA tunnel (or other phrasing). The first thing that I would like to find is whether is there any place where OSPF (example) was made to work over a tunnel. Or maybe that is not the question. > if the MR is at a foriegn link, it turns off routing on the egress > interface. instead it starts sending routing updates through the > tunnel to the Home Agent. when it comes home, it turns on routing > on the egress interface. the tunnel to the Home Agent no longer > exists. routing updates from the MR (either through the > bi-directional tunnel when on foreign link or the egress interface > when on home link) automatically distributes routes to the Home > Agent and other routers on the home link. From nemo-admin@nal.motlabs.com Thu Mar 20 18:57:15 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14668 for ; Thu, 20 Mar 2003 18:57:14 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KNw6RC028596; Fri, 21 Mar 2003 00:58:06 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2KNvxRC028588 for ; Fri, 21 Mar 2003 00:57:59 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2KNvET8026710; Thu, 20 Mar 2003 16:57:14 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id QAA16926; Thu, 20 Mar 2003 16:57:56 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.50]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2KNsSI02893; Thu, 20 Mar 2003 17:54:29 -0600 Message-ID: <3E7A54C1.2010409@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Christophe Janneteau, Ryuji Wakikawa, Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) References: <3E786EFC.FDD9A800@motorola.com> <3E78BAA9.5040106@iprg.nokia.com> <3E799C85.699BA250@motorola.com> <3E7A4549.8040903@iprg.nokia.com> In-Reply-To: <3E7A4549.8040903@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 00:54:41 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > to forward packets to the mobile network prefix, one can use a > combination of binding cache and routing table, So a good sequence of steps of search should be specified. Something like: first search RT, then search BC. What is the difference between that, and a search algorithm on a tree that says: first look right, then look left. I would say very little difference. And if I think the latter is not usually done, maybe the former shouldnt be either. That's one of the reasons I would suppose it is difficult to make a spec where one talks both about RT and BC. Just a suggestion. > I agree with you here. the reason we are discussing this because > there was claimed benefit (both on the mailing list and at the WG > meeting) in using a prefix scoped binding cache entry instead of a > routing entry. I am trying to figure out what it is. So, in my oppinion, if we talk about both RT and BC, I think there is no benefit to have a BCE with something else than the default length. What do you think? Alex From nemo-admin@nal.motlabs.com Thu Mar 20 19:03:02 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14818 for ; Thu, 20 Mar 2003 19:03:01 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L044RC028646; Fri, 21 Mar 2003 01:04:04 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L039RC028636; Fri, 21 Mar 2003 01:03:09 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA06340; Thu, 20 Mar 2003 16:03:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2L033Y00679; Thu, 20 Mar 2003 16:03:03 -0800 X-mProtect: <200303210003> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.218, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHxr8Se; Thu, 20 Mar 2003 16:03:01 PST Message-ID: <3E7A56B4.10000@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E7A44A1.80306@iprg.nokia.com> <3E7A4DBB.7010 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 16:03:00 -0800 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >> >> Ryuji Wakikawa wrote: >> >> > Can you elaborate on the performance difference between binding cache >> > and routing table? Processing steps of searching are almost same. >> >> I have a nice patricia tree for the routing table..... > > > Which routing table? And who is Patricia for that matter anyways. Practical Algorithm To Retrieve Information Coded In Alphanumeric. try google. better still, look at GateD code. Vijay From nemo-admin@nal.motlabs.com Thu Mar 20 19:18:33 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15225 for ; Thu, 20 Mar 2003 19:18:32 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L0K5RC028717; Fri, 21 Mar 2003 01:20:05 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L0JgRC028705 for ; Fri, 21 Mar 2003 01:19:42 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2L0IvT8000051; Thu, 20 Mar 2003 17:18:58 -0700 (MST) Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA20997; Thu, 20 Mar 2003 17:19:39 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.50]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2L0JLI18476; Thu, 20 Mar 2003 18:19:21 -0600 Message-ID: <3E7A5A95.4020107@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E7A44A1.80306@iprg.nokia.com> <3E7A4DBB.7010 <3E7A56B4.10000@iprg.nokia.com> In-Reply-To: <3E7A56B4.10000@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 01:19:33 +0100 Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >>> Ryuji Wakikawa wrote: >>> >>> > Can you elaborate on the performance difference between binding cache >>> > and routing table? Processing steps of searching are almost same. >>> >>> I have a nice patricia tree for the routing table..... >> >> Which routing table? And who is Patricia for that matter anyways. > > Practical Algorithm To Retrieve Information Coded In Alphanumeric. try > google. better still, look at GateD code. Sounds reasonable. We might want to assume that Mobile IPv6 for mobile networks relates in now way to Patricia, or am I biased here? From nemo-admin@nal.motlabs.com Thu Mar 20 19:32:29 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15769 for ; Thu, 20 Mar 2003 19:32:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L0U5RC028775; Fri, 21 Mar 2003 01:30:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L0TkRC028763; Fri, 21 Mar 2003 01:29:47 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA07754; Thu, 20 Mar 2003 16:29:41 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2L0Tfk30285; Thu, 20 Mar 2003 16:29:41 -0800 X-mProtect: <200303210029> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.218, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd8k9TiC; Thu, 20 Mar 2003 16:29:39 PST Message-ID: <3E7A5CF2.7040909@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? References: <20030317093012.04CE.RYUJI@sfc.wide.ad.jp> <3E77F757.3030608@iprg.nokia.com> <3E7A44A1.80306@iprg.nokia.com> <3E7A4DBB.7010 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 16:29:38 -0800 Content-Transfer-Encoding: 7bit Partricia tree is a very widely used data structure for implementing routing table/forwarding table. binding cache is most often a hash list. works well for a few entries. performs very poorly when the binding cache is huge. lets go off the list.... Vijay Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >>>> Ryuji Wakikawa wrote: >>>> >>>> > Can you elaborate on the performance difference between binding >>>> cache >>>> > and routing table? Processing steps of searching are almost same. >>>> >>>> I have a nice patricia tree for the routing table..... >>> >>> >>> Which routing table? And who is Patricia for that matter anyways. >> >> >> Practical Algorithm To Retrieve Information Coded In Alphanumeric. try >> google. better still, look at GateD code. > > > Sounds reasonable. > > We might want to assume that Mobile IPv6 for mobile networks relates in > now way to Patricia, or am I biased here? > From nemo-admin@nal.motlabs.com Thu Mar 20 19:48:53 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16046 for ; Thu, 20 Mar 2003 19:48:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L0l5RC028854; Fri, 21 Mar 2003 01:47:05 +0100 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L0kYRC028846 for ; Fri, 21 Mar 2003 01:46:35 +0100 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2L0k24c010032; Thu, 20 Mar 2003 16:46:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACM44711; Thu, 20 Mar 2003 16:46:01 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA13875; Thu, 20 Mar 2003 16:46:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15994.24777.7681.166399@thomasm-u1.cisco.com> To: Vijay Devarapalli Cc: Christophe Janneteau , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) In-Reply-To: <3E7A4549.8040903@iprg.nokia.com> References: <3E786EFC.FDD9A800@motorola.com> <3E78BAA9.5040106@iprg.nokia.com> <3E799C85.699BA250@motorola.com> <3E7A4549.8040903@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 16:46:01 -0800 (PST) Content-Transfer-Encoding: 7bit Vijay, I don't want to belabor this either, but it seems to me that what you pointing out is two different implementation approaches, rather than fundamental differences in needed functionality. Couldn't a bind cache entry be implemented as a host route, for example? The reason I ask is *mainly* to try to figure out whether we're arguing about terminology as implied by implementation, rather than actual differences in performance with one approach vs. another... Mike Vijay Devarapalli writes: > > jeez.. how did we get into this discussion? I guess I am partly > to blame. anyway, for the rest of the WG, what we are discussing > is highly implementation specific. Christophe has a point there. > > having said that, I prefer using a routing table entry to route > to a /64 prefix instead of using the binding cache entry. one of > the reasons is that in the platform that we use for MIPv6 HA, > there is a highly efficient data structure for the routing table, > but a not so efficient data structure (in terms of searching the > data structure) for the binding cache. I think this would be > true for most home agents. > > route lookups are fast on any router (otherwise who is going to > use your router?), and they continue to improve. > > to forward packets to the mobile network prefix, one can use a > combination of binding cache and routing table, only the routing > table or only the binding cache. I agree with that. also, tunnel > interface betwen the MR and the HA can be conceptual. > > what I would like to see is a routing table entry for the mobile > router's network prefix with the outgoing interface pointing to > the tunnel interface (MR_HA, MR_CoA). this works well with IPsec > too (as shown in draft-ietf-mobileip-mipv6-ha-ipsec-03.txt). > this however requires that we change the tunnel end point > information whenever the MR changes its CoA. we already do this > with MIPv6. the tunnel end point information inside the SADB is > updated as the MN moves. we basically resuse IPsec in tunnel > mode, where the MR - HA tunnel becomes a IPsec tunnel. we do the > same here. > > if you implement the tunnel as a virtual interface it is easy to > update the end point information in the interface data structure. > if you implement it using the binding cache, it is again easy to > update the information in the binding cache. > > now, onto your mail > > Christophe Janneteau wrote: > > o Case 1: This routing table entry would looks like: > > > > Prefix NextHop OutputIFC > > nemo/64 MR_HoA eth0 (inteface towards MR's home link) > > we dont want to use this. I dont like Case 1 either. > > > In addition, as > > said by someone earlier on the mailing list, this would suggest a > > departure from traditional parsing of the routing table since only > > NextHop but not outputIFC should be considered in that case... > > noooo, you can have a routing table entry where only the outgoing > interface is specified. > > > > > o Case 2: This routing table entry would looks like: > > > > Prefix NextHop OutputIFC > > nemo/64 :: MR_HA_tunnel_ifc > > > > No NextHop is specified but the output interface is directly said to be > > the MR-HA tunnel. Here we would not need anymore parsing of the BC > > (departure from Mobile IPv6) but would have to update the tunnel > > endpoint in the routing table each time MR moves. > > uh... the tunnel information is not stored in the routing table. > a tunnel is created as a separate interface and is given a name. > then you enter the name of the interface as the outgoing interface > in the route entry. when you do a lookup by the lname you get the > actual tunnel information. > > > The problem with this > > approach is that it assumes a tunnel (e.g. MR-HA tunnel) is implemented > > as a virtual network interface....which is not true for all (currently > > used) IPv6 stack. This would make the spec too implementation specific > > in my opinion, and make porting of some existing Mobile IPv6 > > implementations to NEMO quite difficult... > > thats the funny part. MIPv6 and MIPv6 ha-mn-ipsec draft kind of > assume a tunnel interface between the MN_CoA and the HA. they also > argue for updating the tunnel end point as the MN moves. I like > this model..... > > > > Again I have nothing against an implementation that would use approaches > > 1 or 2, but i think this should not be THE description of the protocol, > > but only a possible implemtation (e.g. in annex of the nemo spec). > > I agree with you here. the reason we are discussing this because > there was claimed benefit (both on the mailing list and at the WG > meeting) in using a prefix scoped binding cache entry instead of > a routing entry. I am trying to figure out what it is. > > Vijay > > From nemo-admin@nal.motlabs.com Thu Mar 20 20:00:16 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16318 for ; Thu, 20 Mar 2003 20:00:15 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L115RC028935; Fri, 21 Mar 2003 02:01:05 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L105RC028907 for ; Fri, 21 Mar 2003 02:00:06 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA08352; Thu, 20 Mar 2003 16:59:58 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2L0xvc13023; Thu, 20 Mar 2003 16:59:57 -0800 X-mProtect: <200303210059> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.50.218, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhmahlw; Thu, 20 Mar 2003 16:59:55 PST Message-ID: <3E7A640A.2040601@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas CC: Christophe Janneteau , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] MR-HA uses BC (was [nemo] comments on draft-wakikawa-nemo-basic-00.txt-> no homenetwork ?) References: <3E786EFC.FDD9A800@motorola.com> <3E78BAA9.5040106@iprg.nokia.com> <3E799C85.699BA250@motorola.com> <3E7A4549.8040903@iprg.nokia.com> <15994.24777.7681.166399@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 16:59:54 -0800 Content-Transfer-Encoding: 7bit Michael Thomas wrote: > Vijay, > > I don't want to belabor this either, but it seems > to me that what you pointing out is two different > implementation approaches, rather than fundamental > differences in needed functionality. Couldn't a > bind cache entry be implemented as a host route, > for example? sure. you would also need a flag in the host route entry telling the forwarding code to add a tunnel or a routing header when it comes across this host route. > > The reason I ask is *mainly* to try to figure out > whether we're arguing about terminology as implied > by implementation, rather than actual differences > in performance with one approach vs. another... we started discussing the differences and ended up discussing the actual implementations. Vijay From nemo-admin@nal.motlabs.com Thu Mar 20 22:27:13 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20044 for ; Thu, 20 Mar 2003 22:27:03 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L3OhRC001828; Fri, 21 Mar 2003 04:24:48 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L3N5RC001815; Fri, 21 Mar 2003 04:23:10 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2L3Kx1D003309; Fri, 21 Mar 2003 04:21:00 +0100 (MET) Received: from xbe-lon-312.cisco.com ([64.103.99.72]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 21 Mar 2003 04:22:42 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Mar 2003 03:22:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] moving forward (was: no home network ?) Message-ID: Thread-Topic: [nemo] moving forward (was: no home network ?) Thread-Index: AcLvOQTZJS5sxHxrTuS6fy8b42qUcAAHvr8Q From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" , "Vijay Devarapalli" Cc: "Ryuji Wakikawa" , X-OriginalArrivalTime: 21 Mar 2003 03:22:42.0133 (UTC) FILETIME=[21FFB850:01C2EF59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2L3N5RC001815 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 03:22:41 -0000 Content-Transfer-Encoding: 8bit > >> an existing protocol? > > > > > > I think a new routing protocol is not needed. > > Me too, a new routing protocol is not needed. Exactly per > your paragraph below. > > There are more issues though on how to make an existing > protocol work over the MRHA tunnel (or other phrasing). The > first thing that I would like to find is whether is there any > place where OSPF (example) was made to work over a tunnel. > Or maybe that is not the question. > > Both PSBU and draft-wakikawa introduce a new routing protocol. The argument is that a protocol such as RIP or OSPF may create an additional control traffic overhead for a stub that will always be there, which seems to be a costly overkill in some mobility situations. This is why I raise the point. I do not think it's that clear cut though my mind is not made. Vijay's proposal seems to work fine with no additional involvement on our part, but seems impractical over 9.6K GSM or very little more GPRS. My point was mostly that *If* we decide that we need a simpler protocol in terms of advertisements, routes and the redistribution stays the same. Pascal From nemo-admin@nal.motlabs.com Thu Mar 20 22:44:51 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20391 for ; Thu, 20 Mar 2003 22:44:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L3k4RC001959; Fri, 21 Mar 2003 04:46:04 +0100 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L3juRC001951; Fri, 21 Mar 2003 04:45:57 +0100 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2L3jTHp024973; Thu, 20 Mar 2003 19:45:30 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACM58901; Thu, 20 Mar 2003 19:45:29 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA13881; Thu, 20 Mar 2003 19:45:29 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15994.35545.375755.623493@thomasm-u1.cisco.com> To: "Pascal Thubert (pthubert)" Cc: "Alexandru Petrescu" , "Vijay Devarapalli" , "Ryuji Wakikawa" , Subject: RE: [nemo] moving forward (was: no home network ?) In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 19:45:29 -0800 (PST) Content-Transfer-Encoding: 7bit Maybe this is redundant with what Pascal raises, but it seems that there are a couple of orthogonal issues going on here: 1) How do we plumb a mobile network? 2) How do we distribute routes once plumbed? I've always had it in mind that this wg was mainly interested in (1) and that for (2(, nothing really stops you from running IS-IS or OSPF or RIP or whatever. The point Pascal brings up is interesting though. It's not clear that what you want is necessarily a new routing protocol so much as compression and/or partitioning -- which sounds sort of outside my understanding of the NEMO charter, but might find an audience for a BOF sometime in the future... Mike Pascal Thubert (pthubert) writes: > > > >> an existing protocol? > > > > > > > > > I think a new routing protocol is not needed. > > > > Me too, a new routing protocol is not needed. Exactly per > > your paragraph below. > > > > There are more issues though on how to make an existing > > protocol work over the MRHA tunnel (or other phrasing). The > > first thing that I would like to find is whether is there any > > place where OSPF (example) was made to work over a tunnel. > > Or maybe that is not the question. > > > > > Both PSBU and draft-wakikawa introduce a new routing protocol. The > argument is that a protocol such as RIP or OSPF may create an additional > control traffic overhead for a stub that will always be there, which > seems to be a costly overkill in some mobility situations. > > This is why I raise the point. I do not think it's that clear cut though > my mind is not made. Vijay's proposal seems to work fine with no > additional involvement on our part, but seems impractical over 9.6K GSM > or very little more GPRS. > > My point was mostly that *If* we decide that we need a simpler protocol > in terms of advertisements, routes and the redistribution stays the > same. > > Pascal > From nemo-admin@nal.motlabs.com Thu Mar 20 23:04:58 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20767 for ; Thu, 20 Mar 2003 23:04:55 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L455RC002079; Fri, 21 Mar 2003 05:05:05 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L442RC002066 for ; Fri, 21 Mar 2003 05:04:04 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2L43dKc009387; Thu, 20 Mar 2003 21:03:42 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id VAA17881; Thu, 20 Mar 2003 21:03:44 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.42]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h2L43fT27393; Thu, 20 Mar 2003 22:03:41 -0600 Message-ID: <3E7A8F1C.1080601@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: Vijay Devarapalli, Ryuji Wakikawa, Subject: Re: [nemo] moving forward (was: no home network ?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 05:03:40 +0100 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >>> I think a new routing protocol is not needed. >> >> Me too, a new routing protocol is not needed. Exactly per your >> paragraph below. > > Both PSBU and draft-wakikawa introduce a new routing protocol. For the purpose of discussion, let's call a routing protocol something that modifies the routing table, and that has prefixes in the routing table. In this context, contrast Mobile IPv6 that modifies a binding cache (not the routing table), and that has full /128s in the binding cache (no prefixes). By this distinction, draft-wakikawa does fit both a routing protocol and Mobile IPv6. > The argument is that a protocol such as RIP or OSPF may create an > additional control traffic overhead for a stub that will always be > there, which seems to be a costly overkill in some mobility > situations. Those are questions that are not addressed neither by routing protocols nor by Mobile IP I believe. > Vijay's proposal seems to work fine with no additional involvement > on our part I don't think Vijay made such a claim? Vijay? > but seems impractical over 9.6K GSM or very little more GPRS. I don't know whether improving Vijay's proposal relying on GSM/GPRS criteria is a good way to go. Alex From nemo-admin@nal.motlabs.com Fri Mar 21 00:16:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22049 for ; Fri, 21 Mar 2003 00:16:37 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5HCRC002594; Fri, 21 Mar 2003 06:17:13 +0100 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5GQRC002582 for ; Fri, 21 Mar 2003 06:16:29 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 7FB8668974 for ; Fri, 21 Mar 2003 00:16:18 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2L5GI7h029169 for ; Fri, 21 Mar 2003 00:16:18 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-22.lerc.nasa.gov [139.88.246.22]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2L5GFcB001032 for ; Fri, 21 Mar 2003 00:16:17 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030321001044.02419390@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: nemo@nal.motlabs.com From: William D Ivancic Subject: RE: [nemo] moving forward (was: no home network ?) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 00:15:54 -0500 > > > There are more issues though on how to make an existing > > protocol work over the MRHA tunnel (or other phrasing). The > > first thing that I would like to find is whether is there any > > place where OSPF (example) was made to work over a tunnel. > > Or maybe that is not the question. I believe one should be able to easily run a routing protocol over a tunnel. However, do not decrement the TTL or, I believe, you will find it does not work. The TTL is set to one, gets decremented to Zero and the packet is dropped. I had this problem when placing encryptors between an FA and MR router in IPv4. The problem also arose when I needed to run routing protocols over a tunnel using external encryption devices. Will From nemo-admin@nal.motlabs.com Fri Mar 21 00:20:24 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22139 for ; Fri, 21 Mar 2003 00:20:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5L4RC002661; Fri, 21 Mar 2003 06:21:04 +0100 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5KSRC002635; Fri, 21 Mar 2003 06:20:29 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id EFC22689DD; Fri, 21 Mar 2003 00:20:21 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2L5KL7h029762; Fri, 21 Mar 2003 00:20:21 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (firewall-user@vtcp2-22.lerc.nasa.gov [139.88.246.22]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2L5KHcB001517; Fri, 21 Mar 2003 00:20:18 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030321001632.02406570@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: "Pascal Thubert (pthubert)" From: William D Ivancic Subject: RE: [nemo] moving forward (was: no home network ?) Cc: "Alexandru Petrescu" , "Vijay Devarapalli" , "Ryuji Wakikawa" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 00:19:56 -0500 Bandwidths on mobile links may be very small and often are. Also, routing protocols have global convergence times. So, although it may be possible to run RIP, OSPF, or some new routing protocol through a tunnel, one should really consider if this is appropriate for your mobile network, Will At 03:22 AM 3/21/2003 +0000, Pascal Thubert (pthubert) wrote: > > > There are more issues though on how to make an existing > > protocol work over the MRHA tunnel (or other phrasing). The > > first thing that I would like to find is whether is there any > > place where OSPF (example) was made to work over a tunnel. > > Or maybe that is not the question. > > > > >Both PSBU and draft-wakikawa introduce a new routing protocol. The >argument is that a protocol such as RIP or OSPF may create an additional >control traffic overhead for a stub that will always be there, which >seems to be a costly overkill in some mobility situations. > >This is why I raise the point. I do not think it's that clear cut though >my mind is not made. Vijay's proposal seems to work fine with no >additional involvement on our part, but seems impractical over 9.6K GSM >or very little more GPRS. > >My point was mostly that *If* we decide that we need a simpler protocol >in terms of advertisements, routes and the redistribution stays the >same. > >Pascal From nemo-admin@nal.motlabs.com Fri Mar 21 00:29:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22282 for ; Fri, 21 Mar 2003 00:29:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5T7RC002736; Fri, 21 Mar 2003 06:29:07 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5RxRC002721; Fri, 21 Mar 2003 06:28:03 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA17097; Thu, 20 Mar 2003 21:27:51 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2L5RpI21128; Thu, 20 Mar 2003 21:27:51 -0800 X-mProtect: <200303210527> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.180, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdafgpwJ; Thu, 20 Mar 2003 21:27:48 PST Message-ID: <3E7AA2D2.8070104@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William D Ivancic CC: "Pascal Thubert (pthubert)" , Alexandru Petrescu , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] moving forward (was: no home network ?) References: <5.1.1.5.2.20030321001632.02406570@popserve.grc.nasa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 21:27:46 -0800 Content-Transfer-Encoding: 7bit thats right. a PAN connected through a low bandwidth link should depend on its HA to manage routes for it. I dont expect the mobile router in the PAN to run a routing protocol either. Vijay William D Ivancic wrote: > Bandwidths on mobile links may be very small and often are. Also, > routing protocols have global convergence times. So, although it may be > possible to run RIP, OSPF, or some new routing protocol through a > tunnel, one should really consider if this is appropriate for your > mobile network, > > Will > > > > At 03:22 AM 3/21/2003 +0000, Pascal Thubert (pthubert) wrote: > >> >> > There are more issues though on how to make an existing >> > protocol work over the MRHA tunnel (or other phrasing). The >> > first thing that I would like to find is whether is there any >> > place where OSPF (example) was made to work over a tunnel. >> > Or maybe that is not the question. >> > >> > >> Both PSBU and draft-wakikawa introduce a new routing protocol. The >> argument is that a protocol such as RIP or OSPF may create an additional >> control traffic overhead for a stub that will always be there, which >> seems to be a costly overkill in some mobility situations. >> >> This is why I raise the point. I do not think it's that clear cut though >> my mind is not made. Vijay's proposal seems to work fine with no >> additional involvement on our part, but seems impractical over 9.6K GSM >> or very little more GPRS. >> >> My point was mostly that *If* we decide that we need a simpler protocol >> in terms of advertisements, routes and the redistribution stays the >> same. >> >> Pascal > > From nemo-admin@nal.motlabs.com Fri Mar 21 00:37:48 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22409 for ; Fri, 21 Mar 2003 00:37:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5b4RC002863; Fri, 21 Mar 2003 06:37:04 +0100 Received: from asama.sfc.wide.ad.jp (t41-176.internetits.org [203.178.140.176]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5aORC002846 for ; Fri, 21 Mar 2003 06:36:28 +0100 Received: from localhost (localhost [127.0.0.1]) by asama.sfc.wide.ad.jp (8.12.6/8.12.6) with ESMTP id h2L5YNoE002621; Fri, 21 Mar 2003 14:34:24 +0900 (JST) (envelope-from kei@wide.ad.jp) Message-Id: <20030321.143423.783373998.kei@wide.ad.jp> To: vijayd@iprg.nokia.com Cc: ryuji@sfc.wide.ad.jp, nemo@nal.motlabs.com Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? From: Keisuke UEHARA In-Reply-To: <3E7A44A1.80306@iprg.nokia.com> References: <3E77F757.3030608@iprg.nokia.com> <3E7A44A1.80306@iprg.nokia.com> X-Mailer: Mew version 2.2 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 14:34:23 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Vijay, From: Vijay Devarapalli Subject: Re: [nemo] comments on draft-wakikawa-nemo-basic-00.txt -> no home network ? Date: Thu, 20 Mar 2003 14:45:53 -0800 > > Can you elaborate on the performance difference between binding cache > > and routing table? Processing steps of searching are almost same. > > I have a nice patricia tree for the routing table..... And you can implement BC using the nice tree algorithm, if you wish. I try to make clear the discussion: There are 2 issues: (1) How to distribute the routing information for MR-A/64? (2) How to forward the packet addressed to a node on the Mobile Network (for example MR-A, LFN). These two are quite difference. For (1), Routing protocols like OSPF can be used. Of cause, you can use static configuration way. It is an operational issue. For (2), as mentiond in previous my mail, we can use routing table instead of BC. It is implementation issue. In the draft, BC is introduced as a concept. When the HA receives then BU, HA have to manage the binding informatin somehow during the Binding is valid. And when the HA recevies a packet addressed to the mobile network, HA have to forward the packet to MR-A using tunnel. How the tunnel is setup and used are implementation issue. I hope my mail is useful to clarify the discussion. Regards, Kei From nemo-admin@nal.motlabs.com Fri Mar 21 00:40:20 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22452 for ; Fri, 21 Mar 2003 00:40:18 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5e7RC002921; Fri, 21 Mar 2003 06:40:07 +0100 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2L5dMRC002901; Fri, 21 Mar 2003 06:39:25 +0100 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA17301; Thu, 20 Mar 2003 21:39:15 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h2L5dDS26368; Thu, 20 Mar 2003 21:39:13 -0800 X-mProtect: <200303210539> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.180, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3x5nSG; Thu, 20 Mar 2003 21:39:11 PST Message-ID: <3E7AA57E.6090406@iprg.nokia.com> From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli CC: William D Ivancic , "Pascal Thubert (pthubert)" , Alexandru Petrescu , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] moving forward (was: no home network ?) References: <5.1.1.5.2.20030321001632.02406570@popserve.grc.nasa.gov> <3E7AA2D2.8070104@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 20 Mar 2003 21:39:10 -0800 Content-Transfer-Encoding: 7bit my point is it would be good to work on a solution that would work for a PAN network and at the same time work well for a huge mobile network. that is why there are two scenarios in draft-kniveton-mobrtr. a simple PAN would use the consumer model. and a mobile router capable of lot more (and if it is not constrained by low bandwidth uplink), should run a routing protocol with the routers on its home link through the bi-directional tunnel. the latter model IMO, is lot more superior than trying to manage static routes on the Home Agent. Vijay Vijay Devarapalli wrote: > thats right. a PAN connected through a low bandwidth link should > depend on its HA to manage routes for it. I dont expect the > mobile router in the PAN to run a routing protocol either. > > Vijay > > William D Ivancic wrote: > >> Bandwidths on mobile links may be very small and often are. Also, >> routing protocols have global convergence times. So, although it may >> be possible to run RIP, OSPF, or some new routing protocol through a >> tunnel, one should really consider if this is appropriate for your >> mobile network, >> >> Will >> >> >> >> At 03:22 AM 3/21/2003 +0000, Pascal Thubert (pthubert) wrote: >> >>> >>> > There are more issues though on how to make an existing >>> > protocol work over the MRHA tunnel (or other phrasing). The >>> > first thing that I would like to find is whether is there any >>> > place where OSPF (example) was made to work over a tunnel. >>> > Or maybe that is not the question. >>> > >>> > >>> Both PSBU and draft-wakikawa introduce a new routing protocol. The >>> argument is that a protocol such as RIP or OSPF may create an additional >>> control traffic overhead for a stub that will always be there, which >>> seems to be a costly overkill in some mobility situations. >>> >>> This is why I raise the point. I do not think it's that clear cut though >>> my mind is not made. Vijay's proposal seems to work fine with no >>> additional involvement on our part, but seems impractical over 9.6K GSM >>> or very little more GPRS. >>> >>> My point was mostly that *If* we decide that we need a simpler protocol >>> in terms of advertisements, routes and the redistribution stays the >>> same. >>> >>> Pascal >> >> >> > > From nemo-admin@nal.motlabs.com Fri Mar 21 09:08:53 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13895 for ; Fri, 21 Mar 2003 09:08:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LEAGRC006324; Fri, 21 Mar 2003 15:10:16 +0100 Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LE9pRC006312 for ; Fri, 21 Mar 2003 15:09:53 +0100 Received: by sentry.gw.tislabs.com; id JAA16367; Fri, 21 Mar 2003 09:10:44 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma016347; Fri, 21 Mar 03 09:10:09 -0500 Received: from phoenix.gw.tislabs.com (phoenix.gw.tislabs.com [10.33.40.87]) by raven.gw.tislabs.com (8.11.6/8.11.6) with ESMTP id h2LE9DN05554; Fri, 21 Mar 2003 09:09:13 -0500 (EST) Received: (from sandy@localhost) by phoenix.gw.tislabs.com (8.11.2/8.11.2) id h2LE9BX20128; Fri, 21 Mar 2003 09:09:11 -0500 From: Sandy Murphy Message-Id: <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> To: vijayd@iprg.nokia.com Subject: Re: [nemo] moving forward (was: no home network ?) Cc: nemo@nal.motlabs.com, sandy@tislabs.com Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 09:09:11 -0500 >thats right. a PAN connected through a low bandwidth link should >depend on its HA to manage routes for it. I dont expect the >mobile router in the PAN to run a routing protocol either. I'm speaking as a lurker who can't swear to have read the whole thread here, but I've always been curious about the nested nemo's case. Is the nesting supposed to be static? Will there never be the case that a grandchild net might jump over to become a child in another nested net? If that can happen, who handles the revision of routing? Are you saying that the routing change has to go back to the HA? Can there ever be the case that a child in one nested net could pass traffic directly to another child in the same nested net without going back through the base-wired-landline net? --Sandy From nemo-admin@nal.motlabs.com Fri Mar 21 10:32:55 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16941 for ; Fri, 21 Mar 2003 10:32:53 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LFY5RC006624; Fri, 21 Mar 2003 16:34:05 +0100 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LFXQRC006616 for ; Fri, 21 Mar 2003 16:33:27 +0100 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2LFX7Hp020470; Fri, 21 Mar 2003 07:33:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACM84965; Fri, 21 Mar 2003 07:33:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA14043; Fri, 21 Mar 2003 07:33:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.12465.892361.774220@thomasm-u1.cisco.com> To: Sandy Murphy Cc: vijayd@iprg.nokia.com, nemo@nal.motlabs.com Subject: Re: [nemo] moving forward (was: no home network ?) In-Reply-To: <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> References: <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 07:33:05 -0800 (PST) Content-Transfer-Encoding: 7bit Sandy Murphy writes: > Is the nesting supposed to be static? Will there never be the case > that a grandchild net might jump over to become a child in another > nested net? If that can happen, who handles the revision of routing? > Are you saying that the routing change has to go back to the HA? It certainly seems to me that it *could* be static as each layer of nesting has no clue about the other layer -- just like the LMN's don't have any idea that they are behind a mobile router. As an aside, this is why I'm dubious about any kind of artificial edict about the number of layers... how could you even know if you're violating it? [*] > Can there ever be the case that a child in one nested net could pass > traffic directly to another child in the same nested net without > going back through the base-wired-landline net? As it currently stands, no. This is, of course, why route optimization would be nice if it could be engineered... Mike [*] it seems to me that if we don't limit, we need some way to detect topological messes for network admins, if not provide some BCP kind of advise for how to untangle messes... From nemo-admin@nal.motlabs.com Fri Mar 21 10:56:27 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17514 for ; Fri, 21 Mar 2003 10:56:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LFw5RC006723; Fri, 21 Mar 2003 16:58:05 +0100 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LFvWRC006715; Fri, 21 Mar 2003 16:57:32 +0100 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2LFv7Hr009762; Fri, 21 Mar 2003 07:57:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACM86377; Fri, 21 Mar 2003 07:57:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA14046; Fri, 21 Mar 2003 07:57:06 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15995.13906.807997.274159@thomasm-u1.cisco.com> To: Vijay Devarapalli Cc: William D Ivancic , "Pascal Thubert (pthubert)" , Alexandru Petrescu , Ryuji Wakikawa , nemo@nal.motlabs.com Subject: Re: [nemo] moving forward (was: no home network ?) In-Reply-To: <3E7AA57E.6090406@iprg.nokia.com> References: <5.1.1.5.2.20030321001632.02406570@popserve.grc.nasa.gov> <3E7AA2D2.8070104@iprg.nokia.com> <3E7AA57E.6090406@iprg.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 07:57:06 -0800 (PST) Content-Transfer-Encoding: 7bit Vijay Devarapalli writes: > my point is it would be good to work on a solution that would > work for a PAN network and at the same time work well for a > huge mobile network. that is why there are two scenarios in > draft-kniveton-mobrtr. a simple PAN would use the consumer > model. and a mobile router capable of lot more (and if it is > not constrained by low bandwidth uplink), should run a routing > protocol with the routers on its home link through the > bi-directional tunnel. the latter model IMO, is lot more > superior than trying to manage static routes on the Home Agent. From my standpoint, I'm not convinced that it's clear that keeping down the classic MIP/PAN kind of approach that's emerging is even the right approach at all for a huge and complicated set of nested routers. Likewise, it seems to me that something that did handle the large case well would probably crushed the simple PAN/MR case under its own weight. So I for one am happy with this partition of the problem space. Living with the unpleasent consequences of lack of RO and some deployment experience is probably better than trying to partially -- and potentially harmfully -- help the situation. Mike, who suspects that the large case is IRTF material... From nemo-admin@nal.motlabs.com Fri Mar 21 11:59:18 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18795 for ; Fri, 21 Mar 2003 11:59:17 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LH07RC006961; Fri, 21 Mar 2003 18:00:07 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LGxLRC006947 for ; Fri, 21 Mar 2003 17:59:21 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2LGuKbk023892; Fri, 21 Mar 2003 17:57:18 +0100 (MET) Received: from xbe-lon-312.cisco.com ([64.103.99.72]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 21 Mar 2003 17:58:49 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 21 Mar 2003 16:58:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] moving forward (was: no home network ?) Message-ID: Thread-Topic: [nemo] moving forward (was: no home network ?) Thread-Index: AcLvv6H3Rq3xBuT3T3W9N6Q8HBWzVQAC3sfg From: "Pascal Thubert (pthubert)" To: "mat (mailer list)" , "Sandy Murphy" Cc: , X-OriginalArrivalTime: 21 Mar 2003 16:58:49.0603 (UTC) FILETIME=[24E2AD30:01C2EFCB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2LGxLRC006947 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 16:58:49 -0000 Content-Transfer-Encoding: 8bit > > Can there ever be the case that a child in one nested net > could pass > traffic directly to another child in the same > nested net without > going back through the base-wired-landline net? > > As it currently stands, no. This is, of course, > why route optimization would be nice if it could > be engineered... > True... Unless you place an aggregating home agent in a MR up in the nested structure. Pascal From nemo-admin@nal.motlabs.com Fri Mar 21 12:05:41 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18991 for ; Fri, 21 Mar 2003 12:05:40 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LH63RC007009; Fri, 21 Mar 2003 18:06:03 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LH58RC007001 for ; Fri, 21 Mar 2003 18:05:09 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 28ED75D10E; Sat, 22 Mar 2003 02:05:00 +0900 (JST) Message-Id: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> To: jmanner@cs.Helsinki.FI, nemo@nal.motlabs.com, seamoby@ietf.org From: Thierry Ernst In-Reply-To: References: X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: The NEMO/Seamoby terminology Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 22 Mar 2003 02:04:59 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Jukka, all, From: Jukka MJ Manner > Hi Thierry, > I had a talk with Kempf and he would like to get the Seamoby terminology > document to Last Call as soon as possible. Thus, if you could tell me what > NEMO terms would be needed in the Seamoby terminology, please, let me know > as soon as possible. I'll add those and then submit a version for final > call. If the current terms are sufficient, then we can make the last call > immediately. The seamoby terminology contains a section about mobile networks. We, NEMO WG, should make sure those terms are consistent with ours. I was particularly slow reacting to Seamoby request to merge some of our terms, the opportunity window has reached end. So let's do it now to make sure we are consistent. The semoboby terminology already contains a number of terms which are basically cut-and-paste from the NEMO terminology draft, i.e. the most general ones, For consistency, those terms should be removed from the NEMO terminology. It also makes sense to move NEMO terms which have a general scope to draft-seamoby, while keeping the more specifi ones in NEMO. Thus, for consistency and improvement, I think both drafts should be updated the following way: draft-seamoby-mmobility-terminology-02.txt - add "fixed node" as opposed to "mobile node" - update definition of mobile router (Seamoby def not the same as NEMO def) - add network mobility, as opposed to "host mobility" - add egress interface - add ingress interface - add home link prefix - add foreign link prefix draft-ernst-nemo-terminology-01.txt: - update defintion of mobile network with text in NEMO terminology's introducion - remove definition of AR - remove or extend definition of mobile network, MR, MNN - move words about "maintain sessions" from definition MN to definition of LFN, VMN, LMN - remove egress interface - remove ingress interface - remove home subnet prefix - remove foreign subnet prefix - intra-domain mobility - inter-domain mobility Thierry From nemo-admin@nal.motlabs.com Fri Mar 21 12:20:53 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19416 for ; Fri, 21 Mar 2003 12:20:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LHM9RC007073; Fri, 21 Mar 2003 18:22:11 +0100 Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LHLhRC007064 for ; Fri, 21 Mar 2003 18:21:43 +0100 Received: from melkinpaasi.cs.Helsinki.FI (melkinpaasi.cs.helsinki.fi [::ffff:128.214.10.13]) (IDENT: jmanner, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 21 Mar 2003 19:21:42 +0200 From: Jukka MJ Manner To: Thierry Ernst cc: nemo@nal.motlabs.com, seamoby@ietf.org In-Reply-To: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: The NEMO/Seamoby terminology Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 19:21:42 +0200 (EET) Content-Transfer-Encoding: 7bit Hi, you proposal sounds good. Some questions/comments, though: - The "fixed node" term does not mention IPv4-based nodes? - The "network mobility" would fit into the section discussing personal and host mobility, I guess. - All interface and prefix terms would go into the Mobile Network section of the Seamoby draft, right? They are mainly (only?) used there? Regards, Jukka On Sat, 22 Mar 2003, Thierry Ernst wrote: > > Hi Jukka, all, > > From: Jukka MJ Manner > > Hi Thierry, > > I had a talk with Kempf and he would like to get the Seamoby terminology > > document to Last Call as soon as possible. Thus, if you could tell me what > > NEMO terms would be needed in the Seamoby terminology, please, let me know > > as soon as possible. I'll add those and then submit a version for final > > call. If the current terms are sufficient, then we can make the last call > > immediately. > > The seamoby terminology contains a section about mobile networks. We, > NEMO WG, should make sure those terms are consistent with ours. I was > particularly slow reacting to Seamoby request to merge some of our > terms, the opportunity window has reached end. So let's do it now to > make sure we are consistent. > > The semoboby terminology already contains a number of terms which are > basically cut-and-paste from the NEMO terminology draft, i.e. the most > general ones, For consistency, those terms should be removed from the > NEMO terminology. It also makes sense to move NEMO terms which have a > general scope to draft-seamoby, while keeping the more specifi ones in > NEMO. > > Thus, for consistency and improvement, I think both drafts should be > updated the following way: > > draft-seamoby-mmobility-terminology-02.txt > - add "fixed node" as opposed to "mobile node" > - update definition of mobile router (Seamoby def not the same as NEMO > def) > - add network mobility, as opposed to "host mobility" > - add egress interface > - add ingress interface > - add home link prefix > - add foreign link prefix > > draft-ernst-nemo-terminology-01.txt: > - update defintion of mobile network with text in NEMO terminology's > introducion > - remove definition of AR > - remove or extend definition of mobile network, MR, MNN > - move words about "maintain sessions" from definition MN to > definition of LFN, VMN, LMN > - remove egress interface > - remove ingress interface > - remove home subnet prefix > - remove foreign subnet prefix > - intra-domain mobility > - inter-domain mobility > > Thierry > From nemo-admin@nal.motlabs.com Fri Mar 21 13:30:27 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21816 for ; Fri, 21 Mar 2003 13:30:25 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LIV8RC008140; Fri, 21 Mar 2003 19:31:08 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2LIUbRC008114 for ; Fri, 21 Mar 2003 19:30:37 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2LIUSlS018783; Fri, 21 Mar 2003 11:30:29 -0700 (MST) Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id LAA29347; Fri, 21 Mar 2003 11:30:28 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.16]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id h2LIVJ420931; Fri, 21 Mar 2003 12:31:19 -0600 Message-ID: <3E7B5A3F.90907@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandy Murphy CC: , Subject: Re: [nemo] moving forward (was: no home network ?) References: <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> In-Reply-To: <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 19:30:23 +0100 Content-Transfer-Encoding: 7bit Sandy Murphy wrote: > I'm speaking as a lurker who can't swear to have read the whole > thread here, but I've always been curious about the nested nemo's > case. My understanding of nested mobile networks at this point is that there exist certain configurations of nested mobile networks that work with the basic-type of NEMO solution (a Mobile IPv6 protocol with the bidir tunnel, but no ospf or rip). Of course, there are other nested configurations that are not supported, and I don't think there is any requirement to try to support all forms of nested configurations. > Is the nesting supposed to be static? I don't think nesting is static, but there are only certain forms of dynamicity that are supported. Others are not. > Will there never be the case that a grandchild net might jump over > to become a child in another nested net? If I'm getting you right, this corresponds to some pictures I drawed to the list at some point in time. I could refill space here, if needed, but otherwise there's an explanation of "cross-over" tunnels in section B.6 of draft-petrescu-nemo-mrha. If that kind of configuration corresponds to the model you're describing, then it is an open question to me whether we're going to try to support it with a basic solution with Mobile IPv6 (and with no routing protocol like ospf or rip). What do you think, are there reasons to try to support this kinds of configurations (that involve "cross-over" tunnels)? > If that can happen, who handles the revision of routing? Are you > saying that the routing change has to go back to the HA? If you want, may we try to draw lines and pictures, because I don't understand if your various mobile networks have the same HA. How were those two mobile subnets configured when they were at home? For example, if the two mobile networks have the same HA, and that they are peers when they are at home (not aggregated one under the other), then they can nest one under the other at any time; this will involve updating the BC of the HA, but will not involve routing table updates at HA. > Can there ever be the case that a child in one nested net could > pass traffic directly to another child in the same nested net > without going back through the base-wired-landline net? I don't think that the currently thought basic-type of solution looks into that kind of problem. At least not from what I've seen until now. Is this "disconnected operation" problem one of the goals of a basic-types of solutions? Alex From nemo-admin@nal.motlabs.com Mon Mar 24 06:07:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10267 for ; Mon, 24 Mar 2003 06:07:30 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2OB8FRC005330; Mon, 24 Mar 2003 12:08:16 +0100 Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2OB7TRC005320 for ; Mon, 24 Mar 2003 12:07:29 +0100 Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 1E51F5D0AB; Mon, 24 Mar 2003 20:07:21 +0900 (JST) Message-Id: <20030324.200720.26220860.ernst@sfc.wide.ad.jp> To: jmanner@cs.Helsinki.FI Cc: nemo@nal.motlabs.com, seamoby@ietf.org From: Thierry Ernst In-Reply-To: References: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [nemo] Re: The NEMO/Seamoby terminology Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 24 Mar 2003 20:07:20 +0900 (JST) Content-Transfer-Encoding: 7bit Hi Jukka, all, [NEMO folks involve in terminology, please review suggestions below] From: Jukka MJ Manner > you proposal sounds good. Some questions/comments, though: > - The "fixed node" term does not mention IPv4-based nodes? Right. We don't need such details, so, in the seamoby document, we can make it simpler, as the definition for mobile nodes. I don't know if the mention "continuous sessions" we have in draft-nemo is relevant or not in draft-seamoby. To what extent a node is fixed or mobile ? With respect to its address or only with respect to its point of attachment ? Should the definition also cover MANET nodes and thus be general enough ? Tentatively, I propose the following text for draft-seamoby. Text between brackets is optional and could be added/removed: o Fixed Node (FN) A node, either a host or a router, unable to change its point of attachment to the network and its IP address [without breaking open sessions] o Mobile Node (MN) An IP node, either a host or a router, capable of changing its point of attachment to the network, moving from one link to another link [while maintaining continuous sessions] o Mobile Router (MR) A router capable of changing its point of attachment to the network, moving from one link to another link. The MR is capable of forwarding packets between two or more interfaces, and possibly running a dynamic routing protocol modifying the state by which to do packet forwarding. A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). [Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface.] o Mobile Network An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet and thus its reachability in the topology. The mobile network is composed by one or more IP-subnets and is connected to the global Internet via one or more Mobile Routers (MR). The internal configuration of the mobile network is assumed to be relatively stable with respect to the MR. o Mobile Network Node (MNN) Any node (host or router) located within a mobile network, either permanently or temporarily. MNNs may either be mobile nodes (host or router) or fixed nodes. o Ingress interface The interface of a MR attached to a link inside the mobile network. o Egress interface The interface of a MR attached to the home link if the MR is at home, or attached to a foreign link if the MR is in a foreign network. It would be useful to indicate ingress and egress intefaces on the figure. > - The "network mobility" would fit into the section discussing personal > and host mobility, I guess. Yes. > - All interface and prefix terms would go into the Mobile Network section > of the Seamoby draft, right? They are mainly (only?) used there? I think "home subnet prefix" and "foreign subnet prefix" are general to mobility, not only to network mobility. Moreover, those terms appear in section 2 of draft-seamoby, thus they should be defined in section 2. Thierry > On Sat, 22 Mar 2003, Thierry Ernst wrote: > > Thus, for consistency and improvement, I think both drafts should be > > updated the following way: > > > > draft-seamoby-mmobility-terminology-02.txt > > - add "fixed node" as opposed to "mobile node" > > - update definition of mobile router (Seamoby def not the same as NEMO > > def) > > - add network mobility, as opposed to "host mobility" > > - add egress interface > > - add ingress interface > > - add home link prefix > > - add foreign link prefix > > > > draft-ernst-nemo-terminology-01.txt: > > - update defintion of mobile network with text in NEMO terminology's > > introducion > > - remove definition of AR > > - remove or extend definition of mobile network, MR, MNN > > - move words about "maintain sessions" from definition MN to > > definition of LFN, VMN, LMN > > - remove egress interface > > - remove ingress interface > > - remove home subnet prefix > > - remove foreign subnet prefix > > - intra-domain mobility > > - inter-domain mobility From nemo-admin@nal.motlabs.com Wed Mar 26 01:56:06 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20122 for ; Wed, 26 Mar 2003 01:56:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2Q6tVRC015884; Wed, 26 Mar 2003 07:55:33 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2Q6sRRC015874 for ; Wed, 26 Mar 2003 07:54:29 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.8/8.12.8) with ESMTP id h2Q6sOxr012068 for ; Wed, 26 Mar 2003 08:54:25 +0200 (EET) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id IAA26086 for ; Wed, 26 Mar 2003 08:54:22 +0200 (EET) Message-Id: <4.3.2.7.2.20030326083724.00bcc6f0@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: nemo@nal.motlabs.com From: Pekka =?iso-8859-1?Q?Pääkkönen?= Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2Q6sRRC015874 Subject: [nemo] new draft on MNP delegation for NEMO networks Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 08:54:20 +0200 Content-Transfer-Encoding: 8bit Hi all, http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt I have submitted a new draft on Mobile Network Prefix (MNP) delegation related to mobile networks. The draft proposes that MNP delegation should occur between a MR and its HA, and defines a MIPv6 extension for it. With this extension it is possible for the MR to dynamically delegate MNPs when at home or away from home. I hope that the draft causes discussion on MNP delegation related to NEMO networks. Pekka Pääkkönen From nemo-admin@nal.motlabs.com Wed Mar 26 11:51:10 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03647 for ; Wed, 26 Mar 2003 11:50:52 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QGhCRC018419; Wed, 26 Mar 2003 17:43:20 +0100 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QGdARC018393 for ; Wed, 26 Mar 2003 17:39:27 +0100 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2QGcgHR015272; Wed, 26 Mar 2003 17:38:42 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 26 Mar 2003 17:38:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF774@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Erik Nordmark'" Cc: "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 17:38:35 +0100 > > => What if the two MRs cooperate by forwarding traffic to > > the appropriate MR based on src address filtering? > > > > A MR can look at the src address of the packet and see > > whether it belongs to its Home prefix or another one. > > If it belongs to "another" prefix, it can forward the packet > > to the corresponding MR. > > What happens when one of the MRs, or the MR to HA tunnel, fails? > Since one of the claimed benefits (perhaps the main one?) > of multihoming is > redundancy this requires consideration. => Sure, but I was aiming at a smaller step, i.e. making this configuration work. My main concern was to accomodate the case where the two MRs belong to different HAs/ISPs/domains ...etc so that ingress filtering in the home network cannot be coordinated. In this case the benefit of multihoming is not redundancy, but potentially because the two MRs can provide different access characteristics (cellular, WLAN ...etc). They may also provide the same access but more than one happened to be available. I.e. load sharing on the MRs' egress interfaces. I think poviding redundancy in this case is fine could be a good "next step" IMHO. Hesham From nemo-admin@nal.motlabs.com Wed Mar 26 13:12:52 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05892 for ; Wed, 26 Mar 2003 13:12:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QI4XRC018756; Wed, 26 Mar 2003 19:04:44 +0100 Received: from multihop.net ([192.103.16.205]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QI3LRC018746 for ; Wed, 26 Mar 2003 19:03:31 +0100 Received: from [64.36.73.242] (homegw.kniveton.com [64.36.73.242]) by multihop.net (8.12.8/8.12.8) with ESMTP id h2QI2uNE002896 for ; Wed, 26 Mar 2003 10:02:57 -0800 (PST) (envelope-from tj@kniveton.com) User-Agent: Microsoft-Entourage/10.1.1.2418 From: "T.J. Kniveton" To: NeMo Discussion Subscribers Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [nemo] IETF56 Slides Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:02:54 -0800 Content-Transfer-Encoding: 7bit Hi, The presentation slides from IETF56 have been posted to the web page http://www.nal.motlabs.com/nemo/ietf56 TJ From nemo-admin@nal.motlabs.com Wed Mar 26 14:05:05 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07657 for ; Wed, 26 Mar 2003 14:04:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QIq9RC018927; Wed, 26 Mar 2003 19:52:09 +0100 Received: from seraph3.grc.nasa.gov (seraph3.grc.nasa.gov [128.156.10.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QIpYRC018918 for ; Wed, 26 Mar 2003 19:51:40 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 75B006BA1D for ; Wed, 26 Mar 2003 13:51:12 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2QIpB7h008834; Wed, 26 Mar 2003 13:51:11 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2QIovcB002175; Wed, 26 Mar 2003 13:50:57 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030326134159.0245d558@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Michael Thomas From: William D Ivancic Subject: Re: [nemo] moving forward (was: no home network ?) Cc: Sandy Murphy , vijayd@iprg.nokia.com, nemo@nal.motlabs.com In-Reply-To: <15995.12465.892361.774220@thomasm-u1.cisco.com> References: <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> <200303211409.h2LE9BX20128@phoenix.gw.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 13:50:56 -0500 At 07:33 AM 3/21/2003 -0800, Michael Thomas wrote: >Sandy Murphy writes: > > Is the nesting supposed to be static? Will there never be the case > > that a grandchild net might jump over to become a child in another > > nested net? If that can happen, who handles the revision of routing? > > Are you saying that the routing change has to go back to the HA? > >It certainly seems to me that it *could* be static >as each layer of nesting has no clue about the >other layer -- just like the LMN's don't have any >idea that they are behind a mobile router. Agreed. But nesting does not have to be static. A nemo should be able to attach wherever it has permission to. >As an aside, this is why I'm dubious about any >kind of artificial edict about the number of >layers... how could you even know if you're >violating it? [*] > > > Can there ever be the case that a child in one nested net could pass > > traffic directly to another child in the same nested net without > > going back through the base-wired-landline net? > >As it currently stands, no. This is, of course, >why route optimization would be nice if it could >be engineered... I think a picture from Sandy may clarify the question. However, as I interpret this question, both children are in the same nested network. Thus, they are on the same LAN. Therefore, there is no need to go home. If fact, there should be no need to go back home unless you are attached to a different mobile router. A mobile router with multiple LANs knows what LANs are attached to it. Any node attached to that mobile router, should be to talk to another node on that router - so long as it isn't attached to a nested mobile router. Will From nemo-admin@nal.motlabs.com Wed Mar 26 15:46:09 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13630 for ; Wed, 26 Mar 2003 15:45:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QKgSRC019349; Wed, 26 Mar 2003 21:42:29 +0100 Received: from seraph2.grc.nasa.gov (seraph2.grc.nasa.gov [128.156.10.11]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QKfaRC019339 for ; Wed, 26 Mar 2003 21:41:38 +0100 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by seraph2.grc.nasa.gov (Postfix) with ESMTP id 0A17D68958 for ; Wed, 26 Mar 2003 15:41:24 -0500 (EST) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.lerc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.3) with ESMTP id h2QKfK7h009756; Wed, 26 Mar 2003 15:41:20 -0500 (EST) Received: from GR7700006462.grc.nasa.gov (tb2-78.lerc.nasa.gov [139.88.2.78]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.8/8.12.8) with ESMTP id h2QKfDcB024241; Wed, 26 Mar 2003 15:41:13 -0500 (EST) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030326153725.023edd08@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: "Hesham Soliman (EAB)" From: William D Ivancic Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt Cc: "'Erik Nordmark'" , "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053807FEF774@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 15:41:12 -0500 At 05:38 PM 3/26/2003 +0100, Hesham Soliman (EAB) wrote: >My main concern was to accomodate the case where the two >MRs belong to different HAs/ISPs/domains ...etc so that >ingress filtering in the home network cannot be coordinated. >In this case the benefit of multihoming is not redundancy, >but potentially because the two MRs can provide different >access characteristics (cellular, WLAN ...etc). They may also >provide the same access but more than one happened to be available. >I.e. load sharing on the MRs' egress interfaces. .... > >Hesham Beware. For corporate networks, this appears to be a BIG BIG security issue. For instance, are you allowed to have you PC tied to the corporate network while utilized a phone modem to an outside ISP? I am not asking if you CAN do this. I am asking are you ALLOWED to do this. Will From nemo-admin@nal.motlabs.com Wed Mar 26 18:38:01 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22556 for ; Wed, 26 Mar 2003 18:37:44 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QNV0RC019988; Thu, 27 Mar 2003 00:31:11 +0100 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2QLaLRC019564 for ; Wed, 26 Mar 2003 22:36:31 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2QLZb9a007323; Wed, 26 Mar 2003 13:35:54 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA02011; Wed, 26 Mar 2003 21:35:30 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: pekka.paakkonen@vtt.fi, juhani.latvakoski@vtt.fi Cc: nemo@nal.motlabs.com, rdroms@cisco.com From: Ole Troan In-Reply-To: <200303261216.HAA22598@ietf.org> (Internet-Drafts@ietf.org's message of "Wed, 26 Mar 2003 07:16:47 -0500") Message-ID: <7t5k7elreu5.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <200303261216.HAA22598@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 21:35:30 +0000 Pekka, Juhani, what is the motivation for crafting your own MIPv6 specific PD mechanism versus using e.g DHCPv6 PD? why not just specify how DHCPv6 PD could be used in a nemo environment? cheers, Ole > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Mobile Network Prefix Delegation extension for Mobile > IPv6 > Author(s) : P. Paakkonen, J. Latvakoski > Filename : draft-paakkonen-nemo-prefix-delegation-00.txt > Pages : 0 > Date : 2003-3-25 > > This draft proposes a dynamic Mobile Network Prefix (MNP) delegation > extension for Mobile IPv6 protocol to enable MNP delegation for > mobile networks. A MNP is an IPv6 prefix used in a mobile network. > The extension supports dynamic delegation, return, refreshing and > updating operations related to MNP delegation operations between a > Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). > This extension is proposed, because there is a lack for a dynamic MNP > delegation protocol related to mobile networks, and currently MNPs have > to be assigned statically to enable mobile networking. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-paakkonen-nemo-prefix-delegation-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > 2. ( ) message/external-body ( ) message/external-body From nemo-admin@nal.motlabs.com Thu Mar 27 02:50:43 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19026 for ; Thu, 27 Mar 2003 02:50:35 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2R7nuRC022223; Thu, 27 Mar 2003 08:50:03 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2R7m8RC022213 for ; Thu, 27 Mar 2003 08:48:09 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.8/8.12.8) with ESMTP id h2R7lrxr003301; Thu, 27 Mar 2003 09:47:53 +0200 (EET) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id JAA24892; Thu, 27 Mar 2003 09:47:51 +0200 (EET) Message-Id: <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ole Troan From: Pekka =?iso-8859-1?Q?Pääkkönen?= Cc: nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: <7t5k7elreu5.fsf@mrwint.cisco.com> References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 09:47:48 +0200 Hello Ole, Using DHCPv6 prefix extensions might be one solution for MNP delegation. But it is not clear to me at all how DHCPv6 can be used in a NEMO environment. If a MR wants to execute MNP delegation operations with some entity in its home network, when MR is away from home, DHCP relay agents must be used in a foreign domain, because DHCPv6 uses link-local addressing, right? How are these relay agents configured to direct prefix delegation messages to the right entity (for example MR's HA) in MR's home network? If you have a view of how DHCPv6 prefix extensions can be used (maybe depicted with some message flows), please explain. If those MIPv6 extensions are used, then no relay agents would be needed in a foreign domain (at least for MNP delegation). Pekka At 21:35 26.3.2003 +0000, Ole Troan wrote: >Pekka, Juhani, > >what is the motivation for crafting your own MIPv6 specific PD >mechanism versus using e.g DHCPv6 PD? why not just specify how DHCPv6 >PD could be used in a nemo environment? > >cheers, >Ole > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Mobile Network Prefix Delegation extension for > Mobile > > IPv6 > > Author(s) : P. Paakkonen, J. Latvakoski > > Filename : draft-paakkonen-nemo-prefix-delegation-00.txt > > Pages : 0 > > Date : 2003-3-25 > > > > This draft proposes a dynamic Mobile Network Prefix (MNP) delegation > > extension for Mobile IPv6 protocol to enable MNP delegation for > > mobile networks. A MNP is an IPv6 prefix used in a mobile network. > > The extension supports dynamic delegation, return, refreshing and > > updating operations related to MNP delegation operations between a > > Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). > > This extension is proposed, because there is a lack for a dynamic MNP > > delegation protocol related to mobile networks, and currently MNPs have > > to be assigned statically to enable mobile networking. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-paakkonen-nemo-prefix-delegation-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > 2. ( ) message/external-body ( ) message/external-body From nemo-admin@nal.motlabs.com Thu Mar 27 04:26:39 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20910 for ; Thu, 27 Mar 2003 04:26:27 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2R9Q8RC023041; Thu, 27 Mar 2003 10:26:08 +0100 Received: from smtp-2.hut.fi (root@smtp-2.hut.fi [130.233.228.92]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2R9PIRC023033 for ; Thu, 27 Mar 2003 10:25:21 +0100 Received: from tml.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132]) by smtp-2.hut.fi (8.12.8/8.12.6) with ESMTP id h2R9P8Is010057; Thu, 27 Mar 2003 11:25:08 +0200 Message-ID: <3E82C518.8000700@tml.hut.fi> From: Henrik Petander User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= CC: Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> In-Reply-To: <200303261216.HAA22598@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (smtp-2.hut.fi) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 11:32:08 +0200 Content-Transfer-Encoding: 8bit Hi Pekka, Have you read the approach of the mipv6 spec on using dhcpv6 between MN and HA? Dhcpv6 could be run between the HA and MN over the tunnel "link". HA and MN would use the logical tunnel interfaces' link local addresses. The same approach could be used also for NEMO, if MR runs also mobile ipv6. (To make this transparent to the dhcpv6 daemon, the tunnel needs to be visible as an interface in HA and MN.) Regards, Henrik Petander Pekka =?iso-8859-1?Q?Pääkkönen?= wrote: > Hello Ole, > > Using DHCPv6 prefix extensions might be one solution for MNP delegation. > But it is not clear to me at all how DHCPv6 can be used in a NEMO > environment. > If a MR wants to execute MNP delegation operations with some entity in > its home > network, when MR is away from home, DHCP relay agents must be used in a > foreign domain, because DHCPv6 uses link-local addressing, right? How > are these > relay agents configured to direct prefix delegation messages to the > right entity (for example MR's > HA) in MR's home network? If you have a view of how DHCPv6 prefix > extensions can be > used (maybe depicted with some message flows), please explain. > > If those MIPv6 extensions are used, then no relay agents would be needed > in a foreign domain > (at least for MNP delegation). > > > Pekka > > > At 21:35 26.3.2003 +0000, Ole Troan wrote: > > > Pekka, Juhani, > > > > what is the motivation for crafting your own MIPv6 specific PD > > mechanism versus using e.g DHCPv6 PD? why not just specify how DHCPv6 > > PD could be used in a nemo environment? > > > > cheers, > > Ole > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > > > > Title : Mobile Network Prefix Delegation extension > > for Mobile > > > IPv6 > > > Author(s) : P. Paakkonen, J. Latvakoski > > > Filename : draft-paakkonen-nemo-prefix-delegation-00.txt > > > Pages : 0 > > > Date : 2003-3-25 > > > > > > This draft proposes a dynamic Mobile Network Prefix (MNP) delegation > > > extension for Mobile IPv6 protocol to enable MNP delegation for > > > mobile networks. A MNP is an IPv6 prefix used in a mobile network. > > > The extension supports dynamic delegation, return, refreshing and > > > updating operations related to MNP delegation operations between a > > > Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). > > > This extension is proposed, because there is a lack for a dynamic MNP > > > delegation protocol related to mobile networks, and currently MNPs > have > > > to be assigned statically to enable mobile networking. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt > > > > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-paakkonen-nemo-prefix-delegation-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > /internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail > > readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > 2. ( ) message/external-body ( ) message/external-body > > From nemo-admin@nal.motlabs.com Thu Mar 27 05:30:55 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22081 for ; Thu, 27 Mar 2003 05:30:47 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RATBRC023305; Thu, 27 Mar 2003 11:29:15 +0100 Received: from melanieb.vtt.fi (melanieb.vtt.fi [130.188.1.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RASmRC023297 for ; Thu, 27 Mar 2003 11:28:54 +0100 Received: from elemail.ele.vtt.fi (localhost [127.0.0.1]) by melanieb.vtt.fi (8.12.8/8.12.8) with ESMTP id h2RASgxr015942; Thu, 27 Mar 2003 12:28:42 +0200 (EET) Received: from ele4114.vtt.fi (ele4114.ele.vtt.fi [130.188.94.114]) by elemail.ele.vtt.fi (8.9.1a/8.9.1) with ESMTP id MAA04979; Thu, 27 Mar 2003 12:28:40 +0200 (EET) Message-Id: <4.3.2.7.2.20030327115611.00bd4100@elemail.ele.vtt.fi> X-Sender: eleppa@elemail.ele.vtt.fi X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Henrik Petander From: Pekka =?iso-8859-1?Q?Pääkkönen?= Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt Cc: Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: <3E82C518.8000700@tml.hut.fi> References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2RASmRC023297 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:28:37 +0200 Content-Transfer-Encoding: 8bit Hi Henrik, If you refer to the section 10.4.4 of the MIPv6 spec, no, this is new to me. So with this approach DHCPv6 relay functionality of a foreign network would not be needed, when delegating MNPs from the home network? The MR would tunnel its link-local DHCPv6 messages to its HA and DHCPv6 server (HA) would tunnel link-local messages to the MR . There is still one problem on my mind. In section 10.4.2 of MIPv6 spec it is defined that "However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. ". But DHCPv6 with tunneling would require to tunnel DHCPv6 messages to the link-local address of the MR. Does the definition in the spec mean that packets addressed to the link-local address of the MR coming from a node other than the HA MUST not be tunneled to the MR, and those coming from the HA MAY be tunneled to the MR? This would require filtering of the IP traffic at the HA based on the source link-local address of the packet? Pekka At 11:32 27.3.2003 +0200, Henrik Petander wrote: >Hi Pekka, > > >Have you read the approach of the mipv6 spec on using dhcpv6 between MN >and HA? > >Dhcpv6 could be run between the HA and MN over the tunnel "link". HA and >MN would use the logical tunnel interfaces' link local addresses. The same >approach could be used also for NEMO, if MR runs also mobile ipv6. (To >make this transparent to the dhcpv6 daemon, the tunnel needs to be visible >as an interface in HA and MN.) > >Regards, > >Henrik Petander > >Pekka =?iso-8859-1?Q?Pääkkönen?= wrote: > >>Hello Ole, >> >>Using DHCPv6 prefix extensions might be one solution for MNP delegation. >>But it is not clear to me at all how DHCPv6 can be used in a NEMO >>environment. >>If a MR wants to execute MNP delegation operations with some entity in >>its home >>network, when MR is away from home, DHCP relay agents must be used in a >>foreign domain, because DHCPv6 uses link-local addressing, right? How >>are these >>relay agents configured to direct prefix delegation messages to the >>right entity (for example MR's >>HA) in MR's home network? If you have a view of how DHCPv6 prefix >>extensions can be >>used (maybe depicted with some message flows), please explain. >> >>If those MIPv6 extensions are used, then no relay agents would be needed >>in a foreign domain >>(at least for MNP delegation). > > > >> >> >>Pekka >> >> >>At 21:35 26.3.2003 +0000, Ole Troan wrote: >> >> > Pekka, Juhani, >> > >> > what is the motivation for crafting your own MIPv6 specific PD >> > mechanism versus using e.g DHCPv6 PD? why not just specify how DHCPv6 >> > PD could be used in a nemo environment? >> > >> > cheers, >> > Ole >> > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > > >> > > >> > > Title : Mobile Network Prefix Delegation extension >> > for Mobile >> > > IPv6 >> > > Author(s) : P. Paakkonen, J. Latvakoski >> > > Filename : draft-paakkonen-nemo-prefix-delegation-00.txt >> > > Pages : 0 >> > > Date : 2003-3-25 >> > > >> > > This draft proposes a dynamic Mobile Network Prefix (MNP) delegation >> > > extension for Mobile IPv6 protocol to enable MNP delegation for >> > > mobile networks. A MNP is an IPv6 prefix used in a mobile network. >> > > The extension supports dynamic delegation, return, refreshing and >> > > updating operations related to MNP delegation operations between a >> > > Mobile Router (MR) of a mobile network and the MR's Home Agent (HA). >> > > This extension is proposed, because there is a lack for a dynamic MNP >> > > delegation protocol related to mobile networks, and currently MNPs have >> > > to be assigned statically to enable mobile networking. >> > > >> > > A URL for this Internet-Draft is: >> > > >> > >> http://www.ietf.org/internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt >> >> > >> > > >> > > To remove yourself from the IETF Announcement list, send a message to >> > > ietf-announce-request with the word unsubscribe in the body of the >> > message. >> > > >> > > Internet-Drafts are also available by anonymous FTP. Login with the >> > username >> > > "anonymous" and a password of your e-mail address. After logging in, >> > > type "cd internet-drafts" and then >> > > "get draft-paakkonen-nemo-prefix-delegation-00.txt". >> > > >> > > A list of Internet-Drafts directories can be found in >> > > http://www.ietf.org/shadow.html >> > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > > >> > > >> > > Internet-Drafts can also be obtained by e-mail. >> > > >> > > Send a message to: >> > > mailserv@ietf.org. >> > > In the body type: >> > > "FILE >> > /internet-drafts/draft-paakkonen-nemo-prefix-delegation-00.txt". >> > > >> > > NOTE: The mail server at ietf.org can return the document in >> > > MIME-encoded form by using the "mpack" utility. To use this >> > > feature, insert the command "ENCODING mime" before the "FILE" >> > > command. To decode the response(s), you will need "munpack" or >> > > a MIME-compliant mail reader. Different MIME-compliant mail >> > readers >> > > exhibit different behavior, especially when dealing with >> > > "multipart" MIME messages (i.e. documents which have been split >> > > up into multiple messages), so check your local documentation on >> > > how to manipulate these messages. >> > > >> > > >> > > Below is the data which will enable a MIME compliant mail reader >> > > implementation to automatically retrieve the ASCII version of the >> > > Internet-Draft. >> > > 2. ( ) message/external-body ( ) message/external-body >> > From nemo-admin@nal.motlabs.com Thu Mar 27 05:46:59 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22575 for ; Thu, 27 Mar 2003 05:46:51 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RAl8RC023380; Thu, 27 Mar 2003 11:47:08 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RAknRC023372 for ; Thu, 27 Mar 2003 11:46:51 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2RAkegu021565; Thu, 27 Mar 2003 03:46:42 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA22362; Thu, 27 Mar 2003 03:44:17 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h2RAhP107100; Thu, 27 Mar 2003 04:43:25 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9B6742EC86; Thu, 27 Mar 2003 11:43:21 +0100 (CET) Message-ID: <3E82D5C9.1020202@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ole Troan Cc: , , , Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <200303261216.HAA22598@ietf.org> <7t5k7elreu5.fsf@mrwint.cisco.com> In-Reply-To: <7t5k7elreu5.fsf@mrwint.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 11:43:21 +0100 Content-Transfer-Encoding: 7bit Ole Troan wrote: > Pekka, Juhani, > > what is the motivation for crafting your own MIPv6 specific PD > mechanism versus using e.g DHCPv6 PD? why not just specify how > DHCPv6 PD could be used in a nemo environment? Hi Ole, I'm inclined to believe we should look into using PD of DHCPv6 that way. From the PD DHCPv6 draft: "For example, the requesting router might assign a subnet from a delegated prefix to one of its interfaces, and begin sending router advertisements for the prefix on that link." Is it possible for an MR (that got a prefix delegated from its HA) to start acting as a DHCPv6 server itself for the LFN's in the mobile network? Alex From nemo-admin@nal.motlabs.com Thu Mar 27 06:08:49 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23169 for ; Thu, 27 Mar 2003 06:08:48 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RBA8RC023511; Thu, 27 Mar 2003 12:10:08 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RB9FRC023497 for ; Thu, 27 Mar 2003 12:09:16 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2RB97NG024431; Thu, 27 Mar 2003 04:09:08 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id EAA11832; Thu, 27 Mar 2003 04:09:01 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h2RB97T04080; Thu, 27 Mar 2003 05:09:07 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C4F362EC8B; Thu, 27 Mar 2003 12:09:05 +0100 (CET) Message-ID: <3E82DBD1.4020909@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?=, Ole Troan, , Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> <3E82C518.8000700@tml.hut.fi> In-Reply-To: <3E82C518.8000700@tml.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:09:05 +0100 Content-Transfer-Encoding: 7bit Hi Henrik, Henrik Petander wrote: > Dhcpv6 could be run between the HA and MN over the tunnel "link". > HA and MN would use the logical tunnel interfaces' link local > addresses. The same approach could be used also for NEMO, if MR > runs also mobile ipv6. (To make this transparent to the dhcpv6 > daemon, the tunnel needs to be visible as an interface in HA and > MN.) I agree that MR and the Mobile Node as defined by Mobile IPv6 should use the same mechanism for DHCPv6. I would add that, if MN uses DHCPv6 towards its HA, it would do so both when it is away from home, and when it is at home, right? In that case, > (To make this transparent to the dhcpv6 daemon, the tunnel needs to > be visible as an interface in HA and MN.) I wonder if this is still transparent to the dhcpv6 cliend daemon running on the MR (or MN). I mean, when MN is away from home, it runs dhcpv6 client daemon over the link designated by the tunnel interface. However, when the MN is at home, it will supposedly run the dhcpv6 client daemon directly over a true interface link (say eth0). So, my question was if the transparency aspect you mention above can be kept when MN is at home? Can I do that? Alex From nemo-admin@nal.motlabs.com Thu Mar 27 06:10:21 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23206 for ; Thu, 27 Mar 2003 06:10:20 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RBCIRC023528; Thu, 27 Mar 2003 12:12:18 +0100 Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RB0VRC023449 for ; Thu, 27 Mar 2003 12:00:32 +0100 Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2RAxbeM003752; Thu, 27 Mar 2003 03:59:37 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA16861; Thu, 27 Mar 2003 04:00:24 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h2RB0JT31267; Thu, 27 Mar 2003 05:00:20 -0600 Received: from crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 379DE2EC86; Thu, 27 Mar 2003 12:00:18 +0100 (CET) Message-ID: <3E82D9C1.9030903@crm.mot.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= Cc: Ole Troan, , Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> In-Reply-To: <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 12:00:17 +0100 Content-Transfer-Encoding: 8bit Pekka =?iso-8859-1?Q?Pääkkönen?= wrote: > Hello Ole, > > Using DHCPv6 prefix extensions might be one solution for MNP > delegation. But it is not clear to me at all how DHCPv6 can be used > in a NEMO environment. If a MR wants to execute MNP delegation > operations with some entity in its home network, when MR is away > from home, DHCP relay agents must be used in a foreign domain, > because DHCPv6 uses link-local addressing, right? Indeed MR must use link-local addressing, and this should be tunnelled back to HA, not necessarily use relay agents in the foreign domain. > If those MIPv6 extensions are used, then no relay agents would be > needed in a foreign domain (at least for MNP delegation). I would suppose that this is an issue of the link-local addressing of MR in general. The use of DHCPv6 is but one "link-local addressing" issue for MR. The other link-local addressing issues for MR come from the use of routing protocols between MR and HA; another link-local address issue is also the HA sending RA's to MR (or MH for that matter); yet another is from multicast MLD between MR and HA, that also uses link-local addressing. The link-local addressing issue comes mainly from the fact that Mobile IPv6 bans the use of a Home Address as a link-local address. A Home Address can be either global or site-local (until recently). Today it could only be global, but not link-local. It would be nice to have a homogeneous type of solution for all these link-local addressing issues; and that would be to allow Home Addresses as link-local addresses by the base Mobile IPv6 spec. Otherwise, the other solutions that will eventually be developped is: -new Mobile IPv6 messages and message types for PD. -new Mobile IPv6 routing protocol messages. -new Mobile IPv6 MLD messages. -new RA and RS messages (as already done in fact by Mobile Prefix Sol/Adv). -basically all that is link-local messaging will have new Mobile IPv6 messages. What do you think? Alex From nemo-admin@nal.motlabs.com Thu Mar 27 07:35:22 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25032 for ; Thu, 27 Mar 2003 07:35:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RCb9RC023808; Thu, 27 Mar 2003 13:37:09 +0100 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RCaCRC023800 for ; Thu, 27 Mar 2003 13:36:12 +0100 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h2RCa1bh000674; Thu, 27 Mar 2003 13:36:01 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 27 Mar 2003 13:35:59 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053807FEF781@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'William D Ivancic'" Cc: "'Erik Nordmark'" , "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 13:35:58 +0100 > >My main concern was to accomodate the case where the two > >MRs belong to different HAs/ISPs/domains ...etc so that > >ingress filtering in the home network cannot be coordinated. > >In this case the benefit of multihoming is not redundancy, > >but potentially because the two MRs can provide different > >access characteristics (cellular, WLAN ...etc). They may also > >provide the same access but more than one happened to be available. > >I.e. load sharing on the MRs' egress interfaces. .... > > > >Hesham > > > Beware. For corporate networks, this appears to be a BIG > BIG security issue. > > For instance, are you allowed to have you PC tied to the > corporate network > while utilized a phone modem to an outside ISP? I am not > asking if you CAN > do this. I am asking are you ALLOWED to do this. => Of course I'm not allowed to do it, but it's not a protocol issue, it's company policy. I.e. there is no protocol that stops me from doing this, which is what we're discussing here. Hesham From nemo-admin@nal.motlabs.com Thu Mar 27 13:30:05 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11275 for ; Thu, 27 Mar 2003 13:30:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RIVDRC025341; Thu, 27 Mar 2003 19:31:13 +0100 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2RILkRC025234; Thu, 27 Mar 2003 19:21:47 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2RILaHp005263; Thu, 27 Mar 2003 10:21:37 -0800 (PST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA04798; Thu, 27 Mar 2003 18:21:35 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Alexandru Petrescu Cc: , , , Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt From: Ole Troan In-Reply-To: <3E82D5C9.1020202@nal.motlabs.com> (Alexandru Petrescu's message of "Thu, 27 Mar 2003 11:43:21 +0100") Message-ID: <7t58yv0zn4g.fsf@mrwint.cisco.com> User-Agent: Gnus/5.090011 (Oort Gnus v0.11) Emacs/21.2.95 (sparc-sun-solaris2.8) References: <200303261216.HAA22598@ietf.org> <7t5k7elreu5.fsf@mrwint.cisco.com> <3E82D5C9.1020202@nal.motlabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Thu, 27 Mar 2003 18:21:35 +0000 Alex, >> what is the motivation for crafting your own MIPv6 specific PD >> mechanism versus using e.g DHCPv6 PD? why not just specify how >> DHCPv6 PD could be used in a nemo environment? > > Hi Ole, I'm inclined to believe we should look into using PD of DHCPv6 > that way. > > From the PD DHCPv6 draft: > > "For example, the requesting router might assign a subnet > from a delegated prefix to one of its interfaces, and begin > sending router advertisements for the prefix on that link." > > Is it possible for an MR (that got a prefix delegated from its HA) to > start acting as a DHCPv6 server itself for the LFN's in the mobile > network? sure. most typically by 'proxying' the stateless DHCP options across, but you could very well do DHCP address assignment downstream also, where the address pool is acquired via DHCP PD upstream. cheers, Ole From nemo-admin@nal.motlabs.com Thu Mar 27 21:32:55 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01779 for ; Thu, 27 Mar 2003 21:32:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2S2XORC027128; Fri, 28 Mar 2003 03:33:25 +0100 Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2S2WDRC027120 for ; Fri, 28 Mar 2003 03:32:14 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2S2WBB6004589; Thu, 27 Mar 2003 19:32:12 -0700 (MST) Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA04462; Thu, 27 Mar 2003 19:31:51 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.115]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h2S2Vql25182; Thu, 27 Mar 2003 20:31:53 -0600 Message-ID: <3E83C220.4060101@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst CC: , , References: <20030322.020459.68535176.ernst@sfc.wide.ad.jp> <20030324.200720.26220860.ernst@sfc.wide.ad.jp> In-Reply-To: <20030324.200720.26220860.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [nemo] Re: MN defined twice and lack of MH (was: The NEMO/Seamoby terminology) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 04:31:44 +0100 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > [NEMO folks involve in terminology, please review suggestions > below] Sorry for following up late on this, and posting on both lists is not good from my part, sorry. > o Mobile Node (MN) An IP node, either a host or a router, capable > of changing its point of attachment to the network, moving from one > link to another link [while maintaining continuous sessions] Mobile IPv6 draft 21 has this: "mobile node A node that can change its point of attachment from one link to another, while still being reachable via its home address." Which is basically the same thing said twice? What would be helpful for me, at this moment, is a help to be able to talk about MR contrasted to a MN that is not a router. Normally, MN can be either a mobile host, or a mobile router, because node is an entity that runs IP, and a host is a node that is not a router. So, I would like to be able to say "contrary to a MN implementation, an MR implementation will send RAs on the home link (if at home)". And I can not say that, because a MN can be a MR as well as a mobile host. A better formulation would be: "contrary to a MH implementation, an MR implementation will send RAs on the home link (if at home)". So I was trying to talk about MH to stand for mobile host only; (this might conflict with Mobility Header abbreviating MH too). Alex -- Message Classification: GBU From nemo-admin@nal.motlabs.com Fri Mar 28 04:26:51 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22072 for ; Fri, 28 Mar 2003 04:26:49 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2S9SFRC029198; Fri, 28 Mar 2003 10:28:16 +0100 Received: from smtp-4.hut.fi (root@smtp-4.hut.fi [130.233.228.94]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2S9RVRC029190 for ; Fri, 28 Mar 2003 10:27:32 +0100 Received: from tml.hut.fi (tcs-pc-5.tcs.hut.fi [130.233.215.132]) by smtp-4.hut.fi (8.12.8/8.12.6) with ESMTP id h2S9RJ1N010406; Fri, 28 Mar 2003 11:27:20 +0200 Message-ID: <3E84171E.2090601@tml.hut.fi> From: Henrik Petander User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu CC: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> <3E82D9C1.9030903@crm.mot.com> In-Reply-To: <200303261216.HAA22598@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.2(snapshot 20021217) (smtp-4.hut.fi) Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 11:34:22 +0200 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > I would suppose that this is an issue of the link-local addressing of > MR in general. The use of DHCPv6 is but one "link-local addressing" > issue for MR. The other link-local addressing issues for MR come from > the use of routing protocols between MR and HA; another link-local > address issue is also the HA sending RA's to MR (or MH for that > matter); yet another is from multicast MLD between MR and HA, that > also uses link-local addressing. The issue is not only with addressing, but also with the hop limit of 255. > > It would be nice to have a homogeneous type of solution for all these > link-local addressing issues; and that would be to allow Home > Addresses as link-local addresses by the base Mobile IPv6 spec. > > Otherwise, the other solutions that will eventually be developped is: > -new Mobile IPv6 messages and message types for PD. > -new Mobile IPv6 routing protocol messages. > -new Mobile IPv6 MLD messages. > -new RA and RS messages (as already done in fact by Mobile Prefix > Sol/Adv). > -basically all that is link-local messaging will have new Mobile IPv6 > messages. > > What do you think? IMHO it would be better to use link local addressing on the tunnel link to allow running of existing link local protocols between HA and MR than to reinvent non-mobile protocols as mipv6 / nemo extensions. Movement between home and foreign links makes the first option more complex, though, but it is still only an implementation issue. Henrik From nemo-admin@nal.motlabs.com Fri Mar 28 05:53:00 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23577 for ; Fri, 28 Mar 2003 05:52:54 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SArARC029748; Fri, 28 Mar 2003 11:53:10 +0100 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SAqVRC029738 for ; Fri, 28 Mar 2003 11:52:33 +0100 Received: from bebop.France.Sun.COM ([129.157.174.15]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12718; Fri, 28 Mar 2003 03:52:23 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2SAqIK00231; Fri, 28 Mar 2003 11:52:19 +0100 (MET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt To: "Hesham Soliman (EAB)" Cc: "'Erik Nordmark'" , "'Takeshi TANAKA'" , "'marcelo bagnulo'" , "'IETF NEMO'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053807FEF774@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 10:10:52 +0100 (CET) > => Sure, but I was aiming at a smaller step, i.e. making this > configuration work. > My main concern was to accomodate the case where the two > MRs belong to different HAs/ISPs/domains ...etc so that > ingress filtering in the home network cannot be coordinated. > In this case the benefit of multihoming is not redundancy, > but potentially because the two MRs can provide different > access characteristics (cellular, WLAN ...etc). They may also > provide the same access but more than one happened to be available. > I.e. load sharing on the MRs' egress interfaces. OK. In that case you end up with the "uncoordinated site multihoming" problem. Solutions have been proposed in that context (in the ipv6mh discussions and perhaps in multi6 as well). It wouldn't hurt to have some Nemo document covering multihoming to state the issue/problem, but I'm assuming that solutions (that are not Nemo specific) will be developped elsewhere so no need to touch on solutions in a Nemo document I think. Erik From nemo-admin@nal.motlabs.com Fri Mar 28 12:26:05 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08956 for ; Fri, 28 Mar 2003 12:26:04 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SHRARC000467; Fri, 28 Mar 2003 18:27:10 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SHPvRC000443 for ; Fri, 28 Mar 2003 18:25:58 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2SHNjLH024429; Fri, 28 Mar 2003 18:23:52 +0100 (MET) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Mar 2003 18:25:36 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Mar 2003 17:25:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Thread-Index: AcL1GPWf5I+TQMhKRDenAsPnOmedNQAM+ecg From: "Pascal Thubert (pthubert)" To: "Erik Nordmark" , "Hesham Soliman (EAB)" Cc: "Takeshi TANAKA" , "marcelo bagnulo" , "IETF NEMO" X-OriginalArrivalTime: 28 Mar 2003 17:25:36.0414 (UTC) FILETIME=[0B82D3E0:01C2F54F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2SHPvRC000443 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 17:25:35 -0000 Content-Transfer-Encoding: 8bit I wonder if there's not also a security issue there, if we start doing dynamic advertisements from the MR to the HA. Scenario is this: 2 uncoordinated MRs provide their services on the same Mobile Network MR1 -> prefix 1 MR2 -> prefix 2 prefix 1 and prefix 2 are now both present and advertised in RAs on the Mobile Network. If MR1 does not support stateless autoconf on the ingress interface to that Mobile Network, then we have the ingress filtering problem that Erik mentioned. Now if MR1 supports stateless autoconf on that interface: MR1 will allocate an address out of P2 AND install a connected route to P2 via the ingress interface. Note that this route does not come from a routing protocol with a trusted party. Only L2 access control may actually hint about the veracity of the claim by MR2 of the ownership of prefix 2. If MR1 redistributes its connected routes over the routing protocol with the HA, and if in turn the HA redistributes that, now we end up with a situation where HA1 advertises P2. Now what if MR2 is a rogue advertising prefixes that it does not actually own... Pascal > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] > Sent: vendredi 28 mars 2003 10:11 > To: Hesham Soliman (EAB) > Cc: 'Erik Nordmark'; 'Takeshi TANAKA'; 'marcelo bagnulo'; 'IETF NEMO' > Subject: RE: [nemo] about draft-ietf-nemo-requirements-00.txt > > > > => Sure, but I was aiming at a smaller step, i.e. making this > > configuration work. > > My main concern was to accomodate the case where the two > > MRs belong to different HAs/ISPs/domains ...etc so that > > ingress filtering in the home network cannot be coordinated. > > In this case the benefit of multihoming is not redundancy, > > but potentially because the two MRs can provide different > > access characteristics (cellular, WLAN ...etc). They may also > > provide the same access but more than one happened to be available. > > I.e. load sharing on the MRs' egress interfaces. > > OK. In that case you end up with the "uncoordinated site > multihoming" problem. Solutions have been proposed in that > context (in the ipv6mh discussions and perhaps in multi6 as > well). It wouldn't hurt to have some Nemo document covering > multihoming to state the issue/problem, but I'm assuming that > solutions (that are not Nemo specific) will be developped > elsewhere so no need to touch on solutions in a Nemo document I think. > > Erik > > From nemo-admin@nal.motlabs.com Fri Mar 28 13:45:42 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11653 for ; Fri, 28 Mar 2003 13:45:41 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SIj8RC001474; Fri, 28 Mar 2003 19:45:08 +0100 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SIilRC001460 for ; Fri, 28 Mar 2003 19:44:48 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2SIh1Ps009464; Fri, 28 Mar 2003 11:43:08 -0700 (MST) Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id LAA11093; Fri, 28 Mar 2003 11:42:45 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h2SIgt817478; Fri, 28 Mar 2003 12:42:55 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A02942EC86; Fri, 28 Mar 2003 19:42:52 +0100 (CET) Message-ID: <3E8497AC.3060500@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Erik Nordmark , "Hesham Soliman (EAB)" , Takeshi TANAKA , marcelo bagnulo , IETF NEMO Subject: Re: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 19:42:52 +0100 Content-Transfer-Encoding: 7bit Hi Pascal, I'm trying to understand your scenario and risks. Are you basically saying that when a mobile network is multi-homed, and the MRs and HA run dynamic routing protocol, then it is possible for one MR to fool the other MR into believing a fake route? More comments inside: Pascal Thubert (pthubert) wrote: > I wonder if there's not also a security issue there, if we start > doing dynamic advertisements from the MR to the HA. > > Scenario is this: > > 2 uncoordinated MRs provide their services on the same Mobile > Network A topology like this:? --------- / | ----------/ | ------- | | | -| HA/BR |---| Internet | | ------- | | | ----------\ | \ | \ | | | | | ----- ----- | AR1 | | AR2 | ----- ----- | | | | ----- ----- | MR1 | | MR2 | ----- ----- | | ------------ | ----- | LFN | ----- > > MR1 -> prefix 1 MR2 -> prefix 2 > > prefix 1 and prefix 2 are now both present and advertised in RAs on > the Mobile Network. Ok, and both prefixes come from the home domain, right?, not from the visited domain. > Now if MR1 supports stateless autoconf on that interface: > > MR1 will allocate an address out of P2 AND install a connected > route to P2 via the ingress interface. I don't understand this, why would MR1 configure itself ("allocate?") an address out of P2? P2 is advertised on the RAs sent by the ingress interface by MR2, not by MR1 right? Also, why would MR1 install a connected route to P2 via its ingress interface? > If MR1 redistributes its connected routes over the routing protocol > with the HA, and if in turn the HA redistributes that, now we end > up with a situation where HA1 advertises P2. Do you mean "a situation where MR2 advertises P2"? If you mean so, then even if MR1 claims to HA that is being capable to route to p1 (as a directly connected interface), and that HA runs dynamic routing protocol both with MR1 and MR2, you might fear of ending up with three routers (HA, MR1 and MR2) that exchange routing information. So I assume they do it right, that's the job of routing protocols. On another hand, if you assume that among these three routers, one is rogue and pretends a prefix that it does not actually own, and injects a route there where it shouldn't, then this can be probably reduced from a model with three routers MR1, MR2 and HA1 to a model with two routers MR and HA. In that case, yes, please clarify? Alex From nemo-admin@nal.motlabs.com Fri Mar 28 14:25:31 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13326 for ; Fri, 28 Mar 2003 14:25:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SJR5RC002269; Fri, 28 Mar 2003 20:27:05 +0100 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SJQeRC002249; Fri, 28 Mar 2003 20:26:41 +0100 Received: from xbe-ams-313.cisco.com (xbe-ams-313.cisco.com [144.254.228.203]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2SJPhib000637; Fri, 28 Mar 2003 14:26:20 -0500 (EST) Received: from xbe-lon-313.cisco.com ([64.103.99.73]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Mar 2003 20:26:15 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Mar 2003 19:26:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Thread-Index: AcL1WfXXApsRgh4mQcyrisqDaM9EngAA4UbQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: "Erik Nordmark" , "Hesham Soliman (EAB)" , "Takeshi TANAKA" , "marcelo bagnulo" , "IETF NEMO" X-OriginalArrivalTime: 28 Mar 2003 19:26:15.0182 (UTC) FILETIME=[E6272AE0:01C2F55F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2SJQeRC002249 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 19:26:14 -0000 Content-Transfer-Encoding: 8bit > Are you basically saying that when a mobile network is > multi-homed, and the MRs and HA run dynamic routing protocol, > then it is possible for one MR to fool the other MR into > believing a fake route? > Yes, sort of. The RA is actually a form of connected toute advertisement, if you'll accept it. > > A topology like this:? > > --------- > / | > ----------/ | > ------- | | | > -| HA/BR |---| Internet | | > ------- | | | > ----------\ | > \ | > \ | > | | > | | > ----- ----- > | AR1 | | AR2 | > ----- ----- > | | > > > | | > ----- ----- > | MR1 | | MR2 | > ----- ----- > | | > ------------ > | > ----- > | LFN | > ----- > > > > MR1 -> prefix 1 MR2 -> prefix 2 Right, I should have drawn that picture. Thanks for doing it. Note that MR2 is a rogue, does not even need a real home agent. > Ok, and both prefixes come from the home domain, right?, not > from the visited domain. > Prefix 1 is from MR1's admin domain. Prefix 2 is from MR2's admin domain, but if MR2 is an attacker, prefix 2 is anything it wants to intercept. > > Now if MR1 supports stateless autoconf on that interface: > > > > MR1 will allocate an address out of P2 AND install a connected > > route to P2 via the ingress interface. > > I don't understand this, why would MR1 configure itself > ("allocate?") an address out of P2? P2 is advertised on the > RAs sent by the ingress interface by MR2, not by MR1 right? > MR1 gets RAs from MR2 like anyone else. If it is configured to autoconf addresses, it will. Try it! > Also, why would MR1 install a connected route to P2 via its > ingress interface? Because it has an address on that prefix on that interface. So the prefix is expected to be there. This is true for both static addresses and autoconf'ed addresses. > > > If MR1 redistributes its connected routes over the routing > protocol > > with the HA, and if in turn the HA redistributes that, now > we end up > > with a situation where HA1 advertises P2. > > Do you mean "a situation where MR2 advertises P2"? If you > mean so, then even if MR1 claims to HA that is being capable > to route to p1 (as a directly connected interface), and that > HA runs dynamic routing protocol both with MR1 and MR2, you > might fear of ending up with three routers (HA, MR1 and MR2) > that exchange routing information. So I assume they do it > right, that's the job of routing protocols. > > On another hand, if you assume that among these three > routers, one is rogue and pretends a prefix that it does not > actually own, and injects a route there where it shouldn't, > then this can be probably reduced from a model with three > routers MR1, MR2 and HA1 to a model with two routers MR and HA. > > In that case, yes, please clarify? > You missed the point. I meant what I wrote. If MR1 did learn P2 from a trusted routing protocol relationship with MR2, that would not be a problem, but a standard case. Here MR1 learns the prefix from ND that is not secure in nature. If there is a MRHA routing protocol and if MR advertises the info about P2 to HA1, HA1 will trust this. And install a route to P2. And advertise that to its autonomous system, etc... So anyone around HA1 is fooled into sending all traffic for P2 to MR2 via MR1. This is not actually specific to mobility, same as the initial discussion. I do not know if SeND looks into securing the prefix part of RAs. The trust problem we have in PSBU is exactely the same for RA prefixes, if you look at it. Pascal From nemo-admin@nal.motlabs.com Fri Mar 28 14:32:27 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13665 for ; Fri, 28 Mar 2003 14:32:26 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SJY5RC002465; Fri, 28 Mar 2003 20:34:05 +0100 Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SJXVRC002445 for ; Fri, 28 Mar 2003 20:33:31 +0100 Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2SJXUMK018047; Fri, 28 Mar 2003 12:33:30 -0700 (MST) Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA01772; Fri, 28 Mar 2003 12:33:14 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h2SJUG114776; Fri, 28 Mar 2003 13:30:17 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 33FF32EC86; Fri, 28 Mar 2003 20:30:15 +0100 (CET) Message-ID: <3E84A2C7.4080709@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Cc: =?ISO-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?=, Subject: Re: [nemo] Re: I-D ACTION:draft-paakkonen-nemo-prefix-delegation-00.txt References: <200303261216.HAA22598@ietf.org> <200303261216.HAA22598@ietf.org> <4.3.2.7.2.20030327082506.00bd5380@elemail.ele.vtt.fi> <3E82D9C1.9030903@crm.mot.com> <3E84171E.2090601@tml.hut.fi> In-Reply-To: <3E84171E.2090601@tml.hut.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 20:30:15 +0100 Content-Transfer-Encoding: 7bit Henrik Petander wrote: > Alexandru Petrescu wrote: > >> >> I would suppose that this is an issue of the link-local >> addressing of MR in general. The use of DHCPv6 is but one >> "link-local addressing" issue for MR > > > The issue is not only with addressing, but also with the hop limit > of 255. Hi Henrik, what hop limit 255 issue do you see more exactly? Is it related to nesting? Or is it related to sending link-local packets across the tunnel? Alex From nemo-admin@nal.motlabs.com Fri Mar 28 14:56:41 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14670 for ; Fri, 28 Mar 2003 14:56:39 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SJw6RC003015; Fri, 28 Mar 2003 20:58:06 +0100 Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2SJv6RC002979; Fri, 28 Mar 2003 20:57:07 +0100 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h2SJuE8j004665; Fri, 28 Mar 2003 12:56:15 -0700 (MST) Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id h2SJuLbQ004655; Fri, 28 Mar 2003 13:56:23 -0600 Received: from nal.motlabs.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3DA272EC86; Fri, 28 Mar 2003 20:56:37 +0100 (CET) Message-ID: <3E84A8F4.8020108@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Cc: Alexandru Petrescu , Erik Nordmark , "Hesham Soliman (EAB)" , Takeshi TANAKA , marcelo bagnulo , IETF NEMO Subject: Re: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Fri, 28 Mar 2003 20:56:36 +0100 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> >> --------- >> / | >> ----------/ | >> ------- | | | >> -| HA/BR |---| Internet | | >> ------- | | | >> ----------\ | >> \ | >> \ | >> | | >> | | >> ----- ----- >> | AR1 | | AR2 | >> ----- ----- >> | | >> >> >> | | >> ----- ----- >> | MR1 | | MR2 | >> ----- ----- >> | | >> ------------ >> | >> ----- >> | LFN | >> ----- >> >>>MR1 -> prefix 1 MR2 -> prefix 2 > > > Right, I should have drawn that picture. Thanks for doing it. Note that > MR2 is a rogue, does not even need a real home agent. > > > >>Ok, and both prefixes come from the home domain, right?, not >>from the visited domain. >> > > > Prefix 1 is from MR1's admin domain. > Prefix 2 is from MR2's admin domain, but if MR2 is an attacker, prefix 2 > is anything it wants to intercept. Ok, I see. So the basic assumption is that a mobile network is formed by MR1 and LFN. Then suddently MR2 comes in the picture and offers Internet alternative access to the mobile network. If that is the case, then MR2 should do first a form of access control to the mobile network. I mean, this would be an alternative tool to protect against that threat, but of course there might be others. >> I don't understand this, why would MR1 configure itself >> ("allocate?") an address out of P2? P2 is advertised on the RAs >> sent by the ingress interface by MR2, not by MR1 right? >> > > > MR1 gets RAs from MR2 like anyone else. If it is configured to > autoconf addresses, it will. Try it! Ok, I see, right, it will, if configured. But I wouldn't try this at home because: "The autoconfiguration process specified in this document applies only to hosts and not routers. Since host autoconfiguration uses information advertised by routers, routers will need to be configured by some other means." I mean, there is of course much text in many specs to read, and many interpretations are possible. Moreover, many implementations do many things, and many are in widespread use, and many things are common practice. So the above cited text is my preferred interpretation, and I have nothing against other interpretations. But, if I go with my preferred interpretation, then new doors are open by "other means", like e.g. zerouter-to-be. >> Also, why would MR1 install a connected route to P2 via its >> ingress interface? > > > Because it has an address on that prefix on that interface. So the > prefix is expected to be there. This is true for both static > addresses and autoconf'ed addresses. Ok, yes, if autoconfiguring an address then the directly connected route is added in the kernel routing table. I wonder if it will show up in the app's routing table too after if that is already started. If it does, then the threat sort of assumes that MR2 (the attacker) can securely talk to HA to inform it about the fake route. > You missed the point. I meant what I wrote. Sorry for missing your point, it was not my intention. All I'm trying to say is to better refine the threat and identify the potential protections against that threat. I'm not saying there's no threat. > If MR1 did learn P2 from a trusted routing protocol relationship > with MR2, that would not be a problem, but a standard case. Here > MR1 learns the prefix from ND that is not secure in nature. If > there is a MRHA routing protocol and if MR advertises the info > about P2 to HA1, HA1 will trust this. And install a route to P2. > And advertise that to its autonomous system, etc... So anyone > around HA1 is fooled into sending all traffic for P2 to MR2 via > MR1. Yes, exactly, I'm getting your point now, you're right. > I do not know if SeND looks into securing the prefix part of RAs. > The trust problem we have in PSBU The biggest trust problem with PSBU (to my understanding) is that it is a prefix and RR for prefixes impossible, because RR is a ping and you can't ping all addresses of a prefix. Alex From nemo-admin@nal.motlabs.com Fri Mar 28 19:03:55 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26348 for ; Fri, 28 Mar 2003 19:03:53 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2T059RC006862; Sat, 29 Mar 2003 01:05:10 +0100 Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2T04NRC006850; Sat, 29 Mar 2003 01:04:23 +0100 Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2T02VGw027131; Sat, 29 Mar 2003 01:02:32 +0100 (MET) Received: from xbe-lon-312.cisco.com ([64.103.99.72]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Sat, 29 Mar 2003 01:04:16 +0100 Received: from xbe-lon-303.cisco.com ([64.103.98.22]) by xbe-lon-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Sat, 29 Mar 2003 00:04:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6410.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Message-ID: Thread-Topic: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) Thread-Index: AcL1ZDQsF44ysdu9QiuisBH/UwzwygAIoEsQ From: "Pascal Thubert (pthubert)" To: "Alexandru Petrescu" Cc: "IETF NEMO" X-OriginalArrivalTime: 29 Mar 2003 00:04:15.0790 (UTC) FILETIME=[BC91F4E0:01C2F586] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by jessica.nal.motlabs.com id h2T04NRC006850 Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 29 Mar 2003 00:04:15 -0000 Content-Transfer-Encoding: 8bit > The biggest trust problem with PSBU (to my understanding) is > that it is a prefix and RR for prefixes impossible, because > RR is a ping and you can't ping all addresses of a prefix. > Actually you could use the anycast address of the mobile network, if that's really what you wanted to do... Pascal From nemo-admin@nal.motlabs.com Fri Mar 28 22:45:32 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00444 for ; Fri, 28 Mar 2003 22:45:28 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2T3jIRC008574; Sat, 29 Mar 2003 04:45:18 +0100 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2T3inRC008564 for ; Sat, 29 Mar 2003 04:44:51 +0100 Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2T3iZGP020679; Fri, 28 Mar 2003 20:44:36 -0700 (MST) Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id UAA02036; Fri, 28 Mar 2003 20:42:16 -0700 (MST)] Received: from nal.motlabs.com ([163.14.20.10]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id h2T3iXp05418; Fri, 28 Mar 2003 21:44:34 -0600 Message-ID: <3E8524A9.6090906@nal.motlabs.com> From: Alexandru Petrescu Organization: Motorola Labs - Paris User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" CC: IETF NEMO Subject: Re: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Sat, 29 Mar 2003 05:44:25 +0100 Content-Transfer-Encoding: 7bit Pascal Thubert (pthubert) wrote: >> The biggest trust problem with PSBU (to my understanding) is that >> it is a prefix and RR for prefixes impossible, because RR is a >> ping and you can't ping all addresses of a prefix. >> > > Actually you could use the anycast address of the mobile network, > if that's really what you wanted to do... I thought in anycast one address is chosen somehow to be representative for a set of addresses in a prefix ok; but even if that is so, one could not claim a successful RR, successful for the entire prefix, only because one representative of that prefix has succeeded. disclaimer: my anycast knowledge is low and not updated. Alex -- Message Classification: GBU From nemo-admin@nal.motlabs.com Mon Mar 31 13:18:08 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17681 for ; Mon, 31 Mar 2003 13:17:55 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2VIB6RC002955; Mon, 31 Mar 2003 20:11:18 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2VI8RRC002934 for ; Mon, 31 Mar 2003 20:08:38 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04970; Mon, 31 Mar 2003 11:08:15 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2VI8BK06520; Mon, 31 Mar 2003 20:08:12 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [nemo] new draft on MNP delegation for NEMO networks To: =?iso-8859-1?Q?Pekka_P=E4=E4kk=F6nen?= Cc: nemo@nal.motlabs.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20030326083724.00bcc6f0@elemail.ele.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 31 Mar 2003 20:08:07 +0200 (CEST) > I have submitted a new draft on Mobile Network Prefix (MNP) delegation > related to > mobile networks. The draft proposes that MNP delegation should occur between > a MR and its HA, and defines a MIPv6 extension for it. With this extension > it is possible for the MR to dynamically delegate MNPs when at home or away > from home. I hope that the draft causes discussion on MNP delegation related > to NEMO networks. I'm trying to understand how mobility makes the requirements on prefix delegation different than in the non-mobile case? It seems like the lifetime of the delegations are independent of the movements thus wouldn't whatever works for IPv6 in general work in the Nemo case? (Such as draft-ietf-dhc-dhcpv6-opt-prefix-delegation-03.txt) Erik From nemo-admin@nal.motlabs.com Mon Mar 31 13:53:30 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18999 for ; Mon, 31 Mar 2003 13:53:21 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2VIp8RC003212; Mon, 31 Mar 2003 20:51:10 +0200 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2VIM3RC003001; Mon, 31 Mar 2003 20:22:10 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16802; Mon, 31 Mar 2003 11:21:49 -0700 (MST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2VILgK07753; Mon, 31 Mar 2003 20:21:43 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [nemo] multihoming: potential threat? (was: about draft-ietf-nemo-requirements-00.txt) To: "Pascal Thubert (pthubert)" Cc: Alexandru Petrescu , Erik Nordmark , "Hesham Soliman (EAB)" , Takeshi TANAKA , marcelo bagnulo , IETF NEMO In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 31 Mar 2003 20:21:38 +0200 (CEST) > MR1 gets RAs from MR2 like anyone else. If it is configured to autoconf > addresses, it will. Try it! Note that RFC 2461 doesn't say that routers autoconfigure addresses based on RAs they receive - it merely states that routers should do some sanity checks to make sure different RAs don't have conflicting information (where different prefixes isn't a conflict). > You missed the point. I meant what I wrote. If MR1 did learn P2 from a > trusted routing protocol relationship with MR2, that would not be a > problem, but a standard case. Here MR1 learns the prefix from ND that is > not secure in nature. If there is a MRHA routing protocol and if MR > advertises the info about P2 to HA1, HA1 will trust this. And install a > route to P2. And advertise that to its autonomous system, etc... So > anyone around HA1 is fooled into sending all traffic for P2 to MR2 via > MR1. This is not actually specific to mobility, same as the initial > discussion. I don't think the setup you are considering makes any sense. If you have two routers on a link they both need to know the full set of prefixes assigned to that link in order for them to route packets properly. Having the routers try to learn this by peeking at router advertisements is not likely to be operationally robust. And this is not specific to Nemo. Erik From nemo-admin@nal.motlabs.com Mon Mar 31 13:56:04 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19120 for ; Mon, 31 Mar 2003 13:55:55 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2VItdRC003281; Mon, 31 Mar 2003 20:55:39 +0200 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h2VIMQRC003004 for ; Mon, 31 Mar 2003 20:22:32 +0200 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07807; Mon, 31 Mar 2003 10:22:00 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2VILoK07769; Mon, 31 Mar 2003 20:21:51 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark To: Alexandru Petrescu Cc: =?iso-8859-1?Q?Pekka_=3D=3Fiso-8859-1=3FQ=3FP=E4=E4kk=F6nen=3F=3D?= , Ole Troan , nemo@nal.motlabs.com, rdroms@cisco.com In-Reply-To: "Your message with ID" <3E82D9C1.9030903@crm.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [nemo] Link local addresses Sender: nemo-admin@nal.motlabs.com Errors-To: nemo-admin@nal.motlabs.com X-BeenThere: nemo@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mobile networks discussions List-Unsubscribe: , List-Archive: Date: Mon, 31 Mar 2003 20:21:46 +0200 (CEST) > I would suppose that this is an issue of the link-local addressing of > MR in general. The use of DHCPv6 is but one "link-local addressing" > issue for MR. The other link-local addressing issues for MR come from > the use of routing protocols between MR and HA; another link-local > address issue is also the HA sending RA's to MR (or MH for that > matter); yet another is from multicast MLD between MR and HA, that > also uses link-local addressing. What exists in MIPv6 is a prohbition from _forwarding_ packets with link-local addresses out over the tunnel to the MN. But I think all the cases above are about operating a protocol which uses link-local addresses on the link which is the tunnel; the link-local addresses used on the tunnel can be used in that case since there isn't any forwarding taking place. Perhaps this isn't clear enough in the specs. Thus in the particular case of DHCPv6, the HA would operate a DHCPv6 agent (either a server or a relay) on the tunnel interface. Erik From test-admin@nal.motlabs.com Mon Mar 31 22:22:38 2003 Received: from jessica.nal.motlabs.com (dns1.nal.motlabs.com [195.212.111.242]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08710 for ; Mon, 31 Mar 2003 22:22:29 -0500 (EST) Received: from jessica.nal.motlabs.com (localhost.localdomain [127.0.0.1]) by jessica.nal.motlabs.com (8.12.8/8.12.8) with ESMTP id h313McRC007739 for ; Tue, 1 Apr 2003 05:22:41 +0200 Date: Tue, 1 Apr 2003 05:22:38 +0200 Message-Id: <200304010322.h313McRC007739@jessica.nal.motlabs.com> Subject: nal.motlabs.com mailing list memberships reminder From: mailman-owner@jessica.nal.motlabs.com To: nemo-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: test-admin@nal.motlabs.com Errors-To: test-admin@nal.motlabs.com X-BeenThere: test@nal.motlabs.com X-Mailman-Version: 2.0.8 Precedence: bulk This is a reminder, sent out once a month, about your nal.motlabs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, nemo-request@nal.motlabs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@jessica.nal.motlabs.com. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@nal.motlabs.com pupafo http://www.nal.motlabs.com/mailman/options/nemo/nemo-archive%40lists.ietf.org