Thursday, October 31, 2013

New and Different: New IDN and DNSSEC-signed gTLDs

The Internet Corporation for Assigned Names and Numbers (ICANN) announced last week that the first set of approved generic top level (gTLDs) has now been activated on the Internet by virtue of their delegations in the root zone of the global DNS system. According to the announcement, the first four delegations are:
  • شبكة (xn--ngbc5azd) – Arabic for "web/network". The domain registry responsible for managing subdelegations from this new TLD is International Domain Registry Pty. Ltd.
  • онлайн (xn--80asehdb) – Cyrillic for "online". The domain registry for this new TLD is  CORE Association
  • сайт (xn--80aswg) – Cyrillic for "site". The registry for this TLD also is  CORE Association
  • 游戏(xn--unup4y) – Chinese for "game(s)" and the domain registry is Spring Fields, LLC.
Notice that all of these are internationalized domain names (IDNs), with each TLD listed first in its native character set, followed in parenthesis with its equivalent ASCII (IDN) representation. Once the corresponding domain registries for these TLDs complete a post-delegation process to protect any trademark holders, the registries may begin delegating their own subdomains beneath these TLDs. When complete, for the first time, web users will be able to enter domains names in fully Cyrillic, Arabic or Chinese characters (though many country code TLDs are already internationalized).

As suggested in a prior post, organizations seeking to communicate or conduct business with web users of such "native" languages may desire to register and operate a subdomain in one or more of these new IDN gTLDs. Providing full native language support is expected to improve Internet usability and increase penetration.

IDN gTLDs are certainly new and different, as is the requirement that all new gTLDs under this program be secured via DNSSEC. That is each gTLD zone will be signed, which facilitates the signing of subdomains beneath these TLDs. Based on registry policies, registered subdomains may or may not require DNSSEC signing, though we recommend it to retain namespace integrity!

These successful delegations represent the first set of new gTLDs having been vetted through ICANN's "new gTLD" program, begun about twenty months ago, one of the major goals of which was to add support for "DNSSEC from the start" and  IDN gTLDs, With over 1400 gTLD candidates still working through the approval process, expect many more delegations coming soon!

Tuesday, October 15, 2013

Understanding Your IPv6 Deployment Window

If your organization relies on the web for anything at all, you should start thinking about IPv6 deployment planning if you haven’t already done so. The reality is that the face of the Internet is changing from an IPv4-only Internet to a hybrid IPv4-IPv6 Internet. The density of IPv6 traffic today is quite low, just over 2% as recently measured by hits on Google web servers. Nevertheless, this represents a doubling of traffic from less than a year ago. If such an exponentially increasing trend continues, IPv6 traffic will comprise about one-third of Internet traffic by 2017.

One-third of the Internet…at least one billion users by then….that’s a lot of IPv6 eyeballs and potential customers or consumers of your web information! And if they are seeking your email or web servers and you don’t support IPv6 reachability, they will by necessity go elsewhere. But 2017 seems so far away! What’s the hurry? The problem is that implementing IPv6 within your network may take some time. How much time depends on the current state of your IPv6 capability.  Determining your current capability requires a detailed review of your network and computing inventory with respect to individual device or application vendor support of IPv6. Most devices and common applications already support IPv6 today, but if you utilize industry-specific or otherwise unique applications or devices, some research may be required.

If you maintain updated network documentation, perhaps through network management systems, identification of every network device and application may be readily accessible. If not or if your information is dated, you may need to perform network and device discovery to document your inventory. With your network and computing inventory in hand, the next step is to verify IPv6 support for each item, which enables you to categorize each element of inventory as either IPv6 capable or not. For those that are not, you’ll need to evaluate whether each item requires IPv6 support (for example, it may not if it falls outside of the scope of your initial deployment), and if so, what it will take to upgrade to IPv6 support. Such an upgrade may come in the form of a software or firmware upgrade. If software supporting IPv6 is not available, you may need to add or replace a corresponding device or application that does support IPv6.

The set of tasks and upgrades required for all assets requiring mitigation comprises the “to do” list for enabling IPv6. These tasks should be scoped out in terms of required resources, time, and cost then mapped to an overall deployment project plan. Such a project plan may incorporate deployment phases to support a controlled or limited scale deployment initially to “prove in” IPv6 from an equipment, applications and operations perspective. Certainly the more tasks and upgrades you need to perform the more resources and time you will need.

The overall timeframe in your deployment plan, your IPv6 deployment window, provides a critical data point in your decision regarding when to deploy IPv6. Perhaps you would prefer to delay actual deployment based on current adoption rates. Then if trends change and IPv6 deployment suddenly vaults to a higher priority, you’ll have a good sense of how long it will take if you've done your homework and identified your IPv6 deployment window. Feel free to try our IPv6 assessment tool to estimate when IPv6 deployment may impact your business. And for more details on the IPv6 deployment assessment, planning and deployment process, pick up a copy of our IPv6 Deployment and Management book.

Tuesday, October 1, 2013

Still on the fence regarding IPv6 deployment?

IPv6 rollout appears to be moving slowly, and last week's Internet Society announcement that IPv6 traffic has reached 2% of total Internet traffic as measured by hits on google’s web servers would seem to reinforce this perception. While 2% penetration represents a doubling of IPv6 traffic since last year, the total is as yet unimpressive.

But deploying IPv6 is not a trivial undertaking. While recent vintage networking equipment and device operating systems natively support IPv6, application and operational aspects require careful attention. Organizations need to verify proper application reachability and functionality over IPv6. Applications utilizing the current sockets or winsock equivalent interface to the TCP/IP layer should work seamlessly over IPv6. Those applications storing or visually displaying IP addresses of course may require modification to properly handle IPv6 addresses, and any hard-coded IP addresses may require modification to use multiple IP addresses or better yet, DNS to retrieve currently assigned IP addresses as appropriate.

From an operations perspective, organizations must be able to provision, monitor, troubleshoot, secure and manage their networks, and IPv6 adds an entirely new dimension to current network management systems and procedures designed for managing an IPv4 network. At a basic level, this evolution to managing a dual protocol IPv4-IPv6 network requires assessment of current systems capabilities, identification of required mitigation steps, planning for training of IT, networking and help desk staff, tabulation of a resource budget to perform such mitigation and training, then planning and executing the IPv6 rollout.

The effort to deploy IPv6 does take some time and investment, but it should prove well worthwhile for those who plan ahead. As the reach of the Internet continues to expand particularly fueled by growth in mobility, IPv4 address space and IPv4-IPv6 carrier grade NATs will ultimately exhaust their capacities and IPv6 traffic will likely continue to double each year if not grow more rapidly. Organizations who are prepared for this eventuality should enjoy uninterrupted web visitors and traffic growth opportunities.

But if you’re still skeptical about the need to deploy IPv6, contented with the fact that you have plenty of IPv4 address space, I invite you to try our IPv6 quick assessment tool. This simple tool enables you to select the relative importance of basic business drivers or initiatives that may be impacted by your support of IPv6 in the future. The tool provides a qualitative summary for each driver with a brief overall assessment and recommended timeframes for progressing your deployment plans in terms of completing your assessment of what it will take to implement IPv6, your project planning, and your deployment completion.


This basic tool provides food for thought and perhaps some motivation for you (or your boss) to initiate an IPv6 assessment project. The overall deployment process may take some time, and your assessment is key to estimating how much time depending on the level of IPv6 you already have implemented by virtue of current device, applications and vendor support. Performing this assessment up front will enable you to scope out your implementation time interval. This interval is the lead time from which to begin your deployment project working back from when your organizational drivers are expected to demand IPv6 support. So even if you still don't foresee deploying IPv6 any time soon, performing an assessment should arm you with an estimate of how long it will take you from the time you change your mind to join the global Internet!