draft-ietf-dhc-leasequery-by-remote-id-05.txt   draft-ietf-dhc-leasequery-by-remote-id-06.txt 
DHC Working Group P. Kurapati DHC Working Group P. Kurapati
Internet-Draft Juniper Networks Ltd. Internet-Draft Juniper Networks Ltd.
Expires: December 9, 2010 R. Desetti Expires: February 7, 2011 R. Desetti
B. Joshi B. Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
June 7, 2010 August 6, 2010
DHCPv4 Leasequery by relay agent remote ID DHCPv4 Leasequery by Relay Agent Remote ID
draft-ietf-dhc-leasequery-by-remote-id-05.txt draft-ietf-dhc-leasequery-by-remote-id-06.txt
Abstract Abstract
Some Relay Agents extract lease information from the DHCP messages Some Relay Agents extract lease information from the DHCP messages
exchanged between the client and DHCP server. This lease information exchanged between the client and DHCP server. This lease information
is used by relay agents for various purposes like antispoofing and is used by relay agents for various purposes like antispoofing and
prevention of flooding. RFC 4388 [RFC4388] defines a mechanism for prevention of flooding. RFC 4388 defines a mechanism for relay
relay agents to retrieve the lease information from the DHCP server agents to retrieve the lease information from the DHCP server as and
as and when this information is lost. The existing leasequery when this information is lost. The existing leasequery mechanism is
mechanism is data driven, which means that a relay agent can initiate data driven, which means that a relay agent can initiate the
the leasequery only when it starts receiving data from/to the leasequery only when it starts receiving data from/to the clients.
clients. In certain scenarios, this model is not scalable. This In certain scenarios, this model is not scalable. This document
document first looks at issues in existing mechanism and then first looks at issues in existing mechanism and then proposes a new
proposes a new query type, query by remote ID, to address these query type, query by Remote ID, to address these issues.
issues.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 9, 2010. This Internet-Draft will expire on February 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 21
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 8 4.1. Sending the DHCPLEASEQUERY Message . . . . . . . . . . . . 8
4.2. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 9 4.2. Responding to the DHCPLEASEQUERY Message . . . . . . . . . 9
4.3. Determining the IP address to be used in response . . . . 9 4.3. Building a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message . . 9
4.4. Building a DHCPLEASEUNKNOWN or DHCPLEASEACTIVE message . . 10 4.4. Determining the IP address to be used in response . . . . 10
4.5. Sending a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message . . 10 4.5. Sending a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message . . 10
4.6. Receiving a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN 4.6. Receiving a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
Message . . . . . . . . . . . . . . . . . . . . . . . . . 10 Message . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Receiving No Response to the DHCPLEASEQUERY Message . . . 11 4.7. Receiving No Response to the DHCPLEASEQUERY Message . . . 11
4.8. Lease Binding Data Storage Requirements . . . . . . . . . 11 4.8. Lease Binding Data Storage Requirements . . . . . . . . . 11
4.9. Using the DHCPLEASEQUERY Message with Multiple DHCP 4.9. Using the DHCPLEASEQUERY Message with Multiple DHCP
Servers . . . . . . . . . . . . . . . . . . . . . . . . . 11 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 12 5. RFC 4388 Considerations . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 52 skipping to change at page 3, line 52
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 1 Figure 1
For example, when a DSLAM acting as a Relay Agent is rebooted, it For example, when a DSLAM acting as a Relay Agent is rebooted, it
should query the server for the lease information for all the should query the server for the lease information for all the
connections/circuits. Also, as shown in the above figure, there connections/circuits. Also, as shown in the above figure, there
could be multiple clients on one DSL circuit. The relay agent should could be multiple clients on one DSL circuit. The relay agent should
get the lease information of all the clients connected to a DSL get the lease information of all the clients connected to a DSL
circuit. This is possible by introducing a new query type based on circuit. This is possible by introducing a new query type based on
the Remote Id sub-option of the Relay Agent Information option. This the Remote ID sub-option of the Relay Agent Information option. This
document talks about the motivation for the new query type and the document talks about the motivation for the new query type and the
method to perform it. method to perform it.
2. Terminology 2. 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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "access concentrator" o "Access Concentrator"
An access concentrator is a router or switch at the broadband access An access concentrator is a router or switch at the broadband access
provider's edge of a public broadband access network. This document provider's edge of a public broadband access network. This document
assumes that the access concentrator includes the DHCP relay agent assumes that the access concentrator includes the DHCP relay agent
functionality. functionality.
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address. parameters such as a network address.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
increased outage time for clients increased outage time for clients
o results in excessive negative caching, consuming a lot of o results in excessive negative caching, consuming a lot of
resources under a spoofing attack resources under a spoofing attack
o results in antispoofing being done in the slow path instead of the o results in antispoofing being done in the slow path instead of the
fast path fast path
4. Protocol Details 4. Protocol Details
This section talks about the protocol details for query by relay This section talks about the protocol details for query by Remote ID.
agent remote id. Most of the message handlings are similar to RFC Most of the message handlings are similar to RFC 4388 [RFC4388] and
4388 [RFC4388] and this section highlights only the differences. this section highlights only the differences. Reader is advised to
Reader is advised to go through RFC 4388 [RFC4388] before going go through RFC 4388 [RFC4388] before going through this section for
through this section for complete understanding of the protocol. complete understanding of the protocol.
A DHCPLEASEQUERY specified in this document specifies a lease query A DHCPLEASEQUERY specified in this document specifies a lease query
by remote ID unless otherwise specified. by Remote ID unless otherwise specified.
RFC 3046 [RFC3046] defines two sub-options for the Relay Agent RFC 3046 [RFC3046] defines two sub-options for the Relay Agent
Information option. Sub-option 1 corresponds to the circuit ID that Information option. Sub-option 1 corresponds to the Circuit ID that
identifies the local circuit of the access concentrator. This sub- identifies the local circuit of the access concentrator. This sub-
option is unique to the relay agent. Sub-option 2 corresponds to the option is unique to the relay agent. Sub-option 2 corresponds to the
remote ID that identifies the remote host end of the circuit. This Remote ID that identifies the remote host end of the circuit. This
is globally unique in the network. is globally unique in the network.
This document defines a new query type based on the remote ID sub- This document defines a new query type based on the Remote ID sub-
option. Suppose that the access concentrator (e.g., DSLAM) lost the option. Suppose that the access concentrator (e.g., DSLAM) lost the
lease information when it was rebooted. When the access concentrator lease information when it was rebooted. When the access concentrator
comes up, it would initiate (for each connection/circuit) a dhcp comes up, it would initiate (for each connection/circuit) a dhcp
lease query by remote-id as defined in this section. For this query, lease query by Remote ID as defined in this section. For this query,
the requester supplies only an option 82 which will include only an the requester supplies only an option 82 which will include only a
Agent Remote ID sub-option in the DHCPLEASEQUERY message. Remote ID sub-option in the DHCPLEASEQUERY message.
The DHCP server MUST reply with a DHCPLEASEACTIVE message if there is The DHCP server MUST reply with a DHCPLEASEACTIVE message if there is
an active lease corresponding to the agent remote-ID that is present an active lease corresponding to the Remote ID that is present in the
in the DHCPLEASEQUERY message. Otherwise, the server MUST reply with DHCPLEASEQUERY message. Otherwise, the server MUST reply with a
a DHCPLEASEUNKNOWN message. Servers that do not implement DHCPLEASEUNKNOWN message. Servers that do not implement
DHCPLEASEQUERY based on remote ID SHOULD simply not respond. DHCPLEASEQUERY based on Remote ID SHOULD simply not respond.
4.1. Sending the DHCPLEASEQUERY Message 4.1. Sending the DHCPLEASEQUERY Message
The DHCPLEASEQUERY message is typically sent by an access The DHCPLEASEQUERY message is typically sent by an access
concentrator. The DHCPLEASEQUERY message uses the DHCP message concentrator. The DHCPLEASEQUERY message uses the DHCP message
format as described in RFC 2131 [RFC2131], and uses message number 10 format as described in RFC 2131 [RFC2131], and uses message number 10
in the DHCP Message Type option (option 53). The DHCPLEASEQUERY in the DHCP Message Type option (option 53). The DHCPLEASEQUERY
message has the following pertinent message contents: message has the following pertinent message contents:
o The giaddr and Parameter Request List option" are set as explained o The giaddr and Parameter Request List option are set as explained
in section 6.2 of RFC 4388 [RFC4388]. in section 6.2 of RFC 4388 [RFC4388].
o There MUST be a Relay Agent Information option (option 82) with o There MUST be a Relay Agent Information option (option 82) with
only Agent Remote ID sub-option (sub-option 2) in the only a Remote ID sub-option (sub-option 2) in the DHCPLEASEQUERY
DHCPLEASEQUERY message. message.
o The "ciaddr" field MUST be set to zero. o The ciaddr field MUST be set to zero.
o The values of htype, hlen, and chaddr MUST be set to zero. o The values of htype, hlen, and chaddr MUST be set to zero.
o The Client-identifier option (option 61) MUST NOT appear in the o The Client Identifier option (option 61) MUST NOT appear in the
packet. packet.
The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is The DHCPLEASEQUERY message SHOULD be sent to a DHCP server which is
known to possess authoritative information concerning the remote ID. known to possess authoritative information concerning the Remote ID.
The DHCPLEASEQUERY message MAY be sent to more than one DHCP server, The DHCPLEASEQUERY message MAY be sent to more than one DHCP server,
and in the absence of information concerning which DHCP server might and in the absence of information concerning which DHCP server might
possess authoritative information concerning the remote ID, it SHOULD possess authoritative information concerning the Remote ID, it SHOULD
be sent to all DHCP servers configured for the associated relay agent be sent to all DHCP servers configured for the associated relay agent
(if any are known). (if any are known).
4.2. Responding to the DHCPLEASEQUERY Message 4.2. Responding to the DHCPLEASEQUERY Message
There are two possible responses to a DHCPLEASEQUERY message: There are two possible responses to a DHCPLEASEQUERY message:
o DHCPLEASEUNKNOWN o DHCPLEASEUNKNOWN
The DHCPLEASEUNKNOWN message indicates that the client associated The DHCPLEASEUNKNOWN message indicates that the client associated
with the agent remote-ID suboption of the DHCPLEASEQUERY message is with the Remote ID suboption of the DHCPLEASEQUERY message is not
not allocated any lease or it is not managed by the server. allocated any lease or it is not managed by the server.
o DHCPLEASEACTIVE o DHCPLEASEACTIVE
The DHCPLEASEACTIVE message indicates that the server not only knows The DHCPLEASEACTIVE message indicates that the server not only knows
the client specified in the DHCPLEASEQUERY message, but also knows the client specified in the DHCPLEASEQUERY message, but also knows
that there is an active lease for that client. that there is an active lease for that client.
4.3. Determining the IP address to be used in response 4.3. Building a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message
The IP address placed in the "ciaddr" field of a DHCPLEASEACTIVE A DHCPLEASEACTIVE message is built by populating information
pertaining to the client associated with the IP address specified in
the ciaddr field.
In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the Remote ID,
then the list of all those IP addresses MUST be returned in the
associated-ip option, whether or not that option was requested as
part of the Parameter Request List option.
In a DHCPLEASEUNKNOWN response message, the DHCP server MUST echo the
Option 82 received in the DHCPLEASEQUERY message. No other options
are returned for these messages.
For all other options that are specified in Parameter Request List,
the processing is same as mentioned in section 6.4.2 of RFC 4388
[RFC4388].
4.4. Determining the IP address to be used in response
The IP address placed in the ciaddr field of a DHCPLEASEACTIVE
message MUST be the IP address with the latest client-last- message MUST be the IP address with the latest client-last-
transaction-time associated with the client described by the remote transaction-time associated with the client described by the Remote
ID specified in the DHCPLEASEQUERY message. ID specified in the DHCPLEASEQUERY message.
If there is only a single IP address that fulfills this criteria, If there is only a single IP address that fulfills this criteria,
then it MUST be placed in the "ciaddr" field of the DHCPLEASEACTIVE then it MUST be placed in the ciaddr field of the DHCPLEASEACTIVE
message. message.
In the case where more than one IP address has been accessed by the In the case where more than one IP address has been accessed by the
client specified by the Remote ID, then the DHCP server MUST return client specified by the Remote ID, then the DHCP server MUST return
the IP address returned to the client in the most recent transaction the IP address returned to the client in the most recent transaction
with the client unless the DHCP server has been configured by the with the client unless the DHCP server has been configured by the
server administrator to use some other preference mechanism. server administrator to use some other preference mechanism.
4.4. Building a DHCPLEASEUNKNOWN or DHCPLEASEACTIVE message
In a DHCPLEASEUNKNOWN response message, the DHCP server MUST echo the
Option 82 received in the DHCPLEASEQUERY message. No other options
are returned for these messages.
A DHCPLEASEACTIVE message is built by populating information
pertaining to the client associated with the IP address specified in
the "ciaddr" field.
In the case where more than one IP address has been involved in a
DHCP message exchange with the client specified by the Agent Remote
ID, then the list of all those IP addresses MUST be returned in the
associated-ip option, whether or not that option was requested as
part of the Parameter Request List option.
For all other options that are specified in Parameter Request List,
the processing is same as mentioned in section 6.4.2 of RFC 4388
[RFC4388].
4.5. Sending a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message 4.5. Sending a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message
The server unicasts the DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message The server unicasts the DHCPLEASEACTIVE or DHCPLEASEUNKNOWN message
to the address specified in giaddr field of DHCPLEASEQUERY message. to the address specified in giaddr field of DHCPLEASEQUERY message.
4.6. Receiving a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message 4.6. Receiving a DHCPLEASEACTIVE or DHCPLEASEUNKNOWN Message
When a DHCPLEASEACTIVE message is received in response to the When a DHCPLEASEACTIVE message is received in response to the
DHCPLEASEQUERY message, it means that there is currently an active DHCPLEASEQUERY message, it means that there is currently an active
lease associated with the remote-id in the DHCP server. The access lease associated with the Remote ID in the DHCP server. The access
concentrator SHOULD use the information in the "htype", "hlen", and concentrator SHOULD use the information in the "htype", "hlen", and
"chaddr" fields of the DHCPLEASEACTIVE as well as Relay Agent "chaddr" fields of the DHCPLEASEACTIVE as well as Relay Agent
Information option information included in the packet to refresh its Information option information included in the packet to refresh its
location information for this IP address. An access concentrator is location information for this IP address. An access concentrator is
likely to query by IP address for all the IP addresses specified in likely to query by IP address for all the IP addresses specified in
the associated-ip option in the response, if any, at this point in the associated-ip option in the response, if any, at this point in
time. time.
When a DHCPLEASEUNKNOWN message is received by an access concentrator When a DHCPLEASEUNKNOWN message is received by an access concentrator
that had sent out a DHCPLEASEQUERY message, it means that the DHCP that had sent out a DHCPLEASEQUERY message, it means that the DHCP
server does not have definitive information concerning the DHCP server does not have definitive information concerning the DHCP
client specified in the Agent Remote ID sub-option of the client specified in the Remote ID sub-option of the DHCPLEASEQUERY
DHCPLEASEQUERY message. The Access Concentrator MAY store this message. The Access Concentrator MAY store this information for
information for future use. However, a DHCPLEASEQUERY SHOULD NOT be future use. However, a DHCPLEASEQUERY SHOULD NOT be attempted with
attempted with the same Remote ID sub-option. the same Remote ID sub-option.
For leasequery by remote-id, the impact of negative caching is For leasequery by Remote ID, the impact of negative caching is
greatly reduced as the response leads to "definitive" information on greatly reduced as the response leads to "definitive" information on
all the hosts connected behind the connection. Note that in the case all the hosts connected behind the connection. Note that in the case
of data-driven approach [RFC4388], a host spoofing several IP of data-driven approach [RFC4388], a host spoofing several IP
addresses can lead to negative caching of greater magnitude. Another addresses can lead to negative caching of greater magnitude. Another
important change this draft brings is the removal of "periodic" important change this draft brings is the removal of "periodic"
leasequeries generated from negative caching caused by leasequeries generated from negative caching caused by
DHCPLEASEUNKNOWN. Since the information obtained through query by DHCPLEASEUNKNOWN. Since the information obtained through query by
remote-id is complete, there is no need of attempting leasequery Remote ID is complete, there is no need of attempting leasequery
again for the same connection. again for the same connection.
4.7. Receiving No Response to the DHCPLEASEQUERY Message 4.7. Receiving No Response to the DHCPLEASEQUERY Message
When an access concentrator receives no response to a DHCPLEASEQUERY When an access concentrator receives no response to a DHCPLEASEQUERY
message, it should be handled in the same manner as suggested in RFC message, it should be handled in the same manner as suggested in RFC
4388 [RFC4388]. 4388 [RFC4388].
4.8. Lease Binding Data Storage Requirements 4.8. Lease Binding Data Storage Requirements
Implementation Note: Implementation Note:
To generate replies for a lease query by remote-id effeciently, a To generate replies for a lease query by Remote ID effeciently, a
DHCP server should index the lease binding data structures using DHCP server should index the lease binding data structures using
remote-id. Remote ID.
4.9. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers 4.9. Using the DHCPLEASEQUERY Message with Multiple DHCP Servers
This scenario should be handled in the same way it is done in RFC This scenario should be handled in the same way it is done in RFC
4388 [RFC4388]. 4388 [RFC4388].
5. RFC 4388 Considerations 5. RFC 4388 Considerations
This document is compatible with RFC 4388 [RFC4388] based This document is compatible with RFC 4388 [RFC4388] based
implementations, which means that a client that supports this implementations, which means that a client that supports this
extension can work with a server not supporting this document, extension can work with a server not supporting this document,
provided it uses RFC 4388 [RFC4388] defined query types. Also, a provided it uses RFC 4388 [RFC4388] defined query types. Also, a
server supporting this document can work with a client not supporting server supporting this document can work with a client not supporting
this query type. However, there are some changes that this document this query type. However, there are some changes that this document
proposes with respect to RFC 4388 [RFC4388]. Implementers extending proposes with respect to RFC 4388 [RFC4388]. Implementers extending
RFC 4388 [RFC4388] implementations to support this document, should RFC 4388 [RFC4388] implementations to support this document, should
take note of the following points: take note of the following points:
o RFC 4388 [RFC4388] suggests that a DHCPLEASEUNASSIGNED is returned
only in the case of 'query by IP address'. All other query types
will have a return message of either DHCPLEASEACTIVE or
DHCPLEASEUNKNOWN. Although it would be possible to return
DHCPLEASEUNASSIGNED in case of a query by remote-id, in order to
maintain compatibility with other similar query types (MAC and
Client-id) a query by remote-id does not support a
DHCPLEASEUNASSIGNED response.
o There may be cases where a query by IP address/MAC address/Client o There may be cases where a query by IP address/MAC address/Client
Identifier has an option 82 containing remote ID. In that case, Identifier has an option 82 containing Remote ID. In that case,
the query will still be recognized as query by IP address/MAC the query will still be recognized as query by IP address/MAC
address/Client Identifier as specified by RFC 4388 [RFC4388]. address/Client Identifier as specified by RFC 4388 [RFC4388].
o Section 6.4 of RFC 4388 [RFC4388] suggests that a DHCPLEASEUNKNOWN o Section 6.4 of RFC 4388 [RFC4388] suggests that a DHCPLEASEUNKNOWN
MUST NOT have any other option present. But for a query by remote MUST NOT have any other option present. But for a query by Remote
ID, option 82 MUST be present in the reply. ID, option 82 MUST be present in the reply.
6. Security Considerations 6. Security Considerations
This document does not introduce any new security concerns beyond This document does not introduce any new security concerns beyond
those specified in the original leasequery protocol RFC 4388 those specified in the original leasequery protocol RFC 4388
[RFC4388] specifications. [RFC4388] specifications.
7. IANA Considerations 7. IANA Considerations
This document does not introduce any new namespaces for the IANA to This document does not introduce any new namespaces for the IANA to
manage. manage.
8. Acknowledgments 8. Acknowledgments
Copious amounts of text in this document are derived from RFC 4388 Copious amounts of text in this document are derived from RFC 4388
[RFC4388]. Kim kinnear, Damien Neil, Stephen Jacob and Alfred Hoenes [RFC4388]. Kim Kinnear, Damien Neil, Stephen Jacob and Alfred Hoenes
provided valuable feedback on this document provided valuable feedback on this document
9. References 9. References
9.1. Normative Reference 9.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration
 End of changes. 37 change blocks. 
88 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/