draft-ietf-dhc-dhcpv6-fqdn-04.txt   draft-ietf-dhc-dhcpv6-fqdn-05.txt 
DHC B. Volz DHC B. Volz
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: August 28, 2006 February 24, 2006 Expires: September 23, 2006 March 22, 2006
The DHCPv6 Client FQDN Option The DHCPv6 Client FQDN Option
draft-ietf-dhc-dhcpv6-fqdn-04.txt draft-ietf-dhc-dhcpv6-fqdn-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2006. This Internet-Draft will expire on September 23, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies a new Dynamic Host Configuration Protocol for This document specifies a new Dynamic Host Configuration Protocol for
IPv6, DHCPv6, option which can be used to exchange information about IPv6, DHCPv6, option which can be used to exchange information about
a DHCPv6 client's fully-qualified domain name and about a DHCPv6 client's fully-qualified domain name and about
skipping to change at page 7, line 19 skipping to change at page 7, line 19
option in the Option Request option if it expects the server to option in the Option Request option if it expects the server to
include the Client FQDN option in any responses. include the Client FQDN option in any responses.
5.1. Client Desires to Update AAAA RRs 5.1. Client Desires to Update AAAA RRs
If a client that owns/maintains its own FQDN wants to be responsible If a client that owns/maintains its own FQDN wants to be responsible
for updating the FQDN to IPv6 address mapping for the FQDN and for updating the FQDN to IPv6 address mapping for the FQDN and
address(es) used by the client, the client MUST include the Client address(es) used by the client, the client MUST include the Client
FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and
REBIND message originated by the client. A client MAY choose to REBIND message originated by the client. A client MAY choose to
include the Client FQDN option in its SOLICIT messages. The "S" bit include the Client FQDN option in its SOLICIT messages. The "S",
in the Flags field in the option MUST be 0. The "O" and "N" bits "O", and "N" bits in the Flags field in the option MUST be 0.
MUST be 0.
Once the client's DHCPv6 configuration is completed (the client Once the client's DHCPv6 configuration is completed (the client
receives a REPLY message and successfully completes a final check on receives a REPLY message and successfully completes a final check on
the parameters passed in the message), the client MAY originate an the parameters passed in the message), the client MAY originate an
update for the AAAA RRs (associated with the client's FQDN) unless update for the AAAA RRs (associated with the client's FQDN) unless
the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6
client SHOULD NOT initiate an update for the name in the server's client SHOULD NOT initiate an update for the name in the server's
returned Client FQDN option Domain Name field. However, a DHCPv6 returned Client FQDN option Domain Name field. However, a DHCPv6
client that is explicitly configured with a FQDN MAY ignore the state client that is explicitly configured with a FQDN MAY ignore the state
of the "S" bit if the server's returned name matches the client's of the "S" bit if the server's returned name matches the client's
configured name. configured name.
5.2. Client Desires Server to Do DNS Updates 5.2. Client Desires Server to Do DNS Updates
A client can choose to delegate the responsibility for updating the A client can choose to delegate the responsibility for updating the
FQDN to IPv6 address mapping for the FQDN and address(es) used by the FQDN to IPv6 address mapping for the FQDN and address(es) used by the
client to the server. In order to inform the server of this choice, client to the server. In order to inform the server of this choice,
the client SHOULD include the Client FQDN option in its SOLICIT with the client SHOULD include the Client FQDN option in its SOLICIT with
Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the
Client FQDN option in its SOLICIT. The "S" bit in the Flags field in Client FQDN option in its SOLICIT. The "S" bit in the Flags field in
the option MUST be 1. The "O" and "N" bits MUST be 0. the option MUST be 1 and the "O" and "N" bits MUST be 0.
5.3. Client Desires No Server DNS Updates 5.3. Client Desires No Server DNS Updates
A client can choose to request that the server perform no DNS updates A client can choose to request that the server perform no DNS updates
on its behalf. In order to inform the server of this choice, the on its behalf. In order to inform the server of this choice, the
client SHOULD include the Client FQDN option in its SOLICIT with client SHOULD include the Client FQDN option in its SOLICIT with
Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the
Client FQDN option in its SOLICIT. The "N" bit in the Flags field in Client FQDN option in its SOLICIT. The "N" bit in the Flags field in
the option MUST be 1 and the "S" and "O" bits MUST be 0. the option MUST be 1 and the "S" and "O" bits MUST be 0.
skipping to change at page 8, line 39 skipping to change at page 8, line 37
to delete that record and attempt an update for the client's current to delete that record and attempt an update for the client's current
domain name. domain name.
A client that delegates the responsibility for updating the FQDN to A client that delegates the responsibility for updating the FQDN to
IPv6 address mapping to a server will not receive any indication IPv6 address mapping to a server will not receive any indication
(either positive or negative) from the server whether the server was (either positive or negative) from the server whether the server was
able to perform the update. The client MAY use a DNS query to check able to perform the update. The client MAY use a DNS query to check
whether the mapping is up to date. However, depending on the load on whether the mapping is up to date. However, depending on the load on
the DHCPv6 and DNS servers and the DNS propagation delays, the client the DHCPv6 and DNS servers and the DNS propagation delays, the client
can only infer success. If the information is not found to be up to can only infer success. If the information is not found to be up to
date in DNS, the servers might not have completed the updates or zone date in DNS, the authoritative servers might not have completed the
transfers, or not yet updated their caches. updates or zone transfers, or caching resolvers may yet have updated
their caches.
If a client releases an address prior to the expiration of the valid If a client releases an address prior to the expiration of the valid
lifetime and the client is responsible for updating its AAAA RR, the lifetime and the client is responsible for updating its AAAA RR, the
client SHOULD delete the AAAA RR associated with the address before client SHOULD delete the AAAA RR associated with the address before
sending a RELEASE message. Similarly, if a client is responsible for sending a RELEASE message. Similarly, if a client is responsible for
updating its AAAA RRs, but is unable to renew the lifetimes for an updating its AAAA RRs, but is unable to renew the lifetimes for an
address, the client SHOULD attempt to delete the AAAA RR before the address, the client SHOULD attempt to delete the AAAA RR before the
lifetime on the address is no longer valid. A DHCPv6 client which lifetime on the address is no longer valid. A DHCPv6 client which
has not been able to delete an AAAA RR which it added SHOULD attempt has not been able to delete an AAAA RR which it added SHOULD attempt
to notify its administrator, perhaps by emitting a log message. to notify its administrator, perhaps by emitting a log message.
skipping to change at page 9, line 20 skipping to change at page 9, line 20
the Client FQDN option. the Client FQDN option.
Servers MUST only include a Client FQDN option in ADVERTISE and REPLY Servers MUST only include a Client FQDN option in ADVERTISE and REPLY
messages if the client included a Client FQDN option and the Client messages if the client included a Client FQDN option and the Client
FQDN option is requested by the Option Request Option in the client's FQDN option is requested by the Option Request Option in the client's
message to which the server is responding. message to which the server is responding.
The server examines its configuration and the Flag bits in the The server examines its configuration and the Flag bits in the
client's Client FQDN option to determine how to respond: client's Client FQDN option to determine how to respond:
o The server sets to 0 the "S", "O", and "N" Flag bits in its copy o The server sets to 0 the "S", "O", and "N" bits in its copy of the
of the option it will return to the client. option it will return to the client.
o If the client's "N" bit is 1 and the server's configuration allows o If the client's "N" bit is 1 and the server's configuration allows
it to honor the client's request for no server initiated DNS it to honor the client's request for no server initiated DNS
updates, the server sets the "N" bit to 1. updates, the server sets the "N" bit to 1.
o Otherwise, if the client's "S" bit is 1 and the server's o Otherwise, if the client's "S" bit is 1 and the server's
configuration allows it to honor the client's request for the configuration allows it to honor the client's request for the
server to initiate AAAA RR DNS updates, the server sets the "S" to server to initiate AAAA RR DNS updates, the server sets the "S" to
1. If the server's "S" bit does not match the client's "S" bit, 1. If the server's "S" bit does not match the client's "S" bit,
the server sets the "O" bit to 1. the server sets the "O" bit to 1.
The server MAY be configured to use the name supplied in the client's The server MAY be configured to use the name supplied in the client's
skipping to change at page 10, line 10 skipping to change at page 10, line 10
The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in
the Flags field of the Client FQDN option in the REPLY message (to the Flags field of the Client FQDN option in the REPLY message (to
be) sent to the client. be) sent to the client.
The server MAY perform these updates even if the client's message did The server MAY perform these updates even if the client's message did
not carry the Client FQDN option. The server MUST NOT initiate DNS not carry the Client FQDN option. The server MUST NOT initiate DNS
updates when responding with an ADVERTISE message to the client. updates when responding with an ADVERTISE message to the client.
The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR)
before the server sends the REPLY message to the client. before or after sending the REPLY message to the client.
Alternatively, the server MAY send the REPLY message to the client
without waiting for the update to be completed. Whether the DNS
update occurs before or after the REPLY is sent is entirely up to the
DHCPv6 server's configuration.
If the server's AAAA RR DNS update does not complete until after the If the server's AAAA RR DNS update does not complete until after the
server has replied to the DHCPv6 client, the server's interaction server has replied to the DHCPv6 client, the server's interaction
with the DNS server MAY cause the DHCPv6 server to change the domain with the DNS server MAY cause the DHCPv6 server to change the domain
name that it associates with the client. This can occur, for name that it associates with the client. This can occur, for
example, if the server detects and resolves a domain-name conflict example, if the server detects and resolves a domain-name conflict
[8]. In such cases, the domain name that the server returns to the [8]. In such cases, the domain name that the server returns to the
DHCPv6 client would change between two DHCPv6 exchanges. DHCPv6 client would change between two DHCPv6 exchanges.
If the server previously performed DNS updates for the client and the If the server previously performed DNS updates for the client and the
skipping to change at page 11, line 5 skipping to change at page 10, line 49
DNS queries will return records that refer to DHCP IP address DNS queries will return records that refer to DHCP IP address
assignments that have expired or been released. assignments that have expired or been released.
The coupling among primary, secondary, and caching DNS servers is The coupling among primary, secondary, and caching DNS servers is
'loose'; that is a fundamental part of the design of the DNS. This 'loose'; that is a fundamental part of the design of the DNS. This
looseness makes it impossible to prevent all possible situations in looseness makes it impossible to prevent all possible situations in
which a resolver may return a record reflecting a DHCP assigned IP which a resolver may return a record reflecting a DHCP assigned IP
address that has expired or been released. In deployment, this address that has expired or been released. In deployment, this
rarely, if ever, represents a significant problem. Most DHCP-managed rarely, if ever, represents a significant problem. Most DHCP-managed
clients are infrequently looked-up by name in the DNS, and the clients are infrequently looked-up by name in the DNS, and the
deployment of IXFR (RFC 1995 [13]) and NOTIFY (RFC 1996 [14]) can deployment of IXFR ([13]) and NOTIFY ([14]) can reduce the latency
reduce the latency between updates and their visibility at secondary between updates and their visibility at secondary servers.
servers.
We suggest these basic guidelines for implementers. In general, the We suggest these basic guidelines for implementers. In general, the
TTLs for RRs added as a result of DHCP IP address assignment activity TTLs for RRs added as a result of DHCP IP address assignment activity
SHOULD be less than the initial lifetime. The RR TTL on a DNS record SHOULD be less than the initial lifetime. The RR TTL on a DNS record
added SHOULD NOT exceed 1/3 of the lifetime, and SHOULD be at least added SHOULD NOT exceed 1/3 of the lifetime, but SHOULD NOT be less
10 minutes. We recognize that individual administrators will have than 10 minutes. We recognize that individual administrators will
varying requirements: DHCP servers and clients SHOULD allow have varying requirements: DHCP servers and clients SHOULD allow
administrators to configure TTLs and upper and lower bounds on the administrators to configure TTLs and upper and lower bounds on the
TTL values, either as an absolute time interval or as a percentage of TTL values, either as an absolute time interval or as a percentage of
the lease lifetime. the lease lifetime.
While clients and servers MAY update the TTL of the records as the While clients and servers MAY update the TTL of the records as the
lifetime is about to expire, there is no requirement that they do so lifetime is about to expire, there is no requirement that they do so
as this puts additional load on the DNS system with likely little as this puts additional load on the DNS system with likely little
benefit. benefit.
8. DNS Update Conflicts 8. DNS Update Conflicts
 End of changes. 10 change blocks. 
22 lines changed or deleted 17 lines changed or added

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