1 files changed, 356 insertions, 0 deletions
diff --git a/doc/draft-ietf-dhc-dhcp-dns-02.txt b/doc/draft-ietf-dhc-dhcp-dns-02.txt
new file mode 100644
index 00000000..b85ed12e
--- /dev/null
+++ b/doc/draft-ietf-dhc-dhcp-dns-02.txt
@@ -0,0 +1,356 @@
+
+
+Network Working Group                                      Yakov Rekhter
+Internet Draft                                             Cisco Systems
+Expiration Date: April 1997                                 October 1996
+
+
+                    Interaction between DHCP and DNS
+                     draft-ietf-dhc-dhcp-dns-02.txt
+
+
+1. Status of this Memo
+
+   This document is an Internet-Draft.  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.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
+   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
+   ftp.isi.edu (US West Coast).
+
+
+2. Abstract
+
+   DHCP provides a powerful mechanism for IP host autoconfiguration.
+   However, the autoconfiguration provided by DHCP does not include
+   updating DNS, and specifically updating the name to address and
+   address to name mappings maintained by DNS.
+
+   This document specifies how DHCP clients and servers should use the
+   Dynamic DNS Updates mechanism to update the DNS name to address and
+   address to name mapping, so that the mappings for DHCP clients would
+   be consistent with the IP addresses that the clients acquire via
+   DHCP.
+
+
+
+
+
+
+
+
+
+
+
+Yakov Rekhter                                                   [Page 1]
+
+
+
+
+
+Internet Draft       draft-ietf-dhc-dhcp-dns-02.txt         October 1996
+
+
+3. Interaction between DHCP and DNS
+
+   DNS [RFC1034, RFC1035] maintains (among other things) the information
+   about mapping between hosts' Fully Qualified Domain Names (FQDNs)
+   [RFC1594] and IP addresses assigned to the hosts.  The information is
+   maintained in two types of Resource Records (RRs): A and PTR. The A
+   RR contains mapping from a FQDN to an IP address; the PTR RR contains
+   mapping from an IP address to a FQDN.
+
+   DHCP [RFC1541] provides a mechanism by which a host (a DHCP client)
+   could acquire certain configuration information, and specifically its
+   IP address(es). However, DHCP does not provide any mechanisms to
+   update the DNS RRs that contain the information about mapping between
+   the host's FQDN and its IP address(es) (A and PTR RRs). Thus the
+   information maintained by DNS for a DHCP client may be incorrect -  a
+   host (the client) could acquire its address by using DHCP, but the A
+   RR for the host's FQDN wouldn't reflect the address that the host
+   acquired, and the PTR RR for the acquired address wouldn't reflect
+   the host's FQDN.
+
+   Dynamic DNS Updates [DynDNS] is a mechanism that enables DNS
+   information to be updated DNS over a network.
+
+   The Dynamic DNS Update protocol can be used to maintain consistency
+   between the information stored in the A and PTR RRs and the actual
+   address assignment done via DHCP.  When a host with a particular FQDN
+   acquires its IP address via DHCP, the A RR associated with the host's
+   FQDN would be updated (by using the Dynamic DNS Updates protocol) to
+   reflect the new address.  Likewise, when an IP address gets assigned
+   to a host with a particular FQDN, the PTR RR associated with this
+   address would be updated (using the Dynamic DNS Updates protocol) to
+   reflect the new FQDN.
+
+
+4. Models of operations
+
+   When a DHCP client acquires a new address, both the A RR (for the
+   client's FQDN) and the PTR RR (for the acquired address) have to be
+   updated. Therefore, we have two separate Dynamic DNS Update
+   transactions. Acquiring an address via DHCP involves two entities: a
+   DHCP client and a DHCP server. In principle each of these entities
+   could perform none, one, or both of the transactions. However, upon
+   some introspection one could realize that not all permutations make
+   sense.  This document covers the possible design permutations:
+
+         (1) DHCP client updates the A RR, DHCP server updates the PTR
+               RR
+
+
+
+
+Yakov Rekhter                                                   [Page 2]
+
+
+
+
+
+Internet Draft       draft-ietf-dhc-dhcp-dns-02.txt         October 1996
+
+
+         (2) DHCP server updates both the A and the PTR RRs
+
+   One could observe that the only difference between these two cases is
+   whether the FQDN to IP address mapping is updated by a DHCP client or
+   by a DHCP server. The IP address to FQDN mapping is updated by a DHCP
+   server in both cases.
+
+
+4.1. Client FQDN Option
+
+   To update the IP address to FQDN mapping a DHCP server needs to know
+   FQDN of the client to which the server leases the address. To allow
+   the client to convey its FQDN to the server this document defines a
+   new option, called "Client FQDN".
+
+   The code for this option is 81. Its minimum length is 4.
+
+
+
+         Code   Len    Flags  RCODE1 RCODE2   Domain Name
+        +------+------+------+------+------+------+--
+        | TBD  |   n  |  0/1 |      |      |       ...
+        +------+------+------+------+------+------+--
+
+
+
+   The Flags field allows a DHCP client to indicate to a DHCP server
+   whether the client wants the server to be responsible for updating
+   the FQDN to IP address mapping (if Flags is set to 1), or whether the
+   client wants to take this responsibility (if Flags is set to 0).
+
+   The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to
+   a DHCP client the Response Code from Dynamic DNS Updates.
+
+   The Domain Name part of the option carries FQDN of a client.
+
+
+
+4.2. DHCP Client behavior
+
+   If a client wants to be responsible for updating the FQDN to IP
+   address mapping for the FQDN and address(es) used by the client, then
+   the client shall include the Client FQDN option in the DHCPREQUEST
+   message originated by the client. The Flags field in the option shall
+   be set to 0. Once the client's DHCP configuration is completed (the
+   client receives a DHCPACK message, and successfully completed a final
+   check on the parameters passed in the message), the client shall
+   originate an update for the A RR (associated with the client's FQDN).
+
+
+
+Yakov Rekhter                                                   [Page 3]
+
+
+
+
+
+Internet Draft       draft-ietf-dhc-dhcp-dns-02.txt         October 1996
+
+
+   The update shall be originated following the procedures described in
+   [DynDNS].
+
+
+   If a client does not want to be responsible for updating the FQDN to
+   IP address mapping for the FQDN and address(es) used by the client,
+   then the client shall include the Client FQDN option in the
+   DHCPREQUEST message originated by the client. The Flags field in the
+   option shall be set to 1.
+
+
+   A client should set the RCODE1 and RCODE2 fields in the Client FQDN
+   option to 0 when sending the option.
+
+   Whether the client wants to be responsible for updating the FQDN to
+   IP address mapping, or whether the client wants to delegate this
+   responsibility to a server is a local to the client matter. The
+   choice between the two alternatives may be based on a particular
+   security model that is used with the Dynamic DNS Update protocol
+   (e.g., only a client may have sufficient credentials to perform
+   updates to the FQDN to IP address mapping for its FQDN).
+
+   If a client releases its address lease prior to the lease expiration
+   time, and the client is responsible for updating its A RR(s), the
+   client should delete the A RR (following the procedures described in
+   [DynDNS]) associated with the leased address before sending DHCP
+   RELEASE message.
+
+
+4.3. DHCP Server behavior
+
+   When a server receives a DHCPREQUEST message from a client, if the
+   message contains the Client FQDN option, and the server replies to
+   the message with a DHCPACK message, the server shall originate an
+   update for the PTR RR (associated with the address leased to the
+   client).  The server shall originate the update before the server
+   sends the DHCPACK message to the client. The update shall be
+   originated following the procedures described in [DynDNS].  The RCODE
+   from the update [DynDNS] should be carried to the client in the
+   RCODE1 field of the Client FQDN option in the DHCPACK message. The
+   RCODE2 field should be set to 0.
+
+   In addition, if the Client FQDN option carried in the DHCPREQUEST
+   message has its Flags field set to 1, then the server shall originate
+   an update for the A RR (associated with the FQDN carried in the
+   option).  The server shall originate the update before the server
+   sends the DHCPACK message to the client.  The update shall be
+   originated following the procedures described in [DynDNS].  The RCODE
+
+
+
+Yakov Rekhter                                                   [Page 4]
+
+
+
+
+
+Internet Draft       draft-ietf-dhc-dhcp-dns-02.txt         October 1996
+
+
+   from the update [DynDNS] should be carried to the client in the
+   RCODE2 field of the Client FQDN option in the DHCPACK message.
+
+   When a server receives a DHCPREQUEST message from a client, and the
+   message contains the Client FQDN option, the server shall ignore the
+   value carried in the RCODE1 and RCODE2 fields of the option.
+
+   When a DHCP server sends the Client FQDN option to a client in the
+   DHCPACK message, the server should copy the Flags and the Domain Name
+   fields from the Client FQDN option that the client sent to the server
+   in the DHCPREQUEST message.
+
+
+   If a server originates updates for both the A and PTR RRs, then the
+   order in which the updates are generated is not significant.
+
+
+   If a server detects that a lease on an address that the server leases
+   to a client expires, the server should delete the PTR RR associated
+   with the address. In addition, if the client authorized the server to
+   update its A RR, the server should also delete the A RR. The deletion
+   should follow the procedures described in [DynDNS].
+
+   If a server terminates a lease on an address prior to the lease
+   expiration time, the server should delete the PTR RR associated with
+   the address. In addition, if the client (that leased the address)
+   authorized the server to update its A RR, the server should also
+   delete the A RR.  The deletion should follow the procedures described
+   in [DynDNS].
+
+
+5. Updating other RRs
+
+   The procedures described in this document cover updates only to the A
+   and PTR RRs. Updating other types of RRs is outside the scope of this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yakov Rekhter                                                   [Page 5]
+
+
+
+
+
+Internet Draft       draft-ietf-dhc-dhcp-dns-02.txt         October 1996
+
+
+6. Security Considerations
+
+   Security issues are not discussed in this document.
+
+
+7. References
+
+   [RFC1034] P. Mockapetris, "Domain names - concepts and facilities",
+   RFC1034, 11/01/1987
+
+   [RFC1035] P. Mockapetris, "Domain names - implementation and
+   specification", RFC1035, 11/01/1987
+
+   [RFC1541] R. Droms, "Dynamic Host Configuration Protocol", RFC1541,
+   10/27/1993
+
+   [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and
+   Answer Answers to Commonly asked ``New Internet User'' Questions",
+   RFC1594, 03/11/1994
+
+   [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates
+   in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS-
+   09.txt
+
+
+
+8. Acknowledgements
+
+   Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms
+   (Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron),
+   and Michael Patton (BBN) for their review and comments.
+
+
+9. Author Information
+
+
+   Yakov Rekhter
+   cisco Systems, Inc.
+   170 Tasman Dr.
+   San Jose, CA 95134
+   Phone: (914) 528-0090
+   email: yakov@cisco.com
+
+
+
+
+
+
+
+
+
+Yakov Rekhter                                                   [Page 6]
+
+