[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   Individual Submission
   Internet Draft                                        Jae-Hoon Jeong
                                                         Byung-Yeob Kim
                                                          Jung-Soo Park
                                                         Hyoung-Jun Kim
   <draft-jeong-ipv6-ra-dns-autoconf-00.txt>                       ETRI
   Expires: October 2003                                  17 April 2003


           IPv6 Router Advertisement based DNS Autoconfiguration


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 specifies the steps a node takes in deciding how to
   autoconfigure its domain name per interface in IP version 6 and the
   address of recursive DNS server.  The autoconfiguration process
   includes a node's creating a domain name for its global address,
   verifying the uniqueness of the name in the domain where it is placed
   and registering both the regular domain name and inverse domain name
   information of the node with DNS server automatically.  Also, it
   autoconfigures the address of recursive DNS server for DNS name
   resolution.

Conventions used in this document





Jeong, Kim, Park, Kim    Expires - October 2003               [Page 1]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   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. Neighbor Discovery Extension - DNS Option Message Format.......3
   5. Autoconfiguration of Domain Name...............................5
      5.1 Generation of Domain Name..................................7
      5.2 Verification of the Uniqueness of Domain Name..............7
      5.3 Registration of Domain Name................................7
   6. Autoconfiguration of Recursive DNS Server......................7
      6.1 RDNSS Selection by IPv6 Node...............................8
      6.2 Detection of RDNSS Failure.................................8
   7. Security Considerations........................................9
   8. References.....................................................9
   9. Authors' Addresses............................................10

1. Terminology

   This memo uses the terminology described in [3][4].  In addition, two
   new terms are defined below:

   Duplicate Name Detection (DND)  A mechanism to verify the uniqueness
                                   of a domain name through DNS dynamic
                                   update.

   Recursive DNS Server (RDNSS)    A Recursive DNS Server is a name
                                   server that offers the recursive
                                   service of DNS name resolution.

2. Introduction

   IPv6 stateless address autoconfiguration [5] 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, such as web
   service, not only the configuration of IP address in network
   interface, but also that of the recursive DNS server for DNS name
   resolution are necessary [6][7][8].  Also, via the IPv6
   autoconfiguration facility, the domain name for the autoconfigured
   IPv6 address needs to be autoconfigured in the node and registered
   with DNS server managing the domain where the node is placed.



Jeong, Kim, Park, Kim    Expires - October 2003              [Page 2]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   This document defines the process for generating a domain name,
   verifying the uniqueness of the name through DND [3][9] and
   registering the domain name information with DNS server managing the
   zone of the domain through DNS dynamic update [3].  Also, it
   specifies the autoconfiguration of the IPv6 address(es) of recursive
   DNS server for DNS name resolution.

3. Overview

   An IPv6 node can autoconfigure its domain name via IPv6 Router
   Advertisement (RA) based domain name autoconfiguration [4].  This
   automatic mechanism allows a node to generate its own domain name
   using a combination of locally available information and information
   advertised by routers.  A router sends RA message advertising DNS
   zone suffix that includes the subnet(s) associated with a link and
   the address of DNS server managing the DNS zone.  When a node
   receives RA message, it selects one of user identifiers configured
   within itself and then makes its domain name by combining its
   selected user identifier and the DNS zone suffix within RA message.
   The node SHOULD verify the uniqueness of the name through DND.  If
   there is no duplication, the node registers the domain name
   information consisting of regular domain name and inverse domain name
   information with DNS server managing the zone of the domain through
   DNS dynamic update.  Otherwise, it tries to make a new name with one
   of the other candidates of configured user identifiers and DNS zone
   suffix and then configure the name through the procedure of verifying
   the uniqueness of the name through DND again.  In the absence of
   routers, a node can generate only local domain name with local zone
   ".local" [10] and verifies the uniqueness of the name through DND
   [3][9].  If the name is unique, the node configures the name as its
   domain name.  Otherwise, it tries to make a new name and configure
   the name through the procedure of verifying the uniqueness of the
   name again.

   Also, a node can autoconfigure the IPv6 address of RDNSS for DNS name
   resolution through DNS option included in RA message.

4. Neighbor Discovery Extension - DNS Option Message Format

   The DNS autoconfiguration mechanism in this document needs a new RA
   option in Neighbor Discovery like Figure 1 [4].









Jeong, Kim, Park, Kim    Expires - October 2003              [Page 3]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


    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    |  Pref |A|      Reserved       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Reserved                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                   IPv6 Address of DNS Server                  +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    ~                        DNS Zone Suffix                        ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1. DNS Option Message Format


    Fields:

      Type            8-bit identifier of the type of option.

                               Option Name               Type

                         Source Link-Layer Address         1
                         Link-Layer Address                2
                         Prefix Information                3
                         Redirected Header                 4
                         MTU                               5
                          .                                .
                          .                                .
                         DNS Information                 (TBD)

      Length          8-bit unsigned integer.  The length of the
                      option (including the type and length fields)
                      in units of 8 octets.  The value 0 is invalid.
                      Nodes MUST silently discard an ND packet that
                      contains an option with length zero.

      Pref            The preference of a DNS server.  A 4 bit unsigned
                      integer.  A decimal value of 15 indicates the
                      highest preference.  A decimal value of 0
                      indicates that the DNS server can not be used.


Jeong, Kim, Park, Kim    Expires - October 2003              [Page 4]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


      A               1-bit autonomous DNS configuration flag.
                      When set indicates that this DNS zone suffix can
                      be used for stateless domain name
                      autoconfiguration.

      IPv6 Address of DNS Server
                      The IPv6 address of DNS server managing the
                      domain which the DNS zone suffix indicates.  The
                      scope of the address SHOULD be global.
                      The prefix of the address is /64.
                      This address can be used as recursive DNS
                      server's address for DNS name resolution.

      DNS Zone Suffix
                      The DNS zone suffix of the domain where the
                      subnet is placed.  This field is comprised of
                      a sequence of labels, where each label consists
                      of a length octet followed by that number of
                      octets.  The suffix terminates with the zero
                      length octet for the null label of the root.
                      This field SHOULD be padded with zeroes to be
                      the multiple of 8 octets.

   When advertising more than one DNS option, as many DNS options as DNS
   servers are included in an RA message.

5. Autoconfiguration of Domain Name

             IPv6 Node     Router     DNS Server

                 |   global   |            |
              (a)|(----RS--->)|            |
              (b)|<----RA-----|            |
              (c)|---DAD NS--->            |
              (d)|    no NA   |            |
              (e)|------------------------>|
              (f)|<------------------------|
                 |            |            |
              (g)|------------------------>|
              (h)|<------------------------|
              (i)|------------------------>|
              (j)|<------------------------|
                 |                         |

      Figure 2. Procedure of IPv6 Address and Domain Name
   Autoconfiguration




Jeong, Kim, Park, Kim    Expires - October 2003              [Page 5]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   Figure 2 shows the procedure of autoconfiguring a domain name as well
   as an IPv6 address in an IPv6 node [11][12].  The procedure consists
   of two phases. The first phase is the address autoconfiguration (step
   (a) through step (d)) and the second is the domain name
   autoconfiguration (step (e) through step (j)) as follows;

   Step (a) : IPv6 Node sends RS (Router Solicitation) message to get RA
   (Router Advertisement) message.  It is optional.

   Step (b) : For the RS message received from IPv6 Node, router sends
   RA message, which contains prefix option for the stateless address
   autoconfiguration and DNS option informing IPv6 nodes of the address
   of DNS server and DNS zone suffix.

   Step (c) : After making an IPv6 address, the IPv6 Node sends NS
   (Neighbor Solicitation) message for duplicate address detection (DAD).

   Step (d) : If there is no NA (Neighbor Advertisement) message for the
   NS message, the tentative address is unique in the subnet and it can
   be used as the IPv6 node's address.

   Step (e) : After autoconfiguring an IPv6 address, IPv6 Node makes a
   unique domain name with one of the candidates of user id and the DNS
   zone suffix announced by DNS option message.  It sends DNS Server a
   dynamic update request message for verifying the uniqueness of the
   domain name through DNS dynamic update [3][9].

   Step (f) : DNS Server sends the IPv6 Node a dynamic update response
   message.  If the response indicates the verified domain name is
   unique, the IPv6 Node performs the following step (g).  Otherwise, It
   performs the previous step (e) again.

   Step (g) : IPv6 Node sends DNS Server a dynamic update request
   message for registering regular domain name information.

   Step (h) : DNS Server sends IPv6 Node a dynamic update response
   message indicating the successful registration of regular domain name
   information.

   Step (i) : IPv6 Node sends DNS Server a dynamic update request
   message for registering inverse domain name information.

   Step (j) : DNS Server sends IPv6 Node a dynamic update response
   message indicating the successful registration of inverse domain name
   information.





Jeong, Kim, Park, Kim    Expires - October 2003              [Page 6]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   Some parts of the above steps MIGHT be tied together.  Step (g) and
   step (i) can be merged in a single step.  Also, step (h) and step (j)
   can be performed together.

5.1 Generation of Domain Name

   The generation of domain name depends on the local policy.  This
   document suggests an example of the naming schemes for the domain
   name generation.

   The following procedure is based on user preferred identifiers, such
   as foo, foo1, foo2, etc.  These user identifiers are stored in the
   configuration file for domain name autoconfiguration.

   Step (a) : Node selects one unused user identifier in order from the
   list of user identifiers.

   Step (b) : Node combines the user identifier with the advertised DNS
   zone suffix.  When multiple DNS zone suffixes and DNS servers are
   known, node selects one unused DNS zone suffix in the descending
   order of "Pref" field from the list of DNS zone suffixes.  When
   verifying and registering the domain name, node uses the DNS server
   corresponding to the DNS zone suffix.

   As another example of generating a unique domain name, a domain name
   can be made with user identifier and a part of uniqueness-verified IP
   address [13].

5.2 Verification of the Uniqueness of Domain Name

   Node verifies the uniqueness of a generated domain name through DND
   with the advertised DNS server.  If there is a name conflict, the
   node generates a new domain name with unused user identifier and DNS
   zone suffix and then verifies the uniqueness of the name again.
   Otherwise, it registers the domain name information.

5.3 Registration of Domain Name

   For the unique domain name, the node registers both the regular
   domain name and inverse domain name information of the node with DNS
   server sequentially as described in Figure 2.

6. Autoconfiguration of Recursive DNS Server

   The addresses of DNS servers are announced by DNS options in RA
   message.  These addresses can be used for recursive DNS service
   providing DNS name resolution.  For the autoconfiguration of the
   domain name and recursive DNS server, the DNS zone suffix and RDNSS's


Jeong, Kim, Park, Kim    Expires - October 2003              [Page 7]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   address are stored in the configuration file for DNS resolver; i.e.,
   /etc/resolv.conf in UNIX.

6.1 RDNSS Selection by IPv6 Node

   When an IPv6 node perceives multiple RDNSSes through RA message, it
   stores the RDNSS addresses 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 DNS Server"
   field in the DNS option.  The following algorithm is simply based on
   the rule of selecting the nearest possible RDNSS from the node by hop
   count between the node and RDNSS, provided 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 arrange the RDNSSes.
   The IPv6 node operation is shown below:

   Step (a) : Receive and parse all DNS options

   Step (b) : Arrange the addresses of RDNSSes 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 of DNS Server" field and the
   node's IPv6 address MAY be used to decide the distance between the
   node and RDNSS, how far away the node is from the RDNSS.)

   Step (c) : 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 node performs the name resolution, it
   refers to the address of RDNSS in order from the first RDNSS in the
   configuration for name resolution.

6.2 Detection of RDNSS Failure

   Router advertising DNS option message checks periodically if the
   RDNSSes registered with the router are alive.  The dynamic detection
   of RDNSS failure in a router can be done by simply pinging the RDNSS
   periodically (e.g., every ten seconds).  If no response is received,
   the router MAY try to aggressively ping the RDNSS for a short period
   of time (e.g., once every 5 seconds for 15 seconds).  Whenever the
   router detects a failure of any RDNSS, it advertises the failure with
   a new RA message including a DNS option of which "Pref" field has
   zero for the RDNSS.  When an IPv6 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.  Also, If the node has its domain name associated with
   the DNS zone suffix managed by the failed RDNSS, it MAY generate a


Jeong, Kim, Park, Kim    Expires - October 2003              [Page 8]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   new domain name with DNS zone suffix managed by another live RDNSS
   and register the domain name information with the RDNSS.

7. Security Considerations

   Ordinary DNS servers accept DNS dynamic update messages only from
   trusted nodes.  In the current DNS, which lacks public-key
   infrastructure (PKI), the user of a host cannot be identified.  In
   order to support the autoconfiguration of an unidentifiable host's
   domain name, DNS dynamic update SHOULD allow the registration of not
   only the DNS resource record of "AAAA" type, but also that of "PTR"
   type for any host [14].  The former is for the regular domain name
   information and the latter for inverse domain name information.

   Basically, since there is no mechanism to prevent denial-of-service
   (DoS) attack in DNS, the number of issued dynamic update messages
   from IPv6 nodes cannot be controlled by DNS server [14][15].  In
   order to minimize the effects of malicious or misconfigured
   registration requests, it is necessary for DNS server to control them.
   In Mobile IPv6, a correspondent node may silently discard some or all
   binding update messages when it is flooded with the messages [16].
   Like this, DNS server MAY discard some or all DNS messages when being
   filled with the messages.

8. 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] P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates
       in the Domain Name System (DNS UPDATE) ", RFC2136, April 1997.

   [4] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
       IP version 6", RFC 2461.

   [5] S. Thomson and T. Narten, "IPv6 Stateless Address
       Autoconfiguration", RFC2462.

   [6] 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.

   [7] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option",
       draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003.



Jeong, Kim, Park, Kim    Expires - October 2003              [Page 9]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   [8] Jae-Hoon Jeong, Jung-Soo Park, Kyeong-Jin Lee and Hyoung-Jun Kim,
       "The Autoconfiguration of Recursive DNS Server and the
       Optimization of DNS Name Resolution in Hierarchical Mobile IPv6",
       draft-jeong-hmipv6-dns-optimization-00.txt, February 2003.

   [9] Levon Esibov and Dave Thaler, "Linklocal Multicast Name
       Resolution (LLMNR)", draft-ietf-dnsext-mdns-13, November 2002.

   [10] Akira Kato and Paul Vixie, "Operational Guidelines for "local"
       zones in the DNS", draft-kato-dnsop-local-zones-00.txt, February
       2003.

   [11] H. Kitamura, "Domain Name Auto-Registration for Plugged-in IPv6
       Nodes", draft-ietf-dnsext-ipv6-name-auto-reg-00.txt, December
       2002.

   [12] Soohong Daniel Park, "IPv6 Domain Name Auto-Registration
       (6DNAR)", draft-park-6dnar-01.txt, March 2003.

   [13] Jae-Hoon Jeong, Jung-Soo Park and Hyoung-Jun Kim, "Unique DNS
        Name Generation", draft-jeong-name-generation-01, February 2003.

   [14] B. Wellington, "Secure Domain Name System (DNS) Dynamic Update",
        RFC 3007, November 2000.

   [15] B. Wellington, "Domain Name System Security (DNSSEC) Signing
        Authority," RFC3008, November 2000.

   [16] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
        draft-ietf-mobileip-ipv6-21.txt, February 26, 2003.

9. 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

   Byung-Yeob Kim
   ETRI / PEC
   161 Gajong-Dong, Yusong-Gu
   Daejon 305-350
   Korea



Jeong, Kim, Park, Kim    Expires - October 2003              [Page 10]


Internet-Draft     IPv6 RA-based DNS Autoconfiguration      April 2003


   Phone: +82 42 860 6627
   EMail: skylane@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

   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, Kim, Park, Kim    Expires - October 2003              [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/