draft-ietf-dhc-dhcpv6-fqdn-00.txt | draft-ietf-dhc-dhcpv6-fqdn-01.txt | |||
---|---|---|---|---|
DHC B. Volz | DHC B. Volz | |||
Internet-Draft Cisco Systems, Inc. | Internet-Draft Cisco Systems, Inc. | |||
Expires: March 17, 2005 September 16, 2004 | Expires: July 29, 2005 January 25, 2005 | |||
The DHCPv6 Client FQDN Option | The DHCPv6 Client FQDN Option | |||
draft-ietf-dhc-dhcpv6-fqdn-00.txt | draft-ietf-dhc-dhcpv6-fqdn-01.txt | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is subject to all provisions | This document is an Internet-Draft and is subject to all provisions | |||
of section 3 of RFC 3667. By submitting this Internet-Draft, each | of Section 3 of RFC 3667. By submitting this Internet-Draft, each | |||
author represents that any applicable patent or other IPR claims of | author represents that any 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 is aware have been or will be disclosed, and any of | |||
which he or she become aware will be disclosed, in accordance with | which he or she become aware will be disclosed, in accordance with | |||
RFC 3668. | RFC 3668. | |||
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 | |||
other groups may also distribute working documents as | other groups may also distribute working documents as | |||
Internet-Drafts. | Internet-Drafts. | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
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 March 17, 2005. | This Internet-Draft will expire on July 29, 2005. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2004). | Copyright (C) The Internet Society (2005). | |||
Abstract | Abstract | |||
This document specifies a new DHCP for IPv6, DHCPv6, option which can | This document specifies a new Dynamic Host Configuration Protocol for | |||
be used to exchange information about a DHCPv6 client's | IPv6, DHCPv6, option which can be used to exchange information about | |||
fully-qualified domain name and about responsibility for updating DNS | a DHCPv6 client's fully-qualified domain name and about | |||
RRs related to the client's address assignments. | responsibility for updating DNS RRs related to the client's address | |||
assignments. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Models of Operation . . . . . . . . . . . . . . . . . . . . . 3 | 3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 | |||
4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4 | 4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . 4 | |||
4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 | 4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5 | |||
4.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 6 | 4.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 6 | |||
5. DHCPv6 Client behavior . . . . . . . . . . . . . . . . . . . . 7 | 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 6 | |||
6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8 | 5.1 Client Desires to Update AAAA RRs . . . . . . . . . . . . 7 | |||
7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 9 | 5.2 Client Desires Server to Do DNS Updates . . . . . . . . . 7 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 5.3 Client Desires No Server DNS Updates . . . . . . . . . . . 7 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.4 Domain Name and DNS Update Issues . . . . . . . . . . . . 8 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 8 | |||
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 | 6.1 When to Perform DNS Updates . . . . . . . . . . . . . . . 9 | |||
10.2 Informative References . . . . . . . . . . . . . . . . . . . 11 | 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . 10 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 | |||
Intellectual Property and Copyright Statements . . . . . . . . 12 | 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
11.1 Normative References . . . . . . . . . . . . . . . . . . 11 | ||||
11.2 Informative References . . . . . . . . . . . . . . . . . 12 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
Intellectual Property and Copyright Statements . . . . . . . 13 | ||||
1. Introduction | 1. Introduction | |||
DNS ([2], [3]) maintains (among other things) the information about | DNS ([2], [3]) maintains (among other things) the information about | |||
mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] and | mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] and | |||
IP addresses assigned to the hosts. The information is maintained in | IPv6 addresses assigned to the hosts. The information is maintained | |||
two types of Resource Records (RRs): AAAA and PTR [11]. The DNS | in two types of Resource Records (RRs): AAAA and PTR [10]. The DNS | |||
update specification ([4]) describes a mechanism that enables DNS | update specification ([4]) describes a mechanism that enables DNS | |||
information to be updated over a network. | information to be updated over a network. | |||
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] | The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] | |||
provides a mechanism by which a host (a DHCPv6 client) can acquire | provides a mechanism by which a host (a DHCPv6 client) can acquire | |||
certain configuration information, along with its stateful IPv6 | certain configuration information, along with its stateful IPv6 | |||
address(es). This document specifies a new DHCPv6 option, the Client | address(es). This document specifies a new DHCPv6 option, the Client | |||
FQDN option, which can be used by DHCPv6 clients and servers to | FQDN option, which can be used by DHCPv6 clients and servers to | |||
exchange information about the client's fully-qualified domain name | exchange information about the client's fully-qualified domain name | |||
and who has the responsibility for updating the DNS with the | and who has the responsibility for updating the DNS with the | |||
skipping to change at page 4, line 34 | skipping to change at page 4, line 34 | |||
the DNS servers will accept, to sites where each individual DHCPv6 | the DNS servers will accept, to sites where each individual DHCPv6 | |||
client has been configured with credentials which allow the client to | client has been configured with credentials which allow the client to | |||
modify its own domain name. Compliant implementations MAY support | modify its own domain name. Compliant implementations MAY support | |||
some or all of these possibilities. Furthermore, this specification | some or all of these possibilities. Furthermore, this specification | |||
applies only to DHCPv6 client and server processes: it does not apply | applies only to DHCPv6 client and server processes: it does not apply | |||
to other processes which initiate DNS updates. | to other processes which initiate DNS updates. | |||
This document describes a new DHCPv6 option which a client can use to | This document describes a new DHCPv6 option which a client can use to | |||
convey all or part of its domain name to a DHCPv6 server. | convey all or part of its domain name to a DHCPv6 server. | |||
Site-specific policy determines whether DHCPv6 servers use the names | Site-specific policy determines whether DHCPv6 servers use the names | |||
that clients offer or not, and what DHCPv6 servers may do in cases | that clients offer or not, and what DHCPv6 servers do in cases where | |||
where clients do not supply domain names. | clients do not supply domain names. | |||
Other work, such as "Resolving Name Conflicts" [6], may define | ||||
procedures for establishing policy and arbitrating conflicts when | ||||
collisions occur in the use of FQDNs by DHCPv6 clients. | ||||
4. The DHCPv6 Client FQDN Option | 4. The DHCPv6 Client FQDN Option | |||
To update the IPv6 address to FQDN mapping a DHCPv6 server needs to | To update the IPv6 address to FQDN mapping a DHCPv6 server needs to | |||
know the FQDN of the client for the addresses in a binding. To allow | know the FQDN of the client for the addresses for the client's IA_NA | |||
the client to convey its FQDN to the server this document defines a | bindings. To allow the client to convey its FQDN to the server this | |||
new DHCPv6 option, called "Client FQDN". The Client FQDN option also | document defines a new DHCPv6 option, called "Client FQDN". The | |||
contains Flags which DHCPv6 clients and servers use to negotiate who | Client FQDN option also contains Flags which DHCPv6 clients and | |||
does which updates. | servers use to negotiate who does which updates. | |||
The code for this option is TBD. Its minimum length is 2. | The code for this option is TBD. Its minimum length is 1 octet. | |||
The Format of the DHCPv6 Client FQDN option is shown below: | The format of the DHCPv6 Client FQDN option is shown below: | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| OPTION_FQDN | option-len | | | OPTION_FQDN | option-len | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| flags | | | | flags | | | |||
+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+ | | |||
. . | . . | |||
. domain-name . | . domain-name . | |||
skipping to change at page 5, line 29 | skipping to change at page 5, line 29 | |||
option-code OPTION_CLIENT_FQDN (TBD) | option-code OPTION_CLIENT_FQDN (TBD) | |||
option-len 1 + length of domain name | option-len 1 + length of domain name | |||
flags flag bits used between client and server to | flags flag bits used between client and server to | |||
negotiate who performs which updates | negotiate who performs which updates | |||
domain-name the partial or fully qualified domain name | domain-name the partial or fully qualified domain name | |||
(with length option-len - 1) | (with length option-len - 1) | |||
The Client FQDN option MUST only appear in IA_NA-options and | The Client FQDN option MUST only appear in a message's options field | |||
IA_TA-options (see [12]) fields and applies to all addresses for that | and applies to all addresses for all IA_NA bindings in the | |||
binding. | transaction. | |||
4.1 The Flags Field | 4.1 The Flags Field | |||
The Format of the Flags field: | The format of the Flags field is: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| MBZ |N|O|S| | | MBZ |N|O|S| | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
When a DHCPv6 client sends the Client FQDN option, it sets the "S" | The "S" bit indicates whether the server SHOULD or SHOULD NOT perform | |||
bit to indicate that it will not perform any DNS updates, and that it | the AAAA RR (FQDN to address) DNS updates. A client sets the bit to | |||
expects the DHCPv6 server to perform any FQDN-to-IPv6 (the AAAA RR) | 0 to indicate the server SHOULD NOT perform the updates and 1 to | |||
DNS updates on its behalf. If this bit is clear, the client | indicate the server SHOULD perform the updates. The state of the bit | |||
indicates that it intends to perform the FQDN-to-IPv6 DNS updates. | in the reply from the server indicates the action to be taken by the | |||
server; if 1, the server has taken responsibility for AAAA RR updates | ||||
for the FQDN. | ||||
If a DHCPv6 server intends to take responsibility for the AAAA RR | The "O" bit indicates whether the server has overridden the client's | |||
updates, whether or not the client sending the Client FQDN option has | preference for the "S" bit. A client MUST set this bit to 0. A | |||
set the "S" bit, it sets both the "O" and "S" bits, and sends the | server MUST set this bit to 1 if the "S" bit in its reply to the | |||
Client FQDN option in its response message. Clients SHOULD clear the | client does not match the "S" bit received from the client. | |||
"O" bit before sending the Client FQDN option and servers MUST ignore | ||||
the received state of the "O" bit. | ||||
A client MAY set the "N" bit in its request messages to indicate that | The "N" bit indicates whether the server SHOULD NOT perform any DNS | |||
the server should not perform any DNS updates on its behalf. As | updates. A client sets this bit to 0 to request that the server | |||
mentioned in Section 3, in general the DHCPv6 server will be | SHOULD perform updates (the PTR RR and possibly the AAAA RR based on | |||
maintaining DNS PTR records on behalf of clients. However, there may | the "S" bit) or to 1 to request that the server SHOULD NOT perform | |||
be deployments in which clients are configured to perform all desired | any DNS updates. A server sets the "N" bit to indicate whether the | |||
DNS updates or may not want any DNS updates. The server MAY be | server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" | |||
configured to honor this configuration. If the server has been | bit is 1, the "S" bit MUST be 0. | |||
configured to honor a client's "N" indication, it SHOULD set the "N" | ||||
bit in Client FQDN options which it sends to the client in its | ||||
response messages. Clients which have set the "N" bit in their | ||||
requests SHOULD use the state of the "N" bit in server responses to | ||||
determine whether the server was prepared to honor the client's | ||||
indication. If a client has set the "N" bit but its server does not, | ||||
the client SHOULD conclude that the server was not configured to | ||||
honor the client's suggestion, and that the server may attempt to | ||||
perform DNS updates on its behalf. | ||||
The remaining bits in the Flags field are reserved for future | The remaining bits in the Flags field are reserved for future | |||
assignment. DHCPv6 clients and servers which send the Client FQDN | assignment. DHCPv6 clients and servers which send the Client FQDN | |||
option MUST set the MBZ bits to 0, and they MUST ignore these bits. | option MUST clear the MBZ bits, and they MUST ignore these bits. | |||
4.2 The Domain Name Field | 4.2 The Domain Name Field | |||
The Domain Name field of the option carries all or part of the FQDN | The Domain Name part of the option carries all or part of the FQDN of | |||
of a DHCPv6 client. The data in the Domain Name field MUST appear in | a DHCPv6 client. The data in the Domain Name field MUST be encoded | |||
uncompressed DNS encoding as specified in [3]. In order to determine | as described in Section 8 of [5]. In order to determine whether the | |||
whether a name has changed between message exchanges, an unambiguous | FQDN has changed between message exchanges, the client and server | |||
canonical form is necessary. Eventually, the IETF IDN Working Group | MUST NOT alter the Domain Name field contents unless the FQDN has | |||
is expected to produce a standard canonicalization specification, and | actually changed. | |||
this specification may be updated to include its standard. Until | ||||
that time, servers and clients should be sensitive to | ||||
canonicalization when comparing names in the Domain Name field and | ||||
the name canonicalization defined in [9] MAY be used. | ||||
A client may be configured with a fully-qualified domain name, or | A client MAY be configured with a fully-qualified domain name or with | |||
with a partial name that is not fully-qualified. If a client knows | a partial name that is not fully-qualified. If a client knows only | |||
only part of its name, it MAY send a name that is not | part of its name, it MAY send a name that is not fully-qualified, | |||
fully-qualified, indicating that it knows part of the name but does | indicating that it knows part of the name but does not necessarily | |||
not necessarily know the zone in which the name is to be embedded. A | know the zone in which the name is to be embedded. | |||
client which wants to convey part of its FQDN sends a non-terminal | ||||
sequence of labels in the domain name field of the option. Clients | ||||
and servers should assume that the name field contains a | ||||
fully-qualified name unless this partial-name format exists. | ||||
Servers MUST always send the complete fully-qualified domain name in | To send a fully-qualified domain name, the Domain Name field is set | |||
to the DNS encoded domain name including the terminating zero-length | ||||
label. To send a partial name, the Domain Name field is set to the | ||||
DNS encoded domain name without the terminating zero-length label. | ||||
A client MAY also leave the Domain Name field empty if it desires the | ||||
server to provide a name. | ||||
Servers SHOULD send the complete fully-qualified domain name in | ||||
Client FQDN options. | Client FQDN options. | |||
5. DHCPv6 Client behavior | 5. DHCPv6 Client Behavior | |||
The following describes the behavior of a DHCPv6 client that | The following describes the behavior of a DHCPv6 client that | |||
implements the Client FQDN option. | implements the Client FQDN option. | |||
A client MUST only include Client FQDN options in the IA_NA-options | A client MUST only include the Client FQDN option in SOLICIT, | |||
and IA_TA-options fields in SOLICIT, REQUEST, RENEW, or REBIND | REQUEST, RENEW, or REBIND messages. | |||
messages. | ||||
A client that sends the Client FQDN option MUST also include the | A client that sends the Client FQDN option MUST also include the | |||
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. | |||
A client sends the Client FQDN option with no Flags bits set, the "S" | 5.1 Client Desires to Update AAAA RRs | |||
Flags bit set, or the "N" Flags bit set and with the desired partial | ||||
or fully qualified domain name. | ||||
There is no requirement that the client send identical Client FQDN | If a client that owns/maintains its own FQDN wants to be responsible | |||
options data in each of its messages to a server. In particular, if | for updating the FQDN to IPv6 address mapping for the FQDN and | |||
a client has sent Client FQDN options to its server, and the | address(es) used by the client, the client MUST include the Client | |||
configuration of the client changes so that its notion of its domain | FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and | |||
name changes, it MAY send the new name data in a Client FQDN options | REBIND message originated by the client. A client MAY choose to | |||
when it communicates with the server again. This may cause the | include the Client FQDN option in its SOLICIT messages. The "S" bit | |||
DHCPv6 server to update the name associated with the PTR record, and, | in the Flags field in the option MUST be 0. The "O" and "N" bits | |||
if the server updated the AAAA record representing the client, to | MUST be 0. | |||
delete that record and attempt an update for the client's current | ||||
domain name. | ||||
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 SHOULD originate | the parameters passed in the message), the client MAY originate an | |||
the DNS updates for the AAAA RR (associated with the client's FQDNs) | update for the AAAA RRs (associated with the client's FQDN) unless | |||
for any Client FQDN options for which the received "S" and the "O" | the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 | |||
bits in the option's Flags field are not set and if it is otherwise | client MUST NOT initiate an update for the name in the Domain Name | |||
configured to perform the DNS updates. The update SHOULD be | field. | |||
originated following the procedures described in [4]. If the DHCPv6 | ||||
server from which the client is requesting addresses includes Client | ||||
FQDN options in its REPLY message, and if the server sets both the | ||||
"S" and "O" bits in the option's Flags field, the DHCPv6 client MUST | ||||
NOT initiate an update for the name in the Domain Name field and the | ||||
addresses in that binding. | ||||
A client that delegates the responsibility for updating the | 5.2 Client Desires Server to Do DNS Updates | |||
FQDN-to-IPv6 address mapping to a server does not receive any | ||||
indication (either positive or negative) from the server whether the | ||||
server was able to perform the update. If the client needs to | ||||
confirm the DNS update, it SHOULD use a DNS query to check whether | ||||
the mapping is updated. | ||||
If a client releases an address prior to the valid lifetime | A client can choose to delegate the responsibility for updating the | |||
expiration or is unable to extend the lifetimes for an address and | FQDN to IPv6 address mapping for the FQDN and address(es) used by the | |||
the valid lifetime expires, and the client is responsible for | client to the server. In order to inform the server of this choice, | |||
updating its AAAA RRs, the client SHOULD delete the AAAA RR | the client SHOULD include the Client FQDN option in its SOLICIT with | |||
associated with the address before sending a RELEASE message or the | Rapid Commit, REQUEST, RENEW, and REBIND message and MAY include the | |||
lifetime expires. A DHCPv6 client which has not been able to delete | Client FQDN option in its SOLICIT. The "S" bit in the Flags field in | |||
an AAAA RR which it added (because it has lost the use of addresses | the option MUST be 1. The "O" and "N" bits MUST be 0. | |||
of sufficient scope to communicate with the DNS server or has | ||||
exhausted retry limits) should attempt to notify its administrator, | 5.3 Client Desires No Server DNS Updates | |||
perhaps by emitting a log message. | ||||
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 | ||||
client SHOULD include the Client FQDN option in its SOLICIT with | ||||
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 | ||||
the option MUST be 1 and the "S" and "O" bits MUST be 0. | ||||
Once the client's DHCPv6 configuration is completed (the client | ||||
receives a REPLY message and successfully completes a final check on | ||||
the parameters passed in the message), the client MAY originate its | ||||
DNS updates provided the server's "N" bit is 1. If the server's "N" | ||||
bit is 0, the server MAY perform the PTR RR updates; and, MAY also | ||||
perform the AAAA RR updates if the "S" bit is 1. | ||||
5.4 Domain Name and DNS Update Issues | ||||
As there is a possibility that the DHCPv6 server is configured to | ||||
complete or replace a domain name that the client sends, the client | ||||
MAY find it useful to send the Client FQDN option in its SOLICIT | ||||
messages. If the DHCPv6 server returns different Domain Name data in | ||||
its ADVERTISE message, the client could use that data in performing | ||||
its own eventual AAAA RR update, or in forming the Client FQDN option | ||||
that it sends in its subsequent messages. There is no requirement | ||||
that the client send identical Client FQDN option data in its | ||||
SOLICIT, REQUEST, RENEW, or REBIND messages. In particular, if a | ||||
client has sent the Client FQDN option to its server, and the | ||||
configuration of the client changes so that its notion of its domain | ||||
name changes, it MAY send the new name data in a Client FQDN option | ||||
when it communicates with the server again. This MAY cause the | ||||
DHCPv6 server to update the name associated with the PTR records, | ||||
and, if the server updated the AAAA record representing the client, | ||||
to delete that record and attempt an update for the client's current | ||||
domain name. | ||||
A client that delegates the responsibility for updating the FQDN to | ||||
IPv6 address mapping to a server will not receive any indication | ||||
(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 | ||||
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 | ||||
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 | ||||
transfers, or not yet updated their caches. | ||||
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 | ||||
client SHOULD delete the AAAA RR associated with the address before | ||||
sending a RELEASE message. Similarly, if a client is responsible for | ||||
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 | ||||
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 | ||||
to notify its administrator, perhaps by emitting a log message. | ||||
6. DHCPv6 Server Behavior | 6. DHCPv6 Server Behavior | |||
Servers MUST only include Client FQDN options for a binding in | The following describes the behavior of a DHCPv6 server that | |||
ADVERTISE and REPLY messages if the client included a Client FQDN | implements the Client FQDN option when the client's message includes | |||
option for that binding and the Client FQDN option is requested by | the Client FQDN option. | |||
the Option Request Option in the client's message to which the server | ||||
is responding. Servers MUST only include Client FQDN options in the | ||||
IA_NA-options and IA_TA-options fields in messages sent by the | ||||
server. | ||||
When a server allocates a new address from a binding, it uses the | Servers MUST only include a Client FQDN option in ADVERTISE and REPLY | |||
Client FQDN option, if any, in the IA_NA-options or IA_TA-options | messages if the client included a Client FQDN option and the Client | |||
field of that binding to determine the fully qualified domain name | FQDN option is requested by the Option Request Option in the client's | |||
and who will take responsibility for the DNS updates. It records the | message to which the server is responding. | |||
results in the Client FQDN option. The DHCPv6 server SHOULD send its | ||||
The server examines its configuration and the Flag bits in the | ||||
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 | ||||
of the option it will return to the client. | ||||
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 | ||||
updates, the server sets the "N" bit to 1. | ||||
o Otherwise, if the client's "S" bit is 1 and the servers's | ||||
configuration allows it to honor the client's request for the | ||||
server to initiate AAAA RR DNS updates and if it has the necessary | ||||
credentials, the server sets the "S" to 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 MAY be configured to use the name supplied in the client's | ||||
Client FQDN option, or it MAY be configured to modify the supplied | ||||
name, or substitute a different name. The server SHOULD send its | ||||
notion of the complete FQDN for the client in the Domain Name field. | notion of the complete FQDN for the client in the Domain Name field. | |||
The server MAY simply copy the Domain Name field from the Client FQDN | The server MAY simply copy the Domain Name field from the Client FQDN | |||
option that the client sent to the server. The DHCPv6 server MAY be | option that the client sent to the server. | |||
configured to complete or modify the domain name which a client sent, | ||||
or it MAY be configured to substitute a different name. | ||||
If a client's SOLICIT, REQUEST, RENEW, or REBIND message doesn't | 6.1 When to Perform DNS Updates | |||
include the Client FQDN option for a binding (e.g., the client | ||||
doesn't implement the Client FQDN option), the server MAY be | ||||
configured to update either or both of the AAAA and PTR RRs. | ||||
If a client's message includes a Client FQDN option for a binding and | The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in | |||
the requested domain-name is different from the server's current | the Flags field of the Client FQDN option in the REPLY messages (to | |||
knowledge of the fully-qualified domain name and the server is | be) sent to the client. However, the server SHOULD delete any RRs | |||
configured to allow use of that name, the server SHOULD perform the | which it previously added via DNS updates for the client. | |||
necessary DNS updates - the server SHOULD remove the old PTR and AAAA | ||||
RRs it added, if any, and add the new RRs - if it has that | The server MAY perform the PTR RR DNS update (unless the "N" bit is | |||
responsibility. | 1). | |||
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 DHCPACK message (to | ||||
be) sent to the client. | ||||
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 | ||||
updates when responding with an ADVERTISE message to the client. | ||||
The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) | ||||
before the server sends 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 | ||||
server has replied to the DHCPv6 client, the server's interaction | ||||
with the DNS server MAY cause the DHCPv6 server to change the domain | ||||
name that it associates with the client. This can occur, for | ||||
example, if the server detects and resolves a domain-name conflict | ||||
[6]. In such cases, the domain name that the server returns to the | ||||
DHCPv6 client would change between two DHCPv6 exchanges. | ||||
If the server previously performed DNS updates for the client and the | ||||
client's information has not changed, the server MAY skip performing | ||||
additional DNS updates. | ||||
When a server receives a RELEASE or DECLINE for an address, detects | When a server receives a RELEASE or DECLINE for an address, detects | |||
that the valid lifetime on an address that the server bound to a | that the valid lifetime on an address that the server bound to a | |||
client has expired, or terminates a binding on an address prior to | client has expired, or terminates a binding on an address prior to | |||
the binding's expiration time (for instance, by sending a REPLY with | the binding's expiration time (for instance, by sending a REPLY with | |||
a zero valid lifetime for an address), the server SHOULD delete any | a zero valid lifetime for an address), the server SHOULD delete any | |||
PTR RRs which it associated with the address via DNS update. In | PTR RR which it associated with the address via DNS update. In | |||
addition, if the server took responsibility for the AAAA RR, the | addition, if the server took responsibility for AAAA RRs, the server | |||
server SHOULD also delete that AAAA RR. | SHOULD also delete the AAAA RR. | |||
A server MAY initiate and complete the DNS update(s) before the | ||||
server sends the REPLY message to the client. Alternatively, the | ||||
server MAY send the REPLY message to the client without waiting for | ||||
the update to be initiated or completed. The choice between the two | ||||
alternatives is entirely determined by the configuration of the | ||||
DHCPv6 server. Servers SHOULD support both configuration options. | ||||
If the server initiates a DNS update that is not complete until after | ||||
the server has replied to the client, the server's interaction with | ||||
the DNS server may cause the DHCPv6 server to change the domain name | ||||
that it associates with an address for the client. This may occur, | ||||
for example, if the server detects and resolves a domain-name | ||||
conflict. In such cases, the domain name that the server returns to | ||||
the client may change between two DHCPv6 exchanges. | ||||
7. DNS Update Conflicts | 7. DNS Update Conflicts | |||
This document does not resolve how a DHCPv6 client or server prevent | This document does not resolve how a DHCPv6 client or server prevent | |||
name conflicts. This document addresses only how a DHCPv6 client and | name conflicts. This document addresses only how a DHCPv6 client and | |||
server negotiate the fully qualified domain name and who will perform | server negotiate the fully qualified domain name and who will perform | |||
the DNS updates. | the DNS updates. | |||
Implementers of this work will need to consider how name conflicts | Implementers of this work will need to consider how name conflicts | |||
will be prevented. It may be that the DNS updater must hold a | will be prevented. If a DNS updater needs a security token in order | |||
security token in order to successfully perform DNS updates on a | to successfully perform DNS updates on a specific name, name | |||
specific name, in which case name conflicts can only occur if | conflicts can only occur if multiple clients are given a security | |||
multiple clients are given a security token for that name. Or, the | token for that name. Or, if the fully qualified domains are based on | |||
fully qualified domains may be based on the specific address bound to | the specific address bound to a client, conflicts SHOULD NOT occur. | |||
a client or the client's DUID, and in these cases conflicts should | Or, a name conflict resolution technique as described in "Resolving | |||
not occur. However, without this level of security in the DNS system | Name Conflicts" [6]) SHOULD be used. | |||
or use of non-conflicting names, other techniques need to be | ||||
developed. This is an area for future work (see [6]). | ||||
8. Security Considerations | 8. IANA Considerations | |||
IANA is requested to assign a DHCPv6 option code for the Client FQDN | ||||
option. | ||||
9. Security Considerations | ||||
Unauthenticated updates to the DNS can lead to tremendous confusion, | Unauthenticated updates to the DNS can lead to tremendous confusion, | |||
through malicious attack or through inadvertent misconfiguration. | through malicious attack or through inadvertent misconfiguration. | |||
Administrators should be wary of permitting unsecured DNS updates to | Administrators need to be wary of permitting unsecured DNS updates to | |||
zones which are exposed to the global Internet. Both DHCPv6 clients | zones which are exposed to the global Internet. Both DHCPv6 clients | |||
and servers SHOULD use some form of update request origin | and servers SHOULD use some form of update request origin | |||
authentication procedure (e.g., Secure DNS Dynamic Update [10]) when | authentication procedure (e.g., Secure DNS Dynamic Update [9]) when | |||
performing DNS updates. | performing DNS updates. | |||
Whether a DHCPv6 client may be responsible for updating an FQDN to | Whether a DHCPv6 client is responsible for updating an FQDN to IPv6 | |||
IPv6 address mapping or whether this is the responsibility of the | address mapping or whether this is the responsibility of the DHCPv6 | |||
DHCPv6 server is a site-local matter. The choice between the two | server is a site-local matter. The choice between the two | |||
alternatives may be based on the security model that is used with the | alternatives is likely based on the security model that is used with | |||
DNS update protocol (e.g., only a client may have sufficient | the DNS update protocol (e.g., only a client may have sufficient | |||
credentials to perform updates to the FQDN to IP address mapping for | credentials to perform updates to the FQDN to IPv6 address mapping | |||
its FQDN). | for its FQDN). | |||
Whether a DHCPv6 server is always responsible for updating the FQDN | Whether a DHCPv6 server is always responsible for updating the FQDN | |||
to IPv6 address mapping (in addition to updating the IPv6 to FQDN | to IPv6 address mapping (in addition to updating the IPv6 to FQDN | |||
mapping), regardless of the wishes of an individual DHCPv6 client, is | mapping), regardless of the wishes of an individual DHCPv6 client, is | |||
also a site-local matter. The choice between the two alternatives | also a site-local matter. The choice between the two alternatives is | |||
may be based on the security model that is being used with DNS | likely based on the security model that is being used with DNS | |||
updates. In cases where a DHCPv6 server is performing DNS updates on | updates. In cases where a DHCPv6 server is performing DNS updates on | |||
behalf of a client, the DHCPv6 server should be sure of the DNS name | behalf of a client, the DHCPv6 server SHOULD be sure of the DNS name | |||
to use for the client, and of the identity of the client. | to use for the client, and of the identity of the client. | |||
Depending on the prescence of or type of authentication used with the | Depending on the prescence of or type of authentication used with the | |||
Authentication option, a DHCPv6 server may not have much confidence | Authentication option, a DHCPv6 server may not have much confidence | |||
in the identities of its clients. There are many ways for a DHCPv6 | in the identities of its clients. There are many ways for a DHCPv6 | |||
server to develop a DNS name to use for a client, but only in certain | server to develop a DNS name to use for a client, but only in certain | |||
circumstances will the DHCPv6 server know for certain the identity of | circumstances will the DHCPv6 server know for certain the identity of | |||
the client. | the client. | |||
9. Acknowledgements | 10. Acknowledgements | |||
Many thanks to Mark Stapp and Yakov Rekhter as this document is based | Many thanks to Mark Stapp and Yakov Rekhter as this document is based | |||
on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [7]). | on the DHCPv4 Client FQDN option (draft-ietf-dhc-fqdn-option [7]). | |||
And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and | And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and | |||
Ralph Droms for discussions on this work. | Ralph Droms for discussions on this work. | |||
10. References | 11. References | |||
10.1 Normative References | 11.1 Normative References | |||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Levels", BCP 14, RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[2] Mockapetris, P., "Domain names - concepts and facilities", STD | [2] Mockapetris, P., "Domain names - concepts and facilities", | |||
13, RFC 1034, November 1987. | STD 13, RFC 1034, November 1987. | |||
[3] Mockapetris, P., "Domain names - implementation and | [3] Mockapetris, P., "Domain names - implementation and | |||
specification", STD 13, RFC 1035, November 1987. | specification", STD 13, RFC 1035, November 1987. | |||
[4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic | [4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic | |||
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April | Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April | |||
1997. | 1997. | |||
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. | [5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. | |||
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", | |||
RFC 3315, July 2003. | RFC 3315, July 2003. | |||
10.2 Informative References | ||||
[6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients | [6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients | |||
(draft-ietf-dhc-ddns-resolution-*.txt)", October 2003. | (draft-ietf-dhc-ddns-resolution-*.txt)", September 2004. | |||
11.2 Informative References | ||||
[7] Stapp, M., Volz, B. and Y. Rekhter, "The DHCP Client FQDN | [7] Stapp, M., Volz, B. and Y. Rekhter, "The DHCP Client FQDN | |||
Option (draft-ietf-dhc-fqdn-option-*.txt)", July 2004. | Option (draft-ietf-dhc-fqdn-option-*.txt)", January 2005. | |||
[8] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and | [8] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and | |||
Answers - Answers to Commonly asked "New Internet User" | Answers - Answers to Commonly asked "New Internet User" | |||
Questions", RFC 1594, March 1994. | Questions", RFC 1594, March 1994. | |||
[9] Eastlake, D., "Domain Name System Security Extensions", RFC | [9] Wellington, B., "Secure Domain Name System (DNS) Dynamic | |||
2535, March 1999. | ||||
[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic | ||||
Update", RFC 3007, November 2000. | Update", RFC 3007, November 2000. | |||
[11] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS | [10] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS | |||
Extensions to Support IP Version 6", RFC 3596, October 2003. | Extensions to Support IP Version 6", RFC 3596, October 2003. | |||
[12] Narten, T. and R. Draves, "Privacy Extensions for Stateless | ||||
Address Autoconfiguration in IPv6", RFC 3041, January 2001. | ||||
Author's Address | Author's Address | |||
Bernard Volz | Bernard Volz | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
1414 Massachusetts Ave. | 1414 Massachusetts Ave. | |||
Boxborough, MA 01719 | Boxborough, MA 01719 | |||
USA | USA | |||
Phone: +1 978 936 0382 | Phone: +1 978 936 0382 | |||
EMail: volz@cisco.com | Email: volz@cisco.com | |||
Intellectual Property Statement | Intellectual Property Statement | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
skipping to change at page 12, line 41 | skipping to change at page 13, line 41 | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Copyright Statement | Copyright Statement | |||
Copyright (C) The Internet Society (2004). This document is subject | Copyright (C) The Internet Society (2005). This document is subject | |||
to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
Internet Society. | Internet Society. | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |