draft-ietf-dhc-dhcp-dns-02.txt   draft-ietf-dhc-dhcp-dns-03.txt 
Network Working Group Yakov Rekhter Network Working Group Yakov Rekhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: April 1997 October 1996 Expiration Date: September 1997 March 1997
Interaction between DHCP and DNS Interaction between DHCP and DNS
draft-ietf-dhc-dhcp-dns-02.txt draft-ietf-dhc-dhcp-dns-03.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 3, line 22 skipping to change at page 3, line 22
To update the IP address to FQDN mapping a DHCP server needs to know 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 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 the client to convey its FQDN to the server this document defines a
new option, called "Client FQDN". new option, called "Client FQDN".
The code for this option is 81. Its minimum length is 4. The code for this option is 81. Its minimum length is 4.
Code Len Flags RCODE1 RCODE2 Domain Name Code Len Flags RCODE1 RCODE2 Domain Name
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
| TBD | n | 0/1 | | | ... | 81 | n | | | | ...
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
The Flags field allows a DHCP client to indicate to a DHCP server The Flags field allows a DHCP client to indicate to a DHCP server
whether the client wants the server to be responsible for updating whether (a) the client wants to be responsible for updating the FQDN
the FQDN to IP address mapping (if Flags is set to 1), or whether the to IP address mapping (if Flags is set to 0), or (b) the client wants
client wants to take this responsibility (if Flags is set to 0). the server to be responsible for updating the FQDN to IP address
mapping (if Flags is set to 1). The Flags field also allows a DHCP
server to indicate to a DHCP client that the server assumes the
responsibility for updating the FQDN to IP address mapping, even if
the client wants to be responsible for this update (if Flags is set
to 3).
The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to
a DHCP client the Response Code from Dynamic DNS Updates. a DHCP client the Response Code from Dynamic DNS Updates.
The Domain Name part of the option carries FQDN of a client. The Domain Name part of the option carries FQDN of a client.
4.2. DHCP Client behavior 4.2. DHCP Client behavior
If a client wants to be responsible for updating the FQDN to IP 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 address mapping for the FQDN and address(es) used by the client, then
skipping to change at page 5, line 7 skipping to change at page 5, line 11
In addition, if the Client FQDN option carried in the DHCPREQUEST In addition, if the Client FQDN option carried in the DHCPREQUEST
message has its Flags field set to 1, then the server shall originate 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 an update for the A RR (associated with the FQDN carried in the
option). The server shall originate the update before the server option). The server shall originate the update before the server
sends the DHCPACK message to the client. The update shall be sends the DHCPACK message to the client. The update shall be
originated following the procedures described in [DynDNS]. The RCODE originated following the procedures described in [DynDNS]. The RCODE
from the update [DynDNS] should be carried to the client in the from the update [DynDNS] should be carried to the client in the
RCODE2 field of the Client FQDN option in the DHCPACK message. RCODE2 field of the Client FQDN option in the DHCPACK message.
Even, if the Client FQDN option carried in the DHCPREQUEST message
has its Flags field set to 0 (indicating that the client wants to
update the A RR), the server could (under configuration control)
update the A RR. 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
RCODE2 field of the Client FQDN option in the DHCPACK message. The
Flags field in the Client FQND option shall be set to 3.
Whether a DHCP server is always responsible for updating the FQDN to
IP address mapping (in addition to updating the IP to FQDN mapping),
regarless of the wishes of a DHCP client, is a local to the server
matter. The choice between the two alternatives may be based on a
particular security model.
When a server receives a DHCPREQUEST message from a client, and the When a server receives a DHCPREQUEST message from a client, and the
message contains the Client FQDN option, the server shall ignore the message contains the Client FQDN option, the server shall ignore the
value carried in the RCODE1 and RCODE2 fields of the option. 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 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 DHCPACK message, the server shall copy the Domain Name fields from
fields from the Client FQDN option that the client sent to the server the Client FQDN option that the client sent to the server in the
in the DHCPREQUEST message. DHCPREQUEST message.
If the DHCPREQUST message received by a DHCP server from a DHCP
client doesn't carry the Client FQDN option, and the DHCP client
acquires its FQDN from a DHCP server (as part of a normal DHCP
transaction), then the server may be configured to update both A and
PTR RRs. In this scenario the DHCPOFFER message originated by the
server shall carry the Domain Name option, and the client
acknowledges the use of the FQDN carried in this option by including
the option (with the FQDN) in the DHCPREQUEST originated by the
client. The updates shall be originated following the procedures
described in [DynDNS].
If a server originates updates for both the A and PTR RRs, then the If a server originates updates for both the A and PTR RRs, then the
order in which the updates are generated is not significant. order in which the updates are generated is not significant.
If a server detects that a lease on an address that the server leases 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 to a client expires, the server should delete the PTR RR associated
with the address. In addition, if the client authorized the server to 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 update its A RR, the server should also delete the A RR. The deletion
should follow the procedures described in [DynDNS]. should follow the procedures described in [DynDNS].
skipping to change at page 6, line 30 skipping to change at page 7, line 7
[RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and [RFC1594] A. Marine, J. Reynolds, G. Malkin, "FYI on Questions and
Answer Answers to Commonly asked ``New Internet User'' Questions", Answer Answers to Commonly asked ``New Internet User'' Questions",
RFC1594, 03/11/1994 RFC1594, 03/11/1994
[DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates [DynDNS] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates
in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS- in the Domain Name System (DNS UPDATE)", draft-ietf-dnsind-dynDNS-
09.txt 09.txt
8. Acknowledgements 8. Acknowledgements
Many thanks to Mark Beyer (Tandem), Jim Bound (DEC), Ralph Droms Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Peter Ford, Edie
(Bucknell University), Edie Gunter (IBM), Michael Lewis (Chevron), Gunter, Michael Lewis, Michael Patton, and Glenn Stump for their
and Michael Patton (BBN) for their review and comments. review and comments.
9. Author Information 9. Author Information
Yakov Rekhter Yakov Rekhter
cisco Systems, Inc. cisco Systems, Inc.
170 Tasman Dr. 170 Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Phone: (914) 528-0090 Phone: (914) 528-0090
email: yakov@cisco.com email: yakov@cisco.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/