idnits 2.17.1 draft-bernardos-mext-miron-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 945. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 963. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 969. 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 -- 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 7, 2008) is 5772 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-08 ** Obsolete normative reference: RFC 5268 (ref. '7') (Obsoleted by RFC 5568) == Outdated reference: A later version (-04) exists of draft-ietf-mext-aero-reqs-02 == Outdated reference: A later version (-08) exists of draft-ietf-mip6-cn-ipsec-07 == Outdated reference: A later version (-02) exists of draft-ietf-mext-nemo-ro-automotive-req-00 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group C. Bernardos 3 Internet-Draft M. Calderon 4 Intended status: Experimental I. Soto 5 Expires: January 8, 2009 UC3M 6 July 7, 2008 8 Mobile IPv6 Route Optimisation for Network Mobility (MIRON) 9 draft-bernardos-mext-miron-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 8, 2009. 36 Abstract 38 The Network Mobility Basic Support protocol enables networks to roam 39 and attach to different access networks without disrupting the 40 ongoing sessions that nodes of the network may have. By extending 41 the Mobile IPv6 support to Mobile Routers, nodes of the network are 42 not required to support any kind of mobility, since packets must go 43 through the Mobile Router-Home Agent (MRHA) bi-directional tunnel. 44 Communications from/to a mobile network have to traverse the Home 45 Agent, and therefore better paths may be available. Additionally, 46 this solution adds packet overhead, due to the encapsulation. 48 This document describes an approach to the Route Optimisation for 49 NEMO, called Mobile IPv6 Route Optimisation for NEMO (MIRON). MIRON 50 enables mobility-agnostic nodes within the mobile network to directly 51 communicate (i.e. without traversing the MRHA bi-directional tunnel) 52 with Correspondent Nodes. The solution is based on the Mobile Router 53 performing the Mobile IPv6 Route Optimisation signalling on behalf of 54 the nodes of the mobile network. 56 This document (in an appendix) also analyses how MIRON fits each of 57 the currently identified NEMO Route Optimisation requirements for 58 Operational Use in Aeronautics and Space Exploration. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [1]. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Mobile Router operation . . . . . . . . . . . . . . . . . . . 8 71 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 8 72 3.2. Performing Route Optimisation . . . . . . . . . . . . . . 9 73 4. Home Agent, Local Fixed Node and Correspondent Node 74 operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 82 Appendix A. Analysis of MIRON and the Aeronautics requirements . 13 83 A.1. Req1 - Separability . . . . . . . . . . . . . . . . . . . 14 84 A.2. Req2 - Multihoming . . . . . . . . . . . . . . . . . . . . 14 85 A.3. Req3 - Latency . . . . . . . . . . . . . . . . . . . . . . 15 86 A.4. Req4 - Availability . . . . . . . . . . . . . . . . . . . 15 87 A.5. Req5 - Packet Loss . . . . . . . . . . . . . . . . . . . . 16 88 A.6. Req6 - Scalability . . . . . . . . . . . . . . . . . . . . 16 89 A.7. Req7 - Efficient Signaling . . . . . . . . . . . . . . . . 17 90 A.8. Req8 - Security . . . . . . . . . . . . . . . . . . . . . 18 91 A.9. Req9 - Adaptability . . . . . . . . . . . . . . . . . . . 18 92 A.10. Des1 - Configuration . . . . . . . . . . . . . . . . . . . 19 93 A.11. Des2 - Nesting . . . . . . . . . . . . . . . . . . . . . . 19 94 A.12. Des3 - System Impact . . . . . . . . . . . . . . . . . . . 19 95 A.13. Des4 - VMN Support . . . . . . . . . . . . . . . . . . . . 20 96 A.14. Des5 - Generality . . . . . . . . . . . . . . . . . . . . 20 97 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 99 Intellectual Property and Copyright Statements . . . . . . . . . . 22 101 1. Introduction 103 This document assumes that the reader is familiar with the 104 terminology related to Network Mobility [9] and [10] (Figure 1), and 105 with the Mobile IPv6 [2] and NEMO Basic Support [3] protocols. 107 The goals of the Network Mobility (NEMO) Support are described in 108 [11]. Basically, the main goal is to enable networks to move while 109 preserving the communications of their nodes (Mobile Network Nodes, 110 or MNNs), without requiring any mobility support on them. The NEMO 111 Basic Support protocol [3] consists on setting a bi-directional 112 tunnel (Figure 2) between the Mobile Router (MR) of the network (that 113 connects the mobile network to the Internet) and its Home Agent 114 (located at the Home Network of the mobile network). This is 115 basically the Bi-directional Tunnel (BT) operation of Mobile IPv6 116 (MIPv6) [2], but without supporting Route Optimisation. Actually, 117 the protocol extends the existing MIPv6 Binding Update (BU) message 118 to inform the Home Agent (HA) of the current location of the mobile 119 network (i.e. the MR's Care-of Address, CoA), through which the HA 120 has to forward the packets addressed to the network prefix managed by 121 the MR (Mobile Network Prefix, or MNP). 123 --------- 124 | HA_MR | 125 --------- 126 | 127 ------ +-----------+---------+ 128 | CN |----| Internet | 129 ------ +---+-----------------+ 130 | 131 ------ ------------------------------ 132 | AR | | AR: Access Router | 133 ------ | CN: Correspondent Node | 134 | | MR: Mobile Router | 135 ===?========== | HA_MR: MR's Home Agent | 136 MR | MNP: Mobile Network Prefix | 137 | | MNN: Mobile Network Node | 138 ===|========|====(MNP) ------------------------------ 139 MNN MNN 141 Figure 1: Basic scenario of Network Mobility 143 Because of the bi-directional tunnel that is established between HA 144 and MR to transparently enable the movement of networks, the NEMO 145 Basic Support protocol introduces the following limitations: 146 o It forces suboptimal routing (known as angular or triangular 147 routing), since packets are always forwarded through the HA 148 following a suboptimal path and therefore adding a delay in the 149 packet delivery. 150 o It introduces non-negligible packet overhead, reducing the Path 151 MTU (PMTU). An additional IPv6 header (40 bytes) is added to 152 every packet because of the MRHA bi-directional tunnel. 153 o The HA becomes a bottleneck of the communication. This is 154 because, even if a direct path is available between a MNN and a 155 CN, the NEMO Basic Support protocol forces traffic to follow the 156 CN-HA=MR-MNN path. This may cause the Home Link to be congested, 157 resulting in some packets discarded. 159 In order to overcome such limitations, it is necessary to provide 160 what have been called Route Optimisation for NEMO [12], [13], [14], 161 [15]. In Mobile IPv6, the Route Optimisation is achieved by allowing 162 the Mobile Node (MN) to send Binding Update messages also to the CNs. 163 In this way the CN is also aware of the CoA where the MN's Home 164 Address (HoA) is currently reachable. The Return Routability (RR) 165 procedure is defined to authenticate new CoAs that the MN may use, 166 thus securing the change that the CN makes in the IPv6 destination 167 address (using the MN's CoA) of the packets it sends addressed to the 168 MN's HoA [16]. 170 __ _____ __ ___ 171 | | | | | | | | 172 |CN| |HA_MR| |MR| |MNN| 173 |__| |_____| |__| |___| 174 | | | | 175 | ------------ | ------------------------------ | ------------ | 176 | |S:CN,D:MNN| | |S:HA_MR,D:MR_CoA[S:CN,D:MNN]| | |S:CN,D:MNN| | 177 | | DATA | | | DATA | | | DATA | | 178 | ------------ | ------------------------------ | ------------ | 179 |-------------->|-------------------------------->|-------------->| 180 | | | | 181 | ------------ | ------------------------------ | ------------ | 182 | |S:MNN,D:CN| | |S:MR_CoA,D:HA_MR[S:MNN,D:CN]| | |S:MNN,D:CN| | 183 | | DATA | | | DATA | | | DATA | | 184 | ------------ | ------------------------------ | ------------ | 185 |<--------------|<--------------------------------|<--------------| 186 | | | | 188 Figure 2: NEMO Basic Support protocol 190 This document describes a Route Optimisation solution for nodes of a 191 mobile network that do not have (or use) any kind of mobility 192 support, that is, the so-called Local Fixed Nodes (LFNs). The 193 solution enables direct path communication between an LFN and a CN, 194 without requiring any change on the operation of CNs nor LFNs. In 195 order to do that, the MR performs all the Route Optimisation 196 signalling and mobility tasks defined by Mobile IPv6 on behalf of the 197 LFNs attached to the mobile network. 199 2. Protocol Overview 201 The mechanism, called Mobile IPv6 Route Optimisation for NEMO 202 (MIRON), essentially consists in enabling a MR to behave as a proxy 203 for nodes that do not have any kind of mobility support (i.e. LFNs), 204 performing the Mobile IPv6 Route Optimisation signalling and packet 205 handling on behalf of the LFNs. 207 In order to enable packets to be directly routed between the CN and 208 the LFN (avoiding the MRHA tunnel), the MR sends a MIPv6 Binding 209 Update message on behalf of the LFN, binding the LFN's address to the 210 MR's CoA. 212 Mobile IPv6 requires an additional security procedure to be performed 213 before actually sending a Binding Update message to a certain CN (and 214 therefore enabling the Route Optimisation between MN and CN). 215 Basically, this procedure, called Return Routability (RR) -- needed 216 in order to mitigate possible security concerns [16] -- is used to 217 verify that the MN, besides being reachable at the HoA, is also able 218 to send/respond to packets sent to a given address (different to its 219 HoA). This mechanism can be deceived only if the routing 220 infrastructure is compromised or if there is an attacker between the 221 verifier node and the CoA (HoA and CoA) that are being verified. 222 With these exceptions, the test is used to ensure that the MN's Home 223 Address (HoA) and MN's Care-of Address (CoA) are collocated. 225 Since MIRON proposes the MR to behave as a "proxy" (Figure 3), the MR 226 has to perform the Mobile IPv6 Return Routability procedure on behalf 227 of the LFNs. This involves the MR sending the Home Test Init (HoTI) 228 and Care-of Test Init (CoTI) messages to the CN and processing the 229 replies (Home Test message HoT -- and Care-of Test message -- CoT). 230 These messages are sent as specified in [2], using the LFN's address 231 as the source address in the HoTI message -- which is sent 232 encapsulated through the MR's HA --, and the MR's CoA as the source 233 address in the CoTI message. With the information contained in the 234 HoT and CoT messages, sent by the CN in response to the HoTI and CoTI 235 messages respectively, the MR is able to build a BU message to be 236 sent to the CN on behalf of the LFN. This message is sent using the 237 MR's CoA as the packet source address and carries a Home Address 238 destination option set to the LFN's address. 240 Once the Return Routability procedure has been done and the MR has 241 sent the BU message -- binding the address of the LFN (belonging to 242 the MR's MNP) to the MR's CoA -- packets between the CN and the LFN 243 do not follow the suboptimal CN-HA=MR-LFN path anymore, but the CN- 244 MR-LFN optimised route (Figure 4). This signalling has to be 245 repeated periodically, as specified by MIPv6 IPv6 (the RR procedure 246 has to be repeated at least every 7 minutes, to avoid time-shifting 247 attacks). 249 __ _____ __ ___ 250 | | | | | | | | 251 |CN| |HA_MR| |MR| |LFN| 252 |__| |_____| |__| |___| 253 | | | | 254 | ------------ | ------------------------------ | | 255 | |S:LFN,D:CN| | |S:MR_CoA,D:HA_MR[S:LFN,D:CN]| | | 256 | | HoTI | | | HoTI | | | 257 | ------------ | ------------------------------ | | 258 |<-----------------|<--------------------------------| | 259 | | --------------- | | 260 | | |S:MR_CoA,D:CN| | | 261 | | | CoTI | | | 262 | | --------------- | | 263 |<---------------------------------------------------| | 264 | | | | 265 | ------------ | ------------------------------ | | 266 | |S:CN,D:LFN| | |S:HA_MR,D:MR_CoA[S:CN,D:LFN]| | | 267 | | HoT | | | HoT | | | 268 | ------------ | ------------------------------ | | 269 |----------------->|-------------------------------->| | 270 | --------------- | | | 271 | |S:CN,D:MR_CoA| | | | 272 | | CoT | | | | 273 | --------------- | | | 274 |--------------------------------------------------->| | 275 | | | | 276 | | --------------- | | 277 | | |S:MR_CoA,D:CN| | | 278 | | | BU(HoA:LFN) | | | 279 | | --------------- | | 280 |<---------------------------------------------------| | 281 | | | | 283 Figure 3: MIRON signalling 285 In addition to generating and receiving all the signalling related to 286 Route Optimisation on behalf of the LFNs, the MR has also to process 287 the "route optimised" packets sent by/directed to the LFNs 288 (Figure 4): 289 o Packets sent by a CN are addressed to the MR's CoA and contain 290 IPv6 extension headers (a type 2 Routing Header) that are not 291 understood by the LFN. Therefore, the MR has to change the 292 destination address and remove the routing header before 293 delivering the packet to the LFN. 294 o Packets sent by an LFN have to be also processed. The MR, in 295 order to be able to send packets directly to the CN, has to use 296 its CoA as source address of the packets and has also to add a 297 Home Address destination option to every packet (set to the LFN's 298 address). 300 __ _____ __ ___ 301 | | | | | | | | 302 |CN| |HA_MR| |MR| |LFN| 303 |__| |_____| |__| |___| 304 | | | | 305 | --------------- | | | 306 | |S:CN,D:MR_CoA| | | ------------ | 307 | | RH (NH:LFN) | | | |S:CN,D:LFN| | 308 | | DATA | | | | DATA | | 309 | --------------- | | ------------ | 310 |-------------------------------------------->|-------------->| 311 | | | | 312 | | --------------- | | 313 | | |S:MR_CoA,D:CN| | ------------ | 314 | | | HoA:LFN | | |S:LFN,D:CN| | 315 | | | DATA | | | DATA | | 316 | | --------------- | ------------ | 317 |<--------------------------------------------|<--------------| 318 | | | | 320 Figure 4: MIRON packet handling (Route Optimised operation) 322 3. Mobile Router operation 324 The Mobile Router operation defined by the NEMO Basic Support 325 protocol [3] is extended in order to be able to generate and process 326 the Mobile IPv6 Route Optimisation signalling (i.e. Return 327 Routability and Binding Update) [2], since the MR is behaving as a 328 "Proxy-MR" for their LFNs. 330 3.1. Data Structures 332 In addition to the data structures defined in [3], the MR need also 333 to maintain the following information: 334 o The MR extends the Binding Update List (BUL) to contain also some 335 information per each LFN-CN communication that is being optimised. 336 Basically the added fields are those described in [2] that are 337 related to the Route Optimisation procedure defined by Mobile IPv6 338 (such as IP addresses of CNs, binding lifetimes, Return 339 Routability state, etc.), since the MR is behaving as Proxy-MR for 340 the LFNs attached to it. 341 o The BUL is not indexed only by the address of the CN, since there 342 is a different binding per each CN-LFN pair. Therefore, the LFN's 343 address has to be also included in every BUL entry. 345 3.2. Performing Route Optimisation 347 Since the proposed optimisation has to be done per each LFN-CN 348 communication, the MR should track the different ongoing 349 communications that attached LFNs may have, in order to identify 350 potential LFN-CN communications that may be worth optimising. Due to 351 the fact that optimising a certain LFN-CN communication involves a 352 cost -- in terms of signalling and computation resources at the MR -- 353 it may not be worth to perform such a optimisation to some kinds of 354 flows (e.g., DNS queries). The decision about whether to perform 355 Route Optimisation to a certain LFN-CN communication or not is out of 356 the scope of this document. 358 Per each LFN-CN communication that has been decided to be route 359 optimised, the MR has to perform the following actions: 360 o The MR performs the Return Routability procedure as described in 361 Section 2. 362 o The MR sends a MIPv6 Binding Update message to the CN on behalf of 363 the LFN. The BU contains the address of the LFN as the MN's Home 364 Address (HoA) and the MR's CoA as the MN's CoA (the MR's CoA is 365 the only address that is reachable without requiring any agent to 366 be deployed to forward packets to the current location of the 367 mobile network). This procedure binds the LFN's address to the 368 MR's CoA at the CN (i.e. an entry is added at the CN's Binding 369 Cache). 370 o The MR processes every packet received from the CN as follows: 371 * These packets carry the MR's CoA as destination address, and 372 also carry a Type 2 Routing Header with the LFN's address as 373 next hop. The MR processes the Routing Header of the packet, 374 checking if the next hop address belongs to one of its LFNs 375 and, if so, delivering the packet to the LFN. 376 o The MR processes every packet received from the LFN as follows: 377 * The MR's CoA is set as IPv6 source address. 378 * An IPv6 Home Address destination option, carrying the address 379 of the LFN, is inserted. 381 When MIRON is used to perform RO for a certain LFN-CN communication, 382 the resulting PMTU of the path between LFN and CN might be bigger 383 than the one when the MRHA tunnel is used. A MIRON MR implementation 384 MAY decide to modify ICMPv6 Packet Too Big messages [4], [5] to 385 include in the MTU field a value that takes into account the 24-byte 386 overhead of MIRON (due to the Routing Header and Home Address 387 destination option) instead of the 40-byte overhead added when the 388 MRHA bi-directional tunnel is used (due to the IPv6-in-IPv6 389 encapsulation). 391 4. Home Agent, Local Fixed Node and Correspondent Node operation 393 The operation of the Home Agent, the Local Fixed Nodes and the 394 Correspondent Nodes remains unchanged. The only requirement is that 395 CNs must implement the Correspondent Node part of the Route 396 Optimisation defined by Mobile IPv6 (Section 9 of [2]). 398 5. Conclusions 400 This document describes a Route Optimisation for NEMO for LFN-CN 401 flows. The MR performs all the Route Optimisation tasks on behalf of 402 the LFNs that are attached to it. This involves generating and 403 processing all the related signalling (that is, the Return 404 Routability procedure and the Binding Update message), but also 405 handling the packets sent and received by the LFNs, in order to 406 enable the direct CN-MR-LFN route (avoiding the suboptimal CN-HA=MR- 407 LFN path) without requiring any change on the operation of CNs nor 408 LFNs. 410 The Route Optimisation here described is intended for LFN-CN 411 communications in a non-nested NEMO. However, nothing prevents this 412 solution to be also applied in a nested NEMO, avoiding the last 413 tunnel, or even all the tunnels if the MR is provided somehow with a 414 topologically valid IPv6 address that is reachable without traversing 415 any HAs (for example, as described in [17]). 417 MIRON has been implemented [18] within the framework of the European 418 DAIDALOS project (http://www.ist-daidalos.org). The implementation 419 of the NEMO Basic Support protocol of MR and HA and the MIRON code at 420 the MR have been done for Linux (2.6 kernel), mostly at user space 421 (in C). The implementation used at the CNs is MIPL-2.0 422 (http://wwww.mobile-ipv6.org). 424 Conducted tests [17] show that the performance obtained with MIRON is 425 much better -- in terms of latency and effective TCP throughput -- 426 than the obtained by the NEMO Basic Support protocol, specially when 427 the "distance" (i.e. RTT) between the HA and the CN is increased. 429 6. Security Considerations 431 Because an LFN trusts its MR for the routing of all its traffic (both 432 for inbound and outbound packets), allowing the MR to perform some 433 signalling and processing on behalf of the LFNs attached to it does 434 not introduce any new threat. From the architectural point of view, 435 the solution is also natural, since the Route Optimisation support 436 defined by Mobile IPv6 [2] conceptually could be implemented in 437 multiple boxes. MIRON just applies this mechanism, by splitting the 438 mobility functions among two different physical boxes, but actually 439 the conceptual basis of the solution is the same as the one defined 440 by Mobile IPv6. 442 7. IANA Considerations 444 This document has no actions for IANA. 446 8. Acknowledgements 448 Marcelo Bagnulo provided text for an earlier version of this draft. 450 The authors would like to thank Erik Nordmark and Pascal Thubert for 451 their valuable comments. We also thank Antonio de la Oliva for 452 implementing a first prototype of MIRON. 454 The work of Carlos J. Bernardos, Maria Calderon and Ignacio Soto 455 described in this Internet-Draft is based on results of IST FP6 456 Integrated Projects DAIDALOS I & II. DAIDALOS I & II receive 457 research funding from the European Community's Sixth Framework 458 Programme. Apart from this, the European Commission has no 459 responsibility for the content of this Internet-Draft. The 460 information in this document is provided as is and no guarantee or 461 warranty is given that the information is fit for any particular 462 purpose. The user thereof uses the information at its sole risk and 463 liability. 465 The work of Carlos J. Bernardos and Maria Calderon has been also 466 partly supported by the Spanish Government under the POSEIDON 467 (TSI2006-12507-C03-01) project. 469 9. References 471 9.1. Normative References 473 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 474 Levels", BCP 14, RFC 2119, March 1997. 476 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 477 IPv6", RFC 3775, June 2004. 479 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 480 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 481 January 2005. 483 [4] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for 484 IP version 6", RFC 1981, August 1996. 486 [5] Conta, A., Deering, S., and M. Gupta, "Internet Control Message 487 Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) 488 Specification", RFC 4443, March 2006. 490 [6] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 491 "Multiple Care-of Addresses Registration", 492 draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. 494 [7] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. 496 [8] Perkins, C., "Securing Mobile IPv6 Route Optimization Using a 497 Static Shared Key", RFC 4449, June 2006. 499 9.2. Informative References 501 [9] Manner, J. and M. Kojo, "Mobility Related Terminology", 502 RFC 3753, June 2004. 504 [10] Ernst, T. and H-Y. Lach, "Network Mobility Support 505 Terminology", RFC 4885, July 2007. 507 [11] Ernst, T., "Network Mobility Support Goals and Requirements", 508 RFC 4886, July 2007. 510 [12] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 511 Route Optimization Problem Statement", RFC 4888, July 2007. 513 [13] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility 514 Route Optimization Solution Space Analysis", RFC 4889, 515 July 2007. 517 [14] Zhao, F., "NEMO Route Optimization Problem Statement and 518 Analysis", draft-zhao-nemo-ro-ps-01 (work in progress), 519 February 2005. 521 [15] Thubert, P., Molteni, M., and C. Ng, "Taxonomy of Route 522 Optimization models in the Nemo Context", 523 draft-thubert-nemo-ro-taxonomy-04 (work in progress), 524 February 2005. 526 [16] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 527 Nordmark, "Mobile IP Version 6 Route Optimization Security 528 Design Background", RFC 4225, December 2005. 530 [17] Calderon, M., Bernardos, C., Bagnulo, M., Soto, I., and A. de 531 la Oliva, "MIRON: Mobile IPv6 Route Optimization for NEMO", 532 IEEE Journal on Selected Areas in Communications (J-SAC), issue 533 on Mobile Routers and Network Mobility, Volume 24, Number 9, 534 pp. 1702-1716 , September 2006. 536 [18] Bernardos, C., de la Oliva, A., Calderon, M., von Hugo, D., and 537 H. Kahle, "NEMO: Network Mobility. Bringing ubiquity to the 538 Internet access", IEEE INFOCOM 2006 demonstration, Barcelona , 539 April 2006. 541 [19] Eddy, W., Ivancic, W., and T. Davis, "NEMO Route Optimization 542 Requirements for Operational Use in Aeronautics and Space 543 Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02 544 (work in progress), May 2008. 546 [20] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of 547 Multihoming in Network Mobility Support", RFC 4980, 548 October 2007. 550 [21] Dupont, F. and J. Combes, "Using IPsec between Mobile and 551 Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec-07 (work in 552 progress), February 2008. 554 [22] Baldessari, R., Ernst, T., and M. Lenardi, "Automotive Industry 555 Requirements for NEMO Route Optimization", 556 draft-ietf-mext-nemo-ro-automotive-req-00 (work in progress), 557 February 2008. 559 [23] Ng, C., Hirano, J., Petrescu, A., and E. Paik, "Consumer 560 Electronics Requirements for Network Mobility Route 561 Optimization", draft-ng-nemo-ce-req-02 (work in progress), 562 February 2008. 564 Appendix A. Analysis of MIRON and the Aeronautics requirements 566 This appendix looks at the Aeronautics requirements described in [19] 567 and analyses how MIRON fits each of them. If a certain requirement 568 cannot be fulfilled by MIRON as it is described in this document, 569 possible modifications/extensions are also considered. This analysis 570 aims at understanding if MIRON could be a good candidate to be used 571 as a NEMO RO solution for the aeronautics scenario. 573 This appendix only analyses those requirements that involve LFNs, 574 since the MIRON solution described here does only address the Route 575 Optimisation of LFN-CN communications. For those requirements 576 involving VMNs, an extended MIRON solution should be applied, such as 577 the one described in [17]. 579 A.1. Req1 - Separability 581 This requirement basically states that "an RO scheme MUST support 582 configuration by a per-domain dynamic RO policy database. Entries in 583 this database can be similar to those used in IPsec security policy 584 databases in order to specify either bypassing or utilizing RO for 585 specific flows". 587 This requirement is fulfilled by MIRON, since the Route Optimisation 588 is performed in a per-flow basis and the decision about which flows 589 are optimised is taken by the MR. Therefore, different approaches 590 can be implemented in the MR (it is open to the particular MIRON 591 implementation how to do it) to take this decision: static and 592 dynamic policies (using a protocol to update MR's policies), 593 decisions based on current load of the MR, etc. 595 A.2. Req2 - Multihoming 597 This requirement states that "an RO solution MUST support an MR 598 having multiple interfaces, and MUST allow a given domain to be bound 599 to a specific interface. It MUST be possible to use different MNPs 600 for different domains". 602 In MIRON, RO is achieved by the MR performing all the MIPv6-RO 603 operations on behalf of connected LFNs. Therefore, MIRON can 604 potentially benefit directly from any mechanism developed for MIPv6 605 to support multiple interfaces. For example, MIRON could use the 606 Multiple-CoA mechanism [6] to enable an MR register different CoAs at 607 CNs. It is also perfectly possible to support different MNPs for 608 different domains, since the MR can manage the RO also with a per-MNP 609 granularity. 611 We should also mention that although MIRON can benefit from 612 multihoming solutions developed within the MEXT WG, multihoming 613 issues in Network Mobility [20] should be tackled specifically by a 614 general NEMO multihoming framework. Since MIRON does not modify in 615 any way the NEMO Basic Support operation, it will also be compatible 616 with such a general NEMO multihoming solution. 618 A.3. Req3 - Latency 620 This requirement says: "while an RO solution is in the process of 621 setting up or reconfiguring, packets of specified flows MUST be 622 capable of using the MRHA tunnel". 624 This means that an RO solution MUST NOT prevent data packets from 625 being forwarded through the MRHA bi-directional tunnel while the 626 required RO operations are being performed. This requirement is also 627 fulfilled by MIRON, since while the MR performs all the MIPv6-RO 628 operations on behalf of LFNs, their communications still use the MRHA 629 tunnel. 631 A.4. Req4 - Availability 633 This requirement states that "an RO solution MUST be compatible with 634 network redundancy mechanisms and MUST NOT prevent fall-back to the 635 MRHA tunnel if an element in an optimized path fails". It is also 636 stated that "an RO mechanism MUST NOT add any new single point of 637 failure for communications in general". 639 This requirement requires special attention to be achieved by MIRON. 640 On the one hand, current NEMO Basic Support protocol [3] does not 641 fulfil that today, and therefore needs additional work to be carried- 642 out. On the other hand, if we focus only on MIRON availability, the 643 following are the potential points of failure that should be tackled: 644 o Home Agent: a failure of the Home Agent -- in addition to 645 disrupting communications that are being forwarded using the MRHA 646 bi-directional tunnel -- could also cause Route Optimised 647 communications to stop, since the Return Routability procedure 648 (which is part of the MIPv6-RO mechanism) performed by the MR on 649 behalf of LFNs requires the MRHA tunnel to be up. This Return 650 Routability procedure should be repeated every seven minutes 651 (MAX_RR_BINDING_LIFETIME=420 seconds) to avoid time-shifting 652 attacks, and therefore, depending on how long a Home Agent is down 653 and when the failure happens, route optimised communications might 654 be affected. This issue is actually not introduced by MIRON, 655 hence it could be avoided by using a general redundancy mechanism 656 aimed for the NEMO Basic Support protocol. 657 o Mobile Router: a failure of the MR would obviously disrupt 658 established connections in a single-MR NEMO. In the case of a 659 multiple-MR NEMO, additional mechanisms would be required in order 660 to guarantee that route optimised communications managed by a 661 particular MR would survive in case this MR fails. Although MIRON 662 currently does not address this issue, additional mechanisms -- 663 such as deploying back-to-back MRs in aircrafts or designing/ 664 reusing existing protocols to keep the RO state of several MRs 665 synchronised -- might be used here. 667 o Home Network reachability: in case of single-homed NEMOs, if the 668 Home Network is not reachable, traffic through the MRHA bi- 669 directional tunnel will be disrupted. Additionally, Return 670 Routability checks performed by a MIRON MR on behalf of attached 671 LFNs would also fail. Again, this issue is not introduced by 672 MIRON, hence it needs to be addressed by a general redundancy 673 mechanism suited for the NEMO Basic Support protocol. 675 A.5. Req5 - Packet Loss 677 This requirement says that "an RO scheme SHOULD NOT cause either loss 678 or duplication of data packets during RO path establishment, usage, 679 or transition, above that caused in the NEMO basic support case. An 680 RO scheme MUST NOT itself create non-transient losses and 681 duplications within a packet stream". 683 It takes longer to finish a handover of a route optimised flow using 684 MIRON than a normal NEMO Basic Support protocol handover, due to the 685 additional RTT required to complete the MIPv6-RO signalling with CNs. 686 If this additional RTT component in the overall handover delay is 687 considered too much for a certain application, either this 688 application could not use MIRON to provide NEMO RO or a make-before- 689 break solution would be needed. Note that extending MIRON to support 690 existing micromobility solutions -- such as Fast Handovers for Mobile 691 IPv6 [7] -- would not require too much additional work, since MIRON 692 basically re-uses standard MIPv6 mechanisms. 694 Alternatively, MIRON may decide to perform packet bi-casting and send 695 route optimised traffic also through the MRHA bi-directional tunnel, 696 during the time required to finish the MIPv6-RO signalling with CNs. 697 That would allow not to lose any additional packets in the LFN-CN 698 direction, but traffic from the CN would not be received by the LFN 699 until the RO signalling has been completed. Therefore, this solution 700 would only alleviate the problem for outbound packets and would 701 require to take care of duplicated packets. 703 A.6. Req6 - Scalability 705 This requirement says that "an RO scheme MUST be simultaneously 706 usable by the MNNs on hundreds of thousands of craft without 707 overloading the ground network or routing system. This explicitly 708 forbids injection of BGP routes into the global Internet for purposes 709 of RO". 711 Basically, there are three different aspects that may affect to the 712 scalability of MIRON: 714 o Memory consumption at the MR. MIRON needs some additional 715 information to be stored at the MR, such extended BUL (since state 716 information regarding each LFN-CN optimised pair is required). 717 The required memory to store a BUL entry is relatively small and 718 grows linearly with the number of LFN-CN route optimised pairs. 719 o Processing load at the MR. MIRON requires the MR to perform some 720 additional operations: inspection of every packet and special 721 handling (that is, removal of the Routing Header in the CN-to-LFN 722 direction and addition of the Home Address destination option in 723 the LFN-to-CN direction) of route optimised packets. Regarding 724 packet inspection, MIRON just needs to look at the source and 725 destination addresses of every packet to track LFN-CN flows, so 726 this inspection is quite similar to the normal inspection that a 727 router does. Even if some local policies are implemented at the 728 MR to enable smarter decisions about whether a certain flow should 729 be optimised or not -- requiring the MR to look also at other 730 fields in a packet (such as transport headers) -- this inspection 731 is not much different than the inspection than typical firewall 732 software does in a border (access) router. 733 o Impact on the global routing system. MIRON does not have any 734 impact on the global routing tables, and therefore it does not 735 introduce any routing scalability issue, even with large 736 deployments. 738 We can conclude that MIRON required resources grow linearly with the 739 number of optimisations being performed, and that these required 740 resources do not impose any constraint for modern available routers. 741 Besides, MIRON does not impact in any way the global routing system. 743 A.7. Req7 - Efficient Signaling 745 This requirement is related to the additional signalling required by 746 a NEMO RO solution, and basically states that "an RO scheme MUST be 747 capable of efficient signaling in terms of both size and number of 748 individual signaling messages and the ensemble of signaling messages 749 that may simultaneously be triggered by concurrent flows". 751 With MIRON, in order to optimise a CN-LFN flow, the MR has to perform 752 the MIPv6-RO signalling with the CN on behalf of the LFN. This 753 signalling grows linearly with the number of CN-LFN pairs being 754 optimised. In order to optimise an LFN-CN flow, the RR signalling 755 (HoTI+CoTI+HoT+CoT) plus a Binding Update message should be sent 756 every seven minutes. This means that 6.4 bps are required to keep 757 each LFN-CN flow route optimised (without the MR moving). A NEMO 758 that changes its point of attachment very frequently -- although this 759 is not likely to happen in aircraft scenarios -- would require more 760 signalling/support less optimised flows. 762 Another interesting metric is the data traffic overhead. MIRON 763 introduces a 24-byte per packet overhead in every route optimised 764 data packet, because of the Routing Header type 2 (added by the CN to 765 the data packets sent to an LFN) and the Home Address destination 766 option (added by the MR to the data packets sent by the LFN). 767 Actually, the overhead introduced by MIRON is 16-byte less than the 768 the overhead introduced by the NEMO Basic Support protocol, and 769 therefore this means that MIRON reduces the overhead when compared 770 with the NEMO non-optimised scenario. 772 A.8. Req8 - Security 774 This requirement is different depending on the considered traffic 775 domain. For ATS/AOS domains, there are three sub-requirements: "a) 776 The RO scheme MUST NOT further expose MNPs on the wireless link than 777 already is the case for NEMO basic support; b) The RO scheme MUST 778 permit the receiver of a BU to validate an MR's ownership of the CoAs 779 claimed by an MR; and c) The RO scheme MUST ensure that only 780 explicitly authorized MRs are able to perform a binding update for a 781 specific MNP". For the PIES domain: "there are no additional 782 requirements beyond those of normal Internet services and the same 783 requirements for normal Mobile IPv6 RO apply". 785 MIRON does not meet -- without further modification, such as 786 extending it to support solutions like [8], [21]-- requirements a) 787 and c). In order to support those, RO signalling might need to be 788 encrypted, thus requiring some security trust relationship between 789 the MR and the CN (this is not considered as reasonable nowadays, 790 though). On the other hand, MIRON supports requirement b), as this 791 check is already performed by the RR procedure. 793 Regarding the requirements for the PIES domain, MIRON fulfils them, 794 since this is already provided by MIPv6 RO security. 796 A.9. Req9 - Adaptability 798 This requirement states that "applications using new transport 799 protocols, IPsec, or new IP options MUST be possible within an RO 800 scheme". 802 In addition to RO decisions taken based on the lifetime of current 803 communications (e.g., every data communication flow involving more 804 packets than a particular threshold is route optimised), MIRON MAY 805 make use of information about higher layer protocols to classify 806 between flows that prefer the MRHA tunnel or a route optimised path. 807 Depending on the mechanisms used to feed the decision intelligence 808 mechanism at the MR, it might be required to perform some 809 reconfiguration actions on MRs in order to enable new applications 810 and/or protocols benefit from RO. However, the use of unexpected/new 811 higher layer protocols and/or applications would not make MIRON fail, 812 but just revert on using the MRHA bi-directional tunnel for those 813 flows that cannot be classified using existing filters/policies at 814 the MR. 816 Regarding the particular issue of IPsec use, MIRON supports to route 817 optimise communications that use IPsec ESP data traffic, since the 818 ESP header comes after the Routing Header and Home Address 819 destination option, and therefore MIRON does not affect ESP 820 semantics. However, if IPsec AH is used in an LFN-CN communication, 821 outbound (from the LFN to the CN) AH packets need to be reverse- 822 tunnelled through the MRHA tunnel instead of being forwarded 823 following the RO path, since adding the Home Address destination 824 option would affect the AH integrity check. For inbound packets, 825 there is no problem, since the MR just advances the source route and 826 LFN can process these packets normally, without affecting AH 827 semantics. 829 A.10. Des1 - Configuration 831 This requirement is not considered as a strict one, and basically 832 states that "it is desirable that a NEMO RO solution be as simple to 833 configure as possible and also easy to automatically disable if an 834 undesirable state is reached". 836 MIRON configuration is not detailed in this document, since it is 837 open to implementation. However, even if complex policies are used 838 to determine which communication flows/applications are route 839 optimised, MIRON configuration would be as simple as configuring 840 today's firewalls. A MIRON MR does not require more configuration 841 than a MIPv6 MN. 843 A.11. Des2 - Nesting 845 This requirement is not considered as a strict one, and basically 846 states that "it is desirable if the RO mechanism supports RO for 847 nested MRs". 849 MIRON, as it is described in this document, does not provide RO 850 capabilities for nested MRs. However, it can be extended to support 851 also these configurations. [17] describes one possible way of doing 852 that. 854 A.12. Des3 - System Impact 856 This requirement is not considered as a strict one, and basically 857 states that "low complexity in systems engineering and configuration 858 management is desirable in building and maintaining systems using the 859 RO mechanism". 861 Since MIRON RO solution only requires changes on the MR, deploying 862 MIRON is extremely easy in terms of global system impact. Only the 863 MR is required to be configured, maintained and updated. 865 A.13. Des4 - VMN Support 867 This requirement is not considered as a strict one, and basically 868 states that "it is strongly desirable for VMNs to be supported by the 869 RO technique, but not strictly required". 871 As previously mentioned, this document has only described MIRON 872 operation to optimise LFN-CN traffic flows. An extended MIRON 873 version, such as the one described in [17], could be used to provide 874 VMNs with Route Optimisation. 876 A.14. Des5 - Generality 878 This requirement is not considered as a strict one, and basically 879 states that "an RO mechanism that is "general purpose", in that it is 880 also readily usable in other contexts outside of aeronautics and 881 space exploration, is desirable". 883 MIRON has been designed as a general NEMO RO framework, not being 884 focused to address any particular scenario, but to be broadly-scoped. 885 Therefore, MIRON could also be considered as a solution for other 886 scenarios such as the vehicular [22] or consumer electronics ones 887 [23]. 889 Appendix B. Change Log 891 Changes from nemo-miron-01 to mext-miron-00: 892 o "Analysis of MIRON and the Aeronautics requirements" appendix 893 updated as required by the latest available version of [19]. 894 o References updated. 895 o Some text cleanup and minor changes. 897 Changes from nemo-miron-00 to nemo-miron-01: 898 o Added appendix "Analysis of MIRON and the Aeronautics 899 requirements". 900 o Some text cleanup and minor changes. 902 Authors' Addresses 904 Carlos J. Bernardos 905 Universidad Carlos III de Madrid 906 Av. Universidad, 30 907 Leganes, Madrid 28911 908 Spain 910 Phone: +34 91624 6236 911 Email: cjbc@it.uc3m.es 913 Maria Calderon 914 Universidad Carlos III de Madrid 915 Av. Universidad, 30 916 Leganes, Madrid 28911 917 Spain 919 Phone: +34 91624 8780 920 Email: maria@it.uc3m.es 922 Ignacio Soto 923 Universidad Carlos III de Madrid 924 Av. Universidad, 30 925 Leganes, Madrid 28911 926 Spain 928 Phone: +34 91624 5974 929 Email: isoto@it.uc3m.es 931 Full Copyright Statement 933 Copyright (C) The IETF Trust (2008). 935 This document is subject to the rights, licenses and restrictions 936 contained in BCP 78, and except as set forth therein, the authors 937 retain all their rights. 939 This document and the information contained herein are provided on an 940 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 941 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 942 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 943 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 944 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 945 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 947 Intellectual Property 949 The IETF takes no position regarding the validity or scope of any 950 Intellectual Property Rights or other rights that might be claimed to 951 pertain to the implementation or use of the technology described in 952 this document or the extent to which any license under such rights 953 might or might not be available; nor does it represent that it has 954 made any independent effort to identify any such rights. Information 955 on the procedures with respect to rights in RFC documents can be 956 found in BCP 78 and BCP 79. 958 Copies of IPR disclosures made to the IETF Secretariat and any 959 assurances of licenses to be made available, or the result of an 960 attempt made to obtain a general license or permission for the use of 961 such proprietary rights by implementers or users of this 962 specification can be obtained from the IETF on-line IPR repository at 963 http://www.ietf.org/ipr. 965 The IETF invites any interested party to bring to its attention any 966 copyrights, patents or patent applications, or other proprietary 967 rights that may cover technology that may be required to implement 968 this standard. Please address the information to the IETF at 969 ietf-ipr@ietf.org.