Subject: [Softwires] Fw: New Version Notification for draft-cui-softwire-b4-translated-ds-lite-04.txt

From: "peng-wu@foxmail" <[email-masked]>
Date: Wed, 2 Nov 2011 23:06:38 +0800

Hi all,

We've submitted a -04 version of the b4-translated-ds-lite draft.
It describes the per-user-state IPv4-over-IPv6 mechanism with port set support, which can be achieved through some extensions to ds-lite.
There are discussions going on upon this topic during and after the Interim meeting.
We've received quite a lot offline comments/suggestions, and made progresses accordingly.

The draft is available on http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-04
Please provide your valuable comments. And hopefully we'll present it in Taipei.

u---
A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-04.txt has been successfully submitted by Qiong Sun and posted to the IETF repository.

Filename:	 draft-cui-softwire-b4-translated-ds-lite
Revision:	 04
Title:		 Lightweight 4over6 in access network
Creation date:	 2011-10-30
WG ID:		 Individual Submission
Number of pages: 24

Abstract:
   The dual-stack lite mechanism provide an IPv4 access method over IPv6
   ISP network for end users.  Dual-Stack Lite enables an IPv6 provider
   to share IPv4 addresses among customers by combining IPv4-in-IPv6
   tunnel and Carrier Grade NAT.  However, in dual-stack lite, CGN has
   to maintain active NAT sessions, which could become the performance
   bottom-neck due to high dynamics of NAT entries, memory cost and log
   issue.  This document propose the lightweight 4over6 mechanism which
   moves the translation function from tunnel concentrator (AFTR) to
   initiators (B4s), and hence reduces the mapping scale on the
   concentrator to per-customer level.  For NAT44 translation usage, the
   mechanism allocates port restricted IPv4 addresses to initiators in a
   flexible way independent of IPv6 network in the middle.

The IETF Secretariat

---

From: Olivier Vautrin <[email-masked]>
Date: Wed, 2 Nov 2011 16:21:18 -0700

Hello, thanks for this interesting draft.

In your use case, could you explain if every CPE/Host need to reach
Internet? That would be the case in a typical Broadband deployment but
perhaps not in your deployment scenario.

If all CPE needs Internet access, all of them with an IP@ need a dedicated
"bucket of ports" installed in the Concentrator. Which means that we could
just have a static allocation of ports in the Concentrator instead of
DHCP/PCP mechanism as described in your draft.

My point is we could have a Stateless mechanism in the Concentrator as
described in SD-NAT (draft-penno-softwire-sdnat-01) and just use regular
DHCP/Radius on the CPE to get a dynamic address allocation with the same
result.

What do you think?

Cheers,
Olivier

On 11/2/11 8:06 AM, "peng-wu@foxmail" <[email-masked]> wrote:

>It describes the per-user-state IPv4-over-IPv6 mechanism with port set
>support, which can be achieved through some extensions to ds-lite.
>The draft is available on
>http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-04
>A new version of I-D, draft-cui-softwire-b4-translated-ds-lite-04.txt has
>been successfully submitted by Qiong Sun and posted to the IETF
>repository.
>
>_______________________________________________
>Softwires mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires

---

From: "Peng Wu" <[email-masked]>
Date: Thu, 3 Nov 2011 20:12:39 +0800

Hi Olivier,

see inlines :)
--------------
Peng Wu
>perhaps not in your deployment scenario.
Could be every CPE/Host.
>DHCP/PCP mechanism as described in your draft.
Well, we've thought of this.
There're two differences here.

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.

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. In ds-lite with static concentrator 
port allocation, the subscriber still doesn't know its public IPv4 address/port 
without per-session PCP process.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 3 Nov 2011 16:48:21 -0400

Hello Peng,

Some comments inline...

> see inlines :)

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.

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

> In ds-lite with static concentrator

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.

---

From: "Peng Wu" <[email-masked]>
Date: Fri, 4 Nov 2011 15:28:52 +0800

Hi Reinaldo,

inlines :)
--------------
Peng Wu

>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

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

---

From: Qiong <[email-masked]>
Date: Fri, 4 Nov 2011 16:00:22 +0800

Hi, Olivier,

Thanks for your comments:)  I would like to explain a bit more.

> perhaps not in your deployment scenario.

Actually, we have already implemented on both CPE/Host-based initiator. We
have described it in Appendix1, and we have also run a host-based demo
system in IETF 81.

> I think it is a good feature of stateful approach to have flexible port
allocation. The static allocation of ports is discussed in stateless
solution. Anyway, stateful and stateless solution would have its own
advantage and disadvantage.

> DHCP/Radius on the CPE to get a dynamic address allocation with the same

A quick comment: it seems SD-NAT has introduced double address translation
making use of regular DHCP/Radius. It is very interesting, however, it
would introduce more ALG issues than single NAT. It is more like a
hub&spoke stateless solution, e.g. stateless 4over6, etc. I'm not sure how
this kind of stateless mechanism compared to 4rd, dIVI, etc. And I would
prefer a unified address+port allocation algorithm in softwire WG.

Best wishes

Qiong

> Olivi

---

From: "Peng Wu" <[email-masked]>
Date: Fri, 4 Nov 2011 17:38:01 +0800

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

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Nov 2011 19:39:06 -0500

> also different from the existing stateless mechanisms.

The double translation is optional. As with other schemes you need to
guarantee uniqueness, which can be achieved in many different ways.

> the statless mapping rule/algorithm on the AFTR can be quite complicated.

Yes, that is correct. We have approached that and would be happy to discuss.

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Nov 2011 19:41:04 -0500

Can you clarify more ALG issues? It seems to me that whatever ALG issues you
have it will happen irrespective.

On 11/4/11 1:00 AM, "Qiong" <[email-masked]> wrote:

> making use of regular DHCP/Radius. It is very interesting, however, it would
> introduce more ALG issues than single NAT. It is more like a hub&spoke
> stateless solution, e.g. stateless 4over6, etc. I'm not sure how this kind of
> stateless mechanism compared to 4rd, dIVI, etc. And I would prefer a unified
> address+port allocation algorithm in softwire WG.

---

From: Qiong <[email-masked]>
Date: Tue, 8 Nov 2011 14:24:26 +0800

Hi Reinaldo,

I'm not sure whether I understand SD-NAT correctly. I mean, in "lightweight
4over6", we will only do single-NAT in the initiator, and there is no
address/port translation in the concentrator-side. If SD-NAT needs to do
address/or port translation on both CPE and AFTR, there will be double ALG
issues here. But as you mentioned in previous mail, in case double
translation is optional,  double ALG would also be optional.

Anyway, it is an interesting stateless scheme and I would like to discuss
with you in Taipei :)

Best wishes

Qiong

On Tue, Nov 8, 2011 at 8:41 AM, Reinaldo Penno <[email-masked]> wrote:

> would

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 8 Nov 2011 02:00:33 -0500

On 11/7/11 10:24 PM, "Qiong" <[email-masked]> wrote:

> issues here. 

Thanks for the comment. Can you clarify what are the 'double' ALG issues? In
my experience if an ALG works through one NAT, it will work through any NATs
as long as the ALG is implemented (and vice versa).

> But as you mentioned in previous mail, in case double translation
> is optional,  double ALG would also be optional.
> 
> Anyway, it is an interesting stateless scheme and I would like to discuss with
> you in Taipei :)

Sure.

> 
> Best wishes
> 
> Qiong
> 
> On Tue, Nov 8, 2011 at 8:41 AM, Reinaldo Penno
> <[email-masked]<mailto:[email-masked]>> wrote:
> On 11/4/11 1:00 AM, "Qiong" <[email-masked]<mailto:[email-masked]>>
> wrote:
>