BYOIP for Dedicated Servers: Requirements and Responsibilities

Moving to a new dedicated server can mean updating customer allowlists, API connections, and services tied to existing IP addresses. Bring Your Own IP, or BYOIP, can reduce that work by letting you use eligible public address space with a different hosting provider.

BYOIP for dedicated servers requires control of the address block, provider approval, correct routing authorizations, and a working connection between the announced prefix and your servers. Each party also needs a clear role during migration and after launch.

At Atal Networks, we recommend checking these requirements before setting a migration date. Keeping your addresses helps with continuity, but it does not automatically move applications, preserve connections, or remove routing risks.

Understand What BYOIP Changes

BYOIP lets you use public IP addresses that you control, or have permission to use, on a hosting provider’s infrastructure. The provider accepts the address block and delivers traffic to your servers through an agreed network arrangement.

The move changes where the addresses operate. It does not, by itself, transfer their registration or extend your rights beyond an existing lease.

A Dedicated IP Is Not Automatically Portable

An IP address can remain fixed for years without belonging to your organization. If your current host assigned it from its own pool, you usually cannot take it elsewhere without that host’s permission and a supported routing arrangement.

BYOIP becomes useful when you have eligible address space and need to retain:

• Customer or partner IP allowlists.
• Fixed service endpoints.
• Network policies tied to specific addresses.
• Addressing consistency during infrastructure changes.

It may be unnecessary if provider-assigned addresses meet your needs and changing them creates little operational work.

Check BYOIP Requirements Before Ordering

The first task is to establish whether the receiving provider accepts your particular prefix, location, and workload.

Confirm Address Rights and Record Control

Identify the registered resource holder and the party authorized to approve announcements.

For leased space, confirm that the agreement permits use with the intended hosting provider. Also establish who can create or change routing records. The server customer, IP lessor, and registered holder may be different organizations.

A lease payment alone does not prove that you can make every required registry change. Some platforms require direct control of public registration records, while others accept authorized coordination with the resource holder.

Check Prefix Size and IPv6 Support

Providers commonly require at least an IPv4 /24 for an independent public announcement. That block contains 256 addresses, although usable server capacity depends on the delivery method.

A single IP or /29 is generally too specific for broad acceptance as an independent Internet announcement. A provider may still route smaller portions internally beneath an accepted larger prefix.

Check IPv6 separately. Support for IPv6 on a server does not necessarily mean the provider accepts customer-supplied IPv6 prefixes. Provider documentation shows real differences: the reviewed OVHcloud BYOIP service describes IPv4 only, while AWS documents public IPv4 and IPv6 imports.

Confirm the Deployment Scope

Before ordering, ask about eligible server products, facilities, permitted workloads, and existing announcements.

Requirement	Evidence or confirmation needed
Address-use rights	Resource records and relevant authorization
Leased-space permission	Agreement allowing the intended deployment
Prefix eligibility	Accepted address family and block size
Location support	Approval for the chosen facility and service
Routing arrangement	Agreed origin ASN and delivery method
Workload acceptance	Compliance with the provider’s usage terms
Migration readiness	Current announcement details and a handoff plan

Choose Who Announces Your IP Addresses

BYOIP describes the use of your address space. It does not specify who operates BGP, the protocol networks use to exchange routes.

Provider-Managed Announcements

The hosting provider announces the prefix through an agreed origin ASN and routes the addresses to your servers.

You supply the required permissions and maintain the records under your control. The provider manages its routing configuration.

This arrangement can suit businesses that need address portability without operating their own routing software.

Customer-Managed BGP

Your routing device or software exchanges routes with the provider. You manage your side of the session, including announcement policy and route withdrawal.

Both parties must agree on accepted prefixes, session settings, security controls, and troubleshooting responsibilities.

Decision	Provider-managed arrangement	Customer-managed BGP
Customer operates BGP	Usually not required	Required
Customer public ASN	Depends on the service	Depends on the agreed design
Announcement changes	Provider workflow	Customer configuration plus provider policy
Operational workload	Lower customer routing workload	Customer maintains routing and monitoring

BYOIP and BYOASN are separate choices. Bringing your addresses does not always require your own public Autonomous System Number. Dedicated.com documents several announcement arrangements, while Vultr allows either a customer ASN or a private-ASN arrangement.

Prepare Authorization and Routing Records

Proof that you may use an address block and permission for a network to announce it are related but separate requirements.

Letter of Authorization

A Letter of Authorization, or LOA, records permission for the specified network arrangement. Providers commonly request:

• IP prefixes in CIDR notation.
• The resource holder’s organization name.
• The authorized network and relevant ASN.
• An authorized signature and date.
• Contact details and any required expiry date.

Use the receiving provider’s format. If you lease the space, the provider may require authorization from the registered holder rather than a letter signed only by your company.

IRR Records and RPKI ROAs

An Internet Routing Registry, or IRR, stores routing information. A route object identifies an IPv4 prefix and origin ASN; a route6 object serves the corresponding role for IPv6.

A Route Origin Authorization, or ROA, uses Resource Public Key Infrastructure, or RPKI, to authorize an ASN to originate specified address space.

Record	Main purpose	Party to identify
LOA	Documents announcement permission	Authorized resource representative
IRR route or route6 object	Supplies routing information used in filtering	Authorized registry maintainer
ROA	Authorizes the origin ASN and prefix length	Resource holder or authorized RPKI administrator

Check the origin ASN and permitted prefix length before announcement. A mismatch can cause networks applying origin checks to reject the route.

RPKI origin checks do not secure every part of the routing path. We still recommend explicit route filters and ongoing monitoring.

Some platforms use certificates, signed messages, or DNS-based checks to confirm control. Those are provider-specific procedures, not universal BYOIP requirements.

Assign Responsibilities Before Deployment

A BYOIP request can stall when everyone assumes another party owns the next step.

We recommend recording responsibilities across the customer, resource holder, and hosting provider. The table below describes a typical division; the actual service agreement takes priority.

Task	Customer or resource holder	Hosting provider
Address permissions	Maintains rights and supplies evidence	Checks eligibility
LOA	Authorized party signs	Supplies requirements and reviews it
IRR and ROA changes	Makes or approves authorized changes	Supplies agreed routing details
Provider network routing	States requirements	Configures its network service
Customer BGP software	Operates it unless management is included	Maintains the provider side
Server addressing and firewall	Configures and tests unless included	Supplies the network handoff
Reverse DNS	Maintains records or delegates control	Handles records where agreed
Abuse response	Investigates workload activity	Applies network policy and support procedures
Migration	Prepares applications and rollback	Coordinates provider-side changes

For leased IPs, include the lessor’s response times and contact details. A hosting engineer cannot correct a ROA if another organization controls it and has not authorized the change.

Confirm How the Block Reaches Your Servers

An Internet announcement gets traffic to the provider’s network. The provider must then deliver it to the correct server or routing device.

Common arrangements include a static-routed block, a gateway-based subnet, or customer-managed BGP. Confirm the next-hop address, subnet configuration, permitted source addresses, and management connection.

Plan for Virtual Machines and Multiple Hosts

A block routed to one Serveur nu does not automatically work across every host in a cluster.

For virtual machines, agree on:

• Host and guest routing.
• Gateway placement.
• VLAN requirements.
• Connectivity between physical servers.
• Firewall and source-address restrictions.

Cherry Servers documents one practical limitation: servers in different network segments may not share the Layer 2 connection required for a common VM gateway subnet.

Keep management access available through a separate working path during configuration. A mistake in customer routing should not remove your only way to reach the server.

Plan Migration and Acceptance Testing

Keeping the same IP addresses can reduce configuration changes, but it does not guarantee a migration without interruption.

Consider a business moving an API that partners access through IP allowlists. BYOIP may preserve the endpoint address. The business still needs the application, certificates, data, firewall rules, and return routing ready at the destination.

Prepare the Handoff

Use a written migration sequence:

1. Obtain acceptance for the prefix, workload, and target location.
2. Prepare the server and test the application through an available temporary path.
3. Align permissions, IRR records, ROAs, and provider filters.
4. Agree on the existing route’s withdrawal and the new announcement.
5. Set rollback triggers and name the person who can authorize them.
6. Move traffic during the agreed window.
7. Record the result before retiring the previous service.

Do not assume that starting a second announcement is a safe migration method. Planned anycast or multihoming can use multiple paths, but an unplanned overlap may send traffic to the wrong location.

Test Beyond Prefix Approval

Provider approval, active advertisement, server reachability, and working applications are separate milestones.

DigitalOcean’s documentation illustrates this distinction: a provisioned prefix needs advertisement enabled before it becomes reachable through the Internet.

Check external route visibility, inbound and outbound traffic, expected source addresses, application ports, and partner access. Test both IPv4 and IPv6 where applicable.

Existing TCP connections may break during the move even when the IP remains unchanged. Application state and connection handling need their own recovery plan.

Manage Reputation, Reverse DNS, and Security

BYOIP carries operational responsibilities beyond routing.

Maintain Reverse DNS and Geolocation

Confirm who controls PTR records and whether the provider needs reverse DNS delegation.

Check geolocation independently. Moving a server or changing the origin ASN does not automatically update every third-party location database. Geofeeds and correction requests may help, but each database has its own process.

Keep Reputation Checks Relevant

Review the destinations and reputation sources that matter to your workload. Retaining an IP preserves its address identity, including potentially troublesome history.

BYOIP does not guarantee acceptance by every service or permanent removal from blocklists. Maintain current abuse contacts and respond to compromised workloads promptly.

Confirm DDoS Coverage

Ask whether the protection offered with the server also covers your imported prefix. Establish any routing requirements, traffic limits, or conditions.

Document who can request traffic blocking during an attack and who approves restoration. Do not assume that a standard server feature applies unchanged to every customer-address arrangement.

Review Costs, SLA Coverage, and Exit Terms

BYOIP can involve costs beyond the dedicated server and address lease.

Ask about setup fees, per-prefix charges, additional locations, BGP sessions, managed configuration, change requests, and bandwidth.

A service advertised without an import fee may still charge for custom network work. Compare the complete scope rather than one line in a pricing table.

Separate the Server SLA From BYOIP Coverage

The server’s availability commitment may not cover customer routing errors or every BYOIP function. Dedicated.com and OVHcloud publish service limits that show why the specific agreement matters.

Confirm support hours, incident ownership, and which changes need a network-team request.

Plan Removal Before Canceling Hosting

Leaving a provider requires another coordinated network change.

Move services, confirm the replacement routing, withdraw the previous announcement, and remove old assignments. Update authorizations when they are no longer needed, while protecting any agreed rollback period.

Also review reverse DNS, provider access, and lease expiry. Retaining the hosting account does not extend an expired IP lease, and canceling hosting does not necessarily end every address-related agreement.

Common BYOIP Problems and First Checks

Problem	Start by checking
Provider rejects the request	Address rights, block size, location, and permitted workload
Prefix approved but unreachable	Advertisement status, origin records, filters, and delivery route
Traffic arrives but replies fail	Return routing, source address, firewall, and source-address policy
Host works but VMs do not	Guest routes, gateway, VLAN, and network-segment requirements
Only some destinations fail	Remote policy, reputation, and path-specific reachability
Traffic still reaches the old host	Previous announcements and the agreed withdrawal sequence

Collect source and destination addresses, timestamps, application errors, and tests from both ends where possible. This helps the provider distinguish a local configuration fault from behavior outside its network.

Prepare Your BYOIP Request for Atal Networks

Before discussing Serveurs dédiés with our team, gather your prefixes, resource-holder details, lease status, intended ASN arrangement, and current announcement information.

Include the target location, workload, bandwidth needs, server or VM layout, security requirements, and migration window.

Notre IPv4, IPv6, and ASN leasing page lists LOA, route objects, and RPKI among its IP-service features. Confirm acceptance of customer-supplied prefixes and the exact deployment scope with us before placing an order.

Questions fréquemment posées

Can I bring an IP address assigned by my current host?

Usually not without permission from the resource holder. A fixed or dedicated IP is not automatically portable. Check the address agreement first.

Can I use leased IPv4 addresses with BYOIP?

Yes, where the lease permits the arrangement and the receiving provider accepts it. The authorized resource party must support the required records and permissions.

Do I need my own ASN or BGP session?

Not always. Some providers announce customer prefixes themselves. Customer-managed BGP and public ASN requirements depend on the selected service.

Can I bring a single IP address or a /29?

Generally not as an independent globally announced prefix. Smaller allocations may work within a larger accepted block under a provider-specific arrangement.

Can several dedicated servers use the same block?

Yes, if the provider supports the required routing and allocation method. Confirm gateway, VLAN, and location restrictions before designing the deployment.

Does BYOIP guarantee zero downtime?

No. It preserves eligible addresses, but applications, routing changes, connection state, and recovery procedures still affect availability.

Who manages IP reputation and reverse DNS?

Assign both explicitly. Workload behavior usually remains the customer’s responsibility. Reverse DNS depends on delegation and the agreed management service.

Can I keep the addresses after canceling the server?

Only while your resource rights or lease remain active. Coordinate provider withdrawal and the next deployment before cancellation.

Recommended Next Steps

Confirm that your address space is eligible, identify who controls its records, and agree on the provider’s delivery method. Then document migration, testing, support, and exit responsibilities.

Discuss your IP prefixes, server location, and BYOIP requirements with Atal Networks.