idnits 2.17.1 draft-ietf-mip4-experimental-messages-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 478. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 496), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0-127' on line 115 -- Looks like a reference, but probably isn't: '128-255' on line 111 -- Looks like a reference, but probably isn't: '64-127' on line 122 -- Looks like a reference, but probably isn't: '128-192' on line 118 -- Looks like a reference, but probably isn't: '0-255' on line 107 == Unused Reference: '3' is defined on line 415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '2') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 1700 (ref. '3') (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 3012 (ref. '5') (Obsoleted by RFC 4721) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Alpesh Patel 3 INTERNET DRAFT Kent Leung 4 10 September 2004 Cisco Systems 6 Experimental Message, Extension and Error Codes for Mobile IPv4 7 draft-ietf-mip4-experimental-messages-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been 13 disclosed, and any of which I become aware will be disclosed, in 14 accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 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 This Internet-Draft will expire on March 9, 2005. 35 Copyright Notice 37 Copyright (c) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 Mobile IPv4 message types range from 0 to 255. This document 42 reserves a message type for use by an individual, company, or 43 organization for experimental purpose, to evaluate enhancements 44 to Mobile IPv4 messages before formal standards proposal. 46 Table of Contents 48 1. Introduction.............................................2 49 2. Terminology..............................................3 50 3. Experimental Message.....................................3 51 4. Experimental Extensions..................................4 52 4.1 Non-skippable Mobile IPv4 Experimental Extension........5 53 4.2 Non-skippable ICMP Router Discovery Exp. Extension......5 54 4.3 Skippable Mobile IPv4 Experimental Extension............6 55 4.4 Skippable ICMP Router Discovery Experimental Extension..7 56 5. Experimental Error Codes.................................7 57 6. Mobility Entity Considerations...........................7 58 7. IANA Considerations......................................8 59 7.1 New Message Type........................................8 60 7.2 New Extension Values....................................8 61 7.3 New Error Codes.........................................8 62 9. Backward Compatibility Considerations....................9 63 10. Acknowledgements........................................9 64 11. References..............................................9 65 11.1 Normative References..................................10 66 11.2 Informative References................................10 67 12. Authors' Addresses.....................................10 68 Intellectual Property Statement............................11 69 Disclaimer of Validity.....................................11 70 Copyright Statement........................................11 72 1. Introduction 74 Mobile IPv4 message types range from 0 to 255. This document 75 reserves a message type for experimental purposes, to evaluate 76 enhancements to Mobile IPv4 messages before formal standards 77 proposal. 79 Without experimental message capability, one would have to 80 select a type value from the range defined for IANA assignment, 81 which may result in collisions. 83 Within a message, Mobile IP defines a general extension 84 mechanism to allow optional information to be carried by Mobile 85 IP control messages. Extensions are not skippable if defined in 86 the range [0-127] and skippable if defined in the range [128- 87 255]. This document reserves extension types in both the 88 skippable and non-skippable ranges for experimental use. 90 Mobile IPv4 defines error codes for use by the FA [64-127] and 91 HA [128-192]. This document reserves an error code in both 92 these ranges for experimental use. 94 The definition of experimental numbers in this document is done 95 according to the recommendation of Section 2.2 of BCP 82, 96 RFC 3692. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 101 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described 103 in [1]. 105 In addition, this document frequently uses the following terms: 107 EXP-MSG-TYPE: A Mobile-IPv4 message number in the range [0-255] 108 to be assigned by IANA for experimental use. 110 EXP-SKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery 111 Agent Advertisement extension number in the range [128-255] to 112 be assigned by IANA for experimental use. 114 EXP-NONSKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery 115 Agent Advertisement extension number in the range [0-127] to be 116 assigned by IANA for experimental use. 118 EXP-HA-ERROR-CODE: A Mobile-IPv4 error code in the range [128- 119 192] for use by HA in MIPv4 reply messages to indicate an error 120 condition. 122 EXP-FA-ERROR-CODE: A Mobile-IPv4 error code in the range [64- 123 127] for use by FA in reply messages to indicate error 124 condition. 126 Mobility Entity: Entities as defined in [2] (home agent, 127 foreign agent and mobile node). 129 3. Experimental Message 131 Since the nature and purpose of an experimental message cannot 132 be known in advance, the structure is defined as having an 133 opaque payload. Entities implementing the message can interpret 134 the message as per their implementation. One suggestion is to 135 interpret based on extensions present in the message. 137 These messages may be used between the mobility entities (Home 138 Agent, Foreign Agent, and Mobile Node). Experimental messages 139 MUST be authenticated using any of the authentication mechanism 140 defined for Mobile IP ([2], [5]). 142 This message MAY contain extensions defined in Mobile IP, 143 including vendor specific extensions [4]. 145 IP fields: 147 Source Address: Typically the interface address from which 148 the message is sent. 150 Destination Address: The address of the agent or the Mobile 151 Node. 153 UDP fields: 155 Source Port Set according to RFC 768 (variable) 157 Destination Port Set to the value 434 159 Mobile IP fields shown below follow the UDP header: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Opaque. . . 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Type EXP-MSG-TYPE (To be assigned by IANA) 169 Opaque Zero or more octets of data, with structure defined 170 only by the particular experiment it is used for. 172 Once an experimental message has been tested and shown to be 173 useful, a permanent number should be obtained through the 174 normal IANA numbers assignment procedures. 176 A single experimental message type is defined. This message can 177 contain extensions based on which the message can be 178 interpreted. 180 4. Experimental Extensions 182 This document reserves Mobile IPv4 extensions in both the 183 skippable and non-skippable ranges for experimental purposes. 184 The long extension format (for non-skippable extensions) and 185 short extension format (for skippable extensions), as defined 186 by [2], are used for Mobile IPv4 experimental extensions. 188 Also, ICMP router discovery extension numbers in both the 189 skippable and non-skippable ranges are reserved for 190 experimental use. 192 4.1 Non-skippable Mobile IPv4 Experimental Extension 194 This format is applicable for non-skippable extensions and may 195 carry information more than 256 bytes. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Sub-Type | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Opaque. . . 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Type EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is 206 the type, which describes an experimental extension. 208 Sub-Type is a unique number given to each member in the 209 aggregated type. 211 Length Indicates the length (in bytes) of the data field 212 within this extension. It does NOT include the Type, 213 Sub-Type and Length fields. 215 Opaque Zero or more octets of data, with structure defined 216 only by the particular experiment it is used for. 218 Since the length field is 16 bits wide, the extension data can 219 exceed 256 bytes in length. 221 4.2 Non-skippable ICMP Router Discovery Exp. Extension 223 This format is applicable for non-skippable extensions. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | Opaque . . . 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Type EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is 231 the type, which describes an ICMP router discovery 232 experimental extension. 234 Length Indicates the length (in bytes) of the data field 235 within this extension. It does NOT include the Type 236 and Length fields. 238 Opaque Zero or more octets of data, with structure defined 239 only by the particular experiment it is used for. 241 A node which receives a router advertisement with this 242 extension should ignore the extension if it does not recognize 243 it. 245 A mobility entity which understands this extension, but does 246 not recognize it, should drop (ignore) the router 247 advertisement. 249 4.3 Skippable Mobile IPv4 Experimental Extension 251 This format is applicable for skippable extensions, which carry 252 information less than 256 bytes. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Type | Length | Sub-Type | Opaque. . . 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Type EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the 261 type, which describes an experimental extension. 263 Length Indicates the length (in bytes) of the data field 264 within this extension. It does NOT include the Type 265 and Length fields. 267 Sub-Type is a unique number given to each member in the 268 aggregated type. 270 Opaque Zero or more octets of data, with structure defined 271 only by the particular experiment it is used for. 273 Since the length field is 8 bits wide, the extension data 274 cannot exceed 256 bytes in length. 276 4.4 Skippable ICMP Router Discovery Experimental Extension 278 This format is applicable for skippable ICMP router discovery 279 extensions. This extension should be ignored if an 280 implementation does not understand it. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | Opaque. . . 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Type EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the 289 type, which describes an experimental extension. 291 Length Indicates the length (in bytes) of the data field 292 within this extension. It does NOT include the Type 293 and Length fields. 295 Opaque Zero or more octets of data, with structure defined 296 only by the particular experiment it is used for. 298 5. Experimental Error Codes 300 This document reserves reply error code EXP-FA-ERROR-CODE for 301 use by the FA. This document also reserves reply error code 302 EXP-HA-ERROR-CODE for use by the HA. 304 These experimental error codes may be used in registration 305 reply messages. 307 It is recommended that experimental error codes be used 308 with experimental messages and extensions whenever none of the 309 standardized error codes are applicable. 311 6. Mobility Entity Considerations 313 Mobility entities can send and receive experimental messages. 314 Implementations that don't understand the message type SHOULD 315 silently discard the message. 317 Experimental extensions can be carried in experimental messages 318 and standards defined messages. In the latter case, it is 319 suggested that experimental extensions MUST NOT be used in 320 deployed products and usage be restricted to experimentations 321 only. 323 7. IANA Considerations 325 This document defines a control message to be used between 326 mobility entities, two new extension formats and two new error 327 codes. To ensure correct interoperation based on this 328 specification, IANA has reserved values in the Mobile IPv4 329 number space, as defined in [2] for one new message type, two 330 new extensions and two error codes. 332 7.1 New Message Type 334 A new Mobile IPv4 control message using UDP port 434, type EXP- 335 MSG-TYPE has been defined by IANA. This value has been taken 336 from the same number space as Mobile IP Registration Request 337 (Type = 1), and Mobile IP Registration Reply (Type = 3). (The 338 value 255 is suggested in this case). 340 7.2 New Extension Values 342 The following extension types are introduced by this 343 specification: 345 Experimental non-skippable extension: The value for EXP- 346 NONSKIP-EXT-TYPE has been assigned from the numbering space for 347 non-skippable extensions, which may appear in Mobile IPv4 348 control messages. 350 Also, the same number, EXP-NONSKIP-EXT-TYPE has been assigned 351 from the numbering space for non-skippable extensions, which 352 may appear in ICMP router discovery messages. (The value 127 353 is suggested in both cases.) 355 Experimental skippable extension: The value EXP-SKIP-EXT-TYPE 356 has been assigned from the numbering space for skippable 357 extensions, which may appear in Mobile IPv4 control messages. 359 Also, the same number, EXP-SKIP-EXT-TYPE has been assigned from 360 the numbering space for skippable extensions which may appear 361 in ICMP router discovery messages. (The value 255 is suggested 362 in both cases.) 364 7.3 New Error Codes 365 The value EXP-HA-ERROR-CODE has been defined by IANA to be used 366 as code field in messages generated by HA. (The value 192 is 367 suggested for this code.) 369 Also, value EXP-FA-ERROR-CODE has been defined by IANA to be 370 used as the code field in messages generated by the FA. (The 371 value 127 is suggested for this code.) 373 8. Security Considerations 375 Like all Mobile IP control messages, the experimental messages 376 MUST be authenticated as per the requirements specified in [2] 377 or [5]. Experimental messages without a valid authenticator 378 SHOULD be discarded. 380 9. Backward Compatibility Considerations 382 Mobility entities that don't understand the experimental 383 message MUST silently discard it. 385 Mobility entities that don't understand the experimental 386 skippable extensions MUST ignore them. Mobility entities that 387 don't understand the non-skippable experimental extensions 388 MUST silently discard the message containing them. This 389 behavior is consistent with section 1.8 of [2]. 391 Foreign Agents and Home Agents SHOULD include an experimental 392 error code in a reply message only if they have a general 393 indication that the receiving entity would be able to parse it. 394 An indication of this is if the request message was of type 395 EXP-MSG-TYPE or contained at least one experimental extension. 397 10. Acknowledgements 399 The authors would like to acknowledge Henrik Levkowetz for his 400 detailed review of the draft and suggestion to incorporate 401 experimental extensions in this draft. 403 The authors would also like to acknowledge Thomas Narten for 404 his initial review of the draft and reference to [6] for 405 general guidelines. 407 11. References 408 11.1 Normative References 410 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 411 Levels", BCP 14, RFC 2119, March 1997. 413 [2] Perkins, C., "IP Mobility Support", RFC 3344, August 2002. 415 [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 416 RFC 1700, October 1994. 418 11.2 Informative References 420 [4] G. Dommety, K. Leung, "Mobile IP Vendor/Organization-Specific 421 Extensions" RFC 3115, April 2001 423 [5] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 424 Extensions", RFC 3012, November 2000 426 [6] T. Narten, "Assigning Experimental and Testing Numbers 427 Considered Useful", BCP 82, RFC 3692, January, 2004 429 12. Authors' Addresses 431 Questions and comments about this draft should be directed at 432 the Mobile IPv4 working group: 434 mip4@ietf.org 436 Questions and comments about this draft may also be directed to 437 the authors: 439 Alpesh Patel 440 Cisco Systems 441 170 W. Tasman Drive, 442 San Jose, CA 95134 443 USA 444 Email: alpesh@cisco.com 445 Phone: +1 408-853-9580 447 Kent Leung 448 Cisco Systems 449 170 W. Tasman Drive, 450 San Jose, CA 95134 451 USA 452 Email: kleung@cisco.com 453 Phone: +1 408-526-5030 455 Intellectual Property Statement 457 The IETF takes no position regarding the validity or scope of 458 any Intellectual Property Rights or other rights that might be 459 claimed to pertain to the implementation or use of the 460 technology described in this document or the extent to which 461 any license under such rights might or might not be available; 462 nor does it represent that it has made any independent effort 463 to identify any such rights. Information on the procedures 464 with respect to rights in RFC documents can be found in BCP 78 465 and BCP 79. 467 Copies of IPR disclosures made to the IETF Secretariat and any 468 assurances of licenses to be made available, or the result of 469 an attempt made to obtain a general license or permission for 470 the use of such proprietary rights by implementers or users of 471 this specification can be obtained from the IETF on-line IPR 472 repository at http://www.ietf.org/ipr. 474 The IETF invites any interested party to bring to its attention 475 any copyrights, patents or patent applications, or other 476 proprietary rights that may cover technology that may be 477 required to implement this standard. Please address the 478 information to the IETF at ietf-ipr@ietf.org. 480 Disclaimer of Validity 482 This document and the information contained herein are provided 483 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 484 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 485 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 486 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 487 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 488 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 489 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 491 Copyright Statement 493 Copyright (C) The Internet Society (2004). This document is 494 subject to the rights, licenses and restrictions contained in 495 BCP 78, and except as set forth therein, the authors retain all 496 their rights. 498 Acknowledgement 500 Funding for the RFC Editor function is currently provided by 501 the Internet Society.