idnits 2.17.1 draft-yan-ipv6-ra-dns-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 444. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 436), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** 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. 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 (June 25, 2005) is 6880 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: '4' is defined on line 399, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 402, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 419, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '4') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2462 (ref. '7') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. '8') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '10') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-03) exists of draft-yan-dhc-dhcpv6-opt-dnszone-02 == Outdated reference: A later version (-05) exists of draft-ietf-dhc-dhcpv6-fqdn-00 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 5 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 Alcatel Shanghai Bell 4 Expiration: December 2005 X. Duan 5 File: draft-yan-ipv6-ra-dns-01.txt China Mobile 7 DNS update in IPv6 stateless configuration 8 10 June 25, 2005 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 25, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Abstract 43 This document specifies a method to update domain name for IPv6 node 44 whose address is configured using IPv6 stateless address 45 configuration. It is implemented by defining a new option in 46 Router Advertisement (RA) / Router Solicitation (RS) messages. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. The Domain Name Option . . . . . . . . . . . . . . . . . . . . 3 53 3.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 4 54 3.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 5 55 4. Binding rule . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Procedure of DNS update . . . . . . . . . . . . . . . . . . . 6 57 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6.1 Router requirements . . . . . . . . . . . . . . . . . . . 7 59 6.2 Host requirements . . . . . . . . . . . . . . . . . . . . 7 60 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 8 61 8. Interaction with DHCPv6 and MIPv6 . . . . . . . . . . . . . . 8 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 11.1 Normative References . . . . . . . . . . . . . . . . . . . 9 66 11.2 Informative References . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 Copyright Statements . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 The Domain Name System [2], [3] provides a mechanism to associate 73 addresses and other Internet infrastructure elements with 74 hierarchically built domain names. For an IPv6 host, the general 75 resource records maintained in DNS server are AAAA and PTR. The DNS 76 update specification [6] describes a mechanism that enables DNS 77 information to be updated over a network. 79 IPv6 stateless address autoconfiguration [7] allows a host to 80 generate an unique IPv6 address by combining the prefix, advertised 81 by the router, and the local interface identifier without the help of 82 DHCPv6 server or DHCPv6 client. 84 To perform DNS update for the IPv6 host whose addresses are 85 configured using IPv6 stateless address autoconfiguration, this 86 document defined a new RS/RA option to transfer domain name 87 information and negotiate who will perform DNS update between the 88 host and the router. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [1]. 96 Familiarity with the DNS Update protocol [6], IPv6 Neighbour 97 Discovery [8] , and Stateless Address Autoconfiguration [7] is 98 assumed. 100 3. The Domain Name option 102 This section defines a new option in RS/RA message, called 103 "Domain Name Option". The option contains a Domain-name, which is 104 used to transfer domain information between IPv6 host and router, 105 and a Flags, which IPv6 host and router use to negotiate who does 106 DNS updates. 108 The Format of the Domain Name option is shown below: 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Type | Length | Flags | Reserved | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | | 116 . Domain-name . 117 . . 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Type: 8-bit identifier of the type of option(TBD) 121 Length: The length of the option in units of 8 octets. The 122 minimum length of the option is 1 124 Flags: Flag bits used between host and router to 125 negotiate who performs DNS updates 127 Domain-name: The partial or fully qualified domain name 129 The Domain Name option MUST only appear in options field in Router 130 Advertisement and Router Solicitation message. 132 When appear in RA message, it MUST be used together with Prefix 133 options, to mean that it will be bound with the address(es) 134 configured using those prefix(es). 136 When RS message includes Domain Name option, its source address MUST 137 be generated using the prefix advertised by the previous RA message. 139 3.1 The Flags Field 141 The Format of the Flags field: 143 0 1 2 3 4 5 6 7 144 +-+-+-+-+-+-+-+-+ 145 |H|R| RSV | 146 +-+-+-+-+-+-+-+-+ 148 If the router wants to take responsibility for the DNS updates for 149 the host, it will set the "R" bit and clear the "H" bit when sending 150 Domain Name option. 152 If the router wants host to take responsibility for the DNS updates 153 on its own, it will set the "H" bit and clear "R" bit when sending 154 Domain Name option. 156 Host MUST only send the Domain Name option in an RS message. 158 When a host sends the Domain Name option in RS message, it clears the 159 "H" bit to indicate that it will not perform any DNS updates, and 160 that it expects the router to perform DNS updates on its behalf. 162 If "R" bit is cleared, and "H" bit is set in RA message, but host 163 have no ability to update DNS on its own, it can still request the 164 router to perform DNS updates by setting both "R" and "H" bit in 165 RS message. 167 The remaining bits in the Flags field are reserved for future 168 assignment. IPv6 hosts and routers which send the Host FQDN 169 option MUST set the RSV bits to 0, and they MUST ignore these bits. 171 3.2 The Domain Name Field 173 The Domain Name field of the option carries all or part of the FQDN 174 of an IPv6 host. The data in the Domain Name field MUST appear in 175 uncompressed DNS encoding as specified in [3]. 177 Domain Name field MUST be padded with 0 to 4-bytes alignment. 179 The router MUST send the zone suffix or NULL in Domain Name Field in 180 Domain Name options. The host MUST send either FQDN or host name in 181 Domain Name Field in Domain Name options. 183 4. Binding rule 185 As we know, the mapping between IPv6 address and FQDN is multiple-to- 186 multiple. A host can register one FQDN with multiple IPv6 addresses, 187 and also can register one IPv6 address with multiple FQDN. This 188 document specifies a mechanism allowing the router to decide which 189 prefix(es) is bound to which domain name. It is implemented by 190 defining the sequence of the Domain Name option and Prefix option. 192 The Domain Name option MUST be used in combine with Prefix option as 193 defined below: 195 +----------------------------------+ 196 | RA message | 197 +----------------------------------+_ 198 | Prefix options | \ 199 +----------------------------------+ > matching 1 200 | Domain Name options |_/ 201 +----------------------------------+_ 202 | Prefix options | \ 203 +----------------------------------+ > matching 2 204 | Domain Name options |_/ 205 +----------------------------------+ 206 | | 207 ~ ... ~ 208 | | 209 +----------------------------------+_ 210 | Prefix options | \ 211 | with no binding | > Unbound 212 | |_/ Prefix 213 +----------------------------------+ 215 Domain Name options MUST be placed after one or more Prefix options, 216 to mean that they are in a "matching". Hosts can choose to update 217 the binding, whose IPv6 address and domain name are generated from 218 the prefix and domain information in this matching. A typical case is 219 that multiple Prefix options are bound with one Domain Name option. 221 Prefix option can be conveyed in RA message without binding with any 222 Domain Name option. These "unbound" Prefix MUST be placed after the 223 last Domain Name option. 225 5. Procedure of DNS update 227 The processing of Domain Name option is handled like any other ND 228 options and would happen when an RA is received. The following 229 figure shows an illustration of the procedure. 231 IPv6 Host Router DNS server 232 | | | 233 (1)|(-----RS (no DNO)------>)| | 234 (2)|<------RA (DNO)----------| | 235 (3)|--------RS (DNO)-------->| | 236 |(-------------------DNS update ------------------>)| 237 (4)| |------DNS update ------->| 239 (DNO is abbreviation of Domain Name Option in the figure) 241 The procedure consists of the following steps: 243 Step (1) : IPv6 Host sends RS (Router Solicitation) message without 244 the Domain Name option to get a RA message. It is 245 optional. 247 Step (2) : For the RS message sent by IPv6 Host, router sends a RA 248 message, which contains Prefix Information option(s) for 249 stateless address autoconfiguration and Domain Name 250 option(s) for DNS update. 252 Step (3) : IPv6 Host processes the RA message, if the result of the 253 negotiation is router performs DNS update, IPv6 host will 254 sends RS message to the router. The RS message contains 255 a Domain Name option, with the source address set to the 256 address generated using that prefix. Then, the process 257 moves to Step (4). If the result of the negotiation is 258 host performs DNS update, it will update its domain name 259 directly with DNS server and finish the whole process. 261 Step (4) : The router sends DNS update message to the DNS server. 263 6. Requirements 265 The following describes the requirements of host and router that 266 implements the Domain Name option. 268 6.1 Router requirements 270 Router MUST only include Domain Name options for the bindings in 271 RA messages. 273 Router MAY include one or more Domain Name options in a single RA 274 message. 276 Router MUST include Domain Name options as the rules defined in 277 Section 5. 279 Router sends the Domain Name options with the "R" flags bit set and 280 "H" flags bit clear, or, "R" flags bit clear and "H" flags bit set. 282 Router MAY be configured to update RR for the host, or simply request 283 host to update on its own if there are no security requirement in 284 local network. In both cases, router MUST be able to update RRs 285 because some hosts may not have the ability to update DNS by itself. 287 There is no requirement that router stores the result of the DNS 288 update when it update RR for the host. Host is required to check the 289 DNS result by sending DNS query to the DNS server. 291 6.2 Host requirements 293 Host MUST only include Domain Name option in the Options field of 294 Router Solicitation message. 296 Host MUST send RS message with Domain Name option after receiving 297 prefix from a previous RA message. 299 Host MUST only send RS message including Domain Name option to the 300 router if it wants router to take responsibility for the DNS updates. 301 The destination address of this RS message is the unicast address of 302 the router, and the source address MUST be set to the unicast address 303 generated using prefix in a "matching". 305 Host sends the Domain Name option with the "H" flags bit set, the 306 "R" flags bit clear, and with the desired partial domain name. 308 There is no requirement that the host send identical Domain Name 309 option data several times. In particular, if a host has sent Domain 310 Name options to the router, and the configuration of the host changes 311 so that its notion of its domain name changes, it MAY update the 312 records in the DNS server by itself, or send the new name data in a 313 Domain Name option to the router, requesting the router to update the 314 records in DNS server. 316 Host MAY not send RS message with Domain Name option for DNS update 317 if it do not need a domain name, e.g. a mobile user may not need a 318 new domain name in foreign network. How to prevent host to update 319 which DNS is the implementation issue. 321 7. DNS Update Conflicts 323 This document does not address how an IPv6 host or router prevents 324 name conflicts. 326 Implementers of this work will need to consider how name conflicts 327 will be prevented. One possible method may be that the router 328 maintain a mapping table for all hosts in local network, and 329 different router are configured with different domain name suffix. 331 8. Interaction with DHCPv6 and MIPv6 333 There may exist cases in which a host can get different global IPv6 334 address using both RA and DHCP, and the host may want to use a single 335 domain name for all address. In such case, the administrator SHOULD 336 have site local policy to make sure that the zone suffix in the 337 router and in the DHCPv6 server are the same. This can be done by 338 using the Zone Suffix option in DHCPv6 [12]. Host can register each 339 address using FQDN option [13] via DHCPv6 and using Domain Name 340 option via RA/RS separately. 342 If a mobile host in foreign network want to access other PC, it can 343 simply use the care-of-address, if other PC want to communicate the 344 a mobile host in foreign network, it can still use the old domain 345 name of that host and get its home address, them the MIPv6 mechanism 346 will be used. So, for a mobile host in foreign network, it is 347 unnecessary to re-update DNS using new Domain Name option broadcasted 348 by local router. If a mobile host detects it has been located in a 349 foreign network, it can just ignore the Domain Name option included 350 in RA message sent by the foreign router. 352 However, it will be interesting if the mobile host update a new DNS 353 using its original domain name in foreign network, i.e. it updates 354 AAAA record in its home DNS server, and updates PTR record in local 355 foreign DNS server. Such kind of method can replace some functions 356 of MIPv6. Hosts which want to connect to this mobile host will 357 directly get its foreign address by DNS resolution. This issue will 358 be studied in a separate document. 360 9. Security Considerations 362 Unauthenticated updates to the DNS can lead to tremendous confusion, 363 through malicious attack or through inadvertent misconfiguration. 364 Administrators should be wary of permitting unsecured DNS updates to 365 zones which are exposed to the global Internet. Both host and router 366 SHOULD use some form of update request origin authentication 367 procedure (e.g., Secure DNS Dynamic Update [9]) when performing DNS 368 updates. 370 Malicious host may be able to mount a denial of service attack to 371 router by repeated RS messages with "Domain Name" option. Some kind 372 of security mechanism (e.g., Secure Neighbour Discovery [11]) may be 373 used to setup a trust model between router and hosts. 375 Whether the router may be responsible for DNS update or whether it 376 left this responsibility to host itself is a site-local matter. The 377 choice between the two alternatives may be based on the security 378 model that is used with the DNS update protocol. 380 10. Acknowledgements 382 I would like to thank Chris Liljenstolpe, Stefaan De Cnodder, 383 Yinglan Jiang, and Emmanuel Desmet for their valuable comments and 384 kindly help. 386 11. References 388 11.1 Normative References 390 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 391 Levels", BCP 14, RFC 2119, March 1997. 393 [2] Mockapetris, P., "Domain names - concepts and facilities", STD 394 13, RFC 1034, November 1987. 396 [3] Mockapetris, P., "Domain names - implementation and 397 specification", STD 13, RFC 1035, November 1987. 399 [4] Deering, S. and R. Hiden, "Internet Protocol, Version 6 (IPv6) 400 Specification", RFC2460, December 1998. 402 [5] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 403 Extensions to Support IP Version 6", RFC 3596, October 2003. 405 [6] P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates 406 in the Domain Name System (DNS UPDATE)", RFC2136, April 1997. 408 [7] S. Thomson, T. Narten, "IPv6 Stateless Address 409 Autoconfiguration", RFC 2462, December 1998. 411 [8] T. Narten, E. Nordmark, W. Simpson , "Neighbor Discovery for IP 412 Version 6", RFC2461, December 1998. 414 11.2 Informative References 416 [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic 417 Update", RFC 3007, November 2000. 419 [10] Eastlake, D., "Domain Name System Security Extensions", RFC 420 2535, March 1999. 422 [11] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill, P. Nikander, "SEcure 423 Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06.txt, July 424 17, 2004. 426 [12] R. Yan, L. Gui, Y. Jiang, "Zone suffix option for DHCPv6", 427 draft-yan-dhc-dhcpv6-opt-dnszone-02.txt, December 24, 2004. 429 [13] B. Volz, "The DHCPv6 Client FQDN Option", draft-ietf-dhc- 430 dhcpv6-fqdn-00.txt, September, 2004. 432 Copyright notice 434 Copyright (C) The Internet Society (2005). This document is subject 435 to the rights, licenses and restrictions contained in BCP 78, and 436 except as set forth therein, the authors retain all their rights. 438 This document and the information contained herein are provided on an 439 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 440 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 441 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 442 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 443 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 444 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 446 Author Information: 448 Renxiang Yan 449 Research & Innovation Center 450 Alcatel Shanghai Bell Co., Ltd. 451 388#, NingQiao Road, Pudong Jinqiao 452 Shanghai 201206 P.R. China 454 Phone: +86 (21) 5854-1240, ext:7169 455 Email: renxiang.yan@alcatel-sbell.com.cn 457 Xiaodong Duan 458 Research & Development Center 459 China Mobile Communications Corporation 460 53A, Xibianmennei Ave., Xuanwu District, 461 Beijing, 100053 P.R. China 462 Phone: +86 (10) 6600-6688, ext. 3062 464 Email: duanxiaodong@chinamobile.com