Subject: RE: [Capwap] NAT traversal objective - take II

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Wed, 15 Jun 2005 17:29:19 -0400

Pat,

Let me start by saying that my initial concern was related to WTP being
deployed at the private sector of a NAT device in oppose to the AC, but
I believe we should exercises caution when ruling out the latter,
especially with regard to the motivation you provided which outlined
protocol implementation issue rather then addressing the question:
whether or not "AC behind NAT" is a feasible configuration.

On a (partly) different note: I would appreciate if you could elaborate
(though I acknowledge it's not tightly coupled with the CAPWAP protocol)
how an AC(s) suppose to learn the IP address of the other device(s) to
which user's data traffic should be tunneled by the WTP? what purpose
such devices serves? and if several entities exists in a system how an
AC determine to which one to directed the user's data traffic of "its"
WTPs?

Regards,
Emek

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]] 
Sent: Tuesday, June 14, 2005 3:22 PM
To: Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] NAT traversal objective - take II

Having thought about this some more, it appears that the requirements
for NAT conflict with the desire to split the control and the data path.

While I agree that a WTP can be behind a NAT, I don't believe that an AC
can. The reason being that in order to achieve the control/data path
split objective, where data goes to one device and control goes to
another, it is required that the protocol allows the AC to communicate
the data path IP address - and the inclusion of such an IP address in
the protocol implicitely breaks NAT traversal.

So I would disagree with requiring that an AC can be behind a NAT.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
> Sent: Monday, June 13, 2005 11:05 AM
> To: [email-masked]
> Subject: [Capwap] NAT traversal objective - take II
> 
> I would like to propose adding below NAT traversal requirement 
> following the last thread on the subject.
> 
> 
> Classification: Architecture
>  
> Description:
> The CAPWAP protocol doesn't pose any restriction on the environment 
> where the AC and the WTP will be deployed and which devices facilitate

> communication between the two.
> Therefore traversing NAT device cannot be ruled out and the CAPWAP 
> protocol should be robusted against such a scenario.
> 
> Protocol Requirement:
> CAPWAP protocol shall accommodate NAT traversal scenario and in 
> particular allow NAT device to manipulate layer 4 ports, take into 
> consideration symmetric NAT behavior (allowing access from the public 
> side only after session establish from the private side) and avoid 
> peer identification based on entity (e.g. WTP, AC) IP addresses.
> 
> Motivation and Protocol Benefits:
> Independence of WTP and AC on intermediate devices and extending 
> deployment topologies and variance. A service provider connecting 
> their AC to their customer's WTP across a NAT device is an example of 
> potential deployment scenario.
> 
> Relation to Problem Statement:
> This requirement is based on WG discussions that have determined to be

> important for CAPWAP.
> 
> 
> Emek
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap