Re: WG Last Call: a batch of draft-ietf-v6ops-ipv4survey-*01 documents

["Alan E. Beard" <aeb1@aebeard.com>]

Folks:

Hereinafter a few comments on

Introduction to the Survey of IPv4 Addresses in Currently
Deployed IETF Standards
   http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv4survey-intro-01.txt

per Pekka's request below. I'll review the other documents queued for last
call within a few days.

AEB


On Wed, 13 Aug 2003, Pekka Savola wrote:

> Hello all,
>
> Thanks to those who have sent feedback (both on and off-list).
>
> However, a couple of people reading through them is not enough.
>
> PLEASE review the documents ASAP and provide feedback.  We NEED stronger
> support and acknowledgement from the WG that these have actually been
> read!
>

The comments below pertain to section 1.1 of  -ipv4survey-intro-01.
Further comments on this document, mostly concerning section 4, will
follow.

Most of the comments are changes in text for enhanced readability and for
clarification of ambiguous terms.  Changes which do not effect substantial
modification in the meaning of the original (as interpreted by this
reader) are interpolated into the body of the text, with original wording
shown in brackets immediately following the replacement text.

In a few cases suggesting for alternative wording are given which may
alter the substantive meaning of the original: these changes are given in
brackets immediately following the paragraph in which the original text
appears, along with some explanation of the reasoning which prompted the
suggested changes.

I will be interested to learn the reactions of the WG participants to the
changes suggested below.  Comments are welcome; also flames, within
reason. ;-)

Herewith the suggestions:



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 overcome with 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.)

[Alternative text for sentence 2 of the paragraph above:

Over the years this scaling issue has been managed, with varying degrees
of success, by changes made to the network layer and to routing protocols.

Reasoning: In light of our current discussions, it seems to me that the
scaling issue (in actuality, a group of entangled issues) is still with
us; we have so far avoided the worst of the postulated adverse effects by
changes to routing protocols, network layer conventions, operational
techniques described in later paragraphs of the extant draft.  Given the
nature and extent of current activities which purport to address "the
scaling issue", I don't think we have "overcome" the problem; it seems to
me that scaling issues will be a fact of life in the IP world for the
foreseeable future, although we now have a limited set of tools and
techniques for dealing with some of the more pernicious effects, and it is
within our capability to develop more such tools.]

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.

[note: much of the above paragraph has been re-written, but, I think,
without any substantive change in meaning. AEB]

Networks were growing in such a way that it was clear that a convention
for [original text: ...a need 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 [original: was not
sufficient 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. [original text: The next scaling issues to
became apparent in the early 1990's was the exhaustion of the Class B
address space.] The growth and commercialization of the Internet
stimulated organizations to request IP [original text: ...Internet had
organizations requesting IP...] addresses in alarming numbers. By May
[original text: In May...] of 1992 over 45% of the Class B space was
allocated.  In early 1993 RFC 1466 was published directing assignment of
blocks of Class Cs to be given out in lieu of Class B allocations.
[original text: ...Class C's be given out instead of Class B's.] This
solved the problem of address space exhaustion but had significant impact
of the routing infrastructure.

[In the last sentence above, perhaps the word "solved" might be replaced
by any of these words or phrases: "palliated" or "temporarily
circumvented" or "alleviated" or "delayed the most pernicious effects of".
The problem of exhaustion of IPv4 address space is still with us, and is
likely to be extant until a substantial proportion of existing IPv4
networks migrate to IPv6 and surrender their v4 allocations. This appears
as a suggestion because the wording change also effects a significant
alteration in the meaning of the original text: this extends well beyond
a mere clarification.]

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 solved the problem
for the present but there are still potential scaling issues.

[Again, regarding the last sentence above, perhaps a more accurate reading
of the current state of the technology would substitute for the word
"solved" any of the following: "alleviated" or "circumvented".  This
appears as a suggestion because the wording change also effects a
significant change in meaning.]

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 solution in the form of Network Address Translators (NATs).[original
text: Current Internet growth would have long overwhelmed the current
address space if industry didn't supply a solution in Network Address
Translators (NATs).] To do this the Internet has sacrificed the underlying
"End-to-End" principle.

[Regarding the first sentence in the paragraph immediately above: some of
the IPv6 WG members consider NAT not a solution at all; rather, they
proclaim NAT an unmitigatedly BAD THING (emphasis in the original) and,
even in the most generous and flattering of all possible interpretations,
not better than a crude kludge. Perhaps the word "solution" might be
replaced with "circumvention" for a reading more consistent with the
common wisdom concerning NAT.  Additionally, should we make some mention
of PNN address spaces (RFC 1918), without which NAT would probably not
have become as widely implemented as it is today?  Based on what we see
in enterprise implementations, either NAT or PNN alone would probably
have been insufficient to relieve, even temporarily, the demand for v4
address space arising from the rapid growth of IP host counts in business
and academic environments.]

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."

************

Now, what think ye all?

Regards,

AEB
-- 
Alan E. Beard <aeb1@aebeard.com>
AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809
863.815.2529