diff options
Diffstat (limited to 'doc/rfc/rfc4064.txt')
| -rw-r--r-- | doc/rfc/rfc4064.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4064.txt b/doc/rfc/rfc4064.txt new file mode 100644 index 0000000..8c7564f --- /dev/null +++ b/doc/rfc/rfc4064.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group A. Patel +Request for Comments: 4064 K. Leung +Category: Standards Track Cisco Systems + May 2005 + + + Experimental Message, Extensions, and Error Codes for Mobile IPv4 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Mobile IPv4 message types range from 0 to 255. This document + reserves a message type for use by an individual, company, or + organization for experimental purposes, to evaluate enhancements to + Mobile IPv4 messages before a formal standards proposal is issued. + + + + + + + + + + + + + + + + + + + + + + + + + +Patel & Leung Standards Track [Page 1] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + +Table of Contents + + 1. Introduction ................................................. 2 + 2. Terminology .................................................. 3 + 3. Experimental Message ......................................... 3 + 4. Experimental Extensions ...................................... 4 + 4.1. Non-skippable Mobile IPv4 Experimental Extension ....... 5 + 4.2. Non-skippable ICMP Router Discovery Exp. Extension ..... 5 + 4.3. Skippable Mobile IPv4 Experimental Extension ........... 6 + 4.4. Skippable ICMP Router Discovery Experimental Extension . 6 + 5. Experimental Error Codes ..................................... 7 + 6. Mobility Entity Considerations ............................... 7 + 7. IANA Considerations .......................................... 7 + 7.1. New Message Type ....................................... 8 + 7.2. New Extension Values ................................... 8 + 7.3. New Error Codes ........................................ 8 + 8. Security Considerations ...................................... 8 + 9. Backward Compatibility Considerations ........................ 9 + 10. Acknowledgements.............................................. 9 + 11. References ................................................... 9 + 11.1. Normative References ................................... 9 + 11.2. Informative References ................................. 9 + +1. Introduction + + Mobile IPv4 message types range from 0 to 255. This document + reserves a message type for experimental purposes, to evaluate + enhancements to Mobile IPv4 messages before a formal standards + proposal is issued. + + Without experimental message capability, one would have to select a + type value from the range defined for IANA assignment, which may + result in collisions. + + Within a message, Mobile IP defines a general extension mechanism + allowing optional information to be carried by Mobile IP control + messages. Extensions are not skippable if defined in the range [0- + 127] and are skippable if defined in the range [128-255]. This + document reserves extension types in both the skippable and non- + skippable ranges for experimental use. + + Mobile IPv4 defines error codes for use by the FA [64-127] and HA + [128-192]. This document reserves an error code in both of these + ranges for experimental use. + + The definition of experimental numbers in this document is made + according to the recommendation of Section 2.2 of BCP 82, RFC 3692. + + + + +Patel & Leung Standards Track [Page 2] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [1]. + + In addition, this document frequently uses the following terms: + + EXP-MSG-TYPE: A Mobile-IPv4 message number assigned for experimental + use. IANA has assigned message number 255 for this. + + EXP-SKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery Agent + Advertisement extension number assigned for experimental use. IANA + has assigned extension number 255 for this. + + EXP-NONSKIP-EXT-TYPE: A Mobile-IPv4 and ICMP router discovery Agent + Advertisement extension number for experimental use. IANA has + assigned extension number 127 for this. + + EXP-HA-ERROR-CODE: A Mobile-IPv4 error code for use by the HA in + MIPv4 reply messages to indicate an error condition. IANA has + assigned error code 192 for this. + + EXP-FA-ERROR-CODE: A Mobile-IPv4 error code for use by FA in reply + messages to indicate an error condition. IANA has assigned error + code 127 for this. + + Mobility Entity: Entities as defined in [2] (home agent, foreign + agent, and mobile node). + +3. Experimental Message + + As the nature and purpose of an experimental message cannot be known + in advance, the structure is defined as having an opaque payload. + Entities implementing the message can interpret the message according + to their implementation. Interpreting based on extensions present in + the message is one suggestion. + + These messages may be used between the mobility entities (Home Agent, + Foreign Agent, and Mobile Node). Experimental messages MUST be + authenticated using any of the authentication mechanisms defined for + Mobile IP ([2], [5]). + + This message MAY contain extensions defined in Mobile IP, including + vendor-specific extensions [4]. + + + + + + +Patel & Leung Standards Track [Page 3] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + + IP fields: + + Source Address: Typically the interface address from which + the message is sent. + + Destination Address: The address of the agent or the Mobile + Node. + + UDP fields: + + Source Port Set according to RFC 768 (variable) + + Destination Port Set to the value 434 + + Mobile IP fields shown below follow the UDP header. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Opaque. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 255 (EXP-MSG-TYPE) + + Opaque Zero or more octets of data, with structure defined only + by the particular experiment it is used for. + + Once an experimental message has been tested and shown to be useful, + a permanent number should be obtained through the normal IANA numbers + assignment procedures. + + A single experimental message type is defined. This message can + contain extensions based on which the message can be interpreted. + + Up-to-date values for the message types for Mobile IP control + messages are specified in the most recent "Assigned Numbers" [3]. + +4. Experimental Extensions + + This document reserves Mobile IPv4 extensions in both the skippable + and non-skippable ranges for experimental purposes. The long + extension format (for non-skippable extensions) and short extension + format (for skippable extensions), as defined by [2], are used for + Mobile IPv4 experimental extensions. + + Also, ICMP router discovery extension numbers in both the skippable + and non-skippable ranges are reserved for experimental use. + + + + +Patel & Leung Standards Track [Page 4] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + +4.1. Non-skippable Mobile IPv4 Experimental Extension + + This format is applicable for non-skippable extensions and may carry + information more than 256 bytes. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Sub-Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Opaque. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 127 (EXP-NONSKIP-EXT-TYPE) is the type, which describes an + experimental extension. + + Sub-Type A unique number given to each member in the aggregated + type. + + Length Indicates the length (in bytes) of the data field within + this extension. It does NOT include the Type, Sub-Type, + and Length fields. + + Opaque Zero or more octets of data, with structure defined only by + the particular experiment it is used for. + + As the length field is 16 bits wide, the extension data can exceed + 256 bytes in length. + +4.2. Non-skippable ICMP Router Discovery Exp. Extension + + This format is applicable for non-skippable extensions. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Opaque . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 127 (EXP-NONSKIP-EXT-TYPE) is the type, which describes an + ICMP router discovery experimental extension. + + Length Indicates the length (in bytes) of the data field within + this extension. It does NOT include the Type and Length + fields. + + + + + + +Patel & Leung Standards Track [Page 5] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + + Opaque Zero or more octets of data, with structure defined only by + the particular experiment it is used for. + + A node that receives a router advertisement with this extension + should ignore the extension if it does not recognize it. + + A mobility entity that understands this extension but does not + recognize it should drop (ignore) the router advertisement. + +4.3. Skippable Mobile IPv4 Experimental Extension + + This format is applicable for skippable extensions, which carry + information less than 256 bytes. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Sub-Type | Opaque. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 255 (EXP-SKIP-EXT-TYPE) is the type, which describes an + experimental extension. + + Length Indicates the length (in bytes) of the data field within + this extension. It does NOT include the Type and Length + fields. + + Sub-Type A unique number given to each member in the aggregated type. + + Opaque Zero or more octets of data, with structure defined only by + the particular experiment it is used for. + + As the length field is 8 bits wide, the extension data cannot exceed + 256 bytes in length. + +4.4. Skippable ICMP Router Discovery Experimental Extension + + This format is applicable for skippable ICMP router discovery + extensions. This extension should be ignored if an implementation + does not understand it. + + + + + + + + + + + +Patel & Leung Standards Track [Page 6] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Opaque. . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type 255 (EXP-SKIP-EXT-TYPE) is the type, which describes an + experimental extension. + + Length Indicates the length (in bytes) of the data field within + this extension. It does NOT include the Type and Length + fields. + + Opaque Zero or more octets of data, with structure defined only by + the particular experiment it is used for. + +5. Experimental Error Codes + + This document reserves the reply error code EXP-FA-ERROR-CODE for use + by the FA. This document also reserves the reply error code EXP-HA- + ERROR-CODE for use by the HA. + + These experimental error codes may be used in registration reply + messages. + + It is recommended that experimental error codes be used with + experimental messages and extensions whenever none of the + standardized error codes are applicable. + +6. Mobility Entity Considerations + + Mobility entities can send and receive experimental messages. + Implementations that don't understand the message type SHOULD + silently discard the message. + + Experimental extensions can be carried in experimental messages and + standards-defined messages. In the latter case, it is suggested that + experimental extensions MUST NOT be used in deployed products and + that usage be restricted to experiments only. + +7. IANA Considerations + + This document defines a control message to be used between mobility + entities, two new extension formats, and two new error codes. To + ensure correct interoperation based on this specification, IANA has + reserved values in the Mobile IPv4 number space, as defined in [2], + for one new message type, two new extensions, and two error codes. + + + + +Patel & Leung Standards Track [Page 7] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + +7.1. New Message Type + + + A new Mobile IPv4 control message using UDP port 434, type 255 (EXP- + MSG-TYPE), has been defined by IANA. This value has been taken from + the same number space as Mobile IP Registration Request (Type = 1) + and Mobile IP Registration Reply (Type = 3). + +7.2. New Extension Values + + The following extension types are introduced by this specification: + + Experimental non-skippable extension: The value 127 (EXP-NONSKIP- + EXT-TYPE) has been assigned from the numbering space for non- + skippable extensions, which may appear in Mobile IPv4 control + messages. + + Also, the same number, 127 (EXP-NONSKIP-EXT-TYPE), has been assigned + from the numbering space for non-skippable extensions, which may + appear in ICMP router discovery messages. + + Experimental skippable extension: The value 255 (EXP-SKIP-EXT-TYPE) + has been assigned from the numbering space for skippable extensions, + which may appear in Mobile IPv4 control messages. + + Also, the same number, 255 (EXP-SKIP-EXT-TYPE), has been assigned + from the numbering space for skippable extensions, which may appear + in ICMP router discovery messages. + +7.3. New Error Codes + + The value 192 (EXP-HA-ERROR-CODE) has been defined by IANA to be used + as a code field in messages generated by HA. + + Also, the value 127 (EXP-FA-ERROR-CODE) has been defined by IANA to + be used as the code field in messages generated by the FA. + +8. Security Considerations + + Like all Mobile IP control messages, the experimental messages MUST + be authenticated per the requirements specified in [2] or [5]. + Experimental messages without a valid authenticator SHOULD be + discarded. + + + + + + + + +Patel & Leung Standards Track [Page 8] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + +9. Backward Compatibility Considerations + + Mobility entities that don't understand the experimental message MUST + silently discard it. + + Mobility entities that don't understand the experimental skippable + extensions MUST ignore them. Mobility entities that don't understand + the non-skippable experimental extensions MUST silently discard the + message containing them. This behavior is consistent with section + 1.8 of [2]. + + Foreign Agents and Home Agents SHOULD include an experimental error + code in a reply message only if they have a general indication that + the receiving entity would be able to parse it. This is indicated if + the request message was of type EXP-MSG-TYPE or contained at least + one experimental extension. + +10. Acknowledgements + + The authors would like to acknowledge Henrik Levkowetz for his + detailed review of the document and suggestion to incorporate + experimental extensions in this draft. + + The authors would also like to acknowledge Thomas Narten for his + initial review of the document and reference to [6] for general + guidelines. + +11. References + +11.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August + 2002. + + [3] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an + On-line Database", RFC 3232, January 2002. + +11.2. Informative References + + [4] Dommety, G. and K. Leung, "Mobile IP + Vendor/Organization-Specific Extensions", RFC 3115, April 2001. + + [5] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response + Extensions", RFC 3012, November 2000. + + + + +Patel & Leung Standards Track [Page 9] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + + [6] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, January 2004. + +Authors' Addresses + + Questions and comments about this document should be directed to the + Mobile IPv4 working group: + + mip4@ietf.org + + Questions and comments about this document may also be directed to + the authors: + + Alpesh Patel + Cisco Systems + 170 W. Tasman Drive, + San Jose, CA 95134 USA + + Phone: +1 408-853-9580 + EMail: alpesh@cisco.com + + + Kent Leung + Cisco Systems + 170 W. Tasman Drive, + San Jose, CA 95134 USA + + Phone: +1 408-526-5030 + EMail: kleung@cisco.com + + + + + + + + + + + + + + + + + + + + + + +Patel & Leung Standards Track [Page 10] + +RFC 4064 Experimental Message, Extensions, and Error Codes May 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Patel & Leung Standards Track [Page 11] + |