Internet Protocol Version 6 (IPv6) is considered to be the next generation protocol for the Internet. It is designed to support continued Internet growth in the number of users, along with greatly enhanced routing functionality. The current version, Internet Protocol Version 4 (IPv4), was developed in the 1970s and provides the basis for today’s Internet functionality. However, IPv4 suffers from some serious limitations that are now inhibitors to any more growth of the Internet which in turn, inhibits additional integration of the Internet as a global business networking solution. IPv4 provides 232 (4,294,967,296) addresses. Although this appears to be a very large number, it is now insufficient to support the requirements of the maturing Internet.
IPv6 has been under development by the Internet community for over ten years and is designed to overcome these limitations by greatly expanding available IP address space, and by incorporating features such as end-to-end security, mobile communications, quality of service, and system-management burden reduction.
The true transition of the global Internet from IPv4 to IPv6 is expected to span many years. And, during this period of transition, many organizations introducing IPv6 into their infrastructure will support both IPv4 and IPv6 concurrently. There is not a one-size-fits-all transition strategy for IPv6. The incremental, phased approach allows for a significant period where IPv4 and IPv6 can co-exist using one or more transition mechanisms to ensure interoperability between the two protocol suites. The most often used methods of performing this transition is by operating in a dual-stack environment, and the use of tunneling and translation between the two versions of Internet Protocol (IP).
Although there is seldom a viable dialogue between a company’s technical decision makers (TDMs) and business decision makers (BDMs), a professional CCNA must always recognize that any addition to, or modification of, an existing or newly installed network will require an additional amount of money, commonly known as transition costs. Transition costs can be classified as either recurring or non-recurring, and can stem from several sources. However, they are most commonly associated with software and hardware acquisition, employee training, consulting services, and operational costs.
Transition to IPv6 can be phased into an organization’s infrastructure and applications through a lifecycle management process. Organizations expect to acquire IPv6 capability while upgrading infrastructure as part of the normal technology amortization-replacement lifecycle. The availability of transition mechanisms will enable organizations to replace only that equipment deemed necessary to facilitate IPv6 integration. As existing equipment is replaced with newer equipment, native IPv6 capability will be part of the equipment’s basic operating capability. Consequently, the cost of transition from equipment replacement should be significantly minimized.
Training will be an important part of the integration process. IPv6, while built on many of the fundamental principles of IPv4, is different enough that most IT personnel will require formalized training. The level of training required will vary, and will depend on the role a member of the organization’s IT staff plays in developing, deploying, and supporting IPv6 integration. Companies will potentially need to make plans for training their staff.
There are four main categories of training that are considered to be the most critical for any organization that is transitioning from IPv4 to IPv6.
- Awareness – This is generalized information about IPv6 and IPv6-related issues. This type of training is most commonly delivered through workshops, seminars, conferences, and summits. These types of events typically provide overviews of IPv6 technologies, identify vendors that support IPv6, and provide participants with a rudimentary understanding of the IPv6 technology, as well as business drivers, deployment issues, and potential services and/or products enabled by IPv6.
- Architectural– Training in this category should be very detailed and oriented toward those individuals who will have primary responsibilities in designing the architecture and deploying IPv6. Although the type of subject matter will be quite broad, particular attention should be paid to the fundamentals of IPv6, DNS, and DHCPv6, auto-configuration, IPv6 address allocation, transition mechanism, security principles for IPv6 environments, and mobility. Additional topics covered should be routing, multicasting, and principles for connecting to the IPv6 Internet.These topics are the areas where participants will encounter the greatest number of new subjects relative to IPv6, and will have the greatest impact on the development of successful integration plans.
- Operational– Once IPv6 has been integrated into the network, it will need to be supported. Operational training will consist mostly of job-specific training targeted to a participant’s job responsibilities. Core topics such as the fundamentals of IPv6, auto-configuration, and transition mechanisms will need to be covered.However, the bulk of operational training should focus on supporting applications or protocols that have IPv6 underneath them. One example is training for system administrators focusing on supporting IPv6-enabled e-mail and web servers. Operational training will often be hardware- or software-specific, generally produced by or for a particular vendor’s product.
- Specialized – As IPv6 deployment advances and the base level of understanding becomes more pervasive, the need for specialized training will emerge. This type of training should focus less on IPv6 specifically and address greater technological topics where IPv6 plays an important role.
All of my posts addressing the transition from IPv4 to IPv6 could be considered as falling into the Awareness category of training. And, my next one will specifically address the three most commonly used transition strategies, known as dual stack, tunneling, and translation between the two versions of IP.
Author: David Stahl