IETF Logo Mail Archive

Re: [BEHAVE] Why IETF should standardize IPv6 NAT

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 04 November 2008 21:06 UTC

Return-Path: <behave-bounces@ietf.org>
X-Original-To: behave-archive@optimus.ietf.org
Delivered-To: ietfarch-behave-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79FE23A6C8A; Tue, 4 Nov 2008 13:06:23 -0800 (PST)
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC9683A6C8A for <behave@core3.amsl.com>; Tue, 4 Nov 2008 13:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHXY89ziUHsl for <behave@core3.amsl.com>; Tue, 4 Nov 2008 13:06:21 -0800 (PST)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 25A913A635F for <behave@ietf.org>; Tue, 4 Nov 2008 13:06:21 -0800 (PST)
Received: by wf-out-1314.google.com with SMTP id 27so3692048wfd.31 for <behave@ietf.org>; Tue, 04 Nov 2008 13:05:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=74H9mFGMLsDkFWBhrtNRrdX4J5sqkNdMYzTj+SeYBbg=; b=rmFMdlVrL5Beo01lhd5PSoM4v5Qp09V7s1Qk/IIlxE8Xh7tJXwswd7bkguN3OWe6+A MV2UYcF7NxM/69rHOq8ZEmVxmIgofcTg/PVDVnuUoPOqybR5E7RdAgGxhcEa9hu3Em+I lDu4eNrFL5HXb1rWY87c1jZj0/ZgkqHMV3rQg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=u4DQt2Lfqf79ZQoQF54K8Mc6x6e8htVeYJWZ918U89sro2V0u/uh/BVx7oxXTKwq06 w7j3ZEuHdmESPuF82z1Ltrahyy8MDDzFxCAIghfRxLUd0nAC8sr5vZoojLN0jB4Vz4/X r9ErsfBgJRSh7i0zAlp3vMK3V2V0/zQ1wS7ZM=
Received: by 10.142.162.5 with SMTP id k5mr17702wfe.217.1225832736988; Tue, 04 Nov 2008 13:05:36 -0800 (PST)
Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 32sm19086036wfa.8.2008.11.04.13.05.35 (version=SSLv3 cipher=RC4-MD5); Tue, 04 Nov 2008 13:05:36 -0800 (PST)
Message-ID: <4910B91E.5000203@gmail.com>
Date: Wed, 05 Nov 2008 10:05:34 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Christian Vogt <christian.vogt@ericsson.com>
References: <E04D51FF-892B-42DB-A0AB-3BBA7A4F3B20@ericsson.com><75E82803-BFC F-4519-94B6-D77A1A28B68E@ericsson.com><FA41DDCA-0A25-4E1A-8662-0AC0FA36569 6 @lilacglade.org><42852CDA-0745-4E3E-89A2-5137FA4C89D3@ericsson.com><490DD FC 8.4090305@it.uc3m.es><CCDFEA3F-3309-4CCF-950F-5D3C9D267766@nokia.com><5A 64B0AE-FAAC-43B3-8B48-18E78B3DAAFE@ericsson.com> <3112211F-2821-4B62-92A8-E1ECD20C3EA2@cs.ucla.edu> <490F5D42.6090907@it.uc3m.es> <42ED4818-22D3-46E9-A6E5-E83A1847A683@CS.UCLA.EDU> <DF0BCE67-C6E5-4E73-905E-DE7B3F0797A4@ericsson.com>
In-Reply-To: <DF0BCE67-C6E5-4E73-905E-DE7B3F0797A4@ericsson.com>
Cc: Behave Mailing List <behave@ietf.org>, Lixia Zhang <lixia@CS.UCLA.EDU>
Subject: Re: [BEHAVE] Why IETF should standardize IPv6 NAT
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: behave-bounces@ietf.org
Errors-To: behave-bounces@ietf.org

On 2008-11-04 23:07, Christian Vogt wrote:
> Hi Lixia -
> 
>> I just wanted to point out that, if one has to make changes at both
>> ends, encapsulation seems an even better thing than 2-end NATing.
> 
> Why?
> 
> I agree with the advantages of translation that Iljitsch and Marcelo
> have pointed out.  And in addition, I don't see any disadvantage
> compared to tunneling.
> 
> Let me also forestall one common fallacy:  It may seem that, to
> re-establish an original packet, it is simpler to decapsulate than to
> reverse-translate because reverse translation requires a lookup in a
> mapping table.  However, a mapping table lookup also has a security
> function because it verifies the mapping between two addresses.  So a
> mapping table lookup, or an alternative security function, would also
> need to be provided by tunneling techniques.

You can argue that shim6 is an existence proof for such solutions -
it is in fact a two-ended NAT that verifies the address mapping.
But because it uses some in-band signalling, it also has a (minor)
MTU issue. A variant that avoids in-band signalling would avoid
that problem too. A proxy-shim6 solution is pretty much equal to
two-ended NAT.
http://tools.ietf.org/id/draft-bagnulo-pshim6-02.txt

    Brian
_______________________________________________
Behave mailing list
Behave@ietf.org
https://www.ietf.org/mailman/listinfo/behave

v2.23.0 | Report a Bug | By Email