Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching?

Iljitsch van Beijnum <iljitsch@muada.com> Mon, 02 May 2011 12:26 UTC

Return-Path: <iljitsch@muada.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7EE0819 for <behave@ietfa.amsl.com>; Mon, 2 May 2011 05:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.374
X-Spam-Level:
X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVHYHTj57g9q for <behave@ietfa.amsl.com>; Mon, 2 May 2011 05:26:26 -0700 (PDT)
Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) by ietfa.amsl.com (Postfix) with ESMTP id 65BE5E0812 for <behave@ietf.org>; Mon, 2 May 2011 05:26:26 -0700 (PDT)
Received: from [IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2] ([IPv6:2001:470:1f0b:1289:223:12ff:fe56:36b2]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id p42CRb96079195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 May 2011 14:27:38 +0200 (CEST) (envelope-from iljitsch@muada.com)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="utf-8"
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <4DB95962.5090407@gmail.com>
Date: Mon, 02 May 2011 14:26:18 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA2B6487-5506-4FC0-9124-61CF6AD86F82@muada.com>
References: <4DB95962.5090407@gmail.com>
To: buptnoc <buptnoc@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: behave@ietf.org
Subject: Re: [BEHAVE] ***SPAM*** 5.548 (5) Is nat46 worth researching?
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2011 12:26:27 -0000

On 28 apr 2011, at 14:11, buptnoc wrote:

>     As described in draft-ietf-behave-v6v4-framework-10#section-2.4 , we need nat46 translator. 
>     But, do we really need this scenario?Is it worth to deploy this scenario?

>     In fact, this scenario appears when we have v4-only client and v6-only servers

My opinion is: no, this is not worth the trouble. We know that NAT46 is a hard problem, and it's unlikely a solution would be very robust. Because of lack of IPv4 addresses, a relatively small pool of v4 addresses would have to map to all possible v6 addresses, which means that the mappings have to be highly dynamic. But addresses are cached in many places, including often for a long time in applications. Having different applications react differently to NAT46 would be a big deployment problem.

I would recommend (apart from upgrading to IPv6) deploying HTTP and HTTPS proxies, as those will allow HTTP and HTTPS from IPv4-only clients to IPv6-only servers (or the other way around!) and in principle, it's possible to modify any TCP-based application to work through an HTTPS proxy, as those are basically TCP relays.

It should be possible to make an automatic proxy configuration so that a browser only uses the proxy to reach IPv6 destinations and connects to IPv4 destinations directly. However, I haven't tried this myself yet.