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

Dong Zhang <zhangdong_rh@huaweisymantec.com> Sat, 16 October 2010 02:15 UTC

Return-Path: <zhangdong_rh@huaweisymantec.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 097913A6B98; Fri, 15 Oct 2010 19:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.545
X-Spam-Level: *
X-Spam-Status: No, score=1.545 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1]
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 mwRd0MyKwMwg; Fri, 15 Oct 2010 19:15:11 -0700 (PDT)
Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 9480A3A6BB8; Fri, 15 Oct 2010 19:14:23 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LAD001PI2ABOS60@hstga01-in.huaweisymantec.com>; Sat, 16 Oct 2010 10:15:47 +0800 (CST)
Received: from z90001956 ([10.27.154.169]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LAD00LWK29YFF00@hstml02-in.huaweisymantec.com>; Sat, 16 Oct 2010 10:15:35 +0800 (CST)
Date: Sat, 16 Oct 2010 10:15:34 +0800
From: Dong Zhang <zhangdong_rh@huaweisymantec.com>
To: =?gb2312?B?UultaV9EZXNwculz?= <remi.despres@free.fr>
References: <201010151714195590072@huaweisymantec.com> <9A7A1A70-1BA0-472D-9220-9556450AE777@free.fr>
Message-id: <201010161015343743018@huaweisymantec.com>
X-Mailer: Foxmail 6, 10, 201, 20 [cn]
Content-transfer-encoding: base64
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 02:15:12 -0000

Hi Remi,
Please see inline.

Rémi_Després 2010-10-16 Wrote:
> 
>Le 15 oct. 2010 ?11:14, Dong Zhang a écrit :
>
>> Hi Remi,
>>  
>> The IPv6 host address is directly obtained by an indication message from the 6a44 server. Here is the format of the IPv6 address.
>>      +-------+-------+-------+-------+-------+-------+-------+-------+
>>      |  ISP 6a44 prefix (D)       | Customer IPv4 |NAT ext|   Host IPv4      |
>>      |                                  |   address (N)   |port(Z) |  address (A)    |
>>      +-------+-------+-------+-------+-------+-------+-------+-------+
>> According to the draft, N:Z is the address and port used on the CPE NAT44's external side. 
>>                          _                        .-------.
>>             Host      /   \       CPE         /          \     6a44 Relay
>>         +------+  . IP  .    +-----+     .   IPv4    .     +-------+    IPv6
>>         |6a44-C|--| no |--|NAT44|---| Provider  |--O 6a44-S|-- network
>>         +------+  . NAT .  +-----+     .  network  .   +-------+
>>              ^   ^   \ _ /        ^           \          /      |    ^
>>               |   A                  |            '---.---'       |    |
>>               |               A:W <-> N:Z                     |    |
>>               |   |                                                 |    |
>>               |   |                                                 |    |
>>               |    <- - - - - IPv6/UDP/IPv4 - - - - - -<      |
>>               |                                                           |
>>               |                                                           |
>>               < D.N.Z.A (/128) - - - - -  - - -IPv6 - - - - < D (/48)
>> 
>> 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?
> 
>> 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.

>
>
>
>> I mean this lifetime should longer than the expire time of the mapping on the CPE. It is because if the mapping is deleted first and the host still uses the IPv6 address embeded N:Z. It will arise problem. For instance, the CPE may allocate another port, A:W<->N:Y.
>>  
>> Therefore, there may be two ways to solve this.
>> a) set the lifetime of the allocated host IPv6 address shorter than the expire time of CPE NAT44. Thus, the host is able to re-request its IPv6 address within the NAT mapping expire time.
>
>The host ensures that its current NAT44 mapping is maintained with the same timeout as SIP for the same purpose (see in section 6 - the "Waiting for having to refresh the NAT-binding" state.)
>This is expected to be enough.
Understand.
>
>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. 
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.

Thanks.
>
>Regards,
>RD 
>
>> b) require the CPE comply with endpoint-independent mapping in RFC4787,RFC5382. But for this behavior, the premise is the host re-send the address request message must use the same source address and port, A:W. Thus, the NAT can provide the same N:Z.
>>  
>> I suppose this should be clarified in 6a44 draft, if I am correct and not missing someting.
>>  
>>  
>> Thanks.
>>  
>>  
>>  
>>  
>> 2010-10-15
>> Dong Zhang
>>  


------------------				 
Dong Zhang
2010-10-16