Individual Submission Luc Beloeil Internet Draft France Telecom R&D Expires: June 2003 January 2003 IPv6 Router Advertisement DNS resolver Option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract This document defines the DNS resolver (DNSR) option used to advertise on a link IPv6 addresses of DNS resolvers. The DNSR option, which lists the IPv6 addresses of DNS resolvers that all nodes of the link may use to resolve name or address, is attached to IPv6 Neighbor Discovery Router Advertisement messages that are sent across a link. This document specifies the process used by a host to decide how to configure the IPv6 addresses of DNS resolvers that the host could use in IPv6 networks. This document defines the mechanism by which a node processes the DNSR option and updates valid IPv6 addresses of DNS resolvers. 1. Introduction This specification defines the DNS resolvers (DNSR) option for the Neighbor Discovery protocol [DISCOVERY]. The DNSR option adds a new functionality to Router Advertisement messages so as to enable further configuration of a node. Router Advertisement messages sent by a router over a link can be used to assign one or more addresses of DNS resolvers to the nodes connected to the link. DNS resolution is a key service for a host connected to an IPv6 network. Indeed [DISCOVERY] allows any node to autoconfigure a global unicast addresses and default routes. Moreover DNS Discovery Design Team proposed several solutions. An option added to Neighbor Discovery protocol was studied but no definition has been proposed. DNSR option will allow any node to discover IPv6 addresses of DNS resolvers (with preference to global-unicast addresses). The purpose is also to enhance the efficiency of [DISCOVERY] when DHCPv6 is not used. 1.1 Motivation Many sites, particularly home networks and small companies networks, are composed of a network with a single Ethernet link, a "plug-and-play" router, and an uplink to a single provider. The DNSR option provides a standard mechanism for advertising DNS Resolver IPv6 address within such sites. 2. Terminology IP - Internet Protocol Version 6. node - a device that implements IP. router - a node that forwards IP packets not addressed to itself. link - a facility over which nodes can exchange IP datagrams, for example, Ethernet, Token Ring, PPP links, and IP tunnels. 2.1. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORDS]. 3. DNS resolver option format 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 | Code | Reserved... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 address of DNS resolver 1 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 address of DNS resolver n + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type XXX [TBD: IANA] Length (8 + 16 x n) : lenght in bytes of the option Code 8-bit unsigned integer 0x0 = DNS Resolver Reply used by routers. 0x1 = DNS Resolver Query used by nodes. If Code is set to 0x1, no IPv6 address MUST be present. Reserved 40-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. IPv6 address of DNS resolver n The IPv6 address of the DNS resolver n. 4. Protocol overview 4.1. Deployment scenario The DNSR option should be sent within Router Advertisements in order to complete stateless address autoconfiguration. All nodes connected to the same link might use the DNSR option to configure the IPv6 addresses of available DNS resolvers those nodes might use for DNS resolutions. +--------+ | Router | +--------+ | link | ------------------------ | | | | Node1 Node2 Node3 Node4 In such a network, the router allows the node to use stateless address autoconfiguration and may send unsolicited Router Advertisement. A DNS resolver may or may not be connected to the link. A typical deployment scenario could be a small network on which several hosts would be connected to a single router. And that router would interconnect that single-subnet network to an ISP. 4.2. Node operation As specified in [DISCOVERY], if a receiver does not recognize the "DNS resolver option", that receiver MUST ignore that option. 4.2.1 Active mode If a node wants to learn IPv6 addresses of available DNS resolvers, it SHOULD send a "DNS resolver Query". A "DNS resolver Query" is a Router Solicitation with a DNSR option. 4.2.2 Passive mode On any link a node SHOULD listen to Router Advertisements [DISCOVERY]. By that way a node may learn the IPv6 addresses of available DNS resolvers in the case another node on the link has just queried for that information, and that a router has just replied by a Router Advertisement including a DNSR option. 4.3. Router operation The way the router learns IPv6 addresses of reachable DNS resolver is out the scope of that document. That could be achieved typically by an access control protocol, DHCP or manual configuration. The router MUST NOT send DNSR option in Unsolicited Router Advertisements. The router MUST reply to a "DNS resolver query" by sending a "DNS Resolver Reply". A "DNS Resolver Reply" is a router advertisement with DNSR option. As specified in [DISCOVERY], that router advertisement MAY be sent to the soliciting host's address, but the usual case is to multicast the response to the all-nodes group. IPv6 address included in the DNSR option MUST not have a scope larger than the largest scope of the prefixes advertised in the Router Advertisement. For example, if the Router Advertisement advertises only site-local prefixes, DNSR option MUST not include global-scope IPv6 addresses, but only local-scope or site-local-scope addresses. If the router is configured not to send Router Advertisement, any DNS resolver query MUST be discarded, and DNS Resolver Reply MUST NOT BE sent. 5. Security considerations DNSR option in Router Advertisement could introduce DoS attacks if fake RA are advertised with bogus IPv6 addresses of DNS resoslvers. Nevertheless such security considerations are actually related to Neighbor Discovery protocol security. Security issues regarding the Neighbor Discovery protocol are discussed in [DISCOVERY] and in IETF send (Securing Neighbor Discovery) working group. 6. Acknowledgments This document is heavily based on [DISCOVERY], and the author wishes to thank T. Narten, E. Nordmark, and W. Simpson for producing it. The author would also like to acknowledge the work of Jun-ichiro Itojun Hagino and Kazu Yamamoto and all the DNS Discovery Design Team in surveying possible mechanisms for site configuration that eventually lead to this specification. A special thanks to Nathan Lutchansky from who the form of that draft has been inspired. Thanks to Pekka Savola, A. Baudot, D. Binet who have reviewed this draft. 7. References ADDRCONF Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. ADDR-ARCH Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. DISCOVERY Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. KEYWORDS Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8. Author's Address Luc Beloeil France Telecom R&D 42, rue des coutures BP 6243 14066 CAEN Cedex 4 France Phone: (33) 02 31 75 93 91 EMail: luc.beloeil@francetelecom.com 9. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.