FAQ: Sub Allocation
- What is SUB-ALLOCATED PA space? →
SUB-ALLOCATED PA is a new value which can now be put into the "status:" attribute of an inetnum object. Prior to this new "status:" value, inetnum objects could only have the "status:" attribute ASSIGNED PA, ASSIGNED PI, ALLOCATED PA, ALLOCATED PI , EARLY REGISTRATION OR LIR-PARTITIONED.
This new value allows RIPE Database users to identify an IP range from a Local Internet Registry (LIR) allocation that has been delegated to a customer or reseller. Ranges within a sub-allocation can then be assigned to downstream networks. Overall responsibility for the address space remains with the LIR.
- When should the SUB-ALLOCATED PA "status:" value be used? →
Sometimes LIRs need to distribute part of their allocation to customers or resellers and allow maintenance of those ranges by their downstreams. The new "status:" value allows the LIR to create a more specific level object with the customers or resellers maintainer(s) mnt-lower. By doing this, it allows the resellers to administer assigned inetnum objects under the sub-allocation, without giving them control over the whole LIR allocation.
- How is such an object created in the RIPE Database? →
In the same way as an assigned inetnum object is created, except the "status:" value, SUB-ALLOCATED PA is used instead of ASSIGNED PA or ASSIGNED PI.
- How many IP addresses can we sub-allocate? →
There is no limit on how much address space can be sub-allocated.
- How can I protect SUB-ALLOCATED PA objects? →
inetnum objects with the SUB-ALLOCATED PA "status:" use the same attributes as inetnums, therefore they must be protected by a valid maintainer, i.e. mnt-by. Hierarchical authority for SUB-ALLOCATED PA address space can also be specified in the "mnt-lower" and "mnt-routes" attributes.
As LIRs are responsible for all objects within their allocated ranges, it is important they take appropriate steps to ensure they retain some control over the sub-allocated space. We recommend that LIRs ALWAYS EXCLUSIVELY retain mnt-by: of sub-allocations. This will ensure that the address space is not kept by a downstream network if the reseller ceases to receive connectivity from the LIR's network.
When creating a more-specific object under a SUB-ALLOCATED PA object (a route object for example) the hierarchical structure of authorisation will apply to the maintainer(s) of the SUB-ALLOCATED PA object before checking with the maintainer(s) of the ALLOCATED object.
- Can these sub-allocation objects be created by the user/reseller/downstream provider? →
No. Normally only the LIR will have the password for the mntner in the mnt-lower attribute of the allocation inetnum object, and so the LIR should create and maintain sub-allocation objects. When an LIR keeps their mntner in the mnt-by of an object, they retain control over an object. This may be useful to ensure that the address space is not retained by a downstream network if the reseller ceases to receive connectivity from the LIRs network. In addition, the LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community’s policies. Sub-allocations cannot be further sub-allocated by user/reseller/downstream providers.
- What about assignment objects within the sub-allocation? Who makes these; the LIR or the user/reseller/downstream provider? →
You can add your downstream operator's maintainer in the mnt-lower: of the SUB-ALLOCATED PA object, which will allow them to make these assignments themselves. The LIR is always responsible for all objects within its allocated range, so it is recommended that LIRs have contracts that require downstream network operators to follow the RIPE community’s policies when those operators have sub-allocations.
- Do I have to seek approval from the RIPE NCC before entering a SUB-ALLOCATED PA object into the RIPE Database? →
No, it is your space to sub-allocate as you see fit. Responsibility for errors and problems arising from the use of SUB-ALLOCATED PA remains entirely with the LIR concerned.
- Can I use the SUB-ALLOCATED "status:" value in an inet6num object? →
No, SUB-ALLOCATED status is only for IPv4 inetnum objects. However, sub-allocations are possible in IPv6. The status values for inet6num objects are:
* ALLOCATED-BY-RIR - For allocations made by a Regional Internet Registry (RIR) to an LIR.
* ALLOCATED-BY-LIR - For allocations made by an LIR or an LIR's downstream customer to another downstream organisation.
* ASSIGNED - For assignments made to End User sites.
- How often can I make a sub-allocation? →
As often as you need to make them. However, it is recommended that LIRs make use of a slow-start mechanism when making a sub-allocation for a downstream network operator. There are two main advantages to this: the LIR can ensure that the address space it sub-allocates is used efficiently; the LIR can also determine the ability of the downstream organisation to operate within the policies set by the RIPE community.
- Is there a limit to the number of my downstream providers to which I can make the sub-allocation? →
No. However, the slow-start suggestion applies here as well. Please read the SUB-ALLOCATION policy for further details.
- Can I sub-allocate to myself? →
No. This is why the status value LIR-PARTITIONED PA exists. Please see our LIR-PARTIONED FAQ.
Current policy states: “LIRs may make sub-allocations to multiple downstream network operators”.
- Do sub-allocations have to be registered as inetnum objects in the RIPE Database? →
Yes, sub-allocations should be registered. This will allow the RIPE NCC to accurately determine how much space is in use when evaluating additional allocation requests.
- Can an entire sub-allocation be assigned? →
No, as the range is the primary key, you can't have two inetnums in the database with the same range
A reasonable assumption that LIRs might make is that if they sub-allocate a /24, they can (eventually) assign the same /24. However, since the sub-allocation and the assignment objects would have the same range, LIRs or downstream providers can only assign (sub-allocated range -1) as the largest possible assignment in the sub-allocation.
- Can one customer get more than one sub-allocation from the same LIR? →
Yes, customers can recieve more than one sub-allocation from the same LIR.
- Can a customer get sub-allocations from more than one LIR? →
Yes, customers may receive sub-allocations from more than one LIR.