idnits 2.17.1 draft-ng-nemo-multihoming-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (February 2003) is 7738 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) -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' -- No information found for draft-kniventon-monet-requiremetns - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-19 ** Obsolete normative reference: RFC 2460 (ref. '10') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '11') -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-03) exists of draft-petrescu-nemo-mrha-00 -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-01 -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' == Outdated reference: A later version (-01) exists of draft-ng-nemo-access-router-option-00 -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-01) exists of draft-ernst-nemo-terminology-00 -- Possible downref: Normative reference to a draft: ref. '18' ** Obsolete normative reference: RFC 2461 (ref. '19') (Obsoleted by RFC 4861) -- Unexpected draft version: The latest known version of draft-ietf-ipv6-default-addr-select is -08, but you're referring to -09. (However, the state information for draft-kniventon-monet-requiremetns is not up-to-date. The last update was unsuccessful) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Mobility Working Group C. W. Ng 3 Internet-Draft Panasonic Singapore Labs 4 Expires: August 2003 T. Tanaka 5 Panasonic Mobile Communications 6 February 2003 8 Multi-Homing Issues in Bi-Directional Tunneling 9 draft-ng-nemo-multihoming-issues-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes deployment scenario of multi-homed NEMO and 34 attempts to identify issues that arises when supporting multi-homing 35 in NEMO. This document also proposes an approach to facilitate 36 multi-homing in NEMO. However, it is not the objective of this memo 37 to define a specification for multi-homing support in NEMO. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119 [2]. 45 Table of Contents 47 1. Introduction...................................................3 48 1.1. Terms Used................................................5 49 1.2. Organization..............................................5 50 2. Multi-Homing in NEMO...........................................6 51 2.1. Deployment Scenarios of Multi-homed NEMO..................6 52 2.1.1. Single Mobile Router with Multiple Egress Interfaces 53 Bound to a Single Home Agent................................6 54 2.1.2. Single Mobile Router with Multiple Egress Interfaces 55 Bound to Different Home Agents..............................7 56 2.1.3. Multiple Mobile Routers..............................8 57 2.2. Issues of Multi-Homing in NEMO............................9 58 3. Using Multi-Homing Features in Bi-Directional Tunnels.........11 59 3.1. Detecting Presence of Alternate Routes...................11 60 3.2. Re-Establishment of Bi-Directional Tunnels...............12 61 3.2.1. Using Alternate Egress Interface....................12 62 3.2.2. Using Alternate Mobile Router.......................12 63 3.3. To Avoid Tunneling Loop..................................13 64 3.4. Other Considerations.....................................13 65 4. Security Considerations.......................................14 66 References.......................................................14 67 Author's Addresses...............................................16 68 1. Introduction 70 The problem of Network Mobility Support (NEMO) is identified in 71 various previous works [3,4,5,6]. In essence, the problem of network 72 in motion is to provide continuous Internet connectivity to nodes in 73 a network that moves as a whole. Nodes within the network that moves 74 may not be aware of the network changing its point of attachment to 75 the Internet. This differs from the traditional problem of mobility 76 support as addressed by Mobile IPv4 [7] in Internet Protocol version 77 4 (IPv4) [8] and Mobile IPv6 [9] in Internet Protocol version 6 78 (IPv6) [10]. 80 In Mobile IP, each mobile node has a permanent home domain. When the 81 mobile node is attached to its home network, it is assigned a 82 permanent global address known as a home-address (HoA). When the 83 mobile node is away, i.e. attached to some other foreign networks, it 84 is usually assigned a temporary global address known as a care-of- 85 address (CoA). The idea of mobility support is such that the mobile 86 node can be reached at the home-address even when it is attached to 87 other foreign networks. This is done in [7,9] with the introduction 88 of an entity at the home network known as a home agent (HA). Mobile 89 nodes register their care-of-addresses with the home agents using 90 messages known as Binding Updates. The home agent is responsible to 91 intercept messages that are addressed to the mobile node's home- 92 address, and forward the packet to the mobile node's care-of-address 93 using IP-in-IP Tunneling [11,12]. 95 Extending the concept of mobility support for individual hosts to 96 mobility support for a network of nodes, the objective of a network 97 in motion solution is to provide a mechanism where nodes in a mobile 98 network can be reached by their permanent addresses, no matter where 99 on the Internet the mobile network is attached to. There exist a few 100 prior attempts to provide network mobility support, most of them 101 based on using bi-directional tunnels between the mobile routers and 102 the home agents of the mobile routers [13,14,15,16,17]. 104 In bi-directional tunnels between mobile routers and home agents, the 105 mobile router controlling a mobile network performs routing of 106 packets to and from the mobile network when it is in its home domain. 107 When the mobile router and its mobile network move to a foreign 108 domain, the mobile router registers its care-of-address with its home 109 agent. An IP-in-IP tunnel is then set up between the mobile router 110 and the home agent. Every packet going to the mobile network will be 111 intercepted by the home agent and forwarded to the mobile router 112 through the IP-in-IP tunnel. The mobile router then forwards the 113 packet to a host in its mobile network. When a node in its mobile 114 network wishes to send a packet out of the network, the mobile router 115 intercepts the packet and forward the packet to the home agent 116 through the IP-in-IP tunnel. The home agent then sends the packet 117 out to the intended recipient. 119 However, the simple approach of bi-directional tunnel does not cater 120 well to other powerful features of IPv4 and IPv6, such as multi- 121 homing. A network in motion can be multi-homed if there exist a 122 plurality of egress interfaces that offer independent routes to the 123 global Internet. If all of these interfaces belong to the same 124 mobile router, then only the mobile router is multi-homed. The 125 mobile network nodes behind the mobile router see only one egress 126 router, thus they are not multi-homed. On the other hand, if these 127 interfaces belong to separate routers, then the mobile network nodes 128 will see different egress routers and can attach to more than one of 129 these egress routers simultaneously. These mobile network nodes are 130 thus multi-homed themselves. 132 Mobile networks typically have wireless connection to the global 133 network. Though wireless technology has improved tremendously over 134 the recent years, it is still more prone to channel instability and 135 noise when compared to wired networks. One of the advantages of 136 multi-homing is that mobile network nodes can use an alternative path 137 to reach and be reached by the global Internet when one of its uplink 138 is down. This is extremely useful for wireless-based mobile nodes, 139 as it provides a back up mechanism to the unstable wireless uplink. 141 However, with bi-directional tunneling mechanism employed by mobile 142 routers, nodes only chose one mobile router as their default router. 143 When this mobile router loses its connection to the global Internet, 144 it can no longer maintain a tunnel with its home agent. Thus all 145 nodes that made use of the mobile router will lose their connectivity 146 to the global network as well, even though there may exits another 147 mobile router on the same network that has an active link to the 148 global Internet. 150 Mobile network nodes may eventually realize that their default router 151 no longer has a route to the global network, and select an alternate 152 mobile router as their default router. Such a scheme relies on the 153 mobile network nodes to perform their own route discovery. It adds 154 processing load to mobile network nodes, which may have very limited 155 processing powers (e.g. embedded devices), and incurs additional 156 delays (for the mobile network nodes to realize their current default 157 route is down). In addition, different mobile routers will advertise 158 different subnet prefixes, and thus when mobile nodes eventually 159 switch their default routers, they will have to use different care- 160 of-addresses. This requires sending of binding updates to their 161 home-agents, further increasing the lag of recovery. 163 1.1. Terms Used 165 It is assumed that readers are familiar with the NEMO terminology 166 described in [18]. In addition, the following definitions of terms 167 are used in this memo: 169 Alternate Mobile Router 171 This term is used when discussing the behaviour of a mobile 172 router. It refers to another mobile router that is connected 173 to the same mobile network and has an independent route to the 174 global Internet. 176 Alternate Egress Interface 178 This term is used when discussing the behaviour of a mobile 179 router with multiple egress interfaces. It refers to another 180 egress interface that is connected to the global Internet. 182 Failed Egress Interface 184 This term refers to the egress interface of a mobile router 185 that has lost its connection to the global Internet. 187 1.2. Organization 189 In the remaining portions of this memo, we will first describe the 190 motivations and scenarios for deploying multi-homed mobile networks 191 in Section 2. The issues in using bi-directional tunneling in a 192 multi-homed mobile network will also be described. In Section 3, we 193 explore into possible solutions to the problems listed in Section 2, 194 and investigate methods of optimizing bi-directional tunneling to 195 employ features of multi-homing. 197 2. Multi-Homing in NEMO 199 2.1. Deployment Scenarios of Multi-homed NEMO 201 2.1.1. Single Mobile Router with Multiple Egress Interfaces Bound to a 202 Single Home Agent 204 First type of multi-homed mobile network contains only one mobile 205 router. This mobile router have a plurality of egress interfaces, 206 all of which bounds to the same home agent. In such cases, the 207 mobile router usually only advertise a single network prefix to the 208 mobile network. This is illustrated in Figure 2.1 below. 210 +-------------------------+ 211 | | Binding Cache | 212 | | HoA CoA | 213 | | 1::1 2::1 | 214 | Home | 1::2 3::1 | 215 | Agent |=================| 216 | | Routing Table | 217 | | Dest Next-Hop | 218 | | 1:1::/96 1::1 | 219 +-------------------------+ 220 | 221 | 222 +-------------------------------------+ 223 | | 224 | Internet | 225 | | 226 +-------------------------------------+ 227 | | 228 Interface 1 | | Interface 2 229 CoA=2::1 | | CoA=3::1 230 HoA=1::1 | | HoA=1::2 231 | | 232 +--------------------+ 233 | Mobile Router | 234 +--------------------+ 235 | prefix=1:1::/96 236 ----------------?---------------- 237 | 238 +----------------+ 239 | Mobile Network | address=1:1::x 240 | Node x | 241 +----------------+ 243 Figure 2.1 - Single MR with Multiple Egress Interfaces to a Single 244 Home Agent. 246 One example of this type of deployment scenario is that a single 247 Internet Service Provider (ISP) offers two different wireless public 248 access methods such as IEEE 802.11 and GPRS. A mobile router with 249 both access interfaces (i.e. 802.11 and GPRS capabilities) may 250 subscribe to the same ISP and is allowed to use both access methods. 251 The ISP will choose to provide a single home agent for the same 252 mobile router for ease of management. 254 2.1.2. Single Mobile Router with Multiple Egress Interfaces Bound to 255 Different Home Agents 257 The second type of multi-homed mobile network involves a single 258 mobile router with more than one egress interfaces. Each of these 259 egress interfaces is bound to different home agents. This is 260 illustrated in Figure 2.2 below. The mobile router can advertise a 261 single network prefix and inject the appropriate routing update to 262 the home agents (not shown in the figure). In this case, the mobile 263 router uses only one interface for bi-directional tunneling. 264 Alternatively, the mobile router could also advertise two different 265 network prefixes (as shown in the figure). Both egress interfaces 266 are then utilized, and the mobile router maintains two active bi- 267 directional tunnels with both home agents. 269 Example of this kind of deployment scenarios is when a mobile router 270 subscribes to different ISPs. For instance, it may subscribe to 271 802.11 public access services using one ISP, and subscribe to GPRS 272 services from another ISP. In this case, the two different ISPs will 273 provide two different home agents for the same mobile router. 275 +-------------------------+ +-------------------------+ 276 | Binding Cache | | | | Binding Cache | 277 | HoA CoA | | | | HoA CoA | 278 | 1::1 3::1 | Home | | Home | 2::1 4::1 | 279 |=================| Agent | | Agent |=================| 280 | Routing Table | 1 | | 2 | Routing Table | 281 | Dest Next-Hop | | | | Dest Next-Hop | 282 | 1:1::/96 1::1 | | | | 2:1::/96 2::1 | 283 +-------------------------+ +-------------------------+ 284 | | 285 | | 286 +-------------------------------------+ 287 | | 288 | Internet | 289 | | 290 +-------------------------------------+ 291 | | 292 Interface 1 | | Interface 2 293 CoA=3::1 | | CoA=4::1 294 HoA=1::1 | | HoA=2::1 295 | | 296 +--------------------+ 297 | Mobile Router | 298 +--------------------+ 299 | prefix=1:1::/96, 2:1::/96 300 ----------------?---------------- 301 | 302 +----------------+ 303 | Mobile Network | address=1:1::x 304 | Node x | or 2:1::x 305 +----------------+ 307 Figure 2.2 - Single MR with Multiple Egress Interfaces to Different 308 Home Agents. 310 2.1.3. Multiple Mobile Routers 312 The third type of multi-homed mobile network involves multiple mobile 313 routers on the same mobile network. Each of these mobile routers 314 advertise an egress route to the global Internet. In such cases, two 315 different network prefixes are advertised to the mobile network 316 nodes. This is illustrated in Figure 2.3 below. 318 Example of this kind of deployment scenarios is when a mobile network 319 contains more than one device with independent routes to the global 320 Internet. An excellent illustration is the Wireless Personal Area 321 Network (W-PAN) where a mobile phone on the W-PAN connects to the 322 Internet via GPRS services, and a Personal Digital Assistant (PDA) on 323 the same W-PAN connects to the Internet via 802.11 public access. 325 +-------------------------+ +-------------------------+ 326 | Binding Cache | | | | Binding Cache | 327 | HoA CoA | | | | HoA CoA | 328 | 1::1 3::1 | Home | | Home | 2::1 4::1 | 329 |=================| Agent | | Agent |=================| 330 | Routing Table | 1 | | 2 | Routing Table | 331 | Dest Next-Hop | | | | Dest Next-Hop | 332 | 1:1::/96 1::1 | | | | 2:1::/96 2::1 | 333 +-------------------------+ +-------------------------+ 334 | | 335 | | 336 +-------------------------------------+ 337 | | 338 | Internet | 339 | | 340 +-------------------------------------+ 341 | | 342 CoA=3::1 | | CoA=4::1 343 HoA=1::1 | | HoA=2::1 344 | | 345 +----------+ +----------+ 346 | Mobile | | Mobile | 347 | Router 1 | | Router 2 | 348 +----------+ +----------+ 349 prefix=1:1::/96 | | prefix=2:1::/96 350 -------?--------?--------?------- 351 | 352 +----------------+ 353 | Mobile Network | address=1:1::x 354 | Node x | or 2:1::x 355 +----------------+ 357 Figure 2.3 - Multiple MRs on the Same Mobile Network. 359 2.2. Issues of Multi-Homing in NEMO 361 When a mobile network is multi-homed, mobile network nodes can choose 362 to use different routes to send packets to the global Internet, 363 either by way of using different global addresses, or by forwarding 364 the packets to different routers. 366 However, with bi-directional tunneling mechanism employed by mobile 367 routers, mobile network nodes only chose one mobile router as their 368 default router. When this mobile router loses its connection to the 369 global Internet, it can no longer maintain a tunnel with its home 370 agent. Thus all mobile network nodes that made use of the mobile 371 router will lose their connectivity to the global network as well. 372 This is hardly desirable, since there may exits another mobile router 373 on the same network that has an active link to the global Internet. 375 Mobile network nodes may eventually realize that their default router 376 no longer has a route to the global network, and select an alternate 377 mobile router as their default router. Such a scheme relies on the 378 mobile network nodes to perform their own route discovery. It adds 379 processing load to mobile network nodes, which may have very limited 380 processing powers (e.g. embedded devices), and incurs additional 381 delays (for the mobile network nodes to realize their current default 382 route is down). In addition, different mobile routers will advertise 383 different subnet prefixes, and thus when mobile nodes eventually 384 switch their default routers, they will have to use different care- 385 of-addresses. This requires sending of binding updates to their 386 home-agents, further increasing the lag of recovery. 388 3. Using Multi-Homing Features in Bi-Directional Tunnels 390 In order to utilize the additional robustness provided by multi- 391 homing, mobile routers that employ bi-directional tunneling with 392 their home agents should dynamically change their tunnel exit points 393 depending on the link status. For instance, if a mobile router 394 detects that one of its egress interface is down, it should detect if 395 any other alternate route to the global Internet exists. This 396 alternate route may be provided by any other mobile routers connected 397 to one of its ingress interfaces that has an independent route to the 398 global Internet, or by another active egress interface the mobile 399 router it self possess. If such an alternate route exists, the 400 mobile router should re-establish the bi-directional tunnel using 401 this alternate route. 403 In the remaining part of this section, we will attempt to investigate 404 methods of performing such re-establishment of bi-directional 405 tunnels. It is not the objective of this memo to specify a new 406 protocol specifically tailored to provide this form of re- 407 establishments. Instead, we will limit ourselves to currently 408 available mechanisms specified in Mobile IPv6 and Neighbour Discovery 409 in IPv6 [19]. 411 3.1. Detecting Presence of Alternate Routes 413 To actively utilize the robustness provided by multi-homing, a mobile 414 router must first be capable of detecting alternate routes. This can 415 be manually configured into the mobile router by the administrators 416 if the configuration of the mobile network is relatively static. It 417 is however highly desirable for mobile routers to be able to discover 418 alternate routes automatically for greater flexibility. 420 The case where a mobile router possesses multiple egress interface 421 (bound to the same home agent or otherwise) should be trivial, since 422 the mobile router should be able to "realize" it has multiple routes 423 to the global Internet. 425 In the case where multiple mobile routers are on the mobile network, 426 each mobile router has to detect the presence of other mobile router. 427 A mobile router can do so by listening for Router Advertisement 428 message on its *ingress* interfaces. When a mobile router receives a 429 Router Advertisement message with a non-zero Router Lifetime field 430 from one of its ingress interfaces, it knows that another mobile 431 router which can provide an alternate route to the global Internet is 432 present in the mobile network. 434 3.2. Re-Establishment of Bi-Directional Tunnels 436 When a mobile router detects that the link be which its current bi- 437 directional tunnel with its home agent is using is down, it needs to 438 re-establish the bi-directional tunnel using an alternate route 439 detected. We consider two separate cases here: firstly, the 440 alternate route is provided by another egress interface that belongs 441 to the mobile router; secondly, the alternate route is provided by 442 another mobile router connected to the mobile network. We refer to 443 the former case as an alternate route provided by an alternate egress 444 interface, and the latter case as an alternate route provided by an 445 alternate mobile router. 447 3.2.1. Using Alternate Egress Interface 449 When an egress interface of a mobile router loses the connection to 450 the global Internet, the mobile router can make use of its alternate 451 egress interface should it possess multiple egress interfaces. The 452 most direct way to do so is for the mobile router to send a binding 453 update to the home agent of the failed interface using the care-of- 454 address assigned to the alternate interface in order to re-establish 455 the bi-directional tunneling using the care-of-address on the 456 alternate egress interface. After a successful binding update, the 457 mobile router encapsulates outgoing packets through the bi- 458 directional tunnel using the alternate egress interface. 460 The idea is to use the global address (most likely a care-of-address) 461 assigned to an alternate egress interface as the new (back-up) care- 462 of-address of the mobile router to re-establish the bi-directional 463 tunneling with its home agent. 465 3.2.2. Using Alternate Mobile Router 467 When the mobile router loses a connection to the global Internet, the 468 mobile router can utilize a route provided by an alternate mobile 469 router (if one exists) to re-establish the bi-directional tunnel with 470 its home agent. First, the mobile router has to obtain a care-of- 471 address from the alternate mobile router (i.e. attaches itself to the 472 alternate mobile router). Next, it sends binding update to its home 473 agent using the care-of-address obtained from the alternate mobile 474 router From then on, the mobile router can encapsulates outgoing 475 packets through the bi-directional tunnel using via the alternate 476 mobile router. 478 The idea is to obtain a care-of-address from the alternate mobile 479 router and use this as the new (back-up) care-of-address of the 480 mobile router to re-establish the bi-directional tunneling with its 481 home agent. 483 Note that every packet sent from/to mobile network nodes to/from 484 their correspondent nodes will experience two levels of encapsulation. 485 First level of tunneling is done between a mobile router which the 486 mobile network node uses as its default router and the mobile 487 router's home agent. The second level of tunneling is done between 488 the alternate mobile router and its home agent. 490 3.3. To Avoid Tunneling Loop 492 The method of re-establishing the bi-directional tunnel as described 493 in Section 3.2 may lead to infinite loops of tunneling. This happens 494 when two mobile routers on a mobile network lose connection to the 495 global Internet at the same time and each mobile router tries to re- 496 establish bi-directional tunnel using the other mobile router. We 497 refer to this phenomenon as tunneling loop. 499 One approach to avoid tunneling loop is for a mobile router that has 500 lost connection to the global Internet to insert an option into the 501 Router Advertisement message it broadcasts periodically. This option 502 serves to notify other mobile routers on the link that the sender no 503 longer provides global connection. Note that setting a zero Router 504 Lifetime field will not work well since it will cause mobile network 505 nodes that are attached to the mobile router to stop using the mobile 506 router as an access router too (in which case, things are back to 507 square one). 509 3.4. Other Considerations 511 When a mobile network is multi-homed, mobile network nodes may 512 receive Router Advertisements that advertise different network 513 prefixes. This is usually the case when the multi-homed mobile 514 network has two or more mobile routers advertising different routes 515 to the global Internet. It may also occur when the mobile network 516 has only one mobile router with multiple egress interfaces bound to 517 different home agents. In these situations, mobile network nodes 518 typically only select one to form its global (possibly care-of) 519 address. 521 In view of this, it may be desirable for mobile network node to be 522 able to acquire "preference" information on each mobile network 523 prefix from the mobile routers. This allows default address 524 selection mechanism such as that specified in [20] to be used. 525 Further exploration on setting such "preference" information in 526 Router Advertisement based on performance of the bi-directional 527 tunnel might prove to be useful. 529 4. Security Considerations 531 Currently the following security threat is identified with multi- 532 homing in NEMO: 534 - A malicious node in a mobile network advertises an Router 535 Advertisement message with a non-zero Router Lifetime field, 536 tricking mobile network nodes and even mobile routers to forward 537 all packets through it. 539 This is not specific to the multi-homing approach described in this 540 document. However, an authentication mechanism that can authenticate 541 a mobile router from mobile network node when it attaches may be able 542 to prevent such attacks. 544 References 546 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 547 BCP 9, RFC 2026, October 1996. 549 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 550 Levels", BCP 14, RFC 2119, March 1997 552 [3] Soliman, H., and Pettersson, M., "Mobile Networks (MONET) 553 Problem Statement and Scope", Internet Draft, draft-soliman- 554 monet-statement-00.txt, Work In Progress, Feb 2002. 556 [4] Ernst, T. et. al., "Network Mobility Support Requirements", 557 Internet Draft, draft-ietf-nemo-requirements-00.txt, Work In 558 Progress, Feb 2003. 560 [5] Lach, H. et. al., "Mobile Networks Scenarios, Scope and 561 Requirements", Internet Draft, draft-lach-monet-requirements- 562 00.txt, Work In Progress, Feb 2002. 564 [6] Kniventon, T. J., and Yegin, A. E., "Problem Scope and 565 Requirements for Mobile Networks Working Group", Internet 566 Draft, draft-kniventon-monet-requiremetns-00.txt, Work In 567 Progress, Feb 2002. 569 [7] Perkins, C. E. et. al., "IP Mobility Support", IETF RCF 2002, 570 Oct 1996. 572 [8] DARPA, "Internet Protocol", IETF RFC 791, Sep 1981. 574 [9] Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility 575 Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6- 576 19.txt, Work In Progress, Oct 2002. 578 [10] Deering, S., and Hinden, R., "Internet Protocol, Version 6 579 (IPv6) Specification", IETF RFC 2460, Dec 1998. 581 [11] Simpson, W., "IP in IP Tunneling", IETF RFC 1853, Oct 1995. 583 [12] Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6", 584 IETF RFC 2473, Dec 1998. 586 [13] Kniveton, T. et. al., "Mobile Router Tunneling Protocol", 587 Internet Draft: draft-kniveton-mobrtr-03.txt, Work In Progress, 588 Nov 2002. 590 [14] Petrescu, A., et. al., "Issues in Designing Mobile IPv6 Network 591 Mobility with the MR-HA Bidirectional Tunnel (MRHA)", Internet- 592 Draft: draft-petrescu-nemo-mrha-00.txt, Work In Progress, Oct 593 2002. 595 [15] Thubert, P., and Molteni, M., "IPv6 Reverse Routing Header and 596 Its Application to Mobile Networks", Internet Draft: draft- 597 thubert-nemo-reverse-routing-header-01.txt, Work In Progress, 598 Oct 2002. 600 [16] Ernst, T., Castelluccia, C., Bellier, L., Lach, H., and 601 Olivereau, A., "Mobile Networks Support in Mobile IPv6 (Prefix 602 Scope Binding Updates)", Internet Draft: draft-ernst-mobileip- 603 v6-network-03.txt, Work In Progress, Mar 2002. 605 [17] Ng, C. W., and Takeshi, T., "Securing Nested Tunnels 606 Optimization with Access Router Option", Internet Draft: draft- 607 ng-nemo-access-router-option-00.txt, Work In Progress, Oct 608 2002. 610 [18] Ernst, T., and Lach, H., "Network Mobility Support 611 Terminology", Internet Draft, draft-ernst-nemo-terminology- 612 00.txt, Work In Progress, Oct 2002. 614 [19] Narten, T., Nordmark, E., and Simpson, W., "Neighbour Discovery 615 for IPv6", IETF RFC 2461, Dec 1998. 617 [20] Draves, R., "Default Address Selection for IPv6", draft-ietf- 618 ipv6-default-addr-select-09.txt, Work in progress. 620 Author's Addresses 622 Chan-Wah Ng 623 Panasonic Singapore Laboratories Pte Ltd 624 Blk 1022 Tai Seng Ave #04-3530 625 Tai Seng Industrial Estate 626 Singapore 534415 627 Phone: (+65) 6554 5420 628 Email: cwng@psl.com.sg 630 Takeshi Tanaka 631 R&D center 632 Panasonic Mobile Communications Co., Ltd. 633 5-3, Hikarinooka, Yokoshuka-shi, Kanagawa 634 239-0847, Japan 635 Phone: +81-46-840-5494 636 Email: Takeshi.Tanaka@yrp.mci.mei.co.jp