idnits 2.17.1 draft-ietf-mip4-generic-notification-message-00.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 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 854. 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 (January 2007) is 6304 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: 'MIP4-STRING' is defined on line 767, 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 Hitachi (China) 4 Intended status: Standards Track H. Levkowetz 5 Expires: July 5, 2007 Ericsson Research 6 V. Devarapalli 7 Azaire Networks 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 January 2007 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-00.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 July 5, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Notification message - Usage Scenario's . . . . . . . . . . . 6 57 3.1. Notification message from a home agent to a Mobile Node . 6 58 3.1.1. Mobile Registered using a Foreign Agent Care-of 59 Address . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1.2. Mobile Registered using a Collocated Care-of 61 Address . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.2. Notification message from a Foreign Agent to a Mobile 63 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Notification message from a Home Agent to a Foreign 65 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Generic Notification Message and Considerations . . . . . . . 8 67 4.1. Generic Notification Message . . . . . . . . . . . . . . . 8 68 4.2. Generic Notification Acknowledgment Message . . . . . . . 10 69 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 12 70 4.3.1. Receiving Generic Notification Messages . . . . . . . 13 71 4.3.2. Sending Generic Notification Acknowledgement 72 Message . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 14 74 4.4.1. Receiving Generic Notification Message . . . . . . . . 14 75 4.4.2. Sending Generic Notification Acknowledgement 76 Messages . . . . . . . . . . . . . . . . . . . . . . . 15 77 4.4.3. Sending Generic Notification Messages . . . . . . . . 15 78 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 16 79 4.5.1. Sending Generic Notification Messages . . . . . . . . 16 80 4.5.2. Receiving Generic Notification Acknowledgement 81 Messages . . . . . . . . . . . . . . . . . . . . . . . 17 82 4.5.3. Receiving Generic Notification Messages . . . . . . . 18 83 4.5.4. Sending Generic Notification Acknowledgement 84 Messages . . . . . . . . . . . . . . . . . . . . . . . 18 85 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 19 86 5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 19 87 5.2. Generic String Extension . . . . . . . . . . . . . . . . . 19 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 92 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 Intellectual Property and Copyright Statements . . . . . . . . . . 24 97 1. Introduction 99 In some situations, there is a need for Mobile IPv4 entities, such as 100 the home agent, foreign agent and mobile node to send and receive 101 asynchronous notification messages during a mobility session. The 102 base Mobile IP Specification [RFC3344] does not have a provision for 103 this. 105 This document defines a generic message and a notification model that 106 can be used by Mobile IPv4 entities to send various notifications. 107 However, this specification does not define any specific notification 108 message or the actions that the receiving entity is required to 109 perform on receiving that message. Specific extensions and the 110 corresponding handler actions are outside the scope of this document. 112 2. Terminology 114 It is assumed that the reader is familiar with the terminology used 115 in [RFC3543], [RFC3344]. In addition, the following terms are 116 defined: 118 Notification Message 120 A message from a mobility agent to a mobile node or other mobility 121 agent to asynchronously notify it about an event that is relevant 122 to the mobility service it is currently providing. 124 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in BCP 14, [RFC2119]. 128 3. Notification message - Usage Scenario's 130 There are several scenarios where a mobility agent could initiate 131 notification events. Some of these are described in the following 132 sections. 134 3.1. Notification message from a home agent to a Mobile Node 136 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 138 In this case, the home agent cannot directly notify the mobile node, 139 but must send the notification via the foreign agent. 141 +----+ notification +----+ notification +----+ 142 | MN |<================| FA |<=============| HA | 143 +----+ +----+ +----+ 145 Figure 1: Home Agent notifies Mobile Node through Foreign Agent 147 3.1.2. Mobile Registered using a Collocated Care-of Address 149 In this case, the mobile node has registered with the home agent 150 directly, so the notification message can go directly to the mobile 151 node. 153 The notification mechanism as specified here does not support the 154 case of Co-located CoA mode with registration through a foreign agent 155 (due to the 'R' bit being set in the foreign agent's advertisement 156 messages). 158 +----+ notification +----+ 159 | MN |<===================================| HA | 160 +----+ +----+ 162 Figure 2: Home Agent directly notifies Mobile Node 164 3.2. Notification message from a Foreign Agent to a Mobile Node 166 There are two cases where a foreign agent may send notification 167 messages to a mobile node, one where it is relaying a message, the 168 other where the notification is triggered by a message from another 169 network entity, for example a AAA node. (notification messages 170 between a AAA entity and the foreign agent could be based on RADIUS 171 or Diameter, but this is out of scope for this document). If the 172 notification is initiated by a foreign agent, the foreign agent may 173 need to also notify the home agent about the event. 175 +----+ notification +----+ notification +--------+ 176 | MN |<================| FA |<=============| AAA/HA | 177 +----+ +----+ +--------+ 178 || notification +----+ 179 ================>| HA | 180 +----+ 182 Figure 3: Foreign Agent notifies Mobile Node 184 3.3. Notification message from a Home Agent to a Foreign Agent 186 The home agent may also need to send a notification to the foreign 187 agent, but not to the mobile node, as illustrated below: 189 +----+ notification +----+ 190 | FA |<=============| HA | 191 +----+ +----+ 193 Figure 4: Home Agent notifies Foreign Agent 195 4. Generic Notification Message and Considerations 197 This section describes in detail the generic notification message, 198 generic notification acknowledgement message, and some considerations 199 related to the handling of these messages in the mobile node, foreign 200 agent and home agent. 202 4.1. Generic Notification Message 204 A generic notification message is sent by a mobility agent to inform 205 another mobility agent, or a mobile node, of MIP-related information. 206 These messages must use the same IP and UDP headers as any previous 207 Registration Request or Reply message to the same entity. The 208 generic notification message is defined as follows: 210 IP Fields: 212 Source Address Sender's address. 214 Destination Address Receiver's address. 216 UDP Fields: 218 Source Port variable. 220 Destination Port Same as the last Registration Reply/Request 221 message. 223 The UDP header is followed by the Mobile IP fields shown below: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Subtype | ToT |A| Reserved | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Home Address | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Home Agent Address | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Care-of Address | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 + Identification + 238 | | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Extensions... 241 +-+-+-+-+-+-+-+-+-+-+-+-+- 243 Type (TBD) 245 Subtype 247 This field describes the particular type of notification which is 248 carried in the notification message. 250 ToT: Type of Direction 252 This memo defines the semantics of the following ToT field values: 254 0 -- Message sent by the home agent to the mobile node 256 1 -- Message sent by the home agent to the foreign agent 258 2 -- Message sent by the mobile node to the home agent 260 3 -- Message sent by the mobile node to the foreign agent 262 4 -- Message sent by the foreign agent to the mobile node 264 5 -- Message sent by the foreing agent to the home agent 266 A 268 This bit indicates whether the notification message MUST be 269 acknowledged by the recipient. 271 Set to "1" to indicate that acknowledgement is required. 273 Set to "0" to indicate that acknowledgement is optional. 275 Reserved 277 MUST be sent as 0, and ignored when received. 279 Home Address 281 The home IP address of the mobile node. 283 Home Agent Address 285 The IP address of the mobile node's home agent. 287 Care-of Address 289 The mobile node's care-of address, either the co-located care-of 290 address or the foreign agent care-of address. 292 Identification 294 A 64-bit number, constructed by the sender, used for matching 295 Generic Notification with Generic Notification Acknowledgement, 296 and for protecting against replay attacks of notification 297 messages. See Sections 5.4 and 5.7 of [RFC3344]. 299 Extensions 301 The fixed portion of the Generic Notification Message is followed 302 by one or more extensions which may be used with this message, and 303 by one or more authentication extensions (as defined in Section 304 3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] 305 for information on the relative order in which different 306 extensions, when present, must be placed in a Generic Notification 307 Message. 309 4.2. Generic Notification Acknowledgment Message 311 A generic notification acknowledgement message is sent by mobility 312 agents or mobile nodes to indicate the successful receipt of a 313 generic notification message. 315 IP Fields: 317 Source Address Typically copied from the destination 318 address of the Generic Notification to which 319 the agent is replying. 321 Destination Address Copied from the source address of the 322 Generic Notification to which the agent is 323 replying. 325 UDP Fields: 327 Source Port variable. 329 Destination Port Copied from the source port of the 330 corresponding Generic Notification. 332 The UDP header is followed by the Mobile IP fields shown below: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Subtype | ToT |R| Status | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Home Address | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Home Agent Address | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Care-of Address | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 + Identification + 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Extensions... 350 +-+-+-+-+-+-+-+-+-+-+-+-+- 352 Type (TBD) 354 Subtype 356 This field specifies the particular type of notification 357 acknowledgement message. 359 ToT: Type of Direction 361 This memo defines the semantics of the following ToT field values: 363 0 -- Message sent by the home agent to the mobile node 365 1 -- Message sent by the home agent to the foreign agent 367 2 -- Message sent by the mobile node to the home agent 369 3 -- Message sent by the mobile node to the foreign agent 371 4 -- Message sent by the foreign agent to the mobile node 373 5 -- Message sent by the foreing agent to the home agent 375 R: Reserved 377 MUST be sent as 0, and ignored when received. 379 Status 380 If the Generic Notification Message was received without error, 381 this field is set to zero. However, if there is an error in 382 reception, the field is nonzero with the following allowable codes 383 defined in section 3.4 of [RFC3344]. 385 Home Address 387 The home IP address of the mobile node. 389 Home Agent Address 391 The IP address of the sender's home agent. 393 Care-of Address 395 The mobile node's care-of address, either the co-located care-of 396 address or the foreign agent care-of address. 398 Identification 400 A 64-bit number used for matching Generic Notification with 401 Generic Notification Acknowledgement, and for protecting against 402 replay attacks of generic notification messages. The value is 403 based on the Identification field from the Generic Notification 404 message from the sender, and on the style of replay protection 405 used in the security context between the receiver and sender 406 (defined by the mobility security association between them, and 407 SPI value in the authorization-enabling extension). See Sections 408 5.4 and 5.7 of [RFC3344]. 410 Extensions 412 The fixed portion of the generic notification acknowledgement 413 message is followed by one or more of the Extensions listed in 414 Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of 415 [RFC3344] for information on the relative order in which different 416 extensions, when present, MUST be placed in a Generic Notification 417 message. 419 4.3. Mobile Node Consideration 421 It is possible that the mobile node MAY receive a generic 422 notification message from a foreign agent or home agent. Both in the 423 case of FA-CoA and Co-located CoA, the mobile node MAY reply with a 424 Generic Notification Acknowledgement message based on the "A" flag in 425 the notification message. 427 4.3.1. Receiving Generic Notification Messages 429 When the mobile node is using FA-CoA and receives a Notification 430 message, if the "ToT" values is 0, it means that the notification 431 message came from the home agent. If the "ToT" values is 4, the 432 notification came from the foreign agent. 434 If this notification message came from a foreign agent and the mobile 435 node accepts the foreign agent's generic notification message, it 436 will process the notification extension according to the specific 437 rules for that extension. After that, the mobile node MAY reply with 438 a Generic Notification Acknowledgement message back to the foreign 439 agent. If the "A" flag is set in the notification message, then the 440 mobile node MUST send the acknowledgement. 442 If this notification message came from the home agent, relayed by the 443 foreign agent, or is a Co-located CoA, the Mobile-Home Authentication 444 extension MUST be checked and the mobile node MUST check the 445 Authenticator value in the Extension. If no Mobile-Home 446 Authentication Extension is found, or if more than one Mobile-Home 447 Authentication Extension is found, or if the Authenticator is 448 invalid, the mobile node MUST silently discard the Notification 449 message. If the mobile node accepts the home agent's generic 450 notification message, it will process it according to the specific 451 rules for that extension. After that, the mobile node MAY reply with 452 a Generic Notification Acknowledgement message back to the home agent 453 based on the "A" flag in the notification message. 455 4.3.2. Sending Generic Notification Acknowledgement Message 457 Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY 458 reply with a Generic Notification Acknowledgement Message based on 459 the "A" flag in the notification message as follows: 461 In the case of FA-CoA, The source address is the mobile node's 462 address, the destination address is the foreign agent address. 464 If the notification message was initiated from the foreign agent to 465 the mobile node ("ToT" values is set to 4), the ordering of the 466 extension is: any non-authentication Extensions used only by the 467 foreign agent, followed by The Mobile-Foreign Authentication 468 extension defined in section 3.5.3 of [RFC3344]. 470 If the notification message was initiated from the home agent to the 471 mobile node ("ToT" values is set to 1), the ordering of the extension 472 is: any non-authentication Extensions used only by the foreign agent, 473 followed by The Mobile-Foreign Authentication extension defined in 474 section 3.5.3 of [RFC3344], followed by any non-authentication 475 Extensions used only by the home agent, followed by the Mobile-Home 476 Authentication extension defined in section 3.5.2 of [RFC3344] 478 In the case of a FA-CoA, the source address is the mobile node's CoA 479 address and the destination address is the home agent's address 480 ("ToT" values is set to 2), the ordering of the extension is: any 481 non-authentication Extensions used only by the home agent, followed 482 by the Mobile-Home Authentication Extension defined in section 3.5.2. 483 of [RFC3344]. 485 4.4. Foreign Agent Consideration 487 The foreign agent cannot only relay generic notification message from 488 the home agent and mobile node, but it can also initiate a generic 489 notification message to the mobile node or home agent, but only when 490 there is a binding for the mobile node. 492 4.4.1. Receiving Generic Notification Message 494 If the foreign agent receives a notification message, and the "ToT" 495 values is set to 0, it means that the home agent is asking the 496 foreign agent to relay the message to the mobile node. Otherwise, it 497 means that the target of the notification is the foreign agent. 499 If the "ToT" values is set to 1, the Foreign-Home Authentication 500 extension MUST be checked, and the foreign agent MUST check the 501 Authenticator value in the Extension. If no Foreign-Home 502 Authentication Extension is found, or if more than one Foreign-Home 503 Authentication Extension is found, or if the Authenticator is 504 invalid, the foreign agent MUST silently discard the Notification 505 message. If foreign agent accepts the home agent's generic 506 notification message, it will process it based on the specific rules 507 for that extension. The foreign agent MAY then reply with a Generic 508 Notification Acknowledgement message back to the home agent based on 509 the "A" flag in the notification message. 511 the "ToT" values is set to 0, the Foreign-Home Authentication 512 extension MUST be checked, and the foreign agent MUST check the 513 Authenticator value in the Extension. If no Foreign-Home 514 Authentication Extension is found, or if more than one Foreign-Home 515 Authentication Extension is found, or if the Authenticator is 516 invalid, the foreign agent MUST silently discard the Notification 517 message. If foreign agent accepts the home agent's generic 518 notification message, it MUST relay the Generic Notification to the 519 mobile node's home address as specified in the Home Address field of 520 the Generic Notification. The foreign agent MUST NOT modify any of 521 the fields beginning with the fixed portion of the Generic 522 Notification message through and including the Mobile-Home 523 Authentication Extension or other authentication extension supplied 524 by the home agent as an authorization-enabling extension for the 525 mobile node. Furthermore, the foreign agent MUST process and remove 526 any Extensions following the Mobile-Home Authentication Extension and 527 MAY append any of its own non-authentication Extensions of relevance 528 to the mobile node, if applicable, and MUST append the Mobile-Foreign 529 Authentication Extension, if the foreign agent shares a mobility 530 security association with the Mobile Node. 532 4.4.2. Sending Generic Notification Acknowledgement Messages 534 The foreign agent may need to either relay a Generic Notification 535 Acknowledgemnt message between the mobile node and the home agent or 536 send one as a response to a notification messsage that was sent to 537 it. In both cases, the Generic Notification Acknowledgement Message 538 is defined as follows: 540 The source address is the foreign agent address, the destination 541 address is home agent address. 543 If the foreign agent is only relaying this message to the home agent, 544 the foreign agent it MUST NOT modify any of the fields beginning with 545 the fixed portion of the Generic Notification Acknowledgement through 546 and including the Mobile-Home Authentication Extension or other 547 authentication extension supplied by the home agent as an 548 authorization-enabling extension for the mobile node. Furthermore, 549 the foreign agent MUST process and remove any Extensions following 550 the Mobile-Home Authentication Extension and MAY append any of its 551 own non-authentication Extensions of relevance to the home agent, if 552 applicable. It MUST also append the Foreign-Home Authentication 553 Extension, if the foreign agent shares a mobility security 554 association with the home agent. 556 If the notification message is from the home agent to the foreign 557 agent then the "ToT" values is set to 1 and the ordering of the 558 extension is: any non-authentication Extensions used only by the home 559 agent, followed by The Foreign-Home Authentication extension defined 560 in section 3.5.4 of [RFC3344]. 562 4.4.3. Sending Generic Notification Messages 564 If the foreign agent is initiating a notification to the mobile node 565 using the generic notification message, it MAY also notify the home 566 agent as well. 568 In the message to the mobile node, the source address is the foreign 569 agent address, the destination address is the mobile node's address, 570 the "ToT" values is set to 4, and the ordering of the extension is: 572 the notification extension, followed by any non-authentication 573 Extensions used only by the mobile node, followed by The Mobile- 574 Foreign Authentication extension defined in section 3.5.3 of 575 [RFC3344]. Computing Authentication Extension Values is the same as 576 section 3.5.1 of [RFC3344] except the payload is the notification 577 other than registration. 579 In the message to the home agent, the source address is the foreign 580 agent's address, the destination address is the home agent's address 581 (the "ToT" values is set to 5), and the ordering of the extension is: 582 notification extension, followed by any non-authentication Extensions 583 used only by the home agent, followed by The Foreign-Home 584 Authentication extension defined in section 3.5.4 of [RFC3344]. 585 Computing Authentication Extension Values is the same as section 586 3.5.1 of [RFC3344] except the payload is the notification other than 587 registration. 589 4.5. Home Agent Consideration 591 The Home agent MAY initiate a generic notification message to both 592 the mobile node and foreign agent, and it also MAY receive a generic 593 notification acknowledgement message from both the foreign agent and 594 mobile node. The home agent also MAY receive a generic notification 595 message from the foreign agent, but only when there is a binding for 596 a mobile node. If the home agent receives a notification message 597 from a foreign agent and there is no corresponding mobile node 598 registration, the home agent should drop the notification message. 600 4.5.1. Sending Generic Notification Messages 602 In the case of FA CoA, the home agent may either send a notification 603 message to notify the foreign agent, or have the foreign agent relay 604 the notification message to the mobile node if the mobile node needs 605 to the notified. 607 If the message from the home agent to the foreign agent, the source 608 address is home agent's address, the destination address is the 609 foreign agent's address 611 If the foreign agent is working only as a relay agent, the "ToT" 612 values is set to 0, and the ordering of the extension is: the 613 notification extension, followed by any non-authentication extension 614 expected to be used by mobile node, followed by Mobile-Home 615 Authentication Extension defined in section 3.5.2. of [RFC3344], 616 followed by any non-authentication Extensions used only by the 617 foreign agent, followed by The Foreign-Home Authentication extension 618 defined in section 3.5.4 of [RFC3344]. Computing Authentication 619 Extension Values is the same as section 3.5.1 of [RFC3344]. 621 If the foreign agent is the target of this notification message, then 622 the "ToT" values is set to 1, The ordering of the extension is: the 623 notification extension, followed by any non-authentication Extensions 624 used only by the foreign agent, followed by The Foreign-Home 625 Authentication extension defined in section 3.5.4 of [RFC3344]. 626 Computing Authentication Extension Values is the same as section 627 3.5.1 of [RFC3344]. 629 4.5.2. Receiving Generic Notification Acknowledgement Messages 631 In the case of FA-CoA, if the home agent receives this message, and 632 the "ToT" values is set to 2, it means that the notification 633 acknowledgement message came from mobile node, otherwise it came from 634 the foreign agent. The Foreign-Home Authentication extension MUST be 635 checked, and the home agent MUST check the Authenticator value in the 636 Extension. If no Foreign-Home Authentication Extension is found, or 637 if more than one Foreign-Home Authentication Extension is found, or 638 if the Authenticator is invalid, the home agent MUST silently discard 639 the Notification Acknowledgement message. 641 If the "ToT" values is set to 5, and the home agent accepted this 642 message, and the Status field indicates that the notification was 643 accepted by the foreign agent, the home agent MAY also process it 644 based on the notification event. 646 If the "ToT" values is set to 2, and the home agent accepted this 647 message, the Mobile-Home Authentication extension MUST be checked, 648 and the home agent MUST check the Authenticator value in the 649 Extension. If no Mobile-Home Authentication Extension is found, or 650 if more than one Mobile-Home Authentication Extension is found, or if 651 the Authenticator is invalid, the home agent MUST silently discard 652 the Notification Acknowledgement message. if the home agent accepted 653 this message, and the Status field indicates that the notification 654 was accepted by the mobile node, home agent MAY also process it based 655 on the notification event. 657 In the case of Co-located CoA, if the home agent received this 658 message, the Mobile-Home Authentication extension MUST be checked, 659 and the home agent MUST check the Authenticator value in the 660 Extension. If no Mobile-Home Authentication Extension is found, or 661 if more than one Mobile-Home Authentication Extension is found, or if 662 the Authenticator is invalid, the home agent MUST silently discard 663 the Notification Acknowledgement message. For all Generic 664 Notification Acknowledgement messages containing a Status Code 665 indicating status from the mobile node, If the Status field indicates 666 that the notification was accepted by the mobile node, home agent MAY 667 process it based on the notification event. 669 4.5.3. Receiving Generic Notification Messages 671 The home agent MAY receive generic notification messages which are 672 sent from the foreign agent. When the home agent receives this 673 message, the Foreign-Home Authentication extension MUST be checked, 674 and the home agent MUST check the Authenticator value in the 675 Extension. If no Foreign-Home Authentication Extension is found, or 676 if more than one Foreign-Home Authentication Extension is found, or 677 if the Authenticator is invalid, the home agent MUST silently discard 678 the Notification message. If home agent accepts the foreign agent's 679 generic notification message, it will process it based on the 680 notification extension. Furthermore, the home agent MAY reply with a 681 Generic Notification Acknowledgement message back to the foreign 682 agent based on the "A" flag in the notification message. 684 4.5.4. Sending Generic Notification Acknowledgement Messages 686 If the generic notification message came from the foreign agent only, 687 the home agent MAY reply with a generic notification acknowledgement 688 message to the foreign agent based on the "A" flag in the 689 notification message. if the "A" flag is set in the notification 690 message, then the home agent must send a Notification Acknowledgement 691 message. The message is as follows: The source address is home 692 agent's address, the destination address is the foreign agent's 693 address, the "ToT" values is set to 1. The ordering of the extension 694 is: any non-authentication Extensions used only by the foreign agent, 695 followed by The Foreign-Home Authentication extension defined in 696 section 3.5.4 of [RFC3344]. 698 5. Usage Example 700 There are several applications that could use this generic 701 notification message. for example, during handover between CDMA 2000 702 1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be 703 removed on the foreign agent (PDSN) to avoid over-charging 704 subscribers. Other applications such as registration revocation, 705 home agent switch over, NEMO prefix changes, service or billing 706 related events, load balancing where the home agent wants to move 707 some of the registered mobile nodes to other home agents, service 708 termination due to end of prepaid time, and service interruption due 709 to system maintenance. 711 Here we give a example of using revocation extension and describe 712 some possible event which could use the generic string extension 713 [MIP4-STRING]based on this notification mechanism also. There is 714 also the possibility that this notification message could carry many 715 extensions at once. A new VSE extension could be defined to support 716 this notification message. 718 5.1. Revocation Extension 720 If one agent wants to notify another agent about registration 721 revocation [RFC3543], it could easily be carried by a generic 722 notification message and generic notification acknowledgement by 723 specifying the exact "Subtype" in the two messages. 725 5.2. Generic String Extension 727 In some case, the home agent or foreign agent needs to notify the 728 mobile node about service termination due to the end of prepaid time, 729 or service interruption due to system maintenance. This information 730 could be defined based on a string which is recognized by the mobile 731 node easily. An example would be "Maintenance Stopping", "Prepaid 732 Expire". These string MUST be strictly defined so they could be 733 easily understood by all of the network entities. "Subtype" number 734 would need to be decided by working group. 736 6. Security Considerations 738 This specification operates in the security constraints and 739 requirements of [RFC3344]. It extends the operations of mobile node, 740 home agent and foreign agent defined in [RFC3344] to notifiy each 741 other about some events and provides the same level of security for 742 all three nodes. 744 7. IANA Considerations 746 This document describes two new messages, the Generic Notification 747 message, section 4.1 and the Generic Notification Acknowledgement 748 message, section 4.2. These two messages should be allocated from 749 the same address space used by the Registration Request and 750 Registration Reply messages in [RFC3344] 752 8. References 754 8.1. Normative References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, March 1997. 759 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 760 August 2002. 762 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 763 Mobile IPv4", RFC 3543, August 2003. 765 8.2. Informative References 767 [MIP4-STRING] 768 Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 769 String Extension", Jan 2006, 770 . 772 Authors' Addresses 774 Hui Deng 775 Hitachi (China) 776 Beijing Fortune Bldg. 1701 777 5 Dong San Huan Bei-Lu 778 Chao Yang District 779 Beijing 100004 780 China 782 Email: hdeng@hitachi.cn 784 Henrik Levkowetz 785 Ericsson Research 786 Torshamsgatan 23 787 S-164 80, Stockholm 788 SWEDEN 790 Email: henrik@levkowetz.com 792 Vijay Devarapalli 793 Azaire Networks 794 4800 Great America Pkwy 795 Santa Clara, CA 95054 796 USA 798 Email: vijay.devarapalli@azairenet.com 800 Sri Gundavelli 801 Cisco Systems 802 170 W.Tasman Drive 803 San Jose, CA 95134 804 USA 806 Email: sgundave@cisco.com 808 Brian Haley 809 Hewlett-Packard Company 810 110 Spitbrook Road 811 Nashua, NH 03062 812 USA 814 Email: brian.haley@hp.com 816 Full Copyright Statement 818 Copyright (C) The IETF Trust (2007). 820 This document is subject to the rights, licenses and restrictions 821 contained in BCP 78, and except as set forth therein, the authors 822 retain all their rights. 824 This document and the information contained herein are provided on an 825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 827 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 828 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 829 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 832 Intellectual Property 834 The IETF takes no position regarding the validity or scope of any 835 Intellectual Property Rights or other rights that might be claimed to 836 pertain to the implementation or use of the technology described in 837 this document or the extent to which any license under such rights 838 might or might not be available; nor does it represent that it has 839 made any independent effort to identify any such rights. Information 840 on the procedures with respect to rights in RFC documents can be 841 found in BCP 78 and BCP 79. 843 Copies of IPR disclosures made to the IETF Secretariat and any 844 assurances of licenses to be made available, or the result of an 845 attempt made to obtain a general license or permission for the use of 846 such proprietary rights by implementers or users of this 847 specification can be obtained from the IETF on-line IPR repository at 848 http://www.ietf.org/ipr. 850 The IETF invites any interested party to bring to its attention any 851 copyrights, patents or patent applications, or other proprietary 852 rights that may cover technology that may be required to implement 853 this standard. Please address the information to the IETF at 854 ietf-ipr@ietf.org. 856 Acknowledgment 858 Funding for the RFC Editor function is provided by the IETF 859 Administrative Support Activity (IASA).