Cisco Cisco Prime Network Registrar 8.0 White Paper

Page 3 of 8

Migration to native and transition IPv6 infrastructures and network services affects both client and server use of

DNS. With regard to a generic context or perspective, the application initially queries DNS for the default IP

protocol; when the application finds that protocol, it returns the specific record format. Failing that query, the
application fails over to the alternate record format. For example, Microsoft’s Vista assumes IPv6 is on and is used

by default. All initial queries are made for, and are expecting, authentication, authorization, and accounting (AAA)

records (IPv6 records), not A records (IPv4 records). If the IPv6 network is correctly designed and all necessary

network services and applications are appropriately located in the IPv6/IPv4 network, then IPv6 DNS will always be

the preferred solution.

Another problem that can affect application delivery focuses on the interaction between the resource records and

the host name component. Also critical to the success of any DSTM design is the fact that the DSTM itself must be

able to support receipt of both A and AAAA (quad A) resource records (32-bit IPv4 addresses and 128-bit IPv6

addresses, respectively) in its own use of DNS and must conform its processes to the returned record format to

any requester. In the case of A and AAAA record returns for the same query (name), the DSTM application must

be able to identify by policy or configuration which is the preferred IP and then resolve the query based on that

policy or configuration tuple.

You should address the following recommendations and concerns early in the applications development, porting,

or design to support IPv6 fully and well:

●

The native application behavior must discern if it is talking to an IPv4, an IPv6, or an IPv4/IPv6 transition

node. When that determination is made, the application needs to implement the appropriate policies or

configuration behavior.

●

In order to maintain “A” records for backward compatibility throughout the dual-stack transition, the

applications developers should lead the strategy to ensure the transition application solutions are not the

final ones implemented for the specific applications; eventual native IPv6 behavior should be the target.

●

You must determine whether older applications, and their owners, provide enough documentation to

ascertain how embedded the IP addressing is in the application and also determine the proprietary

schemes used to support IP. As we all learned in the Y2K debacle, much application design and code

information is either lost or it left with the developer(s) responsible for its creation.

●

You must ensure that the latest version of BIND is always implemented and well-tested.

●

You must determine the following: Is DNS hierarchy fully documented for the transition period? Is there a

similar documented strategy for post-transition? Does the IPv6 management strategy account for the

integration of location (and all other factors) into DNS, or are the strategy, architecture, and solution just a

short-term fix?

As with any of these presented steps and strategies, their order of execution is critical to the ultimate success of

the applications. Because IPv6 is relatively new (in terms of architects, engineers, and skill sets of support staff),

very few BCPs are available for common reference.

●

Upgrade DNS server software to an IPv6-compatible version.

●

Ensure that all IPv6-specific OS functions are well-understood and implemented by the applications

and DNS.

●

Add dual-stack.

●

Add IPv6 addresses to DNS records.