Subject: [pcp] Comments on draft-tsou-pcp-natcoord-08

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 28 Nov 2012 13:47:38 +0000

Hello Authors,

I reviewed this draft and my general comments are below, mostly related to
the motivation and proposed solution.

The draft states the following:

"
1.  Application Scenario

   PCP can be used to control an upstream device to achieve the
   following goals:

   1.  A plain IP address (i.e., a non-shared) can be assigned to a
       given subscriber because it subscribed to a service which uses a
       protocol that don't embed a transport number or because the NAT
       is the only deployed platform to manage IP addresses.

   2.  An application (e.g., sensor) does not need to listen to a whole
       range of ports available on a given IP address.  Only a limited
       set of ports are used to bind its running services.  For such
       devices, the external port(s) and IP address can be delegated to
       that application and therefore avoid enforcing NAT in the network
       side for its associated flows.  The NAT in the PCP- controlled
       device should be bypassed.

   3.  A device able to restrict its source ports can be delegated an
       external port restricted IP address.  The PCP- controlled device
       should be instructed to by-pass the NAT when handling flows
       destined/issued to that device.
"

In both 2 and 3 NAT could be performed by PCP controlled device. There is
no discussion of this aspect (maybe due to Lw4o6 drivers) but if the
mechanism is to be generic, we need to define how it would work. As I
think about it , it seems there are quite a few issues to be ironed out.

Thanks,

Reinaldo

---

From: "Zhouqian (Cathy)" <[email-masked]>
Date: Thu, 29 Nov 2012 06:31:22 +0000

Hi Reinaldo,
> think about it , it seems there are quite a few issues to be ironed out.

Thanks for your comments. This document will focus on NAT Bypass case only. 
For the scenario when NAT is performed in PCP-controlled device, it is out 
of scope. And what are the issues you are thinking about?

Best Regards,
Cathy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Reinaldo Penno (repenno)
> Sent: Wednesday, November 28, 2012 9:48 PM
> To: [email-masked]
> Subject: [pcp] Comments on draft-tsou-pcp-natcoord-08
> 
> Hello Authors,
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Nov 2012 11:58:39 +0100

Hi Reinaldo,

> think about it , it seems there are quite a few issues to be ironed out.

As mentioned in the presentation, there are ONLY TWO differences between 
MAP and MAP_PORT_SET:

- MAP maps a single port, MAP_PORT_SET maps a set of ports. (Obviously!)

- MAP_PORT_SET has the limitation that NAT is optionally applied to the 
address (as for MAP), but *never* applied to ports.

If someone can find a way to make MAP_PORT_SET work with NAT applied to 
ports, please do suggest it. We have thought a lot about this and can't 
find a clean way to do it. We believe that the limitation is acceptable.

Agreed?

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