North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical 64/2 allocations?
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 <[email protected]> > Subject: Re: Allocation of IP Addresses > From: Paul Ferguson <[email protected]> > Date: Wed, 13 Mar 1996 19:15:44 -0500 > Cc: Jim Browning <[email protected]>, "'com-priv list'" <[email protected]>, "'NANOG > List'" <[email protected]>, "'NIC Registry list'" <[email protected]> > Sender: [email protected] [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]
|