idnits 2.17.00 (12 Aug 2021) /tmp/idnits29972/draft-premec-netlmm-bulk-re-registration-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- 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 (October 7, 2009) is 4602 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetLMM Working Group D. Premec 3 Internet-Draft 4 Intended status: Standards Track S. Gundavelli 5 Expires: April 10, 2010 K. Leung 6 Cisco 7 S. Krishnan 8 Ericsson 9 B. Patil 10 Nokia 11 October 7, 2009 13 Bulk Re-registration for Proxy Mobile IPv6 14 draft-premec-netlmm-bulk-re-registration-03 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 10, 2010. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 Proxy Mobile IPv6 specification requires the Mobile Access Gateway 53 (MAG) to send a separate Proxy Binding Update (PBU) message to the 54 Local Mobility Agent (LMA) for each mobile node (MN) to renew the 55 MN's mobility binding. This document defines a mechanism by which a 56 MAG can update the mobility bindings of multiple MNs attached to it 57 with a single PBU message to the serving LMA. This document also 58 specifies a new mobility option that can be used by the mobility 59 entities in a Proxy Mobile IPv6 domain for carrying the group 60 affiliation of a mobile node in any of the mobility signaling 61 messages. 63 Requirements Language 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC 2119 [RFC2119]. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Bulk Re-registration Overview . . . . . . . . . . . . . . . . 5 74 3.1. Motivation for bulk re-registration . . . . . . . . . . . 5 75 3.2. Bulk re-registration operation . . . . . . . . . . . . . . 6 76 4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1. Proxy Binding Update message . . . . . . . . . . . . . . . 7 78 4.2. Proxy Binding Acknowledgment message . . . . . . . . . . . 8 79 4.3. Mobile Node Group Identifier Option . . . . . . . . . . . 9 80 5. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. LMA operation . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 The Proxy Mobile IPv6 base specification [RFC5213] uses the mobile 93 node identifier in the mobility signaling messages for identifying 94 the mobile node. However, the signaling messages lack the capability 95 to identify a set of mobile nodes which have a common characteristic. 96 A group identifier associated with a mobile node enables the ability 97 to perform protocol operation on a set of mobile nodes via a single 98 transaction. The group identifier provides a more optimal mechanism 99 for protocol operation which would otherwise require multiple atomic 100 transactions on a per mobile node basis. Following are some of the 101 use-cases where such identifier can be used. 103 o In a blade architecture system running the local mobility anchor 104 service, all the mobile node sessions anchored on a given card can 105 be part of one single group. When there is a failure on a 106 specific card, the local mobility anchor can initiate the 107 revocation signaling to the mobile access gateway by sending a 108 sending a single revocation request carrying the group identifier. 110 o For periodic re-registrations, the mobile access gateway may send 111 a single re-registration message for each of the mobile nodes' 112 groups and perform re-registrations for all the mobile node's that 113 are part of that group. 115 o The mobile access gateway or the local mobility anchor in a proxy 116 mobile IPv6 domain may choose to revoke the registration of mobile 117 node associated with a specific realm. In such cases the mobile 118 access gateway or the local mobility anchor can perform the 119 binding revocation signaling using the group ID associated with a 120 specific set of mobile nodes. 122 The remeinder of this document defines a new mobility option, Mobile 123 Node Group Identifier option, that can be used by a local mobility 124 anchor and a mobile access gateway for exchanging the mobile node's 125 group identifier as well as its application for bulk periodic re- 126 registrations. 128 2. Terminology 130 General mobility related terminology is defined in [RFC3775]. 131 Additional PMIPv6 specific terminology can be found in [RFC5213]. 133 PMIPv6 domain 134 Network providing the network based IP mobility service as defined 135 in [RFC5213]. 137 PMIPv6 138 Proxy Mobile IPv6 protocol specified in [RFC5213]. 140 Bulk re-registration 141 PBU/PBAck message exchange where the bulk re-registration flag (B) 142 is set to 1 144 Bulk re-registration set 145 a set of MNs identifed by the Mobile Node Group ID option to which 146 the bulk re-registration operation applies. 148 3. Bulk Re-registration Overview 150 3.1. Motivation for bulk re-registration 152 In a PMIPv6 domain a single LMA serves multiple MAGs and the capacity 153 of the LMA in terms of the number of attached MNs can be quite large. 154 It can be expected that LMA capacity in managed networks may easily 155 exceed hundreds of thousands or more attached MNs. 157 The following simple formula gives an estimate of the average number 158 of re-registration transactions per second as a function of the 159 number of registered MNs and the binding lifetime period: 161 transactions/sec = (number of registered MNs) / (binding lifetime*4) 163 For 50.000 MNs and the binding lifetime of half an hour this gives: 164 50000 MNs / 1800 sec = 27,7 transactions/sec 166 Based on the above formula it is apparent that the default re- 167 registration process where the MAG sends a separate message for each 168 MN is inefficient or suboptimal. These re-registration messages 169 consume significant network resources both in terms of processing 170 power at the LMA and MAG and network bandwidth. 172 This document proposes an optimization of the re-registration process 173 by which the signaling load for re-registration can be reduced to a 174 single transaction per MAG, irrespective of the number of attached 175 MNs. 177 According to this proposal a MAG adds a MN to a set of MNs re- 178 registered in a bulk mode by setting the bulk re-registration bit (B) 179 in the PBU message. The PBU message sent in response contains the 180 Mobile Node Group Identifier mobility option which is defined later 181 in this document. In the context of bulk re-registrations the Mobile 182 Node Group Identifier is an opaque identifier that is allocated by 183 the LMA and which uniquely identifies the bulk set to which the MN 184 was added. 186 A MAG requests a bulk re-registration for a set of MNs by sending a 187 single PBU message which includes a Mobile Node Group Identifier 188 mobility option and the LMA extends the binding lifetime of MNs that 189 are members of that group. By using this method, the MAG and LMA 190 accomplish the re-registration of MNs attached to a MAG in a single 191 transaction. The number of re-registration transactions at the LMA 192 becomes independent of the number of attached MNs; instead it is 193 dependent only on the number of MAGs. 195 In addition to minimizing the signaling overhead associated with the 196 lifetime extension of the mobility bindings, the MAG and LMA may use 197 a single timer per bulk re-registration set to monitor the binding 198 lifetime of all the member MNs instead of an individual timer per MN. 200 3.2. Bulk re-registration operation 202 The bulk re-registration mechanism allows the MAG and the LMA to 203 extend the binding lifetime for a number of MNs with a single 204 transaction. The MAG and LMA maintain a set of MNs that can be re- 205 registered in bulk mode. Such set is called a bulk re-registration 206 set and is a subset of the MNs attached to a MAG. There can be 207 multiple bulk re-registration sets for a given MAG-LMA pair. 208 Initially the bulk re-registration set is empty. MAG requests to add 209 individual MNs to the bulk set by sending a regular PBU message that 210 identifies an individual MN and additionally the bulk registration 211 flag in the message is set to 1. Based on the received bulk re- 212 registration bit the LMA adds the MN to the bulk re-registration set 213 and responds with the PBAck message with the bulk registration flag 214 (B) set to 1. The LMA identifies the bulk re-registration set to 215 which the MN was added by including the Mobile Node Group ID option 216 in the PBAck message. 218 Once there is a non-empty bulk re-registration set, MAG can request 219 to extend the binding lifetime for all MNs that are part of the bulk 220 re-registration set by sending a PBU message with the bulk (B) bit 221 set and by including the Mobile Node Group ID identifiy the bulk re- 222 registration set. Such PBU message lacks any options that identify 223 an individual MN. In particular, the MAG omits both the MN ID 224 (Mobile Node Identifier) and the HNP (Home Network Prefix) options. 226 There may be different triggers that cause the MAG to request a bulk 227 re-registration. Typically the trigger is the binding lifetime 228 expiry of a MN that is a member of a bulk re-registration set. There 229 could be other triggers as well, but they may be implementation or 230 domain specific and outside the scope of this specification. 232 When the MAG requests the MN to be added to the bulk re-registration 233 set, the LMA includes the Mobile Node Group Identifier mobility 234 option in the PBAck message. The Mobile Node Group Identifier is an 235 opaque identifier allocated by the LMA that uniquely identifies the 236 bulk set at the LMA to which the MN was added. The MAG associates 237 the MN with the Mobile Node Group Identifier received in the PBAck. 239 The MAG includes the Mobile Node Group Identifier mobility option set 240 to the value previously received from the LMA to request the bulk re- 241 registration for the MNs that are part of this particular bulk re- 242 registration set. The MAG may include multiple instances of the 243 Mobile Node Group Identifier option in the PBU message to request 244 lifetime refreshment for several bulk sets in a single message. 246 The LMA extends the mobility binding of all MNs that are members of 247 indicated bulk re-registration sets and responds with PBAck message 248 echoing the received Mobile Node Group Identifier mobility options. 250 A MAG may remove a MN from a bulk re-registration set by sending a 251 regular PBU message identifying the MN to be removed and with the 252 bulk re-registration flag set to 0. 254 When requested to add a MN to the bulk re-registration set, the LMA 255 may reject the request. In this case the LMA processes the PBU 256 message as if the bulk re-registration flag was not set and responds 257 with PBAck message where the bulk re-registration flag is set to 0. 259 4. Message formats 261 This section introduces extensions to PBU and PBAck messages used in 262 this specification. 264 4.1. Proxy Binding Update message 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sequence # | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |A|H|L|K|M|R|P|B| Reserved | Lifetime | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 . . 274 . Mobility options . 275 . . 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 1 281 A Proxy Binding Update message is defined in the [RFC5213]. A new 282 flag (B) is defined for the Binding Update message. 284 Bulk Registration Flag (B) 286 If the bulk registration flag (B) is set to 1, then the PBU message 287 is a request to add the MN to the bulk re-registration set. If the 288 bulk registration flag (B) is set to 0 and if the MN is found to be a 289 member of the bulk re-registration set, then the MN is removed from 290 the bulk re-registration set. 292 Mobility Options 294 For descriptions of the mobility options, refer to [RFC5213]. When 295 the PBU message is sent to refresh bindings in a bulk mode, the 296 message MUST contain at least one Mobile Node Group Identifier 297 mobility option and does not contain the MN-ID and the HNP mobility 298 options. 300 4.2. Proxy Binding Acknowledgment message 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Status |K|R|P|B| Res. | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Sequence # | Lifetime | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | 309 . . 310 . Mobility options . 311 . . 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 2: Proxy Binding Acknowledgment message 317 A Proxy Binding Acknowledgment message is defined in the [RFC5213]. 318 A new flag (B) is defined for the Binding Acknowledgment message. 320 Bulk Registration Flag (B) 322 A new flag (B) is included in the Binding Acknowledgment message to 323 indicate to the MAG that the MN was successfully added to the bulk 324 re-registration set. The flag MUST NOT be set to the value of 1 if 325 it was not set to 1 in the corresponding PBU message. 327 Mobility Options 329 For descriptions of these options, refer to [RFC5213]. When the bulk 330 registration flag is set to 1 in the PBU message, then the PBAck 331 message MUST also contain the Mobile Node Group Identifier mobility 332 option. When the Mobile Node Group Identifier mobility option(s) 333 were included in the PBU message, the PBAck message echoes back the 334 Mobile Node Group Identifier options from the PBU message. 336 4.3. Mobile Node Group Identifier Option 338 A new option, Mobile Node Group Identifier option is defined for 339 using it in Proxy Binding Update and Proxy Binding Acknowledgement 340 messages exchanged between a local mobility anchor and mobile access 341 gateway. This option is used for carrying the mobile node's group 342 identifier. 344 The alignment requirement for this option is 4n. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | Sub-type | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Mobile Node Group Identifier | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 3: Mobile Node Group Identifier Option 356 Type 357 359 Length 360 8-bit unsigned integer indicating the length in octets of the 361 option, excluding the type and length fields. The value for this 362 field MUST be set to 6. 364 Sub-type 365 Identifies the specific group type. This number space will be 366 managed by the IANA. 368 Reserved 369 This field is unused for now. The value MUST be initialized to 0 370 by the sender and MUST be ignored by the receiver. 372 Mobile Node Group Identifier A 32-bit field containing the mobile 373 node's group identifier. 375 The Mobile Node's Group Identifier option reflects the group 376 affiliation that is local to the LMA or MAG, as determined by those 377 respective entities. 379 5. MAG Operation 381 The conceptual Binding Update List entry data structure maintained by 382 the MAG, described in Section 6.1 of [RFC5213], MUST be extended to 383 store the mobile node's group identifier. 385 The Mobile Node Group Identifier option MAY be used in the PBU 386 message sent by the MAG to the LMA. When this option is included, 387 the identifier value in the option MUST be set to the mobile node's 388 group identifier that was assigned previously by the LMA. 390 When a new MN attaches to a MAG, the MAG registers the MN with the 391 LMA by sending the PBU message formatted as described in [RFC5213]. 393 Additionally, the MAG MAY set the bulk registration flag (B) in the 394 PBU message to 1 to request the LMA to add the MN to the bulk 395 registration set. The decision to request the bulk re-registration 396 mode for a MN is a matter of local policy at the MAG and is outside 397 the scope of this specification. 399 The MAG SHALL maintain a separate bulk re-registration sets for each 400 LMA. 402 The MAG SHALL add the MN to its bulk re-registration set when it 403 receives a PBAck message with the bulk registration bit set to 1 and 404 if the corresponding PBU message was requesting the LMA to add the MN 405 to the bulk re-registration set. The MAG SHALL associate the MN 406 being registered with the Mobile Node Group Identifier received in 407 the PBAck message. 409 When the binding lifetime of any MN contained in the bulk re- 410 registration set is about to expire, the MAG SHALL request the bulk 411 re-registration by sending the PBU message containing the Mobile Node 412 Group Identifier mobility option. The length of the Mobile Node 413 Group Identifier option may be 0 in which case the MAG is requesting 414 a refreshment of the binding lifetime for all MN attached to that MAG 415 that were registered with the B flag set. Alternatively, the MAG MAY 416 include one or more Mobile Node Group Identifier options containing 417 the values that were indicated by the LMA in the PBAck messages when 418 the MN was added to the bulk set. In this case the MAG asks for 419 refreshment of specific bulk sets indicated by the Mobile Node Group 420 Identifier options. The MAG SHALL NOT include the MN ID and the HNP 421 options in the PBU message requesting bulk refreshment. 423 The MAG MAY trigger a bulk re-registration at any time. The policy 424 and exact conditions for these additional triggers are outside of 425 scope of this specification. 427 When the MAG receives a PBAck message indicating success and which 428 echoes the Mobile Node Group Identifier options that were included in 429 the corresponding PBU message, the MAG SHALL update the binding 430 lifetime of all MNs belonging to the indicated groups to the lifetime 431 value contained in the PBAck message. If in the case of bulk re- 432 registration the PBAck message repeatedly indicates an error, the MAG 433 SHALL fall back to individual re-registration mode. 435 Instead of maintaining one timer per MN, the MAG MAY start a single 436 timer per bulk registration set to oversee the binding lifetime of 437 all MNs that are members of that bulk registration set. 439 If the MAG sets the bulk re-registration bit to 1 in a PBU message 440 but the bulk registration bit (B) is set to 0 in a PBAck message, the 441 MAG SHALL process the PBAck message as per [RFC5213]. In addition, 442 the MAG SHALL infer that the LMA does not support bulk re- 443 registration procedure. The MAG SHALL switch to regular, per-MN re- 444 registration mode as described in [RFC5213]. The MAG MAY retry the 445 bulk re-registration procedure after sufficient time has elapsed from 446 the previous unsuccessful bulk re-registration. This amount of time 447 SHOULD be configurable at the MAG. 449 6. LMA operation 451 The conceptual Binding Cache entry data structure maintained by the 452 LMA, described in Section 5.1 of [RFC5213], MUST be extended to store 453 the mobile node's group identifier. 455 The Mobile Node Group Identifier option MAY be used in the PBAck 456 message sent by the LMA to the MAG. When this option is included, 457 the identifier value in the option MUST be set to the mobile node's 458 group identifier, local to the local mobility anchor. 460 When the LMA receives a PBU message with a bulk registration bit (B) 461 set to 1, the LMA SHALL first process the PBU message as per 462 [RFC5213]. Upon successful processing of the message, the LMA SHALL 463 perform additional processing of the PBU message as described further 464 below for bulk mode re-registrations. 466 If the bulk re-registration flag in the PBU message is set to 1, the 467 LMA MAY add the MN(s) indicated in the PBU to the set of MNs re- 468 registered in a bulk mode, subject to the local policy. The decision 469 whether to enable bulk re-registration mode is a matter of local 470 policy at the LMA and is outside the scope of this specification. 472 If the LMA decides to accept the bulk re-registration mode for the 473 MN, it SHALL add the MN to a bulk re-registration set. The LMA SHALL 474 maintain distinct bulk re-registrations set for each MAG and there 475 could be several such sets per single MAG. 477 Upon adding the MN to the bulk re-registration set, the LMA SHALL 478 respond with the PBAck message containing the bulk registration bit 479 set to 1. The LMA SHALL include the Mobile Node Group Identifier 480 option in the PBAck message. The Mobile Node Group Identifier is 481 allocated by the LMA and identifies the particular bulk set to which 482 the MN is assigned. 484 The PBU message without the MN ID and HNP options but including the 485 Mobile Node Group Identifier mobility option is a valid message and 486 indicates a request for bulk mode re-registration of all MNs that are 487 members of the indicated bulk re-registration set. There MAY be 488 several Mobile Node Group Identifier options in the PBU message, in 489 which case the MAG requests the bulk refreshment of all MNs that are 490 members of the indicated bulk sets. If the length of the Mobile Node 491 Group Identifier option is zero, the MAG is requesting a lifetime 492 refreshment of all the MN attached to the MAG that are members of any 493 bulk set. The LMA SHALL extend the binding lifetime of all affected 494 MNs attached to the MAG that sent the bulk PBU. 496 The LMA SHALL set the binding lifetime of all MNs re-registered in a 497 bulk mode to expire at the same point in time. 499 Upon successful processing of bulk mode re-registration request, the 500 LMA MUST respond with a PBAck message indicating success and echoing 501 the mobility options received from the PBU. The lifetime in the 502 PBAck message indicates the time when binding cache entries of 503 affected MNs will expire. 505 The LMA MAY reject the request for bulk re-registration. In this 506 case the LMA MUST NOT update binding cache entries of any MNs and 507 SHALL respond with PBAck indicating the reason for the rejection in 508 the status code. 510 After successfully processing the bulk PBU message, the LMA SHOULD 511 start a single timer to oversee the binding lifetime of all MNs 512 affected by this bulk re-registration transaction. 514 The LMA not supporting this specification ignores the bulk re- 515 registration bit (B) and the Mobile Node Group Identifier option in a 516 PBU message and processes the message as per the baseline 517 specification [RFC5213]. In this case the PBAck message sent in 518 response contains the bulk re-registration bit (B) set to 0. 520 If the LMA that does not support this specification receives a bulk 521 PBU message that does not contain any options identifying a 522 particular MN then the LMA responds with the PBAck message where the 523 status field contains one of the following error codes: 525 MISSING_HOME_NETWORK_PREFIX_OPTION 527 MISSING_MN_IDENTIFIER_OPTION 529 These error codes are defined in the baseline specification 530 [RFC5213]. 532 7. IANA Considerations 534 This specification defines a new Mobility Header option, the Mobile 535 Node Group Identifier option. This option is described in section 536 Figure 3. The Type value for this option needs to be assigned from 537 the same numbering space as allocated for the other mobility options, 538 as defined in [RFC3775]. 540 Note to RFC Editor: this section may be removed on publication as an 541 RFC. 543 8. Security Considerations 545 The mobile node's identifier is always present in the Proxy Mobile 546 IPv6 signaling messages and additionally carrying the group identity 547 of the mobile node introduces similar vulnerabilities. Specifically, 548 it exposes the group affiliation of the user and may result in 549 compromising the privacy of the user or the location information. 551 The Mobile Node Group Identifier option defined in this specification 552 is for use in Proxy Binding Update and Proxy Binding Acknowledgement 553 messages. This option is carried like any other mobility header 554 option as specified in [RFC3775] and does not require any special 555 security considerations. 557 The bulk re-registration mechanism does not introduce any new 558 security threat or vulnerability to the PMIPv6 specification. 560 9. Acknowledgements 562 Thanks to Jouni Korhonen for his review and input. 564 The authors would like to acknowledge the prior discussions on this 565 topic in netlmm mailing list. 567 Earlier versions of this document were prepared using 2-Word- 568 v2.0.template.dot. 570 10. References 572 10.1. Normative References 574 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 575 Requirement Levels", BCP 14, RFC 2119, March 1997. 577 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 578 in IPv6", RFC 3775, June 2004. 580 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 581 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 583 10.2. Informative References 585 Authors' Addresses 587 Domagoj Premec 589 Email: domagoj.premec@gmail.com 591 Sri Gundavelli 592 Cisco 593 170 West Tasman Drive 594 San Jose, CA 95134 595 USA 597 Phone: 598 Fax: 599 Email: sgundave@cisco.com 600 URI: 602 Kent Leung 603 Cisco 604 170 West Tasman Drive 605 San Jose, CA 95134 606 USA 608 Phone: 609 Fax: 610 Email: kleung@cisco.com 611 URI: 613 Suresh Krishnan 614 Ericsson 615 8400 Decarie Blvd. 616 Town of Mount Royal, QC 617 Canada 619 Phone: +1 514 345 7900 x42871 620 Fax: 621 Email: suresh.krishnan@ericsson.com 622 URI: 624 Basavaraj Patil 625 Nokia 626 6000 Connection Drive 627 Irving, TX 75039 628 USA 630 Phone: 631 Fax: 632 Email: basavaraj.patil@nokia.com 633 URI: