IPv4 Justification Changes in IMS

May 26, 2011

When IANA ran out of IPv4 blocks in February, the belts tightened yet another notch in the IPv4 world. Regional registries such as ARIN have changed how they are allocating additional IPv4 blocks to ISPs, including performing more stringent reviews to ensure efficient utilization of current allocations and reducing future allocation sizes to more fairly distribute the remaining addresses. In turn, ISPs such as SoftLayer have to more closely monitor how we assign our IPv4 space to ensure efficient utilization by our customers. In order to maximize this limited resource, we have to make changes to the way customers order and receive additional IPv4 IPs.

Being down the line from ARIN, SoftLayer's networking department has to ensure we abide by all updated ARIN policies when we issue IPv4 addresses from our available pool in order to remain eligible to receive additional resource allocations. In addition to policy compliance, we are also focused on IPv4 conservation methods such as those referenced in RFC2050. Accordingly, we've made improvements to the way that we handle IPv4 requests to better streamline the process of collecting and reviewing usage and justification details.

Every SoftLayer server comes with one public IPv4 address, and until recently was assigned 4 additional IPs (/30) statically routed to that server. Our first step of IP conservation took place earlier this year, when we ceased the practice of automatically assigning the 4 additional IPs, and only issued them by customer request.

As we move forward, were trying to be as transparent with our customers about the IPv4 justification process as we can, so we're letting you know that additional justification requirements have been imposed on all ISPs by ARIN, and the best way we can meet those requirements is to have our customers follow the same guidelines. Being SoftLayer, we're doing what we can to automate and streamline the IPv4 justification process where possible, and are therefore implementing changes in the ordering system. Beginning on June 1, you will now be presented with a brief questionnaire whenever requesting additional IPv4 addresses. We must collect the requester's contact details, number of IPs that are expected to be used immediately and within the next year, as well as a brief description of how the IPs will be used. What happens next depends on the information you have provided as well as the current IP usage on your account: either the request is automatically approved and fulfilled, or a ticket is spawned for additional manual review by one of the folks in our networking team.

When a ticket is spawned for our network folks, we will get back to you within one business day, and let you know whether we need additional details from you in order to consider the request. These manual reviews will take additional time, depending on the size and complexity of request, as well as the quality of information provided. Please be prepared that there will be some cases where we will not be able to approve a request, such as when name-based virtualization can be used for IP conservation, or when services such as SEO, email campaigns, or VPN termination are the intended use for the additional IPv4 addresses.

If you're familiar with SoftLayer's previous method of ordering additional IPv4 addresses, you might feel like we're making you jump through hoops. These "hoops" are not intended to make the process arbitrarily more difficult. Rather, they're being put in place specifically to make sure we're in the best position possible to meet customer demands with our current IPv4 allocations, and get additional allocations from ARIN before they are completely depleted.

The ISPs that have no problems giving away IPv4 addresses right now without more stringent review are also going to be the providers that have the hardest time getting additional IPv4 blocks from ARIN, and therefore will have a hard time fulfilling future customer needs. At SoftLayer we are going by the philosophy that the more cautiously we approach IPv4 depletion by justifying our customers' needs for each IPv4 address, the longer our IPv4 pool will last to meet those needs.

This is a good opportunity to mention IPv6 as the long-term solution for IPv4 address depletion. The sooner that the public Internet becomes fully IPv6-enabled, the better off the resource constraint will become. The SoftLayer network is enabled for IPv6, and you may place an order for 18.4 quintillion free IPv6 addresses for your server via our web portal today!

-Dani

Comments

May 26th, 2011 at 3:22pm

Cool, I've always wanted 18.4 quintillion IPv6 addresses for my server!

May 31st, 2011 at 3:48am

"The SoftLayer network is enabled for IPv6, and you may place an order for 18.4 quintillion free IPv6 addresses for your server via our web portal today!"

Unless you're like me and are a former The Planet customer who was acquired in the merger. In that case you're left blowing in the wind:
Jimmy V: The Planet servers are not compatible with IPv6
Jimmy V: only Servers on the SoftLayer Platform have the Ipv6 capability
you: Do you know when they will be?
Jimmy V: IPv6 will not be available on the Planet platform

May 31st, 2011 at 12:03pm

If you look at the recent news from one of our competitors, they just announced IPv6 capabilities last week after three years and $10 million in R&D and hardware upgrades: http://sftlyr.com/8b ... The work required to get legacy servers from The Planet would have probably required a similar investment of time and money, and because all new server orders would be provisioned on the SoftLayer platform, the benefits of that retrofitted system couldn't have really been paid for by the new servers those capabilities may have attracted.

The difficulty in incorporating IPv6 on The Planet platform is that every piece of network hardware has to support IPv6, and in The Planet's data centers, many of our routers and switches didn't, so they would have had to be completely replaced. The odds of all of the customers wanting IPv6 on their server being in the same data center (or much less the same rack) were miniscule, so to meet the relatively low demand, a network-wide replacement would have had to happen. If every customer was clamoring for IPv6, the discussion may have been different.

As a result, we decided the best way to support customers on the legacy infrastructure who needed those other capabilities would be to help those customers get onto the SoftLayer platform. The decision shouldn't suggest that the legacy TP customers or their requests were any less valuable; rather the dollars and cents of what it would cost to enable things like IPv6 on a platform that would be growing just wasn't economically feasible. If there were any way to easily incorporate those features in the legacy TP architecture, we most certainly would have done so.

 

      

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Comments

May 26th, 2011 at 3:22pm

Cool, I've always wanted 18.4 quintillion IPv6 addresses for my server!

May 31st, 2011 at 3:48am

"The SoftLayer network is enabled for IPv6, and you may place an order for 18.4 quintillion free IPv6 addresses for your server via our web portal today!"

Unless you're like me and are a former The Planet customer who was acquired in the merger. In that case you're left blowing in the wind:
Jimmy V: The Planet servers are not compatible with IPv6
Jimmy V: only Servers on the SoftLayer Platform have the Ipv6 capability
you: Do you know when they will be?
Jimmy V: IPv6 will not be available on the Planet platform

May 31st, 2011 at 12:03pm

If you look at the recent news from one of our competitors, they just announced IPv6 capabilities last week after three years and $10 million in R&D and hardware upgrades: http://sftlyr.com/8b ... The work required to get legacy servers from The Planet would have probably required a similar investment of time and money, and because all new server orders would be provisioned on the SoftLayer platform, the benefits of that retrofitted system couldn't have really been paid for by the new servers those capabilities may have attracted.

The difficulty in incorporating IPv6 on The Planet platform is that every piece of network hardware has to support IPv6, and in The Planet's data centers, many of our routers and switches didn't, so they would have had to be completely replaced. The odds of all of the customers wanting IPv6 on their server being in the same data center (or much less the same rack) were miniscule, so to meet the relatively low demand, a network-wide replacement would have had to happen. If every customer was clamoring for IPv6, the discussion may have been different.

As a result, we decided the best way to support customers on the legacy infrastructure who needed those other capabilities would be to help those customers get onto the SoftLayer platform. The decision shouldn't suggest that the legacy TP customers or their requests were any less valuable; rather the dollars and cents of what it would cost to enable things like IPv6 on a platform that would be growing just wasn't economically feasible. If there were any way to easily incorporate those features in the legacy TP architecture, we most certainly would have done so.

 

      

Leave a Reply

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • You can enable syntax highlighting of source code with the following tags: <pre>, <blockcode>, <bash>, <c>, <cpp>, <drupal5>, <drupal6>, <java>, <javascript>, <php>, <python>, <ruby>. The supported tag styles are: <foo>, [foo].
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.