Be a Follower

If you are a follower, the problems you face are that you might loose leadership and that early adopters might not solve the problems specific to your environment. A rapid IPv6 ramp-up is not simple, and can be expensive. And, there may be little time left to wait. Being a follower creates a downstream impact of having to react to certain change. Having an unidentified protocol running on an enterprise network can be a potential security threat, if undetected. Current versions of several shipping OSs have IPv6 enabled by default. A few applications might not work properly if IPv6 is enabled end to end.

Organizations will need to make changes to accommodate IPv6 at some point—it is a matter of time. Some straightforward planning and a little effort today can make the future transition much easier. There are a few simple positioning strategies that followers should be adopting now. The level of effort and investment is relatively low, and will make the eventual transition to IPv6 smoother and less costly.

Making minor adjustments to existing processes is often the most effective strategy to address IPv6 as a follower. The changes align (if unexpected adoption drivers do not require quick adoption) with the normal hardware and software life cycle of moving from a development of engineering and testing environments through quality assurance, and then into production. Figure 4-8 highlights the typical packaging that takes place as a product or service moves from its beginning into operation. The organization accepting the turnover package can be viewed as a gatekeeper.

Figure 4-8 Turnover Points for the Process of Technology Integration

Followers can act on some of the process points shown in Figure 4-8 to ease the integration of IPv6 and prepare for its adoption:

• Quality assurance/configuration management: Followers should use their quality assurance/configuration management gatekeeper as a starting point, and move upstream from there. The initial focus should be to simply ensure that hardware and software moving through QA will not fail or introduce security risks when IPv6 is enabled on the hosts and network in a dual-stack configuration. Applications usually go through testing/QA processes prior to deployment in an organization's production environment. The testing/QA environments should be IPv6-enabled end to end. This includes clients, servers, and the network. IPv6 should be part of relevant test plans and QA sign-offs. Verify that all applications will function correctly with IPv6 enabled end to end. Testing to ensure all applications are IP protocol-agnostic is a low-cost, low-risk strategy to prepare for IPv6 deployment in the future. This will avoid "surprises" when the new protocol is eventually turned up in the production environment. QA should perform the following steps:

1 Ensure that the testing environment is running dual-stack, where supported on hosts and networks. Legacy operating systems, such as Windows 2000 Server, should not be included due to their lack of solid support for IPv6.

2 Update requirements of turnover packages from developers/ engineering to include minimum IPv6 requirements.

3 Notify developers that their products will be tested in an environment where IPv6 is enabled on the hosts and network. End-to-end network verification will be a requirement to pass QA certification.

• Application development environment: Java SDKs and integrated development environments (IDE) have supported IPv6 for a few years now. Developers should have IPv6 enabled on their computers and networks. Microsoft is starting to support IPv6 with .NET Framework 1.1 and Visual Studio 2003. There are a few very minor configuration changes that are required to configure the developer workstation and development environment to create IP-version-agnostic code. Newer versions of the IDE have enhanced IPv6 features and support available.

• Application code: The popular open source community collaboration site SourceForge.net lists over 100 IPv6 projects, with over 25 showing an activity rating greater than 80 percent. Structures, API parameters, and other development components will change slightly in a protocol-agnostic application. For example, the function call gethostbyname() must be replaced by the Internet protocol-neutral getaddrinfo() function call. Microsoft has a compile-time flag IPV6STRICT to ensure source code will meet IPv4 and IPv6 requirements. Hard-coded IP addresses should be avoided. Use DNS for name resolution instead. Databases used for IP source/destination address logging should also be modified if there is inadequate room to store the larger IPv6 addresses.

• Protocol-agnostic applications: In-house developed applications often go unchanged for several years. Financially prudent and strategic thinking organizations realize the value of reducing the number of times an application is modified. With this in mind, consider making IPv6

an additional (usually very small) part of new application development requirements and any application modifications. The minor investment now will usually eliminate an IPv6-only application revision in the future. Most applications rely on the OS for network services and will be immune to the introduction of IPv6 in the network. However, some applications and application development environments have specific APIs, definitions, structures, services, or functions that work only in an IPv4 environment.

Today, most products and their development and test environments are IPv6 capable. Many of the implementations and products have been hardened in production. As more stacks and applications come to market at an accelerated rate, some of these products might be less reliable. Going forward, conformance evaluations could become a necessary tool in ensuring quality of IPv6 implementations.

The actions taken to insert IPv6-specific requirements in the process, depicted in Figure 4-8, are a valuable and sometimes inexpensive precursor of the IPv6 integration. Together with other actions, they can pave the road for the IPv6 adoption. Following are some of the actions:

• Basic education and awareness: Organizations make sound business decisions based on knowledge. The decisions around IPv6 are no exception. IPv6 will impact many parts of the organization over time; it is not just a network change. An understanding of the amount of time and effort to make the transition should be factored into future network, application, infrastructure, and training budgets.

• Knowledge of the starting points: An honest gap analysis is helpful in any technology transition. Organizations should have current IT inventory to help assess what systems will need to change when IPv6 implementation is started.

• Leverage of the gatekeepers: IT product and service life cycles include natural turnover points (gatekeepers) as systems move from development through QA into production.

Organizations in a follower position should at least put some short-term effort into the "upstream" areas of hardware, software, and service acquisition, development, and deployment. The short-term goal should be to simply stop doing anything that perpetuates a mandatory dependence on IPv4.

0 0

Post a comment