draft-ietf-dhc-dhcp-dns-01.txt   draft-ietf-dhc-dhcp-dns-02.txt 
Network Working Group Yakov Rekhter Network Working Group Yakov Rekhter
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: January 1997 July 1996 Expiration Date: April 1997 October 1996
Interaction between DHCP and DNS Interaction between DHCP and DNS
draft-ietf-dhc-dhcp-dns-01.txt draft-ietf-dhc-dhcp-dns-02.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 18 skipping to change at page 3, line 18
by a DHCP server. The IP address to FQDN mapping is updated by a DHCP by a DHCP server. The IP address to FQDN mapping is updated by a DHCP
server in both cases. server in both cases.
4.1. Client FQDN Option 4.1. Client FQDN Option
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 TBD. Its minimum length is 2. 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 | | | ... | TBD | n | 0/1 | | | ...
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
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 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 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). client wants to take this responsibility (if Flags is set to 0).
skipping to change at page 4, line 14 skipping to change at page 4, line 14
The update shall be originated following the procedures described in The update shall be originated following the procedures described in
[DynDNS]. [DynDNS].
If a client does not want to be responsible for updating the FQDN to 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, IP address mapping for the FQDN and address(es) used by the client,
then the client shall include the Client FQDN option in the then the client shall include the Client FQDN option in the
DHCPREQUEST message originated by the client. The Flags field in the DHCPREQUEST message originated by the client. The Flags field in the
option shall be set to 1. 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 Whether the client wants to be responsible for updating the FQDN to
IP address mapping, or whether the client wants to delegate this IP address mapping, or whether the client wants to delegate this
responsibility to a server is a local to the client matter. The responsibility to a server is a local to the client matter. The
choice between the two alternatives may be based on a particular choice between the two alternatives may be based on a particular
security model that is used with the Dynamic DNS Update protocol security model that is used with the Dynamic DNS Update protocol
(e.g., only a client may have sufficient credentials to perform (e.g., only a client may have sufficient credentials to perform
updates to the FQDN to IP address mapping for its FQDN). updates to the FQDN to IP address mapping for its FQDN).
If a client releases its address lease prior to the lease expiration 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 time, and the client is responsible for updating its A RR(s), the
skipping to change at page 5, line 7 skipping to change at page 5, line 9
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.
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 RCODE field 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
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 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].
 End of changes. 

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