Re: [v4v6interim] You have been dugg!

Rémi Després <remi.despres@free.fr> Fri, 10 October 2008 12:41 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B970228C156; Fri, 10 Oct 2008 05:41:04 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A733A69C3 for <v4v6interim@core3.amsl.com>; Fri, 10 Oct 2008 05:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.708
X-Spam-Level:
X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.241, 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 vtwPoyGeUNpx for <v4v6interim@core3.amsl.com>; Fri, 10 Oct 2008 05:40:59 -0700 (PDT)
Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by core3.amsl.com (Postfix) with ESMTP id 7CD823A6947 for <v4v6interim@ietf.org>; Fri, 10 Oct 2008 05:40:59 -0700 (PDT)
Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 941D932A7E4; Fri, 10 Oct 2008 14:40:51 +0200 (CEST)
Received: from ordinateur-de-remi-despres.local (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by smtp8-g19.free.fr (Postfix) with ESMTP id 18A3C32A7CA; Fri, 10 Oct 2008 14:40:51 +0200 (CEST)
Message-ID: <48EF4D03.6080505@free.fr>
Date: Fri, 10 Oct 2008 14:39:31 +0200
From: Rémi Després <remi.despres@free.fr>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Turchanyi Geza <turchanyi.geza@gmail.com>, v4v6interim@ietf.org
References: <732E532B-97C7-465C-BBE0-FD1B442DB21E@muada.com> <48EC5D76.5080109@free.fr> <f1110c510810100009r51bf3553n999ef0489f4dff03@mail.gmail.com>
In-Reply-To: <f1110c510810100009r51bf3553n999ef0489f4dff03@mail.gmail.com>
Subject: Re: [v4v6interim] You have been dugg!
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

Turchanyi Geza   (m/j/a) 10/10/08 9:09 AM:
> Hello,
> 
> Well, SAM is an interesting idea.
> 
> HOWEVER: if we can implement new software (almost)everywhere, than why
> not to use IPv6 everywhere?

Two points.
- For SAM to be useful, it doesn't need at all to be available 
everywhere, or even "almost" everywhere: if an ISP has it, its clients 
that also have it can take advantage of its properties (deployment is 
incremental).
- In scenario C, although the customer site has no global IPv4 address 
reserved for it, its SAM hosts are reachable, without NAT traversal, by 
IPv4-only remote clients.

> I missed the point: what can be kept unchanged in the SAM scenario?
In scenario C below, an IPv4 datagram exchanged between the SAM host and 
any remote host that requires the connection to be IPv4 is unchanged 
end-to end. Both source and destination addresses and ports of the 
datagram, and its protocol, are received as sent (5-tuple preservation). 
The IPv4 only host ignores that encapsulation in IPv6 has taken place 
somewhere.

5-tuples being neither restricted nor modified E2E, the solution is more 
general than those that impose NAT traversal. In particular, it ensures 
compatibility with SCTP and with any other transport protocol that may 
be useful in the future.

Regards,

RD

>> Worth being remembered: SAM has more potential than other solutions for
>> IPv4-only clients to reach an IPv6 capable server that only has a shared
>> IPv4 address (with a restricted port range, accessible via tunnels).
>>
>> In particular, in draft-despres-SAM-v4v6coexistenceScenarios-00,
>> scenario C is as follows (simplified to have encapsulation in IPv6 only,
>> and complemented to show on it supports connections both ways).
>>
>>
>>
>> +------+                                    +--------+   Global
>> | SAM  |           +---------+              |  SAM   |  Internet
>> | host |--site v6--| SAM CPE |-- ISP v6 ----| ISP GW |<--- v4 -->
>> +------+           +---------+              +--------+
>>
>>  SAM <--- v4/v6 -->SAM1 SAM2<---- v4/v6 ---> SAM <----- v4 ---->
>>    :                    :                      :
>>    '- Port restricted   '- Stateless CPE       '--- Stateless GW
>>          socket interface
>>
>>
>>        <---- transparency to global v4 packets ----->
>>             (outgoing AND incoming connections)
>>
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim