idnits 2.17.1 draft-ietf-mip4-generic-notification-message-04.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 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 929. 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 (February 12, 2008) is 5912 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: 2 errors (**), 0 flaws (~~), 2 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: August 15, 2008 Ericsson Research 6 V. Devarapalli 7 Azaire Networks 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 February 12, 2008 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-04.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 August 15, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 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 Co-located 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 . . . . . . . . . . . . . . . . 13 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 . . . . . . . . 16 78 4.4.4. Receiving Generic Notification Acknowledgement 79 Messages . . . . . . . . . . . . . . . . . . . . . . . 16 80 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 17 81 4.5.1. Sending Generic Notification Messages . . . . . . . . 17 82 4.5.2. Receiving Generic Notification Acknowledgement 83 Messages . . . . . . . . . . . . . . . . . . . . . . . 18 84 4.5.3. Receiving Generic Notification Messages . . . . . . . 19 85 4.5.4. Sending Generic Notification Acknowledgement 86 Messages . . . . . . . . . . . . . . . . . . . . . . . 19 87 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 20 88 5.1. Revocation Extension . . . . . . . . . . . . . . . . . . . 20 89 5.2. Generic String Extension . . . . . . . . . . . . . . . . . 20 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 92 8. Normative References . . . . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 94 Intellectual Property and Copyright Statements . . . . . . . . . . 25 96 1. Introduction 98 In some situations, there is a need for Mobile IPv4 entities, such as 99 the home agent, foreign agent and mobile node to send and receive 100 asynchronous notification messages during a mobility session. The 101 base Mobile IP Specification [RFC3344] does not have a provision for 102 this. 104 This document defines a generic message and a notification model that 105 can be used by Mobile IPv4 entities to send various notifications. 106 However, this specification does not define any specific notification 107 message or the actions that the receiving entity is required to 108 perform on receiving that message. Specific extensions and the 109 corresponding handler actions are outside the scope of this document. 111 2. Terminology 113 It is assumed that the reader is familiar with the terminology used 114 in [RFC3543], [RFC4917], [RFC3344]. In addition, the following terms 115 are defined: 117 Notification Message 119 A message from a mobility agent to a mobile node or other mobility 120 agent to asynchronously notify it about an event that is relevant 121 to the mobility service it is currently providing. 123 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119, [RFC2119]. 127 3. Notification message - Usage Scenario's 129 There are several scenarios where a mobility agent could initiate 130 notification events. Some of these are described in the following 131 sections. 133 3.1. Notification message from a Home Agent to a Mobile Node 135 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 137 In this case, the home agent cannot directly notify the mobile node, 138 but must send the notification via the foreign agent. 140 +----+ notification +----+ notification +----+ 141 | MN |<================| FA |<=============| HA | 142 +----+ +----+ +----+ 144 Figure 1: Home Agent notifies Mobile Node through Foreign Agent 146 3.1.2. Mobile Registered using a Co-located Care-of Address 148 In this case, the mobile node has registered with the home agent 149 directly, so the notification message can go directly to the mobile 150 node. 152 The notification mechanism as specified here does not support the 153 case of Co-located CoA mode with registration through a foreign agent 154 (due to the 'R' bit being set in the foreign agent's advertisement 155 messages). 157 +----+ notification +----+ 158 | MN |<===================================| HA | 159 +----+ +----+ 161 Figure 2: Home Agent directly notifies Mobile Node 163 3.2. Notification message from a Foreign Agent to a Mobile Node 165 There are two cases where a foreign agent may send notification 166 messages to a mobile node, one where it is relaying a message, the 167 other where the notification is triggered by a message from another 168 network entity, for example a AAA node(notification messages between 169 a AAA entity and the foreign agent could be based on RADIUS or 170 Diameter, but this is out of scope for this document). If the 171 notification is initiated by a foreign agent, the foreign agent may 172 need to also notify the home agent about the event. 174 +----+ notification +----+ notification +--------+ 175 | MN |<================| FA |<=============| AAA/HA | 176 +----+ +----+ +--------+ 177 || notification +----+ 178 ================>| HA | 179 +----+ 181 Figure 3: Foreign Agent notifies Mobile Node 183 3.3. Notification message from a Home Agent to a Foreign Agent 185 The home agent may also need to send a notification to the foreign 186 agent, but not to the mobile node, as illustrated below: 188 +----+ notification +----+ 189 | FA |<=============| HA | 190 +----+ +----+ 192 Figure 4: Home Agent notifies Foreign Agent 194 4. Generic Notification Message and Considerations 196 This section describes in detail the generic notification message, 197 generic notification acknowledgement message, and some considerations 198 related to the handling of these messages in the mobile node, foreign 199 agent and home agent. 201 4.1. Generic Notification Message 203 A generic notification message is sent by a mobility agent to inform 204 another mobility agent, or a mobile node, of MIP-related information. 205 These messages must use the same IP and UDP headers as any previous 206 Registration Request or Reply message to the same entity. The 207 generic notification message is defined as follows: 209 IP Fields: 211 Source Address Sender's address. 213 Destination Address Receiver's address. 215 UDP Fields: 217 Source Port variable. 219 Destination Port Same as the last Registration Reply/Request 220 message. 222 The UDP header is followed by the Mobile IP fields shown below: 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type | Subtype | MD |A| Reserved | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Home Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Home Agent Address | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Care-of Address | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 236 + Identification + 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Extensions... 240 +-+-+-+-+-+-+-+-+-+-+-+-+- 242 Type (TBD) 244 Subtype 246 This field describes the particular type of notification which is 247 carried in the notification message. The following values are 248 reserved in this document. 250 0 Reserved 252 1 Information carried in Vendor specific extensions 254 The value 0 is reserved and should not be used. The value 1 255 indicates that the actual information is carried in vendor 256 specific extensions. Other values are reserved for future 257 extensions. 259 MD: Message Direction 261 This memo defines the semantics of the following MD field value: 263 0 -- Message sent by the home agent to the mobile node 265 1 -- Message sent by the home agent to the foreign agent 267 2 -- Message sent by the mobile node to the home agent 269 3 -- Message sent by the mobile node to the foreign agent 271 4 -- Message sent by the foreign agent to the mobile node 273 5 -- Message sent by the foreing agent to the home 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 289 The home IP address of the mobile node. 291 Home Agent Address 293 The IP address of the mobile node's home agent. 295 Care-of Address 297 The mobile node's care-of address, either the Co-located Care-of 298 Address or the foreign agent care-of address. 300 Identification 302 A 64-bit number, constructed by the sender, used for matching 303 Generic Notification with Generic Notification Acknowledgement, 304 and for protecting against replay attacks of notification 305 messages. See Sections 5.4 and 5.7 of [RFC3344]. 307 Extensions 309 The fixed portion of the Generic Notification Message is followed 310 by one or more extensions which may be used with this message, and 311 by one or more authentication extensions (as defined in Section 312 3.5 of [RFC3344]). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] 313 for information on the relative order in which different 314 extensions, when present, must be placed in a Generic Notification 315 Message. 317 4.2. Generic Notification Acknowledgment Message 319 A generic notification acknowledgement message is sent by mobility 320 agents or mobile nodes to indicate the successful receipt of a 321 generic notification message. 323 IP Fields: 325 Source Address Typically copied from the destination 326 address of the Generic Notification to which 327 the agent is replying. 329 Destination Address Copied from the source address of the 330 Generic Notification to which the agent is 331 replying. 333 UDP Fields: 335 Source Port variable. 337 Destination Port Copied from the source port of the 338 corresponding Generic Notification. 340 The UDP header is followed by the Mobile IP fields shown below: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Subtype | MD | Reserved | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Home Address | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Home Agent Address | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Care-of Address | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 + Identification + 355 | | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Extensions... 358 +-+-+-+-+-+-+-+-+-+-+-+-+- 360 Type (TBD) 362 Subtype 364 This field specifies the particular type of notification 365 acknowledgement message. The following values are reserved in 366 this document. 368 0 Reserved 370 1 Information carried in Vendor specific extensions 372 The value 0 is reserved and should not be used. The value 1 373 indicates that the actual information is carried in vendor 374 specific extensions. Other values are reserved for future 375 extensions. 377 MD: Message Direction 379 This memo defines the semantics of the following MD field value: 381 0 -- Message sent by the home agent to the mobile node 383 1 -- Message sent by the home agent to the foreign agent 385 2 -- Message sent by the mobile node to the home agent 387 3 -- Message sent by the mobile node to the foreign agent 389 4 -- Message sent by the foreign agent to the mobile node 391 5 -- Message sent by the foreing agent to the home agent 393 Reserved 395 MUST be sent as 0, and ignored when received. 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 "MD" value is 0, it means that the notification 443 message came from the home agent. If the "MD" value is 4, the 444 notification came from the foreign agent. 446 If this notification message came from a foreign agent and the mobile 447 node accepts the foreign agent's generic notification message, it 448 will process the notification extension according to the specific 449 rules for that extension. After that, the mobile node MAY reply with 450 a Generic Notification Acknowledgement message back to the foreign 451 agent. If the "A" flag is set in the notification message, then the 452 mobile node MUST send the acknowledgement. 454 If this notification message came from the home agent, relayed by the 455 foreign agent, or is a Co-located CoA, the Mobile-Home Authentication 456 extension MUST be checked and the mobile node MUST check the 457 Authenticator value in the Extension. If no Mobile-Home 458 Authentication Extension is found, or if more than one Mobile-Home 459 Authentication Extension is found, or if the Authenticator is 460 invalid, the mobile node MUST silently discard the Notification 461 message. If the mobile node accepts the home agent's generic 462 notification message, it will process it according to the specific 463 rules for that extension. After that, the mobile node MAY reply with 464 a Generic Notification Acknowledgement message back to the home agent 465 based on the "A" flag in the notification message. 467 4.3.2. Sending Generic Notification Acknowledgement Message 469 Both in the case of a Co-located CoA and FA-CoA, the mobile node MAY 470 reply with a Generic Notification Acknowledgement Message based on 471 the "A" flag in the notification message as follows: 473 If the notification message was initiated from the foreign agent to 474 the mobile node ("MD" value is set to 4), the ordering of the 475 extension is: any non-authentication Extensions used only by the 476 foreign agent, followed by The Mobile-Foreign Authentication 477 extension defined in section 3.5.3 of [RFC3344]. 479 In the case of a FA-CoA, the source address is the mobile node's 480 address, the destination address is the foreign agent's address. 482 If the notification message was initiated from the home agent to the 483 mobile node ("MD" value is set to 0) and in the case of Co-located 484 CoA, the ordering of the extension is: any non-authentication 485 Extensions used only by the home agent, followed by the Mobile-Home 486 Authentication extension defined in section 3.5.2 of [RFC3344] 488 In the case of a FA-CoA, the source address is the mobile node's CoA 489 address and the destination address is the home agent's address ("MD" 490 value is set to 2), the ordering of the extension is: any non- 491 authentication Extensions used only by the home agent, followed by 492 the Mobile-Home Authentication Extension defined in section 3.5.2. of 493 [RFC3344], followed by any non-authentication Extensions used only by 494 the foreign agent, followed by The Mobile-Foreign Authentication 495 extension defined in section 3.5.3 of [RFC3344]. 497 4.4. Foreign Agent Consideration 499 The foreign agent cannot only relay generic notification message from 500 the home agent and mobile node, but it can also initiate a generic 501 notification message to the mobile node or home agent, but only when 502 there is a binding for the mobile node. 504 4.4.1. Receiving Generic Notification Message 506 If the foreign agent receives a notification message, and the "MD" 507 value is set to 0, it means that the home agent is asking the foreign 508 agent to relay the message to the mobile node. Otherwise, it means 509 that the target of the notification is the foreign agent. 511 If the "MD" value is set to 1, 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 will process it based on the specific rules 519 for that extension. The foreign agent MAY then reply with a Generic 520 Notification Acknowledgement message back to the home agent based on 521 the "A" flag in the notification message. 523 If the "MD" value is set to 0, the Foreign-Home Authentication 524 extension MUST be checked, and the foreign agent MUST check the 525 Authenticator value in the Extension. If no Foreign-Home 526 Authentication Extension is found, or if more than one Foreign-Home 527 Authentication Extension is found, or if the Authenticator is 528 invalid, the foreign agent MUST silently discard the Notification 529 message. If foreign agent accepts the home agent's generic 530 notification message, it MUST relay the Generic Notification to the 531 mobile node's home address as specified in the Home Address field of 532 the Generic Notification. The foreign agent MUST NOT modify any of 533 the fields beginning with the fixed portion of the Generic 534 Notification message through and including the Mobile-Home 535 Authentication Extension or other authentication extension supplied 536 by the home agent as an authorization-enabling extension for the 537 mobile node. Furthermore, the foreign agent MUST process and remove 538 any Extensions following the Mobile-Home Authentication Extension and 539 MAY append any of its own non-authentication Extensions of relevance 540 to the mobile node, if applicable, and MUST append the Mobile-Foreign 541 Authentication Extension, if the foreign agent shares a mobility 542 security association with the Mobile Node. 544 4.4.2. Sending Generic Notification Acknowledgement Messages 546 The foreign agent may need to either relay a Generic Notification 547 Acknowledgemnt message between the mobile node and the home agent or 548 send one as a response to a notification messsage that was sent to 549 it. In both cases, the Generic Notification Acknowledgement Message 550 is defined as follows: 552 The source address is the foreign agent address, the destination 553 address is home agent address. 555 If the foreign agent is only relaying this message to the home agent, 556 the foreign agent it MUST NOT modify any of the fields beginning with 557 the fixed portion of the Generic Notification Acknowledgement through 558 and including the Mobile-Home Authentication Extension or other 559 authentication extension supplied by the home agent as an 560 authorization-enabling extension for the mobile node. Furthermore, 561 the foreign agent MUST process and remove any Extensions following 562 the Mobile-Home Authentication Extension and MAY append any of its 563 own non-authentication Extensions of relevance to the home agent, if 564 applicable. It MUST also append the Foreign-Home Authentication 565 Extension, if the foreign agent shares a mobility security 566 association with the home agent. 568 If the notification message is from the home agent to the foreign 569 agent then the "MD" value is set to 1 and the ordering of the 570 extension is: any non-authentication Extensions used only by the home 571 agent, followed by The Foreign-Home Authentication extension defined 572 in section 3.5.4 of [RFC3344]. 574 4.4.3. Sending Generic Notification Messages 576 If the foreign agent is initiating a notification to the mobile node 577 using the generic notification message, it MAY also notify the home 578 agent as well. 580 In the message to the mobile node, the source address is the foreign 581 agent address, the destination address is the mobile node's address, 582 the "MD" value is set to 4, and the ordering of the extension is: the 583 notification extension, followed by any non-authentication Extensions 584 used only by the mobile node, followed by The Mobile-Foreign 585 Authentication extension defined in section 3.5.3 of [RFC3344]. 586 Computing Authentication Extension Value is the same as section 3.5.1 587 of [RFC3344] except the payload is the notification other than 588 registration. 590 In the message to the home agent, the source address is the foreign 591 agent's address, the destination address is the home agent's address 592 (the "MD" value is set to 5), and the ordering of the extension is: 593 notification extension, followed by any non-authentication Extensions 594 used only by the home agent, followed by The Foreign-Home 595 Authentication extension defined in section 3.5.4 of [RFC3344]. 596 Computing Authentication Extension Value is the same as section 3.5.1 597 of [RFC3344] except the payload is the notification other than 598 registration. 600 4.4.4. Receiving Generic Notification Acknowledgement Messages 602 In the case of a FA-CoA, if the foreign agent receives this message, 603 and the "MD" value is set to 3, it means that the notification 604 acknowledgement message came from the mobile node, otherwise it came 605 from the home agent. 607 If the "MD" value is set to 1, and the foreign agent accepted this 608 message, the Foreign-Home Authentication extension MUST be checked, 609 and the home agent MUST check the Authenticator value in the 610 Extension. If no Foreign-Home Authentication Extension is found, or 611 if more than one Foreign-Home Authentication Extension is found, or 612 if the Authenticator is invalid, the foreign agent MUST silently 613 discard the Notification Acknowledgement message. If the foreign 614 agent accepted this message, the home agent MAY also process it based 615 on the notification event. 617 If the "MD" value is set to 3, and the foreign agent accepted this 618 message, the Mobile-Foreign Authentication extension MUST be checked, 619 and the foreign agent MUST check the Authenticator value in the 620 Extension. If no Mobile-Foreign Authentication Extension is found, 621 or if more than one Mobile-Foreign Authentication Extension is found, 622 or if the Authenticator is invalid, the foreign agent MUST silently 623 discard the Notification Acknowledgement message. If the foreign 624 agent accepted this message, the foreign agent MAY also process it 625 based on the notification event. 627 In the case of a FA-CoA and if the "MD" value is set to 2, if the 628 foreign agent received this message, the Mobile-Foreign 629 Authentication extension MUST be checked, and the foreign agent MUST 630 check the Authenticator value in the Extension. If no Mobile-Foreign 631 Authentication Extension is found, or if more than one Mobile-Foreign 632 Authentication Extension is found, or if the Authenticator is 633 invalid, the foreign agent MUST silently discard the Notification 634 Acknowledgement message. If foreign agent accepted the mobile node's 635 Generic Notification Acknowledgement message, it MUST relay this 636 message to the home agent. The foreign agent MUST NOT modify any of 637 the fields beginning with the fixed portion of the Generic 638 Notification Acknowledgement message through and including the 639 Mobile-Home Authentication Extension or other authentication 640 extension supplied by the home agent as an authorization-enabling 641 extension for the mobile node. Furthermore, the foreign agent MUST 642 process and remove any Extensions following the Mobile-Home 643 Authentication Extension and MAY append any of its own non- 644 authentication Extensions of relevance to the home agent, if 645 applicable, and MUST append the Foreign-Home Authentication 646 Extension, if the foreign agent shares a mobility security 647 association with the home agent. 649 4.5. Home Agent Consideration 651 The Home agent MAY initiate a generic notification message to both 652 the mobile node and foreign agent, and it also MAY receive a generic 653 notification acknowledgement message from both the foreign agent and 654 mobile node. The home agent also MAY receive a generic notification 655 message from the foreign agent, but only when there is a binding for 656 a mobile node. If the home agent receives a notification message 657 from a foreign agent and there is no corresponding mobile node 658 registration, the home agent should drop the notification message. 660 4.5.1. Sending Generic Notification Messages 662 In the case of a FA-CoA, the home agent may either send a 663 notification message to notify the foreign agent, or have the foreign 664 agent relay the notification message to the mobile node if the mobile 665 node needs to be notified. 667 If the message is from the home agent to the foreign agent, the 668 source address is the home agent's address, and the destination 669 address is the foreign agent's address 670 If the foreign agent is working only as a relay agent, the "MD" value 671 is set to 0, and the ordering of the extension is: the notification 672 extension, followed by any non-authentication extension expected to 673 be used by mobile node, followed by Mobile-Home Authentication 674 Extension defined in section 3.5.2. of [RFC3344], followed by any 675 non-authentication Extensions used only by the foreign agent, 676 followed by The Foreign-Home Authentication extension defined in 677 section 3.5.4 of [RFC3344]. Computing Authentication Extension Value 678 is the same as section 3.5.1 of [RFC3344]. 680 If the foreign agent is the target of this notification message, then 681 the "MD" value is set to 1, and the ordering of the extension is: the 682 notification extension, followed by any non-authentication Extensions 683 used only by the foreign agent, followed by The Foreign-Home 684 Authentication extension defined in section 3.5.4 of [RFC3344]. 685 Computing Authentication Extension Value is the same as section 3.5.1 686 of [RFC3344]. 688 In the case of a Co-located CoA, the home agent MAY send a 689 notification message directly to the mobile node if it needs to be 690 notified. The "MD" value is set to 0, and the ordering of the 691 extension is: the notification extension, followed by any non- 692 authentication extension expected to be used by mobile node, followed 693 by Mobile-Home Authentication Extension defined in section 3.5.2. of 694 [RFC3344]. 696 4.5.2. Receiving Generic Notification Acknowledgement Messages 698 In the case of a FA-CoA, if the home agent receives this message, and 699 the "MD" value is set to 2, it means that the notification 700 acknowledgement message came from mobile node, otherwise it came from 701 the foreign agent. 703 If the "MD" value is set to 5, and the home agent accepted this 704 message, the home agent MAY also process it based on the notification 705 event. The Foreign-Home Authentication extension MUST be checked, 706 and the home agent MUST check the Authenticator value in the 707 Extension. If no Foreign-Home Authentication Extension is found, or 708 if more than one Foreign-Home Authentication Extension is found, or 709 if the Authenticator is invalid, the home agent MUST silently discard 710 the Notification Acknowledgement message. 712 If the "MD" value is set to 2, and the home agent accepted this 713 message, the Mobile-Home Authentication extension MUST be checked, 714 and the home agent MUST check the Authenticator value in the 715 Extension. If no Mobile-Home Authentication Extension is found, or 716 if more than one Mobile-Home Authentication Extension is found, or if 717 the Authenticator is invalid, the home agent MUST silently discard 718 the Notification Acknowledgement message. If the home agent accepted 719 this message, the home agent MAY also process it based on the 720 notification event. 722 In the case of a Co-located CoA, if the home agent received this 723 message, the Mobile-Home Authentication extension MUST be checked, 724 and the home agent MUST check the Authenticator value in the 725 Extension. If no Mobile-Home Authentication Extension is found, or 726 if more than one Mobile-Home Authentication Extension is found, or if 727 the Authenticator is invalid, the home agent MUST silently discard 728 the Notification Acknowledgement message. 730 4.5.3. Receiving Generic Notification Messages 732 The home agent MAY receive a generic notification message sent from 733 the foreign agent. When the home agent receives this message, the 734 Foreign-Home Authentication extension MUST be checked, and the home 735 agent MUST check the Authenticator value in the Extension. If no 736 Foreign-Home Authentication Extension is found, or if more than one 737 Foreign-Home Authentication Extension is found, or if the 738 Authenticator is invalid, the home agent MUST silently discard the 739 Notification message. If home agent accepts the foreign agent's 740 generic notification message, it will process it based on the 741 notification extension. Furthermore, the home agent MAY reply with a 742 Generic Notification Acknowledgement message back to the foreign 743 agent based on the "A" flag in the notification message. 745 4.5.4. Sending Generic Notification Acknowledgement Messages 747 If the generic notification message came from the foreign agent only, 748 the home agent MAY reply with a generic notification acknowledgement 749 message to the foreign agent based on the "A" flag in the 750 notification message. If the "A" flag is set in the notification 751 message, then the home agent MUST send a Notification Acknowledgement 752 message. The message is as follows: The source address is home 753 agent's address, the destination address is the foreign agent's 754 address, the "MD" value is set to 1. The ordering of the extension 755 is: any non-authentication Extensions used only by the foreign agent, 756 followed by The Foreign-Home Authentication extension defined in 757 section 3.5.4 of [RFC3344]. 759 5. Usage Example 761 There are several applications that could use this generic 762 notification message. for example, during handover between CDMA 2000 763 1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be 764 removed on the foreign agent (PDSN) to avoid over-charging 765 subscribers. Other applications such as registration revocation, 766 home agent switch over, NEMO prefix changes, service or billing 767 related events, load balancing where the home agent wants to move 768 some of the registered mobile nodes to other home agents, service 769 termination due to end of prepaid time, and service interruption due 770 to system maintenance. 772 Here we give a example of using revocation extension and describe 773 some possible event which could use the generic string extension 774 [RFC3344]based on this notification mechanism also. There is also 775 the possibility that this notification message could carry many 776 extensions at once. A new VSE extension could be defined to support 777 this notification message. 779 5.1. Revocation Extension 781 If one agent wants to notify another agent about registration 782 revocation [RFC3543], it could easily be carried by a generic 783 notification message and generic notification acknowledgement by 784 specifying the exact "Subtype" in the two messages. 786 5.2. Generic String Extension 788 In some case, the home agent or foreign agent needs to notify the 789 mobile node about service termination due to the end of prepaid time, 790 or service interruption due to system maintenance. This information 791 could be defined based on a string [RFC4917]which is recognized by 792 the mobile node easily. An example would be "Maintenance Stopping", 793 "Prepaid Expire". These string MUST be strictly defined so they 794 could be easily understood by all of the network entities. "Subtype" 795 number would need to be decided by the working group. 797 6. IANA Considerations 799 This document describes two new messages, the Generic Notification 800 message, section 4.1 and the Generic Notification Acknowledgement 801 message, section 4.2. These two messages should be allocated from 802 the same address space used by the Registration Request and 803 Registration Reply messages in [RFC3344]. The subtype of these two 804 messages indicate what kind of information is carried and will be 805 under assigned by IANA namespace. 807 This document creates a new IANA registry for the Subtype field In 808 the Generic Notification and Generic Notification Acknowledgement 809 messages. New values should be allocated by Standards Actions or 810 IETF Consensus. This document reserves two values for the Subtype 811 field 813 0 Reserved 815 1 Information carried in Vendor specific extensions 817 7. Security Considerations 819 This specification operates in the security constraints and 820 requirements of [RFC3344]. It extends the operations of mobile node, 821 home agent and foreign agent defined in [RFC3344] to notify each 822 other about some events. The Generic Notification message defined in 823 the specification could carry information that modifies the mobility 824 bindings. Therefore the message MUST be integrity protected. Replay 825 protection MUST also be guaranteed. 827 RFC 3344 provides replay protection only for registration requests 828 sent by the mobile node. There is no mechanism for replay protection 829 for messages initiated by a Foreign Agent. The 64-bit Identification 830 field specified in this document for the Generic Notification message 831 is used to provide replay protection for the notification messages 832 initiated by the Foreign Agent. 834 8. Normative References 836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 837 Requirement Levels", BCP 14, RFC 2119, March 1997. 839 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 840 August 2002. 842 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 843 Mobile IPv4", RFC 3543, August 2003. 845 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 846 String Extension", RFC 4917, June 2007. 848 Authors' Addresses 850 Hui Deng 851 China Mobile 852 53A,Xibianmennei Ave., 853 Xuanwu District, 854 Beijing 100053 855 China 857 Email: denghui@chinamobile.com 859 Henrik Levkowetz 860 Ericsson Research 861 Torshamsgatan 23 862 S-164 80, Stockholm 863 SWEDEN 865 Email: henrik@levkowetz.com 867 Vijay Devarapalli 868 Azaire Networks 869 4800 Great America Pkwy 870 Santa Clara, CA 95054 871 USA 873 Email: vijay.devarapalli@azairenet.com 875 Sri Gundavelli 876 Cisco Systems 877 170 W.Tasman Drive 878 San Jose, CA 95134 879 USA 881 Email: sgundave@cisco.com 883 Brian Haley 884 Hewlett-Packard Company 885 110 Spitbrook Road 886 Nashua, NH 03062 887 USA 889 Email: brian.haley@hp.com 891 Full Copyright Statement 893 Copyright (C) The IETF Trust (2008). 895 This document is subject to the rights, licenses and restrictions 896 contained in BCP 78, and except as set forth therein, the authors 897 retain all their rights. 899 This document and the information contained herein are provided on an 900 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 901 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 902 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 903 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 904 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 905 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 907 Intellectual Property 909 The IETF takes no position regarding the validity or scope of any 910 Intellectual Property Rights or other rights that might be claimed to 911 pertain to the implementation or use of the technology described in 912 this document or the extent to which any license under such rights 913 might or might not be available; nor does it represent that it has 914 made any independent effort to identify any such rights. Information 915 on the procedures with respect to rights in RFC documents can be 916 found in BCP 78 and BCP 79. 918 Copies of IPR disclosures made to the IETF Secretariat and any 919 assurances of licenses to be made available, or the result of an 920 attempt made to obtain a general license or permission for the use of 921 such proprietary rights by implementers or users of this 922 specification can be obtained from the IETF on-line IPR repository at 923 http://www.ietf.org/ipr. 925 The IETF invites any interested party to bring to its attention any 926 copyrights, patents or patent applications, or other proprietary 927 rights that may cover technology that may be required to implement 928 this standard. Please address the information to the IETF at 929 ietf-ipr@ietf.org. 931 Acknowledgment 933 Funding for the RFC Editor function is provided by the IETF 934 Administrative Support Activity (IASA).