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

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

Internet Engineering Task Force                             Renxiang Yan
Internet Draft                                             Yinglan Jiang
Expiration: April 2005                                       Luoning Gui
File: draft-yan-dhc-dhcpv6-opt-dnszone-01.txt      Alcatel Shanghai Bell




                    DNS zone suffix option for DHCPv6
                <Draft-yan-dhc-dhcpv6-opt-dnszone-01.txt>

                           October 12, 2004


Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.

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

Copyright Notice

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

Abstract

   The DNS Zone Suffix option provides a mechanism for automated
   assignment of DNS zone suffix using DHCPv6.  This mechanism is



Yan, et. al.                                                    [Page 1]


Internet-Draft        DNS zone suffix option for DHCPv6     October 2004


   intended to assign a DNS zone suffix from DHCPv6 server to a client.
   The client then uses this suffix to configure its domain name.


1.0 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 several methods to register domain name for
   an IPv6 terminal: (1) manually add the DNS resource record into DNS
   server database; (2) use FQDN option and register domain name
   automatically either by DHCP client or by DHCP server [6];
   (3) configure a DNS zone suffix information in the router, and use
   the RA-based DNS auto-registration mechanism [5].

   Method (1) is not effective for large number of IPv6 devices. Method
   (3) requires that the every terminal get the address and FQDN using
   DHCP mechanism. Thus every terminal needs a DHCP client. Method (2)
   will only be suitable in the case where a router is presented in the
   network, and the DNS zone suffix has been configured correctly. 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. It will provide an enhancement for method (2) to
   automatically update domain name for IPv6 terminals, especially in
   access network environment.

1.1 Conventions

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


2.0  DNS Zone Suffix Option Definition

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

   The format of the DNS zone suffix option is:



Yan, et. al.                                                    [Page 2]


Internet-Draft        DNS zone suffix option for DHCPv6     October 2004


     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.

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


3.0  Example and applicability

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




Yan, et. al.                                                    [Page 3]


Internet-Draft        DNS zone suffix option for DHCPv6     October 2004


   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,
   through an embedded stateless 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
   verification, 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.

4.0  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 attack
   by repeated DHCP requests for zone suffix, thus exhausts the DHCP
   server's resource.

   Currently, it is difficult for DHCP servers to develop much
   confidence in the identities of its clients, given the absence of
   entity authentication from the DHCP protocol itself. To guard against



Yan, et. al.                                                    [Page 4]


Internet-Draft        DNS zone suffix option for DHCPv6     October 2004


   attack, DHCP Authentication as described in section 21 of RFC 3315
   can be used.

   To restrict unsecured DNS updates to zones which are exposed to the
   global Internet, IPv6 terminals SHOULD use some form of update
   request origin authentication procedure (e.g., Secure DNS Dynamic
   Update [7]) when performing DNS updates.

   In access network, an extra method to ensure the secure DNS updates
   is to add an IP spoofing filter in access node.


Copyright notice

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


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 DHCPv6 Client FQDN Option", draft-
        volz-dhc-dhcpv6-fqdn-00.txt, July, 2004.



Yan, et. al.                                                    [Page 5]


Internet-Draft        DNS zone suffix option for DHCPv6     October 2004


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

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


Author Information:

   Renxiang Yan
   Yinglan Jiang
   Luoning Gui
   Research & Innovation Center
   Alcatel Shanghai Bell Co., Ltd.
   388#, NingQiao Road, Pudong Jinqiao
   Shanghai 201206 P.R. China

   Phone: +86 (21) 5854-1240

   Email: renxiang.yan@alcatel-sbell.com.cn
          Yinglan.jiang@alcatel-sbell.com.cn
          Luoning.gui@alcatel-sbell.com.cn





























Yan, et. al.                                                    [Page 6]


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