idnits 2.17.1 draft-yan-dhc-dhcpv6-opt-dnszone-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 196. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 188), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (July 8, 2005) is 6867 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) == Unused Reference: '1' is defined on line 200, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 213, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 219, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 222, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (ref. '2') (Obsoleted by RFC 8415) ** Downref: Normative reference to an Informational RFC: RFC 3363 (ref. '3') == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-fqdn-00 ** Obsolete normative reference: RFC 3736 (ref. '9') (Obsoleted by RFC 8415) -- No information found for draft-yan - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Yan 3 Internet Draft Y. Jiang 4 L. Gui 5 Alcatel Shanghai Bell 6 Expiration: January 2006 X. Duan 7 File: draft-yan-dhc-dhcpv6-opt-dnszone-03.txt China Mobile 9 Domain Suffix Option for DHCPv6 10 12 July 8, 2005 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 6, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document specifies a new DHCPv6 (DHCP for IPv6) option which is 46 passed from a DHCPv6 server to a DHCPv6 client to specify the 47 domain suffix name used to perform domain name update. 49 1.0 Introduction 51 This document describes a new option for DHCPv6 [2] that provides a 52 mechanism for the transfer of a domain suffix name. Using this 53 option, an IPv6 device, which works as a DHCPv6 client, can configure 54 the domain suffix name automatically. 56 For example, a service provider could use this option to transfer a 57 domain suffix name to a Customer Premise Equipment (CPE) device 58 acting as a router between the subscriber's internal network and the 59 service provider's core network. 61 The configured domain suffix name is intended to be used by the IPv6 62 device to perform DNS update for the hosts inside its local network. 63 The DNS update can be realized by several methods, e.g. the DHCPv6 64 Client FQDN Option [6] provides a mechanism to exchange client's FQDN 65 information during a stateful DHCPv6 session. [10] defines a DNS 66 update mechanism for IPv6 stateless configuration. 68 1.1 Terminology 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [4]. 74 This document should be read in conjunction with the DHCPv6 75 specification, RFC 3315 [2]. Definitions for terms and acronyms used 76 in this document are defined in RFC 3315 and RFC 3633 [3]. 78 2.0 Domain Suffix Option 80 The domain suffix option is used to carry a domain suffix to the 81 DHCPv6 client, which will be used to construct and update the domain 82 name for the hosts in local network. 84 The format of the domain suffix option is: 86 0 1 2 3 87 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 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 89 | Type | Length | 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 | | 92 ~ Domain suffix ~ 93 | | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 Type: 16-bits identifier of the type of option (TBD). 98 Length: Length of the "domain suffix" field in octets. 100 Domain suffix: The specification of a domain suffix. 102 The domain suffix in the 'domain suffix' MUST include only one item, 103 and MUST be encoded as specified in section "Representation and use 104 of domain names" of RFC3315. 106 2.1 Usage 108 In stateful DHCPv6 [2], the DHCPv6 server MAY place a domain 109 suffix option in the options field of IA_PD option [3] in an outgoing 110 DHCPv6 message. The DHCPv6 server MUST NOT place a domain suffix 111 option in any other portion of a stateful DHCPv6 message. 113 In stateless DHCPv6 [9], the DHCPv6 server MAY place a domain suffix 114 option in the main option buffer of any DHCPv6 message sent to a 115 client. 117 A DHCPv6 server may provide different values for the domain suffix 118 option to different clients. This is useful to avoid domain name 119 confliction in large-scale network. The mechanism for choosing which 120 suffix to assign to which client is a matter of implementation and 121 administrative policy, and is therefore not specified in this 122 document. 124 3.0 Example 126 +-------+ 127 +------+ + CPE +-+ 128 | Node +--+ +-------+ | 129 +------+ | | 130 | +-------+ | 131 +------+ | + CPE +-+ 132 | Node +--+ +-------+ | +----------+ 133 +------+ | : | | 134 : +-------+ | +------------------+ | ISP Core | 135 +----+ CPE +-+--|Aggregation device|--| | 136 +------+ | +-------+ +------------------+ | Network | 137 | Node +--+ | | 138 +------+ +----------+ 140 \____________ __________/ \_________________ ________________/ 141 \/ \/ 142 Subscriber network ISP network 144 The above figure shows a typical usage of the domain suffix option. 145 In this model, ISP has the ISP level domain name suffix (e.g. 146 example.com). CPE in subscriber network may include a DNS server 147 for name resolution for local hosts. 149 The CPE in the subscriber network, which acts as a requesting 150 router, initiates a DHCPv6 session with the ISP's aggregation device, 151 acting as a delegation route. During the DHCP session, an IPv6 152 prefix, along with the corresponding domain suffix name (i.e. 153 example.com) will be transferred to the CPE. 155 The domain suffix name can then be used to construct the domain name 156 for the hosts in subscriber network, using mechanisms defined in [6] 157 or [10]. 159 To avoid frequent domain name conflicts, aggregation device might 160 allocate different domain suffix name for the CPEs. An example way 161 can be selection based on an external authority such as a RADIUS 162 server, in which a unique domain suffix name prefix, called 163 "home name", is negotiated between user and ISP when subscribing. 164 For example, "user1.example.com" and "user2.example.com". 166 4.0 Security Considerations 168 Security considerations in DHCP are described in section 23, 169 "Security Considerations" of RFC 3315. 171 A rogue DHCP server can issue bogus domain suffix to a client. This 172 may cause wrong domain name update. 174 A malicious client may be able to mount a denial of service attack 175 by repeated DHCP requests for domain suffix, thus exhausts the DHCP 176 server's resource. 178 Currently, it is difficult for DHCP servers to develop much 179 confidence in the identities of its clients, given the absence of 180 entity authentication from the DHCP protocol itself. To guard against 181 attack, DHCP Authentication as described in section 21 of RFC 3315 182 can be used. 184 Copyright notice 186 Copyright (C) The Internet Society (2004). This document is subject 187 to the rights, licenses and restrictions contained in BCP 78, and 188 except as set forth therein, the authors retain all their rights. 190 This document and the information contained herein are provided on an 191 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 192 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 193 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 194 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 195 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 196 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 198 References 200 [1] Deering, S. and R. Hiden, "Internet Protocol, Version 6 (IPv6) 201 Specification", RFC2460, December 1998. 203 [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. 204 Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 205 (DHCPv6)", RFC 3315, May 2003. 207 [3] O. Troan, R. Droms, "IPv6 prefix option for DHCPv6", RFC3363, 208 December 2003. 210 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 211 Levels", BCP 14, RFC 2119, March 1997. 213 [5] P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates 214 in the Domain Name System (DNS UPDATE)", RFC2136, April 1997. 216 [6] B. Volz, "The DHCPv6 Client FQDN Option", draft-ietf-dhc- 217 dhcpv6-fqdn-00.txt, September, 2004. 219 [7] Wellington, B., "Secure Domain Name System (DNS) Dynamic 220 Update", RFC 3007, November 2000. 222 [8] Mockapetris, P., "Domain names - concepts and facilities", STD 223 13, RFC 1034, November 1987. 225 [9] R. Droms, "Stateless Dynamic Host Configuration Protocol (DHCP) 226 Service for IPv6", RFC3736, April 2004. 228 [10] R. Yan, "DNS update in IPv6 stateless configuration", draft-yan 229 -ipv6-ra-dns-01.txt, June 2005. 231 Author Information: 233 Renxiang Yan 234 Yinglan Jiang 235 Luoning Gui 236 Research & Innovation Center 237 Alcatel Shanghai Bell Co., Ltd. 238 388#, NingQiao Road, Pudong Jinqiao, 239 Shanghai 201206 P.R. China 240 Phone: +86 (21) 5854-1240, ext. 7169 242 Email: renxiang.yan@alcatel-sbell.com.cn 243 Yinglan.jiang@alcatel-sbell.com.cn 244 Luoning.gui@alcatel-sbell.com.cn 246 Xiaodong Duan 247 Research & Development Center 248 China Mobile Communications Corporation 249 53A, Xibianmennei Ave., Xuanwu District, 250 Beijing, 100053 P.R. China 251 Phone: +86 (10) 6600-6688, ext. 3062 253 Email: duanxiaodong@chinamobile.com