idnits 2.17.1 draft-ietf-mip4-generic-notification-message-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 840. 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 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (June 2007) is 6161 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) == Unused Reference: 'RFC4917' is defined on line 756, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Levkowetz 5 Expires: December 3, 2007 Ericsson Research 6 V. Devarapalli 7 Azaire Networks 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 June 2007 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 3, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document specifies protocol enhancements that allow Mobile IPv4 49 entities to send and receive explicit notification messages using a 50 new Mobile IPv4 message type designed for this purpose. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Notification message - Usage Scenario's . . . . . . . . . . . 5 57 3.1. Notification message from a Home Agent to a Mobile Node . 5 58 3.1.1. Mobile Registered using a Foreign Agent Care-of 59 Address . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.2. Mobile Registered using a Collocated Care-of 61 Address . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Notification message from a Foreign Agent to a Mobile 63 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Notification message from a Home Agent to a Foreign 65 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Generic Notification Message and Considerations . . . . . . . 7 67 4.1. Generic Notification Message . . . . . . . . . . . . . . . 7 68 4.2. Generic Notification Acknowledgment Message . . . . . . . 9 69 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 11 70 4.3.1. Receiving Generic Notification Messages . . . . . . . 11 71 4.3.2. Sending Generic Notification Acknowledgement 72 Message . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 13 74 4.4.1. Receiving Generic Notification Message . . . . . . . . 13 75 4.4.2. Sending Generic Notification Acknowledgement 76 Messages . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.4.3. Sending Generic Notification Messages . . . . . . . . 14 78 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 15 79 4.5.1. Sending Generic Notification Messages . . . . . . . . 15 80 4.5.2. Receiving Generic Notification Acknowledgement 81 Messages . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.5.3. Receiving Generic Notification Messages . . . . . . . 16 83 4.5.4. Sending Generic Notification Acknowledgement 84 Messages . . . . . . . . . . . . . . . . . . . . . . . 17 85 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 18 86 5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 18 87 5.2. Generic String Extension . . . . . . . . . . . . . . . . . 18 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 8. Normative References . . . . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 92 Intellectual Property and Copyright Statements . . . . . . . . . . 23 94 1. Introduction 96 In some situations, there is a need for Mobile IPv4 entities, such as 97 the home agent, foreign agent and mobile node to send and receive 98 asynchronous notification messages during a mobility session. The 99 base Mobile IP Specification [RFC3344] does not have a provision for 100 this. 102 This document defines a generic message and a notification model that 103 can be used by Mobile IPv4 entities to send various notifications. 104 However, this specification does not define any specific notification 105 message or the actions that the receiving entity is required to 106 perform on receiving that message. Specific extensions and the 107 corresponding handler actions are outside the scope of this document. 109 2. Terminology 111 It is assumed that the reader is familiar with the terminology used 112 in [RFC3543], [RFC3344]. In addition, the following terms are 113 defined: 115 Notification Message 117 A message from a mobility agent to a mobile node or other mobility 118 agent to asynchronously notify it about an event that is relevant 119 to the mobility service it is currently providing. 121 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, [RFC2119]. 125 3. Notification message - Usage Scenario's 127 There are several scenarios where a mobility agent could initiate 128 notification events. Some of these are described in the following 129 sections. 131 3.1. Notification message from a Home Agent to a Mobile Node 133 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 135 In this case, the home agent cannot directly notify the mobile node, 136 but must send the notification via the foreign agent. 138 +----+ notification +----+ notification +----+ 139 | MN |<================| FA |<=============| HA | 140 +----+ +----+ +----+ 142 Figure 1: Home Agent notifies Mobile Node through Foreign Agent 144 3.1.2. Mobile Registered using a Collocated Care-of Address 146 In this case, the mobile node has registered with the home agent 147 directly, so the notification message can go directly to the mobile 148 node. 150 The notification mechanism as specified here does not support the 151 case of Co-located CoA mode with registration through a foreign agent 152 (due to the 'R' bit being set in the foreign agent's advertisement 153 messages). 155 +----+ notification +----+ 156 | MN |<===================================| HA | 157 +----+ +----+ 159 Figure 2: Home Agent directly notifies Mobile Node 161 3.2. Notification message from a Foreign Agent to a Mobile Node 163 There are two cases where a foreign agent may send notification 164 messages to a mobile node, one where it is relaying a message, the 165 other where the notification is triggered by a message from another 166 network entity, for example a AAA node(notification messages between 167 a AAA entity and the foreign agent could be based on RADIUS or 168 Diameter, but this is out of scope for this document). If the 169 notification is initiated by a foreign agent, the foreign agent may 170 need to also notify the home agent about the event. 172 +----+ notification +----+ notification +--------+ 173 | MN |<================| FA |<=============| AAA/HA | 174 +----+ +----+ +--------+ 175 || notification +----+ 176 ================>| HA | 177 +----+ 179 Figure 3: Foreign Agent notifies Mobile Node 181 3.3. Notification message from a Home Agent to a Foreign Agent 183 The home agent may also need to send a notification to the foreign 184 agent, but not to the mobile node, as illustrated below: 186 +----+ notification +----+ 187 | FA |<=============| HA | 188 +----+ +----+ 190 Figure 4: Home Agent notifies Foreign Agent 192 4. Generic Notification Message and Considerations 194 This section describes in detail the generic notification message, 195 generic notification acknowledgement message, and some considerations 196 related to the handling of these messages in the mobile node, foreign 197 agent and home agent. 199 4.1. Generic Notification Message 201 A generic notification message is sent by a mobility agent to inform 202 another mobility agent, or a mobile node, of MIP-related information. 203 These messages must use the same IP and UDP headers as any previous 204 Registration Request or Reply message to the same entity. The 205 generic notification message is defined as follows: 207 IP Fields: 209 Source Address Sender's address. 211 Destination Address Receiver's address. 213 UDP Fields: 215 Source Port variable. 217 Destination Port Same as the last Registration Reply/Request 218 message. 220 The UDP header is followed by the Mobile IP fields shown below: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Type | Subtype | MD |A| Reserved | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Home Address | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Home Agent Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Care-of Address | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | | 234 + Identification + 235 | | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Extensions... 238 +-+-+-+-+-+-+-+-+-+-+-+-+- 240 Type (TBD) 242 Subtype 244 This field describes the particular type of notification which is 245 carried in the notification message. 247 MD: Message Direction 249 This memo defines the semantics of the following MD field value: 251 0 -- Message sent by the home agent to the mobile node 253 1 -- Message sent by the home agent to the foreign agent 255 2 -- Message sent by the mobile node to the home agent 257 3 -- Message sent by the mobile node to the foreign agent 259 4 -- Message sent by the foreign agent to the mobile node 261 5 -- Message sent by the foreing agent to the home agent 263 A 265 This bit indicates whether the notification message MUST be 266 acknowledged by the recipient. 268 Set to "1" to indicate that acknowledgement is required. 270 Set to "0" to indicate that acknowledgement is optional. 272 Reserved 274 MUST be sent as 0, and ignored when received. 276 Home Address 278 The home IP address of the mobile node. 280 Home Agent Address 282 The IP address of the mobile node's home agent. 284 Care-of Address 286 The mobile node's care-of address, either the co-located care-of 287 address or the foreign agent care-of address. 289 Identification 291 A 64-bit number, constructed by the sender, used for matching 292 Generic Notification with Generic Notification Acknowledgement, 293 and for protecting against replay attacks of notification 294 messages. See Sections 5.4 and 5.7 of [RFC3344]. 296 Extensions 298 The fixed portion of the Generic Notification Message is followed 299 by one or more extensions which may be used with this message, and 300 by one or more authentication extensions (as defined in Section 301 3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] 302 for information on the relative order in which different 303 extensions, when present, must be placed in a Generic Notification 304 Message. 306 4.2. Generic Notification Acknowledgment Message 308 A generic notification acknowledgement message is sent by mobility 309 agents or mobile nodes to indicate the successful receipt of a 310 generic notification message. 312 IP Fields: 314 Source Address Typically copied from the destination 315 address of the Generic Notification to which 316 the agent is replying. 318 Destination Address Copied from the source address of the 319 Generic Notification to which the agent is 320 replying. 322 UDP Fields: 324 Source Port variable. 326 Destination Port Copied from the source port of the 327 corresponding Generic Notification. 329 The UDP header is followed by the Mobile IP fields shown below: 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Type | Subtype | MD | Reserved | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Home Address | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Home Agent Address | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Care-of Address | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 + Identification + 344 | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Extensions... 347 +-+-+-+-+-+-+-+-+-+-+-+-+- 349 Type (TBD) 351 Subtype 353 This field specifies the particular type of notification 354 acknowledgement message. 356 MD: Message Direction 358 This memo defines the semantics of the following MD field value: 360 0 -- Message sent by the home agent to the mobile node 362 1 -- Message sent by the home agent to the foreign agent 364 2 -- Message sent by the mobile node to the home agent 366 3 -- Message sent by the mobile node to the foreign agent 368 4 -- Message sent by the foreign agent to the mobile node 370 5 -- Message sent by the foreing agent to the home agent 372 Reserved 374 MUST be sent as 0, and ignored when received. 376 Home Address 377 The home IP address of the mobile node. 379 Home Agent Address 381 The IP address of the sender's home agent. 383 Care-of Address 385 The mobile node's care-of address, either the co-located care-of 386 address or the foreign agent care-of address. 388 Identification 390 A 64-bit number used for matching Generic Notification with 391 Generic Notification Acknowledgement, and for protecting against 392 replay attacks of generic notification messages. The value is 393 based on the Identification field from the Generic Notification 394 message from the sender, and on the style of replay protection 395 used in the security context between the receiver and sender 396 (defined by the mobility security association between them, and 397 SPI value in the authorization-enabling extension). See Sections 398 5.4 and 5.7 of [RFC3344]. 400 Extensions 402 The fixed portion of the generic notification acknowledgement 403 message is followed by one or more of the Extensions listed in 404 Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of 405 [RFC3344] for information on the relative order in which different 406 extensions, when present, MUST be placed in a Generic Notification 407 message. 409 4.3. Mobile Node Consideration 411 It is possible that the mobile node MAY receive a generic 412 notification message from a foreign agent or home agent. Both in the 413 case of FA-CoA and Co-located CoA, the mobile node MAY reply with a 414 Generic Notification Acknowledgement message based on the "A" flag in 415 the notification message. 417 4.3.1. Receiving Generic Notification Messages 419 When the mobile node is using FA-CoA and receives a Notification 420 message, if the "MD" value is 0, it means that the notification 421 message came from the home agent. If the "MD" value is 4, the 422 notification came from the foreign agent. 424 If this notification message came from a foreign agent and the mobile 425 node accepts the foreign agent's generic notification message, it 426 will process the notification extension according to the specific 427 rules for that extension. After that, the mobile node MAY reply with 428 a Generic Notification Acknowledgement message back to the foreign 429 agent. If the "A" flag is set in the notification message, then the 430 mobile node MUST send the acknowledgement. 432 If this notification message came from the home agent, relayed by the 433 foreign agent, or is a Co-located CoA, the Mobile-Home Authentication 434 extension MUST be checked and the mobile node MUST check the 435 Authenticator value in the Extension. If no Mobile-Home 436 Authentication Extension is found, or if more than one Mobile-Home 437 Authentication Extension is found, or if the Authenticator is 438 invalid, the mobile node MUST silently discard the Notification 439 message. If the mobile node accepts the home agent's generic 440 notification message, it will process it according to the specific 441 rules for that extension. After that, the mobile node MAY reply with 442 a Generic Notification Acknowledgement message back to the home agent 443 based on the "A" flag in the notification message. 445 4.3.2. Sending Generic Notification Acknowledgement Message 447 Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY 448 reply with a Generic Notification Acknowledgement Message based on 449 the "A" flag in the notification message as follows: 451 In the case of FA-CoA, The source address is the mobile node's 452 address, the destination address is the foreign agent address. 454 If the notification message was initiated from the foreign agent to 455 the mobile node ("MD" value is set to 4), the ordering of the 456 extension is: any non-authentication Extensions used only by the 457 foreign agent, followed by The Mobile-Foreign Authentication 458 extension defined in section 3.5.3 of [RFC3344]. 460 If the notification message was initiated from the home agent to the 461 mobile node ("MD" value is set to 1), the ordering of the extension 462 is: any non-authentication Extensions used only by the foreign agent, 463 followed by The Mobile-Foreign Authentication extension defined in 464 section 3.5.3 of [RFC3344], followed by any non-authentication 465 Extensions used only by the home agent, followed by the Mobile-Home 466 Authentication extension defined in section 3.5.2 of [RFC3344] 468 In the case of a FA-CoA, the source address is the mobile node's CoA 469 address and the destination address is the home agent's address ("MD" 470 value is set to 2), the ordering of the extension is: any non- 471 authentication Extensions used only by the home agent, followed by 472 the Mobile-Home Authentication Extension defined in section 3.5.2. of 474 [RFC3344]. 476 4.4. Foreign Agent Consideration 478 The foreign agent cannot only relay generic notification message from 479 the home agent and mobile node, but it can also initiate a generic 480 notification message to the mobile node or home agent, but only when 481 there is a binding for the mobile node. 483 4.4.1. Receiving Generic Notification Message 485 If the foreign agent receives a notification message, and the "MD" 486 value is set to 0, it means that the home agent is asking the foreign 487 agent to relay the message to the mobile node. Otherwise, it means 488 that the target of the notification is the foreign agent. 490 If the "MD" value is set to 1, the Foreign-Home Authentication 491 extension MUST be checked, and the foreign agent MUST check the 492 Authenticator value in the Extension. If no Foreign-Home 493 Authentication Extension is found, or if more than one Foreign-Home 494 Authentication Extension is found, or if the Authenticator is 495 invalid, the foreign agent MUST silently discard the Notification 496 message. If foreign agent accepts the home agent's generic 497 notification message, it will process it based on the specific rules 498 for that extension. The foreign agent MAY then reply with a Generic 499 Notification Acknowledgement message back to the home agent based on 500 the "A" flag in the notification message. 502 If the "MD" value is set to 0, the Foreign-Home Authentication 503 extension MUST be checked, and the foreign agent MUST check the 504 Authenticator value in the Extension. If no Foreign-Home 505 Authentication Extension is found, or if more than one Foreign-Home 506 Authentication Extension is found, or if the Authenticator is 507 invalid, the foreign agent MUST silently discard the Notification 508 message. If foreign agent accepts the home agent's generic 509 notification message, it MUST relay the Generic Notification to the 510 mobile node's home address as specified in the Home Address field of 511 the Generic Notification. The foreign agent MUST NOT modify any of 512 the fields beginning with the fixed portion of the Generic 513 Notification message through and including the Mobile-Home 514 Authentication Extension or other authentication extension supplied 515 by the home agent as an authorization-enabling extension for the 516 mobile node. Furthermore, the foreign agent MUST process and remove 517 any Extensions following the Mobile-Home Authentication Extension and 518 MAY append any of its own non-authentication Extensions of relevance 519 to the mobile node, if applicable, and MUST append the Mobile-Foreign 520 Authentication Extension, if the foreign agent shares a mobility 521 security association with the Mobile Node. 523 4.4.2. Sending Generic Notification Acknowledgement Messages 525 The foreign agent may need to either relay a Generic Notification 526 Acknowledgemnt message between the mobile node and the home agent or 527 send one as a response to a notification messsage that was sent to 528 it. In both cases, the Generic Notification Acknowledgement Message 529 is defined as follows: 531 The source address is the foreign agent address, the destination 532 address is home agent address. 534 If the foreign agent is only relaying this message to the home agent, 535 the foreign agent it MUST NOT modify any of the fields beginning with 536 the fixed portion of the Generic Notification Acknowledgement through 537 and including the Mobile-Home Authentication Extension or other 538 authentication extension supplied by the home agent as an 539 authorization-enabling extension for the mobile node. Furthermore, 540 the foreign agent MUST process and remove any Extensions following 541 the Mobile-Home Authentication Extension and MAY append any of its 542 own non-authentication Extensions of relevance to the home agent, if 543 applicable. It MUST also append the Foreign-Home Authentication 544 Extension, if the foreign agent shares a mobility security 545 association with the home agent. 547 If the notification message is from the home agent to the foreign 548 agent then the "MD" value is set to 1 and the ordering of the 549 extension is: any non-authentication Extensions used only by the home 550 agent, followed by The Foreign-Home Authentication extension defined 551 in section 3.5.4 of [RFC3344]. 553 4.4.3. Sending Generic Notification Messages 555 If the foreign agent is initiating a notification to the mobile node 556 using the generic notification message, it MAY also notify the home 557 agent as well. 559 In the message to the mobile node, the source address is the foreign 560 agent address, the destination address is the mobile node's address, 561 the "MD" value is set to 4, and the ordering of the extension is: the 562 notification extension, followed by any non-authentication Extensions 563 used only by the mobile node, followed by The Mobile-Foreign 564 Authentication extension defined in section 3.5.3 of [RFC3344]. 565 Computing Authentication Extension Value is the same as section 3.5.1 566 of [RFC3344] except the payload is the notification other than 567 registration. 569 In the message to the home agent, the source address is the foreign 570 agent's address, the destination address is the home agent's address 571 (the "MD" value is set to 5), and the ordering of the extension is: 572 notification extension, followed by any non-authentication Extensions 573 used only by the home agent, followed by The Foreign-Home 574 Authentication extension defined in section 3.5.4 of [RFC3344]. 575 Computing Authentication Extension Value is the same as section 3.5.1 576 of [RFC3344] except the payload is the notification other than 577 registration. 579 4.5. Home Agent Consideration 581 The Home agent MAY initiate a generic notification message to both 582 the mobile node and foreign agent, and it also MAY receive a generic 583 notification acknowledgement message from both the foreign agent and 584 mobile node. The home agent also MAY receive a generic notification 585 message from the foreign agent, but only when there is a binding for 586 a mobile node. If the home agent receives a notification message 587 from a foreign agent and there is no corresponding mobile node 588 registration, the home agent should drop the notification message. 590 4.5.1. Sending Generic Notification Messages 592 In the case of FA-CoA, the home agent may either send a notification 593 message to notify the foreign agent, or have the foreign agent relay 594 the notification message to the mobile node if the mobile node needs 595 to the notified. 597 If the message is from the home agent to the foreign agent, the 598 source address is the home agent's address, and the destination 599 address is the foreign agent's address 601 If the foreign agent is working only as a relay agent, the "MD" value 602 is set to 0, and the ordering of the extension is: the notification 603 extension, followed by any non-authentication extension expected to 604 be used by mobile node, followed by Mobile-Home Authentication 605 Extension defined in section 3.5.2. of [RFC3344], followed by any 606 non-authentication Extensions used only by the foreign agent, 607 followed by The Foreign-Home Authentication extension defined in 608 section 3.5.4 of [RFC3344]. Computing Authentication Extension Value 609 is the same as section 3.5.1 of [RFC3344]. 611 If the foreign agent is the target of this notification message, then 612 the "MD" value is set to 1, and the ordering of the extension is: the 613 notification extension, followed by any non-authentication Extensions 614 used only by the foreign agent, followed by The Foreign-Home 615 Authentication extension defined in section 3.5.4 of [RFC3344]. 616 Computing Authentication Extension Value is the same as section 3.5.1 617 of [RFC3344]. 619 4.5.2. Receiving Generic Notification Acknowledgement Messages 621 In the case of a FA-CoA, if the home agent receives this message, and 622 the "MD" value is set to 2, it means that the notification 623 acknowledgement message came from mobile node, otherwise it came from 624 the foreign agent. The Foreign-Home Authentication extension MUST be 625 checked, and the home agent MUST check the Authenticator value in the 626 Extension. If no Foreign-Home Authentication Extension is found, or 627 if more than one Foreign-Home Authentication Extension is found, or 628 if the Authenticator is invalid, the home agent MUST silently discard 629 the Notification Acknowledgement message. 631 If the "MD" value is set to 5, and the home agent accepted this 632 message, the home agent MAY also process it based on the notification 633 event. 635 If the "MD" value is set to 2, and the home agent accepted this 636 message, the Mobile-Home Authentication extension MUST be checked, 637 and the home agent MUST check the Authenticator value in the 638 Extension. If no Mobile-Home Authentication Extension is found, or 639 if more than one Mobile-Home Authentication Extension is found, or if 640 the Authenticator is invalid, the home agent MUST silently discard 641 the Notification Acknowledgement message. If the home agent accepted 642 this message, the home agent MAY also process it based on the 643 notification event. 645 In the case of a Co-located CoA, if the home agent received this 646 message, the Mobile-Home Authentication extension MUST be checked, 647 and the home agent MUST check the Authenticator value in the 648 Extension. If no Mobile-Home Authentication Extension is found, or 649 if more than one Mobile-Home Authentication Extension is found, or if 650 the Authenticator is invalid, the home agent MUST silently discard 651 the Notification Acknowledgement message. 653 4.5.3. Receiving Generic Notification Messages 655 The home agent MAY receive a generic notification message sent from 656 the foreign agent. When the home agent receives this message, the 657 Foreign-Home Authentication extension MUST be checked, and the home 658 agent MUST check the Authenticator value in the Extension. If no 659 Foreign-Home Authentication Extension is found, or if more than one 660 Foreign-Home Authentication Extension is found, or if the 661 Authenticator is invalid, the home agent MUST silently discard the 662 Notification message. If home agent accepts the foreign agent's 663 generic notification message, it will process it based on the 664 notification extension. Furthermore, the home agent MAY reply with a 665 Generic Notification Acknowledgement message back to the foreign 666 agent based on the "A" flag in the notification message. 668 4.5.4. Sending Generic Notification Acknowledgement Messages 670 If the generic notification message came from the foreign agent only, 671 the home agent MAY reply with a generic notification acknowledgement 672 message to the foreign agent based on the "A" flag in the 673 notification message. If the "A" flag is set in the notification 674 message, then the home agent MUST send a Notification Acknowledgement 675 message. The message is as follows: The source address is home 676 agent's address, the destination address is the foreign agent's 677 address, the "MD" value is set to 1. The ordering of the extension 678 is: any non-authentication Extensions used only by the foreign agent, 679 followed by The Foreign-Home Authentication extension defined in 680 section 3.5.4 of [RFC3344]. 682 5. Usage Example 684 There are several applications that could use this generic 685 notification message. for example, during handover between CDMA 2000 686 1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be 687 removed on the foreign agent (PDSN) to avoid over-charging 688 subscribers. Other applications such as registration revocation, 689 home agent switch over, NEMO prefix changes, service or billing 690 related events, load balancing where the home agent wants to move 691 some of the registered mobile nodes to other home agents, service 692 termination due to end of prepaid time, and service interruption due 693 to system maintenance. 695 Here we give a example of using revocation extension and describe 696 some possible event which could use the generic string extension 697 [RFC3344]based on this notification mechanism also. There is also 698 the possibility that this notification message could carry many 699 extensions at once. A new VSE extension could be defined to support 700 this notification message. 702 5.1. Revocation Extension 704 If one agent wants to notify another agent about registration 705 revocation [RFC3543], it could easily be carried by a generic 706 notification message and generic notification acknowledgement by 707 specifying the exact "Subtype" in the two messages. 709 5.2. Generic String Extension 711 In some case, the home agent or foreign agent needs to notify the 712 mobile node about service termination due to the end of prepaid time, 713 or service interruption due to system maintenance. This information 714 could be defined based on a string which is recognized by the mobile 715 node easily. An example would be "Maintenance Stopping", "Prepaid 716 Expire". These string MUST be strictly defined so they could be 717 easily understood by all of the network entities. "Subtype" number 718 would need to be decided by the working group. 720 6. Security Considerations 722 This specification operates in the security constraints and 723 requirements of [RFC3344]. It extends the operations of mobile node, 724 home agent and foreign agent defined in [RFC3344] to notify each 725 other about some events. The Generic Notification message defined in 726 the specification could carry information that modifies the mobility 727 bindings. Therefore the message MUST be integrity protected. Replay 728 protection MUST also be guaranteed. 730 RFC 3344 provides replay protection only for registration requests 731 sent by the mobile node. There is no mechanism for replay protection 732 for messages initiated by a Foreign Agent. The 64-bit Identification 733 field specified in this document for the Generic Notification message 734 is used to provide replay protection for the notification messages 735 initiated by the Foreign Agent. 737 7. IANA Considerations 739 This document describes two new messages, the Generic Notification 740 message, section 4.1 and the Generic Notification Acknowledgement 741 message, section 4.2. These two messages should be allocated from 742 the same address space used by the Registration Request and 743 Registration Reply messages in [RFC3344] 745 8. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, March 1997. 750 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 751 August 2002. 753 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 754 Mobile IPv4", RFC 3543, August 2003. 756 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 757 String Extension", RFC 4917, June 2007. 759 Authors' Addresses 761 Hui Deng 762 China Mobile 763 53A,Xibianmennei Ave., 764 Xuanwu District, 765 Beijing 100053 766 China 768 Email: denghui@chinamobile.com 770 Henrik Levkowetz 771 Ericsson Research 772 Torshamsgatan 23 773 S-164 80, Stockholm 774 SWEDEN 776 Email: henrik@levkowetz.com 778 Vijay Devarapalli 779 Azaire Networks 780 4800 Great America Pkwy 781 Santa Clara, CA 95054 782 USA 784 Email: vijay.devarapalli@azairenet.com 786 Sri Gundavelli 787 Cisco Systems 788 170 W.Tasman Drive 789 San Jose, CA 95134 790 USA 792 Email: sgundave@cisco.com 794 Brian Haley 795 Hewlett-Packard Company 796 110 Spitbrook Road 797 Nashua, NH 03062 798 USA 800 Email: brian.haley@hp.com 802 Full Copyright Statement 804 Copyright (C) The IETF Trust (2007). 806 This document is subject to the rights, licenses and restrictions 807 contained in BCP 78, and except as set forth therein, the authors 808 retain all their rights. 810 This document and the information contained herein are provided on an 811 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 812 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 813 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 814 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 815 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 816 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 818 Intellectual Property 820 The IETF takes no position regarding the validity or scope of any 821 Intellectual Property Rights or other rights that might be claimed to 822 pertain to the implementation or use of the technology described in 823 this document or the extent to which any license under such rights 824 might or might not be available; nor does it represent that it has 825 made any independent effort to identify any such rights. Information 826 on the procedures with respect to rights in RFC documents can be 827 found in BCP 78 and BCP 79. 829 Copies of IPR disclosures made to the IETF Secretariat and any 830 assurances of licenses to be made available, or the result of an 831 attempt made to obtain a general license or permission for the use of 832 such proprietary rights by implementers or users of this 833 specification can be obtained from the IETF on-line IPR repository at 834 http://www.ietf.org/ipr. 836 The IETF invites any interested party to bring to its attention any 837 copyrights, patents or patent applications, or other proprietary 838 rights that may cover technology that may be required to implement 839 this standard. Please address the information to the IETF at 840 ietf-ipr@ietf.org. 842 Acknowledgment 844 Funding for the RFC Editor function is provided by the IETF 845 Administrative Support Activity (IASA).