idnits 2.17.00 (12 Aug 2021) /tmp/idnits49834/draft-zhao-nemo-ro-ps-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.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 745. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. 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 a Security Considerations section. ** 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 is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R2: Signaling messages MUST be secured to guarantee the integrity, confidentiality, anti-replay and authorization. The insider attack where the attacker is on the routing path SHOULD be at least detected while the outsider attack where the attacker is not on the routing path MUST be resisted. The security mechanism MUST prevent the forged packet being forwarded in a loop inside NEMO and MUST not generate the new vulnerability. Overall, the security level and the location privacy MUST be kept as strong as in NEMO Basic Support protocol. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: R7: The solution SHOULD function for multi-homing NEMO networks (multiple MNPs, multiple MRs and multiple network interfaces, etc.). The solution SHOULD not conflict with multi-homing mechanism, such as loading balance, fault tolerance etc. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R8: Each MR can either independently decide whether to perform RO function or NEMO Basic Support protocol or collaborate with other MR based on its policy. The decision made by one MR MUST not prevent other MR performing either NEMO RO or NEMO Basic Support protocol properly. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: R9: The solution SHOULD ensure backward compatibility with other standards defined by the IETF. Especially the solution MUST not prevent the proper operation of Mobile IPv6 (i.e. the solution MUST allow MIP6-enabled MNNs to operate either of the CN, HA, or MN operations defined in MIP6.) and NEMO Basic Support protocol. -- 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 (October 18, 2004) is 6424 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) == Unused Reference: '3' is defined on line 658, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 662, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 665, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 670, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 677, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 682, but no explicit reference was found in the text == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '1') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-multihoming-issues (ref. '5') == Outdated reference: A later version (-04) exists of draft-thubert-nemo-ro-taxonomy-02 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-07) exists of draft-thubert-nemo-reverse-routing-header-05 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-01) exists of draft-watari-nemo-nested-cn-00 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 13 errors (**), 0 flaws (~~), 20 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group F. Zhao 2 Internet-Draft S F. Wu 3 Expires: April 18, 2005 UC Davis 4 S. Jung 5 Soongsil University 6 October 18, 2004 8 NEMO Route Optimization Problem Statement, Requirements and 9 Evaluation Considerations 10 draft-zhao-nemo-ro-ps-00 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 18, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document describes and analyzes the routing optimization problem 46 in NEMO, defines the requirements that must be met by NEMO route 47 optimization solutions and then describes the metrics to evaluate the 48 performance of NEMO route optimization solutions. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. The definition of "optimal" and "non-optimal" route . . . . . 6 56 4.1 Optimal route . . . . . . . . . . . . . . . . . . . . . . 6 57 4.1.1 CN is not under the same nested NEMO as its peer, 58 MNN . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1.2 CN is under the same nested NEMO as its peer, MNN . . 6 60 4.2 Non-optimal route . . . . . . . . . . . . . . . . . . . . 7 61 4.3 Approximately optimal route . . . . . . . . . . . . . . . 8 62 5. Limitation of NEMO Basic Support protocol . . . . . . . . . . 9 63 5.1 Reverse tunneling . . . . . . . . . . . . . . . . . . . . 9 64 5.2 HA as the only anchor point . . . . . . . . . . . . . . . 9 65 5.3 Inside the nested NEMO . . . . . . . . . . . . . . . . . . 9 66 5.4 Data plane based method . . . . . . . . . . . . . . . . . 9 67 5.5 Data packet and processing overhead . . . . . . . . . . . 10 68 5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6. The formalization of the nested NEMO network . . . . . . . . . 11 70 7. The related tradeoff . . . . . . . . . . . . . . . . . . . . . 13 71 7.1 Data plane method vs. signaling plane method . . . . . . . 13 72 7.2 Optimization vs. the scalability issue in MR, CA and HA . 13 73 7.3 Optimization vs. the scope of change . . . . . . . . . . . 13 74 7.4 Location privacy vs. optimal route . . . . . . . . . . . . 13 75 7.5 Security vs. optimal route . . . . . . . . . . . . . . . . 13 76 7.6 Scalability vs. reliability . . . . . . . . . . . . . . . 14 77 8. The scope of NEMO RO problem . . . . . . . . . . . . . . . . . 15 78 8.1 What NEMO RO considers . . . . . . . . . . . . . . . . . . 15 79 8.2 What NEMO RO does not consider . . . . . . . . . . . . . . 15 80 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. Evaluation Considerations . . . . . . . . . . . . . . . . . 18 82 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 19 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 85 Intellectual Property and Copyright Statements . . . . . . . . 21 87 1. Introduction 89 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 90 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be 91 interpreted as described in RFC2119 [7]. 93 NEMO Basic Support protocol maintains the connectivity when MR 94 changes its point of attachment to the Internet by establishing a bi- 95 directional tunnel between MR and HA. Like MIP6, the protocol 96 specification introduces one level of indirection in the routing 97 system in favor of protocol simplicity and minimal changes on fixed 98 nodes. However, it results in a non-optimal (We will define 99 "optimal" and "non-optimal" later.) route between MNN and CN with a 100 non-zero and even very large probability, which causes the 101 significant communication delay. Moreover, by using IPv6 header 102 encapsulation together with other options, NEMO Basic Support 103 protocol also causes big overheads in packet payload and bandwidth. 104 NEMO RO problem introduces more challenges and more difficulties than 105 MIP6 RO problem because of the nested NEMO network where multiple 106 levels of mobility are formed. Without NEMO RO solution, the 107 performance becomes much worse especially in the nested NEMO. 109 In this draft, we describe and analyze the routing optimization 110 problem in NEMO, defines the requirements that must be met by NEMO 111 route optimization solutions and then describes the metrics to 112 evaluate the performance of NEMO route optimization solutions. 114 2. Terminology 116 The terms used in this draft are defined in [2], besides the 117 following ones: 119 Correspondent Agent (CA): An entity (router or host) performs the 120 RO function with MR on behalf of CN. In NEMO when MR acts as a 121 gateway and performs RO function for an entire mobile network 122 associated with itself, its peer is CA rather than CN that is 123 instead the peer of MNN from an end-to-end perspective. CA may be 124 just CN itself or a router near CN or even CN's default router. 125 One MR could have multiple CAs at the same time because MNNs 126 behind this MR may communicate with CNs in the different networks. 127 And in NEMO Basic Support protocol, HA acts as CA for any node in 128 the Internet to communicate with MNN behind its MR. 130 Anchor point: the entity that knows the binding information 131 between host and location and thus is capable of forwarding the 132 data packets destined for a host to the location directly. In the 133 fixed network, each router is such kind of anchor point because IP 134 address represents both location and host, and the destination IP 135 address together with the routing table provides the sufficient 136 knowledge on how to reach the destination. However in the NEMO 137 mobile network that is compliant with NEMO Basic Support protocol, 138 HA is the only anchor point for CN and MNN. In order to achieve 139 the optimal route in NEMO, MR and CA should become anchor point 140 too. In most cases, the closer to MNN/CN the anchor point is, the 141 shorter the routing path is. 143 Inbound direction: The direction from the Internet infrastructure 144 to the inside of NEMO network. 146 Outbound direction: The direction from the inside of NEMO network 147 to the Internet infrastructure. 149 Inbound route : The route taken by the packets forwarded in the 150 inbound direction. Inbound route is used exchangeably with 151 inbound path. 153 Outbound route : The route taken by the packets forwarded in the 154 outbound direction. Outbound route is used exchangeably with 155 outbound path. 157 3. Assumptions 159 In this draft we do not consider the case of mobile HA. Instead we 160 assume that all HAs are fixed nodes and are located in the Internet 161 infrastructure. Firstly it is not clear yet about the need of mobile 162 HA in the real life at this moment. Secondly and more importantly, 163 since a mobile HA needs the help of another fixed HA in order to 164 forward the traffic for MRs, the mobile HA case can be deduced into 165 the similar case with only fixed HA. Our description has no 166 difficulty to be extended into the mobile HA case. Thus we believe 167 that this assumption is reasonable and does not prevent the thorough 168 analysis on NEMO RO problem. 170 4. The definition of "optimal" and "non-optimal" route 172 NEMO route optimization solution aims to provide the optimal route 173 between MNN and CN as well as between MR and CA. As it has been 174 understood for a long time that the routing path in the Internet is 175 asymmetric, in the following text we consider just either of two 176 directions without explicit statement and the same analyses also 177 apply to the other direction. 179 4.1 Optimal route 181 In the NEMO Route Optimization problem, "optimal route" is not the 182 topologically shortest path or the best route in terms of any other 183 metric from source to destination. Based on the location of CN, 184 "optimal route" is discussed in the following cases: 186 4.1.1 CN is not under the same nested NEMO as its peer, MNN 188 CN may be located in either fixed or mobile network. As the route 189 between MNN/MR and CN/CA consists of two portions, the route in the 190 Internet and the route inside the (nested) NEMO network, we define 191 them separately. The "optimal route" in the Internet is the route 192 between the location of MNN/MR and the location of CN/CA based on the 193 forwarding tables of Internet routers, which is usually built by 194 inter-domain or intra-domain routing protocol. Precisely, location 195 is the point of attachment to the Internet. While in MIP6 MN's 196 Care-of-Address represents its location of attachment to the 197 Internet, in the nested NEMO MNN/MR's Care-of-Address is not 198 sufficient any more to represent its location of attachment to the 199 Internet except the case of root-MR; Instead it represents the point 200 of attachment to the parent MR or the location inside the parent 201 NEMO. A sequence of Care-of-Addresses of MRs or other ways may be 202 used to represent the location of MR in the NEMO RO solution. 204 The "optimal route" inside the NEMO network is formed by the decision 205 of each MR along the outbound and inbound path. In the outbound 206 direction, MR just forwards the packets to its default router that is 207 determined when MR associates to NEMO network while in the inbound 208 direction, MR forwards the packets to the next hop depending on the 209 solution. The inbound path inside the NEMO network may be different 210 from the outbound path. Note that the route inside the NEMO network 211 does not contain HA. 213 4.1.2 CN is under the same nested NEMO as its peer, MNN 215 CN may be under the same MR or different MR from its peer. We assume 216 that node1 wants to communicate with node2 under the same nested 217 NEMO. Path p1 = is the sequence 218 of routers inside the nested NEMO for node1 to reach node2 and path 219 p2 = is the sequence of routers 220 inside the nested NEMO for node2 to reach node1. 222 Case 1: If the intersection of p1 and p2 is not empty, denoted by 223 = where i1 < i2 < ... < ik and j1 < j2 < ... < jk, then 225 ideally the optimal path between node1 and node2 is . Note 227 that MR_(1,i1) is equal to MR_(2,j1). 229 |-----| |-----| 230 |---| MR2 |---| MR3 |--LFN3 231 | |-----| |-----| 232 |-------| |-----| 233 |Root-MR|---| MR1 | 234 |-------| |-----| 235 | |-----| |-----| 236 |---| MR4 |---| MR5 |--LFN5 237 |-----| |-----| 239 Figure 1: The optimal route inside the nested NEMO 241 For example, in the nested NEMO shown by Figure 1, the optimal route 242 between LFN3 and LFN5 is MR3<->MR2<->MR1<->MR4<->MR5. 244 The optimal route in this case is the route turning around at the 245 first MR that is aware of how to forward the data packets from source 246 to destination without going out of the nested NEMO. However, in 247 NEMO Basic Support protocol, the data packet takes a route that goes 248 out of the nested NEMO and comes back to the same nested NEMO again. 250 Case 2: If the intersection of p1 and p2 is empty (It may be due to 251 multiple different root-MRs and no inter-communication between them), 252 the "optimal route" inside the nested NEMO consists of both p1 and 253 p2, and the "optimal route" inside the Internet follows the 254 definition in Section 4.1.1. 256 4.2 Non-optimal route 258 In NEMO Basic Support protocol, the packets are forwarded to an 259 intermediate box, HA, in both directions rather than the location of 260 destination directly, which results in a longer route than the 261 "optimal route" with a high probability. We refer this kind of route 262 as "non-optimal" route. Worse than MIP6, in the nested NEMO network 263 the packets are forwarded to multiple HAs in both directions before 264 arriving at the location of destination. [10] describes the 265 non-optimal route that packets would take using existing Mobile IPv6 266 and NEMO Basic Support mechanisms 268 4.3 Approximately optimal route 270 The solution to achieve an "optimal route" has to consider a lot of 271 other factors, for example, scalability, efficiency, and security, to 272 name a few. Although the solution may result in an approximately 273 optimal route, it must be the best overall when all the related 274 issues are taken into consideration. 276 5. Limitation of NEMO Basic Support protocol 278 In this section, we analyze the limitation of NEMO Basic Support 279 protocol and the reasons to cause the non-optimal route. 281 5.1 Reverse tunneling 283 In NEMO Basic Support protocol, all the packets forwarded by MR in 284 the outbound direction have to go through HA firstly. If the reverse 285 tunnel would be removed in NEMO RO solution, it is equivalent to the 286 case where MR is the anchor point for the outbound packet. 288 Instead in the normal fixed network, the data packets are sent to the 289 destination directly. 291 5.2 HA as the only anchor point 293 Since MR is refrained from announcing its MNP to the infrastructure 294 due to the conflicts and routing instability issues, HA is the only 295 anchor point for MNN as well as CN and thus the packets destined to 296 MNNs can be served only by HA. Even worse in the nested NEMO, the 297 packets inevitably have to go through multiple HAs in order to be 298 forwarded to MNN correctly. 300 The non-optimal route is formed because the binding information is 301 available in HA only and the HA's location is limited in home network 302 only. Image that there are as many HAs as routers scattering around 303 the Internet, every data packet from CN is forwarded by a nearby HA 304 and takes at least a nearly optimal route. Deploying multiple HAs in 305 the different domains or spreading binding information needs to 306 consider a lot of issues, such as fundamental changes, conflict and 307 scalability etc. 309 Compared with the fixed network, there is no limitation on the 310 location of anchor point because each router is such an anchor point. 312 5.3 Inside the nested NEMO 314 If MR inside the nested NEMO is refrained from announcing its MNP to 315 other MRs, MR does not know how to forward in the inbound direction 316 just based on the destination IP address and its own limited 317 knowledge of topology. Thus MR has to depend on the explicit 318 IP-in-IP header to forward to the next hop, which in return requires 319 that each data packet should go through HA. 321 5.4 Data plane based method 323 We categorize NEMO as a data plane method because 1) there is no 324 signaling message introduced for CN to discover or update the binding 325 information; 2) many changes are made in order for the routing 326 decision to be explicitly carried in the data packet in an "in-band" 327 fashion. The limitation of this data plane method is that every data 328 packet has to experience the non-optimal route even though the 329 optimal route may be existing and fairly stable within a certain time 330 window. Considering the potential large number of data packets, the 331 inefficiency as well as the benefits if the problem is solved are 332 very big. 334 On the other hand this method avoids the large change on the 335 infrastructure. Given the fact that a big change on the 336 infrastructure may take a longer time to deploy, a RO solution in 337 data plane may qualify as a necessary step before a revolutionary 338 change happens. 340 5.5 Data packet and processing overhead 342 Encapsulation and other options in IPv6 header cause the overhead in 343 data packet and bandwidth, packet fragmentation, and the processing 344 overhead in MR and HA especially in the nested NEMO where every level 345 of mobility introduces one encapsulation together with applicable 346 option fields into the data packet. 348 In the fixed network, encapsulation and other options are not needed 349 since all the routing decision is purely based on the forwarding 350 table and the destination IP address. 352 5.6 Summary 354 One significant difference between MIP6 and NEMO is the management 355 granularity that is a single host in MIPv6 and a mobile network in 356 NEMO. Another significant difference is the multiple levels of 357 mobility in the nested NEMO, which not only causes much longer 358 routing path and bigger overhead in the data payload but also more 359 challenges when attempting to solve NEMO RO problem, for example, 360 given that any other factor is constant, the number of messages (RR 361 test, BU etc) is in direct proportion to the number of MRs along the 362 path if no cooperation among them. In summary, NEMO RO problem is a 363 challenging problem and requires a well-designed NEMO RO solution. 365 6. The formalization of the nested NEMO network 367 The topology of the nested NEMO can be formalized into graph. When 368 care is taken to avoid the loop to be formed, this graph is a 369 Directed Acyclic Graph that may be also considered as a set of 370 multiple overlapping trees. 372 The inbound graph is a direct graph where each node in V 373 denotes a MR and if one of egress interfaces in MRj gets its 374 care-of-address from one MNP owned by MRi, the link from MRi to MRj, 375 belongs to the edge set E. 377 The outbound graph is a direct graph where each node in V 378 denotes a MR and if MRj chooses MRi as its default router, the link 379 from MRj to MRi, belongs to the edge set E. 381 This method can also formalize a multi-homing nested NEMO where there 382 could be more than one egress interface associated with one MR and 383 more than one MR owning one or more MNPs. Figure 2 below shows an 384 exmaple of nested NEMO network. 386 |-------| |-------| 387 | MR1 | | MR2 | 388 |-------| |-------| 389 | | | 390 MNP1 | | MNP2 MNP2 | 391 --?------+ +-------?------?----------+ 392 | | | 393 | | | 394 |eth0|-------|eth1| |eth0|-------| 395 |----| MR3 |----| |----| MR4 | 396 |-------| |-------| 398 In this figure, MR1 announces MNP1 and MNP2 while MR2 announces MNP2. 399 MR3 has two interfaces that associate with MR1 and MR2 respectively 400 while MR4 associates with MR2 only. 402 Figure 2: An example of nested NEMO network 404 The inbound graph is shown in Figure 3. 406 |-------| |-------| 407 | MR1 |--- ---| MR2 | 408 |-------| \ / |-------| 409 | | \ / | 410 V V X V 411 |-------| / \ |-------| 412 | MR3 |<--/ \-->| MR4 | 413 |-------| |-------| 415 Figure 3: The inbound graph of a nested NEMO network 417 We can simplify the inbound graph shown in Figure 3 into the 418 following one. 420 |-------| |-------| 421 | MR1 |--- ---| MR2 | 422 |-------| \ / |-------| 423 | \ / | 424 V X V 425 |-------| / \ |-------| 426 | MR3 |<--/ \-->| MR4 | 427 |-------| |-------| 429 Figure 4: The simplified inbound graph of a nested NEMO network 431 Assume that MR3 chooses MR2 as the default router through eth1 and 432 MR4 chooses MR1 as the default router through eth0. The outbound 433 graph of this nested NEMO is shown in Figure 5. 435 |-------| |-------| 436 | MR1 |<-- -->| MR2 | 437 |-------| \ / |-------| 438 \ / 439 X 440 |-------| / \ |-------| 441 | MR3 |---/ \---| MR4 | 442 |-------| |-------| 444 Figure 5: The outbound graph of a nested NEMO network 446 The formalization may help us understand the problem better and 447 develop the RO solution. For example, if an explicit next hop 448 address is presented in the packet, MR has to check whether this next 449 hop address belongs to one of its MNPs in order to prevent an 450 attacker forcing the packet to be forwarded in a loop. 452 7. The related tradeoff 454 We discuss the tradeoffs when designing the solution for NEMO RO 455 problem. 457 7.1 Data plane method vs. signaling plane method 459 Data plane method needs fewer changes but introduces more overheads 460 while signaling plane method may require more changes on the 461 protocols. We need to consider how to utilize the advantages of both 462 methods and avoid the disadvantages. 464 7.2 Optimization vs. the scalability issue in MR, CA and HA 466 The closer to CN CA is, the more optimal route; but MR has to perform 467 RO functions with more CAs when the number of different CNs is large 468 and all CNs scatter around the Internet. MR may choose not to 469 perform RO function but NEMO Basic Support protocol due to the 470 management cost. 472 On the other hand, if there are many MRs belonging to the same home 473 network scattering around the Internet, because of the same reason, 474 CA may also choose to perform NEMO Basic Support protocol with HA 475 rather than to perform RO function with each MR. 477 If there are many HAs, each of which is close to each MR belonging to 478 the same home network, the route between MNN and CN is at least 479 nearly optimal. Thus there is a tradeoff between the optimal route 480 and the scalability issue in terms of the number of HAs. 482 7.3 Optimization vs. the scope of change 484 The scope of change is in terms of the number of nodes that need to 485 be changed in order to support NEMO RO solution. If all CNs are 486 changed to support the NEMO RO, the optimal route is formed; however, 487 if the scope of change is a limited number of nodes, the probability 488 that a sub-optimal route is formed could be very large. 490 7.4 Location privacy vs. optimal route 492 Bi-direction tunnel in NEMO Basic Support protocol can maintain some 493 level of location privacy. A potential RO solution may require some 494 location information to be revealed in order to facility route 495 optimization. 497 7.5 Security vs. optimal route 499 In NEMO Basic Support protocol, it is very possible that there pre- 500 exists the security association between MR and HA, which helps resist 501 the various attacks. However in NMEO RO solution, as the MR-HA 502 tunnel may not exist and there is no pre-existing security 503 association between two entities from the different domains, it is 504 more challenging to maintain the same security strength as in NEMO 505 Basic Support protocol. 507 7.6 Scalability vs. reliability 509 This is a general tradeoff in NEMO. As MR manages a whole mobile 510 network, when MR fails due to attack or error, a bunch of MNNs behind 511 MR lose the connectivity even though any single MNN still functions 512 well. However, generally it provides more scalability than MIP6. 514 8. The scope of NEMO RO problem 516 8.1 What NEMO RO considers 518 (Below is an incomplete list of issues related to NEMO RO problem 519 quoted from the NEMO mailing list. More discussions are still 520 needed.) 522 o NEMO The optimal route when two communicating nodes are located 523 either in the same or different (nested) NEMO network [10]. 525 o VMN may choose not to perform MIP6 RO solution so that even though 526 MR performs NEMO RO function, the packets originated from and 527 destined to VMN still have to go through VMN's HA. We need to 528 consider all the related issues if we want to remove this kind of 529 sub-optimal route for VMN. 531 o Missing signaling messages when performing NEMO RO 533 o Obsolete state or signaling message when mobility causes the 534 topology changes 536 o RO problem when multi-homing is also involved 538 o Data packet overhead when header encapsulation, options and 539 routing header are used 541 o Security problem. 543 o Location privacy problem 545 o Looping problem 547 o Cross-over tunnel problem 549 o BU storm 551 8.2 What NEMO RO does not consider 553 TBD. 555 9. Requirements 557 The goal of NEMO RO solution is to provide an optimal route between 558 any two nodes regradless of the location, the configuration, and the 559 type etc. Besides those defined in [1], NEMO RO solution, hereafter 560 referred to as "the solution", must meet the following requirements 561 that are described in the descending order of importance as follows: 563 R1: When any MR in NEMO performs NEMO RO function, the route taken 564 by the traffic from this MR together with any MNN inside this MR's 565 sub-NEMO MUST be better than the one resulted in by performing 566 NEMO Basic Support protocol. 568 R2: Signaling messages MUST be secured to guarantee the integrity, 569 confidentiality, anti-replay and authorization. The insider 570 attack where the attacker is on the routing path SHOULD be at 571 least detected while the outsider attack where the attacker is not 572 on the routing path MUST be resisted. The security mechanism MUST 573 prevent the forged packet being forwarded in a loop inside NEMO 574 and MUST not generate the new vulnerability. Overall, the 575 security level and the location privacy MUST be kept as strong as 576 in NEMO Basic Support protocol. 578 R3: This solution SHOULD introduce limited signaling overhead, 579 limited packet payload overhead, limited memory cost needed for 580 processing, limited complexity in term of data structure and 581 protocol state machine transition. 583 R4: The solution MUST be able to support a potentially large 584 number of MNNs, CNs, CAs as well as HAs (if applicable) and 585 arbitrary levels of MRs unless because of other constraints. 587 R5: The solution SHOULD avoid too many changes on MNN/MR/CN/CA/HA 588 unless the significant performance improvement can be achieved. 589 It is desired to keep the mobility transparency for MNN behind MR. 591 R6: The solution SHOULD be able to handle the topology changes in 592 any kind of mobility pattern very well and minimize the impact of 593 handover over applications, in term of packet loss or delay. 595 R7: The solution SHOULD function for multi-homing NEMO networks 596 (multiple MNPs, multiple MRs and multiple network interfaces, 597 etc.). The solution SHOULD not conflict with multi-homing 598 mechanism, such as loading balance, fault tolerance etc. 600 R8: Each MR can either independently decide whether to perform RO 601 function or NEMO Basic Support protocol or collaborate with other 602 MR based on its policy. The decision made by one MR MUST not 603 prevent other MR performing either NEMO RO or NEMO Basic Support 604 protocol properly. 606 R9: The solution SHOULD ensure backward compatibility with other 607 standards defined by the IETF. Especially the solution MUST not 608 prevent the proper operation of Mobile IPv6 (i.e. the solution 609 MUST allow MIP6-enabled MNNs to operate either of the CN, HA, or 610 MN operations defined in MIP6.) and NEMO Basic Support protocol. 612 More? 614 10. Evaluation Considerations 616 The following metrics are defined to evaluate how good a NEMO RO 617 solution is besides meeting the requirements described above. Each 618 metric may be assigned a weight in order to find a overall best RO 619 solution. 621 o Level of compatibility with NEMO Basic Support protocol 623 o Complexity: How many changes to MNN/MR/CA/HA are introduced? Does 624 the solution maintain the mobility transparency for MNN? 626 o Performence: 627 * The delay to discover and set up the optimal path 628 * The packet overhead and/or signaling overhead to discover and 629 set up the optimal path 630 * The delay to re-discover and re-build the optimal path when the 631 mobility causes the topology change 632 * The packet overhead and/or signaling overhead to re-discover 633 and re-build the optimal path when the mobility causes the 634 topology change 636 o Management cost: 637 * The number of states established or maintained in MR/CA/HA 638 * The number of MNNs supported by MR/CA/HA 640 o More? 642 11. Acknowledgement 644 We sincerely thank Alexandru Petrescu, Thierry Ernst, Pascal Thubert, 645 Carlos Jess Bernardos Cano and Masafumi Watari for their comments and 646 valuable suggestions. 648 12 References 650 [1] Ernst, T., "Network Mobility Support Goals and Requirements", 651 draft-ietf-nemo-requirements-02 (work in progress), February 652 2004. 654 [2] Ernst, T. and H-Y. Lach, "Network Mobility Support 655 Terminology", draft-ietf-nemo-terminology-01 (work in 656 progress), February 2004. 658 [3] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet, 659 "Network Mobility (NEMO) Basic Support Protocol", IETF proposed 660 standard, draft-ietf-nemo-basic-support-03, June 2004. 662 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 663 IPv6", RFC 3775, June 2004. 665 [5] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in 666 Network Mobility Support", 667 draft-ietf-nemo-multihoming-issues-00 (work in progress), July 668 2004. 670 [6] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 671 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 672 Agents", RFC 3776, June 2004. 674 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 675 Levels", RFC 2119, March 1997. 677 [8] Thubert, P., Molteni, M., Ng, C., Ohnishi, H. and E. Paik, 678 "Taxonomy of Route Optimization models in the Nemo Context", 679 draft-thubert-nemo-ro-taxonomy-02 (work in progress), February 680 2004. 682 [9] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 683 its application to Mobile Networks", 684 draft-thubert-nemo-reverse-routing-header-05 (work in 685 progress), June 2004. 687 [10] Watari, M. and T. Ernst, "Route Optimization with Nested 688 Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in 689 progress), October 2004. 691 Authors' Addresses 693 Fan Zhao 694 University of California, Davis 695 University of California, Davis 696 One Shield Avenue 697 Davis, CA 95616 698 US 700 Phone: +1 530 752 3128 701 EMail: fanzhao@ucdavis.edu 703 S. Felix Wu 704 University of California, Davis 705 University of California, Davis 706 One Shield Avenue 707 Davis, CA 95616 708 US 710 Phone: +1 530 754 7070 711 EMail: sfwu@ucdavis.edu 713 Souhwan Jung 714 Soongsil University 715 Soongsil University 716 1-1, Sangdo-dong, Dongjak-ku 717 Seoul 156-743 718 KOREA 720 Phone: +82 2 820 0714 721 EMail: souhwanj@ssu.ac.kr 723 Intellectual Property Statement 725 The IETF takes no position regarding the validity or scope of any 726 Intellectual Property Rights or other rights that might be claimed to 727 pertain to the implementation or use of the technology described in 728 this document or the extent to which any license under such rights 729 might or might not be available; nor does it represent that it has 730 made any independent effort to identify any such rights. Information 731 on the procedures with respect to rights in RFC documents can be 732 found in BCP 78 and BCP 79. 734 Copies of IPR disclosures made to the IETF Secretariat and any 735 assurances of licenses to be made available, or the result of an 736 attempt made to obtain a general license or permission for the use of 737 such proprietary rights by implementers or users of this 738 specification can be obtained from the IETF on-line IPR repository at 739 http://www.ietf.org/ipr. 741 The IETF invites any interested party to bring to its attention any 742 copyrights, patents or patent applications, or other proprietary 743 rights that may cover technology that may be required to implement 744 this standard. Please address the information to the IETF at 745 ietf-ipr@ietf.org. 747 Disclaimer of Validity 749 This document and the information contained herein are provided on an 750 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 751 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 752 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 753 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 754 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 755 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Copyright Statement 759 Copyright (C) The Internet Society (2004). This document is subject 760 to the rights, licenses and restrictions contained in BCP 78, and 761 except as set forth therein, the authors retain all their rights. 763 Acknowledgment 765 Funding for the RFC Editor function is currently provided by the 766 Internet Society.