1. Topic #1 & #5 “All that has to do with header formats”
Pat R. Calhoun

2. Issue 227 Problem Statement
As discussed on the list, the issue is:
During the initialization a session, the AC doesn’t have a simple way to differentiate CAPWAP Discovery Requests from DTLS packets
Several alternatives were discussed, including:
Reserving fixed fields within CAPWAP to ensure differentiation with DTLS
Adding mandatory DTLS header padded with zeroes (which would signify an invalid DTLS header).

3. Proposed Resolution
Agreed upon resolution on the list was to require a fixed header prior to DTLS header
Not present in
Discovery Packets
DTLS Header
UDP
CAPWAP Pre-Header
CAPWAP Header
CAPWAP Payload
Dictates header
that follows

4. Proposed Resolution
The group also agreed that consistency in packet formats was desirable
Therefore, the pre-header was used with data packets as well
Encryption (or not) would be available in the pre-header, although local policy needs to be enforced
Also addresses issue 224 and 89

5. Proposal #1 Pre-Header format proposed by Scott Kelly:
| Version | Tunnel ID | Type | Payload
Version field is used to provide protocol extensibility
The Tunnel ID field, which is equivalent to a DTLS Session Identifier, is used for QoS purposes (topic addressed by Mani)
Type would indicate the contents of the payload field:
0x1 – Clear Text CAPWAP Control Packet
0x2 – Clear Text CAPWAP Data Packet
0x3 – DTLS Encrypted Control Packet
0x4 – DTLS Encrypted Data Packet

6. Proposal #1 (cont)
This last proposal is a merge of both proposals one and two, which eliminates the need for a second version field:
|Version| Tunnel ID | Type |
| (optional) DTLS Header |
|Version| RID | HLEN | WBID |F|L|D|W|M|T| Flags |
| RID | HLEN | WBID |F|L|D|W|M|T| Flags |
| Fragment ID | Frag Offset |Rsvd |
| Session ID |
| (optional) Radio MAC Address |
| Payload |
Issue is created because two version fields exist, and whether they have a relationship.

7. Proposal #2
This alternative proposal exposes part of the CAPWAP header, but only has a single Version field:
|Version| RID | HLEN | WBID |F|L|D|W|M|T| Flags |
| Fragment ID | Frag Offset |Rsvd |
| Session ID |
| (optional) DTLS Specific Information |
| (optional) Wireless Specific Information |
| (optional) Radio MAC Address |
| Payload |
Where DTLS Specific Info has the following format:
| Length | Tunnel ID | DTLS Header

8. Proposal #3 (Pat’s Preference)
This last proposal is a merge of both proposals one and two, and similar to the proposal in issue 137, which eliminates the need for a second version field:
|Version| Tunnel ID | Type |
| (optional) DTLS Header |
| RID | HLEN | WBID |F|L|D|W|M|T| Flags |
| Fragment ID | Frag Offset |Rsvd |
| Session ID |
| (optional) Radio MAC Address |
| Payload |
Type field has the same values as shown in proposal one (1)
Note Issue 137 also inclusome additional document formatting requests, which are editorial in nature and not required

9. Issue 127: Use of SESSION ID
The Session ID is necessary in order to bind the control and data plane
The binding is necessary to support NAT gateways, where multiple WTPs may appear behind a single IP Address

10. Proposal 168
Requested the removal of the Session ID, which is needed for NAT support

11. Control Message Format Proposal
The proposal simply removes the Time Stamp field, which has not found any usefulness (initially requested by David Perkins, yet removed in his proposals 137 and 146):
| Message Type |
| Seq Num | Msg Element Length | Flags |
| Time Stamp |
| Msg Element [0..N] ...
TO:

12. Control Message Format Proposal (partially from Issue 137)
Components not adopted
Introduction of Sequence Number field (which he removed in his subsequent issue 146)
Introduction of reserved field (was used for padding – not required)
Introduction of ‘F’ bit (first packet). This is unnecessary because both ends need to know what packets they’ve received
Introduction of Length field. Unnecessary since this is derived from outer headers

13. Proposal 146
Introduces a separate CAPWAP Fragmentation Header which is not adopted
Complicates the packet format (nothing wrong with the current proposal)
Some text could be useful (mostly editorial)
Additional re-ordering of fields not adopted

14. Proposal 217
The specification is not clear on what fields are to be present
If i encryption is provided on the AC, the frame format contains the necessary fields
If i encryption terminates in the WTP, should the AC add padded fields for the necessary security?
Yes, since this is how most chipsets work today
TKIP would include the necessary header format
The Checksum is not present since it may be removed by the chip

15. Proposal 221
The CAPWAP protocol supports the use of DTLS on the data plane, but has no way to signal from AC to WTP
New AC Descriptor format:
| Stations | Limit |
| Active WTPs | Max WTPs |
| Security | R-MAC Field |Wireless Field | DTLS Policy |
The DTLS Policy field supports on the following values:
0x0: DTLS does not need to be applied on the data channel
0x1: DTLS needs to be applied on the data channel

16. Side Issue The CAPWAP protocol does not specify a DTLS version
In order to guarantee interoperability, a version MUST be mandated