idnits 2.17.1 draft-ietf-capwap-dhc-ac-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 287. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 12, 2007) is 6162 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 205, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-07 ** Obsolete normative reference: RFC 3315 (ref. '4') (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 14, 2007 June 12, 2007 6 CAPWAP Access Controller DHCP Option 7 draft-ietf-capwap-dhc-ac-option-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 14, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 The Control And Provisioning of Wireless Access Points Protocol 41 allows a Wireless Termination Point to use DHCP to discover the 42 Access Controllers it is to connect to. This document describes the 43 DHCP options to be used by the CAPWAP protocol. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Conventions used in this document . . . . . . . . . . . . 3 49 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. CAPWAP AC DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4 51 3. CAPWAP AC DHCPv6 Option . . . . . . . . . . . . . . . . . . . 5 52 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 54 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 57 7.2. Informational References . . . . . . . . . . . . . . . . . 9 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 Intellectual Property and Copyright Statements . . . . . . . . . . 11 61 1. Introduction 63 The Control And Provisioning of Wireless Access Points Protocol 64 (CAPWAP) [5] allows a Wireless Termination Point (WTP) to use DHCP to 65 discover the Access Controllers (AC) it is to connect to. 67 Prior to the CAPWAP Discovery process, the WTP MAY use one of many 68 methods to identify the proper AC to establish a CAPWAP connection 69 with. One of these methods is through the DHCP protocol. This is 70 done through the CAPWAP AC DHCPv4 or CAPWAP AC DHCPv6 Option. 72 1.1. Conventions used in this document 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [1]. 78 1.2. Terminology 80 This document uses terminology defined in [6] and [5]. 82 2. CAPWAP AC DHCPv4 Option 84 This section defines a DHCPv4 option that carries a list of 32-bit 85 (binary) IPv4 addresses indicating one or more CAPWAP AC available to 86 the WTP. 88 The DHCPv4 option for CAPWAP has the format shown in the following 89 figure: 91 0 1 92 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | option-code | option-length | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | | 97 + AC IPv4 Address + 98 | | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | ... | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 option-code: OPTION_CAPWAP_AC_V4 (TBD) 105 option-length: Length of the 'options' field in octets; MUST be a 106 multiple of four (4). 108 AC IPv4 Address: IPv4 address of a CAPWAP AC which the WTP may use. 109 The ACs are listed in the order of preference for use by the WTP. 111 A CAPWAP WTP, acting as a DHCPv4 client, SHOULD request the CAPWAP AC 112 DHCPv4 Option in a Parameter Request List as described in [2] and 113 [3]. 115 If configured with a (list of) CAPWAP AC address(es), a DHCPv4 server 116 SHOULD send the client the CAPWAP AC DHCPv4 option, even if this 117 option is not explicitly requested by the client. 119 A CAPWAP WTP, acting as a DHCPv4 client, receiving the CAPWAP AC 120 DHCPv4 option MAY use the (list of) IP address(es) to locate AC. The 121 CAPWAP protocol [5] provides guidance on the WTP's discovery process. 123 The WTP, acting as a DHCPv4 client, SHOULD try the records in the 124 order listed in the CAPWAP AC DHCPv4 option received from the DHCPv4 125 server. 127 3. CAPWAP AC DHCPv6 Option 129 This section defines a DHCPv6 option that carries a list of 128-bit 130 (binary) IPv6 addresses indicating one or more CAPWAP AC available to 131 the WTP. 133 The DHCPv6 option for CAPWAP has the format shown in the following 134 figure: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | option-code | option-length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | | 142 + + 143 | | 144 + AC IPv6 Address + 145 | | 146 + + 147 | | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | .... | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 option-code: OPTION_CAPWAP_AC_V6 (TBD) 154 option-length: Length of the 'options' field in octets; MUST be a 155 multiple of sixteen (16). 157 AC IPv6 Address: IPv6 address of a CAPWAP AC which the WTP may use. 158 The ACs are listed in the order of preference for use by the WTP. 160 A CAPWAP WTP, acting as a DHCPv6 client, SHOULD request the CAPWAP AC 161 DHCPv6 Option in a Parameter Request List as described in [2] and 162 [3]. 164 If configured with a (list of) CAPWAP AC address(es), a DHCPv6 server 165 SHOULD send the client the CAPWAP AC DHCPv6 option, even if this 166 option is not explicitly requested by the client. 168 A CAPWAP WTP, acting as a DHCPv6 client, receiving the CAPWAP AC 169 DHCPv6 option MAY use the (list of) IP address(es) to locate AC. The 170 CAPWAP protocol [5] provides guidance on the WTP's discovery process. 172 The WTP, acting as a DHCPv6 client, SHOULD try the records in the 173 order listed in the CAPWAP AC DHCPv6 option received from the DHCPv6 174 server. 176 4. IANA Considerations 178 The following DHCPv4 option code for CAPWAP AC option MUST be 179 assigned by IANA: 181 Option Name Value Described in 182 ----------------------------------------------- 183 OPTION_CAPWAP_AC_V4 TBD Section 2 185 The following DHCPv6 option code for CAPWAP AC options MUST be 186 assigned by IANA: 188 Option Name Value Described in 189 ------------------------------------------------ 190 OPTION_CAPWAP_AC_V6 TBD Section 3 192 5. Security Considerations 194 The security considerations in [2], [3] and [4] apply. If an 195 adversary manages to modify the response from a DHCP server or insert 196 its own response, a WTP could be led to contact a rogue CAPWAP AC, 197 possibly one that then intercepts call requests or denies service. 198 CAPWAP's use of DTLS MUST be used to authenticate the CAPWAP peers in 199 the establishment of the session. 201 In most of the networks, the DHCP exchange that delivers the options 202 prior to network access authentication is neither integrity protected 203 nor origin authenticated. Therefore, the options defined in this 204 document are not the only methods used to determine which AC a WTP 205 should connect to. The CAPWAP protocol [5] defines other AC 206 discovery procedures a WTP MAY utilize. 208 6. Acknowledgements 210 The following individuals are acknowledged for their contributions to 211 this protocol specification: Ralph Droms, Margaret Wasserman. 213 7. References 215 7.1. Normative References 217 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 218 Levels", BCP 14, RFC 2119, March 1997. 220 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 221 March 1997. 223 [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 224 Extensions", RFC 2132, March 1997. 226 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 227 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 228 RFC 3315, July 2003. 230 [3] Calhoun, P., Montemurro, M., Stanley, D., "CAPWAP Protocol 231 Specification", draft-ietf-capwap-protocol-specification-07 232 (work in progress), June 2007. 234 7.2. Informational References 236 [6] Manner, J. and M. Kojo, "Mobility Related Terminology", 237 RFC 3753, June 2004. 239 Author's Address 241 Pat R. Calhoun 242 Cisco Systems, Inc. 243 170 West Tasman Drive 244 San Jose, CA 95134 246 Phone: +1 408-853-5269 247 Email: pcalhoun@cisco.com 249 Full Copyright Statement 251 Copyright (C) The IETF Trust (2007). 253 This document is subject to the rights, licenses and restrictions 254 contained in BCP 78, and except as set forth therein, the authors 255 retain all their rights. 257 This document and the information contained herein are provided on an 258 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 259 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 260 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 261 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 262 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 263 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 265 Intellectual Property 267 The IETF takes no position regarding the validity or scope of any 268 Intellectual Property Rights or other rights that might be claimed to 269 pertain to the implementation or use of the technology described in 270 this document or the extent to which any license under such rights 271 might or might not be available; nor does it represent that it has 272 made any independent effort to identify any such rights. Information 273 on the procedures with respect to rights in RFC documents can be 274 found in BCP 78 and BCP 79. 276 Copies of IPR disclosures made to the IETF Secretariat and any 277 assurances of licenses to be made available, or the result of an 278 attempt made to obtain a general license or permission for the use of 279 such proprietary rights by implementers or users of this 280 specification can be obtained from the IETF on-line IPR repository at 281 http://www.ietf.org/ipr. 283 The IETF invites any interested party to bring to its attention any 284 copyrights, patents or patent applications, or other proprietary 285 rights that may cover technology that may be required to implement 286 this standard. Please address the information to the IETF at 287 ietf-ipr@ietf.org. 289 Acknowledgment 291 Funding for the RFC Editor function is provided by the IETF 292 Administrative Support Activity (IASA).