Subject: RE: [Capwap] RE: One issue "In order to support NAT, I recommend thatLWAPP only support one UDP port for Control tunnel and Data Tunnel"

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Wed, 1 Mar 2006 09:46:53 -0500

David Hi,

To answer your two specific questions:
"what IP address would the STA's get, and where would their data be
terminated" - I would say that the STA will get local IP address (i.e.
from the private realm of the NAT), and data will be locally terminated
at the WTP.

The "BO scenario" drawn by Mike is exactly one (out of two) cases I
envisioned. I would even argue that Local MAC (option (1) - data traffic
is locally bridged) is the only realistic approach in this scenario as
overwhelming the WAN link with STA data seems awfully undesired vs. the
option of local bridging (BO might, and in most cases has, alternate
connections - local PSTN, and local Internet access).

The second scenario address a SP network with centralized AC to
customer's WTPs across a NAT device.

Might be useful if AC/WTP vendors on the list could enlighten the group
with respect to products deployment across NAT - if any.

Regards,
Emek

-----Original Message-----
From: Michael Montemurro [mailto:[email-masked]] 
Sent: Wednesday, March 01, 2006 9:11 AM
To: David T. Perkins; Scott G. Kelly
Cc: capwap
Subject: RE: [Capwap] RE: One issue "In order to support NAT, I
recommend thatLWAPP only support one UDP port for Control tunnel and
Data Tunnel"

David,

The scenario that I have observed where NAT traversal comes into play is
what I would call an enterprise branch scenario.

You have an AC that resides at the main office and a small remote branch
office. There is still a requirement for centralized control of the
wireless network. The operating mode of the WTP at the branch location
would likely be "Local MAC". 

All control traffic between the AC and the WTP would traverse the NAT.
There are two options for the data traffic:
1) The data traffic is bridged locally to the branch network. In this
case the STA would get an IP address on the LAN of the branch network.

2) The data traffic would traverse the WAN back to the AC. In this case
the STA would get an IP address on a network that AC lives on.

Cheers,

	Mike

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: February 28, 2006 5:44 PM
> To: Scott G. Kelly
> Cc: capwap
> Subject: Re: [Capwap] RE: One issue "In order to support NAT, I 
> recommend thatLWAPP only support one UDP port for Control tunnel and 
> Data Tunnel"
> 
> HI Emek,
> 
> Last time around the scenario that you described below was brought up,

> I believe I asked questions like, "what IP address would the STA's 
> get, and where would their data be terminated". I don't remember 
> seeing a response. If there is a single WTP behind a NAT in a 
> geographical area, I believe that using a CAPWAP system is 
> inappropriate. It would be more cost effective (for both hardware and 
> operations costs) to use a "stand alone AP".
> Also, I'm not sure if all CAPWAP ACs support multiple groups of 
> separately geograpically located WTPs. Note that since an AC is a 
> single point of failure, I certainly would not want to be in a 
> position as a service provider where I had multiple customers share 
> the same fate, unless the cost of the alternative was prohibative.
> I don't believe that this is the case.
> 
> I really do want to hear motivations, with the alternative listed, and

> the tradeoffs for each approach. I've listed some of the cons, can you

> list some of the pros?
> 
> Thanks,
> /david t. perkins
> 
> On Tue, 28 Feb 2006, Scott G. Kelly wrote:
> 
> > I, like David, wonder how realistic this concern might be. 
> In the first case described below (MSP's cloud-based AC manages 
> customer WTP), where does this WTP reside with respect to the 
> Internet? Wouldn't the provider need a secure tunnel to the customer 
> edge in such cases?  The alternative is unauthenticated tuple-based 
> firewall holes - not a pretty picture from a security perspective.
> > 
> > In the second case described below (NAT traversal within a
> single administrative domain), is this realistic? Seems more like an 
> abberation than a common case, and it seems clear that we don' t want 
> to add this level of complexity just so we can deal with an edge case.

> It seems like the operational issues with this topology would more 
> than out-weigh any benefit.
> > 
> > ----------------------------------------------------------------
> > From: Sadot, Emek (Emek) (esadotavaya.com)
> > Date: Tue, 28 Feb 2006 07:16:16 -0800 (PST)
> > 
> > David,
> > 
> > I was under the impression that the working group already
> went through
> > the "justification" process. To refresh our memory, I
> believe that the
> > key points that were brought up discussed the possibility that a 
> > service provider will connect their AC to their customer's
> WTPs across
> > a NAT device, or a cooperation which segments its facilities by NAT 
> > devices and deploy the AC at the main site and the WTPs at remote 
> > sites (private side of NAT), or perhaps a deployment
> scenario would be
> > some sort of a hosted solutions environment, where the WTPs in the 
> > different NAT'ed customer enterprise sites are controlled
> by a central
> > AC which is part of the provider's hosted solutions equipment.
> > 
> > My belief is that the CAPWAP protocol should not disallow the NAT 
> > traversal.
> > 
> > Regards,
> > Emek
> > 
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins [at] dsperkins.com]
> > Sent: Monday, February 27, 2006 10:21 PM
> > To: zhaoyujin 31390
> > Cc: capwap [at] frascone.com
> > Subject: Re: [Capwap] One issue "In order to support NAT, I
> recommend
> > thatLWAPP only support one UDP port for Control tunnel and
> Data Tunnel"
> > 
> > HI,
> > 
> > CAPWAP with NATs has come up from time to time on this list, and 
> > people have claimed that it is a "typical" or "basic"
> > scenario. I'm sorry, but I don't see it. Before the WG spends time 
> > resolving this issue, I'd really like to see STRONG justifications.
> > That is, why would you deploy a CAPWAP system split this
> way? And if
> > CAPWAP didn't support this NAT split, what would it cost
> you, or what
> > would you not be able to do?
> > 
> > On Mon, 27 Feb 2006, zhaoyujin 31390 wrote:
> > > 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
> > 
> > Regards,
> > /david t. perkins
> > 
> > 
> > _________________________________________________________________
> > 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

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

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