No Working Group R. Wakikawa Internet-Draft Keio University Expires: January 2, 2008 T. Clausen LIX, Ecole Polytechnique B. McCarthy Lancaster University A. Petrescu Motorola Labs July 1, 2007 MANEMO Topology and Addressing Architecture draft-wakikawa-manemoarch-00.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 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Wakikawa, et al. Expires January 2, 2008 [Page 1] Internet-Draft MANEMO Architecture July 2007 Abstract This document outlines the MANEMO architecture including possible topology configuration and addressing assignment. The issues of MANEMO (previously known as nested NEMO) are already summarized in several documents. However, there are several ways how to comprehend what is MANEMO. The MANEMO problems are related to several existing working groups. This document provides the MANEMO architecture model and differences of existing solutions so that IETF can classify the problems and start working on the solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. What is Network Mobility (NEMO) Basic Support . . . . . . . . 4 3. MANEMO Topologies . . . . . . . . . . . . . . . . . . . . . . 7 3.1. MANEMO Basic Topologies . . . . . . . . . . . . . . . . . 7 3.2. MANEMO Advanced Topologies . . . . . . . . . . . . . . . . 9 4. Addressing Architecture of MANEMO . . . . . . . . . . . . . . 11 4.1. NEMO Addressing Approach (MANEMO Architecture) . . . . . . 11 4.2. AUTOCONF Approach (MANET Architecture) . . . . . . . . . . 14 4.3. Comparison of Two Approaches . . . . . . . . . . . . . . . 18 5. Solution Guideline . . . . . . . . . . . . . . . . . . . . . . 20 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9.1. Normative reference . . . . . . . . . . . . . . . . . . . 23 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Wakikawa, et al. Expires January 2, 2008 [Page 2] Internet-Draft MANEMO Architecture July 2007 1. Introduction When mobile routers and mobile nodes converge at the edge of the Internet using wireless interfaces, they can form a wireless network cloud and are able to provide Internet connectivity to one another. This type of network is called a MANEMO Fringe Stub (MFS). Several issues exist in the MFS such as network loop, sub-optimal route, redundant tunnels, multiple exit routers selection, and HA dependency of the NEMO Basic Support. While fixed routers provide connectivity constantly, mobile routers can experience intermittent connectivity to the Internet due to their movement. When the NEMO Basic Support is used in this context, network loops naturally occur. NEMO forces the packets to always travel through the home agent, which in turn causes an sub-optimal route that can become a considerable problem when mobile routers form a nested topology. Different types of routers are able to provide Internet connectivity in the MFS, including both mobile routers and fixed access routers. Any node requiring Internet connectivity has to select the best exit router toward the Internet, therefore it is necessary for mobile nodes to maintain a local topology in the MFS and to utilize any available connectivity with a degree of Intelligence. Unfortunately, MANEMO is still not yet clearly defined and understood by IETF community, this draft attempts to address that problem by identifying the topologies that arise with MANEMO and analyzing their requirements. It is still uncertain whether MANEMO configurations can be suitably supported by MANET/AUTOCONF approaches. In order to determine whether the MANEMO problem can be addressed by existing solutions, we must analyze the expected topology formations, wireless technologies, addressing, etc. We believe there are also missing pieces for MANEMO in IETF. This draft is aimed at helping identify what are those missing pieces. This document describes first the whole idea of the NEMO Basic Support. Then, possible MANEMO topologies are given. Finally we consider a typical MANEMO addressing scheme. We feel that analyzing the problem area in this detail can help the reader's understanding of what MANEMO is and its relationship with existing activity. Wakikawa, et al. Expires January 2, 2008 [Page 3] Internet-Draft MANEMO Architecture July 2007 2. What is Network Mobility (NEMO) Basic Support This section provides brief explanation of Network Mobility Basic Support protocol. If readers are familiar with RFC3753 [1], RFC3775 [2], RFC3963 [3], draft-ietf-nemo-ro-problem-statement [6], please skip this section. A mobile network is defined in RFC3753 [1], "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 of 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.". A mobile network is seen as just IPv6 subnet by any nodes except for Mobile Routers. According to RFC3963, Figure 1 is the common interpretation of a mobile router. Each Mobile Router has an egress interface(s) to reach the home agent through the Internet and also an ingress interface(s) attaching to the Mobile Network. A mobile router obtains its care-of address at the egress interface and establishes a bi-directional tunnel to the home agent. It routes all the packets intercepted at the ingress interface to the bi-directional tunnel. The packet's source address must belong to the mobile network prefix. Only the packets sent to and from a mobile network are routed to the tunnel by the mobile router. Access Network | +-+-+ |AR | +-+-+ | <-egress interface(s) +-+-+ |MR1| +-+-+ | <-ingress interface(s) -+-+-+-+-+- Mobile Network | | | | | H H H H H Mobile Network Nodes (MNNs) Figure 1: Mobile Router Configuration Some known remarks from this NEMO Basic Support are: o Unless a node (host or router) is connected to a mobile network, NEMO guarantees the session continuity to the node. Wakikawa, et al. Expires January 2, 2008 [Page 4] Internet-Draft MANEMO Architecture July 2007 o Any nodes attached to the mobile network are unaware of the mobile router's changing attachment point. The mobile network can be seen as just an IPv6 network. o An access router at the visiting network is not aware of a mobile network existence behind a mobile router. According to draft-ietf-nemo-terminology [4], several different entities can be attached to the mobile network such as Fixed Router in a mobile network and Mobile Network Node including Local Fixed Node, Visiting Mobile Node and Local Mobile Node. In Figure 2, an IPv6 router called Fixed Router is deployed in a mobile network. The fixed router has a dedicated mobile network prefix. The dedicated prefix can be delegated from the mobile network prefix of its mobile router like Figure 2-a. The mobile router sends a binding update for the aggregated mobile network prefix (2001:1::/48). Alternatively, it can be configured with non-aggregated prefix as shown in Figure 2-b. The mobile router sends a binding update containing two mobile network prefix options for both mobile network prefixes (2001: a::/64 and 2001:b::/64). The Fixed Router sends ICMP route advertisements, in order to reach other nodes in the moving network it needs to have routes installed, and this can be achieved by static routes or by running a routing protocol. The Mobile Router has to have a route towards the mobile network prefix owned by the Fixed Router through Fixed Router's IP address. That route can be manually installed, manually configured in a routing protocol configuration file, or dynamically delegated with DHCP Prefix Delegation. Access Network Access Network | <--- egress interface(s) ---> | +-+-+ +-+-+ |MR | Mobile Router |MR | +-+-+ +-+-+ | <-- ingress interface(s) --> | ------+------+----- ------+------+----- Mobile Network/48 | Mobile Network/64 | 2001:1::/48 +-+-+ 2001:a::/64 +-+-+ |FR | |FR | +-+-+ <-- Fixed Router --> +-+-+ | | ------+------ ------+------ Mobile Network-FR/64 Mobile Network-FR/64 2001:1:1::/64 2001:b::/64 a) b) Wakikawa, et al. Expires January 2, 2008 [Page 5] Internet-Draft MANEMO Architecture July 2007 Figure 2: Mobile Router Configuration with Fixed Router When a visiting mobile node is attached to a mobile network, we call this network formation as nested NEMO. Figure 3 shows the two cases where either a mobile node or a mobile router is attached to a mobile network. Specially, if a visiting mobile node is a mobile router, the number of nested level goes longer (Figure 3-b)). Several issues are raised when Nested NEMO is occurred. The nested NEMO issues are already introduced in several documents [6], [7] Access Network Access Network | | +-+-+ +-+-+ |AR | |AR | +-+-+ +-+-+ | | +-+-+ +-+-+ |MR | |MR1| +-+-+ +-+-+ | | -+---+---+- -----+---+- | | | +-+-+ +-+-+ +-+-+ |MN1| |MN2| |MR2| +---+ +---+ +-+-+ : a) : +-+-+ |MRn| +-+-+ | b) Figure 3: Nested NEMO Configuration Wakikawa, et al. Expires January 2, 2008 [Page 6] Internet-Draft MANEMO Architecture July 2007 3. MANEMO Topologies The NEMO Basic Support protocol introduces two different interfaces on a mobile router known as the egress interface and the ingress interface. In MANEMO, several topologies can be expected by attachment combination of these two interfaces. 3.1. MANEMO Basic Topologies When considering MANEMO, following topology can be logically possible. 1. Egress and Ingress (E-I) attachment 2. Egress and Egress (E-E) attachment 3. *Ingress and Ingress (I-I) attachment 4. **Egress/Ingress and Egress/Ingress (EI-EI) attachment [*MANEMO does not consider this case. The reasons are given later in this section.] [**EI-EI is another configuration of E-E attachment. While the NEMO Basic Support does not assume using single interface for both egress and ingress, MANEMO consider this special configuration, too. See Section 3.2 for details.] The E-I attachment is the most common configuration of the NEMO Basic Support. A mobile router connects to the other mobile routers' mobile network by its egress interface. Figure 4 shows the example topology. (e) and (i) in all the figures in this section indicate egress and ingress interfaces. Wakikawa, et al. Expires January 2, 2008 [Page 7] Internet-Draft MANEMO Architecture July 2007 |e |e +-----+ +-----+ | MR | | MR | +-----+ +-----+ |i |i | +---------+ |e | |e +-----+ +-----+ +-----+ | MR | | MR | | MR | +-----+ +-----+ +-----+ |i |i | | |e |e +-----+ +-----+ | MR | | MR | +-----+ +-----+ |i |i Figure 4: Egress-Ingress (E-I) attachments. Figure 5 shows the two (E-E and I-I) scenarios. The E-E attachment is the case when a mobile router uses ad-hoc type of interfaces such as 802.11b ad-hoc mode or 802.11s as its egress interface. Each mobile router connects with egress interface. In MANEMO, this scenario is also considered for inter vehicle networks, etc. (see ref). On the other hand, although the ingress and ingress attachment is logically possible, it is slightly unrealistic. First of all, when ingress interfaces of different mobile routers are connected , two different mobile networks are merged in the single mobile network. A mobile network node will obtain multiple IP addresses from different mobile routers. For instance, in Figure 5, a mobile network node of MR1 obtains an address of mobile network prefixes of all the mobile routers (MR1, MR2 and MR3). Whenever a mobile router leaves, the addresses of the entire mobile network node generated from the mobile network prefix of leaved mobile router will go unreachable. This configuration may break the fundamental features of the NEMO Basic Support protocol (lack of movement transparency). Thus, we do not consider I-I attachment scenario in MANEMO. Wakikawa, et al. Expires January 2, 2008 [Page 8] Internet-Draft MANEMO Architecture July 2007 e+-----+i e+-----+i +--| MR |-- --| MR1 |--+ | +-----+ +-----+ | | | | e+-----+i e+-----+i | +--| MR |-- --| MR2 |--+ | +-----+ +-----+ | | | | e+-----+i e+-----+i | +--| MR |-- --| MR3 |--+ +-----+ +-----+ Figure 5: E-E and I-I Attachment 3.2. MANEMO Advanced Topologies In MANEMO, the different scenarios from the basic topologies are also considered. First, a mobile router only equips with single wireless interfaces and utilizes it conceptually as both egress and ingress interface. In the NEMO Basic Support, a mobile router is assumed to have physically two different interfaces. However, in this context, the ingress and egress interfaces are roles over the same physical interface. A mobile router exposes its mobile network prefix to the interface and also obtains a care-of address at the same interface (named EI-EI attachment). Figure 6 shows the example topology. e/i+-----+ +---| MR | | +-----+ | |e/i+-----+ +---| MR | | +-----+ | |e/i+-----+ +---| MR | +-----+ Figure 6: EI-EI attachment Another scenario is that a mobile router has a fixed router(s) in its mobile network so that another visiting mobile router (a mobile network node) connects to the mobile network through the fixed router. Figure 7 gives two examples. There are several links where a mobile network node can attach. In Figure 7-b), a mobile router Wakikawa, et al. Expires January 2, 2008 [Page 9] Internet-Draft MANEMO Architecture July 2007 attaches to the link between the mobile router (MR) and the fixed router (FR). This topology is possible only if a mobile router allows mobile network nodes to attach to this link. It totally depends on the admission control of each mobile network. When deploying the NEMO Basic Support protocol, it is necessary to consider this fixed router availability in a mobile network. ......|...... : |e : |e : +-----+ : +-----+ : | MR | : | MR | : +-----+ : +-----+ : |i : |i : | : +---------+ : | : | | : +-----+ : +-----+ +-----+ : | FR | : | MR | | FR | : +-----+ : +-----+ +-----+ : |i : | :.....|...... | |e |e +-----+ +-----+ | MR | | MR | +-----+ +-----+ |i |i a) b) Figure 7: Use of Fixed Routers Wakikawa, et al. Expires January 2, 2008 [Page 10] Internet-Draft MANEMO Architecture July 2007 4. Addressing Architecture of MANEMO After the formation of the Nested NEMO, the argument is how to assign an address to each mobile node and mobile router. There are two different approaches today in IETF, 1) NEMO addressing approach and 2) AUTOCONF addressing approach. This section briefly explains the two approaches and discusses their pros and cons. 4.1. NEMO Addressing Approach (MANEMO Architecture) According to the NEMO Basic Support, an attached node to a mobile network will get an address from the mobile network. Figure 8 gives the simplest case. MR1 obtains an IP address (ANP::MR1 as CoA) from the access router that advertised prefix is ANP::/64. The MR2 attached to a mobile network of MR1 generates its CoA from the MNP1::/64. This is what the NEMO basic support is assumed in the protocol design. (e) and (i) in all the figures in this section indicate egress and ingress interfaces, too. Access Network | +-+-+ |AR | +-+-+ | ------+------ ANP::/64 e| ANP::MR1 +-+-+ |MR1| +-+-+ i| ------+------ MNP1::/64 e| MNP1::MR2 +-+-+ |MR2| +-+-+ i| -----+------ MNP2::/64 Figure 8: NEMO Address Assignment for E-I attachment Alternatively, Figure 9 gives another address assignment when a mobile network is formed with a mobile router and a fixed router(s). As discussed with Figure 2, two possible prefix assignment to the fixed router is considered, (1) the mobile network prefix can be divided into sub-prefixes that can be aggregated and one of the sub- Wakikawa, et al. Expires January 2, 2008 [Page 11] Internet-Draft MANEMO Architecture July 2007 prefixes can be assigned to a Fixed Router, (2) the mobile network prefix and the Fixed Router's prefix can be totally different and not necessarily aggregated. In both cases it's the administrator who decides this addressing architecture, it is not the mobile router who divides and assigns. In this Figure, the mobile router (MR1) owns the mobile network prefix (MNP1::/48) and assigns sub-prefixes of the mobile network to a fixed router (FR1). A mobile network node is attached to a link of FR1 (MNP1:1::/64) and maybe not to a link of MR1 (MNP1::/48). If a node is attached to the link of MR1, it turns to the same configuration of Figure 8. In this example, MR2 is attached to a link of FR1 and acquires the MNP1:1::MR2 address as its CoA. Access Network | +-+-+ |AR | +-+-+ | ------+------ ANP::/64 e| ANP::MR1 +-+-+ |MR1| +-+-+ i| ------+------ MNP1::/48 | +-+-+ |FR1| +-+-+ i'| -----+------ MNP1:1::/64 e| MNP1:1::MR2 +-+-+ |MR2| +-+-+ i| -----+------ MNP2::/64 Figure 9: NEMO Address Assignment when Fixed Router is employed According to Section 3, the other possible topology of the nested NEMO are E-E and EI-EI attachments described in Figure 10. The egress interface of each MR is connected in ad-hoc fashion by using 802.11b in ad-hoc mode. This is not originally assumed in the NEMO Basic Support Protocol. Figure 10 is just an example which was Wakikawa, et al. Expires January 2, 2008 [Page 12] Internet-Draft MANEMO Architecture July 2007 discussed in the MANEMO mailing list. In this case, MR reveals its mobile network prefix to its egress interface so that the attached MR (MR2 for MR1) can obtain an IPv6 address (MNP1::MR2) from the upper Mobile Router. The definition of egress interface is extended to support some role of ingress interface. As shown in , two possible scenarios can be given whether the mobile router has its physically available ingress interface or not. In the Scenario-1 (E-E attachment), each mobile router owns its physically available ingress interface. Therefore, the mobile network prefix is advertised to both ingress interface and egress interface by using ICMP Router Advertisement, while the mobile router acquires its care-of address from the upper router (ex. AR for MR1, MR1 for MR2). Note that the NEMO Basic Support does not allow for a mobile router to send ICMP router advertisements for its own mobile network prefix from the egress interface. The mobile router must support bridge functionality between the ingress interface and egress interface. MNN1 (MNP1::MNN) and MR2's egress interface (MNP1::MR2) must be located at the same link, otherwise the multilink subnet issue [8] is occurred. However, this bridge functionality is not currently supported by the NEMO Basic Support protocol. On the other hand, the scenario-2 is simpler than the the scenario-1. A mobile router does not necessarily support the bridge functionality because it does not have an ingress interface. The mobile router uses a single interface as an egress and ingress interfaces. A mobile router must check the source address of all the packets to decide whether the packets should be routed to the bi-directional tunnel or not. In the packet's source address is the CoA of a mobile router, it MUST NOT tunnel the packet. But the source address of a packet is an address of its mobile network prefix, the packet MUST be tunneled to the home agent. Again, this configuration is also not considered by the NEMO Basic Support protocol and needs some modifications to the NEMO Basic Support protocol. Wakikawa, et al. Expires January 2, 2008 [Page 13] Internet-Draft MANEMO Architecture July 2007 Scenario-1(E-E attachment) Scenario-2 (EI-EI attachment) Access Network Access Network | | +-+-+ +-+-+ |AR | ANP::/64 |AR | ANP::/64 +-+-+ +-+-+ | | ------+------ ANP::/64 ------+------ ANP::/64 | | ANP::MR1 e+---- ANP::MR1 ei +----- +-+-+ \ +-+-+ \ |MR1| \ |MR1| \ +-+-+ \ +---+ \ i| \ __| -+----+---- __| /ei|MNP1::MR2 | / e|MNP1::MR2 ______/ +-+-+ MNN1 ______/ +-+-+ / |MR2| MNP1::MNN / |MR2| / +---+ / +-+-+ | | i| ei|MNP2::MR3 | ----+-+-+- +-+-+ | | | |MR3| e|MNP2::MR3 MNN MNN +---+ +-+-+ (MNP2::MNNi) |MR3| +-+-+ i| -+-+-+-+-+-- | | | | | MNNs (MNP3::MNNi) Figure 10: NEMO Address Assignment for E-E and EI-EI attachments 4.2. AUTOCONF Approach (MANET Architecture) The Ad-hoc Network Autoconfiguration (AUTOCONF) working group summarizes the MANET Architecture in [9]. This section gives brief explanation how to apply the MANET architecture to the nested NEMO topology. Figure 11 shows the case where each mobile router is connected by its egress interface in ad-hoc fashion. This scenario is very similar to what MANET is expected. Each mobile router obtains an IPv6 address on its egress interface from the access router called internet gateway in the MANET community. Thus, each mobile router, at the end, obtains an address derived from the access router's prefix (ANP::/64). Note that the egress interface can be treated as a manet interface in this case. Thus, the address Wakikawa, et al. Expires January 2, 2008 [Page 14] Internet-Draft MANEMO Architecture July 2007 assigned to the manet interface must be unique as stated in [9]. [9] suggests link-local addresses, IPv6 address/128, and unique prefix/n (n < 128) per a manet interface. Although the link-local address (LL-MRn-e/128) can be used for the MANET purpose at the manet interface, each mobile router MUST obtain at least one global address for sending a binding update. We will not discuss the use of link local address in further section. Either ANP::MRn/128 or ANP:n:: MRn/64 can be possible for the address on the egress interface (i.e. manet interface) as shown in Figure 11. When each mobile router obtains a unique prefix from the access router, the access router should manage the several prefixes in order to assign individual prefix to every mobile router. The mobile router uses the address (ANP::MRn/128 or ANP:n::MRn/64 in Figure 11) as a care-of address and registers its binding to the home agent. Note that in AUTCONF approach, E-E and EI-EI attachments can be treated as a same, because a mobile router does not advertise its mobile network prefix to the egress interface. Each mobile router only obtains an IPv6 address from access router and not from neighbors (other mobile routers). Access Network | +-+-+ |AR | ANP::/64 or /48 +-+-+ | +----- ANP::MR1/128 or --> |e | ANP:1::MR1/64 or +-+-+ \ LL-MR1-e/128 |MR1| | +-+-+ \ i| \ -----+---- __| / e| <-- ANP::MR2/128 or _____/ +-+-+ ANP:2::MR2/64 or / |MR2| LL-MR2-e/128 / +-+-+ | i| | ----+----- e|<-- ANP::MR3/128 or +-+-+ ANP:3::MR3/64 or |MR3| LL-MR3-e/128 +-+-+ i| -----+------ Wakikawa, et al. Expires January 2, 2008 [Page 15] Internet-Draft MANEMO Architecture July 2007 Figure 11: AUTOCONF addressing assignment for E-E attachment Figure 12 shows the AUTOCONF model when mobile routers are formed in the E-I attachment. According to the MANET architecture [9], MR2 in Figure 12 can obtain an address from the access router (ANP::MR2/128 or ANP:2::MR2/64), even in this configuration. Alternatively, MR2 can run the address autoconfiguration [5] at the attached link (mobile network of MR1) and obtains the MNP1::MR2/64 on its egress interface as a regular IPv6 address autoconfiguration. Thus, a mobile router may obtain two different addresses such as one from the access router and one from its upper mobile router. For example, the mobile router (MR1) directly attached to the access router only obtains an IPv6 address from the access router, because there are no other upper mobile routers. On the other hand, MR2 gets two addresses from upper mobile router (MR1) and the access router. The mobile router should always select the address assigned from the access router as a care-of address and registers it to the home agent. By doing so, any of tunnel overhead issues raised in the MANEMO problem statement are merely occurred. The loop issue can also be avoided by running a manet routing protocol on its manet interface. However, there is one big issue that the upper mobile router's movement causes the effect to the attached nodes. For example, if MR1 moves change its point of attachment, MR2 also detects movement. This is not what the NEMO Basic Support protocol is aimed for. The movement of a mobile router must be hidden from any nodes in its mobile network. We discuss this in Section 4.3. Access Network | +-+-+ |AR | ANP::/48 or /64 +-+-+ | e| <-- ANP::MR1/128 or ANP:1::MR1/64 +-+-+ |MR1| +-+-+ i| MNP1::/64 ------+------ | <- MNP1::MR2/64 (NOT AUTOCONF address) e| <-- ANP::MR2/128 or ANP:2::MR2/64 +-+-+ |MR2| +-+-+ i| -----+----- Wakikawa, et al. Expires January 2, 2008 [Page 16] Internet-Draft MANEMO Architecture July 2007 Figure 12: AUTOCONF Addressing Assignment for the basic Nested NEMO Another problem of this configuration is explained with Figure 13. If a fixed router (FR1) is located in the mobile network, the MANET architecture treats this case as two separate manets inter-connecting by a fixed router. Thus, conceptually, MR2 cannot obtain an address from the access router because the fixed router separates MR1 and MR2. Even if we extend the concept of the MANET architecture [9] in order for the access router to deliver the global unique prefix to the MR2, another problem can be caused. FR1 must have a route of the MR2's prefix assigned by the access router. However, FR1 is just an IPv6 router (i.e. supporting neither the NEMO Basic Support nor AUTOCONF), there is no way that FR1 has a route of the access router's prefix. FR1 cannot route the packet which destination is MR2's address (ANP::MR2/128 or ANP:2::MR2/64) unless the route of MR2's assigned address/prefix is installed in FR1. Access Network | +-+-+ |AR | ANP::/48 or /64 +-+-+ | e|<-- ANP::MR1/128 or ANP:1::MR1/64 +-+-+ |MR1| +-+-+ i| MNP1::/48 ------+------ | +-+-+ <-- it should have routes of either one of |FR1| [ANP:1::/64 & ANP:2::/64] or +-+-+ [ANP::MR1/128 & ANP::MR2/128] i'|MNP1:1::/64 -----+------ |<---MNP1:1::MR2 (NOT AUTOCONF address) e|<--- ANP::MR2/128 or ANP:2::MR2/64 <-- how?? +-+-+ |MR2| +-+-+ i| -----+------ Figure 13: AUTOCONF Addressing Assignment when Fixed Router is employed Wakikawa, et al. Expires January 2, 2008 [Page 17] Internet-Draft MANEMO Architecture July 2007 4.3. Comparison of Two Approaches Before discussing the two approaches, the known MANEMO problems [10] are listed here. o Sub-optimal Route and Redundant tunnel o Network Loop o Multiple Exit Routers (Exit Router selection) o No Communication capability without Home Agent Reachability If the AUTOCONF approach (Section 4.2) is taken, every mobile router may be expected to run a manet routing protocol such as DYMO, OLSR, AODV. Although AUTOCONF approach may not apply to the MANEMO scenarios without modification, MANET + AUTOCONF combination can solve some of MANEMO issues. The sub-optimal route can be easily solved because each mobile router can registers its care-of address generated from the access network prefix. The packets are routed to the access router by IP routing and then routed to the correspondent mobile router by the manet routing. Thus, suboptimal route and redundant tunnel are even not happened in this case. The loop free topology formation is essential of a manet routing protocol, too. The multiple exits may be solved if a manet routing protocol carries additional information of exit routers along with the route information. Finally, if manet routes between mobile routers are established, mobile routers can communicate without reaching to the home agent. If the NEMO addressing approach is selected, None of the issues are solved, because the MANEMO activity is begun on the assumption of the NEMO addressing approach. One thing we have to discuss here is the movement pattern. There are two movement patterns in MANEMO, mobile router's alone movement and grouped movement. For the mobile router's alone movement, a mobile router just leaves its MANEMO and goes somewhere. Therefore, this movement pattern is similar to what MANET is addressing (ex. random- way point). On the other hand, the grouped mobility is very NEMO specific movement pattern. When considering the use case such as passenger's PAN enters in the train, all the mobile routers move all together. We discuss the grouped mobility in further section. Figure 14 shows an example of MANEMO topology. The arrows of the left side of Figure 14 shows the extent of the impact when MR1 changes its attachment from AR1 to AR2 with grouped mobility pattern. If the NEMO approach is used, the impact of MR1 change is hidden by Wakikawa, et al. Expires January 2, 2008 [Page 18] Internet-Draft MANEMO Architecture July 2007 MR1. In the AUTOCONF approach, the impact is propagated to entire mobile routers that are located behind MR1. What the NEMO Basic Support guarantees is movement transparency of a mobile router. Thus, even if MR1 changes its point of attachment, this change is perfectly hidden from MR2, MR3 and MR4. Even if MR1 changes its attachment, the topology relationship among MR1 , MR2, MR3 and MR4 is not changed. This movement transparency should be supported also in nested NEMO formation because this is essential feature of the NEMO Basic Support protocol. In the AUTOCONF and the MANET approach, this feature is missed due to the AUTOCONF addressing assignment. A mobile router obtains an address not from the upper mobile network, but directly from the access router. If MR1 changes its attachment to MR2, all the mobile routers behind MR1 (MR2, MR3 and MR4) are affected by the change of MR1. MR2, MR3 and MR4 should obtain a new address from AR2 after MR1 changes its attachment to AR2. Access Networks | | +-+-+ +-+-+ |AR1| |AR2| +-+-+ +-+-+ | ---> : NEMO AUTOCONF |..................: /|\ /|\ +-+-+ \|/ | |MR1| | +-+-+ | | | -----+----- | | | +-+-+ | |MR2| | +-+-+ | | | -+------+------+- | | | | +-+-+ +-+-+ | |MR3| |MR4| | +-+-+ +-+-+ | | | \|/ -----+----- -----+----- Figure 14: Extent of the Impact from MR1 movement Wakikawa, et al. Expires January 2, 2008 [Page 19] Internet-Draft MANEMO Architecture July 2007 5. Solution Guideline This section classifies existing and proposed solutions for the MANEMO scenarios. We isolated 2 families: 1. Nested NEMO Route Optimization (NEMO centric approach): This is the initial root problem of MANEMO. NEMO mobile routers attach to one another, and MANEMO should optimize the resulting topology for access to the infrastructure, provide a safe model for mobile routers to help one another, some degree of inner routing etc. As shown in Section 4.1, the topology of Nested NEMO becomes tree. For this approach, Tree Discovery [11] has been proposed to form a loop-free tree in MANEMO and NINA [12] provides some routing in that space. Reverse Routing Header (RRH) [13] is a solution how to bypass the number of home agents when mobile routers form the nested NEMO. 2. Mobile ad hoc (MANET centric): This is when NEMO mobile routers form a MANET. We found 3 categories: 1. "1 hop away" A mobile router only discovers a neighbor mobile router(s) and communicate with them directly. The example use case is the car 2 car. NANO [14] provides a very simple solution. 2. "2 hops away" This is where the NHDP [15] could be inserted, still no use of a real routing protocol. A mobile router manages routes for 2-hop neighbor mobile routers. 3. "General MANET" In this case, we need a routing protocol of the MANET family. MANEMO could still help in several fashion, for instance provide scalability by splitting the larger network in a number of more manageable islands, interconnected by NEMO over the infrastructure. Wakikawa, et al. Expires January 2, 2008 [Page 20] Internet-Draft MANEMO Architecture July 2007 6. IANA considerations This document does not require any IANA action. Wakikawa, et al. Expires January 2, 2008 [Page 21] Internet-Draft MANEMO Architecture July 2007 7. Security Considerations This document is a architecture model 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 2, 2008 [Page 22] Internet-Draft MANEMO Architecture July 2007 8. Acknowledgments We would like to thank Teco Boot, Jim Bound, Jari Arkko and Lim Hyung Jin for their comments on this document. We would also like to thank all the people involved in MANEMO activity. 9. References 9.1. Normative reference [1] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. 9.2. Informative Reference [6] Ng, C., "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03 (work in progress), September 2006. [7] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route Optimisation Problem Statement", draft-clausen-nemo-ro-problem-statement-00 (work in progress), October 2004. [8] Thaler, D., "Multilink Subnet Issues", draft-iab-multilink-subnet-issues (work in progress), January 2007. [9] Chakeres, I., "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-01 (work in progress), March 2007. [10] Wakikawa, R., "MANEMO Problem Statement", Wakikawa, et al. Expires January 2, 2008 [Page 23] Internet-Draft MANEMO Architecture July 2007 draft-wakikawa-manemo-problem-statement-00 (work in progress), February 2007. [11] Thubert, P., "Nested Nemo Tree Discovery", draft-thubert-tree-discovery-04 (work in progress), November 2006. [12] Thubert, P., "Network In Node Advertisement", draft-thubert-nina-00 (work in progress), February 2007. [13] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its application to Mobile Networks", draft-thubert-nemo-reverse-routing-header-06 (work in progress), September 2006. [14] Petrescu, A. and C. Janneteau, "The NANO Draft (Scene Scenario for Mobile Routers and MNP in RA)", draft-petrescu-manemo-nano-00 (work in progress), March 2007. [15] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-00 (work in progress), June 2006. Wakikawa, et al. Expires January 2, 2008 [Page 24] Internet-Draft MANEMO Architecture July 2007 Authors' Addresses Wakikawa Ryuji Keio University 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/ Thomas Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org 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/ Alexandru Petrescu Motorola Labs Parc les Algorithmes Saint Aubin Gif-sur-Yvette 91193 France Email: Alexandru.Petrescu@motorola.com Wakikawa, et al. Expires January 2, 2008 [Page 25] Internet-Draft MANEMO Architecture 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 2, 2008 [Page 26]