IETF Logo Mail Archive

Re: Tunnel-to-NAT scenario

Rémi Després <remi.despres@free.fr> Tue, 17 June 2008 12:38 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87163A67D7 for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 05:38:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.183
X-Spam-Level:
X-Spam-Status: No, score=-0.183 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
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 RHvP7XBR9zej for <ietfarch-v6ops-archive@core3.amsl.com>; Tue, 17 Jun 2008 05:38:05 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D45C73A6AE7 for <v6ops-archive@lists.ietf.org>; Tue, 17 Jun 2008 05:38:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1K8aPZ-000LGn-6B for v6ops-data@psg.com; Tue, 17 Jun 2008 12:35:45 +0000
Received: from [212.27.42.30] (helo=smtp4-g19.free.fr) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <remi.despres@free.fr>) id 1K8aPQ-000LG1-G8 for v6ops@ops.ietf.org; Tue, 17 Jun 2008 12:35:38 +0000
Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id CA9753EA125; Tue, 17 Jun 2008 14:35:35 +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 757023EA0E3; Tue, 17 Jun 2008 14:35:35 +0200 (CEST)
Message-ID: <4857AF96.6080806@free.fr>
Date: Tue, 17 Jun 2008 14:35:34 +0200
From: Rémi Després <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421)
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
CC: IPv6 Operations <v6ops@ops.ietf.org>
Subject: Re: Tunnel-to-NAT scenario
References: <C47CE31D.12701%alain_durand@cable.comcast.com> <4857793F.6020808@free.fr> <485782C3.8090309@piuha.net> <038FB0D9-E5F8-42F1-8F55-16EB3962EB72@muada.com> <4857A458.6070104@piuha.net>
In-Reply-To: <4857A458.6070104@piuha.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Jari Arkko  - Le 6/17/08 1:47 PM :
> ... tunneling ensures that your IPv4 traffic is as intact as 
> possible.

In this respect, The APBP-E2E scenario of draft-despres-v6ops-apbp-00
sec. 5.2 goes *one step further* than Tunnel-to-NAT.

When a (modified) dual stack client connects to a v4-only server:
- v4 packets are unchanged E2E.
- The (dual stack) client application sees its public v4 address, so 
that no NAT is needed.

It then seems that, if and when time comes to discuss the APBP protocol, 
after the problem statement, Softwires would be the right place.


Regards.

Rémi

v2.23.0 | Report a Bug | By Email