Subject: [Softwires] [Softwire] Algorithmic feature for SD-NAT

From: Qiong <[email-masked]>
Date: Fri, 23 Mar 2012 16:22:36 +0800

Dear Alain and all,

I'm trying to understand sd-nat-02 and I'm still wondering how to setup
subscriber-based binding table in sd-nat. In my understanding, a totally
static binding table will introduce a lot of workload for operators. But
otherwise, I guess there might be an algorithmic relationship between IPv6
and IPv4 + port range. In this way, would it become some kind of MAP, in
which IPv4 address and IPv6 address is tightly coupled and need to be
planned in advance ?  I'm just wondering why do we still need to maintain
per-subscriber table in AFTR while still keeping stateless. Please correct
me if I miss something here : )

Thanks a lot!

Best wishes
Qiong

---

From: Alain Durand <[email-masked]>
Date: Fri, 23 Mar 2012 07:06:21 -0700

On Mar 23, 2012, at 4:22 AM, Qiong wrote:

> Dear Alain and all,
> 
> I'm trying to understand sd-nat-02 and I'm still wondering how to setup subscriber-based binding table in sd-nat. In my understanding, a totally static binding table will introduce a lot of workload for operators.

Not necessarily. Operators maintain large database for customers, this is just one more field there.
The real question is how to propagate this static table to the AFTRs. This is implementation specific,
but our proposed solution is to use netconf.

> But otherwise, I guess there might be an algorithmic relationship between IPv6 and IPv4 + port range. In this way, would it become some kind of MAP, in which IPv4 address and IPv6 address is tightly coupled and need to be planned in advance ?

This can be done too, but you loose the most important advantage of SD-Nat: the absence of hard coupling between the IPv4 and IPv6 address.
Not coupling both addresses enables great flexibility on how you allocate addresses and port.

>   I'm just wondering why do we still need to maintain per-subscriber table in AFTR while still keeping stateless. Please correct me if I miss something here : 

SD-Nat is per-flow stateless, with a per-subscriber static state.

  - Alain.

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 18:26:00 +0000

Hi Alain,

Quick question. What snag suggests to keep in the customer database? Port
range info?

Thanks,
Yiu

---

From: Peng Wu <[email-masked]>
Date: Sun, 25 Mar 2012 01:56:08 +0800

Hi Alain,

Same question I raised in the other thread.
1) So this table is fully static, and we don't consider user entering
or leaving which may affect the bindings. Instead, the bindings only
rely on the addresses which won't change along the time.
2) Then this falls in the manner of pre-configuration for every
possible user IPv6 address, not on-demand allocation.

Am I correct on the two points?
Thx~

2012/3/23 Alain Durand <[email-masked]>:
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Qiong <[email-masked]>
Date: Sun, 25 Mar 2012 06:11:19 +0800

Hi Alain,

Thanks a lot for your explaination. It is much clearer now. Please see
inline ~~

On Fri, Mar 23, 2012 at 10:06 PM, Alain Durand <[email-masked]> wrote:

> static binding table will introduce a lot of workload for operators.
>
[Qiong] Well, then do you mean operators should plan the specific
relationship between IPv4 address, IPv6 address+ port set for each
subscriber? In CT's case, although we do maintain a large database for
subscriber's infomation, e.g. subscriber type, username, password, etc., we
seldom make planning of each subscriber's IPv4 address. Only a small amount
of top high priority subcribers will be configured with static addresses.

>
> > But otherwise, I guess there might be an algorithmic relationship
> between IPv6 and IPv4 + port range. In this way, would it become some kind
> of MAP, in which IPv4 address and IPv6 address is tightly coupled and need
> to be planned in advance ?
>
> This can be done too, but you loose the most important advantage of
> SD-Nat: the absence of hard coupling between the IPv4 and IPv6 address.

[Qiong] I do regard this as an important feature when we designed for
lightweight 4over6 at the very beginning. But it is still not clear to me
how to achieve it by using algorithmic method rather than MAP, especially
in case there are multiple IPv4 pools, IPv6 pools with hierarchical
relationship. Maybe the simplest way is still to configure a fully static
mapping table, thoughts ?

Thanks a lot !

Best wishes
Qiong

>
> >   I'm just wondering why do we still need to maintain per-subscriber
> table in AFTR while still keeping stateless. Please correct me if I miss
> something here :
>

---

From: Alain Durand <[email-masked]>
Date: Sat, 24 Mar 2012 15:51:46 -0700

> rely on the addresses which won't change along the time.

The bindings are created for paying customers. The idea is that you do not need to make
any pre-supposition on the format of their IPv6 nor the IPv4 address they will be give, both are
totally independent. In particular, this does not require sequential allocation of IP addresses.

Now, how do those static stables change when a customer is added or deleted?
There are essentially 2 ways.
1) out of band configuration. For example Netconf. When the provisioning system add/dele a subscriber,
part of the process is to send a Netconf update to the AFTR.
2) dynamic. When the AFTR sees a new potential subscriber (outside of the known ranges), it ask the central repository
about this subscriber. This could be a radius query. THe results is then cache for next packets. The advantage is that
a 'brand new' AFTR can learn the state on the go, the inconvenient is that it may take a while.

> possible user IPv6 address, not on-demand allocation.

Configuration for every IPv6 subscriber, not every possible IPv6 address in the various /64
This is actually not that bad. Compare to BNGs that do the same and more today for IPv4 or IPv6.
In the end, this is about clustering subscribers on groups of AFTR, the size of the cluster being in the
order of magnitude of the number of subscriber per BNGs, maybe up to 10x more.

Alain

---

From: Alain Durand <[email-masked]>
Date: Sat, 24 Mar 2012 15:56:16 -0700

On Mar 24, 2012, at 6:11 PM, Qiong wrote:

\> I'm trying to understand sd-nat-02 and I'm still wondering how to setup subscriber-based binding table in sd-nat. In my understanding, a totally static binding table will introduce a lot of workload for operators.

Not necessarily. Operators maintain large database for customers, this is just one more field there.
The real question is how to propagate this static table to the AFTRs. This is implementation specific,
but our proposed solution is to use netconf.
[Qiong] Well, then do you mean operators should plan the specific relationship between IPv4 address, IPv6 address+ port set for each subscriber? In CT's case, although we do maintain a large database for subscriber's infomation, e.g. subscriber type, username, password, etc., we seldom make planning of each subscriber's IPv4 address. Only a small amount of top high priority subcribers will be configured with static addresses.

[Alain] I understand this is the practice now, when IPv4 addresses are essentially free. When we move to a mode of operation where IPv4 addresses
are a scarce and expensive resource, you want to be able to manage it tightly, just like you manage bandwidth for subscribers.

[Qiong] I do regard this as an important feature when we designed for lightweight 4over6 at the very beginning. But it is still not clear to me how to achieve it by using algorithmic method rather than MAP, especially in case there are multiple IPv4 pools, IPv6 pools with hierarchical relationship. Maybe the simplest way is still to configure a fully static mapping table, thoughts ?

In the end, if you have a large number of small IPv4 blocks, there is not much to be gained with deterministic formulas, you end up with a long and difficult to manage static list of formulas that are not tight to a business logic. I would agree with you that at that point, you'd be better off with a full static per subscriber table, managed out of band by netconf or other tool.

Alain.

---

From: Alain Durand <[email-masked]>
Date: Sat, 24 Mar 2012 15:58:38 -0700

The per subscriber mapping table looks like:
Subscriber ID (usually IPv6 address of CPE)
Assigned IPv4 public address (the one assigned by DHCPv4 over IPv6)
port range

Alain

---

From: Peng Wu <[email-masked]>
Date: Sun, 25 Mar 2012 12:29:44 +0800

Hi Alain,

Thanks. It really helps.

> order of magnitude of the number of subscriber per BNGs, maybe up to 10x more.
I agree. This is pretty much my general understanding.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 25 Mar 2012 22:55:30 +0200

>  possible user IPv6 address, not on-demand allocation.

=> IMHO these points are not about the SD-NAT class of mechanisms
but more about the interface between the SD-CGN and the provisioning
system. So you can implement what you want (static/dynamic, on demand
or provisioning pushing a config to the SD-CGN).
I think the only thing you can't (easily) do is the SD-NAT doing the
provisioning itself because the SD-CPE needs to get the right
configuration too and until we define a working in-band solution
it will receive it out-of-band, by DHCP for instance.

Note I don't say the questions are not interesting (they need to be solved
for a production deployment) but they are not on the same plan
than the SD-NAT mechanism itself.

Regards

[email-masked]