One document matched: draft-jeong-hmipv6-dns-optimization-01.txt
Differences from 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-01.txt> 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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:09:41 |