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

Stephen, Stephen Sprunk writes:
Does anyone believe the opening of 64/2 (or more likely, a segment thereof) will cause a change in allocation policies or routing filters?
This happened already (although strictly 62/8 is not part of 64/2). RIPE is allocating space from 62/8. They have some special *temporary* guidelines: http://www.ripe.net/docs/ripe-155.html
Is anyone aware of any problems with current equipment in the major providers that would preclude the deployment of 64/2 CIDR blocks?
Check with the RIPE community on their experience so far. David K. ---

Check with the RIPE community on their experience so far.
Two extracts from the draft report of the Local Internet Registry Working Group meeting at RIPE 27 last month: - Started allocating from 62.0.0.0/8 More than 30 ranges allocated. Very few problems reported, have already seen some reverse delegation requests. - Use of the available what-used-to-called Class A space: ripe-155 is an extension of ripe-140, covers additional procedures developed for 62.0.0.0/8. A registry can have a class A and class C allocation at the same time, however you cannot have two class C allocations. (Can have two class A allocations) Miriam says the RIPE NCC already started allocating according to the procedures, there was discussion on the mailing list. The special guidelines are just temporary until the end of the year. She would like to hear if anybody has had problems, special experiences, etc. Cheers. Mike Norris
participants (3)
-
davidk@ISI.EDU
-
Mike Norris
-
Stephen Sprunk