idnits 2.17.00 (12 Aug 2021) /tmp/idnits48306/draft-ietf-v6ops-ipv4survey-subip-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 316 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (April 2004) is 6603 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) == Outdated reference: draft-ietf-v6ops-ipv4survey-intro has been published as RFC 3789 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-intro (ref. '1') Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-ietf-v6ops-ipv4survey-subip-04.txt Nesser & Nesser Consulting 2 Internet Draft Andreas Bergstrom (Ed.) 3 Ostfold University College 4 November 2003 5 Expires April 2004 7 Survey of IPv4 Addresses in Currently Deployed 8 IETF Sub-IP Area Standards 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents at 21 any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document seeks to document all usage of IPv4 addresses in currently 33 deployed IETF Sub-IP Area documented standards. In order to 34 successfully transition from an all IPv4 Internet to an all IPv6 35 Internet, many interim steps will be taken. One of these steps is the 36 evolution of current protocols that have IPv4 dependencies. It is 37 hoped that these protocols (and their implementations) will be 38 redesigned to be network address independent, but failing that will at 39 least dually support IPv4 and IPv6. To this end, all Standards (Full, 40 Draft, and Proposed) as well as Experimental RFCs will be surveyed and 41 any dependencies will be documented. 43 Table of Contents 45 1. Introduction 46 2. Document Organisation 47 3. Full Standards 48 4. Draft Standards 49 5. Proposed Standards 50 6. Experimental RFCs 51 7. Summary of Results 52 7.1 Standards 53 7.2 Draft Standards 54 7.3 Proposed Standards 55 7.4 Experimental RFCs 56 8. Security Consideration 57 9. Acknowledgements 58 10. References 59 11. Authors' Addresses 60 12. Intellectual Property Statement 61 13. Full Copyright Statement 63 1.0 Introduction 65 This document is part of a document set aiming to document all usage of 66 IPv4 addresses in IETF standards. In an effort to have the information 67 in a manageable form, it has been broken into 7 documents conforming 68 to the current IETF areas (Application, Internet, Management & 69 Operations, Routing, Security, Sub-IP and Transport). 71 For a full introduction, please see the introduction [1]. 73 2.0 Document Organization 75 The rest of the document sections are described below. 77 Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, 78 and Proposed Standards, and Experimental RFCs. Each RFC is discussed 79 in its turn starting with RFC 1 and ending with (around) RFC 3100. 80 The comments for each RFC are "raw" in nature. That is, each RFC is 81 discussed in a vacuum and problems or issues discussed do not "look 82 ahead" to see if the problems have already been fixed. 84 Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 85 6. It is here that all of the results are considered as a whole and the 86 problems that have been resolved in later RFCs are correlated. 88 3.0 Full Standards 90 Full Internet Standards (most commonly simply referred to as 91 "Standards") are fully mature protocol specification that are widely 92 implemented and used throughout the Internet. 94 There are no full standars within the scope of this document. 96 4.0 Draft Standards 98 Draft Standards represent the penultimate standard level in the IETF. 99 A protocol can only achieve draft standard when there are multiple, 100 independent, interoperable implementations. Draft Standards are usually 101 quite mature and widely used. 103 There are no draft standards within the scope of this document. 105 5.0 Proposed Standards 107 Proposed Standards are introductory level documents. There are no 108 requirements for even a single implementation. In many cases Proposed 109 are never implemented or advanced in the IETF standards process. They 110 therefore are often just proposed ideas that are presented to the 111 Internet community. Sometimes flaws are exposed or they are one of 112 many competing solutions to problems. In these later cases, no 113 discussion is presented as it would not serve the purpose of this 114 discussion. 116 5.01 RFC 3031 Multiprotocol Label Switching Architecture (MPLS) 118 There are no IPv4 dependencies in this specification. 120 5.02 RFC 3032 MPLS Label Stack Encoding 122 This specification is both IPv4 and IPv6 aware and needs no changes. 124 5.03 RFC 3034 Use of Label Switching on Frame Relay Networks 125 Specification 127 There are no IPv4 dependencies in this specification. 129 5.04 RFC 3035 MPLS using LDP and ATM VC Switching 131 There are no IPv4 dependencies in this specification. 133 5.05 RFC 3036 LDP Specification 135 This specification is both IPv4 and IPv6 aware and needs no changes. 137 5.06 RFC 3038 VCID Notification over ATM link for LDP 139 There are no IPv4 dependencies in this specification. 141 6.0 Experimental RFCs 143 Experimental RFCs typically define protocols that do not have widescale 144 implementation or usage on the Internet. They are often propriety in 145 nature or used in limited arenas. They are documented to the Internet 146 community in order to allow potential interoperability or some other 147 potential useful scenario. In a few cases they are presented as 148 alternatives to the mainstream solution to an acknowledged problem. 150 6.1 RFC 3063 MPLS Loop Prevention Mechanism 152 There are no IPv4 dependencies in this specification. 154 7.0 Summary of Results 156 In the initial survey of RFCs 0 positives were identified out of a 157 total of 7, broken down as follows: 159 Standards 0 of 0 or 0.00% 160 Draft Standards 0 of 0 or 0.00% 161 Proposed Standards 0 of 6 or 0.00% 162 Experimental RFCs 0 of 1 or 0.00% 164 Of those identified many require no action because they document 165 outdated and unused protocols, while others are document protocols 166 that are actively being updated by the appropriate working groups. 167 Additionally there are many instances of standards that should be 168 updated but do not cause any operational impact if they are not 169 updated. The remaining instances are documented below. 171 7.1 Standards 173 There are no standards within the scope of this document. 175 7.2 Draft Standards 177 There are no draft standards within the scope of this document. 179 7.3 Proposed Standards 181 There are no proposed standards with recommendations in this document. 183 7.4 Experimental RFCs 185 There are no experimental standards with recommendations in this 186 document. 188 8.0 Security Consideration 190 This memo examines the IPv6-readiness of specifications; this does not 191 have security considerations in itself. 193 9.0 Acknowledgements 195 The authors would like to acknowledge the support of the Internet 196 Society in the research and production of this document. 197 Additionally the author, Philip J. Nesser II, would like to thanks 198 his partner in all ways, Wendy M. Nesser. 200 The editor, Andreas Bergstrom, would like to thank Pekka Savola 201 for guidance and collection of comments for the editing of this 202 document. 204 10.0 References 206 10.1 Normative 208 [1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the 209 Survey of IPv4 Addresses in Currently Deployed IETF Standards", 210 draft-ietf-v6ops-ipv4survey-intro-05.txt IETF work in progress, 211 November 2003 213 11.0 Authors' Addresses 215 Please contact the author with any questions, comments or suggestions 216 at: 218 Philip J. Nesser II 219 Principal 220 Nesser & Nesser Consulting 221 13501 100th Ave NE, #5202 222 Kirkland, WA 98034 224 Email: phil@nesser.com 225 Phone: +1 425 481 4303 226 Fax: +1 425 48 228 Andreas Bergstrom (Editor) 229 Ostfold University College 230 Email: andreas.bergstrom@hiof.no 231 Address: Rute 503 Buer 232 N-1766 Halden 233 Norway 235 12.0 Intellectual Property Statement 237 The IETF takes no position regarding the validity or scope of any 238 intellectual property or other rights that might be claimed to 239 pertain to the implementation or use of the technology described in 240 this document or the extent to which any license under such rights 241 might or might not be available; neither does it represent that it 242 has made any effort to identify any such rights. Information on the 243 IETF's procedures with respect to rights in standards-track and 244 standards-related documentation can be found in BCP-11. Copies of 245 claims of rights made available for publication and any assurances of 246 licenses to be made available, or the result of an attempt made to 247 obtain a general license or permission for the use of such 248 proprietary rights by implementors or users of this specification can 249 be obtained from the IETF Secretariat. 251 The IETF invites any interested party to bring to its attention any 252 copyrights, patents or patent applications, or other proprietary 253 rights which may cover technology that may be required to practice 254 this standard. Please address the information to the IETF Executive 255 Director. 257 13.0 Full Copyright Statement 259 Copyright (C) The Internet Society (2000). All Rights Reserved. 261 This document and translations of it may be copied and furnished to 262 others, and derivative works that comment on or otherwise explain it 263 or assist in its implementation may be prepared, copied, published 264 and distributed, in whole or in part, without restriction of any 265 kind, provided that the above copyright notice and this paragraph are 266 included on all such copies and derivative works. However, this docu- 267 ment itself may not be modified in any way, such as by removing the 268 copyright notice or references to the Internet Society or other 269 Internet organizations, except as needed for the purpose of develop- 270 ing Internet standards in which case the procedures for copyrights 271 defined in the Internet Standards process must be followed, or as 272 required to translate it into languages other than English. The lim- 273 ited permissions granted above are perpetual and will not be revoked 274 by the Internet Society or its successors or assigns. This document 275 and the information contained herein is provided on an "AS IS" basis 276 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 277 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 278 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 279 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 280 FITNESS FOR A PARTICULAR PURPOSE.