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

Rémi Després <> Fri, 03 February 2012 10:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EB4921F85D4 for <>; Fri, 3 Feb 2012 02:15:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TVMRH9dMqBXO for <>; Fri, 3 Feb 2012 02:15:48 -0800 (PST)
Received: from ( [IPv6:2a01:e0c:1:1599::10]) by (Postfix) with ESMTP id EA48E21F85D1 for <>; Fri, 3 Feb 2012 02:15:44 -0800 (PST)
Received: from [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb] (unknown [IPv6:2a01:e35:8a6d:d900:129a:ddff:fe6b:c6fb]) by (Postfix) with ESMTP id A7E649401B8; Fri, 3 Feb 2012 11:15:37 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-105--82898252
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <>
In-Reply-To: <>
Date: Fri, 3 Feb 2012 11:15:36 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Maoke <>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <>
Subject: Re: [Softwires] No change to RFC6145 needed for 4rd-U
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Feb 2012 10:15:49 -0000

Le 2012-02-02 à 11:59, Maoke a écrit :

> dear Remi,
> sorry but your change of the title of this thread is misleading. i mean: no change to RFC6145 needed for practice of operation. my observation on the ICMP transparency of RFC6145 in double translation is relatively independent, without much relationship to 4rd-U.

> well, the only connection is: 4rd-U REQUIRES IPv6 carrying ICMPv4 messages without translation. 

4rd-U is indeed proposed with all IPv4 payloads transparently transmitted, including ICMPv4.
This could be changed if ICMPv4 if there would be a convincing need.
Honestly, what you have provided so far hasn't been convincing. 

> 2012/2/2 Rémi Després <>
> 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.
> i (and others) have tested the single/double-compatibility in practice and confirmed it is useful at least for some users.

I don't deny. I just believe that, to have a chance to be convinced, I need a description of at least a use case where it is useful (with applicable mapping rules and indication of whether there is a DNS64).

> another mail thread might fall into pure philosophical debate, which is not preferred,

Whatever the thread, I look for a technical discussion, not a philosophical one.


> - maoke 
> RD