[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrea Cima
andrea at ripe.net
Mon Oct 7 12:21:18 CEST 2013
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 > >
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]