Iljitsch, While your comments do not address the policy proposed on the ARIN list there are some elements in your comments that may be relevant to the discussion on the ppml. I will soon forward it. In regard to your comments I have an observation with regard to the amount of IPv4 address space that has been allocated to the RIRs. It is worth noting that the RIRs have not been allocated "around 220" /8s. In fact, the vast majority of IPv4 address allocations pre-date the formation of the RIRs. These allocations were either made by the Central Registry (94 /8s) or the IETF (32 /8s*. This is the old classful D and E space. Some may choose to consider the old classful E space as an IANA reserve). The RIRs have had 50 /8 blocks allocated to them by the IANA. This is just under 20% of the total IPv4 address space. Ray
-----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] Sent: Friday, August 20, 2004 8:38 AM To: Ray Plzak Cc: <address-policy-wg@ripe.net>; <ipv6-wg@ripe.net> Subject: Re: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation
On 20-aug-04, at 14:01, Ray Plzak wrote:
Wilfried,
I've forwarded your comment to the ARIN ppml.
Ray, as long as you're forwarding, maybe you'll find my comment to the RIPE list from a week and a half ago of interest:
The Number Resource Organisation (NRO) has published a proposal for a policy for the allocation of IPv6 address space from the IANA to the RIRs. It is intended that this proposed policy should be agreed by all RIRs' open policy fora and then approved by the ASO and ICANN as a global policy.
Reserving a /6 for each RIR seems like the other extreme to me. In IPv4 we have around 220 /8s that have been given out to RIRs pretty much one at a time in the past. In IPv6 we effectively have 8 /6s. This means that as a percentage of total available space, the RIRs get more than 25 times more IPv6 space than they've been given IPv4 space in the past, even though a v4 /8 will accommodate at most 16.8M end-user assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T (yes, that's 10^12) end-user assignments.
Now I can see SOME value in trying to have relatively large RIR blocks, but cutting up all non-reserved space so aggressively really doesn't have any upsides, and we never know whether we're going to need any really large blocks in the future. Also, doubling every time is ok for a while, but it pretty much guarantees that you're going to have way too much space on your hands at some point.
A more reasonable policy would be:
- reserve a /12 for each RIR now (a 4 bit boundary makes DNS delegations easier, I think a /8 is too much but that might work also) - then, for every delegation, give RIRs enough space to each to last a year comfortably - evaluate whether a new delegation is needed every 3 or 4 months, making the time of new delegations easy to predict