Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite

From: Reinaldo Penno <[email-masked]>
Date: Tue, 1 Nov 2011 19:12:26 -0400

Hello,

we submitted a new draft detailing our implementation of
Stateless-Deterministic NAPT44 and DS-Lite. (SD-NAT)

http://tools.ietf.org/html/draft-penno-softwire-sdnat-01

This is a based on our experience with port bucket/chunk allocation and
deterministic NAPT44. In the draft we provide a comparison with other
stateless/stateful methods floating around.

Thanks,

Reinaldo

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Thu, 3 Nov 2011 18:38:29 -0500

Just to make sure I understand this. 

Deterministic (statefull) NAT is deterministically translating inside IP to outside IP + port range (take NAT44 case).

Deterministic stateLESS NAT is deterministically translating inside IP + inside_src_port to outside IP + outside_src_port. 
No states are required since the incoming traffic in the downstream direction (outside IP +port) can be deterministically translated to inside IP+port. 
Any incoming traffic from outside will be mapped to something (predictable) on the inside even though there may be no traffic initiated from the inside.

CPE still needs statefull NAT.

Is this correct?
Thanks,
Kris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reinaldo Penno
Sent: Tuesday, November 01, 2011 4:12 PM
To: [email-masked]; [email-masked]
Subject: [BEHAVE] Stateless Deterministic NAPT/DS-Lite

Hello,

Thanks,

Reinaldo

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 3 Nov 2011 20:32:51 -0400

Hello Kristian,

comments inline.

On 11/3/11 4:38 PM, "Poscic, Kristian (Kristian)"
<[email-masked]> wrote:

> Deterministic (statefull) NAT is deterministically translating inside IP to
> outside IP + port range (take NAT44 case).

Yes. 

> 
> Deterministic stateLESS NAT is deterministically translating inside IP +
> inside_src_port to outside IP + outside_src_port.
> No states are required since the incoming traffic in the downstream direction
> (outside IP +port) can be deterministically translated to inside IP+port.
> Any incoming traffic from outside will be mapped to something (predictable) on
> the inside even though there may be no traffic initiated from the inside.

Correct, no need for previous outbound packet. Subscriber gets port
forwarding naturally as a consequence.

> CPE still needs statefull NAT.

Yes.

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Fri, 4 Nov 2011 07:21:04 +0100

Reinaldo,

What happens if a customer wants to get more ports than the CPE owns?
How would PCP operate with this model?

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reinaldo Penno
Sent: vrijdag 4 november 2011 1:33
To: Poscic, Kristian (Kristian); [email-masked]; [email-masked]
Subject: Re: [Softwires] [BEHAVE] Stateless Deterministic NAPT/DS-Lite

Hello Kristian,

comments inline.

Yes. 

Yes.

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Alain Durand <[email-masked]>
Date: Mon, 7 Nov 2011 06:54:06 -0800

> What happens if a customer wants to get more ports than the CPE owns?

Similar to the other stateless proposals such a 4rd or divi, there is no provision to dynamically extend that range allocated by the ISP.
The consensus that was expressed a number of time in the wg is that if you need this flexibility,
a stateless solution is the wrong approach, you'd be be better of with a stateful solution.

> How would PCP operate with this model?

This is an interesting question... This should make the life of the PCP server rather easy, as there will be no state to keep there too.

Alain.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Nov 2011 08:05:20 -0800

On Nov 7, 2011 6:58 AM, "Alain Durand" <[email-masked]> wrote:
> Similar to the other stateless proposals such a 4rd or divi, there is no
provision to dynamically extend that range allocated by the ISP.
> This is an interesting question... This should make the life of the PCP
server rather easy, as there will be no state to keep there too.

Interesting indeed, no pcp and no alg.

So for stateless solutions anything that falls out of your static cgn
allocation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp?
Ipsec? ...

Sorry if I missed something obvious for how these are enabled.

Cb

> >> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> >> Reinaldo Penno

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Nov 2011 09:11:14 -0800

> Sorry if I missed something obvious for how these are enabled.

Ok, i think i figured this one out, the SD-CPE will force the ports
into the range supported on the CGN.

---

From: Alain Durand <[email-masked]>
Date: Mon, 7 Nov 2011 09:45:51 -0800

> This is an interesting question... This should make the life of the PCP server rather easy, as there will be no state to keep there too.

Interesting indeed, no pcp and no alg

PCP stil works. It is easier to implement.

So for stateless solutions anything that falls out of your static cgn allocation will not work? Like sip/rtp? Multiplayer games? Ftp? Rtsp? Pptp? Ipsec? ...

If those apps rely on listening on a well known port, they will fail with any address/port sharing solution, stateful or stateless.
If not, they negotiate ports with PCP or other methods before advertising it with a rendez-vous server. This is independent from stateful vs stateless.

Alain.

---

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

> a stateless solution is the wrong approach, you'd be be better of with a

Actually Alain, we can do it. It is a trade-off between public IP usage
efficiency and management.

If CPE run out of ports that subscriber/private IP, if changing IP is not an
option, is moved to another deterministic NAT pool with larger ranges.
Everything is transparent.  This assumes you have a two-tier NAT pool model
(which is common), apart from that it is okay.

> This is an interesting question... This should make the life of the PCP server
> rather easy, as there will be no state to keep there too.
> 
> Alain.
> 
> 
> 
> 
> 
>> 
>> Cheers,
>> Wim
>>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Nov 2011 20:06:44 -0500

Hi,

I read this draft and am a bit puzzled. It looks *very* similar to A+P. I see
two enhancements (in academia we would call them "contributions"):

- The CPE port range is learned dynamically. This is done by listening to ICMP
errors.
Question: how can the CPE differentiate between errors that mean "you're out of
your allocated port set" and those that are normal errors that would have
happened on a regular non-CGN connection?

- There is a possibility of an arbitrary additional 1-to-1 mapping done on the CGN.

If I understand correctly, these features could be considered as enhancements on
top of A+P. Fundamentally this is still A+P.

Did I get this right? Is there a fundamental difference I did not see?

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Nov 2011 23:37:03 -0500

Hi Simon,

One of the fundamental aspects of A+P (http://tools.ietf.org/html/rfc6346)
and variants discussed in softwires WG is the sharing of an IP address
across CPEs, treating port number bits as extended IP address. That is not
the case here.  

Depending on configuration/policy each CPEs can get anything from a full IP
to a port block of P ports, but there is still a unique WAN IP to each CPE.

Thanks,

Reinaldo

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Nov 2011 08:49:08 -0500

> to a port block of P ports, but there is still a unique WAN IP to each CPE.

In my understanding, in A+P, each CPE can also get anything from a full IP to a
block of P ports, and there is also still a unique WAN IP to each CPE. No?

I feel like I'm missing something obvious...

Simon

---

From: Alain Durand <[email-masked]>
Date: Tue, 8 Nov 2011 07:13:56 -0800

Simon:

In A+P, the CPE  must "learn" its external address and port one way or another and do the translation accordingly.
In SD-NAT, the CPE does not need to do that. It just translate using the WAN (or B4) IP address.

Alain.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Nov 2011 10:21:42 -0500

> In SD-NAT, the CPE does not need to do that. It just translate using the WAN (or B4) IP address.

Got it, thanks!

Simon

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Nov 2011 19:01:14 +0100

Reinaldo, Alain, Lionel,

Nicely written document.
Here are a few points:

1. Other stateless solutions and DS-lite
The introduction suggests that other stateless solutions resulted from "efforts to evolve the DS-lite model", this isn't really how they were designed: 
- The DS-lite model is AFAIK based on
  . RFC-1918 addresses being the only IPv4 addresses that traverse the ISP network
  . NATs within the ISP infrastructure
  . Hub-and-spoke topologies (mesh topologies excluded)  
- Works on 4rd and A+P excluded since the origin these three features. They are based on:
  . Public IPv4 addresses across ISP networks 
  . IP-payload transparency (no NAT)
  . Support of mesh topologies (with hub and spoke possible as a limit case)

2. IPv4 address-pool modifications
The draft asserts that SDNAT is necessarily better than stateless solutions to "add and remove addresses from the NAT pool", but doesn't explain.
This isn't clear to me, in particular because sec. 2.1 says "the SD-CPE can learn the external address it is mapped to using the PCP protocol". 
Changing the IPv4 address pool seems therefore to have consequences similar to those of solutions that provide addresses and port sets in DHCP.

On the other hand, with a lifetime applicable to mapping rules, it is possible with other stateless solutions to plan a replacement of obsolete mapping rules by new ones. The time during which IPv4 is unavailable needs not to be long. 

3. Number of ports in IPv6 addresses 
The draft asserts that, with other stateless solutions, "the number of IPv4 port allocated per subscriber is encoded in the IPv6 address". 
There were such proposals, but also proposals that didn't have it.
This isn't AFAIK a requirement of the MAP design team.

4. IPv4-only ISP access networks (6rd + 4rd also works!)
A claimed advantage is that SD-CPEs "can remain IPv4-only devices" (IMHO a strange idea since they have to be upgraded to support SDNAT), and that "the ISP access network can also remain IPv4-only".

On the latter point, note that 6rd can be combined with 4rd (or some other mesh-compatible stateless solution) for the same result: this brings, across IPv4-only  access networks, both IPv6 service AND IPv4 residual service. 

5. Differentiated sharing ratios? 
To support differentiated CPE sharing ratios several sets of mapping-function parameters are presumably needed. 
Their impact on routing plans, and on CGN operation, aren't evaluated.

6. Operational experience
A claimed advantage of SD-NAT over double translation solutions is that there is more operational experience with encapsulation, a consideration that has limited but real value.
But the need of SDNAT to support PCP for incoming connectivity leads to a world where past experience is very limited. 
The fact that others stateless solutions don't need PCP should therefore be noted in the comparison section sec. 7.2.

In view of the above, the need for one more standard is unclear to me. 
(A Mesh-capable solution also works for hub-and-spoke topologies, and can easily be added to CGNs). 

Regards,
RD