idnits 2.17.1 draft-ietf-capwap-dhc-ac-option-02.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 285. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 291. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (October 15, 2008) is 5670 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-ietf-capwap-protocol-specification-13 Summary: 2 errors (**), 0 flaws (~~), 2 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 Intended status: Standards Track October 15, 2008 5 Expires: April 18, 2009 7 CAPWAP Access Controller DHCP Option 8 draft-ietf-capwap-dhc-ac-option-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2009. 35 Abstract 37 The Control And Provisioning of Wireless Access Points Protocol 38 allows a Wireless Termination Point to use DHCP to discover the 39 Access Controllers it is to connect to. This document describes the 40 DHCP options to be used by the CAPWAP protocol. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Conventions used in this document . . . . . . . . . . . . 3 46 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. CAPWAP AC DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4 48 3. CAPWAP AC DHCPv6 Option . . . . . . . . . . . . . . . . . . . 5 49 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 50 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 51 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 52 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 53 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 54 7.2. Informational References . . . . . . . . . . . . . . . . . 10 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 56 Intellectual Property and Copyright Statements . . . . . . . . . . 12 58 1. Introduction 60 The Control And Provisioning of Wireless Access Points Protocol 61 (CAPWAP) [I-D.ietf-capwap-protocol-specification] allows a Wireless 62 Termination Point (WTP) to use DHCP to discover the Access 63 Controllers (AC) it is to connect to. 65 Prior to the CAPWAP Discovery process, the WTP may use one of many 66 methods to identify the proper AC to establish a CAPWAP connection 67 with. One of these methods is through the DHCP protocol. This is 68 done through the CAPWAP AC DHCPv4 or CAPWAP AC DHCPv6 Option. 70 1.1. Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119 [RFC2119]. 76 1.2. Terminology 78 This document uses terminology defined in [RFC3753], [RFC2131], 79 [RFC3315] and [I-D.ietf-capwap-protocol-specification]. 81 2. CAPWAP AC DHCPv4 Option 83 This section defines a DHCPv4 option that carries a list of 32-bit 84 (binary) IPv4 addresses indicating one or more CAPWAP AC available to 85 the WTP. 87 The DHCPv4 option for CAPWAP has the format shown in the following 88 figure: 90 0 1 91 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | option-code | option-length | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | | 96 + AC IPv4 Address + 97 | | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | ... | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 option-code: OPTION_CAPWAP_AC_V4 (TBD) 104 option-length: Length of the 'options' field in octets; MUST be a 105 multiple of four (4). 107 AC IPv4 Address: IPv4 address of a CAPWAP AC which the WTP may use. 108 The ACs are listed in the order of preference for use by the WTP. 110 A DHCPv4 client, acting on behalf of a CAPWAP WTP, MUST request the 111 CAPWAP AC DHCPv4 Option in a Parameter Request List Option, as 112 described in [RFC2131] and [RFC2132]. 114 A DHCPv4 server returns the CAPWAP AC Option to the client if the 115 server policy is configured appropriately and the server is 116 configured with a list of CAPWAP AC addresses. 118 A CAPWAP WTP, acting as a DHCPv4 client, receiving the CAPWAP AC 119 DHCPv4 option MAY use the (list of) IP address(es) to locate AC. The 120 CAPWAP protocol [I-D.ietf-capwap-protocol-specification] provides 121 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 DHCPv6 client, acting on behalf of a CAPWAP WTP, MUST request the 161 CAPWAP AC DHCPv6 Option in a Parameter Request List Option, as 162 described in [RFC3315]. 164 A DHCPv6 server returns the CAPWAP AC Option to the client if the 165 server policy is configured appropriately and the server is 166 configured with a list of CAPWAP AC addresses. 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 [I-D.ietf-capwap-protocol-specification] provides 171 guidance on the WTP's discovery process. 173 The WTP, acting as a DHCPv6 client, SHOULD try the records in the 174 order listed in the CAPWAP AC DHCPv6 option received from the DHCPv6 175 server. 177 4. IANA Considerations 179 The following DHCPv4 option code for CAPWAP AC option must be 180 assigned by IANA: 182 Option Name Value Described in 183 ----------------------------------------------- 184 OPTION_CAPWAP_AC_V4 TBD Section 2 186 The following DHCPv6 option code for CAPWAP AC options MUST be 187 assigned by IANA: 189 Option Name Value Described in 190 ------------------------------------------------ 191 OPTION_CAPWAP_AC_V6 TBD Section 3 193 5. Security Considerations 195 The security considerations in [RFC2131], [RFC2132] and [RFC3315] 196 apply. If an adversary manages to modify the response from a DHCP 197 server or insert its own response, a WTP could be led to contact a 198 rogue CAPWAP AC, possibly one that then intercepts call requests or 199 denies service. CAPWAP's use of DTLS MUST be used to authenticate 200 the CAPWAP peers in the establishment of the session. 202 In most of the networks, the DHCP exchange that delivers the options 203 prior to network access authentication is neither integrity protected 204 nor origin authenticated. Therefore, in security sensitive 205 environments the options defined in this document SHOULD NOT be the 206 only methods used to determine which AC a WTP should connect to. The 207 CAPWAP protocol [I-D.ietf-capwap-protocol-specification] defines 208 other AC discovery procedures a WTP MAY utilize. 210 6. Acknowledgments 212 The following individuals are acknowledged for their contributions to 213 this protocol specification: Ralph Droms, Margaret Wasserman. 215 7. References 217 7.1. Normative References 219 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 223 RFC 2131, March 1997. 225 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 226 Extensions", RFC 2132, March 1997. 228 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 229 and M. Carney, "Dynamic Host Configuration Protocol for 230 IPv6 (DHCPv6)", RFC 3315, July 2003. 232 [I-D.ietf-capwap-protocol-specification] 233 Montemurro, M., Stanley, D., and P. Calhoun, "CAPWAP 234 Protocol Specification", 235 draft-ietf-capwap-protocol-specification-13 (work in 236 progress), September 2008. 238 7.2. Informational References 240 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 241 RFC 3753, June 2004. 243 Author's Address 245 Pat R. Calhoun 246 Cisco Systems, Inc. 247 170 West Tasman Drive 248 San Jose, CA 95134 250 Phone: +1 408-902-3240 251 Email: pcalhoun@cisco.com 253 Full Copyright Statement 255 Copyright (C) The IETF Trust (2008). 257 This document is subject to the rights, licenses and restrictions 258 contained in BCP 78, and except as set forth therein, the authors 259 retain all their rights. 261 This document and the information contained herein are provided on an 262 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 263 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 264 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 265 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 266 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 267 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 269 Intellectual Property 271 The IETF takes no position regarding the validity or scope of any 272 Intellectual Property Rights or other rights that might be claimed to 273 pertain to the implementation or use of the technology described in 274 this document or the extent to which any license under such rights 275 might or might not be available; nor does it represent that it has 276 made any independent effort to identify any such rights. Information 277 on the procedures with respect to rights in RFC documents can be 278 found in BCP 78 and BCP 79. 280 Copies of IPR disclosures made to the IETF Secretariat and any 281 assurances of licenses to be made available, or the result of an 282 attempt made to obtain a general license or permission for the use of 283 such proprietary rights by implementers or users of this 284 specification can be obtained from the IETF on-line IPR repository at 285 http://www.ietf.org/ipr. 287 The IETF invites any interested party to bring to its attention any 288 copyrights, patents or patent applications, or other proprietary 289 rights that may cover technology that may be required to implement 290 this standard. Please address the information to the IETF at 291 ietf-ipr@ietf.org.