TRILL WG J. Touch (ed.) Internet Draft USC/ISI Expires: May 2006 November 4, 2005 RBridge: Problem and Applicability draft-touch-trill-rbridge-prob-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 4, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract RBridges are link layer (L2) devices that use routing protocols as a control plane. They combine the link layer ability to allow hosts to reattach without renumbering with network layer routing benefits. RBridges use existing link state routing to provide higher internal cross-section bandwidth, faster convergence under reconfiguration, and more robustness to link interruption than an equivalent set of Touch Expires May 4, 2006 [Page 1] Internet-Draft RBridge: Problem and Applicability November 2005 conventional bridges using existing spanning tree forwarding. They are intended to apply to similar L2 network sizes as conventional bridges and are intended to be backward compatible with those bridges as both ingress/egress and transit. They also attempt to retain as much 'plug and play' as is already available in existing bridges. This document explains the need for RBridges, defines their desired properties, and describes situations where they will be useful. This document is a work in progress; we invite you to participate on the mailing list at http://www.postel.org/rbridge Table of Contents 1. Introduction...................................................2 2. The Problem....................................................4 2.1. Inefficient Paths.........................................4 2.2. Convergence Under Reconfiguration.........................6 2.3. Robustness to Link Interruption...........................7 2.4. Problems Not Addressed....................................7 3. Desired Properties of RBridges.................................8 3.1. No Change to Link Capabilities............................8 3.2. Zero Configuration and Zero Assumption....................8 3.3. Forwarding Loop Mitigation................................9 3.4. Spanning Tree Management..................................9 3.5. Multiple Attachments.....................................10 3.6. VLAN Issues..............................................10 3.7. Equivalence..............................................10 3.8. Optimizations............................................10 3.9. Internet Architecture Issues.............................11 4. Applicability.................................................11 5. Security Considerations.......................................12 6. IANA Considerations...........................................13 7. Conclusions...................................................13 8. Acknowledgments...............................................13 8.1. Normative References.....................................13 8.2. Informative References...................................13 Author's Addresses...............................................14 Intellectual Property Statement..................................14 Disclaimer of Validity...........................................15 Copyright Statement..............................................15 Acknowledgment...................................................15 1. Introduction [CAVEAT: this document is in very rough form. Input and feedback is solicited] Touch Expires May 4, 2006 [Page 2] Internet-Draft RBridge: Problem and Applicability November 2005 Conventional Ethernet link subnets have a number of attractive features, allowing hosts and routers to relocate within the subnet without requiring renumbering and are automatically configuring. Unfortunately, the basis of the simplicity of these subnets is the spanning tree, which although simple and elegant, can have substantial limitations. In subnets with high host reattachment frequency, convergence of the spanning tree protocol can be slow. Because all traffic flows over a single tree, all traffic is concentrated on a subset of links, increasing susceptibility to the effects of link failures and limiting the bandwidth across the subnet. [I use the term Ethernet link subnets; do I need to define this? It's not a segment, which I think of as being shared or hubbed but not bridged] The alternative to an Ethernet link subnet is often a network subnet. Network subnets can use link-state routing protocols that allow traffic to traverse least-cost paths rather than being aggregated on a spanning tree backbone, providing higher aggregate capacity and more resistance to link failures. Unfortunately, IP - the dominant network layer technology - requires that hosts be renumbered when relocated in different network subnets, interrupting network (e.g., tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are in progress during the transition. It is thus useful to consider a new approach that combines the features of these two existing solutions, hopefully retaining the desirable properties of each. Such an approach would develop a new kind of bridge system that was capable of using network-style routing, while still operating at the link layer. This document describes the challenge of such a combined approach in detail and proposes one solution called an "RBridge". RBridges are bridge-like, link layer devices that aggregate with other rbridges on the same Ethernet link subnet to create a single, virtual device called an "RBridge campus". An Rbridge campus uses the subnet as the substrate for an encapsulation overlay network. Within that network, the campus uses variants of network layer link state routing protocols to enable shortest-path forwarding, robust reaction to link failures, and more rapid reaction to host reattachment. The remainder of this document makes as few assumptions about the rbridge architecture, but a review of some terms will be useful. Note that these terms assume only that an rbridge campus is an aggregation of devices that act as a unit: Touch Expires May 4, 2006 [Page 3] Internet-Draft RBridge: Problem and Applicability November 2005 o Rbridge: a single rbridge device which can aggregate with other rbridge devices to create a campus o Rbridge campus: a set of rbridges acting in unison o Inside a campus (internal): describes communication between rbridge devices; this communication may traverse external devices, but is still considered internal o Outside a campus (external): describes communication on the non- rbridge components of an Ethernet link subnet, notably not between rbridges or between non-rbridges and rbridges o Edge of a campus: describes rbridges that transit traffic from outside the campus to inside, and vice-versa [NOTE - I think a campus is *just* the set of rbridges, and that the Ethernet link subnet is the 'rest of the network'; some others have used the term 'campus' to refer to what I (and some others in the IETF, I think) think of as the Ethernet link subnet - is this confusing? If so, is there a better set of terms? Is 'campus' a term that is better avoided?] 2. The Problem Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted pair with hubs to twisted pair with switches, becoming increasingly simple to wire and manage. Each level has corresponding topology restrictions; thicknet is inherently linear, whereas thinnet and hub- connected twisted pair have to be wired as a tree. Switches allow network managers to avoid thinking in trees, where the spanning tree protocol finds a valid tree automatically; unfortunately, this additional simplicity comes with a number of associated penalties. The spanning tree often results in inefficient use of the link topology; traffic is concentrated on the spanning tree path, and all traffic follows that path even when other more direct paths may be available. The spanning tree configuration is affected by even small topology changes, and small changes can have large effects. Each of these inefficiencies can cause problems for current link layer deployments. 2.1. Inefficient Paths The Spanning Tree Protocol (STP) helps break cycles in a set of interconnected bridges, but it also can limit the bandwidth among that set and cause traffic to take circuitous paths. Touch Expires May 4, 2006 [Page 4] Internet-Draft RBridge: Problem and Applicability November 2005 Consider the network shown in Figure 1, which shows a number of bridges and their interconnecting links. End hosts and routers are not shown; they would connect to the bridges that are shown, labeled A-H. Note that the network shown has cycles which would cause packet storms if hubs (repeaters) were used instead of STP-capable bridges. One possible spanning tree is shown by double lines. B=======\\ C // \ \\ / \\ D // \ \\/ \\ // A-----\-------H===== E \ // || \ // || \ // || G----------F Figure 1 Bridged subnet with spanning tree shown The spanning tree limits the capacity of the resulting subnet. Assume that the links are 100 Mbps. Figure 2 shows how traffic from hosts on A to hosts on C goes via the spanning tree path A-B-H-E-C (links replaced with '1' in the figure); traffic from hosts on G to F go via the spanning three path G-H-E-F (links replaced by '2' in the figure). The link H-E is shared by both paths (alternating '1's and '2's), resulting in an aggregate capacity for both A..C and G..F paths of a total of 100 Mbps. B11111111 C 1 1 1 1 1 1 A H121212E 2 2 2 2 2 2 G F Figure 2 Traffic from A..C (1) and G..F (2) share a link If traffic from G to F were to go directly using full routing, e.g., from G-F, both paths could have 100 Mbps each, and the total aggregate capacity could be 200 Mbps (Figure 3). In this case, the H- F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is more direct. Touch Expires May 4, 2006 [Page 5] Internet-Draft RBridge: Problem and Applicability November 2005 B11111111 C 1 1 1 D 1 1 1 A H111111E G2222222222F Figure 3 Traffic from A..C (1) and G..F (2) with full routing There are a number of features of modern layer 3 routing protocols which would be beneficial if available at layer 2, but which cannot be integrated into the spanning tree system. Multipath routing can distribute load simultaneously among two different paths; alternate path routing supports rapid failover to backup paths. Layer 3 routing typically optimizes paths between pairs of endpoints, conventionally based on hopcount but also including bandwidth, latency, or other policy metrics. 2.2. Convergence Under Reconfiguration The spanning tree is dependent on the way a set of bridges are interconnected, i.e., the link layer topology. Small changes in this topology can cause large changes in the spanning tree. Changes in the spanning tree can take time to propagate and converge. [QUESTION: is there a good visual example of this, one that we can walk through in the description?] [QUESTION: What is the timescale? O(# bridges)? O(#links?), etc?] [QUESTION: is port autolearning in this category too? i.e., are rbridges trying to hide port reattachment from other nodes (or is that even necessary?)] The spanning tree protocol is inherently global to an entire layer 2 subnet; there is no current way to contain, partition, or otherwise factor the protocol into a number of smaller, more stable subsets that interact as groups. Contrast this with Internet routing, which includes both intradomain and interdomain variants, split to provide exactly that containment and scalability within a domain while allowing domains to interact freely independent of what happens inside. Touch Expires May 4, 2006 [Page 6] Internet-Draft RBridge: Problem and Applicability November 2005 [QUESTION: anybody have a convenient reference for a proof? Are new spanning tree protocols not considering AS-like boundaries? (just checking)] 2.3. Robustness to Link Interruption Persistent changes to the link topology, as described in Section 2.2, are not the only effects on subnet stability. Transient link interruptions have similar effects, with similar scalability issues. It would be more useful for subnet configuration to be tolerant of such transients, e.g., supporting alternate, backup paths. [QUESTION: is there more to say here?] Contrast this to network layer intradomain and interdomain routing, both of which include provisions for backup paths. These backups allow routing to be more stable in the presence of transients, as well as to recover more rapidly when the transient disappears. 2.4. Problems Not Addressed There are other challenges to deploying bridged link layer subnets that are not addressed in this document. These include: [NOTE: these are guesses; if any are wrong, we can move or revise] o increased Ethernet link subnet scale o increased node relocation o Ethernet link subnet management protocol security o flooding attacks on a Ethernet link subnet Rbridges are not intended to support increasingly larger scales of Ethernet link subnets than current spanning tree protocols can support. This may be a side-effect of supporting more rapid reaction to subnet reconfiguration or multiple internal paths, or of the grouped modularity an rbridge campus affords, but is not the focus of this work. Similarly, rbridges are not intended to solve the problem of link layer node migration, which can complicate the caches in learning bridges. Similar challenges exist in the ARP protocol, where link layer forwarding is not updated appropriately when nodes move to ports on other bridges. Again, although the grouped modularity of rbridges, like that of network layer ASes, can help hide the effect Touch Expires May 4, 2006 [Page 7] Internet-Draft RBridge: Problem and Applicability November 2005 of migration. That is a side effect, however, and not a primary focus of this work. Current link control plane protocols, including Ethernet link subnet management (STP) and link/network integration (ARP), are vulnerable to a variety of attacks. Rbridges are not intended to directly address these vulnerabilities. Similar attacks exist in the data plane, e.g., source address spoofing, single address traffic attacks, traffic snooping, and broadcast flooding. Rbridges do not address any of these issues, although it is critical that they do not introduce new vulnerabilities in the process (see Section 5). 3. Desired Properties of RBridges RBridges are a link layer device system intended to address the above problems. The architecture of rbridges is presented in a separate document; this document is intended to motivate their utility. The remainder of this section describes some of the desirable or required properties of any system that would solve the above problems, independent of the details of such an architecture. Most of these are based on retaining useful properties of bridges, or maintaining those properties while solving the problems listed in Section 2. 3.1. No Change to Link Capabilities There must be no change to the service that Ethernet subnets already provide as a result of deploying an rbridge campus. Ethernet supports unicast, broadcast, and multicast natively. Although network protocols, notably IP, can tolerate link layers that do not provide all three, it would be useful to retain the support already in place [6]. Zeroconf, as well as existing bridge autoconfiguration, are dependent on broadcast as well. There are subtle implications to such a requirement. Bridge autolearning already is susceptible to moving nodes between ports, because previously learned associations between port and link address change. An rbridge campus could be similarly susceptible to such changes, notably to the extent that edge rbridges learn such associations. 3.2. Zero Configuration and Zero Assumption Both bridges and hubs are zero configuration devices; hubs having no configuration at all, and bridges being automatically self- configured. Bridges are further zero-assumption devices, unlike hubs. Bridges can be interconnected in arbitrary topologies, without regard for cycles or even (inadvertent) self-attachment. STP removes the Touch Expires May 4, 2006 [Page 8] Internet-Draft RBridge: Problem and Applicability November 2005 impact of cycles automatically, and port autolearning reduces unnecessary broadcast of unicast traffic. Rbridges should strive to have similar zero configuration, zero assumption operation. This includes having rbridges automatically discover other rbridges and organize themselves into a campus, as well as to configure that campus for proper operation (plug-and- play). It also includes zero configuration backward compatibility with existing bridges and hubs, which may include interacting with some of the bridge protocols, such as STP. Autoconfiguration extends to optional services, such as multicast support via IGMP snooping, broadcast support via internal serial copy, and supporting multiple VLANs. 3.3. Forwarding Loop Mitigation Spanning tree avoids forwarding loops by design, even during update (?). Rbridges are intended to use adapted network layer routing protocols which may introduce transient loops during routing convergence. Rbridges thus need support for mitigating the effect of such routing loops. In the Internet, loop avoidance is provided by a decrementing hopcounts (TTL); in other networks, packets include a trace (serialized or unioned) of visited nodes [1]. These mechanisms (respectively) limit the impact of loops or detect them explicitly. A mechanism with similar effect should be included in the rbridge. [QUESTION: anyone have a good reference for serialized or union traces - or better names for them?] 3.4. Spanning Tree Management In order to address convergence under reconfiguration and robustness to link interruption (Sections 2.2 and 2.3), participation in the STP must be carefully managed. The goal is to provide the desired stability inside the campus and of the entire Ethernet link subnet while not interfering with the operation of STP outside the campus. This may involve rbridge campuses participating in the STP, where internally a more stable protocol is run such that the interactions between the campus and external STP is dampened, or it may involve severing the external STP into separate STPs on 'stub' external Etehrnet link subnet segments. [we need pictures here; to appear in the next version] Touch Expires May 4, 2006 [Page 9] Internet-Draft RBridge: Problem and Applicability November 2005 3.5. Multiple Attachments [QUESTION: I'm not sure what this refers to; is it the same NIC attached at different points to the rbridge? If so, why should this be possible where it seems ignored in bridges 3.6. VLAN Issues An rbridge campus should support multiple VLANs. This may involve ignorance, just as many bridge devices do not participate in the VLAN protocols. It may alternately support direct VLAN support, e.g., by the use of separate internal routing protocol instances to separate traffic for each VLAN inside the campus. [QUESTION: is it possible to be ignorant of VLANs and still operate? Bridges are, right?] 3.7. Equivalence As with any extension to an existing architecture, it would be useful - though not strictly necessary - to be able to describe or consider the rbridge campus as a model of an existing link layer component. Such equivalence provides a validation model for the architecture. This provides a sanity check, i.e., "we got it right if we can replace an rbridge campus with an X" (where "X" might be a single bridge, a hub, or some other link layer abstraction). It does not matter whether "X" can be implemented on the same scale as the corresponding rbridge campus. It also does not matter if it can - there may be utility to deploying the rbridge campus components incrementally, in ways that a single "X" could not be installed. For example, if an rbridge campus were equivalent to a single bridge, it would mean that the campus would - as a whole - participate in the STP. This need not require that the rbridge would propagate STP internally, any more than a bridge need do so in its on-board control. It would mean that the campus would interact with BPDUs at the edge, where the campus would - again, as a whole - participate as if a single node in the spanning tree. Note that this equivalence is not required; a campus may act as if a hub, or may not have a corresponding equivalent link layer component at all. 3.8. Optimizations There are a number of optimizations that may be applied to rbridge systems. These must be applied in a way that does not affect functionality as a tradeoff for increased performance. Such Touch Expires May 4, 2006 [Page 10] Internet-Draft RBridge: Problem and Applicability November 2005 optimizations address broadcast and multicast frame distribution, VLAN support, and snooping of ARP and IPv6 neighbor discovery. [NOTE: need to say more here.] 3.9. Internet Architecture Issues Rbridges are intended to have no impact on the Internet network layer architecture. In particular, the Internet and higher layer headers should remain intact when traversing an rbridge, just as they do when traversing any other link subnet technologies. This means that the IP TTL field cannot be co-opted for forwarding loop mitigation, as it would interfere with the Internet layer assuming that the link subnet was reachable with no changes in TTL (Internet TTLs are changed only at routers, as per RFC 1812) [1]. Rbridges should also have no impact on Internet routing or signalng, which also means that broadcast and multicast, both of which can pervade an entire Ethernet link subnet, must be able to transparently pervade an rbridge campus. Changing how either of these capabilities behaves would have significant effects on a variety of protocols, including RIP (broadcast), RIPv2 (multicast), ARP (broadcast), IPv6 neighbor discovery (multicast), etc. Note that snooping of network layer packets may be useful, especially for certain optimizations. These include snooping multicast control plane packets (IGMP) to tune link multicast to match the network multicast topology, as is already done in existing smart switches [3]. This also includes snooping IPv6 neighbor discovery messages to assist with governing campus edge configuration, as is the case in some smart learning bridges [7]. Other layers may similarly be snooped, notably ARP packets, for similar reasons for IPv4 [11]. 4. Applicability As might be expected, rbridges are intended to be used to solve the problems described in Section 2. However, not all such installations are appropriate environments for rbridge campuses. This section outlines the issues in the appropriate use of rbridges. Rbridges are intended to address problems of path efficiency and stability within a single Ethernet link subnet. Like bridges, individual rbridge components should find other rbridge components within a single Ethernet link subnet and aggregate into a single rbridge campus. Campuses are not intended to span separate Ethernet link subnets where interconnected by network layer (e.g., router) devices, except via link layer tunnels that are in place prior to Touch Expires May 4, 2006 [Page 11] Internet-Draft RBridge: Problem and Applicability November 2005 their deployment, where such tunnels render the distinct subnet undetectably equivalent from a single Ethernet link subnet. A currently open question is whether a single Ethernet link subnet should contain only one rbridge campus, either of necessity of architecture or utility. Multiple rbridge campuses, like Internet ASes, may allow internal routing protocols to be partitioned in ways that help their stability, but this may come at the price of needing the rbridge campuses to participate more fully as nodes (each modeling a bridge) in the Ethernet link subnet STP. Each architecture solution should decide whether multiple rbridges are supported within a single Ethernet link subnet and mechanisms should be included to enforce whatever decision is made. Rbridges are not intended to address scalability limitations in bridged subnets. Although there may be scale benefits of other aspects of solving rbridge problems, e.g., of using network layer routing to provide stability under link changes or intermittent outages, this is not a focus of this work. As also noted earlier, rbridges are not intended to address security vulnerabilities in either the data plane or control plane of the link layer. This means that rbridges should not limit broadcast frames, ARP requests, or spanning tree protocol messages (if such are interpreted by the campus or campus edge). 5. Security Considerations Rbridges should not introduce new vulnerabilities compared to traditional bridged subnets. Rbridges are not intended to be a solution to Ethernet link subnet vulnerabilities, including spoofing, flooding, snooping, and attacks on the link control plane (STP, flooding the learning cache) and link-network control plane (ARP). Although rbridges are intended to provide more stable routing than STP, this stability is limited to performance, and the subsequent robustness is intended to address non-malicious events. There may be some side-effects to the use of rbridges that can provide more robust operation under certain attacks, such as those interrupting link service, but rbridges should not be relied upon for such capabilities. Finally, rbridges should not interfere with other protocols intended to address these vulnerabilities, such as those under development to secure IPv6 neighbor discovery. Touch Expires May 4, 2006 [Page 12] Internet-Draft RBridge: Problem and Applicability November 2005 [need a ref for secure ipv6 nd] 6. IANA Considerations This document has no IANA considerations. This section should be removed by the RFC Editor prior to final publication. 7. Conclusions (TBA) 8. Acknowledgments Large portions of this document are based on and/or copied from a preliminary description document with permission from the authors [10]. 8.1. Normative References None. 8.2. Informative References [1] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812 (Standards Track), June 1995. [2] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [3] Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, "Internet Group Management Protocol, Version 3," RFC 3376 (Proposed Standard), October 2002. [4] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [5] IEEE 802.1d bridging standard, "IEEE 802.1d bridging standard". [6] P. Karn (ed.), C. Bormann, G.Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for Internet Subnetwork Designers," RFC-3819 / BCP 89, July 2004. [7] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461 (Standards Track), December 1998. Touch Expires May 4, 2006 [Page 13] Internet-Draft RBridge: Problem and Applicability November 2005 [8] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, March 2004. [9] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley Chapter 3, 1999. [10] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent Routing," (work in progress), Apr. 2004 - May 2005. [11] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826 (Standard), November 1982. [12] Touch, J., (ed.), "RBridge Architecture," (work in progress). [13] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual Internet Architecture", ISI Technical Report ISI-TR-570, Presented at the Workshop on Future Directions in Network Architecture (FDNA) 2003 at Sigcomm 2003, March 2003. [14] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [15] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923 (Informational), September 2000. Author's Addresses Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, CA 90292-6695 U.S.A. Phone: +1 (310) 448-9151 Email: touch@isi.edu URL: http://www.isi.edu/touch 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 Touch Expires May 4, 2006 [Page 14] Internet-Draft RBridge: Problem and Applicability November 2005 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 (2005). 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. Touch Expires May 4, 2006 [Page 15]