Following an address request, the server asks the DSTM gateway to add a Tunnel End Point (TEP) for the requesting DSTM client. It is the server who controls the IPv4/IPv6 address mapping performed at the DSTM gateway. Initial versions of DSTM considered that the gateway would build its IPv6/IPv4 mapping table dynamically by observing packet headers, but this approach is now obsolete due to
security concerns.
If the end point for the new tunnel is successfully created, following the answering message from the gateway, the DSTM server (who manages an IPv4 address pool) replies to the host with the following information (step 2):
• The allocated IPv4 address,
• The period over which the address has been allocated
• IPv4 and IPv6 addresses of the TEP.
This information is used by the client to configure an IPv4-over-IPv6 tunnel towards the DSTM gateway (step 3). At this point, the DSTM client has IPv4 connectivity and, if it obtained a global IPv4 address, it will be able to connect to any external IPv4 host.
In DSTM, the period of allocation can be configured based on address availability. Clients are required to ask for allocation renewal before allocation time expires. Depending on local policy and client behaviour, the DSTM server may accept or deny extending the allocation. In normal operation, requests for allocation renewal are periodically sent until the address is no longer needed by the client.
As long as the address allocation is extended, the DSTM server is not required to update the IPv4/IPv6 mapping table at the gateway. However, when the allocation expires, the gateway must be informed in order to update its tables and to allow other clients to reuse the TEP for the freed IPv4 address.
The DSTM gateway is in charge of packet forwarding between the IPv6-only domain and IPv4 networks. It performs packet encapsulation/decapsulation using an IPv4/IPv6 mapping table. For successful bi-directional communication, it is very important to allow IPv4 forwarding at the gateway and to make sure that, for any IPv4 packet coming from the outside, the route to the DSTM client points to the TEP.
DSTM should be used in a network domain where IPv6 routing is enabled and ALL nodes within that domain are able to communicate using IPv6. In this case, IPv4 support can be turned off. Thus the burden of maintaining an IPv4 addressing plan and supporting IPv4 routing is removed. However, given the huge number of IPv4-only hosts and applications in the Internet, a number of hosts inside IPv6-only domains will still require IPv4 connectivity.
DSTM can be deployed where no other solutions, such as ALGs, can be implemented. DSTM allows dual-stack nodes to obtain an IPv4 address and offers a default route (through an IPv4-in-IPv6 tunnel) to an IPv4 gateway. Any IPv4-only application can run over an IPv6-only network if such a scheme is used and, if DSTM is configured to allocate Global IPv4 addresses, hosts inside that domain will be able to communicate with any other host on the Internet.
DSTM may be deployed in several phases. As a first step, IPv4 connectivity may be assured by manually configuring tunnels from dual-stack nodes to a Tunnel End Point (TEP). In a second phase, when address allocation or tunnel set up protocols become available (DHCPv6, TSP), it would be possible to dynamically assign an IPv4 address to nodes which need one. In this phase, the address may be allocated for the whole lifetime of the requesting node, reducing the complexity of address management. Finally, when IPv4 address availability becomes a problem, DSTM may be configured to allocate addresses only for small periods of time, based on the real needs of requesting hosts.
Since the address allocation process in DSTM is triggered only when IPv4 connectivity is strictly necessary, the size of the IPv4 address pool required by the mechanism should decrease with time (as more hosts and applications become IPv6 aware). However, if the lack of IPv4 address space continues, DSTM may be extended to include the ‘ports option’ [Shi05], allowing simultaneous use of the same address by several hosts, but increasing complexity.
