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/ |