IETF Logo Mail Archive

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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 16 October 2010 03:39 UTC

Return-Path: <brian.e.carpenter@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 A46083A6A71; Fri, 15 Oct 2010 20:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.394
X-Spam-Level:
X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 6z5FCo8XjVum; Fri, 15 Oct 2010 20:39:06 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 263803A6B77; Fri, 15 Oct 2010 20:39:02 -0700 (PDT)
Received: by ywa6 with SMTP id 6so766585ywa.31 for <multiple recipients>; Fri, 15 Oct 2010 20:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6pFhj7yfzkRxLuWZko4XXttnT5NXO0SieacjxVoxFZo=; b=X9mG7dqKIBXH2WRUaN2aIwBBUQgd5SWxzIN2RvSSgn910kyHDeNm4JTxWsAV7MBuZa 3M/wyx58Rto00l+ni3AZcINt17do8WMVbPtaYFKjgt+DIKgqiwIeTQIV1Ro8k6LmzN2W Sjh/C5vtQ1FpMJf1k4V1Uw/NqlbnffpLKgOWs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=jN3HNuUZ/pHF325zSW8Ud4RNAUB8kBrb4mTwodPFn7BEP1WKCRaA5fTLj+TFif5R/P Vd2TgyhKoKBYfD6Qun65KnN0VYryWstCKrKqT2WWGzM4LfDI3uzuG6Drn66y4eg9Remx 1+HBnYe2iDa4EIwhOI5X6S3ypkvUTne4FfCl8=
Received: by 10.150.140.4 with SMTP id n4mr2864868ybd.316.1287200416307; Fri, 15 Oct 2010 20:40:16 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id u30sm6532594yhc.29.2010.10.15.20.40.12 (version=SSLv3 cipher=RC4-MD5); Fri, 15 Oct 2010 20:40:15 -0700 (PDT)
Message-ID: <4CB91E95.9000509@gmail.com>
Date: Sat, 16 Oct 2010 16:40:05 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dong Zhang <zhangdong_rh@huaweisymantec.com>
References: <201010151714195590072@huaweisymantec.com> <9A7A1A70-1BA0-472D-9220-9556450AE777@free.fr> <201010161015343743018@huaweisymantec.com>
In-Reply-To: <201010161015343743018@huaweisymantec.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
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 03:39:08 -0000

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.

   Brian

v2.23.0 | Report a Bug | By Email