Slashdot Mirror
Microsoft Runs Out of US Address Space For Azure, Taps Its Global IPv4 Stock
alphadogg (971356) writes "Microsoft has been forced to start using its global stock of IPv4 addresses to keep its Azure cloud service afloat in the U.S., highlighting the growing importance of making the shift to IP version 6. The newer version of the Internet Protocol adds an almost inexhaustible number of addresses thanks to a 128-bit long address field, compared to the 32 bits used by version 4. The IPv4 address space has been fully assigned in the U.S., meaning there are no additional addresses available, Microsoft said in a blog post earlier this week. This requires the company to use the IPv4 address space available to it globally for new services, it said."
So after years of panic, someone finally ran out of IPs. No, wait a minute... They still didn't.
OR they could migrate those services to IPv6??
Considering how much bashing MS gets for not being a leader, this would have made a really good opportunity for them.
(I hate it when people say they're doing something because they were "forced" or "had no choice", when in reality, they had aa choice, they made a choice, and now don't want to take ownership of the outcome)
I work for the Department of Redundancy Department.
It means that when I deployed a new virtual desktop in Azure and specified "East US" as the data center location, services that looked at the IP address thought I was in Brazil or Germany. Which played hell with Google when I started Chrome because it customized the language for the area it thought I was in. That explains a lot.
I pretty sure this just means Microsoft ran out of IPv4 addresses that they bought for the specific purpose of their Azure service, so they are now "borrowing" addresses from their other address pools. This also means their Azure services are no longer one continuous block of addresses.
IP blocks are meant to be a drill-down system. For example, 128.230.x.x is indicates it's on the Syracuse University campus.... with the 16 bits worth of addresses being spread out so that a specific x in the third position would indicate what building to send the packet to.
Microsoft's problem here is that their Azure service has used every one of the IP addresses allocated to it... and Microsoft doesn't have any subnets remaining in the "USA Block" of their IP addresses... so they have to move IPs that would have been used overseas back into the Azure datacenter. As IPv4 continues to be used we're going to start to see more of these "we're running out!" stories.
It's never to late to procrastinate.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
If you called MS support you would have learned that you should have used Internet Explorer, not Chrome!
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
I tried to use Azure, but all of my EU-hosted virtual machines geolocated to US, and I wanted none of that.
Well, now you have a random chance of geolocating to the EU (or S America, or somewhere else)....
It would have made more sense for them to use the EU blocks they owned to host Azure EU services, but they just used their US Azure block until it was full.
One other thing this breaks, is that before you could set up a VPN service on local Azure and the world would think you were in the US. Now it's going to be the reverse. This will break any Azure services that are pulling data only allowed to those in the US.
That is one of Googles great stupidities.
Just because I log in I via a French public hotspot, or a Dutch customers WLAN, doesn't mean I now magically speak French or Dutch, so why does Google switch everything to French and Dutch, despite all my OS and Browser settings still indicating German as primary language, with English as fallback?
Amazingly IPv6 will be sufficient for a long time:
2^128 IPv6 addresses * (1 atom / address) / (7*10^27 atoms/human) = 48 billion humans.
Actually, why not solve it for all time? Given the estimate of 10^80 particles in the universe, then moving to 266 bit addressing (i.e. 80/log(2)) would allow each particle to be addressed individually. Bumping to 512 bit addressing would accommodate the typical logical addressing inefficiencies.
Because, for 90% of business, the only guy who needs to care about the IP address is the IT department.
And they rarely deal with IP addresses and when they do it's mostly copy/paste from some spreadsheet or management program.
Nobody cares what the IP is, nobody memorises what the IP is (maybe fleetingly to type it in somewhere else, but pretty much that's a one-time thing. DHCP takes away all internal IP management apart from the occasional fixed static which is no worse than having asset numbers (which you still have to deal with).
As such, memorable IP numbering is not the problem. Never was. I don't know what the IP is of my external servers, I don't really care. I have them somewhere, no doubt, but who cares? You point the DNS at it once and you're done. You allocate the lease pool and you're done. About the only IP number the average IT team must know are the DNS servers and the default gateway (which is usually .1 for reasons that have everything to do with ease of remembering).
Large corporations don't have a guy memorising the IP's. If anything, they are even more in the dark about exactly what IP's they have and they use, because they never see them except in some asset management program.
When you go to IPv6, it's even less important. Just forget about it. Stick the IPv6 of your DNS into your DHCP servers and you NEVER have to know a single IPv6 address again. In fact, a lot of setups I've seen have this without even knowing - you can be running IPv6 without even realising until something goes wrong and you spot an IPv6 address.
Stop the damn excuses. Deploy IPv6. You want that many IP's, you need to have unwieldy numberings. If you want to assign, say, an alphanumeric code instead of a purely numeric one, it only helps for so long (and we'd have put all our IPv4's into hexadecimal if it didn't).
Nobody cares about SID's, MAC's, GUID's, UUID's, etc. and they are just as long. Get in the real world - where it DOES NOT MATTER how long the data is, your setup just uses technologies and protocols available today to make them memorable where they need to be.
If only your browser sent a header telling the server what your preferred language was. Oh, wait, it does, and Google still thinks that I want to go to their Japanese page when I'm in Japan. One of the many reasons I switched to DuckDuckGo a few years ago...
I am TheRaven on Soylent News
Hopefully everyone in this thread is joking, but it's worth noting that it's not quite that clear cut. The smallest assignment that an ISP can hand out is a /64, so you can really only have 2^64 sites. IPv6 has 2^128 addresses, but a lot of the design works around having sparse routing tables. You really want each /64 to correspond to a broadcast domain, and you don't want to fragment the routing tables too much to get to the /64, so you've actually got a lot fewer addresses. A /64 per human is not enough to assign one IP per atom in the person, but it likely is enough for every device that a person may reasonably want to own and give an IP to, even if that person has a lot of injected sensor nodes.
I am TheRaven on Soylent News
I think the deniers are the same people, with the same arguments.
It's easy to spot the people who don't know what they're talking about. Over the last few days:
1) Just re-assign multicast!
2) Hey, they don't appear to be using those addresses, let's take those!
3) Double/Triple-NAT is good enough for me and everyone else!
4) Let's give out one IP address to everyone and we'll be set for awhile!
5) Let's make a new protocol!
6) IPv6 addresses are too big to remember!
7) You just need to sell it better!
All of those show fundamental misunderstandings about networking. And that part is OK. The problem is that people think they know about flying a plane because they've flown a paper airplane.
Calm down people. Stop trying to barge into the cockpit.
Leave it to Microsoft to screw up the map.
No we won't. Anybody who thinks this doesn't understand how large 2^128 is.
(If you disagree with me, try to back it up with actual numbers.)
Many end users have IPv6 support. Many servers are capable of it. The issue is mostly the US ISPs and middle-tier transit providers dragging their feet. My systems all support IPv6, my m0n0wall box supports it, but neither of the two ISPs I can buy service from support it. In fact they won't sell it to me even if I offer to pay extra money for it!
My pet theory is that Verizon et al wants to convert IPv4 address space into a "resource" they can buy/sell/trade. A bunch of lawyers and MBAs are rubbing their greedy fingers together, hoping we stay in a "resource shortage" for as long as possible.
We could switch over, probably within a year or two, but it would take a government-imposed mandate to force people to stop screwing around and make the change.
Natural != (nontoxic || beneficial)
Don't Panic, or be afraid of IPv6.
People often talk of "switching" to IPv6. One does not "switch". You simply deploy it alongside IPv4. Right now my home network is happily running IPv4 and IPv6 at the same time, called a "dual-stack" environment. This sort of set up will be common for decades until IPv4 use dwindles to nothing, and people start turning it off.
Nearly all operating systems and devices supporting IPv6 have it turned on by default, so you're already running IPv6. You just don't have globally routable addresses assigned (most likely). You could actually use ping (windows) and ping6 (*nix) to ping other hosts on your LAN using link local addresses, which have automatically been assigned (see those addresses starting with fe80 on all of your interfaces?), if you knew how, right now. :-)
If you know IPv4 routing and subnetting, you already know most of what you need to know about IPv6. Except that IPv6 is simpler since there's no need to NAT. Just set up your firewall exactly as you would under IPv4 (same security policy), minus the NAT. Subnetting is also simpler, with no need to fret over "right sizing" your subnets so they're "just big enough" and don't use too much of your precious IPv4 space. Just assign a /64 out of your /48 (businesses will be easily be able to request multiple /48s) and you're done. Never run out of host numbers, or subnets.
Some folks are frightened by the use of hexadecimal for IPv6 addresses. No need to fret. It makes sense, and would have made sense for IPv4 also. Hex for IPv6 not only makes the IPv6 addresses more compact., it's also far easier to translate hex into binary, and work with prefix-lengths than decimal IPv4 address are. I can do it in my head all day with no issue. All you have to do is memorize 16 bin patterns from 0000 to 1111, each represents a hex digit from 0 - F. Piece of cake. No more annoying math and base conversion to try to figure out which subnet some IPv6 address belongs to like with IPv4. No more subnet masks either (which are also decimal), instead, just prefix lengths (although this is also true of IPv4 with CIDR, adopted long ago, many user interfaces still require a netmask for IPv4 instead of just a /prefix-length, sigh).
Anyway. Go play with IPv6. It will be an essential skill to add to your Resume/CV, and will only take a short time to figure out. Go set up an tunnel with Hurricane Electric or some other tunnel broker to get some globally routable IPv6s. It's simple and you'll learn a lot and quickly! And best of all, you'll stop being afraid of IPv6! :-)
(apologies to those who already have adopted IPv6 and know all this already ... this isn't addressed to you!)