idnits 2.17.1 draft-wang-dhc-ldn-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5295], [RFC5296]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2009) is 5398 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: 'RFC3118' is mentioned on line 223, but not defined == Unused Reference: 'RFC2131' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 268, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5296 (Obsoleted by RFC 6696) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Y. Wang 3 Q. Wu 4 Internet Draft Huawei 5 Intended status: Standards Track July 6, 2009 6 Expires: January 2010 8 DHCP Option for Local Domain Name Discovery 9 draft-wang-dhc-ldn-option-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and 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-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on January 6, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document defines the local domain name option for DHCPv4 and 47 DHCPv6. This option is used by the Peer (DHCP client) to request 48 local domain name described in [RFC5296] which is used to derive the 49 local root key, e.g., DSRK defined in [RFC5295]. 51 Table of Contents 53 1. Introduction.................................................3 54 2. Conventions used in this document............................3 55 3. Local Domain Name Option.....................................3 56 3.1. DHCPv4 Local Domain Name Option.........................3 57 3.2. DHCPv4 Local Domain Name Sub-Option.....................4 58 3.3. DHCPv6 Local Domain Name Option.........................4 59 4. Appearance of the option.....................................5 60 5. Client Behavior..............................................5 61 6. Relay Agent Behavior.........................................5 62 7. Server Behavior..............................................6 63 8. Security Considerations......................................6 64 9. IANA Considerations..........................................6 65 10. References..................................................6 66 10.1. Normative References...................................6 67 10.2. Informative References.................................7 68 11. Acknowledgments.............................................7 69 Appendix A. Example of Local Domain Name Discovery..............8 71 1. Introduction 73 [RFC5295] defines the domain-specific root keys (DSRK) which can be 74 used in the specific domain, e.g., local domain which the peer may be 75 attached to. [RFC5296] introduces one re-authentication mechanism in 76 which the local root key, e.g., DSRK is used to derive re- 77 authentication key to re-authenticate the peer in the local domain 78 where the peer is attached. Considering the local root key is 79 generated based on the local domain name, the local domain name (LDN) 80 discovery is one important part of re-authentication. If the peer 81 does not know the local domain name, ERP exchange or lower-layer 82 announcement mechanism is required as described in the [RFC5296]. 83 However lower-layer announcement to obtain the local domain name is 84 not specified. 86 This document defines a Local Domain Name (Sub-)Option for DHCPv4 and 87 DHCPv6. It can be used by the Peer acting as DHCP client to obtain 88 the local domain name. 90 If a DHCPv4 client involves in the local domain name discovery, then 91 the DHCPv4 Local Domain Name Option defined in section 3.1 or 3.2 92 should be included. 94 If a DHCPv6 client involves in the local domain name discovery, then 95 the DHCPv6 Local Domain Name Option defined in section 3.3 should be 96 included. 98 2. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC2119 [RFC2119]. 104 3. Local Domain Name Option 106 In general, the local domain name discovery is used to request local 107 domain name. It happens after network access authentication. An 108 example of local domain name discovery is described in Appendix A. In 109 the local domain name discovery, the LDN option is used by the client 110 (Peer) to obtain the local domain name from DHCP Server. 112 3.1. DHCPv4 Local Domain Name Option 114 The format of the option is: 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Code | Length | Local Domain Name ... 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 Code: The option code (TBD). 124 Length: The option length, minimum 1 octet. 126 Local Domain Name: The local domain name MUST be encoded using the 127 technique described in section 3.1 of RFC1035 [RFC1035]. It MUST NOT 128 be stored in compressed form, as described in section 4.1.4 of 129 RFC1035 [RFC1035]. 131 3.2. DHCPv4 Local Domain Name Sub-Option 133 It is a sub-option of the relay-agent-information option [RFC3046]. 134 The format of the sub-option is: 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 | Code | Length | Local Domain Name ... 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Code: The option code (TBD). 144 Length: The option length, minimum 1 octet. 146 Local Domain Name: The local domain name MUST be encoded using the 147 technique described in section 3.1 of RFC1035 [RFC1035]. It MUST NOT 148 be stored in compressed form, as described in section 4.1.4 of 149 RFC1035 [RFC1035]. 151 3.3. DHCPv6 Local Domain Name Option 153 The format of this option is: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | OPTION_LOCAL_DOMAIN_NAME | option-length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | local-domain-name ... 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 option-code: OPTION_LOCAL_DOMAIN_NAME (TBD) 165 option-length: Length of the 'local domain name' field in octets 167 local-domain-name: The local domain name MUST be encoded as specified 168 in section "Representation and use of domain names" of [RFC3315]. 170 4. Appearance of the option 172 The DHCPv4 LDN option MUST NOT appear in DHCPv4 messages other than 173 the types DHCPOFFER and DHCPACK. Also the option-code of DHCPv4 LDN 174 option MAY appear in the Parameter Request List in the DHCPv4 message 175 types DHCPDISCOVERY and DHCPREQUEST. 177 The DHCPv4 LDN sub-option MUST NOT appear in DHCPv4 messages other 178 than the types DHCPDISCOVERY and DHCPREQUEST. 180 The DHCPv6 LDN option MUST NOT appear in DHCPv6 messages other than 181 the types Solicit, Advertise, Request, Information-Request and Reply. 182 Also the option-code of LDN option MAY appear in the Option Request 183 Option in the DHCPv6 message types Solicit, Request and Information- 184 Request. 186 5. Client Behavior 188 If a DHCPv4 client (Peer) requires DHCP Server to provide the DHCPv4 189 LDN option, it MUST include an Parameter Request List, requesting the 190 DHCPv4 LDN option, as described in section 9.8 of RFC2132 [RFC2132]. 192 If a DHCPv6 client (Peer) requires DHCP Server to provide the DHCPv6 193 LDN option, it MUST include an Option Request option, requesting the 194 DHCPv6 LDN option, as described in section 22.7 of RFC3315 [RFC3315]. 196 6. Relay Agent Behavior 198 If a DHCPv4 relay agent retrieves the local domain name from 199 authentication server, it SHOULD include it in the DHCPv4 LDN sub- 200 option in a relay-agent-information option [RFC3046] and forward to 201 the DHCPv4 server. 203 If a DHCPv6 relay agent retrieves the local domain name from 204 authentication server, it SHOULD include it in the DHCPv6 LDN option 205 and forward to the DHPv6 server. 207 7. Server Behavior 209 If a DHCPv4 LDN option in the Parameter Request List or a DHCPv6 LDN 210 option in an ORO has been requested, the server SHOULD return the 211 DHCPv4 or DHCPv6 the LDN option to the client. If a DHCPv4 LDN sub- 212 option or a DHCPv6 LDN option is included from relay agent, the 213 server SHOULD extract the local domain name and encapsulate it in the 214 returned LDN option. 216 8. Security Considerations 218 The communication between the DHCP client and the DHCP server for 219 the exchange of local domain name information is security sensitive 220 and requires authentication, integrity and replay protection. Either 221 lower-layer security (such as link layer security established as 222 part of the network access authentication protocol run) or DHCP 223 security [RFC3118] can be used. 225 9. IANA Considerations 227 Three option codes need to be assigned. 229 DHCPv4 LDN Option Code 231 DHCPv4 LDN Sub-Option Code 233 DHCPv6 LDN Option Code 235 10. References 237 10.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 243 "Specification for the Derivation of Root Keys from an 244 Extended Master Session Key (EMSK)", RFC 5295, August 2008. 246 [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- 247 authentication Protocol (ERP)", RFC 5296, August 2008. 249 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 250 M. Carney, "Dynamic Host Configuration Protocol for IPv6 251 (DHCPv6)", RFC 3315, July 2003. 253 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 254 Bucknell University, March 1997. 256 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 257 Extensions", RFC 2132, March 1997. 259 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 260 RFC 3046, January 2001. 262 [RFC1035] Mockapetris, P., "Domain Names -- Implementation and 263 Specification", STD 13, RFC 1035, USC/Information Sciences 264 Institute, November 1987. 266 10.2. Informative References 268 [RFC1034] Mockapetris, P., "Domain Names -- Concepts and Facilities", 269 STD 13, RFC 1034, USC/Information Sciences Institute, 270 November 1987. 272 11. Acknowledgments 274 Thanks to DHC and Hokey members for their comments. 276 Appendix A. Example of Local Domain Name Discovery 278 This section introduces a example of local domain name discovery. In 279 this example, the AAA client and DHCP Relay agent integrates into the 280 same NAS. The local domain name can be assigned by the AAA server, 281 e.g., ER server in the hokey re-authentication architecture or 282 allocated by the DHCP server. The detailed procedure is shown below. 284 +--------------+ +-------------+ +-------------+ +--------------+ 285 | Client(Peer) | | Relay Agent | | DHCP Server | | AAA Server | 286 | | | (AAA Client)| | | | | 287 +------+-------+ +------+------+ +------+------+ +------+-------+ 288 | | | | 289 | 1. Initial Attachment and Access Authentication | 290 |<--------------->+<---------------+--------------->| 291 | | | | 292 | | 2. AAA (Local Domain Name) | 293 | |<--------------------------------| 294 | | | | 295 | +-----------------------------+ | | 296 | | 3.Extract Local Domain Name | | | 297 | +-----------------------------+ | | 298 | | | | 299 |4.DHCP Solicit/Request/Info-Request | 300 |---------------->| | | 301 | |5 DHCP Solicit/Request/Info-Request 302 | |--------------->| | 303 | | | | 304 | |6. DHCP Advertise/Reply/Info-Reply 305 | |<---------------| | 306 |7.DHCP Advertise/Reply/Info-Reply | | 307 |<----------------| | | 308 | | | | 310 During step1 ~ step3, the client (Peer) performs initial attachment 311 and access authentication with the AAA Server through NAS (relay 312 agent). In success case, the AAA Server sends the AAA message with 313 the local domain name to NAS (relay agent). NAS (relay agent) 314 extracts the local domain name from the AAA message and then stores 315 it in the local database. 317 During step4 ~ step11, the client (Peer) initiates the DHCP process, 318 requesting a LDN option in an ORO in DHCP Solicit/ Request/ 319 Information-Request message, to DHCP Server. If the local domain name 320 is allocated by the AAA server at said step2, the relay agent SHOULD 321 include the local domain name in the LDN option/sub-option of the 322 being relayed message, and send it to the DHCP Server. 324 The DHCP Server checks if the LDN option code is included in an ORO 325 of DHCPv6 message or in the Parameter Request List of DHCPv4 message. 326 If included, it MUST return the local domain name with the LDN option 327 encapsulated in DHCP message to the client (Peer). If a DHCPv4 LDN 328 sub-option or a DHCPv6 LDN option is included by the relay agent, 329 i.e., the AAA server allocate the local domain name, the DHCP server 330 SHOULD extract the local domain name received from the relay agent 331 and encapsulate it in the returned LDN option. 333 Authors' Addresses 335 Yungui Wang 336 Huawei Technologies Co.,Ltd. 337 Floor 10, HuiHong Mansion, No.91 BaiXia Rd. 338 Nanjing, Jiangsu, 210001 P.R.China 340 Email: w52006@huawei.com 342 Qin Wu 343 Huawei Technologies Co.,Ltd. 344 Floor 12, HuiHong Mansion, No.91 BaiXia Rd. 345 Nanjing, Jiangsu, 210001 P.R.China 347 Email: sunseawq@huawei.com