idnits 2.17.1 draft-devarapalli-mip6-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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 249. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 262. ** 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. 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 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.) -- The document date (October 22, 2006) is 6397 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: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group V. Devarapalli 3 Internet-Draft Azaire Networks 4 Intended status: Standards Track October 22, 2006 5 Expires: April 25, 2007 7 Mobile IPv6 Experimental Messages 8 draft-devarapalli-mip6-experimental-messages-01.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 This Internet-Draft will expire on April 25, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines a new experimental Mobility header message and 42 a mobility option that can be used for experimental extensions to the 43 Mobile IPv6 protocol. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Experimental Mobility Header message . . . . . . . . . . . . . 4 50 4. Experimental Mobility Option . . . . . . . . . . . . . . . . . 4 51 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 52 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 53 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 54 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 56 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 Intellectual Property and Copyright Statements . . . . . . . . . . 7 60 1. Introduction 62 When experimenting with a protocol or defining a new extension to a 63 protocol, one needs either a protocol number, a new message or an 64 option to carry the information related to the experiment. Most 65 implementations end up using unassigned values for the new messages. 66 Many times this creates problems when the same value is assigned 67 through the IETF standards action, by IANA or if the implementation 68 gets deployed with these messages. Therefore it is considered a good 69 practice to set aside some messages for experimental purposes. The 70 need for experimental messages is shown in [3]. 72 This document defines new messages for experimenting with extensions 73 to the Mobile IPv6 protocol. These messages should be strictly used 74 for experiments. Experiments that are successful should be 75 standardized in the IETF. An implementation MUST NOT be released or 76 deployed with the experimental messages. 78 This document defines a new Mobility Header message, the Experimental 79 Mobility message that can be sent at any time by the mobile node, the 80 home agent or the correspondent node. Since Mobility Header messages 81 cannot be combined and sent in one packet, there is always only one 82 Mobility Header message in any Mobile IPv6 packet. Home agent or 83 correspondent node implementations that do not recognize the mobility 84 message type, discard the message and send Binding Error message as 85 described in [2], with the Status field set to 2 (unrecognized MH 86 Type value). Mobile nodes that do not recognize the mobility message 87 type should discard the message and send an ICMP Parameter problem 88 with code 0. 90 This document also defines a new mobility option, the Experimental 91 Mobility option, which can be carried in any Mobility Header message. 92 Mobility options, by definition, can be skipped if an implementation 93 does not recognize the mobility option type [2]. 95 The messages defined in this document can also be used for NEMO 96 implementations [4]. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [1]. 104 3. Experimental Mobility Header message 106 The following illustrates the message format for the Experimental 107 Mobility Header message. The 'MH Type' field in the Mobility Header 108 indicates that it is an Experimental Mobility Header message. 110 If no data is present in this message, padding is not necessary and 111 since the first 8 octets are excluded while calculating the length of 112 the message, the 'Header Len' field in the Mobility Header is set to 113 0. 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | Reserved | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | | 121 . . 122 . Data . 123 . . 124 | | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Reserved 129 A 16-bit reserved field set to zero by the sender and ignored by 130 the receiver. 132 Data 134 Data specific to the experimental protocol extension. The total 135 length is indicated by the 'Header Len' field in the Mobility 136 Header. 138 4. Experimental Mobility Option 140 The Experimental mobility option can be included in any Mobility 141 Header message. If the Mobility Header message includes a Binding 142 Authorization Data option [2], then the Experimental Mobility Option 143 should appear before the Binding Authorization Data option. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type | Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 . . 152 . Data . 153 . . 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Type 159 A 8-bit field indicating that it is an experimental mobility 160 option. 162 Length 164 A 8-bit indicating the length of the option in octets excluding 165 the Type and Length fields. 167 Data 169 Data related to the experimental protocol extension. 171 5. Security Considerations 173 Protection for the Experimental Mobility Header message and mobility 174 option depends on the experiment that is being carried out and the 175 kind of information that is being carried in the messages. If these 176 messages carry information that should not be revealed on the wire or 177 that can affect the binding cache entry at the home agent or the 178 correspondent node, they should be protected in a manner similar to 179 Binding Updates and Binding Acknowledgements. 181 6. IANA Considerations 183 The Experimental Mobility Header message defined in Section 3, should 184 have the type value allocated from the same space as the 'MH Type' 185 field in the Mobility Header [2]. 187 The Experimental mobility option defined in Section 4, should have 188 the type value allocated from the same space as Mobility Options [2]. 190 7. Acknowledgements 192 The author would like to thank Jari Arkko and Basavaraj Patil with 193 whom the contents of this document were discussed first. 195 8. References 197 8.1. Normative References 199 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 200 Levels", BCP 14, RFC 2119, March 1997. 202 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 203 IPv6", RFC 3775, June 2004. 205 8.2. Informative References 207 [3] Narten, T., "Assigning Experimental and Testing Numbers 208 Considered Useful", BCP 82, RFC 3692, January 2004. 210 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 211 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 212 January 2005. 214 Author's Address 216 Vijay Devarapalli 217 Azaire Networks 218 4800 Great America Pkwy 219 Santa Clara, CA 95054 220 USA 222 Email: vijay.devarapalli@azairenet.com 224 Full Copyright Statement 226 Copyright (C) The Internet Society (2006). 228 This document is subject to the rights, licenses and restrictions 229 contained in BCP 78, and except as set forth therein, the authors 230 retain all their rights. 232 This document and the information contained herein are provided on an 233 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 234 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 235 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 236 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 237 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 238 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 240 Intellectual Property 242 The IETF takes no position regarding the validity or scope of any 243 Intellectual Property Rights or other rights that might be claimed to 244 pertain to the implementation or use of the technology described in 245 this document or the extent to which any license under such rights 246 might or might not be available; nor does it represent that it has 247 made any independent effort to identify any such rights. Information 248 on the procedures with respect to rights in RFC documents can be 249 found in BCP 78 and BCP 79. 251 Copies of IPR disclosures made to the IETF Secretariat and any 252 assurances of licenses to be made available, or the result of an 253 attempt made to obtain a general license or permission for the use of 254 such proprietary rights by implementers or users of this 255 specification can be obtained from the IETF on-line IPR repository at 256 http://www.ietf.org/ipr. 258 The IETF invites any interested party to bring to its attention any 259 copyrights, patents or patent applications, or other proprietary 260 rights that may cover technology that may be required to implement 261 this standard. Please address the information to the IETF at 262 ietf-ipr@ietf.org. 264 Acknowledgment 266 Funding for the RFC Editor function is provided by the IETF 267 Administrative Support Activity (IASA).