idnits 2.17.1 draft-ietf-capwap-dhc-ac-option-01.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 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 289. 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 : ---------------------------------------------------------------------------- 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 (March 13, 2008) is 5887 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-10 Summary: 2 errors (**), 0 flaws (~~), 3 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: September 14, 2008 March 13, 2008 6 CAPWAP Access Controller DHCP Option 7 draft-ietf-capwap-dhc-ac-option-01 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 September 14, 2008. 34 Abstract 36 The Control And Provisioning of Wireless Access Points Protocol 37 allows a Wireless Termination Point to use DHCP to discover the 38 Access Controllers it is to connect to. This document describes the 39 DHCP options to be used by the CAPWAP protocol. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1. Conventions used in this document . . . . . . . . . . . . 3 45 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. CAPWAP AC DHCPv4 Option . . . . . . . . . . . . . . . . . . . 4 47 3. CAPWAP AC DHCPv6 Option . . . . . . . . . . . . . . . . . . . 5 48 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 49 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 50 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 52 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 53 7.2. Informational References . . . . . . . . . . . . . . . . . 10 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 55 Intellectual Property and Copyright Statements . . . . . . . . . . 12 57 1. Introduction 59 The Control And Provisioning of Wireless Access Points Protocol 60 (CAPWAP) [I-D.ietf-capwap-protocol-specification] allows a Wireless 61 Termination Point (WTP) to use DHCP to discover the Access 62 Controllers (AC) it is to connect to. 64 Prior to the CAPWAP Discovery process, the WTP MAY use one of many 65 methods to identify the proper AC to establish a CAPWAP connection 66 with. One of these methods is through the DHCP protocol. This is 67 done through the CAPWAP AC DHCPv4 or CAPWAP AC DHCPv6 Option. 69 1.1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC 2119 [RFC2119]. 75 1.2. Terminology 77 This document uses terminology defined in [RFC3753] and 78 [I-D.ietf-capwap-protocol-specification]. 80 2. CAPWAP AC DHCPv4 Option 82 This section defines a DHCPv4 option that carries a list of 32-bit 83 (binary) IPv4 addresses indicating one or more CAPWAP AC available to 84 the WTP. 86 The DHCPv4 option for CAPWAP has the format shown in the following 87 figure: 89 0 1 90 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 | option-code | option-length | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | | 95 + AC IPv4 Address + 96 | | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | ... | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 option-code: OPTION_CAPWAP_AC_V4 (TBD) 103 option-length: Length of the 'options' field in octets; MUST be a 104 multiple of four (4). 106 AC IPv4 Address: IPv4 address of a CAPWAP AC which the WTP may use. 107 The ACs are listed in the order of preference for use by the WTP. 109 A CAPWAP WTP, acting as a DHCPv4 client, SHOULD request the CAPWAP AC 110 DHCPv4 Option in a Parameter Request List as described in [RFC2131] 111 and [RFC2132]. 113 If configured with a (list of) CAPWAP AC address(es), a DHCPv4 server 114 SHOULD send the client the CAPWAP AC DHCPv4 option, even if this 115 option is not explicitly requested by the client. 117 A CAPWAP WTP, acting as a DHCPv4 client, receiving the CAPWAP AC 118 DHCPv4 option MAY use the (list of) IP address(es) to locate AC. The 119 CAPWAP protocol [I-D.ietf-capwap-protocol-specification] provides 120 guidance on the WTP's discovery process. 122 The WTP, acting as a DHCPv4 client, SHOULD try the records in the 123 order listed in the CAPWAP AC DHCPv4 option received from the DHCPv4 124 server. 126 3. CAPWAP AC DHCPv6 Option 128 This section defines a DHCPv6 option that carries a list of 128-bit 129 (binary) IPv6 addresses indicating one or more CAPWAP AC available to 130 the WTP. 132 The DHCPv6 option for CAPWAP has the format shown in the following 133 figure: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | option-code | option-length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | | 141 + + 142 | | 143 + AC IPv6 Address + 144 | | 145 + + 146 | | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | .... | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 option-code: OPTION_CAPWAP_AC_V6 (TBD) 153 option-length: Length of the 'options' field in octets; MUST be a 154 multiple of sixteen (16). 156 AC IPv6 Address: IPv6 address of a CAPWAP AC which the WTP may use. 157 The ACs are listed in the order of preference for use by the WTP. 159 A CAPWAP WTP, acting as a DHCPv6 client, SHOULD request the CAPWAP AC 160 DHCPv6 Option in a Parameter Request List as described in [RFC2131] 161 and [RFC2132]. 163 If configured with a (list of) CAPWAP AC address(es), a DHCPv6 server 164 SHOULD send the client the CAPWAP AC DHCPv6 option, even if this 165 option is not explicitly requested by the client. 167 A CAPWAP WTP, acting as a DHCPv6 client, receiving the CAPWAP AC 168 DHCPv6 option MAY use the (list of) IP address(es) to locate AC. The 169 CAPWAP protocol [I-D.ietf-capwap-protocol-specification] provides 170 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 [RFC2131], [RFC2132] and [RFC3315] 195 apply. If an adversary manages to modify the response from a DHCP 196 server or insert its own response, a WTP could be led to contact a 197 rogue CAPWAP AC, possibly one that then intercepts call requests or 198 denies service. CAPWAP's use of DTLS MUST be used to authenticate 199 the CAPWAP peers in 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 206 [I-D.ietf-capwap-protocol-specification] defines other AC discovery 207 procedures a WTP MAY utilize. 209 6. Acknowledgements 211 The following individuals are acknowledged for their contributions to 212 this protocol specification: Ralph Droms, Margaret Wasserman. 214 7. References 216 7.1. Normative References 218 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 219 Requirement Levels", BCP 14, RFC 2119, March 1997. 221 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 222 RFC 2131, March 1997. 224 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 225 Extensions", RFC 2132, March 1997. 227 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 228 and M. Carney, "Dynamic Host Configuration Protocol for 229 IPv6 (DHCPv6)", RFC 3315, July 2003. 231 [I-D.ietf-capwap-protocol-specification] 232 Calhoun, P., "CAPWAP Protocol Specification", 233 draft-ietf-capwap-protocol-specification-10 (work in 234 progress), March 2008. 236 7.2. Informational References 238 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 239 RFC 3753, June 2004. 241 Author's Address 243 Pat R. Calhoun 244 Cisco Systems, Inc. 245 170 West Tasman Drive 246 San Jose, CA 95134 248 Phone: +1 408-853-5269 249 Email: pcalhoun@cisco.com 251 Full Copyright Statement 253 Copyright (C) The IETF Trust (2008). 255 This document is subject to the rights, licenses and restrictions 256 contained in BCP 78, and except as set forth therein, the authors 257 retain all their rights. 259 This document and the information contained herein are provided on an 260 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 261 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 262 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 263 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 264 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 265 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 Intellectual Property 269 The IETF takes no position regarding the validity or scope of any 270 Intellectual Property Rights or other rights that might be claimed to 271 pertain to the implementation or use of the technology described in 272 this document or the extent to which any license under such rights 273 might or might not be available; nor does it represent that it has 274 made any independent effort to identify any such rights. Information 275 on the procedures with respect to rights in RFC documents can be 276 found in BCP 78 and BCP 79. 278 Copies of IPR disclosures made to the IETF Secretariat and any 279 assurances of licenses to be made available, or the result of an 280 attempt made to obtain a general license or permission for the use of 281 such proprietary rights by implementers or users of this 282 specification can be obtained from the IETF on-line IPR repository at 283 http://www.ietf.org/ipr. 285 The IETF invites any interested party to bring to its attention any 286 copyrights, patents or patent applications, or other proprietary 287 rights that may cover technology that may be required to implement 288 this standard. Please address the information to the IETF at 289 ietf-ipr@ietf.org.