Re: [v6ops] new draft: draft-ietf-v6ops-464xlat

Rémi Després <despres.remi@laposte.net> Tue, 21 February 2012 16:06 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA38121F87FF for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 08:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.288, 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 axNSMsQzNilf for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 08:06:27 -0800 (PST)
Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AB21F8834 for <v6ops@ietf.org>; Tue, 21 Feb 2012 08:06:26 -0800 (PST)
Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8507-out with ME id cg6N1i00N37Y3f403g6P3n; Tue, 21 Feb 2012 17:06:25 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <despres.remi@laposte.net>
In-Reply-To: <20120221115526.0320.8FE1F57E@jpix.ad.jp>
Date: Tue, 21 Feb 2012 17:06:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D69FF5F1-A780-4AF9-9E60-32E4AF71C921@laposte.net>
References: <1808340F7EC362469DDFFB112B37E2FCC67E419632@SRVHKE02.rdm.cz> <4F42ADCC.9070806@bogus.com> <20120221115526.0320.8FE1F57E@jpix.ad.jp>
To: MAWATARI Masataka <mawatari@jpix.ad.jp>
X-Mailer: Apple Mail (2.1084)
Cc: Softwires WG <softwires@ietf.org>, v6ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-464xlat
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2012 16:06:28 -0000

Masataka-san,

Please see in line.

Le 2012-02-21 à 03:55, MAWATARI Masataka a écrit :
...

> As all really know, 464XLAT remove 4rd and MAP, and vice versa, I
> also really think.

I don't understand this sentence because what 464XLAT introduces is (in 4rd/MAP) vocabulary, a variant of stateless CE (one that only works wit stateful BRs whereas those of 4rd/MAP permit BRs to also be stateless). 

Isn't it natural to quickly look whether IETF-specified stateless CEs can work indifferently with stateful and stateless BRs? 

AFAIK, there is little to add to 4rd-U so that its CEs can work according to the generic 464XLAT scenario.
- I plan to work on it in Softwire.
- Would be available to share views on the proposed solution?

> What I really want to realize is faster deploying IPv6 network and
> IPv6 service on the internet.

Same objective (that was that of 6rd, and is also that of 4rd)


Kind regards,
RD