Re: [v4tov6transition] Comment on draft-despres-softwire-6a44-01.txt

Washam Fan <washam.fan@gmail.com> Sat, 16 October 2010 13:04 UTC

Return-Path: <washam.fan@gmail.com>
X-Original-To: v4tov6transition@core3.amsl.com
Delivered-To: v4tov6transition@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B4033A68F7; Sat, 16 Oct 2010 06:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.518
X-Spam-Level:
X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL9Tnb5FN7x5; Sat, 16 Oct 2010 06:04:16 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 84E7E3A6A66; Sat, 16 Oct 2010 06:04:14 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1720828wyb.31 for <multiple recipients>; Sat, 16 Oct 2010 06:05:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=34Uxv1K267BEaEwQEozGjmSwB7A5TLUEKwF+M1vVniw=; b=qf2XJnqh4PcvMT6S5BlpujS1PRmCG3Uf7STD4ix3EXQZjxTjLodKJnpR20S+CZRKVG HKojhNrCtz5Ny9khnIothZoFFD4cUqu2dAfKGMjy8dDbb9I9mVbDi5nEE9aSZ/hiVZII wbLk9EarDk4EZoefHS7oLT/jq8xnK1jKso3hc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pPl19IpG+6afaD0GJrA5jxPFpKvxXXpotcA6rEUxa/3u/gSQetQn8tZS6aZfa8iOOL tnujyAEvd6JjADR2UxNlOGWUYPqQxPGXrxnd3bRGlpDp+stVh8PLhkmIIwHHTv1FdDM2 r9g5A1Ey96nhAxyekxChs+Pu86KGt6qvecRlo=
MIME-Version: 1.0
Received: by 10.216.22.203 with SMTP id t53mr2207146wet.37.1287234337669; Sat, 16 Oct 2010 06:05:37 -0700 (PDT)
Received: by 10.216.28.17 with HTTP; Sat, 16 Oct 2010 06:05:37 -0700 (PDT)
In-Reply-To: <4CB91E95.9000509@gmail.com>
References: <201010151714195590072@huaweisymantec.com> <9A7A1A70-1BA0-472D-9220-9556450AE777@free.fr> <201010161015343743018@huaweisymantec.com> <4CB91E95.9000509@gmail.com>
Date: Sat, 16 Oct 2010 21:05:37 +0800
Message-ID: <AANLkTi=JHtWQQToQ4g4CaGWAkQbB9+=TKEO0jBOmBA5p@mail.gmail.com>
From: Washam Fan <washam.fan@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: softwires <softwires@ietf.org>, v4tov6transition <v4tov6transition@ietf.org>
Subject: Re: [v4tov6transition] Comment on draft-despres-softwire-6a44-01.txt
X-BeenThere: v4tov6transition@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <v4tov6transition.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v4tov6transition>
List-Post: <mailto:v4tov6transition@ietf.org>
List-Help: <mailto:v4tov6transition-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4tov6transition>, <mailto:v4tov6transition-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Oct 2010 13:04:17 -0000

Hi Dong and Brian,

2010/10/16 Brian E Carpenter <brian.e.carpenter@gmail.com>:
> On 2010-10-16 15:15, Dong Zhang wrote:
>> Hi Remi,
>> Please see inline.
>
> ...
>>>> Is the A:W<->N:Z mapping created staticly? Or dynimicly?
>>> Dynamically when the 6a44-C starts operation.
>>> It then remains static until the 6a44 client or the NAT is reset.
>> That is say it is similar to a kind of permanent state once the mapping is created, supposing that there no NAT reboot and power off. Right? If so, the interruption issue of CPE should be considered. 6a44 still needs to guarantee the state recovery, right?
>
> Why? When I have to restart my IPv4-only ADSL box, I lose all
> sessions, and for all I know I get a different IPv4 address.
> So why do I care if 6a44 loses state too?
>
> Certainly the IPv6 client host must be forced to restart
> the 6a44 process when this happens. We do need a method of
> forcing that.

As I read -00, There was a method. As long as the 6a44 server detect
there was inconsistency when checking inner IPv6 address and outer UDP
header and IPv4 header, an indication message generated and forwarded
to the 6a44 client. When 6a44 clients receive indication messages,
they should realise something like restart, expircy would happened. I
think this method is fair enough to address Dong's concern.

Thanks,
washam