64/2 allocations?

Tue Jun 10 15:40:08 UTC 1997

This message is rather dated (LA IETF), but I haven't seen anything lately
on the same topic, nor do there seem to be any relevant RFCs; could anyone
perhaps point me to more recent discussions and/or plans to implement the
below scheme?

Does anyone have projections on when 192/3 will actually be exhausted at
the current allocation rate?

Does anyone believe the opening of 64/2 (or more likely, a segment thereof)
will cause a change in allocation policies or routing filters?

Is anyone aware of any problems with current equipment in the major
providers that would preclude the deployment of 64/2 CIDR blocks?

Has anyone considered the possible effects of IP space being marked
"atomic"; that is, not allowed to be sub-allocated to another AS (and
therefore hopefully precluding route explosion).  Non-atomic allocations
could still be made from the 204/6 swamp to support multi-homing for ASes
not worthy of a /19 (or whatever the policy is today).

Stephen

>To: Michael Dillon <michael at memra.com> 
>     Subject: Re: Allocation of IP Addresses 
>     From: Paul Ferguson <pferguso at cisco.com> 
>     Date: Wed, 13 Mar 1996 19:15:44 -0500 
>     Cc: Jim Browning <jfbb at atmnet.net>, "'com-priv list'"
<com-priv at psi.com>, "'NANOG
>     List'" <nanog at merit.edu>, "'NIC Registry list'"
<nic-registry at internic.net> 
>     Sender: owner-nanog at merit.edu 

[snip]

>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]