Thursday, August 20, 2015

BT survey indicates movement on IPv6 deployments

We recently invited network engineers to participate in an online industry survey to characterize opinions and attitudes about IPv6 deployment in their networks. We’ve conducted this survey for five years running now, and we’ve observed a steady climb in the proportion of survey participants who have deployed or were actively deploying IPv6. This year’s survey didn’t disappoint, as we saw continued IPv6 deployment progress with over half of survey participants indicating they had deployed or were in the process of deploying IPv6. This tally represented a fifteen percent higher proportion that in last year’s survey.

Deploying IPv6 is necessary for organizations to continue to communicate with all users on the “total Internet,” which is slowly evolving from a homogeneous IPv4 Internet to a mixed protocol IPv4-IPv6 Internet. Evidence of such an evolution is visible from various industry measurements, such as the proportion of Google users accessing their sites via IPv6 and’s measurements of IPv6 use globally and by country for web and email servers and DNS.

In the face of evaporating of IPv4 address space availability, growth of the Internet is accelerating due to new Internet users, new and multiple mobile devices for Internet users, and non-user devices or “things” spurring the emergence of the Internet of Things (IoT). Internet accessibility for these users and things will by necessity require IPv6.

Unfortunately IPv4 and IPv6 are not interoperable, so organizations desiring to communicate with these users and things, members of today’s growing total Internet, must support both IPv4 and IPv6. In fact, three of four survey respondents agreed that continued global Internet presence was a key benefit to deploying IPv6. And most survey respondents deploying IPv6 use a dual stack approach to enable Internet reachability via either protocol for their web, email and other Internet-reachable application servers.

Survey results also yielded some interesting shifts in attitudes about IPv6. As the reality of IPv4 address space exhaustion materializes, organizations are becoming more accepting of the need for IPv6 and are increasingly bullish about IPv6’s benefits and value.  For example, survey respondents from organizations that have or are deploying IPv6 recognized as top benefits offering a competitive advantage, supporting IoT initiatives, spurring innovative applications, and enabling a continued global Internet presence.

This year’s survey once again signified that the inability to demonstrate a strong business case was the leading obstacle to IPv6 deployment, followed by the complexity of infrastructure upgrades, conversion of applications or middleware, and staff training. These concerns represent a shift away from networking focused issues from past surveys to those of practical implementation and support, another indicator of attitude shift favoring deployment.

BT’s IPv6 survey findings and public IPv6 measurements corroborate increasing IPv6 deployment worldwide. We’d recommend that organizations that rely on Internet communications for ubiquitous Internet access to resources, collaboration, or commerce start planning for IPv6 deployment if they haven’t done so already. And BT can help along the way, with Advise services to assist with IPv6 deployment planning, execution and management and IP address management (IPAM) solutions from Diamond IP to enable IPv4-IPv6 address planning, discovery and management.  We invite you to review our full survey results and analysis in our survey report.

Monday, July 27, 2015

IPv6 deployments growing steadily though not exponentially (yet)

The percentage of users of google's websites accessing via IPv6 has reached 8% for the first time last week, essentially doubling up the percentage from only a bit more than a year ago. It was then, a year ago that I had last blogged about predicting future IPv6 adoption trends based on "curve fitting" historical measurements. At that time, the predictions for the end of 2014 indicated 6.2% for the exponential growth model, while the polynomial model predicted 5.6%. The actual measurement was 5.7%.

As illustrated in the graph below with curve fits based on the most recent data, the exponential curve, the top (green) curve is certainly the most ambitious as it was last year. It predicts the percentage of IPv6 users accessing google's sites at 11.4% by the end of this year and over 25% by the end of next. Meanwhile the polynomial curve fits are more conservative predicting 8-9% by the end of this year and 12-15% by the end of next.

While IPv6 adoption growth hasn't "gone exponential" just yet, could the exhaustion of IPv4 space most recently within the ARIN region  (mostly N. America), following RIPE (Europe) and APNIC (Asia) serve as the catalyst to drive IPv6 deployment growth exponentially? Further requirements for IP address space must by necessity be filled by IPv6 address space, unless an IPv4 address exchange can be brokered.

But even if no additional IP space is needed, the population of IPv6 capable Internet users is clearly growing. Are they able to access your website? Where do you stand with IPv6 deployment? You can make your opinions known by completing our annual IPv6 survey.   They survey takes only five minutes to complete and you can register to win a $100 Visa gift card, the winner of which will be selected randomly among participants. Hurry, the survey closes at the end of July.

Tuesday, March 3, 2015

Will the IoT be the IPv6 killer app?

The Internet of Things (IoT) refers to the extension of today’s Internet beyond connectivity and interaction among traditional user-operated devices like PCs, tablets, phones and like types of devices into the realm of connectivity and interaction with non-user operated devices such as sensors, monitors and remotely controllable devices. Internet-enabling such “unmanned” devices allows these devices to autonomously report updates, status changes, events, or to perform actions commanded by users or other devices via the Internet. Examples of such “things” commonly in use today range from consumer goods to devices supporting business initiatives such as those in support of the following example applications.
  • Smart initiatives – providing a centralized view of yet unrealized volumes of data for more intelligence resource management and customer service such as:
    • Smart Grid – Dynamic matching of electricity, water, gas, etc. supply with demand, reducing resource waste and saving consumers on utility bills.
    • Smart Cars – Diagnostic and usage sensors within an automobile for performance reporting, troubleshooting and customer notification of worn components and recommended service check-ups as well as automated crash detection and reporting.
    • Smart Homes – Remote monitoring of premises, smart appliances, remote control of power, heating/cooling, lighting, entertainment, and access.
  • Municipal (smart cities) and industrial surveillance and monitoring – physical access control and monitoring, environmental monitoring for extreme conditions (e.g., natural disaster, fire, floods), structural monitoring and traffic monitoring.
  • Field applications – fleet management, dispatch, tracking and vehicle telematics.
  • Healthcare – fitness tracking, remote monitoring of patients’ vital signs, diagnostics and medication administration, “body area networks,” monitoring of storage environments, e.g., for plasma, organs.
  • Industrial – factory line monitoring, diagnostics, resource control, supply chain management, process monitoring and control leveraging improved accessibility that wireless provides.
  • Military – battlefield ad hoc networks with various soldier sensors reporting status updates to military command.
As implied by this list of applications, the key benefit of deploying such things is to extend the visibility, reach and control of a user or organization, providing more information for better insights and control with minimal incremental costs. These applications and others like them may require deployment of hundreds, thousands, even millions of sensor devices whose measurements and status information must be communicated to a centralized application server for processing, analytics and presentation. The confluence of advancements in wireless communications and networking, device miniaturization, battery technology, big data analytics, and application innovations has fueled seemingly limitless possibilities for Internet-connected things, and is constrained only by the imagination of device manufacturers and application developers.

IPv6 is likewise an enabler of IoT in one sense by its sheer address capacity in supporting millions of things (tens of billions by 2020 according to many analysts). When IoT devices are deployed within the confines of an enterprise network for use in internal network applications such as factory automation, surveillance, etc., use of private IPv4 space could provide sufficient address capacity depending on the quantities of things and existing allocations of private space. When public IP addresses are required by things, to literally connect to the Internet, IPv6 addressing may become necessary if not the default, given the general lack of available public IPv4 address space.

Beyond address capacity, certain applications may require ad hoc networking capabilities where things may require address autoconfiguration to “self-initialize” on the IP network or Internet based on local access connectivity. If Dynamic Host Configuration Protocol (DHCP) servers are not provisioned, the stateless address autoconfiguration (SLAAC) feature of IPv6 enables things to detect local network addressing and to auto-assign their IPv6 addresses.

The IPv6 SLAAC feature provides automation with agility for ad hoc Internet access, though it raises potential network access control concerns from a network manager’s perspective. In such cases, provision for security, access control and IP address management (IPAM) solutions becomes critical. IPAM solutions that can detect IPv6 addresses provide visibility into ad hoc IoT devices for network managers, while corresponding security solutions enable qualification and access control for connected things. I’ll discuss these topics in more detail in a future post.

Tuesday, December 16, 2014

DNSSEC Survey Report

BT Diamond IP just published its latest report detailing results of its DNSSEC industry survey, conducted in November, 2014. This year’s survey yielded strong participation from active DNSSEC deployers, meaning those who have already deployed or are deploying DNSSEC. While not likely representative of overall industry deployment status, opinions regarding complexity and business case as obstacles and lack of interest in high security module (HSM) appliances for private key storage prove insightful.

Among the key findings of the survey:

  • Nearly all respondents agreed with the statement that DNSSEC can or does provide value to their organization and over 85 percent likewise agreed that DNSSEC technology is mature and can be reliably deployed.
  • Forty-seven percent of respondents agreed that deploying and maintaining DNSSEC is very complex, 12 of the 47 percent strongly. Only 22 percent disagreed. This is rather telling in that DNSSEC is not only considered complex to the uninitiated, but that experience shows this to be the case.
  • Nearly half of respondents disagreed with the statement that only external (Internet-facing) zones need be signed, while 28 percent agreed with the statement. This majority position debunks the theory that internal name spaces are of little concern when it comes to DNSSEC.
  • Only 20 percent of respondents agreed that dedicated hardware security module (HSM) appliances or cards are required to store private keys.
  • Over 75 percent of respondents assign their DNS groups as responsible for DNSSEC implementation and management, sometimes alone or often in conjunction with other groups. It’s interesting to note that about 25 percent of respondents do not involve the DNS group in the process!
  • As an industry, simplifying the deployment process to reduce complexity and therefore costs to some degree could help spur further DNSSEC deployments.

The survey report documents participants' opinions about the level of concern for securing DNS via DNSSEC, their stage of DNSSEC deployment if any, the perceived value of DNSSEC, deployment obstacles, other DNS security concerns, which groups internally are responsible for DNSSEC management, and even which DNSSEC vendor implementations respondents use.

The full report is available in pdf format at

If you have any comments regarding the report please don't hesitate to contact me.

Monday, October 20, 2014

You're invited to participate in our DNSSEC Survey

Signing DNS data with DNSSEC enables an organization to authenticate its web addresses and other published DNS information, i.e., to secure its namespace. DNSSEC also protects against DNS cache poisoning attacks when DNSSEC validation is enabled on DNS recursive server resolvers. As such DNSSEC is a critical component of a comprehensive DNS security strategy which should also include use of functional and port access control lists (ACLs), transaction signature keys to sign updates and transfers among servers, detection of DNS anomalies, and possibly domain name filtering or firewalling to restrict communications among malware-infected devices and corresponding command and control centers.

BT Diamond IP is sponsoring a DNSSEC survey to gather input from DNS and network administrators regarding their opinions about the value of DNSSEC, potential obstacles to implementation, and relative priority of deployment. And you are hereby invited to participate! The survey consists of twelve questions plus a thirteenth if you'd like to enter your contact information to be entered for a drawing for a $100 VISA gift card. The survey will remain open through November 3, 2014, after which we will compile the results and publish a free survey report. Make your opinions count, take the survey today!

Friday, October 10, 2014

What Exactly is a DNS Firewall?

When you think of an Internet firewall, you likely think of a gateway device which examines IP packets flowing through it and which selectively blocks or redirects those packets meeting certain criteria. Such criteria may include filtering parameters such as IP addresses or ports such that when an IP packet under inspection matches such parameter settings, the packet is blocked or otherwise handled according to policy settings. A DNS firewall performs similar examination and policy handling functions for DNS queries to prevent unwelcome DNS and subsequent data traffic.

Another common assumption associated with Internet firewalls is that they are deployed on the perimeter of a network with the intention of protecting the network from attacks originating external to the network. DNS firewalls however protect the network against attacks that originate within the network. Why worry about internal attacks if morale is sky high and IP firewalls are seemingly impervious? With the proliferation of smart phones and "bring your own device" (BYOD) initiatives intentionally or unintentionally established, it's quite possible that devices physically leaving the domain of a perfectly firewalled network may elsewhere become infected with malware when operated on less secure networks such at as the coffee house wifi or at home.

Certain forms of malware infiltrate a device as a remote agent or "bot" which, along with several other similarly infected devices, forms a "botnet" where an attacker can command several bots to perform attacks such as distributed denial of service attacks. A bot on an infected device will typically attempt to contact the attacker's command and control (C&C) center to receive its marching orders, and the means of contacting the C&C starts with a DNS lookup. The primary goal of a DNS firewall is to identify such C&C contact attempts, to block such attempts and to identify the infected device.

The leading DNS server reference implementation, BIND from the Internet Systems Consortium (ISC) supports the establishment of DNS firewall policies via its response policy zones (RPZ) feature. RPZ enables a DNS administrator to define policies in standard DNS resource record format to enable filtering of DNS queries. Filtering triggers can be defined based on the queried name (QNAME), resolved IP address (IP address within A or AAAA query response), resolving name server IP (NSIP) as resolved within a response to the A or AAAA query for an NS RRSet, and resolving name server name (NSDNAME) as resolved within an NS RRSet. Thus throughout the resolution process for a particular query, the recursive DNS server can filter at multiple points along the way, then enact the corresponding policy action. Such action can be defined as responding with NXDOMAIN, NODATA, pass through, or inclusion of predefined response data, such as directing the session to a walled garden.

The beauty of this technique is in defining policies as resource records within a zone or zones which enables DNS administrators to create their own policies and/or to subscribe to a provider or providers of malicious domain (filtering) information, which can simply zone transfer such domain information to the corresponding recursive DNS servers. Updates of this zone information of course should be secured via the use of standard BIND ACLs as well as transaction signatures (TSIG) to sign incremental or full zone updates.

BT Diamond IP's IP address management products support configuration of DNS firewall functions via its web user interface for our Sapphire appliances as well as stock ISC BIND servers you may already operate. We also partner with Internet Identity as a provider of bad domain information which can be easily configured with our systems though customers are free to implement their own policies using our systems or use other or additional bad domain providers. Feel free to contact me to learn more.

Tuesday, July 8, 2014

IPv6 Growth Inflection Point

Now that the percentage of IPv6 users accessing Google's websites has reached 4%, I decided to revisit my prior post projecting IPv6 growth. Assuming that people around the world use google as it sits atop Alexa’s list of top websites, it would seem such a measurement provides data that could be loosely projected to the Internet at large. It took just 140 days for the IPv6 user rate to climb from 2% to 3%, and interestingly only 140 days from 3% to 4%. Is IPv6 growth going linear? Or more likely have just passed an inflection point beyond which growth will accelerate?

Reiterating our view that the historical IPv6 user data is comprised of two segments, the first being the nearly linear component of near zero penetration up through 2011, and the second representing the present growth phase, we plot the measured IPv6 penetration since the end of 2011. Applying both exponential and second order polynomial curve fittings as before in Figure 1, we see that our exponential curve, the solid red line, fits very well with a R2 of over 0.99 while our polynomial curve fit, the dashed green line yields a respectable R2 of 0.9844.

Figure 1: Curve fittings for most recent Google IPv6 users data

The exponential curve predicts IPv6 penetration at 6.2% by the end of this year, while the polynomial predicts 5.6%. These predictions are both a bit higher than the corresponding points from my prior post at 5.9% and 4.9% respectively. The trend curves are getting steeper though they diverge rapidly after these near term predictor points, with the former model predicting nearly 15% penetration by the end of 2015 and polynomial indicating only about 10%. Incidentally, the linear 140-day percentage point increase model predicts 8.0% by the end of 2015. Stay tuned for my next post on this topic and an update when this particular penetration measure hits 5%.