Introduction

If you’ve been happily stranded on a deserted island somewhere in the South Pacific for the last few years -- without WiFi -- then you might not have heard that the world is running out of IPv4 address space. It’s simply a matter of time before you will be required to migrate to the latest version of the Internet Protocol, Version 6 (IPv6). Aside from increased address space, other valid reasons to migrate from IPv4 to IPv6 include a more simplified network topology, content-based network routing, and security features, such as IPSec. Transitioning to IPv6 is not really a matter of if (it will happen), or even when (soon), it’s a matter of how.

The old saying ”the current run time rules” implies that your current IT infrastructure dictates future technology choices. While IPv4 (the current address scheme) provides more than 4 billion unique addresses, there are many more network-based devices using the Internet, each needing its own unique address. In fact, we have already technically exhausted the number of unique addresses that can be provided directly by IPv4. In the absence of enough address space, network engineers designed sub-optimal “workarounds,” like Network Address Translations (NAT) and extensions to the IPv4 specification, which enabled a temporary increase in the number of addressable network devices. NAT and other IPv4 extensions have merely delayed the inevitable exhaustion of possible IPv4-based network addresses. Today, we can no longer sustain the growth of network-based devices using IPv4 and are now essentially forced to move to IPv6.

Unfortunately, NAT and other IPv4 extensions have not only increased the possible number of IPv4 addresses, but also significantly increased the complexity of network topologies, which in turn impacts network performance, manageability, and security. IPv6 alleviates the need to deploy similar sub-optimal network architectures; however, it does not prevent similar topologies. Therefore, when deploying a new IPv6 infrastructure network architecture, you must avoid deploying a v6-based network architecture that mirrors the existing v4 architecture. Overlaying an IPv6 network topology over an existing IPv4 infrastructure would significantly diminish the value of the transition and potentially cause performance and security issues. (See U.S. Federal IPv6 Transition Guidance for details.)

One option that facilitates transition from IPv4 to IPv6 is the use of dual stack enabled IT components. This requires that both network and application components have the ability to manage both IP stacks and route messages regardless of network protocol.

By deploying a dual IPv4/IPv6 stack solution, IT components can interoperate by effectively translating one address scheme to another. This strategy enables existing IPv4 components to communicate directly with IPv6-enabled applications and network components without the need to expend resources to migrate existing components to IPv6. While dual stack is a valuable method of facilitating interoperability, it does not enable the use of advanced IPv6 capabilities (for example, content-based routing) from IPv4-based devices.

Most legacy IT systems, applications, and vendor product deployments will need remediation in order to migrate to an IPv6 network. Some legacy IT systems and components may never be candidates for migration to IPv6, especially if the vendor does not plan to remediate back-leveled components. Migration of existing IT systems will stretch over many years. For these reasons, you need a method for interoperating between existing IPv4-based systems and the growing number of IPv6 systems that avoids the need to mirror the existing IPv4 topology when a new IPv6 network is deployed. A dual stack strategy should only be employed as a gateway between the existing IPv4 network domain and the ever growing IPv6 domain, as shown in Figure 1. Otherwise, you will fall into the dual stack trap that forces the enterprise to overlay the IPv6 domain on the existing IPv4 domain, effectively mirroring the same inefficiencies IPv6 was designed to avoid in the first place. This includes NAT segmentation, which is a by-product of the limited IPv4 address space and routing protocol. Third party gateways are available to provide a network-based solution for v4 to v6 interoperability and transition. The challenge with these network-based gateway solutions is that they can be expensive and can stifle transition to IPv6 by creating tight bindings between IPv4-only applications and new IPv6 applications.

An Enterprise Service Bus (ESB) bridge creates loose coupling between systems and applications that facilitate migration of services to the IPv6 domain with minimal impact to existing services. An enterprise with an SOA strategy will need an ESB for mediation regardless. Alternatively, organizations can leverage their investment in their existing ESB, like IBM® WebSphere® ESB, which provides support for IPv4 to IPv6 protocol translation. This provides an alternative that bypasses the need for additional network hardware and investment.

An ESB, with mediations, performs these services between a requester and service:

• Routes messages between services.
• Converts transport protocols between requester and service.
• Transforms message formats between requester and service.
• Handles business events from disparate sources.

WebSphere ESB provides a message and event-driven messaging infrastructure based on service-oriented standards. An ESB provides mediation services that enable the transformation of messages to different formats and protocols. WebSphere ESB provides the ability to convert transport protocols between the requester and the invoking service (Figure 2), and enables the definition of the IP version (v4 or v6) when defining the protocol requirements for endpoints. The translation from IPv4 to IPv6 occurs within the ESB and requires no additional programming.

The ESB routes messages between applications, which are requesters or service providers. The ESB converts transport protocols and transforms message formats between requesters and providers. You can leverage this ESB capability by deploying it to create an IP bridge between the IPv4 cloud and the IPv6 cloud. This technique provides loose coupling between application services in an IPv4 domain and those in an IPv6 domain. IPv6-based systems and applications can then leverage IPv4 legacy applications using an SOA interface by using the mediation and protocol transformation services of the ESB.

In Figure 3, each application uses a different IP protocol and different message formats. There is no direct IP route between application A and application B. A node corresponds to a logical or physical computer system with a distinct IP host address. Node names usually correspond to the host name for a specific computer.

The ESB protocol bridge architecture provides a method to extend and advertise IPv4-based services into the IPv6 domain. The next sections of this paper describe how to setup and test the protocol bridge architecture using WebSphere ESB.

Back to top

Configuring the environment

To create an environment that supports the notion of bridging services across isolated networks, you will need to have (Figure 4):

• An ESB server that is only available via an IPv4 address.
• An ESB server that is only available via an IPv6 address.
• A DNS server and another ESB server that are on a dual stack network that enables them to communicate with each other.

This can easily be configured via the DNS server entries. It is possible to configure the deployment topology by having only IPv4 address entries for servers in the IPv4 network, IPv6 address entries for servers in the IPv6 network, and two sets of entries -- one with an IPv4 address and one with an IPv6 address -- for each server in the dual stack network (Figure 5 shows a forward lookup example, Figure 6 shows a reverse lookup example).

Back to top

Configuring the sample application

When you have the network configured, you can build and configure a simple application that will utilize the ESB on the dual stack network to pass services from each of the isolated networks to the other. Figure 7 summarizes the application topology with various J2EE™ and ESB mediation applications running on indicated hosts.

The sample application components described here are available in the download file included with this article. Within this file, you will find the EAR files deployed on each of the servers described above. Additionally, a text file defining the explicit URLs for the applications are included for each server. These application components, when used together, will provide the basic mechanism for bridging services on isolated networks utilizing WebSphere ESB:

• AboutSelfServiceEAR.ear

  This J2EE application implements the core “heartbeat” and “who am I” logic:

  • aboutMe() method provides the capability for the “who am I” request. It takes no parameters and returns a string literal of “Server” or “Client” when invoked.
  • aboutMyCommunity() method provides the capability for the “heartbeat” request. It takes no parameters and returns a string literal containing the server name, such as “IPv6-IPv6” or “IPv6-ESB” or “IPv6-IPv4”, depending on where this implementation is hosted and running.

  Participants in an exchange can be clients or servers.

• AboutSelfServiceClientEAR.ear

  This J2EE application implements universal client logic in a JavaServer™ Page (JSP). This application takes a parameter as an input and invokes “who am I” and “heartbeat” methods on an appropriately chosen local or remote implementation.

• IPMediationModuleApp.ear

  This mediation application runs on each server. It provides an Service Component Architecture (SCA) wrapper to the AboutSelfServiceEAR.ear implementation running on the same server. This application uses the delegation pattern.

• IPV6_624_ProxyApp.ear

  This mediation application runs on the IPv6-IPv6 server. It provides a proxy SCA wrapper façade to the remote AboutSelfServiceEAR.ear implementation running on the IPv6-IPv4 server. This application uses the delegation pattern to delegate the call to the ESB_624_MedModApp mediation application running on the IPv6-ESB server.

• IPV6_426_ProxyApp.ear

  This mediation application runs on the IPv6-IPv4 server. It provides a proxy SCA wrapper façade to the remote AboutSelfServiceEAR.ear implementation running on the IPv6-IPv6 server. This application uses the delegation pattern to delegate the call to the ESB_426_MedModApp mediation application running on the IPv6-ESB server.

• ESB_624_MedModApp.ear
  ESB_426_MedModApp.ear

  These mediation applications run on the IPv6-ESB server. They provide mediation between IPv6 and IPv4 network islands, and use the delegation pattern to delegate the calls to the AboutSelfServiceEAR.ear implementation running on IPv6-IPv6 or IPv6-IPv4 servers.

Table 1 summarizes the distributed deployment of the various applications on the network topology shown in Figure 7.

Back to top

Running the application using the ESB bridge

The sample application described above, when configured on this network architecture, can be utilized to exhibit the ability of WebSphere ESB on a dual stack network to bridge services between single stack networks. To do this, you will need to run a combination of scenarios. Each of these scenarios can be realized by entering a definitive input value in the Endpoint Tier field presented in the browser when loading the application’s URL. Table 2 describes the service invoked and provides related remarks based on the input value entered into the Endpoint Tier field.

To run the universal client on any server, launch a browser and point the URL to http://hostname:port/AboutSelfServiceClient/AboutSelfServiceClient.jsp, where hostname can take the values of (in this example) “IPv6-IPv6” or “IPv6-ESB” or “IPv6-IPv4” and port number be 9080 (depending on installation order). When you run this client, you have the option of entering one of several values into a field, called Endpoint Tier. What the application does then depends on the value entered. Table 3 summarizes the endpoint URLs and some remarks for each input option on each host.

Back to top

Sample of input values and responses

Figures 8 and 9 illustrate results received on the IPv6-IPv6 host when the input value of “0” is entered into the Endpoint Tier field of the sample application.

This testing sequence for all Endpoint Tier field input values can be performed on each of the hosts servicing this application with success.

Back to top

Summary

After configuring the network infrastructure and implementing the sample application provided with this article, you should be able to see how it is possible and advantageous to utilize IBM WebSphere ESB V6.2 within an SOA infrastructure to bridge legacy and non-legacy applications that reside on separate network protocol stacks. Deploying this model enables you to more easily migrate systems and applications from IPv4 to IPv6 networks.

Back to top

Acknowledgements

The authors wish to gratefully acknowledge the help they received from Jeremy Scheer, McLean Technical Exploration Center System Administrator, for administering the test environment.

Resources

• U.S. Federal IPv6 Transition Guidance
  
  
• IBM WebSphere ESB product information
  
  
• IPv6 at IBM
  
  
• Discover IPv6
  
  
• IBM developerWorks WebSphere
  
  

About the authors

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Configuring the environment
• Configuring the sample application
• Running the application using the ESB bridge
• Sample of input values and responses
• Summary
• Acknowledgements
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into WebSphere on developerWorks

Cloud computing for developers

Virtual workshop: Learn how to build a cloud infrastructure and develop/deploy cloud-based applications. (6-8 Apr 2010)

Special offers