idnits 2.17.1 draft-ietf-mip4-generic-notification-message-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2010) is 5037 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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 O. Levkowetz 5 Expires: January 13, 2011 Netnod 6 V. Devarapalli 7 WiChorus 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 July 12, 2010 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-15 17 Abstract 19 This document specifies protocol enhancements that allow Mobile IPv4 20 entities to send and receive explicit notification messages using a 21 Mobile IPv4 message type designed for this purpose. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 13, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Notification Message - Usage Scenarios . . . . . . . . . . . . 7 72 3.1. Notification Message - Examples . . . . . . . . . . . . . 7 73 3.2. Notification Message - Topology . . . . . . . . . . . . . 7 74 3.2.1. Notification Message between a Home Agent and a 75 Mobile Node . . . . . . . . . . . . . . . . . . . . . 8 76 3.2.2. Notification Message between a Foreign Agent and a 77 Mobile Node . . . . . . . . . . . . . . . . . . . . . 8 78 3.2.3. Notification Message between a Home Agent and a 79 Foreign Agent . . . . . . . . . . . . . . . . . . . . 9 80 4. Generic Notification Message and Considerations . . . . . . . 10 81 4.1. Generic Notification Message . . . . . . . . . . . . . . . 10 82 4.2. Generic Notification Acknowledgment Message . . . . . . . 13 83 4.3. Notification Retransmission . . . . . . . . . . . . . . . 16 84 4.4. Mobile Node Consideration . . . . . . . . . . . . . . . . 17 85 4.4.1. Receiving Generic Notification Messages . . . . . . . 17 86 4.4.2. Sending Generic Notification Acknowledgement 87 Message . . . . . . . . . . . . . . . . . . . . . . . 18 88 4.4.3. Sending Generic Notification Messages . . . . . . . . 19 89 4.4.4. Receiving Generic Notification Acknowledgement 90 Messages . . . . . . . . . . . . . . . . . . . . . . . 20 91 4.5. Foreign Agent Consideration . . . . . . . . . . . . . . . 20 92 4.5.1. Receiving Generic Notification Message . . . . . . . . 20 93 4.5.2. Sending Generic Notification Acknowledgement 94 Messages . . . . . . . . . . . . . . . . . . . . . . . 22 95 4.5.3. Sending Generic Notification Messages . . . . . . . . 23 96 4.5.4. Receiving Generic Notification Acknowledgement 97 Messages . . . . . . . . . . . . . . . . . . . . . . . 24 98 4.6. Home Agent Consideration . . . . . . . . . . . . . . . . . 24 99 4.6.1. Sending Generic Notification Messages . . . . . . . . 25 100 4.6.2. Receiving Generic Notification Acknowledgement 101 Messages . . . . . . . . . . . . . . . . . . . . . . . 25 102 4.6.3. Receiving Generic Notification Messages . . . . . . . 26 103 4.6.4. Sending Generic Notification Acknowledgement 104 Messages . . . . . . . . . . . . . . . . . . . . . . . 27 105 5. Future Extensibility . . . . . . . . . . . . . . . . . . . . . 29 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 107 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 108 7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 31 109 7.1.1. Replay Protection using Timestamps . . . . . . . . . . 32 110 7.1.2. Replay Protection using Nonces . . . . . . . . . . . . 33 111 7.2. Non-authentication Extensions Handling in Foreign Agent . 33 112 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 35 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 118 1. Introduction 120 In some situations, there is a need for Mobile IPv4 entities, such as 121 the home agent(HA), foreign agent(FA) and mobile node(MN) to send and 122 receive asynchronous notification messages during a mobility session. 123 'Asynchronous messages' in this context is used to mean messages 124 which are not synchronous with the Registration Request and 125 Registration Reply messages of the base Mobile IP Specification 126 [RFC3344]. The base Mobile IP Specification does not have a 127 provision for this. 129 This document defines a generic message and a notification model that 130 can be used by Mobile IPv4 entities to send various notifications. 131 It also defines a corresponding acknowledgement message to allow for 132 reliable delivery of notifications. Only the following extensions 133 may be present in these new messages, as defined by this document: 135 - MN-HA Authentication Extension 137 - MN-FA Authentication Extension 139 - FA-HA Authentication Extension 141 - Message String Extension 143 The semantics of receiving a generic notification message with a 144 Message String Extension are null; i.e., it has no effect on the 145 state of a mobile node's existing registration. See Section 3.1 for 146 some application examples that motivate the new messages defined in 147 this document. 149 2. Terminology 151 It is assumed that the reader is familiar with the terminology used 152 in [RFC4917], [RFC3344]. In addition, this document frequently uses 153 the following terms: 155 Notification Message 156 A message from a mobility agent to a MN or other mobility 157 agent to asynchronously notify it about an event that is 158 relevant to the mobility service it is currently providing. 160 Generic Notification Message 161 A Notification Message in the context of Mobile IPv4 with a 162 well-defined envelope format and extensibility, and with 163 certain limitations on how extensions may be defined and 164 used, but otherwise generally available for notification 165 purposes within the Mobile IPv4 protocol. Abbreviated 166 'GNM' in this document. 168 Generic Notification Acknowledgement Message 169 An acknowledgement of a received Generic Notification 170 Message. Abbreviated 'GNAM' in this document. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119, [RFC2119]. 176 3. Notification Message - Usage Scenarios 178 3.1. Notification Message - Examples 180 The simplest usage scenario for a notification message is one where 181 the notification has no semantic meaning within the protocol; it is 182 only carrying a message which can be displayed to a user or an 183 operator (depending on which is the receiving entity -- see more on 184 this below, in Section 3.2). Examples of such usage is messages from 185 operator to user about billing or service related events ("You have 186 used nearly all of your prepaid quota; there is only XX MB left -- 187 please purchase further service if you are going to need it."; or 188 "You have now used data transfer services for the amount of $XXX 189 since your last bill; this is above the notification threshold for 190 your account.") or messages about service interruptions, and more. 191 These examples are all supported by the use of the Mobile IPv4 192 Generic Notification Message together with the Message String 193 Extension, as defined in this document. 195 There are also other examples, which cannot be implemented solely 196 using the messages and extensions defined in this document. Some of 197 these are described briefly below, and covered slightly more 198 extensively in Section 5. 200 One example of an application of an extended Generic Notification 201 Message is that during handover between CDMA 2000 1x EV-DO and 202 Wireless LAN, the PPP resource on the CDMA side has to be removed on 203 the FA (PDSN) to avoid over-charging subscribers. To address this, 204 the Registration Revocation Message was defined in [RFC3543], but it 205 would have been preferable to have had it defined as a separate 206 message (i.e., the Generic Notification Message) with a Registration 207 Revocation extension. 209 Other applications are HA switch over (before HA decide to go off- 210 line it would like to notify the MNs to register with another 211 candidate HA), NEMO prefix changes (MN is notified by HA about NEMO 212 prefix changes and service or billing related events, which is an 213 operational requirement), Load balancing (HA wants to move some of 214 the registered MNs to other HAs), Service Termination (due to end of 215 prepaid time), and Service Interruption (due to system maintenance). 217 3.2. Notification Message - Topology 219 There are several scenarios where a mobility agent could initiate 220 notification events. Some of these are described in the following 221 Sections. 223 3.2.1. Notification Message between a Home Agent and a Mobile Node 225 3.2.1.1. Mobile Registered using a Foreign Agent Care-of Address 227 In this case, the HA cannot directly notify the MN, but must send the 228 notification via the FA, vice versa. 230 +----+ notification +----+ notification +----+ 231 | MN |<================>| FA |<=============>| HA | 232 +----+ +----+ +----+ 234 Figure 1: HA notifies MN or MN notifies HA through FA 236 3.2.1.2. Mobile Registered using a Co-located Care-of Address 238 In this case, the MN has registered with the home agent directly, so 239 the notification message can go directly to the MN. 241 The notification mechanism as specified here does not support the 242 case of Co-located CoA mode with registration through a FA (due to 243 the 'R' bit being set in the FA's advertisement messages). 245 +----+ notification +----+ 246 | MN |<===================================>| HA | 247 +----+ +----+ 249 Figure 2: HA directly notifies MN or MN directly notifies HA 251 3.2.2. Notification Message between a Foreign Agent and a Mobile Node 253 There are two cases where a FA may send notification messages to a 254 MN, one where it is relaying a message, the other where the 255 notification is triggered by a message from another network entity, 256 for example a AAA node(notification messages between a AAA entity and 257 the FA could be based on RADIUS or Diameter, but this is out of scope 258 for this document). If the notification is initiated by a FA, the FA 259 may need to also notify the HA about the event. 261 +----+ notification +----+ trigger +--------+ 262 | MN |<================>| FA |<=============| AAA | 263 +----+ +----+ +--------+ 264 || notification +----+ 265 ================>| HA | 266 +----+ 268 Figure 3: FA notifies MN 270 3.2.3. Notification Message between a Home Agent and a Foreign Agent 272 The HA may also need to send a notification to the FA, but not to the 273 MN, The FA may also need to send a notification to the HA, as 274 illustrated below: 276 +----+ notification +----+ 277 | FA |<=============>| HA | 278 +----+ +----+ 280 Figure 4: HA notifies FA or FA notifies HA 282 4. Generic Notification Message and Considerations 284 This section describes in detail the Generic Notification Message 285 (GNM), Generic Notification Acknowledgement Message (GNAM), and some 286 considerations related to the handling of these messages in the MN, 287 FA and HA. 289 The MN and HA MUST maintain the following information, FA also needs 290 to maintain both the HA's and MN's direction the below information: 292 - the IP source address of the Registration Request/Reply 294 - the IP destination address of the Registration Request/Reply 296 - the UDP source port of the Registration Request/Reply 298 - the UDP destination port of the Registration Request/Reply 300 The sending node always sends the GNM message following the same 301 procedure for sending Registration Request as in Section 3.3 of 302 [RFC3344] and the receiving node follows the same procedure for 303 Registration Reply as in Section 3.4. of [RFC3344] when sending GNAM. 305 4.1. Generic Notification Message 307 A GNM is sent by a mobility agent to inform another mobility agent, 308 or a MN, of MIP-related information in the form of a Message String 309 Extension [RFC4917]. These messages MUST use the same IP and UDP 310 headers as any previous Registration Request(RRQ) or Reply (RRP) 311 message to the same entity. This would support NAT traversal and 312 ensure same security association used for GNM/GNAM and RRQ/RRP. The 313 GNM is defined as follows: 315 IP Fields: 317 Source Address Typically copied from the destination 318 address of the last Registration Reply/ 319 Request message that the agent received from 320 the agent to which it is sending the GNM. 322 Destination Address Copied from the source address of the last 323 Registration Reply/Request message that the 324 agent received from the agent to which it is 325 sending the GNM. 327 UDP Fields: 329 Source Port Typically copied from the destination port 330 of the last Registration Reply/Request 331 message that the agent received from the 332 agent to which it is sending the GNM. 334 Destination Port Copied from the source port of the last 335 Registration Reply/Request message that the 336 agent received from the agent to which it is 337 sending the GNM. 339 The UDP header is followed by the Mobile IP fields shown below: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type | MD |A| Reserved | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Home Address | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Home Agent Address | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Care-of Address | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | | 353 + Identification + 354 | | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Extensions... 357 +-+-+-+-+-+-+-+-+-+-+-+-+- 359 Type (To be assigned by IANA) 361 MD: Message Direction 363 This memo defines the semantics of the following MD field value: 365 0 -- Message sent by the HA to the MN 367 1 -- Message sent by the HA to the FA 369 2 -- Message sent by the MN to the HA 371 3 -- Message sent by the MN to the FA 373 4 -- Message sent by the FA to the MN 374 5 -- Message sent by the FA to the HA 376 A 378 This bit indicates whether the notification message MUST be 379 acknowledged by the recipient. If "A" bit has been set during the 380 message, but the sender doesn't receive any acknowledgement 381 message, then the sender will have to re-send the notification 382 message again. 384 Set to "1" to indicate that acknowledgement is required. 386 Set to "0" to indicate that acknowledgement is optional. 388 Reserved 390 MUST be sent as 0, and ignored when received. 392 Home Address 394 The home IP address of the mobile node. 396 Home Agent Address 398 The IP address of the mobile node's HA. 400 Care-of Address 402 The mobile node's care-of address, either the Co-located Care-of 403 Address or the foreign agent care-of address. 405 Identification 407 A 64-bit number, constructed by the sender, used for matching GNM 408 with GNAM, and for protecting against replay attacks of 409 notification messages. See Section 7.1.1 and Section 7.1.2 for 410 more on the use of timestamps and nonces in this field. Support 411 for the use of timestamps is mandatory and support for nonces is 412 optional. 414 Extensions 416 The fixed portion of the GNM is followed by one or more extensions 417 which may be used with this message, and by one or more 418 authentication extensions as defined in Section 3.5 of [RFC3344]. 420 Apart from the Authentication Extensions mentioned below, only one 421 extension is defined in this document as permitted for use with 422 the GNM: the Message String Extension defined in [RFC4917]. 424 This document requires the MN-HA Authentication Extension (AE) to 425 be used when this message is sent between the MN and the HA; MN-FA 426 AE and FA-HA AE are optional. This document also requires the use 427 of the MN-FA AE when this message is sent between the MN and the 428 FA; where the MN-HA AE and FA-HA AE are not needed. This document 429 finally require the use of the FA-HA AE when this message is sent 430 between the FA and the HA, and the MN-HA AE and MN-FA AE are not 431 needed. This could be determined based on the "MD" value. 432 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 433 order of these extensions as they appear in Mobile IPv4 RRQ and 434 RRP messages. The same rules are applicable to GNM and GNAM. 436 4.2. Generic Notification Acknowledgment Message 438 A GNAM is sent by mobility agents or MNs to indicate the successful 439 receipt of a GNM. 441 IP Fields: 443 Source Address Typically copied from the destination 444 address of the GNM to which the agent is 445 replying. 447 Destination Address Copied from the source address of the GNM to 448 which the agent is replying. 450 UDP Fields: 452 Source Port Copied from the destination port of the 453 corresponding GNM. 455 Destination Port Copied from the source port of the 456 corresponding GNM. 458 The UDP header is followed by the Mobile IP fields shown below: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | MD | code | Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Home Address | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Home Agent Address | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Care-of Address | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 + Identification + 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Extensions... 476 +-+-+-+-+-+-+-+-+-+-+-+-+- 478 Type (To be assigned by IANA) 480 MD: Message Direction 482 This memo defines the semantics of the following MD field value: 484 0 -- Message sent by the HA to the MN 486 1 -- Message sent by the HA to the FA 488 2 -- Message sent by the MN to the HA 490 3 -- Message sent by the MN to the FA 492 4 -- Message sent by the FA to the MN 494 5 -- Message sent by the FA to the HA 496 code 498 A value indicating the result of the GNM. See below for a list of 499 currently defined Code values. 501 Notification successful 503 0 -- notification accepted 505 Notification denied by the HA 506 128 -- reason unspecified 508 129 -- administratively prohibited 510 130 -- insufficient resources 512 131 -- mobile node failed authentication 514 132 -- foreign agent failed authentication 516 133 -- notification Identification mismatch 518 Notification denied by the FA 520 64 -- reason unspecified 522 65 -- administratively prohibited 524 66 -- insufficient resources 526 67 -- mobile node failed authentication 528 68 -- home agent failed authentication 530 69 -- notification Identification mismatch 532 Notification denied by the mobile node 534 192 -- reason unspecified 536 193 -- administratively prohibited 538 194 -- insufficient resources 540 195 -- foreign agent failed authentication 542 196 -- home agent failed authentication 544 197 -- notification Identification mismatch 546 Home Address 548 The home IP address of the mobile node. 550 Home Agent Address 552 The IP address of the sender's home agent. 554 Care-of Address 556 The mobile node's care-of address, either the Co-located Care-of 557 Address or the foreign agent care-of address. 559 Identification 561 A 64-bit number used for matching GNM message with GNAM message 562 and for protecting against replay attacks of registration 563 messages. See Section 7.1.1 and Section 7.1.2 for more on the use 564 of timestamps and nonces in this field. Support for the use of 565 timestamps is mandatory and support for nonces is optional. The 566 value is based on the Identification field from the GNM message 567 from the sender, and on the style of replay protection used in the 568 security context between the sender and its receiver (defined by 569 the mobility security association between them, and SPI value in 570 the authorization-enabling extension). 572 Extensions 574 The fixed portion of the GNAM is followed by one or more 575 extensions which may be used with this message, and by one or more 576 authentication extensions as defined in Section 3.5 of [RFC3344]. 578 This document requires the MN-HA Authentication Extension (AE) to 579 be used when this message is sent between the MN and the HA; MN-FA 580 AE and FA-HA AE are optional. This document also requires the use 581 of the MN-FA AE when this message is sent between the MN and the 582 FA; where the MN-HA AE and FA-HA AE are not needed. This document 583 finally requires the use of the FA-HA AE when this message is sent 584 between the FA and the HA, and the MN-HA AE and MN-FA AE are not 585 needed. This could be determined based on the "MD" value. 586 See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for the rules on the 587 order of these extensions as they appear in Mobile IPv4 RRQ and 588 RRP messages. The same rules are applicable to GNM and GNAM. 590 4.3. Notification Retransmission 592 If "A" flag has been set during the GNM message, but the sender 593 doesn't receive any GNAM message within a reasonable time, then 594 another GNM will be retransmitted. When timestamps are used, a new 595 registration Identification is chosen for each retransmission; Thus 596 it counts as a new GNM. When nonces are used, the unanswered GNM 597 message is retransmitted unchanged; thus the retransmission does not 598 count as a new GNM (Section 7.1). In this way a retransmission will 599 not require the receiver to re-synchronize with the sender by issuing 600 another nonce in the case in which the original GNM message (rather 601 than its GNAM message) was lost by the network. 603 The maximum time until a new GNM message is sent SHOULD be no greater 604 than the requested Lifetime of the last GNM message. The minimum 605 value SHOULD be large enough to account for the size of the messages, 606 twice the round trip time for transmission to the receiver, and at 607 least an additional 100 milliseconds to allow for processing the 608 messages before responding. The round trip time for transmission to 609 the receiver will be at least as large as the time required to 610 transmit the messages at the link speed of the sender's current point 611 of attachment. Some circuits add another 200 milliseconds of 612 satellite delay in the total round trip time to the receiver. The 613 minimum time between GNM MUST NOT be less than 1 second. Each 614 successive retransmission timeout period SHOULD be at least twice the 615 previous period, as long as that is less than the maximum as 616 specified above. 618 4.4. Mobile Node Consideration 620 It is possible that the MN MAY receive a GNM from a FA or HA. Both 621 in the case of FA-CoA and Co-located CoA, the MN MAY reply with a 622 GNAM based on the "A" flag in the GNM message. 624 4.4.1. Receiving Generic Notification Messages 626 When the MN is using FA-CoA and receives a Notification message, if 627 the "MD" value is 0, it means that the notification message came from 628 the HA. If the "MD" value is 4, the notification came from the FA. 630 If this notification message came from a FA and the MN accepts the 631 FA's GNM, then it will process the notification extension according 632 to the specific rules for that extension. 634 The MN MUST check for the presence of an authorization-enabling 635 extension, and perform the indicated authentication. Exactly one 636 authorization-enabling extension MUST be present in the GNM, if this 637 message came from a FA, then MN-FA AE MUST be present. If no MN-FA 638 AE is found, or if more than one MN-FA AE is found, or if the 639 Authenticator is invalid, then the MN MUST reject the GNM and MAY 640 send a GNAM to the FA with Code 195, including an Identification 641 field computed in accordance with the rules specified in Section 7.1. 642 The MN MUST do no further processing with such a notification, though 643 it SHOULD log the error as a security exception. 645 The MN MUST check that the Identification field is correct using the 646 context selected by the SPI within mandatory authentication extension 647 like MN-FA AE or MN-HA AE. See Section 7.1 for a description of how 648 this is performed. If incorrect, the MN MUST reject the GNM and MAY 649 send a GNAM to the initiator with Code 197, including an 650 Identification field computed in accordance with the rules specified 651 in Section 7.1. The MN MUST do no further processing with such a 652 notification, though it SHOULD log the error as a security exception. 654 The MN MUST also check that the extensions present in the Generic 655 Notification Message are permitted for use with the GNM. If not, the 656 MN MUST silently discard the message. It MUST NOT do any further 657 processing with such a notification, though it SHOULD log the error. 659 After this, the MN MAY reply GNAM back to the FA. If the "A" flag is 660 set in the GNM, then the MN MUST send the GNAM. 662 If this notification message came from the HA, relayed by the FA, or 663 is a Co-located CoA, then the MN-HA AE MUST be checked and the MN 664 MUST check the Authenticator value in the Extension. If no MN-HA AE 665 is found, or if more than one MN-HA AE is found, or if the 666 Authenticator is invalid, then the MN MUST reject the GNM and MAY 667 send a GNAM to the initiator with Code 196, including an 668 Identification field computed in accordance with the rules specified 669 in Section 7.1. The MN MUST do no further processing with such a 670 notification, though it SHOULD log the error as a security exception. 671 If the MN accepts the HA's GNM, then it will process it according to 672 the specific rules for that extension. After that, the MN MAY reply 673 with a GNAM with Code 0 back to the HA based on the "A" flag in the 674 GNM. 676 4.4.2. Sending Generic Notification Acknowledgement Message 678 Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply 679 with a GNAM based on the "A" flag in the GNM as follows: 681 If the GNM was initiated from the FA to the MN ("MD" value is set to 682 4), then MN-FA AE MUST be the last extension in order to protect all 683 other non-authentication extensions as defined in Section 3.5.3 of 684 [RFC3344]. 686 In the case of a FA-CoA, the source address is the MN's address, the 687 destination address is the FA's address. 689 The Code field of the GNAM is chosen in accordance with the rules 690 specified in Section 4.2. When replying to an accepted notification, 691 a MN SHOULD respond with Code 0. 693 There are a number of reasons the MN might reject a notification such 694 as administrative in nature returning a GNAM with a code of 193, 695 similarly and provides the Code value 192 or 194 for the unspecified 696 reason and insufficient resources. 698 If the GNM was initiated from the HA to the MN ("MD" value is set to 699 0) and in the case of Co-located CoA, then MN-HA AE MUST be the last 700 extension in order to protect all other non-authentication extensions 701 as defined in Section 3.5.2 of [RFC3344] 703 In the case of a FA-CoA, the source address is the MN's HoA address 704 and the destination address is the FA's address ("MD" value is set to 705 2), the ordering of the extension is: any non-authentication 706 Extensions used only by the HA, followed by the MN-HA AE defined in 707 Section 3.5.2 of [RFC3344], followed by any non-authentication 708 Extensions used only by the FA, followed by the MN-FA AE defined in 709 Section 3.5.3 of [RFC3344]. 711 4.4.3. Sending Generic Notification Messages 713 The MN may either send a GNM to notify the FA or HA. 715 If the message is sent to the FA, then the source address is the MN's 716 address, and the destination address is the FA's address 718 If the FA is the target of this notification message, then the "MD" 719 value is set to 3, MN-FA AE MUST be the last extension in order to 720 protect all other non-authentication extensions. Computing 721 Authentication Extension Value is the same as Section 3.5.1 of 722 [RFC3344]. 724 If the FA is working only as a relay agent, then the "MD" value is 725 set to 2, and the ordering of the extension is: the notification 726 extension, followed by any non-authentication extension expected to 727 be used by HA, followed by MN-HA AE defined in Section 3.5.2 of 728 [RFC3344], followed by any non-authentication Extensions used only by 729 the FA, followed by The MN-FA AE defined in Section 3.5.3 of 730 [RFC3344]. Computing Authentication Extension Value is the same as 731 Section 3.5.1 of [RFC3344]. 733 In the case of a Co-located CoA, the MN MAY send a notification 734 message directly to the HA if it needs to be notified. The "MD" 735 value is set to 2, and the ordering of the extension is: the 736 notification extension, followed by any non-authentication extension 737 expected to be used by HA, followed by MN-HA AE defined in Section 738 3.5.2 of [RFC3344]. 740 The MN chooses the Identification field in accordance with the style 741 of replay protection it uses with its HA. This is part of the 742 mobility security association the MN shares with its HA. See 743 Section 7.1 for the method by which the MN computes the 744 Identification field. 746 4.4.4. Receiving Generic Notification Acknowledgement Messages 748 In the case of a FA-CoA, if the MN receives this message, and the 749 "MD" value is set to 0, it means that the GNAM came from HA 751 If the "MD" value is set to 4, then the MN-FA AE MUST be checked, and 752 the MN MUST check the Authenticator value in the Extension. If no 753 MN-FA AE is found, or if more than one MN-FA AE is found, or if the 754 Authenticator is invalid, then the MN MUST silently discard the GNAM. 756 In addition, the low-order 32 bits of the Identification field in the 757 GNAM MUST be compared to the low-order 32 bits of the Identification 758 field in the most recent GNM sent to the replying agent. If they do 759 not match, then the GNAM MUST be silently discarded. 761 If the "MD" value is set to 0, then the MN-HA AE MUST be checked, and 762 the MN MUST check the Authenticator value in the Extension. If no 763 MN-HA AE is found, or if more than one MN-HA AE is found, or if the 764 Authenticator is invalid, then the MN MUST silently discard the GNAM. 765 If the MN accepted this message, then the MN MAY also process it 766 based on the notification event. 768 In the case of a Co-located CoA, if the MN received this message, 769 then the MN-HA AE MUST be checked, and the MN MUST check the 770 Authenticator value in the Extension. If no MN-HA AE is found, or if 771 more than one MN-HA AE is found, or if the Authenticator is invalid, 772 then the MN MUST silently discard the Notification Acknowledgement 773 message. 775 4.5. Foreign Agent Consideration 777 The FA may initiate a GNM to the MN or the HA. Additionally, the FA 778 also relays GNM and GNAM messages between the MN and its HA as long 779 as there is an active binding for the MN at the FA. 781 4.5.1. Receiving Generic Notification Message 783 If the FA receives a GNM, and the "MD" value is set to 0, then it 784 means that the HA is asking the FA to relay the message to the MN. 785 If the "MD" value is set to 1, then it means that the target of the 786 notification is the FA. If the "MD" value is set to 2, then it means 787 that the MN is asking the FA to relay the message to the HA. If the 788 "MD" value is set to 3, then it means that the notification came from 789 the MN to the FA. 791 If the "MD" value is set to 0, then the FA MAY validate the FA-HA AE 792 if present. If the FA-HA AE is invalid, then all extensions between 793 the HA-MN AE and the HA-FA AE MUST be removed, FA SHOULD relay the 794 GNM to the MN's home address as specified in the Home Address field 795 of the GNM, MN will eventually validate the MN-HA AE to ensure that 796 all information sent to the MN is integrity protected. If the FA-HA 797 AE is valid, FA MUST relay the GNM to the MN's home address as 798 specified in the Home Address field of the GNM. The FA MUST NOT 799 modify any of the fields beginning with the fixed portion of the GNM 800 through the MN-HA AE or other authentication extension supplied by 801 the HA as an authorization-enabling extension for the MN. 803 Furthermore, the FA MUST process and remove any extensions following 804 the MN-HA AE. If the FA shares a mobility security association with 805 the MN, the FA MAY append any of its own non-authentication 806 extensions which of relevance to the MN. In this case, the FA MUST 807 append the MN-FA AE after these non-authentication extensions. 809 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 810 FA MUST check the Authenticator value in the Extension. If no FA-HA 811 AE is found, or if more than one FA-HA AE is found, or if the 812 Authenticator is invalid, the FA MUST reject the GNM and MAY send a 813 GNAM to the HA with Code 68, including an Identification field 814 computed in accordance with the rules specified in Section 7.1. The 815 FA MUST do no further processing with such a notification, though it 816 SHOULD log the error as a security exception. 818 The FA MUST check that the Identification field is correct using the 819 context selected by the SPI within mandatory FA-HA AE. See 820 Section 7.1 for a description of how this is performed. If 821 incorrect, the FA MUST reject the GNM and MAY send a GNAM to the 822 initiator with Code 69, including an Identification field computed in 823 accordance with the rules specified in Section 7.1. The FA MUST do 824 no further processing with such a notification, though it SHOULD log 825 the error as a security exception. 827 The FA MUST also check that the extensions present in the Generic 828 Notification Message are permitted for use with the GNM. If not, the 829 FA MUST silently discard the message. It MUST NOT do any further 830 processing with such a notification, though it SHOULD log the error. 832 If FA accepts the HA's GNM, it will process it based on the specific 833 rules for that extension. The FA MAY then reply with a GNAM with 834 Code 0 back to the MN based on the "A" flag in the GNM. 836 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 837 received this message, and if the MN-FA AE is present, the MN-FA AE 838 MUST be checked, and the FA MUST check the Authenticator value in the 839 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 840 found, or if the Authenticator is invalid, the FA MUST silently 841 discard the GNM message. If MN-FA is valid, FA MUST relay the GNM to 842 the HA's address as specified in the Home Agent Address field of the 843 GNM, HA will eventually validate the MN-HA AE to ensure that all 844 information sent to the HA is integrity protected. The FA MUST NOT 845 modify any of the fields beginning with the fixed portion of the GNM 846 through the MN-HA AE or other authentication extension supplied by 847 the MN as an authorization-enabling extension for the HA. 849 Furthermore, the FA MUST process and remove any Extensions following 850 the MN-HA AE, and MAY append any of its own non-authentication 851 Extensions of relevance to the HA if applicable, and MUST append the 852 FA-HA AE, if the FA shares a mobility security association with the 853 HA. 855 If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 856 FA MUST check the Authenticator value in the Extension which is the 857 same as the Section 3.7.2.1 of [RFC3344]. If no MN-FA AE is found, 858 or if more than one MN-FA AE is found, or if the Authenticator is 859 invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN 860 with Code 67, including an Identification field computed in 861 accordance with the rules specified in Section 7.1. The FA MUST do 862 no further processing with such a notification, though it SHOULD log 863 the error as a security exception. 865 The FA MUST check that the Identification field is correct using the 866 context selected by the SPI within mandatory MN-FA AE. See 867 Section 7.1 for a description of how this is performed. If 868 incorrect, the FA MUST reject the GNM and MAY send a GNAM to the 869 initiator with Code 69, including an Identification field computed in 870 accordance with the rules specified in Section 7.1. The FA MUST do 871 no further processing with such a notification, though it SHOULD log 872 the error as a security exception. 874 If FA accepts the MN's GNM, it will process it based on the specific 875 rules for that extension. The FA MAY then reply with a GNAM with 876 Code 0 back to the MN based on the "A" flag in the GNM. 878 4.5.2. Sending Generic Notification Acknowledgement Messages 880 The FA may need to either relay a GNAM message between the MN and the 881 HA or send one as a response to a GNM message that was sent to it. 882 In both cases, the GNAM message is defined as follows: 884 The source address is the FA address, the destination address is HA's 885 or MN's home address. 887 The Code field of the GNAM is chosen in accordance with the rules 888 specified in Section 4.2. When replying to an accepted notification, 889 a FA SHOULD respond with Code 0. 891 There are a number of reasons the FA might reject a notification such 892 as administrative in nature returning a GNAM with a code of 65, 893 similarly and provides the Code value 64 or 66 for the unspecified 894 reason and insufficient resources. 896 If the FA is only relaying this message to the HA, the FA MUST NOT 897 modify any of the fields beginning with the fixed portion of the GNAM 898 through the including the MN-HA AE or other authentication extension 899 supplied by the MN as an authorization-enabling extension for the MN. 900 Furthermore, the foreign agent MUST process and remove any Extensions 901 following the MN-HA AE. If the FA shares a mobility security 902 association with the HA, the FA MAY append any of its own non- 903 authentication extensions which of relevance to the HA, In this case 904 the FA MUST append the FA-HA AE after these non-authentication 905 extensions. 907 If the notification message is from the HA to the FA then the "MD" 908 value is set to 5 and the ordering of the extension is: any non- 909 authentication Extensions used only by the FA, followed by The FA-HA 910 AE defined in Section 3.5.4 of [RFC3344]. 912 If the notification message is from the MN to the FA then the "MD" 913 value is set to 4 and the ordering of the extension is: any non- 914 authentication Extensions used only by the FA, followed by The MN-FA 915 AE defined in Section 3.5.3 of [RFC3344]. 917 4.5.3. Sending Generic Notification Messages 919 If the FA is initiating a notification to the MN using the GNM, it 920 MAY also notify the HA as well. 922 In the message to the MN, the source address is the FA address, the 923 destination address is the MN's address, the "MD" value is set to 4, 924 and the ordering of the extension is: the notification extension, 925 followed by any non-authentication Extensions used only by the MN, 926 followed by The MN-FA AE defined in Section 3.5.3 of [RFC3344]. 927 Computing Authentication Extension Value is the same as Section 3.5.1 928 of [RFC3344] except the payload is the notification other than 929 registration. 931 In the message to the HA, the source address is the FA's address, the 932 destination address is the HA's address (the "MD" value is set to 5), 933 and the ordering of the extension is: notification extension, 934 followed by any non-authentication Extensions used only by the HA, 935 followed by The FA-HA AE defined in Section 3.5.4 of [RFC3344]. 936 Computing Authentication Extension Value is the same as Section 3.5.1 937 of [RFC3344] except the payload is the notification other than 938 registration. 940 4.5.4. Receiving Generic Notification Acknowledgement Messages 942 In the case of a FA-CoA, if the FA receives this message, and the 943 "MD" value is set to 3, it means that the notification 944 acknowledgement message came from the MN, otherwise it came from the 945 HA. 947 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 948 FA MUST check the Authenticator value in the Extension. If no FA-HA 949 AE is found, or if more than one FA-HA AE is found, or if the 950 Authenticator is invalid, the FA MUST silently discard the 951 Notification Acknowledgement message. If the FA accepted this 952 message, the FA MAY also process it based on the notification event. 954 If the "MD" value is set to 3, if the MN-FA AE is present, it MUST be 955 checked, and the FA MUST check the Authenticator value in the 956 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 957 found, or if the Authenticator is invalid, the FA MUST silently 958 discard the GNAM message. If the FA accepted this message, the FA 959 MAY also process it based on the notification event. 961 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 962 received this message, and if the MN-FA AE is present, the MN-FA AE 963 MUST be checked, and the FA MUST check the Authenticator value in the 964 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 965 found, or if the Authenticator is invalid, the FA MUST silently 966 discard the GNAM message. If FA accepted the MN's GNAM message, it 967 MUST relay this message to the HA. The FA MUST NOT modify any of the 968 fields beginning with the fixed portion of the GNAM message through 969 the including the MN-HA AE or other authentication extension supplied 970 by the HA as an authorization-enabling extension for the MN. 971 Furthermore, the FA MUST process and remove any Extensions following 972 the MN-HA AE and MAY append any of its own non-authentication 973 Extensions of relevance to the HA, if applicable, and MUST append the 974 FA-HA AE, if the FA shares a mobility security association with the 975 HA. 977 4.6. Home Agent Consideration 979 The HA MAY initiate a GNM message to both the mobile node and FA, and 980 it also MAY receive a GNAM message from both the FA and MN. The HA 981 also MAY receive a GNM message from the FA, but only when there is a 982 binding for a MN. If the HA receives a GNM from a FA and there is no 983 corresponding MN registration, the HA SHOULD drop the GNM message. 985 4.6.1. Sending Generic Notification Messages 987 In the case of a FA-CoA, the HA may either send a GNM to notify the 988 FA, or have the FA relay the GNM to the MN if the MN needs to be 989 notified. 991 If the message is from the HA to the FA, the source address is the 992 HA's address, and the destination address is the FA's address 994 If the FA is working only as a relay agent, the "MD" value is set to 995 0, and the ordering of the extension is: the notification extension, 996 followed by any non-authentication extension expected to be used by 997 MN, followed by MN-HA AE defined in Section 3.5.2 of [RFC3344], 998 followed by any non-authentication Extensions used only by the FA, 999 followed by The FA-HA AE defined in Section 3.5.4 of [RFC3344]. 1000 Computing Authentication Extension Value is the same as Section 3.5.1 1001 of [RFC3344]. 1003 If the FA is the target of this notification message, then the "MD" 1004 value is set to 1, and the ordering of the extension is: the 1005 notification extension, followed by any non-authentication Extensions 1006 used only by the FA, followed by The FA-HA AE defined in Section 1007 3.5.4 of [RFC3344]. Computing Authentication Extension Value is the 1008 same as Section 3.5.1 of [RFC3344]. 1010 In the case of a Co-located CoA, the HA MAY send a notification 1011 message directly to the MN if it needs to be notified. The "MD" 1012 value is set to 0, and the ordering of the extension is: the 1013 notification extension, followed by any non-authentication extension 1014 expected to be used by MN, followed by MN-HA AE defined in Section 1015 3.5.2 of [RFC3344]. 1017 4.6.2. Receiving Generic Notification Acknowledgement Messages 1019 In the case of a FA-CoA, if the HA receives this message, and the 1020 "MD" value is set to 2, it means that the GNAM message came from MN. 1022 If the "MD" value is set to 5, and the HA accepted this message, the 1023 HA MAY also process it based on the notification event. The FA-HA AE 1024 MUST be checked, and the HA MUST check the Authenticator value in the 1025 Extension. If no FA-HA AE is found, or if more than one FA-HA AE is 1026 found, or if the Authenticator is invalid, the HA MUST silently 1027 discard the GNAM message. 1029 If the "MD" value is set to 2, in the case of a FA-CoA, and if FA-HA 1030 AE is present, the FA-HA AE MUST be checked, and the HA MUST check 1031 the Authenticator value in the Extension. If more than one FA-HA AE 1032 is found, or if the Authenticator is invalid, the HA MUST silently 1033 discard the GNAM message. Anyway, MN-HA AE MUST be checked, and the 1034 HA MUST check the Authenticator value in the Extension. If no MN-HA 1035 AE is found, or if more than one MN-HA AE is found, or if the 1036 Authenticator is invalid, the HA MUST silently discard the GNAM. If 1037 the HA accepted this message, the HA MAY also process it based on the 1038 notification event. 1040 If the "MD" value is set to 2, in the case of a Co-located CoA, MN-HA 1041 AE MUST be checked, and the HA MUST check the Authenticator value in 1042 the Extension. If no MN-HA AE is found, or if more than one MN-HA AE 1043 is found, or if the Authenticator is invalid, the HA MUST silently 1044 discard the GNAM. If the HA accepted this message, the HA MAY also 1045 process it based on the notification event. 1047 4.6.3. Receiving Generic Notification Messages 1049 The HA MAY receive a GNM message sent from the FA. When the HA 1050 receives this message, if the the "MD" value is set to 5, this 1051 message came from FA. FA-HA AE MUST be checked, and the HA MUST 1052 check the Authenticator value in the Extension. If no FA-HA AE is 1053 found, or if more than one FA-HA AE is found, or if the Authenticator 1054 is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA 1055 with Code 132, including an Identification field computed in 1056 accordance with the rules specified in Section 7.1. The HA MUST do 1057 no further processing with such a notification, though it SHOULD log 1058 the error as a security exception. 1060 The HA MUST check that the Identification field is correct using the 1061 context selected by the SPI within mandatory authentication extension 1062 like MN-HA AE or FA-HA AE. See Section 7.1 for a description of how 1063 this is performed. If incorrect, the HA MUST reject the GNM and MAY 1064 send a GNAM to the initiator with Code 133, including an 1065 Identification field computed in accordance with the rules specified 1066 in Section 7.1. The HA MUST do no further processing with such a 1067 notification, though it SHOULD log the error as a security exception. 1068 If HA accepts the FA's GNM message, it will process it based on the 1069 notification extension. Furthermore, the HA MAY reply with a GNAM 1070 message with Code 0 back to the FA based on the "A" flag in the GNM 1071 message. 1073 If the the "MD" value is set to 2, this message come from MN, in the 1074 case of FA-COA, if FA-HA AE is present, it MUST be checked, and the 1075 HA MUST check the Authenticator value in the Extension. If more than 1076 one FA-HA AE Extension is found, or if the Authenticator is invalid, 1077 the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 1078 132, including an Identification field computed in accordance with 1079 the rules specified in Section 7.1. The HA MUST do no further 1080 processing with such a notification, though it SHOULD log the error 1081 as a security exception. And MN-HA AE MUST be checked, and the HA 1082 MUST check the Authenticator value in the Extension. If no MN-HA AE 1083 is found, or if more than one MN-HA AE is found, or if the 1084 Authenticator is invalid, the HA MUST reject the GNM and MAY send a 1085 GNAM to the MN with Code 131, including an Identification field 1086 computed in accordance with the rules specified in Section 7.1. The 1087 HA MUST do no further processing with such a notification, though it 1088 SHOULD log the error as a security exception. If HA accepts the MN's 1089 GNM message, it will process it based on the notification extension. 1090 Furthermore, the HA MAY reply with a GNAM message back to the MN with 1091 Code 0 based on the "A" flag in the GNM message. 1093 If the the "MD" value is set to 2, in the case of a Co-located CoA, 1094 the MN-HA AE MUST be checked, and the HA MUST check the Authenticator 1095 value in the Extension. If no MN-HA AE is found, or if more than one 1096 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 1097 reject the GNM and MAY send a GNAM to the MN with Code 131, including 1098 an Identification field computed in accordance with the rules 1099 specified in Section 7.1. The HA MUST do no further processing with 1100 such a notification, though it SHOULD log the error as a security 1101 exception. If HA accepts the MN's GNM message, it will process it 1102 based on the notification extension. Furthermore, the HA MAY reply 1103 with a GNAM message back to the MN with Code 0 based on the "A" flag 1104 in the GNM message. 1106 The HA MUST also check that the extensions present in the Generic 1107 Notification Message are permitted for use with the GNM. If not, the 1108 HA MUST silently discard the message. It MUST NOT do any further 1109 processing with such a notification, though it SHOULD log the error. 1111 4.6.4. Sending Generic Notification Acknowledgement Messages 1113 If the GNM message came from the FA only, and if the "A" flag is set 1114 in the GNM message, then the HA MUST send a GNAM message. The 1115 message is as follows: The source address is HA's address, the 1116 destination address is the FA's address, the "MD" value is set to 1. 1117 The ordering of the extension is: any non-authentication Extensions 1118 used only by the FA, followed by The Foreign-Home Authentication 1119 extension defined in Section 3.5.4 of [RFC3344]. 1121 The Code field of the GNAM is chosen in accordance with the rules 1122 specified in Section 4.2. When replying to an accepted GNM, a MN 1123 SHOULD respond with Code 0. 1125 If the GNM message came from the MN, and if the "A" flag is set in 1126 the GNM message, then the HA MUST send a GNAM message. The message 1127 is as follows: The source address is HA's address, the destination 1128 address is the FA's address, the "MD" value is set to 0. The 1129 ordering of the extension is: any non-authentication Extensions used 1130 only by the MN, followed by the MN-HA AE defined in Section 3.5.2 of 1131 [RFC3344], optionally followed by any non-authentication Extensions 1132 used only by the FA, optionally followed by The MN-FA AE defined in 1133 Section 3.5.3 of [RFC3344] 1135 5. Future Extensibility 1137 This document defines the Generic Notification Message used with the 1138 Message String Extension [RFC4917]. 1140 It is however possible to define new notification-related extensions 1141 for use with the Generic Notification Message, for cases where the 1142 notification is intended to have a semantic content and is intended 1143 for the HA, FA or MN, rather than for the user. 1145 One example of such usage, which would have been defined in this 1146 document if it hadn't already been defined as a separate message is 1147 the Registration Revocation Message [RFC3543]. This is a message 1148 sent from the HA to FA(s) or MN to notify the receiving node that a 1149 currently active registration is being revoked. The use case for 1150 this is clearly laid out in [RFC3543]. 1152 Another example would be managed maintenance switch-over between HA 1153 instances, where a HA due to go down for maintenance could direct the 1154 MNs registered with it to re-register with another specified HA. 1155 Such a message could also be used for managed load balancing. There 1156 is currently no support for such forced switch-over in the Mobile 1157 IPv4 protocol. 1159 Yet another example is when the prefix set handled by an MIPv4 NEMO 1160 [RFC5177] HA changes; to ensure proper routing, the mobile router 1161 needs to be notified about the change so that its internal routing 1162 rules may be updated. 1164 One final example is home network changes which require host 1165 configuration changes, for instance a change of address for the DNS 1166 server or another network server; again this is a case where the HA 1167 would want to notify the MN of the change, so that service 1168 interruptions can be avoided. 1170 In order to avoid making the MIPv4 Generic Notification Message a 1171 generic protocol extension mechanism by which new protocol mechanisms 1172 could be implemented without appropriate discussion and approval, any 1173 new extensions which are to be used with the Generic Notification 1174 Message must be registered with IANA, where registration is limited 1175 by the 'RFC Required' policy defined in [RFC5226] 1177 6. IANA Considerations 1179 This document defines two new messages, the Generic Notification 1180 Message described in Section 4.1, and the Generic Notification 1181 Acknowledgement Message, described in Section 4.2. The message 1182 numbers for these two message numbers are to be allocated from the 1183 same number space used by the Registration Request and Registration 1184 Reply messages in [RFC3344]. 1186 The Generic Notification Message may only carry extensions which are 1187 explicitly permitted for use with this message. This document 1188 defines 4 extensions which are permitted, in Section 4.1. IANA must 1189 establish a register of Mobile IPv4 extensions which are permitted 1190 for use with the Generic Notification Message. Approval of new 1191 extensions which are permitted for use with the Generic Notification 1192 Message requires that they be defined in an RFC according to the 'RFC 1193 Required' policy described in [RFC5226]. 1195 The Generic Notification Acknowledgement message, specified in 1196 Section 4.2, has a Code field. The number space for the Code field 1197 values is new, and also specified in Section 4.2. The Code number 1198 space is structured according to whether the notification was 1199 successful, or whether the HA denied the notification, or whether FA 1200 denied the notification, or whether MN denied the notification, as 1201 follows: 1203 0 Success Code 1204 64-69 Error Codes from the FA 1205 128-133 Error Codes from the HA 1206 192-197 Error Codes from the MN 1208 Approval of new Code values require expert review. 1210 7. Security Considerations 1212 This specification operates with the security constraints and 1213 requirements of [RFC3344]. It require that when these message is 1214 transmitted between the MN and the HA, MN-HA AE is mandatory, when 1215 this message is transmitted between the MN and the FA, MN-FA AE is 1216 mandatory, when this message is transmitted between the FA and the 1217 HA, FA-HA AE is mandatory. It extends the operations of MN, HA and 1218 FA defined in [RFC3344] to notify each other about some events. The 1219 GNM message defined in the specification could carry information that 1220 modifies the mobility bindings. Therefore the message MUST be 1221 integrity protected. Replay protection MUST also be guaranteed. 1223 RFC 3344 provides replay protection only for registration requests 1224 sent by the MN. There is no mechanism for replay protection for 1225 messages initiated by a FA or a HA. The 64-bit Identification field 1226 specified in this document (Section 4.1 and 4.2) for the GNM message 1227 is used to provide replay protection for the notification messages 1228 initiated by the FA or HA. 1230 7.1. Replay Protection for GNM, GNAM messages 1232 The Identification field is used to let the receiving node verify 1233 that a GNM has been freshly generated by the sending node, not 1234 replayed by an attacker from some previous registration. Two methods 1235 are described in this section: timestamps (mandatory) and "nonces" 1236 (optional). All senders and receivers MUST implement timestamp-based 1237 replay protection. These nodes MAY also implement nonce-based replay 1238 protection 1240 The style of replay protection in effect between any two peer nodes 1241 among MN, FA and HA is part of the mobile security association. A 1242 sending node and its receiving node MUST agree on which method of 1243 replay protection will be used. The interpretation of the 1244 Identification field depends on the method of replay protection as 1245 described in the subsequent subsections. 1247 Whatever method is used, the low-order 32 bits of the Identification 1248 MUST be copied unchanged from the GNM to the GNAM. The receiver uses 1249 those bits (and the sender's source address) to match GNAM with 1250 corresponding replies. The receiver MUST verify that the low-order 1251 32 bits of any GNAM are identical to the bits it sent in the GNM. 1253 The Identification in a new GNM MUST NOT be the same as in an 1254 immediately preceding GNM, and SHOULD NOT repeat while the same 1255 security context is being used between the MN and the HA. 1257 7.1.1. Replay Protection using Timestamps 1259 The basic principle of timestamp replay protection is that the node 1260 generating a message inserts the current time of day, and the node 1261 receiving the message checks that this timestamp is sufficiently 1262 close to its own time of day. Unless specified differently in the 1263 security association between the nodes, a default value of 7 seconds 1264 MAY be used to limit the time difference. This value SHOULD be 1265 greater than 3 seconds. Obviously the two nodes must have adequately 1266 synchronized time-of-day clocks. As with any messages, time 1267 synchronization messages may be protected against tampering by an 1268 authentication mechanism determined by the security context between 1269 the two nodes. 1271 In this document, the timestamps are used, the sender MUST set the 1272 Identification field to a 64-bit value formatted as specified by the 1273 Network Time Protocol (NTP) [RFC5905]. The low-order 32 bits of the 1274 NTP format represent fractional seconds . Note, however, that when 1275 using timestamps, the 64-bit Identification used in a GNM message 1276 from the sender MUST be greater than that used in any previous GNM 1277 message, as the receiver uses this field also as a sequence number. 1278 Without such a sequence number, it would be possible for a delayed 1279 duplicate of an earlier GNM message to arrive at the receiver (within 1280 the clock synchronization required by the receiver), and thus be 1281 applied out of order, mistakenly altering the sender's current 1282 status. 1284 Upon receipt of a GNM message with an authorization-enabling 1285 extension, the receiver MUST check the Identification field for 1286 validity. In order to be valid, the timestamp contained in the 1287 Identification field MUST be close enough to the receiver's time of 1288 day clock and the timestamp MUST be greater than all previously 1289 accepted timestamps for the requesting sender. Time tolerances and 1290 re-synchronization details are specific to a particular mobility 1291 security association. 1293 If the timestamp is valid, the receiver copies the entire 1294 Identification field into the GNAM it returns the GNAM message to the 1295 sender. If the timestamp is not valid, the receiver copies only the 1296 low-order 32 bits into the GNAM, and supplies the high-order 32 bits 1297 from its own time of day. In this latter case, the receiver MUST 1298 reject the registration by returning Code 69/133/197 (identification 1299 mismatch) in the GNAM message. 1301 Furthermore, the receiver MUST verify that the low-order 32 bits of 1302 the Identification in the GNAM are identical to those in the rejected 1303 GNM attempt, before using the high-order bits for clock re- 1304 synchronization. 1306 7.1.2. Replay Protection using Nonces 1308 The basic principle of nonce replay protection is that node A 1309 includes a new random number in every message to node B, and checks 1310 that node B returns that same number in its next message to node A. 1311 Both messages use an authentication code to protect against 1312 alteration by an attacker. At the same time node B can send its own 1313 nonces in all messages to node A (to be echoed by node A), so that it 1314 too can verify that it is receiving fresh messages. 1316 The receiver may be expected to have resources for computing pseudo- 1317 random numbers useful as nonces, according to [RFC4086]. It inserts 1318 a new nonce as the high-order 32 bits of the identification field of 1319 every GNAM message. The receiver copies the low-order 32 bits of the 1320 Identification from the GNM message into the low-order 32 bits of the 1321 Identification in the GNAM message. When the sender receives an 1322 authenticated GNAM message from the receiver, it saves the high-order 1323 32 bits of the identification for use as the high-order 32 bits of 1324 its next GNM message. 1326 The sender is responsible for generating the low-order 32 bits of the 1327 Identification in each GNM message. Ideally it should generate its 1328 own random nonces. However it may use any expedient method, 1329 including duplication of the random value sent by the receiver. The 1330 method chosen is of concern only to the sender , because it is the 1331 node that checks for valid values in the GNAM message. The high- 1332 order and low-order 32 bits of the identification chosen SHOULD both 1333 differ from their previous values. The receiver uses a new high- 1334 order value and the sender uses a new low-order value for each 1335 registration message. 1337 If a GNM message is rejected because of an invalid nonce, the GNAM 1338 always provides the sender with a new nonce to be used in the next 1339 registration. Thus the nonce protocol is self- synchronizing. 1341 7.2. Non-authentication Extensions Handling in Foreign Agent 1343 When the FA is relaying the GNM message between the MN and the HA, 1344 and if the FA does not share a mobility security association with the 1345 MN or HA, all non-authentication extensions between MN and FA, or FA 1346 and HA are not protected; In this case, all non-authentication 1347 extensions should be silently discarded. 1349 8. Acknowledgments 1351 The author appreciate the efforts of Ahmad Muhanna for his detail 1352 reviewing of this document and his many contributions to the text of 1353 this document. The author also wants to thank Kent Leung, Peng Yang 1354 and Peter McCann et al. for their helping developing this document. 1355 Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. 1356 Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, 1357 Tim Polk, Amanda Baber, Sebastian Thalanany, and Joseph Salowey's 1358 discussion and comments. Thanks to Jari Arkko for each step of this 1359 document. 1361 9. References 1363 9.1. Normative References 1365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1366 Requirement Levels", BCP 14, RFC 2119, March 1997. 1368 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1369 August 2002. 1371 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1372 Mobile IPv4", RFC 3543, August 2003. 1374 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1375 Requirements for Security", BCP 106, RFC 4086, June 2005. 1377 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 1378 String Extension", RFC 4917, June 2007. 1380 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1381 Time Protocol Version 4: Protocol and Algorithms 1382 Specification", RFC 5905, June 2010. 1384 9.2. Informative References 1386 [RFC5177] Leung, K., Dommety, G., Narayanan, V., and A. Petrescu, 1387 "Network Mobility (NEMO) Extensions for Mobile IPv4", 1388 RFC 5177, April 2008. 1390 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1391 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1392 May 2008. 1394 Authors' Addresses 1396 Hui Deng 1397 China Mobile 1398 53A,Xibianmennei Ave., 1399 Xuanwu District, 1400 Beijing 100053 1401 China 1403 Email: denghui02@gmail.com 1405 Henrik Levkowetz 1406 Netnod 1407 Franzengatan 5 1408 S-104 25, Stockholm 1409 SWEDEN 1411 Email: henrik@levkowetz.com 1413 Vijay Devarapalli 1414 WiChorus 1415 3590 North First St 1416 San Jose, CA 1417 USA 1419 Email: dvijay@gmail.com 1421 Sri Gundavelli 1422 Cisco Systems 1423 170 W.Tasman Drive 1424 San Jose, CA 95134 1425 USA 1427 Email: sgundave@cisco.com 1429 Brian Haley 1430 Hewlett-Packard Company 1431 110 Spitbrook Road 1432 Nashua, NH 03062 1433 USA 1435 Email: brian.haley@hp.com