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

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 7 Dec 1999 16:22:31 -0500

> From: Daniel Senie <[email-masked]>

    > The counter argument is that for the Home Networking case, which is a
    > HUGE market, it is indeed cheap and easy to use. ... NAT can be used
    > for a variety of things. Perhaps we can agree that it's a good hammer
    > when the nail is a home network, and concentrate on what to do about
    > the large corporation issue.

This relates to a thought I've been having over the last couple of days,
which is that I recently read that the Internet usage numbers in many large
cities in the US (sorry, no idea about the rest of the world, and in any case
this point relates to ARIN only) is now at or over 50% of citizens - i.e. in
the US, the logistic growth curve for that group (which ought to be the
largest possible market segment) has started to tip over.

So my question is: I've been hearing that ARIN is the stingiest of the
registries when it comes to handing out IPv4 addresses - is there any valid
reason for this extreme parsimoniousness (particularly when the plan is to
move over to IPv6, so there ought to be no reason for extreme hoarding of
IPv4 addresses)?

Perhaps a little loosening of the address allocation tap at ARIN, when it
comes to allocating addresses for non-home use, could make life substantially
easier for the segment where some people are finding NAT making their life
difficult?

	Noel

---

From: Kim Hubbard <[email-masked]>
Date: Tue, 07 Dec 1999 17:13:19 -0500

>easier for the segment where some people are finding NAT making their life

I wouldn't say that ARIN is stingy in how much address space it issues, we
allocate whatever an organization (any organization) can justify but they
must be able to justify at least a /20 (by whichever allocation/assignment
policy applies to them) or they will be referred to their upstream ISP.
This isn't done as much for conservation of address space as it is for
aggregation of routing table space.   We recently lowered our minimum
allocation from a /19 to a /20 to allow more organizations to come directly
to ARIN for address space and are monitoring the effect on the routing
tables to see if we can continue lowering it in the future.

Kim

---

From: Kim Hubbard <[email-masked]>
Date: Tue, 07 Dec 1999 17:13:19 -0500

Kim

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 7 Dec 1999 16:31:54 -0800 (PST)

Kim,

what is the impact of allocations -vs- routing table space. a public
access route server reports the following:

64152 network entries and 253321 paths using 13815800 bytes of memory
another sez
69584 network entries and 704080 paths using 32026944 bytes of memory

while my numbers above may not be significant or representative of the
entire net, neither of the above support your conclusion that *today* we
need be seriously concerned with tight allocation policy based on the need
for route aggregation. memory is cheap now, so lets loosen those thumb
screws ;-)

regards,

-rick

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 7 Dec 1999 16:31:54 -0800 (PST)

Kim,

regards,

-rick

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 1999 17:12:34 -0800

> memory is cheap now, so lets loosen those thumb screws ;-)

i think we need an automaton to post a few things every few hours to this
and the nanog list.

it's not the memory.  it's the processing power required which is quite
non-linear.

it's not the memory for the /24s in old b space, it's the horrifying *large*
and *long* meltdowns caused by inadvertant leakage of bogus announcements of
/24s in old b space

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 1999 17:12:34 -0800

randy

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 7 Dec 1999 18:05:57 -0800 (PST)

randy,

just because routers meltdown from leaks and mis-configurations is not a
reasonable justification for ARIN's tight policies on IPv4 allocations,
which kim stated earlier was to keep space aggrigated for router memory
requirements, adding speed and processing power to that definition still
does not justify the strict policy decisions.

-rick

---

From: Rick H Wesson <[email-masked]>
Date: Tue, 7 Dec 1999 18:05:57 -0800 (PST)

randy,

-rick

---

From: Kim Hubbard <[email-masked]>
Date: Wed, 08 Dec 1999 10:24:31 -0500

>does not justify the strict policy decisions.

Hmm, so you don't believe we should bother with aggregation of address
space?  You should come to an ARIN public policy meeting and propose
this..should be interesting :-)

Kim

---

From: Kim Hubbard <[email-masked]>
Date: Wed, 08 Dec 1999 10:24:31 -0500

Kim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Dec 1999 11:58:30 -0600

Rick,

I suspect you didn't read the important bit.

> > it's not the memory.  it's the processing power required which is quite

This is not to do with operational accidents. It's to do with generic growth.

However, we should also engineer our systems to be robust during
operational accidents.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Dec 1999 11:58:30 -0600

Rick,

  Brian