idnits 2.17.1 draft-hampel-mext-ro-without-ha-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (Feb 23, 2011) is 4811 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 141 ** Obsolete normative reference: RFC 3775 (ref. '1') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4651 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 4225 (ref. '5') Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions for IPv6 (MEXT) G. Hampel 3 Internet Draft T. Klein 4 Intended status: Standards Track Alcatel-Lucent 5 Expires: September 27, 2011 Feb 23, 2011 7 Mobile IPv6 Route Optimization without Home Agent 8 draft-hampel-mext-ro-without-ha-00 10 Abstract 12 This document describes extensions to Mobile IPv6 (MIPv6), which 13 permit hosts to conduct route optimization (RO) without home agent. 14 These extensions add robustness and flexibility to MIPv6 since 15 mobility can be supported when the home agent becomes temporarily 16 unavailable or when home-agent support is not desirable. These 17 extensions are compliant with all peer-to-peer signaling 18 solutions that are currently supported for RO. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current 28 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 27, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Operation of Route Optimizaiton without Home Agent . . . . . . 4 57 3.1. Operations on network layer . . . . . . . . . . . . . . . 5 58 3.2. Operations on higher protocol layers . . . . . . . . . . . 6 59 3.3. Operation during unavailability of HA . . . . . . . . . . 7 60 3.4. Learning about correspondent's RO support . . . . . . . . 8 61 4. HoA Support Mobility Option . . . . . . . . . . . . . . . . . . 8 62 5. Policy Changes . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 64 7. Performance Limitations of HA-free RO . . . . . . . . . . . . . 9 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 MIPv6 Route Optimization (RO) [1] enables hosts to move between 73 networks during ongoing traffic connections, while permitting traffic 74 to flow along the shortest routing path. RO hence minimizes end-to- 75 end transport delay and it relieves the home agent (HA) from 76 the processing-intense task of relaying payload traffic. 78 During RO, the HA's relay function is still required for a variety of 79 purposes. It supports a location service in case the mobile has to be 80 reached while away from home. It further relays mobility headers sent 81 by mobile correspondents. The HA also provides an alternative path 82 for home tests when the mobile is away from home. Finally the HA's 83 relay function is used as a fallback in case the correspondent does 84 not support RO. 86 While providing these benefits, the requirement for HA support comes 87 at a certain cost: 89 - Reliability problem: The HA is a single point of failure. When it 90 becomes unavailable, RO is not supported anymore. 92 - Lack of flexibility: When the mobile does not have a HA, RO is not 93 supported at all. 95 - Packet and processing overhead: When the mobile is away from home, 96 it must use a home address (HoA) pertaining to its home link 97 to enjoy RO support. This adds significant overhead to payload 98 packets due to Type 2 Routing headers and Home Address Option 99 headers as well as processing overhead. This overhead applies even 100 if the mobile remains stationary. 102 - Additional signaling traffic: Signaling handshakes have to be 103 conducted between mobile and HA at every mobility event. 105 In many cases, the HA's relay function is not needed during RO, or it 106 is undesirable in case the cost outweighs the benefits: 108 - For traffic between mobile clients and stationary servers, the HA's 109 location service is not needed. This applies to a large fraction of 110 mobile internet traffic. Further, location service may also be 111 provided by other means such as dynamic DNS or on application layer 112 (e.g. SIP registrar). 114 - When the correspondent is mobile, it can send its mobility header 115 messages along the shortest routing path to the mobile's CoA 116 instead of using the detour via the mobile's HA. 118 - The home-test requirement does not imply the need for a HA but the 119 availability of a routable path to the mobile's HoA. Multi-homed 120 hosts that wish to migrate connections from their home link to 121 another simultaneously supported link can conduct the home test 122 without HA. If RO is secured via cryptographically generated 123 addresses (CGA) according to RFC 4866 [2], only one initial home 124 test is necessary, which can be conducted while the mobile is 125 still at home. If stronger security is used such as outlined by 126 RFC 4449 [3], the home test can be completely avoided. 128 - When the mobile knows about the correspondent's RO support it does 129 not need the HA as a fallback relay. This knowledge may be 130 available from prior connections or through means external to the 131 standard. 133 Based on these reasons, it makes sense to support RO without HA. 134 Note that such an enhancement was first proposed by RFC 4651 [4]. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC 2119]. 142 In this document, the following terms are used: 144 Legacy Mobile IPv6 145 Refers to MIPv6 [1] and its extensions excluding those 146 described in this document. 148 HA-bound RO 149 Refers to RO according to legacy MIPv6 151 HA-free RO 152 Refers to RO where the mobile does not have a HA 154 Permanent Home Address 155 Home address (HoA) according to legacy MIPv6 157 Virtual Home Address 158 IPv6 address that holds the equivalent function in 159 HA-free RO as the permanent HoA in HA-bound RO. 161 3. Operation of Route Optimization without Home Agent 163 Two distinct scenarios are considered. In the first scenario, the 164 mobile desires to conduct RO without HA support even if a HA is 165 available. This scenario is referred to as HA-free RO and described 166 in subsection 3.1 and 3.2. In the second scenario, the mobile seeks 167 HA-support during RO but the HA becomes unavailable prior or during 168 RO. This scenario can be treated as a special case of HA-free RO 169 and is discussed in subsection 3.3. Subsection 3.4 elaborates on how 170 the mobile can identify the correspondent's support of RO. 172 3.1. Operations on network layer 174 HA-free RO implies that all traffic and all signaling messages flow 175 on the shortest routing path between mobile and correspondent. 177 In the absence of a HA, the mobile does not have a home network. 178 Therefore, the mobile interprets the IPv6 address of one of its links 179 as a "virtual" HoA as if it resided in its home network. The virtual 180 HoA MUST be a unicast routable IPv6 address. The mobile uses the 181 virtual HoA to start transport connections subject to the limitations 182 discussed in 3.2. 184 When the mobile moves to another IPv6 address, it interprets this 185 address as a care-of-address (CoA). Consequently, it conducts a 186 correspondent registration, which creates a binding between virtual 187 HoA and CoA. The CoA MUST also be a unicast routable IPv6 address. 189 If a home test is required prior to the correspondent registration, 190 the home test MUST be based on the mobile's virtual HoA. This means 191 that the virtual HoA must still be supported during the home test. 192 The mobile omits the home registration. 194 All signaling between mobile and correspondent is the same for 195 HA-free RO as for HA-bound RO. In HA-free RO, the mobile MAY omit 196 message exchanges with the HA. 198 When the correspondent is also mobile, it can send its mobility 199 header messages to either the mobile's virtual HoA or to the 200 mobile's CoA. If the mobile's virtual HoA is not on link anymore, 201 the correspondent MUST send its mobility header messages to the 202 mobile's CoA. This policy is in departure from RFC 3775 [1], which 203 requires that mobile correspondents MUST always send their mobility 204 header messages to the mobile's permanent HoA. 206 To provide clarification to the correspondent on where it should 207 send its own mobility header messages, the mobile has to inform the 208 correspondent about the on-link support of its virtual HoA. This 209 requires introduction of a new mobility header option, referred to as 210 HoA-Support Mobility option, which the mobile inserts into 211 mobility header messages such as BU, Early BU, Home Test Init and 212 Care-of Test Init [1][2]. This option holds a HoA Support flag 213 with settings "supported" or "not supported". The mobile SHOULD 214 insert this option only when the on-link support of the virtual HoA 215 has changed. The HoA-Support Mobility option is defined in section 4. 217 The correspondent SHOULD support an additional field in its binding 218 cache referred to as the HoA Support field, which is updated 219 according to the entry in the mobile's HoA-Support Mobility 220 option. The HoA Support field is initialized with "supported". 221 If this field is set to "not supported", the correspondent MUST send 222 its mobility header messages to the mobile's CoA and it MUST insert 223 the Type-2 Routing header into these messages. Otherwise the 224 correspondent MUST proceed according to legacy MIPv6 and send 225 its mobility header messages to the mobile's HoA (this can be the 226 mobile's virtual or permanent HoA). 228 When the correspondent receives a HoA-Support Mobility option in 229 a mobility header message, it MUST attach a copy of this option in 230 the associated response message such as Binding Acknowledgement (BA), 231 early BA, Home Test and Care-of Test. This informs the mobile that 232 the correspondent complies with the extensions of HA-free RO. 234 In case the correspondent does not support the extensions for HA-free 235 RO provided by this document, it simply ignores the new mobility 236 option. The missing HoA-Support Mobility option in the return message 237 is an indicator for the mobile that HA-free is not supported 238 by the correspondent. In this case, connections make break in case 239 both peers are mobile and the correspondent moves while the mobile's 240 virtual HoA is not on link. Subsection 3.4 discusses on how such a 241 situation can be avoided. 243 3.2. Operations on higher protocol layers 245 Legacy MIPv6 uses the permanent HoA as an invariant on higher 246 protocol layers (e.g. transport layer), which shuns IP mobility from 247 these layers. For HA-free RO, the same functionality is accomplished 248 by using the virtual HoA instead of the permanent HoA. Although the 249 virtual HoA may have limited lifetime on the link, it is used by 250 higher protocol layers throughout the lifetime of the connection. 252 For new connections, higher protocol layers use one of the host's 253 current on-link addresses as the virtual HoA unless an active BU 254 entry exists in the BU list or binding cache. If such an entry 255 exists, higher protocol layers should use the virtual HoA of this 256 entry. This guarantees that temporally overlapping connections with 257 the same correspondent use the same virtual HoA. 259 A multi-homed host MAY start connections from different 260 simultaneously supported IP addresses and declare each IP address as 261 a virtual HoA for the associated connection unless the host already 262 holds a BU entry or binding cache entry for that correspondent. This 263 behavior is compliant with the spirit of RFC 3775 [1], which permits 264 behavior is compliant with the spirit of RFC 3775 [1], which permits 265 simultaneous support of multiple permanent HoAs pertaining to 266 different home subnet prefixes. RFC 3755 makes no restrictions to 267 the topological distance between the home subnet prefixes pertaining 268 to these HoAs. 270 It is also permissible that the mobile uses an HA for some 271 connections and HA-free RO for others. In this case the HoA can be of 272 permanent and virtual nature at the same time. 274 Under all circumstances, the HoA (virtual or permanent) used for the 275 home test MUST always match the HoA used by higher protocol layers. 277 3.3. Operation during unavailability of home agent 279 The mobile determines that the HA is unavailable after it has tried 280 to communicate with the HA and the HA hasn't responded within an 281 adequate timeframe or after a certain number of message 282 retransmissions. 284 When the mobile has decided that the HA is unavailable, it switches 285 to HA-free RO. The following scenarios have to be considered: 287 - In case the mobile cannot obtain an ICMP HA discovery response 288 message or an ICMP Mobile Prefix Advertisement message from the HA, 289 the mobile MAY continue operation using HA-free RO. 291 - In case the home registration fails while the mobile resides in its 292 home network, the mobile MAY use its permanent HoA as a virtual HoA 293 and continue operation using HA-free RO. It MAY also decide to use 294 another on-link address as its virtual HoA. 296 - In case the home registration fails while the mobile resides in a 297 foreign network and before the first correspondent registration has 298 successfully completed, the connection breaks since mobile and 299 correspondent have not yet successfully engaged into RO. 301 - In case the mobile resides in a foreign network and the home 302 registration or the home test fails after the first correspondent 303 registration has successfully completed, the mobile MAY use its 304 permanent HoA as a virtual HoA and continue operation using HA-free 305 RO. In this case, the mobile SHOULD send a BU to the correspondent 306 rightaway and insert the HoA Support Mobility option. 308 When the HA is unavailable and the mobile enters HA-free RO, it MAY 309 still follow a retransmission schedule to re-engage into 310 HA-bound RO. In case the HA becomes responsive again, the mobile 311 MAY return to HA-bound RO for all those connections, whose 312 virtual HoAs match the permanent HoA. All other connections MUST 313 remain in HA-free RO. 315 If HA-bound RO is resumed, the mobile SHOULD send a BU with HoA- 316 Support Mobility option to the correspondent to update the 317 correspondent about the availability of its HoA. 319 3.4. Learning about correspondent's RO Support 321 Prior to engaging into HA-free RO, the mobile can determine if the 322 correspondent supports HA-bound RO or HA-free RO. The mobile MAY 323 pursue one of the following strategies: 325 - For frequently contacted correspondents, the mobile MAY cache 326 from prior sessions if HA-bound or HA-free RO is supported. 328 - The mobile MAY conduct a home test prior to connection 329 establishment and include the HoA Support Mobility Option. 331 - The mobile MAY start the connection in HA-bound RO and switch 332 to HA-free RO as soon as the correspondent registration has 333 succeeded. 335 4. HoA Support Mobility Option 337 The HoA Support Mobility option is inserted into a mobile header 338 message to inform the correspondent about the on-link support of its 339 virtual HoA. The correspondent reflects this mobility option in the 340 response message. 342 The HoA Support Mobility option has the following entries: 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type = TBD | HoA Support | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 HoA Routability 350 8-bit unsigned integer indicating the connectivity of the virtual 351 HoA. The following values are supported: 353 0 HoA is not supported 355 1 HoA is supported 357 5. Policy Changes 359 All mobiles that follow the extensions for HA-free RO described in 360 this document MAY omit signaling handshakes with their HA. 362 6. Security Considerations 364 HA-free RO is subject to the same security concerns as HA-bound RO. 365 These concerns have been addressed by RFC 3775 [1] and RFC 4225 [5]. 366 Since HA-free RO does not alter the signaling between mobile and 367 correspondent and since the HA does not provide additional security 368 support for RO, omission of HA-support should not negatively impact 369 the security of HA-free RO beyond that of HA-bound RO. 371 7. Performance Limitations of HA-free RO 373 HA-free RO has some principle limitations regarding operation and 374 performance: 376 - When a mobile uses the return routability procedure according to 377 RFC 3775, it always has to sustain the virtual HoA on one link to 378 conduct the home tests. 380 - Mobile hosts may require a location service external to MIPv6 in 381 case they support a server function and move to foreign networks. 383 - Simultaneous movement of mobile and correspondent cannot be 384 supported unless both nodes are multi-homed and sustain an extended 385 "make-before-break" time period. 387 8. IANA Considerations 389 The value for the HoA Support Mobility option type must be assinged 390 by IANA. 392 9. References 394 9.1. Normative References 396 [1] D. Johnson, C. Perkins and J. Arkko, "Mobile Support in IPv6", 397 RFC3775, June 2004 399 [2] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route Optimization for 400 Mobile IPv6", RFC4866, May 2007 402 [3] C. Perkins, "Securing Mobile IPv6 Route Optimization Using a 403 Static Shared Key", RFC4449, June 2006. 405 [4] C. Vogt and J. Arkko, "A Taxonomy and Analysis of Enhancements to 406 Mobile IPv6 Route Optimization", RFC4651, February 2007 408 [5] P. Nikander, J. Arkko, T. Aura, G. Montenegro and E. Nordmark, 409 "Mobile IP Version 6 Route Optimization Security Design 410 Background", RFC4225, December 2005 412 Authors' Addresses 414 Georg Hampel 415 Bell Labs, Alcatel-Lucent 416 600 Mountain Avenue 417 Murray Hill, NJ 07974 418 USA 419 Tel: +1 908 582 2377 420 Email: georg.hampel@alcatel-lucent.com 422 Thierry Klein 423 Bell Labs, Alcatel-Lucent 424 600 Mountain Avenue 425 Murray Hill, NJ 07974 426 USA 427 Tel: +1 908 582 3585 428 Email: thierry.klein@alcatel-lucent.com