Белая книга для Cisco Cisco Prime Network Registrar 8.0

Page 1 of 8

White Paper

IPv6 and Applications

Abstract

The deployment of IPv6 requires new strategies, practices, tools, and applications. As IPv6 moves toward full

industry adoption - and as it becomes the primary foundation for next-generation networks - it introduces

complexity that falls outside of the current network infrastructure focus. One area of this complexity that has had

little attention is network applications. Crucial to the success of any IPv6 rollout will be the requisite modifications of

applications that both use and support IPv6.

Introduction and Assumptions

There are many drivers and stakeholders for IPv6 adoption abound, but the most visible message has been that of
imminent “IPv4 address exhaustion”. Because most of the press surrounding early IPv6 adoption has focused on

address exhaustion, application and network developers have incorrectly assumed that the effect of IPv6 adoption

in their domains will be insignificant. On the contrary, older networks, services, and applications will be affected, as

well as new applications development related to IPv6 adoption, such as:

●

The 128-bit IPv6 address vs. the IPv4 32-bit address may affect applications.

●

Formats and data structures for address support are different; for example, canonical form vs. noncanonical

or flexible form.

●

Hierarchical addressing in IPv6 introduces issues with some applications.

●

IPv4 broadcast addresses will be eliminated.

●

IPv6 anycast addresses will be introduced.

For context of this article, “applications” are defined as somewhat generic in nature. This article addresses:

●

Network applications and services that use IPv6

●

Applications that manage IPv6 or applications that IPv6 uses (nodes, routers, services, etc.)

This paper assumes a migratory and evolutionary path for compliance of applications moving from IPv4 to IPv6

that closely follows the actual strategy, development, and deployment of IPv6 networks themselves:



Dual-stack transition mechanism (DSTM) solutions initially give way to:



Translation solutions through Application-Level Gateways (ALGs) or protocol translators that lead to:



Native IPv6 applications, and ultimately the goal of:



IP-agnostic applications for network services and management

The stated assumption that DSTM will be the initial primary means of transitioning from IPv4 to IPv6 is realistic.

What is not realistic is the statement that has been in print that if DSTM is used, then applications do not require

any modification. This article provides ample evidence that applications should be in focus early in the IPv6

migration lifecycle. For the sake of argument, most IPv4 applications will work in any DSTM environment, though

the cost is high because each node must support DSTM with an initial heavy use of tunnels.

It is assumed that the information provided in this article should be used early in the development of any IPv6

strategy and design and should not be relegated to later efforts.