Internet Engineering Task Force Renxiang Yan Internet Draft Alcatel Shanghai Bell Expiration: July 2005 File: draft-yan-ipv6-ra-dns-00.txt DNS update in IPv6 stateless configuration January 20, 2005 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document specifies a method to update domain name for IPv6 node whose address is configured using IPv6 stateless address configuration. It is implemented by defining a new option in Router Advertisement (RA) / Router Solicitation (RS) messages. Yan Expires July, 2005 [Page 1] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Domain Name Option . . . . . . . . . . . . . . . . . . . . 3 3.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 4 3.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 5 4. Binding rule . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Procedure of DNS update . . . . . . . . . . . . . . . . . . . 6 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1 Router requirements . . . . . . . . . . . . . . . . . . . 7 6.2 Host requirements . . . . . . . . . . . . . . . . . . . . 7 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 8 8. Interaction with DHCPv6 and MIPv6 . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1 Normative References . . . . . . . . . . . . . . . . . . . 9 11.2 Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Copyright Statements . . . . . . . . . . . . . . . . . . . . . . . 10 Yan Expires July, 2005 [Page 2] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 1. Introduction The Domain Name System [2], [3] provides a mechanism to associate addresses and other Internet infrastructure elements with hierarchically built domain names. For an IPv6 host, the general resource records maintained in DNS server are AAAA and PTR. The DNS update specification [6] describes a mechanism that enables DNS information to be updated over a network. IPv6 stateless address autoconfiguration [7] allows a host to generate an unique IPv6 address by combining the prefix, advertised by the router, and the local interface identifier without the help of DHCPv6 server or DHCPv6 client. To perform DNS update for the IPv6 host whose addresses are configured using IPv6 stateless address autoconfiguration, this document defined a new RS/RA option to transfer domain name information and negotiate who will perform DNS update between the host and the router. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Familiarity with the DNS Update protocol [6], IPv6 Neighbour Discovery [8] , and Stateless Address Autoconfiguration [7] is assumed. 3. The Domain Name option This section defines a new option in RS/RA message, called "Domain Name option". The option contains a Domain-name, which is used to transfer domain information between IPv6 host and router, and a Flags, which IPv6 host and router use to negotiate who does DNS updates. The Format of the Domain Name option is shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Domain-name . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Yan Expires July, 2005 [Page 3] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 Type: 8-bit identifier of the type of option(TBD) Length: The length of the option in units of 8 octets. The minimum length of the option is 1 Flags: Flag bits used between host and router to negotiate who performs DNS updates Domain-name: The partial or fully qualified domain name The Domain Name option MUST only appear in options field in Router Advertisement and Router Solicitation message. When appear in RA message, it MUST be used together with Prefix options, to mean that it will be bound with the address(es) configured using those prefix(es). When RS message includes Domain Name option, its source address MUST be generated using the prefix advertised by the previous RA message. 3.1 The Flags Field The Format of the Flags field: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |H|R| RSV | +-+-+-+-+-+-+-+-+ If the router wants to take responsibility for the DNS updates for the host, it will set the "R" bit and clear the "H" bit when sending Domain Name option. If the router wants host to take responsibility for the DNS updates on its own, it will set the "H" bit and clear "R" bit when sending Domain Name option. Host MUST send Domain Name option in RS message When a host sends the Domain Name option in RS message, it clears the "H" bit to indicate that it will not perform any DNS updates, and that it expects the router to perform DNS updates on its behalf. If "R" bit is cleared, and "H" bit is set in RA message, but host have no ability to update DNS on its own, it can still request the router to perform DNS updates by setting both "R" and "H" bit in RS message. Yan Expires July, 2005 [Page 4] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 The remaining bits in the Flags field are reserved for future assignment. IPv6 hosts and routers which send the Host FQDN option MUST set the RSV bits to 0, and they MUST ignore these bits. 3.2 The Domain Name Field The Domain Name field of the option carries all or part of the FQDN of an IPv6 host. The data in the Domain Name field MUST appear in uncompressed DNS encoding as specified in [3]. Domain Name field MUST be padded with 0 to 4-bytes alignment. The router MUST send the zone suffix or NULL in Domain Name Field in Domain Name options. The host MUST send either FQDN or host name in Domain Name Field in Domain Name options. 4. Binding rule As we know, the mapping between IPv6 address and FQDN is multiple-to- multiple. A host can register one FQDN with multiple IPv6 addresses, and also can register one IPv6 address with multiple FQDN. This document specifies a mechanism allowing the router to decide which prefix(es) is bound to which domain name. It is implemented by defining the sequence of the Domain Name option and Prefix option. The Domain Name option MUST be used in combine with Prefix option as defined below: +----------------------------------+ | RA message | +----------------------------------+_ | Prefix options | \ +----------------------------------+ > matching 1 | Domain Name options |_/ +----------------------------------+_ | Prefix options | \ +----------------------------------+ > matching 2 | Domain Name options |_/ +----------------------------------+ | | ~ ... ~ | | +----------------------------------+_ | Prefix options | \ | with no binding | > Unbound | |_/ Prefix +----------------------------------+ Yan Expires July, 2005 [Page 5] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 Domain Name options MUST be placed after one or more Prefix options, to mean that they are in a "matching". Hosts can choose to update the binding, whose IPv6 address and domain name are generated from the prefix and domain information in this matching. A typical case is that multiple Prefix options are bound with one Domain Name option. Prefix option can be conveyed in RA message without binding with any Domain Name option. These "unbound" Prefix MUST be placed after the last Domain Name option. 5. Procedure of DNS update The processing of Domain Name option is handled like any other ND options and would happen when an RA is received. The following figure shows an illustration of the procedure. IPv6 Host Router DNS server | | | (1)|(-----RS (no DNO)------>)| | (2)|<------RA (DNO)----------| | (3)|--------RS (DNO)-------->| | |(-------------------DNS update ------------------>)| (4)| |------DNS update ------->| (DNO is abbreviation of Domain Name Option in the figure) The procedure consists of the following steps: Step (1) : IPv6 Host sends RS (Router Solicitation) message without the Domain Name option to get a RA message. It is optional. Step (2) : For the RS message sent by IPv6 Host, router sends a RA message, which contains Prefix Information option(s) for stateless address autoconfiguration and Domain Name option(s) for DNS update. Step (3) : IPv6 Host processes the RA message, if the result of the negotiation is router performs DNS update, IPv6 host will sends RS message to the router. The RS message contains a Domain Name option, with the source address set to the address generated using that prefix. Then, the process moves to Step (4). If the result of the negotiation is host performs DNS update, it will update its domain name directly with DNS server and finish the whole process. Step (4) : The router sends DNS update message to the DNS server. Yan Expires July, 2005 [Page 6] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 6. Requirements The following describes the requirements of host and router that implements the Domain Name option. 6.1 Router requirements Router MUST only include Domain Name options for the bindings in RA messages. Router MAY include one or more Domain Name options in a single RA message. Router MUST include Domain Name options as the rules defined in Section 5. Router sends the Domain Name options with the "R" flags bit set and "H" flags bit clear, or, "R" flags bit clear and "H" flags bit set. Router MAY be configured to update RR for the host, or simply request host to update on its own if there are no security requirement in local network. In both cases, router MUST be able to update RRs because some hosts may not have the ability to update DNS by itself. There is no requirement that router stores the result of the DNS update when it update RR for the host. Host is required to check the DNS result by sending DNS query to the DNS server. 6.2 Host requirements Host MUST only include Domain Name option in the Options field of Router Solicitation message. Host MUST send RS message with Domain Name option after receiving prefix from a previous RA message. Host MUST only send RS message including Domain Name option to the router if it wants router to take responsibility for the DNS updates. The destination address of this RS message is the unicast address of the router, and the source address MUST be set to the unicast address generated using prefix in a "matching". Host sends the Domain Name option with the "H" flags bit set, the "R" flags bit clear, and with the desired partial domain name. There is no requirement that the host send identical Domain Name option data several times. In particular, if a host has sent Domain Name options to the router, and the configuration of the host changes so that its notion of its domain name changes, it MAY update the Yan Expires July, 2005 [Page 7] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 records in the DNS server by itself, or send the new name data in a Domain Name option to the router, requesting the router to update the records in DNS server. Host MAY not send RS message with Domain Name option for DNS update if it do not need a domain name, e.g. a mobile user may not need a new domain name in foreign network. How to prevent host to update which DNS is the implementation issue. 7. DNS Update Conflicts This document does not address how an IPv6 host or router prevents name conflicts. Implementers of this work will need to consider how name conflicts will be prevented. One possible method may be that the router maintain a mapping table for all hosts in local network, and different router are configured with different domain name suffix. 8. Interaction with DHCPv6 and MIPv6 There may exist cases in which a host can get different global IPv6 address using both RA and DHCP, and the host may want to use a single domain name for all address. In such case, the administrator SHOULD have site local policy to make sure that the zone suffix in the router and in the DHCPv6 server are the same. This can be done by using the Zone Suffix option in DHCPv6 [12]. Host can register each address using FQDN option [13] via DHCPv6 and using Domain Name option via RA/RS separately. If a mobile host in foreign network want to access other PC, it can simply use the care-of-address, if other PC want to communicate the a mobile host in foreign network, it can still use the old domain name of that host and get its home address, them the MIPv6 mechanism will be used. So, for a mobile host in foreign network, it is unnecessary to re-update DNS using new Domain Name option broadcasted by local router. If a mobile host detects it has been located in a foreign network, it can just ignore the Domain Name option included in RA message sent by the foreign router. However, it will be interesting if the mobile host update a new DNS using its original domain name in foreign network, i.e. it updates AAAA record in its home DNS server, and updates PTR record in local foreign DNS server. Such kind of method can replace some functions of MIPv6. Hosts which want to connect to this mobile host will directly get its foreign address by DNS resolution. This issue will be studied in a separate document. Yan Expires July, 2005 [Page 8] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 9. Security Considerations Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. Administrators should be wary of permitting unsecured DNS updates to zones which are exposed to the global Internet. Both host and router SHOULD use some form of update request origin authentication procedure (e.g., Secure DNS Dynamic Update [9]) when performing DNS updates. Malicious host may be able to mount a denial of service attack to router by repeated RS messages with "Domain Name" option. Some kind of security mechanism (e.g., Secure Neighbour Discovery [11]) may be used to setup a trust model between router and hosts. Whether the router may be responsible for DNS update or whether it left this responsibility to host itself is a site-local matter. The choice between the two alternatives may be based on the security model that is used with the DNS update protocol. 10. Acknowledgements I would like to thank Chris Liljenstolpe, Stefaan De Cnodder, Yinglan Jiang, and Emmanuel Desmet for their valuable comments and kindly help. 11. References 11.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [4] Deering, S. and R. Hiden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [5] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [6] P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC2136, April 1997. Yan Expires July, 2005 [Page 9] Internet-Draft DNS update in IPv6 stateless configuration Jan. 2005 [7] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [8] T. Narten, E. Nordmark, W. Simpson , "Neighbor Discovery for IP Version 6", RFC2461, December 1998. 11.2 Informative References [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [10] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [11] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill, P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06.txt, July 17, 2004. [12] R. Yan, L. Gui, Y. Jiang, "Zone suffix option for DHCPv6", draft-yan-dhc-dhcpv6-opt-dnszone-02.txt, December 24, 2004. [13] B. Volz, "The DHCPv6 Client FQDN Option", draft-ietf-dhc- dhcpv6-fqdn-00.txt, September, 2004. Copyright notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Author Information: Renxiang Yan Research & Innovation Center Alcatel Shanghai Bell Co., Ltd. 388#, NingQiao Road, Pudong Jinqiao Shanghai 201206 P.R. China Phone: +86 (21) 5854-1240, ext:7169 Email: renxiang.yan@alcatel-sbell.com.cn Yan Expires July, 2005 [Page 10]