No Working Group R. Wakikawa Internet-Draft Keio University Expires: December 3, 2007 T. Clausen LIX, Ecole Polytechnique June 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 December 3, 2007. Copyright Notice Copyright (C) The Internet Society (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 Wakikawa & Clausen Expires December 3, 2007 [Page 1] Internet-Draft MANEMO Architecture June 2007 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 . . . . . . . . . . . . . . . . 8 4. Addressing Architecture of MANEMO . . . . . . . . . . . . . . 11 4.1. NEMO Addressing Approach (MANEMO Architecture) . . . . . . 11 4.2. AUTOCONF Approach (MANET Architecture) . . . . . . . . . . 14 4.3. Comaprison of Two approaches . . . . . . . . . . . . . . . 17 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Normative reference . . . . . . . . . . . . . . . . . . . 21 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 Appendix A. Change Log From Previous Version . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Wakikawa & Clausen Expires December 3, 2007 [Page 2] Internet-Draft MANEMO Architecture June 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, un-optimized path and multiple exit routers to the Internet. 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 un-optimized path 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. In 2004, we set up the MANEMO mailing list and started discussion. Finally, we had unofficial BOF at IETF 68 in Prague. We introduced MANEMO in several working groups such as MANET, AUTOCONF, NEMO. We also had two BOFs discussion general MANEMO problems and existing solutions spaces. Unfortunately, MANEMO is still not yet clearly defined and understood by IETF community. MANEMO maybe just another configuration of MANET/AUTOCONF. The answer is still not clear, yes and no. It depends on how you can see this MANEMO world in terms of addressing, wireless technology, topology formation, etc. You may approach the MANEMO problem with existing solutions. However, existing solutions cannot cover whole idea of MANEMO. We believe there are also missing pieces for MANEMO in IETF. What are the missing pieces? This document describes first the whole idea of the NEMO Basic Support. Then, possible MANEMO topologies are given. MANEMO addressing scheme is then considered. It helps people's understanding of what is MANEMO, relationship with existing activity. Wakikawa & Clausen Expires December 3, 2007 [Page 3] Internet-Draft MANEMO Architecture June 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 & Clausen Expires December 3, 2007 [Page 4] Internet-Draft MANEMO Architecture June 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 delegated mobile network prefix from the mobile router. It can advertise route advertisements in the mobile network-FR in Figure 1. The fixed router may run a routing protocol or have static routes of mobile network prefixes in the mobile network. Access Network | <-egress interface(s) +-+-+ |MR | Mobile Router +-+-+ | <-ingress interface(s) ------+------+----- Mobile Network/48 | +-+-+ |FR | Fixed Router +-+-+ | ------+------ Mobile Network-FR/64 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] Wakikawa & Clausen Expires December 3, 2007 [Page 5] Internet-Draft MANEMO Architecture June 2007 Access Network Access Network | | +-+-+ +-+-+ |AR | |AR | +-+-+ +-+-+ | | +-+-+ +-+-+ |MR | |MR1| +-+-+ +-+-+ | | -+---+---+- -----+---+- | | | +-+-+ +-+-+ +-+-+ |MN1| |MN2| |MR2| +---+ +---+ +-+-+ : a) : +-+-+ |MRn| +-+-+ | b) Figure 3: Nested NEMO Configuration Wakikawa & Clausen Expires December 3, 2007 [Page 6] Internet-Draft MANEMO Architecture June 2007 3. MANEMO Topologies The NEMO Basic Support protocol introduces two different interfaces on a mobile router such as the engress 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. Engress and Ingress (E-I) attachment 2. Engress and Engress (E-E) attachment 3. *Ingress and Ingress (I-I) attachment *I-I is technically possible, but MANEMO does not consider this case. The reasons are given later in this section. 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. |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. Wakikawa & Clausen Expires December 3, 2007 [Page 7] Internet-Draft MANEMO Architecture June 2007 Figure 5 shows the two (E-E and I-I) scenarios. The E-E attachment is the case when a mobile router uses adhoc 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. 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. Wakikawa & Clausen Expires December 3, 2007 [Page 8] Internet-Draft MANEMO Architecture June 2007 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 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) Wakikawa & Clausen Expires December 3, 2007 [Page 9] Internet-Draft MANEMO Architecture June 2007 Figure 7: Use of Fixed Routers Wakikawa & Clausen Expires December 3, 2007 [Page 10] Internet-Draft MANEMO Architecture June 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), In this case, the mobile router (MR1) owns the mobile network prefix (MNP1::/48) and divides it and assigns it to a fixed router (FR1). A mobile network node is attached to a link of FR1 (MNP1:1::/64) and Wakikawa & Clausen Expires December 3, 2007 [Page 11] Internet-Draft MANEMO Architecture June 2007 maybe not to a link of MR1 (MNP1::/48). MNP1:1::/64 is delegated to FR1 by MR1. MR1 and FR1 can run any IGP or can have static routes of each assigned prefix. In this example, MR1 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 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. Wakikawa & Clausen Expires December 3, 2007 [Page 12] Internet-Draft MANEMO Architecture June 2007 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, while the mobile router acquires its care-of address from the upper router (ex. AR for MR1, MR1 for MR2). 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 & Clausen Expires December 3, 2007 [Page 13] Internet-Draft MANEMO Architecture June 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 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 & Clausen Expires December 3, 2007 [Page 14] Internet-Draft MANEMO Architecture June 2007 assigned to the manet interface must be unique as stated in [9]. Although the link-local address 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. Therefore, the access router should manage the several prefixes and assigns individual prefix to every mobile router. The mobile router uses the address generated from the assigned prefix 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, since a mobile router does not advertise its mobile network prefix to the egress interface. Access Network | +-+-+ |AR | ANP::/48 +-+-+ | +----- ANP:1::MR1 e| | +-+-+ \ |MR1| | +-+-+ \ i| \ -----+---- __| / e|ANP:2::MR2 _____/ +-+-+ / |MR2| / +-+-+ | i| | ----+----- ANP:3::MR3 e| +-+-+ |MR3| +-+-+ i| -----+------ 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:2::MR2), 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 on its egress interface. Thus, a mobile router may obtain two different addresses such as one from the access Wakikawa & Clausen Expires December 3, 2007 [Page 15] Internet-Draft MANEMO Architecture June 2007 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 select the address assigned by the access router as a care-of address and registers it to the home agent. To do 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 +-+-+ | e|ANP:1::MR1 +-+-+ |MR1| +-+-+ i| MNP1::/64 ------+------ |(MNP1::MR2) e|ANP:2::MR2 +-+-+ |MR2| +-+-+ i| -----+----- 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 Wakikawa & Clausen Expires December 3, 2007 [Page 16] Internet-Draft MANEMO Architecture June 2007 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 prefix (ANP:2::/64) unless the route of MR2's assigned prefix is installed in FR1. Access Network | +-+-+ |AR | ANP::/48 +-+-+ | e|ANP:1::MR1 +-+-+ |MR1| +-+-+ i| MNP1::/48 ------+------ | +-+-+ |FR1| <-- it should have routes of ANP::1::/4 +-+-+ and ANP:2::/64!? i'|MNP1:1::/6 -----+------ |(MNP1:1::MR2) e|ANP:2::MR2 <-- how?? +-+-+ |MR2| +-+-+ i| -----+------ Figure 13: AUTOCONF Addressing Assignment when Fixed Router is employed 4.3. Comaprison of Two approaches Before discussing the two approaches, the known MANEMO problems [10] are listed here. o Unoptimized Path o Network Loop Wakikawa & Clausen Expires December 3, 2007 [Page 17] Internet-Draft MANEMO Architecture June 2007 o Multiple Exit Routers If the AUTOCONF approach is taken, every mobile router is 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 unoptimized path 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, unoptimized path is 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 . 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. However, one thing we have to discuss here is the movement pattern. 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. If the NEMO approach is used, the impact of MR1 change is hidden by 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. Wakikawa & Clausen Expires December 3, 2007 [Page 18] Internet-Draft MANEMO Architecture June 2007 Access Networks | | +-+-+ +-+-+ |AR1| |AR2| +-+-+ +-+-+ | ---> : NEMO AUTOCONF |..................: /|\ /|\ +-+-+ \|/ | |MR1| | +-+-+ | | | -----+----- | | | +-+-+ | |MR2| | +-+-+ | | | -+------+------+- | | | | +-+-+ +-+-+ | |MR3| |MR4| | +-+-+ +-+-+ | | | \|/ -----+----- -----+----- Figure 14: Extent of the Impact from MR1 movement Wakikawa & Clausen Expires December 3, 2007 [Page 19] Internet-Draft MANEMO Architecture June 2007 5. IANA considerations This document does not require any IANA action. Wakikawa & Clausen Expires December 3, 2007 [Page 20] Internet-Draft MANEMO Architecture June 2007 6. 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. 7. References 7.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. 7.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 & Clausen Expires December 3, 2007 [Page 21] Internet-Draft MANEMO Architecture June 2007 draft-wakikawa-manemo-problem-statement-00 (work in progress), February 2007. Wakikawa & Clausen Expires December 3, 2007 [Page 22] Internet-Draft MANEMO Architecture June 2007 Appendix A. Change Log From Previous Version o Initial Documentation Wakikawa & Clausen Expires December 3, 2007 [Page 23] Internet-Draft MANEMO Architecture June 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 Wakikawa & Clausen Expires December 3, 2007 [Page 24] Internet-Draft MANEMO Architecture June 2007 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Wakikawa & Clausen Expires December 3, 2007 [Page 25]