Subject: RE: [Capwap] NAT traversal

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 10 Jun 2005 10:47:29 -0600

Speaking as a member of the WG:

It would be preferable to have the NAT problem scenarios articulated in
a draft - so we have a distinct record of possible problem scenario(s).
While this may not turn out to be a work item - inasmuch as it happens
to be one of the possible provider and/or (extended) enterprise
deployment scenarios - it would be unfair to let it go unaddressed. 

The protocol (and the WG) is aimed to help solve the primary pain-points
of managing large WLAN deployments - and avoid creating additional ones
along the way if we can help it (that should be a generic objective as
well :)).

Some deployments may be able to address this by way of distributed
(cooperating) AC instances. However, that may not be the normal case.

Providers and large enterprise IT-admins on the list should speak up on
this.

-mani
======
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Darren Loher
Sent: Friday, June 10, 2005 9:33 AM
To: Sadot, Emek (Emek); David T. Perkins
Cc: Pat Calhoun; Cheng Hong; [email-masked]
Subject: RE: [Capwap] NAT traversal

I am starting to think we should leave the NAT issue open to
implementers.  We could say, "The CAPWAP protocol SHOULD minimally
support WTP's which are behind a symmetric NAT.  The CAPWAP protocol MAY
operate over additional forms of NAT."

The details of how and if this requirement is satisfied should be left
to the CAPWAP protocol.  I would certainly give preference to a protocol
which solved at least the minimal case of a WTP's behind symmetric NAT
as in David Perkin's diagram.

Also regarding problem #5 below, I think this issue would likely be
addressed with the discovery and connection management of the CAPWAP
protocol.  The working group has already agreed that discovery
mechanisms are out of scope of CAPWAP, so we should not write in what
are discovery through NAT requirement.  

-Darren

> -----Original Message-----
> From: Sadot, Emek (Emek) [mailto:[email-masked]]
> Sent: Thursday, June 09, 2005 9:27 PM
> To: David T. Perkins; Darren Loher
> Cc: Pat Calhoun; Cheng Hong; [email-masked]
> Subject: RE: [Capwap] NAT traversal
> 
> David,
> 
> Excellent diagram. Respectfully I would avoid naming "Internet" as NAT
> device can segregate Enterprise's internal segments. A second WTP in
the
> private domain (10.1.2.2) may be helpful as well.
> 
> A few problems presented by a NAT device:
> 1. NAT manipulate layer 4 ports -> CAPWAP protocol cannot be layer 3
> protocol based.
> 2. Symmetric NAT will drop AC communicating with the WTP unless the
WTP
> initiate the communication first.
> 3. WTP unique identification at the AC must not by WTP's IP address
(and
> port) based.
> 4. WTP to AC CAPWAP session must be refreshed at the NAT device.
> 5. CAPWAP protocol shall be immunized against NAT device crash. More
> specifically, since session mapping will be erased at the NAT device
the
> WTP (in contrast to the AC) must send CAPWAP to resume communication.
> 
> Emek
> 
> 
> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Thursday, June 09, 2005 8:20 PM
> To: Darren Loher
> Cc: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); [email-masked]
> Subject: RE: [Capwap] NAT traversal
> 
> HI Darren & Pat,
> 
> I'm still having a problem understanding what you are trying
> to accomplish.
> 
> Here is a picture....
> 
> 
>   /------------\   209.128.82.1   10.1.1.1 /---------------\
>  |             |           ----------     |                 |
>  | Internet    |-----------|NAT box |-----|Private Network  |
>  |             |---        ----------     |(say 10.1.1.0/16)|
>   \-----------/    \                       \---------------/
>        |            \                        |
>        AC            \                      WTP     STA-IP=?
>    209.128.82.62      \                  10.1.2.1
>                        \                   /---------------\
>                         \  ----------     |                 |
>                          --|NAT box |-----|Private Network  |
>                            ----------     |(say 10.1.1.0/16)|
>                    209.128.82.2  10.1.1.1  \---------------/
>                                              |
>                                             WTP    STA-IP=?
>                                          10.1.2.1
> 
>                            More NAT boxes
> 
> Is this what you are talking about? And If so, tell me again
> what problem are you trying to solve, or service that you
> are wanting to provide?
> 
> Regards,
> /david t. perkins
> 
> On Thu, 9 Jun 2005, Darren Loher wrote:
> > On the requirements side for NAT, should we specify if the WTP is
> behind
> > NAT, the AC behind NAT or both?  I can see two basic scenarios
> > realistically being implemented:
> >
> >
> >
> > Assume:
> >
> > - Hotspot provider uses whatever available broadband connection as
an
> > Internet uplink
> >
> > -This connection is limited to one, dynamically assigned IP address
> >
> > -NAT is required to share the connection with multiple hosts
> >
> >
> >
> > Scenario 1: The hotspot provider's AC is on the open Internet
> >
> > Scenario 2: The hotspot provider's AC is behind a NAT firewall and
the
> > hotspot provider has port forwarding and/or static NAT control of
this
> > firewall
> >
> >
> >
> > There could be several more, but these seem very common and
> > straightforward.
> >
> >
> >
> > -Darren
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: [email-masked] [mailto:[email-masked]]
On
> > Behalf Of Pat Calhoun
> > Sent: Thursday, June 09, 2005 7:19 AM
> > To: 'Cheng Hong'; 'Sadot, Emek (Emek)'; [email-masked]
> > Subject: RE: [Capwap] NAT traversal
> >
> >
> >
> > Imagine a service provider connecting their AC to their customer's
> WTPs
> > across a NAT. Makes sense to me.
> >
> >
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 	From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Cheng Hong
> > 	Sent: Thursday, June 09, 2005 12:52 AM
> > 	To: Sadot, Emek (Emek); [email-masked]
> > 	Subject: RE: [Capwap] NAT traversal
> >
> > 	Hi Emek,
> >
> >
> >
> > 	Would like to know a bit more about the deployment examples:
> >
> >
> >
> > 	>>say the WTP is located at branch office and the AC at the main
> > office separated by NAT device
> >
> >
> >
> > 	In this case, most likely the NAT traversal is not a problem for
> > the WTP or AC directly. For the branch office and main office case,
> most
> > likely there will be a VPN setup between them. To the WTP and AC,
NAT
> > will be transparent.
> >
> >
> >
> > 	 >>or within an Enterprise segregated by NAT devices.
> >
> >
> >
> > 	Does this mean AC and WTP are on different side of the NAT? It
> > sounds interesting, but is there any reason for deploy it in such a
> way
> > (A NAT inside the enterprise network to separate the AC and WTP)?
> >
> >
> >
> > 	cheers
> >
> >
> >
> > 	Cheng Hong
> >
> >
> >
> >
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 		From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
> > 		Sent: Wednesday, June 08, 2005 4:27 AM
> > 		To: [email-masked]
> > 		Subject: [Capwap] NAT traversal
> >
> > 		All,
> >
> >
> >
> > 		Would like to suggest adding a NAT traversal requirement
> > to the CAPWAP objective document, i.e. the ability of AC and WTP to
> > communicate across NAT device (UDP / TCP transport, refresh CAPWAP
> > session at the NAT device, WTP identification behind NAT device,
> etc.).
> > Deployment examples? say the WTP is located at branch office and the
> AC
> > at the main office separated by NAT device, or within an Enterprise
> > segregated by NAT devices.
> >
> >
> >
> > 		Regards,
> >
> > 		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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 10 Jun 2005 10:03:48 -0700

I think there might be some cases where the AC and WTPs might be on
different sides of a NAT, but I think the most likely scenarios are fairly
limited.

I'm wondering if the CAPWAP protocol itself needs to support NATs or if it
might be possible to include NAT support in a separate document, such as
SIP/STUN and Mobile IP did? It might make the base protocol simplier. In
addition, if CAPWAP supports IPv6 (will it?) and everyone's hopes actually
become reality and IPv6 networks don't have NATs, then having a simplier
base protocol could make IPv6 deployments simplier.

            jak

----- Original Message ----- 
From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
To: "Darren Loher" <[email-masked]>; "Sadot, Emek (Emek)"
<[email-masked]>; "David T. Perkins" <[email-masked]>
Cc: "Pat Calhoun" <[email-masked]>; "Cheng Hong"
<[email-masked]>; <[email-masked]>
Sent: Friday, June 10, 2005 9:47 AM
Subject: RE: [Capwap] NAT traversal

-mani
======
-----Original Message-----

-Darren

the
WTP
(and
the
an
the
this
On
NAT

---

From: Suresh Satapati <[email-masked]>
Date: Mon, 13 Jun 2005 09:50:55 -0700

Talk about IPv6, are there any thoughts/recommendations/experiences to
share on how IPv6 is supposed to work ?  Is this included in the
charter (sorry haven't read the charter) ?

There are several scenarios (enterprise, unmanaged, service-provider
etc) documents in v6ops, where were written before CAPWAP was formed.
Not sure how much of that work needs update or still holds true in the
current context..