DHC B. Volz
Internet-Draft Cisco Systems, Inc.
Expires: January 7, 2005 July 9, 2004
The DHCPv6 Client FQDN Option
draft-volz-dhc-dhcpv6-fqdn-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 January 7, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document specifies a new DHCP 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.
Volz Expires January 7, 2005 [Page 1]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
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 . . . . . . . . . . . . . . . . . . . . 7
6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8
7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 10
10.2 Informative References . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Volz Expires January 7, 2005 [Page 2]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
1. Introduction
DNS ([2], [3]) maintains (among other things) the information about
mapping between hosts' Fully Qualified Domain Names (FQDNs) [8] and
IP addresses assigned to the hosts. The information is maintained in
two types of Resource Records (RRs): AAAA and PTR [11]. 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
for an address 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 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.
Volz Expires January 7, 2005 [Page 3]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
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 to which the server binds each address.
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.
Volz Expires January 7, 2005 [Page 4]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
The Format of the DHCPv6 Client FQDN option:
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)
4.1 The Flags Field
The Format of the Flags field:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |N|O|S|
+-+-+-+-+-+-+-+-+
When a DHCPv6 client sends the Client FQDN option, it sets the "S"
bit to indicate that it will not perform any DNS updates, and that it
expects the DHCPv6 server to perform any FQDN-to-IPv6 (the AAAA RR)
DNS update on its behalf. If this bit is clear, the client indicates
that it intends to maintain its own FQDN-to-IPv6 mapping update.
If a DHCPv6 server intends to take responsibility for the AAAA RR
update, 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
FQDN option in its response message. Clients SHOULD clear the "O"
bit before sending the Client FQDN option and servers MUST ignore the
received state of the "O" bit.
Volz Expires January 7, 2005 [Page 5]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
A client MAY set the "N" bit in its request messages to indicate that
the server should not perform any DNS updates on its behalf. As
mentioned in Section 3, in general the DHCPv6 server will be
maintaining DNS PTR records on behalf of clients. However, there may
be deployments in which clients are configured to perform all desired
DNS updates or may not want any DNS updates. The server MAY be
configured to honor this configuration. If the server has been
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
assignment. DHCPv6 clients and servers which send the Client FQDN
option MUST set the MBZ bits to 0, and they MUST ignore these bits.
4.2 The Domain Name Field
The Domain Name field 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 as specified in [3]. In order to determine
whether a name 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 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
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 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
Client FQDN options.
Volz Expires January 7, 2005 [Page 6]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
5. DHCPv6 Client behavior
The following describes the behavior of a DHCPv6 client that
implements the Client FQDN option.
A client sends the Client FQDN option with no Flags bits set, the "S"
Flags bit set, or the "N" Flags bit set and with the desired partial
or fully qualified domain name.
A client MUST only include the Client FQDN option in the SOLICIT,
REQUEST, RENEW, or REBIND messages.
As a client may be assigned addresses or more addresses when sending
a REQUEST, RENEW, or REBIND message, it SHOULD include a Client FQDN
option in any IA_NA-option fields and MAY include the Client FQDN
option in IA_TA-option fields (see [12]). If it previously received
a Client FQDN option for a specific address (i.e., in the
IAaddr-options field of an IA Address option) and is including that
address in a subsequent REQUEST, RENEW, or REBIND message, it MUST
include that option in the IAaddr-options field for that address.
There is no requirement that the client send identical Client FQDN
options data in each of its messages to a server. In particular, if
a client has sent Client FQDN options 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 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 the AAAA record representing the client, to
delete that record and attempt an update for the client's current
domain name.
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 SHOULD originate
the DNS updates for the AAAA RR (associated with the client's FQDNs)
for any Client FQDN options for which the received "S" and the "O"
bits in the option's Flags field are not set and if it is otherwise
configured to perform the DNS updates. The update SHOULD be
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 that
address.
A client that delegates the responsibility for updating the FQDN to
IPv6 address mapping to a server does not receive any indication
Volz Expires January 7, 2005 [Page 7]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
(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 a binding for an address prior to the valid
lifetime expiration or is unable to extend the lifetimes for an
address and the valid lifetime expires, and the client is responsible
for updating its AAAA RRs, the client SHOULD delete the AAAA RR
associated with the address before sending a RELEASE message or the
lifetime expires. 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 exceeds
retry intervals) should attempt to notify its administrator, perhaps
by emitting a log message.
6. DHCPv6 Server Behavior
Servers MUST only include Client FQDN options in ADVERTISE and REPLY
messages if received in the client's message to which it is
responding. Servers MUST only include Client FQDN options in the
IAaddr-options field of IA Address options in messages sent by the
server.
When a server allocates a new address to an IA, it uses the Client
FQDN option, if any, in the IA_NA-options or IA_TA-options field of
that IA to negotiate the fully qualified domain name and who will
take responsibility for the DNS updates. It records the results in
the Client FQDN in the IAaddr-options field of the IA Address option
for that address. 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 field from the Client FQDN option
that the client sent to the server. The DHCPv6 server MAY be
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
include the Client FQDN option for an IA (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 an address
and the requested domain-name is different from the server's current
knowledge of the fully-qualified domain name and the server is
configured to allow use of that name, the server SHOULD perform the
necessary DNS updates - the server SHOULD remove the old PTR and AAAA
RRs it added, if any, and SHOULD add the new RRs if it has that
responsibility.
Volz Expires January 7, 2005 [Page 8]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
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 which it associated with the address via DNS update. In
addition, if the server took responsibility for the AAAA RR, the
server SHOULD also delete that 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 who will perform the DNS updates and the fully
qualified domain name requested or used.
Implementers of this work will need to consider how name conflicts
will be prevented. It may be that the DNS updater must hold 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, the
fully qualified domains may be based on the specific address bound to
a client or the client's DUID, and in these cases conflicts should
not occur. However, without this level of security in the DNS system
or use of non-conflicting names, other techniques need to be
developed. This is an area for future work (see [6]).
8. Security Considerations
Unauthenticated updates to the DNS can lead to tremendous confusion,
through malicious attack or through inadvertent misconfiguration.
Administrators should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCPv6 clients
Volz Expires January 7, 2005 [Page 9]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
and servers SHOULD use some form of update request origin
authentication procedure (e.g., Secure DNS Dynamic Update [10]) when
performing DNS updates.
Whether a DHCPv6 client may be 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 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 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 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 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.
9. Acknowledgements
Many thanks to Mark Stapp and Yakov Rekhter as this document is based
on draft-ietf-dhc-fqdn-option [7]. And, to Mark Stapp, Josh
Littlefield, Kim Kinnear, and Ralph Droms for discussions on this
option for DHCPv6 and on reviewing early copies of the draft.
10. References
10.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.
Volz Expires January 7, 2005 [Page 10]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
[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.
[7] Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option
(draft-ietf-dhc-fqdn-option-*.txt)", October 2003.
[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] 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: volz@cisco.com
Volz Expires January 7, 2005 [Page 11]
Internet-Draft The DHCPv6 Client FQDN Option July 2004
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 Statement
Copyright (C) The Internet Society (2004). 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.
Volz Expires January 7, 2005 [Page 12]