Re: [Softwires] New version of 4rd-U - Header mapping (4rd-H vs 4rd-T)

Rémi Després <despres.remi@laposte.net> Wed, 01 February 2012 17:33 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EA211E8149 for <softwires@ietfa.amsl.com>; Wed, 1 Feb 2012 09:33:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rgE4jjDdEIf for <softwires@ietfa.amsl.com>; Wed, 1 Feb 2012 09:33:28 -0800 (PST)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B65E11E814C for <softwires@ietf.org>; Wed, 1 Feb 2012 09:33:26 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by smtp1-g21.free.fr (Postfix) with ESMTP id 495D69402B2; Wed, 1 Feb 2012 18:33:18 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-95--229437050
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqX83kPN7VeE4=iu30ne2p7zuBuKk6Aq2SHkkEqz3Tye5Q@mail.gmail.com>
Date: Wed, 1 Feb 2012 18:33:17 +0100
Message-Id: <DABF6A8B-FCC4-4897-B5A1-A35DD4F1C208@laposte.net>
References: <C992D2F8-5E8C-4601-B07D-37AB2B7E72D3@laposte.net> <CAFUBMqXm3BiK5Cq8nmy97Nr6eVYZgooc38Rv3PB6nOWAzmMbUg@mail.gmail.com> <52DBFDA9-1BBB-47DD-9165-F9C0341A669C@laposte.net> <CAFUBMqXVx9F5V+_5RcLdr8V5dn9Hxixm+19hXX10Zh-86t-W4w@mail.gmail.com> <3069401B-458B-41E2-B6B3-B9FA8811CC30@laposte.net> <CAFUBMqX83kPN7VeE4=iu30ne2p7zuBuKk6Aq2SHkkEqz3Tye5Q@mail.gmail.com>
To: Maoke <fibrib@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] New version of 4rd-U - Header mapping (4rd-H vs 4rd-T)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2012 17:33:29 -0000

Le 2012-02-01 à 03:04, Maoke a écrit :

> 
> 
> 2012/1/30 Rémi Després <despres.remi@laposte.net>
> 
>> and definitely there is no compatibility to single translation in RFC6145 at all. as the result, RFC6145 provides a unified solution, while 4rd-U requires ISP (who prefer to use translation) disjointly deploy their networks for single and double translations.
>>  
>>  
>> 
>> If you have a specific configuration that illustrates your concern, it could be discussed with more details.
> 
> Could you, for the sake of a less abstract discussion, describe at least one configuration you have in mind, in which some IPv4 addresses are statelessly shared, and in which there is the RFC6145 compatibility you are talking about.
> Without that, I can't figure out what you mean. 
> (The goal remains customer service, without harm if this happens to be possible without full support of RFC4125, right?)
> 
> to my best understanding, one of the merits of the translation approach is: when an end system changes its stack from ipv4 to ipv6,

If it is on a V6-only network, isn't the end system already dual stack?
Then, if it needs to be reachable in IPv4, why would it change IPv6-only while the 4rd service remains available?

RD

> as long as the ipv4-translatable ipv6 address is applied, its peers in the past can keep using the same ipv4 address (as the temporal-unique identifier) to have access to it. in other words, the stack-changing doesn't impact already-existing peers, but enlarges the opportunity for the new connections from native ipv6 peers. separating single translation and double translation with deploying disjoint ipv4 (as well as corresponding ipv6) spaces is meaningless in this term.

...