Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00

Rémi Després <remi.despres@free.fr> Thu, 26 June 2008 09:23 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 EB6DE3A6913; Thu, 26 Jun 2008 02:23:26 -0700 (PDT)
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 8360C3A6913 for <behave@core3.amsl.com>; Thu, 26 Jun 2008 02:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.056
X-Spam-Level:
X-Spam-Status: No, score=0.056 tagged_above=-999 required=5 tests=[AWL=2.005, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 HmUrNSSUxxGP for <behave@core3.amsl.com>; Thu, 26 Jun 2008 02:23:21 -0700 (PDT)
Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by core3.amsl.com (Postfix) with ESMTP id 8D5A53A68ED for <behave@ietf.org>; Thu, 26 Jun 2008 02:23:21 -0700 (PDT)
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id AEAFF3EA0CB; Thu, 26 Jun 2008 11:23:23 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp4-g19.free.fr (Postfix) with ESMTP id 317F83EA0C4; Thu, 26 Jun 2008 11:23:20 +0200 (CEST)
Message-ID: <48636006.6030202@free.fr>
Date: Thu, 26 Jun 2008 11:23:18 +0200
From: Rémi Després <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Iljitsch van Beijnum <iljitsch@muada.com>
References: <484E982E.6010603@it.uc3m.es> <200806251507.16762.remi.denis-courmont@nokia.com> <8326F300-4B35-40E1-8B7C-BE9D4F59F122@muada.com> <200806260944.21236.remi.denis-courmont@nokia.com> <D73206A8-A565-4BE7-B2C7-1F677099AB8D@muada.com>
In-Reply-To: <D73206A8-A565-4BE7-B2C7-1F677099AB8D@muada.com>
Cc: behave@ietf.org
Subject: Re: [BEHAVE] comments on draft-bagnulo-behave-nat64-00
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: behave-bounces@ietf.org
Errors-To: behave-bounces@ietf.org

Hi Iljitsch,

   Thanks for pointing to the Internet-waist-hourglass draft, IMO a 
great one.

   I don't know whether the point I make here will be considered timely,
but it insistently comes to my mind, and may interest some paricipants
in this discussion.

   All problems of checksum adjustments in NATs can disappear with the
DSTM-APBP approach:
   With it, the client host borrows a public-address+port couple for
each of its transport connections, and then exchanges packets E2E using
this couple.
   Where needed the E2E packets are appropriately encapsulated (ref
draft-despres-v6ops-apbp-00.txt).

   APBP servers lend the public-address+port couples.
   They have for this to manage mappings like the NATS have to.
   But they have besides that NO TRANSLATION to perform, only some sort
of encapsulation-decapsulation of E2E packets.

   Many variations of the detailed protocol can be imagined.
   However, a buildup of enough interest in the subject would be
approriate before the burden of a complete design can be borne.

   APBP can be seen as a compatible extension of NAT devices, with the
following payoff:
   - *Transport protocol independence*, in particular SCTP 
compatibility, for upgraded dual stack hosts that communicate via APBP 
supporting ISPs.
   - In ISP infrastructures, improved scalability of APBP servers
compared to that of NATs.

Rémi

Iljitsch van Beijnum  - Le 6/26/08 9:32 AM :
> On 26 jun 2008, at 8:44, Rémi Denis-Courmont wrote:

>> Oh well, I guess I should push a strawman I-D rather than long 
>> emails.
> 
> You're a bit late:
draft-rosenberg-internet-waist-hourglass-00.txt

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