IPv6: The High VoLTEage Telephony Generator

According to IDC, smartphones outsold personal computers, laptops included in Q4 2010! Nokia just announced the demise of the Venerable Symbian in favour of Windows 7 phone and Microsoft’s bing search engine! Tectonic shifts are under way to adapt to the rise of wireless broadband, an all IP world, and the growing weight of Apple and Google Android. It is also time to head once again for Barcelona with the Mobile World Congress starting on the 14th. Highlights this year? Most probably smartphones and LTE, the only reasonable way to accommodate the upcoming deluge of traffic and associated bandwidth. 180 carriers in 70 countries are now at various stages of testing and deployment while the first 17 LTE networks became operational over the last year and 64 are anticipated to be up and running by end of 2011. Sixty three LTE devices are already approved including the first LTE phones. Verizon and MetropPCS both announced their first LTE smartphones as ready to enter the market .

It might seem obvious that one should be able to talk, send SMS’es and roam with these LTE smartphones; telephony signalling and IP are not obvious bedfellows however. Telephony always loved its signalling with its call set-ups and call-terminations, call data records generation, metered billing and roaming charges. After all considerable revenues are associated with telephony, SMS and roaming. LTE runs over IP however where there is no longer separation of signalling and the call itself. This is where VoLTE and its associated IMS (Internet Multimedia Subsystem) come in. Without a telephone number based signalling system anymore, there will ultimately be only IP addresses to “set up the call”. The need for a one to one correlation between IP addresses and ‘subscriber’ and their various services is rather obvious in this context. Five billion smarter phones with multiple services, plus billions of devices begging for unique identification to communicate seamlessly and accurately m2m, imply untold numbers of unique IP addresses.

Yesterday, I was informed that a major 3G Mobile Operator just got their request for a block of IPv4 addresses refused by their RIR for reasons of imminent shortage and is now scrambling to get some advise and council on that famous IPv6 transition. …Sign of things to come? A recent IETF draft happens to cover possible paths for MNO’s considering IPv6 transition. Some brushing up on LTE and VoLTE [PDF] should come handy when urged to put a roadmap together. Within a short couple of years, hidden under the hood, IPv6 will provide enormous amounts of VoLTEage. After all, it was designed with mobile in mind.

Written by Yves Poppe, Director, Business Development IP Strategy at Tata Communications

Configuring Microsoft Active Directory to Support IPv6

Making Sure AD Supports your IPv6 Architecture in your Microsoft Windows environment.

Complete info at NetworkWorld.

Planning Your Cutover to IPv6 for your Microsoft Windows Environment

Getting to IPv6 in a Managed and Orderly Manner.

In this blog post on IPv6, I’m going to cover what we’ve found to be a well organized and managed process of getting from an IPv4 environment to an IPv6 environment, effectively putting the chicken and the egg in the right sequence…

Step 1: Getting your IPv6 Address Block
Step 2: Architecture Design for IPv6 Mapping
Step 3: Implementing your First IPv6 Server
Step 4: Static Addressing
Step 5: Configuring DHCP
Step 6: Implementing IPv6 Remote Access
Step 7: Configuring Internetworking for IPv6
Step 8: Final Assessment of IPv6 Completion

Complete info at NetworkWorld.

Secure64 Releases New Version of DNS Caching Software

Secure64 Software Corporation today announced the latest release of its popular caching software appliance — Secure64 DNS Cache v2.5 — the most secure caching name server software available. This new version provides support for DNS64, an emerging standard that provides service providers a simple way to transition to IPv6 networks. Secure64 DNS Cache is the first carrier-grade product to offer support for DNS64.

Complete info at VPO.

How the End of IPv4 Affects Email and Hosting

Anyone who has been watching the technology industry for more than a couple of years quickly learns to recognize FUD: Fear, Uncertainty and Doubt. FUD is (apparently) widely believed to be an effective marketing technique, especially when it comes to security, privacy, or scarcity.

But the FUD often falls flat. Scarcity, in particular, is rare on the internet — even rarer than privacy or security. There’s constant FUD about scarcity of bandwidth, but the pipes get upgraded. Attempts to impose artificial scarcity through paywalls or other devices inevitably fail in the face of free alternatives. Even the scarcity of IPv4 addresses, which have indeed run out at the top, hasn’t affected end users at the bottom yet — and probably won’t, for a long time.

Saying that there aren’t any more IPv4 addresses is, quite simply, FUD. We all know it’s FUD because our computers can still connect to the internet. Repeating FUD simply dilutes the message, and often results in reporting which is just laughably wrong.

What’s actually happened is that ICANN, which assigns large ranges of IPv4 addresses to regional registries, has run out of ranges to assign. The regional registries, which in turn assign large blocks of IPv4 addresses to network providers in their region, have for the most part not run out — yet. But they will, eventually, and that’s forcing the network providers to be more cautious about assigning IPv4 ranges to their customers — including the access providers and hosting companies who in turn assign smaller ranges and individual IPs to mail, web, and other servers, and to end users.

What will have to happen between now and then is fairly clear.

First, services which rely on using multiple IP addresses to separate traffic will have to change their architecture. This includes many web hosting environments, because for a long time HTTPS required a separate IP address for each site — but that’s changed, it isn’t necessary any more. Multiple HTTPS sites can now share a single IP address.

It also includes ESPs, who tend to assign one or more IPv4 addresses to each customer that they send for in order to ensure that each has a distinct IP reputation, and to participate in Return Path Certification. But now, we’ve got domain reputation built on DKIM — you can have an effectively infinite number of different signing (d=) domains sent from a single IPv4 or IPv6 address. The big mailbox providers and MTA and filtering vendors have all been getting ready for this, but they can’t bring domain reputation to the forefront and deprioritize IPv4 reputation until the majority of legitimate, wanted mail is signed with DKIM. Similarly, Return Path can’t move our Certified program entirely to domains until both the senders and the receivers are ready for it — which is part of why we’re now requiring DKIM even for IP-based Certification. So, in effect, the ESPs and other large-scale senders have to switch to domains first.

(Many of us in the email industry expect that mail will continue to be transferred from system to system over IPv4 for the foreseeable future, but it’ll get tightened down over time.)

At the same time, customer premise equipment (CPE) — the routers and modems that connect end user networks to their access provider — need to be updated to use IPv6 correctly. Comcast, in particular, has been pushing CPE vendors to make this possible and running lots of tests. If you’re interested, we could cover this in a future article.

And finally, after all of that, we can start talking about deprovisioning the IPv4 addresses which are already out there in favor of moving everything to IPv6, rather than running both networks in parallel.

But, what will convince all of these companies — especially ESPs and hosting firms — to actually make this investment in their future? Maybe that’s where the FUD comes in — maybe they have to be scared into making the right decision. But I’d rather think that they’ll have the foresight to do it calmly, intelligently, all on their own — perhaps after this free training from MAAWG.

And if not, well…sometimes FUD comes true.

(This article was originally published on Return Path’s Received: blog.)

Written by J.D. Falk, Internet Standards and Governance

Test your IPv6

This will test your browser and connection for IPv6 readiness, as well as show you your current IPV4 and IPv6 address.

Q: How does this test work?

The test is entirely client-side javascript. To determine reachability, a series of ajax requests are made from the web server, using various DNS names that force the use of IPv6 only, or dual stack, or other such scenarios. The pass/fail of such fetches, as well as how long they take, are taken into account.

Try the test yourself at http://test-ipv6.com/