idnits 2.17.1 draft-bernardos-nemo-miron-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 927. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 951. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == 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: This means that an RO solution MUST not prevent data packets from being forwarded through the MRHA bi-directional tunnel while the required RO operations are being performed. This requirement is also fulfilled by MIRON, since while the MR performs all the MIPv6-RO operations on behalf of LFNs, their communications still use the MRHA tunnel. -- 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 9, 2007) is 6135 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 1981 (ref. '4') (Obsoleted by RFC 8201) == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-02 ** Obsolete normative reference: RFC 4068 (ref. '7') (Obsoleted by RFC 5268) == Outdated reference: A later version (-02) exists of draft-eddy-nemo-aero-reqs-01 == Outdated reference: A later version (-08) exists of draft-ietf-mip6-cn-ipsec-04 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group C. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental M. Bagnulo 5 Expires: January 10, 2008 Huawei Lab at UC3M 6 M. Calderon 7 I. Soto 8 UC3M 9 July 9, 2007 11 Mobile IPv6 Route Optimisation for Network Mobility (MIRON) 12 draft-bernardos-nemo-miron-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 24 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 January 10, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 The Network Mobility Basic Support protocol enables networks to roam 46 and attach to different access networks without disrupting the 47 ongoing sessions that nodes of the network may have. By extending 48 the Mobile IPv6 support to Mobile Routers, nodes of the network are 49 not required to support any kind of mobility, since packets must go 50 through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. 51 Communications from/to a mobile network have to traverse the Home 52 Agent, and therefore better paths may be available. Additionally, 53 this solution adds packet overhead, due to the encapsulation. 55 This document describes an approach to the Route Optimisation for 56 NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON 57 enables mobility-agnostic nodes within the mobile network to directly 58 communicate (i.e. without traversing the MRHA bi-directional tunnel) 59 with Correspondent Nodes. The solution is based on the Mobile Router 60 performing the Mobile IPv6 Route Optimisation signalling on behalf of 61 the nodes of the mobile network. 63 This document (in an appendix) also analyses how MIRON fits each of 64 the NEMO RO Aeronautics requirements. 66 Requirements Language 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119 [1]. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Mobile Router operation . . . . . . . . . . . . . . . . . . . 8 77 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 8 78 3.2. Performing Route Optimisation . . . . . . . . . . . . . . 9 79 4. Home Agent, Local Fixed Node and Correspondent Node 80 operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 88 Appendix A. Analysis of MIRON and the Aeronautics requirements . 13 89 A.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 14 90 A.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 14 91 A.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 14 92 A.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 15 93 A.5. Req5 - Integrity . . . . . . . . . . . . . . . . . . . . . 15 94 A.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 16 95 A.7. Req7 - Throughput . . . . . . . . . . . . . . . . . . . . 17 96 A.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 18 97 A.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 18 98 A.10. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 18 99 A.11. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 19 100 A.12. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 19 101 A.13. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 19 102 A.14. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 19 103 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 105 Intellectual Property and Copyright Statements . . . . . . . . . . 22 107 1. Introduction 109 This document assumes that the reader is familiar with the 110 terminology related to Network Mobility [9] and [10] (Figure 1), and 111 with the Mobile IPv6 [2] and NEMO Basic Support [3] protocols. 113 The goals of the Network Mobility (NEMO) Support are described in 114 [11]. Basically, the main goal is to enable networks to move while 115 preserving the communications of their nodes (Mobile Network Nodes, 116 or MNNs), without requiring any mobility support on them. The NEMO 117 Basic Support protocol [3] consists on setting a bi-directional 118 tunnel (Figure 2) between the Mobile Router (MR) of the network (that 119 connects the mobile network to the Internet) and its Home Agent 120 (located at the Home Network of the mobile network). This is 121 basically the Bi-directional Tunnel (BT) operation of Mobile IPv6 122 (MIPv6) [2], but without supporting Route Optimisation. Actually, 123 the protocol extends the existing MIPv6 Binding Update (BU) message 124 to inform the Home Agent (HA) of the current location of the mobile 125 network (i.e. the MR's Care-of Address, CoA), through which the HA 126 has to forward the packets addressed to the network prefix managed by 127 the MR (Mobile Network Prefix, or MNP). 129 --------- 130 | HA_MR | 131 --------- 132 | 133 ------ +-----------+---------+ 134 | CN |----| Internet | 135 ------ +---+-----------------+ 136 | 137 ------ ------------------------------ 138 | AR | | AR: Access Router | 139 ------ | CN: Correspondent Node | 140 | | MR: Mobile Router | 141 ===?========== | HA_MR: MR's Home Agent | 142 MR | MNP: Mobile Network Prefix | 143 | | MNN: Mobile Network Node | 144 ===|========|====(MNP) ------------------------------ 145 MNN MNN 147 Figure 1: Basic scenario of Network Mobility 149 Because of the bi-directional tunnel that is established between HA 150 and MR to transparently enable the movement of networks, the NEMO 151 Basic Support protocol introduces the following limitations: 152 o It forces suboptimal routing (known as angular or triangular 153 routing), since packets are always forwarded through the HA 154 following a suboptimal path and therefore adding a delay in the 155 packet delivery. 156 o It introduces non-negligible packet overhead, reducing the Path 157 MTU (PMTU). An additional IPv6 header (40 bytes) is added to 158 every packet because of the MRHA bi-directional tunnel. 159 o The HA becomes a bottleneck of the communication. This is 160 because, even if a direct path is available between a MNN and a 161 CN, the NEMO Basic Support protocol forces traffic to follow the 162 CN-HA=MR-MNN path. This may cause the Home Link to be congested, 163 resulting in some packets discarded. 165 In order to overcome such limitations, it is necessary to provide 166 what have been called Route Optimisation for NEMO [12], [13], [14], 167 [15]. In Mobile IPv6, the Route Optimisation is achieved by allowing 168 the Mobile Node (MN) to send Binding Update messages also to the CNs. 169 In this way the CN is also aware of the CoA where the MN's Home 170 Address (HoA) is currently reachable. The Return Routability (RR) 171 procedure is defined to authenticate new CoAs that the MN may use, 172 thus securing the change that the CN makes in the IPv6 destination 173 address (using the MN's CoA) of the packets it sends addressed to the 174 MN's HoA [16]. 176 __ _____ __ ___ 177 | | | | | | | | 178 |CN| |HA_MR| |MR| |MNN| 179 |__| |_____| |__| |___| 180 | | | | 181 | ------------ | ------------------------------ | ------------ | 182 | |S:CN,D:MNN| | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]| | |S:CN,D:MNN| | 183 | | DATA | | | DATA | | | DATA | | 184 | ------------ | ------------------------------ | ------------ | 185 |-------------->|-------------------------------->|-------------->| 186 | | | | 187 | ------------ | ------------------------------ | ------------ | 188 | |S:MNN,D:CN| | |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| | |S:MNN,D:CN| | 189 | | DATA | | | DATA | | | DATA | | 190 | ------------ | ------------------------------ | ------------ | 191 |<--------------|<--------------------------------|<--------------| 192 | | | | 194 Figure 2: NEMO Basic Support protocol 196 This document describes a Route Optimisation solution for nodes of a 197 mobile network that do not have (or use) any kind of mobility 198 support, that is, the so-called Local Fixed Nodes (LFNs). The 199 solution enables direct path communication between an LFN and a CN, 200 without requiring any change on the operation of CNs nor LFNs. In 201 order to do that, the MR performs all the Route Optimisation 202 signalling and mobility tasks defined by Mobile IPv6 on behalf of the 203 LFNs attached to the mobile network. 205 2. Protocol Overview 207 The mechanism, called Mobile IPv6 Route Optimisation for NEMO 208 (MIRON), essentially consists in enabling a MR to behave as a proxy 209 for nodes that do not have any kind of mobility support (i.e. LFNs), 210 performing the Mobile IPv6 Route Optimisation signalling and packet 211 handling on behalf of the LFNs. 213 In order to enable packets to be directly routed between the CN and 214 the LFN (avoiding the MRHA tunnel), the MR sends a MIPv6 Binding 215 Update message on behalf of the LFN, binding the LFN's address to the 216 MR's CoA. 218 Mobile IPv6 requires an additional security procedure to be performed 219 before actually sending a Binding Update message to a certain CN (and 220 therefore enabling the Route Optimisation between MN and CN). 221 Basically, this procedure, called Return Routability (RR) -- needed 222 in order to mitigate possible security concerns [16] -- is used to 223 verify that the MN, besides being reachable at the HoA, is also able 224 to send/respond to packets sent to a given address (different to its 225 HoA). This mechanism can be deceived only if the routing 226 infrastructure is compromised or if there is an attacker between the 227 verifier node and the CoA (HoA and CoA) that are being verified. 228 With these exceptions, the test is used to ensure that the MN's Home 229 Address (HoA) and MN's Care-of Address (CoA) are collocated. 231 Since MIRON proposes the MR to behave as a "proxy" (Figure 3), the MR 232 has to perform the Mobile IPv6 Return Routability procedure on behalf 233 of the LFNs. This involves the MR sending the Home Test Init (HoTI) 234 and Care-of Test Init (CoTI) messages to the CN and processing the 235 replies (Home Test message HoT -- and Care-of Test message -- CoT). 236 These messages are sent as specified in [2], using the LFN's address 237 as the source address in the HoTI message -- which is sent 238 encapsulated through the MR's HA --, and the MR's CoA as the source 239 address in the CoTI message. With the information contained in the 240 HoT and CoT messages, sent by the CN in response to the HoTI and CoTI 241 messages respectively, the MR is able to build a BU message to be 242 sent to the CN on behalf of the LFN. This message is sent using the 243 MR's CoA as the packet source address and carries a Home Address 244 destination option set to the LFN's address. 246 Once the Return Routability procedure has been done and the MR has 247 sent the BU message -- binding the address of the LFN (belonging to 248 the MR's MNP) to the MR's CoA -- packets between the CN and the LFN 249 do not follow the suboptimal CN-HA=MR-LFN path anymore, but the CN- 250 MR-LFN optimised route (Figure 4). This signalling has to be 251 repeated periodically, as specified by MIPv6 IPv6 (the RR procedure 252 has to be repeated at least every 7 minutes, to avoid time-shifting 253 attacks). 255 __ _____ __ ___ 256 | | | | | | | | 257 |CN| |HA_MR| |MR| |LFN| 258 |__| |_____| |__| |___| 259 | | | | 260 | ------------ | ------------------------------ | | 261 | |S:LFN,D:CN| | |S:MR_CoA,D:HA_MR[S:LFN,D:CN]| | | 262 | | HoTI | | | HoTI | | | 263 | ------------ | ------------------------------ | | 264 |<-----------------|<--------------------------------| | 265 | | --------------- | | 266 | | |S:MR_CoA,D:CN| | | 267 | | | CoTI | | | 268 | | --------------- | | 269 |<---------------------------------------------------| | 270 | | | | 271 | ------------ | ------------------------------ | | 272 | |S:CN,D:LFN| | |S:HA_MR,D:MR_CoA[S:CN,D:LFN]| | | 273 | | HoT | | | HoT | | | 274 | ------------ | ------------------------------ | | 275 |----------------->|-------------------------------->| | 276 | --------------- | | | 277 | |S:CN,D:MR_CoA| | | | 278 | | CoT | | | | 279 | --------------- | | | 280 |--------------------------------------------------->| | 281 | | | | 282 | | --------------- | | 283 | | |S:MR_CoA,D:CN| | | 284 | | | BU(HoA:LFN) | | | 285 | | --------------- | | 286 |<---------------------------------------------------| | 287 | | | | 289 Figure 3: MIRON signalling 291 In addition to generating and receiving all the signalling related to 292 Route Optimisation on behalf of the LFNs, the MR has also to process 293 the "route optimised" packets sent by/directed to the LFNs 294 (Figure 4): 295 o Packets sent by a CN are addressed to the MR's CoA and contain 296 IPv6 extension headers (a type 2 Routing Header) that are not 297 understood by the LFN. Therefore, the MR has to change the 298 destination address and remove the routing header before 299 delivering the packet to the LFN. 300 o Packets sent by an LFN have to be also processed. The MR, in 301 order to be able to send packets directly to the CN, has to use 302 its CoA as source address of the packets and has also to add a 303 Home Address destination option to every packet (set to the LFN's 304 address). 306 __ _____ __ ___ 307 | | | | | | | | 308 |CN| |HA_MR| |MR| |LFN| 309 |__| |_____| |__| |___| 310 | | | | 311 | --------------- | | | 312 | |S:CN,D:MR_CoA| | | ------------ | 313 | | RH (NH:LFN) | | | |S:CN,D:LFN| | 314 | | DATA | | | | DATA | | 315 | --------------- | | ------------ | 316 |-------------------------------------------->|-------------->| 317 | | | | 318 | | --------------- | | 319 | | |S:MR_CoA,D:CN| | ------------ | 320 | | | HoA:LFN | | |S:LFN,D:CN| | 321 | | | DATA | | | DATA | | 322 | | --------------- | ------------ | 323 |<--------------------------------------------|<--------------| 324 | | | | 326 Figure 4: MIRON packet handling (Route Optimised operation) 328 3. Mobile Router operation 330 The Mobile Router operation defined by the NEMO Basic Support 331 protocol [3] is extended in order to be able to generate and process 332 the Mobile IPv6 Route Optimisation signalling (i.e. Return 333 Routability and Binding Update) [2], since the MR is behaving as a 334 "Proxy-MR" for their LFNs. 336 3.1. Data Structures 338 In addition to the data structures defined in [3], the MR need also 339 to maintain the following information: 340 o The MR extends the Binding Update List (BUL) to contain also some 341 information per each LFN-CN communication that is being optimised. 342 Basically the added fields are those described in [2] that are 343 related to the Route Optimisation procedure defined by Mobile IPv6 344 (such as IP addresses of CNs, binding lifetimes, Return 345 Routability state, etc.), since the MR is behaving as Proxy-MR for 346 the LFNs attached to it. 347 o The BUL is not indexed only by the address of the CN, since there 348 is a different binding per each CN-LFN pair. Therefore, the LFN's 349 address has to be also included in every BUL entry. 351 3.2. Performing Route Optimisation 353 Since the proposed optimisation has to be done per each LFN-CN 354 communication, the MR should track the different ongoing 355 communications that attached LFNs may have, in order to identify 356 potential LFN-CN communications that may be worth optimising. Due to 357 the fact that optimising a certain LFN-CN communication involves a 358 cost -- in terms of signalling and computation resources at the MR -- 359 it may not be worth to perform such a optimisation to some kinds of 360 flows (e.g., DNS queries). The decision about whether to perform 361 Route Optimisation to a certain LFN-CN communication or not is out of 362 the scope of this document. 364 Per each LFN-CN communication that has been decided to be route 365 optimised, the MR has to perform the following actions: 366 o The MR performs the Return Routability procedure as described in 367 Section 2. 368 o The MR sends a MIPv6 Binding Update message to the CN on behalf of 369 the LFN. The BU contains the address of the LFN as the MN's Home 370 Address (HoA) and the MR's CoA as the MN's CoA (the MR's CoA is 371 the only address that is reachable without requiring any agent to 372 be deployed to forward packets to the current location of the 373 mobile network). This procedure binds the LFN's address to the 374 MR's CoA at the CN (i.e. an entry is added at the CN's Binding 375 Cache). 376 o The MR processes every packet received from the CN as follows: 377 * These packets carry the MR's CoA as destination address, and 378 also carry a Type 2 Routing Header with the LFN's address as 379 next hop. The MR processes the Routing Header of the packet, 380 checking if the next hop address belongs to one of its LFNs 381 and, if so, delivering the packet to the LFN. 382 o The MR processes every packet received from the LFN as follows: 383 * The MR's CoA is set as IPv6 source address. 384 * An IPv6 Home Address destination option, carrying the address 385 of the LFN, is inserted. 387 When MIRON is used to perform RO for a certain LFN-CN communication, 388 the resulting PMTU of the path between LFN and CN might be bigger 389 than the one when the MRHA tunnel is used. A MIRON MR implementation 390 MAY decide to modify ICMPv6 Packet Too Big messages [4], [5] to 391 include in the MTU field a value that takes into account the 24-byte 392 overhead of MIRON (due to the Routing Header and Home Address 393 destination option) instead of the 40-byte overhead added when the 394 MRHA bi-directional tunnel is used (due to the IPv6-in-IPv6 395 encapsulation). 397 4. Home Agent, Local Fixed Node and Correspondent Node operation 399 The operation of the Home Agent, the Local Fixed Nodes and the 400 Correspondent Nodes remains unchanged. The only requirement is that 401 CNs must implement the Correspondent Node part of the Route 402 Optimisation defined by Mobile IPv6 (Section 9 of [2]). 404 5. Conclusions 406 This document describes a Route Optimisation for NEMO for LFN-CN 407 flows. The MR performs all the Route Optimisation tasks on behalf of 408 the LFNs that are attached to it. This involves generating and 409 processing all the related signalling (that is, the Return 410 Routability procedure and the Binding Update message), but also 411 handling the packets sent and received by the LFNs, in order to 412 enable the direct CN-MR-LFN route (avoiding the suboptimal CN-HA=MR- 413 LFN path) without requiring any change on the operation of CNs nor 414 LFNs. 416 The Route Optimisation here described is intended for LFN-CN 417 communications in a non-nested NEMO. However, nothing prevents this 418 solution to be also applied in a nested NEMO, avoiding the last 419 tunnel, or even all the tunnels if the MR is provided somehow with a 420 topologically valid IPv6 address that is reachable without traversing 421 any HAs (for example, as described in [17]). 423 MIRON has been implemented [18] within the framework of the European 424 DAIDALOS project (http://www.ist-daidalos.org). The implementation 425 of the NEMO Basic Support protocol of MR and HA and the MIRON code at 426 the MR have been done for Linux (2.6 kernel), mostly at user space 427 (in C). The implementation used at the CNs is MIPL-2.0 428 (http://wwww.mobile-ipv6.org). 430 Conducted tests [17] show that the performance obtained with MIRON is 431 much better -- in terms of latency and effective TCP throughput -- 432 than the obtained by the NEMO Basic Support protocol, specially when 433 the "distance" (i.e. RTT) between the HA and the CN is increased. 435 6. Security Considerations 437 Because an LFN trusts its MR for the routing of all its traffic (both 438 for inbound and outbound packets), allowing the MR to perform some 439 signalling and processing on behalf of the LFNs attached to it does 440 not introduce any new threat. From the architectural point of view, 441 the solution is also natural, since the Route Optimisation support 442 defined by Mobile IPv6 [2] conceptually could be implemented in 443 multiple boxes. MIRON just applies this mechanism, by splitting the 444 mobility functions among two different physical boxes, but actually 445 the conceptual basis of the solution is the same as the one defined 446 by Mobile IPv6. 448 7. IANA Considerations 450 This document has no actions for IANA. 452 8. Acknowledgements 454 The authors would like to thank Erik Nordmark and Pascal Thubert for 455 their valuable comments. We also thank Antonio de la Oliva for 456 implementing a first prototype of MIRON. 458 The work of Carlos J. Bernardos, Maria Calderon and Ignacio Soto 459 described in this Internet-Draft is based on results of IST FP6 460 Integrated Projects DAIDALOS I & II. DAIDALOS I & II receive 461 research funding from the European Community's Sixth Framework 462 Programme. Apart from this, the European Commission has no 463 responsibility for the content of this Internet-Draft. The 464 information in this document is provided as is and no guarantee or 465 warranty is given that the information is fit for any particular 466 purpose. The user thereof uses the information at its sole risk and 467 liability. 469 The work of Carlos J. Bernardos, Maria Calderon and Ignacio Soto has 470 been also partly supported by the Spanish Government under the 471 POSEIDON (TSI2006-12507-C03-01) project. 473 9. References 475 9.1. Normative References 477 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 478 Levels", BCP 14, RFC 2119, March 1997. 480 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 481 IPv6", RFC 3775, June 2004. 483 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 484 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 485 January 2005. 487 [4] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 488 IP version 6", RFC 1981, August 1996. 490 [5] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 491 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 492 Specification", RFC 4443, March 2006. 494 [6] Wakikawa, R., "Multiple Care-of Addresses Registration", 495 draft-ietf-monami6-multiplecoa-02 (work in progress), 496 March 2007. 498 [7] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 499 July 2005. 501 [8] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a 502 Static Shared Key", RFC 4449, June 2006. 504 9.2. Informative References 506 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 507 RFC 3753, June 2004. 509 [10] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 510 draft-ietf-nemo-terminology-06 (work in progress), 511 November 2006. 513 [11] Ernst, T., "Network Mobility Support Goals and Requirements", 514 draft-ietf-nemo-requirements-06 (work in progress), 515 November 2006. 517 [12] Ng, C., "Network Mobility Route Optimization Problem 518 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 519 progress), September 2006. 521 [13] Ng, C., "Network Mobility Route Optimization Solution Space 522 Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in 523 progress), September 2006. 525 [14] Zhao, F., "NEMO Route Optimization Problem Statement and 526 Analysis", draft-zhao-nemo-ro-ps-01 (work in progress), 527 February 2005. 529 [15] Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route 530 Optimization models in the Nemo Context", 531 draft-thubert-nemo-ro-taxonomy-04 (work in progress), 532 February 2005. 534 [16] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 535 Nordmark, "Mobile IP Version 6 Route Optimization Security 536 Design Background", RFC 4225, December 2005. 538 [17] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. de 539 la Oliva, "MIRON: Mobile IPv6 Route Optimization for NEMO", 540 IEEE Journal on Selected Areas in Communications (J-SAC), issue 541 on Mobile Routers and Network Mobility, Volume 24, Number 9, 542 pp. 1702-1716 , September 2006. 544 [18] Bernardos, C., de la Oliva, A., Calderon, M., von Hugo, D., and 545 H. Kahle, "NEMO: Network Mobility. Bringing ubiquity to the 546 Internet access", IEEE INFOCOM 2006 demonstration, Barcelona , 547 April 2006. 549 [19] Eddy, W., "NEMO Route Optimization Requirements for Operational 550 Use in Aeronautics and Space Exploration Mobile Networks", 551 draft-eddy-nemo-aero-reqs-01 (work in progress), July 2007. 553 [20] Ng, C., "Analysis of Multihoming in Network Mobility Support", 554 draft-ietf-nemo-multihoming-issues-07 (work in progress), 555 February 2007. 557 [21] Dupont, F. and J. Combes, "Using IPsec between Mobile and 558 Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec-04 (work in 559 progress), March 2007. 561 [22] Baldessari, R., "C2C-C Consortium Requirements for Usage of 562 NEMO in VANETs", draft-baldessari-c2ccc-nemo-req-01 (work in 563 progress), July 2007. 565 Appendix A. Analysis of MIRON and the Aeronautics requirements 567 This appendix looks at the Aeronautics requirements described in [19] 568 and analyses how MIRON fits each of them. If a certain requirement 569 cannot be fulfilled by MIRON as it is described in this document, 570 possible modifications/extensions are also considered. This analysis 571 aims at understanding if MIRON could be a good candidate to be used 572 as a NEMO RO solution for the aeronautics scenario. 574 This appendix only analyses those requirements that involve LFNs, 575 since the MIRON solution described here does only address the Route 576 Optimisation of LFN-CN communications. For those requirements 577 involving VMNs, an extended MIRON solution should be applied, such as 578 the one described in [17]. 580 A.1. Req1 - Separability 582 This requirement basically states that a NEMO "RO scheme MUST have 583 the ability to be bypassed by applications that desire to use bi- 584 directional tunnels through an HA". 586 This requirement is fulfilled by MIRON, since the Route Optimisation 587 is performed in a per-flow basis and the decision about which flows 588 are optimised is taken by the MR. Therefore, different approaches 589 can be implemented in the MR (it is open to the particular MIRON 590 implementation how to do it) to take this decision: static and 591 dynamic policies (using a protocol to update MR's policies), 592 decisions based on current load of the MR, etc. 594 A.2. Req2 - Multihoming 596 This requirement states that "RO schemes MUST permit an MR to be 597 simultaneously connected to multiple access networks, having multiple 598 prefixes and Care-Of Addresses in a MONAMI6 context". 600 In MIRON, RO is achieved by the MR performing all the MIPv6-RO 601 operations on behalf of connected LFNs. Therefore, MIRON can 602 potentially benefit directly from any mechanism developed in the 603 MONAMI6 WG. For example, MIRON could use Multiple-CoA mechanism [6] 604 to enable an MR register different CoAs at CNs. 606 We should also mention that although MIRON can benefit from 607 multihoming solutions developed within the MONAMI6 WG, multihoming 608 issues in Network Mobility [20] should be tackled specifically by a 609 general NEMO multihoming framework. Since MIRON does not modify in 610 any way the NEMO Basic Support operation, it will also be compatible 611 with such a general NEMO multihoming solution. 613 A.3. Req3 - Latency 615 This requirement says: "an RO solution MUST be capable of configuring 616 and reconfiguring itself (and reconfiguring after mobility events) 617 without blocking unoptimized packet flow during its initiation and 618 before or after transitions in the active access links". 620 This means that an RO solution MUST not prevent data packets from 621 being forwarded through the MRHA bi-directional tunnel while the 622 required RO operations are being performed. This requirement is also 623 fulfilled by MIRON, since while the MR performs all the MIPv6-RO 624 operations on behalf of LFNs, their communications still use the MRHA 625 tunnel. 627 A.4. Req4 - Availability 629 This requirement states that "an RO solution MUST NOT imply a single 630 point of failure, whether that be a single MR, a single HA, or other 631 point within the ground network". 633 This requirement requires special attention to be achieved by MIRON. 634 On the one hand, current NEMO Basic Support protocol [3] does not 635 fulfil that today, and therefore needs additional work to be carried- 636 out. On the other hand, if we focus only on MIRON availability, the 637 following are the potential points of failure that should be tackled: 638 o Home Agent: a failure of the Home Agent -- in addition to 639 disrupting communications that are being forwarded using the MRHA 640 bi-directional tunnel -- could also cause Route Optimised 641 communications to stop, since the Return Routability procedure 642 (which is part of the MIPv6-RO mechanism) performed by the MR on 643 behalf of LFNs requires the MRHA tunnel to be up. This Return 644 Routability procedure should be repeated every seven minutes 645 (MAX_RR_BINDING_LIFETIME=420 seconds) to avoid time-shifting 646 attacks, and therefore, depending on how long a Home Agent is down 647 and when the failure happens, route optimised communications might 648 be affected. This issue is actually not introduced by MIRON, 649 hence it could be avoided by using a general redundancy mechanism 650 aimed for the NEMO Basic Support protocol. 651 o Mobile Router: a failure of the MR would obviously disrupt 652 established connections in a single-MR NEMO. In the case of a 653 multiple-MR NEMO, additional mechanisms would be required in order 654 to guarantee that route optimised communications managed by a 655 particular MR would survive in case this MR fails. Although MIRON 656 currently does not address this issue, additional mechanisms -- 657 such as deploying back-to-back MRs in aircrafts or designing/ 658 reusing existing protocols to keep the RO state of several MRs 659 synchronised -- might be used here. 660 o Home Network reachability: in case of single-homed NEMOs, if the 661 Home Network is not reachable, traffic through the MRHA bi- 662 directional tunnel will be disrupted. Additionally, Return 663 Routability checks performed by a MIRON MR on behalf of attached 664 LFNs would also fail. Again, this issue is not introduced by 665 MIRON, hence it needs to be addressed by a general redundancy 666 mechanism suited for the NEMO Basic Support protocol. 668 A.5. Req5 - Integrity 670 The Integrity requirement says: "an RO scheme MUST NOT cause packets 671 to be dropped at any point in operation, when they would not normally 672 have been dropped in a non-RO configuration". 674 It takes longer to finish a handover of a route optimised flow using 675 MIRON than a normal NEMO Basic Support protocol handover, due to the 676 additional RTT required to complete the MIPv6-RO signalling with CNs. 677 If this additional RTT component in the overall handover delay is 678 considered too much for a certain application, either this 679 application could not use MIRON to provide NEMO RO or a make-before- 680 break solution would be needed. Note that extending MIRON to support 681 existing micromobility solutions -- such as Fast Handovers for Mobile 682 IPv6 [7] -- would not require too much additional work, since MIRON 683 basically re-uses standard MIPv6 mechanisms. 685 Alternatively, MIRON may decide to perform packet bi-casting and send 686 route optimised traffic also through the MRHA bi-directional tunnel, 687 during the time required to finish the MIPv6-RO signalling with CNs. 688 That would allow not to lose any additional packets in the LFN-CN 689 direction, but traffic from the CN would not be received by the LFN 690 until the RO signalling has been completed. Therefore, this solution 691 would only alleviate the problem for outbound packets. 693 A.6. Req6 - Scalability 695 This requirement says that "an RO scheme MUST be simultaneously 696 usable by ten thousand nodes without overloading the ground network 697 or routing system". 699 Basically, there are two different aspects that may affect to the 700 scalability of MIRON: 701 o Memory consumption at the MR. MIRON needs some additional 702 information to be stored at the MR, such extended BUL (since state 703 information regarding each LFN-CN optimised pair is required). 704 The required memory to store a BUL entry is relatively small and 705 grows linearly with the number of LFN-CN route optimised pairs. 706 o Processing load at the MR. MIRON requires the MR to perform some 707 additional operations: inspection of every packet and special 708 handling (that is, removal of the Routing Header in the CN-to-LFN 709 direction and addition of the Home Address destination option in 710 the LFN-to-CN direction) of route optimised packets. Regarding 711 packet inspection, MIRON just needs to look at the source and 712 destination addresses of every packet to track LFN-CN flows, so 713 this inspection is quite similar to the normal inspection that a 714 router does. Even if some local policies are implemented at the 715 MR to enable smarter decisions about whether a certain flow should 716 be optimised or not -- requiring the MR to look also at other 717 fields in a packet (such as transport headers) -- this inspection 718 is not much different than the inspection than typical firewall 719 software does in a border (access) router. 720 o Impact on the global routing system. MIRON does not have any 721 impact on the global routing tables, and therefore it does not 722 introduce any routing scalability issue, even with large 723 deployments. 725 We can conclude that MIRON required resources grow linearly with the 726 number of optimisations being performed, and that these required 727 resources do not impose any constraint for modern available routers. 728 Besides, MIRON does not impact in any way the global routing system. 730 A.7. Req7 - Throughput 732 This requirement is related to the additional signalling required by 733 a NEMO RO solution, and basically states that "an RO scheme MUST be 734 capable of operating on traffic streams with individual rates up to 5 735 Mbps, and aggregates of 50 Mbps, while accounting for less than 9.6 736 kbps of bandwidth for its own signaling overhead". 738 MIRON's overhead comes from two different components: 739 o Signalling load. In order to optimise a CN-LFN flow, the MR has 740 to perform the MIPv6-RO signalling with the CN on behalf of the 741 LFN. This signalling grows linearly with the number of CN-LFN 742 pairs being optimised. In order to optimise an LFN-CN flow, the 743 RR signalling (HoTI+CoTI+HoT+CoT) plus a Binding Update message 744 should be sent every seven minutes. This means that 6.4 bps are 745 required to keep each LFN-CN flow route optimised (without the MR 746 moving), and therefore, 1500 LFN-CN flows can be optimised with 747 9.6 kbps. Obviously, previous numbers have been calculated 748 without considering MR's movements, hence a NEMO that changes its 749 point of attachment very frequently -- although this is not likely 750 to happen in aircraft scenarios -- would support less optimised 751 flows. 752 o Data traffic overhead. MIRON introduces a 24-byte per packet 753 overhead in every route optimised data packet, because of the 754 Routing Header type 2 (added by the CN to the data packets sent to 755 an LFN) and the Home Address destination option (added by the MR 756 to the data packets sent by the LFN). Actually, the overhead 757 introduced by MIRON is 16-byte less than the the overhead 758 introduced by the NEMO Basic Support protocol, and therefore this 759 means that MIRON reduces the overhead when compared with the NEMO 760 non-optimised scenario. 762 MIRON's overhead shows to be low enough to achieve target numbers 763 provided in [19], although it would obviously depend on which 764 communication flows are required to be route optimised. 765 Additionally, [19] indicates that those numbers have been chosen 766 somewhat arbitrarily, and may be subject to revision. 768 A.8. Req8 - Security 770 This requirement is summarised as "IPsec MUST be usable over the RO 771 scheme, and the data used to make RO decisions MUST be authenticable 772 authenticable, perhaps using some form of IPsec". 774 MIRON supports to route optimise communications that use IPsec ESP 775 data traffic, since the ESP header comes after the Routing Header and 776 Home Address destination option, and therefore MIRON does not affect 777 ESP semantics. 779 If IPsec AH is used in an LFN-CN communication, outbound (from the 780 LFN to the CN) AH packets need to be to be reverse-tunnelled through 781 the MRHA tunnel instead of being forwarded following the RO path, 782 since adding the Home Address destination option would affect the AH 783 integrity check. For inbound packets, there is no problem, since the 784 MR just advances the source route and LFN can process these packets 785 normally, without affecting AH semantics. 787 If IPsec is preferred to secure RO signalling, MIRON could be 788 extended to support solutions like [8], [21]. 790 A.9. Req9 - Adaptability 792 This requirement states that "New applications, potentially using new 793 transport protocols or IP options MUST be possible within an RO 794 scheme". 796 In addition to RO decisions taken based on the lifetime of current 797 communications (e.g., every data communication flow involving more 798 packets than a particular threshold is route optimised), MIRON MAY 799 make use of information about higher layer protocols to classify 800 between flows that prefer the MRHA tunnel or a route optimised path. 801 Depending on the mechanisms used to feed the decision intelligence 802 mechanism at the MR, it might be required to perform some 803 reconfiguration actions on MRs in order to enable new applications 804 and/or protocols benefit from RO. However, the use of unexpected/new 805 higher layer protocols and/or applications would not make MIRON fail, 806 but just revert on using the MRHA bi-directional tunnel for those 807 flows that cannot be classified using existing filters/policies at 808 the MR. 810 A.10. Des1 - Configuration 812 This requirement is not considered as a strict one, and basically 813 states that "it is desirable that a NEMO RO solution be as simple to 814 configure as possible and also easy to automatically disable if an 815 undesirable state is reached". 817 MIRON configuration is not detailed in this document, since it is 818 open to implementation. However, even if complex policies are used 819 to determine which communication flows/applications are route 820 optimised, MIRON configuration would be as simple as configuring 821 today's firewalls. A MIRON MR does not require more configuration 822 than a MIPv6 MN. 824 A.11. Des2 - Nesting 826 This requirement is not considered as a strict one, and basically 827 states that "it is desirable if the RO mechanism supports RO for 828 nested MRs". 830 MIRON, as it is described in this document, does not provide RO 831 capabilities for nested MRs. However, it can be extended to support 832 also these configurations. [17] describes one possible way of doing 833 that. 835 A.12. Des3 - System Impact 837 This requirement is not considered as a strict one, and basically 838 states that "low complexity in systems engineering and configuration 839 management is desirable in building and maintaining systems using the 840 RO mechanism". 842 Since MIRON RO solution only requires changes on the MR, deploying 843 MIRON is extremely easy in terms of global system impact. Only the 844 MR is required to be configured, maintained and updated. 846 A.13. Des4 - VMN Support 848 This requirement is not considered as a strict one, and basically 849 states that "it is strongly desirable for VMNs to be supported by the 850 RO technique, but not strictly required". 852 As previously mentioned, this document has only described MIRON 853 operation to optimise LFN-CN traffic flows. An extended MIRON 854 version, such as the one described in [17], could be used to provide 855 VMNs with Route Optimisation. 857 A.14. Des5 - Generality 859 This requirement is not considered as a strict one, and basically 860 states that "an RO mechanism that is "general purpose", in that it is 861 also readily usable in other contexts outside of aeronautics and 862 space exploration, is desirable". 864 MIRON has been designed as a general NEMO RO framework, not being 865 focused to address any particular scenario, but to be broadly-scoped. 866 Therefore, MIRON could also be considered as a solution for other 867 scenarios such as the vehicular [22] or consumer electronics ones. 869 Appendix B. Change Log 871 Changes from -00 to -01: 872 o Added appendix "Analysis of MIRON and the Aeronautics 873 requirements". 874 o Some text cleanup and minor changes. 876 Authors' Addresses 878 Carlos J. Bernardos 879 Universidad Carlos III de Madrid 880 Av. Universidad, 30 881 Leganes, Madrid 28911 882 Spain 884 Phone: +34 91624 8859 885 Email: cjbc@it.uc3m.es 887 Marcelo Bagnulo 888 Huawei Lab at UC3M 889 Av. Universidad, 30 890 Leganes, Madrid 28911 891 Spain 893 Phone: +34 91624 8837 894 Email: marcelo@it.uc3m.es 896 Maria Calderon 897 Universidad Carlos III de Madrid 898 Av. Universidad, 30 899 Leganes, Madrid 28911 900 Spain 902 Phone: +34 91624 8780 903 Email: maria@it.uc3m.es 904 Ignacio Soto 905 Universidad Carlos III de Madrid 906 Av. Universidad, 30 907 Leganes, Madrid 28911 908 Spain 910 Phone: +34 91624 5974 911 Email: isoto@it.uc3m.es 913 Full Copyright Statement 915 Copyright (C) The IETF Trust (2007). 917 This document is subject to the rights, licenses and restrictions 918 contained in BCP 78, and except as set forth therein, the authors 919 retain all their rights. 921 This document and the information contained herein are provided on an 922 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 923 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 924 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 925 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 926 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 927 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 929 Intellectual Property 931 The IETF takes no position regarding the validity or scope of any 932 Intellectual Property Rights or other rights that might be claimed to 933 pertain to the implementation or use of the technology described in 934 this document or the extent to which any license under such rights 935 might or might not be available; nor does it represent that it has 936 made any independent effort to identify any such rights. Information 937 on the procedures with respect to rights in RFC documents can be 938 found in BCP 78 and BCP 79. 940 Copies of IPR disclosures made to the IETF Secretariat and any 941 assurances of licenses to be made available, or the result of an 942 attempt made to obtain a general license or permission for the use of 943 such proprietary rights by implementers or users of this 944 specification can be obtained from the IETF on-line IPR repository at 945 http://www.ietf.org/ipr. 947 The IETF invites any interested party to bring to its attention any 948 copyrights, patents or patent applications, or other proprietary 949 rights that may cover technology that may be required to implement 950 this standard. Please address the information to the IETF at 951 ietf-ipr@ietf.org. 953 Acknowledgment 955 Funding for the RFC Editor function is provided by the IETF 956 Administrative Support Activity (IASA).