Internet Research Task Force L. Zhang, Ed. Internet-Draft S. Brim, Ed. Intended status: Informational March 29, 2008 Expires: September 30, 2008 A Taxonomy for New Routing and Addressing Architecture Designs draft-rrg-taxonomy-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 September 30, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The Routing Research Group is tasked to design a new routing architecture to meet the challenges of scalability in face of pervasive multi-homing and inter-domain traffic engineering. A number of solutions have been proposed. This draft describes a taxonomy for the design space, and then uses the taxonomy to discuss and compare the proposed solutions. Zhang & Brim Expires September 30, 2008 [Page 1] Internet-Draft Design Taxonomy March 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Solution Directions . . . . . . . . . . . . . . . . . . . 3 3. A functional model . . . . . . . . . . . . . . . . . . . . . . 5 4. Where to Place the Split Between TAA and TIA . . . . . . . . . 6 4.1. Mapping Inside the Host . . . . . . . . . . . . . . . . . 6 4.2. Mapping Point at Network Administrative Boundary . . . . . 7 4.3. Mapping Point at Prefix Aggregation Places . . . . . . . . 8 4.4. Granularity of Node and Common Issues . . . . . . . . . . 8 5. Where to Put in Mapping: Two Basic Choices . . . . . . . . . . 8 6. Design Space of A New Mapping System . . . . . . . . . . . . . 9 6.1. Elements in Mapping Information Distribution/Discovery . . 9 6.2. Mapping Information Distribution: Push versus Pull . . . . 10 6.3. The Mapping Information Distribution Channel . . . . . . . 12 6.4. The Selection Decision among Multiple TAAs . . . . . . . . 12 7. Failure Handling in the Presence of Mapping . . . . . . . . . 13 7.1. Failure Detection and Handling . . . . . . . . . . . . . . 13 7.2. Data Handling During Transient State . . . . . . . . . . . 14 7.3. Failures in Mapping System . . . . . . . . . . . . . . . . 14 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Zhang & Brim Expires September 30, 2008 [Page 2] Internet-Draft Design Taxonomy March 2008 1. Introduction The Routing Research Group is tasked to design a new routing architecture to meet the challenges of scalability, multi-homing, and inter-domain traffic engineering. With the imminent exhaustion of IPv4 address space, the discussion and some initial deployment of IPv6 has moved from the back burner to the front stage. However, one of the major issues concerning IPv6 deployment is its potential impact on scalability of the already stressed routing system. A number of approaches to scaling the Internet's routing system have been submitted. We expect this taxonomy to facilitate discussion of both existing and future proposals, to position each proposal in the design space, and to help evaluation of various design tradeoffs in all the proposals. We identify dimensions of the design space by first identifying various different approaches from all the proposed solutions. We then extract out common techniques to sketch out the solution space. To test whether we get the solution space right, we try to position the proposals in the design space, and this step helps identify missing issues. As one can see this approach to taxonomy development is an iterative process. We expect that this document will continue to be updated as our understanding of the solution space progresses. We also hope that it can serve as input to the final decisions by the Routing Research Group. This draft is organized into the following parts: o Identify the solution directions; o Identify a common functional model; o Identify the dimensions of the design space; o Identify the open issues; and o Identify the tradeoffs in each of the approaches to resolving the open issues. 2. The Solution Directions The fundamental goal of a scalable routing system design is to be able to support continued growth in the number of Internet users and flexibility in how they use the Internet. One way to control routing system scalability in face of rapid growth is to enforce topologically aggregatable IP address assignment. However, Internet Zhang & Brim Expires September 30, 2008 [Page 3] Internet-Draft Design Taxonomy March 2008 users desire topology-independent (TI) prefixes to ease changing providers and to avoid renumbering. The common practices of multihoming and traffic engineering also lead to prefix de- aggregation. Two basic directions have been proposed to solve this routing table scalability problem: either o Find ways to handle the large and ever growing routing tables, or o Route on topologically aggregatable addresses only. Several publications from academic research fall into the first category (add ref: ROLF, compact routing). This class of solution models the Internet as a large, flat network, where any node may forward traffic for any other nodes. Based on this model, one can determine the next hop for packet forwarding by applying distributed hashing algorithms instead of maintaining a routing table. However, because the operational Internet is an interconnect of multiple networks under different administrations, routing policy plays an essential role in making the routing decisions. It is not the case that any node would be willing to forward traffic for any other nodes, since traffic across AS boundaries means money changing hands. Furthermore, individual ASes are also unwilling to expose their internal topological connectivity to other domains as input to the hash algorithms. The proposals that have been made to the IETF/IRTF so far all fall into the second category, i.e., scaling the routing system by only providing routing for topologically aggregatable addresses (TAAs). However, as we mentioned earlier, Internet users desire topology- independent addresses (TIAs). To both scale the routing system and satisfy user desires at the same time, there needs to be a point where use of a TAA ends and use of a TIA starts. One important design decision is where to engineer this split between TAAs and TIAs. Furthermore, one must also develop a mapping system to bridge the two. There is also another class of approaches aiming at only providing routing for topologically aggregatable addresses (TAAs): simply surpress fine granularity prefixes and inject only aggregated prefixes into the global routing. IVIP and CRIO may be considered as example designs in this category. These approaches require that the aggregation points be able to forward packets towards their real destinations (and tunneling can be one means to serve that purpose). One may view this class of aproaches as an intermediate point between today's routing systema and the approach described in the previous paragraph (separation and mapping between TAA and TIAs), but with the Zhang & Brim Expires September 30, 2008 [Page 4] Internet-Draft Design Taxonomy March 2008 split being placed at the points where prefix aggregations occur, rather than at the user network administrative boundaries. In the rest of this draft, we focus on developing a framework to describe the choices of where to engineer the split, together with the design space for the mapping system. 3. A functional model To make the discussion more concise, we first define terminology. As we already mentioned, we call the part of the IP address space that is topologically aggregatable "TAA Space" and the associated prefixes TA Prefixes. The (non-aggregatable) topology-independent addresses, which by design will not be covered in global routing, are called TI Addresses and TI Prefixes. This terminology is chosen to avoid confusion. TI addresses/prefixes have also been called EIDs, in the sense that they IDentify Edge networks. However in a different context, such as the work by HIP Research Group and Working Group, EID is used to refer to End host IDentifiers. In this draft we will use TIAs and not EIDs. Here we sketch out an overall picture of a scalable routing system design. Global routing runs over TA space, the Internet users by and large operate in TI space, and a mapping function bridges the two. In addition, there is a mapping information distribution mechanism in one form or another. Theoretically speaking, there are multiple places to make the TIA-TAA split, and multiple ways to provide the mapping information between the two. In the solutions proposed to RRG so far, the predominant choices for the split point are either within the endpoint or at a network administrative boundary. A closely related issue is points to which mapping information may be distributed. So far the choices are usually either to inform the host, or to hide the mapping information from entire networks in TI space. These are the subjects of the next two sections. Stepping up a level, this split between TAA and TIA makes a subtle change to the failure modes of the routing system. In today's Internet, site multihoming is a common practice. BGP performs flat routing at the inter-domain level, and dynamic routing picks one of the working links to reach a multihomed site. In the presence of mapping, however, the selection of entry point to a multihomed site is done at the mapping point, be it in the source host or at source network border. Therefore the system must be able to adjust to Zhang & Brim Expires September 30, 2008 [Page 5] Internet-Draft Design Taxonomy March 2008 failures (and recoveries) of the current mapping selection. We discuss the design choices for failure handling in Section X [reference]. The addition of a mapping system also introduces at least one new target for malicious attacks. In today's Internet, one can hijack data traffic by compromising the routing system. With the new design, one might be able to hijack traffic by injecting false information into the mapping system. One could also attempt to damage the mapping system by a DoS attack on one of its elements. We discuss security considerations in Section XX [reference]. 4. Where to Place the Split Between TAA and TIA There is a close coupling between how the mapping is done and where the mapping is done. Since end hosts perform DNS resolution before sending packets in general, a DNS-based mapping solution allows one to set the mapping point anywhere from inside the end host to all the way to the attachment point of an edge network. Proposals that use a new mapping system tend to place the mapping point at network administrative boundaries. 4.1. Mapping Inside the Host SHIM6 is a design that uses DNS to provide mapping information. It places the boundary between TA and TI inside an endpoint stack, at the border between IP and transport layer. A multihomed site will have multiple prefixes assigned to it by its providers, and SHIM6 assigns multiple IP addressees to each internal node (add SHIM6 refs). SHIM6 lets individual hosts select one destination prefix among multiple choices, which potentially influences the path taken by the packets. This design aspect raised concerns from network operators and ISPs regarding their ability to perform traffic engineering, an important part of routing policy support. Variations of the basic SHIM6 design have been developed to address SHIM6's limitations. One of them is SHIM6 proxy, which addresses the concern of having to change all the hosts. Another variation of SHIM6 is Six/One, which addresses the traffic engineering concern. In Six/One, end hosts perform SHIM6, but routers at the network edge may rewrite the IP addresses to meet TE goals. Although this hybrid solution can be used to support TE, it also introduces complexity due to the need for coordination between end hosts and the address rewriting routers. Zhang & Brim Expires September 30, 2008 [Page 6] Internet-Draft Design Taxonomy March 2008 Another design that puts the split inside the host is a proposal from Mark Handley [reference]. Instead of hiding the multiple TAAs below the transport layer as SHIM6 does, the Handley proposal exposes the multiple TAAs directly to the transport layer. 4.2. Mapping Point at Network Administrative Boundary GSE is another design that uses DNS to provide mapping information. In some sense one may view GSE as putting the split between TAA and TIA at the border between an edge network and its provider, although GSE does not really provide edge networks with globally unique topology-independent addresses. GSE cuts the IP address into three parts, the upper part being a globally routeable prefix (called "routing goop", or RG), the middle part representing network topology inside a site (called the site topology partition, or STP), and the lower part being a globally unique identifier for the host (End System Designator, ESD). The combination of the last two parts also makes a site-local address. +-------------------------+ | RG | STP| ESD | +--------+----+-----------+ GSE shelters all the internal nodes from knowing any of the prefixes assigned by their transit providers. Inside an edge network, all communications use site local addresses. Only packets going outside the network will carry a full destination address. A source host obtains the full destination address (including both the upper and lower portions) from a DNS lookup. When the packet exits the source network, its border router replaces the site-local prefix of the source address with an appropriate transit prefix. When the packet enters the destination network, the border router will keep the source address intact so that the receiving host can send reply packets to the source, but will replace the upper portion of the destination address (the external prefix) with a site-local prefix, so that nodes inside an edge network never see their own external prefixes. This eases the change of providers since sites only need to obtain new RG and update the DNS. However for a site with multiple topologically diversified locations, the network management can become difficult if each site uses the same default site-local prefixes. Another way to set the TA-TI split at the border between networks was first described in Map-n-Encap (RFC1955). It assumes that border routers can obtain or access a mapping database that maps non- aggregatable prefixes to their routed TAA attachment points. The border router can then use IP encapsulation to tunnel packets to the destination border router. This approach has the advantages of (1) Zhang & Brim Expires September 30, 2008 [Page 7] Internet-Draft Design Taxonomy March 2008 making no changes to the existing user networks and their operational practices, and (2) eliminating all renumbering induced by changing providers. Several of the newly proposed solutions follow this approach, including APT, IVIP, and LISP. 4.3. Mapping Point at Prefix Aggregation Places [Editor's note: this section is yet to be finished.] As we discussed in Section 2, one may consider an incremental step towards reducing the BGP routing table by simply aggregating fine granularity prefixes into shorter prefixes and only injecting the aggregated prefixes to the routing system. This class of solutions fall into the same direction as the TAA-TIA split, as the longer prefixes being aggregated are essentially equivalent to TI prefixes. The challengings in pursuing this direction lie at where to engineer the aggregation points, which parties may perform the function, as well as how to evaluate the gains and the cost. 4.4. Granularity of Node and Common Issues One may view the different choices of where to place mapping points as different points in the same spectrum, based on the granularity of the "node" the TAA reaches. In the first approach, the TAA reaches end hosts directly; in the second approach, the TAA reaches an entry point to a network containing the end host, and the actual end host is reached by using the entry point's TIA. Although the above two approaches look rather different, they share a set of common issues that arise from site multihoming: choosing a TAA to reach the intended destination host (mapping), detecting failures of the TAA currently in use, and recovering from the failure while minimizing packet losses during failure recovery. Furthermore, one must also secure the mapping distribution channel. These issues will be discussed in Section XYZ (reference). 5. Where to Put in Mapping: Two Basic Choices One way to get the mapping information is to utilize an existing look-up system, and DNS makes a readily available candidate. In today's host implementations, almost all the applications perform a DNS lookup to get the IP address of their intended destinations. Thus one can simply piggyback the TAA to which the destination network is attached in a DNS reply. Putting the mapping information into DNS is conceptually a very simple solution, and has the advantage of avoiding any new design. Zhang & Brim Expires September 30, 2008 [Page 8] Internet-Draft Design Taxonomy March 2008 Furthermore, letting the end host receiving this information may provide flexibility of engineering the TAA-TIA split at various different places, as we will see in the next section. However this simple solution also raises a few concerns. The foremost is the requirement of making changes to all the end hosts. A more subtle issue is the circular dependency between DNS and data delivery: DNS assumes the availability of IP packet delivery, but in the new design data delivery will require getting the mapping information first. A second way of providing the mapping function is to develop a new mapping system. To avoid having to make changes to all end hosts, all the proposed new mapping system designs put it outside the edge networks, so that within an edge network everything can run as today with no changes. However the proposed solutions differ in a number of ways., which we will elaborate in later sections. 6. Design Space of A New Mapping System At a high level, different designs can be sorted along the following dimensions: o Push versus pull; o A hierarchical system versus a flat distribution system; and o A dedicated distribution system versus laying it on top of the existing routing system. Different combinations of the above three dimensions cover all the proposals currently on the table, although it is not necessarily an exhaustive list of all the significant dimensions in the design space. The list will be updated as new important dimensions are identified. 6.1. Elements in Mapping Information Distribution/Discovery Mapping information for an end host in a network must be made available to all sources which want to send packets to that end host. Generally speaking, one can identify the following five logical elements in a mapping information distribution design. 1. The mapping information for a network (e.g. a mapping for a TI prefix to one or more TAAs) is owned by the network's administrator, the owner. Zhang & Brim Expires September 30, 2008 [Page 9] Internet-Draft Design Taxonomy March 2008 2. There may exist an initial distributor which is distinct from the owner/originator of the information, so that owners do not have to be directly involved in mapping distribution system operations. In some cases the owner also acts as the initial distributor. 3. The distribution channel. 4. In cases the distribution channel uses a push model, we need an entity to hold the information for future use. This "holder" may be the user of the mapping information itself, or a node near the users of the information that can supply the information to them when they need it. 5. The user of the mapping information (when it is a different entity from the holder). Origination of mapping information (from owner to initial distributor) can be manual or automated by a protocol exchange. Consideration: how to authenticate each originator of the mapping information. One important consideration in designing a mapping information distribution system is how well it can scale with the number of entries. Mapping information size is likely to grow to at least a few orders of magnitude larger than the current BGP table size, e.g. hundreds of millions. Such a big size imposes limitations on the frequency of dynamic changes to mapping entries. Prompt and reliable mapping information distribution depends on how well the above entities -- the owner, initial distributor, distribution channel, the holder and the user -- of the mapping information can coordinate with each other. Because the Internet is a collection of networks that belong to multiple parties with potentially conflicting interests, it is important to minimize the dependency between different parties in obtaining mapping information. 6.2. Mapping Information Distribution: Push versus Pull Protocol-based distribution of mapping information can be push-based, pull-based, or a combination of the two. Generally speaking, one may sort different types of distribution channels based on how far each pushes the mapping information from the originator to the user. o The initial distributor may push mapping information to all user nodes (perhaps through intermediate steps). An example of this Zhang & Brim Expires September 30, 2008 [Page 10] Internet-Draft Design Taxonomy March 2008 approach is NERD [reference], where the originator injects mapping information into one or more centralized databases, then entire databases are pulled by user nodes to local storage. o At the other end of design spectrum is a pure pull/look up model: the initial distributor holds the mapping information, and the user nodes or holders pull information when needed. o A design can also take a middle ground, by pushing mapping information to some intermediate holder nodes, which can then be polled by the user nodes as needed. An example design of this approach is APT, where the distribution channel pushes mapping information to Default Mappers (holders) in each AS, and ITRs (users) request mapping entries from the default mappers as needed. Designs based on pushing must include mechanisms to push the mapping information out. The complexity of this step depends on where the holders are. A centralized holder design is illustrated by NERD, where individual originators simply submit their mapping information to a central database (the holder) using an existing application protocol. A distributed holder design is illustrated by APT, where a flooding mechanism is needed for the mapping information to be pushed from all originators to default mappers in all ASes. An important aspect of designs based on pulling is an indexing mechanism. Because the input to mapping are multiple millions of unstructured TI prefixes, pull-based systems require a scalable indexing system to direct queries to the distributors with the requested mapping information. Again multiple design choices exist. DHTs (dynamic hash tables) use algorithmic hashing to make the lookup of a large number of unordered items scalable. Another design point is illustrated by CONS, where the indexing system is a hierarchy of TIA prefixes (in a way similar to DNS hierarchy, by replacing DNS domains with prefix aggregations). Yet another design approach is ALT which pushes paths to specific mapping information to users. Just as there can be holders for pushed mapping information, there can also be holders of another kind of index information. Whenever a piece of mapping information is pulled to the user node, that piece can/may be cached at the user node, and also at some intermediate nodes along the pulling path if any such nodes exist. Examples of utilizing caching include the LISP and APT designs where the mapping information is pulled by ITRs and cached there. In addition, CONS, one of LISP's mapping designs, uses a hierarchical structure to retrieve mapping information, thus those nodes along the pulling paths can also cache the information. Zhang & Brim Expires September 30, 2008 [Page 11] Internet-Draft Design Taxonomy March 2008 6.3. The Mapping Information Distribution Channel A related, but separate, question is what to use for the distribution channel. There are three distinguishable channel types. The first one is to add mapping information to the DNS. In this case, the initial distributors are the authoritative DNS servers, the users are source hosts, and the distribution channel is pure pulling (DNS queries), thus there is no holder. Solutions that push the TAAs all the way to endpoint nodes, such as SHIM6 and the Handley proposal, require no changes to the DNS RR content. Among solutions that keep TAAs out of edge networks, GSE does not need any major change to DNS because the TAA is the IP address, while tunneling-based solutions will need to retrieve from DNS the TAA for the destination TIA. An example of this approach is an early version of eFIT (reference), where a DNS reply would carry an ETR RR, the source host puts that value in an IP header option field, and the ITR could use it to encapsulate the packet to the ETR. Another approach is to establish a new and distinct mapping distribution system. This new system can be designed from scratch, or it can borrow from the existing DNS framework to various degrees, ranging from using a similar hierarchical structure to directly using DNS query protocols, even though the system is solely used for mapping information retrieval. A third approach is to distribute mapping information through the routing system. This approach differs from the second one in that it uses routers, as opposed to separate and dedicated entities, to distribute mapping information. 6.4. The Selection Decision among Multiple TAAs Another dimension is how a choice is made among multiple TAAs for a destination. The answer to this question depends in part on the distribution channel. Generally speaking, we can identify the following three cases. 1. If the distribution is pure push, then the user node receives the full mapping information, thus it can make its own decision based on preferences the originator has injected into the mapping system. An example design using this approach is NERD. 2. If the distribution is pure pull, then the originator (the owner of the mapping information) can make the decision on whether to provide puller-dependent or puller-independent replies to mapping queries. Puller-independent replies can be cached at various Zhang & Brim Expires September 30, 2008 [Page 12] Internet-Draft Design Taxonomy March 2008 nodes along the pulling path, which can help reduce system overhead as well as speed up future pulling replies. An example design using this approach is CONS. On the other hand, if mapping replies are tailored specifically for each request in order to support sender-specific policies, they cannot be cached in the polling paths. An example design using this approach is ALT. 3. If the distribution channel uses a combination of push and pull, then the mapping information holder can decide which TAAs shall be given to which mapping point. An example of this approach is APT, where mapping information is pushed to all default mappers (holders) in each AS, which can then behave like policy controllers for the AS to dictate which ITRs use which TAAs. 7. Failure Handling in the Presence of Mapping As explained earlier, a mapping point must be able to adjust the mapping selection upon detection of failures. Failures do not invalidate mapping information, but only cause the selection of mapping entries to change, perhaps temporarily until the failure is recovered. 7.1. Failure Detection and Handling Failure detection is directly coupled with the placement of the mapping points. If the mapping point is inside the host, failure of the current mapping selection can be detected by the endpoints, by transport or upper layer protocols. Since the proposed host-based solutions use DNS to pull mapping information, each host can also make a decision on which alternative mapping value to choose. One failure can affect many endpoints. Putting mapping point inside hosts requires that all hosts detect and handle the failures independently. Those solutions that put the mapping point at a network administrative boundary need new mechanisms for detecting failure at mapping points. Possibilities include o data-triggered detection, i.e. packets reach a dead end o routing-triggered detection, i.e. one learns from a routing protocol (IGP or BGP) that some TAA or TA prefix becomes unreachable. Once a failure is detected, one needs to notify affected parties to Zhang & Brim Expires September 30, 2008 [Page 13] Internet-Draft Design Taxonomy March 2008 avoid the failure. Design possibilities fall into a multi- dimensional space: whether sending separate control packets or piggybacking the notification on data packets; whether directly notifying involved mapping points (those who are sending to the failed demapping point), or notifying holders; and whether notifying everyone, or only the affected parties at the time of the failure (i.e. those who are actively sending). When a failure is remedied, the mapping system may indicate so, so that mapping points may revert to using the mappings they were before the failure. Another consideration is which party holds the temporary failure information, and how it can be removed when recovery is complete. 7.2. Data Handling During Transient State When a failure occurs, there can be in-flight packets heading towards a failed demapping point. Another design consideration is how to handle these in-flight packets. 7.3. Failures in Mapping System A mapping system design must consider various possible failures in the mapping system itself, and understand how robust the system can be in face of the failures. 8. Security This section is unfinished. Here are some considerations. o What is the trust model/relationship between neighbor nodes in the mapping distribution chain? o How to ensure and verify mapping information authenticity? o How possible is it that data packets will be mis-delivered. o How possible is it that control (mapping, signaling) packets will be mis-delivered o Vulnerability to a flood of data packets. o Vulnerability to a flood of control packets. o Vulnerability of control to MITM attacks. Zhang & Brim Expires September 30, 2008 [Page 14] Internet-Draft Design Taxonomy March 2008 o Is it possible to physically separate control traffic from data traffic? o Vulnerability to scanning attacks filling cache. 9. References 9.1. Normative References [ENDPOINTS] "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture [unpublished]", June 1995, . 9.2. Informative References [PODC06] Konjevod, G., Andrea, R., and D. Xia, "Optimal-Stretch Name-Independent Compact Routing in Doubling Metrics", . Authors' Addresses Lixia Zhang (editor) Email: lixia@cs.ucla.edu Scott Brim (editor) Email: swb@employees.org Zhang & Brim Expires September 30, 2008 [Page 15] Internet-Draft Design Taxonomy March 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). Zhang & Brim Expires September 30, 2008 [Page 16]