draft-ietf-dnsext-ipv6-name-auto-reg-00.txt

bind-3.2.


INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   The Detector watches (a) and (b), and detects the appearance of new
   plugged-in IPv6 nodes. (c) is a procedure for sending the detected
   information, to which the Detector ID is attached. The scope of the
   detected address is not checked at the Detector.

   After the Registrar receives the detected information by the
   procedure (c), the scope of the detected address and the decision
   algorithm (which depends on the Detector ID) are checked on the
   Registrar.

   In typical cases, the decision algorithm shows that link-local
   addresses are not candidates for registration. In such cases, the
   detected information for the link-local address is discarded at this
   point.

   (d)(e)(f) and (g) are DAD procedures for the global address of the
   Plugged-in Node. (d) is an optional procedure. (g) is a procedure to
   verify that there is no NA (reply to NS) and that the global address
   is not duplicated.

   The Detector watches (f) and (g), and detects the appearance of new
   plugged-in IPv6 nodes. (h) is a procedure for sending the detected
   information, to which the Detector ID is attached.

   After the Registrar receives the detected information by the
   procedure (h), the scope of the detected address and decision
   algorithm (which depends on Detector ID) are checked on the
   Registrar.

   In typical cases, the decision algorithm shows that global addresses
   are candidates for registration. In such cases, check procedures to
   avoid duplicated registrations are started at this point.

   (i) and (j) are check procedures to verify that the detected address
   is must be registered to the DNS. The Registrar checks for the
   existence of FQDN information for the detected address by executing
   "inverse DNS name resolving" procedures with the detected address
   argument.

   If the existence of FQDN information for the detected address is
   verified, such detected address information for registration is
   canceled and discarded at this point.

   If the existence is not verified, the Registrar starts preparing
   "default domain name" information for the candidate IPv6 address. DNS
   zone suffix information that depends on the Detector ID is taken from
   the Registrar's manually configured database table, and the naming
   rule algorithm that depends on the Detector ID is also taken from it.



H. Kitamura                                                    [Page 15]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   By following the defined naming rule algorithm, the plugged-in node's
   prefix name is selected.

   (k) and (l) are optional procedures for preparing "default domain
   name." If the naming rule that is applied for the detected address
   stipulates inquiring the preference or property of the node, (k) and
   (l) are executed and such information is obtained by the Registrar.
   The obtained information is used as a hint to select the prefix name
   of the plugged-in node.

   A candidate "default domain name" for the detected address is
   prepared here.

   (m) and (n) are check procedures to verify that the candidate
   "default domain name" is not used by anyone. The Registrar checks for
   the existence of the candidate "default domain name" by executing
   "regular DNS name resolving" procedures with the candidate "default
   domain name."

   If the existence is not verified, it becomes fully qualified "default
   domain name." If the existence is verified, the Registrar restarts
   and repeats preparing a candidate "default domain name" for the
   detected address.


   After fully qualified "default domain name" information to register
   is prepared, (o)(p)(q) and (r) are executed to register both regular
   and inverse domain name information to the DNS servers by the Dynamic
   Update messages.

   (Under manual configuration situations, (o)(p)(q) and (r) procedures
   are replaced by the administrators' manual registration (not by the
   Dynamic Updates).)


5. Treatment of "Temporary Addresses" in the Mechanism

   "Temporary address" is defined in [RFC3041]. Temporary addresses are
   detected in this mechanism, because DAD packets are issued when
   temporary address are generated.

   There are two views whether domain names for temporary addresses
   should be registered to the DNS or not.

   One view is that domain names for temporary addresses should NOT be
   registered to the DNS, because temporary addresses are temporary and
   they are introduced to lessen privacy concerns.




H. Kitamura                                                    [Page 16]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   The other view is domain names for temporary addresses should be
   registered to the DNS. [RFC3041] discusses on this issue at section 4
   of [RFC3041]. In order to meet conventional inverse-DNS-based
   "authentication," nodes could register temporary addresses in the DNS
   using random names. The Domain Name Auto-Registration mechanism can
   provide a solution for this issue.

   Since there are two views for domain names registration of temporary
   addresses, which view should be chosen is depends on site policies.



5.1 How to Distinguish "Temporary Addresses" from Public Addresses

   In order to apply above discussed policies, it is necessary to
   distinguish "temporary addresses" from public addresses.

   Only with IP address information, it is difficult to tell that a
   detected address is a temporary address or a public addresses. So,
   link-layer address information is utilized to achieve this operation
   (see section 3.2).

   By utilizing link-layer address information, we can easily tell that
   a detected address is a EUI64-based address or not. (This operation
   is called a "EUI64 check" operation.)

   If a detected address is a EUI64-based, it is not a temporary
   address. It is a normal target address for the Domain Name Auto-
   Registration mechanism.

   If not, it must be a either temporary address or manually configured
   address. We can assume that a domain name for a manually configured
   address must have been registered in the DNS manually.

   In the mechanism, an IP address whose domain name has been already
   registered does not become a candidate. It is verified by "inverse
   DNS name resolving" check procedures (see (i) and (j) procedures in
   Figure 3).

   By applying a "EUI64 check" operation after "inverse DNS name
   resolving" check procedures, we can assume that non EUI64-based
   address must be a temporary address. Since temporary addresses are
   distinguished from public addresses, we can apply above discussed
   policies to temporary addresses.







H. Kitamura                                                    [Page 17]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


6. Security Considerations

   After the Address Autoconfiguration [ADDR-AUTO] has been executed,
   the Domain Name Auto-Registration works as a succeeding of the plug
   and play mechanism. The plugged-in IPv6 nodes' appearances detection
   method is depend on the Address Autoconfiguration.

   Thus, the items that are described in the Security Considerations
   section of the Address Autoconfiguration [ADDR-AUTO] are also
   applicable to this document.

   In addition, the following security issues are considered.

   Since the Detector must send detected information to the Registrar
   securely, some sort of secure communication method (e.g., [TSIG]-like
   authentication, IPsec (AH, ESP), [TLS]) must be used.

   The Registrars must be trusted nodes of the DNS servers and Dynamic
   Update messages must be sent securely from the Registrar to the DNS
   servers by using some sort of secure communication method. The [TSIG]
   technique would be suitable for authenticating the messages.

   In order to minimize the effects of malicious or misconfigured
   registration requests, the Registrar restricts the number of Dynamic
   Update messages that are sent from the Registrar per unit of time.


























H. Kitamura                                                    [Page 18]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


Appendix A. HTTP-based simple protocol between Detector and Registrar

   a. Design of HTTP parameters

    - Request Parameters
        method             = <registration protocol>
        detectorID         = <detector identifier(address)>
        IP-address         = <detected IP address>
        link-layer-address = <detected link-layer address>
        source             = <source type>
        time-detected      = <detected time>

    - Response Parameters
        result             = <result>
        address            = <registered address>
        hostname           = <registered hostname>
        namehint           = <name hint>
        error              = <error>
        time-accepted      = <accepted time>

   b. Message Examples

    - Request message
       POST /cgi-bin/registrar.cgi HTTP/1.1
        Host: registrar-host
        Content-Length: mmm
        User-Agent: DAD-detector
        Content-type: application/x-pnp-dnar

        method=register/2.0
        detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1
        IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0
        link-layer-address=00:00:4c:zz:zz:zz
        source=DAD-detector
        time-detected=1013078377

    - Response message
        HTTP/1.1 200 OK
        Content-Type : text/plain
        Content-Length : nnn
        Connection : close

        result=REGISTER
        address=3ffe:yyyy::202:b3ff:fe2d:68c0
        hostname=host.example.com
        namehint=none
        time-accepted=1013078378




H. Kitamura                                                    [Page 19]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


References

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

   [ND]   T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)," RFC 2461, December 1998.

   [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address
        Autoconfiguration," RFC2462, December 1998.

   [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic
        Updates in the Domain Name System," RFC 2136, April 1997.

   [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B.
        Wellington, "Secret Key Transaction Signatures for DNS
        (TSIG)," RFC 2845, May 2000.

   [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
        RFC2246, January 1999

   [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures
        ( SIG(0)s)," RFC2931, September 2000.

   [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic
        Update," RFC3007, November 2000.

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

   [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol
        Operations for Version 2 of the Simple Network Management
        Protocol (SNMPv2)," RFC1905,  January 1996.

   [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6," RFC3041, January 2001

   [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1"
        RFC2616, June 1999

   [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1"
        RFC2817, May 2000









H. Kitamura                                                    [Page 20]

INTERNET-DRAFT        Domain Name Auto-Registration        December 2002


   [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local
        unicast addresses for DNS resolver,"
        <draft-ietf-ipv6-dns-discovery-07.txt>, October 2002

   [DEF-ADDR] R. Draves, "Default Address Selection for IPv6,"
        <draft-ietf-ipngwg-default-addr-select-09.txt>, August 2002


   [NIQ] M. Crawford, "IPv6 Node Information Queries,"
        <draft-ietf-ipngwg-icmp-name-lookups-09.txt>, May 2002






Author's Address:

   Hiroshi Kitamura
   NEC Corporation
   Development Laboratories
   (Igarashi Building 4F) 11-5, Shibaura 2-Chome,
   Minato-Ku, Tokyo 108-8557, JAPAN

   Phone: [phone]
   Fax:   [phone]
   Email: [e-mail]
























H. Kitamura                                                    [Page 21]