

                  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] 
