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

Versions: 00 01 02 03 draft-ietf-dhc-dhcpv6-opt-dnsdomain

Network Working Group                                       Renxiang Yan
Internet-Draft                                     Alcatel Shanghai Bell
Expires: November 27, 2004                                  May 27, 2004

                     DNS zone suffix option for DHCPv6

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on October 25, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   The DNS Zone Suffix option provides a mechanism for automated
   assignment of DNS zone suffix using DHCPv6.  This mechanism is
   intended to assign a DNS zone suffix from DHCPv6 server to a client.
   The client then uses this suffix to configure its domain name.

Conventions used in this document

   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [3].

Yan                    Expires October 25, 2004                 [Page 1]

Internet-Draft        DNS zone suffix option for DHCPv6       April 2003

1. Introduction

   The introduction of 128-bit address of IPv6 makes it very difficult
   for the user to identify the device by means of its IP address. The
   use of DNS (Domain Name Service) becomes a necessity. With the help
   of DNS, a user only needs to remember the relatively simple domain
   name instead of long IPv6 address.

   Currently, there exist two methods to register domain name for an
   IPv6 host: (1) manually add a DNS RR (resource record) into the DNS
   server database; (2) manually configure a DNS zone suffix infomation
   in the router, and use the RA-based DNS auto-registration mechanism
   as described in [5].

   In method (1), when the number of IPv6 users is large, it will be
   troublesome for network administrator to manage. Moreover, the
   situation will be deteriorated when users need to change the domain
   name of their devices. Method (2) will only be suitable for the
   case where a router is presented in the network. Moreover, when large
   number of routers need to be configured, e.g. in IPv6 access network
   where CPE may work as an IPv6 router which links some IPv6 terminals
   to form a home network, it will be better to define an automatic
   mechanism to configure the DNS zone suffix.

   This document describes a new option for DHCP, named DNS zone suffix
   option. Using this option, a DHCPv6 client can get a DNS zone suffix
   from DHCPv6 server.

2. DHCPv6 specification dependency

   This document describes a new DHCPv6 option for DNS zone suffix
   assignment.  It should be read in conjunction with the DHCPv6
   specification for a complete specification of the DNS zone suffix
   option and mechanism.  Definitions for terms and acronyms not
   specifically defined in this document are defined in the DHCPv6
   specification [2].

3. Terminology

   This document uses the terminology defined in RFC2460 [1] and the
   DHCP specification [2].

4.  DNS Zone Suffix Option

   The DNS zone suffix option is used to carry a DNS zone suffix to the
   DHCPv6 client, which will use it to construct and register a domain

Yan                    Expires October 25, 2004                 [Page 2]

Internet-Draft        DNS zone suffix option for DHCPv6       April 2003

   The format of the DNS zone suffix option is:

     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
    |     OPTION_DNS_Zone_suffix    |         option-length         |
    |                                                               |
    ~                         DNS zone suffix                       ~
    |                                                               |

   option-code:     OPTION_DNS_Zone_suffix (TBD)

   option-length:   Length of the "DNS zone suffix" field in octets.

   DNS zone suffix: A string of DNS zone suffix. It 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.

5.  Appearance of the option

   The DNS zone suffix option MUST NOT appear in any other than the
   following messages: Solicit, Advertise, Request, Renew, Rebind,
   Information-Request, and Reply.

6. Example and applicability

      | Node +--+
      +------+  |
      +------+  |
      | Node +--+                         +---------------
      +------+  |                         |
                :                   +-----+
                :  +---------+      |     |
                +--+ Router  +------| ISP | Internet
                :  +---------+      |     |
                :                   +-----+
      +------+  |                         |
      | Node +--+                         +---------------
   \____________  ___________/  \____________  ___________/
                \/                           \/
      Subscriber's network             ISP network

Yan                    Expires October 25, 2004                 [Page 3]

Internet-Draft        DNS zone suffix option for DHCPv6       April 2003

   The above figure shows a typical usage of the option. In this model,
   ISP has the ISP level domain name suffix (e.g. shtele.com).  The
   procedure may follow as:

   1. The router in the subscriber network initiate DHCP request with
   the DNS zone suffix option to get ISP's suffix (i.e. shetele.com).

   2. The router passes this suffix to the IPv6 nodes in local subnet,
   throught an embedded DHCPv6 server or RA-based mechanism described in
   [5].  Since nodes on different subscriber networks may produce the
   same domain name, to avoid frequent uniqueness verficication, the
   router is suggested to extend DNS zone suffix.  For example, the DNS
   zone suffix of two subscriber networks under "shtele.com" maybe
   "john.shtele.com" and "smith.shtele.com".

   3. An IPv6 node creates FQDN for its global address by adding a
   hostname to the DNS zone suffix, and registers the IP to FQDN mapping
   and FQDN to IP mapping in the domain name server.  This procedure can
   be realized either by itself using DNS update or through DHCPv6
   server [6].  For example, an IPv6 set-top-boxes will hold a domain
   name "stb.john.shtele.com" in the DNS server.

   The DNS zone suffix option can be used in conjunction with other DHCP
   options carrying other configuration information to the router.  For
   example, the router may obtain the addresses of the DNS servers and
   IPv6 prefix from the ISP's DHCP server, and then passes that
   configuration information on to the subscriber nodes through a DHCP
   server in the router.

   The use of DNS zone suffix option are not limited in access.  It can
   be commonly used in case that IPv6 node needs to configure its domain
   name in DNS server.

7.  Security Considerations

   Security considerations in DHCP are described in section 23,
   "Security Considerations" of RFC 3315.

   A rogue DHCP server can issue bogus zone suffix to a client. This may
   cause wrong domain name registration.

   A malicious client may be able to mount a denial of service attach by
   repeated DHCP requests for zone suffix, thus exhausts the DHCP
   server's resource.

   To guard against attack, both DCHP clients and servers SHOULD use
   DHCP authentication as described in section 21, "Authentication of
   DHCP messages" of RFC 3315.

Yan                    Expires October 25, 2004                 [Page 4]

Internet-Draft        DNS zone suffix option for DHCPv6       April 2003

8.  References

8.1  Normative References

   [1]  Deering, S. and R. Hiden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC2460, December 1998.

   [2]  Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
        Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
        (DHCPv6)", RFC 3315, May 2003.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  P. Vixie, S. Thomson, Y. Rekhter and J. Bound, "Dynamic Updates
        in the Domain Name System (DNS UPDATE)", RFC2136, April 1997.

   [5]  Jae-Hoon, J., Byung-Yeob, K., Jung-Soo, P. and Hyong-Jun K.,
        "IPv6 Router Advertisement based DNS Autocofiguration", draft-
        jeong-ipv6-ra-dns-autoconf-00.txt, 17 April, 2003.

   [6]  M.Stapp, Y. Rekhter, "The DHCP Client FQDN Option", draft-dhc-
        fqdn-option-06.txt, October, 2003.

8.2  Informative References

   [7]  Mockapetris, P., "Domain names - concepts and facilities", STD
        13, RFC 1034, November 1987.

9. Authors' Addresses

   Renxiang Yan
   Alcatel Shanghai Bell Co., Ltd.
   388#, NingQiao Road, Pudong Jinqiao
   Shanghai 201206 P.R. China
   Phone: +86 (21) 5854-1240, ext.: 7169
   Emain: renxiang.yan@alcatel-sbell.com.cn

Yan                    Expires October 25, 2004                 [Page 5]

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