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

Versions: 00 01

Internet Engineering Task Force                                   R. Yan
Internet Draft                                     Alcatel Shanghai Bell
Expiration: December 2005                                        X. Duan
File: draft-yan-ipv6-ra-dns-01.txt                          China Mobile



               DNS update in IPv6 stateless configuration
                     <draft-yan-ipv6-ra-dns-01.txt>

                           June 25, 2005

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on December 25, 2005.

Copyright Notice

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

Abstract

   This document specifies a method to update domain name for IPv6 node
   whose address is configured using IPv6 stateless address
   configuration.  It is implemented by defining a new option in
   Router Advertisement (RA) / Router Solicitation (RS) messages.


Yan, et al.              Expires December, 2005                 [Page 1]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The Domain Name Option . . . . . . . . . . . . . . . . . . . .  3
     3.1   The Flags Field  . . . . . . . . . . . . . . . . . . . . .  4
     3.2   The Domain Name Field  . . . . . . . . . . . . . . . . . .  5
   4.  Binding rule . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Procedure of DNS update  . . . . . . . . . . . . . . . . . . .  6
   6.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1   Router requirements  . . . . . . . . . . . . . . . . . . .  7
     6.2   Host requirements  . . . . . . . . . . . . . . . . . . . .  7
   7.  DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . .  8
   8.  Interaction with DHCPv6 and MIPv6  . . . . . . . . . . . . . .  8
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   11.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     11.1  Normative References . . . . . . . . . . . . . . . . . . .  9
     11.2  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Copyright Statements . . . . . . . . . . . . . . . . . . . . . . . 10































Yan, et al.                Expires December, 2005               [Page 2]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005

1.  Introduction

   The Domain Name System [2], [3] provides a mechanism to associate
   addresses and other Internet infrastructure elements with
   hierarchically built domain names.  For an IPv6 host, the general
   resource records maintained in DNS server are AAAA and PTR.  The DNS
   update specification [6] describes a mechanism that enables DNS
   information to be updated over a network.

   IPv6 stateless address autoconfiguration [7] allows a host to
   generate an unique IPv6 address by combining the prefix, advertised
   by the router, and the local interface identifier without the help of
   DHCPv6 server or DHCPv6 client.

   To perform DNS update for the IPv6 host whose addresses are
   configured using IPv6 stateless address autoconfiguration, this
   document defined a new RS/RA option to transfer domain name
   information and negotiate who will perform DNS update between the
   host and the router.

2.  Terminology

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

   Familiarity with the DNS Update protocol [6], IPv6 Neighbour
   Discovery [8] , and Stateless Address Autoconfiguration [7] is
   assumed.

3.  The Domain Name option

   This section defines a new option in RS/RA message, called
   "Domain Name Option".  The option contains a Domain-name, which is
   used to transfer domain information between IPv6 host and router,
   and a Flags, which IPv6 host and router use to negotiate who does
   DNS updates.

   The Format of the Domain Name option is shown below:

     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     |     Flags     |    Reserved   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                      Domain-name                              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Yan, et al.               Expires December, 2005                [Page 3]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


      Type:          8-bit identifier of the type of option(TBD)

      Length:        The length of the option in units of 8 octets. The
                     minimum length of the option is 1

      Flags:         Flag bits used between host and router to
                     negotiate who performs DNS updates

      Domain-name:   The partial or fully qualified domain name

   The Domain Name option MUST only appear in options field in Router
   Advertisement and Router Solicitation message.

   When appear in RA message, it MUST be used together with Prefix
   options, to mean that it will be bound with the address(es)
   configured using those prefix(es).

   When RS message includes Domain Name option, its source address MUST
   be generated using the prefix advertised by the previous RA message.

3.1  The Flags Field

   The Format of the Flags field:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |H|R|     RSV   |
       +-+-+-+-+-+-+-+-+

   If the router wants to take responsibility for the DNS updates for
   the host, it will set the "R" bit and clear the "H" bit when sending
   Domain Name option.

   If the router wants host to take responsibility for the DNS updates
   on its own, it will set the "H" bit and clear "R" bit when sending
   Domain Name option.

   Host MUST only send the Domain Name option in an RS message.

   When a host sends the Domain Name option in RS message, it clears the
   "H" bit to indicate that it will not perform any DNS updates, and
   that it expects the router to perform DNS updates on its behalf.

   If "R" bit is cleared, and "H" bit is set in RA message, but host
   have no ability to update DNS on its own, it can still request the
   router to perform DNS updates by setting both "R" and "H" bit in
   RS message.




Yan, et al.               Expires December, 2005                [Page 4]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


   The remaining bits in the Flags field are reserved for future
   assignment.  IPv6 hosts and routers which send the Host FQDN
   option MUST set the RSV bits to 0, and they MUST ignore these bits.

3.2  The Domain Name Field

   The Domain Name field of the option carries all or part of the FQDN
   of an IPv6 host.  The data in the Domain Name field MUST appear in
   uncompressed DNS encoding as specified in [3].

   Domain Name field MUST be padded with 0 to 4-bytes alignment.

   The router MUST send the zone suffix or NULL in Domain Name Field in
   Domain Name options. The host MUST send either FQDN or host name in
   Domain Name Field in Domain Name options.

4.  Binding rule

   As we know, the mapping between IPv6 address and FQDN is multiple-to-
   multiple.  A host can register one FQDN with multiple IPv6 addresses,
   and also can register one IPv6 address with multiple FQDN.  This
   document specifies a mechanism allowing the router to decide which
   prefix(es) is bound to which domain name.  It is implemented by
   defining the sequence of the Domain Name option and Prefix option.

   The Domain Name option MUST be used in combine with Prefix option as
   defined below:

       +----------------------------------+
       |           RA message             |
       +----------------------------------+_
       |         Prefix options           | \
       +----------------------------------+  > matching 1
       |      Domain Name options         |_/
       +----------------------------------+_
       |         Prefix options           | \
       +----------------------------------+  > matching 2
       |      Domain Name options         |_/
       +----------------------------------+
       |                                  |
       ~              ...                 ~
       |                                  |
       +----------------------------------+_
       |        Prefix options            | \
       |        with no binding           |  > Unbound
       |                                  |_/  Prefix
       +----------------------------------+




Yan, et al.               Expires December, 2005                [Page 5]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


   Domain Name options MUST be placed after one or more Prefix options,
   to mean that they are in a "matching". Hosts can choose to update
   the binding, whose IPv6 address and domain name are generated from
   the prefix and domain information in this matching. A typical case is
   that multiple Prefix options are bound with one Domain Name option.

   Prefix option can be conveyed in RA message without binding with any
   Domain Name option. These "unbound" Prefix MUST be placed after the
   last Domain Name option.

5.  Procedure of DNS update

   The processing of Domain Name option is handled like any other ND
   options and would happen when an RA is received.  The following
   figure shows an illustration of the procedure.


      IPv6 Host                  Router                 DNS server
         |                         |                         |
      (1)|(-----RS (no DNO)------>)|                         |
      (2)|<------RA (DNO)----------|                         |
      (3)|--------RS (DNO)-------->|                         |
         |(-------------------DNS update ------------------>)|
      (4)|                         |------DNS update ------->|

         (DNO is abbreviation of Domain Name Option in the figure)

   The procedure consists of the following steps:

   Step (1) : IPv6 Host sends RS (Router Solicitation) message without
              the Domain Name option to get a RA message.  It is
              optional.

   Step (2) : For the RS message sent by IPv6 Host, router sends a RA
              message, which contains Prefix Information option(s) for
              stateless address autoconfiguration and Domain Name
              option(s) for DNS update.

   Step (3) : IPv6 Host processes the RA message, if the result of the
              negotiation is router performs DNS update, IPv6 host will
              sends RS message to the router.  The RS message contains
              a Domain Name option, with the source address set to the
              address generated using that prefix.  Then, the process
              moves to Step (4).  If the result of the negotiation is
              host performs DNS update, it will update its domain name
              directly with DNS server and finish the whole process.

   Step (4) : The router sends DNS update message to the DNS server.



Yan, et al.               Expires December, 2005                [Page 6]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


6.  Requirements

   The following describes the requirements of host and router that
   implements the Domain Name option.

6.1 Router requirements

   Router MUST only include Domain Name options for the bindings in
   RA messages.

   Router MAY include one or more Domain Name options in a single RA
   message.

   Router MUST include Domain Name options as the rules defined in
   Section 5.

   Router sends the Domain Name options with the "R" flags bit set and
   "H" flags bit clear, or, "R" flags bit clear and "H" flags bit set.

   Router MAY be configured to update RR for the host, or simply request
   host to update on its own if there are no security requirement in
   local network.  In both cases, router MUST be able to update RRs
   because some hosts may not have the ability to update DNS by itself.

   There is no requirement that router stores the result of the DNS
   update when it update RR for the host. Host is required to check the
   DNS result by sending DNS query to the DNS server.

6.2  Host requirements

   Host MUST only include Domain Name option in the Options field of
   Router Solicitation message.

   Host MUST send RS message with Domain Name option after receiving
   prefix from a previous RA message.

   Host MUST only send RS message including Domain Name option to the
   router if it wants router to take responsibility for the DNS updates.
   The destination address of this RS message is the unicast address of
   the router, and the source address MUST be set to the unicast address
   generated using prefix in a "matching".

   Host sends the Domain Name option with the "H" flags bit set, the
   "R" flags bit clear, and with the desired partial domain name.

   There is no requirement that the host send identical Domain Name
   option data several times.  In particular, if a host has sent Domain
   Name options to the router, and the configuration of the host changes
   so that its notion of its domain name changes, it MAY update the


Yan, et al.               Expires December, 2005                [Page 7]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


   records in the DNS server by itself, or send the new name data in a
   Domain Name option to the router, requesting the router to update the
   records in DNS server.

   Host MAY not send RS message with Domain Name option for DNS update
   if it do not need a domain name, e.g. a mobile user may not need a
   new domain name in foreign network.  How to prevent host to update
   which DNS is the implementation issue.

7.  DNS Update Conflicts

   This document does not address how an IPv6 host or router prevents
   name conflicts.

   Implementers of this work will need to consider how name conflicts
   will be prevented.  One possible method may be that the router
   maintain a mapping table for all hosts in local network, and
   different router are configured with different domain name suffix.

8.  Interaction with DHCPv6 and MIPv6

   There may exist cases in which a host can get different global IPv6
   address using both RA and DHCP, and the host may want to use a single
   domain name for all address.  In such case, the administrator SHOULD
   have site local policy to make sure that the zone suffix in the
   router and in the DHCPv6 server are the same.  This can be done by
   using the Zone Suffix option in DHCPv6 [12].  Host can register each
   address using FQDN option [13] via DHCPv6 and using Domain Name
   option via RA/RS separately.

   If a mobile host in foreign network want to access other PC, it can
   simply use the care-of-address, if other PC want to communicate the
   a mobile host in foreign network, it can still use the old domain
   name of that host and get its home address, them the MIPv6 mechanism
   will be used.  So, for a mobile host in foreign network, it is
   unnecessary to re-update DNS using new Domain Name option broadcasted
   by local router.  If a mobile host detects it has been located in a
   foreign network, it can just ignore the Domain Name option included
   in RA message sent by the foreign router.

   However, it will be interesting if the mobile host update a new DNS
   using its original domain name in foreign network, i.e. it updates
   AAAA record in its home DNS server, and updates PTR record in local
   foreign DNS server.  Such kind of method can replace some functions
   of MIPv6.  Hosts which want to connect to this mobile host will
   directly get its foreign address by DNS resolution.  This issue will
   be studied in a separate document.




Yan, et al.               Expires December, 2005                [Page 8]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


9.  Security Considerations

   Unauthenticated updates to the DNS can lead to tremendous confusion,
   through malicious attack or through inadvertent misconfiguration.
   Administrators should be wary of permitting unsecured DNS updates to
   zones which are exposed to the global Internet.  Both host and router
   SHOULD use some form of update request origin authentication
   procedure (e.g., Secure DNS Dynamic Update [9]) when performing DNS
   updates.

   Malicious host may be able to mount a denial of service attack to
   router by repeated RS messages with "Domain Name" option.  Some kind
   of security mechanism (e.g., Secure Neighbour Discovery [11]) may be
   used to setup a trust model between router and hosts.

   Whether the router may be responsible for DNS update or whether it
   left this responsibility to host itself is a site-local matter.  The
   choice between the two alternatives may be based on the security
   model that is used with the DNS update protocol.

10. Acknowledgements

   I would like to thank Chris Liljenstolpe, Stefaan De Cnodder,
   Yinglan Jiang, and Emmanuel Desmet for their valuable comments and
   kindly help.

11.  References

11.1  Normative References

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

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

   [3]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

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

   [5]  Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
        Extensions to Support IP Version 6", RFC 3596, October 2003.

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




Yan, et al.               Expires December, 2005                [Page 9]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


   [7]  S. Thomson, T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

   [8]  T. Narten, E. Nordmark, W. Simpson , "Neighbor Discovery for IP
        Version 6", RFC2461, December 1998.

11.2  Informative References

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

   [10] Eastlake, D., "Domain Name System Security Extensions", RFC
        2535, March 1999.


   [11] J. Arkko, J. Kempf, B. Sommerfeld, B. Zill, P. Nikander, "SEcure
        Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06.txt, July
        17, 2004.

   [12] R. Yan, L. Gui, Y. Jiang, "Zone suffix option for DHCPv6",
        draft-yan-dhc-dhcpv6-opt-dnszone-02.txt, December 24, 2004.

   [13] B. Volz, "The DHCPv6 Client FQDN Option", draft-ietf-dhc-
        dhcpv6-fqdn-00.txt, September, 2004.

Copyright notice

   Copyright (C) The Internet Society (2005).  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.













Yan, et al.               Expires December, 2005               [Page 10]


Internet-Draft   DNS update in IPv6 stateless configuration    June 2005


Author Information:

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

   Phone: +86 (21) 5854-1240, ext:7169
   Email: renxiang.yan@alcatel-sbell.com.cn



   Xiaodong Duan
   Research & Development Center
   China Mobile Communications Corporation
   53A, Xibianmennei Ave., Xuanwu District,
   Beijing, 100053 P.R. China
   Phone: +86 (10) 6600-6688, ext. 3062

   Email: duanxiaodong@chinamobile.com






























Yan, et al.               Expires December, 2005               [Page 11]


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