Subject: RE: NA(P)T, Proxies and PANA

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 24 Jan 2002 14:46:58 +0100

> 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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 24 Jan 2002 10:06:03 -0500

> or require special consideration, but I might be 

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.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 24 Jan 2002 14:08:23 -0800

> that should be cured by IPv6. As for NAT-PT, I don't 

I agree with Hesham. Shall we have a "NAT considerations"
section in every end2end protocol design? Do we have
to complicate every new protocol to make it work accross
a NAT box? I hope not! :)

One possibility is that in the final PANA the PAA is
the first hop router, and then NAT is not an issue at all.

alper