Hi, I think this is a very useful proposal. Several of our customers are ISPs themselves and intends to become LIR when they have utilization of a /22. Until then the procedure for registering their assignments is a bit complicated, the main problems are that we cannot let our customer take care of the administrative part - we have to be in contact with their customer and when allocating/reserving an IP net for the customer, we get a problem when requesting a new allocation from Ripe (80% rule).
Proposal:
- permit LIRs to sub-allocate the address allocation they receive from a RIR to "downstream parties", from now on called sub-LIRs
- the Sub-Allocations are documented as an inetnum: object with "status: SUB-ALLOCATED PA" in the RIPE database. I do not like "LIR-PARTITIONED", because it isn't partitioned ("equal parts"), and also because it doesn't go far enough.
I also believe "SUB-ALLOCATED PA" is more appropriate.
Points of Concern:
- "How big shall the sub-allocation be"?
The exact numbers for the default case would have to be defined.
Again, this is similar to the RIR->LIR case. A LIR by default gets a /20, but might get a bigger space in case it produces a good forecast that shows a reasonable need for a bigger space.
I propose to give a Sub-LIR a /24 to start with, except in cases that they show evidence for needing more. Rationale: it's not too much, and you can delegate DNS on /24 boundaries without ugly tricks.
When the Sub-Allocation is used up (= 80% of the space in there is ASSIGNED), the Sub-LIR can ask for more. If a customer asks for more space than the Sub-LIR has left, the Sub-Allocation can also be increased / a new Sub-Allocation be made.
As a starting point for the discussion, I propose:
- minimum size of a Sub-Allocation: /24 (because that's what's needed to be able to properly delegate the reverse DNS zone) - maximum size of a Sub-Allocation: 4x AW per year and sub-LIR (the number "4" here is of course open for discussion) - if a bigger size is required, go through NCC hostmasters
alternatively one could introduce a new "Sub-Allocation-AW", but that's even more bureaucracy.
In my oppinion it should be closer to a /22. If its only a /24 it has to be split into quite many subnets before its worth the effort of "setting up" a sub-LIR.. But I don't see much point in allocating a larger net than /22, if larger is needed and growth expected then it would be better to set up a normal LIR. Yes, a "Sub-Allocation-AW" might be an idea, but I think it should be a matter between the LIR and the sub-LIR, no reason to bother Ripe with this.
- "What's the size of networks a Sub-LIR can assign to their customers"?
It can not go over the AW of the LIR. This part is fixed due to the RIR/LIR relation.
As for the rest, I propose that this should be a matter between the LIR and the Sub-LIR. They have a contract, and it's the LIRs job to make sure that the Sub-LIR follows the official policies and procedures, maybe introducing their own Sub-AW per Sub-LIR etc.
The LIR acts as a RIR, so the sub-LIR sends ripe-219 applications to the LIR and the LIR approves according to AW, if the request is larger than AW it is forwarded to Ripe NCC hostmasters (just as normal IP requests).
Thoughts and Considerations from the RIPE NCC (Leo Vegoda):
1. How should the RIPE NCC act when a further allocation is requested if the existing allocation is not at "about 80%" usage (when used means valid assignments) - but "about 80%" is used in assignments and sub-allocations?
Answer: see above in the "Motivation" block. The idea is that Sub-Allocations are considered "usage", so if (for example) 40% is ASSIGNED and another 40% is SUB-ALLOCATED, 80% usage is achieved. What percentage of the SUB-ALLOCATED space is actually ASSIGNED is not considered.
So the answer is "if all other things are fine, a new allocation should be made".
It is envisioned that the NCC hostmasters are going to ask nasty questions if the percentage of SUB-ALLOCATED is "overly" high and the percentage of end-user assignments overall is "overly" low (exact values to be defined).
It would be a problem if specific percentages dictates if another allocation is possible or not, since their could be valid reasons for even extreme situations. But in general it might be prudent to go through the documented need for the sub-allocations when requesting a new allocation.
2. If the RIPE NCC should count a "sub-allocation" as used then should it take account of the degree of assignment in the sub-allocations? If so, what degree should be assigned from them?
Answer: I think that the number of end-user assignments made inside sub-allocations should not be a hard criterium (like the 80% rule). I do think that very low ratios should lead to nasty questions.
I do also think that this should be compared to the IANA/RIR level - if a RIR comes back to IANA because all /8s have been "used up" (by allocating to LIRs), IANA doesn't consider the actual usage ratio *inside* the allocations, as long as the RIR has been following its rules for "under which circumstances is it permitted to make an allocation, and which size is OK".
No, I don't think it would make sense if Ripe NCC had to go into the degree of assignments of a LIRs sub-LIRs when deciding to do another allocation. But again, its important that the sub-allocations are properly documented (and valid), that should instead be the criterium.
3. Should there be a maximum size an LIR can sub-allocate? If so, what size? (I know you've previously proposed a /24 as a default or minimum size).
Answer: see above (yes, but the exact number has to be decided upon).
I would think it would be better if the sub-LIR instead setup a normal LIR in case the need was larger than a /22, or would people prefer sub-LIRs with /20 allocations or larger? In my oppinion the sub-LIR status should only be temporary until the customers address utilization had passed /22.
4. Should holders of a sub-allocation be allowed to sub-allocate, too? This is allowed in IPv6. Should IPv4 be different?
Answer: I can see arguments for both sides - sub-sub-allocations might not really make sense in IPv4 (not enough bits to do so much hierarchy), but then, it might make sense in some networks.
I'd leave this one to the community for a decision.
No, in that case the sub-LIR would probably have a need of quite many addresses, and therefore it would be better to set up a LIR.
5. LIRs are contractually obliged to follow the RIPE community's policies. Is it possible to enforce any requirement for a holder of a sub-allocation to follow those policies, too?
Answer: The LIR has signed that it will obey all policies. So it would be part of those to enforce the RIPE rules onto the Sub-LIR as well (by an appropriate contract). This would have to be made very explicit in the "sub-allocation policy document".
It is the responsibility of the LIR that ALL assignments (also those from sub-allocations) are valid according to policies. A contract like the one between LIRs and RIRs might be a good idea between the LIR and the sub-LIR too.
6. If an LIR makes a sub-allocation this is presumably becasue it trusts the re-seller to administer the space responsibly and wants to delegate responsibility for the assignments. This implies that the LIR would place the re-seller's mnt-lower on the sub- allocation allowing the re-seller to assign without returning to the LIR. However, this would remove control over that portion of address space from the LIR. Would this policy require the reclaim attribute to be implemented in the Database?
Answer: this is something to be worked out with the database WG, but to avoid trouble with the RIPE DB entries when a Sub-LIR "goes away" without cleaning up their entries, this is considered useful.
Yes, I believe its necessary that the LIR can somehow overrule everything done in the Ripe DB by the sub-LIR. A few things I would like to add to this proposal: It might also be a good idea if the Ripe NCC keeps a record of all the sub-LIRs, especially if/when the sub-LIR decides to become a LIR. The sub-LIR should also be allowed to assign its own infrastructure within the sub-allocation. The Ripe-219 should as default describe whether its a LIR or a sub-LIR assignment. Some sort of fee for registering as a sub-LIR might be appropriated, at least to make sure not everybody suddenly wants to be sub-LIR! But maybe the decision should be made by the individual LIRs. I would assume that the LIR have to take care of all questions the sub-LIR might have regarding policies, RIPE DB entries and so on. If all future LIRs have first been sub-LIRs it should make it easier for the Ripe NCC hostmasters when setting up the LIRs and doing the first assignments. Med venlig hilsen/Best regards Christian Rasmussen Hosting manager jay.net a/s