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]