Subject: [Capwap] RE: Capwap Digest, Vol 5, Issue 49

From: Leo Yao <[email-masked]>
Date: Thu, 30 Mar 2006 10:44:07 +0530

Hi all,
The capwap ac discory phase should add a new phase to get the actual path
MTU, to make sure the packets should not be fragged between STA to AP & AC.
Regards,
Leo Yao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 1:01 AM
To: [email-masked]
Subject: Capwap Digest, Vol 5, Issue 49

Send Capwap mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.frascone.com/mailman/listinfo/capwap
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Capwap digest..."

Today's Topics:

   1. nat-t issues (was Re: [Capwap] a necessary and sufficient
      capwap	base protocol) (Scott G. Kelly)
   2. RE: Issue 61: Justification Required (Pat Calhoun (pacalhou))
   3. RE: Issue 61: Justification Required (Pat Calhoun (pacalhou))
   4. RE: Issue 61: Justification Required (David T. Perkins)
   5. RE: Issue 61: Justification Required ([email-masked])
   6. split AC-WTP tunneling (was RE:[Capwap] a necessary and
      sufficient	capwap base protocol) (Scott G. Kelly)

----------------------------------------------------------------------

Message: 1
Date: Wed, 29 Mar 2006 13:01:57 -0500 (EST)
From: "Scott G. Kelly" <[email-masked]>
Subject: nat-t issues (was Re: [Capwap] a necessary and sufficient
	capwap	base protocol)
To: Pat Calhoun <[email-masked]>, capwap <[email-masked]>
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain; charset=us-ascii

Hi Pat,

In the interest of clarity, I'm breaking out a few of the issues in this
thread so we can deal with them individually. Comments inline below...

> > Historically, new _tunneling_ protocols are not NAT-able
> > until either the protocols are somehow extended or the market
> > reaches a critical mass, and middlebox vendors are forced by
> > their customers to accommodate the protocols.
> 
> Umm... L2TP was absolutely NAT-able from day one without any ALGs
> required
> on the NAT device. LWAPP used many of the concepts from this
> protocol in
> its early designs.
> 

I was overly general in my statement above - I agree that l2tp does do
pretty well with NATs in general these days, though there actually were
issues with some NAT implementations dropping fragments in the early days.
But, those issues are not there for modern gear. 

We didn't start having problems with l2tp and NAT until we tried to combine
it with IPsec. One of the primary reasons for this was that at that point,
we began trying to manage two related datagram channels through a nat, not
just one. Sound familiar?

If you read on to what I said just below, that gets to the heart of it:

> > LWAPP, as it stands, already runs over one port with a MUX
> > header. This, in conjunction with the built-in heartbeat
> > (echo request/reply), suggests that it should work as-is in
> > some simple NAT scenarios. However, the IPsec group dedicated
> > 2 RFCs to this problem, suggesting that it is not really all
> > that simple. Still, if you could share the details of the
> > scenarios in which it *is* currently working, that might help
> > to clarify how much remains to be done. If we are willing to
> > stick with one channel and a mux header, maybe we can deal
> > with simple nat-t in the base spec, and worry about more
> > complex scenarios in follow-on work.
>
> I don't argue that IPSec had multiple specs for this purpose, but
> again,
> L2TP designed their
> protocol from the get-go with NAT in mind - and it does work. If we
> decide to push this off,
> then we will end up with the multiple specs defining possible
> changes to
> the base spec to
> support NAT environments.
> 
> NAT was a recommendation by the eval team that I agree we need to
> pursue.

In actuality, the IPsec group dedicated *3* RFC's to this problem, if you
include the ipsec-nat requirements doc (RFC 3715), and NAT'd l2tp/ipsec was
one of problem areas those RFCs were trying to address. I think there are
two critical distinctions we must recognize in order to get this dialog off
of square 1:

- the current lwapp implementation is getting some traction in NAT
environments right now precisely because it multiplexes data and control
messages over one channel

- we have a proposal on the table to run these channels over separate
datagram ports; this introduces all of the issues IPsec had to deal with;
and the IPsec folks, after thinking long and hard about this, solved the
problems by putting both channels onto one port (doh!)

Bottom line: we can probably solve most NAT traversal issues by simply using
a mux header, rather than two ports, (and this ignores other issues we'll
have with the two-port approach, which I'll address in another email)

Scott

------------------------------

Message: 2
Date: Wed, 29 Mar 2006 10:36:22 -0800
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: RE: [Capwap] Issue 61: Justification Required
To: "Partha Narasimhan" <[email-masked]>
Cc: capwap <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

> While the current mapping seems the simplest one to choose 
> from a design perspective, my earlier statement was to show 
> that there are other implementations out there that use a 
> different one. This is about a WTP vendor choosing a method 
> to manage their MAC address space and how they allocate 
> addresses to their devices. IMHO, we should leave it to the 
> WTP vendor to use their own MAC address management method(s) 
> rather than impose one particular scheme on them from a 
> protocol spec. 

Which is why I'm hoping that such vendors speak up now. Frankly,
I have a hard time understanding the manufacturing process that
allows for non-contiguous MAC addresses to be assigned to a WTP.
Given the rarity of MAC addresses, vendors generally try to use 
them as efficiently as possible.

So I would prefer we keep it simple vs. maximum flexibility, unless
vendors out there see a specific problem with this approach.

> Based on a very quick glance, it is not clear to me why this 
> would require new messages or changes to the state machine 
> (quite possible I am missing something). It does seem to 
> require adding a field or two to some messages.

You may be right - it depends on how we end up implementing it.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

------------------------------

Message: 3
Date: Wed, 29 Mar 2006 10:36:22 -0800
From: "Pat Calhoun (pacalhou)" <[email-masked]>
Subject: RE: [Capwap] Issue 61: Justification Required
To: "Saravanan Govindan" <[email-masked]>,
	"capwap" <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

So if I understand properly, you'd like the AC to also include the
BSSID the WTP should use, in addition to the WLAN ID?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Tuesday, March 28, 2006 5:21 PM
> To: Pat Calhoun (pacalhou); capwap
> Subject: RE: [Capwap] Issue 61: Justification Required
> 
> Pat,
> 
> I like the idea of specifying a default mode for WLAN 
> configuration because it helps implementers with an exact 
> spec. In a slight change from the request below, I would like 
> to see the AC decide the WLAN ID and its corresponding BSSID 
> (for the WTP) and notify this mapping within the 
> Configuration Response. 
> 
> Saravanan
> 
> 
> 
> 
> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2006 2:06 AM
> To: capwap
> Subject: [Capwap] Issue 61: Justification Required
> 
> The original request stated:
> > Page 108, Section 11.8.1.1. I would like to suggest a slightly 
> > different behavior for configuring a WLAN on a WTP.
> > The AC would send a WLAN ID as part of the Configuration 
> Request and 
> > the WTP would respond with the BSSID that would be used for 
> the WLAN 
> > as part of the Configuration Response.
> > In that way, the WTP is responsible for maintaining BSSID 
> to WLAN ID 
> > mappings.
> 
> I'd like to better understand the justification for making 
> such a change. Anyone have strong feelings, and reasons, for 
> this feature?
>  
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 

------------------------------

Message: 4
Date: Wed, 29 Mar 2006 10:51:54 -0800 (PST)
From: "David T. Perkins" <[email-masked]>
Subject: RE: [Capwap] Issue 61: Justification Required
To: "Pat Calhoun (pacalhou)" <[email-masked]>
Cc: capwap <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

HI,

The use case is the following:

A manufacturer creates an AP that is designed to support
a single BSSID. Later on, new software is developed so that
the device can support multiple BSSIDs (and supports
CAPWAP.) The question is where does the device receive
the needed MAC addresses to support this increased
capability. One approach is to have the
AC manage a pool of MAC addresses that can be allocated
to WTPs (which were previously standalone APs). The
MAC addresses in the pool are typically a rare resource
not to be squandered. Thus, the AC might allocate them
to converted WTPs only as needed. If this approach
is followed, then the MAC address used for the BSSIDs
in the converted WTPs may not (and are probably not)
be contiguous.

On Wed, 29 Mar 2006, Pat Calhoun (pacalhou) wrote:
> > While the current mapping seems the simplest one to choose 
> > from a design perspective, my earlier statement was to show 
> > that there are other implementations out there that use a 
> > different one. This is about a WTP vendor choosing a method 
> > to manage their MAC address space and how they allocate 
> > addresses to their devices. IMHO, we should leave it to the 
> > WTP vendor to use their own MAC address management method(s) 
> > rather than impose one particular scheme on them from a 
> > protocol spec. 
> 
> Which is why I'm hoping that such vendors speak up now. Frankly,
> I have a hard time understanding the manufacturing process that
> allows for non-contiguous MAC addresses to be assigned to a WTP.
> Given the rarity of MAC addresses, vendors generally try to use 
> them as efficiently as possible.
> 
> So I would prefer we keep it simple vs. maximum flexibility, unless
> vendors out there see a specific problem with this approach.
> 
> > Based on a very quick glance, it is not clear to me why this 
> > would require new messages or changes to the state machine 
> > (quite possible I am missing something). It does seem to 
> > require adding a field or two to some messages.
> 
> You may be right - it depends on how we end up implementing it.
> 
> Pat Calhoun

Regards,
/david t. perkins

------------------------------

Message: 5
Date: Wed, 29 Mar 2006 21:04:51 +0100
From: [email-masked]
Subject: RE: [Capwap] Issue 61: Justification Required
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain;	charset=ISO-8859-1;	format="flowed"

1 "extra" MAC address is available for free by using the locally 
administrated bit.

Quoting "David T. Perkins" <[email-masked]>:

> HI,
>
> The use case is the following:
>
> A manufacturer creates an AP that is designed to support
> a single BSSID. Later on, new software is developed so that
> the device can support multiple BSSIDs (and supports
> CAPWAP.) The question is where does the device receive
> the needed MAC addresses to support this increased
> capability. One approach is to have the
> AC manage a pool of MAC addresses that can be allocated
> to WTPs (which were previously standalone APs). The
> MAC addresses in the pool are typically a rare resource
> not to be squandered. Thus, the AC might allocate them
> to converted WTPs only as needed. If this approach
> is followed, then the MAC address used for the BSSIDs
> in the converted WTPs may not (and are probably not)
> be contiguous.
>
> On Wed, 29 Mar 2006, Pat Calhoun (pacalhou) wrote:
>> > While the current mapping seems the simplest one to choose
>> > from a design perspective, my earlier statement was to show
>> > that there are other implementations out there that use a
>> > different one. This is about a WTP vendor choosing a method
>> > to manage their MAC address space and how they allocate
>> > addresses to their devices. IMHO, we should leave it to the
>> > WTP vendor to use their own MAC address management method(s)
>> > rather than impose one particular scheme on them from a
>> > protocol spec.
>>
>> Which is why I'm hoping that such vendors speak up now. Frankly,
>> I have a hard time understanding the manufacturing process that
>> allows for non-contiguous MAC addresses to be assigned to a WTP.
>> Given the rarity of MAC addresses, vendors generally try to use
>> them as efficiently as possible.
>>
>> So I would prefer we keep it simple vs. maximum flexibility, unless
>> vendors out there see a specific problem with this approach.
>>
>> > Based on a very quick glance, it is not clear to me why this
>> > would require new messages or changes to the state machine
>> > (quite possible I am missing something). It does seem to
>> > require adding a field or two to some messages.
>>
>> You may be right - it depends on how we end up implementing it.
>>
>> Pat Calhoun
>
> 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
>

------------------------------

Message: 6
Date: Wed, 29 Mar 2006 14:30:11 -0500 (EST)
From: "Scott G. Kelly" <[email-masked]>
Subject: split AC-WTP tunneling (was RE:[Capwap] a necessary and
	sufficient	capwap base protocol)
To: capwap <[email-masked]>, Pat Calhoun <[email-masked]>
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

A few days ago I suggested that we should not be considering split tunneling
in the base draft. Below is a quote, including Pat's response. I followed up
previously, but I want to spend a bit more energy on this:

>> - split tunneling, where data channel terminates on a different 
>> endpoint than the control channel; this has definite security 
>> implications, and probably requires a secure inter-AC protocol, in 
>> addition to its own state machine loop(s). It's a corner case that 
>> many won't care about.
>
>Same as previous comment. This is mandatory for large scale deployments 
>and the protocol supports it already.

I've included a diagram in a text file attachment (sorry, but my webmail
interface mangles ascii drawings). In the diagram, I've include a NAT cloud
for good measure, but what I really want to draw attention to first is the
inter-ac communication this requires.

The proposal is to allow the AC with which the control channel is
established to tell the WTP to terminate its data channel on a different AC.
I think this is a rather curious construct, since control channel overhead
is relatively light, and it seems like the whole session could be pushed to
AC-2 just as easily (isn't this sort of like load balancing?), but
apparently some folks really want this functionality.

I've proposed not supporting this in the base spec, deferring it until later
(assuming it turns out to be useful, of which I remain unconvinced). One
reason is that it requires a back-end inter-AC protocol, and this MUST be
secured - this is currently out of scope, and bringing it into scope for the
base protocol will just about guarantee that we won't have interoperable
implementations before *next* year at this time.

A secondary issue pertains to the complexity this introduces into the state
machines in both ACs and the WTP. AC-1 must make sure that AC-2 can "handle"
the WTP before telling the WTP to use AC-2. What if AC-2 can't take the
load? And what about race conditions - what if WTP sends data before AC-2 is
ready, or after AC-1 told AC-2 to tear down the session? And if there's a
NAT, what if one channel is lost but the other one is still there? Or AC-2
turns out to be unreachable for some reason? Or AC-2 can't reach WTP?

This is just stream-of-consiousness rambling after 30 seconds of thinking
about it - I'm sure there's plenty more complexity where that came from.
This looks like a minority solution that will take lots of time plus a
charter change to address. I suggest we defer this.

To be very clear, the fact that something is not in the base spec does not
mean a vendor is not free to differentiate by adding the feature using VSA's
or some such approach.

Scott
-------------- next part --------------

                                                    +----------+
                                     +------------->|   AC-1   |
+-------+ control   (========)      /               +----------+
|       |<-------->(          )<---/                      ^
|  WTP  |          (   NAT    )                           | binding ctrl
|       |<-------->(          )<---\                      |  protocol?
+-------+  data     (========)      \                     v
                                     \              +----------+  
                                      +------------>|   AC-2   |
                                                    +----------+ 

------------------------------

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

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

End of Capwap Digest, Vol 5, Issue 49
*************************************

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 31 Mar 2006 07:04:23 -0800

This implies a change on the STA, which is out of scope of CAPWAP. We
have no means to inform a station of the MTU to use over the air.

Pat Calhoun

> From: Leo Yao [mailto:[email-masked]] 
> Sent: Wednesday, March 29, 2006 9:14 PM
> To: [email-masked]
> Subject: [Capwap] RE: Capwap Digest, Vol 5, Issue 49
> 
> Hi all,
> The capwap ac discory phase should add a new phase to get the 
> actual path MTU, to make sure the packets should not be 
> fragged between STA to AP & AC.
> Regards,
> Leo Yao
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Capwap digest..."
> 
> 
> Today's Topics:
> 
> In the interest of clarity, I'm breaking out a few of the 
> issues in this thread so we can deal with them individually. 
> Comments inline below...
> 
> > > Historically, new _tunneling_ protocols are not NAT-able until 
> > > either the protocols are somehow extended or the market reaches a 
> > > critical mass, and middlebox vendors are forced by their 
> customers 
> > > to accommodate the protocols.
> > 
> > required on the NAT device. LWAPP used many of the concepts 
> from this 
> > protocol in its early designs.
> > 
> 
> I was overly general in my statement above - I agree that 
> l2tp does do pretty well with NATs in general these days, 
> though there actually were issues with some NAT 
> implementations dropping fragments in the early days.
> We didn't start having problems with l2tp and NAT until we 
> tried to combine it with IPsec. One of the primary reasons 
> for this was that at that point, we began trying to manage 
> two related datagram channels through a nat, not just one. 
> Sound familiar?
> 
> > > LWAPP, as it stands, already runs over one port with a 
> MUX header. 
> > > This, in conjunction with the built-in heartbeat (echo 
> > > request/reply), suggests that it should work as-is in some simple 
> > > NAT scenarios. However, the IPsec group dedicated
> > > 2 RFCs to this problem, suggesting that it is not really all that 
> > > simple. Still, if you could share the details of the scenarios in 
> > > which it *is* currently working, that might help to 
> clarify how much 
> > > remains to be done. If we are willing to stick with one 
> channel and 
> > > a mux header, maybe we can deal with simple nat-t in the 
> base spec, 
> > > and worry about more complex scenarios in follow-on work.
> >
> > again, L2TP designed their protocol from the get-go with 
> NAT in mind - 
> > and it does work. If we decide to push this off, then we 
> will end up 
> > with the multiple specs defining possible changes to the 
> base spec to 
> In actuality, the IPsec group dedicated *3* RFC's to this 
> problem, if you include the ipsec-nat requirements doc (RFC 
> 3715), and NAT'd l2tp/ipsec was one of problem areas those 
> RFCs were trying to address. I think there are two critical 
> distinctions we must recognize in order to get this dialog 
> off of square 1:
> 
> - the current lwapp implementation is getting some traction 
> in NAT environments right now precisely because it 
> multiplexes data and control messages over one channel
> 
> - we have a proposal on the table to run these channels over 
> separate datagram ports; this introduces all of the issues 
> IPsec had to deal with; and the IPsec folks, after thinking 
> long and hard about this, solved the problems by putting both 
> channels onto one port (doh!)
> 
> Bottom line: we can probably solve most NAT traversal issues 
> by simply using a mux header, rather than two ports, (and 
> this ignores other issues we'll have with the two-port 
> approach, which I'll address in another email)
> 
> Scott
> 
> 
> 
> > While the current mapping seems the simplest one to choose from a 
> > design perspective, my earlier statement was to show that there are 
> > other implementations out there that use a different one. This is 
> > about a WTP vendor choosing a method to manage their MAC 
> address space 
> > and how they allocate addresses to their devices. IMHO, we should 
> > leave it to the WTP vendor to use their own MAC address management 
> > method(s) rather than impose one particular scheme on them from a 
> > protocol spec.
> 
> Which is why I'm hoping that such vendors speak up now. 
> Frankly, I have a hard time understanding the manufacturing 
> process that allows for non-contiguous MAC addresses to be 
> assigned to a WTP.
> Given the rarity of MAC addresses, vendors generally try to 
> use them as efficiently as possible.
> 
> So I would prefer we keep it simple vs. maximum flexibility, 
> unless vendors out there see a specific problem with this approach.
> 
> > Based on a very quick glance, it is not clear to me why this would 
> > require new messages or changes to the state machine (quite 
> possible I 
> > am missing something). It does seem to require adding a 
> field or two 
> > to some messages.
> 
> So if I understand properly, you'd like the AC to also 
> include the BSSID the WTP should use, in addition to the WLAN ID?
> 
> Pat Calhoun
> > From: Saravanan Govindan 
> [mailto:[email-masked]]
> > I like the idea of specifying a default mode for WLAN configuration 
> > because it helps implementers with an exact spec. In a 
> slight change 
> > from the request below, I would like to see the AC decide 
> the WLAN ID 
> > and its corresponding BSSID (for the WTP) and notify this mapping 
> > within the Configuration Response.
> > 
> > Saravanan
> > 
> > 
> > 
> > 
> > I'd like to better understand the justification for making such a 
> > change. Anyone have strong feelings, and reasons, for this feature?
> >  
> > 
> > Pat Calhoun