Individual Submission Internet Draft Jae-Hoon Jeong Jung-Soo Park Kyeong-Jin Lee Hyoung-Jun Kim ETRI Expires: August 2003 February 2003 The Autoconfiguration of Recursive DNS Server and the Optimization of DNS Name Resolution in Hierarchical Mobile IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted [1]. 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 provides the mechanism for the autoconfiguration of recursive DNS server in mobile node and the optimization of DNS name resolution in the hierarchical mobile IPv6 networks. Whenever the mobile node moves into a new MAP domain, the region managed by another MAP, in the hierarchical mobile IPv6 networks, it detects the addresses of recursive DNS servers which are placed in the region and replaces the old ones with the new ones for DNS name resolution. This allows the time for DNS name resolution much reduced by using the nearest DNS recursive server which exists in the region. Therefore, the mechanism of this document can optimize the DNS name resolution. Jeong, Park, Lee, Kim Expires - August 2003 [Page 1] DNS Autoconfiguration and Optimization in HMIPv6 February 2003 Conventions used in this document 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 RFC 2119 [2]. Table of Contents 1. Terminology....................................................2 2. Introduction...................................................2 3. Overview.......................................................3 4. HMIPv6 extension - Advertisement of Recursive DNS Server.......4 5. Neighbor Discovery extension - RDNSS option message format.....4 6. RDNSS selection by the Mobile Node.............................5 7. Detection of RDNSS failure.....................................6 8. Security Considerations........................................6 9. References.....................................................6 10. Author's Addresses............................................7 1. Terminology This memo uses the terminology described in [3]. In addition, a new term is defined below: Recursive DNS Server (RDNSS) A Recursive DNS Server is a name server that offers the recursive service of DNS name resolution. 2. Introduction RFC 2462 [4] provides a way to autoconfigure either fixed or mobile nodes with one or more IPv6 addresses and default routes. For the support of the various services in the Internet, not only the configuration of IP address in network interface, but also that of the recursive DNS server for DNS name resolution are necessary. Up to now, many mechanisms to autoconfigure recursive DNS server in nodes have been proposed [5][6]. This document suggests not only the autoconfiguration of recursive DNS server in mobile node that moves within the hierarchical mobile IPv6 networks [3], but also the optimization of the DNS name resolution in such networks. Whenever the mobile node moves into a new MAP (Mobility Anchor Point) domain, the region managed by another MAP, in the hierarchical mobile IPv6 networks, it detects the addresses of recursive DNS servers which are placed in the region and replaces the old ones with the new ones for DNS name resolution. This allows the time for DNS name resolution much reduced by using the Jeong, Park, Lee, Kim Expires - August 2003 [Page 2] DNS Autoconfiguration and Optimization in HMIPv6 February 2003 nearest DNS recursive server which exists in the region. Like this, because the mobile nodes use the recursive DNS server in the same domain instead of the fixed recursive DNS server, the DNS name resolution of the mobile nodes can be optimized. 3. Overview +-------+ +--------+ | HA |---| RDNSS1 | +-------+ +--------+ | | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +-------+ | MAP | RCoA +-------+ | | | +--------+ | | | | +-----+ +-----+ +--------+ | AR1 | | AR2 |---| RDNSS2 | +-----+ +-----+ +--------+ +----+ | MN | +----+ ------------> Movement Figure 1: Optimization of DNS Name Resolution in HMIPv6 domain Whenever a mobile node enters into a new MAP domain of the visited network, it receives the RA message including MAP option from Access Router (AR) and performs the local binding update with the new MAP. If the list of the addresses of the recursive DNS server (RDNSS) is included in the RA message with the MAP option, the mobile node can detect the new RDNSSs and select one of them for the DNS name resolution. Like Figure 1, this scheme can reduce considerably the time of the name resolution between the mobile node and the RDNSS. Because the mobile node uses the nearest RDNSS in the same MAP domain, RDNSS2, instead of the RDNSS in its home network, RDNSS1. When the mobile node moves into another MAP domain, it replaces the old RDNSS with the new RDNSS for the succeeding name resolutions. Jeong, Park, Lee, Kim Expires - August 2003 [Page 3] DNS Autoconfiguration and Optimization in HMIPv6 February 2003 4. HMIPv6 extension - Advertisement of Recursive DNS Server Because this document considers only router advertisement for MAP discovery, all ARs belonging to the MAP domain MUST advertise the MAP's IP address. The information of the RDNSS in the MAP domain is stored in the MAP by the network administrator and advertised as a new option through the RA message with MAP option. There MAY be more than one RDNSS in a MAP domain. A MAP advertises the RA message including the list of RDNSSs in the same domain with MAP option. The RA message with MAP and RDNSS options is propagated from the MAP to the mobile node through certain (configured) router interfaces within the hierarchy of routers. This would require manual configuration of the MAP and RDNSS options in the MAP and also the routers receiving the MAN and RDNSS options to allow them to propagate the options on certain interfaces. Finally, the mobile node listening to RA messages receives the new RA message and checks if the MAP is new or not. If the MAP is a new one, the mobile node perceives it has moved into another MAP domain and performs both the local binding update with the new MAP and the update of the list of RDNSSs in the configuration of name resolution with the new ones. From the next name resolution, the mobile node uses the new RDNSSs. 5. Neighbor Discovery extension - RDNSS option message format The mechanism of this document needs a new option in Neighbor Discovery [7]. 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( = 3) | Pref | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address for RDNSS + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jeong, Park, Lee, Kim Expires - August 2003 [Page 4] DNS Autoconfiguration and Optimization in HMIPv6 February 2003 Fields: Type Message type. TBA. Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The default value is 3. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. Pref The preference of an RDNSS. A 4 bit unsigned integer. A decimal value of 15 indicates the highest preference. A decimal value of 0 indicates that the RDNSS can not be used. IPv6 Address for RDNSS The RDNSS IPv6 address. The scope of the address can be any scope. i.e., link-local, site-local and global. The prefix of the address is be /64. When advertising more than one RDNSS, as many RDNSS options as the number of RDNSSs are included in an RA message. 6. RDNSS selection by the Mobile Node When a mobile node perceives multiple RDNSSs through RA message, it stores the RDNSSs in order into the configuration the resolver on the node uses for DNS name resolution on the basis of the value of "Pref" field and the prefix of "IPv6 Address for RDNSS" field in the RDNSS option. The following algorithm is simply based on the rule of selecting the nearest possible RDNSS, providing that its preference value did not reach the maximum value of 15. When the distances are the same, this algorithm uses the preference value to order the RDNSSs. The mobile node operation is shown below: 1) Receive and parse all RDNSS options 2) Arrange RDNSSs in an ascending order, starting with the nearest RDNSS and store them in the configuration for DNS name resolution used by resolver. (i.e., the longest prefix matching between the "IPv6 Address for RDNSS" field and mobile node's On-link CoA (LCoA) MAY be used to decide the distance between mobile node and RDNSS, how far away the mobile node is from the RDNSS.) 3) For each RDNSS entry, check the following; - If the value of "Pref" field is set to zero, exclude the RDNSS entry from the list of RDNSSs of the configuration for DNS name Jeong, Park, Lee, Kim Expires - August 2003 [Page 5] DNS Autoconfiguration and Optimization in HMIPv6 February 2003 resolution. Whenever the resolver on the mobile node performs the name resolution, it refers to the address(es) of RDNSS in the configuration for name resolution according to the current rule of selecting an RDNSS, namely from the 1st RDNSS. 7. Detection of RDNSS failure A MAP placed in a MAP domain checks periodically if the RDNSSs registered in the MAP are alive. Whenever the MAP detects the failure of any RDNSS, it advertises the failure down to the hierarchy with a new RA message including an RDNSS option of which "Pref" field has zero for the RDNSS. When a mobile node receives the RA message, it perceives that the RDNSS is out of work or the path to the RDNSS is broken and excludes the RDNSS from the configuration for name resolution. The dynamic detection of RDNSS failure in a MAP can be done by simply pinging the RDNSS periodically (e.g., every ten seconds). If no response is received, the MAP MAY try to aggressively ping the RDNSS for a short period of time (e.g., once every 5 seconds for 15 seconds); if no response is received, an RDNSS option MAY be sent with a preference value of zero. 8. Security Considerations In order to guarantee the secure communication between routers, the router advertisements sent between routers SHOULD be authenticated by AH or ESP [3]. This security is essentially related to Neighbor Discovery protocol security [7]. 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft- ietf-mobileip-hmipv6-07.txt, October 2002. [4] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462. Jeong, Park, Lee, Kim Expires - August 2003 [Page 6] DNS Autoconfiguration and Optimization in HMIPv6 February 2003 [5] A. Durand, J. itojun and D. Thaler, "Well known site local unicast addresses to communicate with recursive DNS servers", draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002. [6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option", draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003. [7] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for IP version 6", RFC 2461. 10. Author's Addresses Jae-Hoon Jeong ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 1664 EMail: paul@etri.re.kr Jung-Soo Park ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6514 EMail: pjs@etri.re.kr Kyeong-Jin Lee ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6484 EMail: leekj@etri.re.kr Hyoung-Jun Kim ETRI / PEC 161 Gajong-Dong, Yusong-Gu Daejon 305-350 Korea Phone: +82 42 860 6576 EMail: khj@etri.re.kr Jeong, Park, Lee, Kim Expires - August 2003 [Page 7]