Changes to RIPE NCC’s IP allocation policies can affect hosting providers, ISPs, and IT teams in its service region. Address planning matters when you launch new VPS nodes, on-board colocation customers, or bring a new application cluster online. IPv4 exhaustion makes address availability, costs, and the transition to IPv6 important planning concerns. In this article, we’ll examine allocation constraints and their implications for capacity planning, budgeting, and network design. We’ll also outline design and procurement considerations for hosting, VPS, dedicated server, and colocation deployments. Policy check: 4 November 2026. RIPE-826 (20 June 2024) and RIPE-807 (30 October 2023) both predate this article’s original publication on 25 December 2025. The separate additional-LIR-account restriction announced from 29 September 2026 is dated explicitly below.
RIPE NCC and IP Allocation Rules in a Nutshell
RIPE NCC is the Regional Internet Registry (RIR) responsible for managing IP address space and Autonomous System Numbers (ASNs) in Europe, the Middle East, and parts of Central Asia. It does not sell IP addresses; instead, it allocates them to members (LIRs – Local Internet Registries such as ISPs and hosting providers) under community‑approved policies. The RIPE community develops policy through an open process; the RIPE NCC implements it and maintains the registry.
These policies define:
- Who can receive address space (membership and eligibility)
- How much they can receive (allocation sizes and limits)
- Under what conditions they can use and transfer that space (justification, documentation, holding periods)
- How reclaimed space (returned or recovered IPs) is re‑distributed
RIPE NCC reached its last /8 in 2012 and announced exhaustion of its normal IPv4 pool on 25 November 2019. Recovered addresses can still be distributed in small amounts through the waiting list. The allocation and transfer sections below explain how that established constraint affects an address plan. Our explanation of IPv4 exhaustion and price dynamics provides related market context; use dated offers to assess current prices.
Why IPv4 Scarcity Matters for IP Allocation
Three separate planning issues matter: limited new IPv4 supply, the conditions for transferring existing resources, and the operational work required to deploy IPv6.
1. IPv4 scarcity is no longer theoretical. Hosting providers and ISPs can conserve IPv4 space by using NAT and load balancers to share addresses across services. The waiting list is supplied by addresses actually returned to or recovered by the RIPE NCC, after quarantine. A merger does not automatically release its company’s addresses into that pool; a registered transfer and a return to the registry are different events.
2. The IPv4 transfer market can affect incentives. The article on IPv4 address pricing covers market considerations. It does not establish today’s price or guarantee future increases. For a transaction, check the registered holder, resource status, transfer eligibility and current terms separately from the commercial price. A transfer rule alone does not demonstrate how market participants behave.
3. IPv6 needs an operational plan. More address space does not configure routing, firewalls, applications or client reachability. Consider dual-stack or IPv6-first designs against actual dependencies rather than assuming that a general allocation policy mandates one migration date. Our article on IPv6 adoption and infrastructure planning offers complementary context; published measurements must be read with their dates and methodology.
Key RIPE NCC IP Allocation Topics
The sections below distinguish current registry requirements from hosting design recommendations. Use the linked policy and procedure texts for an actual application. Allocation to an LIR, assignment to an end user, resource transfer and deregistration are separate processes with different conditions.
1. Small, Last‑Resort IPv4 Allocations
RIPE-826 section 5.1 specifies the size and eligibility for IPv4 allocations from the waiting list:
- The allocation is exactly one /24 (256 addresses). The sum of RIPE NCC allocations to one LIR is limited to 256 addresses; an LIR that has reached or exceeded that limit cannot apply again.
- The operational waiting-list guide requires the requesting LIR account to have received no previous RIPE NCC IPv4 allocation. Membership must be complete, the allocation must be used to make assignments, and the network must have at least one active element in the RIPE NCC service region.
- This is a limit on direct allocations under this policy, not a /24 ceiling on all holdings including transferred space. Additional needs may be addressed through existing inventory, an eligible transfer or an upstream service.
For you as a hosting or infrastructure customer, this means:
- New projects may not get “one public IP per VM” as a default assumption.
- Using reverse proxies, load balancers, and NAT can let multiple services share public IPv4 addresses.
- Prioritize public IPv4 capacity for services that must remain reachable by IPv4-only clients, such as HTTPS frontends, VPN endpoints, public APIs, and mail gateways. This does not necessarily require a dedicated IPv4 address for each service.
2. Waiting Lists and Reclaimed Address Space
Returned or recovered space can become available, but the source and destination of that space matter:
- Members may voluntarily return addresses; closure or deregistration procedures can also result in recovery.
- Recovered addresses undergo quarantine before reuse. A commercial acquisition does not itself put addresses into the waiting-list pool.
- RIPE-826 section 5.2 applies to returned space that RIPE NCC will reissue rather than return to IANA. Within that scope, returned IXP addresses go back to the IXP reserve. Other returned blocks of /24 or larger follow the general allocation rules; smaller blocks enter the IXP pool.
All eligible requests are placed on a first-come-first-served waiting list. The official waiting-list guide explains submission through the LIR Portal and queue statistics. There is no guaranteed waiting time; a /24 can be issued only if and when sufficient contiguous space is available.
Operationally, this introduces uncertainty for smaller networks that do not already have IPv4 space. For hosting customers, the implication is simple: you should not base a new product launch on the assumption that fresh IPv4s will suddenly become available. Plan with what is realistically on the table today, not with hypothetical future allocations.
3. Justification and Documentation
Do not treat every IP operation as a newly tightened, needs-based request. RIPE-826 gives the waiting-list /24 criteria above; assignments have registration and validity requirements; IPv6 uses its own allocation criteria. Transfers from certain other RIR regions can require a specific use plan, as described below.
- LIR IPv4 assignments must be registered individually or using the permitted AGGREGATED-BY-LIR status. An audit must be supported by statistics of the individual assignments in those aggregated objects.
- An assignment remains valid while its original criteria remain valid and it is properly registered. Changed criteria must be documented; incorrect original information affects validity.
- Light use does not automatically mean every allocation will be seized. Policy compliance, valid registration, contractual duties and applicable closure/deregistration procedures are distinct from a provider’s capacity targets.
When choosing a hosting provider, consider these address-management practices separately from RIPE policy requirements:
- A documented process for requesting larger IPv4 ranges for dedicated servers or colocation racks, including any required usage information.
- Options for shared IPs with SNI‑based HTTPS and HTTP reverse proxies, including for containerized workloads, instead of one‑IP‑per‑site designs.
- Clear AUPs (Acceptable Use Policies) covering activities such as mail sending, to help protect the reputation and continued usability of shared IP ranges.
4. Transfer Rules and Holding Periods
RIPE-807 governs eligible whole or partial resource transfers. Allocated resources may be transferred only to another RIPE NCC member; PI resources can also use an eligible sponsoring relationship. Commercial agreement, registry registration and the customer’s service contract should each be checked.
- 24-month restriction: scarce resources such as IPv4 and 16-bit ASNs cannot be transferred for 24 months from receipt by the current holder. This also applies when received through a merger or acquisition, but it does not prevent a further transfer due to a merger or acquisition during those 24 months. Do not generalize this period to all IPv6 or ASN resources.
- Other restrictions: Under RIPE-831 section 3.5, once an existing time restriction has expired, subsequent transfers between LIR accounts held by the same member do not start a new restriction. Resources that policy requires to be returned, or resources subject to a voluntary transfer lock, must be assessed separately. Check the applicable procedure and lock conditions.
- Registration: transfers must be reflected in the RIPE Database. The original holder remains responsible until completion; for a temporary transfer, responsibility returns when the resource is returned.
- Inter-RIR: the other region’s policies also matter. For incoming transfers from a region requiring needs-based policies, RIPE NCC requires a plan to use at least 50% of the resources within five years. This is not a blanket requirement for every transfer within the RIPE region.
For hosting customers, two practical checks follow:
- For IP space included with long‑term colocation or dedicated server contracts, review address-continuity terms, renumbering obligations, and notice periods. A transfer holding period alone does not guarantee continued access to those addresses.
- Before planning an IPv4 transfer, confirm the applicable holding period and the block’s eligibility rather than assuming it can be transferred immediately.
If you are interested in how another region handles similar issues, our article on ARIN IP allocation changes and their operational effects offers a useful comparison. Additional LIR accounts are a separate membership matter. The current membership page says that, from 29 September 2026, existing members are temporarily restricted from acquiring additional LIR accounts until further notice; existing multiple accounts do not have to close. Read that dated notice before the page’s older general instructions for additional accounts. The /24 limit applies per LIR account and should not be restated as a universal historical ban on multiple accounts.
5. IPv6 Allocation and Deployment Planning
RIPE-738, published on 16 March 2020, has separate IPv6 criteria. A large allocation supports hierarchical address planning, but neither allocation nor a registry entry proves that the service is reachable.
- To qualify initially, an LIR must plan to make sub-allocations and/or End Site assignments within two years. Eligible LIRs can receive /32 through /29 without additional size justification; a larger allocation requires supporting documentation.
- End Site assignment size is a local LIR/ISP decision using multiples of /64. /48 and /56 are possible planning choices. Assignments larger than /48 to one End Site, or additional assignments exceeding /48 in total at that site, must be justified by address usage or different routing requirements for additional assignments.
- Keep address policy and training separate. The article on RIPE NCC IPv6 training is a learning resource, not a substitute for allocation criteria or a provider’s product specification.
For a new platform, assess IPv6 support early and preserve the IPv4 access required by current users and integrations. Dual-stack keeps both protocols; it does not automatically release public IPv4 addresses. Any consolidation, translation or IPv6-only segment needs a separate compatibility and capacity design. Verify product and location support with the provider rather than assuming every DCHost service follows the same architecture.
What the Policies Mean for Hosting and Colocation
Most hosting customers obtain addressing through their provider rather than opening their own LIR. Other direct or sponsored resource relationships also exist. The practical effects depend on the provider’s inventory, contract, product and location; registry policy does not set a universal retail IP price or prescribe one hosting architecture.
1. Public IPv4 Becomes More Selective and Valuable
When comparing offers, check how the provider handles these possible choices and constraints:
- Per‑IP pricing or tight limits on how many IPv4s each VPS or dedicated server can have.
- Options for shared IPs for web hosting using SNI and reverse proxies; verify the required HTTP/2 or HTTP/3 support separately.
- Availability of reverse proxies and load balancers that terminate connections on a smaller pool of public IPs while fan‑out occurs over private RFC1918 or ULA space.
In concrete terms, if you previously received multiple IPv4s for “just in case” scenarios on a VPS, now you may be asked to justify extra addresses, or be guided towards solutions that use one IPv4 plus IPv6 and internal networking instead.
2. Plan IPv6 Readiness Around Real Services
IPv6 readiness can expand your deployment options. Match the rollout to client support, product availability and the sensitivity of each service:
- Confirm IPv6 connectivity, prefix size, routing and support for the selected VPS, dedicated server or colocation location.
- Configure intended public services for IPv6, while keeping databases and administrative tools within their existing private/VPN access boundaries.
- Test external IPv6 reachability, TLS, authentication, firewall behavior and monitoring before publishing the relevant AAAA record. Retain A records where IPv4 reachability remains required.
If you are unsure how to start, our IPv6 setup and configuration guide for your VPS server walks step‑by‑step through enabling IPv6, updating firewalls, and testing reachability.
3. Network Design Shifts: NAT, Proxies and Private Addressing
To reconcile limited IPv4 allocations with growing demand, providers lean on several technical tools:
- Layer‑7 reverse proxies (Nginx, HAProxy, etc.) in front of web and API servers.
- Carrier‑grade NAT (CGNAT) or custom NAT gateways to multiplex many internal endpoints behind a few public IPv4s.
- Private overlay networks (VPNs, mesh solutions, or VXLAN‑based fabrics) to connect internal services without consuming public IPs.
These are design options with trade-offs. NAT creates state and port-capacity requirements; reverse proxies add TLS processing, trust-boundary and availability concerns. Test application protocols, inbound access, original-client information, failover and logging. Private addressing is not access control. IPv4 NAT alone does not connect an IPv6-only client to an IPv4-only service; an appropriate translation or proxy design must address that requirement separately.
4. Contract Terms and Address Continuity
Stable addresses are a service requirement to document. A registry holding period does not guarantee that a customer can retain a particular range. Review:
- The address capacity and reservation terms across the period covered by the contract.
- Notice, return and renumbering obligations, including migration assistance and the responsibility for allowlists and DNS changes.
- The resource status: PA assignments/sub-allocations must be returned and renumbered when changing the issuing provider; do not assume they are portable PI space.
Payment gateways, VPN concentrators and partner APIs may depend on long-lived allowlists or endpoint addresses. Record those dependencies before a transfer or provider move, agree the migration sequence and validate both old and new paths. Provider planning and source reputation are useful checks, but neither a long contract nor a 24-month restriction makes a service immune to interruption.
Provider Checks and Your Own IP Operations
The following practices are useful evaluation criteria for DCHost or another hosting provider. Confirm what is actually included in the product, location and support agreement. They are not claims that every provider already performs these tasks or that a registry policy mandates the same commercial service.
1. Proactive IPv4 Capacity Management
Maintain or request an address inventory by product and region. For each pool, distinguish:
- Documented utilization targets and the purpose of operational reserves; investigate idle assignments without assuming all unused space is improper.
- Reserved buffers for growth of existing customers, with explicit reservation and notice terms rather than a guarantee against renumbering.
- Reputation monitoring on mail and web ranges, because clean IP space is too valuable to risk with abuse.
Compare active assignments, unassigned capacity and disaster-recovery reservations before reclaiming anything. Check DNS, logs, partner allowlists and ownership records; an apparently quiet IP may still have a purpose. Any reuse or return must respect its resource status, customer agreement and safe migration process. There is no standard percentage of addresses an audit is guaranteed to recover.
2. IPv6‑First Network and Product Design
For an IPv6-ready platform, verify these items with the responsible team:
- The IPv6 addresses or prefixes included alongside any required IPv4 service.
- Upstream and return-path routing, firewall behavior and product/location support.
- Documented configuration, external reachability tests, AAAA publication sequence and rollback.
Our resource on IPv6 adoption and network planning provides further context. Performance, security and availability depend on routing, implementation and workload; IPv6 is not automatically faster or safer. Include monitoring, staff training and dual-stack operating cost in the decision.
Evaluate options such as:
- Reverse‑proxy setups where multiple sites share a small public IP pool cleanly via SNI and proper TLS.
- Private network segments for microservices, databases, and internal admin tools that do not need public addresses.
- Mail architectures (including dedicated sending IPs where justified) that separate reputation and throughput needs; dedicated addresses alone do not guarantee deliverability.
The article on infrastructure planning under IPv4 exhaustion discusses related choices. Consolidation can reduce address consumption, but shared failure domains, abuse reputation and application compatibility must be tested. Choose the smallest suitable public address footprint without removing necessary isolation.
4. Supporting Your Own LIR or IP Strategy
If you operate your own LIR or hold independent resources, document how the hosting or colocation service will connect to your registry responsibilities. Confirm feasibility and fees before ordering; possession of an ASN or prefix does not by itself provide BGP transit or provider support.
- Agree the routing, transit and peering scope and which prefixes/origins the provider will accept.
- Keep resource registration and the required IRR route/route6 objects consistent with actual routing. Verify the abuse-c role and inherited coverage; each smaller IP object need not have a separate contact.
- Coordinate ROAs and ROV separately. A ROA authorizes an origin ASN for a prefix and length; it neither creates the BGP announcement nor forces every network to filter. ROV does not validate the entire AS path or provide DDoS mitigation.
- Identify who maintains registration, rDNS, contacts, routing filters and transfer paperwork. A transfer changing the organisation/certificate can require ROAs to be recreated; plan the routing transition.
Our article on RIPE NCC services and IP infrastructure explains related registry and operational functions. Use that division of functions to assign registry, upstream-network and customer-application responsibilities in the implementation plan. Check who can change each record, how routing changes are approved and how the result will be monitored.
Practical Action Plan for IPv4 and IPv6
Whether you run a single high‑traffic site or a portfolio of SaaS products, the way RIPE NCC allocates IPs should influence your roadmap. Here’s a practical action list you can start on this quarter.
1. Inventory and Classify Your Current IP Usage
Begin with a simple but honest snapshot:
- List every public IPv4 you use, grouped by function: web frontends, APIs, VPNs, mail, monitoring, etc.
- Mark addresses that are under‑utilized (for example, a single test site on an otherwise empty IP).
- Check which services already have IPv6 enabled and which are still IPv4‑only.
This inventory allows you to see where you can consolidate, dual‑stack, or redesign to fit into a future where new IPv4 allocations from RIPE NCC will be minimal.
2. Dual‑Stack Public Services Wherever Possible
For every Internet‑facing service (web, API, mail, VPN, SaaS endpoints), ask:
- After successful external IPv6 testing, does DNS publish the appropriate A and AAAA records for the intended service?
- Is the application actually listening on IPv6 on the server side?
- Are firewalls and security groups enforcing the intended access policy for both protocols, including necessary ICMPv6 behavior?
Dual-stack preserves IPv4 compatibility while providing an IPv6 path for capable clients. It does not automatically reduce your public IPv4 count or eliminate bottlenecks. Measure each protocol’s connection success, latency and errors independently, and keep nonpublic databases and management endpoints inside their existing access boundaries.
3. Refactor One‑IP‑Per‑App Designs
If you have an older pattern where every site or application received its own public IPv4, evaluate whether consolidation meets the actual service requirements:
- Introduce a reverse‑proxy layer (Nginx, HAProxy, or a dedicated load‑balancer) that terminates TLS and routes requests based on hostname or path.
- Move backend apps and databases to a private subnet reachable only from the proxy or a VPN.
- Reserve dedicated IPv4s only for roles that have clear, justified requirements (for example, separate mail‑sending pools or partner‑facing IP allow‑lists).
A proxy can centralize logs and policy, but it can also become a capacity limit or single failure point. Test health checks, failover, request limits, client identity and TLS under the expected workload. Confirm that private backends are reachable only by intended components. Address conservation and application security should both be acceptance criteria, not assumed outcomes.
4. Budget Realistically for IPv4 and Plan Growth on IPv6
Given RIPE NCC’s limited allocations and the active IPv4 transfer market, you should treat IPv4 like any scarce resource:
- Compare dated per‑IP prices, transfer costs and renewal conditions; do not assume a permanent upward price trend.
- When comparing hosting offers, focus on total cost of ownership including IP addresses, not just raw CPU and RAM.
- Align growth plans (new regions, new products, white‑label offerings) with IPv6‑first designs, retaining IPv4 where client or partner compatibility requires it and budgeting for IPv6 operations.
Our guides on optimizing hosting costs with proper VPS sizing and bandwidth planning complement this address-planning work: both push you to think holistically about resources instead of chasing the cheapest sticker price.
5. Talk to Your Provider Before You Hit a Wall
The worst time to discover that IPv4 is constrained is the week before a big launch. Instead:
- Share your 6‑ to 12‑month roadmap with your hosting provider, especially if you expect major user growth or new products.
- Ask about IPv6 readiness for all relevant services: CDN integration, WAF, DDoS protection, mail, VPN, and logging.
- Discuss multi‑server or multi‑region architectures that distribute load intelligently instead of just adding more IPv4‑heavy nodes.
Before ordering, record the provider’s answers in the technical scope: addresses, protocols, locations, lead times, migration responsibilities and additional charges. That makes an offer reviewable and exposes unresolved dependencies before launch. The plan still needs implementation and acceptance testing on the selected service.
Looking Ahead: RIPE NCC Policy, IPv6 and Your Long‑Term Strategy
Address policy and membership procedures can change through their respective processes. For this review, the core IPv4, IPv6 and transfer documents already existed at the original publication date. The explicitly dated September 2026 additional-account notice must be checked separately. Avoid treating every capacity constraint as evidence that all rules recently tightened.
Keep these items on your review schedule:
- Official policy versions and dated membership notices before a new application or transfer.
- IPv6 skills, upstream/product support and the behavior of real clients and integrations.
- Actual IPv4/IPv6 cost, complexity, availability and user experience rather than assumed benefits from a protocol label.
A documented inventory, clear transfer and service terms, and tested IPv6 support give you concrete inputs for planning. Keep a growth reserve only where justified by your operational needs, and verify which addresses can be reassigned or returned. Revisit the plan when services, contracts or source policies change; a forecast is not reserved capacity.
Build an Address Plan You Can Verify
Eligible LIR accounts can request exactly one /24 through a waiting list with no guaranteed delivery date. Scarce-resource transfers have a 24-month restriction with defined scope and merger/acquisition treatment; registry records and customer continuity remain separate concerns. IPv6 offers address-planning capacity, while deployment still requires connectivity, application and security work.
Inventory public addresses, validate consolidation choices and roll out IPv6 in tested stages. Account for compatibility, staffing and ongoing cost alongside IPv4 pricing. For LIR operations, maintain appropriate assignments, contacts and transfer records; for a hosting customer, make address availability, notice and renumbering terms explicit. RIPE’s policy process is open to participation, so you can also follow or contribute to proposals rather than assuming policy is unchangeable.
If you are planning a DCHost deployment or migration, prepare the service list, expected IPv4/IPv6 requirements, location and routing dependencies for the technical discussion. Use the resulting offer to confirm scope, costs and responsibility, then test the implementation against those agreed requirements.
