Monday, April 23, 2012

Take our 2012 IPv6 Survey

The 2012 edition of our IPv6 survey is now on-line! Breaking our former tri-ennial pattern, we're now going annual, since IPv6 deployment has certainly heated up! We conducting the survey over the next two weeks until May 4. The survey should only take 5-10 minutes to complete and for your trouble, you can enter your name and contact information to be entered into a drawing for a free Apple iPad.

The survey is similar to last year's, which helps us look for trends, but also features a couple of new questions. One of particular interest asks about the "IPv6 density threshold" people may be waiting for to pull the trigger on deploying IPv6. This density threshold relates to the percentage of Internet users that are IPv6 within the entire Internet. It'd be interesting to see if this "IPv6 audience size" has an influence on people's planning initiatives. Thank you in advance for taking the time to complete this survey! Results will be published in mid-May.

Monday, April 16, 2012

IETF decrees that "IPv6 is no longer considered optional"

The Internet Engineering Task Force (IETF), which for all intents and purposes is the standards body of the Internet Protocol, has declared that "IPv6 is no longer considered optional." In RFC 6540 officially published late last week as an Internet Best Current Practice, the IETF cites the impending depletion of IPv4 address space with the continued growth of the Internet as drivers for widespread IPv6 deployment. While the RFC defines requirements for all developers of IP nodes, the main target seems to be consumer device vendors, many of whom have delayed implementation of IPv6. With consumers just implementing these IPv4-only devices today, they are likely to remain installed for many years, extending the IPv4 support lifecycle. Of course IPv4 will be around for quite some time, but the more of these devices that are IPv4+IPv6 instead of IPv4-only, the easier co-existence will be to manage.

Among the best practices recommended, the RFC stipulates that all new "IP implementations" must support IPv6, and IPv6 support must be equivalent to or better than corresponding IPv4 feature support and quality, that dual-stack support is required though IPv4 must not be required for operation, and existing hardware and software implementations should be considered for upgrade to IPv6 support.

Another interesting statement from the RFC is that "the term "IP" can now be interpreted to mean IPv4 + IPv6, IPv6-only, or IPv4-only." While separate standards exist for IPv4 and IPv6, the term "IP" now officially encompasses both protocols. Requirements for features specific to a given version should be so indicated, while general "IP" features will be assumed to apply to both.

This IETF statement complements what the Regional Internet Registries have been promoting for some time, and the World IPv6 Launch seven weeks away testifies to Internet heavyweights' participation in supporting IPv6 deployment. The IPAM Worldwide homepage features a graph embedded from the RIPE NCC which illustrates the relative density of IPv6 networks being advertised on the Internet. While the graph certainly shows a growing influence of IPv6, the raw numbers are also of interest. Considering the worldwide average, 5320 IPv6 networks are being advertised as of the end of March, 2012, while only 3594 were in March, 2011. This represents a 48% jump in advertised IPv6 networks. The industry momentum continues to build for IPv6!

Wednesday, April 4, 2012

DDIB? DDI and block management

I recently had the opportunity to preview a market analyst's brief on BT Diamond IP's DHCP/DNS/IPAM (DDI) features and benefits. Among my comments, I indicated that there was no mention of IPv4/IPv6 block management, a core IPAM function for which we are frankly unmatched. To my surprise, I was asked to elaborate about our block management features and benefits.

From my perspective, for any modest sized or larger IP network, DDI starts with block management. If you have to manually type in every subnet address in your network, why not use a spreadsheet? Block management enables entry of a "root" block, such as, fc00::/7, 2001:db8:a87e::/48, etc. as the root block from which subnets or other "pool" blocks can be allocated. This allocation process should not require re-entry (or cut-and-paste) of a chosen subnet address; if yours does, you're little better off than using spreadsheets which likewise require manual entry. With the Diamond IP solution you simply navigate logically to where the subnet is needed, and a few mouse clicks to select the type of address space (VoIP, wireless, management, etc.) you need, the version (IPv4 or IPv6), and CIDR size then submit!

This simple process ties IPAM directly to business processes. For example:

  • "I need a new wireless subnet in the Philly office finance division"...point and click and done
  • "I'm planning to open a new branch office next month and need to allocate eight subnets for planning purposes"...our site template feature allows one to meet this business requirement in one click!

And each subnet in turn can have an associated address assignment template, so one can also assign addresses for routers, switches, servers, DHCP pools, etc. as well as automatically generate A/AAAA/PTR resource records for each assigned address, further automating DDI functions! These two simple examples illustrate how block management ties directly to business initiatives, and how BT Diamond IP intuitively and easily maps these business initiatives.

There's a lot of noise out there about IPAM and DDI, and the messaging is understandably blurred. When trying to cut through the hype, don't discount what I consider a core IPAM feature: block management. After all, if you don't get your block management right, your underlying IP assignments and DHCP/DNS configurations won't be right either.