summaryrefslogtreecommitdiff
path: root/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt')
-rw-r--r--doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt386
1 files changed, 386 insertions, 0 deletions
diff --git a/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt b/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt
new file mode 100644
index 00000000..e49d805e
--- /dev/null
+++ b/doc/draft/draft-jeong-hmipv6-dns-optimization-00.txt
@@ -0,0 +1,386 @@
+
+
+ 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]
+ \ No newline at end of file
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-19 04:50:19 +0000