draft-ietf-dhc-fqdn-option-06.txt   draft-ietf-dhc-fqdn-option-07.txt 
DHC Working Group M. Stapp DHC M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft B. Volz
Expires: April 26, 2004 Y. Rekhter Expires: January 14, 2005 Cisco Systems, Inc.
Y. Rekhter
Juniper Networks Juniper Networks
October 27, 2003 Jul 16, 2004
The DHCP Client FQDN Option The DHCP Client FQDN Option
<draft-ietf-dhc-fqdn-option-06.txt> <draft-ietf-dhc-fqdn-option-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of 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 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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
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://
http://www.ietf.org/ietf/1id-abstracts.txt. 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 April 26, 2004. This Internet-Draft will expire on January 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
DHCP provides a powerful mechanism for IP host configuration. This document specifies a DHCP for IPv4, DHCPv4, option which can be
However, the configuration capability provided by DHCP does not used to exchange information about a DHCPv4 client's fully-qualified
include updating DNS, and specifically updating the name to address domain name and about responsibility for updating the DNS RR related
and address to name mappings maintained in the DNS. to the client's address assignment.
This document specifies a DHCP option which can be used to exchange
information about a DHCP client's fully-qualified domain name, and
about responsibility for updating DNS RRs related to the client's
DHCP lease.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Models of Operation . . . . . . . . . . . . . . . . . . . . 3 3. Models of Operation . . . . . . . . . . . . . . . . . . . . . 3
4. The Client FQDN Option . . . . . . . . . . . . . . . . . . . 4 4. The Client FQDN Option . . . . . . . . . . . . . . . . . . . . 4
4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 5 4.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . 5
4.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . . 6 4.2 The RCODE Fields . . . . . . . . . . . . . . . . . . . . . 6
4.3 The Domain Name Field . . . . . . . . . . . . . . . . . . . 6 4.3 The Domain Name Field . . . . . . . . . . . . . . . . . . 6
4.3.1 Deprecated ASCII Encoding . . . . . . . . . . . . . . . . . 7 4.3.1 Deprecated ASCII Encoding . . . . . . . . . . . . . . 7
5. DHCP Client behavior . . . . . . . . . . . . . . . . . . . . 7 5. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 7
6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 9 6. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . 11 7. DNS Update Conflicts . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . 15 10.2 Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
1. Terminology 1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119[1]. document are to be interpreted as described in RFC 2119[1].
2. Introduction 2. Introduction
DNS (RFC 1034[2], RFC 1035[3]) maintains (among other things) the DNS ([2], [3]) maintains (among other things) the information about
information about mapping between hosts' Fully Qualified Domain mapping between hosts' Fully Qualified Domain Names (FQDNs) [6] and
Names (FQDNs)[7] and IP addresses assigned to the hosts. The IP addresses assigned to the hosts. The information is maintained in
information is maintained in two types of Resource Records (RRs): A two types of Resource Records (RRs): A and PTR. The DNS update
and PTR. The A RR contains mapping from a FQDN to an IP address; the specification ([4]) describes a mechanism that enables DNS
PTR RR contains mapping from an IP address to a FQDN. The DNS information to be updated over a network.
update specification (RFC 2136[4]) describes a mechanism that
enables DNS information to be updated over a network.
DHCP[5] provides a mechanism by which a host (a DHCP client) can
acquire certain configuration information, along with its IP
address(es). However, DHCP does not provide any mechanisms to update
the DNS RRs that contain the information about mapping between the
host's FQDN and its IP address(es) (A and PTR RRs). Thus DNS
information for a DHCP client may not exist or may be incorrect - a
host (the client) could acquire its address by using DHCP, but the A
RR for the host's FQDN wouldn't reflect the address that the host
acquired, and the PTR RR for the acquired address wouldn't reflect
the host's FQDN.
The DNS Update protocol can be used to maintain consistency between
the information stored in the A and PTR RRs and the actual address
assignment done via DHCP. When a host with a particular FQDN
acquires its IP address via DHCP, the A RR associated with the
host's FQDN would be updated (by using the DNS Update protocol) to
reflect the new address. Likewise, when an IP address is assigned to
a host with a particular FQDN, the PTR RR associated with this
address would be updated (using the DNS Update protocol) to reflect
the new FQDN.
Although this document refers to the A and PTR DNS record types and The Dynamic Host Configuration Protocol for IPv4 (DHCPv4 or just DHCP
to DHCP assignment of IPv4 addresses, the same procedures and in this document) [5] provides a mechanism by which a host (a DHCP
requirements apply for updates to the analogous RR types that are client) can acquire certain configuration information, along with its
used when clients are assigned IPv6 addresses via DHCPv6. address. This document specifies a DHCP option, the Client FQDN
option, which can be used by DHCP 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 A and PTR RRs.
3. Models of Operation 3. Models of Operation
When a DHCP client acquires a new address, a site's administrator When a DHCP client acquires a new address, a site's administrator may
may desire that one or both of the A RR for the client's FQDN and desire that one or both of the A RR for the client's FQDN and the PTR
the PTR RR for the acquired address be updated. Therefore, two RR for the acquired address be updated. Therefore, two separate DNS
separate DNS update transactions may occur. Acquiring an address via update transactions may occur. Acquiring an address via DHCP
DHCP involves two entities: a DHCP client and a DHCP server. In involves two entities: a DHCP client and a DHCP server. In principle
principle each of these entities could perform none, one, or both of each of these entities could perform none, one, or both of the
the transactions. However, in practice not all permutations make transactions. However, in practice not all permutations make sense.
sense. The DHCP client FQDN option is intended to operate in the The DHCP Client FQDN option is intended to operate in the following
following two cases: two cases:
1. DHCP client updates the A RR, DHCP server updates the PTR RR 1. DHCP client updates the A RR, DHCP server updates the PTR RR
2. DHCP server updates both the A and the PTR RRs 2. DHCP server updates both the A and the PTR RRs
The only difference between these two cases is whether the FQDN to The only difference between these two cases is whether the FQDN to IP
IP address mapping is updated by a DHCP client or by a DHCP server. address mapping is updated by a DHCP client or by a DHCP server. The
The IP address to FQDN mapping is updated by a DHCP server in both IP address to FQDN mapping is updated by a DHCP server in both cases.
cases.
The reason these two are important, while others are unlikely, has The reason these two are important, while others are unlikely, has to
to do with authority over the respective DNS domain names. A DHCP do with authority over the respective DNS domain names. A DHCP
client may be given authority over mapping its own A RRs, or that client may be given authority over mapping its own A RRs, or that
authority may be restricted to a server to prevent the client from authority may be restricted to a server to prevent the client from
listing arbitrary addresses or associating its address with listing arbitrary addresses or associating its address with arbitrary
arbitrary domain names. In all cases, the only reasonable place for domain names. In all cases, the only reasonable place for the
the authority over the PTR RRs associated with the address is in the authority over the PTR RRs associated with the address is in the DHCP
DHCP server that allocates the address. server that allocates the address.
In any case, whether a site permits all, some, or no DHCP servers In any case, whether a site permits all, some, or no DHCP servers and
and clients to perform DNS updates into the zones which it controls clients to perform DNS updates into the zones which it controls is
is entirely a matter of local administrative policy. This document entirely a matter of local administrative policy. This document does
does not require any specific administrative policy, and does not not require any specific administrative policy, and does not propose
propose one. The range of possible policies is very broad, from one. The range of possible policies is very broad, from sites where
sites where only the DHCP servers have been given credentials that only the DHCP servers have been given credentials that the DNS
the DNS servers will accept, to sites where each individual DHCP servers will accept, to sites where each individual DHCP client has
client has been configured with credentials which allow the client been configured with credentials which allow the client to modify its
to modify its own domain name. Compliant implementations MAY support own domain name. Compliant implementations MAY support some or all
some or all of these possibilities. Furthermore, this specification of these possibilities. Furthermore, this specification applies only
applies only to DHCP client and server processes: it does not apply to DHCP client and server processes: it does not apply to other
to other processes which initiate DNS updates. processes which initiate DNS updates.
This document describes a new DHCP option which a client can use to This document describes a new DHCP option which a client can use to
convey all or part of its domain name to a DHCP server. convey all or part of its domain name to a DHCP server.
Site-specific policy determines whether DHCP servers use the names Site-specific policy determines whether DHCP servers use the names
that clients offer or not, and what DHCP servers may do in cases that clients offer or not, and what DHCP servers may do in cases
where clients do not supply domain names. Another document, where clients do not supply domain names.
"Resolving Name Conflicts"[6], defines a protocol for establishing
policy and arbitrating conflicts when collisions occur in the use of
FQDNs by DHCP clients.
4. The Client FQDN Option 4. The Client FQDN Option
To update the IP address to FQDN mapping a DHCP server needs to know To update the IP address to FQDN mapping a DHCP server needs to know
the FQDN of the client to which the server leases the address. To the FQDN of the client to which the server leases the address. To
allow the client to convey its FQDN to the server this document allow the client to convey its FQDN to the server this document
defines a new DHCP option, called "Client FQDN". The FQDN Option defines a new DHCP option, called "Client FQDN". The Client FQDN
also contains Flags and RCode fields which DHCP servers can use to option also contains Flags and RCODE fields which DHCP servers can
convey information about DNS updates to clients. use to convey information about DNS updates to clients.
Clients MAY send the FQDN option, setting appropriate Flags values, Clients MAY send the Client FQDN option, setting appropriate Flags
in both their DISCOVER and REQUEST messages. If a client sends the values, in both their DISCOVER and REQUEST messages. If a client
FQDN option in its DISCOVER message, it MUST send the option in sends the Client FQDN option in its DISCOVER message, it MUST send
subsequent REQUEST messages. the option in subsequent REQUEST messages.
The code for this option is 81. Its minimum length is 4. The code for this option is 81. Its minimum length is 4.
The Format of the FQDN Option: The Format of the Client FQDN Option:
Code Len Flags RCODE1 RCODE2 Domain Name Code Len Flags RCODE1 RCODE2 Domain Name
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
| 81 | n | | | | ... | 81 | n | | | | ...
+------+------+------+------+------+------+-- +------+------+------+------+------+------+--
4.1 The Flags Field 4.1 The Flags Field
The Format of the Flags Field: The Format of the Flags Field:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| MBZ |N|E|O|S| | MBZ |N|E|O|S|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
When a DHCP client sends the FQDN option in its DHCPDISCOVER and/or When a DHCP client sends the Client FQDN option in its DHCPDISCOVER
DHCPREQUEST messages, it sets the least-significant bit (labelled and/or DHCPREQUEST messages, it sets the "S" bit to indicate that it
"S") to indicate that it will not perform any DNS updates, and that will not perform any DNS updates, and that it expects the DHCP server
it expects the DHCP server to perform any FQDN-to-IP (the A RR) DNS to perform any FQDN-to-IP (the A RR) DNS update on its behalf. If
update on its behalf. If this bit is clear, the client indicates this bit is clear, the client indicates that it intends to maintain
that it intends to maintain its own FQDN-to-IP mapping update. its own FQDN-to-IP mapping update.
If a DHCP server intends to take responsibility for the A RR update If a DHCP server intends to take responsibility for the A RR update
whether or not the client sending the FQDN option has set the "S" whether or not the client sending the Client FQDN option has set the
bit, it sets both the "O" bit and the "S" bit, and sends the FQDN "S" bit, it sets both the "O" bit and the "S" bit, and sends the
option in its DHCPOFFER and/or DHCPACK messages. Client FQDN option in its DHCPOFFER and/or DHCPACK messages.
The data in the Domain Name field SHOULD appear in DNS-style binary The data in the Domain Name field SHOULD appear in DNS-style binary
encoding (without compression, of course), as described in RFC encoding (without compression, of course), as described in RFC 1035
1035[3]. A client which sends the FQDN option SHOULD use this [3]. A client which sends the Client FQDN option SHOULD use this
encoding. The client MUST set the "E" bit when the data in the encoding. The client MUST set the "E" bit when the data in the
Domain Name field is in DNS binary encoding. If a server receives an Domain Name field is in DNS binary encoding. If a server receives a
FQDN option from a client, and intends to include an FQDN option in Client FQDN option from a client, and intends to include a Client
its reply, it MUST use the same encoding that the client used, and FQDN option in its reply, it MUST use the same encoding that the
MUST set the "E" bit accordingly. client used, and MUST set the "E" bit accordingly.
Server implementors should note that earlier draft versions of this Server implementers should note that earlier draft versions of this
specification permitted an ASCII encoding of the domain name. specification permitted an ASCII encoding of the domain name.
Clients which implemented this encoding were deployed before this Clients which implemented this encoding were deployed before this
specification was completed. Server implementors which need to specification was completed. Server implementers which need to
support these clients should note the section on the deprecated support these clients should note the section on the deprecated ASCII
ASCII encoding (Section 4.3.1). encoding (Section 4.3.1).
A client MAY set the "N" flag in its request messages to indicate A client MAY set the "N" bit in its request messages to indicate that
that the server should not perform any DNS updates on its behalf. As the server should not perform any DNS updates on its behalf. As we
we mentioned in Section 3, we believe that in general the DHCP mentioned in Section 3, we believe that in general the DHCP server
server will be maintaining DNS PTR records on behalf of clients. will be maintaining DNS PTR records on behalf of clients. However,
However, there may be deployments in which clients are configured to there may be deployments in which clients are configured to perform
perform all desired DNS updates. The server MAY be configured to all desired DNS updates. The server MAY be configured to honor this
honor this configuration. If the server has been configured to honor configuration. If the server has been configured to honor a client's
a client's "N" indication, it SHOULD set the "N" bit in fqdn options "N" indication, it SHOULD set the "N" bit in Client FQDN options
which it sends to the client in its OFFER or ACK messages. Clients which it sends to the client in its OFFER or ACK messages. Clients
which have set the "N" bit in their requests SHOULD use the state of 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 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 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 "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 server was not configured to honor the client's suggestion, and that
the server may attempt to perform DNS updates on its behalf. 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. DHCP clients and servers which send the FQDN option MUST assignment. DHCP clients and servers which send the Client FQDN
set the MBZ bits to 0, and they MUST ignore values in the part of option MUST set the MBZ bits to 0, and they MUST ignore these bits.
the field labelled "MBZ".
4.2 The RCODE Fields 4.2 The RCODE Fields
The RCODE1 and RCODE2 fields are used by a DHCP server to indicate The RCODE1 and RCODE2 fields are used by a DHCP server to indicate to
to a DHCP client the Response Code from any A or PTR RR DNS updates a DHCP client the Response Code from any A or PTR RR DNS updates it
it has performed. The server may also use these fields to indicate has performed. The server may also use these fields to indicate
whether it has attempted such an update before sending the DHCPACK whether it has attempted such an update before sending the DHCPACK
message. Each of these fields is one byte long. message. Each of these fields is one byte long.
Implementors should note that EDNS0 describes a mechanism for Implementers should note that EDNS0 describes a mechanism for
extending the length of a DNS RCODE to 12 bits. EDNS0 is specified extending the length of a DNS RCODE to 12 bits. EDNS0 is specified
in RFC 2671[8]. Only the least-significant 8 bits of the RCODE from in RFC 2671 [7]. Only the least-significant 8 bits of the RCODE from
a DNS update will be carried in the Client FQDN DHCP Option. This a DNS update will be carried in the Client FQDN option. This
provides enough number space to accomodate the RCODEs defined in the provides enough number space to accommodate the RCODEs defined in the
DNS update specification. DNS update specification.
4.3 The Domain Name Field 4.3 The Domain Name Field
The Domain Name part 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 DHCP client. The data in the Domain Name field SHOULD appear in a DHCP client. The data in the Domain Name field SHOULD appear in
uncompressed DNS encoding as specified in RFC 1035[3]. If the DHCP uncompressed DNS encoding as specified in RFC 1035[3]. If the DHCP
client uses DNS encoding, it MUST set the third bit in the Flags client uses DNS encoding, it MUST set the third bit in the Flags
field (the "E" bit). In order to determine whether a name has field (the "E" bit). In order to determine whether a name has
changed between message exchanges, an unambiguous canonical form is changed between message exchanges, an unambiguous canonical form is
necessary. Eventually, the IETF IDN Working Group is expected to necessary. Eventually, the IETF IDN Working Group is expected to
produce a standard canonicalization specification, and this produce a standard canonicalization specification, and this
specification may be updated to include its standard. Until that specification may be updated to include its standard. Until that
time, servers and clients should be sensitive to canonicalization time, servers and clients should be sensitive to canonicalization
when comparing names in the Domain Name field and the name when comparing names in the Domain Name field and the name
canonicalization defined in RFC 2535[11] MAY be used. canonicalization defined in RFC 2535 [10] 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 a partial name that is not fully-qualified. If a client knows 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 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 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 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 client which wants to convey part of its FQDN sends a non-terminal
sequence of labels in the Domain Name part of the option. Clients sequence of labels in the Domain Name part of the option. Clients
and servers should assume that the the name field contains a and servers should assume that the name field contains a
fully-qualified name unless this partial-name format exists. fully-qualified name unless this partial-name format exists.
4.3.1 Deprecated ASCII Encoding 4.3.1 Deprecated ASCII Encoding
The DNS encoding specified above MUST be supported by DHCP servers. The DNS encoding specified above MUST be supported by DHCP servers.
However, a substantial population of clients implemented an earlier However, a substantial population of clients implemented an earlier
version of this specification, which permitted an ASCII encoding of version of this specification, which permitted an ASCII encoding of
the Domain Name field. Server implementations should be aware that the Domain Name field. Server implementations should be aware that
clients which send the FQDN option with the "E" bit clear are using clients which send the Client FQDN option with the "E" bit clear are
an ASCII version of the Domain Name field. Servers MAY be prepared using an ASCII version of the Domain Name field. Servers MAY be
to return an ASCII encoded version of the Domain Name field to such prepared to return an ASCII encoded version of the Domain Name field
clients. The use of ASCII encoding in this option should be to such clients. The use of ASCII encoding in this option should be
considered deprecated. considered deprecated.
A DHCP client which used ASCII encoding was permitted to suggest a A DHCP client which used ASCII encoding was permitted to suggest a
single label if it was not configured with a fully-qualified name. single label if it was not configured with a fully-qualified name.
Such clients send a single label as a series of ASCII characters in Such clients send a single label as a series of ASCII characters in
the Domain Name field, excluding the "." (dot) character. Such the Domain Name field, excluding the "." (dot) character. Such
clients SHOULD follow the character-set recommendations of RFC clients SHOULD follow the character-set recommendations of RFC 1034
1034[2] and RFC 1035[3]. [2] and RFC 1035 [3].
Server implementors should also be aware that some client software Server implementers should also be aware that some client software
may attempt to use UTF-8[10] character encoding. This information is may attempt to use UTF-8 [9] character encoding. This information is
included for informational purposes only: this specification does included for informational purposes only: this specification does not
not require any support for UTF-8. require any support for UTF-8.
5. DHCP Client behavior 5. DHCP Client Behavior
The following describes the behavior of a DHCP client that The following describes the behavior of a DHCP client that implements
implements the Client FQDN option. the Client FQDN option.
Other DHCP options may carry data that is related to the Domain-Name Other DHCP options may carry data that is related to the Domain-Name
part of the FQDN option. The Host-Name option, for example, contains part of the Client FQDN option. The Host-Name option, for example,
an ASCII string representation of the client's host-name. In contains an ASCII string representation of the client's host-name.
general, a client should not need to send redundant data, and In general, a client should not need to send redundant data, and
therefore clients which send the FQDN option in their messages MUST therefore clients which send the Client FQDN option in their messages
NOT also send the Host-Name option. Clients which receive both the MUST NOT also send the Host-Name option. Clients which receive both
Host-Name option and the FQDN option from a server SHOULD prefer the Host-Name option and the Client FQDN option from a server SHOULD
FQDN option data. Servers will be asked in Section 6 to ignore the prefer Client FQDN option data. Servers will be asked in Section 6
Host-Name option in client messages which include the FQDN option. to ignore the Host-Name option in client messages which include the
Client FQDN option.
If a client that owns/maintains its own FQDN wants to be responsible If a client that owns/maintains its own FQDN wants to be responsible
for updating the FQDN to IP address mapping for the FQDN and for updating the FQDN to IP address mapping for the FQDN and
address(es) used by the client, then the client MUST include the address(es) used by the client, then the client MUST include the
Client FQDN option in the DHCPREQUEST message originated by the Client FQDN option in the DHCPREQUEST message originated by the
client. A DHCP client MAY choose to include the Client FQDN option client. A DHCP client MAY choose to include the Client FQDN option
in its DISCOVER messages as well as its REQUEST messages. The in its DISCOVER messages as well as its REQUEST messages. The "S"
least-significant ("S") bit in the Flags field in the option MUST be bit in the Flags field in the option MUST be set to 0. Once the
set to 0. Once the client's DHCP configuration is completed (the client's DHCP configuration is completed (the client receives a
client receives a DHCPACK message, and successfully completes a DHCPACK message, and successfully completes a final check on the
final check on the parameters passed in the message), the client MAY parameters passed in the message), the client MAY originate an update
originate an update for the A RR (associated with the client's for the A RR (associated with the client's FQDN). If the DHCP server
FQDN). The update SHOULD be originated following the procedures from which the client is requesting a lease includes the Client FQDN
described in RFC 2136[4] and "Resolving Name Conflicts"[6]. If the option in its ACK message, and if the server sets both the "S" and
DHCP server from which the client is requesting a lease includes the the "O" bits in the option's flags field, the DHCP client MUST NOT
FQDN option in its ACK message, and if the server sets both the "S" initiate an update for the name in the Domain Name field.
and the "O" bits (the two least-significant bits) in the option's
flags field, the DHCP client MUST NOT initiate an update for the
name in the Domain Name field.
A client can choose to delegate the responsibility for updating the A client can choose to delegate the responsibility for updating the
FQDN to IP address mapping for the FQDN and address(es) used by the FQDN to IP address mapping for the FQDN and address(es) used by the
client to the server. In order to inform the server of this choice, client to the server. In order to inform the server of this choice,
the client SHOULD include the Client FQDN option in its DHCPREQUEST the client SHOULD include the Client FQDN option in its DHCPREQUEST
message. The least-significant (or "S") bit in the Flags field in message. The "S" bit in the Flags field in the option MUST be set to
the option MUST be set to 1. A client which delegates this 1. A client which delegates this responsibility MUST NOT attempt to
responsibility MUST NOT attempt to perform a DNS update for the name perform a DNS update for the name in the Domain Name field of the
in the Domain Name field of the FQDN option. The client MAY supply Client FQDN option. The client MAY supply an FQDN in the Client FQDN
an FQDN in the Client FQDN option, or it MAY supply a single label option, or it MAY supply a single label (the most-specific label), or
(the most-specific label), or it MAY leave that field empty as a it MAY leave that field empty as a signal to the server to generate
signal to the server to generate an FQDN for the client in any an FQDN for the client in any manner the server chooses.
manner the server chooses.
Since there is a possibility that the DHCP server may be configured Since there is a possibility that the DHCP server may be configured
to complete or replace a domain name that the client was configured to complete or replace a domain name that the client was configured
to send, the client might find it useful to send the FQDN option in to send, the client might find it useful to send the Client FQDN
its DISCOVER messages. If the DHCP server returns different Domain option in its DISCOVER messages. If the DHCP server returns
Name data in its OFFER message, the client could use that data in different Domain Name data in its OFFER message, the client could use
performing its own eventual A RR update, or in forming the FQDN that data in performing its own eventual A RR update, or in forming
option that it sends in its REQUEST message. There is no requirement the Client FQDN option that it sends in its REQUEST message. There
that the client send identical FQDN option data in its DISCOVER and is no requirement that the client send identical Client FQDN option
REQUEST messages. In particular, if a client has sent the FQDN data in its DISCOVER and REQUEST messages. In particular, if a
option to its server, and the configuration of the client changes so client has sent the Client FQDN option to its server, and the
that its notion of its domain name changes, it MAY send the new name configuration of the client changes so that its notion of its domain
data in an FQDN option when it communicates with the server again. name changes, it MAY send the new name data in an Client FQDN option
This may allow the DHCP server to update the name associated with when it communicates with the server again. This may allow the DHCP
the PTR record, and, if the server updated the A record representing server to update the name associated with the PTR record, and, if the
the client, to delete that record and attempt an update for the server updated the A record representing the client, to delete that
client's current domain name. record and attempt an update for the client's current domain name.
A client that delegates the responsibility for updating the FQDN to A client that delegates the responsibility for updating the FQDN to
IP address mapping to a server might not receive any indication IP address mapping to a server might not receive any indication
(either positive or negative) from the server whether the server was (either positive or negative) from the server whether the server was
able to perform the update. In this case the client MAY use a DNS able to perform the update. In this case the client MAY use a DNS
query to check whether the mapping is updated. query to check whether the mapping is updated.
A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN A client MUST set the RCODE1 and RCODE2 fields in the Client FQDN
option to 0 when sending the option. option to 0 when sending the option.
If a client releases its lease prior to the lease expiration time If a client releases its lease prior to the lease expiration time and
and the client is responsible for updating its A RR, the client the client is responsible for updating its A RR, the client SHOULD
SHOULD delete the A RR (following the procedures described in delete the A RR associated with the leased address before sending a
"Resolving Name Conflicts"[6]) associated with the leased address DHCP RELEASE message. Similarly, if a client was responsible for
before sending a DHCP RELEASE message. Similarly, if a client was updating its A RR, but is unable to renew its lease, the client
responsible for updating its A RR, but is unable to renew its lease, SHOULD attempt to delete the A RR before its lease expires. A DHCP
the client SHOULD attempt to delete the A RR before its lease client which has not been able to delete an A RR which it added
expires. A DHCP client which has not been able to delete an A RR (because it has lost the use of its DHCP IP address) should attempt
which it added (because it has lost the use of its DHCP IP address) to notify its administrator, perhaps by emitting a log message.
should attempt to notify its administrator, perhaps by emitting a
log message.
6. DHCP Server Behavior 6. DHCP Server Behavior
When a server receives a DHCPREQUEST message from a client, if the When a server receives a DHCPREQUEST message from a client, if the
message contains the Client FQDN option, and the server replies to message contains the Client FQDN option, and the server replies to
the message with a DHCPACK message, the server may be configured to the message with a DHCPACK message, the server may be configured to
originate an update for the PTR RR (associated with the address originate an update for the PTR RR (associated with the address
leased to the client). Any such update SHOULD be originated leased to the client). The server MAY complete the update before the
following the procedures described in "Resolving Name Conflicts"[6]. server sends the DHCPACK message to the client. In this case the
The server MAY complete the update before the server sends the RCODE from the update MUST be carried to the client in the RCODE1
DHCPACK message to the client. In this case the RCODE from the field of the Client FQDN option in the DHCPACK message.
update MUST be carried to the client in the RCODE1 field of the Alternatively, the server MAY send the DHCPACK message to the client
Client FQDN option in the DHCPACK message. Alternatively, the server without waiting for the update to be completed. In this case the
MAY send the DHCPACK message to the client without waiting for the RCODE1 field of the Client FQDN option in the DHCPACK message MUST be
update to be completed. In this case the RCODE1 field of the Client set to 255. The choice between the two alternatives is entirely
FQDN option in the DHCPACK message MUST be set to 255. The choice determined by the configuration of the DHCP server. Servers SHOULD
between the two alternatives is entirely determined by the support both configuration options.
configuration of the DHCP server. Servers SHOULD support both
configuration options.
When a server receives a DHCPREQUEST message containing the Client When a server receives a DHCPREQUEST message containing the Client
FQDN option, the server MUST ignore the values carried in the RCODE1 FQDN option, the server MUST ignore the values carried in the RCODE1
and RCODE2 fields of the option. and RCODE2 fields of the option.
In addition, if the Client FQDN option carried in the DHCPREQUEST In addition, if the Client FQDN option carried in the DHCPREQUEST
message has the "S" bit in its Flags field set, then the server MAY message has the "S" bit in its Flags field set, then the server MAY
originate an update for the A RR (associated with the FQDN carried originate an update for the A RR (associated with the FQDN carried in
in the option) if it is configured to do so by the site's the option) if it is configured to do so by the site's administrator,
administrator, and if it has the necessary credentials. The server and if it has the necessary credentials. The server MAY be
MAY be configured to use the name supplied in the client's FQDN configured to use the name supplied in the client's Client FQDN
option, or it MAY be configured to modify the supplied name, or option, or it MAY be configured to modify the supplied name, or
substitute a different name. substitute a different name.
Any such update SHOULD be originated following the procedures The server MAY originate the update before the server sends the
described in "Resolving Name Conflicts"[6]. The server MAY originate DHCPACK message to the client. In this case the RCODE from the
the update before the server sends the DHCPACK message to the update RFC 2136 [4] MUST be carried to the client in the RCODE2 field
client. In this case the RCODE from the update RFC 2136[4] MUST be of the Client FQDN option in the DHCPACK message. Alternatively the
carried to the client in the RCODE2 field of the Client FQDN option server MAY send the DHCPACK message to the client without waiting for
in the DHCPACK message. Alternatively the server MAY send the the update to be completed. In this case the RCODE2 field of the
DHCPACK message to the client without waiting for the update to be Client FQDN option in the DHCPACK message MUST be set to 255. The
completed. In this case the RCODE2 field of the Client FQDN option choice between the two alternatives is entirely a matter of the DHCP
in the DHCPACK message MUST be set to 255. The choice between the server's configuration. In either case, if the server intends to
two alternatives is entirely a matter of the DHCP server's perform the DNS update and the client's REQUEST message included the
configuration. In either case, if the server intends to perform the Client FQDN option, the server SHOULD include the Client FQDN option
DNS update and the client's REQUEST message included the FQDN in its ACK message. If the server includes the Client FQDN option,
option, the server SHOULD include the FQDN option in its ACK it MUST set the "S" bit in the option's Flags field and MUST clear
message. If the server includes the FQDN option, it MUST set the "S" the "O" bit.
bit in the option's Flags field and MUST clear the "O" bit.
Even if the Client FQDN option carried in the DHCPREQUEST message Even if the Client FQDN option carried in the DHCPREQUEST message has
has the "S" bit in its Flags field clear (indicating that the client the "S" bit in its Flags field clear (indicating that the client
wants to update the A RR), the server MAY be configured by the local wants to update the A RR), the server MAY be configured by the local
administrator to update the A RR on the client's behalf. A server administrator to update the A RR on the client's behalf. A server
which is configured to override the client's preference SHOULD which is configured to override the client's preference SHOULD
include an FQDN option in its ACK message, and MUST set both the "O" include a Client FQDN option in its ACK message, and MUST set both
and "S" bits in the FQDN option's Flags field. The update SHOULD be the "O" and "S" bits in the Client FQDN option's Flags field. The
originated following the procedures described in "Resolving Name server MAY originate the update before the server sends the DHCPACK
Conflicts"[6]. The server MAY originate the update before the server message to the client. In this case the RCODE from the update RFC
sends the DHCPACK message to the client. In this case the RCODE from 2136 [4] MUST be carried to the client in the RCODE2 field of the
the update RFC 2136[4] MUST be carried to the client in the RCODE2 Client FQDN option in the DHCPACK message. Alternatively, the server
field of the Client FQDN option in the DHCPACK message. MAY send the DHCPACK message to the client without waiting for the
Alternatively, the server MAY send the DHCPACK message to the client update to be completed. In this case the RCODE2 field of the Client
without waiting for the update to be completed. In this case the FQDN option in the DHCPACK message MUST be set to 255. Whether the
RCODE2 field of the Client FQDN option in the DHCPACK message MUST DNS update occurs before or after the DHCPACK is sent is entirely up
be set to 255. Whether the DNS update occurs before or after the to the DHCP server's configuration.
DHCPACK is sent is entirely up to the DHCP server's configuration.
When a DHCP server sends the Client FQDN option to a client in the When a DHCP server sends the Client FQDN option to a client in the
DHCPACK message, the DHCP server SHOULD send its notion of the DHCPACK message, the DHCP server SHOULD send its notion of the
complete FQDN for the client in the Domain Name field. The server complete FQDN for the client in the Domain Name field. The server
MAY simply copy the Domain Name field from the Client FQDN option MAY simply copy the Domain Name field from the Client FQDN option
that the client sent to the server in the DHCPREQUEST message. The that the client sent to the server in the DHCPREQUEST message. The
DHCP server MAY be configured to complete or modify the domain name DHCP server MAY be configured to complete or modify the domain name
which a client sent, or it MAY be configured to substitute a which a client sent, or it MAY be configured to substitute a
different name. different name.
If the server initiates a DNS update that is not complete until If the server initiates a DNS update that is not complete until after
after the server has replied to the DHCP client, the server's the server has replied to the DHCP client, the server's interaction
interaction with the DNS server may cause the DHCP server to change with the DNS server may cause the DHCP server to change the domain
the domain name that it associates with the client. This may occur, name that it associates with the client. This may occur, for
for example, if the server detects and resolves a domain-name example, if the server detects and resolves a domain-name conflict.
conflict. In such cases, the domain name that the server returns to In such cases, the domain name that the server returns to the DHCP
the dhcp client may change between two dhcp exchanges. client may change between two DHCP exchanges.
The server MUST use the same encoding format (ASCII or DNS binary The server MUST use the same encoding format (ASCII or DNS binary
encoding) that the client used in the FQDN option in its encoding) that the client used in the Client FQDN option in its
DHCPREQUEST, and MUST set the "E" bit in the option's Flags field DHCPREQUEST, and MUST set the "E" bit in the option's Flags field
accordingly. accordingly.
If a client's DHCPREQUEST message doesn't carry the Client FQDN If a client's DHCPREQUEST message doesn't carry the Client FQDN
option (e.g., the client doesn't implement the Client FQDN option), option (e.g., the client doesn't implement the Client FQDN option),
the server MAY be configured to update either or both of the A and the server MAY be configured to update either or both of the A and
PTR RRs. The updates SHOULD be originated following the procedures PTR RRs.
described in "Resolving Name Conflicts"[6].
If a server detects that a lease on an address that the server If a server detects that a lease on an address that the server leases
leases to a client has expired, the server SHOULD delete any PTR RR to a client has expired, the server SHOULD delete any PTR RR which it
which it added via DNS update. In addition, if the server added an A added via DNS update. In addition, if the server added an A RR on
RR on the client's behalf, the server SHOULD also delete the A RR. the client's behalf, the server SHOULD also delete the A RR.
The deletion SHOULD follow the procedures described in "Resolving
Name Conflicts"[6].
If a server terminates a lease on an address prior to the lease's If a server terminates a lease on an address prior to the lease's
expiration time, for instance by sending a DHCPNAK to a client, the expiration time, for instance by sending a DHCPNAK to a client, the
server SHOULD delete any PTR RR which it associated with the address server SHOULD delete any PTR RR which it associated with the address
via DNS Update. In addition, if the server took responsibility for via DNS Update. In addition, if the server took responsibility for
an A RR, the server SHOULD also delete that A RR. The deletion an A RR, the server SHOULD also delete that A RR.
SHOULD follow the procedures described in "Resolving Name
Conflicts"[6].
7. Security Considerations 7. DNS Update Conflicts
This document does not resolve how a DHCP client or server prevent
name conflicts. This document addresses only how a DHCP 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 and in this case 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 "Resolving Name Conflicts" [12]).
8. 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 should be wary of permitting unsecured DNS updates to
zones which are exposed to the global Internet. Both DHCP clients zones which are exposed to the global Internet. Both DHCP 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[12]) when authentication procedure (e.g., Secure DNS Dynamic Update [11]) when
performing DNS updates. performing DNS updates.
Whether a DHCP client may be responsible for updating an FQDN to IP Whether a DHCP client may be responsible for updating an FQDN to IP
address mapping or whether this is the responsibility of the DHCP address mapping or whether this is the responsibility of the DHCP
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 alternatives may be based on the security model that is used with the
the DNS update protocol (e.g., only a client may have sufficient 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 IP address mapping for
its FQDN). its FQDN).
Whether a DHCP server is always responsible for updating the FQDN to Whether a DHCP server is always responsible for updating the FQDN to
IP address mapping (in addition to updating the IP to FQDN mapping), IP address mapping (in addition to updating the IP to FQDN mapping),
regardless of the wishes of an individual DHCP client, is also a regardless of the wishes of an individual DHCP client, is also a
site-local matter. The choice between the two alternatives may be site-local matter. The choice between the two alternatives may be
based on the security model that is being used with DNS updates. In based on the security model that is being used with DNS updates. In
cases where a DHCP server is performing DNS updates on behalf of a cases where a DHCP server is performing DNS updates on behalf of a
client, the DHCP server should be sure of the DNS name to use for client, the DHCP server should be sure of the DNS name to use for the
the client, and of the identity of the client. client, and of the identity of the client.
Currently, it is difficult for DHCP servers to develop much Currently, it is difficult for DHCP servers to develop much
confidence in the identities of its clients, given the absence of confidence in the identities of its clients, given the absence of
entity authentication from the DHCP protocol itself. There are many entity authentication from the DHCP protocol itself. There are many
ways for a DHCP server to develop a DNS name to use for a client, ways for a DHCP server to develop a DNS name to use for a client, but
but only in certain relatively unusual circumstances will the DHCP only in certain relatively unusual circumstances will the DHCP server
server know for certain the identity of the client. If DHCP know for certain the identity of the client. If DHCP Authentication
Authentication[13] becomes widely deployed this may become more [13] becomes widely deployed this may become more customary.
customary.
One example of a situation which offers some extra assurances is one One example of a situation which offers some extra assurances is one
where the DHCP client is connected to a network through an MCNS where the DHCP client is connected to a network through an MCNS cable
cable modem, and the CMTS (head-end) ensures that MAC address modem, and the CMTS (head-end) ensures that MAC address spoofing
spoofing simply does not occur. Another example of a configuration simply does not occur. Another example of a configuration that might
that might be trusted is one where clients obtain network access via be trusted is one where clients obtain network access via a network
a network access server using PPP. The NAS itself might be obtaining access server using PPP. The NAS itself might be obtaining IP
IP addresses via DHCP, encoding a client identification into the addresses via DHCP, encoding a client identification into the DHCP
DHCP client-id option. In this case, the network access server as client-id option. In this case, the network access server as well as
well as the DHCP server might be operating within a trusted the DHCP server might be operating within a trusted environment, in
environment, in which case the DHCP server could be configured to which case the DHCP server could be configured to trust that the user
trust that the user authentication and authorization procedure of authentication and authorization procedure of the remote access
the remote access server was sufficient, and would therefore trust server was sufficient, and would therefore trust the client
the client identification encoded within the DHCP client-id. identification encoded within the DHCP client-id.
8. Acknowledgements 9. Acknowledgements
Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter
Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear, Ford, Edie Gunter, Andreas Gustafsson, R. Barr Hibbs, Kim Kinnear,
Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield, Stuart Kwan, Ted Lemon, Ed Lewis, Michael Lewis, Josh Littlefield,
Michael Patton, and Glenn Stump for their review and comments. Michael Patton, and Glenn Stump for their review and comments.
Normative References 10. References
10.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", RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Mockapetris, P., "Domain names - Concepts and Facilities", RFC [2] Mockapetris, P., "Domain names - concepts and facilities", STD
1034, Nov 1987. 13, RFC 1034, November 1987.
[3] Mockapetris, P., "Domain names - Implementation and [3] Mockapetris, P., "Domain names - implementation and
Specification", RFC 1035, Nov 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", RFC 2136, April 1997. Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
1997.
[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[6] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP Clients 10.2 Informative References
(draft-ietf-dhc-ddns-resolution-*.txt)", October 2003.
Informative References
[7] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and [6] Marine, A., Reynolds, J. and G. Malkin, "FYI on Questions and
Answers to Commonly asked ``New Internet User'' Questions", Answers - Answers to Commonly asked "New Internet User"
RFC 1594, March 1994. Questions", RFC 1594, March 1994.
[8] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, [7] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
August 1999. August 1999.
[9] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000. 2845, May 2000.
[10] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
RFC 2279, January 1998. 2279, January 1998.
[11] Eastlake, D., "Domain Name System Security Extensions", RFC [10] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999. 2535, March 1999.
[12] Wellington, B., "Secure DNS Dynamic Update", RFC 3007, [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
November 2000. Update", RFC 3007, November 2000.
[12] Stapp, M. and B. Volz, "Resolution of DNS Name Conflicts Among
DHCP Clients (draft-ietf-dhc-ddns-resolution-*.txt)", July
2004.
[13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
RFC 3118, June 2001. RFC 3118, June 2001.
Authors' Addresses Authors' Addresses
Mark Stapp Mark Stapp
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: 978.936.1535 Phone: 978.936.1535
EMail: mjs@cisco.com EMail: mjs@cisco.com
Bernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Phone: 978.936.0382
EMail: volz@cisco.com
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Phone: 408.745.2000 Phone: 408.745.2000
EMail: yakov@juniper.net EMail: yakov@juniper.net
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Copies of IPR disclosures made to the IETF Secretariat and any
others, and derivative works that comment on or otherwise explain it assurances of licenses to be made available, or the result of an
or assist in its implementation may be prepared, copied, published attempt made to obtain a general license or permission for the use of
and distributed, in whole or in part, without restriction of any such proprietary rights by implementers or users of this
kind, provided that the above copyright notice and this paragraph specification can be obtained from the IETF on-line IPR repository at
are included on all such copies and derivative works. However, this http://www.ietf.org/ipr.
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be The IETF invites any interested party to bring to its attention any
revoked by the Internet Society or its successors or assigns. 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.
This document and the information contained herein is provided on an Disclaimer of Validity
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement 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.
Funding for the RFC editor function is currently provided by the 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. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/