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

Maoke <> Thu, 02 February 2012 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 396A121F8A9A for <>; Thu, 2 Feb 2012 03:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4X6Xa6eE1mpx for <>; Thu, 2 Feb 2012 03:00:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 05C0821F8A96 for <>; Thu, 2 Feb 2012 02:59:59 -0800 (PST)
Received: by qcsg13 with SMTP id g13so1510635qcs.31 for <>; Thu, 02 Feb 2012 02:59:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G/KVxLxSuvOYLL7+pqBLW+IrDCNsJbXwMtbeZhlgLlo=; b=qEFusqPqmkicCwaHR42HvYq11yWY7naz7+INoqB0SEant0sgClwNOt1iN86lZpJLWq z8kksZHaZS+XhSIgtyVn74cuKmKJp/mC0t5/nwiypC6Hy6LzKvzea+grk9Rzf+p75DAD RhmeE7tNWR6ZYK4RlQS3hC5RliFCFEYOaE+ko=
MIME-Version: 1.0
Received: by with SMTP id y9mr730048qcj.123.1328180399485; Thu, 02 Feb 2012 02:59:59 -0800 (PST)
Received: by with HTTP; Thu, 2 Feb 2012 02:59:59 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 2 Feb 2012 19:59:59 +0900
Message-ID: <>
From: Maoke <>
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= <>
Content-Type: multipart/alternative; boundary=00235429d794e8b56104b7f9180e
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: Thu, 02 Feb 2012 11:00:07 -0000

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.

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. another mail thread might
fall into pure philosophical debate, which is not preferred, especially
considering that carrying ICMPv4 in IPv6 is not secure. in other words,
even if the philosopher had thought the compatibility with single
translation was useless, he'd better not to deploy the IPv6 network
carrying ICMPv4 payload without IPv4 header encapsulated.

- maoke

> RD