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.
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*
Tore Anderson wrote: 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.
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
Nick Hilliard wrote: 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