[99592] in North American Network Operators' Group
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG
daemon@ATHENA.MIT.EDU (Alain Durand)
Fri Sep 28 17:33:35 2007
Date: Fri, 28 Sep 2007 16:57:18 -0400
From: Alain Durand <alain_durand@cable.comcast.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>,
Jari Arkko <jari.arkko@piuha.net>
CC: Randy Bush <randy@psg.com>, <nanog@nanog.org>
In-Reply-To: <05D53176-89DC-459C-8E2F-80CA508965D6@muada.com>
Errors-To: owner-nanog@merit.edu
> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--B_3273843438_827597
Content-type: text/plain;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
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:
>=20
>=20
> On 28-sep-2007, at 6:25, Jari Arkko wrote:
>=20
>>> >> And make it works both way, v4 to v6 and v6 to v4.
>>> >> And also don=B9t call it NAT-PT. That name is dead.
>=20
>> > 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.
>=20
> 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:
>=20
> 1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay
> TCP connections
>=20
> 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
>=20
> 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.
>=20
--B_3273843438_827597
Content-type: text/html;
charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
<HTML>
<HEAD>
<TITLE>Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action=
: Conclusion of IP Version 6 (ipv6)</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Iljit=
sch,<BR>
<BR>
<BR>
Tunneling is great, but it requires to allocate an IPv4 address... that I m=
ay not have in the first place.<BR>
<BR>
- Alain.<BR>
<BR>
<BR>
On 9/28/07 4:39 PM, "Iljitsch van Beijnum" <iljitsch@muada.com=
> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYL=
E=3D'font-size:12.0px'><BR>
<BR>
On 28-sep-2007, at 6:25, Jari Arkko wrote:<BR>
<BR>
>> And make it works both way, v4 to v6 and v6 to v4.<BR>
>> And also don’t call it NAT-PT. That name is dead.<BR>
<BR>
> For what it is worth, this is one of the things that I want<BR>
> to do. I don't want to give you an impression that NAT-PT++<BR>
> will solve all the IPv6 transition issues; I suspect dual stack<BR>
> is a better answer. But nevertheless, the IETF needs to<BR>
> produce a revised spec for the translation case. Fred and<BR>
> I are organizing an effort to do this.<BR>
<BR>
The problem with NAT-PT (translating between IPv6 and IPv4 similar to <BR>
IPv4 NAT) was that it basically introduces all the NAT ugliness that <BR>
we know in IPv4 into the IPv6 world. Rather than "solving" this i=
ssue <BR>
by trying harder, I would like to take the IETF to adopt the <BR>
following approach:<BR>
<BR>
1. for IPv6-only hosts with modest needs: use an HTTPS proxy to relay <BR>
TCP connections<BR>
<BR>
2. for hosts that are connected to IPv6-only networks but with needs <BR>
that can't be met by 1., obtain real IPv6 connectivity tunneled on-<BR>
demand over IPv6<BR>
<BR>
The advantage of 1. is that proxies and applications that can use <BR>
proxies are already in wide use. The advantage of 2. is that it <BR>
provides real IPv4 connectivity without compromises. Different hosts <BR>
(even on the same subnet) can have different IPv4 connectivity (NAT/<BR>
no NAT, firewalled/unfirewalled) without having to provision the <BR>
complete path between the user and the edge of the network <BR>
specifically for that type of connectivity. And no lost addresses for <BR>
subnetting etc.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STY=
LE=3D'font-size:12.0px'><BR>
</SPAN></FONT>
</BODY>
</HTML>
--B_3273843438_827597--
