idnits 2.17.00 (12 Aug 2021) /tmp/idnits20210/draft-ma-netext-pmip-handover-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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5213]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 4, 2012) is 3790 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC4832' is mentioned on line 1019, but not defined == Unused Reference: 'RFC2473' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 1135, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: 'RFC4282' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC4283' is defined on line 1149, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1153, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1156, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1159, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RFC1981' is defined on line 1171, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 1174, but no explicit reference was found in the text == Unused Reference: 'RFC3588' is defined on line 1178, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 1185, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'RFC4330' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: 'RFC4372' is defined on line 1198, but no explicit reference was found in the text == Unused Reference: 'RFC4821' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'RFC4830' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: 'RFC4831' is defined on line 1207, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) Summary: 4 errors (**), 0 flaws (~~), 22 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Zhengming. Ma 3 Internet-Draft Ke. Wang 4 Intended status: Standards Track Fei. Zhang 5 Expires: July 7, 2012 SUN YAT-SEN UNIVERSITY 6 January 4, 2012 8 Network-based Inter-domain handover Support for Proxy Mobile IPv6 9 draft-ma-netext-pmip-handover-02.txt 11 Abstract 13 [RFC5213] prompts the Inner-domain handover of the MN in Proxy Mobile 14 IPv6(PMIPv6).This document describes network-based Inter-domain 15 handover functionality and corresponding mobility options for 16 PMIPv6.This document strictly abides by the three principle describes 17 in PMIPv6: 19 (a)The movement of MN is transparent to CN. 21 (b)MN doesn't participate in any mobility-related signaling.LMA and 22 MAG are responsible for managing IP mobility on behalf of the host. 24 (c)This document is compatible with RFC5213. 26 The points of this document are as follows: 28 (1) Concepts: The MN's Home Agent(HA) ,Home Address (HoA) and Care-of 29 address(CoA) is not only for user but also for the specific 30 session.MN initiating a session uses the address assigned by the LMA 31 which the MN is registered at the moment as the HoA for the 32 session.The user initiating a session uses the address assigned by 33 the LMA which the MN moves to as the CoA for the session. 35 (2) Binding Cache:Every local mobility anchor must maintain two 36 Binding Cache entries for each currently registered mobile node. One 37 is Inner-domain BCE,the other is Inter-domain BCE. Inner-domain BCE 38 maintains the binding between MN's Proxy-CoA and MN's HoA. Inter- 39 domain BCE maintains the bingding between CN's HoA and CN's CoA. 41 (3)Communication:For the user initiating a session or accepting a 42 session,no matter how it moves,the HoA for the session is 43 unchanged,the source address of the data packets is the user's own 44 HoA,and the destination address of the the data packets is the HoA of 45 CN.The local mobility anchor will check all the packets received from 46 the mobile access gateway.If both the source address of the data 47 packets is the MN's HoA recorded in Inner-domain BCE,and the CN's HoA 48 and CoA recorded in Inter-domain BCE are the same,the LMA will route 49 the packets directly to CN as described in RFC5213.Otherwise, 50 according to looking up the Inter-domain BCE,LMA gets the CoA of CN. 51 Then ,LMA encapsulates the packets to route to CN.On receiving a 52 packet from a correspondent node with the destination address 53 matching a mobile node's home network prefix(es), the CN's LMA MUST 54 first check the source address and the destination address of the 55 data packets,if the source address of the data packets is MN's HoA 56 recorded in Inter-domain BCE and the destination address is CN's HoA 57 recorded in Inner-domain BCE ,the CN'LMA will forward the packets to 58 the right MAG directly as described in RFC5213.Otherwise, CN'LMA will 59 remove the outer header before forwarding the packet. Then,LMA looks 60 up the Inner-domain BCE to forward the packets to the right MAG. 62 (4)Updates:When MN moves to visited LMA(MN-vLMA),MN-vLMA will do 63 three things. 65 Firstly MN-vLMA will assign a MN-CoA for MN and build up the Inner- 66 domain BCE for MN. Secondly,MN-vLMA will sends message to MN-hLMA to 67 get the HoA of CN .Then,MN-vLMA builds up the binding between CN-HoA 68 and CN-HoA in the Inter-domain BCE.Thirdly, MN-vLMA sends message to 69 CN-LMA wiht the MN-CoA and MN-HoA included in the message to help CN- 70 LMA updating the Inter-domain BCE for MN. 72 Compared with "draft-ma-netext-pmip-handover-00.txt", this document 73 is compatible with RFC5213 and the LMA described in this document 74 should decide if it is necessary to encapsulate the packets.In other 75 word,if MN and CN are both in their home domain,they will communicate 76 just as the way described in RFC5213 and otherwise they will 77 communicate in the way described in this document. 79 Status of this Memo 81 This Internet-Draft is submitted in full conformance with the 82 provisions of BCP 78 and BCP 79. 84 Internet-Drafts are working documents of the Internet Engineering 85 Task Force (IETF). Note that other groups may also distribute 86 working documents as Internet-Drafts. The list of current Internet- 87 Drafts is at http://datatracker.ietf.org/drafts/current/. 89 Internet-Drafts are draft documents valid for a maximum of six months 90 and may be updated, replaced, or obsoleted by other documents at any 91 time. It is inappropriate to use Internet-Drafts as reference 92 material or to cite them other than as "work in progress." 94 This Internet-Draft will expire on July 7, 2012. 96 Copyright Notice 97 Copyright (c) 2012 IETF Trust and the persons identified as the 98 document authors. All rights reserved. 100 This document is subject to BCP 78 and the IETF Trust's Legal 101 Provisions Relating to IETF Documents 102 (http://trustee.ietf.org/license-info) in effect on the date of 103 publication of this document. Please review these documents 104 carefully, as they describe your rights and restrictions with respect 105 to this document. Code Components extracted from this document must 106 include Simplified BSD License text as described in Section 4.e of 107 the Trust Legal Provisions and are provided without warranty as 108 described in the Simplified BSD License. 110 Table of Contents 112 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 113 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 4 114 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 115 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 116 3. The assumptions on the PMIPv6 domain . . . . . . . . . . . . . 5 117 4. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 6 118 4.1. Home address configuration . . . . . . . . . . . . . . . . 6 119 4.2. Binding Cache Entry Data in LMA . . . . . . . . . . . . . 7 120 4.3. Forwarding Considerations . . . . . . . . . . . . . . . . 7 121 4.3.1. Forwarding Packets Sent by the Mobile Node . . . . . . 7 122 4.3.2. Forwarding Packets to the Mobile Node: . . . . . . . . 7 123 5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 8 124 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 125 6.1. Initial Binding Registration and Forwarding 126 Considerations . . . . . . . . . . . . . . . . . . . . . . 9 127 6.2. MN Performs Inter-domain handover . . . . . . . . . . . . 11 128 6.2.1. Inter-domain handover operation . . . . . . . . . . . 11 129 6.2.2. Forwarding Consideratons . . . . . . . . . . . . . . . 13 130 6.3. CN Performs Inter-domain handover . . . . . . . . . . . . 15 131 6.3.1. Inter-domain handover operation . . . . . . . . . . . 15 132 6.3.2. Forwarding Consideratons . . . . . . . . . . . . . . . 17 133 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 134 7.1. rPBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 135 7.2. rPBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 136 7.3. pPBU . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 137 7.4. pPBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 138 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 139 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 140 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 141 10.1. Normative References . . . . . . . . . . . . . . . . . . . 25 142 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 145 1. Introduction 147 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is network based mobility 148 management protocol which allows IP mobility session continuity for a 149 Mobile Node (MN) without its involvement in mobility management 150 signaling. In RFC5213 the inter-domain handover is not involved.This 151 document describes the network-based Inter-domain handover options, 152 and the corresponding functionality for Inter-domain handover for 153 PMIPv6. The Inter-domain handover takes place during MN moves from 154 home LMA(hLMA) to visited LMA(vLMA). 156 The network-based Inter-domain handover functionality described in 157 this specification does not depend on information provisioned to 158 external entities, such as the Domain Name System (DNS) or the 159 Authentication,Authorization and Accounting (AAA) infrastructure. 160 The trust relationship and coordination management between LMAs 161 within a PMIPv6 domain is deployment specific and will be described 162 in this specification. 164 2. Requirements and Terminology 166 2.1. Requirements 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 169 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 170 this document are to be interpreted as described in [RFC2119]. 172 2.2. Terminology 174 In addition to the terminology defined in [RFC5213], the following 175 terminology is also used: 177 hLMA 179 Home Local Mobility Anchor is the first LMA the MN registered and is 180 the home agent for the mobile node in a Proxy Mobile IPv6 domain. It 181 is the topological anchor point for the mobile node's home network 182 prefix(es) and is the entity that manages the mobile node's binding 183 state. The local mobility anchor has the functional capabilities of 184 a home agent as defined in Mobile IPv6 base specification [RFC3775] 185 with the additional capabilities required for supporting Proxy Mobile 186 IPv6 protocol as defined in this specification. 188 vLMA 190 The vLMA is the LMA the MN visited. 192 rPBU 194 A request message sent by a mobile access gateway to a mobile node's 195 local mobility anchor for establishing a binding between the mobile 196 node's home network prefix(es) assigned to a given interface of a 197 mobile node and its current care-of address (Proxy-CoA). 199 rPBA 201 A reply message sent by a local mobility anchor in response to a 202 Proxy Binding Update message that it received from a mobile access 203 gateway. 205 pPBU 207 A request message sent from a LMA to another LMA. There are two 208 kinds of message formats:a message sent from vLMA to hLMA and a 209 message sent from vLMA to CN's LMA. 211 pPBA 213 A reply message sent from a LMA to another LMA. There are two kinds 214 of message formats:a message sent from hLMA to vLMA and a message 215 sent from CN's LMA to vLMA. 217 Home AAA (hAAA): 219 An Authentication, Authorization, and Accounting (AAA) server located 220 in MN's home network. In scope of this document the hAAA corresponds 221 to a RADIUS server that includes the role of the PMIPv6 Policy Store. 223 Visited AAA (vAAA): 225 An Authentication, Authorization, and Accounting (AAA) server located 226 in MN's visited network. In this document the vAAA is the AAA server 227 that acts as a RADIUS Proxy when the MN moves or attaches through the 228 Visited network. The VAAA receives an authentication (or accounting) 229 request from an AAA client such as a NAS, forwards the request to the 230 hAAA server, receives the reply from the hAAA, and sends that reply 231 back to the AAA client potentially adding changes to reflect local 232 administrative policy. 234 3. The assumptions on the PMIPv6 domain 236 They are discussed here as they have an impact on PMIPv6 deployment. 238 Home AAA server records the user's static and dynamic information,and 239 the dynamic information includes the information of LMA which the MN 240 is registered right now. 242 The MN's Home Address (HoA) and Care-of address(CoA) is not only for 243 user but also for the specific session. 245 MN initiating a session uses the address assigned by the LMA which 246 the MN is registered as the HoA for the session.The user initiating a 247 session uses the address assigned by the LMA which the MN moves to as 248 the CoA for the session. 250 CN accepting a session uses the address assigned by the LMA which the 251 CN is registered as the HoA for the session.CN accepting a session 252 uses the address assigned by the LMA which the CN moves to as the CoA 253 for the session. 255 For the user initiating a session or accepting a session,no matter 256 how it moves,the HoA for the session is unchanged,while the CoA for 257 the session is changing.Then, the source address of the data packets 258 sent by a user initiating a session or accepting a session is the 259 user's own HoA,and the destination address of the the data packets is 260 the HoA of the other end of the session. 262 The network-based Inter-domain handover Management not only ensures 263 the continuity in the session but also ensures that the MN will not 264 detect any change with respect to CN. 266 This specification diverses the PBU/PBA message into two kinds of 267 message formate: pPBU/pPBA message between LMAs ,rPBU/rPBA message 268 between LMA and MAG. 270 4. Local Mobility Anchor Operation 272 The local mobility anchor MUST support the home agent function as 273 defined in [RFC3775] and the extensions defined in this 274 specification. A home agent with these modifications and enhanced 275 capabilities for supporting the Proxy Mobile IPv6 protocol is 276 referred to as a local mobility anchor.This section describes the 277 operational details of the local mobility anchor. 279 4.1. Home address configuration 281 LMA not only assignes the network prefix of the home address for the 282 new users , but also configures the home address for the new users.So 283 that LMA can performs mobility management on behalf of a mobile node. 285 4.2. Binding Cache Entry Data in LMA 287 Every local mobility anchor MUST maintain two Binding Cache entries 288 for each currently registered mobile node. One is Inner-domain 289 BCE,the other is Inter-domain BCE. Inner-domain BCE maintains the 290 binding between MN's Proxy-CoA and MN's HoA. Inter-domain BCE 291 maintains the bingding between CN's HoA and CN's CoA. 293 4.3. Forwarding Considerations 295 LMA should intercepts the packets sent to the Mobile Node's Home 296 Network:When the local mobility anchor is serving a mobile node, it 297 MUST be able to receive packets that are sent to the mobile node's 298 home network. In order for it to receive those packets, it MUST 299 advertise a connected route in to the Routing Infrastructure for the 300 mobile node's home network prefix(es) or for an aggregated prefix 301 with a larger scope. This essentially enables IPv6 routers in that 302 network to detect the local mobility anchor as the last-hop router 303 for the mobile node's home network prefix(es). 305 4.3.1. Forwarding Packets Sent by the Mobile Node 307 The local mobility anchor will check all the packets received from 308 the mobile access gateway.If both the source address of the data 309 packets is the MN's HoA recorded in Inner-domain BCE,and the CN's HoA 310 and CoA recorded in Inter-domain BCE are the same,the LMA will route 311 the packets directly to CN as described in RFC5213.Otherwise, 312 according to looking up the Inter-domain BCE,LMA gets the CoA of CN. 313 Then ,LMA encapsulates the packets to route to CN. The format of the 314 tunneled packet is shown below: 316 IPv6 header (src= LMAA, dst= CN's CoA) /* Tunnel Header */ 318 IPv6 header (src= MN's HoA, dst= CN's HoA ) /* Packet Header */ 320 Upper layer protocols /* Packet Content*/ 322 4.3.2. Forwarding Packets to the Mobile Node: 324 On receiving a packet from a correspondent node with the destination 325 address matching a mobile node's home network prefix(es), the LMA 326 MUST first check the source address and the destination address of 327 the data packets,if the source address of the data packets is CN's 328 HoA recorded in Inter-domain BCE and the destination address is MN's 329 HoA recorded in Inner-domain BCE ,the LMA will forward the packets to 330 the right MAG directly as described in RFC5213.Otherwise, LMA will 331 remove the outer header before forwarding the packet. Then,LMA looks 332 up the Inner-domain BCE to forward the packets to the right MAG. The 333 format of the tunneled packet is shown below: 335 IPv6 header (src= LMAA, dst= MN's Proxy CoA) /* Tunnel Header */ 337 IPv6 header (src= CN's HoA, dst= MN's HoA ) /* Packet Header */ 339 Upper layer protocols /* Packet Content*/ 341 5. Mobile Access Gateway Operation 343 RFC5213 introduces a new functional entity, the mobile access gateway 344 (MAG).The mobile access gateway is the entity that is responsible for 345 detecting the mobile node's movements to and from the access link and 346 sending the Proxy Binding Update messages to the local mobility 347 anchor. In essence, the mobile access gateway performs mobility 348 management on behalf of a mobile node. 350 Every mobile access gateway MUST maintain a Binding Update List.Each 351 entry in the Binding Update List represents a mobile node's mobility 352 binding with its local mobility anchor. The Binding Update List is a 353 conceptual data structure. 355 For supporting this specification, the conceptual Binding Update List 356 entry data structure needs be extended as follows: 358 (a)After detecting a new mobile node on its access link, the mobile 359 access gateway MUST identify the mobile node and acquire its MN- 360 Identifier. If it determines that the network-based mobility 361 management service needs to be offered to the mobile node, it MUST 362 send a Proxy Binding Update message to the local mobility anchor. 364 (b)If the MAG detectes the MN's registration is initial binding 365 registration , the MAG will maintain a binding between MN's HoA and 366 hLMA when it recieves the rPBA message. 368 (c)If the MAG detectes the MN is performing a inter-domain handover , 369 the MAG will maintain a binding between MN's HoA ,vLMA and CoA when 370 it recieves the rPBA message from vLMA. The CoA which is included in 371 rPBA message is the address vLMA assigns for MN. 373 6. Protocol Operation 375 In order to improve the performance during inter-handover (when 376 operations such as attachment to a new LMA and signaling between LMAs 377 are involved), the PFMIPv6 protocol in this document specifies new 378 message forms between the MN's hLMA and MN's vLMA and new message 379 forms between the MN's vLMA and CN's LMA. In this specification take 380 the communication between MN and CN as a example. Both MN and CN are 381 in PMIPv6 domain. 383 6.1. Initial Binding Registration and Forwarding Considerations 385 Both MN and CN are in PMIPv6 domain.The related signaling of Initial 386 Binding Registration is described in RFC5213. Both MN and CN has 387 registered in its hLMA ,and both gets its home address (MN-HoA and 388 CN-HoA).The reference network is illustrated in Figure 1. 390 +---------+ +----------+ 391 | MN-hLMA |---------| CN-hLMA | 392 +---------+ +----------+ 393 | | 394 | | 395 +---------+ +----------+ 396 | MN-MAG | | CN-MAG | 397 +---------+ +----------+ 398 | | 399 | | 400 +---------+ +----------+ 401 | MN | | CN | 402 +---------+ +----------+ 404 Figure 1:Reference network for Initial Binding Registration and 405 Forwarding Considerations 407 Forwarding Considerations: 409 (a) Packets from MN to CN: 411 (1).The source address is MN-HoA, and the destination address is CN- 412 HoA. 414 (2).The packets are forwarded from MN to MN-MAG through Link-layer. 416 (3).The packets are forwarded form MN-MAG to MN-hLMA through tunnel, 417 the source address of the tunnel is MN-MAG's IP address (MN-Proxy- 418 CoA), and the destination address of the tunnel is MN-hLMA's address 419 (MN-hLMAA). 421 (4).MN-hLMA decapsulates the packets and check both the source 422 address and the destination address of the data packets.If both the 423 source address of the data packets is the MN's HoA recorded in Inner- 424 domain BCE,and the CN's HoA and CoA recorded in Inter-domain BCE are 425 the same,the LMA will route the packets directly to CN as described 426 in RFC5213. 428 (5)The packets are intercepted by CN-hLMA.CN-hLMA MUST first check 429 the source address and the destination address of the data packets,if 430 the source address of the data packets is MN's HoA recorded in Inter- 431 domain BCE and the destination address is CN's HoA recorded in Inner- 432 domain BCE ,the CN-hLMA forwards the packets to the right MAG 433 directly as described in RFC5213.CN-hLMA forwards them to CN-MAG 434 through tunnel, the source address of the tunnel is CN-hLMA's address 435 (CN-hLMAA), and the destination address of the tunnel is CN-MAG's 436 address (CN-Proxy-CoA). 438 (6)CN-MAG decapsulates the packets and forwards them to CN through 439 Link-layer. 441 (b) Packets from CN to MN: 443 (1).The source address is CN-HoA , and the destination address is MN- 444 HoA . 446 (2).The packets are forwarded from CN to CN-MAG through Link-layer. 448 (3).The packets are forwarded form CN-MAG to CN-hLMA through tunnel, 449 the source address of the tunnel is CN-Proxy-CoA and the destination 450 address of the tunnel is CN-hLMAA. 452 (4).CN-hLMA decapsulates the packets and check both the source 453 address and the destination address of the data packets.If both the 454 source address of the data packets is the CN's HoA recorded in Inner- 455 domain BCE,and the MN's HoA and CoA recorded in Inter-domain BCE are 456 the same,the LMA will route the packets directly to CN as described 457 in RFC5213. 459 (5). The packets are intercepted by MN-hLMA.The packets are 460 intercepted by MN-hLMA.MN-hLMA MUST first check the source address 461 and the destination address of the data packets,if the source address 462 of the data packets is CN's HoA recorded in Inter-domain BCE and the 463 destination address is MN's HoA recorded in Inner-domain BCE ,the MN- 464 hLMA forwards the packets to the right MAG directly as described in 465 RFC5213. 467 (6).MN-MAG decapsulates the packets and forwards them to MN through 468 Link-layer. 470 6.2. MN Performs Inter-domain handover 472 On the basis of situation described in 6.1,MN roams to MN-vLMA domain 473 and CN is still in its home domain.The reference network is 474 illustrated in Figure 2. 476 +------------------------------------------+ 477 | | 478 +---------+ +---------+ +----------+ 479 | MN-vLMA |-----| MN-hLMA | | CN-hLMA | 480 +---------+ +---------+ +----------+ 481 | | 482 | | 483 +---------+ +----------+ 484 | MN-MAG2 | | CN-MAG | 485 +---------+ +----------+ 486 | | 487 | | 488 +---------+ +----------+ 489 | MN | | CN | 490 +---------+ +----------+ 492 Figure 2:MN roams to MN- vLMA domain 494 6.2.1. Inter-domain handover operation 496 In RFC5213 the inter-domain handover is not involved.This document 497 describes the network-based Inter-domain handover options, and the 498 corresponding functionality for Inter-domain handover for 499 PMIPv6.Since the MN is not involved in IP mobility signaling in 500 PMIPv6, the sequence of events illustrating the MN inter-domain 501 handover are shown in Figure 3. 503 +-------+ RADIUS +-------+ 504 |MN-hAAA|<---------->|MN-vAAA| 505 +-------+ +-------+ 506 |RADIUS 507 | 508 +--+ +------+ +-------+ +-------+ +-------+ +-------+ 509 |MN| |MN-MAG| |MN-hLMA| |MN-MAG2| |MN-vLMA| |CN-hLMA| 510 +--+ +------+ +-------+ +-------+ +-------+ +-------+ 511 | | | | | | 512 | |DeReg PBU | | | | 513 | |------- ->| | | | 514 | | rPBA | | | | 515 | |<---------| | | | 516 | | RS | | | | 517 |------------------------>| | | 518 | | | | | | 519 | | | | rPBU | | 520 | | | |----------> | 521 | | | | rPBA | | 522 | | | <----------| | 523 | | | | pPBU | | 524 | | <------------------| | 525 | | | | pPBA | | 526 | | |----------------->| | 527 | | | | | pPBU| | 528 | | | | |---------> 529 | | | | | pPBA | 530 | | RA | | |<--------| 531 |<------------------------| | | 532 | | | | | | 534 Figure 3:signaling of MN inter-handover 536 (a)MN-MAG detects that a handover is imminent and sends the DeReg PBU 537 message to the MN-hLMA asking MN-hLMA to remove the binding between 538 MN-MAG and MN. 540 (b)The MN-hLMA sends back the rPBA message to MN-MAG. 542 (c) MN roams to MN-vLMA, and sends Router Solicit(RS) message to MN- 543 MAG2. The MN-HoA and CN-HoA are included in RS message. 545 (d) Upon receiving RS message ,MN-MAG2 sends request to download the 546 per MN Policy Profile from the MN-vAAA. 548 (e)MN-vAAA assigns a MN-vLMA to MN -MAG2 ,and sends request to MN- 549 hAAA to download the per MN Policy Profile . MN-vLMA's address is 550 included in the request message. 552 (f)MN-hAAA receives the request message and sends the MN Policy 553 Profile to MN-vAAA ,then MN-hAAA uses MN-vLMAA to take place of MN- 554 hLMAA. 556 (g)MN-vAAA sends the Accept Message which includes both MN-hLMAA and 557 MN-vLMAA to MN-MAG2. 559 (h) MN-MAG2 sends the rPBU message to MN-vLMA. MN-HoA,CN-HoA and MN- 560 hLMAA are included in rPBU message . 562 (i) Upon receiving rPBU message, MN-vLMA firstly assigns a MN-CoA for 563 MN ,builds up the inner-domain BCE for MN and sends rPBA message back 564 to MN-MAG2 .The MN-CoA is included in rPBA message.In the Inner- 565 domain BCE there is a binding between MN's Proxy-CoA2 and MN's CoA. 567 Secondly,MN-vLMA sends pPBU message to MN-hLMA,the source address of 568 the pPBU message is MN-vLMAA and the destination address of the pPBU 569 message is MN-hLMAA. CN-HoA is included in pPBU message. Upon 570 receiving the pPBU message,MN-hLMA sends back pPBA message to MN- 571 vLMA with CN-HoA included .MN-vLMA builds up the binding between CN- 572 HoA and CN-HoA in the Inter-domain BCE. 574 Thirdly,MN-vLMA sends pPBU message to CN-hLMA, the source address of 575 the pPBU message is MN-CoA and the destination address of the pPBU 576 message is CN-HoA.The pPBU message includes the MN-CoA and MN-HoA. 577 This pPBU message is packaged in UDP format,and by judging the format 578 of the message CN-hLMA intercepts the pPBU message ,encapsulates the 579 message and updates the Inter-domain BCE for MN. That means in the 580 Inter-domain BCE there is a binding between MN-CoA and MN-HoA. 582 (j) After receiving rPBA message from MN-vLMA, MN-MAG2 builds up the 583 binding among MN-HoA ,MN-CoA and MN-vLMA. Then MN-MAG2 sends Router 584 Advertise (RA) message to MN. The inter-domain handover operation is 585 over. 587 6.2.2. Forwarding Consideratons 589 Forwarding Considerations: 591 (a) Packets from MN to CN: 593 (1).The source address is MN-HoA, and the destination address is CN- 594 HoA. 596 (2).The packets are forwarded from MN to MN-MAG2 through Link-layer. 598 (3).The packets are forwarded form MN-MAG2 to MN-hLMA through tunnel, 599 the source address of the tunnel is MN-MAG2's IP address, and the 600 destination address of the tunnel is MN-vLMAA. 602 (4).According to check both the source address and the destination 603 address of the data packets.MN-vLMA detects the MN and CN are not 604 both in their home domain,so MN-vLMA encapsulates the packets to 605 route to CN. The format of the tunneled packet is shown below: 607 IPv6 header (src= MN-vLMAA, dst= CN's HoA) /* Tunnel Header */ 609 IPv6 header (src= MN's HoA, dst= CN's HoA ) /* Packet Header */ 611 Upper layer protocols /* Packet Content*/ 613 (5).The packets are intercepted by CN-hLMA.According to check both 614 the source address and the destination address of the data 615 packets.CN-hLMA detects the MN and CN are not both in their home 616 domain,CN-hLMA decapsulates the packets and forwards them to CN-MAG 617 through tunnel, the source address of the tunnel is CN-hLMAA, and the 618 destination address of the tunnel is CN-Proxy-CoA . 620 (6).CN-MAG decapsulates the packets and forwards them to CN through 621 Link-layer. 623 (b) Packets from CN to MN: 625 (1).The source address is CN-HoA , and the destination address is MN- 626 HoA . 628 (2).The packets are forwarded from CN to CN-MAG through Link-layer. 630 (3).The packets are forwarded form CN-MAG to CN-hLMA through tunnel, 631 the source address of the tunnel is CN-Proxy-CoA and the destination 632 address of the tunnel is CN-hLMAA. 634 (4).According to check both the source address and the destination 635 address of the data packets.CN-hLMA detects the MN and CN are not 636 both in their home domain,so CN-hLMA encapsulates the packets to 637 route to MN..The format of the tunneled packet is shown below: 639 IPv6 header (src= CN-hLMAA, dst= MN's CoA) /* Tunnel Header */ 641 IPv6 header (src= CN's HoA, dst= MN's HoA ) /* Packet Header */ 643 Upper layer protocols /* Packet Content*/ 644 (5). The packets are intercepted by MN-vLMA.MN-vLMA decapsulates the 645 packets and forwards them to MN-MAG2 through tunnel, the source 646 address of the tunnel is MN-vLMAA, and the destination address of the 647 tunnel is MN-Proxy-CoA2. 649 (6).MN-MAG2 decapsulates the packets and forwards them to MN through 650 Link-layer. 652 6.3. CN Performs Inter-domain handover 654 On the basis of situation described in 6.2,CN roams to CN-vLMA domain 655 and MN is still in MN-vLMA domain.The reference network is 656 illustrated in Figure 4. 658 +--------------------------------------------+ 659 | | 660 +---------+ +---------+ +----------+ +----------+ 661 | MN-vLMA |---| MN-hLMA | | CN-hLMA |---| CN-vLMA | 662 +---------+ +---------+ +----------+ +----------+ 663 | | 664 | | 665 +---------+ +----------+ 666 | MN-MAG2 | | CN-MAG2 | 667 +---------+ +----------+ 668 | | 669 | | 670 +---------+ +----------+ 671 | MN | | CN | 672 +---------+ +----------+ 674 Figure 4:CN roams to CN- vLMA domain 676 6.3.1. Inter-domain handover operation 678 The sequence of events illustrating the CN inter-domain handover are 679 shown in Figure 5. 681 +-------+ RADIUS +-------+ 682 |CN-hAAA|<---------->|CN-vAAA| 683 +-------+ +-------+ 684 |RADIUS 685 | 686 +--+ +------+ +-------+ +-------+ +-------+ +-------+ 687 |CN| |CN-MAG| |CN-hLMA| |CN-MAG2| |CN-vLMA| |MN-vLMA| 688 +--+ +------+ +-------+ +-------+ +-------+ +-------+ 689 | | | | | | 690 | |DeReg PBU | | | | 691 | |------- ->| | | | 692 | | rPBA | | | | 693 | |<---------| | | | 694 | | RS | | | | 695 |------------------------>| | | 696 | | | | | | 697 | | | | | | 698 | | | | | | 699 | | | | rPBU | | 700 | | | |----------> | 701 | | | | rPBA | | 702 | | | <----------| | 703 | | | | pPBU | | 704 | | <------------------| | 705 | | | | pPBA | | 706 | | |----------------->| | 707 | | | | | pPBU| | 708 | | | | |---------> 709 | | | | | pPBA | 710 | | RA | | |<--------| 711 |<------------------------| | | 712 | | | | | | 714 Figure 5:signaling of CN inter-handover 716 (a)CN-MAG detects that a handover is imminent and sends the DeReg PBU 717 message to the CN-hLMA asking CN-hLMA to remove the binding between 718 CN-MAG and CN. 720 (b)The CN-hLMA sends back the rPBA message to CN-MAG. 722 (c) CN roams to CN-vLMA, and sends RS message to CN-MAG2. The CN-HoA 723 and MN-HoA are included in RS message. 725 (d) Upon receiving RS message ,CN-MAG2 sends request to download the 726 per CN Policy Profile from the CN-vAAA. 728 (e)CN-vAAA assigns a CN-vLMA to CN -MAG2 ,and sends request to CN- 729 hAAA to download the per CN Policy Profile . CN-vLMA's address is 730 included in the request message. 732 (f)CN-hAAA receives the request message and sends the CN Policy 733 Profile to CN-vAAA ,then CN-hAAA uses CN-vLMAA to take place of CN- 734 hLMAA. 736 (g)CN-vAAA sends the Accept Message which includes both CN-hLMAA and 737 CN-vLMAA to CN-MAG2. 739 (h) CN-MAG2 sends the rPBU message to CN-vLMA. MN-HoA,CN-HoA and CN- 740 hLMAA are included in rPBU message . 742 (i) Upon receiving rPBU message, CN-vLMA firstly assigns a CN-CoA for 743 CN ,builds up the inner-domain BCE for CN and sends rPBA message back 744 to CN-MAG2 .The CN-CoA is included in rPBA message.In the Inner- 745 domain BCE there is a binding between CN's Proxy-CoA2 and CN's CoA. 747 Secondly,CN-vLMA sends pPBU message to CN-hLMA,the source address of 748 the pPBU message is CN-vLMAA and the destination address of the pPBU 749 message is CN-hLMAA. MN-HoA is included in pPBU message. Upon 750 receiving the pPBU message,CN-hLMA sends back pPBA message to CN-vLMA 751 with MN-HoA and MN-CoA included .CN-vLMA updates the inter-domain BCE 752 with the binding between MN-HoA and MN-CoA. 754 Thirdly,CN-vLMA sends pPBU message to MN-hLMA, the source address of 755 the pPBU message is CN-CoA and the destination address of the pPBU 756 message is MN-CoA.The pPBU message includes the CN-CoA and CN-HoA. 757 This pPBU message is packaged in UDP format,and by judging the format 758 of the message MN-hLMA intercepts the pPBU message ,encapsulates the 759 message and updates the Inter-domain BCE for CN. That means in the 760 Inter-domain BCE there is a binding between CN-CoA and CN-HoA. 762 (j) After receiving rPBA message from CN-vLMA, CN-MAG2 builds up the 763 binding among CN-HoA ,CN-CoA and CN-vLMA. Then CN-MAG2 sends RA 764 message to CN. The inter-domain handover operation is over. 766 6.3.2. Forwarding Consideratons 768 Forwarding Considerations: 770 (a) Packets from MN to CN: 772 (1).The source address is MN-HoA, and the destination address is CN- 773 HoA. 775 (2).The packets are forwarded from MN to MN-MAG2 through Link-layer. 777 (3).The packets are forwarded form MN-MAG2 to MN-hLMA through tunnel, 778 the source address of the tunnel is MN-MAG2's IP address, and the 779 destination address of the tunnel is MN-vLMAA. 781 (4). According to check both the source address and the destination 782 address of the data packets.CN-hLMA detects the MN and CN are not 783 both in their home domain,so MN-vLMA encapsulates the packets to 784 route to CN. The format of the tunneled packet is shown below: 786 IPv6 header (src= MN-vLMAA, dst= CN's CoA) /* Tunnel Header */ 788 IPv6 header (src= MN's HoA, dst= CN's HoA ) /* Packet Header */ 790 Upper layer protocols /* Packet Content*/ 792 (5).The packets are intercepted by CN-vLMA. According to check both 793 the source address and the destination address of the data 794 packets.CN-hLMA detects the MN and CN are not both in their home 795 domain,so CN-vLMA decapsulates the packets and forwards them to CN- 796 MAG2 through tunnel, the source address of the tunnel is CN-vLMAA, 797 and the destination address of the tunnel is CN-Proxy-CoA2 . 799 (6).CN-MAG2 decapsulates the packets and forwards them to CN through 800 Link-layer. 802 (b) Packets from CN to MN: 804 (1).The source address is CN-HoA , and the destination address is MN- 805 HoA . 807 (2).The packets are forwarded from CN to CN-MAG2 through Link-layer. 809 (3).The packets are forwarded form CN-MAG2 to CN-vLMA through tunnel, 810 the source address of the tunnel is CN-Proxy-CoA2 and the destination 811 address of the tunnel is CN-vLMAA. 813 (4). According to check both the source address and the destination 814 address of the data packets.CN-hLMA detects the MN and CN are not 815 both in their home domain,so CN-vLMA encapsulates the packets to 816 route to MN. The format of the tunneled packet is shown below: 818 IPv6 header (src= CN-vLMAA, dst= MN's CoA) /* Tunnel Header */ 820 IPv6 header (src= CN's HoA, dst= MN's HoA ) /* Packet Header */ 822 Upper layer protocols /* Packet Content*/ 824 (5). The packets are intercepted by MN-vLMA. According to check 825 both the source address and the destination address of the data 826 packets.CN-hLMA detects the MN and CN are not both in their home 827 domain,so MN-vLMA decapsulates the packets and forwards them to MN- 828 MAG2 through tunnel, the source address of the tunnel is MN-vLMAA, 829 and the destination address of the tunnel is MN-Proxy-CoA2. 831 (6).MN-MAG2 decapsulates the packets and forwards them to MN through 832 Link-layer. 834 7. Message Formats 836 This section defines extensions to the Proxy Mobile IPv6 [RFC5213] 837 protocol messages. 839 7.1. rPBU 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Sequence # | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | MN-Identifier | 849 | MN-hLMAA | 850 | CN-HoA | 851 | MN-HoA | 852 | | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Figure 6:rPBU 857 A Binding Update message that is sent by a mobile access gateway to a 858 local mobility anchor is referred to as the "rPBU" message.A new flag 859 (D) is included in the rPBU message. The rest of the Binding Update 860 message format remains the same as defined in [RFC5213] and with the 861 additional (R) and (M) flags, as specified in [RFC3963] and 863 [RFC4140], respectively. 865 Distinguish Flag (D) 867 A new flag (D) is included in the Binding Update message to indicate 868 to the local mobility anchor that the Binding Update message is a 869 proxy registration sent by a mobile access gateway to a local 870 mobility anchor. The flag MUST be set to the value of 1 . 872 The rPBU message sent by a mobile access gateway to a local mobility 873 anchorcontains MN-Identifer , MN-hLMAA, MN-HoA and CN-HoA. 875 7.2. rPBA 877 0 1 2 3 878 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 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Status |K|R|P|D|Reserved| 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Sequence # | Lifetime | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | MN's IP address | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 Figure 7:rPBA 889 A Binding Acknowledgement message that is sent by a local mobility 890 anchor to a mobile access gateway is referred to as the "rPBA" 891 message. A new flag (D) is included in the Binding Acknowledgement 892 message. The rest of the Binding Acknowledgement message format 893 remains the same as defined in [RFC5213] and with the additional (R) 894 flag as specified in [RFC3963]. 896 Distinguish Registration Flag (D) 898 A new flag (D) is included in the Binding Acknowledgement message to 899 indicate that the local mobility anchor processed the corresponding 900 Proxy Binding Update message as rPBU message. The flag is set to a 901 value of 1 . The rPBA message sent by a local mobility anchor to a 902 mobile access gateway contains MN's IP address assigned by the local 903 mobility anchor . 905 7.3. pPBU 907 0 1 2 3 908 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 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Sequence # | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | options | 915 | | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 Figure 8:pPBU 920 A Binding Update message that is sent by a local mobility anchor to a 921 local mobility anchor is referred to as the "pPBU" message.A new flag 922 (D) and a new flag (M) are included in the pPBU message. The rest of 923 the Binding Update message format remains the same as defined in 924 [RFC5213] and with the additional (R) and (M) flags, as specified in 925 [RFC3963] and [RFC4140], respectively. 927 Distinguish Flag (D) 929 A new flag (D) is included in the Binding Update message to indicate 930 to the local mobility anchor that the Binding Update message is a 931 proxy registration sent by a local mobility anchor to a local 932 mobility anchor. The flag MUST be set to the value of 2 or 3. 934 0 1 2 3 935 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 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Sequence # | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | MN-HoA | 942 | CN-HoA | 943 | | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 Figure 9:pPBU sent by a visit LMA to the home LMA 948 A new flag (D) is included in the Binding Update message to indicate 949 to the local mobility anchor that the Binding Update message is a PBU 950 message sent by a visit local mobility anchor to the home local 951 mobility anchor. The flag MUST be set to the value of 2. This pPBU 952 message sent by a visit local mobility anchor to the home local 953 mobility anchor contains MN-HoA and CN-HoA. 955 0 1 2 3 956 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 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | Sequence # | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 |A|H|L|K|M|R|P|D| Reserved | Lifetime | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | MN-HoA | 963 | MN-CoA | 964 | | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 Figure 10:pPBU sent by MN's LMA to CN's LMA 969 A new flag (D) is included in the Binding Update message to indicate 970 to the local mobility anchor that the Binding Update message is a PBU 971 message sent by MN's local mobility anchor to CN's local mobility 972 anchor . The flag MUST be set to the value of 3.This pPBU message 973 sent by MN's local mobility anchor to CN's local mobility anchor 974 contains MN-HoA and MN-HoA. 976 7.4. pPBA 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Status |K|R|P|D|Reserved| 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 983 | Sequence # | Lifetime | 984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 | options | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 Figure 11:pPBA 990 A Binding Acknowledgement message that is sent by a local mobility 991 anchor to a local mobility anchor is referred to as the "pPBA" 992 message. A new flag (D) and a new flag (M) are included in the 993 Binding Acknowledgement message. The rest of the Binding 994 Acknowledgement message format remains the same as defined in 995 [RFC5213] and with the additional (R) flag as specified in [RFC3963]. 997 Distinguish Registration Flag (D) 999 A new flag (D) is included in the Binding Acknowledgement message to 1000 indicate that the local mobility anchor processed the corresponding 1001 Proxy Binding Update message as pPBU message. The flag is set to a 1002 value of 2 or 3. 1004 A new flag (D) is included in the Binding Acknowledgement message to 1005 indicate that the local mobility anchor processed the corresponding 1006 Proxy Binding Update message as pPBU message sent by a visit local 1007 mobility anchor to the home local mobility anchor. The flag is set 1008 to a value of 2 .The options of the message contains the CN-CoA. 1010 A new flag (D) is included in the Binding Acknowledgement message to 1011 indicate that the local mobility anchor processed the corresponding 1012 Proxy Binding Update message as pPBU message sent by MN's local 1013 mobility anchor to CN's local mobility anchor. The flag is set to a 1014 value of 3 . 1016 8. Security Considerations 1018 The potential security threats against any network-based mobility 1019 management protocol are described in [RFC4832]. This section 1020 explains how Proxy Mobile IPv6 protocol defends itself against those 1021 threats. 1023 Proxy Mobile IPv6 protocol recommends the signaling messages, Proxy 1024 Binding Update and Proxy Binding Acknowledgement, exchanged between 1025 the mobile access gateway and the local mobility anchor or between a 1026 local mobility anchor and a local mobility anchorto be protected 1027 using IPsec using the established security associationbetween them. 1028 This essentially eliminates the threats related to the impersonation 1029 of the mobile access gateway or the local mobility anchor. 1031 This specification allows a mobile access gateway to send binding 1032 registration messages on behalf of a mobile node. If proper 1033 authorization checks are not in place, a malicious node may be able 1034 to hijack a mobile node's mobility session or may carry out a denial- 1035 of-service attack. To prevent this attack, this specification 1036 requires the local mobility anchor to allow only authorized mobile 1037 access gateways that are part of that Proxy Mobile IPv6 domain to 1038 send Proxy Binding Update messages on behalf of a mobile node. 1040 To eliminate the threats on the interface between the mobile access 1041 gateway and the mobile node, this specification requires an 1042 established trust between the mobile access gateway and the mobile 1043 node and to authenticate and authorize the mobile node before it is 1044 allowed to access the network. Further, the established 1045 authentication mechanisms enabled on that access link will ensure 1046 that there is a secure binding between the mobile node's identity and 1047 its link-layer address. The mobile access gateway will definitively 1048 identify the mobile node from the packets that it receives on that 1049 access link. 1051 To address the threat related to a compromised mobile access gateway, 1052 the local mobility anchor, before accepting a Proxy Binding Update 1053 message for a given mobile node, may ensure that the mobile node is 1054 attached to the mobile access gateway that sent the Proxy Binding 1055 Update message. This may be accomplished by contacting a trusted 1056 entity, which is able to track the mobile node!_s current point of 1057 attachment. However, the specific details of the actual mechanisms 1058 for achieving this is outside the scope of this document. 1060 9. IANA Considerations 1062 This document defines six new Mobility Header options, the 1063 HomeNetwork Prefix Option, Handoff Indicator Option, Access 1064 Technology Type Option, Mobile Node Link-layer Identifier Option, 1065 Link-local Address Option, and Timestamp Option. The Type value for 1066 these options has been assigned from the same numbering space as 1067 allocated for the other mobility options,as defined in [RFC3775]. 1069 The Handoff Indicator Option introduces a new Handoff Indicator (HI) 1070 numbering space, where the values from 0 to 5 have been reserved by 1071 this document. Approval of new Handoff Indicator type values are to 1072 be made through IANA Expert Review. 1074 The Access Technology Type Option introduces a new Access Technology 1075 type (ATT) numbering space, where the values from 0 to 5 have been 1076 reserved by this document. Approval of new Access Technology type 1077 values are to be made through IANA Expert Review. 1079 This document also defines new Binding Acknowledgement status values. 1080 The status values MUST be assigned from the same number space used 1081 for Binding Acknowledgement status values,as defined in [RFC3775]. 1082 The allocated values for each of thesestatus values must be greater 1083 than 128. 1085 This document creates a new registry for the flags in the Binding 1086 Update message called the "Distinguish Flag". 1088 The following flags are reserved: 1090 (A) 0x8000 [RFC3775] 1092 (H)0x4000 [RFC3775] 1094 (L)0x2000 [RFC3775] 1096 (K) 0x1000 [RFC3775] 1098 (M) 0x0800 [RFC4140] 1100 (R) 0x0400 [RFC3963] 1102 (P) 0x0200[RFC5213] 1104 This document reserves a new flag (D) as follows: 1106 (D) 0x0100 1108 The rest of the values in the 16-bit field are reserved. New values 1109 can be assigned by Standards Action or IESG approval. 1111 This document also creates a new registry for the flags in the 1112 Binding Acknowledgment message called the "Distinguish Flag". The 1113 following values are reserved. 1115 (K) 0x80 [RFC3775] 1117 (R) 0x40 [RFC3963] 1119 (P) 0x20 [RFC5213] 1121 This document reserves a new flag (D) as follows: 1123 (D) 0x10 1125 10. References 1127 10.1. Normative References 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, March 1997. 1132 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1133 IPv6 Specification", RFC 2473, December 1998. 1135 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1136 of Explicit Congestion Notification (ECN) to IP", 1137 RFC 3168, September 2001. 1139 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1140 and M. Carney, "Dynamic Host Configuration Protocol for 1141 IPv6 (DHCPv6)", RFC 3315, July 2003. 1143 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1144 in IPv6", RFC 3775, June 2004. 1146 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1147 Network Access Identifier", RFC 4282, December 2005. 1149 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1150 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1151 (MIPv6)", RFC 4283, November 2005. 1153 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1154 Architecture", RFC 4291, February 2006. 1156 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1157 Internet Protocol", RFC 4301, December 2005. 1159 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1160 RFC 4303, December 2005. 1162 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1163 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1164 September 2007. 1166 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1167 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1169 10.2. Informative References 1171 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1172 for IP version 6", RFC 1981, August 1996. 1174 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1175 "Remote Authentication Dial In User Service (RADIUS)", 1176 RFC 2865, June 2000. 1178 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 1179 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1181 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1182 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1183 RFC 3963, January 2005. 1185 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1186 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1188 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 1189 Bellier, "Hierarchical Mobile IPv6 Mobility Management 1190 (HMIPv6)", RFC 4140, August 2005. 1192 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1193 RFC 4306, December 2005. 1195 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1196 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 1198 [RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 1199 "Chargeable User Identity", RFC 4372, January 2006. 1201 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1202 Discovery", RFC 4821, March 2007. 1204 [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized 1205 Mobility Management (NETLMM)", RFC 4830, April 2007. 1207 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 1208 Management (NETLMM)", RFC 4831, April 2007. 1210 Authors' Addresses 1212 Zhengming Ma 1213 SUN YAT-SEN UNIVERSITY 1214 Department of Electronics and Engineering,daxuecheng,313 1215 Zhongshan University,Guangzhou, 510006 1216 P.R. China 1218 Email: issmzm@mail.sysu.edu.cn 1219 Ke Wang 1220 SUN YAT-SEN UNIVERSITY 1221 Department of Electronics and Engineering,daxuecheng,313 1222 Zhongshan University,Guangzhou, 510006 1223 P.R. China 1225 Email: wang923zheng@sina.com 1227 Fei Zhang 1228 SUN YAT-SEN UNIVERSITY 1229 Department of Electronics and Engineering,daxuecheng,313 1230 Zhongshan University,Guangzhou, 510006 1231 P.R. China 1233 Email: zsu05zhangfei@163.com