Subject: [Capwap] Support NAT..

From: ArchanaSuresh <[email-masked]>
Date: Wed, 01 Mar 2006 20:53:33 +0530

Hi All,

Considering we use two separate ports for control tunnel and 2 APs are
behind the NAT.

Cp - lwapp control port & Dp - lwapp data port
Ip1, Ip2, Ip3 - local IP address at AP1 , AC, NAT device respectively 
Np1, Np2, - New ports used on NAT

When a Ctrl packet goes from AP1 to AC.
	Src <Ip1,Cp> --- Dst <Ip2,Cp>
NAT binding for  <Ip1,Cp>
	Src <Ip3,Np1> --- Dst <Ip2,Cp>
At the AC
The AP1 identifier is <Ip3, Np1>  

When a Data packet goes from AP1 to AC.
	Src <Ip1, Dp> --- Dst <Ip2, Dp>
NAT binding to  <Ip1, Dp>
		Src <Ip3,Np2> --- Dst <Ip2, Dp>
At the AC
	The AP1 identifier is <Ip3, Np2>  

Question 1:
How will AC understand the source tuple  for AP1's data packet 
<Ip3, Np1>  is the same for <Ip3, Np2>  ??
How/When should AC relate these two to belong to AP1 ?

Question 2:
What happens in a case when a data packet first needs to go from the AC to
AP1.
There is no nat entry for the data path as yet.

Regards,
Archana Suresh

-----Original Message-----
From: zhaoyujin 31390 [mailto:[email-masked]] 
Sent: Monday, February 27, 2006 10:29 AM
To: [email-masked]
Subject: [Capwap] One issue "In order to support NAT, I recommend that LWAPP
only support one UDP port for Control tunnel and Data Tunnel"

Dear all:

  I recommend that LWAPP only support one UDP port for Control tunnel and
Data Tunnel. 

  LWAPP protocol uses UDP packets, so that it can directly support NAT
passthrough.

  One basic scenario is that WTP is behind NAT device and AC is in public
network. For control tunnel, there are no problem. Because it is initiated
by WTP, NAT device can create corresponding table for LWAPP control tunnel
packets. 

  The problems is:

   1. The data packets can not be firstly sent from AC to WTP.

   2. Even if WTP firstly sends pacekts, AC can get the corresponding
control tunnel with this LWAPP data tunnel based on the packets.  Because in
one NAT device, there may be multiple WTP. All WTP's IP addresses are same
which is NAT device global IP address, and AC can not know the data packets
belonging to which AP.

Best regards
Yujin Zhao
H3Com

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Wed, 1 Mar 2006 15:10:05 -0500

David Hi,

Forcing an Enterprise customer strive for centralized WLAN architecture
to place an AC at each branch office, or for that matter placing AC at
each Service Provider customer is IMHO more then a bit problematic.

Your 4 points pertain to control functionalities (vs. data), thus
latency, jitter, packet drop, etc. is probably a non-issue with a remote
AC, though fast roaming might need a special consideration.

A separate geographic areas might be a valuable notion, although I'm not
sure I see the difference between remote site (WTP behind NAT) and
different floors, buildings, etc. at the same geographical domain, thus
the same NAT side, as the AC.

I'm not religious. If the group feels that supporting NAT traversal is
pointless - then let's please hear it.

Regards,
Emek 

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]] 
Sent: Wednesday, March 01, 2006 12:07 PM
To: Sadot, Emek (Emek)
Cc: ArchanaSuresh; [email-masked]
Subject: RE: [Capwap] Support NAT..

HI,

It looks like progress is being made on some of the technical issues,
but no one has yet addressed the alternative of placing an AC on the
same side of the NAT as the WTPs.

The CAPWAP protocol includes:
 1) AC discovery,
 2) WTP system image transfer from the AC to the WTP
 3) STA authentication and authorization at the AC
 4) roaming of STAs from one WTP to another (in real time
    if you want to support Voice over 802.11)

Will you have the needed bandwidth, latency, jitter, and packet drop
characteristics if ACs and WTPs are configured as described in the
previous messages on this thread?

Also, unless I've missed it, the current version of the CAPWAP protocol
does not have the capability of indicating that groups of WTPs are in
separate geographic areas (lets call them, "a WiFi cloud"). It is
desirable that an AC coordinate the WTPs in a WiFi cloud so that
compatable channel and power configurations are made and these be
updated as conditions change.
And in follow-on versions of CAPWAP, that compatable rogue detection and
countermeasures be applied to WiFi clouds. 

It really seems like the scenarios described on this thread are NOT
CAPWAP technology, but instead are coordinated standalone APs.

Finally, I do believe that this discussion is productive, and I believe
that we need to have more of it with written findings before trying to
go forward with finalizing the CAPWAP proto document.
I suggest that we have a "terminology and scenario"
session on Sunday afternoon and/or evening at the start of the IETF
conference.

Regards,
/david t. perkins

On Wed, 1 Mar 2006, Sadot, Emek (Emek) wrote:
> I think the answer you are looking for in (1) is that the AC must 
> refrain from uniquely identified the WTP by the IP and Port pair. WTP 
> shall be uniquely identified by - MAC address, serial number for 
> example
> - and the AC shall map the control session and data sessions 5-tuples 
> to that identifier.
> 
> The WTP shall send (dummy) packet on behalf of a STA to the AC with 
> its unique identifier to allow the AC to identify the WTP and sets up 
> WTP 5-tuple to identifier mapping. Note, that until such mapping is 
> established, downstream data packets cannot reach their destination.
> 
> Regards,
> Emek
> 
> From: ArchanaSuresh [mailto:[email-masked]]
> Sent: Wednesday, March 01, 2006 10:24 AM
> To: [email-masked]
> Subject: [Capwap] Support NAT..
> 
> Hi All,
> 

> behind the NAT.
> 
> Cp - lwapp control port & Dp - lwapp data port Ip1, Ip2, Ip3 - local 
> IP address at AP1 , AC, NAT device respectively Np1, Np2, - New ports 
> used on NAT
> 
> How will AC understand the source tuple  for AP1's data packet <Ip3,
> Np1>  is the same for <Ip3, Np2>  ??
> What happens in a case when a data packet first needs to go from the 
> AC to AP1.
> Subject: [Capwap] One issue "In order to support NAT, I recommend that

> LWAPP only support one UDP port for Control tunnel and Data Tunnel"
> 
> Dear all:
> 
>   I recommend that LWAPP only support one UDP port for Control tunnel 
> and Data Tunnel.
> 

> passthrough.
> 
>   One basic scenario is that WTP is behind NAT device and AC is in 
> public network. For control tunnel, there are no problem. Because it 
> is initiated by WTP, NAT device can create corresponding table for 
> LWAPP control tunnel packets.
> 
>   The problems is:
> 
> control tunnel with this LWAPP data tunnel based on the packets.
> Because in one NAT device, there may be multiple WTP. All WTP's IP 
> addresses are same which is NAT device global IP address, and AC can 
> not know the data packets belonging to which AP.
> 
> 
> Best regards
> Yujin Zhao
> H3Com
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 4 Mar 2006 15:26:16 -0800

I, and my customers, feel that NAT traversal is mandatory. No, there are
some customers that do not have VPNs, but these deployments do typically
perform local bridging, so latency, jitter (and such) does not affect
the quality of the service delivered. If local bridging is performed,
the STA is assigned an IP address in the branch office. If tunneling is
mandatory, then the STA is assigned an IP address on a subnet accessible
by the AC.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> From: Sadot, Emek (Emek) [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 12:10 PM
> To: David T. Perkins
> Cc: [email-masked]
> Forcing an Enterprise customer strive for centralized WLAN 
> architecture to place an AC at each branch office, or for 
> that matter placing AC at each Service Provider customer is 
> IMHO more then a bit problematic.
> 
> Your 4 points pertain to control functionalities (vs. data), 
> thus latency, jitter, packet drop, etc. is probably a 
> non-issue with a remote AC, though fast roaming might need a 
> special consideration.
> 
> A separate geographic areas might be a valuable notion, 
> although I'm not sure I see the difference between remote 
> site (WTP behind NAT) and different floors, buildings, etc. 
> at the same geographical domain, thus the same NAT side, as the AC.
> 
> I'm not religious. If the group feels that supporting NAT 
> traversal is pointless - then let's please hear it.
> 
> Regards,
> Emek 
> 
> It looks like progress is being made on some of the technical 
> issues, but no one has yet addressed the alternative of 
> placing an AC on the same side of the NAT as the WTPs.
> 
> Will you have the needed bandwidth, latency, jitter, and 
> packet drop characteristics if ACs and WTPs are configured as 
> described in the previous messages on this thread?
> 
> Also, unless I've missed it, the current version of the 
> CAPWAP protocol does not have the capability of indicating 
> that groups of WTPs are in separate geographic areas (lets 
> call them, "a WiFi cloud"). It is desirable that an AC 
> coordinate the WTPs in a WiFi cloud so that compatable 
> channel and power configurations are made and these be 
> And in follow-on versions of CAPWAP, that compatable rogue 
> detection and countermeasures be applied to WiFi clouds. 
> 
> It really seems like the scenarios described on this thread 
> are NOT CAPWAP technology, but instead are coordinated standalone APs.
> 
> Finally, I do believe that this discussion is productive, and 
> I believe that we need to have more of it with written 
> findings before trying to go forward with finalizing the 
> CAPWAP proto document.
> session on Sunday afternoon and/or evening at the start of 
> the IETF conference.
> 
> Regards,
> /david t. perkins
>