One document matched: 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.
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]
| PAFTECH AB 2003-2026 | 2026-04-23 15:08:22 |