The Pure Blog | Page 3 of 10 | Pure Energy Systems
29 Jun 2019

cPanel Increases Pricing, Potential Chaos Ensues

Yesterday the folks @ cPanel lobbed something of a grenade into the middle of the web hosting industry with a blog post entitled Announcing Account Based Pricing.

Long story short, they are increasing the cost of cPanel for pretty much every situation under the sun effective September 1st. The old pricing model was a flat monthly fee per licensed hosting server, while the new pricing is directly tied to the number of web hosting accounts on the server.

Now, this announcement has sparked a number of reactions, including anger, confusion, and fear from around our industry. We’ve seen reports of providers who believe they will see massive increases in their cPanel costs going forward, with some expressing concern of just how they are going to make the numbers work. These conversations have lead to discussions of providers moving to other platforms, cutting ancillary features out of their offerings to lower costs, or simply closing up shop as they will no longer be able to financially stay above water given the new pricing model.

Some of those reactions and discussions have filtered out from the industry watering holes and into the webmaster forums and chat rooms, to the point we have had more than a couple clients reach out in the last 24 hours asking for information on the topic from our perspective.

With that in mind, even though we don’t yet have 100% of the picture (the pricing being bandied around so far is ‘retail’, we’re not yet sure exactly where our final pricing will land), I wanted to take a moment to discuss both the big picture, as well as what it means for us here at Pure Energy.

In the big picture, things could get dicey for some of the lower cost hosting providers over the next couple months. The lower end market is run on razor thin margins, and, well, I’ll be blunt, it’s hard to stay afloat selling $5/year hosting if your control panel alone is costing you $4/year per account.

For our own environment and business model, we’ll see around a 3x increase in our monthly cPanel license costs, at the retail pricing we’ve seen so far. While not ideal for us, especially coming so closely on the heels of the cost increase we absorbed just a few months ago with the addition of CloudLinux to our servers, at this time I believe we can make the numbers work for our existing Shared Linux Web Hosting plans without a price increase, and without any other substantial changes to our service, plans, or features.

We won’t have 100% of the picture until we get firm pricing from our provider, but to be honest, the bigger concern for us is the uncertainty this injects into the idea of cPanel as a stable platform for our future:

  • Our biggest, as of yet unannounced, project for 2019 was a ‘scratch our own itch’ service that we were hoping to integrate into cPanel pretty tightly and offer to our users as a value added feature of hosting with us, as well as to market the service to other hosting providers as a way to scratch their itch as well. This is on hold (the integration, not the service!) while we see how the cPanel landscape shakes out.
  • A smaller project we had been looking at involved clients who find themselves needing much larger resource allocations than any of our current plans offer. The idea here was larger servers, larger plans, fewer clients per server. We have to re-run the numbers there to see if cPanel still makes sense once we have the finalized pricing.
  • cPanel’s immense popularity has long made it the de-facto ‘go to’ for any provider/service/platform that had a product of interest to the hosting industry. The fallout from this price increase, if it serves to fracture the landscape of providers, could very well jeopardize the dominance that cPanel currently enjoys in the market. If that happens, what happens to the 3rd party interest/support for cPanel?

Some of these are obviously questions that wont be answered for some time, for right now however, things, for us, are status quo. We’ll keep doing the best we can for our clients, keep our eyes on the industry landscape, and keep moving forward.

16 Jun 2019

The Evolution of PHP under Apache

Over the sixteen years we’ve been doing this web hosting thing, we’ve seen a multitude of changes to the way webservers run, and more notably, in how they run scripts under, for instance, languages such as PHP.

 

In the beginning: PHP as CGI

In the beginning running a PHP script was a fairly simple affair.  The Apache webserver of the day used a preforked child based process for handling requests, where the main web server had a pool of child processes, and as each web request came into the server, it would be allocated to a worker, the worker would process that one request, and if a PHP script was involved, a separate CGI process would be spawned out to run PHP and process the scripting part of the page.   There would be a whole slew of settings in your apache configuration that would boil down to “PHP files located in /home/bob/public_html/ get run under the ‘bob’ user account”.

This worked, but it was anything but fast.  As time went on and PHP became more popular, and the sites that it powered became more complex, performance became a big issue, in order to keep things efficient and cost effective, a better way had to be found.

Enter mod_php

Along came mod_php, which sort of up-ended the entire apple cart compared to how we all thought of PHP.   mod_php was an actual module that you linked into Apache itself.  Now your PHP scripts were basically interpreted by the webserver.  No longer did Apache have to ‘spawn out’ another process to render your PHP content.  This was fast.  Then OpCode caching became a thing, with add-ons such as the APC module, where now you could allocate some RAM to be used to persistently cache the PHP code (and possibly other data) in between requests.  Things got extremely fast, and there was much rejoicing on the parts of web hosts everywhere as CPU usage decreased on servers everywhere.

Downside, this meant all PHP scripts needed to run as the same user that Apache ran as.  This meant that everyone’s scripts ran as “nobody”, or possibly “apache”.  Having all the PHP scripts on a server that hosts multiple clients and websites all run under the same security user account was (although I don’t believe anyone initially saw it coming at the time) a huge problem.  The industry started to see a rise in the number of defaced and hijacked sites, and it quickly became evident that the “everything runs as nobody” was to blame.

Malicious actors quickly built PHP scripts that when run, would scour a server, for instance by looking for any *.php files in /home/*/public_html/ on the server, and every time it found a php file it could write to, it would then inject whatever malicious code it desired to spread.  Since all the php scripts on a server ran as the same user, that user account would, by default, need access to all the scripts on the server.   It only took finding one single exploitable script on a website in which they could launch their script to allow the malicious actor to infect (or delete) all the php scripts on the server.  This of course, was not a good solution, as now every script and client account on your server was only as secure as the most out of date, un-patched script on the server!  Something else would need to come along…

(Side Rant:  If, in 2019, you find a web host that is still suggesting that you chown your scripts to “nobody:nobody” or “apache:apache”, be very afraid.  The reasons for this fear should be evident from the last paragraph, but I feel the need to re-iterate the point, because doing so is, well, just a huge mistake security wise!)

SuPHP to the rescue

Then along came SuPHP, which combined most (but not all) of the performance benefits of mod_apache with the flexibility of scripts once again being able to run as individual user accounts.   It was something of a balanced trade off between “fast” and “secure”. 

Apache Gains Workers, But They’re Useless To Us

Along with other great advances to the Apache Web Server, eventually it gained the ability to have ‘Workers’ instead of just ‘Preforked Children Processes’.  While child processes worked fine for years, the overhead of ‘every connection has a dedicated child process that feeds it’ involves a fair amount of overhead.

So the Apache team implemented the ‘Worker’ MPM module.  The server still forks a group of child processes in advance, but each child process is capable of serving multiple http connections via Threads. 

This brought a sizeable boost in performance on hosting servers (notably a decrease in memory needed to service a given number of http connections), but it had one big drawback… it didn’t work with PHP, so it was no good to us for quite some time.

mod_lsapi:  The best of all worlds?

With the recent migration of our servers over to the CloudLinux platform, we’ve gained the ability to leverage the lsapi Apache/PHP interface to achieve a modern ‘best of all worlds’ approach:

  • Apache runs with the mpm_worker module, allowing one child process to handle multiple connections via threads.
  • lsapi interfaces those workers to php via php-fpm as needed when an php file needs to be processed.
  • php-fpm gives us flexibility, security, and performance all in one.

Wait, what’s PHP-FPM?

PHP-FPM is sort of a ‘php server’ if you will.  It is responsible for maintaining a pool of PHP processes that can be handled your PHP code to process.

The flexibility comes in that we can control the version of PHP on a per site level, which is how we can provide the ability for users to control which version of PHP their code runs against.

On the security front, each user has their own self contained php server process, providing a ‘pool’ of PHP processes at their disposal, each running as that user, so no worries about ‘nobody’ permissions or users being able to access each other scripts.

For performance, well, we ‘persist’ the pools per user for a set amount of ‘idle time’ after the last PHP script was processed.  This means that while on the first PHP request for a given client site, we need to (quickly) spin up a PHP process, that process will live-on after the request is finished (up to our idle timeout), if a second request comes in before that time-out ends, it is serviced by the same process, saving start up time, and more importantly, allowing us to once again benefit from the performance boost of PHP OpCode Caching.

The ability to use a PHP pool, when combined with the per-user resource scheduling available to us in CloudLinux, really opens things up possibility wise, allowing us to fairly distribute resources while maintaining performances across all users on a given server.

For instance, here’s the CPU and RAM utilization over a given day for a typical user on one of our shared linux webhosting servers:

cpu and memory graph showing normal traffic activity

Now, this users site got a pretty normal consistent level of traffic throughout the day, it of course had some spikes here and there, but overall, pretty even-keeled distribution of traffic.   You’ll note that the memory usage is pretty even throughout the day, even though CPU jumped a bit more here and there..  This is because even though the clients site may have needed more processing time, the standard PHP process pool for them was already running, and simply kept going handling the visitor load.

Now, lets see what happens when things get… busy.  This customer had a far more interesting day:

cpu and memoryg graph showing peaks caused by a slight DDoS attack

Now, this graph is a bit of an anomaly, not enough to cause a panic, but, well, they were dealing with a slight DDoS attack, in for the form of someone attempting to brute force user logins to their forum.   The traffic was pretty steady throughout the day, but with large spikes in traffic at random times along the way. 

While CPU utilization got pretty intense at times, RAM utilization stayed pretty consistent (most of the time)..   there were a couple times throughout the day when the system determined it was unable to provide all the cpu resources demanded by the attacker, so things did get throttled a bit here and there with the ebb and flow of traffic coming in from the attacker, but the ability for the server to maintain a single, persistent pool of PHP processes to handle the requests, complete with OpCode caching and all the other benefits of reusing the same process for multiple requests, allowed the overall impact to memory to stay pretty consistent throughout the day.

The important thing in this scenario is, that with the persistent php process and OpCode caching being available between requests, the overall load on the server generated by this attack was minimized.  The system did it’s best to maintain service to the client’s website throughout the ‘bursty’ attack periods, and no other client sites hosted on the same server saw any impact at all.

This is a huge change from the days of ‘PHP as CGI’, and we’re confident that Apache Workers + mod_lsapi + php-fpm gives us just the right combination of security, flexibility, and performance going forward to best serve our clients.

 

17 May 2019

Git: Now available across all our hosting plans

logo of the git software projectWe’re happy to announce the immediate availability of Git repository hosting as a standard feature for all of our shared hosting linux plans.

Git is a distributed version control system, allowing you a safe and effective means of tracking revisions and edits to your source code.  The predominate use-case for Git by our clients would be, of course, storing and tracking the web code that powers your site, but I’m sure some enterprising clients will find other, additional uses for it.

The Git repository management section of cPanel can be found under the “Files” section of your cPanel interface, via the icon labeled “Git Version Control”.

The deployment of git repository hosting builds on-top of the same security and resource management feature additions that enabled us to bring about the return of secure shell access previously.  Research (disk/cpu/bandwidth) usage via Git is shared and accounted for within your account’s base cPanel allocations.  (In other words, if your Git repo is 50MB in size, that 50MB of disk space will count against your accounts normal Disk Quota allotment.)

10 Mar 2019

Python support is here!

We’re happy to announce the immediate availability of Python support across all of our Shared Linux Web Hosting Plans.  This opens the possibilities of building your web application using Django, Wagtail, Web2Py, or any other modern web framework that’s written in Python.

We currently support Python 2.7, 3.3, 3.4, 3.5, 3.6, and 3.7 across all our servers.

Users can deploy a new Python application into their account by looking for the “Setup Python App” icon under the “Software” section in cPanel.   You’ll be prompted to select the Python version you wish to use, where the application should live folder wise (we do not recommend hosting them out of your public_html folder!), and the URL you want to associate with the application.

Once setup, cpanel will build a python virtual environment for you using the version you selected, and will deploy a simple “Hello World!” style python application into the folder.  You can then modify/build/create to your hearts content using python.

02 Mar 2019

Current Domain Promotions

Quite a few promotional offers on domain registrations (and also some on renewals and transfers as well!) currently being offered by the various registrars, wanted to just take a moment and spread the word on some deals to be found.  As always our client portal has been updated with the most recent pricing and is standing by to help you with your domain registration needs.

 

Domain TLDActionNormal PricePromotional PricePromotion End Date
.accountant1 Year Registration29.2215.722019-09-30 23:59:59 UTC
.accountant1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.accountantTransfer29.2215.722019-09-30 23:59:59 UTC
.accountants1 Year Registration91.4411.482019-03-31 23:59:59 UTC
.actor1 Year Registration36.547.852019-03-31 23:59:59 UTC
.archi1 Year Registration59.7214.512019-06-30 23:59:59 UTC
.auction1 Year Registration29.227.852019-03-31 23:59:59 UTC
.band1 Year Registration28.005.992019-03-31 23:59:59 UTC
.bio1 Year Registration58.5014.512019-06-30 23:59:59 UTC
.black1 Year Registration46.3014.512019-06-30 23:59:59 UTC
.blog1 Year Registration28.059.062019-06-30 23:59:59 UTC
.blue1 Year Registration15.804.482019-06-30 23:59:59 UTC
.capetown1 Year Registration30.443.012019-03-31 23:59:59 UTC
.city1 Year Registration22.814.832019-03-31 23:59:59 UTC
.co1 Year Registration32.3312.102019-12-31 23:59:59 UTC
.consulting1 Year Registration31.6611.482019-03-31 23:59:59 UTC
.cricket1 Year Renewal73.144.222019-09-30 23:59:59 UTC
.cricket1 Year Registration73.1415.722019-09-30 23:59:59 UTC
.cricketTransfer73.1415.722019-09-30 23:59:59 UTC
.date1 Year Registration29.224.222019-09-30 23:59:59 UTC
.dateTransfer29.224.222019-09-30 23:59:59 UTC
.date1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.download1 Year Registration29.224.222019-09-30 23:59:59 UTC
.downloadTransfer29.224.222019-09-30 23:59:59 UTC
.download1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.durban1 Year Registration30.443.012019-03-31 23:59:59 UTC
.email1 Year Registration22.814.832019-03-31 23:59:59 UTC
.eu1 Year Registration9.633.392019-12-31 23:59:59 UTC
.faith1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.faith1 Year Registration29.228.462019-09-30 23:59:59 UTC
.faithTransfer29.228.462019-09-30 23:59:59 UTC
.green1 Year Registration73.1414.512019-06-30 23:59:59 UTC
.group1 Year Registration22.817.852019-03-31 23:59:59 UTC
.guru1 Year Registration33.547.852019-03-31 23:59:59 UTC
.investments1 Year Registration91.507.852019-03-31 23:59:59 UTC
.joburg1 Year Registration30.443.012019-03-31 23:59:59 UTC
.kim1 Year Registration14.584.482019-06-30 23:59:59 UTC
.lgbt1 Year Registration42.6414.512019-06-30 23:59:59 UTC
.life1 Year Registration33.544.832019-03-31 23:59:59 UTC
.live1 Year Registration21.903.012019-03-31 23:59:59 UTC
.loan1 Year Registration29.224.222019-09-30 23:59:59 UTC
.loanTransfer29.224.222019-09-30 23:59:59 UTC
.loan1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.london1 Year Registration36.549.672019-06-30 23:59:59 UTC
.ltd1 Year Registration22.817.852019-03-31 23:59:59 UTC
.market1 Year Registration29.2216.322019-03-31 23:59:59 UTC
.men1 Year Registration29.224.222019-09-30 23:59:59 UTC
.menTransfer29.224.222019-09-30 23:59:59 UTC
.men1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.mx1 Year Registration54.6612.692019-03-31 23:59:59 UTC
.news1 Year Registration21.9011.482019-03-31 23:59:59 UTC
.ninja1 Year Registration36.547.852019-03-31 23:59:59 UTC
.ooo1 Year Registration29.222.412019-03-31 23:59:59 UTC
.party1 Year Registration29.224.222019-09-30 23:59:59 UTC
.partyTransfer29.224.222019-09-30 23:59:59 UTC
.party1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.pet1 Year Registration15.804.482019-06-30 23:59:59 UTC
.photography1 Year Registration22.817.852019-03-31 23:59:59 UTC
.pink1 Year Registration15.804.482019-06-30 23:59:59 UTC
.poker1 Year Registration46.3014.512019-06-30 23:59:59 UTC
.pub1 Year Registration32.887.852019-03-31 23:59:59 UTC
.racing1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.racing1 Year Registration29.228.462019-09-30 23:59:59 UTC
.racingTransfer29.228.462019-09-30 23:59:59 UTC
.red1 Year Registration15.804.482019-06-30 23:59:59 UTC
.review1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.review1 Year Registration29.228.462019-09-30 23:59:59 UTC
.reviewTransfer29.228.462019-09-30 23:59:59 UTC
.reviews1 Year Registration43.867.852019-03-31 23:59:59 UTC
.rocks1 Year Registration13.364.832019-03-31 23:59:59 UTC
.science1 Year Registration29.224.222019-09-30 23:59:59 UTC
.scienceTransfer29.224.222019-09-30 23:59:59 UTC
.science1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.shoes1 Year Registration53.7516.322019-03-31 23:59:59 UTC
.ski1 Year Registration41.4214.512019-06-30 23:59:59 UTC
.social1 Year Registration60.9411.482019-03-31 23:59:59 UTC
.software1 Year Registration29.227.852019-03-31 23:59:59 UTC
.solutions1 Year Registration22.817.852019-03-31 23:59:59 UTC
.stream1 Year Registration28.034.222019-09-30 23:59:59 UTC
.streamTransfer28.034.222019-09-30 23:59:59 UTC
.stream1 Year Renewal28.034.222019-09-30 23:59:59 UTC
.studio1 Year Registration21.9011.482019-03-31 23:59:59 UTC
.systems1 Year Registration22.817.852019-03-31 23:59:59 UTC
.tips1 Year Registration22.8111.482019-03-31 23:59:59 UTC
.today1 Year Registration21.464.832019-03-31 23:59:59 UTC
.top1 Year Registration9.703.012019-03-31 23:59:59 UTC
.topTransfer9.706.642019-03-31 23:59:59 UTC
.top1 Year Renewal9.706.642019-03-31 23:59:59 UTC
.toys1 Year Registration53.757.852019-03-31 23:59:59 UTC
.trade1 Year Registration29.224.222019-09-30 23:59:59 UTC
.tradeTransfer29.224.222019-09-30 23:59:59 UTC
.trade1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.us1 Year Registration10.074.832019-12-31 23:59:59 UTC
.webcam1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.webcam1 Year Registration29.228.462019-09-30 23:59:59 UTC
.webcamTransfer29.228.462019-09-30 23:59:59 UTC
.win1 Year Registration29.224.222019-09-30 23:59:59 UTC
.winTransfer29.224.222019-09-30 23:59:59 UTC
.win1 Year Renewal29.224.222019-09-30 23:59:59 UTC
.works1 Year Registration33.544.832019-03-31 23:59:59 UTC
.world1 Year Registration33.543.012019-03-31 23:59:59 UTC
.zone1 Year Registration33.544.832019-03-31 23:59:59 UTC

24 Feb 2019

HTTP/2 Now Standard

In the wake of our recent server platform upgrades, we’re happy to announce that as of this weekend, all of our shared linux web servers now support HTTP/2.   This is another one of those ‘under the hood’ silent updates that will help increase performance of websites when accessed via modern browsers, with no action required on anyone’s part to enable or benefit from the change.

 

02 Feb 2019

All Shared Hosting Plans Doubled in Size!

Resource upgrades are here!  We’ve been hinting about it pretty blatantly.   We’ve been itching to get this nailed down for a bit now, as it’s been a while since the last time we had any resource adjustments to the plans.  But we wanted to get all of our ducks in a row to maximize the potential impact before announcing any changes… and we’re very happy with the end-result!

Today we’re happy to announce a rather large upgrade to the Disk Space and Bandwidth allocations that come standard with all of our Shared Hosting Plans:

  • Linux Bronze – $5.95/month
    • Was 400MB Disk Space  |   8GB Bandwidth
    • Now 800MB Disk Space  |  16GB Bandwidth
  • Linux Bronze+ – $7.95/month
    • Was 600MB Disk Space  |  15GB Bandwidth
    • Now 1200MB Disk Space  |  30GB Bandwidth
  • Linux Bronze++ – $9.95/month
    • Was 900MB Disk Space  |  20GB Bandwidth
    • Now 1800MB Disk Space  |  40GB Bandwidth
  • Linux Silver – $14.95/month
    • Was 1536MB Disk Space  |  30GB Bandwidth
    • Now 3072MB Disk Space  |  60GB Bandwidth
  • Linux Silver+ – $19.95/month
    • Was 2048MB Disk Space  |  40GB Bandwidth
    • Now 4096MB Disk Space  |  80GB Bandwidth
  • Linux Gold – $29.95/month
    • Was 4096MB Disk Space  |  80GB Bandwidth
    • Now 8192MB Disk Space  |  160GB Bandwidth

 

Yes, that is correct, we’re doubling the amount of resources available in every plan.

No action is required on anyone’s part to take advantage of these new plans, all existing clients have already had their resource allocations increased to the new levels.

 

27 Jan 2019

ModSecurity: Default on Every Plan

Back in November we discussed the need for web application firewalls and discussed some of the options out there for securing your site with one.  And, well, shortly there after someone reminded me:

Hey, wait, don’t we have ModSecurity implemented everywhere?

Oh yeah, ModSecurity, the old faithful of generic purpose WAF systems.   To be honest, we’ve run it across all of our servers for at-least a year now, silently, in the background, with nobody noticing.  We’re currently utilizing the OWASP Core Ruleset on all of our servers, and while it does detect and prevent a wide range of ‘standard issue’ web based attacks (Cross Site Scripting, Code Injection, SQL Injection, etc), the fact is, it’s we have to be deliberately conservative in what we detect and block at the server level.  Something that may be ‘fishy’ under to one website or code stack could be ‘business as usual’ on another site, so it’s not possible for us to make the rules “extremely secure”, because we don’t want to incorrectly block traffic that someone may actually need for their site to function.

Think of our ModSecurity implementation as a ‘first line defense’, it’s keeping an eye out for the really unscrupulous traffic, the things that we can look at and say “no way that can be legit traffic!”.  But the more granular, focused, specific needs of a given web platform? That’s where the need for a Web Application Firewall specific to your own site and needs comes in.

One thing we have rolled out in the last couple weeks, just in case, is the ability for clients to disable ModSecurity on a given domain under their account.  We don’t recommend it, and I believe we’ve only had one instance of a client really really wanting to do it, but that option is there now.  By default, we enable it everywhere, but if you go into cPanel, under the “Security” section, there’s now a ModSecurity area where you can disable it on a per domain basis.  It’ll warn you that this is potentially unsafe, and not recommended outside of debugging purposes (usually to prove that it’s not ModSecurity causing an issue with a site), but, if you need it, the option is there.

26 Jan 2019

IPv6: Ready, but not yet Prime-Time

IPv6 is one of those weird tech initiatives, in that it’s something everyone seems to agree needs to happen, but actually getting there is just taking way longer than everyone seemed to think it would. We’ve been running IPv6 on many of our own platforms and services for a while now, but coverage has not been 100%, nor had we fully deployed it to customer hosting servers and websites, until now.  Today we’re happy to announce that all customer sites and services are now fully available via IPv6.  Now,  odds are, either you’re reading this and going “Nice”, or you’re going “What the heck is IPv6?”, so lets take a quick moment to cover some likely questions you may have…

What is IPv6 and why do we need it?

Every device that’s directly connected to the Internet needs a unique address that identifies that specific machine.  The internet as we’ve had it all these years runs on a protocol called IP, more specifically, IPv4.  IPv4 gives us unique 32bit addresses that look like this:   139.197.254.128.   Then we use DNS to tell the world “www.purenrg.com = 139.197.254.128”, when you enter or click on our website URL, your computer looks up the DNS name, and gets back that unique address, and that’s how it knows where to connect to pull up our site.

IPv4 addresses can range from “0.0.0.0” to “255.255.255.255”, giving a little under 4.3 billion possible unique addresses ( I hear the deep tech folks groaning already, but bear with me).. due to the way IP address are carved up into into subnets, and the way a number of ranges were reserved for other uses way back in the early days of the Internet, we don’t actually have that many to go around.   Over half a billion where marked ‘reserved’ right off the bat for things like “inside” network space, multicast, etc, so the true number of usable IPv4 addresses is quite a bit smaller than 4.3 billion.

Now, keep in mind, while the Internet as we now enjoy it didn’t exist quite yet, IPv4 was designed in the early 1980s, so at that time, I’m sure the idea of “more than 4 billion devices all sharing the same global network” seemed like “Yeah, that’s not going to be a problem, ever!”   But of course, over the years, we’ve, well, we’ve used them up.  It’s been an ongoing issue for quite some time, but there have been workarounds that have kept things going without major issue:

  • NAT/Proxies/Firewalls.   Odds are you probably have more than one internet connected device in your house.  PCs, laptops, tablets, gaming systems, cameras, etc.  They all have an IP address, but likely not a “public” IP address.  It’s fairly common practice for your ISP to provide some sort of gateway/router device that actually obtains one public IP address, and then handles NAT for all of the devices inside your home.
  • Some of the previously “reserved” space has been “unreserved” and allocated out to the regional registries.
  • Some larger companies that hard large swaths of IP space allocated to them have returned some, or in other cases no longer function as entities and returned huge swaths to be redistributed.  (HP, or companies they merged with/acquired over the years at one point had 64 million IPs that they turned back to the registries)

I don’t want to veer too far into the discussion of IPv4 Exhaustion, but the wiki page linked there gives a great overview of how we got here.  But the basic gist is, while IPv4 got us to where we are today, something different is going to have to take over at some point.

Where did this whole IPv6 thing come from?

Thankfully, in the early 1990s (even then, the Internet was still not “the thing” it is today), someone had the foresight to think that 4.3billion might one day not be enough addresses, so a bunch of folks got together and started brainstorming.   While early versions of IPv6 support made it into things like the Linux kernel in mid 90s, we actually didn’t have a “Draft Standard” for IPv6 until late in 1998, and it didn’t become a true “Internet Standard” until July 2017.  These things, clearly, take time.

So what does IPv6 bring us?  Well, an IPv6 address looks like this:

2604:a880:0:1010:0:0:76:7001   (Again, our main website)

It’s a mouth-full, no doubt, and it’s going to make all of us even more dependent on DNS than we are today.  But, it’s a 128bit address.  That means instead of the 4.3billion possibilities, we now have…  well, billions and billions of possible addresses.  (340 billion billion billion billion addresses, give or take).  So yeah, it should solve our IP address shortage.

Why is it taking so long?

It’s taken quite a while just to get the standard nailed down.  And it’s taken even longer to figure out exactly how to implement it in every scenario.  Then you have the classic adoption problem, nobody wants to be the first ISP to offer “IPv6 only” access, if there’s shortage of content available on IPv6, so ISPs continue to scrounge around and find more IPv4 addresses they can utilize, and (as far as I’m aware), nobody has (yet) been forced into “IPv6 Only” land.

And until there are customers on the IPv6 network, there’s no push on the content providers into offering content on IPv6….  Chicken, meet egg.

Dual Stack implementations solve for this, in that with a Dual Stack configuration, you give your machine both an IPv4, and an IPv6 address, and you can be connected to and connect to others via either one.

So for instance, all of our servers now have an address in both IPv4 and IPv6.  We tell things like our web server to listen on both, and now we’re accessible on both addresses.  Then we publish both via DNS (While IPv4 addresses are stored in ‘A’ records, DNS has a separate ‘AAAA’ record for IPv6 addresses.)

So now, the content is there, even if the visitors are not, just yet, there in large numbers.

So what does IPv6 mean for me?

All the “under the hood” work to make this work for your sites hosted with us is already done.  All of our servers now run in Dual Stack mode, and we’ve ensured web, mail, and other services on every box are listening on both the IPv4 and IPv6 addresses.

So in general, not a whole lot really changes for you just yet, but it’s something you’ll want to be aware of, especially if you write your own code for your website.  You’re going to start seeing those “new, longer addresses” show up in things like your website logs, and at first, it’s going to be a bit confusing and unsettling. 😉

Here’s the part that will blow your mind (it blew mine), there’s a chance, however small, that you may be using IPv6 to read this right now and not even know it.  Many of the ISPs that have started implementing IPv6 are doing so with Dual Stack implementations, quietly, in the background.  A couple days after implementing IPv6 on our own website, we noticed the IPv6 addresses appearing in our client portal logs.  Clients were connecting to the site via IPv6, and they probably didn’t even know it.  That’s, quite honestly,  rather astonishing for something as fundamental to the Internet as IP, that the entire thing can be shifted around under the hood, and a visitor doesn’t even need to notice it.

While most ISPs are being fairly quiet about their embrace of IPv6, there are some larger, established ISPs starting to really make inroads with IPv6, and the number of folks who have IPv6 available to them continues to climb.  It’s not ready to take over the world yet, obviously.  Or own internal observations from our servers show about 3-5% of our traffic comes in over IPv6, and I believe that number is slightly skewed higher by our own servers preferring to talk with one another on IPv6.

But the data consumers are starting to arrive via IPv6, and now with this rollout, we’re ready for them.

If you are interested in finding out the state of your own internet connection, and if it is IPv6 enabled, feel free to visit the IPv6 Test website.

(c) 2020 Pure Energy Systems LLC - All rights reserved.

back to top