Individual Submission Internet Draft Jae-Hoon Jeong Jung-Soo Park Kyeong-Jin Lee Hyoung-Jun Kim ETRI Expires: December 2003 18 June 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 network. Whenever the mobile node moves into a new MAP domain, the region managed by another MAP, in the hierarchical mobile IPv6 network, 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 recursive DNS server which exists in the region. Therefore, the mechanism of this document can optimize the DNS name resolution. Jeong, Park, Lee, Kim Expires - December 2003 [Page 1] Internet-Draft DNS Autoconfiguration in HMIPv6 June 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 Mobile Node................................5 7. Detection of RDNSS Failure....................................6 8. Security Considerations.......................................6 9. References....................................................7 10. Acknowledgements.............................................7 11. Authors' 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 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 network [3], but also the optimization of the DNS name resolution in such a network. Whenever the mobile node moves into a new MAP (Mobility Anchor Point) domain, the region managed by another MAP, in the hierarchical mobile IPv6 network, it detects the addresses of recursive DNS servers which are placed in the region and Jeong, Park, Lee, Kim Expires - December 2003 [Page 2] Internet-Draft DNS Autoconfiguration in HMIPv6 June 2003 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 recursive DNS server which exists in the region. Like this, because the mobile nodes can use the recursive DNS server in the same domain instead of the fixed recursive DNS server, the DNS name resolution for the mobile nodes can be optimized. 3. Overview +-------+ +--------+ | HA |---| RDNSS1 | +-------+ +--------+ | | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +-------+ | MAP | (MN, RCoA, LCoA-2) +-------+ | | | +--------+ | | | | +--------+ +-----+ +-----+ +--------+ | RDNSS2 |---| AR1 | | AR2 |---| RDNSS3 | +--------+ +-----+ +-----+ +--------+ LCoA-1 LCoA-2 +----+ +----+ | MN | | MN | +----+ ------------> +----+ Movement Figure 1. Optimization of DNS Name Resolution in HMIPv6 Domain Whenever a mobile node enters into another MAP domain of the visited network, it receives a Router Advertisement (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 RDNSSes 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 RDNSS. Because the mobile node uses the nearest Jeong, Park, Lee, Kim Expires - December 2003 [Page 3] Internet-Draft DNS Autoconfiguration in HMIPv6 June 2003 RDNSS in the same MAP domain, RDNSS2 or RDNSS3, instead of the RDNSS in its home network, RDNSS1. When the mobile node moves into another MAP domain, it replaces the old RDNSS(es) with the new RDNSS(es) for the succeeding name resolutions. 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 and list of the RDNSS addresses. The information of the RDNSS(es) in the MAP domain is stored in the MAP by the network administrator and advertised as a new option with MAP option through the RA message. There MAY be more than one RDNSS in a MAP domain. In this case, the MAP advertises RA message including the list of RDNSSes in the same domain with MAP option periodically. 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 requires the manual configuration of the MAP and RDNSS options in the MAP and also the routers, receiving the MAN and RDNSS options, MUST allow themselves to propagate the options on certain interfaces. Finally, whenever the mobile node listening to RA messages receives the new RA message, it 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 RDNSSes in the configuration for DNS name resolution with the new ones. From the next name resolution, the mobile node uses the new RDNSSes. 5. Neighbor Discovery Extension - RDNSS Option Message Format The mechanism of this document needs a new option in Neighbor Discovery [7]. Figure 2 shows the format of RDNSS option message. 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 of RDNSS + | | Jeong, Park, Lee, Kim Expires - December 2003 [Page 4] Internet-Draft DNS Autoconfiguration in HMIPv6 June 2003 + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. RDNSS Option Message Format Fields: Type Message type. TBD. 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 cannot be used. IPv6 Address of RDNSS The RDNSS's IPv6 address. The scope of the address SHOULD be global. The prefix length of the address is /64. When advertising more than one RDNSS, as many RDNSS options as the number of RDNSSes are included in an RA message. 6. RDNSS Selection by Mobile Node When a mobile node perceives multiple RDNSSes through RA message, it stores the addresses of the RDNSSes in order into the configuration which 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 of RDNSS" field in the RDNSS option. The following algorithm is simply based on the rule of selecting the nearest possible RDNSS from the mobile node, 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 RDNSSes. The mobile node operation is shown below: 1) Receive and parse all RDNSS options. 2) Arrange RDNSSes in an ascending order, starting with the nearest RDNSS and store them in the configuration for DNS name Jeong, Park, Lee, Kim Expires - December 2003 [Page 5] Internet-Draft DNS Autoconfiguration in HMIPv6 June 2003 resolution used by resolver. For example, the longest prefix matching between the "IPv6 Address of 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 RDNSSes of the configuration for DNS name 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 among the RDNSSes ordered in the configuration. For example, in Figure 1, when a mobile node (MN) moves into another subnet managed by access router AR2, MN uses RDNSS3 in the same subnet instead of RDNSS2 for name resolution. As a last resort for name resolution, each mobile node SHOULD maintain the address(es) of the RDNSS(es) at its home network in the tail of the list of RDNSS addresses. In the case that there are no available RDNSSes for name resolution at a new MAP domain that a mobile node visits, the node can the RDNSSes of the previous MAP domain or of its home network for name resolution. 7. Detection of RDNSS Failure A MAP placed in a MAP domain checks periodically if the RDNSSes 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 any response cannot be received, an RDNSS option for the RDNSS MAY be sent with a preference value of zero. 8. Security Considerations Jeong, Park, Lee, Kim Expires - December 2003 [Page 6] Internet-Draft DNS Autoconfiguration in HMIPv6 June 2003 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", RFC 2462, December 1998. [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, December 1998. 10. Acknowledgements The authors would like to acknowledge the previous contribution of Luc Beloeil. 11. Authors' 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 Jeong, Park, Lee, Kim Expires - December 2003 [Page 7] Internet-Draft DNS Autoconfiguration in HMIPv6 June 2003 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 - December 2003 [Page 8]