Subject: Re: IP network address assignments/allocations information?

From: "Perry E. Metzger" <[email-masked]>
Date: 02 Dec 1999 17:36:48 -0500

Brian E Carpenter <[email-masked]> writes:
> Well, let's not focus on Bill's data. Frankly, I haven't seen any data
> on this topic from any source that really convinces me that it
> means much. All I know is that we have thousands of sites using
> private address space, which completely falsifies any real data and
> makes it impossible to attach any real meaning to concepts such as
> "running out of addresses". My personal opinion is that we ran out
> of addresses in practical terms around about when RFC 1597 was published.

I hate to start a flame war, but Brian is absolutely right. I have
clients spending gargantuan amounts of money dealing with layer upon
layer of NATs because of this. Some people believe that "we aren't
running out of address space" but the fact is that we've already run
out. It just isn't available for many essential purposes.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 02 Dec 1999 17:36:48 -0500

Perry

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Dec 1999 15:23:43 -0800

>clients spending gargantuan amounts of money dealing with layer upon

Folks might recall that, back then, there were nicely elaborate 
calculations put forward, about the date that we would "run out" of 
addresses.  The methodology for the calculations was highly flawed, but 
responses to concern about the methodology was that the numbers were 
"interesting".

The methodology tried to use calculations which did not adequately provide 
for the increased rate of growth that we were just starting to see.

Worse was with the definition of "running out".  Discussion focused on "no 
more addresses available" rather than "a network administrator is not able 
to get a reasonable block allocation".  The latter forced us into NATs.  As 
Brian notes, we really "ran out" a long, long time ago.

This history is worth considering not as sour grapes but to ask whether 
there is some way to get better planning discussions within the IETF.  We 
can't expect to anticipate all requirements.  However some shout loudly 
ahead of time.  The IAB did, after all, try to get a larger address space 
pursued quite awhile ago.

It would be nice to avoid these kinds of problems, in the first place, 
rather than having to dig ourselves out from under them, later.

d/

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave Crocker                                       Brandenburg Consulting
Tel: +1.408.246.8253          675 Spruce Drive       Fax: +1.408.273.6464
[email-masked]   Sunnyvale, CA 94086 USA    www.brandenburg.com

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Dec 1999 15:23:43 -0800

d/

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 02 Dec 1999 16:53:10 -0800

Perry,
 
> out. It just isn't available for many essential purposes.

Consider an alternative where the client decides to use IPv6.  Granted,
the client could get enough IPv6 addresses for all purposes, regardless of
whether these purposes essential or not. But then in order for that
client to communicate with the rest of the folks, the client would
likely to use NAT (as the rest of the folks would still use IPv4). So,
the cost of using NAT wouldn't go away.  But in addition, this alternative
would cause the client to swallow the cost of transition from IPv4 to IPv6 
in its infrastructure.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 02 Dec 1999 16:53:10 -0800

Perry,

Yakov.

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 03 Dec 1999 08:17:19 +0000

In message <[email-masked]>, Yakov Rekhter typed:

 >>likely to use NAT (as the rest of the folks would still use IPv4). 

its economics - if one large client uses IPv6, then so will others
eventually as its cheaper for all of them colelctively than for them
to go on using NATs.

 >>would cause the client to swallow the cost of transition from IPv4 to IPv6 

right - the problem is gettng the FIRST person to go - clearly a
PROVIDER could consider swallowing the cost (i.e. pay cisco to
implement, and debug a deployed IPv6 backbone and then chase customer
problems) - why?> because in the LONG run there's more subscribers
selling content, doing busienss in a fully IP (v6) connected net
than  on a NAT disconnect, and so there's more money for the
provider....

btw, i think the address space stuff for subscribers using NATs is often
(not always) hokum - its
mostly that they can't be bothered to design a decent addressing
architecture for their intranets.

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 03 Dec 1999 08:17:19 +0000

cheers

   jon

---

From: Bill Manning <[email-masked]>
Date: Fri, 3 Dec 1999 05:12:48 -0800 (PST)

> architecture for their intranets.

Oh, I think that there are lots of good engineers out there who do a great
job of designing decent addressing architectures for their networks.
Now if the darn things would just stay within the design constraints over
time, there would not be a problem. Trouble is, those pesky users keep
thinking up new things to do with the network, violating design assumptions.
Makes the addressing architects life a living hell...
	(insert a  quick overview of the evolution of the IPv4
	 addressing architecture here...)
Still, I do think a basic NAT design philosophy is one of "withdraw into my
own little world, protecting me from dealing w/ the troubles outside".

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Fri, 3 Dec 1999 05:12:48 -0800 (PST)

-- 
--bill

---

From: Steve Deering <[email-masked]>
Date: Fri, 3 Dec 1999 08:29:21 -0800

>would cause the client to swallow the cost of transition from IPv4 to IPv6 

Yakov,

There are costs to be swallowed either way, and I believe the costs of
*not* transitioning will be much higher in the end than the costs of
transitioning.  If we don't manage to get the majority of long-haul
communication converted to using bigger addresses before we run out of
global IPv4 addresses for those things that need them even with current
NAT (those things being the "public" side of NAT boxes, and devices that
need to be targets of externally-initiated communication, like IP-based
telephones, pagers, individual monitors, more numerous servers of all
kinds, and devices we haven't imagined yet), then the next level of
"solutions" (NATs between ISPs, routing protocols for DNS names,
recursive RSIP,...) will make today's NAT look benign, in terms of
complexity, interdependency, fragility, insecurity, unmanagability,
and lost functionality.  And if RSIP is part of the "solution", we'll
still end up bearing the costs of upgrading all the hosts anyway, costs
that would be better spent upgrading to IPv6 and actually *solving* the
address shortage problem instead of building an increasingly elaborate,
fragile, and dysfunctional system of work-arounds.

In other words, it's really a question of whether we (the Internet
users, providers, and vendors) expend effort to climb out of the hole
we're in, or keep digging deeper.  We can't avoid expending effort,
because more and more people are jumping into the hole and they won't
all fit.

(And to really milk this metaphor: yes, the first few people who climb
out of the hole still have to pass messages down into the hole to
communicate with those still down there, but at least they can enjoy
the fresh air and wide open space of address abundance.)

Steve

---

From: Steve Deering <[email-masked]>
Date: Fri, 3 Dec 1999 08:29:21 -0800

Yakov,

Steve