Subject: [Capwap] NAT traversal

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 7 Jun 2005 16:26:58 -0400

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

---

From: Inderpreet Singh <[email-masked]>
Date: Wed, 8 Jun 2005 12:45:19 -0400

Sounds like a good idea but it may be implicitly covered under
"Interconnection Objective".  Are you suggesting we make an explicit
separate objective?

---

Inderpreet Singh

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sadot, Emek (Emek)
Sent: Tuesday, June 07, 2005 4:27 PM
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

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Wed, 8 Jun 2005 13:21:55 -0400

Inderpreet,
 
NAT poses specific requirements whereas the interconnection objective,
at least to my interpretation is too general. I would like to see an
explicit NATG traversal objective and willing to put the wording around
it if here no objection from the group.
 
Emek

  _____  

From: Inderpreet Singh [mailto:[email-masked]] 
Sent: Wednesday, June 08, 2005 12:45 PM
To: Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] NAT traversal

---

Inderpreet Singh

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sadot, Emek (Emek)
Sent: Tuesday, June 07, 2005 4:27 PM
To: [email-masked]
Subject: [Capwap] NAT traversal

All,

Regards,

Emek

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 9 Jun 2005 23:46:33 -0400

If both, AC and WTP, are behind symmetric NAT device then we have a
problem due to the nature of symmetric NAT. It get worse if the AC
obtains its IP address via DHCP protocol. If the AC is behind a
symmetric NAT device and have a static IP address then administratively
that NAT device can be configure to honor / accept WTP CAPWAP requests
from the public side.
 
It boiled down to the question how the AC's IP address would be
discovered by the WTP.
- If the AC obtains its IP address via DHCP and register its IP address
to a server where later the WTP will inquire then we have a problem.
- If the AC is statically assigned with an IP address then the problem
can be administratively mitigated (see above).
 
Emek

  _____  

From: Darren Loher [mailto:[email-masked]] 
Sent: Thursday, June 09, 2005 7:24 PM
To: Pat Calhoun; Cheng Hong; Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] NAT traversal

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

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 10 Jun 2005 10:51:43 -0400

Pat,

Compare to other along-the-way network appliances NAT device reboot
presents communication challenge as parties (e.g. AC and WTP) need to
proactively resume communication / protocol from the private side of the
NAT. I would say that the CAPWAP protocol can come up with a solution
for #4 that will covers #5 scenario as well.

Emek

-----Original Message-----
From: Pat Calhoun [mailto:[email-masked]] 
Sent: Friday, June 10, 2005 8:45 AM
To: Sadot, Emek (Emek); 'David T. Perkins'; 'Darren Loher'
Cc: 'Cheng Hong'; [email-masked]
Subject: RE: [Capwap] NAT traversal

I am ok with most statements here, but not necessarily with number 5. I
don't think we need to go as far as to try to create a protocol that can
guard itself against broken NAT infrastructure.

Pat Calhoun

> -----Original Message-----
> From: Sadot, Emek (Emek) [mailto:[email-masked]]
> Sent: Thursday, June 09, 2005 8:27 PM
> To: David T. Perkins; Darren Loher
> Cc: Pat Calhoun; Cheng Hong; [email-masked]
> 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]
> 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:
> > ________________________________
> > 
> [mailto:[email-masked]] On
> > Behalf Of Pat Calhoun
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> >  
> > 
> > 	 
> > 
> > 	
> > ________________________________
> > 
> > 
> > 	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
> > 	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
> > ________________________________
> > 
> > 
> > 		Would like to suggest adding a NAT traversal
> requirement to the
> > CAPWAP objective document, i.e. the ability of AC and WTP to 

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

---

From: "Darren Loher" <[email-masked]>
Date: Fri, 10 Jun 2005 09:32:55 -0700

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

> Sent: Thursday, June 09, 2005 9:27 PM
the
> private domain (10.1.2.2) may be helpful as well.
> 
WTP
> initiate the communication first.
(and
> 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
> 
> 
> I'm still having a problem understanding what you are trying
> to accomplish.
> 
> Here is a picture....
> 
> 
> 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
>

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 10 Jun 2005 14:31:54 -0400

Personally I would like to see a NAT objective spelled out in the
objective document rather then give implementers the freedom.

CAPWAP protocol shall facilitate other technologies, not only Wi-Fi.
Let's do the right thing when we can. IMHO supporting NAT traversal
should be fairly easy to accomplish at this stage of the CAPWAP working,
rather of reengineering the protocol if needed so.

Take it to extreme: we will be doomed if CAPWAP protocol turn to be a
layer 3 transport based protocol.

To your last point: Discovery will not solve problem #5 as WTP and AC
already discovered / authenticate / and registered one each other.
Having said that, I can see how #5 is a none-goal.

Emek

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

-Darren

the
WTP
(and
the

---

From: "Darren Loher" <[email-masked]>
Date: Mon, 13 Jun 2005 09:16:05 -0700

One could also reference STUN RFC 3489 which included study of NAT types
in the SIP working group.   http://www.ietf.org/rfc/rfc3489.txt  It
provides a solution for discovering and working around some types of NAT
using a STUN server as a helper agent.  (intended for a SIP environment)

I only bring this up as background information.

-Darren

> From: Suresh Satapati [mailto:[email-masked]]
> Sent: Monday, June 13, 2005 10:02 AM
> To: Darren Loher
> Cc: Sadot, Emek (Emek); Pat Calhoun; David T. Perkins; Cheng Hong;
> [email-masked]
> Subject: Re: [Capwap] NAT traversal
> 
> On 6/10/05, Darren Loher <[email-masked]> wrote:
> > I agree with Emek that #4 and #5 are important problems when using
NAT.
> 
> Agreed. Also agree with the two high level scenarios :-
> 1. WTP behind NAT
> 2. AC behind NAT
> 
> I can send some text on different types of NATs in the market place
> today. We have gone through this exercise in V6OPS.  All this can go
> into a separate document if the WG feels this is useful work..
> 
> > But I think wether communication is lost via NAT distruption/reboot,
> > link issues or other reasons, a reasonable CAPWAP implementation
should
> > have a method to survive a lost connection and restore the
connection
> > between WTP and AC.
> >
> > Connection integrity/keepalive type functions which would address
> > problems like these probably do not need to be explicit
requirements.
> 
> Yes. No need for explicit requirements here..
> 
> >
> > -Darren
> >
> > > Sent: Friday, June 10, 2005 8:52 AM
> > > To: Pat Calhoun; David T. Perkins; Darren Loher
> > > Cc: Cheng Hong; [email-masked]
> > > proactively resume communication / protocol from the private side
of
> > > I am ok with most statements here, but not necessarily with number
5.
> > I
> > > don't think we need to go as far as to try to create a protocol
that
> > can
> > > > Excellent diagram. Respectfully I would avoid naming "Internet"
as
> > NAT
what
> > > > > On the requirements side for NAT, should we specify if the WTP
is
> > > > behind
> > > > > Imagine a service provider connecting their AC to their
customer's
> > > > WTPs
> > > > > session at the NAT device, WTP identification behind NAT
device,
> > > > etc.).
> > > > > Deployment examples? say the WTP is located at branch office
and
> > > > AC

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Mon, 13 Jun 2005 14:14:57 -0600

Speaking as a WG member-

I agree on the point of keeping the base protocol simple.

I believe that NAT applicability could be managed as follows:

Depending on how analogous the CAPWAP protocol shapes up - to other
protocols encountering similar challenges at L3 and higher and have
addressed them with/out limitations - applicability of existing
SIP/STUN, IPsec/IKE, NSIS, BEHAVE approaches would be worth comparing.
That is later. In CAPWAP case we have an opportunity to examine it up
front.

That said - We have to live with the need to maneuver in NAT
environments. However, we should avoid built-in workarounds to NAT
behaviors (that would be endorsing use of NAT). Thus - I think & agree
it must not be a part of CAPWAP protocol to provide explicit support for
NAT.

As WG chair:

Further - with the Objectives, Evaluation schedules and upcoming
milestones in mind - we should preferably address it outside the scope
of the base protocol.

[Actually - at one point (and I still think it is true) - by default all
new IETF protocols were implicitly required to support IPv6. if that is
so - that becomes an implicit requirement (MUST). If not - it is a
highly desirable objective (SHOULD). NAT-avoidance is a side-effect in
IPv6].

Regards,
-mani
======
-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Friday, June 10, 2005 10:04 AM
To: Mani, Mahalingam (Mahalingam); Darren Loher; Sadot, Emek (Emek);
David T. Perkins

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

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-----
Behalf Of Darren Loher
Sent: Friday, June 10, 2005 9:33 AM

-Darren

the
WTP
(and
the

---

From: "Matt Holdrege" <[email-masked]>
Date: Mon, 13 Jun 2005 13:41:50 -0700

Speaking as the old NAT WG chair, please read and reference RFC 2663 and
perhaps 3027 if you wish to engage in any formal NAT documentation
exercises.

Personally I think if the authors of the protocol draft understand the
NAT problem (it's not that hard), they can write up a simple section in
their document entitled "NAT Considerations". 

-Matt

---

From: "Darren Loher" <[email-masked]>
Date: Wed, 15 Jun 2005 11:36:37 -0700

I like Matt's suggestion.  "The CAPWAP protocol must include a section
entitled NAT Considerations which will document how the protocol is
intended to behave in a NAT environments described in RFC 2663."  Or
perhaps this could be a supplemental draft per protocol instead of a new
additional section?

-Darren

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Matt Holdrege
Sent: Monday, June 13, 2005 2:42 PM
To: [email-masked]
Subject: RE: [Capwap] NAT traversal

-Matt