Subject: RE: [Capwap] Support NAT..

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

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

-----Original Message-----
From: ArchanaSuresh [mailto:[email-masked]] 
Sent: Wednesday, March 01, 2006 10:24 AM
To: [email-masked]
Subject: [Capwap] Support NAT..

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

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

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

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 1 Mar 2006 09:07:02 -0800 (PST)

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