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

From: Rémi Després <[email-masked]>
Date: Fri, 11 Jul 2008 15:43:02 +0200

Marcello.

However strange it may seem, I now put the APBP approach in stanby, 
probably to finally simply give it up.

Reasons:
- The tunnel-to-NAT44 approach is IMHO so advanced, and probably "good 
enough", so that the work on APBP, even if pertinent, would arrive too late.
- Some server applications are reported to require that related TCP 
connections do have the same client IP address. This conflicts with the 
possible load balancing between several APBP servers, one of their nice 
scalability features.
- Some of the underlying concepts of APBP may be better applied in a 
different context (a combination of multi-homing and IPv6 private 
addressing, but this is another story, not related to your draft).

I therefore no longer suggest that having APBP mentioned in your next 
version(s) is desirable.

In any case thanks for your openness to reflect received comments on it.

Regards.

Rémi

marcelo bagnulo braun  - Le 6/19/08 7:59 PM :
> In the next version, i will try to reflect the received comments indeed

> Rémi Després escribió:

>> Please remember what Teemu Savolainen wrote to you in
>> http://psg.com/lists/v6ops/v6ops.2008/msg00800.html

>> Also you can note what Brian Carpenter answered to Iljitsch van 
>> Beijnum, in 
>> http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00876.html

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 Jul 2008 18:54:48 +0200

Following some privatly received comments of Dan Wing, the standby phase 
hasn't be long, and the idea to possibly give up APBP stands no longer !

I just posted draft-01,  with  I believe  substantial simplifications 
and improved applicability.

Sorry for the one more change.

Rémi

Rémi Després  - Le 7/11/08 3:43 PM :
> connections do have the same client IP address. This conflicts with 
> the possible load balancing between several APBP servers, one of their 
> nice scalability features.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Jul 2008 11:03:10 -0700

> Following some privatly received comments of Dan Wing, the 
> standby phase hasn't be long, and the idea to possibly give up 
> APBP stands no longer !
> 

Allow me to elaborate a bit on our offline discussion over the weekend.

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.

A protocol which meets the requirements of APBP would allow UPnP IGD, NAT-PMP,
and appropriate ALGs to be in the subscriber-side CPE box, and allow using
APBP to the carrier-owned NAT64/NAT44 box to obtain a real, publicly-routable
v4 transport address.  That publicly-routable v45 transport address would then
be used by the subscriber-side CPE in exactly the same way that today's
subscriber-side CPE uses its own WAN transport address for the same functions.
For UPnP IGD, the availability of APBP means a host that performs the UPnP
getPublicIPAddress() API call would get a publicly-routable v4 transport
address.  Without APBP, a host performing that same function call would not
get a v4 address at all.

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:

Today's UPnP IGD and NAT-PMP function at a high level:

+-----------------+
|incoming UPnP IGD|
|or NAT-PMP packet|
+----+------------+
     |
     V
+-------------+          +-----------------------+
|  need new   |-----YES->| create NAT binding    |
|NAT binding? |          |using NAT's WAN address|
+----+--------+          +---------+-------------+
     |                             |
     NO                            |
     |                             |
     V                             |
+----+---------------+             |
|respond to UPnP IGD |<------------+
|or NAT-PMP request  |
+----+---------------+

Change to UPnP IGD or NAT-PMP function inside of the subscriber NAT
(difference highlighted with "=" and capital letters):

+-----------------+
|incoming UPnP IGD|
|or NAT-PMP packet|
+----+------------+
     |
     V
+-------------+          +=========================+
|  need new   |-----YES->| SEND "APBP" MESSAGE     |
|NAT binding? |          | TOWARDS SP'S CARRIER NAT|
+----+--------+          +=========+===============+
     |                             |
     NO                            |
     |                             |
     V                             |
+----+---------------+             |
|respond to UPnP IGD |<------------+
|or NAT-PMP request  |
+----+---------------+

-d

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 16 Jul 2008 16:50:04 -0400

Dan,

Because there is only one level of NAT in dual-stack lite, couldn't this be
simplified by asking the dual-stack lite home gateway to forward the UPnP
message to the dual-stack lite carrier-grade NAT?

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Wed, 16 Jul 2008 17:19:25 -0400

But, of course, all this has to be balanced with the security (or lack
thereof) of UPnP...

  - Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Jul 2008 14:32:49 -0700

> -----Original Message-----
> From: Durand, Alain [mailto:[email-masked]] 
> Sent: Wednesday, July 16, 2008 1:50 PM
> To: Dan Wing; Rémi Després; marcelo bagnulo braun
> Cc: v6ops
> Subject: Re: How to include APBP scenarios in the Coexistence 
> RequirementI-D
> 
> Dan,
> 

Yes, UPnP IGD could be considered a candidate protocol to meet
the needs of an address-port-borrowing-protocol.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Jul 2008 14:45:38 -0700

> From: Alain Durand [mailto:[email-masked]] 
> Sent: Wednesday, July 16, 2008 2:19 PM
> To: Alain Durand; Dan Wing; Rémi Després; marcelo bagnulo braun
> Cc: v6ops

A requirement of any APBP is that a subscriber could only open ports
for their own IP address -- not their neighbor's IP address.

-d

> >> 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
> >> A protocol which meets the requirements of APBP would 
> allow UPnP IGD,
> >> NAT-PMP,
> >> v4 transport address.  That publicly-routable v45 
> transport address would
> >> then

---

From: David Miles <[email-masked]>
Date: Thu, 17 Jul 2008 08:56:24 +1000

I just want to add a consideration or two for UPnP and NAT-PMP  
operation in a an environment where many households will share a  
single IPv4 address.

As I understand, UPnP does not have a mechanism to request a anonymous  
(or IGD/NAT-assigned port) whereas NAT-PMP does.

In UPnP, the ExternalPort may request a wildcard mapping which  
indicates all unused ports should be listened to (DMZ operation), but  
provides no facility to request an external port be assigned and  
notify the UPnP client of its value. Consider a theoretical game  
supports any high-port, in UPnP the client must request a mapping and  
specify the external port. If the port-number can be any value it is  
reasonable to assume a random function should find a free port within  
a few AddPortMapping requests.

NAT-PMP works differently, and does support the assignment of a high- 
numbered port of the NAT devices choosing (as it always responds to a  
mapping request with the Mapped External Port value).

Without having firsthand experience I understand some applications,  
such as Xbox Live, request/require specific ports to be opened -  
something that is impractical when many households share the same IP  
address. Point being that each application would need to support a NAT- 
assigned (or at least randomise the request for an) external port. I  
realise that it is no different from having multiple clients in a  
single household but it may present an issue in some cases. Also, I am  
not sure it is a good idea to allow external ports to be < 1024 for  
port mappings (which invariably have a liftetime) because of the  
potential for impersonation or interception of traffic. Restricting  
port mappings to only high-ports may also impact some applications.

All of these considerations leave me in two minds: do we go to the  
effort of inter-working UPnP/NAT-PMP with the invariable NAPT that  
must occur somewhere in the network accepting it will help some apps  
and not others; or, do we accept there are alternative methods for  
NAPT traversal and hole-punching that that do not require explicit  
signalling? If an application needs to be adapted to support either  
environment, perhaps the developers could include IPv6 transport and  
solve our problem.

Does anyone have experience with UPnP and multiple devices/apps behind  
the same IGD, and the external port numbers they request?

Regards,

-David

On 17/07/2008, at 7:19 AM, Alain Durand wrote:

>>> 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
>>> A protocol which meets the requirements of APBP would allow UPnP  
>>> IGD,
>>> NAT-PMP,
>>> v4 transport address.  That publicly-routable v45 transport  
>>> address would
>>> then

---

From: [email-masked]
Date: Thu, 17 Jul 2008 03:10:40 -0600

> explaining the specifics. 

As much as I hate discussions about NAT in context of IPv6, a good draft to 
look at is http://tools.ietf.org/html/draft-jennings-behave-nat6-00

---

From: Rémi Després <[email-masked]>
Date: Thu, 17 Jul 2008 11:44:35 +0200

> explaining the specifics.

Thanks, a very useful RFC.

> 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

---

From: Alain Durand <[email-masked]>
Date: Thu, 17 Jul 2008 11:02:19 -0400

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.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Jul 2008 08:15:33 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, July 17, 2008 2:11 AM
> To: Dan Wing
> Cc: 'Rémi Després'; 'marcelo bagnulo braun'; 'v6ops'
> applications working.  I am

I attempted to kick off a discussion of that draft on Behave.
I would certainly like to see more discussion of it.

-d

---

From: Rémi Després <[email-masked]>
Date: Thu, 17 Jul 2008 18:12:17 +0200

> 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.

> 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.

> packets to the customer. This is not without cost.

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

> 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).

> gateway, the access router and the port allocation system need to be synced

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).

> 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.

> 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.

> 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