With the acceptance of this proposal RIPE NCC will run a one-time operation to allocate an IPv6 block to every LIR that does not have any existing IPv6 holdings. http://www.ripe.net/ripe/policies/proposals/2008-02.html
I'm concerned with the way that this policy is worded. First, it has the same impact as saying that any LIR with IPv4 resources is exempt from 5.1.1 c) in RIPE 421 which says that you must have a plan to sub-allocate IPv6 addresses in order to justify an IPv6 block. This has the effect of raising the barrier to entry for organizations which do no currently have IPv4 allocations, i.e. the criteria for new entrants is stricter than for current RIPE members. Second, some of the organizations receiving these /32 blocks would be able to justify much larger blocks. We got a /22 last year for instance. It seems to me that it would be nicer to offer LIRs an IPv6 block rather than automatically allocating one. If an LIR might be able to justify a larger allocation than /32, then the offer could explain how to do that. This issue here is one of communication. If you simply allocate an IPv6 block but do not clearly communicate this to the LIR (including acknowledgement from the LIR) then you are simply making meaningless entries in a database. The LIR will never use the block and in the next two or three years they will submit another application, or else swamp the RIPE help desk with queries about this strange database object that they have discovered. I am generally in favour of this but I think it needs to be fair to all organizations by removing the condition in 5.1.1 c) in RIPE 421 and it needs to begin by engaging the LIR to ensure that they understand that a /32 is about to be allocated, and they are ready to accept the allocation. The process of allocation is much more than making a database entry. Communication with the LIR and acknowledgement of the LIR are necessary in order to allocate an address block. --Michael Dillon