Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt

Tomas Podermanski <tpoder@cis.vutbr.cz> Fri, 04 March 2011 07:09 UTC

Return-Path: <tpoder@cis.vutbr.cz>
X-Original-To: nat66@core3.amsl.com
Delivered-To: nat66@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 537483A6965 for <nat66@core3.amsl.com>; Thu, 3 Mar 2011 23:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level:
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
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 t8Mvmnn11sVy for <nat66@core3.amsl.com>; Thu, 3 Mar 2011 23:09:25 -0800 (PST)
Received: from ferret.cis.vutbr.cz (ferret6.cis.vutbr.cz [IPv6:2001:67c:1220:4::93e5:391]) by core3.amsl.com (Postfix) with ESMTP id 669A13A696D for <nat66@ietf.org>; Thu, 3 Mar 2011 23:09:25 -0800 (PST)
Received: from flamingo.cis.vutbr.cz (flamingo.cis.vutbr.cz [147.229.3.147]) by ferret.cis.vutbr.cz (8.14.4/8.14.4/VUT Brno) with ESMTP id p247ASkw005639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <nat66@ietf.org>; Fri, 4 Mar 2011 08:10:32 +0100 (CET) (envelope-from tpoder@cis.vutbr.cz)
Received: from dhcp05.cis.vutbr.cz (dhcp05.cis.vutbr.cz [147.229.3.105]) (authenticated bits=0) by flamingo.cis.vutbr.cz (8.13.8/8.14.3/VUT v Brne) with ESMTP id p247AQHP008167 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <nat66@ietf.org>; Fri, 4 Mar 2011 08:10:27 +0100 (CET) (envelope-from tpoder@cis.vutbr.cz)
Message-ID: <4D709062.8080504@cis.vutbr.cz>
Date: Fri, 04 Mar 2011 08:10:26 +0100
From: Tomas Podermanski <tpoder@cis.vutbr.cz>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: nat66@ietf.org
References: <20110228223003.13022.10464.idtracker@localhost> <845A4F08-46E7-48EE-B294-0C8368BAD1CB@cisco.com> <20110302072822.GA20321@serpens.de> <5AC61190-49B0-49B5-ACB1-1FA5082C0380@cisco.com> <20110302203006.GI23030@serpens.de> <4D6EB08E.9000109@gmail.com> <20110302214913.GG20321@serpens.de> <4D6EC293.90608@gmail.com> <20110303065132.GH20321@serpens.de> <4D6FF098.6010600@gmail.com>
In-Reply-To: <4D6FF098.6010600@gmail.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 147.229.3.145
Subject: Re: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
X-BeenThere: nat66@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "List for discussion of IPv6-to-IPv6 NAT." <nat66.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nat66>
List-Post: <mailto:nat66@ietf.org>
List-Help: <mailto:nat66-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nat66>, <mailto:nat66-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2011 07:09:29 -0000

On 3/3/11 8:48 PM, Brian E Carpenter wrote:
> On 2011-03-03 19:51, S.P.Zeidler wrote:
>> Thus wrote Brian E Carpenter (brian.e.carpenter@gmail.com):
>>
>>> On 2011-03-03 10:49, S.P.Zeidler wrote:
>>>> Thus wrote Brian E Carpenter (brian.e.carpenter@gmail.com):
>>>>
>>>>> On 2011-03-03 09:30, S.P.Zeidler wrote:
>>>>> ...
>>>>>> Which applications will have trouble with address stability and
>>>>>> provider independence, thus requiring you to make the benefits of NPTv6
>>>>>> line up with the applications you want to use??
>>>>> The usual ones - those that for whatever reason have explicit
>>>>> dependency on the IP address of the peer.
>>>> i.e. they will have trouble with PI addresses also?
>>> No, why?
>> I am trying to point out that you (and the draft) are claiming that.
>>
>> The benefit of NPTv6 is address stability and provider independence.
>> The benefit of PI is address stability and provider independence.
>>
>> The cost of the method NPTv6 applies to get that benefit is that the
>> addresses change in flight. -This- is the issue.
>>
>> The benefit does not cause any trouble.
>> The means by which you reach this benefit may.
>>
>> You see the distinction?
> Of course. PI has the cost of exploding the BGP4 table.
> NPTv6 has the cost of destroying address transparency.
>
> Since SHIM6 has neither of these costs, are you surprised
> that I prefer it?
>
I completely agree with you. SHIM6 is definitely better solution than
MAP66. But the problem is that SHIM66 requires support for both server
and client side. Living in the real world we can not expect that SHIM66
will be widely supported in less than 5 or 10 years. SHIM66 is nice and
great solution but not for today.

MAP66 is a pragmatic solution that can work today (working
implementation of map66 exists - http://map66.sourceforge.net/). Beleive
me, there is really huge demand from enterprise to have solution like
MAP66. MAP66 is easy to understand, easy to implement, follows habits
that people are used to using in IPv4 world and can work immediately.

>From application perspective, address rewriting used by MAP66 is not a
new issue. The technique is used by enterprise to mapping public
addresses to DMZ for many ears. Almost all application had to deal with
it somehow.

Tomas