North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Allocation of IP Addresses

  • From: Paul Ferguson
  • Date: Wed Mar 13 21:10:10 1996

At 04:43 PM 3/13/96 -0800, Michael Dillon wrote:

>
>Here's an idea. Let new ISP's reserve large blocks (say /16's) in 65/8,
>66/8, .... but don't let them actually use these addresses on the global 
>Internet. Then, the ISP can run a Network Address Translation gateway and
>give their customers 65/8 addresses while still using a chunk from their 
>provider's block. And they can switch providers without forcing their 
>customers to renumber. Then, after they have demonstrated that they 
>should be given a /16, open up the block they were given in 65/8 for use 
>without the NAT.
>

Well, I knew this topic would come up sooner or later, since it was
discussed briefly in LA/IETF at the CIDRD WG meeting(s).

A snippet from the LA/IETF CIDRD minutes:

[snip]

Yakov
Class A Allocation Guidelines
=============================
Motivation
Observation 1: 192/3 is 1/8 of the total IPv4 unicast space
Observation 2: 64/2 is 1/4 of total IPv4 unicast addrses space
Hypothesis1: at some point we will exhaust 192/3
Hypothesis2: at some point we will need to allocate out of 64/2
Observation3: It appears safe to allocate out of 64/2 based
on experience documented in RFC???? on Class A Experiment

Recommendation
allocation of /17 or larger should be done out of 64/2 
allocation of /18 or smaller should be done out of 192/3

Comments?
Randy: Do you mean start this now?
YR: No, only when we decide it necessary.

Eliot Lear: Can big ISPs get bigger blocks?
YR: Yes, it should allow them to.
EL: Do we need to advise Registries?
EL: Should 192/3 be declared unroutable?
YR: Perhaps part of it.
BManning: I would like to attach a rider on this.
I think before anyone gets anything out of 64/2 that they
should agree to give back their old blocks.
TonyLi: Is there some reason not to start alloc 64/2 immediately?
YR: We don't have to yet, so perhaps we should not.
TonyLi: Pressure from international carriers to get large blocks.
ELear: We should wait as long as possible to age legacy systems.
Tony: There weren't any big problems in the RFC.
BManning: Some things were not tested. Only routing protocols were tested.
We couldn't figure out a reliable way to test interior routing.
We should hold off a little longer before we jump into this.
NoelChiappa: We can't get rid of all the legacy systems. Is the
cost of hurting the legacy equipment less than the benefit of 64/2.

[general discussion of when we should implement this. Now or 
wait a little longer for legacy systems to expire.]
[discussion of route-able v unroute-able prefixes. Will certain
prefix ranges be declared unroute-able in future?]
MKosters: @home has a /14 out of net 24, so we have already
allocated out of Class A.

BrianC: Suppose IANA decides to do this, and some joe-ISP
asks for a /14. We haven't given the Registries any guidance
on how to allocate.
RConrad: Policy most likely to remain the "power of 2" increase.
The size of the ISP is irrelevant with this scheme.
Cathy of @home complained that Sean won't take 24/14 only 24/8.
Sean Doran raised the issue of charging for prefixes.

Tony advised we leave this for further discussion on the mailing list.

[snip]

- paul