wdiff draft-ietf-dhc-dhcpv6-fqdn-00.txt draft-ietf-dhc-dhcpv6-fqdn-01.txt

DHC B. Volz
Internet-Draft Cisco Systems, Inc.
Expires: March 17, July 29, 2005 January 25, 2005 September 16, 2004

The DHCPv6 Client FQDN Option
draft-ietf-dhc-dhcpv6-fqdn-00.txt
draft-ietf-dhc-dhcpv6-fqdn-01.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section Section 3 of RFC 3667. By submitting this Internet-Draft, each
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 become aware will be disclosed, in accordance with
RFC 3668.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on March 17, July 29, 2005.

Abstract

This document specifies a new DHCP Dynamic Host Configuration Protocol for
IPv6, DHCPv6, option which can be used to exchange information about
a DHCPv6 client's fully-qualified domain name and about
responsibility for updating DNS RRs related to the client's address
assignments.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Models of Operation . . . . . . . . . . . . . . . . . . . . . 3
4. The DHCPv6 Client FQDN Option . . . . . . . . . . . . . . . . 4
4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5
4.2 The Domain Name Field . . . . . . . . . . . . . . . . . . 6
5. DHCPv6 Client behavior Behavior . . . . . . . . . . . . . . . . . . . 6
5.1 Client Desires to Update AAAA RRs . . . . . . . . . . . . 7
5.2 Client Desires Server to Do DNS Updates . . . . . . . . . 7
5.3 Client Desires No Server DNS Updates . . . . . . . . . . . 7
5.4 Domain Name and DNS Update Issues . . . . . . . . . . . . 8
6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8
6.1 When to Perform DNS Updates . . . . . . . . . . . . . . . 9
7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 9 10
8. Security IANA Considerations . . . . . . . . . . . . . . . . . . . 9 . 10
9. Acknowledgements Security Considerations . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . 10
10. . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1 11
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
10.2 11
11.2 Informative References . . . . . . . . . . . . . . . . . . . 11 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 12
Intellectual Property and Copyright Statements . . . . . . . . 12 13

1. Introduction

DNS ([2], [3]) maintains (among other things) the information about
mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] and
IP
IPv6 addresses assigned to the hosts. The information is maintained
in two types of Resource Records (RRs): AAAA and PTR [11]. [10]. The DNS
update specification ([4]) describes a mechanism that enables DNS
information to be updated over a network.

The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5]
provides a mechanism by which a host (a DHCPv6 client) can acquire
certain configuration information, along with its stateful IPv6
address(es). This document specifies a new DHCPv6 option, the Client
FQDN option, which can be used by DHCPv6 clients and servers to
exchange information about the client's fully-qualified domain name
and who has the responsibility for updating the DNS with the
associated AAAA and PTR RRs.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].

Familiarity with the DNS Update protocol [4], DHCPv6, and DHCPv6
terminology as defined in [5] is assumed.

3. Models of Operation

When a DHCPv6 client acquires an address, a site's administrator may
desire that the AAAA RR for the client's FQDN and the PTR RR for the
acquired address be updated. Therefore, two separate DNS update
transactions may occur. Acquiring an address via DHCPv6 involves two
entities: a DHCPv6 client and a DHCPv6 server. In principle each of
these entities could perform none, one, or both of the DNS update
transactions. However, in practice not all permutations make sense.
The DHCPv6 Client FQDN option is primarily intended to operate in the
following two cases:

1. DHCPv6 client updates the AAAA RR, DHCPv6 server updates the PTR
RR
2. DHCPv6 server updates both the AAAA and the PTR RRs

The only difference between these two cases is whether the FQDN to
IPv6 address mapping is updated by a DHCPv6 client or by a DHCPv6
server. The IPv6 address to FQDN mapping is updated by a DHCPv6
server in both cases.

The reason these two are important, while others are unlikely, has to
do with authority over the respective DNS domain names. A DHCPv6
client may be given authority over mapping its own AAAA RRs, or that
authority may be restricted to a server to prevent the client from
listing arbitrary addresses or associating its addresses with
arbitrary domain names. In all cases, the only reasonable place for
the authority over the PTR RRs associated with the address is in the
DHCPv6 server that allocates the address.

Note: A third case is supported - the client requests that the server
perform no updates. However, this case is presumed to be rare
because of the authority issues.

In any case, whether a site permits all, some, or no DHCPv6 servers
and clients to perform DNS updates into the zones which it controls
is entirely a matter of local administrative policy. This document
does not require any specific administrative policy, and does not
propose one. The range of possible policies is very broad, from
sites where only the DHCPv6 servers have been given credentials that
the DNS servers will accept, to sites where each individual DHCPv6
client has been configured with credentials which allow the client to
modify its own domain name. Compliant implementations MAY support
some or all of these possibilities. Furthermore, this specification
applies only to DHCPv6 client and server processes: it does not apply
to other processes which initiate DNS updates.

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.
Site-specific policy determines whether DHCPv6 servers use the names
that clients offer or not, and what DHCPv6 servers may do in cases where
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

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. for the client's IA_NA
bindings. To allow the client to convey its FQDN to the server this
document defines a new DHCPv6 option, called "Client FQDN". The
Client FQDN option also contains Flags which DHCPv6 clients and
servers use to negotiate who does which updates.

The code for this option is TBD. Its minimum length is 2. 1 octet.

The Format format of the DHCPv6 Client FQDN option is shown below:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_FQDN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | |
+-+-+-+-+-+-+-+-+ |
. .
. domain-name .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code OPTION_CLIENT_FQDN (TBD)

option-len 1 + length of domain name

flags flag bits used between client and server to
negotiate who performs which updates

domain-name the partial or fully qualified domain name
(with length option-len - 1)

The Client FQDN option MUST only appear in IA_NA-options and
IA_TA-options (see [12]) fields a message's options field
and applies to all addresses for that
binding. all IA_NA bindings in the
transaction.

4.1 The Flags Field

The Format format of the Flags field: field is:

0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |N|O|S|
+-+-+-+-+-+-+-+-+

When a DHCPv6 client sends

The "S" bit indicates whether the Client FQDN option, it server SHOULD or SHOULD NOT perform
the AAAA RR (FQDN to address) DNS updates. A client sets the "S" bit to
0 to indicate that it will not the server SHOULD NOT perform any DNS updates, the updates and that it
expects 1 to
indicate the DHCPv6 server to SHOULD perform any FQDN-to-IPv6 (the AAAA RR)
DNS updates on its behalf. If this the updates. The state of the bit is clear,
in the client reply from the server indicates that it intends the action to perform be taken by the
server; if 1, the FQDN-to-IPv6 DNS updates.

If a DHCPv6 server intends to take has taken responsibility for the AAAA RR
updates, whether or not the client sending the Client FQDN option has
set the "S" bit, it sets both the "O" and "S" bits, and sends the
Client FQDN option in its response message. Clients SHOULD clear updates
for the FQDN.

The "O" bit before sending indicates whether the Client FQDN option and servers MUST ignore server has overridden the received state of client's
preference for the "O" "S" bit. A client MAY MUST set this bit to 0. A
server MUST set this bit to 1 if the "N" "S" bit in its request messages reply to indicate that the server should
client does not match the "S" bit received from the client.

The "N" bit indicates whether the server SHOULD NOT perform any DNS updates on its behalf. As
mentioned in Section 3, in general
updates. A client sets this bit to 0 to request that the DHCPv6 server will be
maintaining DNS
SHOULD perform updates (the PTR records RR and possibly the AAAA RR based on behalf of clients. However, there may
be deployments in which clients are configured
the "S" bit) or to 1 to request that the server SHOULD NOT perform all desired
DNS updates or may not want
any DNS updates. The server MAY be
configured to honor this configuration. If the A server has been
configured to honor a client's "N" indication, it SHOULD set sets the "N" bit in Client FQDN options which it sends to indicate whether the client in its
response messages. Clients which have set
server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N"
bit in their
requests SHOULD use the state of is 1, the "N" "S" 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 MUST be 0.

The remaining bits in the Flags field are reserved for future
assignment. DHCPv6 clients and servers which send the Client FQDN
option MUST set clear the MBZ bits to 0, bits, and they MUST ignore these bits.

4.2 The Domain Name Field

The Domain Name field part of the option carries all or part of the FQDN of
a DHCPv6 client. The data in the Domain Name field MUST appear in
uncompressed DNS encoding be encoded
as specified described in [3]. Section 8 of [5]. In order to determine whether a name the
FQDN has changed between message exchanges, an unambiguous
canonical form is necessary. Eventually, the IETF IDN Working Group
is expected to produce a standard canonicalization specification, and
this specification may be updated to include its standard. Until
that time, servers client and clients should be sensitive to
canonicalization when comparing names in server
MUST NOT alter the Domain Name field and contents unless the name canonicalization defined in [9] MAY be used. FQDN has
actually changed.

A client may MAY be configured with a fully-qualified domain name, name or with
a partial name that is not fully-qualified. If a client knows only
part of its name, it MAY send a name that is not fully-qualified,
indicating that it knows part of the name but does not necessarily
know the zone in which the name is to be embedded. A
client which wants to convey part of its FQDN sends

To send a non-terminal
sequence of labels in fully-qualified domain name, the Domain Name field is set
to the DNS encoded domain name field of including the option. Clients
and servers should assume that 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 contains empty if it desires the
server to provide a
fully-qualified name unless this partial-name format exists. name.

Servers MUST always SHOULD send the complete fully-qualified domain name in
Client FQDN options.

5. DHCPv6 Client behavior Behavior

The following describes the behavior of a DHCPv6 client that
implements the Client FQDN option.

A client MUST only include the Client FQDN options in the IA_NA-options
and IA_TA-options fields option in SOLICIT,
REQUEST, RENEW, or REBIND messages.

A client that sends the Client FQDN option MUST also include the
option in the Option Request option if it expects the server to
include the Client FQDN option in any responses.

A client sends the

5.1 Client Desires to Update AAAA RRs

If a client that owns/maintains its own FQDN option with no Flags bits set, wants to be responsible
for updating the "S"
Flags bit set, or FQDN to IPv6 address mapping for the "N" Flags bit set FQDN and with
address(es) used by the desired partial
or fully qualified domain name.

There is no requirement that client, the client send identical Client FQDN
options data in each of its messages to a server. In particular, if
a client has sent MUST include the Client
FQDN options to its server, and option in the
configuration of SOLICIT with Rapid Commit, REQUEST, RENEW, and
REBIND message originated by the client. A client changes so that its notion of its domain
name changes, it MAY send choose to
include the new name data in a Client FQDN options
when it communicates with the server again. This may cause the
DHCPv6 server to update the name associated with the PTR record, and,
if the server updated option in its SOLICIT messages. The "S" bit
in the AAAA record representing Flags field in the client, to
delete that record option MUST be 0. The "O" and attempt an update for the client's current
domain name. "N" bits
MUST be 0.

Once the client's DHCPv6 configuration is completed (the client
receives a REPLY message, message and successfully completes a final check on
the parameters passed in the message), the client SHOULD MAY originate
the DNS updates an
update for the AAAA RR RRs (associated with the client's FQDNs)
for any Client FQDN options for which the received "S" and the "O"
bits in FQDN) unless
the option's Flags field are not server has set and if it is otherwise
configured to perform the DNS updates. The update SHOULD be
originated following the procedures described in [4]. "S" bit to 1. 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, is 1, the DHCPv6
client MUST NOT initiate an update for the name in the Domain Name field and the
addresses in that binding.
field.

5.2 Client Desires Server to Do DNS Updates

A client that delegates can choose to delegate the responsibility for updating the
FQDN-to-IPv6
FQDN to IPv6 address mapping to a server does not receive any
indication (either positive or negative) from for the server whether FQDN and address(es) used by the
server was able
client to perform the update. If the client needs server. 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 message and MAY include the
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.

5.3 Client Desires No Server 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
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
confirm delete that record and attempt an update for the DNS update, it SHOULD 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 updated. 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 valid lifetime expiration or is unable to extend the lifetimes for an address and of the valid
lifetime expires, and the client is responsible for updating its AAAA RRs, RR, the
client SHOULD delete the AAAA RR associated with the address before
sending a RELEASE message or 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 expires. on the address is no longer valid. A DHCPv6 client which
has not been able to delete an AAAA RR which it added (because it has lost the use of addresses
of sufficient scope to communicate with the DNS server or has
exhausted retry limits) should SHOULD attempt
to notify its administrator, perhaps by emitting a log message.

6. DHCPv6 Server Behavior

The following describes the behavior of a DHCPv6 server that
implements the Client FQDN option when the client's message includes
the Client FQDN option.

Servers MUST only include a Client FQDN options for a binding option in ADVERTISE and REPLY
messages if the client included a Client FQDN option for that binding and the Client FQDN Client
FQDN option is requested by the Option Request Option in the client's
message to which the server is responding.

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 is requested by it will return to the Option Request Option in client.
o If the client's message "N" bit is 1 and the server's configuration allows
it to which honor the client's request for no server
is responding. Servers MUST only include Client FQDN options in the
IA_NA-options and IA_TA-options fields in messages sent by initiated DNS
updates, the
server.

When a server allocates a new address from a binding, it uses sets the
Client FQDN option, "N" bit to 1.
o Otherwise, if any, in the IA_NA-options or IA_TA-options
field of that binding client's "S" bit is 1 and the servers's
configuration allows it to determine honor the fully qualified domain name
and who will take responsibility client's request for the
server to initiate AAAA RR DNS updates. It records 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
results name supplied in the client's
Client FQDN option. option, or it MAY be configured to modify the supplied
name, or substitute a different name. The DHCPv6 server SHOULD send its
notion of the complete FQDN for the client in the Domain Name field.
The server MAY simply copy the Domain Name Domain Name field from the Client FQDN
option that the client sent to the server.

6.1 When to Perform DNS Updates

The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in
the Flags field of the Client FQDN option in the REPLY messages (to
be) sent to the client. However, the server SHOULD delete any RRs
which it previously added via DNS updates for the client.

The server MAY perform the PTR RR DNS update (unless the "N" bit is
1).

The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in
the Flags field from of the Client FQDN option that in the client DHCPACK message (to
be) sent to the server. client.

The DHCPv6 server MAY be
configured to complete or modify perform these updates even if 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
include did
not carry the Client FQDN option for a binding (e.g., option. The server MUST NOT initiate DNS
updates when responding with an ADVERTISE message to the client
doesn't implement client.

The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR)
before the Client FQDN option), server sends the REPLY message to the client.
Alternatively, the server MAY be
configured send the REPLY message to the client
without waiting for the update to be completed. Whether the DNS
update either occurs before or both of after the AAAA and PTR RRs. REPLY is sent is entirely up to the
DHCPv6 server's configuration.

If a client's message includes a Client FQDN option for a binding and the requested domain-name is different from server's AAAA RR DNS update does not complete until after the
server has replied to the DHCPv6 client, the server's current
knowledge of interaction
with the DNS server MAY cause the DHCPv6 server to change the fully-qualified domain
name and that it associates with the client. This can occur, for
example, if the server is
configured to allow use of detects and resolves a domain-name conflict
[6]. In such cases, the domain name that name, the server SHOULD perform returns to the
necessary DNS updates -
DHCPv6 client would change between two DHCPv6 exchanges.

If the server SHOULD remove previously performed DNS updates for the old PTR and AAAA
RRs it added, if any, client and add the new RRs - if it
client's information has that
responsibility. not changed, the server MAY skip performing
additional DNS updates.

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
client has expired, or terminates a binding on an address prior to
the binding's expiration time (for instance, by sending a REPLY with
a zero valid lifetime for an address), the server SHOULD delete any
PTR RRs RR which it associated with the address via DNS update. In
addition, if the server took responsibility for the AAAA RR, RRs, the server
SHOULD also delete that 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

This document does not resolve how a DHCPv6 client or server prevent
name conflicts. This document addresses only how a DHCPv6 client and
server negotiate the fully qualified domain name and who will perform
the DNS updates.

Implementers of this work will need to consider how name conflicts
will be prevented. It may be that the If a DNS updater must hold needs a security token in order
to successfully perform DNS updates on a specific name, in which case name
conflicts can only occur if multiple clients are given a security
token for that name. Or, if the fully qualified domains may be are based on
the specific address bound to a client or the client's DUID, and in these cases client, conflicts should
not SHOULD NOT occur. However, without this level of security
Or, a name conflict resolution technique as described in the DNS system
or use of non-conflicting names, other techniques need to "Resolving
Name Conflicts" [6]) SHOULD be
developed. This used.

8. IANA Considerations

IANA is an area requested to assign a DHCPv6 option code for future work (see [6]).

8. the Client FQDN
option.

9. Security Considerations

Unauthenticated updates to the DNS can lead to tremendous confusion,
through malicious attack or through inadvertent misconfiguration.
Administrators should need to be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCPv6 clients
and servers SHOULD use some form of update request origin
authentication procedure (e.g., Secure DNS Dynamic Update [10]) [9]) when
performing DNS updates.

Whether a DHCPv6 client may be is responsible for updating an FQDN to IPv6
address mapping or whether this is the responsibility of the DHCPv6
server is a site-local matter. The choice between the two
alternatives may be is likely based on the security model that is used with
the DNS update protocol (e.g., only a client may have sufficient
credentials to perform updates to the FQDN to IP IPv6 address mapping
for its FQDN).

Whether a DHCPv6 server is always responsible for updating the FQDN
to IPv6 address mapping (in addition to updating the IPv6 to FQDN
mapping), regardless of the wishes of an individual DHCPv6 client, is
also a site-local matter. The choice between the two alternatives
may be is
likely based on the security model that is being used with DNS
updates. In cases where a DHCPv6 server is performing DNS updates on
behalf of a client, the DHCPv6 server should SHOULD be sure of the DNS name
to use for the client, and of the identity of the client.

Depending on the prescence of or type of authentication used with the
Authentication option, a DHCPv6 server may not have much confidence
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
circumstances will the DHCPv6 server know for certain the identity of
the client.

10. Acknowledgements

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]).
And, to Ted Lemon, Mark Stapp, Josh Littlefield, Kim Kinnear, and
Ralph Droms for discussions on this work.

10.

11. References

10.1

11.1 Normative References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[2] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.

[3] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[4] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997.

[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.

10.2 Informative References

[6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients
(draft-ietf-dhc-ddns-resolution-*.txt)", October 2003. September 2004.

11.2 Informative References

[7] Stapp, M., Volz, B. and Y. Rekhter, "The DHCP Client FQDN
Option (draft-ietf-dhc-fqdn-option-*.txt)", July 2004. January 2005.

[8] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and
Answers - Answers to Commonly asked "New Internet User"
Questions", RFC 1594, March 1994.

[9] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.

[10] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.

[11]

[10] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
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

Bernard Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA

Phone: +1 978 936 0382
EMail:
Email: volz@cisco.com

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright (C) The Internet Society (2004). (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.