idnits 2.17.1 draft-ietf-mip4-experimental-messages-01.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 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 477), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 477. ** Found boilerplate matching RFC 3979, Section 5, paragraph 1 (on line 379), which is fine, but *also* found old RFC 2026, Section 10.4A text on line 467. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 392), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 473. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 1 boilerplate, a section with a similar start was also found: The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Experimental extensions can be carried in experimental messages and standards defined messages. In the later case, it is suggested that experimental extensions MUST not be used in deployed products and usage be restricted to experimentations only. -- 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 108 -- Looks like a reference, but probably isn't: '128-255' on line 104 -- Looks like a reference, but probably isn't: '64-127' on line 295 -- Looks like a reference, but probably isn't: '128-192' on line 296 -- Looks like a reference, but probably isn't: '0-255' on line 100 == Unused Reference: '3' is defined on line 412, 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 (~~), 6 warnings (==), 11 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 11 May 2004 Cisco Systems 6 Experimental Message, Extension and Error Codes for Mobile IPv4 7 draft-ietf-mip4-experimental-messages-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet 15 Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working 17 documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them other than 23 as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (c) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 Mobile IPv4 message types range from 0 to 255. This document 38 reserves a message type for use by an individual, company, or 39 organization for experimental purpose, to evaluate enhancements 40 to Mobile IPv4 messages before formal standards proposal. 42 Table of Contents 44 1. Introduction.............................................2 45 2. Terminology..............................................3 46 3. Experimental Message.....................................3 47 4. Experimental Extensions..................................4 48 4.1 Non-skippable Mobile IPv4 Experimental Extension........5 49 4.2 Non-skippable Router Discovery Experimental Extension...5 50 4.3 Skippable Mobile IPv4 Experimental Extension............6 51 4.4 Skippable ICMP Router Discovery Experimental Extension..7 52 5. Experimental Error Codes.................................7 53 6. Mobility Entity Considerations...........................7 54 7. IANA Considerations......................................8 55 8. Security Considerations..................................8 56 9. Backward Compatibility Considerations....................9 57 10. Intellectual Property Rights............................9 58 11. Acknowledgements........................................9 59 12. References.............................................10 60 12.1 Normative References..................................10 61 12.2 Informative References................................10 62 13. Authors' Addresses.....................................10 63 Intellectual Property Statement............................11 64 Full Copyright Statement...................................11 66 1. Introduction 68 Mobile IPv4 message types range from 0 to 255. This document 69 reserves a message type for experimental purposes, to evaluate 70 enhancements to Mobile IPv4 messages before formal standards 71 proposal. 73 Without experimental message capability, one would have to 74 select a type value from the range defined for IANA assignment, 75 which may result in collisions. 77 Also, Mobile IP defines a general extension mechanism to allow 78 optional information to be carried by Mobile IP control 79 messages. Extensions are not skippable if defined in range 80 [0-127] and skippable if defined in range [128-255]. This 81 document reserves extension types in both the skippable and 82 non-skippable range for experimental use. 84 Mobile IPv4 defines error codes for use by the FA [64-127] and 85 HA [128-192]. This document reserves an error code in both 86 these ranges for experimental use. 88 This document defines and reserves experimental numbers as per 89 the recommendation of BCP 82 (section 2.2), RFC 3692. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 94 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described 96 in [1]. 98 In addition, this document frequently uses the following terms: 100 EXP-MSG-TYPE: A Mobile-IPv4 message number in the range [0-255] 101 to be assigned by IANA for experimental use. 103 EXP-SKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery 104 (advertisement) extension number in the range [128-255] to be 105 assigned by IANA for experimental use. 107 EXP-NONSKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery 108 (advertisement) extension number in the range [0-127] to be 109 assigned by IANA for experimental use. 111 EXP-HA-ERROR-CODE: A Mobile-IPv4 error code in the range [128- 112 192] for use by HA in reply messages to indicate error 113 condition. 115 EXP-FA-ERROR-CODE: A Mobile-IPv4 error code in the range [64- 116 127] for use by FA in reply messages to indicate error 117 condition. 119 Mobility Entity: Entities as defined in [2] (home agent, 120 foreign agent and mobile node). 122 3. Experimental Message 124 Since the nature and purpose of an experimental message cannot 125 be known in advance, the structure is defined as an opaque 126 payload. Entities implementing the message can interpret the 127 message as per their implementation. One suggestion is to 128 interpret based on extensions present in the message. 130 These messages may be used between the mobility entities (Home 131 Agent, Foreign Agent, and Mobile Node). Experimental messages 132 SHOULD be authenticated using any of the authentication 133 mechanism defined for Mobile IP ([2], [5]). 135 This message MAY contain extensions defined in Mobile IP, 136 including vendor specific extensions [4]. 138 IP fields: 139 Source Address Typically the interface address from which 140 the message is sent. 142 Destination Address The address of the agent or the Mobile 143 Node. 145 UDP fields: 147 Source Port Set according to RFC 768 (variable) 149 Destination Port Set to the value 434 151 Mobile IP fields shown below follow the UDP header: 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Type | Opaque. . . 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Type EXP-MSG-TYPE (To be assigned by IANA) 161 Opaque Zero or more octets of data, with structure defined 162 only by the particular experiment it is used for. 164 Once an experimental message has been tested and shown to be 165 useful, a permanent number should be obtained through the 166 normal assignment procedures. 168 A single experimental message type is recommended since this 169 message can contain extensions based on which the message can 170 be interpreted. 172 4. Experimental Extensions 174 This document reserves Mobile IPv4 extensions in both the 175 skippable and non-skippable range for experimental purposes. 176 The long extension format (for non-skippable extensions) and 177 short extension format (for skippable extensions), as defined 178 by [2] are used for Mobile IPv4 experimental extensions. 180 Also, ICMP router discovery extension numbers in both the 181 skippable and non-skippable range are reserved for experimental 182 use. 184 4.1 Non-skippable Mobile IPv4 Experimental Extension 186 This format is applicable for non-skippable extensions and may 187 carry information more than 256 bytes. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Sub-Type | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Opaque. . . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Type EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is 198 the type, which describes an experimental extension. 200 Sub-Type is a unique number given to each member in the 201 aggregated type. 203 Length Indicates the length (in bytes) of the data field 204 within this extension. It does NOT include the Type, 205 Sub-Type and Length bytes. 207 Opaque Zero or more octets of data, with structure defined 208 only by the particular experiment it is used for. 210 Since the length field is 16 bits wide, the extension data can 211 exceed 256 bytes in length. 213 4.2 Non-skippable Router Discovery Experimental Extension 215 This format is applicable for non-skippable extensions. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Length | Opaque . . . 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 Type EXP-NONSKIP-EXT-TYPE (to be assigned by IANA) is 223 the type, which describes an ICMP router discovery 224 experimental extension. 226 Length Indicates the length (in bytes) of the data field 227 within this extension. It does NOT include the Type, 228 Sub-Type and Length bytes. 230 Opaque Zero or more octets of data, with structure defined 231 only by the particular experiment it is used for. 233 A node, which receives a router advertisement with this 234 extension should ignore the extension if it does not recognize 235 it. 237 A mobility entity, which understands this extension, but does 238 not recognize it should drop (ignore) the router advertisement. 240 4.3 Skippable Mobile IPv4 Experimental Extension 242 This format is applicable for skippable extensions, which carry 243 information less than 256 bytes. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Sub-Type | Opaque. . . 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Type EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the 252 type, which describes an experimental extension. 254 Length Indicates the length (in bytes) of the data field 255 within this extension. It does NOT include the Type 256 and Length bytes. 258 Sub-Type is a unique number given to each member in the 259 aggregated type. 261 Opaque Zero or more octets of data, with structure defined 262 only by the particular experiment it is used for. 264 Since the length field is 8 bits wide, the extension data 265 cannot exceed 256 bytes in length. 267 4.4 Skippable ICMP Router Discovery Experimental Extension 269 This format is applicable for skippable ICMP router discovery 270 extensions. This extension should be ignored if an 271 implementation does not understand it. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | Opaque. . . 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type EXP-SKIP-EXT-TYPE (to be assigned by IANA) is the 280 type, which describes an experimental extension. 282 Length Indicates the length (in bytes) of the data field 283 within this extension. It does NOT include the Type 284 and Length bytes. 286 Opaque Zero or more octets of data, with structure defined 287 only by the particular experiment it is used for. 289 A node, which receives a router advertisement with this 290 extension should ignore the extension. 292 5. Experimental Error Codes 294 This document reserves reply error code EXP-FA-ERROR-CODE, in 295 the range [64-127], for use by the FA. This document also 296 reserves reply error code EXP-HA-ERROR-CODE, in the range [128- 297 192], for use by the HA. 299 These experimental error codes may be used in registration 300 reply messages. 302 It is recommended that experimental error codes are used 303 with experimental messages and extensions whenever none of the 304 standardized error codes are applicable. 306 6. Mobility Entity Considerations 307 Mobility entities can send and receive experimental messages. 308 Implementations that don't understand the message type SHOULD 309 silently discard the message. 311 Experimental extensions can be carried in experimental messages 312 and standards defined messages. In the later case, it is 313 suggested that experimental extensions MUST not be used in 314 deployed products and usage be restricted to experimentations 315 only. 317 7. IANA Considerations 319 IANA services are required for this draft. Since a new message 320 type is needed to be reserved as experimental, a value must be 321 assigned for EXP-MSG-TYPE from the Mobile IP control message 322 space. 324 Also, values for EXP-NONSKIP-EXT-TYPE and EXP-SKIP-EXT-TYPE 325 must be assigned for experimental extensions. 327 The value for EXP-NONSKIP-EXT-TYPE should be assigned from the 328 numbering space for non-skippable extensions which may appear 329 in control messages, and also (with the same number) from the 330 numbering space for non-skippable extensions which may appear 331 in ICMP router discovery messages. The value 127 is suggested 332 in both cases. 334 The value for EXP-SKIP-EXT-TYPE should be assigned from the 335 numbering space for skippable extensions which may appear in 336 control messages, and also (with the same number) from the 337 numbering space for skippable extensions which may appear in 338 ICMP router discovery messages. The value 255 is suggested in 339 both cases. 341 Also, values for EXP-HA-ERROR-CODE and EXP-FA-ERROR-CODE must 342 be assigned for experimental error code. The suggested values 343 are 192 for the EXP-HA-ERROR-CODE and 127 for the EXP-FA-ERROR- 344 CODE. 346 8. Security Considerations 348 Like all Mobile IP control messages, the experimental messages 349 MUST be authenticated as per the requirements specified in [2] 350 or [5]. Experimental messages without a valid authenticator 351 MUST be discarded. 353 9. Backward Compatibility Considerations 355 Mobility entities that don't understand the experimental 356 message MUST silently discard it. 358 Mobility entities that don't understand the experimental 359 skippable extensions MUST ignore them. Mobility entities that 360 don't understand the non-skippable experimental extensions 361 MUST silently discard the message containing them. 363 FA and HA SHOULD include experimental error code in reply 364 message only if they have a general indication that the 365 receiving entity would be able to parse it. An indication of 366 this is if the request message was of type EXP-MSG-TYPE or 367 contained at-least one experimental extension. 369 10. Intellectual Property Rights 371 The IETF takes no position regarding the validity or scope of 372 any Intellectual Property Rights or other rights that might be 373 claimed to pertain to the implementation or use of the 374 technology described in this document or the extent to which 375 any license under such rights might or might not be available; 376 nor does it represent that it has made any independent effort 377 to identify any such rights. Information on the procedures 378 with respect to rights in RFC documents can be found in BCP 78 379 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of 383 an attempt made to obtain a general license or permission for 384 the use of such proprietary rights by implementers or users of 385 this specification can be obtained from the IETF on-line IPR 386 repository at http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention 389 any copyrights, patents or patent applications, or other 390 proprietary rights that may cover technology that may be 391 required to implement this standard. Please address the 392 information to the IETF at ietf-ipr@ietf.org. 394 11. Acknowledgements 395 The authors would like to acknowledge Henrik Levkowetz for his 396 detailed review of the draft and suggestion to incorporate 397 experimental extensions in this draft. 399 The authors would also like to acknowledge Thomas Narten for 400 his initial review of the draft and reference to [6] for 401 general guidelines. 403 12. References 405 12.1 Normative References 407 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 408 Levels", BCP 14, RFC 2119, March 1997. 410 [2] Perkins, C., "IP Mobility Support", RFC 3344, August 2002. 412 [3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 413 RFC 1700, October 1994. 415 12.2 Informative References 417 [4] G. Dommety, K. Leung, "Mobile IP Vendor/Organization-Specific 418 Extensions" RFC 3115, April 2001 420 [5] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 421 Extensions", RFC 3012, November 2000 423 [6] T. Narten, "Assigning Experimental and Testing Numbers 424 Considered Useful", BCP 82, RFC 3692, January, 2004 426 13. Authors' Addresses 428 Questions and comments about this draft should be directed at 429 the Mobile IPv4 working group: 431 mip4@ietf.org 433 Questions and comments about this draft may also be directed to 434 the authors: 436 Alpesh Patel 437 Cisco Systems 438 170 W. Tasman Drive, 439 San Jose, CA 95134 440 USA 441 Email: alpesh@cisco.com 442 Phone: +1 408-853-9580 444 Kent Leung 445 Cisco Systems 446 170 W. Tasman Drive, 447 San Jose, CA 95134 448 USA 449 Email: kleung@cisco.com 450 Phone: +1 408-526-5030 452 Intellectual Property Statement 454 The IETF takes no position regarding the validity or scope of 455 any intellectual property or other rights that might be claimed 456 to pertain to the implementation or use of the technology 457 described in this document or the extent to which any license 458 under such rights might or might not be available; neither does 459 it represent that it has made any effort to identify any such 460 rights. Information on the IETF's procedures with respect to 461 rights in standards-track and standards-related documentation 462 can be found in BCP-11. Copies of claims of rights made 463 available for publication and any assurances of licenses to be 464 made available, or the result of an attempt made to obtain a 465 general license or permission for the use of such proprietary 466 rights by implementors or users of this specification can be 467 obtained from the IETF Secretariat. 469 The IETF invites any interested party to bring to its attention 470 any copyrights, patents or patent applications, or other 471 proprietary rights which may cover technology that may be 472 required to practice this standard. Please address the 473 information to the IETF Executive Director. 475 Full Copyright Statement 477 Copyright (C) The Internet Society (2004). All Rights Reserved. 479 This document and translations of it may be copied and 480 furnished to others, and derivative works that comment on or 481 otherwise explain it or assist in its implementation may be 482 prepared, copied, published and distributed, in whole or in 483 part, without restriction of any kind, provided that the above 484 copyright notice and this paragraph are included on all such 485 copies and derivative works. However, this document itself may 486 not be modified in any way, such as by removing the copyright 487 notice or references to the Internet Society or other Internet 488 organizations, except as needed for the purpose of developing 489 Internet standards in which case the procedures for copyrights 490 defined in the Internet Standards process must be followed, or 491 as required to translate it into languages other than English. 493 The limited permissions granted above are perpetual and will 494 not be revoked by the Internet Society or its successors or 495 assigns. 497 This document and the information contained herein is provided 498 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 499 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 500 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 501 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 502 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 503 PARTICULAR PURPOSE. 505 Acknowledgement 507 Funding for the RFC Editor function is currently provided by 508 the Internet Society.