Network Working Group                                 P. Calhoun, Editor
Internet-Draft                                       Cisco Systems, Inc.
Expires: August 28, November 6, 2006                          M. Montemurro, Editor
                                                        Chantry Networks
                                                      D. Stanley, Editor
                                                          Aruba Networks
                                                       February 24,
                                                             May 5, 2006

                     CAPWAP Protocol Specification
              draft-ietf-capwap-protocol-specification-00
              draft-ietf-capwap-protocol-specification-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, November 6, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Wireless LAN product architectures have evolved from single
   autonomous access points to systems consisting of a centralized
   controller and Wireless Termination Points (WTPs).  The general goal
   of centralized control architectures is to move access control,
   including user authentication and authorization, mobility management
   and radio management from the single access point to a centralized
   controller.

   This specification defines the Control And Provisioning of Wireless
   Access Points (CAPWAP) Protocol.  The CAPWAP protocol meets the IETF
   CAPWAP working group protocol requirements.  The CAPWAP protocol is
   designed to be flexible, allowing it to be used for a variety of
   wireless technologies.  This document describes the base CAPWAP
   protocol, including an extension which supports the IEEE 802.11
   wireless LAN protocol.  Future extensions will enable support of
   additional wireless technologies.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7
     1.1.   Goals  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     1.2.   Conventions used in this document  . . . . . . . . . . .   8
     1.2.
     1.3.   Contributing Authors . . . . . . . . . . . . . . . . . .   8
     1.3.
     1.4.   Acknowledgements . . . . . . . . . . . . . . . . . . . .  10
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  11
     2.1.   Wireless Binding Definition  . . . . . . . . . . . . . .  12
     2.2.   CAPWAP State Machine Definition  . . . Session Establishment Overview  . . . . . . . . .  12
     2.3.   Use of DTLS in the   CAPWAP Protocol State Machine Definition  . . . . . . . . . . .  21
       2.3.1.   DTLS Error Handling Requirements .  14
       2.3.1.    CAPWAP Protocol State Transitions . . . . . . . . .  21  15
       2.3.2.    CAPWAP to DTLS Cookie Exchange Failure Commands . . . . . . . . . . . . . .  22
       2.3.3.    DTLS Re-Assembly Failure . . . to CAPWAP Notifications  . . . . . . . . . . .  23
   3.  CAPWAP Transport  .
       2.3.4.    DTLS State Transitions  . . . . . . . . . . . . . .  23
     2.4.   Use of DTLS in the CAPWAP Protocol . . . . . . .  24
     3.1.   UDP Transport . . . .  26
       2.4.1.    DTLS Handshake Processing . . . . . . . . . . . . .  27
       2.4.2.    DTLS Error Handling . . . .  24
     3.2.   AC Discovery . . . . . . . . . . . .  28
       2.4.3.    DTLS Rehandshake Behavior . . . . . . . . . .  24
     3.3.   Fragmentation/Reassembly . . .  29
       2.4.4.    DTLS EndPoint Authentication  . . . . . . . . . . .  32
   3.  CAPWAP Transport  . .  25
   4.  CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . .  26
     4.1.   CAPWAP  35
     3.1.   UDP Transport Header  . . . . . . . . . . . . . . . .  27
       4.1.1.   VER Field . . . . .  35
     3.2.   AC Discovery . . . . . . . . . . . . . . . .  27
       4.1.2.   RID Field . . . . . .  35
     3.3.   Fragmentation/Reassembly . . . . . . . . . . . . . . .  27
       4.1.3.   F Bit .  36
   4.  CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . .  37
     4.1.   CAPWAP Transport Header  . .  27
       4.1.4.   L Bit . . . . . . . . . . . . . .  38
     4.2.   CAPWAP Data Messages . . . . . . . . .  27
       4.1.5.   R Bit . . . . . . . . .  40
     4.3.   CAPWAP Control Messages  . . . . . . . . . . . . . .  28
       4.1.6.   Fragment ID . .  41
       4.3.1.    Control Message Format  . . . . . . . . . . . . . .  41
       4.3.2.    Control Message Quality of Service  . . . .  28
       4.1.7.   Length . . . .  44
     4.4.   CAPWAP Protocol Message Elements . . . . . . . . . . . .  44
       4.4.1.    AC Descriptor . . . . . . .  28
       4.1.8.   Status and WLANS . . . . . . . . . . . .  45
       4.4.2.    AC IPv4 List  . . . . . .  28
       4.1.9.   Payload . . . . . . . . . . . . .  46
       4.4.3.    AC IPv6 List  . . . . . . . . .  28
     4.2.   CAPWAP Data Messages . . . . . . . . . .  46
       4.4.4.    AC Name . . . . . . . .  28
     4.3.   CAPWAP Control Messages Overview . . . . . . . . . . . .  29
       4.3.1.   Control Message Format . .  47
       4.4.5.    AC Name with Index  . . . . . . . . . . . . .  29
       4.3.2.   Message Element Format . . .  47
       4.4.6.    AC Timestamp  . . . . . . . . . . . .  31
       4.3.3.   Quality of Service . . . . . . .  48
       4.4.7.    Add MAC ACL Entry . . . . . . . . . .  32
   5.  CAPWAP Discovery Operations . . . . . . .  48
       4.4.8.    Add Mobile Station  . . . . . . . . . .  33
     5.1.   Discovery Request . . . . . .  49
       4.4.9.    Add Static MAC ACL Entry  . . . . . . . . . . . . .  33
       5.1.1.   Discovery Type  49
       4.4.10.   CAPWAP Timers . . . . . . . . . . . . . . . . . . .  34
       5.1.2.   WTP Descriptor  50
       4.4.11.   Change State Event  . . . . . . . . . . . . . . . .  50
       4.4.12.   Data Transfer Data  . . .  34
       5.1.3.   WTP Radio Information . . . . . . . . . . . . .  51
       4.4.13.   Data Transfer Mode  . .  35
       5.1.4.   WTP MAC Type . . . . . . . . . . . . . .  52
       4.4.14.   Decryption Error Report . . . . . .  36
       5.1.5.   WTP Frame Type . . . . . . . .  52
       4.4.15.   Decryption Error Report Period  . . . . . . . . . .  53
       4.4.16.   Delete MAC ACL Entry  .  36
     5.2.   Discovery Response . . . . . . . . . . . . . .  53
       4.4.17.   Delete Mobile Station . . . . .  37
       5.2.1.   AC Address . . . . . . . . . .  54
       4.4.18.   Delete Static MAC ACL Entry . . . . . . . . . . .  38
       5.2.2.   AC Descriptor .  54
       4.4.19.   Discovery Type  . . . . . . . . . . . . . . . . . .  38
       5.2.3.   AC Name  55
       4.4.20.   Duplicate IPv4 Address  . . . . . . . . . . . . . .  55
       4.4.21.   Duplicate IPv6 Address  . . . . . . . .  39
       5.2.4.   WTP Manager Control IPv4 Address . . . . . .  56
       4.4.22.   Idle Timeout  . . . .  39
       5.2.5.   WTP Manager Control IPv6 Address . . . . . . . . . .  40
     5.3.   Primary Discovery Request . . . . .  56
       4.4.23.   Image Data  . . . . . . . . . .  41
       5.3.1.   Discovery Type . . . . . . . . . .  57
       4.4.24.   Image Filename  . . . . . . . . .  41
       5.3.2.   WTP Descriptor . . . . . . . . .  57
       4.4.25.   Initiate Download . . . . . . . . . .  41
       5.3.3.   WTP MAC Type . . . . . . .  58
       4.4.26.   Location Data . . . . . . . . . . . . .  41
       5.3.4.   WTP Frame Type . . . . . .  58
       4.4.27.   MTU Discovery Padding . . . . . . . . . . . . .  41
       5.3.5.   WTP Radio Information . .  59
       4.4.28.   Radio Administrative State  . . . . . . . . . . . .  59
       4.4.29.   Result Code .  41
     5.4.   Primary Discovery Response . . . . . . . . . . . . . . .  41
       5.4.1.   AC Descriptor . . . .  60
       4.4.30.   Session ID  . . . . . . . . . . . . . . .  42
       5.4.2.   AC Name . . . . .  60
       4.4.31.   Statistics Timer  . . . . . . . . . . . . . . . . .  42
       5.4.3.   WTP Manager Control IPv4 Address  61
       4.4.32.   Vendor Specific Payload . . . . . . . . . .  42
       5.4.4.   WTP Manager Control IPv6 Address . . . .  61
       4.4.33.   WTP Board Data  . . . . . .  42
   6.  Control Channel Management . . . . . . . . . . . .  62
       4.4.34.   WTP Descriptor  . . . . .  43
     6.1.   Echo Request . . . . . . . . . . . . .  63
       4.4.35.   WTP Fallback  . . . . . . . . .  43
     6.2.   Echo Response . . . . . . . . . .  64
       4.4.36.   WTP Frame Encapsulation Type  . . . . . . . . . . .  43
   7.  65
       4.4.37.   WTP Configuration Management IPv4 IP Address . . . . . . . . . . . . . . . .  44
     7.1.   Configuration Consistency  66
       4.4.38.   WTP MAC Type  . . . . . . . . . . . . . . .  44
       7.1.1.   Configuration Flexibility . . . .  66
       4.4.39.   WTP Radio Information . . . . . . . . .  45
     7.2.   Configure Request . . . . . .  67
       4.4.40.   WTP Manager Control IPv4 Address  . . . . . . . . .  67
       4.4.41.   WTP Manager Control IPv6 Address  . . . .  45
       7.2.1.   Administrative State . . . . .  68
       4.4.42.   WTP Name  . . . . . . . . . . .  45
       7.2.2.   AC Name . . . . . . . . . .  69
       4.4.43.   WTP Reboot Statistics . . . . . . . . . . . .  46
       7.2.3.   AC Name with Index . . .  69
       4.4.44.   WTP Static IP Address Information . . . . . . . . .  70
     4.5.   CAPWAP Protocol Timers . . . . .  46
       7.2.4.   WTP Board Data . . . . . . . . . . . .  71
       4.5.1.    DiscoveryInterval . . . . . . .  46
       7.2.5.   Statistics Timer . . . . . . . . . .  71
       4.5.2.    DTLSRehandshake . . . . . . . .  47
       7.2.6.   WTP Static IP Address Information . . . . . . . . .  48
       7.2.7.   WTP Reboot Statistics .  71
       4.5.3.    DTLSSessionDelete . . . . . . . . . . . . . .  49
     7.3.   Configure Response . . .  71
       4.5.4.    EchoInterval  . . . . . . . . . . . . . . . .  50
       7.3.1.   Decryption Error Report Period . . .  71
       4.5.5.    KeyLifetime . . . . . . . .  50
       7.3.2.   Change State Event . . . . . . . . . . . .  71
       4.5.6.    MaxDiscoveryInterval  . . . . .  50
       7.3.3.   CAPWAP Timers . . . . . . . . . .  72
       4.5.7.    NeighborDeadInterval  . . . . . . . . .  51
       7.3.4.   AC IPv4 List . . . . . .  72
       4.5.8.    ResponseTimeout . . . . . . . . . . . . . .  52
       7.3.5.   AC IPv6 List . . . .  72
       4.5.9.    RetransmitInterval  . . . . . . . . . . . . . . . .  52
       7.3.6.   WTP Fallback  72
       4.5.10.   SilentInterval  . . . . . . . . . . . . . . . . . .  72
       4.5.11.   WaitJoin  . .  53
       7.3.7.   Idle Timeout . . . . . . . . . . . . . . . . . . .  72
     4.6.   CAPWAP Protocol Variables  .  53
     7.4.   Configuration Update Request . . . . . . . . . . . . . .  54
       7.4.1.   WTP Name  73
       4.6.1.    DiscoveryCount  . . . . . . . . . . . . . . . . . .  73
       4.6.2.    MaxDiscoveries  . . . .  54
       7.4.2.   Change State Event . . . . . . . . . . . . . .  73
       4.6.3.    MaxRetransmit . . .  54
       7.4.3.   Administrative State . . . . . . . . . . . . . . . .  54
       7.4.4.   Statistics Timer  73
       4.6.4.    RetransmitCount . . . . . . . . . . . . . . . . . .  55
       7.4.5.   Location Data  73
   5.  CAPWAP Discovery Operations . . . . . . . . . . . . . . . . .  74
     5.1.   Discovery Request Message  . .  55
       7.4.6.   Decryption Error Report Period . . . . . . . . . . .  55
       7.4.7.   AC IPv4 List . .  74
     5.2.   Discovery Response Message . . . . . . . . . . . . . . .  75
     5.3.   Primary Discovery Request Message  . . .  55
       7.4.8.   AC IPv6 List . . . . . . . .  75
     5.4.   Primary Discovery Response . . . . . . . . . . . .  55
       7.4.9.   Add MAC ACL Entry . . .  76
   6.  CAPWAP Join Operations  . . . . . . . . . . . . . .  55
       7.4.10.  Delete MAC ACL Entry . . . . .  77
     6.1.   Join Request . . . . . . . . . . .  56
       7.4.11.  Add Static MAC ACL Entry . . . . . . . . . . .  77
     6.2.   Join Response  . . .  56
       7.4.12.  Delete Static MAC ACL Entry . . . . . . . . . . . .  57
       7.4.13.  CAPWAP Timers . . . . . .  78
   7.  Control Channel Management  . . . . . . . . . . . . .  57
       7.4.14.  AC Name with Index . . . .  79
     7.1.   Echo Request . . . . . . . . . . . . .  57
       7.4.15.  WTP Fallback . . . . . . . . .  79
     7.2.   Echo Response  . . . . . . . . . . .  58
       7.4.16.  Idle Timeout . . . . . . . . . .  79
   8.  WTP Configuration Management  . . . . . . . . . .  58
       7.4.17.  Timestamp . . . . . .  80
     8.1.   Configuration Consistency  . . . . . . . . . . . . . . .  58
     7.5.  80
       8.1.1.    Configuration Update Response Flexibility . . . . . . . . . . . . .  58
       7.5.1.   Result Code  81
     8.2.   Configuration Status . . . . . . . . . . . . . . . . . .  81
     8.3.   Configuration Status Response  . . . . .  58
     7.6.   Change State Event . . . . . . . .  82
     8.4.   Configuration Update Request . . . . . . . . . . . . . .  82
     8.5.   Configuration Update Response  . . . .  59
       7.6.1. . . . . . . . . .  83
     8.6.   Change State Event Request . . . . . . . . . . . . . . . . .  59
     7.7.  84
     8.7.   Change State Event Response  . . . . . . . . . . . . . .  59
     7.8.  84
     8.8.   Clear Config Indication  . . . . . . . . . . . . . . . .  60
   8.  85
   9.  Device Management Operations  . . . . . . . . . . . . . . . .  61
     8.1.  86
     9.1.   Image Data Request . . . . . . . . . . . . . . . . . . .  61
       8.1.1.  86
     9.2.   Image Download . Data Response  . . . . . . . . . . . . . . . . . .  61
       8.1.2.   Image Data  87
     9.3.   Reset Request  . . . . . . . . . . . . . . . . . . . . .  61
     8.2.   Image Data  87
     9.4.   Reset Response . . . . . . . . . . . . . . . . . .  62
     8.3.   Reset Request  . . . .  87
     9.5.   WTP Event Request  . . . . . . . . . . . . . . . . .  62
     8.4.   Reset Response . .  87
     9.6.   WTP Event Response . . . . . . . . . . . . . . . . . . .  63
     8.5.   WTP Event  88
     9.7.   Data Transfer Request  . . . . . . . . . . . . . . . . .  88
     9.8.   Data Transfer Response . .  63
       8.5.1.   Decryption Error Report . . . . . . . . . . . . . .  63
       8.5.2.   Duplicate IPv4 Address .  88
   10. Mobile Session Management . . . . . . . . . . . . . .  64
       8.5.3.   Duplicate IPv6 Address . . . .  90
     10.1.  Mobile Config Request  . . . . . . . . . . .  64
     8.6.   WTP Event Response . . . . . .  90
     10.2.  Mobile Config Response . . . . . . . . . . . . .  65
     8.7.   Data Transfer Request . . . .  90
   11. IEEE 802.11 Binding . . . . . . . . . . . . .  65
       8.7.1.   Data Transfer Mode . . . . . . . .  91
     11.1.  Split MAC and Local MAC Functionality  . . . . . . . . .  66
       8.7.2.   Data Transfer Data  91
       11.1.1.   Split MAC . . . . . . . . . . . . . . . . .  66
     8.8.   Data Transfer Response . . . .  91
       11.1.2.   Local MAC . . . . . . . . . . . . .  67
   9.  Mobile Session Management . . . . . . . .  93
     11.2.  Roaming Behavior . . . . . . . . . .  68
     9.1.   Mobile Config Request . . . . . . . . . .  96
     11.3.  Group Key Refresh  . . . . . . .  68
       9.1.1.   Add Mobile . . . . . . . . . . . .  97
     11.4.  Transport specific bindings  . . . . . . . . .  68
       9.1.2.   Delete Mobile . . . . .  97
     11.5.  BSSID to WLAN ID Mapping . . . . . . . . . . . . . .  69
     9.2.   Mobile Config Response . .  99
     11.6.  Quality of Service for Control Messages  . . . . . . . .  99
     11.7.  IEEE 802.11 Specific CAPWAP Control Messages . . . . . . 100
       11.7.1.   IEEE 802.11 WLAN Config Request .  69
       9.2.1.   Result Code . . . . . . . . . 100
       11.7.2.   IEEE 802.11 WLAN Config Response  . . . . . . . . . 101
     11.8.  Data Message bindings  . .  70
   10. CAPWAP Security . . . . . . . . . . . . . . . 101
     11.9.  Control Message bindings . . . . . . . .  71
     10.1.  Endpoint Authentication using DTLS . . . . . . . . 101
       11.9.1.   Mobile Config Request . . .  71
       10.1.1.  Authenticating with Certificates . . . . . . . . . .  71
       10.1.2.  Authenticating with Preshared Keys . . . . . . . . .  72
     10.2.  Refreshing Cryptographic Keys  . 101
       11.9.2.   WTP Event Request . . . . . . . . . . . .  73
     10.3.  Certificate Usage . . . . . 101
       11.9.3.   Configuration Messages  . . . . . . . . . . . . . .  73
   11. 102
     11.10. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . .  74
     11.1.  Division of labor  . . . . . . . . . . . . . . . . . . .  74
       11.1.1.  Split MAC  . . . . . . . . . . . . . . . . . . . . .  74
       11.1.2.  Local MAC  . . . . . . . . . . . . . Message Element Definitions  . . . . . . . .  76
     11.2.  Roaming Behavior and 102
       11.10.1.  IEEE 802.11 security . . . . Add WLAN  . . . . . .  79
     11.3.  Transport specific bindings . . . . . . . . . 102
       11.10.2.  IEEE 802.11 Antenna . . . . .  80
       11.3.1.  Payload encapsulation . . . . . . . . . . . 106
       11.10.3.  IEEE 802.11 Assigned WTP BSSID  . . . .  80
       11.3.2.  Status and WLANS field . . . . . . 107
       11.10.4.  IEEE 802.11 Broadcast Probe Mode  . . . . . . . . .  80
     11.4.  BSSID to 108
       11.10.5.  IEEE 802.11 Delete WLAN ID Mapping . . . . . . . . . . . . . . . .  81
     11.5.  Quality of Service for 108
       11.10.6.  IEEE 802.11 Direct Sequence Control Messages . . . . . . . .  81
     11.6.  Data Message bindings 109
       11.10.7.  IEEE 802.11 Information Element . . . . . . . . . . 110
       11.10.8.  IEEE 802.11 MAC Operation . . . . . . .  82
     11.7.  Control Message bindings . . . . . . 110
       11.10.9.  IEEE 802.11 MIC Countermeasures . . . . . . . . . .  82
       11.7.1. 112
       11.10.10. IEEE 802.11 MIC Error Report From Mobile Config Request  . . . . . . . .  . . . . . . .  82
       11.7.2.  WTP Event Request  . . . . . . . . . . . . . . . . .  86
     11.8. 112
       11.10.11. IEEE 802.11 Control Messages Mobile  . . . . . . . . . . . . . . . .  88
       11.8.1. 113
       11.10.12. IEEE 802.11 WLAN Config Request Mobile Session Key  . . . . . . . . . .  88
       11.8.2. 114
       11.10.13. IEEE 802.11 WLAN Config Response . . Multi-domain Capability . . . . . . . .  94
       11.8.3. 116
       11.10.14. IEEE 802.11 WTP Event  . . . . . . . . . . . . . . .  94
     11.9.  Message Element Bindings . . . OFDM Control  . . . . . . . . . . . . .  96
       11.9.1. 117
       11.10.15. IEEE 802.11 WTP WLAN Radio Configuration . Rate Set  . . . . .  96
       11.9.2.  IEEE 802.11 Rate Set . . . . . . . . . . 118
       11.10.16. IEEE 802.11 Statistics  . . . . . .  98
       11.9.3.  IEEE 802.11 Multi-domain Capability . . . . . . . .  98
       11.9.4. 118
       11.10.17. IEEE 802.11 MAC Operation  . Supported Rates . . . . . . . . . . . .  99
       11.9.5. 120
       11.10.18. IEEE 802.11 Tx Power  . . . . . . . . . . . . . . . . 101
       11.9.6. 121
       11.10.19. IEEE 802.11 Tx Power Level  . . . . . . . . . . . . . 101
       11.9.7.  IEEE 802.11 Direct Sequence Control  . . . . . . . . 102
       11.9.8. 121
       11.10.20. IEEE 802.11 OFDM Control . . . Update Mobile QoS . . . . . . . . . . . 103
       11.9.9. 122
       11.10.21. IEEE 802.11 Antenna  . . Update WLAN . . . . . . . . . . . . . . 104
       11.9.10. 122
       11.10.22. IEEE 802.11 Supported Rates  . . . . WTP Quality of Service  . . . . . . . . 105
       11.9.11. 125
       11.10.23. IEEE 802.11 CFP Status . . . . . . . . . . . WTP Radio Fail Alarm Indication . . . . 105
       11.9.12. 126
       11.10.24. IEEE 802.11 Broadcast Probe Mode . WTP Radio Configuration . . . . . . . . 127
       11.10.25. Station QoS Profile . 106
       11.9.13. IEEE 802.11 WTP Quality of Service . . . . . . . . . 106
       11.9.14. IEEE 802.11 MIC Error Report From Mobile . . . . . . 108
     11.10. IEEE 802.11 128
     11.11. Technology Specific Message Element Values . . . . . . . . . . . 108 129
   12. CAPWAP Protocol Timers NAT Considerations  . . . . . . . . . . . . . . . . . . . 109
     12.1.  MaxDiscoveryInterval . . 130
   13. Security Considerations . . . . . . . . . . . . . . . . 109
     12.2.  SilentInterval . . . 132
     13.1.  CAPWAP Security  . . . . . . . . . . . . . . . . . . 109
     12.3.  NeighborDeadInterval . . 132
       13.1.1.   Converting Protected Data into Unprotected Data . . 133
       13.1.2.   Converting Unprotected  Data into Protected Data
                 (Insertion) . . . . . . . . . . . . . . 109
     12.4.  WaitJoin . . . . . . 133
       13.1.3.   Deletion of Protected Records . . . . . . . . . . . 133
       13.1.4.   Insertion of Unprotected Records  . . . . . . . 109
     12.5.  EchoInterval . . 133
     13.2.  Use of Preshared Keys in CAPWAP  . . . . . . . . . . . . 133
     13.3.  Use of Certificates in CAPWAP  . . . . . . . . 109
     12.6.  DiscoveryInterval . . . . . 134
     13.4.  AAA Security . . . . . . . . . . . . . . 109
     12.7.  RetransmitInterval . . . . . . . . 134
     13.5.  IEEE 802.11 Security . . . . . . . . . . . 110
     12.8.  ResponseTimeout . . . . . . . 135
   14. IANA Considerations . . . . . . . . . . . . . 110
     12.9.  KeyLifetime . . . . . . . . 136
   15. References  . . . . . . . . . . . . . . 110
   13. CAPWAP Protocol Variables . . . . . . . . . . . 137
     15.1.  Normative References . . . . . . . 111
     13.1.  MaxDiscoveries . . . . . . . . . . . 137
     15.2.  Informational References . . . . . . . . . . 111
     13.2.  DiscoveryCount . . . . . . 138
   Editors' Addresses  . . . . . . . . . . . . . . . 111
     13.3.  RetransmitCount . . . . . . . . 140
   Intellectual Property and Copyright Statements  . . . . . . . . . . . . 111
     13.4.  MaxRetransmit  . . . . . . . . . . . . . . . . . . . . . 111
   14. NAT Considerations  . . . . . . . . . . . . . . . . . . . . . 112
   15. Security Considerations . . . . . . . . . . . . . . . . . . . 114
     15.1.  PSK based Session Key establishment  . . . . . . . . . . 114
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115
   17. References  . . . . . . . . . . . . . . . . . . . . . . . . . 116
     17.1.  Normative References . . . . . . . . . . . . . . . . . . 116
     17.2.  Informational References . . . . . . . . . . . . . . . . 117
   Editors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 118
   Intellectual Property and Copyright Statements  . . . . . . . . . 119 141

1.  Introduction

   The emergence of centralized architectures, in which simple IEEE
   802.11 WTPs are managed by an Access Controller (AC) suggests that a
   standards based, interoperable protocol could radically simplify the
   deployment and management of wireless networks.  WTPs require a set
   of dynamic management and control functions related to their primary
   task of connecting the wireless and wired mediums.  Traditional
   protocols for managing WTPs are either manual static configuration
   via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs
   are self-contained).  This document describes the CAPWAP Protocol, a
   standard, interoperable protocol which enables an AC to manage a
   collection of WTPs.  The  While the protocol is defined to be independent
   of layer 2 technology.  An technology, an IEEE 802.11 binding is provided to support
   IEEE 802.11 wireless LAN networks.

   CAPWAP assumes a network configuration consisting of multiple WTPs
   communicating via the Internet Protocol (IP) to an AC.  WTPs are
   viewed as remote RF interfaces controlled by the AC.  The AC forwards
   all L2 frames to be transmitted by a WTP to that WTP via the CAPWAP
   protocol.  L2 frames from mobile nodes (STAs) are forwarded by the
   WTP to the AC using the CAPWAP protocol.  Both Split-MAC and Local
   MAC arhcitectures are supported.  Figure 1 illustrates this
   arrangement as applied to an IEEE 802.11 binding.

              +-+         802.11 frames          +-+
              | |--------------------------------| |
              | |              +-+               | |
              | |--------------| |---------------| |
              | |  802.11 PHY/ | |     CAPWAP     | |
              | | MAC sublayer | |               | |
              +-+              +-+               +-+
              STA              WTP                AC

   Figure 1: Representative CAPWAP Architecture for Split MAC

   Provisioning WTPs with security credentials, and managing which WTPs
   are authorized to provide service are traditionally handled by
   proprietary solutions.  Allowing these functions to be performed from
   a centralized AC in an interoperable fashion increases manageability
   and allows network operators to more tightly control their wireless
   network infrastructure.

1.1.  Goals

   Goals

   The goals for the CAPWAP protocol are listed below:

   1. To centralize the bridging, forwarding, authentication and policy
      enforcement functions for a wireless network.  Optionally, the AC
      may also provide centralized encryption of user traffic.
      Centralization of these functions will enable reduced cost and
      higher efficiency by applying the capabilities of network
      processing silicon to the wireless network, as in wired LANs.

   2. To enable shifting of the higher level protocol processing from
      the WTP.  This leaves the time critical applications of wireless
      control and access in the WTP, making efficient use of the
      computing power available in WTPs which are the subject to severe
      cost pressure.

   3. To provide a generic encapsulation and transport mechanism,
      enabling the CAPWAP protocol to be applied to other access point
      types in the future, via a specific wireless binding.

   The CAPWAP protocol concerns itself solely with the interface between
   the WTP and the AC.  Inter-AC, or mobile node (STA) to AC
   communication is strictly outside the scope of this document.

1.1.

1.2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

1.2.

1.3.  Contributing Authors

   This section lists and acknowledges the authors of significant text
   and concepts included in this specification.  [Note: This section
   needs work to accurately reflect the contribution of each author and
   this work will be done in revision 01 of this document.]

   The CAPWAP Working Group selected the Lightweight Access Point
   Protocol (LWAPP) [add reference, when available]to be used as the
   basis of the CAPWAP protocol specification.  The following people are
   authors of the LWAPP document:

      Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA  95134
      Phone: +1 408-853-5513, Email: bob.ohara@cisco.com

      Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA  95134
      Phone: +1 408-853-5269, Email: pcalhoun@cisco.com

      Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA  95134
      Phone: +1 408-853-5548, Email: rsuri@cisco.com

      Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA  95134
      Phone: +1 408-853-0532, Email: ncamwing@cisco.com

      Scott Kelly, Facetime Communications, 1159 Triton Dr, Foster City, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA  94404 94089
      Phone: +1 650 572-5846,  408-754-8408, Email: scott@hyperthought.com skelly@arubanetworks.com

      Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA  94043
      Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com

      Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI  48108
      Phone: +1 734 222 1610, Email: shares@nexthop.com

   DTLS is used as the security solution for the CAPWAP protocol.  The
   following people are authors of significant DTLS-related text
   included in this document:

      Scott Kelly, Facetime Communications, 1159 Triton Dr, Foster City, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA  94404 94089
      Phone: +1 650 572-5846,  408-754-8408, Email: scott@hyperthought.com skelly@arubanetworks.com

      Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303
      Email: ekr@networkresonance.com

   The concept of using DTLS to secure the CAPWAP protocol was part of
   the Secure Light Access Point Protocol (SLAPP) proposal [add
   reference when available].  The following people are authors of the
   SLAPP proposal:

      Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA  94089
      Phone: +1 408-480-4716, Email: partha@arubanetworks.com

      Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085
      Phone: +1 408 470 7372, Email: dharkins@tropos.com

      Subbu Ponnuswammy, Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA  94089
      Phone: +1 408-754-1213, Email: subbu@arubanetworks.com

   [Ed note: Additional authors to be added as required.]

1.3.

1.4.  Acknowledgements

   The authors thank Michael Vakulenko for contributing text that
   describes how CAPWAP can be used over a layer 3 (IP/UDP) network.

   The authors thank Russ Housley and Charles Clancy for their
   assistance in provide a security review of the LWAPP specification.
   Charles' review can be found at [14].

   [Ed note: Additional acknowledgements to be added as required.] [16].

2.  Protocol Overview

   The CAPWAP protocol is a generic protocol defining AC and WTP control
   and data plane communication via a CAPWAP protocol transport
   mechanism.  CAPWAP control messages, and optionally CAPWAP data
   messages
   messages, are secured using Datagram Transport Layer Security (DTLS). (DTLS)
   [14].  DTLS is a standards-track IETF protocol based upon TLS.  The
   underlying security-related protocol mechanisms of TLS have been
   successfully deployed for many years.

   The CAPWAP protocol Transport layer carries two types of payload,
   CAPWAP Data messages and CAPWAP Control messages.  CAPWAP Data
   messages are forwarded wireless frames.  CAPWAP protocol Control
   messages are management messages exchanged between a WTP and an AC.
   The CAPWAP Data and Control packets are sent over separate UDP ports.
   Since both data and control frames can exceed the PMTU, the payload
   of a CAPWAP data or control message can be fragmented.  The
   fragmentation behavior is highly dependent upon the lower layer
   transport and is defined in Section 3.

   The CAPWAP Protocol begins with a discovery phase.  The WTPs send a
   Discovery Request message, causing any Access Controller (AC)
   receiving the message to respond with a Discovery Response message.
   From the Discovery Response messages received, a WTP will select an
   AC with which to establish a secure DTLS session, using the DTLS
   initialization request message.  [MTU discovery mechanism? to
   determine the MTU supported by the network between the WTP and AC.] session.  CAPWAP protocol
   messages will be fragmented to the maximum length discovered to be
   supported by the network.

   Once the WTP and the AC have completed DTLS session establishment, a
   configuration exchange occurs in which both devices to agree on
   version information.  During this exchange the WTP may receive
   provisioning settings.  For the IEEE 802.11 binding, this information
   typically includes a name (IEEE 802.11 Service Set Identifier, SSID)
   security parameters, the data rates to be advertised and the
   associated radio channel(s) to be used.  The WTP is then enabled for
   operation.

   When the WTP and AC have completed the version and provision exchange
   and the WTP is enabled, the CAPWAP protocol is used to encapsulate
   the wireless data frames sent between the WTP and AC.  The CAPWAP
   protocol will fragment the L2 frames if the size of the encapsulated
   wireless user data (Data) or protocol control (Management) frames
   causes the resultant resulting CAPWAP protocol packet to exceed the MTU
   supported between the WTP and AC.  Fragmented CAPWAP packets are
   reassembled to reconstitute the original encapsulated payload.

   The CAPWAP protocol provides for the delivery of commands from the AC
   to the WTP for the management of mobile units (STAs) that are
   communicating with the WTP.  This may include the creation of local
   data structures in the WTP for the mobile units and the collection of
   statistical information about the communication between the WTP and
   the mobile units.  The CAPWAP protocol provides a mechanism for the
   AC to obtain statistical information collected by the WTP.

   The CAPWAP protocol provides for a keep alive feature that preserves
   the communication channel between the WTP and AC.  If the AC fails to
   appear alive, the WTP will try to discover a new AC.

   This Document uses terminology defined in [5].

2.1.  Wireless Binding Definition

   The CAPWAP protocol is independent of a specific WTP radio
   technology.  Elements of the CAPWAP protocol are designed to
   accommodate the specific needs of each wireless technology in a
   standard way.  Implementation of the CAPWAP protocol for a particular
   wireless technology must follow the binding requirements defined for
   that technology.  This specification includes a binding for the IEEE
   802.11 standard(see Section 11).

   When defining a binding for other wireless technologies, the authors
   MUST include any necessary definitions for technology-specific
   messages and all technology-specific message elements for those
   messages.  At a minimum, a binding MUST provide the definition for a
   binding-specific Statistics message element, carried in the WTP Event
   Request message, and a Mobile message element, carried in the Mobile
   Configure Request.  If technology specific message elements are
   required for any of the existing CAPWAP messages defined in this
   specification, they MUST also be defined in the technology binding
   document.

   The naming of binding-specific message elements MUST begin with the
   name of the technology type, e.g., the binding for IEEE 802.11,
   provided in this specification, begins with "IEEE 802.11"."

2.2.  CAPWAP Session Establishment Overview

   This section describes the session establishment process message
   exchanges in the ideal case.  The annotated ladder diagram shows the
   AC on the right, the WTP on the left, and assumes the use of
   certificates for DTLS authentication.  The CAPWAP Protocol State
   Machine is described in detail in Section 2.3.

           ============                         ============
               WTP                                   AC
           ============                         ============
            [----------- begin optional discovery ------------]
            Discover Request     ------>
                                 <------       Discover Response

            [----------- end optional discovery ------------]

                        (--- begin dtls handshake ---)

           ClientHello           ------>
                                 <------       HelloVerifyRequest
                                                   (with cookie)

           ClientHello           ------>
           (with cookie)
                                 <------       ServerHello
                                 <------       Certificate
                                 <------       ServerHelloDone

           (WTP callout for AC authorization)

           Certificate*
           ClientKeyExchange
           CertificateVerify*
           [ChangeCipherSpec]
           Finished              ------>

                                            (AC callout for WTP
                                              authorization)

                                               [ChangeCipherSpec]
                                 <------       Finished

                      (--- DTLS session is established now ---)

           Join Request           ------>
                                 <------       Join Response

                      ( ---assume image is up to date ---)

           Configure Request      ------->
                                 <------       Configure Response

                         (--- enter RUN state ---)

                                   :
                                   :

           Echo Request           ------->
                                 <------       Echo Response
                                   :
                                   :

           EventRequest          ------->
                                 <------       Event Response

                                   :
                                   :

   At the end of the illustrated CAPWAP message exchange, the AC and WTP
   are securely exchanging CAPWAP control messages.  This is an
   idealized illustration, provided to clarify protocol operation.
   Section 2.3 provides a detailed description of the corresponding
   state machine.

2.3.  CAPWAP State Machine Definition

   The following state diagram represents the lifecycle of a WTP-AC
   session:

              /-------------\
            |             v
            |       +------------+
            |      C|    Idle    |<---------------------------------------+
            |       +------------+                                       |
            |        ^    |a    ^                                        |
            |        |    |     \----\                 y                 |
            |        |    |          |   +-------------+------------+    |
            |        |    |          |   |             | DTLS-rekey |    |
            |        |    |          |   |  +--------->+------------+    |
            |        |    |          |   |  |                  |6        ^
            |        |    |          |t  V  | x                V         |
            |        |    |        +--------+--+       +------------+    |
            |       /     |       C|    Run    |------>| DTLS-Reset |<---|----\
   session.  Use of DTLS by the CAPWAP protocol results in the
   juxtaposition of two nominally separate yet tightly bound state
   machines.  The DTLS and CAPWAP state machines are coupled through an
   API consisting of commands (from CAPWAP to DTLS) and notifications
   (from (DTLS to CAPWAP).  Certain transitions in the DTLS state
   machine are triggered by commands from the CAPWAP state machine,
   while certain transitions in the CAPWAP state machine are triggered
   by notifications from the DTLS state machine.

   This section defines the CAPWAP Integrated State Machine.  In the
   figure below, single lines (denoted with '-' and '|') are used to
   illustrate state transitions.  Double lines (denoted with '=' and
   '"') are used to illustrate commands and notifications between DTLS
   and CAPWAP.  A line composed of '~' characters is used to delineate
   the boundary between nominal CAPWAP and DTLS state machine
   components.

            /-------------<----------------+--------------------\
            v                              |d                   |     /
         +------+  b+-----------+    +----------+               |       r+-----------+     u +------------+
         | Idle |-->| Discovery |--->|  Sulking |               |    /
         +------+ a +-----------+ c  +----------+               |
          ^   |aa    ^     v|       |     | |e            /----------------------\   |
          |   V     f| v            k|                      |   |
       h +--------------+  +------------+ i +------------+j |   |
      /--|    Join      |->|  Configure |-->| Image Data |  |   |
      |  +--------------+ g+------------+   +------------+  |          /----/       V   |
      |   "c1,  ^  ^   ^        m|            ^    |l       |   |
      |   "c4   "  "   "         |  C|  Discovery    /-------/    |    q|        k|           +-------+   /----/   |
      |   "     "  "   "         V    |s           v   V        |
      |   "     "  "   "   +------------+ o+------------+       |
      |  b+--------------+    +-------------+   "     "  "   "   |    Run     |->|    Reset |-+ w   |-------/
      |   "     "  "   "  n+------------+  +------------+   p
      |   "     "  "   "        "c2  ^       ^  c3"   ^
      \---"-----"--"---"--------"----"-------/    "   "     CAPWAP
   ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~
          "     "  "   "        "    "            "   "      DTLS
          v     "  "n2 \"""""\  "    "            v   "n6,n7
   /-->+------+ " W+------+  "  "    "      +------------+
   | /-| Idle |     |d     f| " C| Auth |--"~-"----"----->|  Shutdown  |-------\P
   | | +------+ "  +------+V "  "    " /--->|            |<----\ |
   | |X     Z|  "   ^  U|    "  " n4 " |  Configure    +------------+     |        +-------+ |
   | |       |  "   |   |      +-------------+    "  " n5," |         ^             |   |e    v |
   |              ^ |       v  "n1 |Y  |  +---------+  n3"  v  |i            2|  n8" |R        |Q            | | C| Sulking
   | |      +--------+  |  +------------+    +--------------+  S+------------+     | |  +---------+  C| DTLS-Init  |--->| DTLS-Complete|
   | |                +------------+ z  +--------------+      |  Init  |                   |h                         |4  \->|    Run     |<--|   Rekey    |     | |                          v                 o /
             \
   |                        +------------+-------/
              \-----------------/ | Image Data |C
                                                         +------------+n      +--------+     |            |-->|            |     | |
   | |                     +------------+T  +------------+     | |
   | \---------------------------------------------------------/ |
   \-------------------------------------------------------------/

   Figure 2: CAPWAP Integrated State Machine

   The CAPWAP protocol state machine, depicted above, is used by both
   the AC and the WTP.  In cases where states are not shared (i.e. not
   implemented in one or the other of the AC or WTP), this is explicitly
   called out in the transition descriptions below.  For every state
   defined, only certain messages are permitted to be sent and received.  In all of the
   The CAPWAP control messages defined in this document, definitions specify the state for state(s) in which
   each command
   is valid is specified.

   Note that in the state diagram figure above, the 'C' character message is
   used to represent a condition that causes the state to remain the
   same. valid.

2.3.1.  CAPWAP Protocol State Transitions

   The following text discusses the various state transitions, and the
   events that cause them.  This section does not discuss interactions
   between DTLS- and CAPWAP-specific states.  Those interactions, as
   well as DTLS-specific states and transitions, are discussed in
   subsequent sections.

   Idle to Discovery (a): This is the transition occurs once device
      initialization state. is complete.

      WTP: The WTP enters the Discovery state prior to transmitting the
         first Discovery Request message (see Section 5.1).  Upon
         entering this state, the WTP sets the DiscoveryInterval timer
         (see Section 12). 4.5).  The WTP resets the DiscoveryCount counter
         to zero (0) (see Section 13). 4.6).  The WTP also clears all
         information from ACs (e.g., AC Addresses) it may have received during a previous
         Discovery phase.

      AC: The AC does not need to maintain state information for the WTP upon
         reception of the Discovery Request message, but it MUST SHOULD
         respond with a Discovery Response message (see Section 5.2).

   Discovery
         This transition is a no-op for the AC.

   Idle to Discovery (b): Join (aa): This transition occurs when the WTP presents a
      DTLS ClientHello message containing a valid cookie to the AC.

      WTP: This transition is a no-op for the WTP.

      AC: The AC does not maintain state in which information until the WTP
         presents a DTLS ClientHello message containing a valid cookie.
         Upon receipt of a DTLS ClientHello message containing a valid
         cookie, the AC creates session state and transitions to the
         Join state.

   Discovery to Discovery (b): In the Discovery state, the WTP
      determines which AC to connect to.

      WTP: This event transition occurs when the DiscoveryInterval timer
         expires.
         The  If the WTP is configured with a list of ACs, it
         transmits a Discovery Request message to every AC from which the WTP it
         has not received a Discovery Response message.  For every
         transition to this event, the WTP increments the DiscoveryCount
         counter.  See Section 5.1 for more information on how the WTP
         knows the ACs to which ACs it should transmit the Discovery Request
         messages.  The WTP restarts the DiscoveryInterval timer. timer
         whenever it transmits Discovery Request messages.

      AC: This is a no-op.

   Discovery to Sulking (d): (c): This state transition occurs on a WTP when
      Discovery or connectivity to the AC fails.

      WTP: The WTP enters this state when the DiscoveryInterval timer
         expires and the DiscoveryCount variable is equal to the
         MaxDiscoveries variable (see Section 13). 4.6).  Upon entering this
         state, the WTP shall start the SilentInterval timer.  While in
         the Sulking state, all received CAPWAP protocol messages
         received shall be ignored.

      AC: This is a no-op.

   Sulking to Idle (e): (d): This state transition occurs on a WTP when it must
      restart the discovery phase.

      WTP: The WTP enters this state when the SilentInterval timer (see
         Section 12) 4.5) expires.

      AC: This is a no-op.

   Discovery to DTLS-Init (f): Join (e): This state is used by transition occurs when the WTP sends a
      ClientHello message to confirm
      its commitment to an AC the AC, confirming that it wishes to be
      provided service and
      to simultaneously establish a secure channel with that services by the AC.

         WTP: The WTP selects the best AC based either on the information it
         gathered during the Discovery Phase. Phase or on its configuration.
         It then sends a
         ClientHello JoinRequest message to its preferred AC, sets
         the WaitJoin timer, and awaits the outcome of the DTLS handshake. Join Response Message.

         AC: The AC enters this state for the given WTP upon reception
         of a ClientHello.  The AC responds by sending either the
         ServerHello or the HelloVerifyRequest to the WTP.  For the AC,
         this This is a meta-state; in actuality, it remains in the Discovery
         state.  To do otherwise resuls in loss of the stateless nature
         of no-op for the cookie exchange.

   DTLS-Init AC.

   Join to Idle (h): Discovery (f): This state transition is used when the DTLS
      Initialization process failed.

      WTP: This state transition occurs if to return the
      WTP is unable to
         successfully establish a DTLS session.

      AC: This state transition occurs if the AC is unable to
         successfully establish a DTLS session.

   DTLS-Init to Discovery (i): This state transition is used to return
      the WTP to discovery mode when an unresponsive AC is encountered.

      WTP: The WTP enters re-enters the Discovery state when the DTLS handshake
         fails. WaitJoin timer
         expires.

      AC: This state transition is invalid.

   DTLS-Init to DTLS-Complete (z): This state transition is used to
      indicate DTLS session establishment.

      WTP: The DTLS-Complete state is entered when the WTP receives the
         Finished message from the AC.

      AC: The DTLS-Complete state is entered when the AC receives the
         Finished mesage from the WTP.

   DTLS-Complete a no-op.

   Join to Configure (2): (g): This state transition is used by the WTP and
      the AC to exchange configuration information.

      WTP: The WTP enters the Configure state when it successfully
         completes DTLS session establishment and the Join operation.  If it determines that its
         version number and the version number advertised by the AC are
         the same.  The same, the WTP transmits the Configure Request message(see
         Section 7.2) Configuration Status message
         (see Section 8.2) to the AC with a snapshot of its current
         configuration.  The WTP also starts the ResponseTimeout timer
         (see Section 12). ).  (Section 4.5) If the version numbers are not the same,
         the WTP will immediately transition to Image Data state (see
         transition (i)).

      AC: This state transition occurs when immediately after the AC
         transmits the Join Response message to the WTP.  If the AC
         receives the
         Configure Request Configuration Status message from the WTP.  The WTP, the AC
         must transmit a
         Configure Configuration Status Response message(see
         Section 7.3) 8.3) to the WTP, and may include specific message
         elements to override the WTP's configuration.  If the AC
         instead receives the Image Data Request from the WTP, it
         immediately transitions to the Image Data state (see transition
         (i)).

   Join to Reset (h): This state transition occurs when the WaitJoin
      Timer expires.

      WTP: The state transition occurs when the WTP WaitJoin timer
         expires, or upon DTLS negotiation failure.

      AC: Thise state transition occurs when the AC WaitJoin timer
         expires, or or upon DTLS Complete negotiation failure.

   Configure to Image Data (4): (i): This state transition is used by the WTP
      and the AC to download executable firmware.

      WTP: The WTP enters the Image Data state when it successfully
         comletes DTLS session establishment, and determines that its
         version number and the version number advertised by the AC are
         different.  The WTP transmits the Image Data Request (see
         Section 8.1) 9.1) message requesting that a download of the AC's
         latest firmware be initiated.

      AC: This state transition occurs when the AC receives the Image
         Data Request message from the WTP.  The AC must transmit an
         Image Data Response message(see message (see Section 8.2) 9.2) to the WTP, which
         includes a portion of the firmware.

   Image Data to Image Data (n): (j): The Image Data state is used by WTP and
      the AC during the firmware download phase.

      WTP: The WTP enters the Image Data state when it receives a an Image
         Data Response message indicating that the AC has more data to
         send.

      AC: This state transition occurs when the AC receives the Image
         Data Request message from the WTP while already in the Image
         Data state, and it detects that the firmware download has not
         completed.

   Configure to DTLS-Reset Reset (k): This state transition is used to reset the DTLS
      connection to the AC prior to restarting the WTP with a new
      configuration.

      WTP: The WTP enters the DTLS-Reset Reset state when it determines that a
         new configuration
         reset of the WTP is required. required, due to the characteristics of a
         new configuration.

      AC: The AC transitions to the DTLS-Reset Reset state when it receives the DTLS
         connection tear-down is complete.
         DTLSPeerDisconnect (n7) notification.

   Image Data to DTLS-Reset (o): Reset (l): This state transition is used to reset the
      DTLS connection prior to restarting the WTP after an image
      download.

      WTP: The When an image download completes, the WTP enters the DTLS-Reset Reset
         state, and terminates the DTLS connection, sending a
         DTLSShutdown command to the DTLS state when image download
         completes. machine.

      AC: The AC enters the DTLS-Reset Reset state upon receipt of TLS
         Finished message from the WTP. a DTLSIdle (n6)
         notification.

   Configure to Run (q): (m): This state transition occurs when the WTP and
      AC enter their normal state of operation.

      WTP: The WTP enters this state when it receives a successful
         Configure
         Configuration Status Response message from the AC.  The WTP
         initializes the HeartBeat Timer timer (see Section 12), 4.5), and
         transmits the Change State Event Request message (see
         Section 7.6). 8.6).

      AC: This state transition occurs when the AC receives the Change
         State Event Request message (see Section 7.6) 8.6) from the WTP.
         The AC responds with a Change State Event Response (see
         Section 7.7) 8.7) message.  The AC must start the
         NeighborDeadInterval timer (see Section 12). 4.5).

   Run to Run (r): (n): This is the normal state of operation.

      WTP: This is the WTP's normal state of operation.  There are many
         events that result this state transition:

         Configuration Update: The WTP receives a Configuration Update
            Request message(see Section 7.4). 8.4).  The WTP MUST respond with
            a Configuration Update Response message (see Section 7.5). 8.5).

         Change State Event: The WTP receives a Change State Event
            Response message, or determines that it must initiate a
            Change State Event Request message, as a result of a failure
            or change in the state of a radio.

         Echo Request: The WTP receives an Echo Request message (see
            Section 6.1), 7.1), to which it MUST respond with an Echo Response
            message(see Section 6.2). 7.2).

         Clear Config Indication: The WTP receives a Clear Config
            Indication message (see Section 7.8). 8.8).  The WTP MUST reset
            its configuration back to manufacturer defaults.

         WTP Event: The WTP generates a WTP Event Request message to
            send information to the AC (see Section 8.5). 9.5).  The WTP
            receives a WTP Event Response message from the AC (see
            Section 8.6). 9.6).

         Data Transfer: The WTP generates a Data Transfer Request
            message to the AC (see Section 8.7). 9.7).  The WTP receives a
            Data Transfer Response message from the AC (see
            Section 8.8). 9.8).

         WLAN Config Request: The WTP receives a WLAN Config Request
            message (see Section 11.8.1), 11.7.1), to which it MUST respond with
            a WLAN Config Response message (see Section 11.8.2). 11.7.2).

         Mobile Config Request: The WTP receives a Mobile Config Request
            message (see Section 9.1), 10.1), to which it MUST respond with a
            Mobile Config Response message (see Section 9.2). 10.2).

      AC: This is the AC's normal state of operation:

         Configuration Update: The AC sends a Configuration Update
            Request message (see Section 7.4) 8.4) to the WTP to update its
            configuration.  The AC receives a Configuration Update
            Response message (see Section 7.5) 8.5) from the WTP.

         Change State Event: The AC receives a Change State Event
            Request message (see Section 7.6), 8.6), to which it MUST respond
            with the Change State Event Response message (see
            Section 7.7). 8.7).

         Echo: The AC sends an Echo Request message Section 6.1) 7.1 or
            receives the corresponding Echo Response message (see message, see
            Section 6.2) 7.2 from the WTP.

         Clear Config Indication: The AC sends a Clear Config Indication
            message (see Section 7.8). 8.8).

         WLAN Config: The AC sends a WLAN Config Request message (see
            Section 11.8.1) 11.7.1) or receives the corresponding WLAN Config
            Response message (see Section 11.8.2) 11.7.2) from the WTP.

         Mobile Config: The AC sends a Mobile Config Request message
            (see Section 9.1) 10.1) or receives the corresponding Mobile
            Config Response message (see Section 9.2) 10.2) from the WTP.

         Data Transfer: The AC receives a Data Transfer Request message
            from the AC (see Section 8.7) 9.7) and MUST generate a
            corresponding Data Transfer Response message (see
            Section 8.8). 9.8).

         WTP Event: The AC receives a WTP Event Request message from the
            AC (see Section 8.5) 9.5) and MUST generate a corresponding WTP
            Event Response message (see Section 8.6). 9.6).

   Run to Idle (t): Reset(o): This event occurs state transition is used when an error occurs in the
      communication between the AC or WTP and
      wish to tear down the AC. connection.  This may occur as part of
      normal operation, or due to error conditions.

      WTP: The WTP enters the Idle Reset state when it initiates orderly
         termination of the DTLS connection, or when the underlying
         reliable transport in is unable to transmit a message within the
         RetransmitInterval timer (see timer, see Section 12), and 4.5 The WTP also enters
         the maximum
         number of RetransmitCount counter has reached Reset state upon receiving a DTLS session termination
         message (DTLS alert) from the MaxRetransmit
         variable (see Section 13). AC.  The WTP sends a DTLSReset
         command to the DTLS state machine.

      AC: The AC enters the Idle state when it initiates orderly
         termination of the DTLS connection, or when the underlying
         reliable transport in is unable to transmit a message within the
         RetransmitInterval timer (see Section 12), 4.5), and the maximum
         number of RetransmitCount counter has reached the MaxRetransmit
         variable (see Section 13).

   Run to DTLS-Reset(u): This state transition is used to when the AC or
      WTP wish to tear down the connection.

      WTP: The WTP enters the DTLS-Reset state when it initiates orderly
         termination of the DTLS connection; The WTP sends a TLS
         Finished message to the AC.

      AC: 4.6).  The AC also enters the DTLS-Reset Reset state
         upon receipt of receiving a TLS
         Finished DTLS session termination message from the WTP.

   Run

   Reset to DTLS-Rekey (x): Idle (p): This state transition occurs when the state
      machine is used to initiate restarted following a new DTLS
      handshake.  Either system restart, an unrecoverable
      error on the WTP AC-WTP connection, or orderly session teardown.

      WTP: The WTP clears any state associated with any AC may initiate and enters
         the state
      transition.  DTLS protected CAPWAP packets may continue to flow
      while a new handshake is being performed.  Because packets may be
      reordered, records encrypted under the new cipher suite may be
      received before one side receives the ChangeCipherSpec from the
      other side. Idle state.

      AC: The epoch value in the DTLS record header allows the data from the
      two associations/cryptographic states to be distinguished.
      Implementations SHOULD retain the AC clears any state for the old association
      until it is likely that all old records have been received or
      dropped, e.g., for associated with the maximum packet lifetime.  If WTP and enters the
         idle state.

   Run to Image Data (s): This state is
      dropped too early, transition occurs when the only effect will be that some data is lost,
      which is a condition that systems running over unreliable
      protocols need AC
      transmits an Image Data Request to consider in any case.

      Because the new handshake is performed over the existing DTLS
      association, both sides can be confident that the handshake was
      properly initiated and was not tampered with.  All data is
      protected under either WTP, with the old or new keys--and these can be
      distinguished Initiate
      Download message element.  The means by both the epoch and the authentication (MAC)
      verification.  Thus, there is no period during which data the AC decides to
      download firmware is
      unprotected. undefined, but could occur through an
      administrative action.

      WTP: The WTP enters the DTLS-Rekey state when either (1) a rekey
         is required, or (2) the AC initiates a DTLS handshake.

      AC: The AC enters the DTLS-Rekey this state when either (1) a rekey is
         required, or (2) the WTP initiates a DTLS handshake.

   DTLS-rekey it receives an an Image Data
         Request to Run (y): This event occurs when the DTLS rehandshake is
      completed.

      WTP: This state transition occurs when WTP, with the Initiate Download message element.
         The WTP completes responds by transmitting an Image Data Request with the DTLS
         rehandshake.
         Image Filename message element included..

      AC: This state transition occurrs occurs when the AC completed decides that an WTP
         is to update its firmware by sending an Image Data Request to
         the DTLS
         rehandshake.

   DTLS-rekey WTP, with the Initiate Download message element.

2.3.2.  CAPWAP to Reset (6): This event occurs when DTLS Commands

   Four commands are defined for the CAPWAP to DTLS rehandshake
      exchange phase times out.

      WTP: API.  These
   "commands" are conceptual, and may be implemented as one or more
   function calls.  This state transition occurs when the WTP does not
         successfully complete API definition is provided to clarify
   interactions between the DTLS rehandshake phase.

      AC: This and CAPWAP components of the integrated
   CAPWAP state transition occurs when machine.

   Below is a list of the AC does not successfully
         complete minimal command API:

   o  c1: DTLSStart is sent to the DTLS rehandshake phase.

   DTLS-Reset to Reset (v): This state transition is used module to complete cause a DTLS session tear-down.

      WTP: The WTP enters
      to be established.

   o  c2: DTLSRehandshake is sent to the Reset state when it has completed DTLS
         session clean-up, and it module to cause initiation
      of a rehandshake (DTLS rekey).

   o  c3: DTLSShutdown is ready sent to complete the CAPWAP
         protocol session clean-up.

      AC: The AC enters the Reset state when it has completed DTLS module to cause session clean-up, and it
      teardown.

   o  c4: DTLSAbort is ready sent to complete the CAPWAP
         protocol session clean-up.

   Reset DTLS module to Idle (w): This event occurs cause session teardown
      when the state machine is
      restarted.

      WTP: The WTP reboots.  After reboot WaitJoin timer expires.

2.3.3.  DTLS to CAPWAP Notifications

   Eight notifications are defined for the WTP will start its DTLS to CAPWAP
         state machine API.  These
   "notifications" are conceptual, and may be implemented in the Idle state.

      AC: The AC clears any state associated with the WTP.  The AC
         generally does this numerous
   ways (e.g. as a result of function return values).  This API definition is
   provided to clarify interactions between the reliable link layer
         timing out.

2.3.  Use of DTLS in and CAPWAP
   components of the integrated CAPWAP Protocol

   DTLS state machine.

   Below is used as a tightly-integrated secure wrapper for the CAPWAP
   protocol.  Certain errors may occur during the DTLS negotiation
   and/or the resulting session; list of the following section describes those,
   along with handling requirements.  It API notifications:

   o  n1: DTLSInitFailure is important sent to note that the CAPWAP protocol, being the controlling entity for the DTLS session,
   must establish its own timers outside of DTLS (e.g.  WaitJoin), and
   is responsible for terminating sessions which timeout.  DTLS
   implements a retransmission backoff timer, but will not terminate a
   session unless instructed module to do so.

2.3.1.  DTLS Error Handling Requirements

   DTLS uses all of the same handshake messages and flows as TLS, with
   three principal changes:

   1.  A stateless cookie exchange has been added indicate an
      initialization failure, which may be due to prevent denial out of
       service attacks.

   2.  Modifications memory or other
      internal error condition.

   o  n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the handshake header have been made
      CAPWAP module to handle
       message loss, reordering, and fragmentation

   3.  Retransmission timers indicate peer authentication or authorization
      failures, respectively.

   o  n3: DTLSEstablished is sent to handle message loss have been added.

   Each of these features can cause the DTLS session CAPWAP module to fail, as
   discussed below.  For reference, an illustration of indicate that
      that a normal DTLS
   session establishment (in this particular case, using certificates
   for authentication) is as follows:

            Client (WTP)                         Server (AC)
            ------------                         ------------
            ClientHello           ------>

                                  <-----        HelloVerifyRequest
                                                (contains cookie)

            ClientHello           ------>
            (with cookie)
                                  <------       ServerHello (seq=1)
                                  <------       Certificate (seq=2)
                                  <------       ServerHelloDone (seq=3)
            Certificate*
            ClientKeyExchange
            CertificateVerify*
            [ChangeCipherSpec]
            Finished               ------>

                                                [ChangeCipherSpec]
                                   <------      Finished

2.3.2.  DTLS Cookie Exchange Failure

   The cookie exchange is optional in DTLS.  For use with the CAPWAP
   protocol, it secure channel now exists.

   o  n4: DTLSEncapFailure may not be required if the network on which the AC and
   WTP reside is entirely within the same administrative domain.
   However, if AC-WTP communications traverse multiple administrative
   domains, the cookie exchange SHOULD sent to CAPWAP to indicate an
      encapsulation failure.  DTLSDecapFailure may be supported.  There are three
   potential points of sent to CAPWAP to
      indicate an encryption/authentication failure in Hello exchange, assuming cookies are
   used:

   o  The AC does not respond  n5: DTLSRehandshake is sent to the ClientHello (this may occur
      independently of cookie usage)

   o  The WTP does not respond CAPWAP module to the HelloVerifyRequest indicate DTLS
      rehandshake initiation by peer.

   o  The ClientHello contains an invalid cookie

   In determining appropriate error handling behavior for any of these
   cases, it  n6: DTLSIdle is important sent to remember that the stateless cookie
   implements a defense mechanism from the point of view of CAPWAP module to indicate that session
      abort (as requested by CAPWAP) is complete; this occurs when the AC.
   That is, it
      WaitJoin timer expires, or when CAPWAP is explictly designed executing an orderly
      session shutdown.

   o  n7: DTLSPeerDisconnect is sent to minimize AC-side processing
   prior the CAPWAP module to verifying indicate
      DTLS session teardown by peer.  Note that the WTP n7 notification, can receive
      be received while in the Join, Configure, Image Data, Run and respond
      Reset states, and always causes a transition to packets at the specified address.  Hence, any processing associated with this
   mechanism SHOULD Reset state.

   o  n8: DTLSReassemblyFailure may be minimized.

   In the case of AC non-responsiveness sent to the ClientHello, the WaitJoin
   timer will eventually expire.  When this occurs, the WTP SHOULD log
   an error message and choose an alternative AC if one exists, or
   return CAPWAP module to
      indicate DTLS fragment reassembly failure.

2.3.4.  DTLS State Transitions

   This section describes the CAPWAP protocol Discovery state.

   In transitions in the case DTLS-specific portion
   of WTP non-responsiveness to the HelloVerifyRequest, state machine.

   Idle to Init (Z): This transition indicates the
   DTLS implementation purposely does not set begining of a timer (the
   HelloVerifyRequest DTLS
      session.

      WTP: The state ransition is stateless triggered by design).  This means that DTLS
   itself will provide no indication receipt of WTP non-responsiveness.  To
   mitigate this, the AC MAY log a message when sending a
   HelloVerifyRequest, DTLSStart
         command from the CAPWAP state machine, and SHOULD log causes the WTP to
         send a message upon DTLS ClientHello to the AC.

      AC: The state transition is triggered by receipt of a valid
   corresponding ClientHello.  In this way, optional external detection
   of non-responsive WTP's can be used to troubleshoot such problems
   using data the DTLSStart
         command from the CAPWAP state machine.  The AC alone.  In reality, administrators will
   typically have access starts the
         WaitJoin timer and awaits reception of a DTLS ClientHello
         message

   Init to Authenticate/Authorize (Y) This transition indicates that the
      DTLS handshake is in progress.

      WTP: The WTP logs as well, making detection executes this state transition upon receipt of such
   problems straightforward.

   In case a
         valid ServerHello.

      AC: The AC executes this transition upon receipt of a certificate
         payload (if configured for public key authentication) or upon
         receipt of the ClientKeyExchange payload if configured for
         preshared keys.

   Init to Idle(X) This state transition occurs upon timeout of an invalid cookie in the ClientHello,
      WaitJoin Timer.

      WTP: Upon receiving a DTLSAbort command from the AC MUST
   terminate CAPWAP state
         machine, the WTP DTLS handshake, returing state machine transitions to Discovery Idle state.  A DTLS
   alert MAY be sent to the WTP indicating

      AC: Upon receiving a DTLSAbort command from the failure.

2.3.3.  DTLS Re-Assembly Failure

   Since DTLS handshake messages are potentially larger than CAPWAP state
         machine, the maximum
   record size, AC DTLS supports fragmenting state machine transitions to Idle state.

   Authenticate/Authorize to Authenticate/Authorize (W) This state
      transition is a Loopback state, representing execution of the TLS
      handshake messages across
   multiple records.  There are several potential causes of re-assembly
   errors, protocol, including overlapping and/or lost fragments.  The DTLS
   implementation should return an error authorization callbacks to the
      CAPWAP protocol
   implementation when such errors occur.  The precise error value is an
   API issue, architecture.

      WTP: Upon receiving AC credential, attempt to execute associated
         validation, authentication, and hence is beyond authorization callbacks.  Note
         that credentials may span protocol messages, in which case the scope of
         WTP will remain in this document. state pending receipt of all credential
         payloads.

      AC: Upon receipt of such an error, the CAPWAP WTP credential, attempt to execute
         associated validation, authentication, and authorization
         callbacks.  Note that credentials may span protocol implementation SHOULD
   log an appropriate error message.  Whether processing continues or messages,
         in which case the AC will remain in this state pending receipt
         of all credential payloads.

    Authenticate/Authorize to Shutdown (V) This state transition
      indicates a failure of the DTLS session is terminated is implementation dependent.

3.  CAPWAP Transport

   The CAPWAP protocol uses UDP as handshake.

      WTP: Send a transport, and can be used with
   IPv4 DTLSAuthenticateFail or IPv6.  This section details DTLSAuthorizeFail to the specifics
         CAPWAP state machine, depending on the exact cause of how the CAPWAP
   protocol works in conjunction with IP.

3.1.  UDP Transport

   Communication between
         error.  May send a WTP and an DTLS notification to the AC is established according to indicate
         failure.

      AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the
   standard UDP client/server model.  One CAPWAP
         state machine, depending on the exact cause of the CAPWAP requirements is error.  May
         send a DTLS Notification to allow the AC to indicate failure.

   Authenticate/Authorize to Run (U) This state transition occurs upon
      successful completion of the DTLS handshake.

      WTP: Send a WTP DTLSEstablished notification to reside behind the CAPWAP state
         machine.

      AC: Send a firewall and/or Network Address
   Translation (NAT) device.  Since DTLSEstablished notification to the connection CAPWAP state
         machine.

   Run to Rekey (T) This state transition occurs when a DTLS rehandshake
      is in progress; this is initiated by the
   WTP (client) to the well-known UDP port of when either (a) the AC (server), DTLS state
      machine receives the use
   of UDP is DTLSRehandshake command from CAPWAP, or (b) a logical choice.
      DTLS rehandshake message is received from the peer..

      WTP: If CAPWAP protocol issued a DTLSRehandshake command, initiate
         rehandshake with the peer; note that control packets sent between traffic may
         continue to flow using existing secure association.  If the WTP and
         rehandshake is initiated by the AC use
   well known UDP port 12222. peer, send a DTLSRehandshake
         notification to CAPWAP.

      AC: If CAPWAP protocol data packets sent between
   the WTP and issued a DTLSRehandshake command, initiate
         rehandshake with the AC use UDP port [to be IANA assigned].

3.2.  AC Discovery

   A WTP and an AC will frequently not reside in peer; note that control traffic may
         continue to flow using existing secure association.  If the same IP subnet
   (broadcast domain).  When this occurs,
         rehandshake is initiated by the WTP must be capable peer, send a DTLSRehandshake
         notification to CAPWAP.

   Run to Shutdown (S) This state transition indicates a shutdown of
   discovering the AC, without requiring that multicast services are
   enabled in the network.
      DTLS channel.

      WTP: This section describes how state transition occurs when the CAPWAP state machine
         sends a DTLSShutdown command, or when the the AC discovery is
   performed by WTPs.

   As terminates the
         DTLS session.

      AC: This state transition occurs when CAPWAP state machine sends a
         DTLSShutdown command, or when the WTP attempts terminates the DTLS
         session.

    Rekey to establish communication with an AC, it sends Run (R) This state transition indicates the Discovery Request message and successful
      completion of a DTLS rehandshake.

      WTP: This state transition occurs when the WTP receives the corresponding response DTLS
         Finished message from the AC(s).  The WTP must send AC, completing the Discovery Request DTLS re-handshake.

      AC: This state transition occurs when the AC sends a DTLS Finished
         message to either the limited broadcast IP address (255.255.255.255),
   a well known multicast address or WTP, completing the DTLS re-handshake.

   Rekey to Shutdown (Q) This state transition indicates the unicast IP address failure of
      the
   AC.  Upon receipt of DTLS rekey operation.

      WTP: This state transition occurs when there is a failure in the Discovery Request message,
         rehandshake negotiation with the AC issues AC.

      AC: This state transition occurs when there is a
   Discovery Response message to failure in the unicast IP address of
         rehandshake negotiation with the WTP,
   regardless WTP.

   Shutdown to Idle (P) This state transition occurs upon transmission
      of whether the Discovery Request message was sent as a
   broadcast, multicast DTLS Session termination message, or unicast message.

   WTP use upon receipt of a limited IP broadcast, multicast or unicast IP address is
   implementation dependent.

   When a DTLS
      session termination message.

      WTP: This state transition occurs after the WTP transmits a Discovery Request message to a unicast
   address, the DTLS
         session termination message.  If the WTP must first obtain receives a DTLS
         session termination message, it sends the IP address of DTLSPeerDisconnect
         notification to CAPWAP and moves to the AC.  Any
   static configuration of an AC's IP address on Idle state.

      AC: This state transition occurs after the WTP non-volatile
   storage is implementation dependent.  However, additional dynamic
   schemes are possible, for example:

   DHCP: A comma delimited ASCII encoded list of AC IP addresses is
      embedded in the DHCP vendor specific option 43 extension.  An
      example of the actual format of transmits the vendor specific payload for
      IPv4 is of DTLS
         session termination message.  If the form "10.1.1.1, 10.1.1.2".

   DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or
      more AC addresses.

3.3.  Fragmentation/Reassembly

   While fragmentation and reassembly services are provided by IP, the
   CAPWAP protocol also provides such services.  Environments where receives a DTLS session
         termination message, it sends the
   CAPWAP protocol is used involve firewall, Network Address Translation
   (NAT) and "middle box" devices, which tend to drop IP fragments in
   order DTLSPeerDisconnect
         notification to minimize possible Denial of Service attacks.  By providing
   fragmentation CAPWAP and reassembly at the application layer, any
   fragmentation required due moves to the tunneling component Idle state.

2.4.  Use of DTLS in the CAPWAP
   protocol becomes transparent to these intermediate devices.
   Consequently, the CAPWAP protocol Protocol

   DTLS is not impacted by any network
   configurations.

4.  CAPWAP Packet Formats

   This section contains the CAPWAP protocol packet formats.  A CAPWAP
   protocol packet consists of a CAPWAP Transport Layer packet header
   followed by used as a CAPWAP message.  The CAPWAP message can be either of
   type Control or Data, where Control packets carry signaling, and Data
   packets carry user payloads.  The CAPWAP frame formats tightly-integrated, secure wrapper for the CAPWAP
   Data packets, and for
   protocol.  In this document DTLS encapsulated CAPWAP Data and Control
   packets. CAPWAP are discussed as shown below:

      CAPWAP Data Packet :
       +--------------------------------+
       | IP  |UDP  | CAPWAP | Wireless  |
       | Hdr |Hdr  | Header | Payload   |
       +--------------------------------+

       CAPWAP + Optional DTLS Data Packet Security:
       +------------------------------------------------+
       | IP  |UDP |
   nominally distinct entitites; however they are very closely coupled,
   and may even be implemented inseparably.  Since there are DTLS  | CAPWAP  | Wireless |
   library implementations currently available, and since security
   protocols (e.g.  IPsec, TLS) are often implemented in widely
   available acceleration hardware, it is both convenient and forward-
   looking to maintain a modular distinction in this document.

   This section describes a detailed walk-through of the interactions
   between the DTLS   |
       | Hdr |Hdr | Hdr   | Hdr     | Payload  | Trailer|
       +------------------------------------------------+
                   \--authenticated-----------/
                           \---     encrypted-----------/ module and the CAPWAP Control Packet module, via 'commands' (CAPWAP
   to DTLS) and 'notifications' (DTLS Security Required):
       +-----------------------------------------------------------+
       | IP  |UDP | to CAPWAP) as they would be
   encountered during the normal course of operation.

2.4.1.  DTLS | CAPWAP | Control | Message    | Handshake Processing

   Details of the DTLS    |
       | Hdr |Hdr | Hdr  | Header | Header  | Element(s) | Trailer |
       +-----------------------------------------------------------+
                   \-------authenticated-----------------/
                          \------------encrypted-------------------/

   UDP: All CAPWAP packets handshake process are encapsulated within UDP.  Section
      Section 3.1 defines specified in [DTLS].  This
   section describes the specific UDP usage.

   CAPWAP Header: All CAPWAP protocol packets use a common header that
      immediately follows interactions between the DTLS session
   establishment process and the UDP header.  This header, is defined in
      Section 4.1.

   Wireless Payload: A CAPWAP protocol packet that contains a wireless
      payload is known as a data frame.  The CAPWAP protocol does not
      dictate protocol.  In the format of normal case,
   the wireless payload, which is defined by DTLS handshake will proceed as follows (NOTE: this example uses
   certificates, but preshared keys are also supported):

           ============                         ============
               WTP                                   AC
           ============                         ============

             ClientHello           ------>
                                 <------       HelloVerifyRequest
                                                   (with cookie)

           ClientHello           ------>
           (with cookie)
                                 <------       ServerHello
                                 <------       Certificate
                                 <------       ServerHelloDone

           (WTP callout for AC authorization)

           Certificate*
           ClientKeyExchange
           CertificateVerify*
           [ChangeCipherSpec]
           Finished              ------>

                                            (AC callout for WTP
                                              authorization)

                                               [ChangeCipherSpec]
                                 <------       Finished

   DTLS, as specified, provides its own retransmit timers with an
   exponential back-off.  However, it will never terminate the appropriate wireless standard.  Additional information handshake
   due to non-responsiveness; rather, it will continue to increase its
   back-off timer period.  Hence, timing out incomplete DTLS handshakes
   is in
      Section 4.2.

   Control Header: The CAPWAP protocol includes a signalling component,
      known as entirely the responsiblity of the CAPWAP control protocol.  All CAPWAP control packets
      include a Control Header, which is defined in Section 4.3.1.

   Message Elements: A CAPWAP Control packet includes one

2.4.1.1.  Join Operations

   The WTP, either through the Discovery process, or more
      message elements, which are found immediately following through pre-
   configuration, determines the
      control header.  These message elements are in a Type/Length/value
      style header, defined in Section 4.3.2.

4.1.  CAPWAP Transport Header

   All CAPWAP protocol messages are encapsulated using AC to connect to.  The WTP uses DTLS to
   establish a common header
   format, regardless of secure connection to the CAPWAP control or CAPWAP Data transport
   used selected AC.  Prior to carry
   initiation of the messages.  However, certain flags are not
   applicable for a given transport.  Refer to DTLS handshake, the specific transport
   section in order to determine which flags are valid.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |VER| RID |F|L|R|    Frag ID    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Status/WLANs         |   Payload...  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.1.1.  VER Field

   A 2 bit field which contains WTP sets the version WaitJoin timer.
   Upon receipt of CAPWAP used in this
   packet.  The value for this draft is 0.

4.1.2.  RID Field

   A 3 bit field which contains the Radio ID number for this packet.
   WTPs with multiple radios but a single MAC Address use this field to
   indicate which radio is associated with the packet.

4.1.3.  F Bit

   The Fragment 'F' bit indicates whether this packet is ClientHello message containing a fragment.
   When this bit is one (1), valid cookie, the packet is a fragment and MUST be
   combined with
   AC sets the other corresponding fragments WaitJoin timer.  If the Join operation has not completed
   prior to reassemble timer expiration, the
   complete information exchanged between Join process is aborted, the WTP
   transitions back to Discovery state, and AC.

4.1.4.  L Bit

   The Not Last 'L' bit is valid only if the 'F' bit is set and
   indicates whether AC transitions back to
   Idle state.  Upon successful completion of the packet contains Join process the last fragment of a
   fragmented exchange between WTP and AC.  When this bit
   WaitJoin timer is 1, deactivated.

2.4.2.  DTLS Error Handling

   If the
   packet is AC does not respond to any DTLS messages sent by the last fragment.  When this bit is 0, WTP, the packet is
   DTLS specification calls for the last fragment.

4.1.5.  R Bit

   The R bit is reserved and set WTP to 0 in this version of retransmit these messages.
   If the WaitJoin timer expires, CAPWAP
   protocol.

4.1.6.  Fragment ID

   An 8 bit field whose value is assigned will issue the DTLSAbort
   command, causing DTLS to each group of fragments
   making up terminate the handshake and remove any
   allocated session context.  Note that DTLS MAY send a complete set.  The fragment ID space is managed
   individually for every WTP/AC pair.  The value of Fragment ID is
   incremented with each new set of fragments.  The Fragment ID wraps single TLS
   Alert message to
   zero after the maximum value has been used AC to identify a set of
   fragments.  The indicate session termination.

   If the WTP does not respond to any DTLS messages sent by the AC, the
   CAPWAP protocol only supports up allows for three possiblities, listed below.  Note
   that DTLS MAY send a single TLS Alert message to 2 fragments per
   frame.

4.1.7.  Length

   The 16 bit length field contains the number of bytes AC to indicate
   session termination.

   o  The message was lost in transit; in this case, the Payload.
   The field is encoded as an unsigned number.

4.1.8.  Status and WLANS WTP will re-
      transmit its last outstanding message, since it did not receive
      the reply.

   o  The interpretation of WTP sent a DTLS Alert, which was lost in transit; in this 16 bit field is binding specific.  Refer
   to
      case, the transport portion of AC's WaitJoin timer will expire, and the binding for a specific wireless
   technology for session will be
      terminated.

   o  Communication with the definition of WTP has completely failed; in this field.

4.1.9.  Payload

   This field contains case,
      the header AC's WaitJoin timer will expire, and the session will be
      terminated.

   The DTLS specification provides for a CAPWAP Data Message or CAPWAP
   Control Message, followed by retransmission of unacknowledged
   requests.  If retransmissions remain unacknowledged, the WaitJoin
   timer will eventually expire, at which time the data associated with that message.

4.2.  CAPWAP Data Messages

   A CAPWAP protocol data message is module will
   terminate the session.

   If a forwarded wireless frame. cookie fails to validate, this could represent a WTP error, or
   it could represent a DoS attack.  Hence, AC resource utilization
   SHOULD be minimized.  The
   CAPWAP protocol defines two different modes of encapsulations; IEEE
   802.3 and native wireless.  IEEE 802.3 encapsulation requires that AC MAY log a message indicating the bridging function be performed in
   failure, but SHOULD NOT attempt to reply to the WTP.  An IEEE 802.3
   encapsulated user payload frame has

   Since DTLS handshake messages are potentially larger than the following format:

       +------------------------------------------------------+
       | IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
       +------------------------------------------------------+ maximum
   record size, DTLS supports fragmenting of handshake messages across
   multiple records.  There are several potential causes of re-assembly
   errors, including overlapping and/or lost fragments.  The DTLS module
   MUST send a DTLSReassemblyFailure notification to CAPWAP.  Whether
   precise information is given along with notification is an
   implementation issue, and hence is beyond the scope of this document.
   Upon receipt of such an error, the CAPWAP protocol also defines implementation
   SHOULD log an appropriate error message.  Whether processing
   continues or the native wireless encapsulation
   mode.  The actual format DTLS session is terminated is implementation
   dependent.

   DTLS decapsulation errors consist of three types: decryption errors,
   and authentication errors, and malformed DTLS record headers.  Since
   DTLS authenticates the encapsulated CAPWAP data frame prior to encapsulation, if decryption
   fails, it is
   subject difficult to detect this without first attempting to
   authenticate the rules defined under the specific wireless technology
   binding.  As packet.  If authentication fails, a consequence, each wireless technology binding decryption error
   is also likely, but not guaranteed.  Rather than attempt to derive
   (and require the implementation of) algorithms for detecting
   decryption failures, these are reported as authentication failures.
   The DTLS module MUST
   define provide a section entitled "Payload encapsulation", which defines DTLSDecapFailure notification to
   CAPWAP when such errors occur.  If a malformed DTLS record header is
   detected, the
   format of packets SHOULD be silently discarded, and the wireless payload that receiver
   MAY log an error message.

   There is encapsulated within currently only one encapsulation error defined: MTU
   exceeeded.  As part of DTLS session establishment, CAPWAP informs
   DTLS of the MTU size.  This may be dynamically modified at any time
   when CAPWAP
   Data messages.

   In sends the event that DTLSMtuUpdate command to DTLS.  DTLS returns
   this notification to CAPWAP whenever a transmission request will
   result in a packet which exceeds the encapsulated frame would exceed MTU.

2.4.3.  DTLS Rehandshake Behavior

   DTLS rekeying (known in DTLS as "rehandshake") requires special
   attention, as the transport
   layer's MTU, DTLS specification provides no rehandshake
   triggering mechanism.  Rather, the sender application (in this case, CAPWAP)
   is responsible expected to manage this for the fragmentation itself.  This section addressed
   various aspects of the
   frame, rehandshake behavior.

   One simple way to think of a DTLS session is as specified in Section 3.3.

4.3.  CAPWAP Control Messages Overview

   The CAPWAP Control protocol provides a control channel between the
   WTP and the AC.  Control messages pair of
   unidirectional channels which are divided into tightly bound together.  A useful
   analogy is the following
   distinct message types:

   Discovery: CAPWAP Discovery messages are used to identify potential
      ACs, their load and capabilities.

   WTP Configuration: The WTP Configuration messages are twisted pair used by for phone wiring, with one line per
   pair.  Then, the AC rehandshake process can be thought of using the call
   over the existing pair to push establish a specific configuration to the WTP it has call over a control
      channel with.  Messages new pair - that deal with is,
   an entirely new session is negotiated under the retrieval protection of statistics
      from the WTP also fall
   existing session.

   This sounds simple enough, yet there is operational complexity in this category.

   Mobile Session Management: Mobile session management messages are
      used by
   changing over to the AC new session.  In particular, how does each end
   know when it is safe to push specific mobile policies delete the "old" session, and switch over to
   the WTP.

   Firmware Management: Messages in new one?  If DTLS were not a datagram protocol, this category are used by would be
   simpler, but the fact that message delivery is unreliable
   significantly complicates things: when the AC to
      push a new firmware image to (the "server")
   transmits its Finished message, it cannot be sure that the WTP.

   Discovery, WTP Configuration and Mobile Session Management messages
   MUST be implemented.  Firmware Management MAY be implemented.

   In addition, technology specific bindings may introduce new control
   channel commands.

4.3.1.  Control Message Format

   All CAPWAP control messages are sent encapsulated within
   received it until the CAPWAP
   header (see Section 4.1).  Immediately following WTP transmits data on the CAPWAP header,
   is new channel.

   This fact constrains the control header, way in which has we transition to the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Message Type |    Seq Num    |      Msg Element Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Msg Element [0..N]       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.1.1.  Message Type

   The Message Type field identifies new
   session, and delete the function old one.  The WTP, upon receipt of the CAPWAP control
   message.  The valid values AC's
   Finished message for Message Type are the following:

           Description                       Value
           Discovery Request                    1
           Discovery Response                   2
           Configure Request                    3
           Configure Response                   4
           Configuration Update Request         5
           Configuration Update Response        6
           WTP Event Request                    7
           WTP Event Response                   8
           Change State Event Request           9
           Change State Event Response         10
           Echo Request                        11
           Echo Response                       12
           Unused                              13
           Image Data Request                  14
           Image Data Response                 15
           Reset Request                       16
           Reset Response                      17
           Primary Discovery Request           18
           Primary Discovery Response          19
           Data Transfer Request               20
           Data Transfer Response              21
           Clear Config Indication             22
           WLAN Config Request                 23
           WLAN Config Response                24
           Mobile Config Request               25
           Mobile Config Response              26

4.3.1.2.  Sequence Number

   The Sequence Number Field new session, immediately makes the new
   session active, and transmits no further data (e.g. echo requests,
   statistics, etc) on the old channel, and sends a TLS "user_cancelled"
   alert message on the old channel, after which the old session is an identifier value to match request/
   response packet exchanges.  When
   immediately deleted.

   The AC, sets a CAPWAP packet with DTLSSessionDelete timer, (see Section 4.5) and
   immediately makes the new session active, and transmits no further
   data (e.g. echo requests, statistics, etc) on the old channel.

   If a request TLS "user_cancelled" alert message type is received, received on the value of old
   channel, the sequence number field session delete timer is
   copied into deactivated, and the corresponding response packet.

   When session is
   deleted.

   if the dtls-session-delete timer expires, a CAPWAP control TLS "user_cancelled"
   alert message is sent, its internal sequence number
   counter transmitted on the old channel, and the session is monotonically incremented, ensuring
   deleted.

   Note that no two requests
   pending have the same sequence number.  This field will wrap back to
   zero.

4.3.1.3.  Message Element Length

   The Length field indicates the number of bytes following the Sequence
   Num field.

4.3.1.4.  Message Element[0..N]

   The message element(s) carry there is a slight possibility that some packets may be in
   flight when the information pertinent to each of session is deleted.  However, since CAPWAP provides
   reliable delivery, these packets will be retransmitted over the
   control message types.  Every control message in this specification
   specifies which message elements new
   channel.

2.4.3.1.  Peer Initiated Rehandshake Triggers

   Since key lifetimes are permitted.

4.3.2.  Message Element Format

   The message element not negotiable in DTLS, it is used to carry information pertinent to possible that a
   control message.  Every message element is identified by
   rehandshake from a peer may occur at any time, and implementations
   must be prepared for this eventuality.  Presumably, communicating
   devices will be within the Type
   field, whose numbering space is managed via IANA (see Section 16).
   The total length same domain of control.  This being the message elements
   case, overly-aggressive rekeying may be detected by simply monitoring
   logs, assuming such activity is indicated in indeed logged.  Hence,
   implementations MUST log rekey attempts as they occur, reporting the Message
   Element Length field.

   All of
   time and identifying information for the message element definitions peer.

   CAPWAP implementations MUST provide an administrative interface which
   permits specification of key lifetimes in seconds.  Also,
   implementations which wait until this document use a diagram
   similar interval has expired to begin
   the one below in order to depict its format.  Note that in
   order rehandshake process are liable to simplify this specification, these diagrams do not include encounter temporary service
   lapses on heavily loaded networks, so implementations SHOULD begin
   the header fields (Type rehandshake before the actual lifetime has elapsed.

   Given the relatively low bandwidth we might reasonably expect over a
   CAPWAP control channel and Length).  The header field values are
   defined in the Message element descriptions.

   Additional message elements may strength of modern cryptographic
   algorithms (e.g.  AES-128, 3DES, etc), it is reasonable to assume
   that lifetimes will typically be defined in separate IETF
   documents.

   The format more than 8 hours.  Given this
   assumption, a good rule of thumb for deciding when to rekey is this:
   deduct a message element uses the TLV format shown here:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Type             |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Value ...   |
     +-+-+-+-+-+-+-+-+

   Where Type (16 bit) identifies the character random number of seconds from the information
   carried in lifetime (say, between 1%
   and 5% of the Value field lifetime), and Length (16 bits) indicates begin the number rehandshake process at that
   point.  Using a random value helps avert collisions, when both sides
   initiate a rehandshake at the same time (discussed further below).

2.4.3.2.  Time Based Rehandshake Triggers

   CAPWAP implementations MUST provide an administrative interface which
   permits specification of bytes key lifetimes in seconds.  Also,
   implementations which wait until this interval has expired to begin
   the Value field.

4.3.2.1.  Generic Message Elements

   This section includes message elements that rehandshake process are not bound liable to encounter temporary service
   lapses on heavily loaded networks, so implementations SHOULD begin
   the rehandshake before the actual lifetime has elapsed.

   Given the relatively low bandwidth we might reasonably expect over a
   specific
   CAPWAP control message.

4.3.2.1.1.  Vendor Specific

   The Vendor Specific Payload channel and the strength of modern cryptographic
   algorithms (e.g.  AES-128, 3DES, etc), it is used reasonable to communicate vendor specific
   information assume
   that key lifetimes will typically be more than 8 hours.  Given this
   assumption, a good rule of thumb for deciding when to rekey is this:
   deduct a random number of seconds from the lifetime (say, between 1%
   and 5% of the WTP lifetime), and begin the AC.  The rehandshake process at that
   point.  Using a random value contains the
   following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Element ID           |   Value...    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  104 for Vendor Specific

   Length:  >= 7

   Vendor Identifier:  A 32-bit value containing the IANA assigned "SMI
      Network Management Private Enterprise Codes" [17]

   Element ID:  A 16-bit Element Identifier which is managed by the
      vendor.

   Value:  The value associated with the vendor specific element.

4.3.3.  Quality of Service

   It is recommended that CAPWAP control messages be sent by helps avert collisions, when both sides
   initiate a rehandshake at the AC
   and the WTP with same time.

2.4.3.3.  Volume Based Rehandshake Triggers

   CAPWAP implementations MUST provide an appropriate Quality administrative interface which
   permits specification of Service precedence value,
   ensuring that congestion key lifetimes in packet count.  Like time-
   based, lifetimes, implementations which wait until this interval has
   expired to begin the network minimizes occurrences of
   CAPWAP control channel disconnects.  Therefore, a Quality of Service
   enabled CAPWAP device should use:

   802.1P:  The precedence value of 7 rehandshake process may encounter temporary
   service lapses on heavily loaded networks, so implementations SHOULD be used.

   DSCP:  The DSCP tag value
   begin the rehandshake before the actual lifetime has elapsed.

   Volume-based lifetime estimation for purposes of 46 SHOULD rehandshake
   initiation is considerably more complex than time-based lifetime.  In
   addition to avoiding collisions, the maximum burst rate must be used.

5.  CAPWAP Discovery Operations

   The Discovery messages
   known, and an extimate made, assuming rehandshake packets are lost,
   etc.  Hence, we do not specify a one-size-fits-all approach here, and
   the specific algorithm used by is implementation dependent.

2.4.3.4.  Rehandshake Collisions

   A collision occurs when both sides initiate a WTP to determine which ACs rehandshake
   simultaneously.  No matter how much care is taken, rehandshake
   collisions are
   available to provide service, and a distinct possibility.  Hence, a contention
   resolution strategy is specified.

   A rehandshake collision is detected when a system receives a
   rehandshake initiation when it has one outstanding with the capabilities and load same
   peer.

   When this occurs, each side will compare its own address with that of the
   ACs.

5.1.  Discovery Request
   its peer (in network byte order).

   The Discovery Request message is used by one with the WTP to automatically
   discover potential ACs available in lower of the network. two addresses will ignore the peer's
   rehandshake message, and continue with its own rehandshake process.

   The Discovery
   Request one with the higher message provides ACs will immediately abort its current
   rehandshake, and set the DTLSRehandshake timer (see Section 4.5); if
   the peer with the primary capabilities of lower address does not complete the
   WTP.  A WTP must exchange this information to ensure subsequent
   exchanges rehandshake
   before the timer expires, the peer with the ACs higher address will re-
   initiate.

2.4.4.  DTLS EndPoint Authentication

   DTLS supports endpoint authentication with certificates or preshared
   keys.  The TLS algorithm suites for each endpoint authentication
   method are consistent described below.

2.4.4.1.  Authenticating with the WTP's functional
   characteristics.  A WTP must transmit this command even if it has a
   statically configured AC.

   Discovery Request messages MUST be sent by a WTP in the Discover
   state after waiting Certificates

   Note that only block ciphers are currently recommended for a random delay less than
   MaxDiscoveryInterval, after a WTP first comes up or is
   (re)initialized.  A WTP MUST send no more than use with
   DTLS.  To understand the maximum of
   MaxDiscoveries Discovery Request messages, waiting reasoning behind this, see [26].
   However,support for a random delay
   less than MaxDiscoveryInterval between each successive message.

   This AES counter mode encryption is to prevent an explosion of WTP Discovery Request messages.
   An example of this occurring is when many WTPs currently
   progressing in the TLS working group, and once protocol identifiers
   are powered on at available, they will be added below.  At present, the
   same time.

   Discovery Request messages following
   algorithms MUST be sent by a WTP supported when no Echo
   Response messages are received using certificates for NeighborDeadInterval and the WTP
   returns to the Idle state.  Discovery Request messages are sent after
   NeighborDeadInterval.  They MUST CAPWAP
   authentication:

   o  TLS_RSA_WITH_AES_128_CBC_SHA

   o  TLS_RSA_WITH_3DES_EDE_CBC_SHA

   The following algorithms SHOULD be sent after waiting for a random
   delay less than MaxDiscoveryInterval.  A WTP supported when using certificates:

   o  TLS_DH_RSA_WITH_AES_128_CBC_SHA
   o  TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

   The following algorithms MAY send up to be supported when using certificates:

   o  TLS_RSA_WITH_AES_256_CBC_SHA

   o  TLS_DH_RSA_WITH_AES_256_CBC_SHA

2.4.4.2.  Authenticating with Preshared Keys

   Pre-shared keys present significant challenges from a maximum
   of MaxDiscoveries Discovery Request messages, waiting security
   perspective, and for that reason, their use is strongly discouraged.
   However, [13] defines 3 different methods for authenticating with
   preshared keys:

   o  PSK key exchange algorithm - simplest method, ciphersuites use
      only symmetric key algorithms

   o  DHE_PSK key exchange algorithm - use a random
   delay less than MaxDiscoveryInterval between each successive message.

   If PSK to authenticate a Discovery Response message
      Diffie-Hellman exchange.  These ciphersuites give some additional
      protection against dictionary attacks and also provide Perfect
      Forward Secrecy (PFS).

   o  RSA_PSK key exchange algorithm - use RSA and certificates to
      authenticate the server, in addition to using a PSK.  This is not received after sending the
   maximum number
      susceptible to passive attacks.

   The first approach (plain PSK) is susceptible to passive dictionary
   attacks; hence, while this alorithm MAY be supported, special care
   should be taken when choosing that method.  In particular, user-
   readable passphrases SHOULD NOT be used, and use of short PSKs should
   be strongly discouraged.  Additionally, DHE_PSK MUST be supported,
   and RSA_PSK MAY be supported.

   The following cryptographic algorithms MUST be supported when using
   preshared keys:

   o  TLS_DHE_PSK_WITH_AES_128_CBC_SHA

   o  TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA

   The following algorithms SHOULD be supported when using preshared
   keys:

   o  TLS_DHE_PSK_WITH_AES_256_CBC_SHA

   The following algorithms MAY be supported when using preshared keys:

   o  TLS_PSK_WITH_AES_128_CBC_SHA

   o  TLS_PSK_WITH_AES_256_CBC_SHA

   o  TLS_PSK_WITH_3DES_EDE_CBC_SHA

   o  TLS_RSA_PSK_WITH_AES_128_CBC_SHA

   o  TLS_RSA_PSK_WITH_AES_256_CBC_SHA

   o  TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA

2.4.4.3.  Certificate Usage

   Validation of Discovery Request messages, the WTP enters certificates by the
   Sulking state AC and MUST wait for WTP is required so that
   only an interval equal to SilentInterval
   before sending further Discovery Request messages.

   The Discovery Request message AC may be sent as a unicast, broadcast or
   multicast message.

   Upon receiving a Discovery Request message, perform the functions of an AC will respond with and that only a Discovery Response message sent to the address in WTP may
   perform the source
   address functions of a WTP.  This restriction of functions to the received discovery request message.

   The following subsections define the message elements
   AC or WTP requires that the certificates used by the AC MUST be
   included in
   distinguishable from the Discovery Request message.

5.1.1.  Discovery Type

   The Discovery message element is certificate used to configure a WTP to operate
   in a specific mode.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     | Discovery Type|
     +-+-+-+-+-+-+-+-+

   Type:  58 for Discovery Type

   Length:  1

   Discovery Type:  An 8-bit value indicating how by the AC was discovered.
      The following values are supported:

      0 - Broadcast

      1 - Configured

5.1.2.  WTP Descriptor

   The WTP descriptor message element is used by WTP.  To accomplish
   this differentiation, the WTP to communicate
   it's current hardware/firmware configuration.  The value contains x.509v3 certificates MUST include the
   following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Hardware   Version                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Software   Version                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Boot   Version                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Max Radios  | Radios in use |    Encryption Capabilities    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  3 for WTP Descriptor

   Length:  16
   Hardware Version:  A 32-bit integer representing
   Extensions field [11] and MUST include the WTP's hardware
      version number

   Software Version:  A 32-bit integer representing NetscapeComment [15]
   extension.

   For an AC, the WTP's Firmware
      version number

   Boot Version:  A 32-bit integer representing value of the NetscapeComment extension MUST be the
   string "CAPWAP AC Device Certificate".  For a WTP, the WTP's boot loader's
      version number

   Max Radios:  An 8-bit value representing of the number
   NetscapeComment extension MUST be the string "CAPWAP WTP Device
   Certificate".

   Part of radios (where
      each radio the CAPWAP certificate validation process includes ensuring
   that the proper string is identified via included in the RID field) supported by NetscapeComment extension,
   and only allowing the CAPWAP session to be established if the
   extension does not represent the same role as the device validating
   the certificate.  For instance, a WTP

   Radios in use:  An 8-bit value representing MUST NOT accept a certificate
   whose NetscapeComment field is set to "CAPWAP WTP Device
   Certificate".

3.  CAPWAP Transport

   The CAPWAP protocol uses UDP as a transport, and can be used with
   IPv4 or IPv6.  This section details the number specifics of radios
      present how the CAPWAP
   protocol works in conjunction with IP.

3.1.  UDP Transport

   Communication between a WTP and an AC is established according to the
   standard UDP client/server model.  One of the CAPWAP requirements is
   to allow a WTP

   Encryption Capabilities:  This 16-bit field to reside behind a firewall and/or Network Address
   Translation (NAT) device.  Since the connection is used initiated by the
   WTP to
      communicate it's capabilities (client) to the AC.  Since most WTP's support
      link layer encryption, well-known UDP port of the AC may make (server), the use
   of these services.
      There are binding dependent encryption capabilities. UDP is a logical choice.

   CAPWAP protocol control packets sent between the WTP and the AC use
   well known UDP port [to be IANA assigned].  CAPWAP protocol data
   packets sent between the WTP and the AC use UDP port [to be IANA
   assigned].

3.2.  AC Discovery

   A WTP that
      does and an AC will frequently not have any encryption capabilities would set reside in the same IP subnet
   (broadcast domain).  When this field to
      zero (0).  Refer to occurs, the specific binding for further specification WTP must be capable of
   discovering the Encryption Capabilities field.

5.1.3.  WTP Radio Information

   The WTP radios information message element AC, without requiring that multicast services are
   enabled in the network.  This section describes how AC discovery is used
   performed by WTPs.

   As the WTP attempts to communicate establish communication with an AC, it sends
   the
   radio information in a specific slot.  The Discovery Request MUST
   include one such message element per radio in and receives the WTP. corresponding response
   message from the AC(s).  The Radio-
   Type field is used by WTP must send the AC in order to determine which technology
   specific binding is Discovery Request
   message to be used with either the WTP.

   The value contains two fields, as shown.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |           Radio Type          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  4 for WTP Radio Information

   Length:  3

   Radio ID:  The Radio Identifier, which typically refers limited broadcast IP address (255.255.255.255),
   a well known multicast address or to an
      interface index on the WTP
   Radio Type:  The type unicast IP address of radio present.  Note this bitfield can be
      used to specify support for more than a single type the
   AC.  Upon receipt of PHY/MAC.
      The following values are supported:

      1 - 802.11b:  An IEEE 802.11b radio.

      2 - 802.11a:  An IEEE 802.11a radio.

      4 - 802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE 802.11n radio.

      65535 - all:  Used the Discovery Request message, the AC issues a
   Discovery Response message to specify all radios in the WTP.

5.1.4. unicast IP address of the WTP,
   regardless of whether the Discovery Request message was sent as a
   broadcast, multicast or unicast message.

   WTP MAC Type

   The use of a limited IP broadcast, multicast or unicast IP address is
   implementation dependent.

   When a WTP MAC-Type transmits a Discovery Request message element allows to a unicast
   address, the WTP to communicate its
   mode must first obtain the IP address of operation to the AC.  A  Any
   static configuration of an AC's IP address on the WTP that advertises support non-volatile
   storage is implementation dependent.  However, additional dynamic
   schemes are possible, for both
   modes allows the example:

   DHCP: A comma delimited ASCII encoded list of AC to select IP addresses is
      embedded in the mode to use, based on local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |   MAC Type    |
     +-+-+-+-+-+-+-+-+

   Type:  TBD for WTP MAC Type

   Length:  1

   MAC Type:  The MAC mode DHCP vendor specific option 43 extension.  An
      example of operation supported by the WTP.  The
      following values are supported

      0 - Local-MAC:  Local-MAC actual format of the vendor specific payload for
      IPv4 is of the default mode that MUST form "10.1.1.1, 10.1.1.2".

   DNS: The DNS name "CAPWAP-AC-Address" MAY be
         supported resolvable to one or
      more AC addresses.

3.3.  Fragmentation/Reassembly

   While fragmentation and reassembly services are provided by all WTPs.

      1 - Split-MAC:  Split-MAC support IP, the
   CAPWAP protocol also provides such services.  Environments where the
   CAPWAP protocol is optional, used involve firewall, Network Address Translation
   (NAT) and allows the AC "middle box" devices, which tend to receive and process native wireless frames.

      2 - Both:  WTP is capable drop IP fragments in
   order to minimize possible Denial of supporting both Local-MAC Service attacks.  By providing
   fragmentation and Split-
         MAC.

5.1.5.  WTP Frame Type

   The WTP Frame-Type message element allows reassembly at the WTP application layer, any
   fragmentation required due to communicate the tunneling modes component of operation which it supports to the AC.  A WTP that
   advertises support for all modes allows the AC CAPWAP
   protocol becomes transparent to select which mode
   will be used, based on its local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |   Frame Type  |
     +-+-+-+-+-+-+-+-+

   Type:  TBD for WTP Frame Type

   Length:  1

   Frame Type:  The Frame type specifies the encapsulation modes
      supported by the WTP.  The following values are supported

      1 - Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the MAC
         Type is set to Split-MAC.

      2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when these intermediate devices.
   Consequently, the MAC Type CAPWAP protocol is
         set to Split-MAC.

      4 - Native Bridging:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined not impacted by any network
   configurations.

4.  CAPWAP Packet Formats

   This section contains the wireless binding (see Section 4.2).

      7 - All:  The WTP is capable CAPWAP protocol packet formats.  A CAPWAP
   protocol packet consists of supporting all frame types.

5.2.  Discovery Response

   The Discovery Response message provides a mechanism for an AC to
   advertise its services to requesting WTPs.

   Discovery Response messages are sent CAPWAP Transport Layer packet header
   followed by an AC after receiving a
   Discovery Request message from a WTP.

   When a WTP receives a Discovery Response message, it MUST wait for an
   interval not less than DiscoveryInterval for receipt of additional
   Discovery Response messages.  After the DiscoveryInterval elapses,
   the WTP enters the DTLS-Init state and selects one of the ACs that
   sent a Discovery Response message and send a DTLS Handshake to that
   AC. CAPWAP message.  The following subsections define the CAPWAP message elements that MUST can be
   included in the Discovery Response Message.

5.2.1.  AC Address

   The AC address message element is used to communicate the identity either of
   the AC.
   type Control or Data, where Control packets carry signaling, and Data
   packets carry user payloads.  The value contains two fields, CAPWAP frame formats for CAPWAP
   Data packets, and for DTLS encapsulated CAPWAP Data and Control
   packets. are as shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ shown below:

      CAPWAP Data Packet :
       +--------------------------------+
       |   Reserved IP  |UDP  |                  MAC Address CAPWAP |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wireless  |                 MAC Address
       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  2 for AC Address

   Length:  7

   Reserved:  MUST be set to zero

   Mac Address:  The MAC Address of the AC

5.2.2.  AC Descriptor

   The AC payload message element is used by the AC to communicate it's
   current state.  The value contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hdr |Hdr  |   Reserved Header |                 Hardware  Version ... Payload   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       +--------------------------------+

       CAPWAP + Optional DTLS Data Packet Security:
       +------------------------------------------------+
       |     HW Ver IP  |UDP |                 Software  Version ... DTLS  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ CAPWAP  |     SW Ver Wireless |            Stations DTLS   |     Limit
       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hdr |Hdr |     Limit Hdr   |            Radios Hdr     |   Max Radio Payload  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Trailer|
       +------------------------------------------------+
                   \--authenticated-----------/
                           \---     encrypted-----------/

       CAPWAP Control Packet (DTLS Security Required):
       +-----------------------------------------------------------+
       |   Max Radio IP  |UDP |    Security DTLS |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  6 for AC Descriptor

   Length:  18

   Reserved:  MUST be set to zero
   Hardware Version:  The AC's hardware version number

   Software Version:  The AC's Firmware version number

   Stations:  The number of mobile stations currently associated with CAPWAP | Control | Message    | DTLS    |
       | Hdr |Hdr | Hdr  | Header | Header  | Element(s) | Trailer |
       +-----------------------------------------------------------+
                   \-------authenticated-----------------/
                          \------------encrypted-------------------/

   UDP: All CAPWAP packets are encapsulated within UDP.  Section
      Section 3.1 defines the AC

   Limit:  The maximum number of stations supported by specific UDP usage.

   CAPWAP Header: All CAPWAP protocol packets use a common header that
      immediately follows the AC

   Radios: UDP header.  This header, is defined in
      Section 4.1.

   Wireless Payload: A CAPWAP protocol packet that contains a wireless
      payload is known as a data frame.  The number of WTPs currently attached to CAPWAP protocol does not
      dictate the AC

   Max Radio:  The maximum number format of WTPs supported by the AC

   Security:  A 8 bit bit mask specifying the authentication credential
      type supported wireless payload, which is defined by
      the AC.  The following values are supported (see appropriate wireless standard.  Additional information is in
      Section 10):

      1 - X.509 Certificate Based

      2 - Pre-Shared Secret

5.2.3.  AC Name 4.2.

   Control Header: The AC name message element contains an ASCII representation of CAPWAP protocol includes a signalling component,
      known as the
   AC's identity.  The value is CAPWAP control protocol.  All CAPWAP control packets
      include a variable length byte string.  The
   string Control Header, which is NOT zero terminated.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     | Name ...
     +-+-+-+-+-+-+-+-+

   Type:  31 for AC Name

   Length:  > 0

   Name: defined in Section 4.3.1.

   Message Elements: A variable length ASCII string containing the AC's name

5.2.4.  WTP Manager Control IPv4 Address

   The WTP Manager CAPWAP Control IPv4 Address packet includes one or more
      message element is sent by the
   AC to elements, which are found immediately following the WTP during
      control header.  These message elements are in a Type/Length/value
      style header, defined in Section 4.4.

4.1.  CAPWAP Transport Header

   All CAPWAP protocol messages are encapsulated using a common header
   format, regardless of the discovery process and is CAPWAP control or CAPWAP Data transport
   used by the AC to
   provide the interfaces available on the AC, and the current number of
   WTPs connected.  In carry the event that multiple WTP Manager Control IPV4
   Address message elements messages.  However, certain flags are returned, the WTP is expected not
   applicable for a given transport.  Refer to perform
   load balancing across the multiple interfaces. specific transport
   section in order to determine which flags are valid.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   |                           IP Address HLEN  |F|L|W|M|            Flags            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           WTP Count          Fragment ID          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  99 for WTP Manager Control IPv4 Address

   Length:  6

   IP Address:  The IP     Frag Offset         |Rsv-2|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 (optional) Radio MAC Address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            (optional) Wireless Specific Information           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Payload ....                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version: A 4 bit field which contains the version of an interface.

   WTP Count: CAPWAP used in
      this packet.  The value for this draft is 0.

   RID: A 5 bit field which contains the Radio ID number of for this
      packet.  WTPs currently connected to the interface.

5.2.5.  WTP Manager Control IPv6 with multiple radios but a single MAC Address range
      use this field to indicate which radio is associated with the
      packet.

   HLEN: Length of CAPWAP tunnel header in 4 byte words.  (Similar to IP
      header length).  This length includes the optional headers.

   F: The WTP Manager Control IPv6 Address message element Fragment 'F' bit indicates whether this packet is sent by a fragment.
      When this bit is one (1), the
   AC packet is a fragment and MUST be
      combined with the other corresponding fragments to reassemble the
      complete information exchanged between the WTP during and AC.

   L: The Not Last 'L' bit is valid only if the discovery process 'F' bit is set and
      indicates whether the packet contains the last fragment of a
      fragmented exchange between WTP and AC.  When this bit is 1, the
      packet is not the last fragment.  When this bit is 0, the packet
      is the last fragment.

   W: The Wireless 'W' bit is used to specify whether the optional
      wireless specific information field is present in the header.  A
      value of one (1) is used to represent the fact that the optional
      header is present.

   M: The M bit is used to indicate that the Radio MAC Address optional
      header is present.  This is used to communicate the MAC address of
      the receiving radio when the native wireless packet.  This field
      MUST NOT be set to one in packets sent by the AC to
   provide the interfaces available on WTP.

   Flags: A set of reserved bits for future flags in the AC, CAPWAP header.
      All implementations complying with version zero of this protocol
      MUST set these bits to zero.

   Fragment ID: An 16 bit field whose value is assigned to each group of
      fragments making up a complete set.  The fragment ID space is
      managed individually for every WTP/AC pair.  The value of Fragment
      ID is incremented with each new set of fragments.  The Fragment ID
      wraps to zero after the maximum value has been used to identify a
      set of fragments.

   Fragment Offset: A 13 bit field that indicates where in the payload
      will this fragment belong during re-assembly.  This field is valid
      when the 'F' bit is set to 1.  The fragment offset is measured in
      units of 8 octets (64 bits).  The first fragment has offset zero.

   Reserved: The 3-bit Reserved-2 field is reserved and set to 0 in this
      version of the current number CAPWAP protocol.

   Radio MAC Address: This optional field contains the MAC address of
   WTPs connected.
      the radio receiving the packet.  This message element is useful for in packets sent
      from the WTP to
   perform load balancing across multiple interfaces. the AC, when the native wireless frame format is
      converted to 802.3 by the WTP.  This field is only present if the
      'M' bit is set.

      The field contains the basic format:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Length     |                           IP                  MAC Address                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           WTP Count           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  142 for WTP Manager Control IPv6 Address
      Length:  18

   IP Address:  The IP Address of an interface.

   WTP Count: The number of WTPs currently connected to bytes in the interface.

5.3.  Primary Discovery Request MAC Address field.  The Primary Discovery Request message length
         field is sent by present since new IEEE technologies are using 48 byte
         MAC addresses.

      MAC Address: The MAC Address of the WTP to determine
   whether its preferred (or primary) AC is available.

   A Primary Discovery Request message is sent by a WTP when it has a
   primary AC configured, and is connected to another AC. receiving radio.

   Wireless Specific Information: This
   generally occurs as a result of a failover, and is optional field contains
      technology specific information that may be used by the WTP as
   a means to discover when its primary AC becomes available.  As a
   consequence, this message carry per
      packet wireless information.  This field is only sent by a WTP when it present if the
      'W' bit is in set.

      The field contains the Run
   state. basic format:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  Wireless ID  |    Length     |             Data
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Wireless ID: The frequency wireless binding identifier.  The following
         values are defined:

         1 - : IEEE 802.11

      Length: The length of the Primary Discovery Request messages should be no
   more often than data field

      Data: Wireless specific information, whose details are defined in
         the sending of technology specific binding section.

   Payload: This field contains the Echo Request message.

   Upon receipt of header for a Discovery Request message, CAPWAP Data Message or
      CAPWAP Control Message, followed by the AC responds data associated with a
   Primary Discovery Response that
      message.

4.2.  CAPWAP Data Messages

   A CAPWAP protocol data message sent to is a forwarded wireless frame.  The
   CAPWAP protocol defines two different modes of encapsulations; IEEE
   802.3 and native wireless.  IEEE 802.3 encapsulation requires that
   the address bridging function be performed in the source
   address of WTP.  An IEEE 802.3
   encapsulated user payload frame has the received Primary Discovery Request message.

   The following subsections define the message elements that MUST be
   included in format:

       +------------------------------------------------------+
       | IP Header | UDP Header | CAPWAP Header | 802.3 Frame |
       +------------------------------------------------------+

   The CAPWAP protocol also defines the Primary Discovery message.

5.3.1.  Discovery Type native wireless encapsulation
   mode.  The Discovery Type message element actual format of the encapsulated CAPWAP data frame is
   subject to the rules defined in Section 5.1.1.

5.3.2.  WTP Descriptor

   The WTP Descriptor message element under the specific wireless technology
   binding.  As a consequence, each wireless technology binding MUST
   define a section entitled "Payload encapsulation", which defines the
   format of the wireless payload that is defined in Section 5.1.2.

5.3.3.  WTP MAC Type

   The Discovery Type message element encapsulated within the CAPWAP
   Data messages.

   In the event that the encapsulated frame would exceed the transport
   layer's MTU, the sender is defined responsible for the fragmentation of the
   frame, as specified in Section 5.1.4.

5.3.4.  WTP Frame Type 3.3.

4.3.  CAPWAP Control Messages

   The CAPWAP Control protocol provides a control channel between the
   WTP Frame Type message element is defined in Section 5.1.5.

5.3.5.  WTP Radio Information

   A WTP Radio Information message element must be present for every
   radio in and the WTP.  This AC.  Control messages are divided into the following
   distinct message element is defined in Section 5.1.3.

5.4.  Primary Discovery Response

   The Primary types:

   Discovery: CAPWAP Discovery Response message enables an AC messages are used to advertise its
   availability identify potential
      ACs, their load and services to requesting WTPs that capabilities.

   WTP Configuration: The WTP Configuration messages are configured to
   have used by the AC as its primary AC.

   Primary Discovery Response messages are sent by an AC after receiving
   a Primary Discovery Request message.

   When
      to push a specific configuration to the WTP receives a Primary Discovery Response message, it may
   establish has a CAPWAP protocol connection to its primary AC, based on control
      channel with.  Messages that deal with the configuration retrieval of statistics
      from the WTP Fallback Status message element on the
   WTP.

   The following subsections define the message elements that MUST be
   included also fall in this category.

   Mobile Session Management: Mobile session management messages are
      used by the Primary Discovery Request message.

5.4.1.  AC Descriptor

   The Discovery Type message element is defined in Section 5.2.2.

5.4.2.  AC Name

   The AC Name message element is defined in Section 5.2.3.

5.4.3.  WTP Manager Control IPv4 Address

   A WTP Radio Information message element MAY be present for every
   radio in the WTP which are reachable via IPv4.  This message element
   is defined in Section 5.2.4.

5.4.4.  WTP Manager Control IPv6 Address

   A WTP Radio Information message element must be present for every
   radio in to push specific mobile station policies to the WTP which are reachable via IPv6.  This message element
   is defined
      WTP.

   Firmware Management: Messages in Section 5.2.5.

6.  Control Channel Management

   The Control Channel Management messages this category are used by the WTP and AC to
   maintain
      push a new firmware image to the WTP.

   Discovery, WTP Configuration and Mobile Session Management messages
   MUST be implemented.  Firmware Management MAY be implemented.

   In addition, technology specific bindings may introduce new control communication channel.

6.1.  Echo Request

   The Echo Request message is a keep alive mechanism for
   channel commands.

4.3.1.  Control Message Format

   All CAPWAP control
   messages.

   Echo Request messages are sent periodically by a WTP in encapsulated within the Run state CAPWAP
   header (see Section 2.2) to determine the state of the connection between
   the WTP and 4.1).  Immediately following the AC.  The Echo Request message CAPWAP header,
   is sent by the WTP when control header, which has the Heartbeat timer expires. following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Message Type                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Seq Num    |        Msg Element Length     |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Time Stamp                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Msg Element [0..N] ...
     +-+-+-+-+-+-+-+-+-+-+-+-+

4.3.1.1.  Message Type

   The WTP MUST start its
   NeighborDeadInterval timer when Message Type field identifies the Heartbeat timer expires. function of the CAPWAP control
   message.  The Echo Request message carries no message elements.

   When an AC receives Message Type field is comprised of an Echo Request IANA Enterprise
   Number and a message it responds with an Echo
   Response message.

6.2.  Echo Response type value field.  The Echo Response message acknowledges first two byte contain
   the Echo Request message, and
   is only processed while in IANA Enterprise Number (for example, the Run state (see Section 2.2).

   An Echo Response message IEEE 802.11 IANA
   Enterprise number is sent by an AC after receiving an Echo
   Request message.  After transmitting 13277), and the Echo Response message, second two bytes contain the
   AC SHOULD reset its Heartbeat timer to expire
   Message Type value.  The message type field can be expressed as:

   Message Type = IANA Enterprise Number * 256 + Message Type Value

   The valid values for base CAPWAP Message Types are given in the value configured
   for EchoInterval.  If another table
   below:

           CAPWAP Control Message           Message Type
                                              Value
           Discovery Request                    1
           Discovery Response                   2
           Join Request                         3
           Join Response                        4
           Configuration Status                 5
           Configuration Status Response        6
           Configuration Update Request         7
           Configuration Update Response        8
           WTP Event Request                    9
           WTP Event Response                  10
           Change State Event Request          11
           Change State Event Response         12
           Echo Request                        13
           Echo Response                       14
           Image Data Request                  15
           Image Data Response                 16
           Reset Request                       17
           Reset Response                      18
           Primary Discovery Request           19
           Primary Discovery Response          20
           Data Transfer Request               21
           Data Transfer Response              22
           Clear Config Indication             23
           Mobile Config Request               24
           Mobile Config Response              25

4.3.1.2.  Sequence Number

   The Sequence Number Field is an identifier value to match request and
   response packet exchanges.  When a CAPWAP packet with a request
   message type is not received by
   the AC when received, the timer expires, value of the AC SHOULD consider sequence number field is
   copied into the WTP to be
   no longer be reachable.

   The Echo Response message carries no message elements. corresponding response packet.

   When a WTP receives an Echo Response CAPWAP control message it stops the
   NeighborDeadInterval timer, and initializes is sent, its internal sequence number
   counter is monotonically incremented, ensuring that no two requests
   pending have the Heartbeat timer same sequence number.  This field will wrap back to
   zero.

4.3.1.3.  Message Element Length

   The Length field indicates the EchoInterval.

   If number of bytes following the NeighborDeadInterval timer expires prior Sequence
   Num field.

4.3.1.4.  Flags

   The Flags field MUST be set to receiving an Echo
   Response message, the WTP enters zero.

4.3.1.5.  Time Stamp

   The Timestamp contains the Idle state.

7.  WTP Configuration Management

   Wireless Termination Point Configuration messages are used timestamp.  PRC-TODO: Details need to
   exchange configuration information between the AC be
   added here, and the WTP.

7.1.  Configuration Consistency

   The CAPWAP protocol provides flexibility in how WTP configuration is
   managed.  A WTP has two options:

   1. I am waiting for info from Dave Perkins.

4.3.1.6.  Message Element[0..N]

   The WTP retains no configuration and accepts the configuration
      provided by message element(s) carry the AC.

   2. The WTP retains information pertinent to each of the configuration
   control message types.  Every control message in this specification
   specifies which message elements are permitted.

4.3.2.  Control Message Quality of parameters provided Service

   It is recommended that CAPWAP control messages be sent by both the AC
      that are non-default values.

   If
   and the WTP opts to save configuration locally, with an appropriate Quality of Service precedence value,
   ensuring that congestion in the network minimizes occurrences of
   CAPWAP protocol
   state machine control channel disconnects.  Therefore, a Quality of Service
   enabled CAPWAP device should use the following values:

   802.1P:  The precedence value of 7 SHOULD be used.

   DSCP:  The DSCP tag value of 46 SHOULD be used.

4.4.  CAPWAP Protocol Message Elements

   This section defines the Configure state, CAPWAP Protocol message elements which allows for
   configuration exchange.  In the Configure state, the WTP sends its
   current configuration overrides are
   included in CAPWAP protocol control messages.

   Message elements are used to carry information needed in control
   messages.  Every message element is identified by the AC Type field,
   whose numbering space is managed via IANA (see Section 14).  The
   total length of the Configure Request
   message.  A configuration override is a parameter that is non-
   default.  One example message elements is that indicated in the CAPWAP protocol, Message
   Element Length field.

   All of the default
   antenna configuration is internal omni antenna.  A WTP that either
   has no internal antennas, or has been explicitly configured by the AC
   to message element definitions in this document use external antennas, sends its antenna configuration during the
   configure phase, allowing the AC to become aware of the WTP's current
   configuration.

   Once the WTP has provided its configuration to the AC, the AC sends
   its own configuration.  This allows the WTP to inherit the
   configuration and policies from the AC.

   An AC maintains a copy of each active WTP's configuration.  There is
   no need for versioning or other means diagram
   similar to identify configuration
   changes.  If a WTP becomes inactive, the AC MAY delete the
   configuration associated with it.  If a WTP fails, and connects one below in order to a
   new AC, it provides depict its overridden configuration parameters, allowing
   the new AC to be aware of the WTP's configuration.

   This model allows for resiliency in case of an AC failure, format.  Note that
   another AC can provide service to the WTP.  In this scenario, the new
   AC would be automatically updated with WTP configuration changes,
   eliminating the need for inter-AC communication or the need for all
   ACs to be aware of the configuration of all WTPs in the network.

   Once the CAPWAP protocol enters the Run state, the WTPs begin to
   provide service.  It is quite common for administrators to require
   that configuration changes be made while the network is operational.

   Therefore, the Configuration Update Request is sent by the AC to the
   WTP
   order to make simplify this specification, these changes at run-time.

7.1.1.  Configuration Flexibility

   The CAPWAP protocol provides diagrams do not include
   the flexibility to configure and manage
   WTPs of varying design and functional characteristics.  When a WTP
   first discovers an AC, it provides primary functional information
   relating to its type of MAC header fields (Type and to the nature of frames to be
   exchanged.  The AC configures the WTP appropriately.  The AC also
   establishes corresponding internal operations to deal with the WTP
   according to its functionalities.

7.2.  Configure Request Length).  The Configure Request message is sent by a WTP to deliver its current
   configuration to its AC.

   Configure Request messages header field values are sent by a WTP while
   defined in the Configure
   state.

   The Configure Request message carries binding specific message
   elements.  Refer to the appropriate binding for the definition of
   this structure.

   When an AC receives a Configure Request message it will act upon the
   content of the packet and respond to the WTP with a Configure
   Response message.

   The Configure Request message includes multiple Administrative State
   message Elements.  There is one such message element for the WTP, and
   one message Message element per radio in the WTP.

   The following subsections define the descriptions.

   Additional message elements that MUST may be
   included defined in the Configure Request message.

7.2.1.  Administrative State separate IETF
   documents.

   The administrative event message element is used to communicate the
   state format of a particular radio.  The value contains message element uses the following
   fields. TLV format shown here:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID              Type             |  Admin State             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  27 for Administrative State

   Length:  2

   Radio ID:  An 8-bit value representing the radio to configure.  The
      Radio ID field may also include
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Value ...   |
     +-+-+-+-+-+-+-+-+

   Where Type (16 bit) identifies the value character of 0xff, which is used
      to identify the WTP itself.  Therefore, if an AC wishes to change the administrative state of a WTP, it would include 0xff information
   carried in the
      Radio ID field.

   Admin State:  An 8-bit value representing Value field and Length (16 bits) indicates the administrative state number
   of
      the radio.  The following values are supported:

      1 - Enabled

      2 - Disabled

7.2.2.  AC Name

   The AC Name message element is defined bytes in Section Section 5.2.3.

7.2.3. the Value field.

4.4.1.  AC Name with Index Descriptor

   The AC Name with Index payload message element is sent used by the AC to the WTP
   to configure preferred ACs.  The number of instances where this
   message element would be present is equal to the number of ACs
   configured on the WTP.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Index     |   AC Name...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  90 for AC Name with Index

   Length:  > 2

   Index:  The index of the preferred server (e.g., 1=primary,
      2=secondary).

   AC Name:  A variable length ASCII string containing the AC's name.

7.2.4.  WTP Board Data communicate it's
   current state.  The WTP Board Data message element is sent by the WTP to the AC and value contains information about the hardware present. following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Card ID            |         Card Revision         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          WTP Model                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Reserved    |                          WTP Model                 Hardware  Version ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP Serial Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     HW Ver    |                      WTP Serial Number                 Software  Version ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP Serial Number     SW Ver    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            Stations           |                      WTP Serial Number     Limit     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      WTP Serial Number     Limit     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Active WTPs          |                      WTP Serial Number   Max WTPs    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Ethernet MAC Address
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Max WTPs    |      Ethernet MAC Address    Security   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  50  1 for WTP Board Data AC Descriptor

   Length:  26

   Card ID:  A 2 byte  18

   Reserved:  MUST be set to zero

   Hardware Version:  The AC's hardware identifier.

   Card Revision:  A 2 byte Revision of the card.

   WTP Model:  8 byte WTP Model Number.

   WTP Serial Number:  24 byte WTP Serial Number.

   Ethernet MAC Address:  MAC Address version number

   Software Version:  The AC's Firmware version number

   Stations:  The number of mobile stations currently associated with
      the WTP's Ethernet interface.

7.2.5.  Statistics Timer AC

   Limit:  The statistics timer message element value is used maximum number of stations supported by the AC
   Active WTPs:  The number of WTPs currently attached to
   inform the WTP AC

   Max WTPs:  The maximum number of WTPs supported by the frequency which it expects to receive updated
   statistics.

      0                   1
      0 1 2 3 4 5 6 7 AC

   Security:  A 8 9 0 bit bit mask specifying the authentication credential
      type supported by the AC.  The following values are supported (see
      Section 2.4.4):

      1 - X.509 Certificate Based

      2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Statistics Timer       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  37 for Statistics Timer

   Length:  2

   Statistics Timer:  A 16-bit unsigned integer indicating the time, in
      seconds

7.2.6.  WTP Static IP Address Information - Pre-Shared Secret

4.4.2.  AC IPv4 List

   The WTP Static IP Address Information AC List message element is used by an
   AC to configure or clear a previously configured static IP address on WTP with the
   latest list of ACs in a WTP. cluster.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       AC IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Netmask                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Gateway Address[]                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Static     |
     +-+-+-+-+-+-+-+-+

   Type:  82  2 for WTP Static IP Address Information AC List

   Length:  13

   IP Address:  The IP Address to assign to the WTP.  This field is only
      valid if the static field is set to one.

   Netmask:  The IP Netmask.  This field is only valid if the static
      field is set to one.

   Gateway:  The IP address of the gateway.  This field is only valid if
      the static field is set to one.

   Netmask:  4

      The AC IP Netmask.  This field is only valid if the static
      field is set to one.

   Static: Address: An 8-bit boolean stating whether the WTP should use a static
      IP address or not.  A value of zero disables the static IP
      address, while a value array of one enables it.

7.2.7.  WTP Reboot Statistics 32-bit integers containing an AC's
      IPv4 Address.

4.4.3.  AC IPv6 List

   The WTP Reboot Statistics AC List message element is sent by the WTP used to configure a WTP with the
   AC to communicate reasons why reboots have occurred.
   latest list of ACs in a cluster.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Crash Count                       AC IP Address[]                         |    CAPWAP Initiated Count
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       AC IP Address[]                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Link Failure Count                       AC IP Address[]                         | Failure Type
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                       AC IP Address[]                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  67  3 for WTP Reboot Statistics AC IPV6 List

   Length:  7

   Crash Count:  16

      The number of reboots that have occurred due to a WTP
      crash.  A value AC IP Address: An array of 65535 implies that this information is not
      available on the WTP.

   CAPWAP Initiated Count: 32-bit integers containing an AC's
      IPv6 Address.

4.4.4.  AC Name

   The number of reboots that have occurred at
      the request of a CAPWAP protocol message, such as a change in
      configuration that required a reboot or AC name message element contains an explicit CAPWAP reset
      request.  A value ASCII representation of 65535 implies that this information is not
      available on the WTP.

   Link Failure Count:
   AC's identity.  The number of times that value is a CAPWAP protocol
      connection with an AC has failed.

   Failure Type:  The last WTP failure. variable length byte string.  The following values are
      supported:
   string is NOT zero terminated.

      0
      0 - Link Failure 1 - CAPWAP Initiated (see Section 8.3) 2 - WTP Crash

      255 - Unknown (e.g., WTP doesn't keep track of info)

7.3.  Configure Response 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     | Name ...
     +-+-+-+-+-+-+-+-+

   Type:  4 for AC Name

   Length:  > 0

   Name:  A variable length ASCII string containing the AC's name

4.4.5.  AC Name with Index

   The Configure Response AC Name with Index message element is sent by an AC and provides a
   mechanism for the AC to override a WTP's requested configuration.

   Configure Response messages are sent by an AC after receiving a
   Configure Request message.

   The Configure Response message carries binding specific message
   elements.  Refer to the appropriate binding for the definition of
   this structure.

   When a WTP receives a Configure Response message it acts upon the
   content
   to configure preferred ACs.  The number of the message, as appropriate.  If the Configure Response
   message includes a Change State Event instances where this
   message element that causes a
   change in the operational state of one of the Radio, the WTP will
   transmit a Change State Event would be present is equal to the AC, as an acknowledgement number of ACs
   configured on the
   change in state.

   The following subsections define the message elements that MUST be
   included in the Configure Response message.

7.3.1.  Decryption Error Report Period

   The Decryption Error Report Period message element value is used by
   the AC to inform the WTP how frequently it should send decryption
   error report messages.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |        Report Interval        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  38 for Decryption Error Report Period

   Length:  3

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the WTP

   Report Interval:  A 16-bit unsigned integer indicating the time, in
      seconds

7.3.2.  Change State Event

   The Change State message element is used to communicate a change in
   the operational state of a radio.  The value contains two fields, as
   shown.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |     State     |     Cause     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  26 for Change State Event

   Length:  3

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the WTP.

   State:  An 8-bit boolean value representing the state of the radio.
      A value of one disables the radio, while a value of two enables
      it.

   Cause:  In the event of a radio being inoperable, the cause field
      would contain the reason the radio is out of service.

   Cause:  In the event of a radio being inoperable, the cause field
      would contain the reason the radio is out of service.  The
      following values are supported:

      0 - Normal

      1 - Radio Failure

      2 - Software Failure

7.3.3.  CAPWAP Timers

   The CAPWAP Timers message element is used by an AC to configure
   CAPWAP timers on a WTP.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Discovery   | Echo Request     Index     |   AC Name...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  68  5 for CAPWAP Timers AC Name with Index

   Length:  > 2

   Discovery:

   Index:  The number index of seconds between CAPWAP Discovery packets,
      when the WTP is in preferred server (e.g., 1=primary,
      2=secondary).

   AC Name:  A variable length ASCII string containing the discovery mode.

   Echo Request:  The number of seconds between WTP Echo Request CAPWAP
      messages.

7.3.4. AC's name.

4.4.6.  AC IPv4 List Timestamp

   The AC List Timestamp message element is used sent by the AC to configure a WTP with synchronize the
   latest list of ACs in a cluster.
   WTP's clock.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       AC IP Address[]                           Timestamp                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  59  6 for AC List Timestamp

   Length:  4

   Timestamp:  The AC IP Address: An array of 32-bit integers containing an AC's
      IPv4 Address.

7.3.5.  AC IPv6 List current time, allowing all of the WTPs to be
      time synchronized in the format defined by Network Time Protocol
      (NTP) in RFC 1305 [10].

4.4.7.  Add MAC ACL Entry

   The AC Add MAC Access Control List (ACL) Entry message element is used
   by an AC to configure add a MAC ACL list entry on a WTP, ensuring that the WTP with
   no longer provides any service to the
   latest list of ACs MAC addresses provided in a cluster. the
   message.  The MAC Addresses provided in this message element are not
   expected to be saved in non-volatile memory on the WTP.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       AC IP Address[]                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       AC IP Address[]                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       AC IP Num of Entries|                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       AC IP                 MAC Address[]                 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  141  7 for AC IPV6 List Add MAC ACL Entry

   Length:  16  >= 7

   Num of Entries:  The AC IP number of MAC Addresses in the array.

   MAC Address:  An array of 32-bit integers containing an AC's
      IPv6 Address.

7.3.6.  WTP Fallback MAC Addresses to add to the ACL.

4.4.8.  Add Mobile Station

   The WTP Fallback Add Mobile Station message element is sent used by the AC to inform a
   WTP that it should forward traffic for a particular mobile station.
   The Add Mobile Station message element will be accompanied by
   technology specific binding information element which may include
   security parameters.  Consequently, the security parameters must be
   applied by the WTP for the particular mobile.

   Once a mobile station's policy has been pushed to
   enable or disable automatic CAPWAP fallback in the event that WTP through
   this message element, an AC may change any policies by simply sending
   a modified Add Mobile Station message element.  When a WTP
   detects its preferred AC, and is not currently connected to it. receives
   an Add Mobile Station message element for an existing mobile station,
   it must override any existing state it may have for the mobile
   station in question.  The latest Add Mobile Station message element
   data overrides any previously received messages.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+ 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Mode    Radio ID   |
     +-+-+-+-+-+-+-+-+                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  MAC Address                  |  VLAN Name...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  91  8 for WTP Fallback Add Mobile

   Length:  1

   Mode:  The  >= 7

   Radio ID:  An 8-bit value indicates representing the status of automatic CAPWAP
      fallback on radio

   MAC Address:  The mobile station's MAC Address

   VLAN Name:  An optional variable string containing the WTP.  A value of zero disables fallback, while a
      value of one enables it.  When enabled, if VLAN Name on
      which the WTP detects that
      its primary AC is available, and it is not connected to it, it
      SHOULD automatically disconnect from its current AC and reconnect to its primary.  If disabled, the WTP will locally bridge user data.  Note this field is
      only reconnect to its
      primary through manual intervention (e.g., through the Reset
      Request command).

7.3.7.  Idle Timeout valid with WTPs configured in Local MAC mode.

4.4.9.  Add Static MAC ACL Entry

   The Idle Timeout Add Static MAC ACL Entry message element is sent used by the an AC to add
   a permanent ACL entry on a WTP, ensuring that the WTP no longer
   provides any service to
   provide it with the idle timeout that it should enforce MAC addresses provided in the message.
   The MAC Addresses provided in this message element are expected to be
   saved in non-volative memory on its active
   mobile station entries. the WTP.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Timeout Num of Entries|                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  97  9 for Idle Timeout Add Static MAC ACL Entry

   Length:  4

   Timeout:  >= 7

   Num of Entries:  The current idle timeout to be enforced by the WTP.

7.4.  Configuration Update Request

   Configure Update Request messages are sent by the AC to provision the
   WTP while number of MAC Addresses in the Run state.  This is used to modify the configuration array.

   MAC Address:  An array of MAC Addresses to add to the WTP while it permanent ACL.

4.4.10.  CAPWAP Timers

   The CAPWAP Timers message element is operational.

   When used by an AC receives a Configuration Update Request message it will
   respond with a Configuration Update Response message, with the
   appropriate Result Code.

   The following subsections define the message elements included in the
   Configuration Update message.

7.4.1.  WTP Name

   The WTP Name message element is to configure
   CAPWAP timers on a variable length bye string.  The
   string is not zero terminated. WTP.

      0                   1
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+-
     | WTP Name ...
     +-+-+-+-+-+-+-+-+-

   Type:  5 for WTP Name

   Length:  0

   Timeout:  A non-zero terminated string containing the WTP name.

7.4.2.  Change State Event

   The Change State Event message element is defined in Section
   Section 7.3.2.

7.4.3.  Administrative State

   The Administrative State message element is defined in Section
   Section 7.2.1.

7.4.4.  Statistics Timer

   The Statistics Timer message element is defined in Section
   Section 7.2.5.

7.4.5.  Location Data

   The Location Data message elementis a variable length byte string
   containing user defined location information (e.g.  "Next to
   Fridge").  This information is configurable by the network
   administrator, and allows for the WTP location to be determined
   through this field.  The string is not zero terminated.

      0 8 9 0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+-
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Location ...
     +-+-+-+-+-+-+-+-+-   Discovery   | Echo Request  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  35  10 for Location Data CAPWAP Timers

   Length:  0

   Timeout:  A non-zero terminated string containing  2

   Discovery:  The number of seconds between CAPWAP Discovery packets,
      when the WTP location.

7.4.6.  Decryption Error Report Period

   The Decryption Error Report Period message element is defined in
   Section 7.3.1.

7.4.7.  AC IPv4 List

   The AC List message element is defined in Section 7.3.4.

7.4.8.  AC IPv6 List the discovery mode.

   Echo Request:  The AC List message element is defined in Section 7.3.5.

7.4.9.  Add MAC ACL Entry number of seconds between WTP Echo Request CAPWAP
      messages.

4.4.11.  Change State Event

   The Add MAC Access Control List (ACL) Entry Change State message element is used
   by an AC to add a MAC ACL list entry on communicate a WTP, ensuring that the WTP
   no longer provides any service to the MAC addresses provided change in
   the
   message. operational state of a radio.  The MAC Addresses provided in this message element are not
   expected to be saved in non-volatile memory on the WTP. value contains two fields, as
   shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|                 MAC Address[]   Radio ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     State     |                 MAC Address[]     Cause     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  65  11 for Add MAC ACL Entry Change State Event

   Length:  >= 7

   Num of Entries:  3

   Radio ID:  The number of MAC Addresses in Radio Identifier, typically refers to some interface
      index on the array.

   MAC Address: WTP.

   State:  An array 8-bit boolean value representing the state of MAC Addresses to add to the ACL.

7.4.10.  Delete MAC ACL Entry radio.
      A value of one disables the radio, while a value of two enables
      it.

   Cause:  In the event of a radio being inoperable, the cause field
      would contain the reason the radio is out of service.  The Delete MAC ACL Entry
      following values are supported:

      0 - Normal

      1 - Radio Failure

      2 - Software Failure

4.4.12.  Data Transfer Data

   The Data Transfer Data message element is used by an AC to delete a
   MAC ACL entry on a WTP, ensuring that the WTP provides service to provide
   information to the
   MAC addresses provided in the message. AC for debugging purposes.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|                 MAC Address[]
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Data Type   |                 MAC Address[]  Data Length  |    Data ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  66  12 for Delete MAC ACL Entry Data Transfer Data

   Length:  >= 7

   Num 3

   Data Type:  An 8-bit value the type of Entries: information being sent.  The number
      following values are supported:

      1 - WTP Crash Data

      2 - WTP Memory Dump

   Data Length:  Length of MAC Addresses in data field.

   Data:  Debug information.

4.4.13.  Data Transfer Mode

   The Data Transfer Mode message element is used by the array.

   MAC Address:  An array of MAC Addresses AC to delete request
   information from the ACL.

7.4.11.  Add Static MAC ACL Entry WTP for debugging purposes.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |   Data  Type   |
     +-+-+-+-+-+-+-+-+

   Type:  13 for Data Transfer Mode

   Length:  1

   Data Type:  An 8-bit value the type of information being requested.
      The Add Static MAC ACL Entry following values are supported:

      1 - WTP Crash Data

      2 - WTP Memory Dump

4.4.14.  Decryption Error Report

   The Decryption Error Report message element value is used by an AC to add
   a permanent ACL entry on a WTP, ensuring that the WTP no longer
   provides any service
   to inform the MAC addresses provided in AC of decryption errors that have occurred since the message.
   The MAC Addresses provided in
   last report.  Note that this message element error reporting mechanism is not used if
   encryption and decryption services are expected to be
   saved in non-volative memory on provided via the WTP. AC.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|   Radio ID    |Num Of Entries |      Mobile MAC Address[] Address       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Mobile MAC Address[]                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  70  14 for Add Static MAC ACL Entry Decryption Error Report

   Length:  >= 7 8

   Radio ID:  The Radio Identifier, which typically refers to an
      interface index on the WTP
   Num of Of Entries:  The  An 8-bit unsigned integer indicating the number of
      mobile MAC Addresses in the array. addresses.

   Mobile MAC Address:  An array of mobile station MAC Addresses addresses that
      have caused decryption errors.

4.4.15.  Decryption Error Report Period

   The Decryption Error Report Period message element value is used by
   the AC to add inform the WTP how frequently it should send decryption
   error report messages.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |        Report Interval        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  15 for Decryption Error Report Period

   Length:  3

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the permanent ACL.

7.4.12. WTP

   Report Interval:  A 16-bit unsigned integer indicating the time, in
      seconds

4.4.16.  Delete Static MAC ACL Entry

   The Delete Static MAC ACL Entry message element is used by an AC to delete a previously added static
   MAC ACL entry on a WTP, ensuring that the WTP provides service to the
   MAC addresses provided in the message.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Num of Entries|                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  71  16 for Delete MAC ACL Entry

   Length:  >= 7
   Num of Entries:  The number of MAC Addresses in the array.

   MAC Address:  An array of MAC Addresses to delete from the static MAC
      ACL entry.

7.4.13.  CAPWAP Timers ACL.

4.4.17.  Delete Mobile Station

   The CAPWAP Timers Delete Mobile station message element is defined in Section 7.3.3.

7.4.14.  AC Name with Index

   The used by the AC Name with Index message element is defined in Section 7.2.3.

7.4.15. to inform
   an WTP Fallback that it should no longer provide service to a particular
   mobile station.  The WTP Fallback message element is defined in Section 7.3.6.

7.4.16.  Idle Timeout

   The Idle Timeout must terminate service immediately upon
   receiving this message element is defined in Section 7.3.7.

7.4.17.  Timestamp element.

   The Timestamp transmission of a Delete Mobile Station message element is sent by could
   occur for various reasons, including for administrative reasons, as a
   result of the AC to to synchronize fact that the
   WTP's clock.

      0                   1                   2                   3
      0 mobile has roamed to another WTP, etc.

   Once access has been terminated for a given station, any future
   packets received from the mobile station must result in a
   deauthenticate message, as specified in [6].

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Timestamp    Radio ID   |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  TBD  17 for Timestamp Delete Mobile Station

   Length:  4

   Timestamp:  The AC's current time, allowing all of the WTPs to be
      time synchronized in  7

   Radio ID:  An 8-bit value representing the format defined by Network Time Protocol
      (NTP) in RFC 1305 [10].

7.5.  Configuration Update Response radio

   MAC Address:  The Configuration Update Response message is the acknowledgement
   message for the Configuration Update Request message. mobile station's MAC Address

4.4.18.  Delete Static MAC ACL Entry

   The Configuration Update Response Delete Static MAC ACL Entry message element is sent used by a WTP after
   receiving a Configuration Update Request message.

   When an AC receives to
   delete a Configure Update Response message the result
   code indicates if the WTP successfully accepted the configuration.

   The following subsections define the message elements that must be
   present in the Configuration Update message.

7.5.1.  Result Code

   The Result Code message element value is previously added static MAC ACL entry on a 32-bit integer value,
   indicating the result of WTP, ensuring
   that the request operation corresponding WTP provides service to the
   sequence number MAC addresses provided in the
   message.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Result Code Num of Entries|                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 MAC Address[]                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  2  18 for Result Code Delete Static MAC ACL Entry

   Length:  >= 7

   Num of Entries:  The number of MAC Addresses in the array.

   MAC Address:  An array of MAC Addresses to delete from the static MAC
      ACL entry.

4.4.19.  Discovery Type

   The Discovery message element is used to configure a WTP to operate
   in a specific mode.

      0
      0 1 2 3 4

   Result Code: 5 6 7
     +-+-+-+-+-+-+-+-+
     | Discovery Type|
     +-+-+-+-+-+-+-+-+

   Type:  19 for Discovery Type

   Length:  1

   Discovery Type:  An 8-bit value indicating how the AC was discovered.
      The following values are defined: supported:

      0  Success - Broadcast

      1  Failure (AC List message element MUST be present)

7.6.  Change State Event Request - Configured

4.4.20.  Duplicate IPv4 Address

   The Change State Event Request Duplicate IPv4 Address message element is used by the a WTP to inform
   the
   an AC that it has detected another IP device using the same IP
   address it is currently using.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MAC Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  20 for Duplicate IPv4 Address

   Length:  10

   IP Address:  The IP Address currently used by the WTP.

   MAC Address:  The MAC Address of a change in the operational state. offending device.

4.4.21.  Duplicate IPv6 Address

   The Change State Event Request Duplicate IPv6 Address message element is sent used by the WTP when it
   receives a Configuration Response message that includes a Change
   State Event message element.  It is also sent when the WTP detects an
   operational failure with a radio.  The Change State Event Request
   message may be sent in either the Configure or Run state (see
   Section 2.2.

   When to inform
   an AC receives a Change State Event message that it will respond with
   a Change State Event Response message and make any necessary
   modifications to internal WTP data structures.

   The following subsections define the message elements that must be
   present in has detected another host using the Change State Event Request message.

7.6.1.  Change State Event

   The Change State Event message element same IP address it
   is defined in Section 7.3.2.

7.7.  Change State Event Response currently using.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MAC Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  21 for Duplicate IPv6 Address

   Length:  22

   IP Address:  The Change State Event Response message acknowledges the Change State
   Event Request message.

   A Change State Event Response message is IP Address currently used by a WTP after receiving a
   Change State Event Request message.

   The Change State Event Response message carries no message elements.

   Its purpose is to acknowledge the receipt of the Change State Event
   Request message. WTP.

   MAC Address:  The WTP does not need to perform any special processing MAC Address of the Change
   State Event Response message.

7.8.  Clear Config Indication

   The Clear Config Indication message is used to reset a WTP's
   configuration.

   The Clear Config Indication message is sent by an AC to request that
   a WTP reset its configuration to the manufacturing default
   configuration. offending device.

4.4.22.  Idle Timeout

   The Clear Config Indication Idle Timeout message element is sent while in
   the Run CAPWAP state.

   The Clear Config Indication message carries no message elements.

   When a WTP receives a Clear Config Indication message it resets its
   configuration to the manufacturing default configuration.

8.  Device Management Operations

   This section defines CAPWAP operations responsible for debugging,
   gathering statistics, logging, and firmware management.

8.1.  Image Data Request

   The Image Data Request message is used to update firmware on the WTP.
   This message and its companion response message are used by the AC to
   ensure that the image being run on each WTP is appropriate.

   Image Data Request messages are exchanged between the WTP and the AC to download a new program image to the WTP.

   When a WTP or AC receives an Image Data Request message
   provide it will
   respond with an Image Data Response message.

   The format of the Image Data and Image Download message elements are
   described in the following subsections.

8.1.1.  Image Download

   The image download message element is sent by the WTP to the AC and
   contains the image filename.  The value is a variable length byte
   string.  The string is NOT zero terminated. idle timeout that it should enforce on its active
   mobile station entries.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Filename ...                            Timeout                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  32  22 for Image Download Idle Timeout

   Length:  >= 1

   Filename:  A variable length string containing the filename  4

   Timeout:  The current idle timeout to
      download.

8.1.2. be enforced by the WTP.

4.4.23.  Image Data

   The image data message element is present in the Image Data Request
   message sent by the AC and contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Opcode    |           Checksum            |  Image Data   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Image Data ...                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  33  23 for Image Data

   Length:  >= 4 (allows 0 length element if last data unit is 1024
      bytes)

   Opcode:  An 8-bit value representing the transfer opcode.  The
      following values are supported:

      3 - Image data is included

      5 - An error occurred.  Transfer is aborted

   Checksum:  A 16-bit value containing a checksum of the image data
      that follows

   Image Data:  The Image Data field contains 1024 characters, unless
      the payload being sent is the last one (end of file).  If the last
      block was 1024 in length, an Image Data with a zero length payload
      is sent.

8.2.

4.4.24.  Image Data Response Filename

   The Image Data Response message acknowledges the Image Data Request
   message.

   An Image Data Response image filename message element is sent in response by the WTP to a received
   Image Data Request message.  Its purpose is to acknowledge the
   receipt of the Image Data Request message.

   The Image Data Response message carries no message elements.

   No action is necessary on receipt.

8.3.  Reset Request

   The Reset Request message is used to cause a WTP to reboot.

   A Reset Request message is sent by an AC to cause a WTP to
   reinitialize its operation.

   The Reset Request carries no message elements.

   When a WTP receives a Reset Request it will respond with a Reset
   Response and then reinitialize itself.

8.4.  Reset Response

   The Reset Response message acknowledges the Reset Request message.

   A Reset Response message is sent by the WTP after receiving a Reset
   Request message.

   The Reset Response message carries no message elements.  Its purpose
   is to acknowledge the receipt of the Reset Request message.

   When an AC receives a Reset Response message, it is notified that the
   WTP will reinitialize its operation.

8.5.  WTP Event Request

   WTP Event Request message
   is used by a WTP to send information to its
   AC.  The WTP Event Request message may be sent periodically, or sent
   in response to an asynchronous event on the WTP.  For example, a WTP
   MAY collect statistics and use initiate the WTP Event Request firmware download process.  This message to
   transmit
   element contains the statistics to image filename, which the AC.

   When an AC receives a WTP Event Request message it will respond with
   a WTP Event Response message.

   The subsequently
   transfers to the WTP Event Request message MUST contain one of via the Image Data message
   elements described below, or a message element that is defined for a
   specific wireless technology.

8.5.1.  Decryption Error Report element.  The Decryption Error Report message element value
   is used by the WTP
   to inform the AC of decryption errors that have occurred since the
   last report.  Note that this error reporting mechanism a variable length byte string, which is not used if
   encryption and decryption services are provided via the AC. NOT zero terminated.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |Num Of Entries |      Mobile MAC Address       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Mobile MAC Address[]                           Filename ...                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  39  24 for Decryption Error Report Image Filename

   Length:  >= 8

   Radio ID:  The Radio Identifier, which typically refers to an
      interface index on the WTP

   Num Of Entries:  An 8-bit unsigned integer indicating 1

   Filename:  A variable length string containing the number of
      mobile MAC addresses.

   Mobile MAC Address:  An array of mobile station MAC addresses that
      have caused decryption errors.

8.5.2.  Duplicate IPv4 Address filename to
      download.

4.4.25.  Initiate Download

   The Duplicate IPv4 Address Initiate Download message element is used by a WTP the AC to inform
   an AC the
   WTP that it has detected another IP device using should initiate a firmware upgrade.  This is performed by
   having the same IP
   address it WTP initiate its own Image Data Request, with the Image
   Download message element.  This message element does not contain any
   data.

   Type:  25 for Initiate Download

   Length:  0

4.4.26.  Location Data

   The Location Data message elementis a variable length byte string
   containing user defined location information (e.g.  "Next to
   Fridge").  This information is currently using. configurable by the network
   administrator, and allows for the WTP location to be determined
   through this field.  The string is not zero terminated.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
     +-+-+-+-+-+-+-+-+-
     | Location ...
     +-+-+-+-+-+-+-+-+-

   Type:  26 for Location Data

   Length:  > 0

   Timeout:  A non-zero terminated string containing the WTP location.

4.4.27.  MTU Discovery Padding

   The MTU Discovery Padding message element is used as padding to
   perform MTU discovery, and MUST contain octets of value 0xFF, of any
   length

    0
      0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+
     |  Padding...
     +-+-+-+-+-+-+-+-

   Type:  27 for MTU Discovery Padding

   Length:  variable

   Timeout:  A variable length pad.

4.4.28.  Radio Administrative State

   The administrative event message element is used to communicate the
   state of a particular radio.  The value contains the following
   fields.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MAC Address 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Radio ID   |          MAC Address  Admin State  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  77  28 for Duplicate IPv4 Address Administrative State

   Length:  10

   IP Address:  2

   Radio ID:  An 8-bit value representing the radio to configure.  The IP Address currently
      Radio ID field may also include the value of 0xff, which is used by
      to identify the WTP.

   MAC Address:  The MAC Address WTP itself.  Therefore, if an AC wishes to change
      the administrative state of a WTP, it would include 0xff in the offending device.

8.5.3.  Duplicate IPv6 Address
      Radio ID field.

   Admin State:  An 8-bit value representing the administrative state of
      the radio.  The Duplicate IPv6 Address following values are supported:

      1 - Enabled
      2 - Disabled

4.4.29.  Result Code

   The Result Code message element value is used by a WTP 32-bit integer value,
   indicating the result of the request operation corresponding to inform
   an AC that it has detected another host using the same IP address it
   is currently using.
   sequence number in the message.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MAC Address                         Result Code                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  77  29 for Duplicate IPv6 Address Result Code

   Length:  22

   IP Address:  The IP Address currently used by the WTP.

   MAC Address:  The MAC Address of the offending device.

8.6.  WTP Event Response  4

   Result Code:  The WTP Event Response message acknowledges receipt of the WTP Event
   Request message.

   A WTP Event Response following values are defined:

      0  Success

      1  Failure (AC List message issent by an AC after receiving a WTP
   Event Request message. element MUST be present)

      2  Success (NAT detected)

      3  Failure (unspecified)

      4  Failure (Join Failure, Resource Depletion)

      5  Failure (Join Failure, Unknown Source)

      6  Failure (Join Failure, Incorrect Data)

      7  Failure (Join Failure, Session ID already in use)

4.4.30.  Session ID

   The WTP Event Response message carries no session ID message elements.

8.7.  Data Transfer Request element value contains a randomly generated
   unsigned 32-bit integer.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Session ID                                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  30 for Session ID

   Length:  4

   Session ID:  A 32-bit random session identifier

4.4.31.  Statistics Timer

   The Data Transfer Request statistics timer message element value is used to deliver debug
   information from the WTP to the AC.

   Data Transfer Request messages are sent by the WTP to the AC when the
   WTP determines that it has important information to send to the AC.
   For instance, if
   inform the WTP detects that its previous reboot was caused
   by a system crash, it can send of the crash file to the AC.  The remote
   debugger function in the WTP also uses the Data Transfer Request
   message to send console output to the AC for debugging purposes.

   When the AC receives a Data Transfer Request message frequency which it responds expects to receive updated
   statistics.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Statistics Timer       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  31 for Statistics Timer

   Length:  2

   Statistics Timer:  A 16-bit unsigned integer indicating the WTP ith a Data Transfer Response message.  The AC MAY log the
   information received.

   The Data Transfer Request message MUST contain one of the following
   message element listed below.

8.7.1.  Data Transfer Mode time, in
      seconds

4.4.32.  Vendor Specific Payload

   The Data Transfer Mode message element Vendor Specific Payload is used by the AC to request communicate vendor specific
   information from between the WTP for debugging purposes. and the AC.  The value contains the
   following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+ 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Data  Type                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Element ID           |   Value...    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  52  32 for Data Transfer Mode Vendor Specific

   Length:  1

   Data Type:  An 8-bit  >= 7

   Vendor Identifier:  A 32-bit value containing the type of information being requested. IANA assigned "SMI
      Network Management Private Enterprise Codes" [19]
   Element ID:  A 16-bit Element Identifier which is managed by the
      vendor.

   Value:  The following values are supported:

      1 - WTP Crash Data

      2 - value associated with the vendor specific element.

4.4.33.  WTP Memory Dump

8.7.2.  Data Transfer Board Data

   The Data Transfer WTP Board Data message element is used sent by the WTP to provide
   information to the AC for debugging purposes. and
   contains information about the hardware present.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Data Type                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=0                 |  Data             Length           |    Data ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=1                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Optional additional vendor specific WTP board data TLVs

   Type:  53  33 for Data Transfer WTP Board Data

   Length:  >= 3

   Data Type:  An 8-bit  >=14

   Vendor Identifier:  A 32-bit value containing the type of information being sent. IANA assigned "SMI
      Network Management Private Enterprise Codes"

   Type:  The following values are supported:

      1

      0 - WTP Crash Model Number:  The WTP Model Number MUST be included in
         the WTP Board Data

      2 message element.

      1 - WTP Memory Dump

   Data Length:  Length of data field.

   Data:  Debug information.

8.8.  Data Transfer Response Serial Number:  The Data Transfer Response message acknowledges WTP Serial Number MUST be included in
         the WTP Board Data Transfer
   Request message.

   A Data Transfer Response message is sent element.

      2 - Board ID:  A hardware identifier, which MAY be included in response to a received the
         WTP Board Data Transfer Request message.  Its purpose is to acknowledge receipt mesage element.

      3 - Board Revision  A revision number of the board, which MAY be
         included in the WTP Board Data Transfer Request message.

   The Data Transfer Response message carries no message elements.

   Upon receipt of a Data Transfer Response message, the element.

4.4.34.  WTP transmits
   more information, if more information Descriptor

   The WTP descriptor message element is available.

9.  Mobile Session Management

   Messages in this section are used by the AC a WTP to create, modify or
   delete mobile station session state on the WTPs.

9.1.  Mobile Config Request communicate
   it's current hardware/firmware configuration.  The Mobile Config Request message is used to create, modify or delete
   mobile session state on a WTP.  The message is sent by the AC to the
   WTP, and may contain one or more message elements.  The message
   elements for this CAPWAP control message include information that is
   generally highly technology specific.  Therefore, please refer to the
   appropriate binding section or document for the definitions of the
   messages elements that may be used in this control message.

9.1.1.  Add Mobile

   The Add Mobile message element is used by the AC to inform a WTP that
   it should forward traffic for a particular mobile station.  The Add
   Mobile message element will be accompanied by technology specific
   binding information element which may include security parameters.
   Consequently, the security parameters must be applied by the WTP for
   the particular mobile.

   Once a mobile station's policy has been pushed to the WTP through
   this message element, an AC may change any policies by simply sending
   a modified Add Mobile message element.  When a WTP receives an Add
   Mobile message element for an existing mobile station, it must
   override any existing state it may have for value contains the mobile station in
   question.  The latest Add Mobile overrides any previously received
   messages.
   following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   Max Radios  |                  MAC Address Radios in use |    Encryption Capabilities    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  MAC Address                       Vendor Identifier                       |  VLAN Name...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=0                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=1                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type=0                 |             Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  29  34 for Add Mobile WTP Descriptor

   Length:  >= 7

   Radio ID: 31

   Max Radios:  An 8-bit value representing the number of radios (where
      each radio
   MAC Address:  The mobile station's MAC Address

   VLAN Name: is identified via the RID field) supported by the WTP

   Radios in use:  An optional variable string containing 8-bit value representing the VLAN Name on
      which number of radios
      present in the WTP is to locally bridge user data.  Note this

   Encryption Capabilities:  This 16-bit field is
      only valid with WTPs configured in Local MAC mode.

9.1.2.  Delete Mobile

   The Delete Mobile message element is used by the AC WTP to inform an
      communicate it's capabilities to the AC.  Since most WTP's support
      link layer encryption, the AC may make use of these services.
      There are binding dependent encryption capabilities.  A WTP that it should no longer provide service
      does not have any encryption capabilities would set this field to a particular mobile
   station.
      zero (0).  Refer to the specific binding for further specification
      of the Encryption Capabilities field.

   Vendor Identifier:  A 32-bit value containing the IANA assigned "SMI
      Network Management Private Enterprise Codes"

   Type:  The following values are supported.  The Hardware Version,
      Software Version, and Boot Version values MUST be included.

      0 - WTP must terminate service immediately upon receiving
   this Model Number:  The WTP Model Number MUST be included in
         the WTP Board Data message element.

      1 - WTP Serial Number:  The transmission of a Delete Mobile message element could occur for
   various reasons, including for administrative reasons, as a result of WTP Serial Number MUST be included in
         the fact that WTP Board Data message element.

      2 - Board ID:  A hardware identifier, which MAY be included in the mobile has roamed
         WTP Board Data mesage element.

      3 - Board Revision  A revision number of the board, which MAY be
         included in the WTP Board Data message element.

      4 - Hardware Version:  A 32-bit integer representing the WTP's
         hardware version number

      5 - Software Version:  A 32-bit integer representing the WTP's
         Firmware version number

      6 - Boot Version:  A 32-bit integer representing the WTP's boot
         loader's version number

4.4.35.  WTP Fallback

   The WTP Fallback message element is sent by the AC to another WTP, etc.

   Once access has been terminated the WTP to
   enable or disable automatic CAPWAP fallback in the event that a WTP
   detects its preferred AC, and is not currently connected to it.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |     Mode      |
     +-+-+-+-+-+-+-+-+

   Type:  35 for WTP Fallback
   Length:  1

   Mode:  The 8-bit value indicates the status of automatic CAPWAP
      fallback on the WTP.  A value of zero disables fallback, while a given station, any future
   packets received
      value of one enables it.  When enabled, if the WTP detects that
      its primary AC is available, and it is not connected to it, it
      SHOULD automatically disconnect from its current AC and reconnect
      to its primary.  If disabled, the mobile must result in a deauthenticate
   message, WTP will only reconnect to its
      primary through manual intervention (e.g., through the Reset
      Request command).

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC.

      2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as specified in [6]. native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      4 - Native Bridging:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      7 - All:  The WTP is capable of supporting all frame encapsulation
         types.

4.4.37.  WTP IPv4 IP Address

   The WTP IPv4 address is used to perform NAT detection.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |                  MAC                      WTP IPv4 IP Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  30  37 for Delete Mobile WTP IPv4 IP Address

   Length:  7

   Radio ID:  An 8-bit value representing the radio

   MAC  4

   WTP IPv4 IP Address:  The mobile station's IPv4 address from which the WTP is sending
      packets.  This field is used for NAT detection.

4.4.38.  WTP MAC Address

9.2.  Mobile Config Response Type

   The Mobile Configuration Response WTP MAC-Type message is used element allows the WTP to acknowledge a
   previously received Mobile Configuration Request message, and
   includes a Result Code message element which indicates whether an
   error occurred on the WTP.

   This message requires no special processing, and is only used to
   acknowledge the Mobile Configuration Request message.

9.2.1.  Result Code

   The Result Code message element is defined in Section 7.5.1.

10.  CAPWAP Security

   This version communicate its
   mode of operation to the CAPWAP protocol uses DTLS with AC.  A WTP that advertises support for both certificate
   and shared secret based credentials to secure CAPWAP protocol
   Control, and (optionally) Data packets.  CAPWAP protocol Discovery
   Request and Discover Response messages are sent in
   modes allows the clear, as they
   are sent prior AC to esablishment of a secure DTLS session between select the mode to use, based on local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |   MAC Type    |
     +-+-+-+-+-+-+-+-+

   Type:  38 for WTP and MAC Type

   Length:  1

   MAC Type:  The MAC mode of operation supported by the AC.  Once WTP.  The
      following values are supported

      0 - Local-MAC:  Local-MAC is the DTLS session default mode that MUST be
         supported by all WTPs.

      1 - Split-MAC:  Split-MAC support is established, optional, and allows the CAPWAP
   state machine (see Section 2.2) AC
         to receive and process native wireless frames.

      2 - Both:  WTP is in the Configure state, all CAPWAP
   control frames are encrypted.

   An in-depth security analysis capable of threats supporting both Local-MAC and risks to AC-AP
   communication Split-
         MAC.

4.4.39.  WTP Radio Information

   The WTP radios information message element is beyond used to communicate the scope of this document.  The list below
   provides
   radio information in a summary of the assumptions made specific slot.  The Discovery Request MUST
   include one such message element per radio in the CAPWAP protocol
   security design:

   o  WTP-AC communications may be accessible WTP.  The Radio-
   Type field is used by the AC in order to a sophisticated
      attacker.

   o  When authentication and/or privacy of end determine which technology
   specific binding is to end traffic be used with the WTP.

   The value contains two fields, as shown.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |           Radio Type                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Radio Type    |
     +-+-+-+-+-+-+-+-+

   Type:  39 for WTP Radio Information

   Length:  5

   Radio ID:  The Radio Identifier, which typically refers to an
      interface index on the WTP

   Radio Type:  The type of radio present.  Note this bitfield can be
      used to specify support for more than a single type of PHY/MAC.
      The following values are supported:

      1 - 802.11b:  An IEEE 802.11b radio.

      2 - 802.11a:  An IEEE 802.11a radio.

      4 - 802.11g:  An IEEE 802.11g radio.

      8 - 802.11n:  An IEEE 802.11n radio.

      0xOF - 802.11b, 802.11a, 802.11g and AC 802.11n:  The 4 radio types
         indicated are intermediaries supported in the WTP.

4.4.40.  WTP Manager Control IPv4 Address

   The WTP Manager Control IPv4 Address message element is required, IPSEC [19] or
      another end sent by the
   AC to end security protocol must be used.

   o  Privacy the WTP during the discovery process and authentication for at least some WTP-AC control
      traffic is required, for example to enable secure delivery of user
      sessions keys from used by the AC to
   provide the WTP.

10.1.  Endpoint Authentication using DTLS

   Certificate-based authentication is natively supported in DTLS, interfaces available on the AC, and
   support for preshared keys has been standardized the current number of
   WTPs connected.  In the event that multiple WTP Manager Control IPV4
   Address message elements are returned, the WTP is expected to perform
   load balancing across the multiple interfaces.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           WTP Count           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  40 for WTP Manager Control IPv4 Address

   Length:  6

   IP Address:  The IP Address of an interface.

   WTP Count:  The number of WTPs currently connected to the interface.

4.4.41.  WTP Manager Control IPv6 Address

   The WTP Manager Control IPv6 Address message element is sent by the
   AC to the WTP during the discovery process and is used by the AC to
   provide the interfaces available on the AC, and the current number of
   WTPs connected.  This message element is useful for the WTP to
   perform load balancing across multiple interfaces.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           IP Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           WTP Count           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  41 for WTP Manager Control IPv6 Address

   Length:  18
   IP Address:  The IP Address of an interface.

   WTP Count:  The number of WTPs currently connected to the interface.

4.4.42.  WTP Name

   The WTP Name message element is a variable length bye string.  The
   string is not zero terminated.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+-
     | WTP Name ...
     +-+-+-+-+-+-+-+-+-

   Type:  42 for WTP Name

   Length:  variable

   WTP Name:  A non-zero terminated string containing the WTP name.

4.4.43.  WTP Reboot Statistics

   The WTP Reboot Statistics message element is sent by the WTP to the
   AC to communicate reasons why reboots have occurred.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Crash Count          |    CAPWAP Initiated Count     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Link Failure Count       | Failure Type  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  43 for WTP Reboot Statistics

   Length:  7

   Crash Count:  The number of reboots that have occurred due to a WTP
      crash.  A value of 65535 implies that this information is not
      available on the WTP.

   CAPWAP Initiated Count:  The number of reboots that have occurred at
      the request of a CAPWAP protocol message, such as a change in
      configuration that required a reboot or an explicit CAPWAP reset
      request.  A value of 65535 implies that this information is not
      available on the WTP.

   Link Failure Count:  The number of times that a CAPWAP protocol
      connection with an AC has failed.

   Failure Type:  The last WTP failure.  The following values are
      supported:

      0 - Link Failure

      1 - CAPWAP Initiated (see Section 9.3)

      2 - WTP Crash

      255 - Unknown (e.g., WTP doesn't keep track of info)

4.4.44.  WTP Static IP Address Information

   The WTP Static IP Address Information message element is used by an
   AC to configure or clear a previously configured static IP address on
   a WTP.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IP Address                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Netmask                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Gateway                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Static     |
     +-+-+-+-+-+-+-+-+

   Type:  44 for WTP Static IP Address Information

   Length:  13

   IP Address:  The IP Address to assign to the WTP.  This field is only
      valid if the static field is set to one.

   Netmask:  The IP Netmask.  This field is only valid if the static
      field is set to one.

   Gateway:  The IP address of the gateway.  This field is only valid if
      the static field is set to one.

   Netmask:  The IP Netmask.  This field is only valid if the static
      field is set to one.

   Static:  An 8-bit boolean stating whether the WTP should use a static
      IP address or not.  A value of zero disables the static IP
      address, while a value of one enables it.

4.5.  CAPWAP Protocol Timers

   A WTP or AC that implements CAPWAP discovery MUST implement the
   following timers.

4.5.1.  DiscoveryInterval

   The minimum time, in seconds, that a WTP MUST wait after receiving a
   Discovery Response, before initiating a DTLS handshake.

   Default: 5

4.5.2.  DTLSRehandshake

   The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to
   complete.

   Default: 10

4.5.3.  DTLSSessionDelete

   The minimum time, in seconds, a WTP MUST wait for DTLS session
   deletion.

   Default: 5

4.5.4.  EchoInterval

   The minimum time, in seconds, between sending echo requests to the AC
   with which the WTP has joined.

   Default: 30

4.5.5.  KeyLifetime

   The maximum time, in seconds, which a CAPWAP DTLS session key is
   valid.

   Default: 28800

4.5.6.  MaxDiscoveryInterval

   The maximum time allowed between sending discovery requests from the
   interface, in seconds.  Must be no less than 2 seconds and no greater
   than 180 seconds.

   Default: 20 seconds.

4.5.7.  NeighborDeadInterval

   The minimum time, in seconds, a WTP MUST wait without having received
   Echo Responses to its Echo Requests, before the destination for the
   Echo Request may be considered dead.  Must be no less than
   2*EchoInterval seconds and no greater than 240 seconds.

   Default: 60

4.5.8.  ResponseTimeout

   The minimum time, in seconds, which the WTP or AC must respond to a
   CAPWAP Request message.

   Default: 1

4.5.9.  RetransmitInterval

   The minimum time, in seconds, which a non-acknowledged CAPWAP packet
   will be retransmitted.

   Default: 3

4.5.10.  SilentInterval

   The minimum time, in seconds, a WTP MUST wait after failing to
   receive any responses to its discovery requests, before it MAY again
   send discovery requests.

   Default: 30

4.5.11.  WaitJoin

   The maximum time, in seconds, a WTP MUST wait without having received
   a DTLS Handshake message from an AC.  This timer must be greater than
   30 seconds.

   Default: 60

4.6.  CAPWAP Protocol Variables

   A WTP or AC that implements CAPWAP discovery MUST allow for the
   following variables to be configured by system management; default
   values are specified so as to make it unnecessary to configure any of
   these variables in many cases.

4.6.1.  DiscoveryCount

   The number of discoveries transmitted by a WTP to a single AC.  This
   is a monotonically increasing counter.

4.6.2.  MaxDiscoveries

   The maximum number of discovery requests that will be sent after a
   WTP boots.

   Default: 10

4.6.3.  MaxRetransmit

   The maximum number of retransmissions for a given CAPWAP packet
   before the link layer considers the peer dead.

   Default: 5

4.6.4.  RetransmitCount

   The number of retransmissions for a given CAPWAP packet.  This is a
   monotonically increasing counter.

5.  CAPWAP Discovery Operations

   The Discovery messages are used by a WTP to determine which ACs are
   available to provide service, and the capabilities and load of the
   ACs.

5.1.  Discovery Request Message

   The Discovery Request message is used by the WTP to automatically
   discover potential ACs available in the network.  The Discovery
   Request message provides ACs with the primary capabilities of the
   WTP.  A WTP must exchange this information to ensure subsequent
   exchanges with the ACs are consistent with the WTP's functional
   characteristics.  A WTP must transmit this command even if it has a
   statically configured AC.

   Discovery Request messages MUST be sent by a WTP in the Discover
   state after waiting for a random delay less than
   MaxDiscoveryInterval, after a WTP first comes up or is
   (re)initialized.  A WTP MUST send no more than the maximum of
   MaxDiscoveries Discovery Request messages, waiting for a random delay
   less than MaxDiscoveryInterval between each successive message.

   This is to prevent an explosion of WTP Discovery Request messages.
   An example of this occurring is when many WTPs are powered on at the
   same time.

   Discovery Request messages MUST be sent by a WTP when no Echo
   Response messages are received for NeighborDeadInterval and the WTP
   returns to the Idle state.  Discovery Request messages are sent after
   NeighborDeadInterval.  They MUST be sent after waiting for a random
   delay less than MaxDiscoveryInterval.  A WTP MAY send up to a maximum
   of MaxDiscoveries Discovery Request messages, waiting for a random
   delay less than MaxDiscoveryInterval between each successive message.

   If a Discovery Response message is not received after sending the
   maximum number of Discovery Request messages, the WTP enters the
   Sulking state and MUST wait for an interval equal to SilentInterval
   before sending further Discovery Request messages.

   The Discovery Request message may be sent as a unicast, broadcast or
   multicast message.

   Upon receiving a Discovery Request message, the AC will respond with
   a Discovery Response message sent to the address in the source
   address of the received discovery request message.

   The following message elements MUST be included in the Discovery
   Request message:

   o  Discovery Type, see Section 4.4.19

   o  WTP Descriptor, see Section 4.4.34

   o  WTP Frame Type, see Section 4.4.36

   o  WTP MAC Type, see Section 4.4.38

   o  WTP Radio Information, see Section 4.4.39

5.2.  Discovery Response Message

   The Discovery Response message provides a mechanism for an AC to
   advertise its services to requesting WTPs.

   The Discovery Response message is sent by an AC after receiving a
   Discovery Request message from a WTP.

   When a WTP receives a Discovery Response message, it MUST wait for an
   interval not less than DiscoveryInterval for receipt of additional
   Discovery Response messages.  After the DiscoveryInterval elapses,
   the WTP enters the DTLS-Init state and selects one of the ACs that
   sent a Discovery Response message and send a DTLS Handshake to that
   AC.

   The following message elements MUST be included in the Discovery
   Response Message:

   o  AC Descriptor, see Section 4.4.1

   o  AC Name, see Section 4.4.4

   o  WTP Manager Control IPv4 Address, see Section 4.4.40

   o  WTP Manager Control IPv6 Address, see Section 4.4.41

5.3.  Primary Discovery Request Message

   The Primary Discovery Request message is sent by the WTP to determine
   whether its preferred (or primary) AC is available.

   A Primary Discovery Request message is sent by a WTP when it has a
   primary AC configured, and is connected to another AC.  This
   generally occurs as a result of a failover, and is used by the WTP as
   a means to discover when its primary AC becomes available.  As a
   consequence, this message is only sent by a WTP when it is in the Run
   state.

   The frequency of the Primary Discovery Request messages should be no
   more often than the sending of the Echo Request message.

   Upon receipt of a Discovery Request message, the AC responds with a
   Primary Discovery Response message sent to the address in the source
   address of the received Primary Discovery Request message.

   The following message elements MUST be included in the Primary
   Discovery Request message.

   o  Discovery Type, see Section 4.4.19

   o  WTP Descriptor, see Section 4.4.34

   o  WTP Frame Type, see Section 4.4.36

   o  WTP MAC Type, see Section 4.4.38

   o  WTP Radio Information, see Section 4.4.39 A WTP Radio Information
      message element MUST be present for every radio in the WTP.

5.4.  Primary Discovery Response

   The Primary Discovery Response message enables an AC to advertise its
   availability and services to requesting WTPs that are configured to
   have the AC as its primary AC.

   The Primary Discovery Response message is sent by an AC after
   receiving a Primary Discovery Request message.

   When a WTP receives a Primary Discovery Response message, it may
   establish a CAPWAP protocol connection to its primary AC, based on
   the configuration of the WTP Fallback Status message element on the
   WTP.

   The following message elements MUST be included in the Primary
   Discovery Response message.

   o  AC Descriptor, see Section 4.4.1

   o  AC Name, see Section 4.4.4

   o  WTP Manager Control IPv4 Address, see Section 4.4.40

   o  WTP Manager Control IPv6 Address, see Section 4.4.41

6.  CAPWAP Join Operations

   The Join Request message is used by a WTP to request service from an
   AC after a DTLS connection is established to that AC.  The Join
   Response message is used by the the AC to indicate that it will or
   will not provide service.

6.1.  Join Request

   The Join Request message is used by a WTP to inform an AC that it
   wishes to provide services through the AC.  A Join Request message is
   sent by a WTP after receiving one or more Discovery Responses, and
   completion of DTLS session establishment.  When an AC receives a Join
   Request message it responds with a Join Response message.

   Upon completion of the DTLS handshake (synonymous with DTLS "session
   establishment"), the WTP sends the Join Request message to the AC.
   Upon receipt of the Join Request Message, the AC generates a Join
   Response message and sends it to the WTP, indicating success or
   failure.

   Upon transmission of the Join Request message, the WTP sets the
   WaitJoin timer.  If the Join Response message has not been received
   prior to expiration, the WTP aborts the Join process and transitions
   back to the Discovery state, see Section 2.3.1).  Upon receipt of the
   Join Response message, the WaitJoin timer is deactivated.

   If the AC rejects the Join Request, it sends a Join Response with a
   failure indication then enters the CAPWAP reset state, resulting in
   shutdown of the DTLS session.

   Upon determining which AC to join, the WTP creates session state
   containing the AC address and session ID, creates the Join Request
   message, sets the WaitJoin timer for the session and sends the Join
   Request message to the AC.

   If an invalid (i.e. malformed) Join Request message is received, the
   message MUST be silently discarded by the AC.  No response is sent to
   the WTP.  The AC SHOULD log this event.

   The following message elements MUST be included in the Join Request
   message.

   o  Location Data, see Section 4.4.26

   o  Session ID, see Section 4.4.30
   o  WTP Descriptor, see Section 4.4.34

   o  WTP IPv4 IP Address, see Section 4.4.37

   o  WTP Name, see Section 4.4.42

   o  WTP Radio Information, see Section 4.4.39 A WTP Radio Information
      message element MUST be present for every radio in the WTP.

6.2.  Join Response

   The Join Response message is sent by the AC to indicate to a WTP that
   it is capable and willing to provide service to it.

   After determining that a WTP should join the AC, the AC creates
   session state containing the WTP address, port and session ID, sets
   the WaitJoin timer for the session, sends the Join Response message
   to the WTP.

   The WTP, receiving a Join Response message checks for success or
   failure.  If the message indicates success, the WTP clears the
   WaitJoin timer for the session and proceeds to the Configure or Image
   Data state.  Otherwise, the WTP enters the CAPWAP reset state,
   resulting in shutdown of the DTLS session.

   If the WaitJoin Timer expires prior to reception of the Join Response
   message, the WTP MUST terminate the handshake, deallocate associated
   session state and transition to the Discover state.

   If an invalid (malformed) Join Response message is received, the WTP
   SHOULD log an informative message detailing the error.  This error
   MUST be treated in the same manner as AC non-responsiveness.  In this
   way, the WaitJoin timer will eventually expire, in which case the WTP
   may (if it is so configured) attempt to join with an alternative AC.

   The following message elements MAY be included in the Join Response
   message.

   o  Result Code, see Section 4.4.29

   o  AC IPv4 List, see Section 4.4.2

   o  AC IPv6 List, see Section 4.4.3

   o  Session ID, see Section 4.4.30

7.  Control Channel Management

   The Control Channel Management messages are used by the WTP and AC to
   maintain a control communication channel.

7.1.  Echo Request

   The Echo Request message is a keep alive mechanism for CAPWAP control
   messages.

   Echo Request messages are sent periodically by a WTP in the Run state
   (see Section 2.3) to determine the state of the connection between
   the WTP and the AC.  The Echo Request message is sent by the WTP when
   the Heartbeat timer expires.  The WTP MUST start its
   NeighborDeadInterval timer when the Heartbeat timer expires.

   The Echo Request message carries no message elements.

   When an AC receives an Echo Request message it responds with an Echo
   Response message.

7.2.  Echo Response

   The Echo Response message acknowledges the Echo Request message, and
   is only processed while in the Run state (see Section 2.3).

   An Echo Response message is sent by an AC after receiving an Echo
   Request message.  After transmitting the Echo Response message, the
   AC SHOULD reset its Heartbeat timer to expire in the value configured
   for EchoInterval.  If another Echo Request message or other control
   message is not received by the AC when the timer expires, the AC
   SHOULD consider the WTP to be no longer be reachable.

   The Echo Response message carries no message elements.

   When a WTP receives an Echo Response message it stops the
   NeighborDeadInterval timer, and initializes the Heartbeat timer to
   the EchoInterval.

   If the NeighborDeadInterval timer expires prior to receiving an Echo
   Response message, or other control message, the WTP enters the Idle
   state.

8.  WTP Configuration Management

   Wireless Termination Point Configuration messages are used to
   exchange configuration information between the AC and the WTP.

8.1.  Configuration Consistency

   The CAPWAP protocol provides flexibility in how WTP configuration is
   managed.  A WTP has two options:

   1. The WTP retains no configuration and accepts the configuration
      provided by the AC.

   2. The WTP retains the configuration of parameters provided by the AC
      that are non-default values.

   If the WTP opts to save configuration locally, the CAPWAP protocol
   state machine defines the Configure state, which allows for
   configuration exchange.  In the Configure state, the WTP sends its
   current configuration overrides to the AC via the Configuration
   Status message.  A configuration override is a parameter that is non-
   default.  One example is that in the CAPWAP protocol, the default
   antenna configuration is internal omni antenna.  A WTP that either
   has no internal antennas, or has been explicitly configured by the AC
   to use external antennas, sends its antenna configuration during the
   configure phase, allowing the AC to become aware of the WTP's current
   configuration.

   Once the WTP has provided its configuration to the AC, the AC sends
   its own configuration.  This allows the WTP to inherit the
   configuration and policies from the AC.

   An AC maintains a copy of each active WTP's configuration.  There is
   no need for versioning or other means to identify configuration
   changes.  If a WTP becomes inactive, the AC MAY delete the
   configuration associated with it.  If a WTP fails, and connects to a
   new AC, it provides its overridden configuration parameters, allowing
   the new AC to be aware of the WTP's configuration.

   This model allows for resiliency in case of an AC failure, that
   another AC can provide service to the WTP.  In this scenario, the new
   AC would be automatically updated with WTP configuration changes,
   eliminating the need for inter-AC communication or the need for all
   ACs to be aware of the configuration of all WTPs in the network.

   Once the CAPWAP protocol enters the Run state, the WTPs begin to
   provide service.  It is quite common for administrators to require
   that configuration changes be made while the network is operational.

   Therefore, the Configuration Update Request is sent by the AC to the
   WTP to make these changes at run-time.

8.1.1.  Configuration Flexibility

   The CAPWAP protocol provides the flexibility to configure and manage
   WTPs of varying design and functional characteristics.  When a WTP
   first discovers an AC, it provides primary functional information
   relating to its type of MAC and to the nature of frames to be
   exchanged.  The AC configures the WTP appropriately.  The AC also
   establishes corresponding internal operations to deal with the WTP
   according to its functionalities.

8.2.  Configuration Status

   The Configuration Status message is sent by a WTP to deliver its
   current configuration to its AC.

   Configuration Status messages are sent by a WTP while in the
   Configure state.

   The Configuration Status message carries binding specific message
   elements.  Refer to the appropriate binding for the definition of
   this structure.

   When an AC receives a Configuration Status message it will act upon
   the content of the packet and respond to the WTP with a Configuration
   Status Response message.

   The Configuration Status message includes multiple Administrative
   State message Elements.  There is one such message element for the
   WTP, and one message element per radio in the WTP.

   The following message elements MUST be included in the Configuration
   Status message.

   o  AC Name, see Section 4.4.4

   o  AC Name with Index, see Section 4.4.5

   o  Radio Administrative State, see Section 4.4.28

   o  Statistics Timer, see Section 4.4.31

   o  WTP Board Data, see Section 4.4.33

   o  WTP Static IP Address Information, see Section 4.4.44
   o  WTP Reboot Statistics, see Section 4.4.43

8.3.  Configuration Status Response

   The Configuration Status Response message is sent by an AC and
   provides a mechanism for the AC to override a WTP's requested
   configuration.

   Configuration Status Response messages are sent by an AC after
   receiving a Configure Request message.

   The Configuration Status Response message carries binding specific
   message elements.  Refer to the appropriate binding for the
   definition of this structure.

   When a WTP receives a Configuration Status Response message it acts
   upon the content of the message, as appropriate.  If the
   Configuration Status Response message includes a Change State Event
   message element that causes a change in the operational state of one
   of the Radio, the WTP will transmit a Change State Event to the AC,
   as an acknowledgement of the change in state.

   The following message elements MUST be included in the Configuration
   Status Response message.

   o  AC IPv4 List, see Section 4.4.2

   o  AC IPv6 List, see Section 4.4.3

   o  CAPWAP Timers, see Section 4.4.10

   o  Change State Event, see Section 4.4.11

   o  Decryption Error Report Period, see Section 4.4.15

   o  Idle Timeout, see Section 4.4.22

   o  WTP Fallback, see Section 4.4.35

8.4.  Configuration Update Request

   Configure Update Request messages are sent by the AC to provision the
   WTP while in the Run state.  This is used to modify the configuration
   of the WTP while it is operational.

   When an AC receives a Configuration Update Request message it will
   respond with a Configuration Update Response message, with the
   appropriate Result Code.

   One or more of the following message elements MAY be included in the
   Configuration Update message.

   o  AC IPv4 List, see Section 4.4.2

   o  AC IPv6 List, see Section 4.4.3

   o  AC Name with Index, see Section 4.4.5

   o  AC Timestamp, see Section 4.4.6

   o  Add MAC ACL Entry, see Section 4.4.7

   o  Add Static MAC ACL Entry, see Section 4.4.9

   o  CAPWAP Timers, see Section 4.4.10

   o  Change State Event, see Section 4.4.11

   o  Decryption Error Report Period, see Section 4.4.15

   o  Delete MAC ACL Entry, see Section 4.4.16

   o  Delete Static MAC ACL Entry, see Section 4.4.18

   o  Idle Timeout, see Section 4.4.22

   o  Location Data, see Section 4.4.26

   o  Radio Administrative State, see Section 4.4.28

   o  Statistics Timer, see Section 4.4.31

   o  WTP Fallback, see Section 4.4.35

   o  WTP Name, see Section 4.4.42

8.5.  Configuration Update Response

   The Configuration Update Response message is the acknowledgement
   message for the Configuration Update Request message.

   The Configuration Update Response message is sent by a WTP after
   receiving a Configuration Update Request message.

   When an AC receives a Configure Update Response message the result
   code indicates if the WTP successfully accepted the configuration.

   The following message element MUST be present in the Configuration
   Update message.

   Result Code, see Section 4.4.29

   The following message elements MAY be present in the Configuration
   Update message.

   o  AC IPv4 List, see Section 4.4.2

   o  AC IPv6 List, see Section 4.4.3

8.6.  Change State Event Request

   The Change State Event Request message is used by the WTP to inform
   the AC of a change in the operational state.

   The Change State Event Request message is sent by the WTP when it
   receives a Configuration Response message that includes a Change
   State Event message element.  It is also sent when the WTP detects an
   operational failure with a radio.  The Change State Event Request
   message may be sent in either the Configure or Run state (see [12]).
   Section 2.3.

   When an AC receives a Change State Event message it will respond with
   a Change State Event Response message and make any necessary
   modifications to internal WTP data structures.

   The TLS
   algorithm suites following message elements MUST be present in the Change State
   Event Request message.

   o  Change State Event message element, see Section 4.4.11

8.7.  Change State Event Response

   The Change State Event Response message acknowledges the Change State
   Event Request message.

   A Change State Event Response message is by a WTP after receiving a
   Change State Event Request message.

   The Change State Event Response message carries no message elements.
   Its purpose is to acknowledge the receipt of the Change State Event
   Request message.

   The WTP does not need to perform any special processing of the Change
   State Event Response message.

8.8.  Clear Config Indication

   The Clear Config Indication message is used to reset a WTP's
   configuration.

   The Clear Config Indication message is sent by an AC to request that
   a WTP reset its configuration to the manufacturing default
   configuration.  The Clear Config Indication message is sent while in
   the Run CAPWAP state.

   The Clear Config Indication message carries no message elements.

   When a WTP receives a Clear Config Indication message it resets its
   configuration to the manufacturing default configuration.

9.  Device Management Operations

   This section defines CAPWAP operations responsible for debugging,
   gathering statistics, logging, and firmware management.

9.1.  Image Data Request

   The Image Data Request message is used to update firmware on the WTP.
   This message and its companion response message are used by the AC to
   ensure that the image being run on each endpoint authentication method WTP is appropriate.

   Image Data Request messages are
   described below.

10.1.1.  Authenticating exchanged between the WTP and the AC
   to download a new firmware image to the WTP.  When a WTP or AC
   receives an Image Data Request message it will respond with Certificates an Image
   Data Response message.  The message elements contained within the
   Image Data Request is required in order to determine the intent of
   the request.  Note that only block ciphers are currently recommended one message element may be present in
   any given Image Data Request message.

   The decision that new firmware is to downloaded to the WTP can occur
   in one of two methods:

      When the WTP joins the AC, and each exchange their software
      revision, the WTP may opt to initiate a firmware download by
      sending an Image Data Request, which contains an Image Filename
      message element.

      Once the WTP is in the CAPWAP state, it is possible for use the AC to
      cause the WTP to initiate a firmware download by initiating an
      Image Data Request, with
   DTLS.  To understand the reasoning behind this, see [23].
   However,support for AES counter mode encryption is currently
   progressing in Initiate Download message element.
      The WTP would then transmit the Image Filename message element to
      start the download process.

   Regardless of how the download was initiated, once the AC receives an
   Image Data Request with the Image Filename message element, it begins
   the transfer process by transmitting its own request with the TLS working group, and once protocol identifiers
   are available, they will be added below.  At present, Image
   Data message element.  This continues until the following
   algorithms MUST be supported when using certificates for CAPWAP
   authentication:

   o  TLS_RSA_WITH_AES_128_CBC_SHA

   o  TLS_RSA_WITH_3DES_EDE_CBC_SHA
   The following algorithms SHOULD be supported when using certificates:

   o  TLS_DH_RSA_WITH_AES_128_CBC_SHA

   o  TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA whole firmware image
   has been transfered.

   The following algorithms message elements MAY be supported when using certificates:

   o  TLS_RSA_WITH_AES_256_CBC_SHA included in the Image Data
   Request Message.

   o  TLS_DH_RSA_WITH_AES_256_CBC_SHA

10.1.2.  Authenticating with Preshared Keys

   Pre-shared keys present significant challenges from a security
   perspective, and for that reason, their use is strongly discouraged.
   However, [12] defines 3 different methods for authenticating with
   preshared keys:  Image Data, see Section 4.4.23

   o  PSK key exchange algorithm - simplest method, ciphersuites use
      only symmetric key algorithms  Image Filename, see Section 4.4.24

   o  DHE_PSK key exchange algorithm - use a PSK  Initiate Download, see Section 4.4.25

9.2.  Image Data Response

   The Image Data Response message acknowledges the Image Data Request
   message.

   An Image Data Response message is sent in response to authenticate a
      Diffie-Hellman exchange.  These ciphersuites give some additional
      protection against dictionary attacks and also provide Perfect
      Forward Secrecy (PFS).

   o  RSA_PSK key exchange algorithm - use RSA and certificates received
   Image Data Request message.  Its purpose is to
      authenticate acknowledge the server, in addition
   receipt of the Image Data Request message.

   The Image Data Response message carries no message elements.

   No action is necessary on receipt.

9.3.  Reset Request

   The Reset Request message is used to using cause a PSK.  Not
      susceptible WTP to passive attacks.

   The first approach (plain PSK) reboot.

   A Reset Request message is susceptible sent by an AC to passive dictionary
   attacks; hence, while this alorithm MAY be supported, special care
   should be taken when choosing that method.  In particular, user-
   readable passphrases SHOULD NOT be used, and use of short PSKs should
   be strongly discouraged.  Additionally, DHE_PSK MUST be supported,
   and RSA_PSK MAY be supported. cause a WTP to
   reinitialize its operation.

   The following cryptographic algorithms MUST be supported when using
   preshared keys:

   o  TLS_DHE_PSK_WITH_AES_128_CBC_SHA

   o  TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA Reset Request carries no message elements.

   When a WTP receives a Reset Request it will respond with a Reset
   Response and then reinitialize itself.

9.4.  Reset Response

   The following algorithms SHOULD be supported when using preshared
   keys:

   o  TLS_DHE_PSK_WITH_AES_256_CBC_SHA Reset Response message acknowledges the Reset Request message.

   A Reset Response message is sent by the WTP after receiving a Reset
   Request message.

   The following algorithms MAY be supported when using preshared keys:

   o  TLS_PSK_WITH_AES_128_CBC_SHA

   o  TLS_PSK_WITH_AES_256_CBC_SHA

   o  TLS_PSK_WITH_3DES_EDE_CBC_SHA

   o  TLS_RSA_PSK_WITH_AES_128_CBC_SHA

   o  TLS_RSA_PSK_WITH_AES_256_CBC_SHA

   o  TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA

10.2.  Refreshing Cryptographic Keys

   Since AC-WTP associations Reset Response message carries no message elements.  Its purpose
   is to acknowledge the receipt of the Reset Request message.

   When an AC receives a Reset Response message, it is notified that the
   WTP will tend reinitialize its operation.

9.5.  WTP Event Request

   WTP Event Request message is used by a WTP to send information to its
   AC.  The WTP Event Request message may be relatively long-lived, sent periodically, or sent
   in response to an asynchronous event on the WTP.  For example, a
   mechanism is provided WTP
   MAY collect statistics and use the WTP Event Request message to periodically refresh
   transmit the encryption and
   authentication keys; this is referred statistics to as "rekeying".  When the key
   lifetime reaches 95% AC.

   When an AC receives a WTP Event Request message it will respond with
   a WTP Event Response message.

   The WTP Event Request message MUST contain one of the configured value, identified in the
   KeyLifetime timer (see Section 12), message
   elements listed below, or a new DTLS seesion SHOULD be
   initiated (via message element that is defined for a CAPWAP implementation API).

10.3.  Certificate Usage

   Validation
   specific wireless technology.

   o  Decryption Error Report, see Section 4.4.14

   o  Duplicate IPv4 Address, see Section 4.4.20

   o  Duplicate IPv6 Address, see Section 4.4.21

9.6.  WTP Event Response

   The WTP Event Response message acknowledges receipt of the certificates WTP Event
   Request message.

   A WTP Event Response message issent by the an AC and after receiving a WTP
   Event Request message.

   The WTP Event Response message carries no message elements.

9.7.  Data Transfer Request

   The Data Transfer Request message is required so that
   only an AC may perform used to deliver debug
   information from the functions of an AC and that only a WTP may
   perform to the functions of a WTP.  This restriction of functions AC.

   Data Transfer Request messages are sent by the WTP to the AC or when the
   WTP requires determines that it has important information to send to the certificates used by the AC MUST be
   distinguishable from AC.
   For instance, if the certificate used WTP detects that its previous reboot was caused
   by a system crash, it can send the WTP.  To accomplish
   this differentiation, the x.509v3 certificates MUST include crash file to the
   Extensions field [11] and MUST include AC.  The remote
   debugger function in the NetscapeComment [13]
   extension.

   For an AC, WTP also uses the value of Data Transfer Request
   message to send console output to the NetscapeComment extension MUST be AC for debugging purposes.

   When the
   string "CAPWAP AC Device Certificate".  For receives a WTP, Data Transfer Request message it responds to
   the value of WTP ith a Data Transfer Response message.  The AC MAY log the
   NetscapeComment extension
   information received.

   The Data Transfer Request message MUST be contain one of the string "CAPWAP WTP Device
   Certificate".

   Part message
   elements listed below.

   o  Data Transfer Mode, see Section 4.4.13

   o  Data Transfer Data, see Section 4.4.12

9.8.  Data Transfer Response

   The Data Transfer Response message acknowledges the Data Transfer
   Request message.

   A Data Transfer Response message is sent in response to a received
   Data Transfer Request message.  Its purpose is to acknowledge receipt
   of the CAPWAP certificate validation process includes ensuring
   that Data Transfer Request message.

   The Data Transfer Response message carries no message elements.

   Upon receipt of a Data Transfer Response message, the proper string WTP transmits
   more information, if more information is included available.

10.  Mobile Session Management

   Messages in this section are used by the NetscapeComment extension, AC to create, modify or
   delete mobile station session state on the WTPs.

10.1.  Mobile Config Request

   The Mobile Config Request message is used to create, modify or delete
   mobile session state on a WTP.  The message is sent by the AC to the
   WTP, and only allowing may contain one or more message elements.  The message
   elements for this CAPWAP control message include information that is
   generally highly technology specific.  Refer to the appropriate
   binding section or document for the definitions of the messages
   elements that may be used in this control message.

   The following CAPWAP session to Control message elements MAY be established if the
   extension does not represent the same role as the device validating included in the certificate.  For instance,
   Mobile Config Request message.

   o  Add Mobile Station, see Section 4.4.8

   o  Delete Mobile Station, see Section 4.4.17

10.2.  Mobile Config Response

   The Mobile Configuration Response message is used to acknowledge a WTP
   previously received Mobile Configuration Request message, and MUST NOT accept
   include a certificate
   whose NetscapeComment field Result Code message element, see Section 4.4.29 which
   indicates whether an error occurred on the WTP.

   This message requires no special processing, and is set only used to "CAPWAP WTP Device
   Certificate".
   acknowledge receipt of the Mobile Configuration Request message.

11.  IEEE 802.11 Binding

   This section defines the extensions required for the CAPWAP protocol
   to be used with the IEEE 802.11 protocol.

11.1.  Division of labor  Split MAC and Local MAC Functionality

   The CAPWAP protocol, when used with IEEE 802.11 devices, requires a
   specific behavior from the WTP and the AC, specifically in terms of
   which to support the required
   IEEE 802.11 protocol functions are handled. functions.

   For both the Split and Local MAC approaches, the CAPWAP functions, as
   defined in the taxonomy specification, specification [Add reference], reside in the
   AC.

11.1.1.  Split MAC

   This section shows the division of labor between the WTP and the AC
   in a Split MAC architecture.  Figure 4 3 shows the clear separation of
   functionality among CAPWAP components.

        Function                               Location
            Distribution Service                      AC
            Integration Service                       AC
            Beacon Generation                         WTP
            Probe Response Generation                 WTP
            Power Mgmt/Packet Buffering               WTP
            Fragmentation/Defragmentation             WTP             WTP/AC
            Assoc/Disassoc/Reassoc                    AC

       802.11e
            Classifying                               AC
            Scheduling                                WTP/AC
            Queuing                                   WTP

       802.11i
            802.1X/EAP                                AC
            RSNA Key Management                        AC
            802.11 Encryption/Decryption              WTP or AC              WTP/AC

   Figure 4: 3: Mapping of 802.11 Functions for Split MAC Architecture

   The Distribution and Integration services reside on the AC, and
   therefore all user data is tunneled between the WTP and the AC.  As
   noted above, all real-time IEEE 802.11 services, including the control
   protocol and the beacon
   and probe response frames, are handled on the WTP.

   All remaining IEEE 802.11 MAC management frames are supported on the
   AC, including the Association Request which allows the AC to be
   involved in the access policy enforcement portion of the IEEE 802.11
   protocol.  The IEEE 802.1X and IEEE 802.11i key management function
   are also located on the AC.

   While the admission control component of IEEE 802.11e resides on the
   AC, the real time scheduling and queuing functions are on the WTP.
   Note this does not exclude the AC from providing additional policing
   and scheduling functionality.

   Note that in the following figure, the use of '( - )' indicates that
   processing of the frames is done on the WTP.

             Client                       WTP                        AC

                      Beacon
             <-----------------------------
                   Probe Request
             ----------------------------( - )------------------------->
                   Probe Response
             <-----------------------------
                              802.11 AUTH/Association
             <--------------------------------------------------------->
                                Add
                  Mobile Config Request[Add Mobile (Clear Text, 802.1X Only) 802.1X)]
                                             <------------------------->
                    802.1X Authentication & 802.11i Key Exchange
             <--------------------------------------------------------->
                                         Add
                  Mobile Config Request[Add Mobile (AES-CCMP, PTK=x) PTK=x)]
                                             <------------------------->
                               802.11 Action Frames
             <--------------------------------------------------------->
                                   802.11 DATA (1)
             <---------------------------( - )------------------------->

   Figure 5: 4: Split MAC Message Flow

   Figure 5 4 provides an illustration of the division of labor in a Split
   MAC architecture.  In this example, a WLAN has been created that is
   configured for IEEE 802.11i, using AES-CCMP for privacy.  The
   following process occurs:

   o  The WTP generates the IEEE 802.11 beacon frames, using information
      provided to it through the Add WLAN (see Section Section 11.8.1.1) 11.10.1)
      message element.

   o  The WTP processes the probe request and responds with a
      corresponding probe response.  The probe request is then forwarded
      to the AC for optional processing.

   o  The WTP forwards the IEEEE 802.11 Authentication and Association
      frames to the AC, which is responsible for responding to the
      client.

   o  Once the association is complete, the AC transmits an CAPWAP Add
      Mobile Station request to the WTP (see Section Section 9.1.1. 4.4.8.  In
      the above example, the WLAN is configured for IEEE 802.1X, and
      therefore the '802.1X only' policy bit is enabled.

   o  If the WTP is providing encryption/decryption services, once the
      client has completed the IEEE 802.11i key exchange, the AC
      transmits another Add Mobile request to the WTP, stating the
      security policy to enforce for the client (in this case AES-CCMP),
      as well as the encryption key to use.  If encryption/decryption is
      handled in the AC, the Add Mobile Station request would have the
      encryption policy set to "Clear Text".

   o  The WTP forwards any 802.11 Action frames received to the AC.

   o  All client data frames are tunneled between the WTP and the AC.
      Note that the WTP is responsible for encrypting and decrypting
      frames, if it was indicated in the Add Mobile request.

11.1.2.  Local MAC

   This section shows the division of labor between the WTP and the AC
   in a Local MAC architecture.  Figure 6 5 shows the clear separation of
   functionality among CAPWAP components.

        Function                               Location
            Distribution Service                      WTP
            Integration Service                       WTP
            Beacon Generation                         WTP
            Probe Response                            WTP
            Power Mgmt/Packet Buffering               WTP
            Fragmentation/Defragmentation             WTP
            Assoc/Disassoc/Reassoc                    WTP

       802.11e
            Classifying                               WTP
            Scheduling                                WTP
            Queuing                                   WTP

       802.11i
            802.1X/EAP                                AC
            RSNA Key Management                            AC
            802.11 Encryption/Decryption              WTP

   Figure 6: 5: Mapping of 802.11 Functions for Local AP Architecture

   Given the Distribution and Integration Services exist on the WTP,
   client data frames are not forwarded to the AC, with the exception
   listed in the following paragraphs.

   While the MAC is terminated on the WTP, it is necessary for the AC to
   be aware of mobility events within the WTPs.  As a consequence, the
   WTP MUST forward the IEEE 802.11 Association Requests to the AC, and
   the AC MAY reply with a failed Association Response if it deems it
   necessary.

   The IEEE 802.1X and IEEE 802.11i RSNA Key Management function resides in the AC.
   Therefore, the WTP MUST forward all IEEE 802.1X/Key 802.1X/RSNA Key Management
   frames to the AC and forward the associated responses to the station.

   Note that in the following figure, the use of '( - )' indicates that
   processing of the frames is done on the WTP.

             Client                       WTP                        AC

                      Beacon
             <-----------------------------
                       Probe
             <---------------------------->
                    802.11 AUTH
             <-----------------------------
                                 802.11 Association
             <---------------------------( - )------------------------->
                                Add
                  Mobile Config Request[Add Mobile (Clear Text, 802.1X Only) 802.1X)]
                                             <------------------------->
                    802.1X Authentication & 802.11i Key Exchange
             <--------------------------------------------------------->
                               802.11 Action Frames
             <--------------------------------------------------------->
                                         Add
                    Mobile Config Request[Add Mobile (AES-CCMP, PTK=x) PTK=x)]
                                             <------------------------->
                     802.11 DATA
             <----------------------------->

   Figure 7: 6: Local MAC Message Flow

   Figure 7 6 provides an illustration of the division of labor in a Local
   MAC architecture.  In this example, a WLAN has been created that is
   configured for IEEE 802.11i, using AES-CCMP for privacy.  The
   following process occurs:

   o  The WTP generates the IEEE 802.11 beacon frames, using information
      provided to it through the Add WLAN (see Section 11.8.1.1) 11.10.1) message
      element.

   o  The WTP processes the probe request and responds with a
      corresponding probe response.

   o  The WTP forwards the IEEE 802.11 Authentication and Association
      frames to the AC, which is responsible for responding to the
      client.

   o  Once the association is complete, the AC transmits an CAPWAP Add
      Mobile request Station message element to the WTP (see Section
      Section 9.1.1. 4.4.8.  In the above example, the WLAN is configured for
      IEEE 802.1X, and therefore the '802.1X only' policy bit is
      enabled.

   o  The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange
      messages to the AC for processing.

   o  The AC transmits another Add Mobile request Station message element to the
      WTP, stating the security policy to enforce for the client (in
      this case AES-
      CCMP), AES-CCMP), as well as the encryption key to use.  The
      Add Mobile
      request Station message element MAY include a VLAN name, which
      when present is used by the WTP to identify the VLAN on which the
      user's data frames are to be bridged.

   o  The WTP forwards any IEEE 802.11 Action frames received to the AC.

   o  The WTP optionally may tunnel client data frames to the AC.  If
      client data frames are locally bridged, the WTP will need to
      provide the necessary encryption and decryption services.

11.2.  Roaming Behavior and 802.11 security

   It is important that CAPWAP implementations react properly to mobile
   devices associating to the networks in how they generate Add Mobile
   and Delete Mobile messages.  This section expands upon the examples
   provided in the previous section, and describes how the CAPWAP
   control protocol is used in order to provide secure roaming.

   Once a client has successfully associated with the network in a
   secure fashion, it is likely to attempt to roam to another access
   point. WTP.
   Figure 8 7 shows an example of a currently associated station moving
   from its "Old WTP" to a new WTP. "new WTP".  The figure is useful for multiple
   different security policies, including standard IEEE 802.1X and dynamic WEP
   keys, WPA or even WPA2 both with key caching (where the IEEE 802.1x
   exchange would be bypassed) and without.

            Client              Old WTP              WTP              AC

                          Association Request/Response
             <--------------------------------------( - )-------------->
                                Add
                 Mobile Config Request[Add Mobile (Clear Text, 802.1X Only) 802.1X)]
                                                      <---------------->
             802.1X Authentication (if no key cache entry exists)
             <--------------------------------------( - )-------------->
                           802.11i 4-way Key Exchange
             <--------------------------------------( - )-------------->
                                         Delete
                     Mobile Config Request[Delete Mobile]
                                    <---------------------------------->
                                         Add
                  Mobile Config Request[Add Mobile (AES-CCMP, PTK=x) PTK=x)]
                                                      <---------------->

   Figure 8: 7: Client Roaming Example

11.3.  Transport specific bindings

   All CAPWAP transports have  Group Key Refresh

   Periodically, the following IEEE 802.11 specific
   bindings:

11.3.1.  Payload encapsulation

   The CAPWAP protocol defines Group Key (GTK)for the data frame, which allows a wireless
   payload BSS needs to be encapsulated.  For IEEE 802.11, updated.
   The AC uses an EAPoL frame to update the IEEE 802.11 header
   and payload is encapsulated (excluding group key for each STA in
   the IEEE 802.11 FCS checksum).
   The IEEE 802.11 FCS checksum is handled by BSS.  While the WTP.  This allows AC is updating the
   WTP to validate a GTK, each L2 broadcast frame prior to sending it
   transmitted to the AC.  Similarly,
   when an AC wishes BSS needs to transmit a frame towards a station, the WTP
   computes be duplicated and adds transmitted using
   both the FCS checksum.

11.3.2.  Status current GTK and WLANS field

   The interpretation of this 16 bit field depends on the direction of
   transmission of the packet.  Refer to new GTK.  Once the figure in Section 4.1.

   Status

   When a CAPWAP packet is GTK update process
   has completed, broadcast frames transmitted from a WTP to an AC, this field
   is called the status field and indicates radio resource information
   associated with BSS will be
   encrypted using the frame.  When new GYT

   In the message is a CAPWAP control
   message this field is transmitted as zero.

   The status field is divided into case of Split MAC, the signal strength and signal AC needs to
   noise ratio with which an IEEE 802.11 frame was received, encoded in
   the following manner:

                 0                   1
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |     RSSI      |     SNR       |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   RSSI:  RSSI is a signed, 8-bit value.  It is the received signal
      strength indication, in dBm.

   SNR:  SNR is a signed, 8-bit value.  It is duplicate all broadcast
   packets and update the signal to noise ratio
      of key index so that the received IEEE 802.11 frame, in dB.

   WLANs field:  When a CAPWAP data message packet is transmitted from an AC to
      a WTP, this 16 bit field indicates on which WLANs
   using both the encapsulated
      IEEE 802.11 frame is current and new GTK to be transmitted.  For unicast packets, this
      field is not used by ensure that all STA's in the
   BSS receive the WTP.  For broadcast or multicast packets, frames.  In the case of local MAC, the WTP might require this information if it provides encryption
      services.

      Given that a single
   needs to duplicate and transmit broadcast or multicast packet might need frames using the
   appropriate index to be
      sent ensure that all STA's in the BSS continue to multiple wireless LANs (presumably each with a different
   receive broadcast key), this field is defined as a bit field.  A bit set
      indicates a WLAN ID (see Section Section 11.8.1.1) which will be
      sent the data. frames.

   The WLANS field Group Key update procedure is encoded given in the following
      manner:

                 0                   1
                 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |          WLAN ID(s)           |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.4.  BSSID to WLAN ID Mapping figure.  The CAPWAP protocol makes assumptions regarding the BSSIDs used on
   the WTP.  It is a requirement for
   AC will signal the WTP update to use a contiguous block
   of BSSIDs.  The WLAN Identifier field, which is managed by the AC, is
   used as GTK using an offset into 802.11 Configuration
   Request frame with the BSSID list.

   For instance, if a WTP had a base BSSID address of 00:01:02:00:00:00, new GTK, its index, and the Key Status set to
   3 (begin GTK update).  The AC sent an Add WLAN message with a WLAN Identifier of 2 (see
   Section Section 11.8.1.1), will then begin updating the BSSID GTK for
   each STA.  During this time, the specific WLAN on the WTP
   would be 00:01:02:00:00:02.

   The AC (for Split MAC) or WTP communicates (for Local
   MAC) must duplicate broadcast packets and transmit them encrypted
   with both the maximum number of BSSIDs that it supports
   during current and new GTK.  When the Config Request within AC has completed the IEEE GTK
   update to all STA's in the BSS, the AC must transmit an 802.11 WTP WLAN Radio
   Configuration message element (see Section 11.9.1).

11.5.  Quality of Service for Control Messages

   It is recommended that IEEE 802.11 MAC management frames be sent by
   both Request frame containing the AC new GTK, its index, and
   the Key Status set to 4 (GTK update complete).

              Client           WTP with appropriate Quality of Service values,
   ensuring that congestion in the network minimizes occurrences of
   packet loss.  Therefore, a Quality of Service enabled CAPWAP device
   should use:

   802.1P:  The precedence value of 6 SHOULD be used for all IEEE 802.11
      MAC management frames, except for Probe Requests which SHOULD use
      4.

   DSCP:  The DSCP tag value of 46 SHOULD be used for all IEEE                                           AC

                802.11
      MAC management frames, except for Probe Requests which SHOULD use
      34.

11.6.  Data Message bindings

   There are no CAPWAP Data Config Request ( Update WLAN (GTK, GTK Index, GTK Start)
                             <----------------------------------------------
                                        802.1X EAPoL (GTK Message bindings for IEEE 802.11.

11.7.  Control 1)
             <-------------( - )-------------------------------------------
                                        802.1X EAPoL (GTK Message bindings

   The IEEE 2)
               -------------( - )------------------------------------------->
            802.11 binding has the following Control Message
   definitions.

11.7.1.  Mobile Config Request

   This section contains the IEEE 802.11 ( Update WLAN (GTK, GTK Index, GTK Complete)
                             <---------------------------------------------

   Figure 8: Group Key Update Procedure

11.4.  Transport specific message elements that
   are used with bindings

   All CAPWAP transports have the Mobile Config Request.

11.7.1.1.  IEEE 802.11 Mobile

   The following IEEE 802.11 Mobile message element accompanies specific
   bindings:

   Payload encapsulation The CAPWAP protocol defines the Add Mobile
   message element, and CAPWAP data
      frame, which is used to push encapsulate a wireless payload.  For IEEE
      802.11, the IEEE 802.11 station policy.

   The latest header and payload are encapsulated
      (excluding the IEEE 802.11 Mobile message element overrides any
   previously received message elements.  If the FCS checksum).  The IEEE 802.11 Mobile
   message element's EAP Only bit FCS
      checksum is set, handled by the WTP.  This allows the WTP MUST drop all IEEE
   802.11 packets that do not contain EAP packets.  Note that to validate a
      frame prior to sending it to the AC.  Similarly, when EAP
   Only is set, an AC wishes
      to transmit a frame towards a station, the Encryption Policy WTP computes and adds
      the FCS checksum.

   CAPWAP Header Reserved field MAY be set, The reserved CAPWAP header field (see
      figure Section 4.1) is only used with CAPWAP data frames, and therefore it
   is possible to inform a
      serves two purposes, depending upon the direction of the frame.
      For packets from the WTP to only accept encrypted EAP packets.
   Once the mobile station has successfully completed EAP
   authentication, AC, the field uses the format
      described in the IEEE 802.11 Frame Info" field.  However, for
      frames sent by the AC must send a new Add Mobile message element to
   remove the EAP Only restriction, and optionally push WTP, the session key
   down to format used is described in
      described in the WTP.

   If Destination WLANs field.

   IEEE 802.11 Frame Info When an CAPWAP data frame is received from a
      station over the QoS air, it is encapsulated and this field is set, the WTP MUST observe used to
      include radio and provide policing of PHY specific information associated with the 802.11e priority tag to ensure that it does not exceed
      frame.

      When used with the value
   provided by IEEE 802.11 binding, the AC. field follows the
      following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |        Association ID         |     Flags     RSSI      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     SNR       |          Capabilities           Data Rate           |   WLAN ID     |Supported Rates
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  TBD for Add IEEE 802.11 Mobile

   Length:  >= 8

   Radio ID:  An

      RSSI:  RSSI is a signed, 8-bit value representing value.  It is the radio

   Association ID:  A 16-bit value specifying received signal
         strength indication, in dBm.

      SNR:  SNR is a signed, 8-bit value.  It is the signal to noise
         ratio of the received IEEE 802.11
      Association Identifier

   MAC Address: frame, in dB.

      Data Rate:  The mobile station's MAC Address

   Capabilities:  A 16-bit data rate field containing is a 16 bit unsigned value.  The
         contents of the IEEE 802.11 capabilities field is set to use with 1/10th of the mobile.

   WLAN ID:  An 8-bit value specifying data rate of the WLAN Identifier

   Supported Rates:  The variable length field containing
         packet received by the supported
      rates WTP.  For instance, a packet received at
         5.5Mbps would be set to 55, while 11Mbps would be set to 110.

   Destination WLANs The Destination WLAN field is used with to specify the mobile station.

11.7.1.2.  IEEE 802.11 Mobile Session Key

   The Mobile Session Key Payload message element
      target WLANs for a given frame, and is sent when only used with broadcast
      and multicast frames.  This field allows the AC
   determines that encryption of to transmit a mobile station must be performed in
   the WTP.  This message element MUST NOT be present without
      single broadcast or multicast frame to the IEEE
   802.11 Mobile (see Section 11.7.1.1) message element, WTP, and MUST NOT be
   sent if allows the WTP had not specifically advertised support for
      to perform the necessary frame replication services.  The field
      uses the
   requested encryption scheme. following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           MAC Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          MAC Address          |E|C|           Flags           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Encryption Policy                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Pairwise TSC                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Pairwise TSC          |         Pairwise RSC          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              WLAN             |                         Pairwise RSC            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Session Key...
       +-+-+-+-+-+-+-+-
   Type:  105 for IEEE 802.11 Mobile Session Key

   Length:  >= 25

   MAC Address:  The mobile station's MAC Address

   Flags:  A 16

      WLAN:  This bit field, whose unused bits MUST be set field indicates the WLAN ID (see section
         Section 11.10.1) which the WTP will transmit the associated
         frame on.  For instance, if a multicast packet is to zero.  The
      following be
         transmitted on WLANs 1 and 3, bits are defined:

      E:  The one bit 1 and 3 of this field would
         be enabled.  Note this field is to be set by the AC to inform zero for unicast
         packets and is unused if the WTP that is not providing encryption
         services.

      Reserved:  This field MUST NOT accept be set to zero.

11.5.  BSSID to WLAN ID Mapping

   The CAPWAP protocol allows the WTP to assign BSSIDs upon creation of
   a WLAN (see Section Section 11.10.1).  While manufacturers are free
   to assign BSSIDs using any 802.11 data frames, other than IEEE 802.1X
         frames.  This arbitrary mechanism, it is advised that
   where possible the equivalent BSSIDs are assigned as a contiguous block.

   When assigned as a block, implementations can still assign any of the WTP's IEEE 802.1X port
   available BSSIDs to any WLAN.  One possible method is for the mobile station WTP to be in
   assign the closed state.  When set, address using the following algorithm: base BSSID address
   + WLAN ID.

   The WTP MUST drop any non-IEEE 802.1X packets it receives from communicates the mobile station.

      C:  The one bit field is set by maximum number of BSSIDs that it supports
   during the AC to inform Config Request within the IEEE 802.11 WTP WLAN Radio
   Configuration message element (see Section 11.10.24).

11.6.  Quality of Service for Control Messages

   It is recommended that
         encryption services will IEEE 802.11 MAC management frames be provided sent by
   both the AC.  When set, AC and the WTP SHOULD police frames received from stations to ensure with appropriate Quality of Service values,
   ensuring that
         they comply to the stated encryption policy, but does not need
         to take specific cryptographic action on congestion in the frame.  Similarly, network minimizes occurrences of
   packet loss.  Therefore, a Quality of Service enabled CAPWAP device
   should use:

   802.1P:  The precedence value of 6 SHOULD be used for transmitted all IEEE 802.11
      MAC management frames, the WTP only needs except for Probe Requests which SHOULD use
      4.

   DSCP:  The DSCP tag value of 46 SHOULD be used for all IEEE 802.11
      MAC management frames, except for Probe Requests which SHOULD use
      34.

11.7.  IEEE 802.11 Specific CAPWAP Control Messages

   This section defines CAPWAP Control Messages that are specific to forward already
         encrypted frames.

   Encryption Policy: the
   IEEE 802.11 binding.  The policy field informs two messages are defined as IEEE 802.11
   WLAN Config Request and IEEE 802.11 WLAN Config Response.  See
   Section 4.3.1.1

   The valid message types for IEEE 802.11 specific control messages are
   listed below.  The IANA Enterprise number used with these messages is
   13277

           CAPWAP Control Message           Message Type
                                               Value

           IEEE 802.11 WLAN Config Request     3398912
           IEEE 802.11 WLAN Config Response    3398913

11.7.1.  IEEE 802.11 WLAN Config Request

   The IEEE 802.11 WLAN Configuration Request is sent by the AC to the
   WTP how in order to handle
      packets from/to change services provided by the mobile station.  The following values are
      supported:

      0 - Encrypt WEP 104: All packets to/from WTP.  This control
   message is used to either create, update or delete a WLAN on the mobile station must
         be encrypted using standard 104 bit WEP.

      1 - Clear Text: All packets to/from WTP.

   The IEEE 802.11 WLAN Configuration Request is sent as a result of
   either some manual admistrative process (e.g., deleting a WLAN), or
   automatically to create a WLAN on a WTP.  When sent automatically to
   create a WLAN, this control message is sent after the mobile station do not
         require any additional crypto processing CAPWAP
   Configure Update Request message has been received by the WTP.

      2 - Encrypt WEP 40: All packets to/from the mobile station must be
         encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128: All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCMP 128: All packets to/from

   Upon receiving this control message, the mobile station
         must be encrypted using 128 bit AES CCMP [7]

      5 - Encrypt TKIP-MIC: All packets to/from WTP will modify the mobile station must
         be encrypted using TKIP
   necessary services, and authenticated using Michael [21]
   Pairwise TSC:  The 6 byte Transmit Sequence Counter (TSC) field to
      use transmit an IEEE 802.11 WLAN Configuration
   Response.

   A WTP MAY provide service for unicast packets transmitted more than one WLAN, therefore every
   WLAN is identified through a numerical index.  For instance, a WTP
   that is capable of supporting up to the mobile.

   Pairwise RSC:  The 6 byte Receive Sequence Counter (RSC) 16 SSIDs, could accept up to use for
      unicast packets received from 16
   IEEE 802.11 WLAN Configuration Request messages that include the mobile.

   Session Key:  The session key Add
   WLAN message element.

   Since the WTP index is the primary identifier for a WLAN, an AC MAY
   attempt to use when encrypting
      traffic to/from ensure that the mobile station.  For dynamically created keys,
      this same WLAN is commonly known as identified through the same
   index number on all of its WTPs.  An AC that does not follow this
   approach MUST find some other means of maintaining a Pairwise Transient Key (PTK).

11.7.1.3.  Station QoS Profile WLAN Identifier
   to SSID mapping table.

   The Station QoS Profile Payload following message element contains the maximum
   IEEE 802.11e priority tag that elements may be used by the station.  Any
   packets received that exceeds the value encoded included in this the IEEE 802.11
   WLAN Config Request message.  Only one message element must either be dropped or tagged using the maximum value
   permitted by to the user.  The priority tag must MUST be between zero (0)
   and seven (7).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           MAC Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          MAC Address          |     802.1P Precedence Tag     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  140 for
   present.

   o  IEEE 802.11 Add WLAN, see Section 11.10.1

   o  IEEE 802.11 Delete WLAN, see Section 11.10.5

   o  IEEE 802.11 Update WLAN, see Section 11.10.21

   o  IEEE 802.11 Information Element, see Section 11.10.7

11.7.2.  IEEE 802.11 Station QOS Profile

   Length:  8

   MAC Address:  The mobile station's MAC Address

   802.1P Precedence Tag: WLAN Config Response

   The maximum 802.1P precedence value that IEEE 802.11 WLAN Configuration Response is sent by the AC to the
   WTP will allow in as an acknowledgement of the TID field receipt of an IEEE 802.11 WLAN
   Configuration Request.

   The following message elements may be included in the extended 802.11e QOS IEEE 802.11
   WLAN Config Request message.  Only one message element MUST be
   present.

   o  IEEE 802.11 Assigned WTP BSSID, see Section 11.10.3

11.8.  Data
      header.

11.7.1.4. Message bindings

   There are no CAPWAP Data Message bindings for IEEE 802.11.

11.9.  Control Message bindings

   This section describes he IEEE 802.11 Update specific message elements
   included in CAPWAP Control Messages.

11.9.1.  Mobile QoS Config Request

   The Update Mobile QoS following IEEE 802.11 specific message element is elements MAY used to change with the Quality
   of Service policy on
   CAPWAP Mobile Config Request message.

   o  IEEE 802.11 Mobile, see Section 11.10.11

   o  IEEE 802.11 Mobile Session Key, see Section 11.10.12

   o  Station QOS Profile, see Section 11.10.25

11.9.2.  WTP Event Request

   The following IEEE 802.11 specific message elements may be included
   in the CAPWAP WTP Event Request message.

   o  IEEE 802.11 MIC Countermeasures, see Section 11.10.9
   o  IEEE 802.11 Statistics, see Section 11.10.16

   o  IEEE 802.11 WTP for a given mobile station.

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Fail Alarm Indication, see Section 11.10.23

11.9.3.  Configuration Messages

   This section defines the IEEE 802.11 Message Elements which MAY be
   included in the Configuration Status, Configuration Status Response,
   Configuration Update Request and Mobile Config Request CAPWAP control
   meessages.  The binding of message elements to CAPWAP control
   messages is shown below:

                                             Conf  Conf  Conf  Mobile
   Message Element                           Stat  Stat  Upd   Config Req
                                             Msg   Resp   Msg   Msg

   IEEE 802.11 Antenna                        X     X     X
   IEEE 802.11 Broadcast Probe Mode                 X     X
   IEEE 802.11 Direct Sequence Control        X     X     X
   IEEE 802.11 MAC Address          |   DSCP Tag    |  802.1P Tag   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  106 for Operation                  X     X     X
   IEEE 802.11 MIC Error Report From Mobile               X
   IEEE 802.11 Mobile Session Key                               X
   IEEE 802.11 Multi-domain Capability        X     X     X
   IEEE 802.11 OFDM Control                   X     X     X
   IEEE 802.11 Rate Set                             X     X
   IEEE 802.11 Supported Rates                X     X
   IEEE 802.11 Tx Power                       X     X     X
   IEEE 802.11 Tx Power Level                 X
   IEEE 802.11 Update Mobile QoS

   Length:  14                                X
   IEEE 802.11 WTP Mode and Type              X?          X
   IEEE 802.11 WTP Quality of Service               X     X
   IEEE 802.11 WTP Radio ID: Configuration        X     X     X

11.10.  IEEE 802.11 Message Element Definitions

11.10.1.  IEEE 802.11 Add WLAN

   The Radio Identifier, typically refers Add WLAN message element is used by the AC to some interface
      index define a wireless
   LAN on the WTP

   MAC Address:  The mobile station's MAC Address.

   DSCP Tag:  The DSCP label to use if packets are to be DSCP tagged.

   802.1P Tag: WTP.  The 802.1P precedence value to use if packets are to be inclusion of this message element MUST also
   include IEEE 802.1P tagged.

11.7.2.  WTP Event Request

   This section contains the 802.11 specific Information Element message elements that are
   used with elements, containing
   the WTP Event Request message.

11.7.2.1.  IEEE following 802.11 Statistics IEs:

   Power Capability information element
   WPA information element

   RSN information element

   EDCA Parameter Set information element

   QoS Capability information element

   WMM information element

   The statistics message element is sent by the WTP to transmit it's
   current statistics.  The value contains uses the following fields. format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    WLAN ID    |            Reserved           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Tx Fragment Count                      Encryption Policy                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Multicast Tx Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Failed Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Retry Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Multiple Retry Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Frame Duplicate Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       RTS Success Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       RTS Failure Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       ACK Failure Count                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Rx Fragment Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Key Index   |                       Multicast RX Count   Key Status  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      QoS      |                        FCS Error  Count   Auth Type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Tx Frame Count   MAC Mode    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Tunnel Mode  |                       Decryption Errors Suppress SSID |    SSID ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  38  1024 for Statistics IEEE 802.11 Add WLAN

   Length:  60  >= 49

   Radio ID:  An 8-bit value representing the radio.

   Tx Fragment Count:  A 32-bit

   WLAN ID:  An 8-bit value representing specifying the number of
      fragmented frames transmitted.

   Multicast Tx Count: WLAN Identifier.

   Reserved:  A 32-bit 16-bit value representing the number of
      multicast frames transmitted.

   Failed Count: that MUST be set to zero.

   Encryption Policy:  A 32-bit value representing specifying the transmit excessive
      retries.

   Retry Count:  A 32-bit value representing encryption scheme
      to apply to traffic to and from the number mobile station.  The
      applicability of transmit
      retries.

   Multiple Retry Count:  A 32-bit value representing the number of
      transmits encryption policy depends upon the security
      policy.  For static WEP keys, which is true when the 'Shared Key'
      bit is set, this encryption policy is relevant for both unicast
      and multicast traffic.  For encryption schemes that required more than one retry.

   Frame Duplicate Count:  A 32-bit value representing employ a
      separate encryption key for unicast and multicast traffic, the duplicate
      frames received.

   RTS Success Count:  A 32-bit value representing
      encryption policy defined here only applies to multicast data.  In
      these scenarios, the number of
      successfully transmitted Ready To Send (RTS).

   RTS Failure Count:  A 32-bit value representing unicast encryption policy is communicated via
      the failed
      transmitted RTS.

   ACK Failure Count:  A 32-bit value representing Add Mobile Station (Section 4.4.8).

      0 - Encrypt WEP 104: All packets to/from the number of failed
      acknowledgements.

   Rx Fragment Count:  A 32-bit value representing mobile station must
         be encrypted using standard 104 bit WEP.

      1 - Clear Text: All packets to/from the number of
      fragmented frames received.

   Multicast RX Count: mobile station do not
         require any additional crypto processing by the WTP.

      2 - Encrypt WEP 40: All packets to/from the mobile station must be
         encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128: All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
         must be encrypted using 128 bit AES CCMP [7]

      5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
         be encrypted using TKIP and authenticated using Michael [24]

   Key:  A 32-bit value representing 32 byte Session Key to use with the number of
      multicast frames received.

   FCS Error Count: encryption policy.

   Key-Index:  The Key Index associated with the key.

   Key Status:  A 32-bit 1 byte value representing that specifies the number state and usage of FCS
      failures.

   Decryption Errors: the
      key that has been included.  The following values describe the key
      usage and its status:

   0 - A 32-bit value representing the number of
      Decryption errors that occurred on zero, with the WTP.  Note 'Encryption Policy' field set to any
      value other than 'Clear Text' means that this the WLAN uses per-station
      encryption keys, and therefore the key in the 'Key' field is only valid in cases where the WTP provides encryption/
      decryption services.

11.8.  802.11 Control Messages

   This section defines CAPWAP Control Messages that are specific
      used for multicast traffic.

   1 - When set to one, the
   IEEE 802.11 binding.

11.8.1.  IEEE 802.11 WLAN Config Request employs a shared WEP key, also known as
      a static WEP key, and uses the encryption key for both unicast and
      multicast traffic for all stations.

   2 - The IEEE 802.11 WLAN Configuration Request is sent by value of 2 indicates that the AC to will begin rekeying the
   WTP GTK
      with the STA's in order to change services provided by the WTP.  This control
   message BSS.  It is used to either create, update or delete a WLAN on the WTP.

   The only valid when IEEE 802.11 WLAN Configuration Request 802.11i is sent
      enabled as a result the security policy for the BSS.

   3 - The value of
   either some manual admistrative process (e.g., deleting a WLAN), or
   automatically 3 indicates that the AC has completed rekeying the
      GTK and broadcast packets no longer need to create a WLAN on a WTP.  When sent automatically be duplicated and
      transmitted with both GTK's.

   QOS:  An 8-bit value specifying the QoS policy to
   create a WLAN, this control message is sent after enforce for the CAPWAP
   Configuration Request message has been received by
      station.

      The following values are supported:

      0 - Best Effort

      1 - Video

      2 - Voice

      3 - Background

   Auth Type:  An 8-bit value specifying the WTP.

   Upon receiving this control message, supported authentication
      type.

      The following values are supported:

      0 - Open System

      1 - WEP Shared Key

      2 - WPA/WPA2 802.1X

      3 - WPA/WPA2 PSK

   MAC Mode:  This field specifies whether the WTP will modify should support the
   necessary services, and transmit an IEEE 802.11
      WLAN Configuration
   Response.

   A in Local or Split MAC modes.  Note that the AC MUST NOT
      request a mode of operation that was not advertised by the WTP MAY provide service
      during the discovery process (see section Section 4.4.38).  The
      following values are supported:

      0 - Local-MAC:  Service for more than one WLAN, therefore every the WLAN is identified through a numerical index.  For instance, a WTP
   that is capable of supporting up to 16 SSIDs, could accept up to 16
   IEEE 802.11 WLAN Configuration Request messages that include be provided in Local
         MAC mode.

      1 - Split-MAC:  Service for the Add WLAN message element.

   Since the index is to be provided in Split
         MAC mode.

   Tunnel Mode:  This field specifies the primary identifier tunneling type to be used for a WLAN, an
      all stations associated with the WLAN.  Note that the AC SHOULD
   attempt to ensure MUST NOT
      request a mode of operation that was not advertised by the same WLAN WTP
      during the discovery process (see section Section 4.4.36).  The
      following values are supported:

      0 - Local Bridging:  All user traffic is identified through to be locally bridged.

      1 - 802.3 Tunnel:  All user traffic is to be tunneled to the same
   index number on all of its WTPs.  An AC that does not follow this
   approach MUST find some other means in
         802.3 format (see section Section 4.2).

      2 - 802.11 Bridging:  All user traffic is to be tunneled to the AC
         in 802.11 format.

   Supress SSID:  A boolean indicating whether the SSID is to be
      advertised by the WTP.  A value of maintaining zero supresses the SSID in the
      802.11 Beacon and Probe Response frames, while a WLAN Identifier value of one will
      cause the WTP to SSID mapping table. populate the field.

   SSID:  The following subsections define SSID attribute is the message elements service set identifier that are value will be
      advertised by the WTP for this CAPWAP operation.  Only one message MUST be present.

11.8.1.1. WLAN.

11.10.2.  IEEE 802.11 Add WLAN Antenna

   The Add WLAN antenna message element is used communicated by the WTP to the AC to define a wireless
   LAN
   provide information on the WTP. antennas available.  The AC MAY use this
   element to reconfigure the WTP's antennas.  The value contains the
   following format: fields:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |         WLAN Capability       |    WLAN ID    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Encryption Policy                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               Key                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Key Index   |   Shared Key  | WPA Data Len  |WPA IE Data ...|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | RSN Data Len  |RSN IE Data ...| WME Data Len  |WME IE Data ...|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  11e Data Len |11e IE Data ...|      QoS      |   Auth Type   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Suppress SSID |    SSID ...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  7 for IEEE 802.11 Add WLAN

   Length:  >= 49

   Radio ID:  An 8-bit value representing the radio.

   WLAN Capability:  A 16-bit value containing the capabilities to be
      advertised by the WTP within the Probe and Beacon messages.

   WLAN ID:  An 8-bit value specifying the WLAN Identifier.

   Encryption Policy:  A 32-bit value specifying the encryption scheme
      to apply to traffic to and from the mobile station.

      The following values are supported:

      0 - Encrypt WEP 104: All packets to/from the mobile station must
         be encrypted using standard 104 bit WEP.

      1 - Clear Text: All packets to/from the mobile station do not
         require any additional crypto processing by the WTP.

      2 - Encrypt WEP 40: All packets to/from the mobile station must be
         encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128: All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
         must be encrypted using 128 bit AES CCMP [7]

      5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
         be encrypted using TKIP and authenticated using Michael [21]

      6 - Encrypt CKIP: All packets to/from the mobile station must be
         encrypted using Cisco TKIP.

   Key:  A 32 byte Session Key to use with the encryption policy.

   Key-Index:  The Key Index associated with the key.

   Shared Key:  A 1 byte boolean that specifies whether the key included
      in the Key field is a shared WEP key.  A value of zero is used to
      state that the key is not a shared WEP key, while a value of one
      is used to state that the key is a shared WEP key.

   WPA Data Len:  Length of the WPA IE.

   WPA IE:  A 32 byte field containing the WPA Information Element.

   RSN Data Len:  Length of the RSN IE.

   RSN IE:  A 64 byte field containing the RSN Information Element.

   WME Data Len:  Length of the WME IE.

   WME IE:  A 32 byte field containing the WME Information Element.

   DOT11E Data Len:  Length of the 802.11e IE.

   DOT11E IE:  A 32 byte field containing    Radio ID   |   Diversity   |    Combiner   |  Antenna Cnt  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Antenna Selection [0..N]                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  1025 for IEEE 802.11 Antenna

   Length:  >= 5

   Radio ID:  An 8-bit value representing the 802.11e Information
      Element.

   QOS: radio to configure.

   Diversity:  An 8-bit value specifying whether the QoS policy antenna is to enforce for the
      station.
      provide receive diversity.  The following values are supported:

      0 - Best Effort Disabled

      1 - Video Enabled (may only be true if the antenna can be used as a
         receive antenna)

   Combiner:  An 8-bit value specifying the combiner selection.  The
      following values are supported:

      1 - Sectorized (Left)

      2 - Voice Sectorized (Right)

      3 - Background

   Auth Type: Omni

      4 - MIMO

   Antenna Count:  An 8-bit value specifying the station's authentication
      type. number of Antenna
      Selection fields.

   Antenna Selection:  One 8-bit antenna configuration value per antenna
      in the WTP.  The following values are supported:

      0 - Open System

      1 - WEP Shared Key Internal Antenna

      2 - WPA/WPA2 802.1X External Antenna

11.10.3.  IEEE 802.11 Assigned WTP BSSID

   The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when
   the IEEE 802.11 WLAN Config Request included the IEEE 802.11 Add WLAN
   message element.  The value field of this message element contains
   the BSSID that has been assigned by the WTP, which allows the WTP to
   perform its own BSSID assignment.

   The WTP is free to assign the BSSIDs the way it sees fit, but it is
   highly recommended that the WTP assign the BSSID using the following
   algorithm: BSSID = {base BSSID} + WLAN ID.

        0                   1                   2                   3 - WPA/WPA2 PSK

   Supress SSID:  A boolean indicating
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                             BSSID                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             BSSID             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  1026 for IEEE 802.11 Assigned WTP BSSID

   Length:  6

   BSSID:  The BSSID assigned by the WTP for the WLAN created as a
      result of receiving an IEEE 802.11 Add WLAN.

11.10.4.  IEEE 802.11 Broadcast Probe Mode

   The Broadcast Probe Mode message element indicates whether a WTP will
   respond to NULL SSID probe requests.  Since broadcast NULL probes are
   not sent to a specific BSSID, the WTP cannot know which SSID the
   sending station is to querying.  Therefore, this behavior must be
      advertised by global
   to the WTP.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |    Status     |
     +-+-+-+-+-+-+-+-+

   Type:  1027 for IEEE 802.11 Broadcast Probe Mode

   Length:  1

   Status:  An 8-bit boolean indicating the status of whether a WTP
      shall response to a NULL SSID probe request.  A value of zero supresses the
      disables NULL SSID in the
      802.11 Beacon and Probe Response frames, probe response, while a value of one will
      cause the WTP to populate the field.

   SSID: enables
      it.

11.10.5.  IEEE 802.11 Delete WLAN

   The SSID attribute delete WLAN message element is used to inform the service set identifier WTP that will a
   previously created WLAN is to be
      advertised by deleted.  The value contains the WTP
   following fields:

      0                   1                   2
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |            WLAN ID            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  1028 for this WLAN.

11.8.1.2. IEEE 802.11 Delete WLAN

   The delete

   Length:  3
   Radio ID:  An 8-bit value representing the radio

   WLAN ID:  A 16-bit value specifying the WLAN Identifier

11.10.6.  IEEE 802.11 Direct Sequence Control

   The direct sequence control message element is used to inform a bi-directional
   element.  When sent by the WTP, it contains the current state.  When
   sent by the AC, the WTP that a
   previously created WLAN is MUST adhere to be deleted. the values.  This element is
   only used for 802.11b radios.  The value contains has the following fields: fields.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |            WLAN ID    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Current Chan  |  Current CCA  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Energy Detect Threshold                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  28  1029 for IEEE 802.11 Delete WLAN Direct Sequence Control

   Length:  3  8

   Radio ID:  An 8-bit value representing the radio

   WLAN ID:  A 16-bit value specifying to configure.

   Reserved:  MUST be set to zero

   Current Channel:  This attribute contains the WLAN Identifier

11.8.1.3. current operating
      frequency channel of the DSSS PHY.

   Current CCA:  The current CCA method in operation.  Valid values are:

         1 - energy detect only (edonly)

         2 - carrier sense only (csonly)

         4 - carrier sense and energy detect (edandcs)

         8 - carrier sense with timer (cswithtimer)

         16 - high rate carrier sense and energy detect (hrcsanded)

   Energy Detect Threshold:  The current Energy Detect Threshold being
      used by the DSSS PHY.

11.10.7.  IEEE 802.11 Update WLAN Information Element

   The Update WLAN IEEE 802.11 Information Element is used to communicate any IE
   defined in the IEEE 802.11 protocol.  The data field contains the raw
   IE as it would be included within an IEEE 802.11 MAC management
   message.

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       |B|P|   Flags   | Info Element
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type:  1030 for IEEE 802.11 Information Element

   Length:  >= 2

   B:  When set, the WTP is to include the information element in
      beacons associated with the WLAN.

   P:  When set, the WTP is to include the information element in probe
      responses associated with the WLAN.

   Flags:  Reserved field and MUST be set to zero.

   Info Element:  The IEEE 802.11 Information Element, which includes
      the type, length and value field.

11.10.8.  IEEE 802.11 MAC Operation

   The MAC operation message element is used sent by the AC to define a
   wireless LAN set the 802.11
   MAC parameters on the WTP.  The value contains the following format: fields.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |             WLAN ID           |Encrypt Policy    Reserved   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         RTS Threshold         |                      Encryption Policy
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Key...  Short Retry  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Long Retry   |                             Key ...    Fragmentation Threshold    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Key Index                       Tx MSDU Lifetime                        |   Shared Key
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        WLAN Capability                       Rx MSDU Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  34  1031 for IEEE 802.11 Update WLAN MAC Operation

   Length:  43  16

   Radio ID:  An 8-bit value representing the radio.

   WLAN ID:  A 16-bit value specifying the WLAN Identifier.

   Encryption Policy:  A 32-bit value specifying the encryption scheme
      to apply radio to traffic configure.

   Reserved:  MUST be set to and from the mobile station.

      The following values are supported:

      0 - Encrypt WEP 104: All packets to/from zero

   RTS Threshold:  This attribute indicates the mobile station must number of octets in an
      MPDU, below which an RTS/CTS handshake MUST NOT be encrypted using standard 104 bit WEP.

      1 - Clear Text: All packets to/from performed.  An
      RTS/CTS handshake MUST be performed at the mobile station do not
         require beginning of any additional crypto processing by the WTP.

      2 - Encrypt WEP 40: All packets to/from the mobile station must be
         encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128: All packets to/from frame
      exchange sequence where the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCMP 128: All packets to/from MPDU is of type Data or Management,
      the mobile station
         must be encrypted using 128 bit AES CCMP [7]

      5 - Encrypt TKIP-MIC: All packets to/from MPDU has an individual address in the mobile station must
         be encrypted using TKIP Address1 field, and authenticated using Michael [21]

      6 - Encrypt CKIP: All packets to/from the mobile station must be
         encrypted using Cisco TKIP.

   Key:  A 32 byte Session Key
      length of the MPDU is greater than this threshold.  Setting this
      attribute to use with be larger than the encryption policy.

   Key-Index:  The Key Index associated with maximum MSDU size MUST have the key.

   Shared Key:  A 1 byte boolean that specifies whether
      effect of turning off the key included
      in RTS/CTS handshake for frames of Data or
      Management type transmitted by this STA.  Setting this attribute
      to zero MUST have the Key field is a shared WEP key.  A effect of turning on the RTS/CTS handshake
      for all frames of Data or Management type transmitted by this STA.
      The default value of zero means that this attribute MUST be 2347.

   Short Retry:  This attribute indicates the key is not a shared WEP key, while maximum number of
      transmission attempts of a value frame, the length of one which is used less than
      or equal to
      state RTSThreshold, that MUST be made before a failure
      condition is indicated.  The default value of this attribute MUST
      be 7.

   Long Retry:  This attribute indicates the key maximum number of
      transmission attempts of a frame, the length of which is greater
      than dot11RTSThreshold, that MUST be made before a shared WEP key.

   WLAN Capability:  A 16-bit failure
      condition is indicated.  The default value containing of this attribute MUST
      be 4.

   Fragmentation Threshold:  This attribute specifies the capabilities current
      maximum size, in octets, of the MPDU that MAY be delivered to the
      PHY.  An MSDU MUST be
      advertised by broken into fragments if its size exceeds
      the WTP within value of this attribute after adding MAC headers and trailers.
      An MSDU or MMPDU MUST be fragmented when the Probe resulting frame has
      an individual address in the Address1 field, and Beacon messages.

11.8.2.  IEEE 802.11 WLAN Config Response

   The IEEE 802.11 WLAN Configuration Response is sent by the AC to length of the
   WTP as an acknowledgement
      frame is larger than this threshold.  The default value for this
      attribute MUST be the lesser of 2346 or the receipt aMPDUMaxLength of an IEEE 802.11 WLAN
   Configuration Request.

   This CAPWAP control message does not include any message elements.

11.8.3.  IEEE 802.11 WTP Event

   The IEEE 802.11 WTP Event CAPWAP message is used by the WTP in order
   to report asynchronous events to
      attached PHY and MUST never exceed the AC.  There is no reply message
   expected from lesser of 2346 or the AC, except that
      aMPDUMaxLength of the message is acknowledged via attached PHY.  The value of this attribute
      MUST never be less than 256.

   Tx MSDU Lifetime:  This attribute speficies the
   reliable transport.

   When elapsed time in TU,
      after the AC receives initial transmission of an MSDU, after which further
      attempts to transmit the IEEE 802.11 WTP Event, it will take whatever
   action is necessary, depending upon MSDU MUST be terminated.  The default
      value of this attribute MUST be 512.

   Rx MSDU Lifetime:  This attribute specifies the message elements present elapsed time in TU,
      after the initial reception of a fragmented MMPDU or MSDU, after
      which further attempts to reassemble the message. MMPDU or MSDU MUST be
      terminated.  The IEEE 802.11 WTP Event message default value MUST contain one of the following
   message element described in the next subsections.

11.8.3.1. be 512.

11.10.9.  IEEE 802.11 MIC Countermeasures

   The MIC Countermeasures message element is sent by the WTP to the AC
   to indicate the occurrence of a MIC failure.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |    WLAN ID    |          MAC Address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          MAC Address                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  61  1032 for IEEE 802.11 MIC Countermeasures

   Length:  8

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the WTP.

   WLAN ID:  This 8-bit unsigned integer includes the WLAN Identifier,
      on which the MIC failure occurred.

   MAC Address:  The MAC Address of the mobile station that caused that caused the
      MIC failure.

11.10.10.  IEEE 802.11 MIC Error Report From Mobile

   The MIC Error Report From Mobile message element is sent by an AC to
   an WTP when it receives a MIC failure notification, via the Error bit
   in the EAPOL-Key frame.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Client MAC Address                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Client MAC Address       |             BSSID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             BSSID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |    WLAN ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  1033 for IEEE 802.11 MIC Error Report From Mobile

   Length:  14

   Client MAC Address:  The Client MAC Address of the station reporting
      the MIC failure.

   BSSID:  The BSSID on which the MIC failure is being reported.

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the WTP

   WLAN ID:  The WLAN ID on which the MIC failure is being reported.

11.10.11.  IEEE 802.11 Mobile

   The IEEE 802.11 Mobile message element accompanies the Add Mobile
   message element, and is used to deliver IEEE 802.11 station policy
   from the AC to the WTP.

   The latest IEEE 802.11 Mobile message element overrides any
   previously received message elements.

   If the QoS field is set, the WTP MUST observe and provide policing of
   the 802.11e priority tag to ensure that it does not exceed the value
   provided by the AC.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID   |        Association ID         |     Flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Capabilities         |   WLAN ID     |Supported Rates
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  1034 for Add IEEE 802.11 Mobile

   Length:  >= 8

   Radio ID:  An 8-bit value representing the radio

   Association ID:  A 16-bit value specifying the IEEE 802.11
      Association Identifier

   Flags:  The Flags field MUST be set to zero

   Capabilities:  A 16-bit field containing the IEEE 802.11 capabilities
      to use with the mobile.

   WLAN ID:  An 8-bit value specifying the WLAN Identifier

   Supported Rates:  The variable length field containing the supported
      rates to be used with the mobile station.

11.10.12.  IEEE 802.11 Mobile Session Key

   The Mobile Session Key Payload message element is sent when the AC
   determines that encryption of a mobile station must be performed in
   the WTP.  This message element MUST NOT be present without the IEEE
   802.11 Mobile (see Section 11.10.11) message element, and MUST NOT be
   sent if the WTP had not specifically advertised support for the
   requested encryption scheme.

   If the IEEE 802.11 Mobile Session Key message element's EAP-Only bit
   is set, the WTP MUST drop all IEEE 802.11 packets that do not contain
   EAP packets.  Note that when EAP-Only is set, the Encryption Policy
   field MAY be set, and therefore it is possible to inform a WTP to
   only accept encrypted EAP packets.  Once the mobile station has
   successfully completed EAP authentication, the
      MIC failure.

11.8.3.2.  IEEE 802.11 WTP Radio Fail Alarm Indication

   The WTP Radio Fail Alarm Indication AC must send a new Add
   Mobile message element is sent by to remove the
   WTP EAP Only restriction, and
   optionally push the session key down to the AC when it detects a radio failure. WTP.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Radio ID                           MAC Address                         |     Type
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Status          MAC Address          |E|C|           Flags           |      Pad
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Encryption Policy                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Pairwise TSC                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Pairwise TSC          |         Pairwise RSC          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Pairwise RSC                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Session Key...
       +-+-+-+-+-+-+-+-

   Type:  95  1035 for WTP Radio Fail Alarm Indication IEEE 802.11 Mobile Session Key

   Length:  4

   Radio ID:  >= 25

   MAC Address:  The Radio Identifier, typically refers mobile station's MAC Address

   Flags:  A 16 bit field, whose unused bits MUST be set to some interface
      index on the WTP

   Type:  The type of radio failure detected. zero.  The
      following values bits are
      supported:

      1 - Receiver

      2 - Transmitter

   Status:  An 8-bit boolean indicating whether defined:

      E:  The one bit EAP-Only field is set by the radio failure AC to inform the WTP
         that is
      being reported or cleared.  A value of zero MUST NOT accept any 802.11 data frames, other than IEEE
         802.1X frames.  This is used to clear the
      event, while a value equivalent of the WTP's IEEE 802.1X
         port for the mobile station to be in the closed state.  When
         set, the WTP MUST drop any non-IEEE 802.1X packets it receives
         from the mobile station.

      C:  The one bit field is used set by the AC to report inform the event.

   Pad:  Reserved field MUST WTP that
         encryption services will be set provided by the AC.  When set, the
         WTP SHOULD police frames received from stations to ensure that
         they comply to zero (0).

11.9.  Message Element Bindings

   The IEEE 802.11 Message Element binding has the following
   definitions:

                                             Conf  Conf  Conf  Add
                                             Req   Resp  Upd   Mobile

   IEEE 802.11 stated encryption policy, but does not need
         to take specific cryptographic action on the frame.  Similarly,
         for transmitted frames, the WTP WLAN Radio Configuration   X     X     X
   IEEE 802.11 Rate Set                             X     X
   IEEE 802.11 Multi-domain Capability        X     X     X
   IEEE 802.11 MAC Operation                  X     X     X
   IEEE 802.11 Tx Power                       X     X     X
   IEEE 802.11 Tx Power Level                 X
   IEEE 802.11 Direct Sequence Control        X     X     X
   IEEE 802.11 OFDM Control                   X     X     X
   IEEE 802.11 Supported Rates                X     X
   IEEE 802.11 Antenna                        X     X     X
   IEEE 802.11 CFP Status                     X           X
   IEEE 802.11 Broadcast Probe Mode                 X     X
   IEEE 802.11 only needs to forward already
         encrypted frames.

   Encryption Policy:  The policy field informs the WTP Mode how to handle
      packets from/to the mobile station.  The following values are
      supported:

      0 - Encrypt WEP 104: All packets to/from the mobile station must
         be encrypted using standard 104 bit WEP.

      1 - Clear Text: All packets to/from the mobile station do not
         require any additional crypto processing by the WTP.

      2 - Encrypt WEP 40: All packets to/from the mobile station must be
         encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128: All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
         must be encrypted using 128 bit AES CCMP [7]

      5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
         be encrypted using TKIP and Type              X?          X
   IEEE 802.11 WTP Quality of Service               X     X
   IEEE 802.11 MIC Error Report From Mobile               X
   IEEE 802.11 Update Mobile QoS                                X
   IEEE 802.11 Mobile authenticated using Michael [24]

   Pairwise TSC:  The 6 byte Transmit Sequence Counter (TSC) field to
      use for unicast packets transmitted to the mobile.

   Pairwise RSC:  The 6 byte Receive Sequence Counter (RSC) to use for
      unicast packets received from the mobile.

   Session Key:  The session key the WTP is to use when encrypting
      traffic to/from the mobile station.  For dynamically created keys,
      this is commonly known as a Pairwise Transient Key                               X

11.9.1. (PTK).

11.10.13.  IEEE 802.11 WTP WLAN Radio Configuration Multi-domain Capability

   The WTP WLAN radio configuration multi-domain capability message element is used by the AC to configure a
   Radio on
   inform the WTP. WTP of regulatory limits.  The message element value contains the
   following
   Fields: fields.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved   |        Occupancy Limit        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    CFP Per    |      CFP Maximum Duration     |     BSS ID    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                            BSS ID        First Channel #        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     BSS ID    |        Beacon Period          |    DTIM Per   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       Number of Channels      |                        Country String       Max Tx Power Level      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Num Of BSSIDs |
       +-+-+-+-+-+-+-+-+

   Type:  8  1036 for IEEE 802.11 WTP WLAN Radio Configuration Multi-Domain Capability

   Length:  20  8
   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST be set to zero

   Occupancy Limit:

   First Channnel #:  This attribute indicates the maximum amount value of
      time, in TU, that a point coordinator MAY control the usage of lowest
      channel number in the
      wireless medium without relinquishing control subband for long enough to
      allow at least one instance of DCF access to the medium.  The
      default value associated domain country
      string.

   Number of this Channels:  This attribute SHOULD be 100, and indicates the maximum value SHOULD be 1000.

   CFP Period:  The attribute describes of the total
      number of DTIM intervals
      between channels allowed in the start of CFPs.

   CFP Maximum Duration:  The subband for the associated
      domain country string.

   Max Tx Power Level:  This attribute describes indicates the maximum duration
      of the CFP transmit
      power, in dBm, allowed in TU that MAY be generated by the PCF.

   BSSID: subband for the associated domain
      country string.

11.10.14.  IEEE 802.11 OFDM Control

   The WLAN Radio's base MAC Address.  For WTPs that support
      more than OFDM control message element is a single WLAN, bi-directional element.  When
   sent by the value of WTP, it contains the WLAN Identifier is added
      to current state.  When sent by the last octet of AC,
   the BSSID.  Therefore, a WTP that supports 16
      WLANs MUST have 16 MAC Addresses reserved for it, and the last
      nibble is used adhere to represent the WLAN ID.

   Beacon Period: values.  This attribute specifies the number of TU that a
      station uses element is only used for scheduling Beacon transmissions.  This
   802.11a radios.  The value is
      transmitted in Beacon and Probe Response frames.

   DTIM Period:  This attribute specifies contains the number of beacon intervals
      that elapses between transmission of Beacons frames containing a
      TIM element whose DTIM Count field is 0.  This following fields:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved   | Current Chan  |  Band Support |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         TI Threshold                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  1037 for IEEE 802.11 OFDM Control

   Length:  8

   Radio ID:  An 8-bit value is
      transmitted in representing the DTIM Period field of Beacon frames.

   Country Code: radio to configure.

   Reserved:  MUST be set to zero

   Current Channel:  This attribute identifies contains the country in which current operating
      frequency channel of the
      station is operating. OFDM PHY.

   Band Supported:  The first two octets capability of this string is the
      two character country code as described OFDM PHY implementation to
      operate in document ISO/IEC 3166-
      1.  The third octet MUST be one of the following:

      1. three U-NII bands.  Coded as an ASCII space character, if the regulations under which the
         station is integer value of a
      three bit field as follows:

         capable of operating encompass all environments in the country,

      2. an ASCII 'O' character, if the regulations under which the
         station is lower (5.15-5.25 GHz) U-NII band
         capable of operating are for an outdoor environment only, or

      3. an ASCII 'I' character, if the regulations under which in the
         station is middle (5.25-5.35 GHz) U-NII band

         capable of operating are in the upper (5.725-5.825 GHz) U-NII band

      For example, for an indoor environment only

   Number implementation capable of BSSIDs:  This attribute contains operating in the maximum number of
      BSSIDs supported by
      lower and mid bands this attribute would take the WTP.  This value restricts the number of
      logical networks supported by

   TI Threshold:  The Threshold being used to detect a busy medium
      (frequency).  CCA MUST report a busy medium upon detecting the WTP, and is between 1 and 16.

11.9.2.
      RSSI above this threshold.

11.10.15.  IEEE 802.11 Rate Set

   The rate set message element value is sent by the AC and contains the
   supported operational rates.  It contains the following fields.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |                 Rate Set...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  16  1038 for IEEE 802.11 Rate Set

   Length:  >= 3

   Radio ID:  An 8-bit value representing the radio to configure.

   Rate Set:  The AC generates the Rate Set that the WTP is to include
      in it's Beacon and Probe messages.  The length of this field is
      between 2 and 8 bytes.

11.9.3.

11.10.16.  IEEE 802.11 Multi-domain Capability Statistics

   The multi-domain capability statistics message element is used sent by the AC to
   inform the WTP of regulatory limits. to transmit it's
   current statistics.  The value contains the following fields.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |                   Reserved                    |        First Channel #
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Tx Fragment Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Number of Channels                       Multicast Tx Count                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Failed Count                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          Retry Count                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Multiple Retry Count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Frame Duplicate Count                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       RTS Success Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       RTS Failure Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       ACK Failure Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Rx Fragment Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Multicast RX Count                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        FCS Error  Count                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Max                        Tx Power Level Frame Count                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Decryption Errors                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  10  1039 for IEEE 802.11 Multi-Domain Capability Statistics

   Length:  8  60

   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST be set to zero

   First Channnel #:  This attribute indicates radio.

   Tx Fragment Count:  A 32-bit value representing the number of
      fragmented frames transmitted.

   Multicast Tx Count:  A 32-bit value representing the number of
      multicast frames transmitted.

   Failed Count:  A 32-bit value representing the transmit excessive
      retries.

   Retry Count:  A 32-bit value representing the number of transmit
      retries.

   Multiple Retry Count:  A 32-bit value representing the lowest
      channel number in of
      transmits that required more than one retry.

   Frame Duplicate Count:  A 32-bit value representing the subband for duplicate
      frames received.

   RTS Success Count:  A 32-bit value representing the associated domain country
      string.

   Number number of Channels:  This attribute indicates
      successfully transmitted Ready To Send (RTS).

   RTS Failure Count:  A 32-bit value representing the failed
      transmitted RTS.

   ACK Failure Count:  A 32-bit value representing the number of failed
      acknowledgements.

   Rx Fragment Count:  A 32-bit value representing the number of
      fragmented frames received.

   Multicast RX Count:  A 32-bit value representing the number of
      multicast frames received.

   FCS Error Count:  A 32-bit value representing the value number of FCS
      failures.

   Decryption Errors:  A 32-bit value representing the total number of channels allowed in the subband for the associated
      domain country string.

   Max Tx Power Level:  This attribute indicates
      Decryption errors that occurred on the maximum transmit
      power, in dBm, allowed WTP.  Note that this field
      is only valid in cases where the subband for the associated domain
      country string.

11.9.4. WTP provides encryption/
      decryption services.

11.10.17.  IEEE 802.11 MAC Operation Supported Rates

   The MAC operation supported rates message element is sent by the AC WTP to set the 802.11
   MAC parameters on indicate
   the WTP. rates that it supports.  The value contains the following fields.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved   |         RTS Threshold         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Short Retry  |  Long Retry   |    Fragmentation Threshold    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Tx MSDU Lifetime                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Rx MSDU Lifetime                        |               Supported Rates...
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  11  1040 for IEEE 802.11 MAC Operation Supported Rates

   Length:  16  >= 3

   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST be set to zero

   RTS Threshold:  This attribute indicates the number of octets in an
      MPDU, below which an RTS/CTS handshake MUST NOT be performed.  An
      RTS/CTS handshake MUST be performed at the beginning of any frame
      exchange sequence where the MPDU is of type Data or Management,
      the MPDU has an individual address in the Address1 field, and the
      length of the MPDU is greater than this threshold.  Setting this
      attribute to be larger than the maximum MSDU size MUST have the
      effect of turning off the RTS/CTS handshake for frames of Data or
      Management type transmitted by this STA.  Setting this attribute
      to zero MUST have the effect of turning on the RTS/CTS handshake
      for all frames of Data or Management type transmitted by this STA.
      The default value of this attribute MUST be 2347.

   Short Retry:  This attribute indicates the maximum number of
      transmission attempts of a frame, the length of which is less than
      or equal to RTSThreshold, that MUST be made before a failure
      condition is indicated.  The default value of this attribute MUST
      be 7.

   Long Retry:  This attribute indicates the maximum number of
      transmission attempts of a frame, the length of which is greater
      than dot11RTSThreshold, that MUST be made before a failure
      condition is indicated.  The default value of this attribute MUST
      be 4.

   Fragmentation Threshold:  This attribute specifies the current
      maximum size, in octets, of the MPDU that MAY be delivered to the
      PHY.  An MSDU MUST be broken into fragments if its size exceeds
      the value of this attribute after adding MAC headers and trailers.
      An MSDU or MMPDU MUST be fragmented when the resulting frame has
      an individual address in the Address1 field, and the length of the
      frame is larger than this threshold.  The default value for this
      attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the
      attached PHY and MUST never exceed the lesser of 2346 or the
      aMPDUMaxLength of the attached PHY.  The value of this attribute
      MUST never be less than 256.

   Tx MSDU Lifetime:  This attribute speficies the elapsed time in TU,
      after the initial transmission of an MSDU, after which further
      attempts to transmit the MSDU MUST be terminated.  The default
      value of this attribute MUST be 512.

   Rx MSDU Lifetime:  This attribute specifies the elapsed time in TU,
      after radio.

   Supported Rates:  The WTP includes the initial reception of a fragmented MMPDU or MSDU, after
      which further attempts Supported Rates that its
      hardware supports.  The format is identical to reassemble the MMPDU or MSDU MUST be
      terminated.  The default value MUST be 512.

11.9.5. Rate Set
      message element and is between 2 and 8 bytes in length.

11.10.18.  IEEE 802.11 Tx Power

   The Tx power message element value is bi-directional.  When sent by
   the WTP, it contains the current power level of the radio in
   question.  When sent by the AC, it contains the power level the WTP
   MUST adhere to.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved   |        Current Tx Power       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  12  1041 for IEEE 802.11 Tx Power

   Length:  4

   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST be set to zero

   Current Tx Power:  This attribute contains the transmit output power
      in mW.

11.9.6.

11.10.19.  IEEE 802.11 Tx Power Level

   The Tx power level message element is sent by the WTP and contains
   the different power levels supported.  The value contains the
   following fields.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |   Num Levels  |        Power Level [n]        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type:  13  1042 for IEEE 802.11 Tx Power Level

   Length:  >= 4

   Radio ID:  An 8-bit value representing the radio to configure.

   Num Levels:  The number of power level attributes.

   Power Level:  Each power level fields contains a supported power
      level, in mW.

11.9.7.

11.10.20.  IEEE 802.11 Direct Sequence Control Update Mobile QoS

   The direct sequence control Update Mobile QoS message element is a bi-directional
   element.  When sent by the WTP, it contains the current state.  When
   sent by used to change the AC, Quality
   of Service policy on the WTP MUST adhere for a given mobile station.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |                  MAC Address                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          MAC Address          |   DSCP Tag    |  802.1P Tag   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  1043 for IEEE 802.11 Update Mobile QoS

   Length:  8

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the values.  This WTP

   MAC Address:  The mobile station's MAC Address.

   DSCP Tag:  The DSCP label to use if packets are to be DSCP tagged.

   802.1P Tag:  The 802.1P precedence value to use if packets are to be
      IEEE 802.1P tagged.

11.10.21.  IEEE 802.11 Update WLAN

   The Update WLAN message element is
   only used for 802.11b radios. by the AC to define a
   wireless LAN on the WTP.  The value has inclusion of this message element MUST
   also include the IEEE 802.11 Information Element message element,
   containing the following fields. 802.11 IEs:

   Power Capability information element

   WPA information element

   RSN information element

   EDCA Parameter Set information element

   QoS Capability information element

   WMM information element

   The message element uses the following format:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved             WLAN ID           |Encrypt Policy | Current Chan
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Current CCA                      Encryption Policy        |     Key...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Energy Detect Threshold                             Key ...                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Key Index   |   Shared Key  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  14  1044 for IEEE 802.11 Direct Sequence Control Update WLAN

   Length:  8  43

   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST radio.

   WLAN ID:  A 16-bit value specifying the WLAN Identifier.

   Encryption Policy:  A 32-bit value specifying the encryption scheme
      to apply to traffic to and from the mobile station.  The
      applicability of the encryption policy depends upon the security
      policy.  For static WEP keys, which is true when the 'Shared Key'
      bit is set, this encryption policy is relevant for both unicast
      and multicast traffic.  For encryption schemes that employ a
      separate encryption key for unicast and multicast traffic, the
      encryption policy defined here only applies to multicast data.  In
      these scenarios, the unicast encryption policy is communicated via
      the Add Mobile Station (Section 4.4.8).

      The following values are supported:

      0 - Encrypt WEP 104: All packets to/from the mobile station must
         be encrypted using standard 104 bit WEP.

      1 - Clear Text: All packets to/from the mobile station do not
         require any additional crypto processing by the WTP.

      2 - Encrypt WEP 40: All packets to/from the mobile station must be
         encrypted using standard 40 bit WEP.

      3 - Encrypt WEP 128: All packets to/from the mobile station must
         be encrypted using standard 128 bit WEP.

      4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
         must be encrypted using 128 bit AES CCMP [7]

      5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
         be set encrypted using TKIP and authenticated using Michael [24]

   Key:  A 32 byte Session Key to zero

   Current Channel:  This attribute contains use with the current operating
      frequency channel encryption policy.

   Key-Index:  The Key Index associated with the key.

   Key Status:  A 1 byte value that specifies the state and usage of the DSSS PHY.

   Current CCA:
      key that has been included.  The current CCA method in operation.  Valid following values are:

         1 - energy detect only (edonly)

         2 - carrier sense only (csonly)

         4 - carrier sense describe the key
      usage and energy detect (edandcs)
         8 its status:

   0 - carrier sense A value of zero, with timer (cswithtimer)

         16 - high rate carrier sense and energy detect (hrcsanded)

   Energy Detect Threshold:  The current Energy Detect Threshold being
      used by the DSSS PHY.

11.9.8.  IEEE 802.11 OFDM Control

   The OFDM control message element is a bi-directional element.  When
   sent by the WTP, it contains the current state.  When sent by 'Encryption Policy' field set to any
      value other than 'Clear Text' means that the AC, WLAN uses per-station
      encryption keys, and therefore the WTP MUST adhere to key in the values.  This element 'Key' field is only
      used for
   802.11a radios.  The value contains the following fields:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 multicast traffic.

   1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Radio ID   |    Reserved   | Current Chan  |  Band Support |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         TI Threshold                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  15 for IEEE 802.11 OFDM Control

   Length:  8

   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST be - When set to zero

   Current Channel:  This attribute contains one, the current operating
      frequency channel of WLAN employs a shared WEP key, also known as
      a static WEP key, and uses the OFDM PHY.

   Band Supported: encryption key for both unicast and
      multicast traffic for all stations.

   2 - The capability value of 2 indicates that the OFDM PHY implementation to
      operate in AC will begin rekeying the three U-NII bands.  Coded as an integer value of a
      three bit field as follows:

         capable of operating in GTK
      with the lower (5.15-5.25 GHz) U-NII band

         capable of operating STA's in the middle (5.25-5.35 GHz) U-NII band

         capable of operating in BSS.  It is only valid when IEEE 802.11i is
      enabled as the upper (5.725-5.825 GHz) U-NII band

      For example, security policy for an implementation capable the BSS.

   3 - The value of operating in 3 indicates that the
      lower and mid bands this attribute would take AC has completed rekeying the value
   TI Threshold:  The Threshold being used
      GTK and broadcast packets no longer need to detect a busy medium
      (frequency).  CCA MUST report a busy medium upon detecting the
      RSSI above this threshold.

11.9.9. be duplicated and
      transmitted with both GTK's.

11.10.22.  IEEE 802.11 Antenna WTP Quality of Service

   The antenna WTP Quality of Service message element value is communicated sent by the WTP to the AC to
   provide information on
   the antennas available.  The AC MAY use this
   element WTP to reconfigure the WTP's antennas.  The value contains the
   following fields:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 communicate quality of service configuration information.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |   Diversity   |    Combiner   |  Antenna Cnt  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    Antenna Selection [0..N]  Tag Packets  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  41  1045 for IEEE 802.11 Antenna WTP Quality of Service

   Length:  >= 5 2

   Radio ID:  An 8-bit value representing the radio  The Radio Identifier, typically refers to configure.

   Diversity: some interface
      index on the WTP

   Tag Packets:  An 8-bit value specifying indicating whether the antenna is to
      provide receive diversity. CAPWAP packets should be
      tagged with for QoS purposes.  The following values are currently
      supported:

      0 - Disabled

      1 - Enabled (may only be true if the antenna can be used as a
         receive antenna)

   Combiner:  An 8-bit value specifying the combiner selection.  The
      following values are supported: Untagged

      1 - Sectorized (Left) 802.1P

      2 - Sectorized (Right)

      3 - Omni

      4 - Mimo
   Antenna Count:  An 8-bit value specifying the number of Antenna
      Selection fields.

   Antenna Selection:  One 8-bit antenna configuration value per antenna
      in the WTP.  The DSCP

      Immediately following values are supported:

      1 - Internal Antenna

      2 - External Antenna

11.9.10.  IEEE 802.11 Supported Rates

   The supported rates message element is sent by the WTP to indicate above header is the rates that it supports. following data
      structure.  This data structure will be repeated five times; once
      for every QoS profile.  The value contains order of the following fields. QoS profiles are Voice,
      Video, Best Effort and Background.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Radio ID  Queue Depth  |             CWMin             |     CWMax     |               Supported Rates...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  16 for IEEE 802.11 Supported Rates

   Length:  >= 3

   Radio ID:  An 8-bit value representing the radio.

   Supported Rates:  The WTP includes the Supported Rates that it's
      hardware supports.  The format is identical to the Rate Set
      message element and is between 2 and 8 bytes in length.

11.9.11.  IEEE 802.11 CFP Status

   The CFP Status message element is sent to provide the CF Polling
   configuration.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID     CWMax     |    Status     AIFS      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  48 for IEEE 802.11 CFP Status

   Length:  2
   Radio ID:   Dot1P Tag   |   DSCP Tag    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Queue Depth:  The Radio Identifier, typically refers to some interface
      index on the WTP

   Status:  An 8-bit boolean containing the status number of packets that can be on the CF Polling
      feature.  A value of zero disables CFP Status, while a value of
      one enables it.

11.9.12.  IEEE 802.11 Broadcast Probe Mode

   The Broadcast Probe Mode message element indicates whether a WTP will
   respond to NULL SSID probe requests.  Since broadcast NULL probes are
   not sent to a specific BSSID, QoS
      transmit queue at any given time.

   CWMin:  The Contention Window minimum value for the WTP cannot know which SSID QoS transmit
      queue.

   CWMax:  The Contention Window maximum value for the
   sending station is querying.  Therefore, this behavior must be global QoS transmit
      queue.

   AIFS:  The Arbitration Inter Frame Spacing to the WTP.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |    Status     |
     +-+-+-+-+-+-+-+-+

   Type:  51 use for IEEE 802.11 Broadcast Probe Mode

   Length:  1

   Status:  An 8-bit boolean indicating the status of whether a WTP
      shall response to a NULL SSID probe request.  A value of zero
      disables NULL SSID probe response, while a QoS
      transmit queue.

   Dot1P Tag:  The 802.1P precedence value of one enables
      it.

11.9.13. to use if packets are to be
      802.1P tagged.

   DSCP Tag:  The DSCP label to use if packets are to be DSCP tagged.

11.10.23.  IEEE 802.11 WTP Quality of Service Radio Fail Alarm Indication

   The WTP Quality of Service Radio Fail Alarm Indication message element value is sent by the AC to
   the
   WTP to communicate quality of service configuration information. the AC when it detects a radio failure.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |  Tag Packets     Type      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    Status     |      Pad      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  57  1046 for IEEE 802.11 WTP Quality of Service Radio Fail Alarm Indication

   Length:  >= 2  4

   Radio ID:  The Radio Identifier, typically refers to some interface
      index on the WTP

   Tag Packets:  An value indicating whether CAPWAP packets should be
      tagged with for QoS purposes.

   Type:  The type of radio failure detected.  The following values are currently
      supported:

      0 - Untagged

      1 - 802.1P Receiver

      2 - DSCP

      Immediately following Transmitter

   Status:  An 8-bit boolean indicating whether the above header radio failure is
      being reported or cleared.  A value of zero is used to clear the following data
      structure.  This data structure will
      event, while a value of one is used to report the event.

   Pad:  Reserved field MUST be repeated five times; once
      for every QoS profile. set to zero (0).

11.10.24.  IEEE 802.11 WTP Radio Configuration

   The order of WTP WLAN radio configuration is used by the QoS profiles are Voice,
      Video, Best Effort AC to configure a
   Radio on the WTP, and Background. by the WTP to deliver its radio configuration
   to the AC.  The message element value contains the following fields:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Queue Depth    Radio ID   |             CWMin    Reserved   |     CWMax Num of BSSIDs |  DTIM Period  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     CWMax                            BSSID                              |     AIFS
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              CBR          BSSID                |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      Beacon Period            |   Dot1P Tag
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   DSCP Tag                         Country Code                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Queue Depth:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  1047 for IEEE 802.11 WTP WLAN Radio Configuration

   Length:  16

   Radio ID:  An 8-bit value representing the radio to configure.

   Reserved:  MUST be set to zero

   BSSID:  The WLAN Radio's base MAC Address.

   Number of BSSIDs:  This attribute contains the maximum number of packets that can be on
      BSSIDs supported by the specific QoS
      transmit queue at any given time.

   CWMin:  The Contention Window minimum WTP.  This value for restricts the QoS transmit
      queue.

   CWMax:  The Contention Window maximum number of
      logical networks supported by the WTP, and is between 1 and 16.

   DTIM Period:  This attribute specifies the number of beacon intervals
      that elapse between transmission of Beacons frames containing a
      TIM element whose DTIM Count field is 0.  This value is
      transmitted in the DTIM Period field of Beacon frames.

   Beacon Period:  This attribute specifies the number of TU that a
      station uses for scheduling Beacon transmissions.  This value is
      transmitted in Beacon and Probe Response frames.

   Country Code:  This attribute identifies the QoS transmit
      queue.

   AIFS:  The Arbitration Inter Frame Spacing to country in which the
      station is operating.  Special attention is required with use of
      this field, as implementations which take action based on this
      field could violate regulatory requirements.  Some regulatory
      bodies do permit configuration of the country code under certain
      restrictions, such as the FCC, when WTPs are certified as Software
      Defined Radios.

      The WTP and AC may ignore the value of this field, depending upon
      regulatory requirements, for example to avoid classification as a
      Software Defined Radio.  When this field is used, the first two
      octets of this string is the two character country code as
      described in document ISO/IEC 3166- 1, and the third octet MUST
      have the QoS
      transmit queue.

   CBR:  The CBR value to observe for 1, 2 or 3 as defined below.  When the QoS transmit queue.

   Dot1P Tag:  The 802.1P precedence value to use of the
      third octet is 255, the country code field is not used, and MUST
      be ignored

      1  an ASCII space character, if packets the regulations under which the
         station is operating encompass all environments in the country,

      2  an ASCII 'O' character, if the regulations under which the
         station is operating are to be
      802.1P tagged.

   DSCP Tag:  The DSCP label to use for an outdoor environment only, or

      3  an ASCII 'I' character, if packets the regulations under which the
         station is operating are to be DSCP tagged.

11.9.14.  IEEE 802.11 MIC Error Report From Mobile for an indoor environment only

      255 Country Code field is not used; ignore the field.

11.10.25.  Station QoS Profile

   The MIC Error Report From Mobile Station QoS Profile Payload message element is sent contains the maximum
   IEEE 802.11e priority tag that may be used by an AC to
   an WTP when it receives a MIC failure notification, via the Error bit station.  Any
   packet received that exceeds the value encoded in this message
   element must either be dropped or tagged using the EAPOL-Key frame. maximum value
   permitted by to the user.  The priority tag must be between zero (0)
   and seven (7).

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Client                           MAC Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Client          MAC Address          |             BSSID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             BSSID     802.1P Precedence Tag     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Radio ID    |    WLAN ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:  79  1048 for IEEE 802.11 MIC Error Report From Mobile Station QOS Profile

   Length:  14

   Client  8

   MAC Address:  The Client mobile station's MAC Address of the station reporting
      the MIC failure.

   BSSID:  The BSSID on which the MIC failure is being reported.

   Radio ID:
   802.1P Precedence Tag:  The Radio Identifier, typically refers to some interface
      index on maximum 802.1P precedence value that the
      WTP

   WLAN ID:  The WLAN ID on which will allow in the MIC failure is being reported.

11.10.  IEEE 802.11 TID field in the extended 802.11e QOS Data
      header.

11.11.  Technology Specific Message Element Values

   This section lists IEEE 802.11 specific values for any generic CAPWAP
   message elements which include fields whose values are technology
   specific.

   IEEE 802.11 uses the following values:

   4 - Encrypt AES-CCMP 128:  WTP supports AES-CCMP, as defined in [7].

   5 - Encrypt TKIP-MIC:  WTP supports TKIP and Michael, as defined in
      [21].
      [24].

12.  CAPWAP Protocol Timers

   A  NAT Considerations

   There are two specific situations in which a NAT system may be used
   in conjunction with a CAPWAP-enabled system.  The first consists of a
   configuration where the WTP or AC is behind a NAT system.  Given that implements CAPWAP discovery MUST implement all
   communication is initiated by the
   following timers.

12.1.  MaxDiscoveryInterval

   The maximum time allowed between sending discovery requests from WTP, and all communication is
   performed over IP using two UDP ports, the
   interface, protocol easily traverses
   NAT systems in seconds.  Must be no less than 2 seconds and no greater
   than 180 seconds.

   Default: 20 seconds.

12.2.  SilentInterval this configuration.

   The minimum time, in seconds, second configuration is one where the AC sits behind a WTP MUST wait after failing to
   receive any responses to NAT.  Two
   issues exist in this situation.  First, an AC communicates its discovery requests, before
   interfaces, and associated WTP load on these interfaces, through the
   WTP Manager Control IP Address.  This message element is currently
   mandatory, and if NAT compliance became an issue, it MAY again
   send discovery requests.

   Default: 30

12.3.  NeighborDeadInterval

   The minimum time, in seconds, a would be
   possible to either:

   1. Make the WTP Manager Control IP Address optional, allowing the WTP MUST wait without having received
   Echo Responses
      to its Echo Requests, before simply use the destination for known IP Address.  However, note that this
      approach would eliminate the
   Echo Request may ability to perform load balancing of
      WTP across ACs, and therefore is not the recommended approach.

   2. Allow an AC to be considered dead.  Must able to configure a NAT'ed address for every
      associated AC that would generally be no less than
   2*EchoInterval seconds and no greater than 240 seconds.

   Default: 60

12.4.  WaitJoin

   The maximum time, communicated in seconds, a the WTP MUST wait without having received
      Manager Control IP Address message element.

   3. Require that if a DTLS Handshake WTP determines that the AC List message element
      consists of a set of IP Addresses that are different from the AC's
      IP Address it is currently communicating with, then assume that
      NAT is being enforced, and require that the WTP communicate with
      the original AC's IP Address (and ignore the WTP Manager Control
      IP Address message element(s)).

   Another issue related to having an AC.  This timer must AC behind a NAT system is CAPWAP's
   support for the CAPWAP Objective to allow the control and data plane
   to be greater than
   TBD seconds.

   Default: TBD

12.5.  EchoInterval

   The minimum time, in seconds, between sending echo requests separated.  In order to support this requirement, the AC
   with CAPWAP
   protocol defines the WTP Manager Data IP Address message element,
   which allows the AC to inform the WTP has joined.

   Default: 30

12.6.  DiscoveryInterval

   The minimum time, in seconds, that the CAPWAP data frames are
   to be forwarded to a WTP separate IP Address.  This feature MUST wait after receiving a
   Discovery Response, before initiating be
   disabled when an AC is behind a DTLS handshake.

   Default: 5

12.7.  RetransmitInterval

   The minimum time, in seconds, which NAT.  However, there is no easy way
   to provide some default mechanism that satisfies both the data/
   control separation and NAT objectives, as they directly conflict with
   each other.  As a non-acknowledged CAPWAP packet consequence, user intervention will be retransmitted.

   Default: 3

12.8.  ResponseTimeout required to
   support such networks.

   The minimum time, in seconds, which CAPWAP protocol allows for all of the ACs identities supporting a
   group of WTPs to be communicated through the WTP or AC List message element.
   This feature must respond to a
   CAPWAP Request message.

   Default: 1

12.9.  KeyLifetime

   The maximum time, in seconds, which be disabled when the AC is behind a CAPWAP DTLS session key NAT and the IP
   Address that is
   valid.

   Default: 28800

13. embedded would be invalid.

   The CAPWAP Protocol Variables

   A WTP or AC protocol has a feature that implements CAPWAP discovery MUST allow for the
   following variables to be configured by system management; default
   values are specified so as to make it unnecessary allows an AC to configure any of
   these variables in many cases.

13.1.  MaxDiscoveries

   The maximum number of discovery requests that will be sent after a
   WTP boots.

   Default: 10

13.2.  DiscoveryCount
   static IP address on a WTP.  The number of discoveries transmitted WTP Static IP Address Information
   message element provides such a function, however this feature SHOULD
   NOT be used in NAT'ed environments, unless the administrator is
   familiar with the internal IP addressing scheme within the WTP's
   private network, and does not rely on the public address seen by the
   AC.

   When a WTP to detects the duplicate address condition, it generates a single
   message to the AC, which includes the Duplicate IP Address message
   element.  The IP Address embedded within this message element is
   different from the public IP address seen by the AC.

13.  Security Considerations

   This
   is a monotonically increasing counter.

13.3.  RetransmitCount

   The number of retransmissions section describes security considerations for a given the CAPWAP packet.  This is a
   monotonically increasing counter.

13.4.  MaxRetransmit

   The maximum number of retransmissions
   protocol.  It also provides security recommendations for a given protocols
   used in conjunction with CAPWAP.

13.1.  CAPWAP packet
   before Security

   As it is currently specified, the CAPWAP protocol sits between the
   security mechanisms specified by the wireless link layer considers protocol
   (e.g.IEEE 802.11i) and AAA.  One goal of CAPWAP is to bootstrap trust
   between the peer dead.

   Default: 5

14.  NAT Considerations

   There are two specific situations in which STA and WTP using a NAT system may be series of preestablished trust
   relationships:

         STA            WTP           AC            AAA
         ==============================================

                            DTLS Cred     AAA Cred
                         <------------><------------->

                         EAP Credential
          <------------------------------------------>

           wireless link layer
           (e.g.802.11 PTK)
          <-------------->
              (derived)

   Within CAPWAP, DTLS is used
   in conjunction with to secure the link between the WTP and
   AC.  In addition to securing control messages, it's also a CAPWAP-enabled system.  The first consists link in
   this chain of a
   configuration where trust for establishing link layer keys.  Consequently,
   much rests on the security of DTLS.

   In some CAPWAP deployment scenarios, there are two channels between
   the WTP and AC: the control channel, carrying CAPWAP control
   messages, and the data channel, over which client data packets are
   tunneled between the AC and WTP.  Typically, the control channel is behind a NAT system.  Given that all
   communication is initiated
   secured by DTLS, while the WTP, and all communication data channel is
   performed over IP using two UDP ports, not.  In the protocol easily traverses
   NAT systems in this configuration.

   The second configuration remote WTP
   with local MAC deployment scenario, there is only one where channel (a
   control channel) between the AC sits behind and WTP.

   The use of parallel protected and unprotected channels deserves
   special consideration, but does not create a NAT.  Two
   issues exist in this situation.  First, an AC communicates its
   interfaces, threat.  There are two
   potential concerns: attempting to convert protected data into un-
   protected data and associated WTP load on these interfaces, through the
   WTP Manager Control IP Address.  This message element is currently
   mandatory, attempting to convert un-protected data into
   protected data.  These concerns are addressed below.

13.1.1.  Converting Protected Data into Unprotected Data

   Since CAPWAP does not support authentication-only ciphers (i.e. all
   supported ciphersuites include encryption and if NAT compliance became an issue, authentication), it would be is
   not possible to either:

   1. Make the WTP Manager Control IP Address optional, allowing convert protected data into unprotected data.  Since
   encrypted data is (ideally) indistinguishable from random data, the WTP
      to simply
   probability of an encrypted packet passing for a well-formed packet
   is effectively zero.

13.1.2.  Converting Unprotected  Data into Protected Data (Insertion)

   The use of message authentication makes it impossible for the known IP Address.  However, note that this
      approach would eliminate the ability
   attacker to perform load balancing forge protected records.  This makes conversion of
      WTP across ACs, and therefore is
   unprotected records to protected records impossible.

13.1.3.  Deletion of Protected Records

   An attacker could remove protected records from the stream, though
   not undetectably so, due the recommended approach.

   2. Allow an AC to be able to configure a NAT'ed address for every
      associated AC that built-in reliability of the underlying
   CAPWAP protocol.  In the worst case, the attacker would generally remove the
   same record repeatedly, resulting in a CAPWAP session timeout and
   restart.  This is effectively a DoS attack, and could be communicated accomplished
   by a man in the WTP
      Manager Control IP Address message element.

   3. Require that middle regardless of the CAPWAP protocol security
   mechanisms chosen.

13.1.4.   Insertion of Unprotected Records

   An attacker could inject packets into the unprotected channel, but
   this may become evident if sequence number desynchronization occurs
   as a WTP determines that result.  Only if the AC List message element
      consists of attacker is a set MiM can packets be inserted
   undetectably.  This is a consequence of IP Addresses that are different channel's lack of
   protection, and not a new threat resulting from the AC's
      IP Address CAPWAP security
   mechanism.

13.2.  Use of Preshared Keys in CAPWAP

   While use of preshared keys may provide deployment and provisioning
   advantages not found in public key based deployments, it is currently communicating with, then assume that
      NAT is being enforced, also
   introduces a number of operational and require that the WTP communicate with
      the original AC's IP Address (and ignore security concerns.  In
   particular, because the WTP Manager Control
      IP Address message element(s)).

   Another issue related to having an AC behind a NAT system keys must typically be entered manually, it
   is CAPWAP's
   support common for the CAPWAP Objective to allow the control and data plane
   to be separated.  In order people to support this requirement, the CAPWAP
   protocol defines the WTP Manager Data IP Address message element,
   which allows the AC base them on memorable words or phrases.
   These are referred to inform as "low entropy passwords/passphrases".

   Use of low-entropy preshared keys, coupled with the WTP fact that the CAPWAP data frames
   keys are often not frequently updated, tends to be forwarded to a separate IP Address.  This feature MUST be
   disabled when an AC is behind a NAT.  However, there is no easy way
   to provide some default mechanism that satisfies both significantly
   increase exposure.  For these reasons, we make the data/
   control separation and NAT objectives, as they directly conflict following
   recommendations:

   o  When DTLS is used with a preshared-key (PSK) ciphersuite, each other.  As WTP
      SHOULD have a consequence, user intervention unique PSK.  Since WTPs will likely be required to
   support such networks.

   The CAPWAP protocol allows widely
      deployed, their physical security is not guaranteed.  If PSKs are
      not unique for all of each WTP, key reuse would allow the ACs identities supporting a
   group compromise of WTPs
      one WTP to be communicated through the AC List message element.
   This feature must be disabled when result in the AC compromise of others

   o  Generating PSKs from low entropy passwords is behind a NAT and the IP
   Address that NOT RECOMMENDED.

   o  It is embedded would be invalid.

   The CAPWAP protocol has a feature RECOMMENDED that allows an AC implementations that allow the
      administrator to manually configure the PSK also provide a
   static IP address on a WTP.  The WTP Static IP Address Information
   message element provides such a function, however this feature
      capability for generation of new random PSKs, taking "RFC 1750
      [4]" into account.

   o  Preshared keys SHOULD
   NOT be used periodically updated.  Implementations
      may facilitate this by providing an administrative interface for
      automatic key generation and periodic update, or it may be
      accomplished manually instead.

13.3.  Use of Certificates in NAT'ed environments, unless the administrator is
   familiar CAPWAP

   For public-key-based DTLS deployments, each device SHOULD have unique
   credentials, with a certificate profile authorizing them to act as
   either a WTP or AC.  If devices do not have unique credentials, it is
   possible that by compromising one, any other one using the internal IP addressing scheme within the WTP's
   private network, same
   credential may also be considered to be compromised.

   Each device is responsible for authenticating and does not rely on authorizing devices
   with which they communicate.  At minimum, such authentication entails
   validation of the public address seen chain of trust leading to the peer certificate,
   followed by the
   AC.

   When the peer certificate itself.  Implementations SHOULD
   also provide a secure method for verifying that the credential in
   question has not been revoked.

   Note that if the WTP detects relies on the duplicate address condition, it generates AC for network connectivity (e.g.
   the AC is a
   message layer 2 switch to the AC, which includes the Duplicate IP Address message
   element.  The IP Address embedded within this message element WTP is
   different from directly connected),
   there is a chicken and egg problem, in that the public IP address seen by WTP may not be able
   to contact an OCSP server or otherwise obtain an up to date CRL if a
   compromised AC doesn't explicitly permit this.  This cannot be
   avoided, except through effective physical security and monitoring
   measures at the AC.

15.

13.4.  AAA Security Considerations

   The security of the CAPWAP AAA protocol over DTLS is completely dependent
   on the security of DTLS.  Any flaws in DTLS compromise used to distribute EAP keys to the ACs, and
   consequently its security
   of the CAPWAP protocol.  In particular, it is critical that the
   communicating parties verify their peer's credentials.  In the case
   of pre-shared keys, this happens automatically via important to the key. overall system
   security.  When used with TLS or IPsec, security guidelines specified
   in "RFC 3539 [12]" SHOULD be followed.

   In general, the
   case of certificates, the parties must check link between the peer's certificate.
   The appropriate checks are described in Section 10.3.

   The use of parallel protected AC and unprotected channels deserves
   special consideration, but does not create AAA server SHOULD be secured
   using a threat.  There are two
   potential concerns: attempting to convert protected data into un-
   protected data and attempting to convert un-protected data into
   protected data.  The use of message strong ciphersuite keyed with mutually authenticated session
   keys.  Implementations SHOULD NOT rely solely on Basic RADIUS shared
   secret authentication makes as it
   impossible for the attacker to forge protected records.  The attacker
   can easily remove protected records from the stream (this is a
   consequence of unreliability), though not undetectably so.  If a non-
   encrypted cipher suite is in use, the attacker can turn such a record
   into often vulnerable to dictionary
   attacks, but rather SHOULD use stronger underlying security
   mechanisms.

13.5.  IEEE 802.11 Security

   When used with an un-protected record.  However, this attack is really no
   different from simple injection into the unprotected stream.

   Perfect Forward Secrecy is not a requirement for IEEE 802.11 infrastructure with WEP encryption, the
   CAPWAP protocol.

   The CAPWAP protocol does not add any new vulnerabilities to IEEE
   802.11 infrastructure which uses WEP for encryption.  However,
   implementors vulnerabilities.  Derived
   session keys between the STA and WTP can be compromised, resulting in
   many well-documented attacks.  Implementors SHOULD discourage the use
   of WEP to allow the market to
   move towards and encourage use of technically sound cryptographic solutions, solutions
   such as those in an IEEE
   802.11i.

15.1.  PSK based Session Key establishment

   Use of a fixed shared secret of limited entropy (for example, a PSK
   that 802.11 RSN.

   STA authentication in CAPWAP is relatively short, or was chosen by a human performed using IEEE 802.lX, and thus may
   contain less entropy than its length would imply) may allow an
   attacker to perform a brute-force or dictionary attack to recover the
   secret.

   It is RECOMMENDED that implementations that allow the administrator
   to manually configure
   consequently EAP.  Implementors SHOULD use EAP methods meeting the PSK also provide a functionality for
   generating a new random PSK, taking
   requirements specified in RFC 1750 [4] into account.

16. 4017 [ref]

14.  IANA Considerations

   A separate UDP port for data channel communications is (currently)
   the selected demultiplexing mechanism, and a port must be assigned
   for this purpose.

   The Message element type fields must be IANA aassigned, see
   Section 4.3.2.

17. 4.4.

15.  References

17.1.

15.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   National Institute of Standards and Technology, "Advanced
         Encryption Standard (AES)", FIPS PUB 197, November 2001,
         <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

   [3]   Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-
         MAC (CCM)", RFC 3610, September 2003.

   [4]   Eastlake, D., Crocker, S., and J. Schiller, "Randomness
         Recommendations for Security", RFC 1750, December 1994.

   [5]   Manner, J. and M. Kojo, "Mobility Related Terminology",
         RFC 3753, June 2004.

   [6]   "Information technology - Telecommunications and information
         exchange between systems - Local and metropolitan area networks
         - Specific requirements - Part 11: Wireless LAN Medium Access
         Control (MAC) and Physical Layer (PHY) specifications",
         IEEE Standard 802.11, 1999,
         <http://standards.ieee.org/getieee802/download/
         802.11-1999.pdf>.

   [7]   "Information technology - Telecommunications and information
         exchange between systems - Local and metropolitan area networks
         - Specific requirements - Part 11: Wireless LAN Medium Access
         Control (MAC) and Physical Layer (PHY) specifications Amendment
         6: Medium Access Control (MAC) Security Enhancements",
         IEEE Standard 802.11i, July 2004, <http://standards.ieee.org/
         getieee802/download/802.11i-2004.pdf>.

   [8]   Clark, D., "IP datagram reassembly algorithms", RFC 815,
         July 1982.

   [9]   Schaad, J. and R. Housley, "Advanced Encryption Standard (AES)
         Key Wrap Algorithm", RFC 3394, September 2002.

   [10]  Mills, D., "Network Time Protocol (Version 3) Specification,
         Implementation", RFC 1305, March 1992.

   [11]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
         Public Key Infrastructure Certificate and Certificate
         Revocation List (CRL) Profile", RFC 3280, April 2002.

   [12]  Aboba, B. and J. Wood, "Authentication, Authorization and
         Accounting (AAA) Transport Profile", RFC 3539, June 2003.

   [13]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
         Transport Layer Security (TLS)", RFC 4279, December 2005.

   [13]

   [14]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

   [15]  "Netscape Certificate Extensions Specification",
         <http://wp.netscape.com/eng/security/comm4-cert-exts.html>.

   [14]

   [16]  Clancy, C., "Security Review of the Light Weight Access Point
         Protocol", May 2005,
         <http://www.cs.umd.edu/~clancy/docs/lwapp-review.pdf>.

   [15]

   [17]  Rescorla et al, E., "Datagram Transport Layer Security",
         June 2004.

   [16]

   [18]  "Recommendation for Block Cipher Modes of Operation: the CMAC
         Mode for Authentication", May 2005, <http://csrc.ncsl.nist.gov/
         publications/nistpubs/800-38B/SP_800-38B.pdf>.

17.2.

15.2.  Informational References

   [17]

   [19]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-
         line Database", RFC 3232, January 2002.

   [18]

   [20]  Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.

   [19]

   [21]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [20]

   [22]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [21]

   [23]  Karn, P. and W. Simpson, "ICMP Security Failures Messages",
         RFC 2521, March 1999.

   [24]  "WiFi Protected Access (WPA) rev 1.6", April 2003.

   [22]

   [25]  Dierks et al, T., "The TLS Protocol Version 1.1", June 2005.

   [23]

   [26]  Modadugu et al, N., "The Design and Implementation of Datagram
         TLS", Feb 2004.

   [27]  "The Care and Feeding of Cookie Monsters", May 2006.

   [28]  "Internet Key Exchange (IKEv2) Protocol",
         draft-ietf-ipsec-ikev2-17.txt", September 2004.

Editors' Addresses

   Pat R. Calhoun
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134

   Phone: +1 408-853-5269
   Email: pcalhoun@cisco.com

   Michael P. Montemurro
   Chantry Networks
   1900 Minnesota Court, Suite 125
   Mississauga, ON  L5N 3C9
   Canada

   Phone: +1 905-363-6413 905-363-6400
   Email: michael.montemurro@siemens.com montemurro.michael@gmail.com

   Dorothy Stanley
   Aruba Networks
   1322 Crossman Ave
   Sunnyvale, CA  94089

   Phone: +1 630-363-1389
   Email: dstanley@arubanetworks.com

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.