IETF Logo Mail Archive

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

Christian Huitema <huitema@microsoft.com> Thu, 03 March 2011 17:23 UTC

Return-Path: <huitema@microsoft.com>
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 CD4173A67F1 for <nat66@core3.amsl.com>; Thu, 3 Mar 2011 09:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 3XVVXjooZX7e for <nat66@core3.amsl.com>; Thu, 3 Mar 2011 09:23:12 -0800 (PST)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 69F873A69FF for <nat66@ietf.org>; Thu, 3 Mar 2011 09:23:12 -0800 (PST)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 3 Mar 2011 09:24:19 -0800
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.270.2; Thu, 3 Mar 2011 09:24:20 -0800
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.56]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0270.002; Thu, 3 Mar 2011 09:24:19 -0800
From: Christian Huitema <huitema@microsoft.com>
To: S.P.Zeidler <spz@serpens.de>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [nat66] Fwd: New Version Notification - draft-mrw-nat66-08.txt
Thread-Index: AQHL15hhByvNBxX8/UmIIeWNFFpdMJQaLb6AgACVmACAAETRAIAACT0AgAAM3YCAAAiegIAAjumAgAApMBA=
Date: Thu, 3 Mar 2011 17:24:17 +0000
Message-ID: <22F6318E46E26B498ABC828879B08D4F0BCB92@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
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>
In-Reply-To: <20110303065132.GH20321@serpens.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "nat66@ietf.org" <nat66@ietf.org>
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: Thu, 03 Mar 2011 17:23:13 -0000

> 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.

But PI has its own set of costs. There is the impact on the global routing tables, which means PI can only be a solution for a relatively small fraction of the users. And there is the administrative cost of getting a PI address allocated, and then convincing the network providers to advertise it.

You could just as well mention the advantage of provider based addresses -- no address stability, no provider independence, but very low administrative cost, no impact on global routing, and transparency to applications.

I suppose we could summarize all that in a neat table.

-- Christian Huitema

v2.8.7 | Report a Bug | By Email