386 lines
22 KiB
Plaintext
386 lines
22 KiB
Plaintext
|
||
|
||
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]
|
||
|