Network Working Group B. Williamson Internet-Draft D. Farinacci Intended status: Informational Cisco Systems Expires: May 15, 2008 S. Venaas UNINETT November 12, 2007 Light-weight Multicast Address Discovery Protocol draft-williamson-mboned-madp-00 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 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Light-weight, multicast address discovery mechanisms that can be used by large scale client-server application deployments have been virtually non-existent in the past. This has resulted in many multicast client-server applications being deployed with "hard-coded" multicast addresses within the client workstations in order to provide "zero-configuration" operation of the application. Williamson, et al. Expires May 15, 2008 [Page 1] Internet-Draft MADP November 2007 Unfortunately, many of these hard-coded multicast addresses are often picked at random by the application developers resulting in multicast address collisions with other protocols/applications or conflicts with the multicast scoping plans of a network administrator. This document describes a "light-weight" multicast address discovery protocol that can be used by application clients to locate their nearest application server using well-known scope relative multicast addresses. Once located, the server can then communicate the multicast address(es) that have been configured on the server by the network administrator for use by the application. This permits applications be written to operate in a flexible "near-zero" configuration mode without having to use "hard-coded" addresses or rely on any other network service other than multicast and the existence of a nearby application server. Requirements Language 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]. Williamson, et al. Expires May 15, 2008 [Page 2] Internet-Draft MADP November 2007 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Type Format . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Types . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 10 3.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 Appendix A. Scenarios . . . . . . . . . . . . . . . . . . . . . 11 Appendix A.1. Scenario 1 . . . . . . . . . . . . . . . . . . . . . 12 Appendix A.2. Scenario 2 . . . . . . . . . . . . . . . . . . . . . 12 Appendix A.3. Summary . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Williamson, et al. Expires May 15, 2008 [Page 3] Internet-Draft MADP November 2007 1. Background The current trend of new (and to some extent old) multicast applications which make use of unconfigurable, hard-coded multicast group addresses is causing problems for network administrators that wish to constrain the "scope" of the application within their networks. A good example of these sorts of applications are software "push" applications that make use of multicast to deploy new and updated software to PC's and workstations within an organization. Often times these applications are already running at various places within the network (usually on a link-local scope) prior to the network administrator deploying IP Multicast in her network. In many cases, the network administrators are not even aware that these applications are in use when they make the decision to deploy multicast within the network. When this happens, the application's scope is no longer link-local in scope and suddenly begins to operate on a network-wide scope; often resulting in network performance problems as well as causing undesired effects to the application itself. In other cases, the network administrator wishes to deploy a new multicast application in a network that already has multicast enabled but wishes to limit the geographical scope of the application. While this can be accomplished with most router vendor equipment, the use of hard-coded multicast addresses by the application generally results in the need to make special exceptions to any carefully crafted Administratively Scoped address plan that has been deployed by the network administrator in order to limit the scope of the application to the desired scope boundary. If the number of deployed hard-coded address applications is small, maintenance of these exceptions to the scoped address plan is manageable. However, there is a growing trend of multicast application developers who use hard-coded multicast addresses in their application which results in an increasing number of exceptions that must be managed which quickly becomes problematic. What is clearly needed by the network administrator is the ability to assign and configure the application with the multicast address(es) appropriate to the desired operational scope of the application without having to reconfigure a large number of routers in the network with exceptions to the currently deployed scoped address plan. On the other hand, application developers frequently need to meet "zero configuration" requirements for their application. This is particularly true in client-server applications (such as the software push applications described previously) to avoid having to configure Williamson, et al. Expires May 15, 2008 [Page 4] Internet-Draft MADP November 2007 each individual client workstation with the multicast address(es) that have been assigned by the network administrator based on the desired application scope. As a result, application developers have tended to make use of hard-coded multicast addresses within their application to accomplish this goal. In some cases (albeit only a few), the application developers apply to IANA in order to get the necessary multicast address(es) assigned. Tragically, many don't even bother with this step and simply make their own assignments using a random, "atmospherical extraction" method of picking the multicast address(es) out of "thin air". These random picks are often made even worse by the application developer making poor multicast address selections such as random addresses from the "Administratively Scoped" address range described in [2] or even worse, multicast addresses that map into MAC address ranges that are always "flooded" by most Layer 2 switches. What is clearly needed here is a mechanism that allows the network administrator to assign/configure the multicast address(es) used by the application so that it operates within the desired geographical scope while at the same time providing the application to be deployed and still meet the "zero configuration" requirement (or at least near-zero configuration) demanded by the application. Several methods have been proposed in the past to accomplish the above including the use of special DNS records to allow the application to "look-up" the multicast addresses that have been configured by the network administrator. Others have proposed the use of MADCAP [3] to accomplish the same goal. Invariably, all of these approaches suffer from the same problem in the eyes of the application developer. That is, their application becomes dependant on some other service being deployed and properly configured in the network in order for the application to be deployed and operate with zero configuration. What is needed instead is a mechanism that can be embedded in the client-server application that is independent of other network services (other than multicast). Thus, the goal of the Multicast Address Discovery Protocol is to provide this independent mechanism whereby the applications multicast address(es) are configured only in the application server(s) which in turn communicates this/these address(es) directly to the clients via multicast at application startup. 2. Overview The Multicast Address Discovery Protocol (MADP) consists of a a Williamson, et al. Expires May 15, 2008 [Page 5] Internet-Draft MADP November 2007 light-weight server component and a light-weight client component that any application developer can embed in its associated application server code and application client code. This MADP embedded functionality operates independently of any other network service (other than multicast) and allows the client application to learn the multicast addresses that have been configured for use by the application at its nearest companion application server. This is accomplished by establishing contact with it's topologically closest application server using a well-known multicast address that has been assigned for use by MADP. Application servers will join this well- known MADP multicast address and listen for requests from their companion application clients. When contacted, the server will then send the requesting client the multicast address(es) that are to be used by the application via a unicast directly to the requesting client. By using MADP in this manner, a client/server multicast application consisting of a few application servers and hundreds of application clients may be easily deployed in the network with near- zero configuration capabilities simply by configuring the desired application multicast address(es) to be used at the application server(s). In order to locate the topologically closest application server, the application client uses an expanding ring search. For IPv4, this is based on a well-known Scope Relative multicast address in the Adminstratively Scoped address range [2]. For IPv6, this search is based on the address scope bits in the IPv6 multicast address. In both the IPv4 and IPv6 cases, the application client first attempts to locate it's companion application server by multicasting a MADP Request packet containing a unique application identification string, on the local link and listening for a matching unicast MADP Response back from a companion application server. If this fails to locate a server, the search is expanded to the Local Scope in the case of IPv4 and to the equivalent scope for IPv6. Application servers must join the well-known MADP multicast address(es) described above and listen for multicast MADP Requests with a matching application identification string. Any received MADP Requests that do not have a matching application identification string are assumed to be for some other client-server application and are quietly ignored. When a MADP Request with a matching application identification string is received, the server sends back a unicast MADP Response to the requesting application client. If a server is not found within the Local Scope, the search is expanded to the Organization-Local scope (aka Org-Local scope) in the case of IPv4 and to the equivalent scope for IPv6. Williamson, et al. Expires May 15, 2008 [Page 6] Internet-Draft MADP November 2007 (Note: IPv6 applications MAY try intermediate scopes larger than the Local Scope before proceeding to the Org-Local scope. However, since there are no well-known Scope Relative addresses in IPv4 other than for the Local Scope and the Org-Local scope this is not possible for IPv4.) When the first matching MADP Response is received from a companion application server via unicast, the application client ceases sending MADP Requests and uses the information in the MADP Response to configure it's multicast addresses as specified by the application server. Any further MADP Responses are ignored by the application client. (Note: If it is necessary for the client-server application to "re- address" itself and move to a new set of multicast addresses, it is the responsibility of the application server(s) to communicate this requirement to all application clients within the operation of the client-server application. At that point, all application clients would send new MADP Requests to obtain the newly assigned addresses. The implementation and management of this process is beyond the scope of MADP.) 3. Protocol Details All protocol messages have a common format consisting of a sequence of TLVs (Type, Length and Value). This makes the protocol easily extendible. This document defines two message types, Request message and Reply message. A request is sent by a node, which we will call a MADP client, containing one or more TLVs specifying what it is looking for. Nodes listening for MADP requests are called servers. A server receiving a request may, depending on the request, send a response back. Client and server behavior is further discussed in the sub-sections below. The messages are sent using UDP, requests are sent to a MADP multicast group and port . Replies are sent by unicast to the source address and source port of the request. The response source address is a unicast address of the replying server, and the source port is the MADP port. Each message is sent in a single datagram where the payload consists of a sequence of TLVs. There is no padding between the TLVs. 3.1. Type Format All types are formatted as specified below. Williamson, et al. Expires May 15, 2008 [Page 7] Internet-Draft MADP November 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type (2 octets) specifies the type. The different types are defined below. Length (2 octets) specifies the length of the value field. Depending on the type it can be from 0 to 65535. Value. The value must always be of the specified length. See the respective type definitions for possible values. If the length is 0, the value field is not included. 3.2. Types Request, type 0. Length MUST be zero (and hence no value). This type MUST be used in MADP Requests to specify that it is a Request message. This type MUST NOT be included more than once. If this type is included, type 1 MUST NOT be included. Reply, type 1. Length MUST be zero (and hence no value). This type MUST be used in MADP Replies to specify that it is a Reply message. This type MUST NOT be included more than once. If this type is included, type 0 MUST NOT be included. Request Name, type 2. Length MUST be non-zero. This type MUST be present exactly once in both MADP Request and Reply messages. The value in the reply MUST be the same as in the request. Vendor Name/ID, type 3. Length MUST be non-zero. This type SHOULD be used in MADP Requests. A reply to a request containing this type MUST also contain it and have the same value. There is no registry for the names so uniqueness cannot be guaranteed. It is left to the vendor to pick a name that is likely to be unique. This type MUST NOT be included more than once. Client Identifier, type 4. Length MUST be non-zero. This type SHOULD be used in MADP Requests. A reply to a request containing this type MUST also contain it and have the same value. This type MUST NOT be included more than once. Williamson, et al. Expires May 15, 2008 [Page 8] Internet-Draft MADP November 2007 Request ID, type 5. Length MUST be non-zero. This type MAY be used in MADP Requests. A reply to a request containing this type MUST also contain it with the same value. This type MUST NOT be included more than once. Multicast group, type 6. Length MUST be greater than 1. This type MUST NOT be used in MADP Requests, but MAY be used in MADP Replies. The value format is as specified below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family | Number of Sources (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast group address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Source Address [1] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Source Address [2] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Source Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... The first field is the two octets address family which is a value 0-65535 as assigned by IANA for Internet Address Families [2]. All addresses in the value MUST be of this family. This is followed by 2 octets specifying the number of sources, and a multicast group address. Finally if the number of sources N is non-zero, there will be N source addresses. Sources are specified only for Source Specific Multicast (SSM). If no sources are specified, the Number of Sources field MUST be set to 0. The length of the value depends on the address family and the number of sources. E.g., for IPv4 the length of the value is 1 + 4 + 2 + N * 4, while for IPv6 the length is 1 + 16 + 2 + N * 16. This type MAY be included multiple times. (Note: The actual association of the functional task assigned to any Multicast Groups (and any optional Sources) is beyond the scope of the MADP definition. Instead, it is expected that the order of multiple Multicast Group Types and the order of their optional Sources is significant to the application. That is to say, Clients and Servers are expected to understand the function assigned to each Group (and optional Sources within the Group) simply by the order in which they are listed in the Response. Williamson, et al. Expires May 15, 2008 [Page 9] Internet-Draft MADP November 2007 3.3. Client Behavior A device trying to discover what multicast address to use for further communication with other devices, or simply trying to discover the unicast addresses of devices to communicate with can attempt this by sending MADP Requests. The MADP Request MUST contain the Request type, and a Request Name type that specifies what kind of devices or servers it wants responses from. The client SHOULD also add a Vendor Name/ID type to ensure that it will only get responses for devices/ servers of the specified vendor. The client SHOULD also add the Client Identifier type to describe itself to the server. This may assist servers in deciding whether and how they should respond. Finally the client MAY include the Request ID type containing an ID to aid it in pairing requests with responses. E.g., the client might use a monotonically increasing value so that each request has a unique ID. The client performs an expanding ring search by first sending requests to the MADP group of smallest scope, then trying the group with the next scope and so on. For each scope it should send at least three requests to account for possible packet loss. If at least one reply is received, it will stop and use the received information. For IPv4 it uses the well-known Scope Relative multicast address in the Adminstratively Scoped address range [2]. It should start with the local scope 239.255.0.0/16 with a TTL of 1 to look for servers on the local link. If this fails, it should proceed with the same scope with a TTL of 255, and finally the organization local scope 239.192.0.0/14 with a TTL of 255. For IPv6 it would start with the link-local scope 2, next site-local scope 5 and finally organization-local scope 8. The TTL SHOULD be set to 255 for all IPv6 requests. The client MUST ignore MADP messages that do not contain exactly one Reply type. It SHOULD also verify that it matches a recent request it made. The client can do this since a server MUST echo back any Request Name, Vendor Name/ID, Client Identifier and RequestID type present in the reply. 3.4. Server Behavior A server receiving a MADP message inspects the types present to determine whether and how to respond. First it MUST check that the Request and Request Name types are present. A server MUST ignore the message unless both are present. If the Vendor Name/ID type is present the server MUST ignore the request unless explicitly configured or programmed to serve that particular Vendor Name/ID. The server MAY decide to ignore the request based on the specified Request Name, Vendor NAME/ID and Client Identifier types, or it MAY Williamson, et al. Expires May 15, 2008 [Page 10] Internet-Draft MADP November 2007 decide to reply based on those types. The server MUST ignore the request if no Request Name is specified. The server SHOULD do rate limiting per request source IP address. A server is configured or programmed with what patterns to respond to. This may not necessarily require the exact patterns to be configured or programmed but could involve some pattern matching, e.g., regular expressions. The server must also know whether a multicast group type is required for the response. If a multicast group is required the server SHOULD ignore the request unless it is able to specify one. The server only sends replies in response to requests. The response MUST contain the Reply type, and all of the Request Name, Vendor Name/ID, Client Identifier and RequestID types that were present in the request with the exact same values. In addition the server adds Multicast Group types if required. 4. IANA Considerations IANA is requested to give an IPv4 scope relative assignment per [2], an IPv6 multicast group ID per [4] and a UDP port number. 5. Security Considerations Deployment and use of this protocol should only affect devices that make use of it. There is a possible denial of service attack in that a rogue server may respond to requests intended for another server. Due to the expanding ring search, this causes problems if the rogue device is at least as close as the proper server. A client has no way of telling which response is legitimate. A rogue device may also specify a multicast group that should not be used by the client. The client's use of this group may cause problems like traffic leaking outside the desired scope or that the client receives/sends packets from/to a multicast group that is used for another purpose. Appendix A. Scenarios This section is provided to offer application developers some simple but not all inclusive ideas on how to use MADP to achieve near-zero configuration deployment their applications. Williamson, et al. Expires May 15, 2008 [Page 11] Internet-Draft MADP November 2007 Appendix A.1. Scenario 1 Here we consider a client-server application which uses a multicast address to communicate between the server and the clients. In order to avoid hard-coding the multicast address into the application and to provide the deploying network administrator some flexibility in the choice of application multicast address assignment, MADP is used by the application. The network administrator first deploys the server(s) in the network and configures the server's application software (through a method consistent with the application) with the multicast address to be used. Client workstations are then deployed in the network. When the application starts up in the client, it first sends a MADP Request using the MADP Local Scope Scope-Relative Address [239.255.255.???] but with a TTL of 1. If it hears no MADP Responses from a companion application server on the local link, it tries again using the MADP Local Scope Scope-Relative Address [239.255.255.???] but with a TTL of 255. If it hears no MADP Responses from a companion application server in the Local Scope, it tries again using the MADP Org-Local Scope-Relative Address [239.???.???.???] with a TTL of 255. Eventually the MADP Request is heard by a companion application server and it responds with a MADP Response containing a single multicast group TLV which contains the multicast group that was configured by the network administrator on the server. Appendix A.2. Scenario 2 In this scenario, we consider an application with 4 different unique communications functions (1-4) associated with the application and which are normally accomplished via 4 different multicast groups. Again, the network administrator deploys the application server(s) in the network and configures the server with the 4 different multicast addresses. (Using some method consistent with the application.) Next, the client applications are deployed in the network. They locate a companion application server using MADP and the expanding ring search methodology in the same manner as in Scenario 1 above. The application servers respond to client MADP Requests by unicasting a MADP response that contains an ordered list of 4 multicast group TLV's that describe the 4 multicast addresses in use by the application for Functions 1-4. Again, the order of the multicast group TLV's in the MADP Response is significant and is used to signify which multicast group is used for Williamson, et al. Expires May 15, 2008 [Page 12] Internet-Draft MADP November 2007 which function. This TLV to Function ordering is known by both the application client and application server and hence the first multicast group TLV is used for Function 1, the second for Function 2 and so on. However, consider now that the application provides the network administrator the option of using unicast for some of these functions in cases where unicast is a better fit for the network administrators deployment of the application. In this case, the application can still make use of MADP to communicate information about all 4 functions. For example, let us assume that the network administrator prefers Function 3 to operate using Unicast. In that case, how is the client application to resolve what Function is to use what multicast group if the client receives a MADP Response with an ordered list of only 3 multicast group TLV's containing 3 groups. Which Function goes with which group? In order to avoid this problem, it is suggested that the application server would always send a TLV for each function so that the order of the TLV's is significant and can be mapped to the 4 Functions in use. However, where a function is to use unicast, the application server would insert a "Dummy" TLV with a multicast group address of all zeros to signify that this function is to use unicast. Furthermore, source records within the TLV could be used to specify what unicast address(es) are to be used for the communication function. Assume that in this case Function 3 is to operate using unicast and not multicast. By inserting a "Dummy" TLV (with a multicast address of zero) for the Function 3 will still result in an ordered list of 4 multicast group TLV's (e.g. group1, group2, 0000, group4) which avoids any ambiguity about which Function is to use which method/ address. In this case, this 3rd Dummy entry in the ordered list with 0000 for the group address would tell the client that Function 3 is to use unicast and not multicast for this deployment of the application. Again, this dummy entry could optionally be populated with Source record(s) to pass on unicast addresses. Appendix A.3. Summary The above scenarios are offered as examples of how MADP can be used to satisfy a variety of application requirements for near-zero configuration and yet give network administrators the flexibility of choosing the multicast addresses that application is to use that fit into his/her multicast addressing plan. This was not meant to be an exhaustive study of all the possible scenarios and applications of MADP. It is offered simply as a starting point for application developers to consider. Williamson, et al. Expires May 15, 2008 [Page 13] Internet-Draft MADP November 2007 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [2] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [3] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. [4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Authors' Addresses Beau Williamson Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: bwilliam@cisco.com Dino Farinacci Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Stig Venaas UNINETT Trondheim NO-7465 Norway Email: venaas@uninett.no Williamson, et al. Expires May 15, 2008 [Page 14] Internet-Draft MADP November 2007 Full 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. 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). Williamson, et al. Expires May 15, 2008 [Page 15]