draft-ietf-dhc-3315id-for-v4-02.txt   draft-ietf-dhc-3315id-for-v4-03.txt 
DHC Working Group Ted Lemon DHC Working Group Ted Lemon
INTERNET DRAFT Nominum INTERNET DRAFT Nominum
Expires: August 2004 Bill Sommerfeld Expires: January 2005 Bill Sommerfeld
Internet Draft Sun Microsystems Internet Draft Sun Microsystems
Document: <draft-ietf-dhc-3315id-for-v4-02.txt> Document: <draft-ietf-dhc-3315id-for-v4-03.txt>
Category: Standards Track February, 2004 Category: Standards Track July, 2004
Node-Specific Client Identifiers for DHCPv4 Node-Specific Client Identifiers for DHCPv4
Status of this Memo 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,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcwg@ietf.org mailing list. should be submitted to the dhcwg@ietf.org mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with Internet-Drafts are working documents of the Internet Engineering
all provisions of Section 10 of RFC2026. Internet-Drafts are working Task Force (IETF), its areas, and its working groups. Note that
documents of the Internet Engineering Task Force (IETF), its areas, other groups may also distribute working documents as
and its working groups. Note that other groups may also distribute Internet-Drafts.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at months and may be updated, replaced, or obsoleted by other
any time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than a "work in
progress."
The list of current Internet-Drafts can be accessed at: The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
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
Abstract Abstract
This document specifies the format that is to be used for encoding This document specifies the format that is to be used for encoding
DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those DHCPv4 [RFC2131 and RFC2132] client identifiers, so that those
identifiers will be interchangeable with identifiers used in the identifiers will be interchangeable with identifiers used in the
DHCPv6 protocol [RFC3315]. DHCPv6 protocol [RFC3315].
Introduction Introduction
skipping to change at page 2, line 16 skipping to change at page 2, line 24
RFC2131/2132-style DHCP client identifiers. RFC2131/2132-style DHCP client identifiers.
This document first describes the problem to be solved. It then This document first describes the problem to be solved. It then
states the new technique that is to be used to solve the problem. states the new technique that is to be used to solve the problem.
Finally, it describes the specific changes that one would have to Finally, it describes the specific changes that one would have to
make to RFC2131 and RFC2132 in order for those documents not to make to RFC2131 and RFC2132 in order for those documents not to
contradict what is described in this document. contradict what is described in this document.
1.0 Applicability 1.0 Applicability
This document updates RFC2131 and RFC2132. DHCPv4 servers This document updates RFC2131 and RFC2132. DHCPv4 server
implementations SHOULD conform to this document. DHCPv4 clients on implementations SHOULD conform to this document. DHCPv4 clients on
network devices that are expected to support DHCPv6 in the future network devices that are expected to support DHCPv6 in the future
SHOULD conform to this document. This document makes no changes to SHOULD conform to this document. This document makes no changes to
the behavior of DHCPv6 clients or servers. the behavior of DHCPv6 clients or servers.
DHCPv4 clients and servers that are implemented according to this DHCPv4 clients and servers that are implemented according to this
document should be implemented as if the changes specified in document should be implemented as if the changes specified in
section 4.3 and 4.4 have been made to RFC2131 and RFC2132. section 4.3 and 4.4 have been made to RFC2131 and RFC2132.
2.0 Problem Statement 2.0 Problem Statement
2.1. Client identities are ephemeral 2.1. Client identities are ephemeral
RFC2132 recommends that client identifiers be generated by using RFC2132 recommends that client identifiers be generated by using
the permanent link-layer address of the network interface that the the permanent link-layer address of the network interface that the
client is trying to configure. In cases where a network interface client is trying to configure. In cases where a network interface
is removed from the client computer and replaced with a different is removed from the client computer and replaced with a different
network interface with a different permanent link-layer address, network interface with a different permanent link-layer address,
the identity of the client changes. The client loses its IP the identity of the client changes. The client loses its IP
address and any other resources associated with its old identifier address and any other resources associated with its old identifier
- for example, its domain name as published through the DHCP - for example, its domain name as published through the DHCPv4
server. server.
2.2. Clients can accidentally present multiple identities 2.2. Clients can accidentally present multiple identities
Consider a DHCP client that has two network interfaces, one of Consider a DHCPv4 client that has two network interfaces, one of
which is wired and one of which is wireless. There are three which is wired and one of which is wireless. The DHCPv4 client
interesting cases here: will succeed in configuring either zero, one, or two network
interfaces. Under the current specification, each network
(a) Each network interface is attached to a different link. interface will receive a different IP address. The DHCPv4 server
(b) Both network interface are connected to the same link. will treat each network interface as a completely independent
(c) Only one network interface is attached to a link. DHCPv4 client, on a completely independent host.
Case (a) is problematic, and is beyond the scope of this document.
Briefly, in case (a), there is no obvious way to choose which of
the two network interfaces represents the published identity of the
client, and since the two network interfaces are connected to
different network links, this could make a significant
difference. Also, if, as is likely, the two devices use two
different identifiers, but wish to be identified as the same
client in the sense of the domain name on which their A record is
published, they will compete for which interface identity gets the
single available published identity, and there is no obvious way
to write a DHCP client that produces the right result.
Cases (b) and (c) are very common in practice, because many
devices such as laptop computers that are popular at the time of
this writing have both wireless and wired network interfaces that
are installed simultaneously. Both wired and wireless have
advantages - wired has the advantage of speed, and wireless the
advantage of mobility.
So it seems likely that there will be devices that are in states Thus, when the client presents some information to be updated in a
(b) and (c) frequently, and indeed frequently make transitions network directory service, such as the DNS, the name that is
between these states. If the DHCP client that configures these presented will be the same on both interfaces, but the identity
devices uses the link-layer address of each device as an that is presented will be different. What will happen is that one
identifier, the two devices will appear to the DHCP server to be of the two interfaces will get the name, and will retain that name
different nodes, and thus will be assigned different IP addresses. as long as it has a valid lease, even if it loses its connection to
the network, while the other network interface will never get the
name. In some cases, this will achieve the desired result - when
only one network interface is connected, sometimes its IP address
will be published. In some cases, the one connected interface's IP
address will not be the one that is published. When there are two
interfaces, sometimes the correct one will be published, and
sometimes not.
As in state (a), in state (b) only one of the two devices will be This is likely to be a particular problem with modern laptops,
be able to acquire the public identity of the client, although this which usually have built-in wireless ethernet and wired ethernet.
is less of a problem in case (b) because both interfaces are at When the user is near a wired outlet, he or she may want the
least connected to the same network link. Furthermore, if a device additional speed and privacy provided by a wired connection, but
in state (b) makes the transition to state (c), it is quite that same user may unplug from the wired network and wander around,
possible that the lease for the device that has lost connectivity still connected to the wireless network. When a transition like
will remain valid for some time. If the public identity of the this happens, under the current scheme, if the address of the wired
client is associated with this now-defunct interface the client interface is the one that gets published, this client will be seen
will not be reachable through its published domain name. by hosts attempting to connect to it as if it has intermittent
connectivity, even though it actually has continuous network
connectivity through the wireless port.
2.3. RFC2131/2132 and RFC3315 identifiers are incompatible 2.3. RFC2131/2132 and RFC3315 identifiers are incompatible
The 'client identifier' option is used by DHCP clients and servers The 'client identifier' option is used by DHCPv4 clients and
to identify clients. In some cases, the value of the 'client servers to identify clients. In some cases, the value of the
identifier' option is used to mediate access to resources (for 'client identifier' option is used to mediate access to resources
example, the client's domain name, as published through the DHCP (for example, the client's domain name, as published through the
server). RFC2132 and RFC3315 specify different methods for DHCPv4 server). RFC2132 and RFC3315 specify different methods for
deriving client identifiers. These methods guarantee that the deriving client identifiers. These methods guarantee that the
DHCPv4 and DHCPv6 identifier will be different. This means that DHCPv4 and DHCPv6 identifier will be different. This means that
mediation of access to resources using these identifiers will not mediation of access to resources using these identifiers will not
work correctly in cases where a node may be configured using DHCPv4 work correctly in cases where a node may be configured using DHCPv4
in some cases and DHCPv6 in other cases. in some cases and DHCPv6 in other cases.
2.4. RFC2131 does not require the use of a client identifier 2.4. RFC2131 does not require the use of a client identifier
RFC2131 allows the DHCP server to identify clients either by RFC2131 allows the DHCPv4 server to identify clients either by
using the client identifier option sent by the client, or, if the using the client identifier option sent by the client, or, if the
client did not send one, the client's link-layer address. Like client did not send one, the client's link-layer address. Like the
the client identifier format recommended by RFC2131, this suffers client identifier format recommended by RFC2131, this suffers from
from the problems previously described in (2) and (3). the problems previously described in (2) and (3).
3. Solutions 3. Requirements
The solution to problem 2.1 is to use a DHCP client identifier In order to address the problems stated in section 2, DHCPv4 client
that is persistent - not tied to a particular piece of removable identifiers must have the following characteristics:
network hardware. Then, when network hardware is swapped in and
out, the client identifier does not change, and thus the client has
a consistent IP address and consistent use of whatever resources
have been associated with its identifier.
This creates a new problem in case 2.2, however: if the two - They must be persistent, in the sense that a particular host's
network interfaces are connected to the same link and use the same client identifier must not change simply because a piece of
identifier, then the server's IP address assignment algorithm will network hardware is added or removed.
assign the same IP address to both interfaces. But if the DHCP
client state machines configuring the two interfaces are
sufficiently out of sync, the DHCPDISCOVER from the slower
interface may be sent after the DHCPACK for the faster
interface. In this case, the DHCP server will detect a conflict
and abandon the IP address, because the faster interface is
responding to ICMP echo requests. So we can't just use the same
identifier on every interface.
The solution to problem 2.3 is to use the DHCP Unique Identifier as - It must be possible for the client to represent itself as having
defined in RFC3315 as a client identifier. The DUID provides more than one network identity - for example so that a client
several different ways of producing persistent DHCP client with two network interfaces can express to the DHCPv4 server that
identifiers, at least one of which is likely to be appropriate for these two network interfaces are to receive different IP
any particular sort of network device. This is also a valid way of addresses, even if they happen to be connected to the same link.
addressing problem 2.1.
To finish addressing problem 2.2, we modify the solution slightly. - It must be possible, in cases where the DHCPv4 client is
In addition to the DUID, RFC3315 defines an Identity Association ID expressing more than one network identity at the same time, it
(IAID). The IAID, in combination with the DUID, identifies a must nevertheless be possible for the DHCPv4 server to determine
particular identity with which to associate an IP address. So a that the two network identities belong to the same host.
DHCP client has a single DUID, but has one IAID for each interface.
The DHCP server associates IP addresses with the combination of
(DUID, IAID), but uses the DUID to identify the client as a whole.
The solution to problem (2.4) is to deprecate the use of the - It must be possible for a client that is prepared to handle the
contents of the chaddr field in the DHCP packet as a means of case where two or more network interfaces have the same IP
identifying the client. address to use exactly the same identifier for each interface.
4. Implementation Requirements - DHCPv4 servers that do not conform to this specification, but that
are compliant with the older client identifier specification,
must correctly handle client identifiers sent by clients that
conform to this specification.
Here we specify changes to the behavior of DHCP clients and - DHCPv4 servers that do conform to this specification must
interoperate correctly with DHCPv4 clients that do not conform to
this specification, except that when configuring such clients,
behaviors such as those described in section two may occur.
- The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet
as an identifier must be deprecated.
- DHCPv4 client identifiers used by dual-stack hosts that also use
DHCPv6 must use the same host identification string for both
DHCPv4 and DHCPv6 - for example, a DHCPv4 server that uses the
client's identity to update the DNS on behalf of a DHCPv4 client
must register the same client identity in the DNS that would be
registered by the DHCPv6 server on behalf of the DHCPv6 client
running on that host, and vice versa.
In order to satisfy all but the last of these requirements, we need
to construct a DHCPv4 client identifier out of two parts. One part
must be unique to the host on which the client is running. The
other must be unique to the network identity being presented. The
DHCP Unique Identifier (DUID) and Identity Association Identifier
(IAID) specified in RFC3315 satisfy these requirements. And in
order to satisfy the last requirement, we must use the DUID to
identify the DHCPv4 client. So, taking all the requirements
together, the DUID and IAID described in RFC3315 are the only
possible solution.
4. Implementation
Here we specify changes to the behavior of DHCPv4 clients and
servers. We also specify changes to the wording in RFC2131 and servers. We also specify changes to the wording in RFC2131 and
RFC2132. DHCP clients, servers and relay agents that conform to RFC2132. DHCPv4 clients, servers and relay agents that conform to
this specification must implement RFC2131 and RFC2132 with the this specification must implement RFC2131 and RFC2132 with the
wording changes specified in sections 4.3 and 4.4. wording changes specified in sections 4.3 and 4.4.
4.1. DHCP Client behavior 4.1. DHCPv4 Client behavior
DHCP clients conforming to this specification MUST use stable DHCP DHCPv4 clients conforming to this specification MUST use stable
node identifiers in the dhcp-client-identifier option. DHCP DHCPv4 node identifiers in the dhcp-client-identifier option.
clients MUST NOT use client identifiers based solely on layer two DHCPv4 clients MUST NOT use client identifiers based solely on
addresses that are hard-wired to the layer two device (e.g., the layer two addresses that are hard-wired to the layer two device
ethernet MAC address) as suggested in RFC2131, except as allowed in (e.g., the ethernet MAC address) as suggested in RFC2131, except as
section 9.2 of RFC3315. DHCP clients MUST send a 'client allowed in section 9.2 of RFC3315. DHCPv4 clients MUST send a
identifier' option containing an Identity Association Unique 'client identifier' option containing an Identity Association
Identifier, as defined in section 10 of RFC3315, and a DHCP Unique Unique Identifier, as defined in section 10 of RFC3315, and a DHCP
Identifier, as defined in section 9 of RFC3315. These together Unique Identifier, as defined in section 9 of RFC3315. These
constitute an RFC3315-style binding identifier. together constitute an RFC3315-style binding identifier.
The general format of the DHCPv4 'client identifier' option is The general format of the DHCPv4 'client identifier' option is
defined in section 9.14 of RFC2132. defined in section 9.14 of RFC2132.
To send an RFC3315-style binding identifiier in a DHCPv4 'client To send an RFC3315-style binding identifiier in a DHCPv4 'client
identifier' option, the type of the 'client identifier' option is identifier' option, the type of the 'client identifier' option is
set to 255. The type field is immediately followed by the IAID, set to 255. The type field is immediately followed by the IAID,
which is an opaque 32-bit quantity. The IAID is immediately which is an opaque 32-bit quantity. The IAID is immediately
followed by the DUID, which consumes the remaining contents of the followed by the DUID, which consumes the remaining contents of the
'client identifier' option. The format of the 'client 'client identifier' option. The format of the 'client identifier'
identifier' option is as follows: option is as follows:
Code Len Type IAID DUID Code Len Type IAID DUID
+----+----+-----+----+----+----+----+----+----+--- +----+----+-----+----+----+----+----+----+----+---
| 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |... | 61 | n | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
+----+----+-----+----+----+----+----+----+----+--- +----+----+-----+----+----+----+----+----+----+---
Any DHCPv4 or DHCPv6 client that conforms to this specification Any DHCPv4 or DHCPv6 client that conforms to this specification
SHOULD provide a means by which an operator can learn what DUID the SHOULD provide a means by which an operator can learn what DUID the
client has chosen. Such clients SHOULD also provide a means by client has chosen. Such clients SHOULD also provide a means by
which the operator can configure the DUID. A device that is which the operator can configure the DUID. A device that is
normally configured with both a DHCPv4 and DHCPv6 client SHOULD normally configured with both a DHCPv4 and DHCPv6 client SHOULD
automatically use the same DUID for DHCPv4 and DHCPv6 without any automatically use the same DUID for DHCPv4 and DHCPv6 without any
operator intervention. operator intervention.
DHCP clients that support more than one network interface SHOULD DHCPv4 clients that support more than one network interface SHOULD
use the same DUID on every interface. DHCP clients that support use the same DUID on every interface. DHCPv4 clients that support
more than one network interface SHOULD use a different IAID on more than one network interface SHOULD use a different IAID on
each interface. each interface.
4.2. DHCPv4 Server behavior 4.2. DHCPv4 Server behavior
This document does not require any change to DHCPv4 or DHCPv6 This document does not require any change to DHCPv4 or DHCPv6
servers that follow RFC2131 and RFC2132. However, some DHCPv4 servers that follow RFC2131 and RFC2132. However, some DHCPv4
servers can be configured not to conform to RFC2131 and RFC2131, in servers can be configured not to conform to RFC2131 and RFC2131, in
the sense that they ignore the 'client identifier' option and use the sense that they ignore the 'client identifier' option and use
the client's hardware address instead. the client's hardware address instead.
DHCP servers that conform to this specification MUST use the DHCPv4 servers that conform to this specification MUST use the
'client identifier' option to identify the client if the client 'client identifier' option to identify the client if the client
sends it. sends it.
DHCP servers MAY use administrator-supplied values for chaddr and DHCPv4 servers MAY use administrator-supplied values for chaddr and
htype to identify the client in the case where the administrator is htype to identify the client in the case where the administrator is
assigning a fixed IP address to the client, even if the client assigning a fixed IP address to the client, even if the client
sends an client identifier option. This is ONLY permitted in the sends an client identifier option. This is ONLY permitted in the
case where the DHCP server administrator has provided the values case where the DHCPv4 server administrator has provided the values
for chaddr and htype, because in this case if it causes a problem, for chaddr and htype, because in this case if it causes a problem,
the administrator can correct the problem by removing the offending the administrator can correct the problem by removing the offending
configuration information. configuration information.
4.3. Changes from RFC2131 4.3. Changes from RFC2131
In section 2 of RFC2131, on page 9, the text that reads "; for In section 2 of RFC2131, on page 9, the text that reads "; for
example, the 'client identifier' may contain a hardware address, example, the 'client identifier' may contain a hardware address,
identical to the contents of the 'chaddr' field, or it may contain identical to the contents of the 'chaddr' field, or it may contain
another type of identifier, such as a DNS name" is deleted. another type of identifier, such as a DNS name" is deleted.
In section 4.2 of RFC2131, the text "The client MAY choose to In section 4.2 of RFC2131, the text "The client MAY choose to
explicitly provide the identifier through the 'client identifier' explicitly provide the identifier through the 'client identifier'
option. If the client supplies a 'client identifier', the client option. If the client supplies a 'client identifier', the client
MUST use the same 'client identifier' in all subsequent messages, MUST use the same 'client identifier' in all subsequent messages,
and the server MUST use that identifier to identify the client. If and the server MUST use that identifier to identify the client. If
the client does not provide a 'client identifier' option, the the client does not provide a 'client identifier' option, the
server MUST use the contents of the 'chaddr' field to identify the server MUST use the contents of the 'chaddr' field to identify the
client." is replaced by the text "The client MUST explicitly client." is replaced by the text "The client MUST explicitly
provide a client identifier through the 'client identifier' provide a client identifier through the 'client identifier'
option." option. The client MUST use the same 'client identifier' option
for all messages."
In the same section, the text "Use of 'chaddr' as the client's In the same section, the text "Use of 'chaddr' as the client's
unique identifier may cause unexpected results, as that identifier unique identifier may cause unexpected results, as that identifier
may be associated with a hardware interface that could be moved to may be associated with a hardware interface that could be moved to
a new client. Some sites may choose to use a manufacturer's serial a new client. Some sites may choose to use a manufacturer's serial
number as the 'client identifier', to avoid unexpected changes in a number as the 'client identifier', to avoid unexpected changes in a
clients network address due to transfer of hardware interfaces clients network address due to transfer of hardware interfaces
among computers. Sites may also choose to use a DNS name as the among computers. Sites may also choose to use a DNS name as the
'client identifier', causing address leases to be associated with 'client identifier', causing address leases to be associated with
the DNS name rather than a specific hardware box." is replaced by the DNS name rather than a specific hardware box." is replaced by
skipping to change at page 6, line 48 skipping to change at page 7, line 19
In section 4.4.1 of RFC2131, the text "The client MAY include a In section 4.4.1 of RFC2131, the text "The client MAY include a
different unique identifier" is replaced with "The client MUST different unique identifier" is replaced with "The client MUST
include a unique identifier". include a unique identifier".
In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1, where In sections 3.1, item 4 and 6, 3.2 item 3 and 4, and 4.3.1, where
RFC2131 says that 'chaddr' may be used instead of the 'client RFC2131 says that 'chaddr' may be used instead of the 'client
identifier' option, the text that says "or 'chaddr'" and "'chaddr' identifier' option, the text that says "or 'chaddr'" and "'chaddr'
or" is deleted. or" is deleted.
Note that these changes do not relieve the DHCP server of the Note that these changes do not relieve the DHCPv4 server of the
obligation to use 'chaddr' as an identifier if the client does not obligation to use 'chaddr' as an identifier if the client does not
send a 'client identifier' option. Rather, they oblige clients send a 'client identifier' option. Rather, they oblige clients
that conform with this document to send a 'client identifier' that conform with this document to send a 'client identifier'
option, and not rely on 'chaddr' for identification. DHCP servers option, and not rely on 'chaddr' for identification. DHCPv4
MUST use 'chaddr' as an identifier in cases where 'client servers MUST use 'chaddr' as an identifier in cases where 'client
identifier' is not sent, in order to support old clients that do identifier' is not sent, in order to support old clients that do
not conform with this document. not conform with this document.
4.4. Changes from RFC2132 4.4. Changes from RFC2132
The text in section 9.14, beginning with "The client identifier MAY The text in section 9.14, beginning with "The client identifier MAY
consist of" through "that meet this requirement for uniqueness." is consist of" through "that meet this requirement for uniqueness." is
replaced with "the client identifier consists of a type field whose replaced with "the client identifier consists of a type field whose
value is normally 255, followed by a two-byte type field, followed value is normally 255, followed by a two-byte type field, followed
by the contents of the identifier. The two-byte type field and the by the contents of the identifier. The two-byte type field and the
skipping to change at page 7, line 29 skipping to change at page 7, line 52
attack in the DHCPv4 protocol are discussed in section 7 of the attack in the DHCPv4 protocol are discussed in section 7 of the
DHCP protocol specification [RFC2131] and in Authentication for DHCP protocol specification [RFC2131] and in Authentication for
DHCP messages [RFC3118]. Potential exposure to attack in the DHCP messages [RFC3118]. Potential exposure to attack in the
DHCPv6 protocol is discussed in section 23 of RFC3315. DHCPv6 protocol is discussed in section 23 of RFC3315.
6. IANA Considerations 6. IANA Considerations
This document defines no new name spaces that need to be This document defines no new name spaces that need to be
administered by the IANA. This document deprecates all 'client administered by the IANA. This document deprecates all 'client
identifier' type codes other than 255, and thus there is no need identifier' type codes other than 255, and thus there is no need
for the IANA to track possible values for the type field of the for the IANA to track additional possible values for the type field
'client identifier' option. of the 'client identifier' option.
7. Normative References 7. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March, 1997 Extensions", RFC2132, March, 1997
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
Carney, M., "Dynamic Host Configuration Protocol for Carney, M., "Dynamic Host Configuration Protocol for
IPv6 (DHCPV6)", July, 2003 IPv6 (DHCPV6)", July, 2003
skipping to change at page 8, line 23 skipping to change at page 8, line 38
Bill Sommerfeld Bill Sommerfeld
Sun Microsystems Sun Microsystems
1 Network Drive 1 Network Drive
Burlington, MA 01824 Burlington, MA 01824
+1 781 442 3458 +1 781 442 3458
sommerfeld@sun.com sommerfeld@sun.com
Full Copyright Statement Full Copyright Statement
"Copyright (C) 2003, 2004 The Internet Society. All Rights Reserved. Copyright (C) The Internet Society (2003-2004). This document is
This document and translations of it may be copied and furnished to subject to the rights, licenses and restrictions contained in BCP
others, and derivative works that comment on or otherwise explain 78, and except as set forth therein, the authors retain all their
it or assist in its implementation may be prepared, copied, rights.
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative
works. However, this 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
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein are provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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