Skip to main content

Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents
draft-ietf-v6ops-ipv4survey-intro-06

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 3789.
Authors Andreas Bergstrom , Philip J. Nesser II
Last updated 2013-03-02 (Latest revision 2003-12-22)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 3789 (Informational)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Bert Wijnen
Send notices to <pekkas@netcore.fi>, <Jonne.Soininen@nokia.com>,<bob@thefinks.com>
draft-ietf-v6ops-ipv4survey-intro-06
Network Working Group                               Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-intro-06.txt     Nesser & Nesser Consulting
Internet Draft                                  Andreas Bergstrom (Ed.)
                                             Ostfold University College
                                                          December 2003
                                                       Expires May 2004

           Introduction to the Survey of IPv4 Addresses in 
                 Currently Deployed IETF Standards

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document is a general overview and introduction to the v6ops IETF
workgroup project of documenting all usage of IPv4 addresses in
currently deployed IETF documented standards.  It is broken into seven
documents conforming to the current IETF areas.  It also describes the
methodology used during documentation, which type of RFCs that has
been documented, and a concatenated summary of results.

Table of Contents

1. Introduction
   1.1 Short Historical Perspective
   1.2 An Observation on the Classification of Standards
2. Methodology
   2.1 Scope
3. Summary of Results
   3.1 Application Area Specifications
   3.2 Internet Area Specifications
   3.3 Operations & Management Area Specifications
   3.4 Routing Area Specifications
   3.5 Security Area Specifications
   3.6 Sub-IP Area Specifications
   3.7 Transport Area Specifications
4. Discussion of "Long Term" Stability of Addresses on Protocols
5. Security Consideration
6. Acknowledgements
7. References
7.1 Normative
8. Authors' Addresses
9. Intellectual Property Statement
10. Full Copyright Statement

1.0 Introduction

This document is the introduction to 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[1],  
Internet[2], Management & Operations[3], Routing[4], Security[5], 
Sub-IP[6] and Transport[7]).  It also describes the methodology used 
during documentation, which type of RFCs that has been documented, 
and a concatenated summary of results.

1.1 Short Historical Perspective

There are many challenges that face the Internet Engineering community.
The foremost of these challenges has been the scaling issue: how to 
grow a network that was envisioned to handle thousands of hosts to one 
that will handle tens of millions of networks with billions of hosts.  
Over the years this scaling problem has been managed, with varying 
degrees of succes, by changes to the network layer and to routing 
protocols.  (Although largely ignored in the changes to network layer 
and routing protocols, the tremendous advances in computational 
hardware during the past two decades have been of significant benefit 
in managment of scaling problems encountered thus far.)

The first "modern" transition to the network layer occurred in during 
the early 1980's from the Network Control Protocol (NCP) to IPv4.  This
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
documented in RFC 760.  A year later IPv4 was updated in RFC 791 to
include the famous A, B, C, D, & E class system.

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 
1984 RFC 917 was published formalizing the practice of subnetting.

By the late 1980's it was clear that the current exterior routing 
protocol used by the Internet (EGP) was insufficiently robust to scale 
with the growth of the Internet.  The first version of BGP was 
documented in 1989 in RFC 1105.

Yet another scaling issue, exhaustion of the class B address space, 
became apparent in the early 1990s.  The growth and commercialization 
of the Internet stimulated organisations requesting IP addresses in 
alarming numbers.  By May of 1992 over 45% of the Class B space had
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.  
This temporarily circumvented the problem of address space exhaustion, 
but had significant impact of the routing infrastructure.

The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466.  This led to the implementation 
of BGP4 and CIDR prefix addressing.  This may have circumvented the 
problem for the present but there are still potential scaling issues.

Growth in the population of Internet hosts since the mid-1980s would
have long overwhelmed the IPv4 address space if industry had not 
supplied a circumvention in the form of Network Address Translators 
(NATs).  To do this the Internet has watered down the underlying 
"End-to-End" principle.

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
address these issues.  The outcome of that process was IPv6.

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
decided on how well the IETF defines transition mechanisms and how
industry accepts the solution.  The question is not "should," but 
"when."

1.2 An Observation on the Classification of Standards

It has become clear during the course of this investigation that there
has been little management of the status of standards over the years.
Some attempt has been made by the introduction of the classification of
standards into Full, Draft, Proposed, Experimental, and Historic.
However, there has not been a concerted effort to actively manage the
classification for older standards.  Standards are only classified as
Historic when either a newer version of the protocol is deployed,
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
of Proposed Standards.  Since this is the entry level position for
protocols entering the standards process, many old protocols or non-
implemented protocols linger in this status indefinitely.  This problem
also exists for Experimental RFCs.  Similarly the problem exists
for the Best Current Practices (BCP) and For You Information (FYI)
series of documents.

To exemplify this point, there are 61 Full Standards, only 4 of which
have been reclassified to Historic. There are 65 Draft Standards, 611
Proposed Standards, and 150 Experimental RFCs, of which only 66
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
development and documentation there should be at least as many (if
not a majority of) protocols that have been retired compared to the ones
that are currently active.

Please note that there is occasionally some confusion of the meaning of
a "Historic" classification.  It does NOT necessarily mean that the
protocol is not being used.  A good example of this concept is the
Routing Information Protocol(RIP) version 1.  There are many thousands
of sites using this protocol even though it has Historic status.  There
are potentially hundreds of otherwise classified RFC's that should be
reclassified.

2.0 Methodology

To perform this study each class of IETF standards are investigated in
order of maturity:  Full, Draft, and Proposed, as well as Experimental.
Informational and BCP RFCs are not addressed.  RFCs that have been
obsoleted by either newer versions or as they have transitioned through
the standards process are not covered.  RFCs which have been classified
as Historic are also not included.

Please note that a side effect of this choice of methodology is that
some protocols that are defined by a series of RFC's that are of 
different levels of standards maturity are covered in different spots 
in the document.  Likewise other natural groupings (i.e. MIBs, SMTP 
extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined.

2.1 Scope

The procedure used in this investigation is an exhaustive reading of the
applicable RFC's.  This task involves reading approximately 25000 pages
of protocol specifications.  To compound this, it was more than a 
process of simple reading.  It was necessary to attempt to understand 
the purpose and functionality of each protocol in order to make a proper
determination of IPv4 reliability.  The author has made every effort to 
make this effort and the resulting document as complete as possible, but
it is likely that some subtle (or perhaps not so subtle) dependence was 
missed.  The author encourage those familiar (designers, implementers 
or anyone who has an intimate knowledge) with any protocol to review 
the appropriate sections and make comments.

3.0  Summary of Results

In the initial survey of RFCs 175 positives were identified, out of a
total of 871, broken down as follows:

        Standards                         32 of  65 or 49.23%
        Draft Standards                   14 of  59 or 23.73%
        Proposed Standards               107 of 602 or 17.77%
        Experimental RFCs                 22 of 145 or 15.17%

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 
(SNMP MIBs for example).  
Additionally there are many instances of standards that should be 
updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 
for example) if they are not updated.

In this statistical survey, a positive is defined as a RFC containing
an IPv4 dependency, regardless of context.

3.1 Application Area Specifications

In the initial survey of RFCs, 33 positives were identified out of a 
total of 257, broken down as follows:

       Standards:                          1 out of 20, or  5.00%
       Draft Standards:                    4 out of 25, or 16.00%
       Proposed Standards:                19 out of 155 or 12.26%
       Experimental RFCs:                 10 out of 57  or 17.54%

For more information, please look at [1].

3.2 Internet Area Specifications

In the initial survey of RFCs 52 positives were identified out of a
total of 186, broken down as follows:

      Standards                          17 of  24 or 70.83%
      Draft Standards                     6 of  20 or 30.00%
      Proposed Standards                 22 of 111 or 19.91%
      Experimental RFCs                   7 of  31 or 22.58%

For more information, please look at [2].

3.3 Operations & Management Area Specifications

In the initial survey of RFCs 36 positives were identified out of a 
total of 153, broken down as follows:
 
        Standards                                6 of  15 or 40.00%
        Draft Standards                          4 of  15 or 26.67%
        Proposed Standards                      26 of 112 or 23.21%
        Experimental RFCs                        0 of  11 or  0.00%

For more information, please look at [3].

3.4 Routing Area Specifications

In the initial survey of RFCs, 22 positives were identified out of a
total of 44, broken down as follows:

   Standards                                    3 of  3 or 100.00%
   Draft Standards                              1 of  2 or  50.00%
   Proposed Standards                          13 of 29 or  44.83%
   Experimental RFCs                            6 of 11 or  54.54%

For more information, please look at [4].

3.5 Security Area Specifications

In the initial survey of RFCs 4 positives were identified out of a 
total of 124, broken down as follows:

        Standards                               0 of   1 or  0.00%
        Draft Standards                         1 of   3 or 33.33%
        Proposed Standards                      1 of 102 or  0.98%
        Experimental RFCs                       2 of  18 or 11.11%

For more information, please look at [5].

3.6 Sub-IP Area Specifications

In the initial survey of RFCs, 0 positives were identified out of a 
total of 7, broken down as follows:

        Standards                           0 of  0 or  0.00%
        Draft Standards                     0 of  0 or  0.00%
        Proposed Standards                  0 of  6 or  0.00%
        Experimental RFCs                   0 of  1 or  0.00%

For information about the Sub-IP Area standards, please look at [6].

3.7 Transport Area Specifications

In the initial survey of RFCs 25 positives were identified out of a 
total of 104, broken down as follows:

        Standards                                 3 of  5 or 60.00%
        Draft Standards                           0 of  2 or  0.00%
        Proposed Standards                       17 of 82 or 20.73%
        Experimental RFCs                         4 of 15 or 26.67%

For more information, please look at [7].

4.0  Discussion of "Long Term" Stability of Addresses on Protocols

In attempting this analysis it was determined that a full scale 
analysis is well beyond the scope of this document.  Instead a short
discussion is presented on how such a framework might be established.

A suggested approach would be to do an analysis of protocols based on 
their overall function, similar (but not strictly) to the OSI network
reference model.   It might be more appropriate to frame the discussion
in terms of the different Areas of the IETF.  

The problem is fundamental to the overall architecture of the Internet
and its future.  One of the stated goals of the IPng (now IPv6) was 
"automatic" and "easy" address renumbering.  An additional goal is
"stateless autoconfiguration."  To these ends, a substantial amount of
work has gone into the development of such protocols as DHCP and Dynamic
DNS.  This goes against the Internet age-old "end-to-end principle."

Most protocol designs implicitly count on certain underlying principles
that currently exist in the network.  For example, the design of packet
switched networks allows upper level protocols to ignore the underlying
stability of packet routes.  When paths change in the network, the 
higher level protocols are typically unaware and uncaring.  This works
well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of
little consequence. 

In a world where endpoints (i.e. A and F in the example above) change 
at a "rapid" rate, a new model for protocol developers should be 
considered.  It seems that a logical development would be a change in 
the operation of the Transport layer protocols.  The current model is
essentially a choice between TCP and UDP,  Neither of these protocols
provides any mechanism for an orderly handoff of the connection if and
when the network endpoint (IP) addresses changes.  Perhaps a third 
major transport layer protocol should be developed, or perhaps updated
TCP & UDP specifications that include this function might be a better
solution.  

There are many, many variables that would need to go into a successful
development of such a protocol.  Some issues to consider are: timing 
principles; overlap periods as an endpoint moves from address A, to 
addresses A & B (answers to both), to  only B; delays due to the 
recalculation of routing paths, etc...

5.0 Security Consideration

This memo examines the IPv6-readiness of specifications; this does not
have security considerations in itself.

6.0 Acknowledgements

The authors would like to acknowledge the support of the Internet 
Society in the research and production of this document.  
Additionally the author, Philip J. Nesser II, would like to thanks 
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.
He would further like to thank Alan E. Beard, Jim Bound, Brian Carpenter 
and Itojun for valuable feedback on many points of this document.

7.0 References

7.1 Normative

[1]  Philip J. Nesser II, Rute Sofia. "Survey of IPv4 Addresses 
     in Currently Deployed IETF Application Area Standards", 
     draft-ietf-v6ops-ipv4survey-apps-03.txt 
     IETF work in progress, October 2003

[2]  Philip J. Nesser II, Cleveland Mickles. "Internet Area: Survey 
     of IPv4 Addresses Currently Deployed Deployed IETF Standards", 
     draft-ietf-v6ops-ipv4survey-int-02.txt 
     IETF work in progress, October 2003

[3]  Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses
     in Currently Deployed IETF Operations & Management Area Standards",
     draft-ietf-v6ops-ipv4survey-ops-04.txt 
     IETF work in progress, November 2003

[4]  Philip J. Nesser II, Cesar Olvera. "Survey of IPv4 Addresses 
     in Currently Deployed IETF Routing Area Standards", 
     draft-ietf-v6ops-ipv4survey-routing-02.txt IETF work in progress,
     October 2003

[5]  Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses
     in Currently Deployed IETF Security Area Standards",
     draft-ietf-v6ops-ipv4survey-sec-03.txt IETF work in progress,
     November 2003

[6]  Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses
     in Currently Deployed IETF Sub-IP Area Standards",
     draft-ietf-v6ops-ipv4survey-subip-04.txt IETF work in progress,
     November 2003

[7]  Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses
     in Currently Deployed IETF Transport Area Standards",
     draft-ietf-v6ops-ipv4survey-trans-04.txt IETF work in progress,
     November 2003

8.0 Authors' Addresses

Please contact the author with any questions, comments or suggestions
at:

Philip J. Nesser II
Principal
Nesser & Nesser Consulting
13501 100th Ave NE, #5202
Kirkland, WA 98034

Email:  phil@nesser.com
Phone:  +1 425 481 4303
Fax:    +1 425 482 9721

Andreas Bergstrom (Editor)
Ostfold University College
Email: andreas.bergstrom@hiof.no
Address: Rute 503 Buer
         N-1766 Halden
         Norway

9.0 Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

10.0  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu-
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English. The lim-
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS 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.