[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)

Hi All,

On 10/6/13 2:39 PM, Elvis Velea wrote:

>>> 5.1.2 Initial Allocation Size
>>> Allocations made by the RIPE NCC to the LIR have a minimum 
>>> allocation size of a /32 and may be up to a /29 with no additional 
>>> documentation required.
>>> Allocations made by the RIPE NCC to the End User have a minimum 
>>> allocation size of a /32.
>> RIPE NCC reserves a /29 for every /32 allocation, right?

The RIPE NCC reserves three bits for each allocation. This is due to historical reasons as, according to policy, the RIPE NCC had to reserve a /29 for each LIR. /32s (and their reservations) are made using the sparse allocation method.


>> So even End Users would "occupy" a /29 even if many of them would
>> forever be satisfied with a /48?
>> This is god news for the routing table as only prefixes size are going
>> to change if End Users grow their networks. (Unlike in IPv4, were
>> grows often implied new routes popping up).
>
> Well, the RIPE NCC reserves two or three extra bits. So, if you get a 
> /48, they will reserve a /45, 

We currently reserve two bits for IPv6 assignments, which is done on the basis of availability. According to the policy: "When possible, these further assignments will be made from an adjacent address block."

http://www.ripe.net/ripe/docs/ripe-589#IPv6_PI_Assignments


Best regards,
Andrea Cima
RIPE NCC



> if you get a /32, they reserve a /29, if you get a /29, they will 
> reserve a /26.
>
> And indeed, the growth of the routing table will be kept low if every 
> time someone will need an additional allocation, the RIPE NCC will 
> just extend the current one with 1-3 bits.
>
> Additionally, if someone will specifically ask for a /48, the RIPE NCC 
> will continue making the small allocation and the 2-3 bits 
> reservation, it's not like.. whenever you ask for a /48 the RIPE NCC 
> will reserve a /32 or /29.
>
>>
>>
>> Elvis Velea wrote:
>>> Creating different levels/limits will complicate the policy again 
>>> and our aim was to make it as simple as possible.
>> I like the proposals simplicity and I support the proposal from what I
>> have read so far.
>
> I am glad, I see that the general feeling is that everyone likes it 
> for being simple and there are just a few comments, mostly on the same 
> topics.
>
> We have worked through a few iterations to get this proposal to be 
> this simple. Some things may still be fixed for the second version of 
> this proposal which I think will be published after we compile all the 
> feedback from this list and the RIPE Meeting.
>
>>
>> Tore Anderson wrote:
>>> Then you would have only one path and no confusion:
>>>    RIR[RIPE NCC] -> LIR -> End User
>> I would support this if there is a way to eliminate the distinction of
>> PI/PA in IPv4 too. In fact, with the initial proposal End Users are
>> becoming IR in the moment they hand out their first address to a
>> customer. The question is: How can we back off from those who *love*
>> their Sponsoring LIR for doing all the "international RIPE stuff" and
>> those who are eager to share some of their address space with
>> friends/neighbors/customers? There should not arise any new
>> requirement from a change like this for those who just want their
>> network numbered without having to deal with international contracts
>> but there should be new options for those who like to do IR things.
>> RPKI, for example, is something the more tech-savy End Users are
>> missing today.
>>
>
> It would be difficult, some End users still want to be independent 
> from a particular LIR, by having only one path, and after looking at 
> my crystal ball, I would see the following problems:
>
> a. RIPE NCC would allocate only to the LIR and the LIR could keep the 
> end user captive - stay in a contract with me or renumber your network
> b. LIRs may start to de-aggregate their allocations up to a level that 
> the global routing table may explode and we will really have nothing 
> to do against it
> c. we may see anti-competitive laws or such, because only LIRs will be 
> able to get addresses from the RIPE NCC and therefore, LIRs will be 
> able to make their own rules on who gets what. You may be forced to 
> become an LIR if you need addresses.
>
>> Nick Hilliard wrote:
>>> So how could you convince the existing ipv6 PI holders that the cost
>>> increase from €50/year to LIR membership fees would be worth it?
>> Speaking for me, not possible. Other small enterprises probably think 
>> the same.
>> I think we should provide some strong incentive to become a LIR
>> eventually. If the price jumps from 50EUR/yr to 1800EUR/yr business
>> will ask what it gets for the extra money.
>
> Forcing everyone to become an LIR is going to be difficult. We have 
> received some numbers from Andrea (thanks A.) and will propose some 
> different discussion points during the RIPE Meeting.
>
>>
>>
>> BTW, I suggest renaming End User to SIR (Sponsored Internet Registry).
>> A SIR could re-allocate its address space and/or just number their
>> enterprise network with it.
>
> During one of the iterations of this policy proposal I had the idea of 
> PIR (Portable Internet Registry). However, the idea was not very well 
> received by the co-authors.
>
> It's definition was supposed to be:
>
> "A Portable Internet Registry is an IR which can request (via a 
> Sponsoring LIR) an allocation from the RIR. The PIR sub-allocates 
> address space to the users of the network services that it provides. "
>
> Considering the current feedback, I think we do need to define the 
> additional layer we add to the chain.
>
> The PIR or SIR may not be good enough. If we do define the SIR/PIR, 
> what do we do with the entity receiving a sub-allocation from an LIR, 
> this entity will also be allowed to sub-allocate based on the proposed 
> policy. What would we call that entity then?
>
> cheers,
> elvis
>
>