TRIAD has a clear, low-cost deployment path, based on user need, allowing TRIAD to be realized as an incremental evolution of the current Internet.
Consider as an extreme example a country with limited IPv4 addresses
such as Thailand.
The limitations of conventional NAT make it questionable
as a solution to providing more addresses
yet moving to IPv6 does not make sense either (see Appendix).
However, with TRIAD,
each such country can install a WRAP relay router
that interfaces to the Internet.
Attached to this top-level relay are one or more WRAPID gateways
that include conventional NAT capability.
The conventional NAT capability allows these hosts to communicate with
the existing conventional IPv4 Internet.
Each ISP, country or even organization that adopts TRIAD is able to
communicate with other organizations using TRIAD without
consuming any of its precious and limited global IPv4 addresses
.
For instance, if Thailand and Indonesia both adopt TRIAD,
they then have virtually unlimited addresses internally
and between themselves,
and are only constrained on the number of addresses they have
available to communicate with the current Internet.
(This is actually the same situation as if they had internally converted
to IPv6, given they would still have to communicate with the rest of
the planet using IPv4.
But, with IPv6, they would also have to upgrade all their existing
hosts and networking infrastructure.)
Thus, each organization is motivated to adopt TRIAD because it allows them to communicate with other TRIAD organizations without using their limited global IPv4 addresses, and because it makes it easier for other TRIAD users to communicate with them. So, those organizations that are currently short of addresses are motivated to move to TRIAD and those that are not are still motivated if they are interested in having the former communicate with them. Given that most of the major web sites are in the United States, and the U.S. companies have been in the lead to build Web-based operations, there would be considerable commercial motivation to support TRIAD in the American web sites once service providers in other countries were using TRIAD among themselves.
This initial deployment requires no real changes to end hosts and no change to the basic IPv4 routers and switches constituting the infrastructure of the leaf and backbone networks. It only requires the deployment of relay agents and WRAPID gateways, but these are modest extensions of the current NAT-enabled routers. Here, we assume that end-user applications have been or will be modified in any case to deal with the lack of meaning of addresses across NAT boundaries.
Once WRAP is deployed to some degree in the Internet, first host implementations are expected to arise with large-scale servers where eliminating the extra overhead, delay and point of failure of a WRAPID gateway may be warranted. Making an externally accessed server WRAP-enabled also eliminates the server use of an externally visible (IPv4) address which, with an active server, would be essentially allocated indefinitely to this server. During this transition, conventional IPv4 hosts and TRIAD-aware hosts can easily and efficiently co-exist in the same address realm. Given that WRAP appears relatively straight forward to implement, the main delay in getting all hosts upgraded to WRAP is expected to be the basic inertia in getting changes into commercial software and getting administrators of systems to upgrade their software. Hosts that need end-to-end security and reliability are also motivated to upgrade to native WRAP.
NBRP is just one means of providing the name-to-authoritative server mapping needed by DRP. This same information already exists in the current Domain Name System (in the form of NS records, which organizations with domain names already control) so resolver relay agents can make use of the existing naming infrastructure to locate other TRIAD gateways rather than participating in a dynamic routing protocol. We expect deployment to occur mainly at the edges of the network, and thus cannot depend on ISPs providing new infrastructure. Such a scenario could lead to an topology that would have many thousands of realms peering in the ``global'' Internet, but there is little need for NBRP in such an environment. The amount of topological change in such a situation is small, and multihomed sites can easily list all their gateways as NS records rather than constantly updating the DNS. Later, these resolver relays can be upgraded to routing relays as ISPs begin offering NBRP.