Saturday, February 26, 2011

Upcoming Milestones in Bringing DNSSEC to .com

Starting today, ICANN-accredited registrars may submit Delegation Signer (DS) records to Verisign, the .com administrator. Most organizations obtain and register their domain names with domain registrars, who may also be their ISP. Contact your registrar to determine if they are participating in this process. Verisign will include submitted DS records in a"deliberately unvalidatable" .com zone that will be published on Monday, February 28. This deliberately unvalidatable zone will contain dummy keys for testing purposes.

As recently announced , the .com zone will be signed in production on March 31, 2011. The submitted DS records will be included in the signed .com zone and the .com DS record will be published in the root zone, fully linking the chain of trust for .com zones!

This linked chain of trust vastly simplifies the management of trusted keys on validating resolvers (typically within recursive or caching DNS servers which are queried by clients or "stub resolvers"). Prior to this linkage, a validating resolver requires a copy of each .com's trusted subzone's public key (key signing key, KSK). So if a DNS administrator desired to implement DNSSEC validation to protect the cache of his/her DNS servers, a trusted key for each subzone needed to be configured on each caching server. If you think about all the .com subzones your users browse or email to, that's a lot of trusted keys! Fortunately, with a fully linked chain of trust, only the root zone's public key (KSK) need be configured for successful validation of .com subzones.

The KSK of a signed zone basically signs the zone's key records, consisting of the KSK and the zone signing key(s) (ZSKs). The ZSK signs the zone, meaning that it is used to produce a signature for each resource record set within the zone. The DS record is analogous to the NS record. The NS record provides referrals to the next subzone in the domain tree for name resolution. The DS record provides a "trust referral" to a signed subzone by incorporating a hash of the subzone's KSK. If a validating resolver does not "trust" the subzone's KSK, it can check if the parent zone links trust to this KSK via a corresponding DS record; if so the validating resolver can determine if it trusts the parent zone's KSK, and so on up the domain tree to the root!

Friday, February 25, 2011

IPv6 Implications for Enterprises

With the recent announcement that IANA has allocated its last remaining IPv4 address space to the Regional Internet Registries (RIRs), time is running out on availability of new IPv4 address space allocations. As the last remaining IPv4 address space is allocated, enterprises at some point in the not too distant future will have no choice but to implement IPv6 for Internet-accessible web or email servers. Any newly-formed organization or those that require additional address space after this time will be "IPv6-only" organizations.

Perhaps you're thinking this is not an issue given the plentiful private IPv4 address space. But consider this: as this population of IPv6-only organizations and users grows into 2013 and beyond, will they be able to reach your websites and email? To serve this population which will grow rapidly as more IP-based public and private applications are deployed, implementation of IPv6-addressable Internet servers is imperative.

Besides implementing IPv6 on Internet-facing servers, enterprises should take heed regarding IPv6 addresses already in use internally. Many popular operating systems including Microsoft Windows and Linux natively support IPv6 addressing. A major feature of IPv6 addressing is address autoconfiguration, which enables a device to identify the subnet address to which it is attached by virtue of router advertisement messages and to append its self-derived Interface Identifier to this subnet address to fully compose a unique IPv6 address unbeknownst to network administrators.

Autoconfiguration may provide a convenience for users initializing on a network, but it runs counter to network admission control (NAC), a strategy for reviewing and approving the assignment of addresses to devices. The scope of autoconfigured IPv6 devices can be constrained to a local link by disabling the autoconfiguration option in router advertisements or by disabling router advertisements altogether until you consciously deploy IPv6 on the given link. Take control and implement IPv6 on your terms...but do plan to implement it!

Wednesday, February 23, 2011

Network World Concurs: IPAM Required for IPv6, IPv4, DHCP, DNS

I couldn't agree more! It's nice to see corroboration in recent commentary by Jeff Doyle on the overall disciplined approach for IPAM encompassing IP planning, DHCP and DNS. In his article for Network World, Jeff states that an IPAM solution is even more necessary with the advent (or onslaught?) of IPv6 deployment. Dotted decimal IPv4 address allocations and assignments can more easily be tracked in spreadsheets or homegrown solutions than can IPv6 hexadecimal.

In addition, Jeff highlights the need to integrate DHCP and DNS management with IP address planning, which I've always contended helps eliminate duplicate entry of common data, saving time and reducing the potential for data entry errors.

Another comment I found interesting is Jeff's contention that some organizations will conclude that managing two protocols, IPv4 and IPv6, is expensive, risky and difficult and will fully implement IPv6 sooner rather than later. If this prediction holds true, then the need to plan for and implement IPv6 on Internet-facing servers is even more urgent than I discussed in a prior post. IPv6 is the future! Plan on it!

Incidentally, if you're interested in more discussion regarding IPv6 allocations and even allocating address space such that assignments have "meaning" as Jeff suggests, please consult Chapter 3 of my IP Address Management Principles and Practice book.

Thursday, February 3, 2011

When will the second domino of IPv4 space exhaustion fall in your region?

Now that IANA has exhausted its IPv4 address space, each Regional Internet Registry (RIR) now has a finite amount of IPv4 space to allocate to its “customers”, Internet Service Providers (ISPs). Eventually RIRs will run out of IPv4 space to allocate, followed by an ISP near you. The potaroo site, famous for its predictive tracking of the exhaustion of IPv4 space over the last few years, has published a frequency distribution for each RIR indicating for the estimated probability of IPv4 exhaustion by time frame.

This chart indicates that the Asia Pacific region will likely be the first to face exhaustion at the RIR level. The Asia Pacific Network Information Centre (APNIC) appears to be likely to exhaust its IPv4 space before the end of this year! According to the chart, the European region served by the RIPE NCC will exhaust in about a year or so, followed by North America’s ARIN RIR, exhausting in about one and a half to two years. The Latin America and Africa regions, served by LACNIC and AFRINIC respectively, have a relatively lengthy remaining IPv4 lifetime, not likely to exhaust until 2014 or later.

As IPv4 address space availability shrinks, requirements for obtaining IPv4 address space will become increasingly stringent. But with the continued growth of converged and virtualized IP devices, networks, services and applications, such controls will merely add flow control and only minimally extend the exhaustion date. IPv6 will soon be the only IP address space available for new address space requests. Now is the time to learn about and plan for IPv6!

Tuesday, February 1, 2011

First Domino Falls in IPv4 Address Space Exhaustion

As of today, IANA has allocated two /8 IPv4 blocks to APNIC, leaving five remaining /8 blocks. As discussed in a prior post, IANA will now allocate the remaining five /8 blocks, one each to the five Regional Internet Registries (RIRs). IANA's IPv4 address space has been exhausted!

Each of the RIRs now has finite and fixed IPv4 address space for allocation to ISPs. This may take a few months but soon the RIRs will exhaust followed by exhaustion of IPv4 space available to end users. The time to start learning and planning for IPv6 is now!

The timing is perfect given my talk today at Cisco Live! in London regarding IPAM. I will raise major news and reinforce my recommendation to start the process today!