draft-ietf-v6ops-ipv4survey-intro-05.txt   draft-ietf-v6ops-ipv4survey-intro-06.txt 
Network Working Group Philip J. Nesser II Network Working Group Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-intro-05.txt Nesser & Nesser Consulting draft-ietf-v6ops-ipv4survey-intro-06.txt Nesser & Nesser Consulting
Internet Draft Andreas Bergstrom (Ed.) Internet Draft Andreas Bergstrom (Ed.)
Ostfold University College Ostfold University College
November 2003 December 2003
Expires April 2004 Expires May 2004
Introduction to the Survey of IPv4 Addresses in Introduction to the Survey of IPv4 Addresses in
Currently Deployed IETF Standards Currently Deployed IETF Standards
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 100 skipping to change at line 100
culminated in the famous "flag day" of January 1, 1983. IP Version 4 culminated in the famous "flag day" of January 1, 1983. IP Version 4
originally specified an 8 bit network and 24 bit host addresses, as originally specified an 8 bit network and 24 bit host addresses, as
documented in RFC 760. A year later IPv4 was updated in RFC 791 to documented in RFC 760. A year later IPv4 was updated in RFC 791 to
include the famous A, B, C, D, & E class system. include the famous A, B, C, D, & E class system.
Networks were growing in such a way that it was clear that a convention Networks were growing in such a way that it was clear that a convention
for breaking networks into smaller pieces was needed. In October of for breaking networks into smaller pieces was needed. In October of
1984 RFC 917 was published formalizing the practice of subnetting. 1984 RFC 917 was published formalizing the practice of subnetting.
By the late 1980's it was clear that the current exterior routing By the late 1980's it was clear that the current exterior routing
protocol used by the Internet (EGP) was insufficiently robudt to scale protocol used by the Internet (EGP) was insufficiently robust to scale
with the growth of the Internet. The first version of BGP was with the growth of the Internet. The first version of BGP was
documented in 1989 in RFC 1105. documented in 1989 in RFC 1105.
Yet another scaling issue, exhaustion of the class B address space, Yet another scaling issue, exhaustion of the class B address space,
became apparent in the early 1990s. The growth and commercialization became apparent in the early 1990s. The growth and commercialization
of the Internet stimulated organisations requesting IP addresses in of the Internet stimulated organisations requesting IP addresses in
alarming numbers. By May of 1992 over 45% of the Class B space had alarming numbers. By May of 1992 over 45% of the Class B space had
been allocated. In early 1993 RFC 1466 was published directing been allocated. In early 1993 RFC 1466 was published directing
assignment of blocks of Class C's be given out instead of Class B's. assignment of blocks of Class C's be given out instead of Class B's.
This temporarily circumvented the problem of address space exhaustion, This temporarily circumvented the problem of address space exhaustion,
but had significant impact of the routing infrastructure. but had significant impact of the routing infrastructure.
The number of entries in the "core" routing tables began to grow The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466. This led to the implementation exponentially as a result of RFC 1466. This led to the implementation
of BGP4 and CIDR prefix addressing. This may have circumvented the of BGP4 and CIDR prefix addressing. This may have circumvented the
problem for the present but there are still potential scaling issues. problem for the present but there are still potential scaling issues.
Growth in the population of Internet hosts since the mid-1980s would Growth in the population of Internet hosts since the mid-1980s would
have long overwhelmed the IPv4 address space if industry had not have long overwhelmed the IPv4 address space if industry had not
supplied a circumvention in the form of Network Address Translators supplied a circumvention in the form of Network Address Translators
(NATs). To do this the Internet has sacrificed the underlying (NATs). To do this the Internet has watered down the underlying
"End-to-End" principle. "End-to-End" principle.
In the early 1990's the IETF was aware of these potential problems and In the early 1990's the IETF was aware of these potential problems and
began a long design process to create a successor to IPv4 that would began a long design process to create a successor to IPv4 that would
address these issues. The outcome of that process was IPv6. address these issues. The outcome of that process was IPv6.
The purpose of this document is not to discuss the merits or problems of The purpose of this document is not to discuss the merits or problems of
IPv6. That is a debate that is still ongoing and will eventually be IPv6. That is a debate that is still ongoing and will eventually be
decided on how well the IETF defines transition mechanisms and how decided on how well the IETF defines transition mechanisms and how
industry accepts the solution. The question is not "should," but industry accepts the solution. The question is not "should," but
skipping to change at line 148 skipping to change at line 148
Some attempt has been made by the introduction of the classification of Some attempt has been made by the introduction of the classification of
standards into Full, Draft, Proposed, Experimental, and Historic. standards into Full, Draft, Proposed, Experimental, and Historic.
However, there has not been a concerted effort to actively manage the However, there has not been a concerted effort to actively manage the
classification for older standards. Standards are only classified as classification for older standards. Standards are only classified as
Historic when either a newer version of the protocol is deployed, Historic when either a newer version of the protocol is deployed,
it is randomly noticed that an RFC describes a long dead protocol, or it is randomly noticed that an RFC describes a long dead protocol, or
a serious flaw is discovered in a protocol. Another issue is the status a serious flaw is discovered in a protocol. Another issue is the status
of Proposed Standards. Since this is the entry level position for of Proposed Standards. Since this is the entry level position for
protocols entering the standards process, many old protocols or non- protocols entering the standards process, many old protocols or non-
implemented protocols linger in this status indefinitely. This problem implemented protocols linger in this status indefinitely. This problem
also exists for Experimental Standards. Similarly the problem exists also exists for Experimental RFCs. Similarly the problem exists
for the Best Current Practices (BCP) and For You Information (FYI) for the Best Current Practices (BCP) and For You Information (FYI)
series of documents. series of documents.
To exemplify this point, there are 61 Full Standards, only 4 of which To exemplify this point, there are 61 Full Standards, only 4 of which
have been reclassified to Historic. There are 65 Draft Standards, 611 have been reclassified to Historic. There are 65 Draft Standards, 611
Proposed Standards, and 150 Experimental RFCs, of which only 66 Proposed Standards, and 150 Experimental RFCs, of which only 66
have been reclassified as Historic. That is a rate of less than 8%. have been reclassified as Historic. That is a rate of less than 8%.
It should be obvious that in the more that 30 years of protocol It should be obvious that in the more that 30 years of protocol
development and documentation there should be at least as many (if development and documentation there should be at least as many (if
not a majority of) protocols that have been retired compared to the ones not a majority of) protocols that have been retired compared to the ones
skipping to change at line 209 skipping to change at line 209
In the initial survey of RFCs 175 positives were identified, out of a In the initial survey of RFCs 175 positives were identified, out of a
total of 871, broken down as follows: total of 871, broken down as follows:
Standards 32 of 65 or 49.23% Standards 32 of 65 or 49.23%
Draft Standards 14 of 59 or 23.73% Draft Standards 14 of 59 or 23.73%
Proposed Standards 107 of 602 or 17.77% Proposed Standards 107 of 602 or 17.77%
Experimental RFCs 22 of 145 or 15.17% Experimental RFCs 22 of 145 or 15.17%
Of those identified many require no action because they document Of those identified many require no action because they document
outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for outdated and unused protocols, while others are document protocols
example), while others are document protocols that are actively being that are actively being updated by the appropriate working groups
updated by the appropriate working groups (SNMP MIBs for example). (SNMP MIBs for example).
Additionally there are many instances of standards that should be Additionally there are many instances of standards that should be
updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123
for example) if they are not updated. for example) if they are not updated.
In this statistical survey, a positive is defined as a RFC containing In this statistical survey, a positive is defined as a RFC containing
an IPv4 dependency, regardless of context. an IPv4 dependency, regardless of context.
3.1 Application Area Specifications 3.1 Application Area Specifications
In the initial survey of RFCs, 33 positives were identified out of a In the initial survey of RFCs, 33 positives were identified out of a
total of 257, broken down as follows: total of 257, broken down as follows:
Standards: 1 out of 20, or 5.00% Standards: 1 out of 20, or 5.00%
Draft Standards: 4 out of 25, or 16.00% Draft Standards: 4 out of 25, or 16.00%
Proposed Standards: 18 out of 155 or 11.61% Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 31.58% Experimental RFCs: 10 out of 57 or 17.54%
For more information, please look at [1]. For more information, please look at [1].
3.2 Internet Area Specifications 3.2 Internet Area Specifications
In the initial survey of RFCs 52 positives were identified out of a In the initial survey of RFCs 52 positives were identified out of a
total of 186, broken down as follows: total of 186, broken down as follows:
Standards 17 of 24 or 70.83% Standards 17 of 24 or 70.83%
Draft Standards 6 of 20 or 30.00% Draft Standards 6 of 20 or 30.00%
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/