Re: on NAT-PT

[Erik Nordmark <Erik.Nordmark@sun.com>]

> There are also other alternatives that would not require IPv4
> routing within the domain.  For example, a dual stack host running
> in an IPv6-only infrastructure could set-up an IPv4 in IPv6 tunnel to the
> a dual-stack router on the edge of the IPv6-only network.  The IPv4 address
> for the dual-stack host could be dynamically allocated/leased, allowing a
> large number of nodes that occasionally use IPv4 to share a smaller
> number of IPv4 addresses.  DSTM offers one example of this type of
> mechanism.

Yes, I think the ability to use DHCPv* to setup tunnels (that terminate
within the same admin domain) is a useful tool, the same way that tunnel 
broker/TSP is a useful tool to setup tunnels that cross admin boundaries
(where some authentication/sign-in is needed). I think that is the key
essence of DSTM.

But I'm not certain one can get much IPv4 address reuse by using short
leases. It depends on the traffic pattern and type of applications
folks use and since that is quite unpredictable the conservative thing
would be to design for the worse case which I think means one IPv4 address
per IPv6 address.

Still, this could be combined with a v4NAT for sharing IPv4 addresses.
I think this is lower complexity than NAT-PT/SIIT since it just piles
boxes (or functions if folks want to implement them in the same
box) after eachother with no interaction between them.
Thus you'd have a box terminating the IPv4 in IPv6 tunnel, and after that
a v4NAT. Thus you avoid running IPv4 except between the tunnel box and
the v4NAT (and externally).

  Erik