DHC Working Group B. Joshi
Internet-Draft P. Kurapati
Expires: February 5, 2007 Infosys Technologies Ltd.
August 4, 2006
Extension of DHCP Leasequery in Bridging/Switching networks
draft-joshi-dhcp-lease-query-ext-01.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 5, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
As per industry trends, Access Networks have been migrating from
traditional ATM based networks to Ethernet networks. In Ethernet
based access networks, Access Concentrators are typically configured
to act as traditional bridge. These Access Concentrators also act as
relay agents and relay DHCP messages between hosts and DHCP servers.
It also maintains and updates lease/location information while
relaying the DHCP messages. Access Concentrators may use the lease/
location information for anti-spoofing, data forwarding etc. This
Joshi & Kurapati Expires February 5, 2007 [Page 1]
Internet-Draft Extension of DHCP Leasequery August 2006
lease/location information is lost if an Access Concentrator gets
rebooted. RFC 4388 [4] has defined a new message type DHCPLEASEQUERY
to address similar limitation in Routed Access Networks.
This document initially gives an overview of the functioning of the
Access Concentrator acting as a relay agent in a Layer 2 aggregation
network. The limitation[as mentioned above] in a typical switched/
bridged[layer 2] is then discussed followed by the proposal to extend
the DHCPLEASEQUERY message to address this limitation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Typical layer 2 access network . . . . . . . . . . . . . . . . 6
3.1. Access Concentrator acting as Layer 2 DHCP relay agent . . 6
4. Protocol Extension Overview . . . . . . . . . . . . . . . . . 8
4.1. Lease/Location information in layer 2 Networks . . . . . . 8
4.2. Extension of DHCPLEASEQUERY in layer 2 Networks . . . . . 8
5. Protocol Extension Details . . . . . . . . . . . . . . . . . . 9
5.1. Definition required for extension of DHCPLEASEQUERY
message . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Generating DHCPLEASEQUERY Message . . . . . . . . . . . . 9
5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent . . 11
5.4. Handling DHCPLEASEQUERY Message in DHCP Server . . . . . . 11
5.5. Handling DHCP Reply Message in Layer-3 Relay Agent . . . . 12
5.6. Handling DHCP Reply Message in Access Concentrator . . . . 13
5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message . . . . . . 13
5.6.2. Handling DHCPLEASEUNKNOWN Reply Message . . . . . . . 13
5.6.3. Handling DHCPLEASEACTIVE Reply Message . . . . . . . . 13
5.6.4. Handling No Response to the DHCPLEASEQUERY Message . . 13
5.6.5. Handling DHCPLEASEQUERY messages not belonging to
Access Concentrator . . . . . . . . . . . . . . . . . 13
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17
9.2. Informative Reference . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Joshi & Kurapati Expires February 5, 2007 [Page 2]
Internet-Draft Extension of DHCP Leasequery August 2006
1. Introduction
Access networks are undergoing transformation from traditional ATM
based networks to Ethernet based networks. Service providers have
deployed Access Concentrators in both Routing and Bridging modes. In
the Routing mode, Access Concentrator terminates the user connection
and 'routes' the packets to the edge/core network. In the bridging
mode, Access Concentrator does frame switching based on MAC address,
VLANs etc. It also supports DHCP/PPPoE/IGMP snooping for better
security and bandwidth management. In case of DHCP/PPPoE snooping,
Access Concentrator acts as a Relay Agent.
In both routing and bridging mode, Access Concentrator maintains
lease/location information by extracting it from the DHCP replies
received from the DHCP server. This information is typically
maintained for anti-spoofing, data forwarding etc. This lease/
location information is lost when Access Concentrator gets rebooted.
RFC 4388 [4] has defined a method to access information from the DHCP
server in a lightweight and consistent manner. This is achieved by
the use of a new message type "DHCPLEASEQUERY" that allows Relay
Agents to query DHCP servers to obtain location information of DHCP
clients.
RFC 4388 [4] assumes that in a typical access environment, Access
Concentrator acts as a Layer 3 DHCP Relay Agent. This document
suggests extension to RFC 4388 [4] to make it suitable in a layer 2
access environment.
Joshi & Kurapati Expires February 5, 2007 [Page 3]
Internet-Draft Extension of DHCP Leasequery August 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document uses the following terms:
o "Access Concentrator"
An Access Concentrator is a router or switch at the broadband access
provider's edge of a public broadband access network. This document
assumes that the Access Concentrator acts as a Transparent Bridge and
includes the DHCP relay agent functionality. For example: In DSL
environment, this is typically known as DSLAM.(Digital Subscriber
Line Access Multiplexer)
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address.
o "Layer-3 Relay Agent"
A Layer-3 Relay Agent is a third-party agent that transfers Bootstrap
Protocol (BOOTP) and DHCP messages between clients and servers
residing on different subnets, per [RFC951] and [RFC1542].
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
o "downstream"
Downstream is the direction from the edge network towards the
broadband subscriber.
o "lease/location information"
Lease/Location information is information maintained by the Access
Concentrator to either forward traffic to a broadband-accessible host
or for anti-spoofing of MAC address/IP address or for both. This
information includes knowledge of the host hardware address, host IP
address, the port or virtual circuit that leads to the host, lease
timeout for the associated IP address and/or the hardware address of
the intervening subscriber modem.
Joshi & Kurapati Expires February 5, 2007 [Page 4]
Internet-Draft Extension of DHCP Leasequery August 2006
o "MAC address"
In the context of a DHCP packet, a MAC address consists of the
following fields: hardware type "htype", hardware length "hlen", and
client hardware address "chaddr".
o "Transparent Bridge"
A device which does bridging based on MAC learning principles.
Bridge learns the Source MAC of the incoming frames and updates a
table with MAC/Interface information. While forwarding data packets,
bridge looks at this table to find the outgoing interface.
o "upstream"
Upstream is the direction from the broadband subscriber towards the
edge network.
Joshi & Kurapati Expires February 5, 2007 [Page 5]
Internet-Draft Extension of DHCP Leasequery August 2006
3. Typical layer 2 access network
Figure 1 shows a typical access network where the Access Concentrator
acts as a traditional Transparent Bridge. In a typical layer 2
access network, multiple hosts may be connected to each port. These
hosts use DHCP to receive User/Host Specific configuration details.
Access concentrator snoops DHCP requests and append relay agent
information before bridging them to the upstream Layer-3 Relay Agent.
A DHCP server may use the Relay Agent information to apply policies
for allocation of specific configuration details like IP address etc.
+-------------+
| DHCP Server |
+--+----------+
|
---+---+-------- LAN
| +------------+
| | |------------- user#1
+------+----------+ VLAN | Access |------------- user#1
| Layer-3 Relay |----------|Concentrator| :
| Agent | | (Bridge) | :
+-----------------+ | |------------- user#n
+------------+
Figure 1
3.1. Access Concentrator acting as Layer 2 DHCP relay agent
In access networks, Access Concentrator acting as Transparent Bridge
can also act as a Layer 2 DHCP Relay Agent. In figure 1, Layer-3
Relay Agent can not correctly identify the end hosts so Access
Concentrator needs to append Relay Agent Information [option 82] to
each DHCP packet before forwarding it to Layer-3 Relay Agent. When a
DHCP reply is received, Access concentrator uses the Relay Agent
option [option 82] to identify the outgoing interface. Access
Concentrator removes the Relay Agent option before forwarding DHCP
reply to end hosts.
In layer 2 mode, Access Concentrator does not set the "giaddr" field
in the DHCP request before it forwards the request to DHCP server.
When the Layer-3 Relay Agent receives a DHCP packet from the Access
Concentrator with Relay Agent option already added, it should
populate the giaddr field and relay that packet to the DHCP servers.
This process is inline with RFC 3046 [3] which says that if the DHCP
packet is from a trusted entity, Relay Agent MUST add the "giaddr"
field before forwarding the DHCP request to DHCP server. Layer-3
Joshi & Kurapati Expires February 5, 2007 [Page 6]
Internet-Draft Extension of DHCP Leasequery August 2006
Relay Agent SHOULD set the "giaddr" field with the IP address of the
interface on which the DHCP request is received.
When DHCP server reply to such a DHCP request, it sets the
destination IP address in IP header to the "giaddr" value. When
Layer-3 Relay Agent receives the DHCP reply, it identifies the
outgoing interface based on the destination IP address in the DHCP
reply. Layer-3 Relay Agent does not remove the DHCP Relay Agent
option and forwards the DHCP reply to the Access Concentrator.
Access Concentrator snoops the DHCP reply message, removes the Relay
Agent option and identifies the outgoing interface based on the
details in Relay Agent option [3].
Joshi & Kurapati Expires February 5, 2007 [Page 7]
Internet-Draft Extension of DHCP Leasequery August 2006
4. Protocol Extension Overview
4.1. Lease/Location information in layer 2 Networks
An Access Concentrator snoops all DHCP messages and maintains the
information of outgoing interface, MAC Address, IP address and Lease
information for each DHCP Client. This information [MAC-IP-Interface
Binding] MAY be used to prevent MAC/IP Spoofing attacks and MAY also
be used for bridging frames.
4.2. Extension of DHCPLEASEQUERY in layer 2 Networks
Access Concentrator acting as Transparent Bridge typically maintains
lease/location information for all DHCP clients. This makes it
vulnerable to the same issue [location/lease information lost when
Access Concentrator gets rebooted] which has been addressed in RFC
4388 [4] for Layer 3 networks. This document extends mechanism
proposed in [4] to address this issue for layer 2 networks.
When Access Concentrator needs to bridge a frame, it MAY refer to
location/lease information to verify the IP address or MAC address.
If the location/lease information is not available, Access
Concentrator can query DHCP server to obtain the lease/location
information using DHCPLEASEQUERY message.
Access Concentrator can generate a DHCPLEASEQUERY [Query by IP
address, MAC address or client identifier [7]] with all the fields
properly populated as defined in RFC 4388 [4].
When Layer-3 Relay Agent receives a DHCPLEASEQUERY, before forwarding
it to DHCP server, it MUST populate the "giaddr" field with the IP
address of the interface on which the request has been received.
Layer-3 Relay Agent should forward this DHCPLEASEQUERY to a
particular DHCP server, if it knows which DHCP server might possess
location/lease information for the given IP address or it should send
it to all the DHCP servers configured in the Layer-3 Relay Agent.
DHCP reply message for DHCPLEASEQUERY would have destination IP
address as the IP address mentioned in "giaddr" field of DHCP
request. DHCP server also appends Relay Agent option in the DHCP
reply. When Layer-3 Relay Agent processes the DHCP reply, it
identifies the outgoing interface based on the destination IP address
of the DHCP reply message.
Access Concentrator receives the DHCP reply and can retrieve the
location/lease information from the reply message.
Joshi & Kurapati Expires February 5, 2007 [Page 8]
Internet-Draft Extension of DHCP Leasequery August 2006
5. Protocol Extension Details
5.1. Definition required for extension of DHCPLEASEQUERY message
The extension of DHCP Leasequery to switched/bridged networks
requires the definition of following new option for DHCP packet
beyond those defined by [RFC2131] and [RFC2132]. See also Section 7,
IANA Considerations.
1. There is a new option "access-concentrator-hwaddr":
access-concentrator-hwaddr
This option allows a Layer 3 Relay agent to unicast a DHCP
reply for a DHCPLEASEQUERY message to the Access Concentrator
which had generated the DHCPLEASEQUERY message.
The code for this option need to be allocated by IANA. The
length of this option is 18.
code len [Hardware address details]
+------+------+------------+----------+-------------+
| X | 18 | htype (1) | hlen (1) | hwaddr (16) |
+------+------+------------+----------+-------------+
In the above option:
o 'X' need to be allocated by IANA.
o "htype" represents Hardware address type, see ARP section
in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet.
o "hlen" represents Hardware address length (e.g. '6' for
10mb ethernet)
o "hwaddr" is Access Concentrator hardware address.
5.2. Generating DHCPLEASEQUERY Message
When a data packet is received from a host, Access Concentrator MAY
verify if it has location/lease information for the source IP address
or source MAC address of data packet received. Similarly when Access
Concentrator receives a data packet from upstream interface, it MAY
verify location/lease information for the destination IP address or
destination MAC address of the data packet. An Access Concentrator
would typically generate DHCPLEASEQUERY message if the location/lease
information is not available for the corresponding IP address or MAC
address assuming that it has lost the location/lease information
Joshi & Kurapati Expires February 5, 2007 [Page 9]
Internet-Draft Extension of DHCP Leasequery August 2006
during last reboot. The DHCPLEASEQUERY message uses the DHCP message
format as described in RFC 2131 [2], and uses message number 10 in
the DHCP Message Type option (option 53). The DHCPLEASEQUERY message
has the following pertinent message contents:
o "giaddr" field MUST not be set. Though RFC 4388 mandates that an
Access Concentrator [in layer 3 mode] MUST set the "giaddr" field,
this document suggest that an Access Concentrator acting as
Transparent Bridge MUST not set the "giaddr" field.
o Access concentrator which can receives a unicast reply for
DHCPLEASEQUERY message SHOULD add option "access-concentrator-
hwaddr" in DHCPLEASEQUERY message. Option "access-concentrator-
hwaddr" SHOULD be populated based on the interface on which this
request is sent out. This option MUST be added as the last option
[but before 'End Option' 255] in the DHCPLEASEQUERY message.
o TTL value in IP header MUST be set to 1. This is to make sure
that this packet is not forwarded beyond the Access Concentrator's
LAN.
o The Parameter Request List option (option 55) MUST include the
Relay Agent Information option (option 82).
o All the other options in Parameter Request List option (option 55)
SHOULD be set as per the interest of the requester. The
interesting options are likely to include the IP Address Lease
Time option (option 51) and possibly the Vendor class identifier
option (option 60).
o Source IP address of the DHCPLEASEQUERY message MUST be set to
0.0.0.0.
o Destination IP address of the DHCPLEASEQUERY message MUST be set
to broadcast address 255.255.255.255.
o Destination MAC address of the DHCPLEASEQUERY message MUST be set
to FF:FF:FF:FF:FF:FF.
o Source MAC address of the DHCPLEASEQUERY message MUST be set to
the hardware address of the interface on which this request is
sent out.
All other fields in MAC header, IP header and DHCP header SHOULD be
set as per RFC 2131 [2]. Additional details concerning different
query types are same as defined in RFC 4388 [4].
Joshi & Kurapati Expires February 5, 2007 [Page 10]
Internet-Draft Extension of DHCP Leasequery August 2006
5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent
A Layer-3 Relay Agent conforming to this document, MUST process the
DHCP LEASEQUERY message received on its downstream interface. While
processing a DHCPLEASEQUERY message, it MUST verify following:
o If "giaddr" field is already set, "giaddr" field is not touched
and the DHCP request is forwarded as per [2].
o TTL value in IP header MUST be 1. If it is any other value, this
packet MUST be silently discarded.
After verifying the received DHCPLEASEQUERY request packet, Relay
Agent should modify the DHCPLEASEQUERY request packet. The
DHCPLEASEQUERY message has the following pertinent message contents:
o "giaddr" field MUST be set to the primary IP address of the
interface on which this DHCPLEASEQUERY request has been received.
o No other fields in DHCP header needs to be changed.
o Source IP address of IP header MAY be set to either the primary IP
address of the interface on which this DHCPLEASEQUERY request has
been received or to the IP address of the Interface on which this
request will be sent out.
o Destination IP address in IP header MUST be set to the IP address
of the DHCP server.
o Rest of the fields in IP header and DHCP header should be set as
per [2].
In Layer-3 environment, RFC 4388 does not recommend how to set the
"giaddr" field in DHCPLEASEQUERY message. While generating a
DHCPLEASEQUERY message, a Layer-3 Relay Agent conforming to this
document MUST always set the "giaddr" field to the primary IP address
of the interface on which DHCPLEASEQUERY message will be sent. As
described above, while receiving a DHCP reply, this helps Layer-3
Relay Agent to identify if it had generated a DHCPLEASEQUERY message
or relayed it from an Access Concentrator.
5.4. Handling DHCPLEASEQUERY Message in DHCP Server
DHCP servers conforming to this document MUST echo the entire
contents of the "access-concentrator-hwaddr" option [code 'X'] in the
reply. DHCP servers SHALL NOT place the echoed "access-concentrator-
hwaddr" option in the overloaded sname or file fields. If a server
is unable to copy a full "access-concentrator-hwaddr" option into a
Joshi & Kurapati Expires February 5, 2007 [Page 11]
Internet-Draft Extension of DHCP Leasequery August 2006
response, it SHALL send the response without the "access-
concentrator-hwaddr" option, and SHOULD increment an error counter
for the situation.
This document does not propose any other changes to RFC 4388 [4]. for
handling DHCPLEASEQUERY message in DHCP server.
5.5. Handling DHCP Reply Message in Layer-3 Relay Agent
When Layer-3 Relay Agent receives a DHCP Reply message with message
type as DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN, it
first verifies the destination IP address. Following options are
considered:
o If the destination IP address of the DHCP reply packet is same as
the primary IP address of the interface this reply has been
received, it is assumed that this request was generated by the
Layer-3 Relay Agent. So it should not forward this DHCP Reply
message.
o If the destination IP address of the DHCP reply packet is same as
the primary IP address of any of the outgoing interfaces except
the one on which the reply was received, it is assumed that the
request was generated by an Access Concentrator and so Layer-3
Relay Agent should forward this Reply message. Outgoing interface
for the DHCP reply would be the one which has the same IP address
as the destination IP address.
Layer-3 Relay Agent will need to make following modification in DHCP
reply before forwarding it to the Access Concentrator:
o It MUST reset the "giaddr" field before forwarding the DHCP reply
to Access Concentrator.
o It SHOULD modify the source IP address of the DHCP reply to either
0.0.0.0 or to the IP address of the outgoing interface.
o It SHOULD modify the destination IP address of the DHCP reply to
255.255.255.255.
o It MUST look for "access-concentrator-hwaddr" option [code 'X'] in
the DHCP reply and if it finds this option, it MUST extract the
hardware address and use it to unicast the reply to the Access
Concentrator. If it does not find this option, it SHOULD
broadcast this reply over the outgoing interface identified as
above.
Joshi & Kurapati Expires February 5, 2007 [Page 12]
Internet-Draft Extension of DHCP Leasequery August 2006
5.6. Handling DHCP Reply Message in Access Concentrator
5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message
When a DHCPLEASEUNASSIGNED message is received by Access
Concentrator, that means that there is no currently active lease for
the IP address present in the DHCP server, but that a server does in
fact manage that IP address. Access Concentrator SHOULD cache this
information for later use.
5.6.2. Handling DHCPLEASEUNKNOWN Reply Message
When a DHCPLEASEUNKNOWN message is received by Access Concentrator,
it SHOULD cache this information but only for a short lifetime,
approximately for 5 minutes as suggested in RFC 4388 [4].
5.6.3. Handling DHCPLEASEACTIVE Reply Message
When Access Concentrator receives a DHCPLEASEACTIVE message, it MUST
update its location/lease information.
5.6.4. Handling No Response to the DHCPLEASEQUERY Message
This has been discussed in detail in RFC 4388 [4] and the same holds
good for this document as well.
5.6.5. Handling DHCPLEASEQUERY messages not belonging to Access
Concentrator
o Since Layer 3 Relay Agent can broadcast the reply of
DHCPLEASEQUERY message, it will be processed by all the Access
Concentrators connected to the same LAN. Using Relay Agent
Information Option, an Access Concentrator should be able to
correctly identify if the DHCPLEASEQUERY response is meant for
itself. Responses which does not belong to an Access Concentrator
MUST be silently discarded.
o In a typical bridged network, multiple Access Concentrators may
share the same LAN. As DHCPLEASEQUERY message generated by an
Access Concentrator is broadcast, it will be received by other
Access Concentrators also. Access Concentrators MUST silently
discard any DHCPLEASEQUERY message received on its upstream
interface.
Joshi & Kurapati Expires February 5, 2007 [Page 13]
Internet-Draft Extension of DHCP Leasequery August 2006
6. Security Consideration
o Access Networks flood traffic to all the ports if the destination
MAC is not present in MAC Learning table. The lease/location
information obtained by snooping the DHCP messages and refreshed
using DHCPLEASEQUERY mechanism, can be used to prevent this
flooding.
o If a Layer 2 Relay Agent, Layer 3 Relay Agent or DHCP server does
not support the new option "access-concentrator-hwaddr", a Layer 3
Relay Agent would broadcast the response of the DHCPLEASEQUERY to
the Access Concentrator. This response will be processed by all
the Access Concentrators on the same LAN. This increases
unnecessary cpu processing on the Access Concentrator on the same
LAN.
o All other security aspects are same as mentioned in "Security
Consideration" section of RFC 4388 [4].
Joshi & Kurapati Expires February 5, 2007 [Page 14]
Internet-Draft Extension of DHCP Leasequery August 2006
7. IANA Considerations
This document needs IANA to provide a unique number for the new
option to carry Hardware address of an Access Concentrator. Please
refer to section 5.1 for more details.
Joshi & Kurapati Expires February 5, 2007 [Page 15]
Internet-Draft Extension of DHCP Leasequery August 2006
8. Acknowledgments
Andre Kostur provided good feedback on this memo. A detailed
discussion with Ted Lemon, Andre Kostur, Stefaan and David W.
Hankinson on how a Layer 3 Relay Agent can unicast the DHCP reply to
an Access Concentrator was very helpful.
Joshi & Kurapati Expires February 5, 2007 [Page 16]
Internet-Draft Extension of DHCP Leasequery August 2006
9. References
9.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[4] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol
(DHCP) Leasequery", RFC 4388, February 2006.
9.2. Informative Reference
[5] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
September 1985.
[6] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, October 1993.
[7] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Joshi & Kurapati Expires February 5, 2007 [Page 17]
Internet-Draft Extension of DHCP Leasequery August 2006
Authors' Addresses
Bharat joshi
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: bharat_joshi@infosys.com
URI: http://www.infosys.com/
Pavan Kurapati
Infosys Technologies Ltd.
44 Electronics City, Hosur Road
Bangalore 560 100
India
Email: pavan_kurapati@infosys.com
URI: http://www.infosys.com/
Joshi & Kurapati Expires February 5, 2007 [Page 18]
Internet-Draft Extension of DHCP Leasequery August 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Joshi & Kurapati Expires February 5, 2007 [Page 19]