Record the exact proposal
- List CIDR, registry object, destination service, region and intended origin.
- Ask OVHcloud to confirm uncertain eligibility conditions before the address commitment.
OVHcloud BYOIP: choose the block and origin together
Bringing IPv4 to OVHcloud starts with eligibility and control of the registry records. Confirm the destination service and announcement model before ordering a block or planning a migration.
Discuss an IPv4 lease
Check the import constraints first
Registry and exact range
The documented IPv4 path accepts ARIN, RIPE and APNIC space with eligible record types. The registry object must match the imported range exactly. Confirm the actual record, not just a covering allocation.
Import size and destination
Supported IPv4 imports run from /24 through /19 and become /24 blocks. Choose the region and an eligible destination service before budgeting the deployment.
Existing announcements
OVHcloud warns against simultaneous announcements elsewhere. An order can precede withdrawal, but the other announcement must stop when the BYOIP service is delivered. Plan the handover with both networks.
Separate control verification from routing permission
OVHcloud verifies control through a token in the range’s public WHOIS object and, for a customer origin, the ASN object. Its workflow requires an exact-prefix route object using the selected origin: AS16276 or the customer’s ASN. Imported addresses are announced while at least one block is routed to a service; parking every block stops the announcement.
These provider-specific points are summarized from the official OVHcloud BYOIP procedure, checked November 15, 2026. Confirm current eligibility for the proposed block, product and region before placing an order.
For a leased block, ask who can publish the verification token and routing records. Treat a missing publication owner as an unresolved dependency. An address quotation should not be mistaken for confirmation that another provider has accepted the import.
Prepare one shared handover sheet
Assign each change
- Name the owners of registry verification, routing authorization and service configuration.
- Include a contact who can correct rejected records during the change window.
Agree evidence and recovery
- Define what the teams will observe before and after the move.
- Agree how to restore the previous service if the destination cannot carry the workload.
Accept the running workload
- Test the actual service from relevant networks, including return traffic.
- Record the result before retiring temporary permissions or closing the migration task.
Use the routing references for implementation
Keep the provider’s import decision separate from the mechanics of publishing and checking records. Use the IRR publication guide for prefix-origin objects and the ROA guide for origin validation. A completed registry edit does not show that a receiving network has refreshed its filters.
During cutover, use the prefix-announcement checks to compare intended records, observed routing and actual traffic. Keep the previous service available for the agreed recovery period when the migration design permits it; do not assume every provider supports simultaneous origination.
If you are still choosing between independent routing, provider origination and remote delivery, start with the no-ASN purchasing scenario. The BYOIP overview covers the wider choice of destination platforms.
Frequently asked questions
Can I use a leased IPv4 block for OVHcloud BYOIP?
Confirm the specific block with OVHcloud before committing to a lease. A lease alone does not establish eligibility or the ability to complete registry verification. Agree who controls the required records and who will make each change.
Do I need my own public ASN for OVHcloud BYOIP?
The documented workflow offers OVHcloud AS16276 or a customer ASN. Choose the model before preparing authorization records; the public origin must match the intended announcement.
Does importing a block make the application ready?
No. Import acceptance, service attachment, route visibility and application reachability are separate checks. Keep the migration reversible until traffic to the actual workload has been tested.
What should I confirm before requesting IPv4?
Identify the exact CIDR, registry record, destination product and region, intended public origin, verification owner and change window. Ask both parties to confirm dependencies before agreeing activation dates.
Prepare your OVHcloud IPv4 requirement
Include the CIDR size, registry, destination product, region and intended origin when discussing address availability. Confirm provider acceptance and record-control responsibilities before activation.