[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-joshi-dhc-l2ra) 00 01 02 03 04 05 06

DHC Working Group                                               B. Joshi
Internet-Draft                                               P. Kurapati
Expires: July 31, 2008                         Infosys Technologies Ltd.
                                                        January 28, 2008


                    Layer 2 Relay Agent Information
                       draft-ietf-dhc-l2ra-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 July 31, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).














Joshi & Kurapati          Expires July 31, 2008                 [Page 1]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


Abstract

   In some networks, DHCP servers rely on Relay Agent Information option
   appended by Relay Agents for IP address and other parameter
   assignment policies.  This works fine when end hosts are directly
   connected to Relay Agents.  In some network configurations, one or
   more Layer 2 devices may reside between DHCP clients and Relay agent.
   In these network scenarios, it is difficult to use the Relay Agent
   Information option for IP address and other parameter assignment
   policies effectively.  So there is a need for the device that is
   closest to the end hosts to append Relay Agent Information option in
   DHCP messages.  These devices are typically known as Layer 2 Relay
   Agents.

   This document aims to describe the network scenarios where Layer 2
   Relay Agent is in use and also how it handles DHCP messages.



































Joshi & Kurapati          Expires July 31, 2008                 [Page 2]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Need of Layer 2 Relay Agent  . . . . . . . . . . . . . . . . .  6
   4.  Layer 2 Relay Agent in various network scenarios . . . . . . .  7
     4.1.  DHCP server and client on same subnet  . . . . . . . . . .  7
       4.1.1.  Client-server interaction  . . . . . . . . . . . . . .  7
       4.1.2.  Issues due to introduction of Layer 2 Relay Agent  . .  9
     4.2.  Multiple DHCP server and Client on same subnet . . . . . .  9
       4.2.1.  Client-server interaction  . . . . . . . . . . . . . . 10
       4.2.2.  Issues due to introduction of Layer 2 Relay Agent  . . 10
     4.3.  DHCP server on another subnet with one Layer 3 Relay
           Agent  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.3.1.  Client-server interaction  . . . . . . . . . . . . . . 11
       4.3.2.  Issues due to introduction of Layer 2 Relay Agent  . . 12
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Consideration . . . . . . . . . . . . . . . . . . . . 15
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19



























Joshi & Kurapati          Expires July 31, 2008                 [Page 3]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


1.  Introduction

   DHCP Relay Agents eliminate the necessity of having a DHCP server on
   each physical network.  Relay Agents populate the 'giaddr' field as
   they deem appropriate and also add 'Relay Agent Information' option
   to the DHCP messages.  DHCP servers use this option for IP address
   and other parameter assignment policies.  These DHCP Relay Agents are
   typically an IP routing aware device and are referred as Layer 3
   Relay Agents.

   In some network configurations, there is a need for Layer 2 devices
   to add Relay Agent Information option as they are closer to the end
   hosts.  These Layer 2 devices can not relay the message to the DHCP
   servers as they are typically configured in bridging mode.  These
   Layer 2 devices append the Relay Agent Information option and
   broadcast the DHCP message.  A Layer 3 Relay Agent relays it to the
   DHCP server.

   This document provides information about where a Layer 2 Relay Agent
   fits in and how it is used.  This document also looks at various
   network scenarios with Layer 2 Relay Agent and discusses various
   issues caused by introduction of Layer 2 Relay Agent.





























Joshi & Kurapati          Expires July 31, 2008                 [Page 4]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


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  "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 [6] and RFC1542[7].

   o  "DHCP server"

   A DHCP server is an Internet host that returns configuration
   parameters to DHCP clients.

   o  "Unnumbered Interfaces"

   An interface with no IP address associated with it.  IP packets
   received on this interface will be processed like any other numbered
   IP interface.  It may use a local IP address while generating IP
   packets.





















Joshi & Kurapati          Expires July 31, 2008                 [Page 5]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


3.  Need of Layer 2 Relay Agent

   A Layer 2 device intercepts DHCP messages for following reasons:

   1.  In some network deployments like xDSL, the subscriber aggregation
       devices (also known as Access Concentrator or a DSLAM in case of
       DSL) are configured to act as bridges.  As these devices are
       closest to the subscriber, they are in the best position to
       provide a unique Relay Agent Information option to enforce
       policies in DHCP server.

   2.  In some networks, the Layer 2 Switch which is closest to the end
       users, snoops the DHCP messages.  These switches extract DHCP
       Lease Information and use this information to install packet
       filters.  This helps in preventing the Layer 2 and Layer 3
       spoofing attempts by the subscribers.  A point to note here is
       that in cases where switches maintain the Lease Information, they
       have to intercept unicast DHCP messages as well to keep this
       information upto date.

   3.  NOTE: Please send an email to the authors if you are aware of any
       other functionality of Layer 2 Relay Agent.  It will be helpful
       in updating this list.  This note will be removed before moving
       it for IESG review.



























Joshi & Kurapati          Expires July 31, 2008                 [Page 6]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


4.  Layer 2 Relay Agent in various network scenarios

   This section describes the various network scenarios where a Layer 2
   Relay Agent fits in.  It also describes how it handles different DHCP
   messages.

4.1.  DHCP server and client on same subnet

   In certain network configurations, DHCP server may reside on the same
   subnet as the DHCP clients.  A Layer 2 aggregation device resides
   between the DHCP clients and DHCP server.  Following points describe
   how this Layer 2 device handles various DHCP messages if it acts as a
   Layer 2 Relay Agent.  Figure #1 shows a typical network setup.


   +--------+
   | End    |           +--------+     |
   | Host#1 +-----------|        |     |     +-----------+
   +--------+           | Layer  +-----|     |           |
                        |   2    |     +-----| DHCP      |
   +--------+           | device |     |     | Server#1  |
   | End    +-----------|  #1    |     |     +-----------+
   | Host#2 |           +--------+     |
   +--------+                          |
                                       |
   +--------+                          |
   | End    |           +--------+     |
   | Host#3 +-----------|        |     |
   +--------+           | Layer  +-----|
                        |   2    |     |
   +--------+           | device |     |
   | End    +-----------|  #2    |
   | Host#n |           +--------+
   +--------+


                                 Figure 1

4.1.1.  Client-server interaction

   The following summary of protocol message exchanges between clients
   and DHCP servers describes how they are handled in Layer 2 Relay
   Agent.

   1.  The client [End Host #1] broadcasts a DHCPDISCOVER message on its
       local physical subnet.  Layer 2 Relay Agent [#1] intercepts this
       message, appends Relay Agent Information option and broadcasts it
       to all the ports except on which it was received.  Relay Agent



Joshi & Kurapati          Expires July 31, 2008                 [Page 7]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


       Information option could be created as suggested in RFC 3046[3].
       Layer 2 Relay Agent does not set the 'giaddr' field.

   2.  Layer 2 device [#2] would also receive this DHCPDISCOVER message
       from Layer 2 device [#1].  If it is configured as Layer 2 Relay
       Agent, it intercepts this message but does not add another Relay
       Agent Information option to the message.  It may discard this
       message if it is coming from an untrusted entity.  Otherwise, it
       will broadcast this on all the ports except on which the message
       was received.

   3.  Server responds with a DHCPOFFER message after applying its local
       policies.  DHCP server echoes back the Relay Agent Information
       option in the DHCPOFFER message.  Layer 2 Relay Agent intercepts
       this message and removes the Relay Agent Information option.  It
       identifies the outgoing port using Relay Agent Information option
       and forwards to the identified interface.

   4.  Same DHCPOFFER message will be received by the other Layer 2
       Device [#2].  If it is configured as Layer 2 Relay Agent, it
       broadcasts this message normally without removing the Relay Agent
       option since it had not added the same.  A Layer 2 Relay Agent
       uses the Relay Agent Information option to find out if it had
       appended it to the request message.

   5.  The client receives this DHCPOFFER message and it broadcasts a
       DHCPREQUEST message that contains the 'server identifier' option
       to indicate the server it has selected.  Layer 2 Relay Agent [#1]
       handles this message similar to how it handles DHCPDISCOVER
       message.

   6.  The server receives the DHCPREQUEST message from the client and
       responds with a DHCPACK message containing the configuration
       parameters for the requesting client.  A DHCP server may unicast
       the DHCPACK message if the broadcast bit in the DHCPREQUEST
       message is not set.  DHCP server would echo back the Relay Agent
       Information option in the reply message.  A Layer 2 Relay Agent
       may intercept this unicast message and process it similar to the
       DHCPOFFER message.

   7.  A server that is unable to satisfy the DHCPREQUEST message,
       responds with DHCPNACK.  Layer 2 Relay Agent process this similar
       to DHCPACK message.

   8.  The client receives the DHCPACK message with configuration
       parameters.  If client detects that the address is already in
       use, it sends a DHCPDECLINE message to the server.  Layer 2 Relay
       Agent process this message similar to DHCPDISCOVER message.



Joshi & Kurapati          Expires July 31, 2008                 [Page 8]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


   9.  When client knows the address of a DHCP server, it may unicast
       DHCPDISCOVER, DHCPREQUEST messages to the server.  DHCP clients
       unicast the DHCP messages like DHCPRELEASE and DHCPREQUEST when
       renewing the lease to the DHCP server.  Layer 2 Relay Agent may
       or may not intercept these messages based on internal
       configuration.  If Layer 2 Relay Agents intercept these messages,
       they append Relay Agent Information option and forward it towards
       the DHCP server.  They also intercept the reply messages and
       remove Relay Agent Information option before forwarding them.

4.1.2.  Issues due to introduction of Layer 2 Relay Agent

   1.  A DHCP server should be able to handle a DHCP message that
       contains the Relay Agent Information option without 'giaddr'
       field set in the message.  Some existing DHCP server
       implementations do not echo back the Relay Agent Information
       option if giaddr is not set.  This may lead to issues at Layer 2
       Relay Agents as they will not be able to identify the outgoing
       port correctly and would broadcast it to all ports.  Some Layer 2
       Relay Agents discard the reply messages if they do not find a
       Relay Agent Information option in a DHCP reply.

   2.  A DHCP server should be able to handle a unicast DHCP message
       containing Relay Agent Information option.  Some existing DHCP
       server implementations do not echo back the Relay Agent
       Information option in DHCP reply messages.

4.2.  Multiple DHCP server and Client on same subnet

   In certain network scenarios, there could be multiple DHCP server on
   the same subnet.  Figure #2 shows a typical network setup.




















Joshi & Kurapati          Expires July 31, 2008                 [Page 9]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


   +--------+
   | End    |           +--------+     |
   | Host#1 +-----------|        |     |     +-----------+
   +--------+           | Layer  +-----|     |           |
                        |   2    |     +-----| DHCP      |
   +--------+           | device |     |     | Server#1  |
   | End    +-----------|  #1    |     |     +-----------+
   | Host#2 |           +--------+     |
   +--------+                          |
                                       |     +-----------+
   +--------+                          |     | DHCP      |
   | End    |           +--------+     |-----| Server #2 |
   | Host#3 +-----------|        |     |     |           |
   +--------+           | Layer  +-----|     +-----------+
                        |   2    |     |
   +--------+           | device |
   | End    +-----------|  #2    |
   | Host#n |           +--------+
   +--------+


                                 Figure 2

4.2.1.  Client-server interaction

   The message exchange are same as explained in 4.1.1.  However, due to
   introduction of multiple DHCP servers the below additional message
   exchanges may happen

   1.  When Host [#1] sends DHCPDISCOVER, it will be received by both
       the DHCP Servers connected to Layer 2 Relay Agent #1 and both the
       servers will respond with a DHCPOFFER.  So instead of one
       DHCPOFFER message, Layer 2 Relay Agent would receive two
       messages.  Processing of DHCP messages in the Layer 2 Relay Agent
       remains the same.

4.2.2.  Issues due to introduction of Layer 2 Relay Agent

   1.  This is same as described in section 4.1.2.

4.3.  DHCP server on another subnet with one Layer 3 Relay Agent

   In certain network scenarios, there could be a Layer 3 Relay Agent
   which relays the DHCP messages from one subnet to DHCP server on
   another subnet and vice versa.  In typical deployments, Access
   Concentrator acts as Layer 2 Relay Agent and IP edge device (BRAS or
   IP Services Switch) acts as Layer 3 Relay Agent.




Joshi & Kurapati          Expires July 31, 2008                [Page 10]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


   +--------+
   | End    |        +--------+     |                   |
   | Host#1 +--------|        |     |  +-----------+    |
   +--------+        | Layer  +-----|  |           |    |
                     |   2    |     +--| Layer 3   |----|
   +--------+        | device |     |  | Relay     |    |
   | End    +--------|  #1    |     |  | Agent #1  |    |
   | Host#2 |        +--------+     |  +-----------+    |  +---------+
   +--------+                       |                   |  |         |
                                    |                   +--| DHCP    |
   +--------+                       |                   |  | Server  |
   | End    |        +--------+     |                   |  |   #1    |
   | Host#3 +--------|        |     |                      +---------+
   +--------+        | Layer  +-----|
                     |   2    |     |
   +--------+        | device |     |
   | End    +--------|  #2    +
   | Host#n |        +--------+
   +--------+



                                 Figure 3

4.3.1.  Client-server interaction

   As far as DHCP message processing is concerned, the presence of Layer
   3 Relay Agent is transparent to Layer 2 Relay Agent.  So all the
   messages are handled in the same way as defined in section 4.1.1 by
   Layer 2 Relay Agent.

   Layer 3 Relay Agent are configured to trust/untrust an entity based
   on a specific criteria (For example : VLAN/interface on which the
   message was received).  If the DHCP messages coming from the client
   has a relay agent option present, Layer 3 Relay Agent checks if it is
   coming on a trusted interface.  If it is coming from a trusted
   interface, it will set the 'giaddr' with one of the local interface
   address and unicasts it to the configured servers.  If the message is
   coming from an untrusted interface Layer 3 Relay Agent discards the
   message.

   Typical message processing in this scenario is given below.

   1.  When client sends a DHCPDISCOVER message, Layer 2 Relay Agent
       forwards it as described in section 4.1.1.  Layer 3 Relay Agent
       receives this message and finds that it contains Relay Agent
       Information option.  It verifies whether the message is from a
       trusted entity or not.  If it is from trusted entity it populates



Joshi & Kurapati          Expires July 31, 2008                [Page 11]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


       the 'giaddr' as it deems appropriate and relay it to the DHCP
       server.

   2.  DHCP Server process the message in the same way as described in
       section 4.1 and will unicast the DHCPOFFER to Layer 3 Relay Agent
       on the address specified in 'giaddr' field.

   3.  Layer 3 Relay Agent process the DHCPOFFER and identifies the
       outgoing interface.  It resets the giaddr and broadcasts the
       message on the identified outgoing interface

   4.  Clients receive DHCPOFFER and generate DHCPREQUEST message.
       Layer 2 Relay Agent process it as described in section 4.1.1.
       Layer 3 Relay Agent receives the DHCPREQUEST message and process
       it similar to the DHCPDISCOVER message described in step #1.

   5.  DHCP Server process the DHCPREQUEST and unicasts the DHCP ACK
       message to layer 3 Relay Agent if 'broadcast' flag is set or
       directly to the client if 'broadcast' flag is not set.  If Layer
       3 Relay Agent receives this message, it will process it similar
       to DHCPOFFER as described in step #3.

   6.  In case of unicast messages [For example: DHCPREQUEST in case of
       DHCPRENEW], a Layer 3 Relay Agent may or may not intercept the
       message.  If it intercepts a unicast DHCP request message, it
       populates the 'giaddr' and relay it to the DHCP server.  When
       DHCP server sends a reply for this request message, it resets the
       'giaddr' field, identifies outgoing interface and forwards the
       reply on the identified interface.

4.3.2.  Issues due to introduction of Layer 2 Relay Agent

   Though the processing of DHCP messages remain the same in Layer 2
   Relay Agent, we see some more issues when a Layer 3 Relay Agent is
   present to relay the DHCP messages to the DHCP server.

   1.  When a Layer 2 Relay Agent is configured to intercept unicast
       messages as well, it appends Relay Agent Information option
       before forwarding them.  A Layer 3 Relay Agent may not intercept
       these unicast messages.  Due to this, a DHCP server may not echo
       back the Relay Agent Information option because the giaddr is not
       populated.

   2.  Existing Layer 3 Relay Agents populate the 'giaddr' with the IP
       address of the interface on which the request was received.  This
       helps Layer 3 Relay Agent to identify the outgoing interface for
       the DHCP replies.  In some cases, a Layer 3 Relay Agent may use
       unnumbered interfaces.  In this case, it has to use a system wide



Joshi & Kurapati          Expires July 31, 2008                [Page 12]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


       IP address to populate the 'giaddr' field.  Due to this, it
       becomes difficult to identify the correct outgoing interface for
       the messages received from the DHCP server.  In these cases, some
       existing Layer 3 Relay Agent implementations maintain an internal
       state for each DHCP messages and use this state to identify the
       outgoing interface.

   3.  DHCP server uses certain parameters to differentiate the RENEW
       and REBIND state of a client.  A DHCP client unicasts a RENEW
       request to the DHCP server, so DHCP server sees a DHCPREQUEST
       without 'giaddr' and Relay Agent Information option as RENEW
       request.  While a REBIND request is broadcast and so DHCP server
       expect it to contain 'giaddr' and Relay Agent Information option.
       If Layer 2 Relay Agent is configured to intercept unicast
       messages, it will append Relay Agent Information option to the
       unicast DHCP messages.  Because of this, it could be difficult
       for DHCP server to differentiate between a RENEWING and REBINDING
       state.

































Joshi & Kurapati          Expires July 31, 2008                [Page 13]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


5.  Acknowledgments

   This document is the result of a discussion on DHC WG mailing list.
   Thanks to David W. Hankins and Michael Wacker for providing inputs on
   some of the existing implementations.  Thanks to Stefaan.De.Cnodder
   and Mukund Kamath for reviewing the draft and providing valuable
   suggestions












































Joshi & Kurapati          Expires July 31, 2008                [Page 14]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


6.  Security Consideration

   o  A Layer 2 Relay Agent should always be configured to identify a
      trustable entity so that it appends Relay Agent Information option
      to DHCP messages coming from this and forward it.  If a DHCP
      message is received from a non-trustable entity, it should discard
      it and may report to the administrator.

   o  Introduction of Layer 2 Relay Agent does not introduce any new
      security issue.  Security issues pertaining to Relay Agents in
      general applies to Layer 2 Relay Agents as well.








































Joshi & Kurapati          Expires July 31, 2008                [Page 15]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


7.  IANA Considerations

   This document does not introduce any new namespaces for the IANA to
   manage.















































Joshi & Kurapati          Expires July 31, 2008                [Page 16]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


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]  Droms, R. and B. Arbaugh, "Authentication for DHCP Messages",
        RFC 3118, June 2001.

   [5]  Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.

8.2.  Informative Reference

   [6]  Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
        September 1985.

   [7]  Wimer, W., "Clarifications and Extensions for the Bootstrap
        Protocol", RFC 1542, October 1993.

   [8]  Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
        Extensions", RFC 2132, March 1997.























Joshi & Kurapati          Expires July 31, 2008                [Page 17]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


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 July 31, 2008                [Page 18]


Internet-Draft       Layer 2 Relay Agent Information        January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Joshi & Kurapati          Expires July 31, 2008                [Page 19]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/