Subject: [BEHAVE] Comments on draft-boucadair-port-range-00.txt

From: Dave Thaler <[email-masked]>
Date: Tue, 4 Nov 2008 19:51:02 -0800

Some high level comments on this draft:

1) Port forwarding won't work as it does today since users will not be able to do port-forwarding on well-known ports used by services/games/etc, since multiple users would want the same port.  This is an inherent limitation in IP sharing schemes.

2) This document currently seems to assume that end hosts never connect directly to the service provider, and it requires changes in all devices that can connect directly to the service provider.

3) It still requires a separate IP address for each CPE device behind the same provider PRR (for anyone who hasn't read this draft, a PRR is what this draft has instead of a CGN).  The CGN motivation generally comes from not having enough IP space to number all CPEs.  A separate address allows using private IP space (in addition to the shared public IP), but if you have more customers than you have private IP space, then you still cannot uniquely identify a customer by IP address.  This will increase management complexity and costs.

4) If you don't have a separate IP address, but instead use source routing as suggested, my understanding is that it would be a huge performance hit due to slow-path forwarding in many routers.

5) The draft does not currently provide a solution to customer-to-customer communication except when the customers share a common next hop router and you put the PRR there (as opposed to closer to the core).  And the solution it does have again assumes modified CPE's that are not end hosts (where this solution would break some apps).

A marked up copy with more detailed comments is attached.

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

---

From: <[email-masked]>
Date: Wed, 12 Nov 2008 12:06:11 +0100

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Dave Thaler
> Envoyé : mercredi 5 novembre 2008 04:51
> À : BOUCADAIR Mohamed RD-CORE-CAE; LEVIS Pierre RD-CORE-CAE; 
> VILLEFRANQUE Alain RD-CORE-CAE
> Cc : [email-masked]
> Objet : [BEHAVE] Comments on draft-boucadair-port-range-00.txt
> 
> 1) Port forwarding won't work as it does today since users 
> will not be able to do port-forwarding on well-known ports 
> used by services/games/etc, since multiple users would want 
> the same port.  This is an inherent limitation in IP sharing schemes.

We need to distinguish here two things: the port forwarding capability and the use of well-known ports.
- As for port forwarding, this feature is still delivered. 
- The availability of well known ports depends on the port mask assigned to the customer. Under some engineering choices, we agree that some well known port numbers won't be available for a given customer. This is one motivation for our proposal of a port mask that can result in a balanced distributed of well-known port numbers. See draft-boucadair-dhc-port-range-01 for more discussion about this issue. 

> 2) This document currently seems to assume that end hosts 
> never connect directly to the service provider, and it 
> requires changes in all devices that can connect directly to 
> the service provider.

What do you mean by "directly connected to the provider"? 
Do you mean terminals that currently receive a unique public address?
Is a PC connected to a WiFi hotspot "directly connected to the provider"?

Port range restriction should be, with relevant modifications, applicable to hosts. 

> 3) It still requires a separate IP address for each CPE 
> device behind the same provider PRR (for anyone who hasn't 
> read this draft, a PRR is what this draft has instead of a 
> CGN).  The CGN motivation generally comes from not having 
> enough IP space to number all CPEs.  A separate address 
> allows using private IP space (in addition to the shared 
> public IP), but if you have more customers than you have 
> private IP space, then you still cannot uniquely identify a 
> customer by IP address.  This will increase management 
> complexity and costs.

Right, however:
-Private IPv4 address overlapping is something many ISPs already do (for instance using VPNs)
-It depends on the number of clients with shared addresses
-A secondary IP address is just an example of implementation

> 4) If you don't have a separate IP address, but instead use 
> source routing as suggested, my understanding is that it 
> would be a huge performance hit due to slow-path forwarding 
> in many routers.

Agreed

> 5) The draft does not currently provide a solution to 
> customer-to-customer communication except when the customers 
> share a common next hop router and you put the PRR there (as 
> opposed to closer to the core).  And the solution it does 
> have again assumes modified CPE's that are not end hosts 
> (where this solution would break some apps).

The outgoing packets must pass through the PRR that handles the destination subnet, in order to select the route that corresponds to the (IP, port) CPE destination. 
This will be achieved depending on the routing topology.
It is possible to have a distant PRR (in terms of close to the core) using mechanisms such as tunnels, overlay, VPN,IS-IS-MT, OSPF-MT,...
We'll make it clearer in the next version.

> A marked up copy with more detailed comments is attached.

Please find attached your file with the authors' answers