No Working Group R. Wakikawa Internet-Draft Keio University Expires: January 10, 2008 P. Thubert Cisco T. Boot Infinity Networks J. Bound HP B. McCarthy Lancaster University July 9, 2007 Problem Statement and Requirements for MANEMO draft-wakikawa-manemo-problem-statement-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 10, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Wakikawa, et al. Expires January 10, 2008 [Page 1] Internet-Draft PS. and Req. for MANEMO July 2007 Abstract The NEMO Basic Support protocol has well-known issues when multiple mobile routers are connected to each other in a nested fashion. These issues have been already analyzed in the NEMO Working Group. However, solutions are not yet considered and discussed in the IETF. MANEMO (MANET for NEMO) is an approach to resolve these issues. Although most of issues are relevant to what the MANET working group is chartered to deliver, a different approach may be required. This document identifies the problems which MANEMO will solve and provides the MANEMO requirements. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. MANEMO Characteristic . . . . . . . . . . . . . . . . . . . . 6 4. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 10 5. Existing Solutions and MANEMO approach . . . . . . . . . . . . 12 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative reference . . . . . . . . . . . . . . . . . . . 18 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log From Previous Version . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 23 Wakikawa, et al. Expires January 10, 2008 [Page 2] Internet-Draft PS. and Req. for MANEMO July 2007 1. Introduction Mobile Ad-hoc Network mechanisms have been standardized for local communication when wireless nodes are connected in an ad-hoc fashion. Several routing protocols were already standardized within the MANET working group and almost ready for deployment. The AUTOCONF working group has been recently formed to standardize the IP address configuration (both local address and global address). On the other hand, the NEMO working group has standardized the NEMO Basic Support Protocol [1] for global mobility of networks to support network movement transparency. The MANET/AUTOCONF and the NEMO working groups discuss their solutions separately without the consideration of integrating them. In the NEMO Working Group, the well-known issues caused by nested NEMO are addressed. Some of them are very similar to what the MANET/AUTOCONF working groups deal with as a problem space. However, the NEMO Basic Support protocol requires always connected Home Agent reachability and network movement transparency in relation to a mobile network. These multiple effort creates some contradiction between MANET/AUTOCONF and NEMO. We discuss this contradiction briefly in this document and also in [11]. In addition to that, the MANET protocols (DYMO [12] and OLSR [13]) may solve many of the upcoming problems introduced by new technologies, but implementing all functionalities of the MANET routing protocols may not be always desired for some specific issues. As the 6lowpan Working Group works on how to apply MANET protocols to LoWPANs (ex. RSN mailing list: Routing Sensor Network), it may be required to determine the possibility of either extending or downsizing the existing MANET/ AUTOCONF solutions for the nested NEMO problems for a sensor network. Since the nested NEMO problems are minor issues caused only within the NEMO Basic Support model, it may be time to look at a light-weight approach for the issues within the IETF. Solutions for MANEMO have already been proposed within the IETF such as [14] and [15]. The NEMO Working Group has the analysis document [16] for the nested NEMO issue. MANEMO is possibly related to the following on- going work in IETF. o Existing Routing Protocols (MANET, OSPF) o Network Mobility Support (NEMO) o Mobile Ad-hoc Network and Auto Configuration (AUTOCONF) o Mobile Ad-hoc Sensor Network (6LOWPAN) Wakikawa, et al. Expires January 10, 2008 [Page 3] Internet-Draft PS. and Req. for MANEMO July 2007 o Mobile Nodes and Multiple Interfaces in IPv6 (Monami6) Wakikawa, et al. Expires January 10, 2008 [Page 4] Internet-Draft PS. and Req. for MANEMO July 2007 2. Terminology The keywords "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 [2] Readers are expected to be familiar with all the terms defined in the RFC3753 [3] and the NEMO Terminology draft [4] MANEMO Fringe Stub (MFS) The MANEMO Fringe Stub is a cloud of Mobile Routers connected by wireless or wired links. Any type of link supporting IPv6 connectivity can be used, including partly meshed wireless topologies. An MFS is a stub at the edge of the Internet, interconnecting various types of devices which discover each other and form a network in an ad-hoc fashion to provide global connectivity to one another. Many disjunctive MFS can be connected to the Internet. An MFS can also be floating, which means the cloud is not connected to the Internet. Exit Router The Exit Router is a router which provides connectivity to the Internet and acts as a layer-3 sink for the MFS. The Exit Router can be a fixed Access Router supporting MANEMO or a mobile router (root-MR) connected directly to the Internet. Multiple Exit Routers may be available in an MFS. MANEMO MANET for NEMO. MANEMO provides the necessary additions to existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to find the most suited exit towards the Internet. MANEMO enables some internal connectivity within the nested NEMO whether the Internet is reachable or not. MANEMO is not MANET + NEMO. MANET + NEMO could suggest a MANET protocol reuse whereas MANET for NEMO suggests the development of a new protocol. Nested NEMO The Nested NEMO is a network configuration where one or more mobile routers are connected in a nested formation. The detailed issues can be found in [17] and [18]. Wakikawa, et al. Expires January 10, 2008 [Page 5] Internet-Draft PS. and Req. for MANEMO July 2007 3. MANEMO Characteristic Before discussing the detail of MANEMO problems, we highlight the characteristics of MANEMO Fringe Stub (MFS) by comparing it with a traditional ad-hoc network (MANET) in this section. Mobile routers of RFC3963 are the core nodes of an MFS. A mobile network served by a mobile router is seen as a normal IPv6 network. It is possible for a mobile router to connect to another mobile router's mobile network. As a result, mobile routers are connected and form a nested topology which is known as nested NEMO. In MFS, not only mobile routers, but also mobile hosts, fixed nodes (host and router) are considered. Fixed hosts and routers can be connected to one of the mobile networks and can also be located in the Internet. Access routers to provide wireless connectivity are also considered as a node within an MFS. All these nodes may be involved within the MANEMO protocol. Figure 1 shows the abstract topology of mobile routers. Two exit routers (ER1 and ER2) are identified and each number indicates a mobile router. In order to highlight the MANEMO characteristic, we only show the mobile routers in the topology. We discuss all the possible topologies of mobile routers in MFS in the MANEMO architecture [11]. Each mobile router owns an assigned prefix from its home agent. The prefix is configured for a mobile network. A mobile router acquires a topologically correct address (care-of address) at the egress interface and tunnels all the data to its home agent by using the care-of address. Although MANET supports Internet connectivity, because of NEMO Basic Support, the reachability to its home agent for home registration is a fundamental aspect of MANEMO. Without home registration, it cannot communicate to other nodes with its mobile network prefix according to RFC3963. If the binding registration is completed, all the traffic from the mobile network is tunneled to the home agent. In NEMO context, at least one exit router for MFS is required. MR1 and MR3 of Figure 1 can be away from the wireless attach facility and loose connectivity to the network. The disconnected MFS can also occur. Moreover, on the MANEMO mailing list, we currently discuss the case when each mobile router is connected by the egress interface and forms a MANET-like network. This case can be seen as "mobile routers forming a mobile ad-hoc network". Except for the assigned prefix to each mobile router, the characteristic of this scenario may be same as mobile ad-hoc network. Wakikawa, et al. Expires January 10, 2008 [Page 6] Internet-Draft PS. and Req. for MANEMO July 2007 +-------------------+ Internet (Wired/Wireless) | | | | | \|/ ER1 ER2 /|\ | / | 1---2 3 | |\ / | Wireless Links 4 5---6---7----8--9 | | \ \ | 10---11 12 13---14 \|/ Figure 1: Example Topology Figure 2 shows the difference of communication model between MANET and MANEMO. A mobile router (MR6) communicates with another mobile router (MR14) . The Figure 2-a shows the basic MANET communication model. MANET protocols maintain local routing information so that they can communicate directly inside this ad-hoc network. Even if there are multi-paths between nodes, most of the MANET routing protocols select the shortest path in default. If many sessions are in process within the network, the congestion at some links can be obviously observed. The links between MR6 to MR8 in Figure 2 may become possible bottlenecks if many nodes are communicating at the same time. Figure 2-b, on the other hand, shows the MANEMO communication model. The default communication path between MR6 and MR14 is through the Internet. Each mobile router transmits packets to the exit router even if the destination node is located nearby. Thus, packets are traveled over the Internet (through several home agents if it is required) and routed to the exit router to which the destination mobile router belongs. Even if the path length may increase, the path over the Internet is often more reliable than the shortest link. Note that it is true that the link between ER1-MR1 and ER2-MR3 become the bottleneck for all the traffic coming in and out of the MFS. Additional latency may also be observed, but it is a trade-off of several aspects such as latency, congestion, reliability and costs of local routing management (MANET routing protocol). In MANEMO, it is still possible to maintain the neighboring mobile routers. End nodes can communicate to the destination directly along the shortest path (not through the exit routers). Each mobile router should be able to decide whether the packets are routed to the exit router or to the destination directly. MANEMO does not identify how to manage local routing, but the primarily goal is to manage the path to the exit router as a default. Wakikawa, et al. Expires January 10, 2008 [Page 7] Internet-Draft PS. and Req. for MANEMO July 2007 (Internet) +===== HAn =======+ ER1 ER2 || // 1---2 3 1---2 3 |\ / |\\ // 4 5---6<==7====8--9 4 5==>6---7----8--9 | \ \\ | \ \\ 10---11 12 13==>14 10---11 12 13==>14 a) MANET b) MANEMO Figure 2: Communication Model When a mobile router changes its point of attachment, it must hide the changes from any nodes located in its mobile network [1]. Since nodes in the mobile network are moved all together, sets of mobile routers can move at once in MFS. Nodes can be an IPv6 node, a mobile host of RFC3775, and a mobile router of RFC3963. For instance, in Figure 3, a mobile router (MR4) moves its point of attachment. Even if MR4 moves, the movement has minimum impact to any nodes including mobile routers (MR10 and MR11) located in the MR4's mobile network. The mobile network nodes must be completely unaware of the movement. On the other hand, within most of the MANET and AUTOCONF schemes, the change of MR4's attachment effects the neighboring nodes (possibly the entire network). Most of the routing protocols require the route re-calculation or route re-discovery (route maintenance) when topology changes are occurred. This should be avoided because it breaks the nature of the NEMO basic support protocol. A detailed explanation can be found in [11]. +------------------+ +------------------+ ER1 ER2 ER1 ER2 | / | / 1---2 3 ==> 1---2 3 |\ / \ / |4| 5---6---7----8--9 5---6---7----8--9 | \ \ \ \ 10---11 12 13---14 12 13---14 | Router-4 moves to Router-12 |4| >| > 10---11 ^^^^^^^ Wakikawa, et al. Expires January 10, 2008 [Page 8] Internet-Draft PS. and Req. for MANEMO July 2007 movement transparency Figure 3: Movement Model Another aspect of MANEMO characteristic is that each mobile router can be connected by different wireless technology, while a default MANET assumption is to use a single wireless interface in ad-hoc mode (ex. 802.11b ad-hoc mode). Each mobile router has, at least two interfaces such as egress and ingress interfaces. For example, MR3 connects to ER2 by 3G (HSDPA), MR3 and MR8 are connected by 802.11b, MR8 and MR13 are by 802.11g, and so on. as described in Figure 4. +------------------+ ER1 ER2 | WiMAX / <-3G(HSDPA) 1---2 3 |\ / <-wifi(802.11b) 4 5---6---7----8--9 | \ \ <-wifi(802.11g) 10---11 12 13---14 wifi(802.11a) Figure 4: Movement Model The final difference is the routing capability. In MANET, each router can route the packet received at the manet interface [19]. A route can receive a packet from a manet interface and can send the packet from the same manet interface according to its routing table. However, in the NEMO Basic Support model, a mobile router can route only the tunneled packet to and from its mobile network. Without the bi- directional tunnel, the mobile router never routes the non- tunneled packet according to [1]. The packet sent from the ingress interface is always routed to the mobile router's home agent by using IP encapsulation. The incoming packets must always be tunneled from the mobile router's home agent except for the packets sent to the mobile node itself. Wakikawa, et al. Expires January 10, 2008 [Page 9] Internet-Draft PS. and Req. for MANEMO July 2007 4. Problem Statements Radio connectivity and movement have disrupted the concept of a link as we know it in the wired environment. Specific modes for specific radios are proposed to restore that concept, which is essential for IP operations, as single hop (802.11 infrastructure mode) or multihop (802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified solution to reconstruct a minimum topological abstraction at layer 3 for the use of NEMO. The MANEMO problems are already observed in several Working Groups and some are specified in [17], [20] 1. Sub-optimal route and Redundant tunnel: This issue is described in Section 2.1, 2.3 and 2.6 of [17] and in Appendix B.1, B.2, B.3, B.4 of [17]. 2. No Communication capability without Home Agent Reachability: This issue is described in Section 2.6 of [17] 3. Exit Router Selection: This problem occurs when a mobile node obtains multiple Exit Routers toward the Internet. In the illustrated case, the mobile node should attempt to obtain some information about each Exit Router in order to more efficiently utilize them. MANEMO may carry this information about each Exit Router and present it to the connected mobile node. . . . . . . . . . . . .. . . . The Internet . . . .. . . . . . . . . . . . | | +-+-+ +-+-+ |AR1| |AR2+--+ +-+-+ +-+-+ | | +---+ | | +-----|MR1|----+ | +-+-+ | | +-+-+ +--------+MR2| +---+ Figure 5: Multiple Exit Routers Wakikawa, et al. Expires January 10, 2008 [Page 10] Internet-Draft PS. and Req. for MANEMO July 2007 4. Network Loop: A network loop can occur when multiple mobile routers are nested and suddenly the Exit Router (root-MR, i.e. MR1) looses connectivity to the Internet and connects to the mobile network of a lower hierarchical MR (i.e. MR2 in the figure). In this case, the loop is observed between mobile routers. Each mobile network is designed to have movement transparency from the NEMO Basic Support Protocol. Any node connecting to a mobile network cannot know whether the access network is a mobile network or not. Moreover, it is impossible to know whether a connecting mobile router has managed Internet connectivity or not. The mobile router may loose Internet Connectivity, temporarily. Internet Internet | | +-+-+ +-+-+ |AR | |AR | +-+-+ +---+ | +-+-+ +---+ |MR1| --> |MR1+->+ +-+-+ +-+-+ | | /|\ | | | | +-+-+ +-+-+ \|/ |MR2| |MR2|<-+ +---+ +---+ Figure 6: Network Loop Section 4.8 of [20] discussed the loop problem when a mobile router is multihomed. Wakikawa, et al. Expires January 10, 2008 [Page 11] Internet-Draft PS. and Req. for MANEMO July 2007 5. Existing Solutions and MANEMO approach Several approaches can be taken for the problems listed in Section 4. Some analysis can be found in [21]. [MANET Routing Protocol and AUTOCONF] While manet routing protocols maintain the local connectivity, the primary goal of MANEMO is to discover an exit router and to maintain the path to the Internet through the exit router for binding registration and traffic over the bidirectional tunnel. Only for this purpose, MANET routing protocols have excess functionalities such as flooding messages for route discovery or route updates, etc. The primary goal of the MANET routing protocols is to maintain local connectivity. However, the local connectivity management should not be mandated to the MANEMO solution, although MANEMO may be interested in the local routing in the future. The NEMO Basic Support protocol basically requires tunneling the packets to the Internet. NHDP [22] is alternate solution to discover neighboring nodes, but it is limited to only two hop neighbors' information. There is a case that an exit router is more than 2 hops away. The AUTOCONF working group discusses the address assignment scheme for ad-hoc networks. However, the addressing architecture is slightly different from what the NEMO basic support protocol is expecting. More details can be found in [11]. [NEMO Route Optimization Scheme] There is no route optimization scheme in IETF. Only the analysis document is available in [16]. Contrary to the existing solutions, MANEMO arranges a tree structure towards the Internet. This tree is the simplest network topology connecting Mobile Routers within an MFS to a single Exit Router. The Exit Router is the root of the MANEMO Tree. The packets from MFS are routed along the tree and are routed to the destination. Routing to multiple home agents should be avoided as much as possible. Basic required functionalities for MANEMO are: 1. Discovering and Selecting exit routers 2. Forming loop-free Tree by making an exit router as a root 3. Maintaining the path to the exit router 4. Bypassing Home Agents for the traffic from MFS The MANEMO work focus is on a Neighbor Discovery (ND) [5] based solution that is required to provide multihop reachability while supporting the inner movements within the nested NEMO. ND provides the means to discover neighbors and the prefix on a link, which are Wakikawa, et al. Expires January 10, 2008 [Page 12] Internet-Draft PS. and Req. for MANEMO July 2007 pervasive across IPv6 nodes and link types. Mobile IPv6 [6] and NEMO [1] rely heavily on ND for roaming and Home Link activities. Considering that NEMO already uses ND for Router Discovery, it makes sense to extend ND in MANEMO as opposed to providing a second peering mechanism. ND has already been extended to expose some layer 3 information, such as router selection hints [7]. ND is consistently being improved for mobility, in particular with Mobile IPv6 [6] and DNA [23], and for security with Secure ND [8]. ND operates on bidirectional links, whereas this is a restriction from the MANET standpoint, this condition enables simpler solutions for MANEMO. Neighbor Discovery is well suited for providing hints for composing a path to the Internet access router. The Exit Routes connect MFS to the Internet. Multicast support could be provided by using the loop-free MANEMO Tree to forward packets to the Internet. Down-tree forwarding would use MLD-proxy [24], either with native MLD [9][10] / ICMP packets or send with the ND extensions to increase efficiency. Wakikawa, et al. Expires January 10, 2008 [Page 13] Internet-Draft PS. and Req. for MANEMO July 2007 6. Requirements MANEMO has the following requirements: R1: MANEMO must enable the discovery of multihop topologies at layer 3 from mere reachability and elaborate links for IPv6 usage, regardless of the wired or wireless media. R2: MANEMO must enable packets transmitted from nodes visiting the MFS to reach the Internet via an optimized path towards the nearest Exit Router, and back. R3: MANEMO must enable IP connectivity within the MFS whether Internet is reachable or not. R4: MANEMO must enable packets transmitted from nodes visiting the MFS to reach the Internet with a topologically correct address. R5: MANEMO should aim at minimizing radio interference with itself as the control messages get propagated in the MFS. R6: MANEMO must enable inner movements within MFS to occur, and ensure propagating details of this movement is kept at a minimum. R7: An MFS may split to become two separate MFSs, in this case MANEMO must continue to maintain local connectivity within the separate MFSs and connectivity between the split MFSs. MFSs may merge, in this case inner MFS connectivity optimization must be restored. R8: MANEMO should enable and optimize the trade-off between ensuring some reciprocity between MFS peers and maintaining a safe degree of CIA properties between the peer Mobile Routers. R9: MANEMO must support ad-hoc operation, for isolated MFSs (R3) and multi-hop access to the Internet (R2). R10: MANEMO must not require modifications to any node other than nodes that participates to the MFS, including HA. It must support fixed nodes, mobile hosts and mobile routers in the MFS, and ensure backward compatibility with other standards defined by the IETF. R11: MANEMO should enable multicast communication, for nodes within the MFS and on the Internet. Wakikawa, et al. Expires January 10, 2008 [Page 14] Internet-Draft PS. and Req. for MANEMO July 2007 R12: MANEMO must optimize the path to the Internet using cross-layer metrics. R13: MANEMO may provide direct peer to peer reachability for nearby nodes. Wakikawa, et al. Expires January 10, 2008 [Page 15] Internet-Draft PS. and Req. for MANEMO July 2007 7. IANA considerations This document does not require any IANA action. Wakikawa, et al. Expires January 10, 2008 [Page 16] Internet-Draft PS. and Req. for MANEMO July 2007 8. Security Considerations This document is a problem statement and does not create any security threat. It discusses the concepts of Capability, Innocuousness and Anonymity in a nested NEMO. Wakikawa, et al. Expires January 10, 2008 [Page 17] Internet-Draft PS. and Req. for MANEMO July 2007 9. Acknowledgments We would like to thank all the people who have provided comments on this draft, and also co-authors of earlier documents in which authors of this present document have been engaged. As such, we would like to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham Soliman, Carlos Jesus Bernardos Cano and many others. 10. References 10.1. Normative reference [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [7] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, November 2005. [8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Wakikawa, et al. Expires January 10, 2008 [Page 18] Internet-Draft PS. and Req. for MANEMO July 2007 10.2. Informative Reference [11] Wakikawa, R., "MANEMO Topology and Addressing Architecture", draft-wakikawa-manemoarch-00 (work in progress), July 2007. [12] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-10 (work in progress), July 2007. [13] Clausen, T., "The Optimized Link State Routing Protocol version 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. [14] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-07 (work in progress), February 2007. [15] Thubert, P., "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-06 (work in progress), July 2007. [16] Ng, C., "Network Mobility Route Optimization Solution Space Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in progress), September 2006. [17] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03 (work in progress), September 2006. [18] Clausen, T., "NEMO Route Optimisation Problem Statement", draft-clausen-nemo-ro-problem-statement-01 (work in progress), March 2007. [19] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-chakeres-manet-arch-01 (work in progress), October 2006. [20] Ng, C., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-07 (work in progress), February 2007. [21] Boot, T., "Analysis of MANET and NEMO", draft-boot-manet-nemo-analysis-01 (work in progress), June 2007. [22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-04 (work in progress), July 2007. [23] Kempf, J., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-06 (work in progress), Wakikawa, et al. Expires January 10, 2008 [Page 19] Internet-Draft PS. and Req. for MANEMO July 2007 June 2007. [24] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD- Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in progress), April 2004. Wakikawa, et al. Expires January 10, 2008 [Page 20] Internet-Draft PS. and Req. for MANEMO July 2007 Appendix A. Change Log From Previous Version o Removed Use-Case Scenarios o Updated the Section4: use the references to existing documents o Removed the Approach Rationale Authors' Addresses Ryuji Wakikawa Department of Environmental Information, Keio University 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1100 Fax: +81-466-49-1395 Email: ryuji@sfc.wide.ad.jp URI: http://www.wakikawa.org/ Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Teco Boot Infinity Networks B.V. Elperstraat 4 Schoonloo 9443TL Netherlands Email: teco@inf-net.nl Wakikawa, et al. Expires January 10, 2008 [Page 21] Internet-Draft PS. and Req. for MANEMO July 2007 Jim Bound Hewlett-Packard PO BOX 570 Hollis, NH 03049 USA Phone: +603 465 3130 Email: jim.bound@hp.com McCarthy Ben Lancaster University Computing Department, Lancaster University. InfoLab 21, South Drive Lancaster, Lancashire LA1 4WA UK Phone: +44-1524-510-383 Fax: +44-1524-510-492 Email: b.mccarthy@lancaster.ac.uk URI: http://www.network-mobility.org/ Wakikawa, et al. Expires January 10, 2008 [Page 22] Internet-Draft PS. and Req. for MANEMO July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wakikawa, et al. Expires January 10, 2008 [Page 23]