idnits 2.17.1 draft-ietf-mip4-generic-notification-message-07.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 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1219. 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 (November 3, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3846' is defined on line 1132, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track H. Levkowetz 5 Expires: May 7, 2009 Ericsson Research 6 V. Devarapalli 7 WiChorus 8 S. Gundavelli 9 Cisco Systems 10 B. Haley 11 Hewlett-Packard Company 12 November 3, 2008 14 Generic Notification Message for Mobile IPv4 15 draft-ietf-mip4-generic-notification-message-07.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 May 7, 2009. 42 Abstract 44 This document specifies protocol enhancements that allow Mobile IPv4 45 entities to send and receive explicit notification messages using a 46 new Mobile IPv4 message type designed for this purpose. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Notification message - Usage Scenario's . . . . . . . . . . . 6 53 3.1. Notification message between a Home Agent and a Mobile 54 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1.1. Mobile Registered using a Foreign Agent Care-of 56 Address . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1.2. Mobile Registered using a Co-located Care-of 58 Address . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.2. Notification message between a Foreign Agent and a 60 Mobile Node . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Notification message between a Home Agent and a 62 Foreign Agent . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Generic Notification Message and Considerations . . . . . . . 8 64 4.1. Generic Notification Message . . . . . . . . . . . . . . . 8 65 4.2. Generic Notification Acknowledgment Message . . . . . . . 11 66 4.3. Mobile Node Consideration . . . . . . . . . . . . . . . . 14 67 4.3.1. Receiving Generic Notification Messages . . . . . . . 15 68 4.3.2. Sending Generic Notification Acknowledgement 69 Message . . . . . . . . . . . . . . . . . . . . . . . 16 70 4.3.3. Sending Generic Notification Messages . . . . . . . . 16 71 4.3.4. Receiving Generic Notification Acknowledgement 72 Messages . . . . . . . . . . . . . . . . . . . . . . . 17 73 4.4. Foreign Agent Consideration . . . . . . . . . . . . . . . 18 74 4.4.1. Receiving Generic Notification Message . . . . . . . . 18 75 4.4.2. Sending Generic Notification Acknowledgement 76 Messages . . . . . . . . . . . . . . . . . . . . . . . 19 77 4.4.3. Sending Generic Notification Messages . . . . . . . . 20 78 4.4.4. Receiving Generic Notification Acknowledgement 79 Messages . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.5. Home Agent Consideration . . . . . . . . . . . . . . . . . 21 81 4.5.1. Sending Generic Notification Messages . . . . . . . . 22 82 4.5.2. Receiving Generic Notification Acknowledgement 83 Messages . . . . . . . . . . . . . . . . . . . . . . . 22 84 4.5.3. Receiving Generic Notification Messages . . . . . . . 23 85 4.5.4. Sending Generic Notification Acknowledgement 86 Messages . . . . . . . . . . . . . . . . . . . . . . . 24 87 5. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 25 88 5.1. Generic String Extension . . . . . . . . . . . . . . . . . 25 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 92 7.1. Replay Protection for GNM, GNAM messages . . . . . . . . . 27 93 7.1.1. Replay Protection using Timestamps . . . . . . . . . . 27 94 8. Normative References . . . . . . . . . . . . . . . . . . . . . 29 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 96 Intellectual Property and Copyright Statements . . . . . . . . . . 31 98 1. Introduction 100 In some situations, there is a need for Mobile IPv4 entities, such as 101 the home agent(HA), foreign agent(FA) and mobile node(MN) to send and 102 receive asynchronous notification messages during a mobility session. 103 The base Mobile IP Specification [RFC3344] does not have a provision 104 for this. 106 This document defines a generic message and a notification model that 107 can be used by Mobile IPv4 entities to send various notifications. 108 However, this specification does not define any specific notification 109 message or the actions that the receiving entity is required to 110 perform on receiving that message. Specific extensions and the 111 corresponding handler actions are outside the scope of this document. 113 2. Terminology 115 It is assumed that the reader is familiar with the terminology used 116 in [RFC4917], [RFC3344]. In addition, the following terms are 117 defined: 119 Notification Message 121 A message from a mobility agent to a MN or other mobility agent to 122 asynchronously notify it about an event that is relevant to the 123 mobility service it is currently providing. 125 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119, [RFC2119]. 129 3. Notification message - Usage Scenario's 131 There are several scenarios where a mobility agent could initiate 132 notification events. Some of these are described in the following 133 sections. 135 3.1. Notification message between a Home Agent and a Mobile Node 137 3.1.1. Mobile Registered using a Foreign Agent Care-of Address 139 In this case, the HA cannot directly notify the MN, but must send the 140 notification via the FA, vice versa. 142 +----+ notification +----+ notification +----+ 143 | MN |<================>| FA |<=============>| HA | 144 +----+ +----+ +----+ 146 Figure 1: HA notifies MN or MN notifies HA through FA 148 3.1.2. Mobile Registered using a Co-located Care-of Address 150 In this case, the MN has registered with the home agent directly, so 151 the notification message can go directly to the MN. 153 The notification mechanism as specified here does not support the 154 case of Co-located CoA mode with registration through a FA (due to 155 the 'R' bit being set in the FA's advertisement messages). 157 +----+ notification +----+ 158 | MN |<===================================>| HA | 159 +----+ +----+ 161 Figure 2: HA directly notifies MN or MN directly notifies HA 163 3.2. Notification message between a Foreign Agent and a Mobile Node 165 There are two cases where a FA may send notification messages to a 166 MN, one where it is relaying a message, the other where the 167 notification is triggered by a message from another network entity, 168 for example a AAA node(notification messages between a AAA entity and 169 the FA could be based on RADIUS or Diameter, but this is out of scope 170 for this document). If the notification is initiated by a FA, the FA 171 may need to also notify the HA about the event. 173 +----+ notification +----+ trigger +--------+ 174 | MN |<================>| FA |<=============| AAA | 175 +----+ +----+ +--------+ 176 || notification +----+ 177 ================>| HA | 178 +----+ 180 Figure 3: FA notifies MN 182 3.3. Notification message between a Home Agent and a Foreign Agent 184 The HA may also need to send a notification to the FA, but not to the 185 MN, The FA may also need to send a notification to the HA, as 186 illustrated below: 188 +----+ notification +----+ 189 | FA |<=============>| HA | 190 +----+ +----+ 192 Figure 4: HA notifies FA or FA notifies HA 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 MN, foreign agent 199 and HA. 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 MN, of MIP-related information such as 205 vendor specific extensions[RFC3115] and generic string 206 notification[RFC4917]. These messages must use the same IP and UDP 207 headers as any previous Registration Request or Reply message to the 208 same entity. This would support NAT traversal and ensure same 209 security association used for GNM/GNAM and RRQ/RRP. The generic 210 notification message is defined as follows: 212 IP Fields: 214 Source Address Same as the last Registration Reply/Request 215 message received. 217 Destination Address Same as the last Registration Reply/Request 218 message. 220 UDP Fields: 222 Source Port Same as the last Registration Reply/Request 223 message. 225 Destination Port Same as the last Registration Reply/Request 226 message. 228 The UDP header is followed by the Mobile IP fields shown below: 230 0 1 2 3 231 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Subtype | MD |A| Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Home Address | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Home Agent Address | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Care-of Address | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 242 + Identification + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Extensions... 246 +-+-+-+-+-+-+-+-+-+-+-+-+- 248 Type (TBD) 250 Subtype 252 This field describes the particular type of notification which is 253 carried in the notification message. The following values are 254 reserved in this document. 256 0 Reserved 258 1 Information carried in Vendor specific extensions which is 259 specified in [RFC3115]. 261 2 Information carried in Generic String extensions which is 262 specified in [RFC4917]. 264 The value 0 is reserved and should not be used. The value 1 265 indicates that the actual information is carried in vendor 266 specific extensions. Other values are reserved for future 267 extensions. 269 MD: Message Direction 271 This memo defines the semantics of the following MD field value: 273 0 -- Message sent by the HA to the MN 275 1 -- Message sent by the HA to the FA 276 2 -- Message sent by the MN to the HA 278 3 -- Message sent by the MN to the FA 280 4 -- Message sent by the FA to the MN 282 5 -- Message sent by the FA to the HA 284 A 286 This bit indicates whether the notification message MUST be 287 acknowledged by the recipient. if "A" bit has been set during the 288 message, but the sender doesn't receive any acknowledgement 289 message, the sender will have to resend the notification message 290 again. 292 Set to "1" to indicate that acknowledgement is required. 294 Set to "0" to indicate that acknowledgement is optional. 296 Reserved 298 MUST be sent as 0, and ignored when received. 300 Home Address 302 The home IP address of the mobile node. 304 Home Agent Address 306 The IP address of the mobile node's HA. 308 Care-of Address 310 The mobile node's care-of address, either the Co-located Care-of 311 Address or the foreign agent care-of address. 313 Identification 315 A 64-bit number, constructed by the sender, used for matching 316 Generic Notification with Generic Notification Acknowledgement, 317 and for protecting against replay attacks of notification 318 messages. Here is the same as Sections 5.4 and 5.7 of [RFC3344]. 319 Timestamps is mandatory and nonces is optional. 321 Extensions 322 The fixed portion of the Generic Notification Message is followed 323 by one or more extensions which may be used with this message, and 324 by one or more authentication extensions (as defined in Section 325 3.5 of [RFC3344]. This document mandate the MN-HA AE when this 326 message is sent between the MN and the HA, others are optional. 327 This document also mandate the MN-FA AE when this message is sent 328 between the MN and the FA, others are optional. This document 329 mandate the FA-HA AE when this message is sent between the FA and 330 the HA, others are optional. This could be judged based on "MD" 331 value.). See Sections 3.6.1.3 and 3.7.2.2 of [RFC3344] for 332 information on the relative order in which different extensions, 333 when present, must be placed in a Generic Notification Message. 335 4.2. Generic Notification Acknowledgment Message 337 A generic notification acknowledgement message is sent by mobility 338 agents or MNs to indicate the successful receipt of a generic 339 notification message. 341 IP Fields: 343 Source Address Typically copied from the destination 344 address of the Generic Notification to which 345 the agent is replying. 347 Destination Address Copied from the source address of the 348 Generic Notification to which the agent is 349 replying. 351 UDP Fields: 353 Source Port Copied from the source port of the 354 corresponding Generic Notification. 356 Destination Port Copied from the source port of the 357 corresponding Generic Notification. 359 The UDP header is followed by the Mobile IP fields shown below: 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Type | Subtype | MD | code | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Home Address | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Home Agent Address | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Care-of Address | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 + Identification + 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Extensions... 377 +-+-+-+-+-+-+-+-+-+-+-+-+- 379 Type (TBD) 381 Subtype 383 This field specifies the particular type of notification 384 acknowledgement message. The following values are reserved in 385 this document. 387 0 Reserved 389 1 Information carried in Vendor specific extensions which is 390 specified in [RFC3115]. 392 2 Information carried in Generic String extensions which is 393 specified in [RFC4917]. 395 The value 0 is reserved and should not be used. The value 1 396 indicates that the actual information is carried in vendor 397 specific extensions. Other values are reserved for future 398 extensions. 400 MD: Message Direction 402 This memo defines the semantics of the following MD field value: 404 0 -- Message sent by the HA to the MN 406 1 -- Message sent by the HA to the FA 407 2 -- Message sent by the MN to the HA 409 3 -- Message sent by the MN to the FA 411 4 -- Message sent by the FA to the MN 413 5 -- Message sent by the FA to the HA 415 code 417 A value indicating the result of the Generic Notification Message. 418 See below for a list of currently defined Code values. 420 Notification suceessful 422 0 -- notification accepted 424 Notification denied by the HA 426 128 -- reason unspecified 428 129 -- administratively prohibited 430 130 -- insufficient resources 432 131 -- mobile node failed authentication 434 132 -- foreign agent failed authentication 436 133 -- notification Identification mismatch 438 Notification denied by the FA 440 64 -- reason unspecified 442 65 -- administratively prohibited 444 66 -- insufficient resources 446 67 -- mobile node failed authentication 448 68 -- home agent failed authentication 450 69 -- notification Identification mismatch 452 Notification denied by the mobile node 453 192 -- reason unspecified 455 193 -- administratively prohibited 457 194 -- insufficient resources 459 195 -- foreign agent failed authentication 461 196 -- home agent failed authentication 463 197 -- notification Identification mismatch 465 Home Address 467 The home IP address of the mobile node. 469 Home Agent Address 471 The IP address of the sender's home agent. 473 Care-of Address 475 The mobile node's care-of address, either the Co-located Care-of 476 Address or the foreign agent care-of address. 478 Identification 480 A 64-bit number, constructed by the sender, used for matching 481 Generic Notification with Generic Notification Acknowledgement, 482 and for protecting against replay attacks of notification 483 messages. Here is the same as Sections 5.4 and 5.7 of [RFC3344]. 484 Timestamps is mandatory. 486 Extensions 488 The fixed portion of the generic notification acknowledgement 489 message is followed by one or more of the Extensions listed in 490 Section 3.5 of [RFC3344]. See Sections 3.6.1.3 and 3.7.2.2 of 491 [RFC3344] for information on the relative order in which different 492 extensions, when present, MUST be placed in a Generic Notification 493 message. 495 4.3. Mobile Node Consideration 497 It is possible that the MN MAY receive a generic notification 498 message(GNM) from a FA or HA. Both in the case of FA-CoA and Co- 499 located CoA, the MN MAY reply with a generic notification 500 acknowledgement message (GNAM) based on the "A" flag in the GNM 501 message. 503 4.3.1. Receiving Generic Notification Messages 505 When the MN is using FA-CoA and receives a Notification message, if 506 the "MD" value is 0, it means that the notification message came from 507 the HA. If the "MD" value is 4, the notification came from the FA. 509 If this notification message came from a FA and the MN accepts the 510 FA's GNM, it will process the notification extension according to the 511 specific rules for that extension. 513 After that, the MN MAY reply GNAM back to the FA. If the "A" flag is 514 set in the GNM, then the MN MUST send the acknowledgement with Code 515 0. 517 The MN MUST check for the presence of an authorization-enabling 518 extension, and perform the indicated authentication. Exactly one 519 authorization-enabling extension MUST be present in the Registration 520 Request, if this message came from a FA, MN-FA AE MUST be present, If 521 no MN-FA AE is found, or if more than one MN-FA AE is found, or if 522 the Authenticator is invalid, the MN MUST reject the GNM and SHOULD 523 send a GNAM to the FA with Code 195, including an Identification 524 field computed in accordance with the rules specified in Section 525 7.1.1. The MN MUST do no further processing with such a 526 notification, though it SHOULD log the error as a security exception. 528 The MN MUST check that the Identfication field is correct using the 529 context selected by the SPI within mandatory authentication extension 530 like MN-FA AE or MN-HA AE. See Section 7.1.1 for a description of 531 how this is performed. If incorrect, the MN MUST reject the GNM and 532 SHOULD send a GNAM to the initiator with Code 197, including an 533 Identification field computed in accordance with the rules specified 534 in Section 7.1.1. The MN MUST do no further processing with such a 535 notification, though it SHOULD log the error as a security exception. 537 If this notification message came from the HA, relayed by the FA, or 538 is a Co-located CoA, the MN-HA AE MUST be checked and the MN MUST 539 check the Authenticator value in the Extension. If no MN-HA AE is 540 found, or if more than one MN-HA AE is found, or if the Authenticator 541 is invalid, the MN MUST reject the GNM and SHOULD send a GNAM to the 542 initiator with Code 196, including an Identification field computed 543 in accordance with the rules specified in Section 7.1.1. The MN MUST 544 do no further processing with such a notification, though it SHOULD 545 log the error as a security exception. If the MN accepts the HA's 546 GNM, it will process it according to the specific rules for that 547 extension. After that, the MN MAY reply with a GNAM with Code 0 back 548 to the HA based on the "A" flag in the GNM. 550 4.3.2. Sending Generic Notification Acknowledgement Message 552 Both in the case of a Co-located CoA and FA-CoA, the MN MAY reply 553 with a GNAM based on the "A" flag in the GNM as follows: 555 If the GNM was initiated from the FA to the MN ("MD" value is set to 556 4), the ordering of the extension is: any non-authentication 557 Extensions used only by the FA, followed by The MN-FA AE defined in 558 section 3.5.3 of [RFC3344]. 560 In the case of a FA-CoA, the source address is the MN's address, the 561 destination address is the FA's address. 563 The Code field of the GNAM is chosen in accordance with the rules 564 specified in the section 4.2. When replying to an accepted 565 notification, a MN SHOULD respond with Code 0. 567 There are a number of reasons the MN might reject a notification such 568 as administrative in nature returning a GNAM with a code of 193, 569 similarly and provides the Code value 192 or 194 for the unspecified 570 reason and insufficent resources. 572 If the GNM was initiated from the HA to the MN ("MD" value is set to 573 0) and in the case of Co-located CoA, the ordering of the extension 574 is: any non-authentication Extensions used only by the HA, followed 575 by the MN-HA AE defined in section 3.5.2 of [RFC3344] 577 In the case of a FA-CoA, the source address is the MN's HoA address 578 and the destination address is the FA's address ("MD" value is set to 579 2), the ordering of the extension is: any non-authentication 580 Extensions used only by the HA, followed by the MN-HA AE defined in 581 section 3.5.2. of [RFC3344], followed by any non-authentication 582 Extensions used only by the FA, followed by The MN-FA AE defined in 583 section 3.5.3 of [RFC3344]. 585 4.3.3. Sending Generic Notification Messages 587 The MN may either send a GNM to notify the FA or HA. 589 If the message is sent to the FA, the source address is the MN's 590 address, and the destination address is the FA's address 592 If the FA is the target of this notification message, then the "MD" 593 value is set to 3, and the ordering of the extension is: the 594 notification extension, followed by any non-authentication Extensions 595 used only by the FA, followed by The MN-FA AE defined in section 596 3.5.3 of [RFC3344]. Computing Authentication Extension Value is the 597 same as section 3.5.1 of [RFC3344]. 599 If the FA is working only as a relay agent, the "MD" value is set to 600 2, and the ordering of the extension is: the notification extension, 601 followed by any non-authentication extension expected to be used by 602 HA, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 603 followed by any non-authentication Extensions used only by the FA, 604 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 605 Computing Authentication Extension Value is the same as section 3.5.1 606 of [RFC3344]. 608 In the case of a Co-located CoA, the MN MAY send a notification 609 message directly to the HA if it needs to be notified. The "MD" 610 value is set to 2, and the ordering of the extension is: the 611 notification extension, followed by any non-authentication extension 612 expected to be used by HA, followed by MN-HA AE defined in section 613 3.5.2 of [RFC3344]. 615 The MN chooses the Identification field in accordance with the style 616 of replay protection it uses with its FA or HA. This is part of the 617 mobility security association the MN shares with its FA or HA. See 618 Section 7.1.1 for the method by which the MN computes the 619 Identification field. 621 4.3.4. Receiving Generic Notification Acknowledgement Messages 623 In the case of a FA-CoA, if the MN receives this message, and the 624 "MD" value is set to 0, it means that the GNAM came from HA 626 If the "MD" value is set to 4, the MN-FA AE MUST be checked, and the 627 MN MUST check the Authenticator value in the Extension. If no MN-FA 628 AE is found, or if more than one MN-FA AE is found, or if the 629 Authenticator is invalid, the MN MUST silently discard the GNAM. 631 In addition, the low-order 32 bits of the Identification field in the 632 GNAM MUST be compared to the low-order 32 bits of the Identification 633 field in the most recent GNA sent to the replying agent. if they do 634 not match, the GNAM MUST be silently discarded. 636 If the "MD" value is set to 0, the MN-HA AE MUST be checked, and the 637 HA MUST check the Authenticator value in the Extension. If no MN-HA 638 AE is found, or if more than one MN-HA AE is found, or if the 639 Authenticator is invalid, the HA MUST silently discard the GNAM. If 640 the MN accepted this message, the MN MAY also process it based on the 641 notification event. 643 In the case of a Co-located CoA, if the MN received this message, the 644 MN-HA AE MUST be checked, and the HA MUST check the Authenticator 645 value in the Extension. If no MN-HA AE is found, or if more than one 646 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 647 silently discard the Notification Acknowledgement message. 649 4.4. Foreign Agent Consideration 651 The FA can not only relay generic notification message between the HA 652 and MN, but it can also initiate a GNM to the MN or HA, and it will 653 depends on whether there is a binding for the MN. 655 4.4.1. Receiving Generic Notification Message 657 If the FA receives a GNM, and the "MD" value is set to 0, it means 658 that the HA is asking the FA to relay the message to the MN. If the 659 "MD" value is set to 1, it means that the target of the notification 660 is the FA. If the "MD" value is set to 2, it means that the MN is 661 asking the FA to relay the message to the HA. If the "MD" value is 662 set to 3, it means that the notification came from the MN to the FA. 664 if the "MD" value is set to 0, the FA MAY check the FA-HA AE and 665 Authenticator value in the Extension. If the FA validates the HA's 666 GNM, it MUST relay the GNM to the MN's home address as specified in 667 the Home Address field of the GNM. The FA MUST NOT modify any of the 668 fields beginning with the fixed portion of the GNM through and MN-HA 669 AE or other authentication extension supplied by the HA as an 670 authorization-enabling extension for the MN. 672 Furthermore, the FA MUST process and remove any Extensions following 673 the MN-HA AE, and MAY append any of its own non-authentication 674 Extensions of relevance to the MN if applicable, and MUST append the 675 MN-FA AE, if the FA shares a mobility security association with the 676 MN. 678 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 679 FA MUST check the Authenticator value in the Extension. if no FA-HA 680 AE is found, or if more than one FA-HA AE is found, or if the 681 Authenticator is invalid, the FA MUST reject the GNM and SHOULD send 682 a GNAM to the HA with Code 68, including an Identification field 683 computed in accordance with the rules specified in Section 7.1.1. 684 The FA MUST do no further processing with such a notification, though 685 it SHOULD log the error as a security exception. 687 The FA MUST check that the Identfication field is correct using the 688 context selected by the SPI within mandatory FA-HA AE. See Section 689 7.1.1 for a description of how this is performed. If incorrect, the 690 FA MUST reject the GNM and SHOULD send a GNAM to the initiator with 691 Code 69, including an Identification field computed in accordance 692 with the rules specified in Section 7.1.1. The FA MUST do no further 693 processing with such a notification, though it SHOULD log the error 694 as a security exception. 696 If FA accepts the HA's generic notification message, it will process 697 it based on the specific rules for that extension. The FA MAY then 698 reply with a GNAM with Code 0 back to the MN based on the "A" flag in 699 the GNM. 701 if the "MD" value is set to 2, the FA MAY check the MN-FA AE and 702 Authenticator value in the Extension. If the FA validates the MN's 703 GNM, it MUST relay the GNM to the HA's address as specified in the 704 Home Agent Address field of the GNM. The FA MUST NOT modify any of 705 the fields beginning with the fixed portion of the GNM through and 706 MN-HA AE or other authentication extension supplied by the MN as an 707 authorization-enabling extension for the HA. 709 Furthermore, the FA MUST process and remove any Extensions following 710 the MN-HA AE, and MAY append any of its own non-authentication 711 Extensions of relevance to the MN if applicable, and MUST append the 712 MN-FA AE, if the FA shares a mobility security association with the 713 MN. 715 If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the 716 FA MUST check the Authenticator value in the Extension which is the 717 same as the section 3.7.2.1 of RFC 3344. If no MN-FA AE is found, or 718 if more than one MN-FA AE is found, or if the Authenticator is 719 invalid, the FA MUST reject the GNM and SHOULD send a GNAM to the HA 720 with Code 67, including an Identification field computed in 721 accordance with the rules specified in Section 7.1.1. The FA MUST do 722 no further processing with such a notification, though it SHOULD log 723 the error as a security exception. 725 The FA MUST check that the Identfication field is correct using the 726 context selected by the SPI within mandatory MN-FA AE. See Section 727 7.1.1 for a description of how this is performed. If incorrect, the 728 FA MUST reject the GNM and SHOULD send a GNAM to the initiator with 729 Code 69, including an Identification field computed in accordance 730 with the rules specified in Section 7.1.1. The FA MUST do no further 731 processing with such a notification, though it SHOULD log the error 732 as a security exception. 734 If FA accepts the MN's GNM, it will process it based on the specific 735 rules for that extension. The FA MAY then reply with a GNAM with 736 Code 0 back to the MN based on the "A" flag in the GNM. 738 4.4.2. Sending Generic Notification Acknowledgement Messages 740 The FA may need to either relay a GNAM message between the MN and the 741 HA or send one as a response to a GNM messsage that was sent to it. 742 In both cases, the GNAM message is defined as follows: 744 The source address is the FA address, the destination address is HA's 745 or FA's address. 747 The Code field of the GNAM is chosen in accordance with the rules 748 specified in the section 4.2. When replying to an accepted 749 notification, a FA SHOULD respond with Code 0. 751 There are a number of reasons the FA might reject a notification such 752 as administrative in nature returning a GNAM with a code of 65, 753 similarly and provides the Code value 64 or 66 for the unspecified 754 reason and insufficent resources. 756 If the FA is only relaying this message to the HA, the FA it MUST NOT 757 modify any of the fields beginning with the fixed portion of the 758 Generic Notification Acknowledgement through and including the MN-HA 759 AE or other authentication extension supplied by the HA as an 760 authorization-enabling extension for the MN. Furthermore, the 761 foreign agent MUST process and remove any Extensions following the 762 MN-HA AE and MAY append any of its own non-authentication Extensions 763 of relevance to the HA, if applicable. It MUST also append the FA-HA 764 AE, if the FA shares a mobility security association with the HA. 766 If the notification message is from the HA to the FA then the "MD" 767 value is set to 5 and the ordering of the extension is: any non- 768 authentication Extensions used only by the HA, followed by The FA-HA 769 AE defined in section 3.5.4 of [RFC3344]. 771 If the notification message is from the MN to the FA then the "MD" 772 value is set to 4 and the ordering of the extension is: any non- 773 authentication Extensions used only by the HA, followed by The MN-FA 774 AE defined in section 3.5.3 of [RFC3344]. 776 4.4.3. Sending Generic Notification Messages 778 If the FA is initiating a notification to the MN using the generic 779 notification message, it MAY also notify the HA as well. 781 In the message to the MN, the source address is the FA address, the 782 destination address is the MN's address, the "MD" value is set to 4, 783 and the ordering of the extension is: the notification extension, 784 followed by any non-authentication Extensions used only by the MN, 785 followed by The MN-FA AE defined in section 3.5.3 of [RFC3344]. 786 Computing Authentication Extension Value is the same as section 3.5.1 787 of [RFC3344] except the payload is the notification other than 788 registration. 790 In the message to the HA, the source address is the FA's address, the 791 destination address is the HA's address (the "MD" value is set to 5), 792 and the ordering of the extension is: notification extension, 793 followed by any non-authentication Extensions used only by the HA, 794 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 795 Computing Authentication Extension Value is the same as section 3.5.1 796 of [RFC3344] except the payload is the notification other than 797 registration. 799 4.4.4. Receiving Generic Notification Acknowledgement Messages 801 In the case of a FA-CoA, if the FA receives this message, and the 802 "MD" value is set to 3, it means that the notification 803 acknowledgement message came from the MN, otherwise it came from the 804 HA. 806 If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the 807 FA MUST check the Authenticator value in the Extension. If no FA-HA 808 AE is found, or if more than one FA-HA AE is found, or if the 809 Authenticator is invalid, the FA MUST silently discard the 810 Notification Acknowledgement message. If the FA accepted this 811 message, the FA MAY also process it based on the notification event. 813 If the "MD" value is set to 3, if the MN-FA AE is presented, it MUST 814 be checked, and the FA MUST check the Authenticator value in the 815 Extension. If no MN-FA AE is found, or if more than one MN-FA AE is 816 found, or if the Authenticator is invalid, the FA MUST silently 817 discard the GNAM message. If the FA accepted this message, the FA 818 MAY also process it based on the notification event. 820 In the case of a FA-CoA and if the "MD" value is set to 2, if the FA 821 received this message, the MN-FA AE MUST be checked, and the FA MUST 822 check the Authenticator value in the Extension. If no MN-FA AE is 823 found, or if more than one MN-FA AE is found, or if the Authenticator 824 is invalid, the FA MUST silently discard the GNAM message. If FA 825 accepted the MN's GNAM message, it MUST relay this message to the HA. 826 The FA MUST NOT modify any of the fields beginning with the fixed 827 portion of the GNAM message through and including the MN-HA AE or 828 other authentication extension supplied by the HA as an 829 authorization-enabling extension for the MN. Furthermore, the FA 830 MUST process and remove any Extensions following the MN-HA AE and MAY 831 append any of its own non-authentication Extensions of relevance to 832 the HA, if applicable, and MUST append the FA-HA AE, if the FA shares 833 a mobility security association with the HA. 835 4.5. Home Agent Consideration 837 The HA MAY initiate a GNM message to both the mobile node and FA, and 838 it also MAY receive a GNAM message from both the FA and MN. The HA 839 also MAY receive a GNM message from the FA, but only when there is a 840 binding for a MN. if the HA receives a GNM from a FA and there is no 841 corresponding MN registration, the HA should drop the GNM message. 843 4.5.1. Sending Generic Notification Messages 845 In the case of a FA-CoA, the HA may either send a GNM to notify the 846 FA, or have the FA relay the GNM to the MN if the MN needs to be 847 notified. 849 If the message is from the HA to the FA, the source address is the 850 HA's address, and the destination address is the FA's address 852 If the FA is working only as a relay agent, the "MD" value is set to 853 0, and the ordering of the extension is: the notification extension, 854 followed by any non-authentication extension expected to be used by 855 MN, followed by MN-HA AE defined in section 3.5.2. of [RFC3344], 856 followed by any non-authentication Extensions used only by the FA, 857 followed by The FA-HA AE defined in section 3.5.4 of [RFC3344]. 858 Computing Authentication Extension Value is the same as section 3.5.1 859 of [RFC3344]. 861 If the FA is the target of this notification message, then the "MD" 862 value is set to 1, and the ordering of the extension is: the 863 notification extension, followed by any non-authentication Extensions 864 used only by the FA, followed by The FA-HA AE defined in section 865 3.5.4 of [RFC3344]. Computing Authentication Extension Value is the 866 same as section 3.5.1 of [RFC3344]. 868 In the case of a Co-located CoA, the HA MAY send a notification 869 message directly to the MN if it needs to be notified. The "MD" 870 value is set to 0, and the ordering of the extension is: the 871 notification extension, followed by any non-authentication extension 872 expected to be used by MN, followed by MN-HA AE defined in section 873 3.5.2. of [RFC3344]. 875 4.5.2. Receiving Generic Notification Acknowledgement Messages 877 In the case of a FA-CoA, if the HA receives this message, and the 878 "MD" value is set to 2, it means that the GNAM message came from MN. 880 If the "MD" value is set to 5, and the HA accepted this message, the 881 HA MAY also process it based on the notification event. The FA-HA AE 882 MUST be checked, and the HA MUST check the Authenticator value in the 883 Extension. If no FA-HA AE is found, or if more than one FA-HA AE is 884 found, or if the Authenticator is invalid, the HA MUST silently 885 discard the GNAM message. 887 If the "MD" value is set to 2, MN-HA AE MUST be checked, and the HA 888 MUST check the Authenticator value in the Extension. If no MN-HA AE 889 is found, or if more than one MN-HA AE is found, or if the 890 Authenticator is invalid, the HA MUST silently discard the 891 Notification Acknowledgement message. If the HA accepted this 892 message, the HA MAY also process it based on the notification event. 894 In the case of a Co-located CoA, if the HA received this message, the 895 MN-HA AE MUST be checked, and the HA MUST check the Authenticator 896 value in the Extension. If no MN-HA AE is found, or if more than one 897 MN-HA AE is found, or if the Authenticator is invalid, the HA MUST 898 silently discard the GNAM message. 900 4.5.3. Receiving Generic Notification Messages 902 The HA MAY receive a GNM message sent from the FA. When the HA 903 receives this message, if the the "MD" value is set to 5, this 904 message came from FA. FA-HA AE MUST be checked, and the HA MUST 905 check the Authenticator value in the Extension. If no FA-HA AE is 906 found, or if more than one FA-HA AE is found, or if the Authenticator 907 is invalid, the HA MUST reject the GNM and SHOULD send a GNAM to the 908 FA with Code 132, including an Identification field computed in 909 accordance with the rules specified in Section 7.1.1. The HA MUST do 910 no further processing with such a notification, though it SHOULD log 911 the error as a security exception. 913 The HA MUST check that the Identfication field is correct using the 914 context selected by the SPI within mandatory authentication extension 915 like MN-HA AE or FA-HA AE. See Section 7.1.1 for a description of 916 how this is performed. If incorrect, the HA MUST reject the GNM and 917 SHOULD send a GNAM to the initiator with Code 133, including an 918 Identification field computed in accordance with the rules specified 919 in Section 7.1.1. The HA MUST do no further processing with such a 920 notification, though it SHOULD log the error as a security exception. 921 If HA accepts the FA's GNM message, it will process it based on the 922 notification extension. Furthermore, the HA MAY reply with a GNAM 923 message with Code 0 back to the FA based on the "A" flag in the GNM 924 message. 926 if the the "MD" value is set to 2, this message come from MN, if 927 FA-HA AE is presented, it MUST be checked, and the HA MUST check the 928 Authenticator value in the Extension. if more than one FA-HA AE 929 Extension is found, or if the Authenticator is invalid, the HA MUST 930 reject the GNM and SHOULD send a GNAM to the FA with Code 132, 931 including an Identification field computed in accordance with the 932 rules specified in Section 7.1.1. The HA MUST do no further 933 processing with such a notification, though it SHOULD log the error 934 as a security exception. And MN-HA AE MUST be checked, and the HA 935 MUST check the Authenticator value in the Extension. If no MN-HA AE 936 is found, or if more than one MN-HA AE is found, or if the 937 Authenticator is invalid, the HA MUST reject the GNM and SHOULD send 938 a GNAM to the MN with Code 131, including an Identification field 939 computed in accordance with the rules specified in Section 7.1.1. 940 The HA MUST do no further processing with such a notification, though 941 it SHOULD log the error as a security exception. If HA accepts the 942 MN's GNM message, it will process it based on the notification 943 extension. Furthermore, the HA MAY reply with a GNAM message back to 944 the MN with Code 0 based on the "A" flag in the GNM message. 946 4.5.4. Sending Generic Notification Acknowledgement Messages 948 If the GNM message came from the FA only, the HA MAY reply with a 949 GNAM message to the FA based on the "A" flag in the GNM message. If 950 the "A" flag is set in the GNM message, then the HA MUST send a GNAM 951 message. The message is as follows: The source address is HA's 952 address, the destination address is the FA's address, the "MD" value 953 is set to 1. The ordering of the extension is: any non- 954 authentication Extensions used only by the FA, followed by The 955 Foreign-Home Authentication extension defined in section 3.5.4 of 956 [RFC3344]. 958 The Code field of the GNAM is chosen in accordance with the rules 959 specified in the section 4.2. When replying to an accepted GNM, a MN 960 SHOULD respond with Code 0. 962 If the GNM message came from the MN, the HA MAY reply with a GNAM 963 message to the MN based on the "A" flag in the GNM message. If the 964 "A" flag is set in the GNM message, then the HA MUST send a GNAM 965 message. The message is as follows: The source address is HA's 966 address, the destination address is the FA's address, the "MD" value 967 is set to 0. The ordering of the extension is: any non- 968 authentication Extensions used only by the MN, followed by the MN-HA 969 AE defined in section 3.5.2. of [RFC3344], optionly followed by any 970 non-authentication Extensions used only by the FA, optionly followed 971 by The MN-FA AE defined in section 3.5.3 of [RFC3344] 973 5. Usage Example 975 There are several applications that could use this generic 976 notification message. for example, during handover between CDMA 2000 977 1x EV-DO and Wireless LAN, the PPP resource of CDMA side have to be 978 removed on the FA (PDSN) to avoid over-charging subscribers. Other 979 applications such as HA switch over, NEMO prefix changes, service or 980 billing related events, load balancing where the HA wants to move 981 some of the registered mobile nodes to other HAs, service termination 982 due to end of prepaid time, and service interruption due to system 983 maintenance. 985 Here we describe some possible event which could use the generic 986 string extension [RFC4917]based on this notification mechanism also. 987 There is also the possibility that this notification message could 988 carry many extensions at once. A new VSE extension could be defined 989 to support this notification message. 991 5.1. Generic String Extension 993 In some case, the HA or FA needs to notify the mobile node about 994 service termination due to the end of prepaid time, or service 995 interruption due to system maintenance. This information could be 996 defined based on a string [RFC4917]which is recognized by the MN 997 easily. An example would be "Maintenance Stopping", "Prepaid 998 Expire". These string MUST be strictly defined so they could be 999 easily understood by all of the network entities. "Subtype" number 1000 would need to be decided by the working group. 1002 6. IANA Considerations 1004 This document describes two new messages, the Generic Notification 1005 message, section 4.1 and the Generic Notification Acknowledgement 1006 message, section 4.2. These two messages should be allocated from 1007 the same address space used by the Registration Request and 1008 Registration Reply messages in [RFC3344]. The subtype of these two 1009 messages indicate what kind of information is carried and will be 1010 under assigned by IANA namespace. 1012 This document creates a new IANA registry for the Subtype field In 1013 the Generic Notification and Generic Notification Acknowledgement 1014 messages. New values should be allocated by Standards Actions or 1015 IETF Consensus. This document reserves four values for the Subtype 1016 field 1018 0 Reserved 1020 1 Information carried in Vendor specific extensions 1022 2 Information carried in Generic String Extension 1024 7. Security Considerations 1026 This specification operates in the security constraints and 1027 requirements of [RFC3344]. It require that when this message is 1028 transmitted between the MN and the HA, MN-HA AE is mandatory, when 1029 this message is transmitted between the MN and the FA, MN-FA AE is 1030 mandatory, when this message is transmitted between the FA and the 1031 HA, FA-HA AE is mandatory. It extends the operations of MN, HA and 1032 FA defined in [RFC3344] to notify each other about some events. The 1033 GNM message defined in the specification could carry information that 1034 modifies the mobility bindings. Therefore the message MUST be 1035 integrity protected. Replay protection MUST also be guaranteed. 1037 RFC 3344 provides replay protection only for registration requests 1038 sent by the MN. There is no mechanism for replay protection for 1039 messages initiated by a FA or a HA. The 64-bit Identification field 1040 specified in this document (Section 4.1 and 4.2) for the GNM message 1041 is used to provide replay protection for the notification messages 1042 initiated by the FA or HA. 1044 7.1. Replay Protection for GNM, GNAM messages 1046 The Identification field is used to let the receiving node verify 1047 that a GNM has been freshly generated by the sending node, not 1048 replayed by an attacker from some previous registration. This 1049 documents require that all MNs, FAs and HAs MUST implement timestamp- 1050 based replay protection. 1052 The style of replay protection in effect between any two peer node 1053 among MN, FA and HA. A sending node and its receiving node MUST 1054 agree on which method of replay protection will be used. The 1055 interpretation of the Identification field depends on the method of 1056 replay protection as described in the subsequent subsections. 1058 The low-order 32 bits of the Identification MUST be copied unchanged 1059 from the HNM to the HNMA. The receiver uses those bits (and the 1060 sender's source address) to match HNAM with corresponding replies. 1061 The receiver MUST verify that the low-order 32 bits of any HNAM are 1062 identical to the bits it sent in the GNM. 1064 The Identification in a new GNM MUST NOT be the same as in an 1065 immediately preceding GNM, and SHOULD NOT repeat while the same 1066 security context is being used between the MN and the HA. 1068 7.1.1. Replay Protection using Timestamps 1070 The basic principle of timestamp replay protection is that the node 1071 generating a message inserts the current time of day, and the node 1072 receiving the message checks that this timestamp is sufficiently 1073 close to its own time of day. Unless specified differently in the 1074 security association between the nodes, a default value of 7 seconds 1075 MAY be used to limit the time difference. This value SHOULD be 1076 greater than 3 seconds. Obviously the two nodes must have adequately 1077 synchronized time-of-day clocks. As with any messages, time 1078 synchronization messages may be protected against tampering by an 1079 authentication mechanism determined by the security context between 1080 the two nodes. 1082 In this document, the timestamps are used, the sender MUST set the 1083 Identification field to a 64-bit value formatted as specified by the 1084 Network Time Protocol[RFC1305]. The low-order 32 bits of the NTP 1085 format represent fractional seconds, and those bits which are not 1086 available from a time source SHOULD be generated from a good source 1087 of randomness. Note, however, that when using timestamps, the 64-bit 1088 Identification used in a GNM message from the sender MUST be greater 1089 than that used in any previous GNM message, as the receiver uses this 1090 field also as a sequence number. Without such a sequence number, it 1091 would be possible for a delayed duplicate of an earlier GNM message 1092 to arrive at the receiver (within the clock synchronization required 1093 by the receiver), and thus be applied out of order, mistakenly 1094 altering the sender's current status. 1096 Upon receipt of a GNM message with an authorization-enabling 1097 extension, the receiver MUST check the Identification field for 1098 validity. In order to be valid, the timestamp contained in the 1099 Identification field MUST be close enough to the receiver's time of 1100 day clock and the timestamp MUST be greater than all previously 1101 accepted timestamps for the requesting sender. Time tolerances and 1102 resynchronization details are specific to a particular mobility 1103 security association. 1105 If the timestamp is valid, the receiver copies the entire 1106 Identification field into the GNAM it returns the GNAM message to the 1107 sender. If the timestamp is not valid, the receiver copies only the 1108 low-order 32 bits into the GNAM, and supplies the high-order 32 bits 1109 from its own time of day. In this latter case, the receiver MUST 1110 reject the registration by returning Code 69/133/197 (identification 1111 mismatch) in the GNAM message. 1113 Furthermore, the receiver MUST verify that the low-order 32 bits of 1114 the Identification in the GNAM are identical to those in the rejected 1115 GNM attempt, before using the high-order bits for clock 1116 resynchronization. 1118 8. Normative References 1120 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1121 Specification, Implementation", RFC 1305, March 1992. 1123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1124 Requirement Levels", BCP 14, RFC 2119, March 1997. 1126 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/ 1127 Organization-Specific Extensions", RFC 3115, April 2001. 1129 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1130 August 2002. 1132 [RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for 1133 Carrying Network Access Identifiers", RFC 3846, June 2004. 1135 [RFC4917] Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message 1136 String Extension", RFC 4917, June 2007. 1138 Authors' Addresses 1140 Hui Deng 1141 China Mobile 1142 53A,Xibianmennei Ave., 1143 Xuanwu District, 1144 Beijing 100053 1145 China 1147 Email: denghui02@gmail.com 1149 Henrik Levkowetz 1150 Ericsson Research 1151 Torshamsgatan 23 1152 S-164 80, Stockholm 1153 SWEDEN 1155 Email: henrik@levkowetz.com 1157 Vijay Devarapalli 1158 WiChorus 1159 3590 North First St 1160 San Jose, CA 1161 USA 1163 Email: dvijay@gmail.com 1165 Sri Gundavelli 1166 Cisco Systems 1167 170 W.Tasman Drive 1168 San Jose, CA 95134 1169 USA 1171 Email: sgundave@cisco.com 1173 Brian Haley 1174 Hewlett-Packard Company 1175 110 Spitbrook Road 1176 Nashua, NH 03062 1177 USA 1179 Email: brian.haley@hp.com 1181 Full Copyright Statement 1183 Copyright (C) The IETF Trust (2008). 1185 This document is subject to the rights, licenses and restrictions 1186 contained in BCP 78, and except as set forth therein, the authors 1187 retain all their rights. 1189 This document and the information contained herein are provided on an 1190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1192 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1193 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1194 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1197 Intellectual Property 1199 The IETF takes no position regarding the validity or scope of any 1200 Intellectual Property Rights or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; nor does it represent that it has 1204 made any independent effort to identify any such rights. Information 1205 on the procedures with respect to rights in RFC documents can be 1206 found in BCP 78 and BCP 79. 1208 Copies of IPR disclosures made to the IETF Secretariat and any 1209 assurances of licenses to be made available, or the result of an 1210 attempt made to obtain a general license or permission for the use of 1211 such proprietary rights by implementers or users of this 1212 specification can be obtained from the IETF on-line IPR repository at 1213 http://www.ietf.org/ipr. 1215 The IETF invites any interested party to bring to its attention any 1216 copyrights, patents or patent applications, or other proprietary 1217 rights that may cover technology that may be required to implement 1218 this standard. Please address the information to the IETF at 1219 ietf-ipr@ietf.org.