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

Rémi Després <remi.despres@free.fr> Fri, 15 October 2010 16:55 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 E70D53A6CAA; Fri, 15 Oct 2010 09:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.412
X-Spam-Level:
X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=0.537, 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 0iP2KQpZWrxr; Fri, 15 Oct 2010 09:55:48 -0700 (PDT)
Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.21]) by core3.amsl.com (Postfix) with ESMTP id 675CD3A6C93; Fri, 15 Oct 2010 09:55:42 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id 5971970000A3; Fri, 15 Oct 2010 18:57:03 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2313.sfr.fr (SMTP Server) with ESMTP id D28357000084; Fri, 15 Oct 2010 18:57:02 +0200 (CEST)
X-SFR-UUID: 20101015165702862.D28357000084@msfrf2313.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <201010151714195590072@huaweisymantec.com>
Date: Fri, 15 Oct 2010 18:57:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A7A1A70-1BA0-472D-9220-9556450AE777@free.fr>
References: <201010151714195590072@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: Fri, 15 Oct 2010 16:55:49 -0000

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



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

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. 

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
>