An IPv4 address identifies your connection to the online world. IP addresses make it possible to host websites, manage secure communication, and engage in countless other essential, internet-related activities.
Typically, when migrating to a new cloud provider, a business has only one path: lease the provider’s IP addresses.
But what if a business already has a block of IP addresses?
That’s where BYOIP (Bring Your Own IP) comes into play as a compelling second option. Today, many leading cloud providers have implemented BYOIP policies that allow previous owners or lessors to pair their legacy IP addresses with the new cloud resources.
But what does that entail? What are the benefits of a BYOIP approach?
Here’s what businesses need to consider before they begin the migration process.
What Is BYOIP?
As the name implies, BYOIP is a set of policies that grants an organization the rights to use its own existing IP addresses within the cloud provider’s infrastructure.
Put simply, if a business already owns and uses a block of IP addresses on its legacy system or server, it can then retain all or part of those publicly routable addresses when they migrate or integrate with the new cloud provider.
For instance, if a business sought to migrate to a major provider like Amazon Web Services (AWS) or Google Cloud, either provider allows clients to provision their own public IPv4 addresses. Then, after those IP addresses were imported, the cloud provider would manage them in the same manner as a Google or Amazon-provided address. As Google notes, the only exceptions are:
The IP addresses are available only to the customer who bought them.
There are no charges for idle or in-use IP addresses.
Doesn’t support overlapping BOYIP route announcements.
Working Mechanics of BYOIP
Generally speaking, when the time comes to perform the transfer process involved with migration, an organization must:
Assess and validate their IP addresses by confirming eligibility with a Regional Internet Registry (RIR).
Coordinate with the chosen cloud provider like AWS or Google Cloud.
Use the cloud provider control panel to configure the addresses on cloud infrastructure&.
Adjust existing network configurations for a seamless transition. This includes updating Internet Routing Registry entries and any RPKI certificates you have.
Maintain post-migration performance through continuous monitoring and management. Some or all of this can be outsourced to performance monitoring companies.
Recognize that cloud providers might not support using a small part of a bigger block of addresses used elsewhere.
That said, the exact onboarding process for how to migrate existing IPv4 addresses to a new cloud provider will depend on the provider. Each one has its own infrastructure and requirements that might lead to variations in the procedure. For example, AWS has a two-phase, three-step process:
Preparation phase—Step 1—Create an RSA key pair, and use it to generate a self-signed X.509 certificate for authentication purposes that will be used solely for the provisioning phase.
RIR configuration phase – Step 3 – Create a ROA object in the RIR. The ROA defines the desired address range, the Autonomous System Numbers (ASNs) allowed to advertise the address range, and an expiration date to register with the Resource Public Key Infrastructure (RPKI) of the RIR. Organizations that already have a ROA will need to update the existing ROA to reflect the ASN of the cloud provider.
Benefits of BYOIP Adoption
Some of the tangible benefits of BYOIP include:
IP ownership continuity – In the digital landscape, an IP address is more than just a numerical identifier—it signifies identity and trust. By allowing organizations to keep their proven IP addresses, BYOIP avoids the time-consuming and challenging process of building a reputation from scratch with new IPs. This mitigates the risk of blocklists interfering with the usability of your addresses. And the same addresses can be transferred to a different cloud provider in the future, if needed.
Application compatibility – Many legacy applications or services might be configured to work IPv4 addresses or the address may even be hard-coded into the device or a license. BYOIP ensures seamless compatibility during migration, preserving existing IP address relationships, and avoiding the need to redefine hardcoded IPs, resulting in smoother transitions.
Third-party integration – Similarly, systems that are already integrated with third-party services might require IP whitelisting. BYOIP ensures uninterrupted communication with these entities, enabling businesses to move to the cloud without losing existing firewall entries or permissions.
Smoother migration – A cloud migration can be an energy-intensive process. For a successful migration, the goal is to minimize any potential disruptions. BYOIP minimizes changes in network configurations, thus reducing the risks and complexities that might come with tasks such as redefining hardcoded applications or splitting traffic between locations.
Regulatory compliance – Certain industries or regions require organizations to use IP addresses that are documented, and possibly communicated to a regulator or auditor for compliance purposes. BYOIP facilitates adherence to these regulations, including data sovereignty laws and region-specific legal demands, thus ensuring alignment with various governance structures.
Full control – With BYOIP the business has greater control over your IP addresses. It has the sole authority to dictate the desired configurations and operations.
Retention of valuable intangible assets – IPv4 addresses are not just functional necessities; they’re increasingly seen as valuable intangible assets. In light of the growing market demand and tightening supply of IPv4 address blocks, owning these resources is akin to holding a unique piece of digital real estate. As the availability of IPv4 addresses continues to diminish, their value can appreciate over time. Furthermore, organizations that retain ownership of these addresses through BYOIP have the flexibility to potentially capitalize on this appreciation by selling, leasing, or using the addresses as collateral.
Enhanced security – If an organization’s security policies are tied to specific IP addresses, BYOIP makes it easier to transfer those policies into the cloud. Some adjustments will be needed because the physical infrastructure is changing. But BYOIP massively lowers the scale of reconfiguration.
BYOIP Implementation Challenges and Limitations
Implementing BYOIP—although beneficial—carries its own set of unique challenges and limitations that organizations must carefully weigh before committing to this policy. Common issues include:
Onboarding process – The actual process of bringing your own IP address into a cloud provider like AWS EC2 is not complex and can be accomplished by an experienced network engineer in less than a full day. The process includes:
Configuring IP address space via RIR
Creating route origins authorization
Generating self-signed X.509 certificates
Uploading the public key to the RIR Resource database
Creating a signed message
Provisioning the CIDR with AWS region
Provider limitations – Not all cloud providers support BYOIP.
BYOIP at AWS
AWS is permitting BYOIP on its platform. For information on how to take advantage of this opportunity, see our AWS-BYOIP blog.
BYOIP with IPv4.Global
For any cloud migration, businesses may opt to BYOIP rather than buying or leasing their IP addresses from the cloud provider. This policy allows for increased flexibility, control, and efficiency in managing IP assets. By leveraging existing IP addresses, organizations can preserve their established reputation, ensure seamless compatibility with applications, and meet regional-specific regulatory requirements.
But what if a business has legacy IP addresses it wants to transfer, but lacks the expertise to perform the migration? Contact us to learn more about the migration process.
NORDVPN DISCOUNT - CircleID x NordVPN Get NordVPN
[74% +3 extra months, from $2.99/month]
A Message from Our Sponsor
How to Take Advantage of Rising IPv4 Address Value:IPv4.Global specializes in helping clients sell, lease and buy IPv4. We help make the process less complicated and time-consuming by:
• Helping you find a buyer
• Leading you through the registry process
• Providing advice and expertise to reorganize your network
Contact us by calling (212) 610-5601 to speak with an expert for help turning your invisible asset into revenue.
Filed Under
Comments
Interop Show net moved 45/8 every couple of monthsKarl Auerbach – Feb 13, 2024 3:02 PM
When I was doing the Interop show network (roughly 1987/8 through the early 2000’s) we moved our IPv4 address block quite frequently around the world. (We had 45.x.x.x/8.) We always were dual homed to two distinct transit providers.
Sometimes there were only a few days between when we turned off our BGP announcements in one venue (such as Las Vegas) and began new announcements for 45/8 in a new location, such as Tokyo.
Apart from establishing fairly fast physical connectivity to convention centers our main job was dealing with getting BGP announcements going and accepted by our providers and by most of the other providers. Fortunately we were fairly well known and trusted. But we did have to deal with the route damping algorithms because while we were bringing things up we looked a lot like a badly flapping path. We had to spend a lot of time on the phone asking for those automatically imposed damping blocks to be manually reset.
(We, of course, learned the hard way to turn our DNS TTLs down to quite low values several days before any move.)
We, and pretty much everyone else, knew that our net block, being a trade show net that encouraged experimentation, would be the source of some bad stuff. So we got a lot of leeway from people who might have blocked other network address blocks that emitted the similar of junk.
I have had (and still have) my own IPv4 blocks (from Jon Postel) that I would lend out to worthy (and trustworthy) groups for short term use.
The junk-emission/blocking issue is a big one: When I lent blocks I made it clear that the people I was lending it to had to take care to avoid that block from being known as a source of bad traffic. Once a block gets a bad reputation - and worse, actual filters in routers and firewalls - it is hard to clean things up.
More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.
When I was doing the Interop show network (roughly 1987/8 through the early 2000’s) we moved our IPv4 address block quite frequently around the world. (We had 45.x.x.x/8.) We always were dual homed to two distinct transit providers.
Sometimes there were only a few days between when we turned off our BGP announcements in one venue (such as Las Vegas) and began new announcements for 45/8 in a new location, such as Tokyo.
Apart from establishing fairly fast physical connectivity to convention centers our main job was dealing with getting BGP announcements going and accepted by our providers and by most of the other providers. Fortunately we were fairly well known and trusted. But we did have to deal with the route damping algorithms because while we were bringing things up we looked a lot like a badly flapping path. We had to spend a lot of time on the phone asking for those automatically imposed damping blocks to be manually reset.
(We, of course, learned the hard way to turn our DNS TTLs down to quite low values several days before any move.)
We, and pretty much everyone else, knew that our net block, being a trade show net that encouraged experimentation, would be the source of some bad stuff. So we got a lot of leeway from people who might have blocked other network address blocks that emitted the similar of junk.
I have had (and still have) my own IPv4 blocks (from Jon Postel) that I would lend out to worthy (and trustworthy) groups for short term use.
The junk-emission/blocking issue is a big one: When I lent blocks I made it clear that the people I was lending it to had to take care to avoid that block from being known as a source of bad traffic. Once a block gets a bad reputation - and worse, actual filters in routers and firewalls - it is hard to clean things up.