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/