idnits 2.17.1 draft-deng-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 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 861. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 867. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 23, 2006) is 6514 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 4 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 Expires: December 25, 2006 H. Levkowetz 5 Ericsson Research 6 V. Devarapalli 7 Azaire Networks 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 June 23, 2006 14 Generic Notification Message for Mobile IPv4 15 draft-deng-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 25, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 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 type designed for this purpose. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Scenarios Requiring a Notification Message . . . . . . . . . . 5 57 3.1. Home Agent Initiates a Notification to the Mobile Node . . 5 58 3.1.1. Foreign Agent Care-of Address . . . . . . . . . . . . 5 59 3.1.2. Co-located Care-of Address . . . . . . . . . . . . . . 5 60 3.2. Foreign Agent Initiates a Notification to the Mobile 61 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.3. Home Agent Initiates a Notification to the Foreign 63 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Generic Notification Message and Considerations . . . . . . . 7 65 4.1. Generic Notification Message . . . . . . . . . . . . . . . 7 66 4.2. Generic Notification Acknowledgment Message . . . . . . . 9 67 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 11 68 4.3.1. Receiving Generic Notification Messages . . . . . . . 12 69 4.3.2. Sending Generic Notification Acknowledgement 70 Message . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 13 72 4.4.1. Receiving Generic Notification Message . . . . . . . . 13 73 4.4.2. Sending Generic Notification Acknowledgement 74 Message . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.4.3. Sending Generic Notification Messages . . . . . . . . 15 76 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 15 77 4.5.1. Sending Generic Notification Message . . . . . . . . . 15 78 4.5.2. Receiving Generic Notification Acknowledgement 79 Messages . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.5.3. Receiving Generic Notification Messages . . . . . . . 17 81 4.5.4. Sending Generic Notification Acknowledgement 82 Messages . . . . . . . . . . . . . . . . . . . . . . . 17 83 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 18 84 5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 18 85 5.2. Generic String Extension . . . . . . . . . . . . . . . . . 18 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 90 8.2. Informative 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 events during a mobility session. The base 99 Mobile IP Specification [RFC3344] does not have a provision for this. 101 This document defines a generic message and a notification model that 102 can be used by Mobile IPv4 entities to send various notifications. 103 However, this specification does not define any specific notification 104 message or the actions that the receiving entity is required to 105 perform on receiving that message. Specific extensions and the 106 corresponding handler actions are outside the scope of this document. 108 2. Terminology 110 It is assumed that the reader is familiar with the terminology used 111 in [RFC3543], [RFC3344]. In addition, the following terms are 112 defined: 114 Notification Message 116 A message from a mobility agent to a mobile node or other mobility 117 agent to asynchronously notify it about an event that is relevant 118 to the mobility service it is currently providing. 120 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in BCP 14, [RFC2119]. 124 3. Scenarios Requiring a Notification Message 126 There are several scenarios where a mobility agent could initiate 127 notification events. Some of these are described in the following 128 sections. 130 3.1. Home Agent Initiates a Notification to the Mobile Node 132 The home agent may wish to notify a mobile node about events such as 133 load balancing, where the home agent wants to move some of the 134 registered mobile nodes to other home agents; service termination due 135 to end of prepaid time; or service interruption due to system 136 maintenance. If the event requires some specific response from the 137 mobile node, a new extension and specification needs to be defined 138 for this. On the other hand, the notification could be intended for 139 the user, for example, the message string extension [MIP4-STRING]. 141 3.1.1. Foreign Agent Care-of Address 143 In this case, the home agent cannot directly notify the mobile node, 144 but must send the notification via the foreign agent. 146 +----+ notification +----+ notification +----+ 147 | MN |<================| FA |<=============| HA | 148 +----+ +----+ +----+ 150 Figure 1: Home Agent notifies Mobile Node through Foreign Agent 152 3.1.2. Co-located Care-of Address 154 In this case, the mobile node has registered with the home agent 155 directly, so the notification message can go directly to the mobile 156 node. 158 The notification mechanism as specified here does not support the 159 case of Co-located CoA mode with registration through a foreign agent 160 (due to the 'R' bit being set in the foreign agent's advertisement 161 messages). 163 +----+ notification +----+ 164 | MN |<===================================| HA | 165 +----+ +----+ 167 Figure 2: Home Agent directly notifies Mobile Node 169 3.2. Foreign Agent Initiates a Notification to the Mobile Node 171 There are two cases where a foreign agent may send notification 172 messages to a mobile node, one where it is relaying a message, the 173 other where the notification is triggered by a message from another 174 network entity, for example a AAA node. (notification messages 175 between a AAA entity and the foreign agent could be based on RADIUS 176 or Diameter, but this is out of scope for this document). If the 177 notification is initiated by a foreign agent, the foreign agent may 178 need to also notify the home agent about the event. 180 +----+ notification +----+ notification +--------+ 181 | MN |<================| FA |<=============| AAA/HA | 182 +----+ +----+ +--------+ 183 || notification +----+ 184 ================>| HA | 185 +----+ 187 Figure 3: Foreign Agent notifies Mobile Node 189 3.3. Home Agent Initiates a Notification to the Foreign Agent 191 The home agent may also need to send a notification to the foreign 192 agent, but not to the mobile node, as illustrated below: 194 +----+ notification +----+ 195 | FA |<=============| HA | 196 +----+ +----+ 198 Figure 4: Home Agent notifies Foreign Agent 200 4. Generic Notification Message and Considerations 202 This section describes in detail the generic notification message, 203 generic notification acknowledgement message, and some considerations 204 related to the handling of these messages in the mobile node, foreign 205 agent and home agent. 207 4.1. Generic Notification Message 209 A generic notification message is sent by a mobility agent to inform 210 another mobility agent, or a mobile node, of MIP-related information. 211 These messages must use the same IP and UDP headers as any previous 212 Registration Request or Reply message to the same entity. The 213 generic notification message is defined as follows: 215 IP Fields: 217 Source Address Sender's address. 219 Destination Address Receiver's address. 221 UDP Fields: 223 Source Port variable. 225 Destination Port Same as the last Registration Reply/Request 226 message. 228 The UDP header is followed by the Mobile IP fields shown below: 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Subtype |M|H|A| Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Home Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Home Agent Address | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Care-of Address | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 + Identification + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Extensions... 246 +-+-+-+-+-+-+-+-+-+-+-+-+- 248 Type (TBD) 250 Subtype 252 This field describes the particular type of notification which is 253 carried in the notification message. 255 M 257 This bit indicates whether the receiver of the notification is a 258 mobile node 260 Set to "1" to indicate that if the message is intended for the 261 mobile node. 263 Set to "0" to indicate that if the message is not intended for the 264 mobile node. 266 H 268 This bit indicates whether the sender of this message is the home 269 agent or the foreign agent. 271 Set to "1" to indicate that the sender is the home agent. 273 Set to "0" to indicate that the sender is the foreign agent. 275 A 277 This bit indicates whether the notification message MUST be 278 acknowledged by the recipient. 280 Set to "1" to indicate that acknowledgement is required. 282 Set to "0" to indicate that acknowledgement is optional. 284 Reserved 286 MUST be sent as 0, and ignored when received. 288 Home Address 290 The home IP address of the mobile node. 292 Home Agent Address 294 The IP address of the mobile node's home agent. 296 Care-of Address 298 The mobile node's care-of address, either the co-located care-of 299 address or the foreign agent care-of address. 301 Identification 303 A 64-bit number, constructed by the sender, used for matching 304 Generic Notification with Generic Notification Acknowledgement, 305 and for protecting against replay attacks of notification 306 messages. See Sections 5.4 and 5.7 of [RFC3344]. 308 Extensions 310 The fixed portion of the Generic Notification Message is followed 311 by one or more extensions which may be used with this message, and 312 by one or more authentication extensions (as defined in Section 313 3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] 314 for information on the relative order in which different 315 extensions, when present, must be placed in a Generic Notification 316 Message. 318 4.2. Generic Notification Acknowledgment Message 320 A generic notification acknowledgement message is sent by mobility 321 agents or mobile nodes to indicate the successful receipt of a 322 generic notification message. 324 IP Fields: 326 Source Address Typically copied from the destination 327 address of the Generic Notification to which 328 the agent is replying. 330 Destination Address Copied from the source address of the 331 Generic Notification to which the agent is 332 replying. 334 UDP Fields: 336 Source Port variable. 338 Destination Port Copied from the source port of the 339 corresponding Generic Notification. 341 The UDP header is followed by the Mobile IP fields shown below: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Subtype |M|H| Reserved | Status | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Home Address | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Home Agent Address | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Care-of Address | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 + Identification + 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Extensions... 359 +-+-+-+-+-+-+-+-+-+-+-+-+- 361 Type (TBD) 363 Subtype 365 This field specifies the particular type of notification 366 acknowledgement message. 368 M 370 This bit indicates whether the sender of this message is the 371 mobile node or not. 373 Set to "1" to indicate that the sender is the mobile node. 375 Set to "0" to indicate that the sender is not the mobile node. 377 H 379 This bit indicates whether the receiver of this notification 380 acknowledgement is the home agent or not. 382 Set to "1" to indicate that the receiver is the home agent. 384 Set to "0" to indicate that thee receiver is not the home agent. 386 Reserved 388 MUST be sent as 0, and ignored when received. 390 Status 392 If the Generic Notification Message was received without error, 393 this field is set to zero. However, if there is an error in 394 reception, the field is nonzero with the following allowable codes 395 defined in section 3.4 of [RFC3344]. 397 Home Address 399 The home IP address of the mobile node. 401 Home Agent Address 403 The IP address of the sender's home agent. 405 Care-of Address 407 The mobile node's care-of address, either the co-located care-of 408 address or the foreign agent care-of address. 410 Identification 412 A 64-bit number used for matching Generic Notification with 413 Generic Notification Acknowledgement, and for protecting against 414 replay attacks of generic notification messages. The value is 415 based on the Identification field from the Generic Notification 416 message from the sender, and on the style of replay protection 417 used in the security context between the receiver and sender 418 (defined by the mobility security association between them, and 419 SPI value in the authorization-enabling extension). See Sections 420 5.4 and 5.7 of [RFC3344]. 422 Extensions 424 The fixed portion of the generic notification acknowledgement 425 message is followed by one or more of the Extensions listed in 426 Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of 427 [RFC3344] for information on the relative order in which different 428 extensions, when present, MUST be placed in a Generic Notification 429 message. 431 4.3. Mobile Node Consideration 433 It is possible that the mobile node MAY receive a generic 434 notification message from a foreign agent or home agent. Both in the 435 case of FA-CoA and Co-located CoA, the mobile node MAY reply with a 436 Generic Notification Acknowledgement message based on the "A" flag in 437 the notification message. 439 4.3.1. Receiving Generic Notification Messages 441 When the mobile node is using FA-CoA and receives a Notification 442 message, if the "H" flag is set, it means that the notification 443 message came from the home agnet. If the "H" flag is not set, the 444 notification came from the foreign agent. 446 In either case, the Mobile-Foreign Authentication extension MUST be 447 used, and the mobile node MUST check the Authenticator value in the 448 Extension. If no Mobile-Foreign Authentication Extension is found, 449 or if more than one Mobile-Foreign Authentication Extension is found, 450 or if the Authenticator is invalid, the mobile node MUST silently 451 discard the Notification message. 453 If this notification message came from a foreign agent and the mobile 454 node accepts the foreign agent's generic notification message, it 455 will process the notification extension according to the specific 456 rules for that extension. After that, the mobile node MAY reply with 457 a Generic Notification Acknowledgement message back to the foreign 458 agent. If the "A" flag is set in the notification message, then the 459 mobile node MUST send the acknowledgement. 461 If this notification message came from the home agent, relayed by the 462 foreign agent, or is a Co-located CoA, the Mobile-Home Authentication 463 extension MUST be checked and the mobile node MUST check the 464 Authenticator value in the Extension. If no Mobile-Home 465 Authentication Extension is found, or if more than one Mobile-Home 466 Authentication Extension is found, or if the Authenticator is 467 invalid, the mobile node MUST silently discard the Notification 468 message. If the mobile node accepts the home agent's generic 469 notification message, it will process it according to the specific 470 rules for that extension. After that, the mobile node MAY reply with 471 a Generic Notification Acknowledgement message back to the home agent 472 based on the "A" flag in the notification message. 474 4.3.2. Sending Generic Notification Acknowledgement Message 476 Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY 477 reply with a Generic Notification Acknowledgement Message based on 478 the "A" flag in the notification message as follows: 480 In the case of FA-CoA, The source address is the mobile node's 481 address, the destination address is the foreign agent address. 483 If the notification message was initiated from the foreign agent to 484 the mobile node ("M" flag is set to "1", "H" flag is set to "0"), the 485 ordering of the extension is: any non-authentication Extensions used 486 only by the foreign agent, followed by The Mobile-Foreign 487 Authentication extension defined in section 3.5.3 of [RFC3344]. 489 ! If the notification message was initiated from the home agent to 490 the mobile node ("M" flag is set to "1", "H" flag is set to "1"), the 491 ordering of the extension is: any non-authentication Extensions used 492 only by the foreign agent, followed by The Mobile-Foreign 493 Authentication extension defined in section 3.5.3 of [RFC3344], 494 followed by any non-authentication Extensions used only by the home 495 agent, followed by the Mobile-Home Authentication extension defined 496 in section 3.5.2 of [RFC3344] 498 In the case of a FA-CoA, the source address is the mobile node's CoA 499 address and the destination address is the home agent's address ("M" 500 flag is set to "1", "H" flag is set to "1"), the ordering of the 501 extension is: the Generic Notification extension, followed by any 502 non-authentication extension expected to be used by home agent, 503 followed by the Mobile-Home Authentication Extension defined in 504 section 3.5.2. of [RFC3344]. 506 4.4. Foreign Agent Consideration 508 The foreign agent cannot only relay generic notification message from 509 the home agent and mobile node, but it can also initiate a generic 510 notification message to the mobile node or home agent, but only when 511 there is a binding for the mobile node. This means that the 512 messaging is between the entities in the binding relation. 514 4.4.1. Receiving Generic Notification Message 516 If the foreign agent receives a notification message, and the "M" 517 flag is set to "1", it means that the home agent is asking the 518 foreign agent to relay the message to the mobile node. Otherwise, it 519 means that the target of the notification is the foreign agent. 521 If the "M" flag is set to "0", the Foreign-Home Authentication 522 extension MUST be checked, and the foreign agent MUST check the 523 Authenticator value in the Extension. If no Foreign-Home 524 Authentication Extension is found, or if more than one Foreign-Home 525 Authentication Extension is found, or if the Authenticator is 526 invalid, the foreign agent MUST silently discard the Notification 527 message. If foreign agent accepts the home agent's generic 528 notification message, it will process it based on the specific rules 529 for that extension. The foreign agent MAY then reply with a Generic 530 Notification Acknowledgement message back to the home agent based on 531 the "A" flag in the notification message. 533 If the "M" flag is set to "1", the Foreign-Home Authentication 534 extension MUST be checked, and the foreign agent MUST check the 535 Authenticator value in the Extension. If no Foreign-Home 536 Authentication Extension is found, or if more than one Foreign-Home 537 Authentication Extension is found, or if the Authenticator is 538 invalid, the foreign agent MUST silently discard the Notification 539 message. If foreign agent accepts the home agent's generic 540 notification message, it MUST relay the Generic Notification to the 541 mobile node's home address as specified in the Home Address field of 542 the Generic Notification. The foreign agent MUST NOT modify any of 543 the fields beginning with the fixed portion of the Generic 544 Notification message through and including the Mobile-Home 545 Authentication Extension or other authentication extension supplied 546 by the home agent as an authorization-enabling extension for the 547 mobile node. Furthermore, the foreign agent MUST process and remove 548 any Extensions following the Mobile-Home Authentication Extension and 549 MAY append any of its own non-authentication Extensions of relevance 550 to the mobile node, if applicable, and MUST append the Mobile-Foreign 551 Authentication Extension, if the foreign agent shares a mobility 552 security association with the Mobile Node. 554 4.4.2. Sending Generic Notification Acknowledgement Message 556 The foreign agent may need to either relay a Generic Notification 557 Acknowledgemnt message between the mobile node and the home agent or 558 send one as a response to a notification messsage that was sent to 559 it. In both cases, the Generic Notification Acknowledgement Message 560 is defined as follows: 562 The source address is the foreign agent address, the destination 563 address is home agent address. 565 if the foreign agent is only relaying this message to the home agent, 566 the foreign agent it MUST NOT modify any of the fields beginning with 567 the fixed portion of the Generic Notification Acknowledgement through 568 and including the Mobile-Home Authentication Extension or other 569 authentication extension supplied by the home agent as an 570 authorization-enabling extension for the mobile node. Furthermore, 571 the foreign agent MUST process and remove any Extensions following 572 the Mobile-Home Authentication Extension and MAY append any of its 573 own non-authentication Extensions of relevance to the home agent, if 574 applicable. It MUST also append the Foreign-Home Authentication 575 Extension, if the foreign agent shares a mobility security 576 association with the home agent. 578 If the notification message is from the home agent to the foreign 579 agent then flag "M" is set to "0" and flag "H" is set to "1" and the 580 ordering of the extension is: any non-authentication Extensions used 581 only by the home agent, followed by The Foreign-Home Authentication 582 extension defined in section 3.5.4 of [RFC3344]. 584 4.4.3. Sending Generic Notification Messages 586 If the foreign agent is initiating a notification the mobile node 587 using the generic notification message, it MAY also notify the home 588 agent as well. 590 In the message to the mobile node, the source address is the foreign 591 agent address, the destination address is the mobile node's address, 592 the "M" flag is set to "1" and the "H" flag is set to "0", and the 593 ordering of the extension is: the notification extension, followed by 594 any non-authentication Extensions used only by the mobile node, 595 followed by The Mobile-Foreign Authentication extension defined in 596 section 3.5.3 of [RFC3344]. Computing Authentication Extension 597 Values is the same as section 3.5.1 of [RFC3344] except the payload 598 is the notification other than registration. 600 In the message to the home agent, the source address is the foreign 601 agent's address, the destination address is the home agent's address, 602 the "M" flag is set to "0" and the "H" flag is set to "0", The 603 ordering of the extension is: notification extension, followed by any 604 non-authentication Extensions used only by the home agent, followed 605 by The Foreign-Home Authentication extension defined in section 3.5.4 606 of [RFC3344]. Computing Authentication Extension Values is the same 607 as section 3.5.1 of [RFC3344] except the payload is the notification 608 other than registration. 610 4.5. Home Agent Consideration 612 Home agent MAY initiate a generic notification message to both the 613 mobile node and foreign agent, and it also MAY receive a generic 614 notification acknowledgement message from both the foreign agent and 615 mobile node. The home agent also MAY receive a generic notification 616 message from the foreign agent, but only when there is a binding for 617 a mobile node. It can send a message to the mobile node or to the 618 registered foreign agent in the path. This means that the messaging 619 is between the entities in the binding relation. If the home agent 620 receives a notification message from a foreign agent and there is no 621 corresponding mobile node registration, the home agent should drop 622 the notification message. 624 4.5.1. Sending Generic Notification Message 626 In the case of FA CoA, the home agent may either send a notification 627 message to notify the foreign agent, or have the foreign agent relay 628 the notification message to the mobile node if the mobile node needs 629 to the notified. 631 if the message from the home agent to the foreign agent, the source 632 address is home agent's address, the destination address is the 633 foreign agent's address 635 if the foreign agent is working only as a relay agent, the "M" flag 636 is set to "1" and the "H" flag is set to "1", and the ordering of the 637 extension is: the notification extension, followed by any non- 638 authentication extension expected to be used by mobile node, followed 639 by Mobile-Home Authentication Extension defined in section 3.5.2. of 640 [RFC3344], followed by any non-authentication Extensions used only by 641 the foreign agent, followed by The Foreign-Home Authentication 642 extension defined in section 3.5.4 of [RFC3344]. Computing 643 Authentication Extension Values is the same as section 3.5.1 of 644 [RFC3344]. 646 if the foreign agent is the target of this notification message, then 647 the "M" flag is set to "0" and the "H" flag is set to "1", The 648 ordering of the extension is: the notification extension, followed by 649 any non-authentication Extensions used only by the foreign agent, 650 followed by The Foreign-Home Authentication extension defined in 651 section 3.5.4 of [RFC3344]. Computing Authentication Extension 652 Values is the same as section 3.5.1 of [RFC3344]. 654 4.5.2. Receiving Generic Notification Acknowledgement Messages 656 In the case of FA-CoA, if the home agent receives this message, and 657 the "M" flag is set to "1", it means that the notification 658 acknowledgement message came from mobile node, otherwise it came from 659 the foreign agent. The Foreign-Home Authentication extension MUST be 660 checked, and the home agent MUST check the Authenticator value in the 661 Extension. If no Foreign-Home Authentication Extension is found, or 662 if more than one Foreign-Home Authentication Extension is found, or 663 if the Authenticator is invalid, the home agent MUST silently discard 664 the Notification Acknowledgement message. 666 if the "M" flag is set to "0", and the home agent accepted this 667 message, and the Status field indicates that the notification was 668 accepted by the foreign agent, the home agent MAY also process it 669 based on the notification event. 671 if the "M" flag is set to "0", and the home agent accepted this 672 message, the Mobile-Home Authentication extension MUST be checked, 673 and the home agent MUST check the Authenticator value in the 674 Extension. If no Mobile-Home Authentication Extension is found, or 675 if more than one Mobile-Home Authentication Extension is found, or if 676 the Authenticator is invalid, the home agent MUST silently discard 677 the Notification Acknowledgement message. if the home agent accepted 678 this message, and the Status field indicates that the notification 679 was accepted by the mobile node, home agent MAY also process it based 680 on the notification event. 682 In the case of Co-located CoA, if the home agent received this 683 message, the Mobile-Home Authentication extension MUST be checked, 684 and the home agent MUST check the Authenticator value in the 685 Extension. If no Mobile-Home Authentication Extension is found, or 686 if more than one Mobile-Home Authentication Extension is found, or if 687 the Authenticator is invalid, the home agent MUST silently discard 688 the Notification Acknowledgement message. For all Generic 689 Notification Acknowledgement messages containing a Status Code 690 indicating status from the mobile node, If the Status field indicates 691 that the notification was accepted by the mobile node, home agent MAY 692 process it based on the notification event. 694 4.5.3. Receiving Generic Notification Messages 696 the home agent MAY receive generic notification messages which are 697 sent from the foreign agent. When the home agent receives this 698 message, and the Foreign-Home Authentication extension MUST be 699 checked, the home agent MUST check the Authenticator value in the 700 Extension. If no Foreign-Home Authentication Extension is found, or 701 if more than one Foreign-Home Authentication Extension is found, or 702 if the Authenticator is invalid, the home agent MUST silently discard 703 the Notification message. If home agent accepts the foreign agent's 704 generic notification message, it will process it based on the 705 notification extension. Furthermore, the home agent MAY reply with a 706 Generic Notification Acknowledgement message back to the foreign 707 agent based on the "A" flag in the notification message. 709 4.5.4. Sending Generic Notification Acknowledgement Messages 711 If the generic notification message came from the foreign agent only, 712 the home agent MAY reply with a generic notification acknowledgement 713 message to the foreign agent based on the "A" flag in the 714 notification message. if the "A" flag is set in the notification 715 message, then the home agent must send a Notification Acknowledgement 716 message. The message is as follows: The source address is home 717 agent's address, the destination address is the foreign agent's 718 address, the "M" flag is set to "0" and the "H" flag is set to "0". 719 The ordering of the extension is: any non-authentication Extensions 720 used only by the foreign agent, followed by The Foreign-Home 721 Authentication extension defined in section 3.5.4 of [RFC3344]. 723 5. Usage Example 725 There are several applications that could use this generic 726 notification message. for example, during handover between CDMA 2000 727 1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be 728 removed on the foreign agent (PDSN) to avoid over-charging 729 subscribers. Other applications such as registration revocation, 730 home agent switch over, NEMO prefix changes, and service or billing 731 related events. 733 Here we give a example of using revocation extension and describe 734 some possible event which could use the generic string extension 735 based on this notification mechanism also. There is also the 736 possibility that this notification message could carry many 737 extensions at once. A new VSE extension could be defined to support 738 this notification message. 740 5.1. Revocation Extension 742 If an agent would like to notify another agent about registration 743 revocation [RFC3543], it could easily be carried by a generic 744 notification message and generic notification acknowledgement. One 745 would just specify the exact number of "Subtype" in this two 746 messages. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 751 | Type | Length |I| Reserved | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 753 | Timestamp | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 756 5.2. Generic String Extension 758 In some case, the home agent or foreign agent needs to notify mobile 759 node about service termination due to the end of prepaid time, or 760 service interruption due to system maintenance. This information 761 could be defined based on a string which is recognized by mobile node 762 easily. An example would be "Maintenance Stopping", "Prepaid 763 Expire". These string MUST be strictly defined so they could be 764 easily understood by all of the network entities. "Subtype" number 765 will be decided by working group. 767 6. Security Considerations 769 Mobile IP Generic Notification and Generic Notification 770 Acknowledgement are authenticated, and the authentication verified by 771 the recipient. 773 7. IANA Considerations 775 This document describes two new messages, the Generic Notification 776 message, section 4.1 and the Generic Notification Acknowledgement 777 message, section 4.2. These two messages should be allocated from 778 the same address space used by the Registration Request and 779 Registration Reply messages in [RFC3344] 781 8. References 783 8.1. Normative References 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 789 August 2002. 791 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 792 Mobile IPv4", RFC 3543, August 2003. 794 8.2. Informative References 796 [MIP4-STRING] 797 Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 798 String Extension", Jan 2006, 799 . 801 Authors' Addresses 803 Hui Deng 804 Hitachi (China) 805 Beijing Fortune Bldg. 1701 806 5 Dong San Huan Bei-Lu 807 Chao Yang District 808 Beijing 100004 809 China 811 Email: hdeng@hitachi.cn 813 Henrik Levkowetz 814 Ericsson Research 815 Torshamsgatan 23 816 S-164 80, Stockholm 817 SWEDEN 819 Email: henrik@levkowetz.com 821 Vijay Devarapalli 822 Azaire Networks 823 4800 Great America Pkwy 824 Santa Clara, CA 95054 825 USA 827 Email: vijay.devarapalli@azairenet.com 829 Sri Gundavelli 830 Cisco Systems 831 170 W.Tasman Drive 832 San Jose, CA 95134 833 USA 835 Email: sgundave@cisco.com 837 Brian Haley 838 Hewlett-Packard Company 839 110 Spitbrook Road 840 Nashua, NH 03062 841 USA 843 Email: brian.haley@hp.com 845 Intellectual Property Statement 847 The IETF takes no position regarding the validity or scope of any 848 Intellectual Property Rights or other rights that might be claimed to 849 pertain to the implementation or use of the technology described in 850 this document or the extent to which any license under such rights 851 might or might not be available; nor does it represent that it has 852 made any independent effort to identify any such rights. Information 853 on the procedures with respect to rights in RFC documents can be 854 found in BCP 78 and BCP 79. 856 Copies of IPR disclosures made to the IETF Secretariat and any 857 assurances of licenses to be made available, or the result of an 858 attempt made to obtain a general license or permission for the use of 859 such proprietary rights by implementers or users of this 860 specification can be obtained from the IETF on-line IPR repository at 861 http://www.ietf.org/ipr. 863 The IETF invites any interested party to bring to its attention any 864 copyrights, patents or patent applications, or other proprietary 865 rights that may cover technology that may be required to implement 866 this standard. Please address the information to the IETF at 867 ietf-ipr@ietf.org. 869 Disclaimer of Validity 871 This document and the information contained herein are provided on an 872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 879 Copyright Statement 881 Copyright (C) The Internet Society (2006). This document is subject 882 to the rights, licenses and restrictions contained in BCP 78, and 883 except as set forth therein, the authors retain all their rights. 885 Acknowledgment 887 Funding for the RFC Editor function is currently provided by the 888 Internet Society.