idnits 2.17.1 draft-korhonen-netext-redirect-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 == Line 779 has weird spacing: '... Option is s...' -- The document date (October 7, 2009) is 5314 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track S. Gundavelli 5 Expires: April 10, 2010 Cisco 6 H. Yokota 7 KDDI Lab 8 X. Cui 9 Huawei 10 October 7, 2009 12 Runtime LMA Assignment Support for Proxy Mobile IPv6 13 draft-korhonen-netext-redirect-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 10, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes a redirect functionality and corresponding 52 mobility options for Proxy Mobile IPv6. The redirect functionality 53 allows a dynamic runtime assignment of a Local Mobility Anchor and 54 redirecting the mobility session to the assigned Local Mobility 55 Anchor. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 5 61 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 6 64 4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 7 66 4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 8 67 5. Runtime LMA Assignment Operation . . . . . . . . . . . . . . . 10 68 5.1. Common Mobile Access Gateway Operation . . . . . . . . . . 10 69 5.2. Common Local Mobility Anchor Operation . . . . . . . . . . 10 70 5.3. Mobility Session Created During the Redirection . . . . . 11 71 5.3.1. General Operation . . . . . . . . . . . . . . . . . . 11 72 5.3.2. Mobile Access Gateway Considerations . . . . . . . . . 12 73 5.3.3. Local Mobility Anchor Considerations . . . . . . . . . 13 74 5.4. Mobility Session Created After the Redirection . . . . . . 14 75 5.4.1. General Operation . . . . . . . . . . . . . . . . . . 14 76 5.4.2. Mobile Access Gateway Considerations . . . . . . . . . 14 77 5.4.3. Local Mobility Anchor Considerations . . . . . . . . . 15 78 5.5. Redirection Example . . . . . . . . . . . . . . . . . . . 15 79 5.5.1. Redirection During the Initial PBU/PBA Exchange . . . 16 80 5.5.2. Redirection During Mid-session PBU/PBA Exchange . . . 17 81 6. Multi-Homing Considerations . . . . . . . . . . . . . . . . . 18 82 7. Configuration Variables . . . . . . . . . . . . . . . . . . . 19 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 This document describes the Redirect-Capability and the Redirect 94 mobility options, and the corresponding functionality for a runtime 95 assignment of the Local Mobility Anchor (LMA) for Proxy Mobile IPv6 96 (PMIPv6). Hereafter the terms 'runtime assignment' and 'redirection' 97 are used interchangeably throughout this specification. The runtime 98 assignment takes place during a Proxy Binding Update (PBU) and a 99 Proxy Binding Acknowledgement (PBA) messages exchange between a 100 Mobile Access Gateway (MAG) and a LMA. The runtime assignment 101 functionality defined in this specification can be used, for example, 102 for load balancing purposes during the initial PBU/PBA messages 103 exchange. However, other use cases are also possible. In case of 104 load balancing, the runtime assignment approach is just one 105 implementation option. MAGs and LMAs can implement other solutions 106 that are, for example, completely transparent at PMIPv6 protocol 107 level and do not depend on the functionality defined in this 108 specification. 110 The runtime assignment functionality described in this specification 111 does not depend on information provisioned to external entities, such 112 as the Domain Name System (DNS) or the Authentication, Authorization 113 and Accounting (AAA) infrastructure. The trust relationship and 114 coordination management between LMAs within a PMIPv6 domain is 115 deployment specific and not described in this specification. 117 There are number of reasons, why the runtime assignment is an useful 118 addition to the PMIPv6 protocol. The following list describes some 119 identified ones: 121 o LMAs with multiple IP addresses: a cluster of LMAs or a blade 122 architecture LMA may appear to the routing system as multiple LMAs 123 with separate unicast IP addresses. A MAG can initially select 124 any of those LMA IP addresses as the LMA Address using e.g., DNS- 125 and AAA-based solutions. However, MAG's initial selection may be 126 suboptimal from the LMA point of view and immediate redirection to 127 a "proper LMA" would be needed. The LMA could use [RFC5142] based 128 approach but that would imply unnecessary setting up of a mobility 129 session in a "wrong LMA" with associated backend support system 130 interactions, involve additional signaling between the MAG and the 131 LMA, and re-establishing mobility session to the new LMA again 132 with associated signaling. 134 o Bypassing a load balancer: a cluster of LMAs or a blade 135 architecture LMA may have a load balancer in front of them or 136 integrated in one of the LMAs. The load balancer would represent 137 multiple LMAs during the LMA discovery phase and only its IP 138 address would be exposed to the MAG hiding possible individual LMA 139 or LMA blade IP addresses from the MAG. However, if all traffic 140 must always go through the load balancer it becomes quickly a 141 bottleneck. Therefore, a PMIPv6 protocol level support for 142 bypassing the load balancer after the initial PBU/PBA exchange 143 would greatly help scalability. Also bypassing the load balancer 144 as soon as possible allows implementing load balancers that do not 145 maintain any MN specific state information. 147 o Independence from DNS: DNS-based load balancing is a common 148 practise. However, keeping MAGs up-to-date with LMA load status 149 using DNS is hard e.g., due caching and unpredictable zone update 150 delays. Generally, LMAs constantly updating [RFC2136] zone's 151 master DNS server might not feasible in a large PMIPv6 domain due 152 to increased load on the master DNS server and additional 153 background signaling. Furthermore, MAGs may do (LMA) destination 154 address selection decisions that are not in-line what the DNS 155 administrator actually wanted [RFC3484]. 157 o Independence from AAA: AAA-based solutions have basically the same 158 arguments as DNS-based solutions above. It is also typical that 159 AAA-based solutions offload the initial LMA selection to the DNS 160 infrastructure. The AAA infrastructure does not return an IP 161 address or a Fully Qualified domain Name (FQDN) to a single LMA, 162 rather a FQDN representing a group of LMAs. 164 o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 165 specification does not specify how the PMIPv6 protocol should 166 treat anycast addresses assigned to mobility agents. Although 167 [RFC4291] now allows using anycast addresses as source addresses, 168 it does not make much sense using anycast addresses for the MAG to 169 the LMA communication after the initial PBU/PBA exchange. For 170 example, a blade architecture LMA may appear to the routing system 171 as multiple LMAs with separate unicast IP addresses and with one 172 or more "grouping" anycast addresses. 174 2. Requirements and Terminology 176 2.1. Requirements 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 2.2. Terminology 184 In addition to the terminology defined in [RFC5213], the following 185 terminology is also used: 187 rfLMA 189 The LMA which receives the PBU from a MAG and decides to redirect 190 the IP mobility session to the target LMA (r2LMA). 192 r2LMA 194 The LMA to which a MAG was redirected to. 196 Redirection Domain 198 A group of LMAs that consist of at least one rfLMA and one or more 199 r2LMAs. A rfLMA is allowed to redirect mobility sessions only to 200 r2LMAs that belong to the same redirection domain. 202 3. Proxy Mobile IPv6 Domain Assumptions 204 The redirection functionality has several assumptions on the PMIPv6 205 domain. They are discussed here as they have impact on PMIPv6 206 deployment. 208 Each functional LMA, whether that is a separate LMA in a cluster or 209 an individual blade in a chassis, participating to the redirection 210 MUST be reachable at an unicast IP address. The rfLMA and the r2LMA 211 MUST have a prior agreement and an established trust relationship to 212 perform the redirection. In this case, the rfLMA and the r2LMA are 213 said to belong to the same 'redirection domain'. 215 The rfLMA MUST NOT redirect the mobility session to a r2LMA that is 216 not able to accept the redirected mobility session. That is, the 217 redirection functionality is not enabled in the r2LMA, or the r2LMA 218 does not belong to the same redirection domain as the rfLMA, or the 219 r2LMA is down or otherwise unreachable. How the rfLMA learns and 220 knows of other r2LMAs in the redirection domain, is not covered by 221 this specification. 223 Each LMA and MAG participating to the redirection is assumed to have 224 required Security Associations (SA) already set up in advance. 225 Dynamic negotiation of the SAs using e.g., IKEv2 [RFC4306] MAY be 226 supported but is out of scope of this specification. However, it 227 should be noted that if anycast addresses are used within the PMIPv6 228 domain to contact the rfLMA, then manual keying of the SAs may be 229 required [RFC4303]. 231 The redirection functionality negotiation during the PBU/PBA exchange 232 is stateless. The LMA MUST NOT include the Redirect mobility option 233 in the PBA and perform the redirection, unless the MAG indicated the 234 redirection functionality support in the corresponding PBU using the 235 Redirection-Capability mobility option. The LMA MUST NOT include the 236 Redirect mobility option unsolicited even if the MAG had earlier 237 indicated support for the redirection functionality. The MAG MUST 238 NOT conclude LMA's redirection functionality support based on the 239 absence of the Redirect mobility option in the PBA. 241 4. Mobility Options 243 The Redirect mobility options allow a LMA to inform a MAG of a 244 redirection to a new LMA during a PBU/PBA exchange. MAGs and LMAs 245 that implement the Redirect mobility option MUST support the 246 redirection functionality during the initial PBU/PBA exchange that 247 creates a new mobility session. MAGs and LMAs that implement the 248 Redirect mobility option MAY support the redirection of an 249 established mobility session. 251 4.1. Redirect-Capability Mobility Option 253 A PBU message MAY contain the Redirect-Capability mobility option as 254 an indication to a LMA that a MAG supports the redirection 255 functionality. When this option is included, the MAG may be 256 redirected to another LMA, and the redirected to LMA may 257 simultaneously create a Binding Cache Entry (BCE). Hence, the MAG 258 including this option MUST be able to support both redirection, and 259 redirection with BCE creation. The Redirect-Capability mobility 260 option has the alignment requirement of 4n. There can zero or one 261 Redirect-Capability mobility option in the PBU. The format of the 262 Redirect-Capability mobility option is shown below: 264 0 1 2 3 265 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Option Type | Option Length |F| Reserved | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Redirect-Capability Mobility Option 272 o Option Type: 8-bit identifier set to TBD1. 274 o Option Length: 8-bit unsigned integer, representing the length of 275 the Redirect-Capability mobility option in octets, excluding the 276 Option Type and Length fields. The Option Length MUST be set to 277 2. 279 o 'F' flag: This bit is set to one (1) if the MAG supports IPv4 280 transport. Otherwise, the bit is set to zero (0). 282 o Reserved: This field is reserved for future use. MUST be set to 283 zero. 285 4.2. Redirect Mobility Option 287 The LMA MAY include the Redirect mobility option in a PBA only if the 288 MAG indicated support for the redirection functionality and the 289 mobility session was redirected from a LMA to another. The Redirect 290 mobility option in the PBA MUST contain an unicast IPv6 address of 291 the r2LMA. The Redirect mobility option in the PBA MAY contain an 292 IPv4 address of the r2LMA. There can zero or one Redirect mobility 293 option in the PBA. 295 The Redirect mobility option has the alignment requirement of 4n. 296 The format of the Redirect mobility option is shown below: 298 0 1 2 3 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Option Type | Option Length |D| Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | | 304 | IPv6 r2LMA Address | 305 | | 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Optional IPv4 r2LMA Address | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Redirect Mobility Option 313 o Option Type: 8-bit identifier set to TBD2. 315 o Option Length: 8-bit unsigned integer, representing the length of 316 the Redirect mobility option in octets, excluding the Option Type 317 and Length fields. If the IPv4 LMA Address is included in the 318 option, the Option Length MUST be set to 22. Otherwise, the 319 Option Length MUST be set to 18. 321 o 'D' flag: This bit is set to one (1) if the mobility session (and 322 the corresponding Binding Cache Entry) is already created in the 323 r2LMA. Otherwise, the bit is set to zero (0). 325 o Reserved: This field is reserved for future use. MUST be set to 326 zero. 328 o IPv6 r2LMA Address: the unicast IPv6 address of the r2LMA. 330 o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This 331 value is present if the r2LMA IPv4 address is available. 333 5. Runtime LMA Assignment Operation 335 5.1. Common Mobile Access Gateway Operation 337 The base PMIPv6 protocol [RFC5213] operation is such that a MAG sends 338 a PBU to an LMA which results in a BCE being created at the LMA and a 339 PBA sent back (from the LMA) to the MAG, which in turn creates an 340 entry in the Binding Update List (BUL). The semantics of the base 341 protocol operation are extended with the redirection feature by 342 having the rfLMA forward the PBU sent by a MAG to the r2LMA (which 343 creates the BCE) and the PBA which is routed back to the sending MAG 344 through rfLMA, causing the MAG to create a BUL which points to r2LMA. 345 The semantics in the case where the rfLMA does not forward the PBU 346 but instead returns a PBA to the MAG which includes the Redirect 347 Mobility option which has the address of the r2LMA are also extended 348 from the base protocol operation. 350 Backwards compatibility is maintained in a deployment wherein some 351 MAGs may have the ability to support redirection while others do not. 352 This is accomplished by the use of the Redirect-Capability Mobility 353 Option being included in the PBU sent by the MAG. An LMA which has 354 the capability to redirect a MAG to a target r2LMA on receiving a PBU 355 from a legacy MAG can only respond with a PBA which does not include 356 any r2LMA address. 358 When the redirection functionality is enabled, then the MAG MAY 359 include the Redirect-Capability mobility option in any PBU. The 360 Redirect-Capability mobility option in the PBU is also an indication 361 to a LMA that the MAG supports the redirection functionality and is 362 prepared to be redirected. The redirection concerns always one 363 mobility session at time. 365 If the MAG receives a PBA that contains the Redirect mobility option 366 without first including the Redirect-Capability mobility option in 367 the corresponding PBU, then the MAG MUST treat the PBA as if the 368 binding update failed and log the event. 370 5.2. Common Local Mobility Anchor Operation 372 The text in the following section refers to a 'LMA' when it means the 373 combination of the rfLMA and the r2LMA i.e., the entity where 374 redirection is possible. When the text points to a specific LMA role 375 during the redirection, it uses either the 'rfLMA' or the 'r2LMA'. 377 If the redirection functionality is enabled in the LMA but the 378 redirection is not going to take place for a reason or other, and the 379 rfLMA is not willing to serve (or capable of) as a normal RFC 5213 380 LMA for the MAG, then the rfLMA MUST reject the PBU and send back a 381 PBA with Status Value set to NOT_LMA_FOR_THIS_MAG error code. 382 Otherwise, the rfLMA MUST act as a normal RFC 5213 defined LMA for 383 the MAG. 385 The rfLMA MUST only redirect the MAG to a new r2LMA that it knows the 386 MAG has a SA with or the MAG and the r2LMA are able to create it 387 dynamically. The rfLMA MUST NOT redirect the MAG to a r2LMA that the 388 rfLMA and the r2LMA do not have a prior redirection agreement and an 389 established trust relationship for the redirection. These SA related 390 knowledge issues and trust relationships are deployment specific in a 391 PMIPv6 domain and in a redirection domain, and out of scope of this 392 specification. Possible context transfer and other coordination 393 management between the rfLMA and the r2LMA, are again deployment 394 specific for LMAs in a redirection domain. 396 The rfLMA MUST NOT redirect a MAG using IPv6 transport to a new r2LMA 397 using IPv4 transport, if the MAG does not indicate support for IPv4 398 in the Redirect-Capability mobility option, as there is no guarantee 399 that the MAG supports switching from IPv6 transport to IPv4 400 transport. The same also applies for redirecting a MAG using IPv4 401 transport to a r2LMA supporting only IPv6 transport. 403 As a result of a successful redirection, the PBA MUST contain the 404 Redirect mobility option with a valid r2LMA Address, the 'D' flag 405 reflecting the r2LMA status, and the PBA Status Value indicating 406 either success or redirection. 408 In general the r2LMA may be a normal RFC 5213 LMA without any 409 redirection functionality. The r2LMA MAY also include rfLMA 410 functionality in which case the consideration described in the 411 following sections for the rfLMA apply. If the redirection 412 functionality is implemented but not enabled in a LMA, then the LMA 413 MUST ignore the Redirect-Capability mobility option received in PBUs 414 and act as a LMA defined in RFC 5213. 416 5.3. Mobility Session Created During the Redirection 418 5.3.1. General Operation 420 During the redirection the PBA is returned from the LMA Address where 421 the PBU was sent to i.e., from the rfLMA. After the redirection all 422 PMIPv6 communication continues directly between the MAG and the 423 r2LMA. The overall redirection flow sequence is shown in Figure 1. 425 MAG rfLMA r2LMA 426 | | | 427 1) |--PBU-->| ~ ~ ~ | (redirection takes place, BCE gets created in 428 2) |<--PBA--| ~ ~ ~ | r2LMA, PBA contains r2LMA information and 429 | | | 'D' flag is set to 1 430 3) |<=====data======>| 431 | | | 432 4) |-------PBU------>| (lifetime extension, 433 5) |<------PBA-------| de-registration, etc.) 434 | | | 436 Figure 1: Runtime LMA assignment from rfLMA to r2LMA and setting up a 437 mobility session in the r2LMA within a redirection domain 439 The assumption in the signaling flow step 1) shown in Figure 1 is 440 that the mobility session gets created in the r2LMA, although the 441 rfLMA is responsible for interfacing with the MAG. The interaction 442 between the rfLMA and the r2LMA in the redirection domain is not 443 defined in this specification. There are several possible solutions 444 for the rfLMA and the r2LMA interaction depending on e.g. the 445 collocation properties of the rfLMA and the r2LMA, and whether the 446 rfLMA and the r2LMA implement an interface that is interoperable 447 among multiple LMA vendors. One potential example solution is 448 discussed in Section 5.5. 450 5.3.2. Mobile Access Gateway Considerations 452 In addition to MAG operations described in Section 5.1, the following 453 considerations has to taken into account during the redirection. 455 If the MAG receives a PBA that contains the Redirect mobility option 456 with the 'D' flag set to one (1) and the MAG had included the 457 Redirect-Capability mobility option in the corresponding PBU, then 458 the MAG MUST perform the following steps in addition to the normal 459 RFC 5213 PBA processing: 461 o Check if there is a SA between the MAG and the r2LMA. If this 462 check fails, then the MAG MUST treat the PBA as if the binding 463 update failed and log the event. This situation should not happen 464 and is an indication of incorrectly configured or malfunctioning 465 redirection domain. 467 o If there was no SA between the MAG and the r2LMA and the above 468 bullet described PBA handling was done, then the MAG MAY still 469 resend the PBU to the same rfLMA without including the Redirect- 470 Capability mobility option. However, the MAG SHOULD choose 471 another rfLMA to contact, if just possible. 473 If the redirection was successful, the MAG updates the BUL to 474 correspond the r2LMA Address included in the received Redirect 475 mobility option. There is no need to resend any PBUs to the r2LMA 476 after a successful redirection. The mobility session has already 477 been established in the r2LMA as indicated by the 'D' flag with value 478 one (1) in the Redirection mobility option. The MAG MUST send 479 subsequent binding refreshing PBUs and user traffic to the new r2LMA 480 Address. If the MAG includes the Redirect-Capability mobility option 481 in subsequent PBUs, the LMA MAY redirect the MAG again. For the 482 subsequent mid-session redirections it is assumed that the r2LMA also 483 has the rfLMA functionality. [ED: discuss the setting of the Handoff 484 Indicator option value in this case and what happens if the HNP/ 485 IPv4-HoA changes.] 487 5.3.3. Local Mobility Anchor Considerations 489 If the redirection functionality is enabled in the LMA and the 490 received PBU contains the Redirect-Capability mobility option, then 491 the rfLMA MAY redirect the MAG to a new r2LMA. In the case of 492 redirection, the PBA returned to the MAG MUST always include the 493 unicast IPv6 address of the r2LMA in the Redirect mobility option 494 with the 'D' flag set to one (1) and the Status Value set to a value 495 indicating success. If the r2LMA has IPv4 support enabled, then the 496 PBA returned to the MAG SHOULD include the IPv4 address of the r2LMA 497 in the Redirect mobility option. If the rfLMA did not redirect the 498 MAG to a new r2LMA or the redirection failed, then the PBA MUST NOT 499 contain the Redirect mobility option. 501 If the redirection was successful, the mobility session MUST be 502 established in the r2LMA. The actual PBU processing that creates the 503 mobility session and the corresponding BCE takes place in the r2LMA. 504 However, depending on the LMA's implementation of the PMIPv6 security 505 framework, the security processing (such as IPsec) of the PBU may 506 take place in the rfLMA before the PBU is transferred from the rfLMA 507 to the r2LMA. Whenever the redirection processing has involved the 508 r2LMA, the PBA sent by the rfLMA to the MAG MUST reflect the 509 information the r2LMA would include in its PBA (such as mobility 510 options, Status Value and so on). The only exceptions are possible 511 security related options that the rfLMA MAY need to modify or remove. 512 The rfLMA is always allowed to add more mobility options to the PBA. 514 During the redirection process, the rfLMA MAY need to maintain a 515 temporary MAG-rfLMA-r2LMA state and may even act as a "proxy MAG" to 516 the r2LMA. This, however, depends on the collocation properties of 517 the rfLMA and the r2LMA, and how the rfLMA interact with the r2LMA. 518 The interaction may happen as a PBU/PBA packet forwarding in a 519 conventional sense or as an inter-blade communication using some LMA 520 architecture specific communication method. Once the redirection has 521 completed successfully from the rfLMA point of view and it has sent 522 the PBA to the MAG, the rfLMA can remove all state information 523 regarding the recent redirection. 525 5.4. Mobility Session Created After the Redirection 527 5.4.1. General Operation 529 During the redirection the PBA is returned from the LMA Address where 530 the PBU was sent to i.e., from the rfLMA. After the redirection, the 531 MAG has to initiate another PBU/PBA exchange with the r2LMA and after 532 that all PMIPv6 communication continues between the MAG and the 533 r2LMA. The overall redirection flow sequence is shown in Figure 2. 535 MAG rfLMA r2LMA 536 | | | 537 1) |--PBU-->| | (redirection takes place, PBA contains r2LMA 538 2) |<--PBA--| | information, 'D' flag is set to 0 ) 539 | | | 540 3) |-------PBU------>| (BCE gets created in r2LMA) 541 4) |<------PBA-------| 542 | | | 543 5) |<=====data======>| 544 | | | 545 6) |-------PBU------>| (lifetime extension, 546 7) |<------PBA-------| de-registration, etc.) 547 | | | 549 Figure 2: Runtime LMA assignment from rfLMA to r2LMA within a 550 redirection domain 552 The assumption in the signaling flow steps 1) and 2) shown in 553 Figure 2 is that the MAG is only redirected to the r2LMA. The 554 mobility session creation with the r2LMA requires a new PBU/PBA 555 exchange with the r2LMA using the normal RFC 5213 procedures. 557 5.4.2. Mobile Access Gateway Considerations 559 The MAG operation is exactly the same as described in Section 5.1 and 560 Section 5.3.2 except for three aspects: 562 o The 'D' flag in the received Redirection mobility option is set to 563 zero (0). This indicates to the MAG that there is no mobility 564 session (i.e. BCE) created in the r2LMA and not in the rfLMA 565 either. The Status Value in the received PBA MUST have been set 566 to the value TBD. The MAG was only assigned with a new r2LMA 567 Address information. 569 o Check if there is a SA between the MAG and the r2LMA. If this 570 check fails, then the MAG MUST either treat the PBA as if the 571 binding update failed and log the event, or initiate dynamic 572 creation of the SA between the MAG and the r2LMA (note that the 573 dynamic creation of the SA is outside of the scope of this 574 specification). 576 o The MAG MUST initiate a new PBU/PBA exchange with the r2LMA in 577 order to establish a mobility session. Only after a successful 578 PBU/PBA exchange with the r2LMA, the redirection has completed. 579 The initial PBU sent to the r2LMA SHOULD NOT contain the Redirect- 580 Capability mobility option in order to avoid possible immediate 581 new redirection. 583 5.4.3. Local Mobility Anchor Considerations 585 If the redirection functionality is enabled in the LMA and the 586 received PBU contains the Redirect-Capability mobility option, then 587 the rfLMA MAY redirect the MAG to a new r2LMA. In the case of 588 redirection, the PBA returned to the MAG MUST always include the 589 unicast IPv6 address of the r2LMA in the Redirect mobility option 590 with the 'D' flag set to zero (0) and the Status Value MUST be set to 591 the value TBD. If the r2LMA has IPv4 support enabled, then the PBA 592 returned to the MAG SHOULD include the IPv4 address of the r2LMA in 593 the Redirect mobility option. If the rfLMA did not redirect the MAG 594 to a new r2LMA or the redirection failed, then the PBA MUST NOT 595 contain the Redirect mobility option. 597 5.5. Redirection Example 599 This section gives a high level example of one possible "Mobility 600 Session Created During the Redirection" solution discussed in 601 Section 5.3. The example shows how the complete procedure for a LMA 602 redirection takes place in a PMIPv6 domain and eventually ends up to 603 a creation of a mobility session between a MAG and a r2LMA. Note 604 that this section is only for example purposes, not for specifying 605 the rfLMA to the r2LMA interaction. 607 During the redirection PBU/PBA exchange, the mobility session and the 608 corresponding BCE gets created in the r2LMA before the rfLMA sends 609 the PBA back to the MAG (see the dotted lines between the rfLMA and 610 the r2LMA in steps 1) and 2) in Figure 1). The mobility session can 611 only be created in the r2LMA that belongs to the same redirection 612 domain as the rfLMA. The example solution described here has the 613 assumption that the rfLMA also has limited MAG functionality, and the 614 rfLMA and r2LMAs have required SAs established, if needed. 616 5.5.1. Redirection During the Initial PBU/PBA Exchange 618 Here we describe the redirection during the initial PBU/PBA exchange. 619 Error cases are excluded for the brevity. 621 o A MAG discovers a LMA Address in a PMIPv6 domain using some 622 mechanism and that LMA happens to be a rfLMA in some redirection 623 domain. 625 o The MAG creates and sends a PBU to the rfLMA as defined in 626 Section 5.3.2 of this specification. 628 o The rfLMA receives the PBU from a MAG. The PBU contains relevant 629 mobility options to enable redirection such as the Redirect- 630 Capability mobility option. 632 o The rfLMA does the security processing on the PBU as described in 633 RFC 5213. The rfLMA selects an appropriate r2LMA for the mobility 634 session under the conditions described in Section 5.3.3 of this 635 specification and creates a temporary MAG-rfLMA-r2LMA state. The 636 rfLMA has to maintain this state until the redirection process 637 completes from its point of view. 639 o The rfLMA overwrites the source address of the PBU with its own 640 address and also overwrites the destination address of the PBU 641 with the r2LMA Address. Furthermore, the rfLMA includes the 642 Alternate Care-of Address mobility option containing the MAG 643 Address into the PBU (if it was not already present) and also 644 removes the Redirect-Capability mobility option from the PBU. 645 After this, the rfLMA forwards the PBU to the r2LMA. 647 o The r2LMA receives the PBU, processes it and creates the mobility 648 session with the MAG as defined in RFC 5213. After successfully 649 processing the PBU the r2LMA forwards a PBA to the rfLMA as 650 defined in RFC 5213. 652 o The rfLMA receives the PBA from the r2LMA and processes it 653 according to the information it has concerning the temporary MAG- 654 rfLMA-r2LMA state. This step involves the rfLMA overwriting the 655 source and destination addresses of the PBA according to the 656 temporary state information (the source address of the PBA will be 657 the rfLMA Address and the destination address of the PBA will be 658 the MAG Address). The rfLMA includes the Redirect mobility option 659 with the appropriate r2LMA address information and 'D' flag set to 660 1 into the PBA. After this the rfLMA sends the PBA to the MAG. 662 o The MAG receives the PBA from the rfLMA and processes it as 663 defined in RFC 5213 and additionally in Section 5.3.2 of this 664 specification. 666 In addition to the above steps, the rfLMA and the r2LMAs, and a group 667 of r2LMAs may e.g. exchange additional status, context and load 668 information between each other. How this information exchange is 669 done, is out of scope of this example and the specification. 670 Furthermore, how and based on what criteria the rfLMA selects an 671 appropriate r2LMA is also out of scope of this example and the 672 specification. 674 5.5.2. Redirection During Mid-session PBU/PBA Exchange 676 Here we briefly discuss the mid-session redirection during a re- 677 registration or a handover triggered PBU/PBA exchange. From the MAG 678 point of view the actual procedural steps for mid-session redirection 679 are the same as described in Section 5.5.1. There are few notable 680 differences on the LMA side though. 682 o The previous r2LMA cannot redirect the mobility session to a new 683 r2LMA during the re-registration or the handover PBU/PBA exchange 684 unless it also implements rfLMA functionality. The lack of rfLMA 685 functionality in the r2LMA implicitly prohibits mid-session 686 redirection using the solution defined in this specification. 688 o The previous r2LMA cannot redirect the mobility session to a new 689 r2LMA during the re-registration or the handover PBU/PBA exchange 690 unless the previous r2LMA is able to transfer the "mobility 691 session context" to the new r2LMA. Otherwise, the new r2LMA would 692 receive a PBU with Handoff Indicator set to other than "Attachment 693 over a new interface" and there would not be a matching BCE. This 694 is an undefined situation and would most likely result the 695 mobility session to be terminated. [ED: add more details here]. 696 Note that a possible context transfer between LMAs is out of scope 697 of this specification. 699 6. Multi-Homing Considerations 701 A MN can be multi-homed. A single LMA entity should have the control 702 over all possible multi-homed mobility sessions the MN has. All 703 mobility sessions a multi-homed MN may have SHOULD be anchored in the 704 single LMA entity. Therefore, once the MN has established one 705 mobility session with one LMA, the subsequent mobility sessions of 706 the same MN SHOULD be anchored to the LMA that was initially 707 assigned. 709 One possible solution already supported by this specification is 710 applying the redirection only for the very first initial attach a 711 multi-homed MN does towards a PMIPv6 domain. After the initial 712 attach, the assigned r2LMA Address has been stored in the policy 713 profile. For the subsequent mobility sessions of the multi-homed MN, 714 the same assigned r2LMA Address would be used and there is no need to 715 contact the rfLMA. 717 MAGs have a control over selectively enabling and disabling the 718 redirection of the LMA. If the multi-homed MN is attached to a 719 PMIPv6 domain via multiple MAGs, the assigned r2LMA Address should be 720 stored in the remote policy store and downloaded as a part of the 721 policy profile download to a MAG. Alternatively, MAGs can share 722 policy profile information using other means. In both cases, the 723 actual implementation of the policy profile information sharing is 724 specific to a PMIPv6 deployment and out of scope of this 725 specification. 727 7. Configuration Variables 729 This specification defines three configuration variables that control 730 the redirection functionality within a PMIPv6 domain. 732 EnableLMARedirectFunction 734 This configuration variable is available in both a MAG and in a 735 rfLMA. When set to 1 (i.e., enabled), the PMIPv6 node enables the 736 redirection functionality. The default value is 0 (i.e., 737 disabled). 739 EnableLMARedirectAcceptFunction 741 This configuration variable is available in a r2LMA. When set to 742 1 (i.e., enabled), the r2LMA is able to accept redirected mobility 743 sessions from a rfLMA. The default value is 0 (i.e., disabled). 745 8. Security Considerations 747 The security considerations of PMIPv6 signaling described in RFC 5213 748 apply to this document. An incorrectly configured LMA may cause 749 unwanted redirection attempts to non-existing LMAs or to other LMAs 750 that do not have and will not have a SA with the redirected MAG. At 751 the same time, a falsely redirected MAG will experience failed 752 binding updates or creation of mobility sessions. An incorrectly 753 configured LMA may also cause biased load distribution within a 754 PMIPv6 domain. This document also assumes that the LMAs that 755 participate to redirection have adequate prior agreement and trust 756 relationship between each other. 758 If the SAs between MAGs and LMAs are manually keyed (as it might be 759 needed by the 'direct redirection answer' scenario), then the anti- 760 replay service of ESP protected PMIPv6 traffic cannot typically be 761 provided. This is, however, deployment specific for a PMIPv6 domain. 763 If a PMIPv6 domain deployment with a redirection requires that a 764 rfLMA has to modify a received PBU in any way e.g., by changing the 765 destination IP address field of the outer IP header, then the 766 security mechanism (such as possible authentication options) used to 767 protect the PBU must not cover the outer IP header on those parts 768 that might get modified. Alternatively, the rfLMA can do all 769 required security mechanism processing on the received PBU and remove 770 those security related options from the PBU that would cause the 771 security check to fail on the r2LMA. 773 9. IANA Considerations 775 Two new mobility options for the use with PMIPv6 are defined in the 776 [RFC3775] "Mobility Options" registry. The mobility options are 777 defined in Section 4: 779 Redirect-Capability Mobility Option is set to TBD1 780 Redirect Mobility Option is set to TBD2 782 This document defines the following new Status value for use in PBA 783 messages. The value is to be allocated from the same number space, 784 as defined in Section 6.1.8 of [RFC3775]. The allocated value MUST 785 be greater than 128 indicating that the PBU was rejected by the LMA: 787 NOT_LMA_FOR_THIS_MAG is set to TBD3 789 10. Acknowledgements 791 The author would like to thank Basavaraj Patil and Domagoj Premec for 792 their reviews and comments on the initial versions of this document. 793 The authors also thank Yungui Wang and Qin Wu for their comments and 794 discussion on this document. 796 11. References 798 11.1. Normative References 800 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 801 Requirement Levels", BCP 14, RFC 2119, March 1997. 803 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 804 in IPv6", RFC 3775, June 2004. 806 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 807 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 809 11.2. Informative References 811 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 812 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 813 RFC 2136, April 1997. 815 [RFC3484] Draves, R., "Default Address Selection for Internet 816 Protocol version 6 (IPv6)", RFC 3484, February 2003. 818 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 819 Architecture", RFC 4291, February 2006. 821 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 822 RFC 4303, December 2005. 824 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 825 RFC 4306, December 2005. 827 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 828 "Mobility Header Home Agent Switch Message", RFC 5142, 829 January 2008. 831 Authors' Addresses 833 Jouni Korhonen (editor) 834 Nokia Siemens Networks 835 Linnoitustie 6 836 FI-02600 Espoo 837 FINLAND 839 Email: jouni.nospam@gmail.com 841 Sri Gundavelli 842 Cisco 843 170 West Tasman Drive 844 San Jose, CA 95134 845 USA 847 Email: sri.gundavelli@cisco.com 849 Hidetoshi Yokota 850 KDDI Lab 851 2-1-15 Ohara, Fujimino 852 Saitama, 356-8502 853 Japan 855 Email: yokota@kddilabs.jp 857 Xiangsong Cui 858 Huawei 860 Email: Xiangsong.Cui@huawei.com