Tuesday, December 17, 2013

More New Generic Top Level DNS Domains

Since the inaugural set of four new generic top level domains (gTLDs) was announced six weeks ago, the tally of new gTLDs has grown to 35. And the number of new gTLDs will likely continue to grow well into the hundreds during 2014 as respective domain applicants work through the approval process. Even today, the 35 newly delegated TLDs comprise just over 10% of the 343 TLDs in the Internet root zone.

The table below summarizes the status of the today's TLDs by type (country code, generic, etc.), whether internationalized or not, and whether DNSSEC-signed or not. Starting at the bottom of the table, of the three generic-restricted TLDs, .biz, .name and .pro, only .biz is signed and clearly none of them are internationalized. The .arpa infrastructure domain is signed as well. None of the so-called sponsored TLDs are internationalized and about half are signed. All of the generic TLDs are signed, and the 35 new gTLDs fall within this row. In fact, all new gTLDs must be signed as required by the new gTLD program. And for the first time, we have five gTLDs so far that are also internationalized, thanks also to the program.

SignedUnsigned
IDNNon-IDNIDNNon-IDN
Country Code TLD128924160
Generic TLD53400
Sponsored TLD0708
Infrastructure TLD (.arpa)0100
Generic-restricted TLD0102

All of this may be quite interesting, but how does this affect you? Certainly you should be aware of an inflow of new TLDs in the DNS, which affords the opportunity to register subdomains within appropriate TLDs. For example, if your organization seeks to reach a certain population which uses a non-Latin based language, publishing your domain name (and website) in native language could attract and simplify reachability to your web infrastructure.

Secondly as new gTLDs move towards production, an increasing proportion of DNSSEC-signed zones will rise accordingly. Signed TLDs extend the DNSSEC chain of trust down from the root through a growing proportion of the TLD layer, and ultimately to second level domains typically administered by organizations, enterprises, governments, etc. Such a linked chain of trust simplifies the process of DNSSEC signature validation on the part of validating resolvers, which can authenticate domain information and verify information integrity using the root trust anchor.

Speaking of DNSSEC validation, according to Verisign Labs, alas, less than 5% of resolutions are performed by validating resolvers. Some large broadband and wireless providers have enabled DNSSEC validation within their recursive servers, but many have yet to do so. Much like the case with IPv6, opportunities for use of DNSSEC are growing as the Internet evolves, but it requires some work to participate. DNSSEC can help build a more secure Internet, so if your TLD(s) support DNSSEC signing, I encourage you to investigate implementing DNSSEC. And if any of your TLDs are internationalized, internationalizing your domain label may likewise be worthy of analysis.

You can follow the links to these web resources to keep up with the new gTLD program at ICANN, IANA for a listing and types of TLDs, and ICANN Research regarding TLD signing status.

Wednesday, November 13, 2013

IPv6 block allocation tools

There's much to consider when developing an IPv6 address plan. Such a plan defines how you intend to allocate subnets from the IPv6 block you received from your ISP or Internet Registry. The first step entails defining how much address space is required across and into the depths of your IP network to provide IPv6 address capacity for those devices requiring it. You can use your current IPv4 address allocation database as a guide to define the active utilization of your IPv4 address space and should provide a solid basis for IPv6 capacity needs barring new network initiatives that increase address space usage. Once you've defined where in your network you require IPv6 addresses and how much, you should consider how to perform your allocations.

One approach is to simply allocate all required /64 subnets directly from your base ISP allocation, using a monotonic, sparse, best-fit or random allocation approach. This single-tier allocation approach may work fine for small networks, but for modest to larger networks, mapping your allocations to network topology (and other factors we'll consider next) can simplify routing and ongoing management of your network. For example, if you operate a traditional three layer core-access-local network architecture, you may want to consider allocating large address blocks from your ISP allocation to your core components or core routers. Subtending access components or routers can then be allocated blocks that "roll-up" or are allocated from their respective core blocks. Likewise local networks and subnets can be allocated from respective access blocks. This approach renders a hierarchical aggregation model that streamlines route advertisements within your network as routers need only communicate summarized (rolled-up) address space and not individual sub-allocations.

However you may also want to consider inserting additional hierarchical layers to facilitate network management and security processes that are based on IP address assignments. If your network supports multiple applications or classes of service, such as voice, video, and data, you may configure your routers to inspect source/destination IP addresses in the IP header to apply corresponding packet treatment. Imposing such a policy within a purely topological allocation scheme can be cumbersome. However if your first allocation tier is for class of service, followed by core, access and local tiers, the application of a class of service policy is a single router entry in every router in your network!

If you map out your IPv6 address plan up front, you can design in a strategy that will simplify implementation of network and security policies. And you can design in the ability to visually recognize locations, applications or security domains by sight based on the value of certain hex digits within the IPv6 address. Read my post on the Internet Society IPv6 Deploy 360 website for details and examples of such address plans. In addition, I've just posted a free online tool that enables you to experiment with different multi-layered allocation strategies to help you define how many layers you may need and of what size for each.

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!

Thursday, June 6, 2013

World IPv6 Launch One Year Later

Did last year's World IPv6 Launch inspire you to move forward with making or executing plans to deploy IPv6? The Internet Society links to several measurement sites, many of which indicate an increasing volume of IPv6 traffic. The World IPv6 Launch site also has a nice infographic that indicates that IPv6 web usage has doubled since the launch one year ago. 

Is your network among the contributors to this increased IPv6 uptake? Make your voice heard by completing our annual IPv6 survey. This year's survey is very similar to last and prior years' surveys in order to help us identify trends and changing perceptions about IPv6. The survey should take about five minutes to complete so we invite you to let us know what you think. We're also going to be drawing the name of one survey respondent to whom we will award a $100 Visa gift card, so I invite you to complete the survey. 


Monday, May 6, 2013

IPv6 Address Planning

If you are putting together your IPv6 address plan, you'll need to consider how you should allocate subnets from the IPv6 block you received from your ISP or Internet Registry. In fact you should consider how to design the structure of your IPv6 allocation hierarchy to simplify ongoing network management once deployment has begun. 

The first step entails defining how much address space is required across and into the depths of your IP network to provide IPv6 address capacity for those devices requiring it. You can use your current IPv4 address allocation record as a guide to define the active utilization of your IPv4 address space. Once you've defined where you require IPv6 addresses, you'll next need to define how to perform your allocations. One approach is to simply allocate /64 subnets directly from your base ISP allocation, using a sparse, best-fit or random allocation approach. 


This single-tier allocation approach may work fine for small networks, but for modest to larger networks, mapping your allocations to network topology (and other factors we'll consider next) can simplify routing and ongoing management of your network. For example, if you operate a traditional core-access-local network architecture, you may consider allocating large allocations from your ISP allocation to your core components or routers. Subtending access components or routers can then be allocated blocks that "roll-up" or are allocated from their respective core components. Likewise local networks and subnets can be allocated from respective access components. This approach renders a hierarchical aggregation model that streamlines route advertisements within your network as routers need only communicate summarized (rolled-up) address space and not individual sub-allocations. 


However you may also want to consider inserting additional hierarchical layers to facilitate network management and security processes that are based on IP address assignments. If your network supports multiple classes of service, e.g., voice, video, and data, you may configure your routers to inspect source/destination IP addresses in the IP header to apply corresponding packet treatment. Imposing such a policy within a purely topological allocation scheme can be cumbersome. However if your first allocation tier is for class of service, followed by core, access and local tiers, the application of a class of service policy is a single router entry in every router in your network! To learn more about various IPv6 address allocation strategies, tune into our upcoming webinar which will discuss IPv6 allocation considerations including some examples and resulting network management implications. After May 8, you can access the replay from the webinars section of our IPv6 Resource Center.

Thursday, April 25, 2013

IPv6 Subnet Calculator

We've just published a free online IPv6 subnet calculator for your use and enjoyment. For the uninitiated, a subnet is a subdivision or allocation of a larger address block. Subnetting is necessary to enable an organization to carve up the address block received from its ISP into subdivisions across the organization in order to provide IP address capacity to end devices requiring IP network access. In many enterprises, the subnetting process involves tiers or layers to better map to the organization's routing structure, security policies, applications' routing requirements, or other reasons. Thus in the simplest case, an organization choosing to use the private 10.0.0.0/8 space, they may choose to allocate bits 9-16 to the top layer of its address hierarchy. This would yield 256 subnets, starting from 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16, on up to 10.255.0.0/16. Each /16 could in turn be further subdivided using bits 17-24 to create 256 subnets for each of the 256 /16 blocks. For example, within the 10.25.0.0/16 block, the first such subnet is 10.25.0.0/24 and the last is 10.25.255.0/24.

In this trivial example, subnetting was quite easy because our subnet sizes coincided with our notation boundaries; that is the size of each subnet was 8 bits corresponding to the dot-separated decimal numbers. If you've worked with subnetting IPv4 blocks, you've probably encountered the more challenging task of subnetting on non-octet boundaries. Converting the 32-bit IPv4 block to binary, counting out to the subnet bit length, then back to dotted decimal is the sure-fire way to perform this function.

IPv6 introduces a much longer binary string with 128 bits, though the IPv6 addressing architecture specifications stipulate minimum subnet sizes of /64 (64 bits) in most cases. This leaves 64 bits to work with, which is twice as many as an entire IPv4 address in bit length. The other wrinkle of course is that IPv6 addresses are expressed in hexadecimal, which makes the conversion to binary and back more challenging or at least less familiar. To help you get your head around this process, we've published our IPv6 subnet calculator. It's even mobile-compatible so you can bring it up wherever you are.

Just enter your IPv6 block address (the default shown is the IPv6 documentation address), define the prefix length, then select the subnet size corresponding to the CIDR length of each subnet. Click the Calculate button and you'll see the resulting subnets displayed. Depending on the subnet size with respect to the prefix length, the results may span several pages. You can also select the page size to fit the device on which you happen to be using the calculator. Feel free to post a comment or send me an email with any feedback or comments!

Thursday, April 11, 2013

Learn about IPAM with our free webinar series!

As we have done several times over the years, we are planning another webinar series offering educational material regarding IPAM technologies including IPv6, DNSSEC and IDNA. The full webinar lineup, dates and times, and brief synopses are posted on the BT Diamond IP website. Register for any number of topics you're interested in.

When planning such a series, we certainly have no shortage of topic ideas. IPv6 as always remains of high interest from the Internet community at large. We ran an intensive 5-webinar IPv6 series about a year ago, and these webinars are still relevant and posted for playback on the BT Diamond IP website. So this time around, I selected three different IPv6 webinar topics. 

The first seeks to relate IPv6 to "managers," which yes as the title unfortunately implies, is somewhat "dumbed down" technically in terms of describing IPv6, but it also includes topics related to how IPv6 can impact one's business. I'll discuss the potential benefits of deploying IPv6 from potential cost savings and revenue upsides, to "softer" benefits as well. On the cost side of the equation, I'll discuss major cost areas to consider, though it is really up to each organization to define the scope and extent of their IPv6 deployment, so costs will be implementation-dependent.

Our second webinar will cover the IPv6 deployment process in general. This webinar will nearly coincide with the launch of our new IPv6 Deployment and Management book, which itself covers the topics to be discussed in this webinar. So think of this one as the "audio cliff notes" version of the book! Our third webinar will discuss IPv6 address planning in more depth. IP address planning is what we do and many of our customers have asked us for help in defining such a plan for IPv6. This webinar will provide guidelines and discuss trade-offs for various approaches.

The second half of our series shifts gears to other germane IPAM technologies, starting off with an "Introduction to IPAM" webinar. We at BT Diamond IP have been in the IPAM industry for nearly twenty years and we arguably founded the very IPAM industry itself. So we know a thing or two about IPAM; but the term IPAM has unfortunately been muddied over the last few years to camouflage the IPAM shortcomings of some highly visible DDI vendors. So this webinar seeks to set the record straight on what IPAM truly comprises. 

Our final two webinars address a pair of increasingly important DNS technologies, DNSSEC and IDNA. DNSSEC, like IPv6 has been around for over a decade. And while IPv6 deployments are starting to gain traction, DNSSEC deployment continues to languish. But let's face it, for DNS engineers, the topic of asymmetric key cryptography is a bit intimidating if not orthogonal to the DNS technology they understand inside and out. So we'll discuss the cryptography process at a basic level, discuss what DNSSEC does and doesn't protect, and talk about ongoing administrative duties and potential time savers.

Internationalized Domain Names (IDNs) are domain names represented in "native language" characters, i.e., non-Roman alphabets. DNS specifications dictate that DNS information be communicated "on the wire" as ASCII characters, which represent well the Roman alphabet. To enable broader unicode character sets, the IDN for Applications (IDNA) standards were codified within the IETF. IDNA enables a character string represented as unicode characters to be transformed into a string of ASCII characters, enabling the IDN to be represented in zone files and on the wire in ASCII per DNS specifications. So why is IDNA important? It enables organizations to present themselves to the Internet at large with native-language web addresses, email addresses, and so on. If your target market includes regions of the world that do not use strictly a Roman alphabet, then providing an Internet presence in native language could provide a marketing differentiator; and accessing your Internet presence starts with DNS.

I hope you find these topics of interest and the webinars useful. If you have any suggestions for other IPAM related topics, please feel free to post a comment below.

Wednesday, April 10, 2013

Book completed - now back to blogging!

It's been a few months since I've posted due to the urgency to finish my new IPv6 book, a death in the family and a period of abnormally onerous work requirements (always getting in the way!). My new book, co-authored with Michael Dooley is entitled, IPv6 Deployment and Management, ISBN-10: 1118387291/ISBN-13:978-1118387207, and will be available within the month.

Mike and I were motivated to write this book given the myriad questions we received from customers, prospects, and acquaintances about how to go about IPv6 deployment. Certainly having worked with IPv4 and IPv6 from an IPAM perspective for several years, we were able to share our experiences. However, there's much more to deploying IPv6 than managing the IPv4-IPv6 address space! So we set out to learn about the broader aspects of IPv6 deployment thanks to extensive research and interaction with some of our colleagues, and we discovered that it touches every aspect of the IP network. And given that I've never seen two identical IP networks, each one is unique, and the deployment planning and execution process likewise differs per IP network.

So there's no universal cookie cutter answer to the question of how to deploy IPv6, but we attempted to map out a basic process and identify key issues when planning an IPv6 deployment project. There's a lot to think about when implementing a new protocol, from assessing the ability of current infrastructure (routers, switches, servers, end user devices, databases, applications, etc.)  to support IPv6, to defining how such a dual protocol network is to be managed and supported, to creating security practices and policies and certainly documenting and tracking the IP address plan. From this assessment, plans can be made with respect to remediating non-IPv6 complaint components, mapping out a project plan, testing and executing the plan.

The book provides a detailed discussion of IPv6 deployment drivers, the IPv6 protocol, IPv4-IPv6 co-existence techniques, and key considerations when deploying IPv6 including IP addressing, network management and security. Readers may find that just particular sections apply to them, or all of them!