idnits 2.17.1 draft-ietf-mip6-vsm-03.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 17. -- 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 (October 5, 2007) is 6045 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: 2 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 A. Patel 5 Expires: April 7, 2008 K. Leung 6 Cisco 7 October 5, 2007 9 Mobile IPv6 Vendor Specific Option 10 draft-ietf-mip6-vsm-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 7, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 There is a need for vendor specific extensions to Mobility Header 44 messages so that Mobile IPv6 vendors are able to extend the protocol 45 for research or deployment purposes. This document defines a new 46 vendor specific mobility option. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Vendor Specific Mobility Option . . . . . . . . . . . . . . . . 4 53 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Intellectual Property and Copyright Statements . . . . . . . . . . 7 62 1. Introduction 64 Vendor specific messages have traditionally allowed vendors to 65 implement extensions to some protocols and distinguish themselves 66 from other vendors. These messages are clearly marked by a Vendor ID 67 that identifies the vendor. A particular vendor's implementation 68 identifies the vendor extension by recognizing the Vendor ID. 69 Implementations that do not recognize the Vendor ID either discard or 70 skip processing the message. 72 Mobile IPv6 [2] is being deployed and there is a need for vendor 73 specific extensions to Mobility Header messages so that vendors are 74 able to extend the Mobile IPv6 protocol for research or deployment 75 purposes. 77 This document defines a new mobility option, the Vendor Specific 78 Mobility option, which can be carried in any Mobility Header message. 79 The Vendor Specific mobility option MUST be used only with a Mobility 80 Header message. Mobility options, by definition, can be skipped if 81 an implementation does not recognize the mobility option type [2]. 83 The messages defined in this document can also be used for NEMO [3] 84 and Proxy MIPv6 [4] since these protocols also use Mobility Header 85 messages. 87 Vendor-specific protocol extensions can cause serious 88 interoperability issues and may in addition have adverse operational 89 impact, if they are not designed and used carefully. The vendor- 90 specific option described in this document is meant to support simple 91 use cases where it is sufficient to include some vendor data in the 92 standardized Mobile IPv6 protocol exchanges. The vendor-specific 93 option is not suitable for more complex vendor extensions that modify 94 Mobile IPv6 itself. Although these options allow vendors to 95 piggyback additional data onto Mobile IPv6 message exchanges, RFC 96 3775 [2] requires that unrecognized options be ignored and that the 97 end systems be able to process the remaining parts of the message 98 correctly. Extensions that use the vendor specifc mobility option 99 should require an indication that the option was processed, in the 100 response, using the vendor specific mobility option. 102 Vendors are generally encouraged to bring their protocol extensions 103 to the IETF for review and standardization. Complex vendor 104 extensions that modify Mobile IPv6 itself, will see large-scale 105 deployment or involve industry consortia or other multi-vendor 106 organizations MUST be standardized in the IETF. Past experience has 107 shown that such extensions of IETF protocols are critically dependent 108 on IETF review and standardization. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [1]. 116 3. Vendor Specific Mobility Option 118 The Vendor Specific Mobility Option can be included in any Mobility 119 Header message and has an alignment requirement of 4n+2. If the 120 Mobility Header message includes a Binding Authorization Data option 121 [2], then the Vendor Specific mobility option should appear before 122 the Binding Authorization Data option. Multiple Vendor Specific 123 mobility options MAY be present in a Mobility Header message. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Type | Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Vendor ID | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Sub-Type | Data....... 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Type 137 A 8-bit field indicating that it is a Vendor Specific mobility 138 option. 140 Length 142 A 8-bit field indicating the length of the option in octets 143 excluding the Type and the Length fields. All other fields are 144 included. 146 Vendor ID 148 The SMI Network Management Private Enterprise Code of the IANA 149 maintained Private Enterprise Numbers registry [5]. 151 Sub-type 153 A 8-bit field indicating the type of vendor specific information 154 carried in the option. The administration of the Sub-type is done 155 by the Vendor. 157 Data 159 Vendor specific data that is carried in this message. 161 4. Security Considerations 163 The Vendor Specific mobility messages should be protected in a manner 164 similar to Binding Updates and Binding acknowledgements if it carries 165 information that should not be revealed on the wire or that can 166 affect the binding cache entry at the home agent or the correspondent 167 node. In particular the messages containing the Vendor Specific 168 mobility option MUST be integrity protected. 170 5. IANA Considerations 172 The Vendor Specific mobility option defined in Section 3, should have 173 the type value allocated from the same space as the Mobility Options 174 registry created by RFC 3775 [2]. 176 6. Acknowledgements 178 The author would like to thank Jari Arkko and Basavaraj Patil with 179 whom the contents of this document were discussed first. 181 7. References 183 7.1. Normative References 185 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 186 Levels", BCP 14, RFC 2119, March 1997. 188 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 189 IPv6", RFC 3775, June 2004. 191 7.2. Informative References 193 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 194 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 195 January 2005. 197 [4] Gundavelli, S., "Proxy Mobile IPv6", 198 draft-sgundave-mip6-proxymip6-02 (work in progress), March 2007. 200 [5] IANA Assigned Numbers Online Database, "Private Enterprise 201 Numbers", http://www.iana.org/assignments/enterprise-numbers . 203 Authors' Addresses 205 Vijay Devarapalli 206 Azaire Networks 207 4800 Great America Pkwy 208 Santa Clara, CA 95054 209 USA 211 Email: vijay.devarapalli@azairenet.com 213 Alpesh Patel 214 Cisco 215 170 West Tasman Drive 216 San Jose, CA 95134 217 USA 219 Email: alpesh@cisco.com 221 Kent Leung 222 Cisco 223 170 West Tasman Drive 224 San Jose, CA 95134 225 USA 227 Email: kleung@cisco.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).