[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-dhc-l2ra

DHC Working Group                                               B. Joshi
Internet-Draft                                               P. Kurapati
Expires: May 13, 2008                          Infosys Technologies Ltd.
                                                       November 10, 2007


                    Layer 2 Relay Agent Information
                      draft-joshi-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 May 13, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 closest Layer 2



Joshi & Kurapati          Expires May 13, 2008                  [Page 1]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


   device 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Need of Layer 2 Relay Agent  . . . . . . . . . . . . . . . . .  5
   4.  Layer 2 Relay Agent in various network scenarios . . . . . . .  6
     4.1.  DHCP server and client on same subnet  . . . . . . . . . .  6
       4.1.1.  Client-server interaction  . . . . . . . . . . . . . .  6
       4.1.2.  Issues due to introduction of Layer 2 Relay Agent  . .  8
     4.2.  Multiple DHCP server and Client on same subnet . . . . . .  8
       4.2.1.  Client-server interaction  . . . . . . . . . . . . . .  9
       4.2.2.  Issues due to introduction of Layer 2 Relay Agent  . .  9
     4.3.  DHCP server on another subnet with one Layer 3 Relay
           Agent  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       4.3.1.  Client-server interaction  . . . . . . . . . . . . . . 10
       4.3.2.  Issues due to introduction of Layer 2 Relay Agent  . . 10
   5.  Enhancements in Layer 2 Relay Agent  . . . . . . . . . . . . . 12
     5.1.  Broadcasting DHCP requests on all ports  . . . . . . . . . 12
     5.2.  A Layer 3 Relay Agent broadcasting a DHCP reply  . . . . . 12
     5.3.  Maintaining Lease Information by Layer 2 Relay Agent . . . 12
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Consideration . . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18
















Joshi & Kurapati          Expires May 13, 2008                  [Page 2]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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 a IP routing aware device and sometimes are referred as
   Layer 3 Relay Agent.

   In some networks, 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 confiured 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 issues that are
   involved.






























Joshi & Kurapati          Expires May 13, 2008                  [Page 3]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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 May 13, 2008                  [Page 4]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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 postion to
       provide a unique Relay Agent Information option to enforce
       policies in DHCP server.  Some existing implementation intercepts
       only broadcast messages while some of them intercepts unicast
       messages as well.  If a Layer 2 Relay Agent intercepts a DHCP
       message, it appends Relay Agent Information option in DHCP
       message and forwards it.

   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.
























Joshi & Kurapati          Expires May 13, 2008                  [Page 5]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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 handlded 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 May 13, 2008                  [Page 6]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


       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.  If the device is not configured as Layer 2 Relay
       Agent, it will switch/bridge the message normally.

   3.  Server responds with a DHCPOFFER message that includes an
       available network address in the 'yiaddr' field (and other
       configuration parameters in DHCP options).  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 usually identify the outgoing port
       using Relay Agent Information option.  If the broadcast bit is
       clear, it unicasts this message to the identified port otherwise
       broadcasts it to all the ports except from which this reply
       message was received.

   4.  Same DHCPOFFER message will be received by the other Layer 2
       Device [#2].  If it is configured as Layer 2 Relay Agent, it
       broadcast this message normally.  This is because it can find out
       that it had not forwarded the DHCPDISCOVER request.  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
       intercepts this unicast message and remove Relay Agent
       Information option.  It usually identify the outgoing port using
       Relay Agent Information option.  If the broadcast bit is clear,
       it unicasts this message to the identified port otherwise
       broadcast it to all the ports except from which this reply
       message was received.



Joshi & Kurapati          Expires May 13, 2008                  [Page 7]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


   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 messages similar to DHCPDISCOVER message.

   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 intercepts 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 but the 'giaddr'
       field in the message is not set.  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 May 13, 2008                  [Page 8]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


   +--------+
   | 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 L2RA #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/to one subnet to/from the DHCP
   server on another subnet.  In access network scenarios, its seen that
   Access Concentrator works as Layer 2 Relay Agent.






Joshi & Kurapati          Expires May 13, 2008                  [Page 9]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


   +--------+
   | 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.

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 case, a Layer 3 Relay Agent may use
       unnumbered interfaces.  In this case, it has to use a system wide



Joshi & Kurapati          Expires May 13, 2008                 [Page 10]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


       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 intercepts 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 May 13, 2008                 [Page 11]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


5.  Enhancements in Layer 2 Relay Agent

   This section looks at various possible enhancements in Layer 2 Relay
   Agents.  These enhancements is aimed in increasing the flexibility
   and efficiency of Layer 2 Relay Agent in general.

5.1.  Broadcasting DHCP requests on all ports

   A normal Layer 2 Relay Agent would broadcast a DHCP request message
   to all its port except on which the message was received.  Because of
   this, a DHCP request message is received by those devices which would
   not be interested in it.  A configuration of uplink port that leads
   to a Layer 3 Relay Agent or DHCP server can solve this issue.  Some
   of the existing implementation [Mostly in xDSL Access Concentrators]
   already supports this.

5.2.  A Layer 3 Relay Agent broadcasting a DHCP reply

   In most of the cases, a Layer 3 Relay Agent would broadcast a DHCP
   reply.  This will again be received by those devices which would not
   be interested in it.  A new sub-option in Relay Agent Information
   option can solve this issue.

5.3.  Maintaining Lease Information by Layer 2 Relay Agent

   A Layer 2 Relay Agent may maintain the lease information.  This
   information is lost if the Layer 2 Relay Agent reboots.  DHCPv4
   Leasequery can be extended to solve this issue.























Joshi & Kurapati          Expires May 13, 2008                 [Page 12]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


6.  Acknowledgments

   This document is the result of a discussion on DHC WG mailing list.
   David W. Hankins and Michael Wacker provided inputs on some of the
   existing implementations.














































Joshi & Kurapati          Expires May 13, 2008                 [Page 13]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


7.  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 May 13, 2008                 [Page 14]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


8.  IANA Considerations

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















































Joshi & Kurapati          Expires May 13, 2008                 [Page 15]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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

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

9.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 May 13, 2008                 [Page 16]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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 May 13, 2008                 [Page 17]


Internet-Draft       Layer 2 Relay Agent Information       November 2007


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, 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.


Copyright Statement

   Copyright (C) The IETF Trust (2007).  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 May 13, 2008                 [Page 18]


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