Posts Tagged 'Arin'

August 27, 2012

IPv4 v. IPv6 - What's the Difference?

About a year ago, Phil Jackson and I recorded a podcast-esque click-through of a presentation that explained the difference between IPv4 and IPv6 address space, and as a testament to the long-tail nature of blog posts, Internet Society's Deploy360 Blog shared the video. With a hint of nostalgia, I clicked "play" on the video.

I laughed. I cried. I found it informative. I noticed a few places where it could have been better.

We recorded the video in response to a tweet from one of our Twitter followers, and the off-the-cuff dialog wound up being somewhere in between "accessible, informative and funny" and "overly detailed, too long and obviously improvised." Because there aren't many people who want to listen to two guys give a 15-minute presentation on IP addresses when they could be watching a Songified review of Five Guys Burgers and Fries or an epic data center tour, I thought I'd dilute the information from the video into a quick blog post that spells out some of the major distinctions between IPv4 and IPv6 so you can scan it, interject your own "witty" banter and have your favorite YouTube viral video playing in the background.

IP Address Overview

An IP address is like a telephone number or a street address. When you connect to the Internet, your device (computer, smartphone, tablet) is assigned an IP address, and any site you visit has an IP address. The IP addressing system we've been using since the birth of the Internet is called IPv4, and the new addressing system is called IPv6. The reason we have to supplement the IPv4 address system (and ultimately eclipse it) with IPv6 is because the Internet is running out of available IPv4 address space, and IPv6 provides is an exponentially larger pool of IP addresses ... Let's look at the numbers:

  • Total IPv4 Space: 4,294,967,296 addresses
  • Total IPv6 Space: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses

Even saying the IPv6 space is "exponentially larger" doesn't really paint the picture of the difference in size.

IPv4 Addresses

To understand why the IPv4 address space is limited to four billion addresses, we can break down an IPv4 address. An IPv4 address is a 32-bit number made up of four octets (8-bit numbers) in decimal notation, separated by periods. A bit can either be a 1 or a 0 (2 possibilities), so the decimal notation of an octet would have 28 distinct possibilities — 256 of them, to be exact. Because we start numbering at 0, the possible values of one an octet in an IPv4 address go from 0 to 255.

Examples of IPv4 Addresses: 192.168.0.1, 66.228.118.51, 173.194.33.16

If an IPv4 address is made up of four sections with 256 possibilities in each section, to find the total number of possibilities in the entire IPv4 pool, you'd just multiply 256*256*256*256 to get to the 4,294,967,296 number. To look at it another way, you've got 32 bits, so 232 will get you to the same total.

IPv6 Addresses

IPv6 addresses are based on 128 bits. Using the same math as above, we can take 2128 and find the total IPv6 address pool (which I won't copy again here because it takes up too much space). Because the IPv6 pool is so much larger than the IPv4 pool, it'd be much more difficult to define the space in the same decimal notation ... you'd have 232 possibilities in each section.

To allow for that massive IPv6 pool to be used a little more easily, IPv6 addresses are broken down into eight 16-bit sections, separated by colons. Because each section is 16 bits, it can have 216 variations (65,536 distinct possibilities). Using decimal numbers between 0 and 65,535 would still be pretty long-winded, so IPv6 addresses are expressed with hexadecimal notation (16 different characters: 0-9 and a-f).

Example of an IPv6 Addresses: 2607:f0d0:4545:3:200:f8ff:fe21:67cf

That's still a mouthful, but it's a little more manageable than the decimal alternatives.

CIDR Slash (/) Notation

When people talk about blocks of IP addresses, they generally use CIDR Slash (/) Notation where the block might look like this: 192.0.2.0/24 ... When you glance at that number, you might assume, "Okay, so you have 192.0.2.0 through 192.0.2.24," but CIDR notation is not showing you the range of addresses, it's telling you the size of the "network" part of the allocation.

IP addresses are made up two parts — the network and the host. The "network" part of the address tells us the number of bits that stay the same at the beginning of the block of IPs, while the "host" part of the address are the bits that define the different possibilities of IP addresses in the block. In CIDR notation, a /24 is telling us that the first 24 bits of the address are defined by the network, so we have 8 bits (32 total bits minus 24 network bits) in the host — 28 is 256 distinct addresses. The 192.0.2.0/24 IPv4 address block includes 192.0.2.0 to 192.0.2.255.

IPv4 address blocks can be as large as a /8 (given to regional registries like ARIN and APNIC), and they can be as small as a /32 (which is a single IP address).

Why Provision So Many IPv6 Addresses?

When SoftLayer provisions an IPv6 address block on a server, we give a /64 block of IPv6 addresses ... Or 18,446,744,073,709,551,616 IPv6 addresses to each server. That number seems excessive, but the /64 block size is the "smallest" IPv6 allocation block.

Providers like SoftLayer are allocated /32 blocks of IPv6 addresses. The difference between a /32 and a /64 is 32 bits (232) ... Bonus points if you can remember where you've seen that number before. What that means is that SoftLayer is given a block of IP addresses so large that we could provision 4,294,967,296 /64 blocks of IPv6 addresses ... Or put more remarkably: In one /32 block of IPv6 space, there are the same number of /64 blocks of IPv6 addresses as there are TOTAL IPv4 addresses.

So while it's pretty impossible to use a full /64 of IPv6 addresses on a server, it's equally difficult for SoftLayer to burn through its /32 block.

So Now What?

IPv4 space is running out quickly. If your site isn't running a dual-stack IPv6 configuration yet, it's possible that you're going to start missing traffic from users who are only able to access the Internet over IPv6 (which is not backwards compatible with IPv4). If your Internet Service Provider (ISP) doesn't support IPv6 yet, you won't be able to access websites that are broadcast only with IPv6 addresses.

The percentage of instances of each of those cases is relatively small, but it's only going to get larger ... And it only takes one missed customer to make you regret not taking the steps to incorporate IPv6 into your infrastructure.

-@khazard

May 26, 2011

IPv4 Justification Changes in IMS

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

March 4, 2011

3 Bars | 3 Questions: IPv6

Thanks to Marc's vote, I had the distinct honor of being the third guest on our "3 Bars | 3 Questions" series. The topic of conversation: IPv6.

Are we in a "The sky is falling!" situation yet? How can customers put pressure on their ISPs and software providers to add IPv6 support? How long with ARIN and SoftLayer have IPv4 addresses to give out now that IANA has released their entire free pool? Here's my take:

This video was recorded while Kevin was standing outside the Moscone Center in San Francisco at GDC 2011 over a mobile hotspot connection, so the video quality suffered a little. To silence the street noise, Kevin muted his side of the conversation as I spoke.

-Will

February 18, 2011

Is Your Business Ready for World IPv6 Day?

As you may have seen earlier in the week, SoftLayer is joining ISOC's 24-hour IPv6 "test flight" as a part of World IPv6 Day on June 8, 2011.

As I alluded in ISOC's press release, SoftLayer is a hosting provider, but we aren't going to be an effective resource for our customers if we don't adopt the newest technologies and platforms for future growth. Because we've built our business around that idea, you won't see many substantial changes when June 8 rolls around ... We were a little ahead of the curve in December 2008 when we began providing native IPv6 support to our publicly available services. The point of this Internet-wide event is not about getting there first, though ... It's about everyone getting there.

What does World IPv6 day mean to you? Probably little to nothing in the short-run. While there's a unanimous sense of urgency to be prepared, the real deadline is still a little ways into the future. If you're a SoftLayer customer, it's pretty easy for you to take part in your own World IPv6 Day: Provision your free IPv6 /64 on your server and start using them.

I encourage you to set goals for IPv6 functionality for the near future so you don't find yourself scrambling for a solution when you can't get any new IPv4 addresses. Don't let the fact that ARIN still has 5.20 IPv4 /8s in aggregate lull you into inaction ... The well will run dry, and the sooner you're ready for it, the better. Would your business be ready to flip the switch to IPv6 on June 8?

-Will

January 21, 2011

What Does IPv4 Exhaustion Mean for You?

THE SKY IS FALLING! EVERYBODY MOOOOOOVVVVEEEE! WWWHHHYYY??!! OH THE HUMANITY!!!

Are those your reactions to the depletion of IPv4 space? Probably not. If you haven't seen the IPv4 Exhaustion Rate countdown in the sidebar of SoftLayer.com, head over there and check it out ... At the current rate, there will be ZERO unallocated IPv4 blocks by the middle of February 2011, and that's not a good thing for the Internet as we know it.

Will you need to move your servers into a bomb shelter to protect your now-even-more-valuable IP addresses? Will Google stop Googling? Will there be riots in the streets as over-caffeinated sysadmins flip cars and topple dilapidated buildings in pursuit of lost 32-bit addresses? What does it really mean for you as a hosting customer and web surfer?

The sky won't fall. Your servers are safe in their data centers. Google will still Google. Sysadmins will still be working hard at their desks. But the belt is going to start tightening, and after a while, it might get pretty uncomfortable.

What's Really Happening

All of these IPv4 Exhaustion Rate counters are loosely tracking the IPv4 space that hasn't been allocated by the International Assigned Numbers Authority (IANA) to a Regional Internet Registry. The Regional Internet Registries (RIRs) are ARIN (USA and Canada), LACNIC (Latin America, South America and Caribbean), RIPE NCC (Predominantly Europe and Russia), AFRINIC (Africa) and APNIC (Asia Pacific).

When the IANA gives out its last block of IPv4 addresses, every available IPv4 address will be allocated to one of these registries. And that's when the fun will really start. Since SoftLayer operates primarily out of the United States of America, for simplicity's sake, we'll use ARIN as we talk about the next steps for RIRs.

Anyone who's requested large blocks of IPv4 space in the past few years can attest to the significant changes in the request process. Additional justification is required, you have to be using a certain percentage of the IPv4 space you've already been provisioned and you have to get in line.

When the IANA IPv4 address space is exhausted, regional registries like ARIN will still have space available, and that space is all they're going to get. As a result, it'll probably be even harder to get get large blocks of space from those registries.

SoftLayer requests IPv4 space from ARIN for our customers. As ARIN slows the distribution of IPv4 space with additional requirements, it'll be more difficult for providers like SoftLayer to get additional space. In the same way ARIN orders IPv4 space to have stock for SoftLayer to request, SoftLayer has a pool of IPv4 addresses already assigned to us that we provision to our customers' servers.

In Short:

  1. ARIN won't be able to get any more IPv4 space from IANA.
  2. It will be more difficult for SoftLayer to get IPv4 space from ARIN.
  3. It will be more difficult for customers to get IPv4 space from SoftLayer.

How long will ARIN be able to maintain a reserve of IPv4 in the midst of qualified need in the region? How long will SoftLayer continue to receive requested IPv4 address blocks from ARIN? How long will SoftLayer's pool of IPv4 addresses last for our customers? These questions don't have definite answers yet, but for ARIN and SoftLayer, the general answer is "As long as possible."

What Does that Mean for You?

In the short term, it depends. If you find yourself in need of a huge block of IPv4 addresses, you're going to run into a lot more trouble. If you're just ordering a server and need one public IPv4 address, you might not notice much of a difference. If you're somewhere in between, you might see a few changes as we tighten our belts in response to the belts above us being tightened.

In the long term, it means you should prioritize IPv6 adoption. You can run IPv6 in parallel with IPv4 on your SoftLayer servers, and we'll do our best to help you understand how to implement IPv6 in your environment. IPv6 needs to be in the back of your mind as you create new applications and prepare to scale your business.

Consider the possibility that you'll never be able to get another IPv4 address when IANA runs out of IPv4 space. What will that do for your business? How would that change your development priorities? What are the IPv6 plans for the mission-critical hardware/software vendors you use?

IPv6 traffic is only a small fraction of overall Internet traffic right now, but you can be sure that as IPv4 space is harder and harder to come by as you move down the funnel, IPv6 traffic is going to grow exponentially. The work you do in preparing for that will need to be done now or later. It's a lot easier to start working on it now than to wait until you need it ... by that time, it'll already be too late.

-@khazard

Categories: 
Subscribe to arin