idnits 2.17.1 draft-ietf-mip6-generic-notification-message-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 426. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 432. 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 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 (October 2007) is 6036 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 3775 (ref. '2') (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIP6 Working Group Brian Haley 2 Internet Draft Hewlett-Packard 3 Intended status: Standards Track Sri Gundavelli 4 Expires: January, 2008 Cisco Systems 5 October 2007 7 Generic Notification Message for Mobile IPv6 8 draft-ietf-mip6-generic-notification-message-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document specifies a new Mobility Header message type that 36 allows Mobile IPv6 entities to send and receive generic notification 37 messages. 39 Conventions used in this document 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC-2119 [1]. 45 Table of Contents 47 1. Introduction...................................................2 48 2. Generic Notification Messages..................................2 49 2.1 Generic Notification Request Message.......................3 50 2.2 Generic Notification Acknowledgement Message...............4 51 3. Sending Generic Notification Messages..........................5 52 3.1 Sending Generic Notification Request Messages..............5 53 3.2 Sending Generic Notification Acknowledgement Messages......6 54 4. Receiving Generic Notification Messages........................6 55 4.1 Receiving Generic Notification Request Messages............6 56 4.1.1 Mobile Node Operation....................................7 57 4.1.2 Home Agent Operation.....................................7 58 4.1.3 Retransmissions..........................................7 59 5. Protocol Constants.............................................8 60 6. IANA Considerations............................................8 61 7. Security Considerations........................................8 62 8. References.....................................................8 63 8.1 Normative Reference........................................8 64 8.2 Informative references.....................................9 65 Acknowledgments...................................................9 66 Author's Addresses................................................9 68 1. Introduction 70 RFC 3775 [2] contains no provision for Mobile IPv6 entities, such as 71 a home agent or mobile node, to send and receive asynchronous 72 notification messages during a mobility session. 74 This document describes a generic notification message protocol that 75 can be used by Mobile IPv6 entities for sending and receiving simple 76 notification events. 78 The document does not define any specific events, or the 79 corresponding actions that the receiver is required to do upon 80 receiving an event. 82 2. Generic Notification Messages 84 The messages described below follow the Mobility Header format 85 specified in Section 6.1 of [2]: 87 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 | Payload Proto | Header Len | MH Type | Reserved | 89 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 90 | Checksum | | 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 92 | | 93 . . 94 . Message Data . 95 . . 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 2.1 Generic Notification Request Message 101 The Generic Notification Request message is used by the home agent to 102 notify the mobile node, or vice-versa, that there is an event that 103 requires attention. This packet is sent as described in Section 3. 105 The Generic Notification Request message uses the MH Type value 106 (TBD). When this value is indicated in the MH Type field, the format 107 of the Message Data field in the Mobility Header is as follows: 109 0 1 2 3 110 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 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 |A| Reserved | Sequence # | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | | 115 . . 116 . Mobility options . 117 . . 118 | | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Acknowledge (A) 123 The Acknowledge (A) bit is set by the sender to request a Generic 124 Notification Acknowledgement (Section 3.1) be returned upon receipt 125 of a Generic Notification Request. 127 Reserved 129 These fields are unused. They MUST be initialized to zero by the 130 sender, and MUST be ignored by the receiver. 132 Sequence # 134 An 8-bit unsigned integer used by the receiving node to sequence 135 Generic Notification Requests and by the sending node to match a 136 returned Generic Notification Acknowledgement with this Generic 137 Notification Request. 139 Mobility options 141 Variable-length field of such length that the complete Mobility 142 Header is an integer multiple of 8 octets long. This field 143 contains zero of more TLV-encoded mobility options. The encoding 144 and format of defined options MUST follow the format specified in 145 Section 6.2 of [2]. The receiver MUST ignore and skip any options 146 with it does not understand. 148 This specification does not define any options valid for the 149 Generic Notification Request message. 151 If no options are present in this message, no padding is necessary 152 and the Header Len field in the Mobility Header will be set to 0. 154 2.2 Generic Notification Acknowledgement Message 156 The Generic Notification Acknowledgement message is used by the home 157 agent to notify the mobile node, or vice-versa, that there is an 158 event that requires attention. This packet is sent as described in 159 Section 3. 161 The Generic Notification Acknowledgement message uses the MH Type 162 value (TBD). When this value is indicated in the MH Type field, the 163 format of the Message Data field in the Mobility Header is as 164 follows: 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Status | Sequence # | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | 172 . . 173 . Mobility options . 174 . . 175 | | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Status 180 8-bit unsigned integer indicating the disposition of the Signaling 181 Request. Values of the Status field less than 128 indicate that 182 the Signaling Request was accepted by the receiving node. Values 183 greater than or equal to 128 indicate that the Signaling Request 184 was rejected by the receiving node. The following Status values 185 are currently defined: 187 0 Notification Request accepted 189 128 Reason unspecified 191 129 Administratively prohibited 193 130 Insufficient resources 195 131 Unsupported mobility option 197 132 Not home agent for this mobile node 199 Sequence # 201 An 8-bit unsigned integer used by the receiving node to sequence 202 Generic Notification Requests and by the sending node to match a 203 returned Generic Notification Acknowledgement with this Generic 204 Notification Request. The sequence number in the Generic 205 Notification Acknowledgement is copied from the sequence number 206 field in the Generic Notification Request. 208 Mobility options 210 Variable-length field of such length that the complete Mobility 211 Header is an integer multiple of 8 octets long. This field 212 contains zero of more TLV-encoded mobility options. The encoding 213 and format of defined options MUST follow the format specified in 214 Section 6.2 of [2]. The receiver MUST ignore and skip any options 215 with it does not understand. 217 This specification does not define any options valid for the 218 Generic Notification Acknowledgement message. 220 If no options are present in this message, no padding is necessary 221 and the Header Len field in the Mobility Header will be set to 0. 223 3. Sending Generic Notification Messages 225 3.1 Sending Generic Notification Request Messages 227 When sending a Generic Notification message, the sending node 228 constructs the packet as it would any other Mobility Header, except: 230 o The MH Type field MUST be set to (TBD). 231 o The Acknowledge (A) bit MAY be set to indicate the receiver must 232 send a Generic Notification Acknowledgement. 234 The Generic Notification Request message MUST use the home agent to 235 mobile node IPsec ESP authentication SA for integrity protection. 237 3.2 Sending Generic Notification Acknowledgement Messages 239 A Generic Notification Acknowledgement message should be sent to 240 indicate receipt of a Generic Notification Request as follows: 242 o If the Generic Notification Request was discarded because it 243 does not meet the requirements as specified in [2] described in 244 Section 4, a Generic Notification Acknowledgement MUST NOT be 245 sent. Otherwise, the treatment depends on the below rule. 247 o If the Acknowledgement (A) bit is set in the Generic 248 Notification Request, a Generic Notification Acknowledgement 249 MUST be sent. Otherwise, the treatment depends on the below 250 rule. 252 o If the Generic Notification Request was discarded for any other 253 reason, a Generic Notification Acknowledgement SHOULD be sent. 255 If the Source Address field of the IPv6 header that carried the 256 Generic Notification Request does not contain a unicast address, the 257 Generic Notification Acknowledgement MUST NOT be sent, and the 258 Generic Notification Request packet MUST be silently discarded. 259 Otherwise, the acknowledgement MUST be sent to the Source Address. 261 4. Receiving Generic Notification Messages 263 Upon receiving a Generic Notification message, the Mobility Header 264 MUST be verified as specified in [2], specifically: 266 o The Checksum, MH type, Payload Proto and Header Len fields MUST 267 meet the requirements of Section 9.2 of [2]. 269 o The packet MUST be covered by the home agent to mobile node 270 IPsec ESP authentication SA for integrity protection. 272 If the packet is dropped due to the above tests, the receiving node 273 MUST follow the processing rules as Section 9.2 of [2]. For example, 274 it MUST send a Binding Error message with the Status field set to 2 275 (unrecognized MH Type value) if it does not support the message type. 277 Subsequent checks depend on the current mode of operation of the 278 node. 280 4.1 Receiving Generic Notification Request Messages 282 If the Generic Notification Request message is valid according to the 283 tests in Section 4, then it is processed further as follows: 285 o If the receiving node does not allow Generic Notification 286 Request messages, it MUST reject the request and SHOULD return a 287 Generic Notification Acknowledgement to the sender in which the 288 Status field is set to 129 (administratively prohibited). 290 o If the receiving node does not support the type of Mobility 291 Option in the Generic Notification Request message, it MUST 292 reject the request and SHOULD return a Generic Notification 293 Acknowledgement to the sender in which the Status field is set 294 to 131 (unsupported mobility option). 296 Subsequent checks depend on the current mode of operation of the 297 node. 299 4.1.1 Mobile Node Operation 301 If the mobile node rejects the Generic Notification Request message 302 for any other reason than specified in Section 4, it SHOULD return a 303 Generic Notification Acknowledgement to the home agent in which the 304 Status field is set to 128 (reason unspecified). 306 4.1.2 Home Agent Operation 308 If the receiving node is a home agent, it MUST perform these 309 additional checks: 311 o If the home agent has no entry marked as a home registration in 312 its Binding Cache for this mobile node, then this node MUST 313 reject the request and SHOULD return a Generic Notification 314 Acknowledgement to the mobile node in which the Status field is 315 set to 132 (not home agent for this mobile node). 317 o If the home agent cannot process the Generic Notification 318 Request message because it is over-utilized, it MUST reject the 319 request and SHOULD return a Generic Notification Acknowledgement 320 to the mobile node in which the Status field is set to 130 321 (insufficient resources). 323 If the home agent rejects the Generic Notification Request message 324 for any other reason, it SHOULD return a Generic Notification 325 Acknowledgement to the mobile node in which the Status field is set 326 to 128 (reason unspecified). 328 4.1.3 Retransmissions 329 If the sender has set the Acknowledge (A) bit in the Generic 330 Notification Request, but does not receive a Generic Notification 331 Acknowledgement, then it MAY retransmit the message, until a response 332 is received. The initial value for the retransmission timer is 333 INITIAL_MH_NOTIFICATION_TIMEOUT. The retransmissions by the sender 334 MUST use an exponential back-off mechanism, in which the timeout 335 period is doubled upon each retransmission, until either the sender 336 gets a response from the target node, or the timeout period reaches 337 the value MAX_MH_NOTIFICATION_TIMEOUT. 339 5. Protocol Constants 341 INITIAL_MH_NOTIFICATION_TIMEOUT 5 seconds 342 MAX_MH_NOTIFICATION_TIMEOUT 20 seconds 344 6. IANA Considerations 346 A new Mobility Header type is required for the following new message 347 described in Section 2: 349 (TBD) Generic Notification Request Message 350 (TBD) Generic Notification Acknowledgement Message 352 7. Security Considerations 354 As with other messages in [2], the Generic Notification message MUST 355 use the home agent to mobile node ESP encryption SA for 356 confidentiality protection, and MUST use the home agent to mobile 357 node ESP authentication SA for integrity protection. 359 The Generic Notification message MAY use the IPsec ESP SA in place 360 for Binding Updates and Acknowledgements as specified in Section 5.1 361 of [2], in order to reduce the number of configured security 362 associations. This also gives the message authenticity protection. 364 8. References 366 8.1 Normative Reference 368 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 369 Levels", BCP 14, RFC 2119, March 1997. 371 [2] Johnson, D. Perkins, C., and Arkko, J., "Mobility Support in 372 IPv6", RFC 3775, June, 2004 373 8.2 Informative references 375 Acknowledgments 377 Thanks to Hui Deng, James Kempf and Vijay Devarapalli for their 378 initial review of the draft. 380 Author's Addresses 382 Brian Haley 383 Hewlett-Packard Company 384 110 Spitbrook Road 385 Nashua, NH 03062, USA 386 Email: brian.haley@hp.com 388 Sri Gundavelli 389 Cisco Systems 390 170 W.Tasman Drive 391 San Jose, CA 95134, USA 392 Email: sgundave@cisco.com 394 Full Copyright Statement 396 Copyright (C) The IETF Trust (2007). 398 This document is subject to the rights, licenses and restrictions 399 contained in BCP 78, and except as set forth therein, the authors 400 retain all their rights. 402 This document and the information contained herein are provided on an 403 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 404 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 405 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 406 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 407 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 408 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 410 Intellectual Property 412 The IETF takes no position regarding the validity or scope of any 413 Intellectual Property Rights or other rights that might be claimed to 414 pertain to the implementation or use of the technology described in 415 this document or the extent to which any license under such rights 416 might or might not be available; nor does it represent that it has 417 made any independent effort to identify any such rights. Information 418 on the procedures with respect to rights in RFC documents can be 419 found in BCP 78 and BCP 79. 421 Copies of IPR disclosures made to the IETF Secretariat and any 422 assurances of licenses to be made available, or the result of an 423 attempt made to obtain a general license or permission for the use of 424 such proprietary rights by implementers or users of this 425 specification can be obtained from the IETF on-line IPR repository at 426 http://www.ietf.org/ipr. 428 The IETF invites any interested party to bring to its attention any 429 copyrights, patents or patent applications, or other proprietary 430 rights that may cover technology that may be required to implement 431 this standard. Please address the information to the IETF at 432 ietf-ipr@ietf.org. 434 Acknowledgement 436 Funding for the RFC Editor function is provided by the IETF 437 Administrative Support Activity (IASA).