IETF Logo Mail Archive

Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation

Rémi Després <despres.remi@laposte.net> Mon, 10 October 2011 07:23 UTC

Return-Path: <despres.remi@laposte.net>
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 2A75F21F8AF7 for <softwires@ietfa.amsl.com>; Mon, 10 Oct 2011 00:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 IYaAGML5VXYH for <softwires@ietfa.amsl.com>; Mon, 10 Oct 2011 00:23:16 -0700 (PDT)
Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 75BF421F8A6F for <softwires@ietf.org>; Mon, 10 Oct 2011 00:23:15 -0700 (PDT)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id ivPD1h00337Y3f403vPD6l; Mon, 10 Oct 2011 09:23:13 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <CAM+vMEQipeJ2qnnVw9JcQ2U9OUxV5FYu=PDKn413B9cFXU290w@mail.gmail.com>
Date: Mon, 10 Oct 2011 09:23:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B9108A8B-5FEE-491B-83DE-B2A5397872A5@laposte.net>
References: <F259BF79-B3C9-4434-AAC4-9F84B8D9A0FA@laposte.net> <CAM+vMER2CBTpYOhcu63th7AJejCJ4sv0_GqeiZmwHVHEEeW1WA@mail.gmail.com> <0C2B5428-98D4-4F67-B18D-9ACA946A68E7@laposte.net> <CAM+vMEQ4=xxgBgoqDAcd=t_Yx=j+wJm-rP-haJwdSxRSOv5sVQ@mail.gmail.com> <02D4DC4B-EB93-42C6-AE9F-135B0C598F8E@laposte.net> <CAM+vMEQipeJ2qnnVw9JcQ2U9OUxV5FYu=PDKn413B9cFXU290w@mail.gmail.com>
To: GangChen <phdgang@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] Proposed Unified Address Mapping for encapsulation and double-translation
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: Mon, 10 Oct 2011 07:23:17 -0000

Le 8 oct. 2011 à 05:26, GangChen a écrit :

> Hello Remi,
> 
> 2011/10/6, Rémi Després <despres.remi@laposte.net>:
>> 
>> Le 6 oct. 2011 à 06:01, GangChen a écrit :
>> 
>>> 
>>> I understand such encoded information helps deriving a shared IPv4
>>> address. However, I guess it's not necessary to dig up such
>>> information if we only take traffic contronl on IPv6 data plane (as I
>>> said below)
>> 
>> I agree that it is "not necessary" to exploit this field to filter IPv4
>> traffic.
>> 
>> Yet it MAY be used to facilitate configuration of traffic control parameters
>> (IPv4 addresses are expressed in clear form instead of having to be derived
>> with the help of mapping rules).
> 
> May I clarify whether such traffic control parameters are for IPv4 or
> IPv6 data plane?

As I understand it, the objective is to use existing traffic-control tools of IPv6 for both IPv6 AND IPv4.
This seems to me a valuable feature. 

Regards,
RD

 
> 
> Many thanks
> 
> Gang
>

v2.23.0 | Report a Bug | By Email