Application as a service

The summer of IPv6: IPv6 strategies for content and application providers

 Application as a service  Comments Off on The summer of IPv6: IPv6 strategies for content and application providers
Jul 132012

Oh summer, lovely summer. Time to think, plan, learn new things. Time to enjoy gardening up here in Sweden. During the long dark winter, the garden is hidden under a layer of snow, so as a gardener there’s only a few months to enjoy your flowers and vegetables. The Swedes are moving out in gardens or to cottages on the countryside, always connected. 3G, 4G or wired broadband, but always connected. Users expect the services to work wherever and whenever. Some people travel around, many Swedes go to Thailand for holidays. Still connected, still using the same applications. Soon, even Swedish application providers will get complains that the users can’t reach the services while traveling. The net will be broken. “Google and Facebook works, but your application can’t be used.” Application and content providers need to prepare for the change to IPv6, because even if you have a local customer base, they don’t stay in one place or on a single network. They are mobile. And still need to connect. Let’s look at IPv6 for application providers!

IETF Draft: IPv6 Guidance for Internet Content and Application Service Providers

The Summer of IPv6The IETF is really helpful with advice for the transition to the IPv6 protocol. A document being worked on is aimed exactly at the content providers on the net, explaining what’s going on and what’s needed. The introduction is clear and to the point. You will loose business if you don’t do anything now.

“The deployment of IPv6 [RFC2460] is now in progress, and users with no IPv4 access are likely to appear in increasing numbers in the coming years. Any provider of content or application services over the Internet will need to arrange for IPv6 access or else risk losing large numbers of potential users. In this document, we refer to the users of content or application services as “customers” to clarify the part they play, but this is not intended to limit the scope to commercial sites.”

The authors, B. Carpenter and S. Jiang,  stress the fact that the time for action is now, before you actually see that you have issues so large that they will affect your business. You have time to learn, lab and get the skills to migrate. In addition, the introduction of IPv6 service should not make the user experience worse. IPv6 should enhance your service, not provide a poorer service either to IPv4 or IPv6 users. With the addition of WebRTC realtime multimedia web browsing IPv6 without single or double NAT access will actually be the preferred choice for your users.

Inside-out or outside-in strategies

The document proposes two strategies. Outside-in is the strategy where you start with the outside facing services, maybe adding a reverse proxy to enable IPv6 access and work towards the inside, IPv6 enabling service after service, layer after layer. Inside-out starts by enabling the internal infrastructure, moving to the outside and finally exposing services using IPv6.

“Which of these approaches to adopt depends on the precise circumstances of the ICP concerned. “Outside in” has the benefit of giving interested customers IPv6 access at an early stage, and thereby gaining precious operational experience, before meticulously updating every piece of equipment and software. For example, if some back-office system, that is never exposed to users, only supports IPv4, it will not cause delay. “Inside out” has the benefit of completing the implementation of IPv6 as a single project. Any ICP could choose this approach, but it might be most appropriate for a small ICP without complex back-end systems.”

Use the old guys on the block!

The IETF draft is very extensive and covers both strategies and technical issues content and application providers need to consider. Good reading for everyone!

I laughed a bit at the following quote: “Some older staff may have experience of running multiprotocol networks, which were common twenty years ago before the dominance of IPv4.”. When I started using TCP/IP, it was an add-on to existing networks. IBM, Microsoft, Apple, Digital Equipment, Xerox – everyone had their own network and we added TCP/IP alongside it. Regardless, IPv6 will be a new protocol for everyone. And we did not use the dual stacks to reach the same services in those old networks, so problems like Happy Eyeballs are new even to us old grumpy networkers.

A lab is very useful!

I will leave you to read the document by yourself with one last quote:

“It is very useful to have a small laboratory network available for training and self-training in IPv6, where staff may experiment and make mistakes without disturbing the operational IPv4 service. This lab should run both IPv4 and IPv6, to gain experience with a dual- stack environment and new features such as having multiple addresses per interface, and addresses with lifetimes and deprecation.”

That’s it for today! Start building your lab. All you need is your laptop, a virtual machine and an IPv6 tunnel. From there, build a network lab with IPv6-only and IPv6/IPv4 dual stack parts to test your application and services. Add reverse proxys, try what happens with putting your services on dual stack. Learn IPv6 this summer!

Have a great IPv6 week!


PS. Please note that the document is still a draft being discussed, it’s not finalized yet. If you want to join the discussions, join the IETF IPv6 operations mailing list.

 Posted by at 08:30