idnits 2.17.1 draft-eastlake-ext-ip-ver-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2780]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (April 2001) is 8384 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) == Unused Reference: 'RFC 2434' is defined on line 143, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 3rd 2 UPDATES BCP 37 / RFC 2780 Motorola 3 Scott Bradner 4 Harvard University 5 Expires: October 2001 April 2001 7 Extended IP Versions 8 -------- -- -------- 9 11 Status of This Document 13 Distribution of this draft, which is intended to become part of Best 14 Current Practice 37, is unlimited. Comments should be sent to the 15 authors. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC 2026. Internet-Drafts are 19 working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 The current four bit Internet Protocol (IP) Version field provides 41 for such a limited number of versions that very tight control must be 42 exercised on their allocation as documented in [RFC 2780]. 43 Provisions are specified whereby one value of that field is extended 44 to provide more easily allocated values. 46 Table of Contents 48 Status of This Document....................................1 49 Copyright Notice...........................................1 50 Abstract...................................................1 52 Table of Contents..........................................2 54 1. Introduction............................................3 55 2. Extended IP Versions....................................3 56 3. IANA Considerations.....................................4 57 4. Security Considerations.................................4 59 References.................................................5 60 Authors Addresses..........................................5 62 Full Copyright Statement...................................6 63 Expiration and File Name...................................6 65 1. Introduction 67 Since the begining of the Internet Protocol (IP), it has had a four 68 bit version field. This was entirely adequate in the early days when 69 the Internet engineering community was tiny and went fairly rapdily 70 through version 1, 2, and 3, before stabilizing on version 4 (IPv4) 71 under which the Internet has prospered [RFC 791]. 73 A few years ago, when a need was felt for specification of a new 74 version, the remaining version number space was barely adequate to 75 assign versions to the main contenders, leading to the selection of 76 IPv6 as the main path [RFC 2460]. Furthermore, the Internet 77 engineering community has grown by over two orders of magnitude since 78 the specification of IP, with IETF attendence going from 15 to 3000 79 potentially increasing demand for experimental parameter values. 81 To continue the successful tradition of simple free availability of 82 parameter values, IP version numbers should be extended. How 83 beneficial this will be in this particular case is unclear. But if 84 the prospering of Internet Technology has taught us anything, it is 85 that simple free availability of parameter values can lead to 86 surprising creativity and vigor. Perhaps this mechanism will do that 87 or perhaps it will turn out to be little, like the DNS Class 88 mechanism. But the cost is small and the potential benefit hard to 89 bound. 91 An equivalent 4 bit IP version number can be allocated for any 92 extended IP version, when warranted, under the IP version allocation 93 procedure specified in [RFC 2780]. 95 2. Extended IP Versions 97 The Internet Protocol packet format is defined to begin with a four 98 bit Version as follows: 100 0 101 0 1 2 3 4 5 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 |Version| ... 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 To extend this versioning mechanism, this document specifies that the 107 version number (TBD (suggest 1)) is followed by a twelve bit 108 extention as shown below. 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | (TBD) | x | y | ... 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 The version number is considered an unsigned integer equal to x*256 + 117 y. This produces version numbers in the range 0 to 4095 but the 118 first sixteen values, 0 through 15, are reserved for future 119 definition and to avoid conflict with non-extended version numbers. 120 This structure causes the remainder of the IP packet to be 16 bit 121 aligned. 123 3. IANA Considerations 125 IP Version number nibble value (TBD (suggest 1)) is allocated for 126 extended IP Versions as documnted herein. 128 Extended IP versions 0 through 15 are reserved and required a 129 "Standards Action" as defined in RFC 2434 for allocation. 131 Extended IP version 16 through 4095 are to be allocated in sequential 132 order based on "Specification Required" as defined in RFC 2434. 134 4. Security Considerations 136 Firwalls or other software which wishes to pass only packets they 137 understand should block all packets with extended IP versions. 139 References 141 [RFC 791] - "Internet Protocol", J. Postel, September 1981. 143 [RFC 2434] - "Guidelines for Writing an IANA Considerations Section 144 in RFCs", T. Narten, H. Alvestrand, October 1998. 146 [RFC 2460] - "Internet Protocol, Version 6 (IPv6) Specification", 147 Deering, S. and R. Hinden, December 1998. 149 [RFC 2780] - "IANA Allocation Guidelines For Values In the Internet 150 Protocol and Related Headers", S. Bradner, V. Paxon, March 2000. 152 Authors Addresses 154 Scott Bradner 155 Harvard University 156 Cambridge, MA 02138 USA 158 Telephone: +1 617 495 3864 159 EMail: sob@harvard.edu 161 Donald E. Eastlake 3rd 162 Motorola 163 155 Beaver Street 164 Milford, MA 01757 USA 166 Telephone: +1-508-634-2066 (h) 167 +1-508-261-5434 (w) 168 FAX: +1-508-261-4447 (w) 169 EMail: Donald.Eastlake@motorola.com 171 Full Copyright Statement 173 Copyright (C) The Internet Society (2001). All Rights Reserved. 175 This document and translations of it may be copied and furnished to 176 others, and derivative works that comment on or otherwise explain it 177 or assist in its implementation may be prepared, copied, published 178 and distributed, in whole or in part, without restriction of any 179 kind, provided that the above copyright notice and this paragraph are 180 included on all such copies and derivative works. However, this 181 document itself may not be modified in any way, such as by removing 182 the copyright notice or references to the Internet Society or other 183 Internet organizations, except as needed for the purpose of 184 developing Internet standards in which case the procedures for 185 copyrights defined in the Internet Standards process must be 186 followed, or as required to translate it into languages other than 187 English. 189 The limited permissions granted above are perpetual and will not be 190 revoked by the Internet Society or its successors or assigns. 192 This document and the information contained herein is provided on an 193 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 194 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 195 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 196 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 197 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 199 Expiration and File Name 201 This draft expires October 2001. 203 Its file name is draft-eastlake-ext-ip-ver-02.txt.