idnits 2.17.1 draft-ietf-dhc-dhcpv6-opt-dnsdomain-04.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 248. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (November 10, 2006) is 6377 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) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group R. Yan 3 Internet Draft Y. Jiang 4 Expiration Date: May 2007 Alcatel Shanghai Bell 5 X. Duan 6 China Mobile 8 Domain Suffix Option for DHCPv6 9 11 November 10, 2006 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 6, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes a new option for DHCPv6 (DHCP for IPv6) that 45 provides a mechanism for specifying a domain name suffix. 47 1. Introduction 49 This document describes a new option for DHCPv6 [RFC3315] that 50 provides a mechanism for specifying a domain name suffix. Using this 51 option, the DHCPv6 server can specify a domain name suffix to the 52 DHCPv6 client. 54 1.1 Terminology 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Domain suffix 61 In this document, the domain suffix is defined as the 62 suffix of a fully qualified domain name (FQDN). It is 63 starts with lower-level domain name and continues all 64 the way up to the top-level domain name. 66 This document should be read in conjunction with the DHCPv6 67 specification, [RFC3315]. Definitions for terms and acronyms used in 68 this document are defined in RFC3315. 70 2. Domain Suffix Option 72 The domain suffix option for DHCPv6 is used by the DHCPv6 server to 73 tell the DHCPv6 client the domain suffix that the DHCPv6 server 74 administrator has specified for that DHCPv6 client. 76 The format of the domain suffix option is: 78 0 1 2 3 79 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 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 | option-code | option-length | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 | | 84 ~ domain suffix ~ 85 | | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 88 option-code: OPTION_DOMAIN_SUFFIX (TBD). 90 option-length: length of the "domain suffix" field in octets. 92 domain suffix: the specification of a domain suffix. 94 The domain suffix in the 'domain suffix' field MUST be encoded as 95 specified in section of RFC3315 titled "Representation and use of 96 domain names", except that it SHOULD only include one domain name, 97 being a series of labels terminated by exactly one root label. 99 If more than one root label is present, the DHCP client 100 implementations MUST select the first name, ignoring any subsequent 101 labels. 103 2.1 Usage 105 A DHCPv6 client MUST include the option code in Option Request 106 Option [RFC3315] if it desires the domain suffix option, and the 107 DHCPv6 server SHOULD include this option in an Advertise or Reply 108 if requested by the client in the Option Request Option. 110 A DHCPv6 server may provide different values for the domain suffix 111 option to different clients. The mechanism for choosing which 112 suffix to assign to which client is a matter of implementation and 113 administrative policy, and is therefore not specified in this 114 document. 116 3. Security Considerations 118 Security considerations in DHCP are described in section 23, 119 "Security Considerations" of RFC3315. 121 4. IANA Considerations 123 IANA is requested to assign a DHCPv6 option code for the 124 OPTION_DOMAIN_SUFFIX. 126 5. Acknowledgements 128 The authors thank Ralph Droms, Ted Lemon, Stig Venaas, Bernie Volz, 129 Tatuya Jinmei, Joe Quanaim and Stefaan De Cnodder for valuable 130 discussions and comments. 132 6. References 134 6.1 Normative References 136 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 137 Requirement Levels", BCP 14, RFC 2119, March 1997. 139 [RFC3315] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. 140 and R. Droms (ed.), "Dynamic Host Configuration Protocol 141 for IPv6 (DHCPv6)", RFC 3315, May 2003. 143 [RFC3633] O. Troan, R. Droms, "IPv6 prefix option for DHCPv6", 144 RFC3633, December 2003. 146 Appendix: Examples 148 The examples defined below are intended to give a reference usage of 149 the domain suffix option. 151 Example 1: Used for host 153 One obvious example for the option is in a case where a DHCP client 154 is not configured to assert a particular domain. The client could 155 request the domain suffix in the ORO option to request the domain 156 name it could use, as the usage for option 15 in DHCPv4. 158 Example 2: Used for IPv6 residential gateway 160 In IPv6 home network, it is easy to imagine that each device can get 161 a globally unique IPv6 address, so that the device could be visited 162 from outside network easily. It will be better if these devices 163 could be accessed using domain name other than the tedious IPv6 164 address. 166 Usually, residential gateway in home network works as a prefix 167 requesting router [RFC3633] to request IPv6 prefix from prefix 168 delegation router and allocate the address to home device using 169 stateless configuration or through an embedded DHCPv6 server. 170 One method to configure the domain suffix in CPEs in large scale is 171 using domain suffix option. 173 During DHCP session initiated by residential gateway, domain suffix 174 name (e.g. example.com) could be specified. 176 The domain suffix can then be used to update domain name for the 177 hosts in subscriber network, by an embedded DHCPv6 server in 178 residencial gateway or by other means of DNS update mechanism for 179 stateless IPv6 configuration. 181 To avoid frequent domain name conflicts, aggregation device might 182 allocate different domain suffix name for the CPE. An example way can 183 be selection based on an external authority such as a RADIUS server, 184 in which an unique domain suffix name prefix, called "home name", are 185 negotiated between user and ISP when subscribing. For example, 186 "user1.example.com" and "user2.example.com". 188 Authors' Addresses 190 Renxiang Yan 191 Yinglan Jiang 192 Research & Innovation Center 193 Alcatel Shanghai Bell Co., Ltd. 194 388#, NingQiao Road, Pudong Jinqiao, 195 Shanghai 201206 P.R. China 196 Phone: +86 (21) 5854-1240, ext. 7169 198 Email: renxiang.yan@alcatel-sbell.com.cn 199 Yinglan.jiang@alcatel-sbell.com.cn 201 Xiaodong Duan 202 Research & Development Center 203 China Mobile Communications Corporation 204 53A, Xibianmennei Ave., Xuanwu District, 205 Beijing, 100053 P.R. China 206 Phone: +86 (10) 6600-6688, ext. 3062 208 Email: duanxiaodong@chinamobile.com 210 Full Copyright Statement 212 Copyright (C) The Internet Society (2006). 214 This document is subject to the rights, licenses and restrictions 215 contained in BCP 78, and except as set forth therein, the authors 216 retain all their rights. 218 This document and the information contained herein are provided on an 219 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 220 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 221 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 222 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 223 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 224 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 226 Intellectual Property 228 The IETF takes no position regarding the validity or scope of any 229 Intellectual Property Rights or other rights that might be claimed to 230 pertain to the implementation or use of the technology described in 231 this document or the extent to which any license under such rights 232 might or might not be available; nor does it represent that it has 233 made any independent effort to identify any such rights. Information 234 on the procedures with respect to rights in RFC documents can be 235 found in BCP 78 and BCP 79. 237 Copies of IPR disclosures made to the IETF Secretariat and any 238 assurances of licenses to be made available, or the result of an 239 attempt made to obtain a general license or permission for the use of 240 such proprietary rights by implementers or users of this 241 specification can be obtained from the IETF on-line IPR repository at 242 http://www.ietf.org/ipr. 244 The IETF invites any interested party to bring to its attention any 245 copyrights, patents or patent applications, or other proprietary 246 rights that may cover technology that may be required to implement 247 this standard. Please address the information to the IETF at ietf- 248 ipr@ietf.org. 250 Acknowledgment 252 Funding for the RFC Editor function is currently provided by the 253 Internet Society.