idnits 2.17.1 draft-ietf-netext-update-notifications-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 8, 2013) is 3824 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) == Outdated reference: A later version (-12) exists of draft-ietf-netext-pmip6-qos-03 == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Gundavelli 5 Expires: April 11, 2014 Cisco 6 M. Liebsch 7 NEC 8 H. Yokota 9 KDDI 10 J. Korhonen 11 Renesas Mobile 12 October 8, 2013 14 Update Notifications for Proxy Mobile IPv6 15 draft-ietf-netext-update-notifications-12 17 Abstract 19 This document specifies protocol enhancements for allowing the local 20 mobility anchor in a Proxy Mobile IPv6 domain to asynchronously 21 notify the mobile access gateway about changes related to a mobility 22 session. These update notification messages are exchanged using a 23 new Mobility Header message type specifically designed for this 24 purpose. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 11, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 62 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Notification Message - Usage Examples . . . . . . . . . . . . 4 65 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Update Notification(UPN) . . . . . . . . . . . . . . . . . 5 67 4.2. Update Notification Acknowledgement(UPA) . . . . . . . . . 7 68 5. LMA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Constructing the Update Notification Message . . . . . . . 10 70 5.2. Receiving the Update Notification Acknowledgement 71 Message . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 6. MAG Considerations . . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. Receiving the Update Notification Message . . . . . . . . 12 74 6.2. Constructing the Update Notification Acknowledgement 75 Message . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7. Protocol Configuration Variables . . . . . . . . . . . . . . . 15 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 81 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 82 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 85 1. Introduction 87 In some situations, there is a need for the local mobility anchor to 88 send asynchronous notification messages to the mobile access gateway 89 in the course of a mobility session. These situations include 90 changes to mobility session parameters and policy parameters. In 91 this context, 'Asynchronous messages' is used to mean messages that 92 are not synchronous with the Proxy Binding Update and Proxy Binding 93 Acknowledgement messages of the base Proxy Mobile IPv6 specification 94 [RFC5213]. The base Proxy Mobile IPv6 specification does not have a 95 provision for sending unsolicited update notifications messages from 96 the local mobility anchor to the mobile access gateway. 98 Proxy Mobile IPv6 [RFC5213] is a network-based mobility management 99 protocol. It is designed for providing IP mobility management 100 support to a mobile node, without requiring the participation of the 101 mobile node in any IP mobility related signaling. The protocol 102 defines two mobility management entities, local mobility anchor (LMA) 103 and mobile access gateway (MAG). These entities are responsible for 104 managing IP mobility management support for a mobile node in a Proxy 105 Mobile IPv6 domain. The setup of the mobility session is initiated 106 by the mobile access gateway by sending a Proxy Binding Update 107 message and acknowledged by the local mobility anchor in the Proxy 108 Binding Acknowledgement message. Once the mobility session is set 109 up, currently there is no mechanism for the local mobility anchor to 110 inform the mobile access gateway about changes to the mobility 111 session or any parameters related to the mobility session. However, 112 there are mechanisms in the Proxy Mobile IPv6 protocol which allows a 113 local mobility anchor to send signaling messages to the mobile access 114 gateway asynchronously, as defined in Proxy Mobile IPv6 Heartbeat 115 message [RFC5847], or in the Binding Revocation message [RFC5846], 116 but, these signaling messages are designed for a very specific 117 purpose and are not sufficient for supporting a notification 118 framework. 120 One such scenario where such a mechanism is needed is when the local 121 mobility anchor wants to inform the mobile access gateway that it 122 needs to re-register the mobility session for a mobile node. It is 123 possible to achieve a similar effect by using a short lifetime for 124 the mobility sessions but in several networks this results in an 125 unacceptable, and mostly unnecessary, increase in the signaling load 126 and overhead. More suitable is to enable a demand-based signaling 127 from the local mobility anchor to one or more mobile access gateways. 128 Another example is when there is change in QoS policy 129 [I-D.ietf-netext-pmip6-qos], or a change in IP Flow mobility policy 130 [I-D.ietf-netext-pmipv6-flowmob], or a IPv4 Traffic Offload Policy 131 [RFC6909], for a mobility session, the local mobility anchor wants to 132 request the mobile access gateway to perform re-registration of the 133 mobility session and so in order to update the policies associated 134 with the mobility session of a mobile node. 136 This document defines a new mobility header message for allowing the 137 local mobility anchor to send notification messages to the mobile 138 access gateway and a corresponding mobility header message for the 139 mobile access gateway to acknowledge the notification message. The 140 purpose of the notification message is two-fold: (1) enable the local 141 mobility anchor to notify the mobile access gateway about the updated 142 session parameters, (2) enable the local mobility anchor to request 143 the mobile access gateway to re-negotiate the session parameters. 145 2. Conventions and Terminology 147 2.1. Conventions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 2.2. Terminology 155 All the mobility related terms used in this document are to be 156 interpreted as defined in the base Proxy Mobile IPv6 specifications 157 [RFC5213] and [RFC5844]. 159 3. Notification Message - Usage Examples 161 Use Case 1: Consider a use case where the local mobility anchor wants 162 the mobile access gateway to re-register a specific mobility session. 164 MN MAG LMA 165 |------>| | 1. Mobile Node Attach 166 | |------->| 2. Proxy Binding Update 167 | |<-------| 3. Proxy Binding Acknowledgement 168 | |========| 4. Tunnel/Route Setup 169 | | | 170 | |<-------| 5. Update Notification (FORCE-REREGISTRATION) 171 | |------->| 6. Update Notification Acknowledgement 172 | | | 173 | |------->| 7. Proxy Binding Update 174 | |<-------| 8. Proxy Binding Acknowledgement 175 | | | 177 Figure 1: Update Notification - Force ReRegistration 179 Use Case 2: Consider a use case where the local mobility anchor wants 180 to notify the updated session parameters to the mobile access 181 gateway, for example, an updated QoS profile, or an updated IPv4 182 Offload Policy. 184 MN MAG LMA 185 |------>| | 1. Mobile Node Attach 186 | |------->| 2. Proxy Binding Update 187 | |<-------| 3. Proxy Binding Acknowledgement 188 | |========| 4. Tunnel/Route Setup 189 | | | 190 | |<-------| 5. Update Notification 191 | |------->| 6. Update Notification Acknowledgement 192 | + | 7. MAG applies the new policy option 193 | | | 195 Figure 2: Update Notification - Notifying Session Parameters 197 4. Message Formats 199 4.1. Update Notification(UPN) 201 The Update Notification is a mobility header message that has an MH 202 Type value of . It is used by the local mobility anchor to 203 notify the mobile access gateway that some parameters related to the 204 mobility session have changed. 206 The format of the Update Notification message is as follows: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Sequence # | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Notification Reason |A|D| Reserved | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 . . 217 . Mobility options . 218 . . 219 | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Figure 3: Update Notification Message 224 Sequence Number 225 A 16-bit unsigned integer used by the local mobility anchor to 226 match the received Update Notification Acknowledgement message 227 with this Update Notification message. This sequence number could 228 be a random number and can be managed under the same variable used 229 in Proxy Mobile IPv6 signaling messages [RFC5213]. At any time, 230 implementations MUST ensure there is no collision between the 231 sequence numbers of all outstanding Update Notification messages. 232 Notification Reason 233 This 16-bit unsigned integer indicates the Notification reason 234 code. This code corresponding to the reason that caused the local 235 mobility anchor to send the Update Notification to the mobile 236 access gateway. This field does not contain any structure and 237 MUST be treated as an enumeration. The reason code can indicate 238 vendor specific reason in case the semantics of the Update 239 Notification message get clear from the attached options, not 240 solely from the reason code. These attached options can be 241 deployment specific and are not specified in this document. The 242 following Notification Reason values are currently defined: 244 (0) - Reserved 245 This value is currently reserved and cannot be used 247 (1) - FORCE-REREGISTRATION 248 Request to re-register the session by sending a Proxy Binding 249 Update for the mobility session 251 (2) - UPDATE-SESSION-PARAMETERS 252 Request to apply the updated session parameters obtained from 253 the message on the mobility session 255 (3) - VENDOR-SPECIFIC-REASON 256 The Notification reason is for vendor-specific use. The 257 processing rules are to based on the Vendor-specific mobility 258 option(s) [RFC5094] present in the message 260 (4) - ANI-PARAMS-REQUESTED 261 Request to send currently known ANI [RFC6757] parameters for 262 the mobility session 264 (255) - Reserved 265 This value is currently reserved and cannot be used 267 Acknowledgement Requested Flag ('A' Flag) 268 When this flag is set to a value of (1), it is an indication that 269 the local mobility anchor is requesting the mobile access gateway 270 to send a Update Notification Acknowledgement message. When this 271 flag is set to a value of (0), it is an indication that the local 272 mobility anchor is not requesting any Update Notification 273 Acknowledgement message. 274 Re-Transmitted Request Flag ('D' Flag) 275 When this flag is set to a value of (1), it is an indication that 276 the message is a re-transmitted message and has the same Sequence 277 Number and other message contents as in the previously sent 278 message. The 'D' flag is set for retransmitted request messages, 279 to aid the reliable detection of duplicate requests at the 280 received of the request message. It is set when originating 281 requests that have not yet been acknowledged, as an indication of 282 a possible duplicate due to a retransmission. This flag MUST be 283 cleared when sending a request for the first time for a given 284 Sequence Number; otherwise, the sender MUST set this flag. 285 Reserved 286 This field is unused for now. The value MUST be initialized to 0 287 by the sender and MUST be ignored by the receiver. 288 Mobility Options 289 A variable-length field of such length that the complete Mobility 290 Header is an integer multiple of 8 octets long;Pad1 [RFC6275] and 291 PadN [RFC6275] options can be used for padding. This field 292 contains zero or more TLV-encoded mobility options. Any of the 293 mobility header options including vendor-specific mobility options 294 [RFC5094] can be included here. The receiver MUST ignore and skip 295 any options that it does not understand. These mobility options 296 are used by the mobile access gateway to identify the specific 297 binding for which the Update Notification message is sent. 299 4.2. Update Notification Acknowledgement(UPA) 301 The Update Notification Acknowledgement is a mobility header message 302 that has an MH Type value of . The mobile access gateway 303 sends this message in order to acknowledge that it has received an 304 Update Notification message with the A-flag set and to indicate the 305 status after processing the message. 307 The format of the Update Notification Acknowledgement message is as 308 follows: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sequence # | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Status Code | Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 . . 319 . Mobility options . 320 . . 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 4: Update Notification Acknowledgement Message 326 Sequence Number 327 A 16-bit unsigned integer copied from the Update Notification 328 message. This is used for matching the Update Notification 329 Acknowledgement message with the Update Notification message. 330 Status Code 331 This 8-bit unsigned integer indicates the status code. Specifies 332 the result of the processing of the update notification message. 333 The status codes between 0 and 127 signify successful processing 334 of the Update Notification message and codes between 128 and 255 335 signify that an error occurred during processing of the update 336 notification message. The following Status Code values are 337 currently defined: 339 (0) - SUCCESS 340 The mobile access gateway successfully processed the received 341 Update Notification Message. 343 (128) - FAILED-TO-UPDATE-SESSION-PARAMETERS 344 The mobile access gateway was not able to apply the session 345 parameters sent by the local mobility anchor in the Update 346 Notification Message. 348 (129) - MISSING-VENDOR-SPECIFIC-OPTION 349 The received Update Notification Message does not have the 350 required vendor-specific mobility option(s) needed for handling 351 the message. 353 Reserved 354 This field is unused for now. The value MUST be initialized to 0 355 by the sender and MUST be ignored by the receiver. 356 Mobility Options 357 A variable-length field of such length that the complete Mobility 358 Header is an integer multiple of 8 octets long;Pad1 [RFC6275] and 359 PadN [RFC6275] options can be used for padding. This field 360 contains zero or more TLV-encoded mobility options. Any of the 361 mobility header options including vendor-specific mobility options 362 [RFC5094] can be included here. The receiver MUST ignore and skip 363 any options that it does not understand. These mobility options 364 are used by the mobile access gateway to identify the specific 365 binding for which the Update Notification Acknowledgement message 366 is sent. 368 5. LMA Considerations 370 o The local mobility anchor sends the Update Notification message in 371 response to a condition that is specified in the Notification 372 Reason field. The Notification Reason field in the Update 373 Notification message MUST be set to a specific value that 374 identifies the reason for which the Update Notification message is 375 being sent. The Notification Reason based on the chosen value, 376 may require a specific Action that the mobile access gateway needs 377 to perform (Ex: Requiring Re-registration of a mobility session). 378 o The Update Notification message MUST include either the Mobile 379 Node Identifier option [RFC4283], or the Mobile Node Group 380 Identifier Option [RFC6602]. 381 * If the Mobile Node Identifier option is present, it indicates 382 that the Update Notification message is sent for that specific 383 mobility session. 384 * If the Mobile Node Group Identifier option is present, it 385 indicates that the Update Notification message is sent for the 386 set of mobility sessions identified by the Group Identifier. 387 The Group Identifier is negotiated as part of the initial 388 PMIPv6 signaling. If the Group Identifier is not negotiated in 389 the initial Proxy Mobile IPv6 signaling, a value of (1) for the 390 Group Identifier can always be used. The Group Identifier 391 value of (1) identifies the all the mobility sessions 392 established between that local mobility anchor and the mobile 393 access gateway. 394 o The Update Notification message MAY contain a modified session 395 parameters in the form of a mobility options (e.g.,: IPv4 Traffic 396 Offload option, or a QoS option), so the mobile access gateway can 397 apply them on the identified mobility session. 399 5.1. Constructing the Update Notification Message 401 The local mobility anchor when sending the Update Notification 402 message to the mobile access gateway has to construct the message as 403 specified below: 405 o For requesting an Acknowledgement message and an indication about 406 the result of processing the message from the mobile access 407 gateway for the Update Notification message, the "A" flag in the 408 Update Notification message MUST be set to a value of (1), 409 otherwise it MUST be set to a value of (0). However, if the 410 Notification Reason is set to a value of (1) "FORCE- 411 REREGISTRATION", or (4) "ANI-PARAMS-REQUESTED", then it is 412 RECOMMENDED to have the "A" flag set to a value of (0). For 413 certain general notifications of informational in nature, the 414 local mobility anchor may choose not request Acknowledgement for 415 the Update Notification message. 416 o The Sequence Number field of the message MUST be initialized to a 417 random number and increased monotonically for subsequent messages. 418 Once the sequence number hits the maximum value, it should be 419 wrapped around to 0. Furthermore, if the message is a re- 420 transmission of a previously sent message, then the sequence 421 number value is not changed. 422 o When using IPv4 transport, the source address in the IPv4 header 423 MUST be set to local mobility anchor's IPv4 address (IPv4-LMAA) 424 and the destination address in the IPv4 header MUST be set to 425 IPv4-Proxy-CoA of the mobile access gateway. The Mobility Header 426 (without the IPv6 header) containing the Update Notification 427 message is encapsulated in UDP header with the destination port of 428 5436 [RFC5844]. If IPsec ESP is used to protect signaling, the 429 packet is processed using transport mode ESP. 430 o The format of the Update Notification message sent over IPv4 and 431 protected using ESP is shown below: 433 IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA) 434 ESP header (in transport mode) 435 UDP header (sport=5436, dport=5436) 436 Mobility Header (Update Notification) 437 (One or more Mobile Header Options) 439 o When using IPv6 transport, the source address in the IPv6 header 440 MUST be set to local mobility anchor's IPv6 address (LMAA). The 441 destination address in the IPv6 header MUST be set to Proxy-CoA of 442 the mobile access gateway. The Mobility Header is part of the 443 IPv6 headers. 445 o The format of the Update Notification message sent over IPv6 and 446 protected using ESP is shown below: 448 IPv6 header (src=Proxy-CoA, dst=LMAA) 449 Mobility Header (Update Notification) 450 ESP header (in transport mode) 451 (One or more Mobile Header Options) 453 5.2. Receiving the Update Notification Acknowledgement Message 455 o If the local mobility anchor does not receive an Update 456 Notification Acknowledgement message from the mobile access 457 gateway for the Update Notification message with the A-flag set, 458 then the local mobility anchor MUST retransmit the message. 459 Following are the related considerations: 460 * When retransmitting an Update Notification message, the 461 sequence number value and other message contents MUST be the 462 same as in the original message. The "D" flag in the message 463 MUST be set to a value of (1). 464 * There MUST be a minimum delay of, 465 MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY (Section 7), with 466 a default value of 1000 milli-seconds, between two retransmit 467 messages. 468 * The message MUST be retransmitted up to number of times defined 469 by the configuration variable, 470 MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT (Section 7), with a 471 default value of (1). If there is no Update Notification 472 Acknowledgement message after retransmission count reaches the 473 value defined by the configuration variable, 474 MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT, then the message MUST 475 be discarded and the event SHOULD be logged. 476 o If the local mobility anchor receives a Binding Error message with 477 the Status field set to 2 as described in [RFC6275], then it is an 478 indication that the mobile access gateway does not support the 479 Update Notification Mobility Header message and hence the local 480 mobility anchor MUST NOT send any further Update Notification 481 messages to that mobile access gateway unless an administrative 482 action is taken. 483 o When receiving a Update Notification Acknowledgement message, the 484 local mobility anchor MUST verify the Mobility Header as described 485 in Section 9.2. of [RFC6275]. If the packet is dropped due to 486 failing of any of the Mobility Header test checks, the local 487 mobility anchor MUST follow the processing rules as in Section 9.2 488 of [RFC6275]. 490 o Upon receiving the Update Notification Acknowledgement message, 491 the local mobility anchor MUST verify that the received message is 492 protected by the security association that is being used to 493 protect the other signaling messages between those two peers. For 494 example, if the Proxy Binding Update and Proxy Binding 495 Acknowledgement messages are protected using IPsec Security 496 Association, then the Update Notification Acknowledgement message 497 MUST have the IPsec protection with the currently established 498 IPsec security association that is being used for protecting the 499 other Proxy Mobile IPv6 signaling messages. 500 o If the local mobility anchor receives an Update Notification 501 Acknowledgement message with a failure Status and the value of 128 502 or greater, then it SHOULD log an error. 503 o If the sequence number in the received Update Notification 504 Acknowledgement message does not match any of the Update 505 Notification messages that the local mobility anchor sent, then 506 the message MUST be discarded and the message should be logged. 507 o If the local mobility anchor receives an Update Notification 508 Acknowledgement message from the mobile access gateway for the 509 Update Notification message, which did not have the A-flag set, 510 the local mobility anchor MUST process the received message in the 511 same way as a requested acknowledgement. 513 6. MAG Considerations 515 6.1. Receiving the Update Notification Message 517 o When receiving a Update Notification message, the mobile access 518 gateway MUST verify the Mobility Header as described in Section 519 9.2. of [RFC6275]. If the packet is dropped due to failing of any 520 of the Mobility Header test checks, the mobile access gateway MUST 521 follow the processing rules as in Section 9.2 of [RFC6275]. 522 o Upon receiving the Update Notification message, the mobile access 523 gateway MUST verify that the received packet is protected by the 524 security association that is being used to protect the other 525 signaling messages between those two peers. For example, if the 526 Proxy Binding Update and Proxy Binding Acknowledgement messages 527 are protected using IPsec Security Association, then the Update 528 Notification message MUST have the IPsec protection with the 529 currently established IPsec security association that is being 530 used for protecting the other Proxy Mobile IPv6 signaling 531 messages. 532 o If the received Update Notification message is a re-transmission 533 of a previously received message, identified by the Sequence 534 Number, then the mobile access gateway MUST NOT handle the message 535 as a new request. The 'D' flag is used as an indication of a 536 retransmitted request, e.g., due to lost messages or the local 537 mobility anchor not seeing the requested update actions. If the 538 mobile access gateway has not seen the (potentially lost) initial 539 request message, it MUST treat the received Update Notification 540 message (with the 'D' flag set) as receiving the initial request 541 and continue processing based on that. If the mobile access 542 gateway detects that the request is a retransmission based on the 543 'D' flag and the Sequence Number, then it SHOULD redo the 544 requested update action e.g., when the acknowledgement 'A' flag is 545 not set. The mobile access gateway MUST always respond to the 546 retransmitted request if the 'A' flag is set. 547 o Upon accepting the Update Notification message, the mobile access 548 gateway MUST process the message and perform the actions based on 549 the Notification Reason. 550 * If the (A) flag in the message is set to a value of (1), the 551 mobile access gateway MUST send an Update Notification 552 Acknowledgement message with the status code field set based on 553 the result of processing the Update Notification message. 554 * If the Notification Reason is set to a value of (1) "FORCE- 555 REREGISTRATION", then the mobile access gateway MUST send a 556 Proxy Binding Update message to the local mobility anchor and 557 obtain the updated session parameters for that mobility 558 session. 559 * If the Notification Reason is set to a value of (2) "UPDATE- 560 SESSION-PARAMETERS", then the mobile access gateway MUST apply 561 the session parameters that are obtained from the Update 562 Notification message in the form of mobility options. However, 563 if the mobile access gateway is unable to apply the notified 564 session parameters, then the mobile access gateway MUST apply 565 the following considerations. 566 + If the received Update Notification message has the (A) flag 567 in the message set to a value of (0), then the mobile access 568 gateway MUST drop the received Update Notification message 569 and log the error. 570 + If the received Update Notification message has the (A) flag 571 in the message set to a value of (1), then the mobile access 572 gateway MUST send an Update Notification Acknowledgement 573 message with the Status Code value of 128 (FAILED-TO-UPDATE- 574 SESSION-PARAMETERS). 575 * If the Notification Reason is set to a value of (3) "VENDOR- 576 SPECIFIC-REASON", then the mobile access gateway MUST apply the 577 considerations related to handling of the Vendor-specific 578 option [RFC5094] that is carried in the Update Notification 579 message. However, if there is no Vendor-specific option 580 present in the message, the mobile access gateway MUST apply 581 the following considerations. 582 + If the received Update Notification message has the (A) flag 583 in the message set to a value of (0), then the mobile access 584 gateway MUST drop the received Update Notification message 585 and log the error. 586 + If the received Update Notification message has the (A) flag 587 in the message set to a value of (1), then the mobile access 588 gateway MUST send an Update Notification Acknowledgement 589 message with the Status Code value of 129 (MISSING-VENDOR- 590 SPECIFIC-OPTION). 591 * If the Notification Reason is set to a value of (4) "ANI- 592 PARAMS-REQUESTED", then the mobile access gateway MUST send a 593 Proxy Binding Update message to the local mobility anchor with 594 the Access Network Identifier Option [RFC6757]. The Access 595 Network Identifier option MUST reflect the current access 596 network parameters for that mobility session as known to the 597 mobile access gateway at the time of sending the Proxy Binding 598 Update message. 599 * For other Notification Reasons that are not reserved by this 600 document, the processing required on the mobile access gateway 601 is out of the scope for this document and will be specified for 602 each Notification reason in the respective document. 604 6.2. Constructing the Update Notification Acknowledgement Message 606 The mobile access gateway when sending the Update Notification 607 Acknowledgement message to the local mobility anchor has to construct 608 the message as specified below: 610 o The Sequence Number MUST be the same as the sequence Number from 611 the received Update Notification message. 612 o The status field of the Update Notification message MUST be set to 613 a value that reflects the status of the processing of the Update 614 Notification request. The value of 0 (success), indicates that 615 the handling of the Update Notification message was successful. 616 o The Update Notification Acknowledgement message MUST contain 617 either the Mobile Node Identifier option, or the Mobile Node Group 618 Identifier option, copied from the Update Notification message. 619 Furthermore, the mobile access gateway MAY include other mobility 620 header options. 621 o The source address in the IP header of the Update Notification 622 Acknowledgement message MUST be set to the destination IP address 623 of the received Update Notification message. 624 o The destination address in the IP header MUST be set to the source 625 address of the received Update Notification message. 626 o If IPsec ESP is used to protect signaling, the packet is processed 627 using transport mode ESP. 628 o The format of the Update Notification Acknowledgement message sent 629 over IPv4 and protected using ESP is shown below: 631 IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA) 632 ESP header (in transport mode) 633 UDP header (sport=5436, dport=5436) 634 Mobility Header (Update Notification Acknowledgement) 635 (One or more Mobile Header Options) 637 o The format of the Update Notification Acknowledgement message sent 638 over IPv6 and protected using ESP is shown below: 640 IPv6 header (src=LMAA, dst=Proxy-CoA ) 641 Mobility Header (Update Notification Acknowledgement) 642 ESP header (in transport mode) 643 (One or more Mobile Header Options) 645 7. Protocol Configuration Variables 647 This specification defines the following configuration variables that 648 controls the Update Notification feature. 650 The mobility entities, local mobility anchor, and the mobile access 651 gateway have to allow these variables to be configured by the system 652 management. The configured values for these protocol variables have 653 to survive server reboots and service restarts. 655 MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT 657 This variable specifies the maximum number of times a local 658 mobility anchor can retransmit a Update Notification message 659 before it receives an Update Notification Acknowledgement message. 660 The default value for this parameter is 1. The suggested range 661 for this variable is to keep the configured value between 0 and 5. 663 MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY 665 This variable specifies the minimum delay in seconds before an 666 Update Notification message is retransmitted. The default value 667 for this parameter is 1000 milli-seconds. The suggested range for 668 this varaible is to keep the configured value between 500 and 5000 669 milli-seconds. 671 8. Security Considerations 673 The Update Notification protocol described in this specification is 674 for use between local mobility anchor and mobile access gateway. 675 This specification defines two new mobility header messages, Update 676 Notification and the Update Notification Acknowledgement messages. 677 These mobility header messages are to be protected using the same 678 security mechanism that is used for protecting the Proxy Mobile IPv6 679 signaling messages exchanged between a given local mobility anchor 680 and mobile access gateway. 682 If IPsec is used, the IPsec security association that is used for 683 protecting the Proxy Binding Update and Proxy Binding 684 Acknowledgement, also needs to be used for protecting Update 685 Notification and the Update Notification Acknowledgement messages. A 686 Proxy Mobile IPv6 implementation and the IPsec layer are typically 687 able to communicate with each other through an implementation 688 specific interface, for example, to exchange configuration and 689 notification information. 691 The traffic selectors associated with the Security Policy Database 692 (SPD) entry for protecting Proxy Binding Update and Proxy Binding 693 Acknowledgement messages (section 4.2, [RFC5213]) have to be extended 694 to include the mobility header type values, and , 695 allocated for Update Notification and Update Notification 696 Acknowledgement messages. Furthermore, any time there is rekeying of 697 the IPsec security association between the mobile access gateway and 698 the local mobility anchor, the newly established IPsec security 699 association will be used for protecting the Update Notification and 700 the Update Notification Acknowledgement messages. 702 9. Acknowledgements 704 The authors would like to thank Basavaraj Patil, Rajeev Koodli, 705 Lionel Morand, Itsuma Tanaka, Rajesh Pazhyannur, Carlos Jesus 706 Bernardos Cano, John Kaippallimalil, Brian Haberman and other members 707 of the NETEXT working group for all the comments and discussions on 708 the draft. 710 The authors would like to thank Barry Leiba, Robert Sparks, Carlos 711 Pignataro, Benoit Claise, Stephen Farrell and Jari Arkko for their 712 inputs to the document as part of the IESG review proccess. 714 10. IANA Considerations 716 This document requires the following IANA actions. 718 o Action-1: This specification defines a new Mobility Header Type 719 message, Update Notification. This mobility header message is 720 described in Section 4.1. The type value for this 721 message needs to be allocated from the Mobility Header Types 722 registry at http://www.iana.org/assignments/mobility-parameters. 723 RFC Editor: Please replace in Section 4.1 and Section 8 724 with the assigned value, and update this section accordingly. 725 o Action-2: This specification defines a new Mobility Header Type 726 message, Update Notification Acknowledgement. This mobility 727 header message is described in Section 4.2. The type value 728 for this message needs to be allocated from the Mobility 729 Header Types registry at 730 http://www.iana.org/assignments/mobility-parameters. RFC Editor: 731 Please replace in Section 4.2 and Section 8 with the 732 assigned value, and update this section accordingly. 733 o Action-3: This specification defines a new registry for 734 Notification Reasons. It is called, "Update Notification Reasons 735 Registry". This registry should be created under "Mobile IPv6 736 Parameters" registry at 737 http://www.iana.org/assignments/mobility-parameters. The 738 Notification Reason is a field in the Update Notification message 739 Section 4.1. The number space for the Notification Reason field 740 needs to be managed by IANA, under the Registry, Update 741 Notification Reason Registry. This specification reserves the 742 following type values. The allocation policy for this field is, 743 "specification required". 745 +=====+===========================+=======================+ 746 |Value| Description | Reference | 747 +=====+===========================+=======================+ 748 | 0 | Reserved | | 749 +=====+===================================================+ 750 | 1 | FORCE-REREGISTRATION | | 751 +=====+===================================================+ 752 | 2 | UPDATE-SESSION-PARAMETERS | | 753 +=====+===================================================+ 754 | 3 | VENDOR-SPECIFIC-REASON | | 755 +=====+===================================================+ 756 | 4 | ANI-PARAMS-REQUESTED | | 757 +=====+===================================================+ 758 |255 | Reserved | | 759 +=====+===================================================+ 760 o Action-4: This specification defines a new registry for Status. 761 It is called, "Update Notification Acknowledgement Status 762 Registry". This registry should be created under "Mobile IPv6 763 Parameters" registry at 764 http://www.iana.org/assignments/mobility-parameters. The status 765 is a field in the Update Notification Acknowledgement message 766 Section 4.2. The number space for the status field needs to be 767 managed by IANA, under the Registry, Update Notification Status 768 Registry. This specification reserves the following type values. 769 The allocation policy for this field is, "specification required". 770 The status codes between 0 and 127 signify successful processing 771 of the Update Notification message and codes between 128 and 255 772 signify that an error occurred during processing of the Update 773 Notification message. 775 +=====+=====================================+=============+ 776 |Value| Description | Reference | 777 +=====+=====================================+=============+ 778 | 0 | SUCCESS | | 779 +=====+=====================================+=============+ 780 |128 | FAILED-TO-UPDATE-SESSION-PARAMETERS | | 781 +=====+=====================================+=============+ 782 |129 | MISSING-VENDOR-SPECIFIC-OPTION | | 783 +=====+=====================================+=============+ 785 11. References 787 11.1. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 793 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 794 (MIPv6)", RFC 4283, November 2005. 796 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 797 Vendor Specific Option", RFC 5094, December 2007. 799 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 800 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 802 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 803 Mobile IPv6", RFC 5844, May 2010. 805 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 806 in IPv6", RFC 6275, July 2011. 808 [RFC6602] Abinader, F., Gundavelli, S., Leung, K., Krishnan, S., and 809 D. Premec, "Bulk Binding Update Support for Proxy Mobile 810 IPv6", RFC 6602, May 2012. 812 11.2. Informative References 814 [I-D.ietf-netext-pmip6-qos] 815 Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. 816 Gundavelli, "Quality of Service Option for Proxy Mobile 817 IPv6", draft-ietf-netext-pmip6-qos-03 (work in progress), 818 July 2013. 820 [I-D.ietf-netext-pmipv6-flowmob] 821 Bernardos, C., "Proxy Mobile IPv6 Extensions to Support 822 Flow Mobility", draft-ietf-netext-pmipv6-flowmob-07 (work 823 in progress), August 2013. 825 [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., 826 and P. Yegani, "Binding Revocation for IPv6 Mobility", 827 RFC 5846, June 2010. 829 [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, 830 S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile 831 IPv6", RFC 5847, June 2010. 833 [RFC6757] Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and 834 R. Pazhyannur, "Access Network Identifier (ANI) Option for 835 Proxy Mobile IPv6", RFC 6757, October 2012. 837 [RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. 838 Koodli, "IPv4 Traffic Offload Selector Option for Proxy 839 Mobile IPv6", RFC 6909, April 2013. 841 Authors' Addresses 843 Suresh Krishnan 844 Ericsson 845 8400 Blvd Decarie 846 Town of Mount Royal, Quebec 847 Canada 849 Phone: +1 514 345 7900 x42871 850 Email: suresh.krishnan@ericsson.com 851 Sri Gundavelli 852 Cisco 853 170 West Tasman Drive 854 San Jose, CA 95134 855 USA 857 Email: sgundave@cisco.com 859 Marco Liebsch 860 NEC 861 Kurfuersten-Anlage 36 862 D-69115 Heidelberg 863 Germany 865 Email: marco.liebsch@neclab.eu 867 Hidetoshi Yokota 868 KDDI 870 Email: yokota@kddilabs.jp 872 Jouni Korhonen 873 Renesas Mobile 874 Porkkalankatu 24 875 Helsinki FIN-00180 876 Finland 878 Email: jouni.nospam@gmail.com