Re: [Softwires] Fw: New VersionNotificationfordraft-cui-softwire-b4-translated-ds-lite-04.txt

"Peng Wu" <peng-wu@foxmail.com> Fri, 04 November 2011 09:38 UTC

Return-Path: <peng-wu@foxmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB30121F8C1A for <softwires@ietfa.amsl.com>; Fri, 4 Nov 2011 02:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.649
X-Spam-Level:
X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, MIME_BASE64_TEXT=1.753]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKq2qkiQOL9E for <softwires@ietfa.amsl.com>; Fri, 4 Nov 2011 02:38:47 -0700 (PDT)
Received: from smtpbg52.qq.com (smtpbg52.qq.com [64.71.138.43]) by ietfa.amsl.com (Postfix) with SMTP id 4EF4821F8C15 for <softwires@ietf.org>; Fri, 4 Nov 2011 02:38:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s0907; t=1320399494; bh=eaMpub7s75rqmGBOHutxfrgyQ0rp04AUFr8eu9RdZ30=; h=X-QQ-mid:Received:X-QQ-SSF:Date:From:To:Reply-To:Subject: References:X-Priority:X-Mailer:Mime-Version:Message-ID: Content-Type:Content-Transfer-Encoding; b=XfNiggg2K3rGErOhdnZDvmszDYMlPUXpU7NjEpc4FOJQEwHvGjgBgYo8bVnUrnzAz niWAtuWlA9LBr335804EYO4cBlJXRqanmnZE4vDjpJZ+7xdP2CgdG7rr+bMNkE/
X-QQ-mid: esmtp8t1320399491t696t17013
Received: from PengWU-PC (unknown [115.232.19.210]) by esmtp4.qq.com (ESMTP) with id ; Fri, 04 Nov 2011 17:38:01 +0800 (CST)
X-QQ-SSF: 00000000000000F0FxF001000000000
Date: Fri, 04 Nov 2011 17:38:01 +0800
From: Peng Wu <peng-wu@foxmail.com>
To: Reinaldo Penno <rpenno@juniper.net>, Olivier Vautrin <ovautrin@juniper.net>, softwires <softwires@ietf.org>
References: <CAD84C25.575C7%rpenno@juniper.net>, <2011110415285269417121@foxmail.com>
X-Priority: 3
X-Mailer: Foxmail 7.0.1.82[cn]
Mime-Version: 1.0
Message-ID: <2011110417380132016863@foxmail.com>
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
Subject: Re: [Softwires] Fw: New VersionNotificationfordraft-cui-softwire-b4-translated-ds-lite-04.txt
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: peng-wu <peng-wu@foxmail.com>
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 09:38:48 -0000

Hi Reinaldo,

I just took a brief look at draft-penno-softwire-sdnat-01,  to get the basic
 idea. Not sure if I understand correctly.

This is a quite customized mechanism rather than just "static port set allocation in the
 concentrator". I guess that's why I'm confused by you last email, ha :)

Regarding the DS-lite case, you kind of encode the port set index into the B4 IPv6 address,
and than, achieve statelessness. The difference with the existing stateless mechanisms
is that, you don't encode the public IPv4 address so you don't inform the customers
this information. And you also need double translation to fit in the AFTR NAT, which is
also different from the existing stateless mechanisms.

This is quite interesting. It fits in the specific DS-lite case, but in general it's stateless mechanism.
We kind of fall into different categories and use cases. Actually we have discussions on 
stateless vs. lightweight 4over6 in the Introduction part of our draft. For example, think of
the case when either the B4 IPv6 addresses or the IPv4 address pool are scattered. Then the 
the statless mapping rule/algorithm on the AFTR can be quite complicated. 


--------------
Peng Wu
>Hi Reinaldo,
>
>inlines :)
>--------------
>Peng Wu
>
>>> The first and the major one is that, if we just take ds-lite and have static
>>> port set allocation in the concentrator, the concentrator still has to keep
>>> the per-session NAT table and perform the translation, while in lightweight
>>> 4over6, NAT happens on CPE and the concentrator just perform
>>> encapsulation/decapsulation, with a per-subscriber mapping table.
>>
>>Per-session NAT is not needed if:
>>
>>- the B4 performs NAT or
>>- Each host has a unique IP and a known port space.
>>
>>Our implementation performs NAT without any per session state.
>Could you go a little further into this? 
>I'm actually confused how you do NAT without (source IP, 
>source port, dst IP, dst port) mapping table
>
>>
>>> 
>>> The second one is that in lightweight 4over6, with one-time DHCP/PCP,
>>> the subscriber learns its public IPv4 address. This brings convenience and
>>> eases the ALG problem to a certain extent.
>>
>>I think ALG is an application issue and can only be fully solved when all
>>applications make use of PCP.
>Well, my point is, if the whole problem is just a local 44NAT(as is in leightweight 4over6), 
>then we already have uPnP, and end host don't need PCP to negotiate with the AFTR 
>which is  probably a remote, big network device.
>>
>>> In ds-lite with static concentrator
>>> port allocation, the subscriber still doesn't know its public IPv4
>>> address/port 
>>> without per-session PCP process.
>>
>>Yes, that is a good point. We devised an extension to PCP to return the
>>public IP and port range. Therefore a single message would be needed.
>Similar idea. But I still need your elaboration on the principle of this
> none-session-state NAT thing to get the whole picture.
>>
>_______________________________________________
>Softwires mailing list
>Softwires@ietf.org
>https://www.ietf.org/mailman/listinfo/softwires
>