Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
alain_durand at cable.comcast.com
Fri Sep 28 20:57:18 UTC 2007
Tunneling is great, but it requires to allocate an IPv4 address... that I
may not have in the first place.
On 9/28/07 4:39 PM, "Iljitsch van Beijnum" <iljitsch at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NANOG