📄 draft-jeong-hmipv6-dns-optimization-00.txt
字号:
Individual Submission Internet Draft Jae-Hoon Jeong Jung-Soo Park Kyeong-Jin Lee Hyoung-Jun Kim <draft-jeong-hmipv6-dns-optimization-00.txt> 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.
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -