Re: [Softwires] MAP documents - next steps

Rémi Després <> Thu, 02 February 2012 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83B3721F8AAD for <>; Thu, 2 Feb 2012 00:06:21 -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 ge1hyOtduzVR for <>; Thu, 2 Feb 2012 00:06:21 -0800 (PST)
Received: from ( [IPv6:2a01:e0c:1:1599::10]) by (Postfix) with ESMTP id AE84221F8ACB for <>; Thu, 2 Feb 2012 00:06:18 -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 2BED29401D7; Thu, 2 Feb 2012 09:06:08 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-96--177066607"
From: Rémi Després <>
In-Reply-To: <>
Date: Thu, 02 Feb 2012 09:06:07 +0100
Message-Id: <>
References: <> <> <> <>
To: Maoke <>
X-Mailer: Apple Mail (2.1084)
Cc: softwires WG <>
Subject: Re: [Softwires] MAP documents - next steps
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 08:06:21 -0000

Le 2012-02-02 à 05:20, Maoke a écrit :

> 2012/2/2 Rémi Després <>
> Except for the fact that double RF46145 is replaced by the self-contained Header mapping variant, more transparent, but about which there is an ongoing discussion with Maoke, the last 4rd-U draft is, in my understanding, largely what you are looking for.
> briefly summary my action and understanding in order to avoid confusion.

> 1. my detailed re-study on RFC6145 behavior in double translation has been finished and i have NO new protocol or algorithm proposal which is worthy sharing to the community;

No misunderstanding on this.

> 2. (because) RFC6145 has provided (not thorough but) good enough transparency when used in double translation, and accordingly it is NOT needed to be updated;

Full transparency, based on clear theory, remains AFAIK better than "good enough" based on some collected statistic at a given time.

> 3. carrying ICMPv4 directly in IPv6 payload will be a harmful idea and less feasible.

I don't see where you see that ICMPv4 payload tunneled in a mapped header isn't easily feasible.

Stating it is harmful is of course not a proof.
Discussion on this point can continue with more details in other e-amils based on configurations you have in mind.  


> basically i doubt it is significant enough to make a document explaining the RFC6145 behavior in double-translation, as well as the corresponding concerns. however, if some people would like to have such an informational document, i'd love to elaborate. 
> - maoke