RFC 3789

Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents

📅 published June 2004, from ietf

RFC 3789 💖

The basics first, bestie 🎀

  • Series: Network Working Group
  • Title: Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents
  • Authors: P. Nesser, II (Nesser & Nesser Consulting), and A. Bergstrom, Ed. (Ostfold University College)
  • Category: Informational
  • Date: June 2004
  • Obsoletes/Updates: this header doesn't list any RFCs it obsoletes or updates 🙈

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🦋

Copyright (C) The Internet Society (2004).

Abstract 🌸

Okay so this doc is a big-picture overview and intro to the v6ops IETF workgroup project, which is documenting all the ways IPv4 addresses get used in IETF standards track and experimental RFCs. 😭 It's split into seven documents that line up with the current IETF areas. It also explains the methodology, which types of RFCs got documented, and gives a combined summary of the results. Iconic, right? 👑

Table of Contents 🧚

1.0.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
      1.1.  Short Historical Perspective . . . . . . . . . . . . .  2
      1.2.  An Observation on the Classification of Standards. . .  3
2.0.  Methodology. . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.1.  Scope. . . . . . . . . . . . . . . . . . . . . . . . .  4
3.0.  Summary of Results . . . . . . . . . . . . . . . . . . . . .  5
      3.1.  Application Area Specifications. . . . . . . . . . . .  5
      3.2.  Internet Area Specifications . . . . . . . . . . . . .  5
      3.3.  Operations and Management Area Specifications. . . . .  6
      3.4.  Routing Area Specifications. . . . . . . . . . . . . .  6
      3.5.  Security Area Specifications . . . . . . . . . . . . .  6
      3.6.  Sub-IP Area Specifications . . . . . . . . . . . . . .  6
      3.7.  Transport Area Specifications. . . . . . . . . . . . .  7
4.0.  Discussion of "Long Term" Stability of Addresses on
      Protocols. . . . . . . . . . . . . . . . . . . . . . . . . .  7
5.0.  Security Considerations. . . . . . . . . . . . . . . . . . .  8
6.0.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  8
7.0.  References . . . . . . . . . . . . . . . . . . . . . . . . .  8
      7.1.  Normative References . . . . . . . . . . . . . . . . .  8
8.0.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
9.0.  Full Copyright Statement . . . . . . . . . . . . . . . . . . 10

1.0. Introduction ✨

This doc is the intro to a whole document set that's trying to document all the usage of IPv4 addresses in IETF standards. 🧚 To keep it manageable, it got broken into 7 documents, matching the current IETF areas (Application [1], Internet [2], Operations and Management [3], Routing [4], Security [5], Sub-IP [6], and Transport [7]). It also covers the methodology, which types of RFCs were documented, and a concatenated summary of results. 💖

1.1. Short Historical Perspective 🌈

Okay, the Internet engineering community has had so many challenges. 💀 The biggest one has been scaling: how do you grow a network that was built for thousands of hosts into one that handles tens of millions of networks with billions of hosts? 😭 Over the years, scaling has been managed, with mixed success, through changes to the network layer and to routing protocols. (Hardware doesn't get enough credit here, ngl. The huge leaps in computing power over the past two decades have been a massive help with the scaling problems dealt with so far, even though the network layer and routing protocols didn't change to account for it.) 🖥️

The first "modern" move to the network layer happened in the early 1980s, going from the Network Control Protocol (NCP) to IPv4. 🦋 It peaked with 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 got updated in RFC 791 to add the famous A, B, C, D, and E class system. 🎀

As networks kept growing, it was obvious that they needed a way to be broken into smaller pieces. In October of 1984, RFC 917 was published to formalize subnetting. 🍓

By the late 1980s, it was clear that the exterior routing protocol the Internet was using at the time (EGP) wasn't robust enough to scale with the Internet's growth. The first version of BGP was documented in 1989 in RFC 1105. 🫶

Then came another scaling issue: running out of Class B address space, which showed up in the early 1990s. 😭 Growth and commercialization pushed organisations to request 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 that blocks of Class C's be handed out instead of Class B's. That temporarily dodged the address exhaustion problem, but it had a big impact on the routing infrastructure. 🌸

Because of RFC 1466, the number of entries in the "core" routing tables started growing exponentially. ⭐ That led to the implementation of BGP4 and CIDR prefix addressing. This may have worked around the problem for now, but they still pose potential scaling issues. 👑

Growth in the population of Internet hosts since the mid-1980s would have totally overwhelmed the IPv4 address space if industry hadn't supplied a workaround in the form of Network Address Translators (NATs). To do this, the Internet watered down the underlying "End-to-End" principle. 🙈

In the early 1990s, the IETF knew about these potential problems and started a long design process to create a successor to IPv4 that would address them. That process's outcome was IPv6. ✨

The purpose of this document is not to discuss the merits or problems of IPv6. 🫶 That debate is still ongoing, and it will eventually be decided by 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 🔥

Okay, this part is a little tea ☕. During this investigation it became super clear that there hasn't been much management of the status of standards over the years. Some effort was made by introducing the classifications Full, Draft, Proposed, Experimental, and Historic. 🌈 However, there hasn't been a concerted effort to actively manage the classification of older standards. Standards only get classified as Historic when a newer version of the protocol is deployed and someone randomly notices an RFC describing a long dead protocol, or when a serious flaw is discovered in a protocol. 💀

Proposed Standards are another issue. This is the entry-level spot for protocols entering the standards process, so many old protocols or non-implemented protocols linger in this status indefinitely. 🙈 The same problem exists for Experimental RFCs. Similarly, the problem exists for the Best Current Practices (BCP) and For You Information (FYI) series of documents. 🧚

To put this into numbers: 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's a rate of less than 8%. 😭 It should be obvious that after more than 30 years of protocol development and documentation, there should be at least as many (if not a majority of) retired protocols as active ones. 🦋

Please note there's sometimes confusion about what a "Historic" classification means. It does NOT necessarily mean that the protocol isn't being used. A good example is Routing Information Protocol (RIP) version 1. Many thousands of sites use this protocol even though it has Historic status. 🌸 There are potentially hundreds of other classified RFCs that should be reclassified. 💖

2.0. Methodology 🎀

To run this study, each class of IETF standards was 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, either by newer versions or because they moved through the standards process, are not covered. RFCs classified as Historic aren't included either. 🧚

Also, a side effect of this choice is that some protocols defined by a series of RFCs at different levels of standards maturity get covered in different spots in the document. 🍓 Other natural groupings (for example MIBs, SMTP extensions, IP over FOO, PPP, DNS, etc.) could easily have been imagined too. ✨

2.1. Scope 💅

The procedure for this investigation was an exhaustive reading of the applicable RFCs. 😭 That meant reading about 25,000 pages of protocol specifications. And it wasn't just simple reading: the author had to actually understand the purpose and functionality of each protocol to make a proper determination of IPv4 reliability. 🤓 The author made every effort to produce as complete a document set as possible, but it's likely that some subtle (or maybe not so subtle) dependency was missed. The author encourages anyone familiar with a protocol (designers, implementers, or anyone with intimate knowledge) to review the relevant sections and leave comments. 🫶

3.0. Summary of Results 👑

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

      Standards:                        30 out of  68 or 44.12%
      Draft Standards:                  16 out of  68 or 23.53%
      Proposed Standards:               98 out of 597 or 16.42%
      Experimental RFCs:                29 out of 144 or 20.14%

Of those identified, many don't need any action because they document outdated and unused protocols, while others are active protocols being updated by the appropriate working groups (SNMP MIBs, for example). 🌈

There are also many standards that should be updated but don't cause any operational impact if they aren't (STD 3/RFCs 1122 and 1123, for example). 🙈

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

3.1. Application Area Specifications 🦋

In the initial survey of RFCs, 34 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 🌐

okay so in the first sweep of the RFCs we found 52 positives out of 186 total. here's how it broke down 👀

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

for more info, check out [2] 💖

3.3. Operations and Management Area Specifications 🛠️

in the first sweep we got 36 positives out of 153 total. the breakdown is giving 📊

      Standards:                         6 out of  15 or 40.00%
      Draft Standards:                   4 out of  15 or 26.67%
      Proposed Standards:               26 out of 112 or 23.21%
      Experimental RFCs:                 0 out of  11 or  0.00%

for more info, check out [3] 🎀

3.4. Routing Area Specifications 🗺️

first sweep: 23 positives out of 46 total. the numbers are kinda wild 😭

      Standards:                         3 out of  3 or 100.00%
      Draft Standards:                   1 out of  3 or  33.33%
      Proposed Standards:               13 out of 29 or  44.83%
      Experimental RFCs:                 6 out of 11 or  54.54%

for more info, check out [4] 🦋

3.5. Security Area Specifications 🔐

in the first sweep, 4 positives out of 124 total. honestly the security area is giving a small-but-mighty vibe 💅

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

for more info, check out [5] 🌸

3.6. Sub-IP Area Specifications 🧚

first sweep: 0 positives out of 7 total. no cap, this one's a tiny area 🥺

      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%

for info about the Sub-IP Area standards, check out [6] 🍓

3.7. Transport Area Specifications 🚚

in the first sweep we found 24 positives out of 104 total. the transport area really said "I'm here for it" 🔥

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

for more info, check out [7] 💜

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

okay so when we tried to do this analysis, we realized a full-scale version is way too big for this doc 😭 so instead we're giving a quick chat about how a framework like this could get set up ✨

one idea is to look at protocols based on what they actually do, kinda like the OSI network reference model (but not strictly, we're not that rigid bestie 💅). it might also make more sense to frame everything by the different IETF Areas.

this whole thing is foundational to the Internet's architecture and where it's headed 🌈 the IPng (now IPv6) folks wanted "automatic" and "easy" address renumbering, and they also wanted "stateless autoconfiguration." so a lot of work went into protocols like DHCP and Dynamic DNS 🫶 but honestly? this goes against the Internet's age-old "end-to-end principle." it's a whole vibe shift 💀

most protocol designs quietly count on certain underlying principles already being true in the network. like, packet switched networks let upper layer protocols ignore whether the route underneath is stable 🦋 when paths change, the higher layers usually have no clue and honestly don't care. and that works great, because whether a packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is basically no big deal 🙈

now picture a world where endpoints (like A and F in the example above) change at a "rapid" rate 😳 then we need to think about a new model for protocol developers. a logical move would be changing how the Transport layer protocols work 💖 right now you basically pick TCP or UDP, and neither one gives you any clean way to hand off a connection when the endpoint (IP) addresses change. maybe we need a third major transport layer protocol, or maybe updated TCP and UDP specs that add this function would be the better move ✨

there are SO many variables that would need to go into building something like this 😩 some things to think about: timing principles; overlap periods as an endpoint moves from address A, to addresses A and B (answers to both), to only B; delays due to the recalculation of routing paths, etc...

5.0. Security Considerations 🛡️

⚠️ okay bestie, this one is short but it's important. this memo examines the IPv6-readiness of specifications. this does not have security considerations in itself.

6.0. Acknowledgements 🫶

the authors want to give a shoutout to the Internet Society for supporting the research and production of this document 🎀 author Philip J. Nesser II also wants to thanks his partner in all ways, Wendy M. Nesser 💕

the editor, Andreas Bergstrom, wants to thank Pekka Savola for the guidance and for collecting comments while editing this doc 🙌 he also wants to thank Alan E. Beard, Jim Bound, Brian Carpenter, and Itojun for giving valuable feedback on many points. the whole team really showed up 👑

7.0. References 📚

7.1. Normative References

[1]  Sofia, R. and P. Nesser, II, "Survey of IPv4 Addresses in
     Currently Deployed IETF Application Area Standards", RFC 3795,
     June 2004.

[2]  Mickles, C., Editor and P. Nesser, II, "Survey of IPv4 Addresses
     in Currently Deployed IETF Internet Area Standards", RFC 3790,
     June 2004.

[3]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
     Addresses in Currently Deployed IETF Operations & Management
     Area Standards", RFC 3796, June 2004.

[4]  Olvera, C. and P. Nesser, II, "Survey of IPv4 Addresses in
     Currently Deployed IETF Routing Area Standards", RFC 3791, June
     2004.

[5]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
     Addresses in Currently Deployed IETF Security Area Standards",
     RFC 3792, June 2004.

[6]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
     Addresses in Currently Deployed IETF Sub-IP Area Standards", RFC
     3793, June 2004.

[7]  Nesser, II, P. and A. Bergstrom, Editor, "Survey of IPv4
     Addresses in Currently Deployed IETF Transport Area Standards",
     RFC 3794, June 2004.

8.0. Authors' Addresses 📬

please reach out to 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 482 9721
EMail:  phil@nesser.com


Andreas Bergstrom, Editor
Ostfold University College
Rute 503 Buer
N-1766 Halden
Norway

EMail: andreas.bergstrom@hiof.no

Copyright (C) The Internet Society (2004). this document is subject to the rights, licenses and restrictions in BCP 78. except as set forth there, the authors keep all their rights 💅

this document and the info in it are provided on an "AS IS" basis, and the contributor, the organization they represent or are sponsored by (if any), the Internet Society and the Internet Engineering Task Force all disclaim the following, in full:

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 on whether any Intellectual Property Rights or other rights that someone might claim about the technology in this document are valid or in scope, or on whether anyone can get a license for them. it also doesn't say it made any independent effort to find those rights. info about how rights work for RFC documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, or the results of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

the IETF invites any interested party to let it know about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 🌸

funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from