idnits 2.17.1 draft-ietf-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, updated by RFC 4748 on line 243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 254. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 267. 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 (February 21, 2007) is 6266 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) == Outdated reference: A later version (-02) exists of draft-sgundave-mip6-proxymip6-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 February 21, 2007 5 Expires: August 25, 2007 7 Mobile IPv6 Experimental Messages 8 draft-ietf-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 August 25, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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 [4] 96 and Proxy MIPv6 [5] since these protocols also use Mobility Header 97 messages. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [1]. 105 3. Experimental Mobility Header message 107 The following illustrates the message format for the Experimental 108 Mobility Header message. The 'MH Type' field in the Mobility Header 109 indicates that it is an Experimental Mobility Header message. 111 If no data is present in this message, padding is not necessary and 112 since the first 8 octets are excluded while calculating the length of 113 the message, the 'Header Len' field in the Mobility Header is set to 114 0. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Reserved | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | | 122 . . 123 . Data . 124 . . 125 | | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Reserved 130 A 16-bit reserved field set to zero by the sender and ignored by 131 the receiver. 133 Data 135 Data specific to the experimental protocol extension. The total 136 length is indicated by the 'Header Len' field in the Mobility 137 Header. 139 4. Experimental Mobility Option 141 The Experimental mobility option can be included in any Mobility 142 Header message. If the Mobility Header message includes a Binding 143 Authorization Data option [2], then the Experimental Mobility Option 144 should appear before the Binding Authorization Data option. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Type | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | | 152 . . 153 . Data . 154 . . 155 | | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Type 160 A 8-bit field indicating that it is an experimental mobility 161 option. 163 Length 165 A 8-bit indicating the length of the option in octets excluding 166 the Type and Length fields. 168 Data 170 Data related to the experimental protocol extension. 172 5. Security Considerations 174 Protection for the Experimental Mobility Header message and mobility 175 option depends on the experiment that is being carried out and the 176 kind of information that is being carried in the messages. If these 177 messages carry information that should not be revealed on the wire or 178 that can affect the binding cache entry at the home agent or the 179 correspondent node, they should be protected in a manner similar to 180 Binding Updates and Binding Acknowledgements. 182 6. IANA Considerations 184 The Experimental Mobility Header message defined in Section 3, should 185 have the type value allocated from the same space as the 'MH Type' 186 field in the Mobility Header [2]. 188 The Experimental mobility option defined in Section 4, should have 189 the type value allocated from the same space as Mobility Options [2]. 191 7. Acknowledgements 193 The author would like to thank Jari Arkko and Basavaraj Patil with 194 whom the contents of this document were discussed first. 196 8. References 198 8.1. Normative References 200 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 201 Levels", BCP 14, RFC 2119, March 1997. 203 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 204 IPv6", RFC 3775, June 2004. 206 8.2. Informative References 208 [3] Narten, T., "Assigning Experimental and Testing Numbers 209 Considered Useful", BCP 82, RFC 3692, January 2004. 211 [4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 212 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 213 January 2005. 215 [5] Gundavelli, S., "Proxy Mobile IPv6", 216 draft-sgundave-mip6-proxymip6-01 (work in progress), 217 January 2007. 219 Author's Address 221 Vijay Devarapalli 222 Azaire Networks 223 4800 Great America Pkwy 224 Santa Clara, CA 95054 225 USA 227 Email: vijay.devarapalli@azairenet.com 229 Full Copyright Statement 231 Copyright (C) The IETF Trust (2007). 233 This document is subject to the rights, licenses and restrictions 234 contained in BCP 78, and except as set forth therein, the authors 235 retain all their rights. 237 This document and the information contained herein are provided on an 238 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 239 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 240 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 241 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 242 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 243 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 245 Intellectual Property 247 The IETF takes no position regarding the validity or scope of any 248 Intellectual Property Rights or other rights that might be claimed to 249 pertain to the implementation or use of the technology described in 250 this document or the extent to which any license under such rights 251 might or might not be available; nor does it represent that it has 252 made any independent effort to identify any such rights. Information 253 on the procedures with respect to rights in RFC documents can be 254 found in BCP 78 and BCP 79. 256 Copies of IPR disclosures made to the IETF Secretariat and any 257 assurances of licenses to be made available, or the result of an 258 attempt made to obtain a general license or permission for the use of 259 such proprietary rights by implementers or users of this 260 specification can be obtained from the IETF on-line IPR repository at 261 http://www.ietf.org/ipr. 263 The IETF invites any interested party to bring to its attention any 264 copyrights, patents or patent applications, or other proprietary 265 rights that may cover technology that may be required to implement 266 this standard. Please address the information to the IETF at 267 ietf-ipr@ietf.org. 269 Acknowledgment 271 Funding for the RFC Editor function is provided by the IETF 272 Administrative Support Activity (IASA).