Re: How to include APBP scenarios in the Coexistence RequirementI-D

[Rémi Després <remi.despres@free.fr>]

Alain Durand  - Le 7/17/08 5:02 PM :

> The service provider still has to run the port mapping part of the CGN, the
> only advantage I see is to avoid back-hauling the data traffic to the CGN.

Actually, this may not be the case, depending on how far away a customer 
site finds its APBP servers.

But there are other advantages, among which:
- less processing in ISP devices (essentially encap-decap vs ALGs).
- As pointed out by Dan, specific ALGs in CPE routers, that users are 
familiar with, remain in operation.


> More importantly, you introduce a whole bunch of new issues. In random
> order:
> - You need to put filtering in place on the ISP access router to make sure
> the customer is only using the allocated port numbers. This list needs to be
> in sync with the port number allocation system.

In the APBP server, yes, but NOT in the ISP access router.

Testing that a number is in a given range is not difficult.

It may even not be necessary if the CPE is manged by the ISP.

> - The same access router now need to do port base routing to return the
> packets to the customer. This is not without cost.

NO (E2E packets are encapsulated between APBP clients and servers).

> - Allocating chunks of port number is not the most efficient allocation
> algorithm. If a customers does nothing or just use one port number, you are
> wasting a lot of resources.

Wasting SOME resource, yes indeed, but "a lot" is debatable.

To take an example, if each residential customer receives 512 ports, 
then 126 customer sites can be supported per public IPv4 address.

As noted in the draft, a sparing use of these 512 ports is possible: 
"In APBP clients, port management may be optimized so as to increase the 
number of transport connections that are possible with a given number of 
ports. In particular, port reuse based on endpoint dependent mappings 
may be envisaged for ports that are  assigned to outgoing transport 
connections known not to need endpoint independent mapping (DNS, HTTP, 
SMTP, POP3, NNTP, Telnet, SNMP, etc.)."

IMU, CGNs would also enforce a maximum number of connections per 
customer site to avoid DOS attacks. They would be able to overbook, 
right, but do you know with which factor (a factor of 1 keeps things 
simple).

> - Timing out those port number is a bit of a mess, both the apps, the home
> gateway, the access router and the port allocation system need to be synced
> up.

I don't see that.

Once a customer site has received its lot, it keeps it until it rests 
with no active connection, and then releases its lot (or until, being 
turned off, it  no longer sends its keep-alives).


> - All kind of security measure need to be put in place to prevent customers
> to hoard the port number space.

IMU, it is sufficient to check in the APBP server that used ports are, 
for each customer site, in its assigned range.


> In other words, the complexity you create by distributing the mapping
> mechanism seems high. It seem to me a better trade-off to centralize this in
> a CGN. Please note that an ISP does not need to run only one CGN and can
> distribute those as well close to its network edge, but no closer.

IMU, APBP servers and CGNs can be put at the same places, centralized or 
not, as traffic engineering preferences of ISPs tell.


> Note: the route you are on seems to lead to IPv7 (ask ekr about it)

I don't see this.

But OK, I can ask ekr if you tell me how to do it.

> you augment the IPv4 addressing space with the port number space for
> routing. You might have seen the T-shirt 32+16 > 128.

I was not aware to be that smart, but that seems nice a result :-).


Cheers.

RD