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

[Alain Durand <[e-mail]>]

Rémi,

I have some fundamental objections to the APBP proposal.

What is does is replace the carrier grade nat (CGN) by a distributed system
of home gateways that are allocated chunks of port numbers.
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.

You still have most if the issue with CGN, which are mainly customer apps
cannot expect to run on their own, well know, port number.

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.
- The same access router now need to do port base routing to return the
packets to the customer. This is not without cost.
- 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.
- 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.
- All kind of security measure need to be put in place to prevent customers
to hoard the port number space.

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.

Note: the route you are on seems to lead to IPv7 (ask ekr about it), where
you augment the IPv4 addressing space with the port number space for
routing. You might have seen the T-shirt 32+16 > 128.

   - Alain.


On 7/17/08 5:44 AM, "Rémi Després" <[e-mail]> wrote:

> Dan Wing  - Le 7/16/08 8:03 PM :
> 
>> I noticed all of the current proposals (SNAT, NAT64, NAT6, IVI,
>> dual-stack-lite, etc.) are quiet on a significant aspect of a requirement
>> that
>> is important:  keeping existing games and existing applications working.  I
>> am
>> thinking of game boxes like Microsoft's Xbox that need UPnP IGD in order to
>> function properly over the Internet, and applications such as Microsoft
>> Netmeeting (needs an H.323 ALG in the NAT), Quicktime and RealAudio streaming
>> (RTSP), and so on.  http://tools.ietf.org/html/rfc3027 does a good job of
>> explaining the specifics.
> 
> Thanks, a very useful RFC.
> 
> 
> 
>> Here is some beautiful ASCII art diagrams of the difference between today's
>> UPnP IGD (and NAT-PMP) and what I am suggesting is useful (and necessary) for
>> tomorrow's APBP in conjunction with UPnP IGD and NAT-PMP:
> 
> In the new APBP draft
> (http://tools.ietf.org/html/draft-despres-v6ops-apbp-01), an APBP client
> obtains in one request a public IPv4 address and a range of ports to go
> with it.
> An APBP message to the APBP server is then not necessary for each
> UPnP... packet, and independent outgoing connections will have the same
> public IPv4 source adress, IMO an important progress.
> 
> Here is a proposed revision of your ASCII art:
> 
> +-----------------+
> |incoming UPnP IGD|
> |or NAT-PMP packet|
> +----+------------+
>       |
>       V
> +-------------+          +===============================+
> |  need new   |-----YES->|If needed, Send an APBP Request|
> |NAT binding? |          |   Then create NAT binding     |
> +----+--------+          |using the obtained IPv4 address|
>       |                   | and a free port in its range  |
>       NO                  +===============================+
>       |                             |
>       V                             |
> +----+---------------+             |
> |respond to UPnP IGD |<------------+
> |or NAT-PMP request  |
> +----+---------------+
> 
> 
> 
> 
> Once an APBP client has obtained a range of ports with an address, it
> can operate as though it would have an exclusive v4 address, except that
> it has less than 64K ports to go with it, and no port in the < 1024 range.
> - Of course, this is still a significant restriction but, IMU, CGNs
> won't do better.
> - To be reachable on a well-known port, in a site that has an IPv6
> prefix and no public IPv4 address, applications should better be
> reachable in IPv6.
> 
> 
> Regards.
> 
> RD
>