DHC Working Group B. Joshi
Internet-Draft P. Kurapati
Expires: December 10, 2006 Infosys Technologies Ltd.
June 8, 2006
Extension of DHCP LEASEQUERY in Bridging/Switching networks
draft-joshi-dhcp-lease-query-ext-00.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 December 10, 2006.
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 December 10, 2006 [Page 1]
Internet-Draft Extension of DHCP LEASEQUERY June 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 DHCP LEASEQUERY in layer 2 Networks . . . . . 8
5. Protocol Extension Details . . . . . . . . . . . . . . . . . . 9
5.1. Generating DHCP LEASEQUERY Message . . . . . . . . . . . . 9
5.2. Handling DHCP LEASEQUERY Message in Layer-3 Relay Agent . 10
5.3. Handling DHCP LEASEQUERY Message in DHCP Server . . . . . 10
5.4. Handling DHCP Reply Message in Layer-3 Relay Agent . . . . 10
5.5. Handling DHCP Reply Message in Access Concentrator . . . . 11
5.5.1. Handling DHCPLEASEUNASSIGNED Reply Message . . . . . . 11
5.5.2. Handling DHCPLEASEUNKNOWN Reply Message . . . . . . . 11
5.5.3. Handling DHCPLEASEACTIVE Reply Message . . . . . . . . 12
5.5.4. Handling No Response to the DHCPLEASEQUERY Message . . 12
5.5.5. Handling DHCP messages not belonging to Access
Concentrator . . . . . . . . . . . . . . . . . . . . . 12
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 15
8.2. Informative Reference . . . . . . . . . . . . . . . . . . 15
Appendix A. Layer-3 Relay Agent forwarding DHCP reply using
Unicast . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Joshi & Kurapati Expires December 10, 2006 [Page 2]
Internet-Draft Extension of DHCP LEASEQUERY June 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 December 10, 2006 [Page 3]
Internet-Draft Extension of DHCP LEASEQUERY June 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 December 10, 2006 [Page 4]
Internet-Draft Extension of DHCP LEASEQUERY June 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 December 10, 2006 [Page 5]
Internet-Draft Extension of DHCP LEASEQUERY June 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 typically 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"
Joshi & Kurapati Expires December 10, 2006 [Page 6]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
field before forwarding the DHCP request to DHCP server. Layer-3
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 December 10, 2006 [Page 7]
Internet-Draft Extension of DHCP LEASEQUERY June 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 DHCP LEASEQUERY 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 DHCP LEASEQUERY message.
Access Concentrator can generate a DHCP LEASEQUERY [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 December 10, 2006 [Page 8]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
5. Protocol Extension Details
5.1. Generating DHCP LEASEQUERY 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 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 assuming that it has lost
the location/lease information during last reboot. The DHCP
LEASEQUERY 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 DHCP LEASEQUERY 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 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 DHCP LEASEQUERY message MUST be set to
0.0.0.0.
o Destination IP address of the DHCP LEASEQUERY message MUST be set
to broadcast address 255.255.255.255.
o Source MAC address of the DHCP LEASEQUERY message MUST be set to
00:00:00:00:00:00.
o Destination MAC address of the DHCP LEASEQUERY message MUST be set
to FF:FF:FF:FF:FF:FF.
Joshi & Kurapati Expires December 10, 2006 [Page 9]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
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].
5.2. Handling DHCP LEASEQUERY 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 DHCP LEASEQUERY 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 DHCP LEASEQUERY request packet, Relay
Agent should modify the DHCP LEASEQUERY request packet. This
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 DHCP LEASEQUERY 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 DHCP LEASEQUERY request has
been received or to the IP address of the Interface on which this
request will be sent out.
o Destination IP address of IP header MUST be set to either the IP
address of the DHCP server [if Relay Agent can map the IP address
in ciadd field to a DHCP server] or to the broadcast IP address
[255.255.255.255]
o Rest of the fields in IP header and DHCP header should be set as
per [2].
5.3. Handling DHCP LEASEQUERY Message in DHCP Server
This document does not propose any changes to RFC 4388 [4]. for
handling DHCP LEASEQUERY message in DHCP server.
5.4. 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
Joshi & Kurapati Expires December 10, 2006 [Page 10]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
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 would need to 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 would also need to modify the destination IP address of the
DHCP reply to 255.255.255.255.
o It SHOULD broadcast this reply over the outgoing interface
identified as above.
5.5. Handling DHCP Reply Message in Access Concentrator
5.5.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.5.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].
Joshi & Kurapati Expires December 10, 2006 [Page 11]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
5.5.3. Handling DHCPLEASEACTIVE Reply Message
When Access Concentrator receives a DHCPLEASEACTIVE message, it MUST
update its location/lease information.
5.5.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.5.5. Handling DHCP messages not belonging to Access Concentrator
Since the reply to the LEASEQUERY is broadcast over the LAN, it will
be processed by all the Access Concentrators connected to the same
LAN.
o Using option 82 string, an Access Concentrator should be able to
correctly identify if the LEASEQUERY response is meant for itself.
All other responses MUST be discarded silently.
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 December 10, 2006 [Page 12]
Internet-Draft Extension of DHCP LEASEQUERY June 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 message, can be used to prevent this
flooding.
o Since the response of the DHCP LEASEQUERY is broadcast to the
Access Concentrator, the 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. One
solution to address this issue is suggested in Appendix A.
o All other security aspects are same as mentioned in "Security
Consideration" section of RFC 4388 [4].
Joshi & Kurapati Expires December 10, 2006 [Page 13]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
7. IANA Considerations
This document does not introduce any new namespaces for the IANA to
manage.
Joshi & Kurapati Expires December 10, 2006 [Page 14]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
8. References
8.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.
8.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 December 10, 2006 [Page 15]
Internet-Draft Extension of DHCP LEASEQUERY June 2006
Appendix A. Layer-3 Relay Agent forwarding DHCP reply using Unicast
Layer-3 Relay Agent broadcasts all DHCP replies received from the
DHCP Server on the LAN where many Access Concentrators MAY be
connected. Since the message is broadcast, all the Access
Concentrators will process the message. In ideal case, only the
Access Concentrator which has generated the LEASEQUERY should process
the DHCP reply. This can be achieved if Edge Router can figure out
the MAC address of the Access Concentrator and unicast the DHCP reply
to that MAC address. For this, Layer-3 Relay Agent MUST either store
this information or extract it from the DHCP reply.
For achieving this, a new suboption called Access-Concentrator-id can
be included in Option 82 which will have the MAC address of the
upstream interface of the Access Concentrator. This option MAY be
sent along with all DHCP messages forwarded by Access Concentrator.
The format of the Relay Agent Information option as defined in RFC
3046 [3] is:
Code Len Agent Information Field
+------+------+------+------+------+------+--...-+------+
| 82 | N | i1 | i2 | i3 | i4 | | iN |
+------+------+------+------+------+------+--...-+------+
New Sub-option will be
SubOpt Len Sub-option Value
+------+------+--------------------+
| X | 6 | MAC Address |
+------+------+--------------------+
Value of X still need to be allocated.
DHCP server appends the option 82 while replying to a DHCPLEASEQUERY
request. Layer-3 Relay Agent should look for this option in Relay
Agent Option and if this Sub Option is available, Layer-3 Relay Agent
SHOULD unicast the reply to the MAC address extracted from this new
Sub Option. In the absence of this sub option, Layer-3 Relay Agent
SHOULD broadcast the reply.
This solution has been added in Appendix to generate discussion in
WG. If WG feels that it should be included in the Draft then this
will be added as part of the draft itself.
Joshi & Kurapati Expires December 10, 2006 [Page 16]
Internet-Draft Extension of DHCP LEASEQUERY June 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 December 10, 2006 [Page 17]
Internet-Draft Extension of DHCP LEASEQUERY June 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 December 10, 2006 [Page 18]