Given the background described above, it was obvious that 6NET needed to use IPv6 as the transport protocol as widely as possible during the life-cycle of the project. (See Appendix A2 for a snap-shot of systems used to provide name services for 6NET). The overall aim of 6NET was to “go native” as early as possible. The network layer itself needed to be as stable as reasonably possible. This meant that routine operations, management, fault identification and repair needed be straight-forward. This required alignment and integration of the DNS service for 6NET with the existing IPv4-based Internet. This meant operation of DNS services on the top of IPv4 protocol stack, and completing the IPv6- based communication provisions.

In order to understand some of the decisions taken, it should be noted that DNS is both an application (in fact a distributed and replicated database which uses the basic network transport services IPv4 TCP/UDP and IPv6 TCP/UDP) and an essential support service for the operation and management of an IP-based internet.

Most of the partners in 6NET (NRENs, companies) either have a working DNS environment already at their disposal or can use the services of their “upstream” service providers (e.g. individual university partners can make use of the services of their NREN). Therefore the initial goal for a DNS service for 6NET was to take care of the operational requirements of the 6NET backbone.