idnits 2.17.1 draft-wakikawa-manemoarch-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 973. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 997. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 521: '... router, it MUST NOT tunnel the pack...' RFC 2119 keyword, line 522: '...ile network prefix, the packet MUST be...' RFC 2119 keyword, line 578: '...ch mobile router MUST obtain at least ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2007) is 6142 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '1') ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') ** Obsolete normative reference: RFC 2462 (ref. '5') (Obsoleted by RFC 4862) == Outdated reference: A later version (-01) exists of draft-clausen-nemo-ro-problem-statement-00 == Outdated reference: A later version (-07) exists of draft-ietf-autoconf-manetarch-01 == Outdated reference: A later version (-01) exists of draft-wakikawa-manemo-problem-statement-00 == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-04 == Outdated reference: A later version (-03) exists of draft-thubert-nina-00 == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-06 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-00 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 No Working Group R. Wakikawa 3 Internet-Draft Keio University 4 Expires: January 2, 2008 T. Clausen 5 LIX, Ecole Polytechnique 6 B. McCarthy 7 Lancaster University 8 A. Petrescu 9 Motorola Labs 10 July 1, 2007 12 MANEMO Topology and Addressing Architecture 13 draft-wakikawa-manemoarch-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 2, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document outlines the MANEMO architecture including possible 47 topology configuration and addressing assignment. The issues of 48 MANEMO (previously known as nested NEMO) are already summarized in 49 several documents. However, there are several ways how to comprehend 50 what is MANEMO. The MANEMO problems are related to several existing 51 working groups. This document provides the MANEMO architecture model 52 and differences of existing solutions so that IETF can classify the 53 problems and start working on the solutions. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. What is Network Mobility (NEMO) Basic Support . . . . . . . . 4 61 3. MANEMO Topologies . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1. MANEMO Basic Topologies . . . . . . . . . . . . . . . . . 7 63 3.2. MANEMO Advanced Topologies . . . . . . . . . . . . . . . . 9 65 4. Addressing Architecture of MANEMO . . . . . . . . . . . . . . 11 66 4.1. NEMO Addressing Approach (MANEMO Architecture) . . . . . . 11 67 4.2. AUTOCONF Approach (MANET Architecture) . . . . . . . . . . 14 68 4.3. Comparison of Two Approaches . . . . . . . . . . . . . . . 18 70 5. Solution Guideline . . . . . . . . . . . . . . . . . . . . . . 20 72 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 79 9.1. Normative reference . . . . . . . . . . . . . . . . . . . 23 80 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 23 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 83 Intellectual Property and Copyright Statements . . . . . . . . . . 26 85 1. Introduction 87 When mobile routers and mobile nodes converge at the edge of the 88 Internet using wireless interfaces, they can form a wireless network 89 cloud and are able to provide Internet connectivity to one another. 90 This type of network is called a MANEMO Fringe Stub (MFS). Several 91 issues exist in the MFS such as network loop, sub-optimal route, 92 redundant tunnels, multiple exit routers selection, and HA dependency 93 of the NEMO Basic Support. While fixed routers provide connectivity 94 constantly, mobile routers can experience intermittent connectivity 95 to the Internet due to their movement. When the NEMO Basic Support 96 is used in this context, network loops naturally occur. NEMO forces 97 the packets to always travel through the home agent, which in turn 98 causes an sub-optimal route that can become a considerable problem 99 when mobile routers form a nested topology. Different types of 100 routers are able to provide Internet connectivity in the MFS, 101 including both mobile routers and fixed access routers. Any node 102 requiring Internet connectivity has to select the best exit router 103 toward the Internet, therefore it is necessary for mobile nodes to 104 maintain a local topology in the MFS and to utilize any available 105 connectivity with a degree of Intelligence. Unfortunately, MANEMO is 106 still not yet clearly defined and understood by IETF community, this 107 draft attempts to address that problem by identifying the topologies 108 that arise with MANEMO and analyzing their requirements. 110 It is still uncertain whether MANEMO configurations can be suitably 111 supported by MANET/AUTOCONF approaches. In order to determine 112 whether the MANEMO problem can be addressed by existing solutions, we 113 must analyze the expected topology formations, wireless technologies, 114 addressing, etc. We believe there are also missing pieces for MANEMO 115 in IETF. This draft is aimed at helping identify what are those 116 missing pieces. This document describes first the whole idea of the 117 NEMO Basic Support. Then, possible MANEMO topologies are given. 118 Finally we consider a typical MANEMO addressing scheme. We feel that 119 analyzing the problem area in this detail can help the reader's 120 understanding of what MANEMO is and its relationship with existing 121 activity. 123 2. What is Network Mobility (NEMO) Basic Support 125 This section provides brief explanation of Network Mobility Basic 126 Support protocol. If readers are familiar with RFC3753 [1], RFC3775 127 [2], RFC3963 [3], draft-ietf-nemo-ro-problem-statement [6], please 128 skip this section. 130 A mobile network is defined in RFC3753 [1], "An entire network, 131 moving as a unit, which dynamically changes its point of attachment 132 to the Internet and thus its reachability in the topology. The 133 mobile network is composed of one or more IP-subnets and is connected 134 to the global Internet via one or more Mobile Routers (MR). The 135 internal configuration of the mobile network is assumed to be 136 relatively stable with respect to the MR.". A mobile network is seen 137 as just IPv6 subnet by any nodes except for Mobile Routers. 138 According to RFC3963, Figure 1 is the common interpretation of a 139 mobile router. Each Mobile Router has an egress interface(s) to 140 reach the home agent through the Internet and also an ingress 141 interface(s) attaching to the Mobile Network. A mobile router 142 obtains its care-of address at the egress interface and establishes a 143 bi-directional tunnel to the home agent. It routes all the packets 144 intercepted at the ingress interface to the bi-directional tunnel. 145 The packet's source address must belong to the mobile network prefix. 146 Only the packets sent to and from a mobile network are routed to the 147 tunnel by the mobile router. 149 Access Network 150 | 151 +-+-+ 152 |AR | 153 +-+-+ 154 | <-egress interface(s) 155 +-+-+ 156 |MR1| 157 +-+-+ 158 | <-ingress interface(s) 159 -+-+-+-+-+- Mobile Network 160 | | | | | 161 H H H H H Mobile Network Nodes (MNNs) 163 Figure 1: Mobile Router Configuration 165 Some known remarks from this NEMO Basic Support are: 167 o Unless a node (host or router) is connected to a mobile network, 168 NEMO guarantees the session continuity to the node. 170 o Any nodes attached to the mobile network are unaware of the mobile 171 router's changing attachment point. The mobile network can be 172 seen as just an IPv6 network. 174 o An access router at the visiting network is not aware of a mobile 175 network existence behind a mobile router. 177 According to draft-ietf-nemo-terminology [4], several different 178 entities can be attached to the mobile network such as Fixed Router 179 in a mobile network and Mobile Network Node including Local Fixed 180 Node, Visiting Mobile Node and Local Mobile Node. In Figure 2, an 181 IPv6 router called Fixed Router is deployed in a mobile network. The 182 fixed router has a dedicated mobile network prefix. The dedicated 183 prefix can be delegated from the mobile network prefix of its mobile 184 router like Figure 2-a. The mobile router sends a binding update for 185 the aggregated mobile network prefix (2001:1::/48). Alternatively, 186 it can be configured with non-aggregated prefix as shown in 187 Figure 2-b. The mobile router sends a binding update containing two 188 mobile network prefix options for both mobile network prefixes (2001: 189 a::/64 and 2001:b::/64). 191 The Fixed Router sends ICMP route advertisements, in order to reach 192 other nodes in the moving network it needs to have routes installed, 193 and this can be achieved by static routes or by running a routing 194 protocol. The Mobile Router has to have a route towards the mobile 195 network prefix owned by the Fixed Router through Fixed Router's IP 196 address. That route can be manually installed, manually configured 197 in a routing protocol configuration file, or dynamically delegated 198 with DHCP Prefix Delegation. 200 Access Network Access Network 201 | <--- egress interface(s) ---> | 202 +-+-+ +-+-+ 203 |MR | Mobile Router |MR | 204 +-+-+ +-+-+ 205 | <-- ingress interface(s) --> | 206 ------+------+----- ------+------+----- 207 Mobile Network/48 | Mobile Network/64 | 208 2001:1::/48 +-+-+ 2001:a::/64 +-+-+ 209 |FR | |FR | 210 +-+-+ <-- Fixed Router --> +-+-+ 211 | | 212 ------+------ ------+------ 213 Mobile Network-FR/64 Mobile Network-FR/64 214 2001:1:1::/64 2001:b::/64 215 a) b) 217 Figure 2: Mobile Router Configuration with Fixed Router 219 When a visiting mobile node is attached to a mobile network, we call 220 this network formation as nested NEMO. Figure 3 shows the two cases 221 where either a mobile node or a mobile router is attached to a mobile 222 network. Specially, if a visiting mobile node is a mobile router, 223 the number of nested level goes longer (Figure 3-b)). Several issues 224 are raised when Nested NEMO is occurred. The nested NEMO issues are 225 already introduced in several documents [6], [7] 227 Access Network Access Network 228 | | 229 +-+-+ +-+-+ 230 |AR | |AR | 231 +-+-+ +-+-+ 232 | | 233 +-+-+ +-+-+ 234 |MR | |MR1| 235 +-+-+ +-+-+ 236 | | 237 -+---+---+- -----+---+- 238 | | | 239 +-+-+ +-+-+ +-+-+ 240 |MN1| |MN2| |MR2| 241 +---+ +---+ +-+-+ 242 : 243 a) : 244 +-+-+ 245 |MRn| 246 +-+-+ 247 | 249 b) 251 Figure 3: Nested NEMO Configuration 253 3. MANEMO Topologies 255 The NEMO Basic Support protocol introduces two different interfaces 256 on a mobile router known as the egress interface and the ingress 257 interface. In MANEMO, several topologies can be expected by 258 attachment combination of these two interfaces. 260 3.1. MANEMO Basic Topologies 262 When considering MANEMO, following topology can be logically 263 possible. 265 1. Egress and Ingress (E-I) attachment 267 2. Egress and Egress (E-E) attachment 269 3. *Ingress and Ingress (I-I) attachment 271 4. **Egress/Ingress and Egress/Ingress (EI-EI) attachment 273 [*MANEMO does not consider this case. The reasons are given later in 274 this section.] 276 [**EI-EI is another configuration of E-E attachment. While the NEMO 277 Basic Support does not assume using single interface for both egress 278 and ingress, MANEMO consider this special configuration, too. See 279 Section 3.2 for details.] 281 The E-I attachment is the most common configuration of the NEMO Basic 282 Support. A mobile router connects to the other mobile routers' 283 mobile network by its egress interface. Figure 4 shows the example 284 topology. (e) and (i) in all the figures in this section indicate 285 egress and ingress interfaces. 287 |e |e 288 +-----+ +-----+ 289 | MR | | MR | 290 +-----+ +-----+ 291 |i |i 292 | +---------+ 293 |e | |e 294 +-----+ +-----+ +-----+ 295 | MR | | MR | | MR | 296 +-----+ +-----+ +-----+ 297 |i |i 298 | | 299 |e |e 300 +-----+ +-----+ 301 | MR | | MR | 302 +-----+ +-----+ 303 |i |i 305 Figure 4: Egress-Ingress (E-I) attachments. 307 Figure 5 shows the two (E-E and I-I) scenarios. The E-E attachment 308 is the case when a mobile router uses ad-hoc type of interfaces such 309 as 802.11b ad-hoc mode or 802.11s as its egress interface. Each 310 mobile router connects with egress interface. In MANEMO, this 311 scenario is also considered for inter vehicle networks, etc. (see 312 ref). On the other hand, although the ingress and ingress attachment 313 is logically possible, it is slightly unrealistic. First of all, 314 when ingress interfaces of different mobile routers are connected , 315 two different mobile networks are merged in the single mobile 316 network. A mobile network node will obtain multiple IP addresses 317 from different mobile routers. For instance, in Figure 5, a mobile 318 network node of MR1 obtains an address of mobile network prefixes of 319 all the mobile routers (MR1, MR2 and MR3). Whenever a mobile router 320 leaves, the addresses of the entire mobile network node generated 321 from the mobile network prefix of leaved mobile router will go 322 unreachable. This configuration may break the fundamental features 323 of the NEMO Basic Support protocol (lack of movement transparency). 324 Thus, we do not consider I-I attachment scenario in MANEMO. 326 e+-----+i e+-----+i 327 +--| MR |-- --| MR1 |--+ 328 | +-----+ +-----+ | 329 | | 330 | e+-----+i e+-----+i | 331 +--| MR |-- --| MR2 |--+ 332 | +-----+ +-----+ | 333 | | 334 | e+-----+i e+-----+i | 335 +--| MR |-- --| MR3 |--+ 336 +-----+ +-----+ 338 Figure 5: E-E and I-I Attachment 340 3.2. MANEMO Advanced Topologies 342 In MANEMO, the different scenarios from the basic topologies are also 343 considered. First, a mobile router only equips with single wireless 344 interfaces and utilizes it conceptually as both egress and ingress 345 interface. In the NEMO Basic Support, a mobile router is assumed to 346 have physically two different interfaces. However, in this context, 347 the ingress and egress interfaces are roles over the same physical 348 interface. A mobile router exposes its mobile network prefix to the 349 interface and also obtains a care-of address at the same interface 350 (named EI-EI attachment). Figure 6 shows the example topology. 352 e/i+-----+ 353 +---| MR | 354 | +-----+ 355 | 356 |e/i+-----+ 357 +---| MR | 358 | +-----+ 359 | 360 |e/i+-----+ 361 +---| MR | 362 +-----+ 364 Figure 6: EI-EI attachment 366 Another scenario is that a mobile router has a fixed router(s) in its 367 mobile network so that another visiting mobile router (a mobile 368 network node) connects to the mobile network through the fixed 369 router. Figure 7 gives two examples. There are several links where 370 a mobile network node can attach. In Figure 7-b), a mobile router 371 attaches to the link between the mobile router (MR) and the fixed 372 router (FR). This topology is possible only if a mobile router 373 allows mobile network nodes to attach to this link. It totally 374 depends on the admission control of each mobile network. When 375 deploying the NEMO Basic Support protocol, it is necessary to 376 consider this fixed router availability in a mobile network. 378 ......|...... 379 : |e : |e 380 : +-----+ : +-----+ 381 : | MR | : | MR | 382 : +-----+ : +-----+ 383 : |i : |i 384 : | : +---------+ 385 : | : | | 386 : +-----+ : +-----+ +-----+ 387 : | FR | : | MR | | FR | 388 : +-----+ : +-----+ +-----+ 389 : |i : | 390 :.....|...... | 391 |e |e 392 +-----+ +-----+ 393 | MR | | MR | 394 +-----+ +-----+ 395 |i |i 396 a) b) 398 Figure 7: Use of Fixed Routers 400 4. Addressing Architecture of MANEMO 402 After the formation of the Nested NEMO, the argument is how to assign 403 an address to each mobile node and mobile router. There are two 404 different approaches today in IETF, 1) NEMO addressing approach and 405 2) AUTOCONF addressing approach. This section briefly explains the 406 two approaches and discusses their pros and cons. 408 4.1. NEMO Addressing Approach (MANEMO Architecture) 410 According to the NEMO Basic Support, an attached node to a mobile 411 network will get an address from the mobile network. Figure 8 gives 412 the simplest case. MR1 obtains an IP address (ANP::MR1 as CoA) from 413 the access router that advertised prefix is ANP::/64. The MR2 414 attached to a mobile network of MR1 generates its CoA from the 415 MNP1::/64. This is what the NEMO basic support is assumed in the 416 protocol design. (e) and (i) in all the figures in this section 417 indicate egress and ingress interfaces, too. 419 Access Network 420 | 421 +-+-+ 422 |AR | 423 +-+-+ 424 | 425 ------+------ ANP::/64 426 e| ANP::MR1 427 +-+-+ 428 |MR1| 429 +-+-+ 430 i| 431 ------+------ MNP1::/64 432 e| MNP1::MR2 433 +-+-+ 434 |MR2| 435 +-+-+ 436 i| 437 -----+------ MNP2::/64 439 Figure 8: NEMO Address Assignment for E-I attachment 441 Alternatively, Figure 9 gives another address assignment when a 442 mobile network is formed with a mobile router and a fixed router(s). 443 As discussed with Figure 2, two possible prefix assignment to the 444 fixed router is considered, (1) the mobile network prefix can be 445 divided into sub-prefixes that can be aggregated and one of the sub- 446 prefixes can be assigned to a Fixed Router, (2) the mobile network 447 prefix and the Fixed Router's prefix can be totally different and not 448 necessarily aggregated. In both cases it's the administrator who 449 decides this addressing architecture, it is not the mobile router who 450 divides and assigns. In this Figure, the mobile router (MR1) owns 451 the mobile network prefix (MNP1::/48) and assigns sub-prefixes of the 452 mobile network to a fixed router (FR1). A mobile network node is 453 attached to a link of FR1 (MNP1:1::/64) and maybe not to a link of 454 MR1 (MNP1::/48). If a node is attached to the link of MR1, it turns 455 to the same configuration of Figure 8. In this example, MR2 is 456 attached to a link of FR1 and acquires the MNP1:1::MR2 address as its 457 CoA. 459 Access Network 460 | 461 +-+-+ 462 |AR | 463 +-+-+ 464 | 465 ------+------ ANP::/64 466 e| ANP::MR1 467 +-+-+ 468 |MR1| 469 +-+-+ 470 i| 471 ------+------ MNP1::/48 472 | 473 +-+-+ 474 |FR1| 475 +-+-+ 476 i'| 477 -----+------ MNP1:1::/64 478 e| MNP1:1::MR2 479 +-+-+ 480 |MR2| 481 +-+-+ 482 i| 483 -----+------ MNP2::/64 485 Figure 9: NEMO Address Assignment when Fixed Router is employed 487 According to Section 3, the other possible topology of the nested 488 NEMO are E-E and EI-EI attachments described in Figure 10. The 489 egress interface of each MR is connected in ad-hoc fashion by using 490 802.11b in ad-hoc mode. This is not originally assumed in the NEMO 491 Basic Support Protocol. Figure 10 is just an example which was 492 discussed in the MANEMO mailing list. In this case, MR reveals its 493 mobile network prefix to its egress interface so that the attached MR 494 (MR2 for MR1) can obtain an IPv6 address (MNP1::MR2) from the upper 495 Mobile Router. The definition of egress interface is extended to 496 support some role of ingress interface. As shown in , two possible 497 scenarios can be given whether the mobile router has its physically 498 available ingress interface or not. 500 In the Scenario-1 (E-E attachment), each mobile router owns its 501 physically available ingress interface. Therefore, the mobile 502 network prefix is advertised to both ingress interface and egress 503 interface by using ICMP Router Advertisement, while the mobile router 504 acquires its care-of address from the upper router (ex. AR for MR1, 505 MR1 for MR2). Note that the NEMO Basic Support does not allow for a 506 mobile router to send ICMP router advertisements for its own mobile 507 network prefix from the egress interface. The mobile router must 508 support bridge functionality between the ingress interface and egress 509 interface. MNN1 (MNP1::MNN) and MR2's egress interface (MNP1::MR2) 510 must be located at the same link, otherwise the multilink subnet 511 issue [8] is occurred. However, this bridge functionality is not 512 currently supported by the NEMO Basic Support protocol. 514 On the other hand, the scenario-2 is simpler than the the scenario-1. 515 A mobile router does not necessarily support the bridge functionality 516 because it does not have an ingress interface. The mobile router 517 uses a single interface as an egress and ingress interfaces. A 518 mobile router must check the source address of all the packets to 519 decide whether the packets should be routed to the bi-directional 520 tunnel or not. In the packet's source address is the CoA of a mobile 521 router, it MUST NOT tunnel the packet. But the source address of a 522 packet is an address of its mobile network prefix, the packet MUST be 523 tunneled to the home agent. Again, this configuration is also not 524 considered by the NEMO Basic Support protocol and needs some 525 modifications to the NEMO Basic Support protocol. 527 Scenario-1(E-E attachment) Scenario-2 (EI-EI attachment) 529 Access Network Access Network 530 | | 531 +-+-+ +-+-+ 532 |AR | ANP::/64 |AR | ANP::/64 533 +-+-+ +-+-+ 534 | | 535 ------+------ ANP::/64 ------+------ ANP::/64 536 | | 537 ANP::MR1 e+---- ANP::MR1 ei +----- 538 +-+-+ \ +-+-+ \ 539 |MR1| \ |MR1| \ 540 +-+-+ \ +---+ \ 541 i| \ __| 542 -+----+---- __| /ei|MNP1::MR2 543 | / e|MNP1::MR2 ______/ +-+-+ 544 MNN1 ______/ +-+-+ / |MR2| 545 MNP1::MNN / |MR2| / +---+ 546 / +-+-+ | 547 | i| ei|MNP2::MR3 548 | ----+-+-+- +-+-+ 549 | | | |MR3| 550 e|MNP2::MR3 MNN MNN +---+ 551 +-+-+ (MNP2::MNNi) 552 |MR3| 553 +-+-+ 554 i| 555 -+-+-+-+-+-- 556 | | | | | 557 MNNs (MNP3::MNNi) 559 Figure 10: NEMO Address Assignment for E-E and EI-EI attachments 561 4.2. AUTOCONF Approach (MANET Architecture) 563 The Ad-hoc Network Autoconfiguration (AUTOCONF) working group 564 summarizes the MANET Architecture in [9]. This section gives brief 565 explanation how to apply the MANET architecture to the nested NEMO 566 topology. Figure 11 shows the case where each mobile router is 567 connected by its egress interface in ad-hoc fashion. This scenario 568 is very similar to what MANET is expected. Each mobile router 569 obtains an IPv6 address on its egress interface from the access 570 router called internet gateway in the MANET community. Thus, each 571 mobile router, at the end, obtains an address derived from the access 572 router's prefix (ANP::/64). Note that the egress interface can be 573 treated as a manet interface in this case. Thus, the address 574 assigned to the manet interface must be unique as stated in [9]. [9] 575 suggests link-local addresses, IPv6 address/128, and unique prefix/n 576 (n < 128) per a manet interface. Although the link-local address 577 (LL-MRn-e/128) can be used for the MANET purpose at the manet 578 interface, each mobile router MUST obtain at least one global address 579 for sending a binding update. We will not discuss the use of link 580 local address in further section. Either ANP::MRn/128 or ANP:n:: 581 MRn/64 can be possible for the address on the egress interface (i.e. 582 manet interface) as shown in Figure 11. When each mobile router 583 obtains a unique prefix from the access router, the access router 584 should manage the several prefixes in order to assign individual 585 prefix to every mobile router. 587 The mobile router uses the address (ANP::MRn/128 or ANP:n::MRn/64 in 588 Figure 11) as a care-of address and registers its binding to the home 589 agent. Note that in AUTCONF approach, E-E and EI-EI attachments can 590 be treated as a same, because a mobile router does not advertise its 591 mobile network prefix to the egress interface. Each mobile router 592 only obtains an IPv6 address from access router and not from 593 neighbors (other mobile routers). 595 Access Network 596 | 597 +-+-+ 598 |AR | ANP::/64 or /48 599 +-+-+ 600 | 601 +----- 602 ANP::MR1/128 or --> |e | 603 ANP:1::MR1/64 or +-+-+ \ 604 LL-MR1-e/128 |MR1| | 605 +-+-+ \ 606 i| \ 607 -----+---- __| 608 / e| <-- ANP::MR2/128 or 609 _____/ +-+-+ ANP:2::MR2/64 or 610 / |MR2| LL-MR2-e/128 611 / +-+-+ 612 | i| 613 | ----+----- 614 e|<-- ANP::MR3/128 or 615 +-+-+ ANP:3::MR3/64 or 616 |MR3| LL-MR3-e/128 617 +-+-+ 618 i| 619 -----+------ 621 Figure 11: AUTOCONF addressing assignment for E-E attachment 623 Figure 12 shows the AUTOCONF model when mobile routers are formed in 624 the E-I attachment. According to the MANET architecture [9], MR2 in 625 Figure 12 can obtain an address from the access router (ANP::MR2/128 626 or ANP:2::MR2/64), even in this configuration. Alternatively, MR2 627 can run the address autoconfiguration [5] at the attached link 628 (mobile network of MR1) and obtains the MNP1::MR2/64 on its egress 629 interface as a regular IPv6 address autoconfiguration. Thus, a 630 mobile router may obtain two different addresses such as one from the 631 access router and one from its upper mobile router. For example, the 632 mobile router (MR1) directly attached to the access router only 633 obtains an IPv6 address from the access router, because there are no 634 other upper mobile routers. On the other hand, MR2 gets two 635 addresses from upper mobile router (MR1) and the access router. The 636 mobile router should always select the address assigned from the 637 access router as a care-of address and registers it to the home 638 agent. By doing so, any of tunnel overhead issues raised in the 639 MANEMO problem statement are merely occurred. The loop issue can 640 also be avoided by running a manet routing protocol on its manet 641 interface. However, there is one big issue that the upper mobile 642 router's movement causes the effect to the attached nodes. For 643 example, if MR1 moves change its point of attachment, MR2 also 644 detects movement. This is not what the NEMO Basic Support protocol 645 is aimed for. The movement of a mobile router must be hidden from 646 any nodes in its mobile network. We discuss this in Section 4.3. 648 Access Network 649 | 650 +-+-+ 651 |AR | ANP::/48 or /64 652 +-+-+ 653 | 654 e| <-- ANP::MR1/128 or ANP:1::MR1/64 655 +-+-+ 656 |MR1| 657 +-+-+ 658 i| MNP1::/64 659 ------+------ 660 | <- MNP1::MR2/64 (NOT AUTOCONF address) 661 e| <-- ANP::MR2/128 or ANP:2::MR2/64 662 +-+-+ 663 |MR2| 664 +-+-+ 665 i| 666 -----+----- 668 Figure 12: AUTOCONF Addressing Assignment for the basic Nested NEMO 670 Another problem of this configuration is explained with Figure 13. 671 If a fixed router (FR1) is located in the mobile network, the MANET 672 architecture treats this case as two separate manets inter-connecting 673 by a fixed router. Thus, conceptually, MR2 cannot obtain an address 674 from the access router because the fixed router separates MR1 and 675 MR2. Even if we extend the concept of the MANET architecture [9] in 676 order for the access router to deliver the global unique prefix to 677 the MR2, another problem can be caused. FR1 must have a route of the 678 MR2's prefix assigned by the access router. However, FR1 is just an 679 IPv6 router (i.e. supporting neither the NEMO Basic Support nor 680 AUTOCONF), there is no way that FR1 has a route of the access 681 router's prefix. FR1 cannot route the packet which destination is 682 MR2's address (ANP::MR2/128 or ANP:2::MR2/64) unless the route of 683 MR2's assigned address/prefix is installed in FR1. 685 Access Network 686 | 687 +-+-+ 688 |AR | ANP::/48 or /64 689 +-+-+ 690 | 691 e|<-- ANP::MR1/128 or ANP:1::MR1/64 692 +-+-+ 693 |MR1| 694 +-+-+ 695 i| MNP1::/48 696 ------+------ 697 | 698 +-+-+ <-- it should have routes of either one of 699 |FR1| [ANP:1::/64 & ANP:2::/64] or 700 +-+-+ [ANP::MR1/128 & ANP::MR2/128] 701 i'|MNP1:1::/64 702 -----+------ 703 |<---MNP1:1::MR2 (NOT AUTOCONF address) 704 e|<--- ANP::MR2/128 or ANP:2::MR2/64 <-- how?? 705 +-+-+ 706 |MR2| 707 +-+-+ 708 i| 709 -----+------ 711 Figure 13: AUTOCONF Addressing Assignment when Fixed Router is 712 employed 714 4.3. Comparison of Two Approaches 716 Before discussing the two approaches, the known MANEMO problems [10] 717 are listed here. 719 o Sub-optimal Route and Redundant tunnel 721 o Network Loop 723 o Multiple Exit Routers (Exit Router selection) 725 o No Communication capability without Home Agent Reachability 727 If the AUTOCONF approach (Section 4.2) is taken, every mobile router 728 may be expected to run a manet routing protocol such as DYMO, OLSR, 729 AODV. Although AUTOCONF approach may not apply to the MANEMO 730 scenarios without modification, MANET + AUTOCONF combination can 731 solve some of MANEMO issues. The sub-optimal route can be easily 732 solved because each mobile router can registers its care-of address 733 generated from the access network prefix. The packets are routed to 734 the access router by IP routing and then routed to the correspondent 735 mobile router by the manet routing. Thus, suboptimal route and 736 redundant tunnel are even not happened in this case. The loop free 737 topology formation is essential of a manet routing protocol, too. 738 The multiple exits may be solved if a manet routing protocol carries 739 additional information of exit routers along with the route 740 information. Finally, if manet routes between mobile routers are 741 established, mobile routers can communicate without reaching to the 742 home agent. 744 If the NEMO addressing approach is selected, None of the issues are 745 solved, because the MANEMO activity is begun on the assumption of the 746 NEMO addressing approach. 748 One thing we have to discuss here is the movement pattern. There are 749 two movement patterns in MANEMO, mobile router's alone movement and 750 grouped movement. For the mobile router's alone movement, a mobile 751 router just leaves its MANEMO and goes somewhere. Therefore, this 752 movement pattern is similar to what MANET is addressing (ex. random- 753 way point). On the other hand, the grouped mobility is very NEMO 754 specific movement pattern. When considering the use case such as 755 passenger's PAN enters in the train, all the mobile routers move all 756 together. We discuss the grouped mobility in further section. 758 Figure 14 shows an example of MANEMO topology. The arrows of the 759 left side of Figure 14 shows the extent of the impact when MR1 760 changes its attachment from AR1 to AR2 with grouped mobility pattern. 761 If the NEMO approach is used, the impact of MR1 change is hidden by 762 MR1. In the AUTOCONF approach, the impact is propagated to entire 763 mobile routers that are located behind MR1. What the NEMO Basic 764 Support guarantees is movement transparency of a mobile router. 765 Thus, even if MR1 changes its point of attachment, this change is 766 perfectly hidden from MR2, MR3 and MR4. Even if MR1 changes its 767 attachment, the topology relationship among MR1 , MR2, MR3 and MR4 is 768 not changed. This movement transparency should be supported also in 769 nested NEMO formation because this is essential feature of the NEMO 770 Basic Support protocol. In the AUTOCONF and the MANET approach, this 771 feature is missed due to the AUTOCONF addressing assignment. A 772 mobile router obtains an address not from the upper mobile network, 773 but directly from the access router. If MR1 changes its attachment 774 to MR2, all the mobile routers behind MR1 (MR2, MR3 and MR4) are 775 affected by the change of MR1. MR2, MR3 and MR4 should obtain a new 776 address from AR2 after MR1 changes its attachment to AR2. 778 Access Networks 779 | | 780 +-+-+ +-+-+ 781 |AR1| |AR2| 782 +-+-+ +-+-+ 783 | ---> : 784 NEMO AUTOCONF |..................: 785 /|\ /|\ +-+-+ 786 \|/ | |MR1| 787 | +-+-+ 788 | | 789 | -----+----- 790 | | 791 | +-+-+ 792 | |MR2| 793 | +-+-+ 794 | | 795 | -+------+------+- 796 | | | 797 | +-+-+ +-+-+ 798 | |MR3| |MR4| 799 | +-+-+ +-+-+ 800 | | | 801 \|/ -----+----- -----+----- 803 Figure 14: Extent of the Impact from MR1 movement 805 5. Solution Guideline 807 This section classifies existing and proposed solutions for the 808 MANEMO scenarios. We isolated 2 families: 810 1. Nested NEMO Route Optimization (NEMO centric approach): This is 811 the initial root problem of MANEMO. NEMO mobile routers attach 812 to one another, and MANEMO should optimize the resulting topology 813 for access to the infrastructure, provide a safe model for mobile 814 routers to help one another, some degree of inner routing etc. 815 As shown in Section 4.1, the topology of Nested NEMO becomes 816 tree. For this approach, Tree Discovery [11] has been proposed 817 to form a loop-free tree in MANEMO and NINA [12] provides some 818 routing in that space. Reverse Routing Header (RRH) [13] is a 819 solution how to bypass the number of home agents when mobile 820 routers form the nested NEMO. 822 2. Mobile ad hoc (MANET centric): This is when NEMO mobile routers 823 form a MANET. We found 3 categories: 825 1. "1 hop away" A mobile router only discovers a neighbor mobile 826 router(s) and communicate with them directly. The example 827 use case is the car 2 car. NANO [14] provides a very simple 828 solution. 830 2. "2 hops away" This is where the NHDP [15] could be inserted, 831 still no use of a real routing protocol. A mobile router 832 manages routes for 2-hop neighbor mobile routers. 834 3. "General MANET" In this case, we need a routing protocol of 835 the MANET family. MANEMO could still help in several 836 fashion, for instance provide scalability by splitting the 837 larger network in a number of more manageable islands, 838 interconnected by NEMO over the infrastructure. 840 6. IANA considerations 842 This document does not require any IANA action. 844 7. Security Considerations 846 This document is a architecture model and does not create any 847 security threat. It discusses the concepts of Capability, 848 Innocuousness and Anonymity in a nested NEMO. 850 8. Acknowledgments 852 We would like to thank Teco Boot, Jim Bound, Jari Arkko and Lim Hyung 853 Jin for their comments on this document. We would also like to thank 854 all the people involved in MANEMO activity. 856 9. References 858 9.1. Normative reference 860 [1] Manner, J. and M. Kojo, "Mobility Related Terminology", 861 RFC 3753, June 2004. 863 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 864 IPv6", RFC 3775, June 2004. 866 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 867 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 868 January 2005. 870 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 871 draft-ietf-nemo-terminology-06 (work in progress), 872 November 2006. 874 [5] Thomson, S. and T. Narten, "IPv6 Stateless Address 875 Autoconfiguration", RFC 2462, December 1998. 877 9.2. Informative Reference 879 [6] Ng, C., "Network Mobility Route Optimization Problem 880 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 881 progress), September 2006. 883 [7] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route 884 Optimisation Problem Statement", 885 draft-clausen-nemo-ro-problem-statement-00 (work in progress), 886 October 2004. 888 [8] Thaler, D., "Multilink Subnet Issues", 889 draft-iab-multilink-subnet-issues (work in progress), 890 January 2007. 892 [9] Chakeres, I., "Mobile Ad hoc Network Architecture", 893 draft-ietf-autoconf-manetarch-01 (work in progress), 894 March 2007. 896 [10] Wakikawa, R., "MANEMO Problem Statement", 897 draft-wakikawa-manemo-problem-statement-00 (work in progress), 898 February 2007. 900 [11] Thubert, P., "Nested Nemo Tree Discovery", 901 draft-thubert-tree-discovery-04 (work in progress), 902 November 2006. 904 [12] Thubert, P., "Network In Node Advertisement", 905 draft-thubert-nina-00 (work in progress), February 2007. 907 [13] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 908 its application to Mobile Networks", 909 draft-thubert-nemo-reverse-routing-header-06 (work in 910 progress), September 2006. 912 [14] Petrescu, A. and C. Janneteau, "The NANO Draft (Scene Scenario 913 for Mobile Routers and MNP in RA)", 914 draft-petrescu-manemo-nano-00 (work in progress), March 2007. 916 [15] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", 917 draft-ietf-manet-nhdp-00 (work in progress), June 2006. 919 Authors' Addresses 921 Wakikawa Ryuji 922 Keio University 923 Department of Environmental Information, Keio University. 924 5322 Endo 925 Fujisawa, Kanagawa 252-8520 926 Japan 928 Phone: +81-466-49-1100 929 Fax: +81-466-49-1395 930 Email: ryuji@sfc.wide.ad.jp 931 URI: http://www.wakikawa.org/ 933 Thomas Clausen 934 LIX, Ecole Polytechnique 936 Phone: +33 6 6058 9349 937 Email: T.Clausen@computer.org 939 McCarthy Ben 940 Lancaster University 941 Computing Department, Lancaster University. 942 InfoLab 21, South Drive 943 Lancaster, Lancashire LA1 4WA 944 UK 946 Phone: +44-1524-510-383 947 Fax: +44-1524-510-492 948 Email: b.mccarthy@lancaster.ac.uk 949 URI: http://www.network-mobility.org/ 951 Alexandru Petrescu 952 Motorola Labs 953 Parc les Algorithmes Saint Aubin 954 Gif-sur-Yvette 91193 955 France 957 Email: Alexandru.Petrescu@motorola.com 959 Full Copyright Statement 961 Copyright (C) The IETF Trust (2007). 963 This document is subject to the rights, licenses and restrictions 964 contained in BCP 78, and except as set forth therein, the authors 965 retain all their rights. 967 This document and the information contained herein are provided on an 968 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 969 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 970 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 971 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 972 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 973 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 975 Intellectual Property 977 The IETF takes no position regarding the validity or scope of any 978 Intellectual Property Rights or other rights that might be claimed to 979 pertain to the implementation or use of the technology described in 980 this document or the extent to which any license under such rights 981 might or might not be available; nor does it represent that it has 982 made any independent effort to identify any such rights. Information 983 on the procedures with respect to rights in RFC documents can be 984 found in BCP 78 and BCP 79. 986 Copies of IPR disclosures made to the IETF Secretariat and any 987 assurances of licenses to be made available, or the result of an 988 attempt made to obtain a general license or permission for the use of 989 such proprietary rights by implementers or users of this 990 specification can be obtained from the IETF on-line IPR repository at 991 http://www.ietf.org/ipr. 993 The IETF invites any interested party to bring to its attention any 994 copyrights, patents or patent applications, or other proprietary 995 rights that may cover technology that may be required to implement 996 this standard. Please address the information to the IETF at 997 ietf-ipr@ietf.org. 999 Acknowledgment 1001 Funding for the RFC Editor function is provided by the IETF 1002 Administrative Support Activity (IASA).