idnits 2.17.1 draft-neumann-netlmm-inter-domain-02.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 'Intended status' indicated for this document; assuming Proposed Standard 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5525 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: 'CN' is mentioned on line 174, but not defined == Missing Reference: 'MAG' is mentioned on line 310, but not defined == Missing Reference: 'SMA' is mentioned on line 310, but not defined == Missing Reference: 'MN' is mentioned on line 310, but not defined == Missing Reference: 'LMA' is mentioned on line 310, but not defined -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Neumann 3 Internet-Draft X. Fu 4 Expires: September 10, 2009 J. Lei 5 University of Goettingen 6 G. Zhang 7 Huawei Technologies Co., Ltd. 8 March 9, 2009 10 Inter-Domain Handover and Data Forwarding between Proxy Mobile IPv6 11 Domains 12 draft-neumann-netlmm-inter-domain-02 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 10, 2009. 37 Copyright Notice 39 Copyright (c) 2009 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. 49 Abstract 51 This document specifies mechanisms to setup and maintain handover and 52 data forwarding procedures that allow a mobile node to move between 53 different domains that provide (localized) network-based mobility 54 support based on Proxy Mobile IPv6 for that node. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 60 2.1. Conventions used in this document . . . . . . . . . . . . 3 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Finding the Session Mobility Anchor . . . . . . . . . . . 5 64 3.1.1. Direct Location . . . . . . . . . . . . . . . . . . . 5 65 3.1.2. Indirect Location . . . . . . . . . . . . . . . . . . 6 66 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Inter-Domain Mobility Support . . . . . . . . . . . . . . . . 7 68 4.1. Registration of a new Mobile Node . . . . . . . . . . . . 7 69 4.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 8 70 5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 8 71 5.1. Support to find the Session Mobility Anchor . . . . . . . 8 72 5.1.1. Direct SMA Location . . . . . . . . . . . . . . . . . 9 73 5.1.1.1. Processing of an Initial Binding Registration . . 9 74 5.1.1.2. Querying the Common Database . . . . . . . . . . . 9 75 5.2. Processing Proxy Binding Updates . . . . . . . . . . . . . 9 76 5.2.1. LMA to SMA PBU . . . . . . . . . . . . . . . . . . . . 9 77 5.2.2. MAG to LMA PBU . . . . . . . . . . . . . . . . . . . . 9 78 5.2.3. MAG to SMA PBU . . . . . . . . . . . . . . . . . . . . 9 79 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 10 81 6.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 11 82 6.3. Session Destination Address Option . . . . . . . . . . . . 11 83 6.4. Session Mobilty Anchor Address Option . . . . . . . . . . 12 84 7. Inter-Domain Security . . . . . . . . . . . . . . . . . . . . 13 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 9.1. Intra-domain securtiy considerations . . . . . . . . . . . 14 88 9.2. Inter-domain security considerations . . . . . . . . . . . 14 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 92 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 A mobile node in the current Internet needs to maintain a fixed 98 endpoint when it moves to allow for seamless connectivity with its 99 corresponding nodes. When the mobile nodes moves between network- 100 based mobility domains that are under different administrative 101 control, this becomes challenging. One network is responsible for 102 the communication endpoint while the other network provides the 103 actual mobility services to the mobile node. This document proposes 104 an approach to solve this problem by using inter-domain signaling to 105 setup session handover and data forwarding between the different 106 domains. 108 A network-based localized mobility management solution like Proxy 109 Mobile IPv6 (PMIPv6) [RFC5213] provides a mobile node with mobility 110 within the PMIPv6-enabled domain it is deployed in. When the mobile 111 node leaves the network, however, the mobility support breaks since 112 the mobile node moves out of the administrative reach of the local 113 mobility solution. 115 2. Conventions & Terminology 117 2.1. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 2.2. Terminology 125 Mobility Session 127 The period of time in which the mobile node needs mobility support 128 from the network. If the mobile node reaches a state where it 129 currently does not need mobility support, the mobility session can 130 safely be reset. During a mobility session the network-based 131 mobility solution described in this document offers the mobile a 132 fixed end-point for its communications, namely the session 133 mobility anchor, which stays valid even when the mobile node moves 134 between Proxy Mobile IP domains. 136 Session Mobility Anchor 138 A fixed end-point which relays all the communication for the 139 mobile node. This is the local mobility anchor of the first Proxy 140 Mobile IP domain that a mobile node is connected to during a 141 mobility session. 143 3. Overview 145 In order to provide continuous mobility support for a mobile nodes 146 that is moving between different mobility domains, a steady anchor 147 point has to be provided for corresponding nodes. In Mobile IP, for 148 example, this is the home agent while in Proxy Mobile IP this is the 149 local mobility anchor (LMA). This anchor point allows the mobile 150 node to change its point of attachment to a network without its 151 corresponding nodes noticing that. All the mobile node's traffic is 152 routed through the local mobility anchor which then forwards the 153 traffic to the mobile node. When a mobile node leaves a Proxy Mobile 154 IP domain, however, it moves beyond the control of the local mobility 155 anchor and therefore its mobility breaks. 157 When a mobile node initially attaches to a Proxy Mobile IP domain, 158 the local mobility anchor becomes the session mobility anchor (SMA) 159 for the mobile node. For the duration of the mobility session this 160 session mobility anchor will handle all incoming and outgoing 161 connections for the mobile node. As long as the mobile node stays 162 within the local Proxy Mobile IP domain, this only includes regular 163 Proxy Mobile IPv6 operations as described in [RFC5213]. When the 164 mobile node leaves the local Proxy Mobile IP domain, however, the new 165 Proxy Mobile IP domain's local mobility anchor will initialize a 166 tunnel to the session mobility anchor to allow the session mobility 167 anchor to continue serving as an anchor point for the mobile node as 168 shown in Figure 1. Within the new Proxy Mobile IP domain all regular 169 Proxy Mobile IP operations still apply with the exception that all 170 traffic for the mobile node is tunneled from the new local mobility 171 anchor to the session mobility anchor which in turn communicates with 172 the correspondent node. 174 [CN] 175 || 176 || 177 [LMA_1 >===========================================> [LMA_3] 178 = SMA]] >=================> [LMA_2] Tunnel | 179 | Tunnel | | 180 | | | 181 | | | 182 | | | 183 [MAG] [MAG] [MAG] 184 | | | 185 MN ------------------------> MN ----------------------> MN 186 Movement Movement 188 Figure 1: Movement 190 For all intends and purposes from the point of view of the session 191 mobility anchor, the current local mobility anchor of a mobile node 192 can be seen as a mobile access gateway which performs the 193 corresponding operations. 195 3.1. Finding the Session Mobility Anchor 197 When a mobile node attaches to a Proxy Mobile IP domain, the local 198 mobility anchor of this domain has to locate the session mobility 199 anchor for this mobile node and initiate a tunnel between itself and 200 the session mobility anchor. In case the Proxy Mobile IP domain is 201 the first domain the mobile node attaches to within its mobility 202 session, the current local mobility anchor becomes the session 203 mobility anchor and continues with its regular Proxy Mobile IP 204 operations. If the mobile node already has been attached to a 205 different Proxy Mobile IP domain, it's session mobility anchor 206 resides within this previous domain and the local mobility anchor 207 needs to establish a binding with the session mobility anchor in 208 order to send and receive the data for the mobile node through its 209 session mobility anchor. Depending on the scenario, the local 210 mobility anchor can directly or indirectly locate the session 211 mobility anchor for a mobile node. 213 3.1.1. Direct Location 215 Direct location of a session mobility anchor for a mobile node 216 requires some kind of look-up between associated Proxy Mobile IP 217 domains. For example, this can be achieved by maintaining a common 218 database where session mobility anchors deposit the information for 219 which mobile node they are responsible for. Such a database can be 220 established by service level agreements between the operators of 221 Proxy Mobile IP domains. For a local mobility anchor to locate the 222 session mobility anchor for a mobile node it will send a look-up 223 request to the database using the mobile node's identity (e.g. its 224 Network Access Identifier (NAI) [RFC4282]) as the look-up key. If 225 the database does not have an entry for the mobile node, the local 226 mobility anchor becomes the session mobility anchor for the mobility 227 session of the mobile node. 229 This common database can be implemented as a virtual mobility anchor 230 (VMA) as shown in Figure 2. The virtual mobility anchor is shared 231 across all mobility domains and processes specific proxy binding 232 updates from their local mobility anchors. It is called virtual 233 mobility anchor since it does not relay any traffic for mobile nodes. 234 When a mobile node attaches to a PMIP domain the corresponding local 235 mobility anchor sends a Proxy Binding Update to the virtual mobility 236 anchor which includes the mobile node's identity (e.g. its Network 237 Access Identifier (NAI) [RFC4282]) or it's link layer address) and 238 the S flag set to 1 (see Section 6.1). It also includes the Session 239 Destination option set to the global address of the local mobility 240 anchor. If the virtual mobility anchor already has a binding for the 241 mobile node, it forwards the Proxy Binding Update to the particular 242 session mobility anchor. The session mobility anchor updates it's 243 own bindings and responds with a Proxy Binding Acknowledgment to the 244 virtual mobility anchor which also has the S flag set and includes a 245 Session Mobility Anchor Address option which is set to the global 246 address of the session mobility anchor (see Section 6.2). If the 247 virtual mobility anchor does not have a binding for the particular 248 mobile node, it creates one and replies with Proxy Binding 249 Acknowledgment that indicates that no session mobility anchor was 250 found by including a Session Mobility Anchor Address option which is 251 set to an empty address. The local mobility anchor then regards 252 itself as the session mobility anchor. 254 /---[VMA]---\ 255 /---/ / \ \---\ 256 / / \ \ 257 / /----/ \----\ \ 258 3. / / 2. 1. \ \ 4. 259 PBA / / PBU PBU \ \ PBA 260 / / \ \ 261 [SMA] >=================> [LMA_2] 262 | 5. Tunnel | 263 | | 264 | | 265 | | 266 [MAG] [MAG] 267 | | 268 MN ------------------------> MN 269 Movement 271 Figure 2: Direct location of the session mobility anchor using a 272 virtual mobility anchor 274 3.1.2. Indirect Location 276 If no common database exists between Proxy Mobile IP domains, the 277 local mobility anchor can use an indirect scheme to locate the 278 session mobility anchor of a mobile node. For this purpose, the 279 local mobility anchor infers the session mobility anchor assigned IP 280 address of the mobile node and uses this address to send its session 281 transfer request to. Since the session mobility anchor is 282 responsible for this IP address, the local mobility anchor will 283 indirectly reach the session mobility anchor. If there is no reply 284 to the request, the local mobility anchor must assume that no 285 previous session mobility anchor exists and itself become the session 286 mobility anchor for the mobility session of the mobile node. The 287 session mobility anchor assigned IP address of a mobile node is the 288 IP address the mobile node got assigned when it initially attached to 289 a Proxy Mobile IP domain. The local mobility anchor can try to infer 290 this IP address, for example, by analyzing the mobile node's Router 291 Solicitation messages [RFC4861] or DHCP requests [RFC3315]. 293 3.2. Assumptions 295 This document assumes that there are some operational agreements 296 between the operators of the different Proxy Mobile IP domains. Part 297 of this agreement are, for example, the conditions under which users 298 are allowed to move between domains and the location method that is 299 used to find the session mobility anchor. 301 4. Inter-Domain Mobility Support 303 4.1. Registration of a new Mobile Node 305 When a new mobile node attaches to a Proxy Mobile IP domain, the 306 corresponding local mobility anchor registers itself as the new local 307 mobility anchor for the mobile node with the session mobility anchor 308 of the mobile node. 310 [MN] [MAG] [LMA] [SMA] 311 | | | | 312 Attaches | | | 313 | | | | 314 |--Rtr Sol ->| | | 315 | | | | 316 | |--PBU----->| | 317 | | | | 318 | | |------PBU--->| 319 | | | | 320 | | |<-----PBA----| 321 | | |===Tunnel====| 322 | | | | 323 | |<---PBA----| | 324 | |==Tunnel===| | 325 | | | | 326 |<--Rtr Adv--| | | 327 | | | | 328 Figure 3: Signal Flow 330 Figure 3 shows the signaling flow when a mobile node attaches to a 331 Proxy Mobile IP domain. As in the normal Proxy Mobile IP case, the 332 mobile node sends a Router Solicitation message that is received by 333 the local mobile access gateway. The mobile access gateway then 334 sends its Proxy Binding Update (PBU) to the local mobility anchor. 335 To register itself with the session mobility anchor as the new local 336 mobility anchor for the mobile node, the local mobility anchor 337 forwards this Proxy Binding Update to the session mobility anchor. 338 The session mobility anchor then determines the corresponding 339 policies for the mobile node as it would for a local mobile node and 340 constructs the Proxy Binding Acknowledgment (PBA). The Proxy Binding 341 Acknowledgment is then sent to the local mobility anchor as if it 342 were a local mobile access gateway and a bi-directional tunnel is 343 established between the session mobility anchor and the local 344 mobility anchor. The local mobility anchor forwards the received 345 Proxy Binding Acknowledgment to its mobile access gateway which in 346 turn uses the Proxy Binding Acknowledgment to configure the mobile 347 node. Also, the local mobility anchor establishes the bi-direct 348 tunnel to this mobile access gateway. All traffic for the mobile 349 node is then routed from the session mobility anchor through the 350 local mobility anchor and the mobile access gateway. All future 351 movements of the mobile node within the new Proxy Mobile IPv6 domain 352 are covered by local mobility operations as described in [RFC5213]. 354 4.2. Local Routing 356 Traffic might occur between nodes that are currently allocated in the 357 same mobility domain but are associated with session mobility anchors 358 outside this domain. The local mobility anchor of the domain MAY 359 optimize the delivery of this traffic by locally routing the packets 360 instead of sending them over the corresponding session mobility 361 anchor(s). The flag EnableMAGLocalRouting MAY be used for 362 controlling this behavior. For further local routing considerations, 363 see Section 6.10.3. of the Proxy Mobile IPv6 (PMIPv6) document 364 [RFC5213]. 366 5. Local Mobility Anchor Considerations 368 5.1. Support to find the Session Mobility Anchor 370 The LMA is responsible to either act as a SMA for nodes that attach 371 to its domain originally or to locate the corresponding SMA for nodes 372 that move to its domain from another domain. In the first case, the 373 LMA needs to support operations that allow it to be found and queried 374 by other LMAs for mobility session related data. In the later case, 375 the LMA needs to perform these locating and querying operations 376 itself. This document describes two operating schemes for this 377 purpose: the direct location of the SMA and the indirect location of 378 the SMA. 380 5.1.1. Direct SMA Location 382 As explained in Section 3.1.1 the direct location of the SMA is 383 performed using a common database between the participating PMIP 384 domains. 386 5.1.1.1. Processing of an Initial Binding Registration 388 Upon the reception of an Initial Binding Registration (cf. Section 389 5.3.2. [RFC5213]) the LMA MUST query the common database for a SMA 390 for the corresponding mobile node. If a SMA is returned the LMA will 391 act as a visited LMA and send a corresponding PBU to the SMA. If not 392 SMA is returned, the LMA will act as a SMA for the mobile node and 393 update the database accordingly. Afterwards the LMA processes the 394 Initial Binding Registration as specified in [RFC5213]. 396 5.1.1.2. Querying the Common Database 398 ... 400 5.2. Processing Proxy Binding Updates 402 5.2.1. LMA to SMA PBU 404 If a SMA receives a PBU from a LMA it MUST assume that the mobile 405 node moved to the PMIP domain the LMA is responsible for. The SMA 406 MUST process the PBU as it would process a PBU from any of the MAGs 407 in its own domain. 409 5.2.2. MAG to LMA PBU 411 If a LMA that is not the SMA for a mobile node receives a PBU which 412 is not part of an Initial Binding Registration it MUST process the 413 PBU as it would process any other PBU. If the PBU is successful it 414 MUST also send a Binding Lifetime Extension PBU to the SMA. 416 5.2.3. MAG to SMA PBU 418 If a SMA receives a PBU from a MAG within its own domain it MUST 419 process it like it would process the PBU as a LMA. 421 6. Message Formats 423 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 424 protocol messages. 426 6.1. Proxy Binding Update Message 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Sequence # | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 |A|H|L|K|M|R|P|S|Reserved | Lifetime | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | | 435 . . 436 . Mobility options . 437 . . 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 A new flag (S) is included in the Binding Update message. The rest 442 of the Binding Update message format remains the same as defined in 443 [RFC5213]. 445 Session Forwarding Flag (S) 447 A new flag (S) is included in the Binding Update message to 448 indicate that the Binding Update message is a request from a local 449 mobility anchor to a session mobility anchor to forward all data 450 for a particular mobile node to the local mobility anchor. The 451 flag MUST be set to 1 in case a local mobility anchor requests a 452 session forwarding and to 0 otherwise. 454 Mobility Options 456 In addition to the mobility options specified in [RFC5213] there 457 can be at most one instance of the Session Destination Address 458 option included in a Proxy Binding Update Message. 460 6.2. Proxy Binding Acknowledgement Message 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Status |K|R|P|S|Reserv.| 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Sequence # | Lifetime | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 . . 470 . Mobility options . 471 . . 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 A new flag (S) is included in the Binding Acknowledgement message. 476 The rest of the Binding Acknowledgement message format remains the 477 same as defined in [RFC5213]. 479 Session Forwarding Flag (S) 481 A new flag (S) is included in the Binding Acknowledgement message 482 to indicate that the local mobility anchor that processed the 483 corresponding Proxy Binding Update message supports session 484 forwarding. The flag is set to a value of 1 only if the 485 corresponding Proxy Binding Update had the Session Forwarding Flag 486 (S) set to value of 1. 488 Mobility Options 490 In addition to the mobility options specified in [RFC5213] there 491 can be at most one instance of the Session Mobility Anchor Address 492 option included in a Proxy Binding Acknowledgement. 494 6.3. Session Destination Address Option 496 The Session Destination option indicates where a local mobility 497 requests the data to be send in a session forwarding request. 499 The Session Destination Address option is encoded in type-length- 500 value (TLV) format as follows: 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Option Type | Option Length | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | | 508 + + 509 | | 510 + Session Destination Address + 511 | | 512 + + 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Option Type 518 TBD 520 Option Length 522 8-bit unsigned integer. Length of the option, in octets, 523 excluding the Option Type and Option Length fields. This field 524 MUST be set to 16. 526 Session Destination Address 528 The destination address for the session data of the mobile node. 529 This is usually the address of the local mobility anchor which is 530 responsible for the mobile node. This address MUST be a unicast 531 routable address. 533 6.4. Session Mobilty Anchor Address Option 535 The Session Mobility Anchor Address option indicates the address of 536 the session mobility anchor which is ultimately responsible for a 537 Proxy Binding Update request. 539 The Session Mobility Anchor Address option is encoded in type-length- 540 value (TLV) format as follows: 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Option Type | Option Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 + + 549 | | 550 + Session Mobilty Anchor Address + 551 | | 552 + + 553 | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Option Type 558 TBD 560 Option Length 562 8-bit unsigned integer. Length of the option, in octets, 563 excluding the Option Type and Option Length fields. This field 564 MUST be set to 16. 566 Session Mobility Anchor Address 568 The address of the session mobility anchor. This address MUST be 569 a unicast routable address. 571 7. Inter-Domain Security 573 This document introduces signaling and data forwarding between 574 different Proxy Mobile IP domains which needs to be protected. Proxy 575 Mobile IP itself recommends using IPsec with established security 576 associations to protect the signaling messages, Proxy Binding Update 577 and Proxy Binding Acknowledgment message exchanges between the mobile 578 access gateway and the local mobility anchor. This document extends 579 this recommendation for all message exchanges between the session 580 mobility anchor and the local mobility anchor including forwarded 581 data for the mobile node. How the IPsec associations are established 582 is beyond this document. 584 8. IANA Considerations 585 9. Security Considerations 587 This section deals with the considerations related to intra-domain 588 security within one Proxy Mobile IP domain and inter-domain security 589 between different Proxy Mobile IP domains that are involved in 590 managing a mobile nodes mobility. 592 9.1. Intra-domain securtiy considerations 594 This document does not change any intra-domain mobility procedures 595 and therefore does not introduce additional intra-domain security 596 risks. The security considerations in [RFC5213] cover security risks 597 inside a Proxy Mobile IPv6 domain. 599 9.2. Inter-domain security considerations 601 The signaling and data forwarding between different Proxy Mobile IP 602 domains where the session mobility anchor resides in one domain and 603 the current local mobility anchor for a mobile node resides in the 604 other domain is recommended to be protected by using IPsec with 605 established security associations. This means that the local 606 mobility anchor establishes and maintains an IPsec tunnel to the 607 session mobility anchor which is used for communications. How these 608 security associations are established is beyond this document. It is 609 recommended, however, to establish some kind of service agreements 610 between service providers to specify security constraints and to 611 arrange the valid endpoints (i.e. the local mobility anchor and 612 session mobility anchor addresses). 614 In opposite to plain Proxy Mobile IPv6, the signaling between the 615 session mobility anchor and the mobile node traverses not only the 616 Internet but also the local network of the current Proxy Mobile IP 617 domain. The signaling between the session mobility anchor and the 618 mobile node is, therefore, at least exposed to the current local 619 mobility anchor, and the corresponding mobile access gateways in the 620 current Proxy Mobile IP domain. Especially for applicable 621 authentication procedures between the session mobility anchor and the 622 mobile node, the session mobility anchor is recommended to only use 623 procedures that cannot be exploited by overhearing parties. 625 10. References 627 10.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 633 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 635 10.2. Informative References 637 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 638 and M. Carney, "Dynamic Host Configuration Protocol for 639 IPv6 (DHCPv6)", RFC 3315, July 2003. 641 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 642 Network Access Identifier", RFC 4282, December 2005. 644 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 645 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 646 September 2007. 648 Appendix A. Open Issues 650 o better definition of mobility session (when to start a new 651 session) 653 o extend inter domain security issues 655 o De-Registration of a MN 657 Authors' Addresses 659 Niklas Neumann 660 University of Goettingen 661 Computer Networks Group 662 Goldschmidtstrasse 7 663 Goettingen 37077 664 Germany 666 Email: neumann@cs.uni-goettingen.de 668 Xiaoming Fu 669 University of Goettingen 670 Computer Networks Group 671 Goldschmidtstrasse 7 672 Goettingen 37077 673 Germany 675 Email: fu@cs.uni-goettingen.de 676 Jun Lei 677 University of Goettingen 678 Computer Networks Group 679 Goldschmidtstrasse 7 680 Goettingen 37077 681 Germany 683 Email: lei@cs.uni-goettingen.de 685 Gong Zhang 686 Huawei Technologies Co., Ltd. 687 Corporate Research Department 688 B-1 Building, Longgang 689 Shenzhen 518129 690 P.R.China 692 Email: Nicholas@huawei.com