Iljitsch,


Tunneling is great, but it requires to allocate an IPv4 address... that I may not have in the first place.

   - Alain.


On 9/28/07 4:39 PM, "Iljitsch van Beijnum" <iljitsch@muada.com> wrote:



On 28-sep-2007, at 6:25, Jari Arkko wrote:

>> And make it works both way, v4 to v6 and v6 to v4.
>> And also don’t call it NAT-PT. That name is dead.

> For what it is worth, this is one of the things that I want
> to do. I don't want to give you an impression that NAT-PT++
> will solve all the IPv6 transition issues; I suspect dual stack
> is a better answer. But nevertheless, the IETF needs to
> produce a revised spec for the translation case. Fred and
> I are organizing an effort to do this.

The problem with NAT-PT (translating between IPv6 and IPv4 similar to
IPv4 NAT) was that it basically introduces all the NAT ugliness that
we know in IPv4 into the IPv6 world. Rather than "solving" this issue
by trying harder, I would like to take the IETF to adopt the
following approach:

1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay
TCP connections

2. for hosts that are connected to IPv6-only networks but with needs
that can't be met by 1., obtain real IPv6 connectivity tunneled on-
demand over IPv6

The advantage of 1. is that proxies and applications that can use
proxies are already in wide use. The advantage of 2. is that it
provides real IPv4 connectivity without compromises. Different hosts
(even on the same subnet) can have different IPv4 connectivity (NAT/
no NAT, firewalled/unfirewalled) without having to provision the
complete path between the user and the edge of the network
specifically for that type of connectivity. And no lost addresses for
subnetting etc.