idnits 2.17.1 draft-ietf-netext-redirect-12.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 (October 13, 2011) is 4572 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) == Missing Reference: 'MAG' is mentioned on line 720, but not defined -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 15, 2012 Cisco 6 H. Yokota 7 KDDI Lab 8 X. Cui 9 Huawei Technologies 10 October 13, 2011 12 Runtime LMA Assignment Support for Proxy Mobile IPv6 13 draft-ietf-netext-redirect-12.txt 15 Abstract 17 This document describes a runtime Local Mobility Anchor assignment 18 functionality and corresponding mobility options for Proxy Mobile 19 IPv6. The runtime Local Mobility Anchor assignment takes place 20 during a Proxy Binding Update and a Proxy Binding Acknowledgement 21 message exchange between a Mobile Access Gateway and a Local Mobility 22 Anchor. The runtime Local Mobility Anchor assignment functionality 23 defined in this specification can be used, for example, for load 24 balancing purposes. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 15, 2012. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4 62 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 5 65 4. Mobility Options . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Redirect-Capability Mobility Option . . . . . . . . . . . 5 67 4.2. Redirect Mobility Option . . . . . . . . . . . . . . . . . 6 68 4.3. Load Information Mobility Option . . . . . . . . . . . . . 7 69 4.4. Alternate IPv4 Care-of Address Mobility Option . . . . . . 9 70 5. Runtime LMA Assignment . . . . . . . . . . . . . . . . . . . . 9 71 5.1. General Operation . . . . . . . . . . . . . . . . . . . . 9 72 5.2. Mobile Access Gateway Operation . . . . . . . . . . . . . 10 73 5.3. Local Mobility Anchor Operation . . . . . . . . . . . . . 11 74 5.3.1. Collocated rfLMA and r2LMA Functions . . . . . . . . . 12 75 5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) . . . . 14 76 6. Handoff and Multi-Homing Considerations . . . . . . . . . . . 18 77 7. Configuration Objects . . . . . . . . . . . . . . . . . . . . 18 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 This specification describes a runtime assignment of a Local Mobility 89 Anchor (LMA) for Proxy Mobile IPv6 (PMIPv6) [RFC5213] protocol. The 90 runtime LMA assignment takes place during a Proxy Binding Update 91 (PBU) and a Proxy Binding Acknowledgement (PBA) message exchange 92 between a Mobile Access Gateway (MAG) and a LMA. The runtime LMA 93 assignment functionality defined in this specification can be used, 94 for example, for load balancing purposes. MAGs and LMAs can also 95 implement other load balancing mechanisms that are completely 96 transparent at PMIPv6 protocol level and do not depend on the 97 functionality defined in this specification. 99 The runtime LMA assignment functionality does not depend on the 100 Domain Name System (DNS) or the Authentication, Authorization and 101 Accounting (AAA) infrastructure for the assignment of the LMA where 102 the mobile node is anchored to. All MAGs and LMAs (either rfLMAs or 103 r2LMAs, see Section 2.2) have to belong to the same PMIPv6 domain. 105 There are number of reasons why the runtime LMA assignment is a 106 useful addition to the PMIPv6 protocol. Few identified ones are 107 listed below: 109 o LMAs with multiple IP addresses: a cluster of LMAs or a blade 110 architecture LMA may appear to the routing system as multiple LMAs 111 with separate unicast IP addresses. A MAG can initially select 112 any of the LMA's as the serving LMA using for example, DNS- and 113 AAA-based solutions. However, MAG's initial selection may be 114 suboptimal from the LMA point of view and immediate runtime 115 assignment to a "proper LMA" would be needed. The LMA could use 116 [RFC5142] based approach but that would imply unnecessary setting 117 up of a mobility session in a "wrong LMA" with associated backend 118 support system interactions, involve additional signaling between 119 the MAG and the LMA, and re-establishing mobility session to the 120 new LMA again with associated signaling. 122 o Bypassing a load balancer: a cluster of LMAs or a blade 123 architecture LMA may have a load balancer in front of them or 124 integrated in one of the LMAs. The load balancer would represent 125 multiple LMAs during the LMA discovery phase and only its IP 126 address would be exposed to the MAG hiding possible individual LMA 127 or LMA blade IP addresses from the MAG. However, if all traffic 128 must always go through the load balancer it becomes quickly a 129 bottleneck. Therefore, a PMIPv6 protocol level support for 130 bypassing the load balancer after the initial PBU/PBA exchange 131 would greatly help scalability. Also bypassing the load balancer 132 as soon as possible allows implementing load balancers that do not 133 maintain any Mobile Node (MN) specific state information. 135 o Independence from DNS: DNS-based load balancing is a common 136 practice. However, keeping MAGs up-to-date with LMA load status 137 using DNS is hard e.g., due to caching and unpredictable zone 138 update delays [RFC6097]. Generally, LMAs constantly updating 139 [RFC2136] zone's master DNS server might not feasible in a large 140 PMIPv6 domain due to increased load on the master DNS server and 141 additional background signaling. Furthermore, MAGs may do (LMA) 142 destination address selection decisions that are not in-line with 143 what the DNS administrator actually wanted [RFC3484]. 145 o Independence from AAA: AAA-based solutions have basically the same 146 arguments as DNS-based solutions above. It is also typical that 147 AAA-based solutions offload the initial LMA selection to the DNS 148 infrastructure [RFC5779]. The AAA infrastructure does not return 149 an IP address or a Fully Qualified domain Name (FQDN) to a single 150 LMA, rather a FQDN representing a group of LMAs. 152 o Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6 153 specification does not specify how the PMIPv6 protocol should 154 treat anycast addresses assigned to mobility agents. For example, 155 a blade architecture LMA may have an unique unicast IP address for 156 each blade and a single anycast address for all blades. A MAG 157 could then initially send a PBU to an anycast LMA address and 158 receive a PBA from an anycast LMA address. Once the MAG receives 159 the unicast address of the runtime assigned LMA blade through the 160 initial PBU/PBA exchange, the subsequent communication continues 161 using the unicast address. 163 As a summary, the DNS/AAA based approaches cannot be used to select 164 an "appropriate" LMA at runtime. Therefore, this specification 165 defines a solution that is applicable for blade/cluster LMA 166 implementations where the IP address known to the MAG is not the best 167 LMA of choice at runtime. 169 2. Requirements and Terminology 171 2.1. Requirements 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 2.2. Terminology 179 In addition to the terminology defined in [RFC5213], the following 180 terminology is also used: 182 rfLMA 184 An LMA which receives a PBU from a MAG and decides to assign an IP 185 mobility session with a new target LMA (r2LMA). 187 r2LMA 189 The LMA assigned to a MAG as a result of the runtime LMA 190 assignment. 192 Runtime Assignment Domain 194 A group of LMAs that consist of at least one rfLMA and one or more 195 r2LMAs. A rfLMA is allowed to assign MAGs only with r2LMAs that 196 belong to the same runtime assignment domain. The rfLMA and one 197 or more r2LMAs may consist of multiple blades in a single network 198 element, multiple physical network elements, or multiple LMAs 199 distributed geographically. 201 3. Proxy Mobile IPv6 Domain Assumptions 203 The runtime LMA assignment functionality has few assumptions within 204 the PMIPv6 domain. 206 Each LMA in a runtime assignment domain MUST be reachable at an 207 unicast IP address. The rfLMA and the r2LMA MUST have a prior 208 agreement, adequate means to secure their inter-LMA communication and 209 an established trust relationship to perform the runtime LMA 210 assignment. 212 Each LMA and MAG participating in the runtime LMA assignment is 213 assumed to have required Security Associations (SA) pre-established. 214 Dynamic negotiation of the SAs using e.g., IKEv2 [RFC5996] SHOULD be 215 supported but is out of scope of this specification. 217 4. Mobility Options 219 In the following sections all presented values, bit fields and 220 addresses are in network byte order. 222 4.1. Redirect-Capability Mobility Option 224 The Redirect-Capability mobility option has the alignment requirement 225 of 4n. There can be zero or one Redirect-Capability mobility option 226 in the PBU. The format of the Redirect-Capability mobility option is 227 shown below: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Option Type | Option Length | Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Redirect-Capability Mobility Option 237 o Option Type: 8-bit identifier set to TBD1. 239 o Option Length: 8-bit unsigned integer, representing the length of 240 the Redirect-Capability mobility option in octets, excluding the 241 Option Type and Length fields. The Option Length MUST be set to 242 2. 244 o Reserved: This field is reserved for future use. MUST be set to 245 zero by the sender and ignored by the receiver. 247 The Redirect-Capability option is used by the MAG to inform the LMA 248 that is implements and has enabled the runtime LMA assignment 249 functionality. 251 4.2. Redirect Mobility Option 253 The Redirect mobility option in the PBA MUST contain an unicast 254 address of the r2LMA and the address family MUST be the same as the 255 currently used transport between the MAG and the rfLMA. There can 256 zero or one Redirect mobility option in the PBA. The Redirect 257 mobility option has the alignment requirement of 4n. The format of 258 the Redirect mobility option is shown below: 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Option Type | Option Length |K|N| Reserved | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 | Optional IPv6 r2LMA Address | 267 | | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Optional IPv4 r2LMA Address | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Redirect Mobility Option 275 o Option Type: 8-bit identifier set to TBD2. 277 o Option Length: 8-bit unsigned integer, representing the length of 278 the Redirect mobility option in octets, excluding the Option Type 279 and Length fields. If 'K' flag is set and 'N' is unset, then the 280 length MUST be 18. If 'K' flag is unset and 'N' is set, then the 281 length MUST be 6. Both 'K' and 'N' flags cannot be set or unset 282 simultaneously. 284 o 'K' flag: This bit is set (1) if the 'Optional IPv6 r2LMA Address' 285 is included in the mobility option. Otherwise, the bit is unset 286 (0). 288 o 'N' flag: This bit is set (1) if the 'Optional IPv4 r2LMA Address' 289 is included in the mobility option. Otherwise, the bit is unset 290 (0). 292 o Reserved: This field is reserved for future use. MUST be set to 293 zero by the sender and ignored by the receiver. 295 o Optional IPv6 r2LMA Address: the unicast IPv6 address of the 296 r2LMA. This value is present when the corresponding PBU was 297 sourced from an IPv6 address. 299 o Optional IPv4 r2LMA Address: the IPv4 address of the r2LMA. This 300 value is present when the corresponding PBU was sourced from an 301 IPv4 address (for IPv4 transport, see [RFC5844]). 303 The Redirect option is used by the LMA to inform the MAG that the 304 runtime LMA assignment took place and the MAG has to update its 305 Binding Update List Entry (BULE) for the mobility session. 307 4.3. Load Information Mobility Option 309 The Load Information mobility option can be included in any PBA and 310 is used to report priority and key load information of a LMA to a MAG 311 (or to a 'proxy-MAG'). The Load Information mobility option has the 312 alignment requirement of 4n. The format of the mobility option is 313 shown below: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Option Type | Option Length | Priority | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Sessions in Use | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Maximum Sessions | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Used Capacity | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Maximum Capacity | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Load Information Mobility Option 331 o Option Type: 8-bit identifier set to TBD4. 333 o Option Length: 8-bit unsigned integer, representing the length of 334 the Load Information mobility option in octets, excluding the 335 Option Type and Length fields. The length is set to 18. 337 o Priority: 16-bit unsigned integer, representing the priority of an 338 LMA. The lower value the higher priority. The priority has only 339 meaning among a group of LMAs under the same administration, for 340 example, determined by a common LMA FQDN, a domain name or a 341 realm. 343 o Sessions in Use: 32-bit unsigned integer, representing the number 344 of parallel mobility sessions the LMA has in use. 346 o Maximum Sessions: 32-bit unsigned integer, representing the 347 maximum number of parallel mobility sessions the LMA is willing to 348 accept. 350 o Used Capacity: 32-bit unsigned integer, representing the used 351 bandwidth/throughput capacity of the LMA in kilobytes per second. 353 o Maximum Capacity: 32-bit unsigned integer, representing the 354 maximum bandwidth/throughput capacity in kilobytes per second the 355 LMA is willing to accept. 357 The session and capacity information can easily be used to calculate 358 different load factors of the LMA. A MAG (or a 'proxy-MAG') MAY use 359 the priority and load information to internally maintain priority 360 ordering of LMAs. 362 4.4. Alternate IPv4 Care-of Address Mobility Option 364 The Alternate IPv4 Care-of Address (A4CoA) mobility option has the 365 alignment requirement of 4n+2. The format of the mobility option is 366 shown below: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Option Type | Option Length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Alternate IPv4 Care-of Address | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Alternate IPv4 Care-of Address Mobility Option 378 o Option Type: 8-bit identifier set to TBD5. 380 o Option Length: 8-bit unsigned integer, representing the length of 381 the Load Information mobility option in octets, excluding the 382 Option Type and Length fields. The length is set to 4. 384 o Alternate IPv4 Care-of Address: an IPv4 equivalent of the 385 [RFC6275] Alternate Care-of Address option for IPv6. In the 386 context of PMIPv6 its semantic is equivalent to the Alternate 387 Care-of Address option for IPv6. 389 A MAG MAY include the Alternate IPv4 Care-of Address option in a PBU. 390 An LMA that receives and implements the Alternate IPv4 Care-of 391 Address option MUST echo the option as such back to the MAG in a 392 reply PBA. 394 5. Runtime LMA Assignment 396 5.1. General Operation 398 During the runtime LMA assignment, the PBA is returned from the LMA 399 Address to which the PBU was sent to i.e., from the rfLMA address. 400 After the runtime LMA assignment all PMIPv6 communication continues 401 directly between the MAG and the r2LMA bypassing the rfLMA. The 402 overall runtime LMA assignment flow sequence is shown in Figure 1. 404 [MAG] [rfLMA] [r2LMA] 405 | | | 406 1) |--PBU-->| | LMA assignment takes place in rfLMA. 407 | | | 408 2) | | ~ ~ ~ >|\ 409 | | | + BCE gets created in r2LMA. 410 3) | |<~ ~ ~ ~|/ 411 | | | 412 4) |<--PBA--| | PBA contains r2LMA information. 413 | | | 414 |<=====data======>| 415 | | | 416 5) |-------PBU------>| Lifetime extension, 417 6) |<------PBA-------| de-registration, etc. 418 | | | 420 Figure 1: Runtime LMA assignment from rfLMA to r2LMA and setting up a 421 mobility session in the r2LMA within a runtime assignment domain 423 The assumption in the signaling flow step 1) shown in Figure 1 is 424 that the mobility session gets created in the r2LMA, although the 425 rfLMA is responsible for interfacing with the MAG. There are several 426 possible solutions for the rfLMA and the r2LMA interaction depending 427 on e.g. the collocation properties of the rfLMA and the r2LMA. This 428 specification describes two: 430 o Collocated rfLMA & r2LMA functions, where the 'rfLMA side of the 431 LMA' is reachable via an anycast address or the loopback address 432 of the LMA. See Section 5.3.1 for further details. 434 o Separate rfLMA & r2LMA functions, where the rfLMA acts as a non- 435 transparent 'proxy-MAG' to a r2LMA. See Section 5.3.2 for further 436 details. 438 There are other possible implementations of the rfLMA and the r2LMA. 439 At the end, as long as the protocol between the MAG and the rfLMA 440 follows this specification , the collocation or inter-communication 441 properties of the rfLMA and the r2LMA do not matter. 443 5.2. Mobile Access Gateway Operation 445 In the base PMIPv6 protocol [RFC5213] a MAG sends a PBU to an LMA, 446 which results in a Binding Cache Entry (BCE) creation at the LMA and 447 the LMA sending a PBA sent back to the MAG. The MAG in turn creates 448 a corresponding Binding Update List Entry (BULE). This specification 449 extends the base protocol with the runtime LMA assignment 450 functionality. 452 If the MAG supports the runtime LMA assignment and the functionality 453 is also enabled (see EnableLMARedirectFunction configuration object 454 in Section 7), then the MAG includes the Redirect-Capability mobility 455 option in a PBU that establishes a new mobility session (i.e. 456 Handoff Indicator Option in the PBU has the value of 1). The 457 Redirect-Capability mobility option in the PBU is also an indication 458 to an LMA that the MAG supports the runtime LMA assignment 459 functionality and is prepared to be assigned with a different LMA. 460 The runtime LMA assignment concerns always one mobility session at a 461 time. 463 If the MAG receives a PBA that contains the Redirect mobility option 464 without first including the Redirect-Capability mobility option in 465 the corresponding PBU, then the MAG MUST ignore the option and 466 process the PBA as described in RFC 5213. 468 If the MAG receives a PBA that contains the Redirect mobility option 469 and the MAG had included the Redirect-Capability mobility option in 470 the corresponding PBU, then the MAG MUST perform the following steps 471 in addition to the normal RFC 5213 PBA processing: 473 o The MAG updates its BULE to contain the r2LMA address included in 474 the received Redirect mobility option. 476 o If there is no SA between the MAG and the r2LMA, the MAG SHOULD 477 initiate a dynamic creation of the SA between the MAG and the 478 r2LMA as described in Section 4 of RFC 5213. If the dynamic SA 479 creation fails, the MAG SHOULD log the event. The MAG MAY retry 480 the dynamic creation of the SA, and if those also fail, the newly 481 created BULE (and also the BUL in the r2LMA) will eventually 482 timeout. If the failure is persistent, it can be regarded as a 483 system level configuration error. 485 The MAG is not required to send a fresh PBU to the r2LMA after a 486 successful runtime assignment. The mobility session has already been 487 established in the r2LMA. The MAG MUST send all user traffic to the 488 r2LMA address. The MAG MUST send subsequent binding refresh PBUs 489 (e.g., lifetime extension, handoff etc) to the r2LMA address. If 490 there is no existing tunnel between the MAG and the r2LMA unicast 491 address, then the MAG creates one as described in Section 6.9.1 of 492 [RFC5213]. 494 5.3. Local Mobility Anchor Operation 496 The text in the following sections refers to an 'LMA' when it means 497 the combination of the rfLMA and the r2LMA i.e., the entity where 498 runtime LMA assignment is possible. When the text points to a 499 specific LMA role during the runtime assignment, it uses either the 500 'rfLMA' or the 'r2LMA'. 502 If the runtime assignment functionality is enabled (see 503 EnableLMARedirectFunction configuration object in Section 7) in the 504 rfLMA but the LMA assignment is not going to take place for some 505 reason, and the rfLMA is not willing to serve (or capable of) as a 506 normal RFC 5213 LMA for the MAG, then the rfLMA MUST reject the PBU 507 and send back a PBA with Status Value set to 130 (Insufficient 508 resources) error code. If the rfLMA is able to make the assignment 509 to an r2LMA, it returns a PBA with the Redirect mobility option as 510 defined below. Otherwise, the rfLMA MUST act as a normal RFC 5213 or 511 RFC 5844 defined LMA for the MAG. 513 The rfLMA MUST only assign the MAG to a new r2LMA with which it knows 514 the MAG has an SA or with which it knows the MAG can establish an SA 515 dynamically. The rfLMA MUST NOT assign the MAG with a r2LMA that the 516 rfLMA and the r2LMA do not have a prior agreement and an established 517 trust relationship for the runtime LMA assignment. These SA related 518 knowledge issues and trust relationships are deployment specific in a 519 PMIPv6 domain and in a runtime assignment domain, and out of scope of 520 this specification. Possible context transfer and other coordination 521 management between the rfLMA and the r2LMA are again deployment 522 specific for LMAs in a runtime assignment domain. The rfLMA MUST NOT 523 change the used transport IP address family during the runtime LMA 524 assignment. 526 As a result of a successful runtime LMA assignment, the PBA MUST 527 contain the Redirect mobility option with a valid r2LMA unicast 528 address and the PBA Status Value indicating success. 530 Next we describe two deployment and implementation models for the 531 runtime LMA assignment. In Section 5.3.1, we describe a model where 532 the rfLMA and r2LMA are collocated. In Section 5.3.2 we describe a 533 model where rfLMA acts as a non-transparent 'proxy MAG', and where 534 the rfLMA and the r2LMA are separate. There can be even more 535 implementation options depending on the rfLMA and the r2LMA 536 collocation properties, and how the inter-LMA communication is 537 arranged. 539 5.3.1. Collocated rfLMA and r2LMA Functions 541 In this solution approach the rfLMA and the r2LMA are part of the 542 same 'collocated LMA', and may even be using to the same physical 543 network interface. The rfLMA is reachable via an anycast or a 544 loopback address of the LMA. Each r2LMA is reachable via its unicast 545 address. Figure 2 illustrates example signaling flows for the 546 solution. 548 The MAG-LMA SA is between the MAG and the rfLMA (i.e. the anycast or 549 the loopback address of the LMA). How this SA has been set up is out 550 of scope of this specification but a manual SA configuration is one 551 possibility. 553 The rfLMA becomes active when the runtime LMA assignment 554 functionality is enabled (see EnableLMARedirectFunction configuration 555 object in Section 7). When the rfLMA receives a PBU destined to it, 556 and the PBU contains the Redirect-Capability mobility option, then 557 the 'collocated LMA' MUST create a mobility session in a r2LMA role 558 using the procedures described in RFC 5213. If there is no existing 559 tunnel between the MAG and the r2LMA unicast address, then the r2LMA 560 creates one as described in Section 5.3 of [RFC5213]. The r2LMA used 561 for accepting and anchoring the mobility session MUST also have the 562 runtime LMA assignment functionality enabled (see 563 EnableLMARedirectAcceptFunction configuration object in Section 7). 565 If the mobility session creation succeeded, then 'collocated LMA' in 566 the rfLMA role sends a PBA to the MAG. The PBA is sourced using the 567 rfLMA (anycast or loopback) address. The PBA MUST contain the r2LMA 568 unicast address (IPv6 or IPv4) in the Redirect mobility option. 570 If the PBU is received on the r2LMA unicast address, then the PBU is 571 processed as described in RFC 5213 and the response PBA MUST NOT 572 contain the Redirect mobility option. 574 If the PBU is received on the rfLMA address and there is no Redirect- 575 Capability mobility option in the PBU, then the 'collocated LMA' MAY 576 choose to be a LMA for the MAG (assuming the rfLMA address is not an 577 anycast address). Otherwise, the rfLMA MUST reject the PBU and send 578 back a PBA in a rfLMA role with Status Value set to 130 (Insufficient 579 resources) error code (as mentioned in Section 5.3). 581 [MAG] [rfLMA /r2LMA_1/r2LMA_2/r2LMA_3] 582 | | | | | 583 MAG discovers rfLMA | | | | 584 BULE for rfLMA | | | | 585 | | | | | 586 |-- PBU --------------------->| | | | 587 | src=MAG_Proxy-CoA, | | | | 588 | dst=rfLMA, | | | | 589 | Redirect-Capability, .. | r2LMA gets selected | 590 | BCE is created in r2LMA_2 591 | |Tunnel setup in r2LMA_2| 592 | | | | | 593 |<- PBA ----------------------| | | | 594 | src=rfLMA, | | | | 595 | dst=MAG_Proxy-CoA, | | | | 596 | Redirect=r2LMA_2_address, | | | | 597 | Load Info, .. | | | | 598 | | | | | 599 BULE updated to r2LMA_2 | | | | 600 Tunnel setup | | | | 601 | | | | | 602 |<=========== MAG-r2LMA_2 tunnel ============>| | 603 | | | | | 604 Lifetime extension etc | | | | 605 | | | | | 606 |-- PBU ------------------------------------->| | 607 | src=MAG_Proxy-CoA, | | | | 608 | dst=r2LMA_2, .. | | | | 609 | | | | | 610 |<- PBA --------------------------------------| | 611 | src=r2LMA_2, | | | | 612 | dst=MAG_Proxy-CoA, | | | | 613 | Load Info, .. | | | | 614 | | | | | 616 Figure 2: Collocated rfLMA and r2LMA example 618 5.3.2. Separate rfLMA and r2LMA Functions (Proxy-MAG) 620 In this solution approach the rfLMA and the r2LMA are two isolated 621 functions, and may even be physically separate networking nodes. The 622 r2LMA can be any RFC 5213 or RFC 5844 compliant LMA without any 623 knowledge of this specification when IPv6 transport is used. In case 624 of IPv4 transport the RFC 5844 compliant LMA MUST also implement the 625 Alternate IPv4 Care-of Address option (see Section 4.4). Figure 3 626 illustrates example signaling flows for the solution. 628 The rfLMA is actually a non-transparent 'proxy-MAG' (see [RFC2616] 629 for a generic definition of a non-transparent proxy, although for 630 HTTP, but the idea also applies here) which shows up as an LMA 631 implementing this specification towards the MAG, and as a base RFC 632 5213 compliant MAG to the r2LMA. This type of operation is also 633 referred as 'chaining' in other contexts. The protocol between the 634 'proxy-MAG' and the r2LMA is the base RFC 5213 PMIPv6 protocol. 636 The MAG-LMA SA is between the MAG and the rfLMA, and RFC 5213 SA 637 considerations apply fully. The MAG has no knowledge of the 'proxy- 638 MAG'-r2LMA SA. RFC 5213 considerations regarding the SA between the 639 'proxy-MAG' and the r2LMA apply fully. It is also possible that 640 'proxy-MAG'-r2LMA security is arranged using other means than IPsec, 641 for example using layer-2 VPNs. 643 When the rfLMA receives a PBU, and the PBU contains the Redirect- 644 Capability mobility option, then the rfLMA in a 'proxy-MAG' role: 646 o Processes the PBU using the procedures described in RFC 5213 647 except that no mobility session gets created. Instead the rfLMA 648 creates a proxy state based on the received PBU. 650 o The rfLMA assigns a r2LMA to the MAG. 652 o The rfLMA creates a new PBU', which includes all non-security 653 related mobility options from the original PBU and an Alternate 654 Care-of Address (ACoA) option containing the Proxy Care-of Address 655 of the original MAG. If the original PBU already included an 656 Alternate Care-of Address option, then the content of the 657 Alternate Care-of Address option in the PBU' MUST be the same as 658 in the original PBU. 660 Note, in case of IPv4 transport [RFC5844], the Alternate IPv4 661 Care-of Address (A4CoA) option MUST be used and contain the IPv4 662 Proxy Care-of Address of the original MAG. 664 o The rfLMA sends the new PBU' sourced from its 'proxy-MAG' IPv6 or 665 IPv4 Proxy Care-of Address and destined to the r2LMA address using 666 the procedures described in RFC 5213 (or RFC 5844 in case of IPv4 667 transport). 669 The r2LMA processed the received PBU' using the procedures described 670 in RFC 5213 or RFC 5844. In case of IPv4 transport, the r2LMA uses 671 the IPv4 Proxy Care-of Address from the Alternate IPv4 Care-of 672 Address option for the tunnel setup and the creation of the BCE. The 673 reply PBA' MUST be destined to the source address of the received 674 PBU' i.e. the Care-of Address the 'proxy-MAG'. 676 Once the rfLMA in a 'proxy-MAG' role receives a reply PBA' from the 677 r2LMA and the mobility session creation succeeded in the r2LMA, the 678 rfLMA sends a PBA to the original MAG. The PBA is sourced from the 679 rfLMA address and destined to MAG (IPv6 or IPv4) Proxy Care-of 680 Address. The PBA MUST contain the r2LMA (IPv6 or IPv4) unicast 681 address in the Redirect mobility option. Other non-security related 682 mobility options (including the Load Information option) are copied 683 from the PBA' to the PBA as such. 685 In the case of an error: 687 o The PBA' Status Value indicates that the mobility session creation 688 failed in the r2LMA. For example, the Status Value in the PBA' is 689 set to 130 - Insufficient resources, or 691 o there was no PBA' response from the r2LMA, or 693 o the PBA' did not include the Alternate IPv4 Care-of Address option 694 although it was included in the corresponding PBU' (when using 695 IPv4 transport), 697 then the rfLMA SHOULD assign the MAG to a new r2LMA and rerun the 698 PBU' sending procedure described earlier for the new r2LMA. The 699 number and order of r2LMA reassignments attempts is controlled by the 700 local policy and the amount of known r2LMAs in the rfLMA. When the 701 rfLMA in a 'proxy-MAG' role concludes the mobility session creation 702 failed with r2LMA(s), the rfLMA MUST set the Status Value in the PBA 703 as received from the latest contacted PBA' Status Value or to 130 704 (Insufficient resources) in case of no responses from rfLMAs, and 705 send the reply PBA to the MAG. The PBA is sourced from the rfLMA 706 address and destined to MAG Proxy Care-of Address. Other possible 707 non-security related mobility options (including the Load Information 708 option) are copied from the PBA' to the PBA as such. 710 Once the rfLMA has sent the reply PBA to the MAG, it can remove the 711 proxy state. Subsequent traffic between the MAG and the r2LMA will 712 bypass the rfLMA (assuming the mobility session creation succeeded in 713 the r2LMA). 715 If the rfLMA receives a PBU with no Redirect-Capability mobility 716 option in the PBU, then the PBU is processed as described in 717 Section 5.3), i.e. the rfLMA may or may not act as a RFC 5213 or RFC 718 5844 LMA to the MAG. 720 [MAG] [rfLMA] [r2LMA] 721 | | | 722 MAG discovers rfLMA | | 723 BULE for rfLMA | | 724 | | | 725 |-- PBU --------------------->| rfLMA assigns a r2LMA and | 726 | src=MAG_Proxy-CoA, | creates a proxy state | 727 | dst=rfLMA, | | 728 | Redirect-Capability, .. | | 729 | |-- PBU' -------------------->| 730 | | src=proxy-MAG_Proxy-CoA, | 731 | | dst=r2LMA, | 732 | | ACoA/A4CoA=MAG_Proxy-CoA, | 733 | | .. | 734 | | BCE created in r2LMA 735 | | Tunnel setup 736 | | Proxy-CoA is MAG's address 737 | | | 738 | rfLMA removes the |<- PBA' ---------------------| 739 | proxy state | src=r2LMA, | 740 | | dst=proxy-MAG_Proxy-CoA, | 741 | | Load Info, .. | 742 |<- PBA ----------------------| | 743 | src=rfLMA, | | 744 | dst=MAG_Proxy-CoA, | | 745 | Redirect=r2LMA_address, | | 746 | Load Info, .. | | 747 | | | 748 BULE updated to r2LMA | | 749 Tunnel setup | | 750 | | | 751 |<===================== MAG-r2LMA tunnel ==================>| 752 | | | 753 Lifetime extension etc | | 754 | | | 755 |-- PBU --------------------------------------------------->| 756 | src=MAG_Proxy-CoA, dst=r2LMA, .. | 757 | | | 758 |<- PBA ----------------------------------------------------| 759 | src=r2LMA, dst=MAG_Proxy-CoA, Load Info, .. | 760 | | | 762 Figure 3: Separate rfLMA and r2LMA ('proxy-MAG') example 764 6. Handoff and Multi-Homing Considerations 766 A MN can be multi-homed i.e. have network connectivity over multiple 767 interfaces connected one or more accesses. If PMIPv6-based handovers 768 between multiple interfaces or accesses are desired then a single LMA 769 should have a control over all possible multi-homed mobility sessions 770 the MN has. Once the MN has established one mobility session with 771 one LMA, the subsequent mobility sessions of the same MN would be 772 anchored to the LMA that was initially assigned. If each mobility 773 session over a different interface (and possibly a MAG) has no 774 requirements for PMIPv6-based handovers between accesses or 775 interfaces, then the rest of the considerations in this section do 776 not apply. 778 One possible solution already supported by this specification is 779 applying the runtime LMA assignment only for the very first initial 780 attach a multi-homed MN does towards a PMIPv6 domain. After the 781 initial attach, the assigned r2LMA Address has been stored in the 782 policy profile. For the subsequent mobility sessions of the multi- 783 homed MN, the same assigned r2LMA Address would be used and there is 784 no need to contact the rfLMA. Discovering the same r2LMA each time 785 has an assumption that the MN has an identity that can always point 786 to the same policy profile independent of the used access. 788 MAGs have a control over selectively enabling and disabling the 789 runtime assignment of the LMA. If the multi-homed MN is attached to 790 a PMIPv6 domain via multiple MAGs, the assigned r2LMA Address should 791 be stored in the remote policy store and downloaded as a part of the 792 policy profile download to a MAG. Alternatively, MAGs can share 793 policy profile information using other means. In both cases, the 794 actual implementation of the policy profile information sharing is 795 specific to a PMIPv6 deployment and out of scope of this 796 specification. 798 7. Configuration Objects 800 This specification defines two configuration objects that control the 801 runtime LMA assignment functionality within a PMIPv6 domain. 803 EnableLMARedirectFunction 805 This configuration object is available in both a MAG and in a 806 rfLMA. When set to TRUE (i.e., enabled), the PMIPv6 node enables 807 the runtime LMA assignment functionality. The default value is 808 FALSE (i.e., disabled). 810 EnableLMARedirectAcceptFunction 812 This configuration object is available in a r2LMA. When set to 813 TRUE (i.e., enabled), the r2LMA is able to accept runtime LMA 814 assignment mobility sessions from a rfLMA. The default value is 815 FALSE (i.e., disabled). 817 Note that the MAG and LMA configuration objects from [RFC5213] 818 Sections 9.1 and 9.2 do not apply for an LMA when in an rfLMA role. 820 8. Security Considerations 822 The security considerations of PMIPv6 signaling described in RFC 5213 823 apply to this document. An incorrectly configured LMA may cause 824 unwanted runtime LMA assignment attempts to non-existing LMAs or to 825 other LMAs that do not have and will not have a SA with the MAG. 826 Consequently, the MAG will experience failed binding updates or 827 unsuccessful creation of mobility sessions. An incorrectly 828 configured LMA may also cause biased load distribution within a 829 PMIPv6 domain. This document also assumes that the LMAs that 830 participate to runtime LMA assignment have adequate prior agreement 831 and trust relationship between each other. 833 If the SAs between MAGs and LMAs are manually keyed (as it may be 834 needed by the scenario described in Section 5), then the anti-replay 835 service of ESP protected PMIPv6 traffic cannot typically be provided. 836 This is, however, deployment specific to a PMIPv6 domain. 838 If a PMIPv6 domain deployment with a runtime LMA assignment requires 839 that a rfLMA has to modify a PBU/PBA in any way e.g., by changing the 840 source and destination IP address or any other field of the 841 encapsulating IP packet, then the security mechanism (such as 842 possible authentication options) used to protect the PBU/PBA MUST NOT 843 cover the outer IP packet on those parts that might get modified. 844 Alternatively, the rfLMA can do all required security processing on 845 the PBU/PBA, and the communication between the rfLMA and the r2LMA 846 would be unprotected at the PMIPv6 protocol level. In this case the 847 runtime assignment domain MUST implement adequate level of security 848 using other means, such as layer-2 VPNs. 850 9. IANA Considerations 852 Two new mobility options for the use with PMIPv6 are defined in the 853 [RFC6275] "Mobility Options" registry. The mobility options are 854 defined in Section 4: 856 Redirect-Capability Mobility Option is set to TBD1 857 Redirect Mobility Option is set to TBD2 858 Load Information Mobility Option is set to TBD4 859 Alternate IPv4 Care-of Address is set to TBD5 861 10. Acknowledgements 863 The author would like to thank Basavaraj Patil, Domagoj Premec, Ahmad 864 Muhanna, Vijay Devarapalli, Rajeev Koodli, Yungui Wang, Pete McCann 865 and Qin Wu for their discussion on this document. A special thank to 866 Qian Li for her detailed feedback on the protocol details. 868 11. References 870 11.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997. 875 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 876 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 878 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 879 in IPv6", RFC 6275, July 2011. 881 11.2. Informative References 883 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 884 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 885 RFC 2136, April 1997. 887 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 888 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 889 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 891 [RFC3484] Draves, R., "Default Address Selection for Internet 892 Protocol version 6 (IPv6)", RFC 3484, February 2003. 894 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 895 Architecture", RFC 4291, February 2006. 897 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 898 "Mobility Header Home Agent Switch Message", RFC 5142, 899 January 2008. 901 [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 902 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 903 Gateway and Local Mobility Anchor Interaction with 904 Diameter Server", RFC 5779, February 2010. 906 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 907 Mobile IPv6", RFC 5844, May 2010. 909 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 910 "Internet Key Exchange Protocol Version 2 (IKEv2)", 911 RFC 5996, September 2010. 913 [RFC6097] Korhonen, J. and V. Devarapalli, "Local Mobility Anchor 914 (LMA) Discovery for Proxy Mobile IPv6", RFC 6097, 915 February 2011. 917 Authors' Addresses 919 Jouni Korhonen (editor) 920 Nokia Siemens Networks 921 Linnoitustie 6 922 FI-02600 Espoo 923 FINLAND 925 Email: jouni.nospam@gmail.com 927 Sri Gundavelli 928 Cisco 929 170 West Tasman Drive 930 San Jose, CA 95134 931 USA 933 Email: sri.gundavelli@cisco.com 935 Hidetoshi Yokota 936 KDDI Lab 937 2-1-15 Ohara, Fujimino 938 Saitama, 356-8502 939 Japan 941 Email: yokota@kddilabs.jp 942 Xiangsong Cui 943 Huawei Technologies 944 KuiKe Bld., No.9 Xinxi Rd. 945 Shang-Di Information Industry Base 946 Hai-Dian District, Beijing, P.R. China, 100085 948 Email: Xiangsong.Cui@huawei.com