From: "Wang, Cliff" <[email-masked]>
Date: Thu, 24 Jan 2002 17:51:27 -0000

The real NATP issue is that in order to support NAT traversal, both the PAA
and NAT box need to be aware of the binding between the PANA client and
pre-NAT address. Based on that NAT can allow or deny NAT translation. If the
PANA client is authenticated, NAT will be allowed.

I don't see how port binding will work. The traffic from PANA client can use
any port. So is the NAT translated port. There could be multiple sessions at
the same time as well. Neither PANA nor NAT box has the capability to
control the binding between port(s) and client.

-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Thursday, January 24, 2002 10:06 AM
To: Hesham Soliman (ERA)
Cc: 'George Tsirtsis'; 'MORAND Lionel FTRD/DAC/ISS';
[email-masked]
Subject: Re: NA(P)T, Proxies and PANA

On Thu, Jan 24, 2002 at 02:46:58PM +0100, Hesham Soliman (ERA) wrote:
>   > Still in the context of *requirements* the current position of the
>   > requirements team is as follows. We have no language in the 
>   > requirements wrt
>   > NATs and yet we state nothing that would render a solution 
>   > that deals with
>   > NATs invalid. In other words we DO NOT place a requirement 
>   > for solutions to
>   > work over NAT but we do not disallow solution from doing so 
>   > either... and we
>   > currently think this is good enough. 
>   >
> 
> => I think this is fine, mandating NAT support is
> extreme IMHO. For IPv4 NATs, I definitely don't think
> we should mandate supporting them. This is a disease
> that should be cured by IPv6. As for NAT-PT, I don't 
> see real scenarios where NAT-PT would cause problems
> or require special consideration, but I might be 
> missing something. 
> 
> Hesham
> 

The following text is my personal understanding of PANA problem with NA(P)T,
which is copy-and-pasted from the internal mail discussion among the members
of the terminology/requirements team.

Note that the following may not apply to newer NAT-based technology 
such as "Real Specific IP".   

Yoshihiro Ohba

-------------------------------------------------
It is easy to make a binding for access control between IP address of a
device and the PANA client, since the IP address always appears in the
source IP address field of IP headers carrying PANA messages.  

On the other hand, it would be difficult to make a binding for access
control between port number (plus IP address) of a device and the PANA
client.  There are two reasons why it is difficult.

The first reason is that to make a binding between port 
number and the PANA client, the NAPT must have such a capability.

For instance, assume that there are two devices connected to 
a NAPT router with different PANA client IDs.

[email-masked]
    (device A)-----+
                   |
                   |
           [internal network]--(NAPT router)---(PAA)
                   |
[email-masked]  |
    (device B)-----+
                    
When a NAPT router receives a TCP SYN packet 
from a device with destination port number = 80 (http), how 
can the NAPT router distinguish 
which client the TCP SYN packet belongs to?  I think it is 
generally difficult.

The second reason is that to make a binding between port number and the PANA
client, the PAA must have such a capability, too.  To achieve this, PANA
client must have capability to inform the PAA of the mapping between the
port number and the client identifier either on demand (when a new TCP
connection request is received at NAPT router) or during the initial
authentication phase.  However, since the port number is translated at the
NAPT router, the PANA client behind the NAPT does not have a knowledge about
which port number is actually used at the ISP side.