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

Rémi Després <remi.despres@free.fr> Tue, 19 October 2010 09:19 UTC

Return-Path: <remi.despres@free.fr>
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 5E93B3A6AC4; Tue, 19 Oct 2010 02:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 uI7NJKS+16Uo; Tue, 19 Oct 2010 02:18:59 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id DA3F53A6A87; Tue, 19 Oct 2010 02:18:58 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2322.sfr.fr (SMTP Server) with ESMTP id 859B2700009D; Tue, 19 Oct 2010 11:20:28 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2322.sfr.fr (SMTP Server) with ESMTP id 153EC7000099; Tue, 19 Oct 2010 11:20:27 +0200 (CEST)
X-SFR-UUID: 20101019092028871.153EC7000099@msfrf2322.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <remi.despres@free.fr>
In-Reply-To: <201010161015343743018@huaweisymantec.com>
Date: Tue, 19 Oct 2010 11:20:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <606D9E17-70AF-4AE3-9310-1A8CE34EC09B@free.fr>
References: <201010151714195590072@huaweisymantec.com> <9A7A1A70-1BA0-472D-9220-9556450AE777@free.fr> <201010161015343743018@huaweisymantec.com>
To: Dong Zhang <zhangdong_rh@huaweisymantec.com>
X-Mailer: Apple Mail (2.1081)
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: Tue, 19 Oct 2010 09:19:00 -0000

Le 16 oct. 2010 à 04:15, Dong Zhang a écrit :

>>> ...
>>> 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?

Yes

> If so, the interruption issue of CPE should be considered. 6a44 still needs to guarantee the state recovery, right?

In my understanding, the recovery mechanism is already in the draft:
When the host send a packet to the 6a44 server (which it must do at least every 29 seconds) the CPE creates a new mapping,  and the server, finding an inconsistency between ports contained in the IPv6 address and the UDP header, returns to the host an IPv6 address indication with the updated address.


>> 
>>> When the host reqests the IPv6 address to the 6a44 server, the server gives the host IPv6 address and liftime directly.  If  the mapping on the CPE is allocated dynamically, how does the lifetime of the allocated host IPv6 address will be set?
>> 
>> An ISP that doesn't plan any customer renumbering can give this lifetime a very large value.
>> It is only when a renumbering is planned that, a short lifetime is useful.
> Hmm... Now that it is an operational issue, adding some clarification could be helpful for the reader, I think.

It now seems to me that suppressing the server-provided lifetime, as discussed below, would be better (simplifying, wherever we can, is always a progress).

>> ...
>> Actually, it is still unclear to me whether the lifetime in IPv6 Address Indication is useful enough to keep its presence. 
>> Since the NAT-binding-refresh time of 29 seconds is already rather short, compared to the timing of renumbering operations, I would be interested in views of others on this.

>> 
> IMHO, it is common tha an address  has a lease or lifetime. 

Yes (but this of course isn't sufficient to justify it here).

> I wonder what the IPv6 source is in the IPv6 ADDRESS REQUEST msg when the host sends it for the first time. If the CPE IPv4 address is renumbered, from N to M, will the host re-send the ADDRESS REQUEST still with the IPv6 source embeded with N? Then 6a44 server checks the consistency between the inner and outer addresses.

> It will find N is not equal to M.

Yes (assuming that the CPE has changed to the new address). 
Then, as above, the server returns to the host an updated IPv6 address indication containing M.

Regards,
RD