Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant

Maoke <fibrib@gmail.com> Wed, 01 February 2012 02:04 UTC

Return-Path: <fibrib@gmail.com>
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 DE3DA11E808E for <softwires@ietfa.amsl.com>; Tue, 31 Jan 2012 18:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 2TkgaeiQXRtE for <softwires@ietfa.amsl.com>; Tue, 31 Jan 2012 18:04:04 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CAEDF21F848F for <softwires@ietf.org>; Tue, 31 Jan 2012 18:04:03 -0800 (PST)
Received: by qcsg13 with SMTP id g13so449320qcs.31 for <softwires@ietf.org>; Tue, 31 Jan 2012 18:04:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u59e+yUlGs9L7HahF7yUmNFeOpws026gBg5nwOjYB/U=; b=viA5ejaSMqYMqFMEz7xe8CLETMmxBjJHTReWmvUwpKGaHGqQFHjzzUt9+cLmEcjwLx mky3GKeKMY1cXn7Y2Kt4j9LnDc6dwyWILQYAO3q1Jj9q7XX86gkQfX00scvUUc/QKsd+ GhCaodZSz5G5/jbdLY9HXlrCdC36Bj/dLpjk0=
MIME-Version: 1.0
Received: by 10.224.202.65 with SMTP id fd1mr30677241qab.12.1328061843215; Tue, 31 Jan 2012 18:04:03 -0800 (PST)
Received: by 10.229.211.72 with HTTP; Tue, 31 Jan 2012 18:04:03 -0800 (PST)
In-Reply-To: <3069401B-458B-41E2-B6B3-B9FA8811CC30@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>
Date: Wed, 1 Feb 2012 11:04:03 +0900
Message-ID: <CAFUBMqX83kPN7VeE4=iu30ne2p7zuBuKk6Aq2SHkkEqz3Tye5Q@mail.gmail.com>
From: Maoke <fibrib@gmail.com>
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= <despres.remi@laposte.net>
Content-Type: multipart/alternative; boundary=20cf30050eea6795e704b7dd7e68
Cc: Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] New version of 4rd-U - with plain Encapsulation as a variant
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 02:04:05 -0000

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

i think this is a clear-enough use-case but if i still make any confusion,
i may draw some pictures for you offline.

i have investigated, technically, what if we had updated RFC6145 with
carrying ICMPv4 messages in IPv6 directly instead of translating to ICMPv6,
specially for double translation, but i found 1) the necessity is weak,
according to the transparency check for RFC6145 end-to-end behavior in
double-translation; 2) it is impossible to make decision among alternatives
due to lack of knowledge about the remote stack (i.e. cannot distinguish
single or double translation with no state nor complicated dynamic
configuration); and 3) it is harmful to have ICMPv4 in IPv6 payload (as i
mentioned previously). my conclusion is: for RFC6145, it is a wise choice
to keep using a unified translation algorithm no matter the case is single
or double.

- M.


> RD
>