This article was written by Barry Bahrami who is the CEO of Commercial Network Services.
In part one, I reviewed the problem created by an internet that has simply become too big for IPv4 addressing. In this part, we will get on to specific issues IPv4 only providers – and their customers – can expect to experience by refusing to support IPv6.
With IPv4 addresses no longer ‘belonging’ to a single customer of an ISP, IPv4 only edge providers will need to rethink their entire internet presence from a technical perspective. For example:
IPv4 only downside on the IPv6 internet
Nuisance traffic can no longer be filtered by IPv4 address at firewalls without potentially impacting legitimate traffic to multiple customers of the same ISP.
Almost every provider has firewall rules set up at their gateways to block nuisance traffic coming from known IP addresses. We see IP addresses blocked by brokers from time to time. Even though the brokers will generally not admit to the trader that their IP is blocked (or simply do not realize it), it becomes obvious when a change of the trader’s IPv4 address quickly resolves the issue for them. After ISPs turn on large scale NAT, these types of rules will instead block ALL traders using the same shared IPv4 address assigned by their ISP.
Logs become more difficult to track activity by IP address because each IP will be more likely to reflect traffic from multiple unrelated users.
When reviewing log activity, we can no longer safely assume that an IPv4 address belongs to one user at any given time. Logs must be analyzed a bit deeper to include user names. Of course activity from users who have not yet logged in may be a problem to review easily.
Firewall rules tracking and blocking attack traffic by IP address will no longer work properly.
Most edge providers have automated rules set up to block attack traffic from unspecified IP addresses. It generally goes something to the effect of “if any IP address sends us too much of (some type of traffic), block ALL traffic from the same IP for a period of time.”
This is obviously a problem because each IPv4 address will in actuality be used by multiple customers of the same ISP. And so if one customer of an ISP becomes infected by a ‘noisy’ virus or simply if multiple customers of the same ISP tries to reach the same edge service around the same time, it will result in a firewall disconnecting other customers of the same ISP (who are sharing the same IPv4 address) through no fault of their own.
Other issues caused by adding an additional layer of NAT
We have not even begun to explore the bugs that may manifest in client and server software when an extra layer of NAT is introduced. NAT can already be problematic for client/server applications and inserting an unnecessary layer of it is never a good thing.
Affiliate Marketing and the Online Brokerage BusinessGo to article >>
Many consumers are already behind the NAT provided by their cable or DSL modem, etc. And many edge providers employ NAT on their internet facing servers for either some layer of security or because they also do not have enough IP addresses to go around.
The IPv4 circuit between the trader and edge provider will no longer be end-to-end once ISPs start inserting their layer of NAT in the middle. Instead, it will go something like NAT (consumer modem)<->NAT (ISP)<->NAT (edge provider).
That’s a lot of NAT! Any IPv4 only client side software that listens for traffic on specific ports will be out of the question. Nobody can possibly say this will likely be trouble free for all retail traders. And that is unfortunate because it does not need to be this way.
While ISPs are actively rolling out IPv6, most edge providers servicing financial services (that I am aware of) are seriously behind. I know of only one VPS provider in our space that issues IPv6 (and IPv4) addresses. That is important so the growing number of users on IPv6 enabled ISP’s can continue to reliably connect to their hosted server without address translation in the middle (a potential point of failure and unnecessary source of increased latency which can degrade the end-user experience).
Lack of support to continue
I reached out to MetaQuotes, NinjaTrader, Spotware systems and Dukascopy to inquire which of their platforms for retail traders support IPv6. Of these popular systems, MetaQuotes says it has no plans to implement IPv6. NinjaTrader has some IPv6 support and is currently evaluating further adaptation. Dukascopy and its API only support IPv4. Spotware did not respond with specific info however since no brokers I know have any IPv6 address space, it would be silly to assume these software titles – or any others – will support IPv6 either.
The most shocking is also probably no surprise to many reading this – MetaQuotes told me: “We don’t support IPv6 and don’t have such plans in the nearest future “. They went on to say: “We have plans to add IPv6 to MetaTrader 5, but that can’t be done in foreseeable future. Platform should be totally rewritten for that.”
It does not sound like a high priority. I am speculating that this is probably because firms buying MetaTrader server do not support IPv6 and so they are not requesting it, a chicken/egg scenario. MetaTrader is perhaps the most popular retail trading platform in the world – and brokers using the platform have no possibility to support IPv6 clients without the software supporting it too. The same goes for all trading platforms.
Providers offering API access to their traders do not fare well in this assessment either. Of the more than 1200 networks peering with CNS, none of the financial service providers have any IPv6 infrastructure. Not a single one. To get an idea how far behind the industry is, take a look at these RIPE statistics measuring the percentage of networks on the entire internet that announce an IPv6 prefix. It’s roughly 25% on the entire internet and quickly increasing.
Keep in mind a ‘network’ in this measurement can consist of one or tens of thousands of users/hosts on the same ISP. Google is reporting the number of IPv6 users accessing their network nearly doubled over just the past year. These numbers clearly demonstrate that financial services are far behind the rest of the Internet in IPv6 deployment.
The likely scenario is that the problem will quietly creep in until one day a big ISP suddenly turns on the IPv4 NAT and brokers support desks are inundated with calls from pockets of seemingly unrelated and very upset traders experiencing odd and inexplicable connectivity issues. Network operations centers at many IPv4 only edge providers will immediately scramble to rework their firewall rules, tune their software configurations and get used to new ways to parse logs.
While this band aid is applied, retail traders will continue to experience connectivity issues. It will, at the very least, be a rough period for everyone involved, with the avoidable potential disaster for traders and brokers quickly becoming inevitable.
Part 3 will review the future of IPv6 in online trading and provide action tips that I hope everyone will promptly adopt to avoid certain issues in the future while also keeping all customers natively connected.