ALLOCATED-BY-LIR in the RIPE Database: What It Means

An inet6num object with status: ALLOCATED-BY-LIR is a registry statement about how IPv6 address space has been delegated inside the RIPE Database hierarchy. It is useful evidence, but it is easy to read more into the status than the database actually says.

The short version

ALLOCATED-BY-LIR records a sub-allocation made by a RIPE NCC member from its allocation to another organisation.The other organisation may take over some management of that sub-allocation, while the member remains responsible for the registered resources and retains technical control under the RIPE Database model. More-specific assignment objects still need to be documented beneath the sub-allocation as applicable.

The status by itself does not tell you whether the resource is leased, sold, provided at no separate charge, bundled with another service, or governed by any particular commercial contract. It also does not prove that the prefix is currently routed on the Internet.

Where it sits in the RIPE IPv6 hierarchy

Common IPv6 status values and the question each one answers
Status	Typical meaning	What to look at next
ALLOCATED-BY-RIR	RIPE NCC allocation to an LIR or other qualifying holder under the applicable policy.	Holder organisation, parent allocation size and maintainer relationships.
ALLOCATED-BY-LIR	Sub-allocation created by an LIR for a downstream organisation that may need to make further assignments or allocations.	Downstream organisation, `mnt-lower`, child objects and routing records.
AGGREGATED-BY-LIR	An aggregate representing multiple customer assignments of a declared assignment size.	`assignment-size`, intended customer model and responsible contacts.
ASSIGNED	An assignment to an End User or End Site for the registered use.	Assignee, contacts, routing requirements and whether further assignment is permitted.

A simple parent-child example

2001:db8::/29          status: ALLOCATED-BY-RIR
└── 2001:db8::/32      status: ALLOCATED-BY-LIR
    ├── 2001:db8:1000::/48  status: ASSIGNED
    └── 2001:db8:2000::/36  status: AGGREGATED-BY-LIR

In this example, the /29 is the upstream RIPE allocation and the /32 is a downstream sub-allocation. The /32 can contain more-specific objects that document how the downstream network uses or delegates the space.

What ALLOCATED-BY-LIR does prove

The object is registered as a sub-allocation beneath an upstream allocation in the RIPE Database.
The object has a specific prefix, organisation/contact context and maintainer relationships recorded in the database.
The downstream arrangement is intended to support further registration beneath that sub-allocation.
The RIPE NCC member remains responsible for the registered resources above the sub-allocation and retains technical control of its allocated address space.

What it does not prove

It does not prove a paid lease. Commercial terms are outside the RIPE Database status field.
It does not reveal price or commitment. Monthly price, contract term, deposits and cancellation rights are contractual matters.
It does not prove ownership transfer. Registry status and commercial rights are separate questions.
It does not prove current BGP use. A registered inet6num object can exist without an active route.
It does not identify the current origin ASN by itself. Check routing data, route6 objects and RPKI separately.
It does not prove utilisation. Child objects and routing observations can provide clues, but neither alone establishes actual customer or address usage.

Do not confuse registry objects with routing evidence

The RIPE Database and the global routing table answer different questions. An inet6num object describes registered address-space information. A route6 object is an Internet Routing Registry record linking a prefix to an origin ASN. An RPKI ROA authorises an origin ASN for a prefix and prefix length. Observed BGP data shows what networks are actually announcing.

These sources should agree for a clean deployment, but one should not be treated as a substitute for the others. A route description or stale mirror should also not override a current RIPE Database object when the question is registry status.

A practical verification sequence

Start with the current RIPE Database objectConfirm the exact prefix, status, organisation, maintainers and parent allocation.
Inspect the parentVerify which RIPE allocation contains the prefix and which LIR sits above it in the hierarchy.
Check the downstream organisationDetermine whether the recipient is itself a RIPE NCC member/LIR or another type of operator.
Inspect child objectsLook for ASSIGNED, AGGREGATED-BY-LIR or further ALLOCATED-BY-LIR objects that show how the block is being registered downstream.
Check route6 and RPKICompare the intended origin ASN and prefix length with IRR and ROA data.
Check observed BGP separatelyUse independent routing data to see whether the prefix is currently announced and by which ASN.
Keep commercial conclusions separateOnly a contract, invoice, provider statement or equivalent evidence can establish commercial terms.

Why this distinction matters

If you are assessing IPv6 supply, competitor inventory or a potential upstream relationship, treatingALLOCATED-BY-LIR as shorthand for “paid lease” can lead to bad conclusions. The registry tells you that a downstream sub-allocation exists. It does not tell you why it exists commercially.

The same caution applies in the other direction: seeing a prefix originated by a particular ASN does not, by itself, establish who supplied the resource or what contractual relationship exists behind the route.

Official RIPE references

Related ELISTEKA guides

For deployment work, continue with the IPv6 routing checklist or review how a RIPE IPv6 /32 lease is onboarded.

If your network needs a RIPE IPv6 /32, see the current ELISTEKA /32 offer.