[Softwires] No change to RFC6145 needed for 4rd-U

Rémi Després <despres.remi@laposte.net> Thu, 02 February 2012 09:30 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9903221F8A58 for <softwires@ietfa.amsl.com>; Thu, 2 Feb 2012 01:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QWXBOSr5ArBc for <softwires@ietfa.amsl.com>; Thu, 2 Feb 2012 01:30:58 -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 C880D21F8A27 for <softwires@ietf.org>; Thu, 2 Feb 2012 01:30:55 -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 F192F940204; Thu, 2 Feb 2012 10:30:48 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-97--171986897
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <CAFUBMqX83kPN7VeE4=iu30ne2p7zuBuKk6Aq2SHkkEqz3Tye5Q@mail.gmail.com>
Date: Thu, 2 Feb 2012 10:30:47 +0100
Message-Id: <23CE9B9D-5469-4537-B4D8-607834D13EBF@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: [Softwires] No change to RFC6145 needed for 4rd-U
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: Thu, 02 Feb 2012 09:30:58 -0000

Le 2012-02-01 à 03:04, Maoke a écrit :
> ...
> 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,

Introducing ICMPv4 messages in IPv6 packets "instead of" ICMPv6 messages in RFC6145 would be an incompatible change. 
I don't think anyone proposed that.
What might be envisaged without the same backward incompatibility, is that IPv6-only hosts would accept in IPv6 packets BOTH IPv6 ICMP messages and ICMPv4 messages.

Yet, it remains to be analyzed whether it would be useful in real world.

This depends on a detailed use case being identified, where double RFC6145 translation would have a substantial advantage over the header-mapping variant of 4rd-U-03 (4rd-H). (This advantage would have to compensate for the loss of IPv4 transparency as good as that of 4rd-E, and for the loss of the tunnel-specific traffic class which can be used in 4rd-E.) 

This use case, key for this discussion, is subject of another e-mail thread.