diff options
Diffstat (limited to 'doc/rfc/rfc3793.txt')
| -rw-r--r-- | doc/rfc/rfc3793.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc3793.txt b/doc/rfc/rfc3793.txt new file mode 100644 index 0000000..b547c57 --- /dev/null +++ b/doc/rfc/rfc3793.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group P. Nesser, II +Request for Comments: 3793 Nesser & Nesser Consulting +Category: Informational A. Bergstrom, Ed. + Ostfold University College + May 2004 + + + Survey of IPv4 Addresses in Currently Deployed + IETF Sub-IP Area Standards Track and Experimental Documents + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This document seeks to document all usage of IPv4 addresses in + currently deployed IETF Sub-IP Area documented standards. In order + to successfully transition from an all IPv4 Internet to an all IPv6 + Internet, many interim steps will be taken. One of these steps is + the evolution of current protocols that have IPv4 dependencies. It + is hoped that these protocols (and their implementations) will be + redesigned to be network address independent, but failing that will + at least dually support IPv4 and IPv6. To this end, all Standards + (Full, Draft, and Proposed) as well as Experimental RFCs will be + surveyed and any dependencies will be documented. + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Document Organisation . . . . . . . . . . . . . . . . . . . . . 2 + 3. Full Standards. . . . . . . . . . . . . . . . . . . . . . . . . 2 + 4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . . . 2 + 5. Proposed Standards. . . . . . . . . . . . . . . . . . . . . . . 3 + 6. Experimental RFCs . . . . . . . . . . . . . . . . . . . . . . . 3 + 7. Summary of Results. . . . . . . . . . . . . . . . . . . . . . . 4 + 7.01. Standards . . . . . . . . . . . . . . . . . . . . . . . . 4 + 7.02. Draft Standards . . . . . . . . . . . . . . . . . . . . . 4 + 7.03. Proposed Standards. . . . . . . . . . . . . . . . . . . . 4 + 7.04. Experimental RFCs . . . . . . . . . . . . . . . . . . . . 4 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . 4 + + + +Nesser II & Bergstrom Informational [Page 1] + +RFC 3793 IPv4 Addresses in the IETF Sub-IP Area May 2004 + + + 10. Normative Reference . . . . . . . . . . . . . . . . . . . . . . 5 + 11. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 5 + 12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 6 + +1. Introduction + + This document is part of a document set aiming to document all usage + of IPv4 addresses in IETF standards. In an effort to have the + information in a manageable form, it has been broken into 7 documents + conforming to the current IETF areas (Application, Internet, + Operations & Management, Routing, Security, Sub-IP and Transport). + + For a full introduction, please see the introduction [1]. + +2. Document Organization + + The rest of the document sections are described below. + + Sections 3, 4, 5, and 6 each describe the raw analysis of Full, + Draft, and Proposed Standards, and Experimental RFCs. Each RFC is + discussed in its turn starting with RFC 1 and ending with (around) + RFC 3100. The comments for each RFC are "raw" in nature. That is, + each RFC is discussed in a vacuum and problems or issues discussed do + not "look ahead" to see if the problems have already been fixed. + + Section 7 is an analysis of the data presented in Sections 3, 4, 5, + and 6. It is here that all of the results are considered as a whole + and the problems that have been resolved in later RFCs are + correlated. + +3. Full Standards + + Full Internet Standards (most commonly simply referred to as + "Standards") are fully mature protocol specification that are widely + implemented and used throughout the Internet. + + There are no full standards within the scope of this document. + +4. Draft Standards + + Draft Standards represent the penultimate standard level in the IETF. + A protocol can only achieve draft standard when there are multiple, + independent, interoperable implementations. Draft Standards are + usually quite mature and widely used. + + There are no draft standards within the scope of this document. + + + + + +Nesser II & Bergstrom Informational [Page 2] + +RFC 3793 IPv4 Addresses in the IETF Sub-IP Area May 2004 + + +5. Proposed Standards + + Proposed Standards are introductory level documents. There are no + requirements for even a single implementation. In many cases + Proposed are never implemented or advanced in the IETF standards + process. They therefore are often just proposed ideas that are + presented to the Internet community. Sometimes flaws are exposed or + they are one of many competing solutions to problems. In these later + cases, no discussion is presented as it would not serve the purpose + of this discussion. + + 5.01. RFC 3031 Multiprotocol Label Switching Architecture (MPLS) + + There are no IPv4 dependencies in this specification. + + 5.02. RFC 3032 MPLS Label Stack Encoding + + This specification is both IPv4 and IPv6 aware and needs no + changes. + + 5.03. RFC 3034 Use of Label Switching on Frame Relay Networks + Specification + + There are no IPv4 dependencies in this specification. + + 5.04. RFC 3035 MPLS using LDP and ATM VC Switching + + There are no IPv4 dependencies in this specification. + + 5.05. RFC 3036 LDP Specification + + This specification is both IPv4 and IPv6 aware and needs no + changes. + + 5.06. RFC 3038 VCID Notification over ATM link for LDP + + There are no IPv4 dependencies in this specification. + +6. Experimental RFCs + + Experimental RFCs typically define protocols that do not have + widescale implementation or usage on the Internet. They are often + propriety in nature or used in limited arenas. They are documented + to the Internet community in order to allow potential + interoperability or some other potential useful scenario. In a few + cases they are presented as alternatives to the mainstream solution + to an acknowledged problem. + + + + +Nesser II & Bergstrom Informational [Page 3] + +RFC 3793 IPv4 Addresses in the IETF Sub-IP Area May 2004 + + + 6.01. RFC 3063 MPLS Loop Prevention Mechanism + + There are no IPv4 dependencies in this specification. + +7. Summary of Results + + In the initial survey of RFCs 0 positives were identified out of a + total of 7, broken down as follows: + + Standards: 0 out of 0 or 0.00% + Draft Standards: 0 out of 0 or 0.00% + Proposed Standards: 0 out of 6 or 0.00% + Experimental RFCs: 0 out of 1 or 0.00% + + Of those identified many require no action because they document + outdated and unused protocols, while others are document protocols + that are actively being updated by the appropriate working groups. + Additionally there are many instances of standards that should be + updated but do not cause any operational impact if they are not + updated. The remaining instances are documented below. + + 7.01. Standards + + There are no standards within the scope of this document. + + 7.02. Draft Standards + + There are no draft standards within the scope of this document. + + 7.03. Proposed Standards + + There are no proposed standards with recommendations in this + document. + + 7.04. Experimental RFCs + + There are no experimental standards with recommendations in this + document. + +8. Security Considerations + + This memo examines the IPv6-readiness of specifications; this does + not have security considerations in itself. + +9. Acknowledgements + + The authors would like to acknowledge the support of the Internet + Society in the research and production of this document. + + + +Nesser II & Bergstrom Informational [Page 4] + +RFC 3793 IPv4 Addresses in the IETF Sub-IP Area May 2004 + + + Additionally the author, Philip J. Nesser II, would like to thank his + partner in all ways, Wendy M. Nesser. + + The editor, Andreas Bergstrom, would like to thank Pekka Savola for + guidance and collection of comments for the editing of this document. + +10. Normative Reference + + [1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the + Survey of IPv4 Addresses in Currently Deployed IETF Standards", + RFC 3789, May 2004. + +11. Authors' Addresses + + Please contact the authors with any questions, comments or + suggestions at: + + Philip J. Nesser II + Principal + Nesser & Nesser Consulting + 13501 100th Ave NE, #5202 + Kirkland, WA 98034 + + Phone: +1 425 481 4303 + Fax: +1 425 48 + EMail: phil@nesser.com + + + Andreas Bergstrom, Editor + Ostfold University College + Rute 503 Buer + N-1766 Halden + Norway + + EMail: andreas.bergstrom@hiof.no + + + + + + + + + + + + + + + + +Nesser II & Bergstrom Informational [Page 5] + +RFC 3793 IPv4 Addresses in the IETF Sub-IP Area May 2004 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR + IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to + rights in RFC documents can be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention + any copyrights, patents or patent applications, or other + proprietary rights that may cover technology that may be required + to implement this standard. Please address the information to the + IETF at ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + +Nesser II & Bergstrom Informational [Page 6] + |