AVT WG J. Peterson Internet-Draft NeuStar Expires: January 10, 2005 J. Rosenberg dynamicsoft July 12, 2004 A Multiplexing Mechanism for the Real-Time Protocol (RTP) draft-peterson-rosenberg-avt-rtp-ssrc-demux-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines a mechanism for the Real-Time Protocol (RTP) that allows multiple RTP sessions to be demultiplexed at a single port. Accordingly, it also requests that the IANA allocate assigned ports for the use of RTP with three applications: voice, video and text. A similar mechanism is proposed for the Real-Time Control Protocol (RTCP). The use of this mechanism is confined to a strict domain of applicability. Peterson & Rosenberg Expires January 10, 2005 [Page 1] Internet-Draft RTP SSRC Multiplexing July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multiple Ports vs. Single Port Multiplexing . . . . . . . . . 4 3. Applicability of this Mechanism . . . . . . . . . . . . . . . 5 4. RTP and SSRC Multiplexing . . . . . . . . . . . . . . . . . . 7 5. Negotiating Usage in SDP . . . . . . . . . . . . . . . . . . . 8 5.1 Specifying a Port in SDP . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.1 Registration for SDP Attributes . . . . . . . . . . . . . 11 7.2 Registration for SIP option-tag . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Peterson & Rosenberg Expires January 10, 2005 [Page 2] Internet-Draft RTP SSRC Multiplexing July 2004 1. Introduction The Real-Time Protocol (RTP) specification (RFC 3550) [1]) Section 3 notes that "RTP depends upon the lower-layer protocol to provide some mechanism such as ports to multiplex the RTP and RTCP packets of a session." As such, there is no standard port over which RTP traffic flows; ephemeral ports are generally selected for RTP connections. While this simplifies the implementation of RTP as a protocol, it also gives rise to problems for applications that use RTP. Notably, it interferes with the operation of Network Address Translators (NATs, [8]). It also makes it hard for firewall administrators to implement layer-4 policies for RTP, since the ports over which RTP travels cannot be anticipated. As such, this document proposes a mechanism for RTP that would allow multiple RTP sessions to be multiplexed at a single transport-layer port. A given host might instruct several peers, for example, to all send media (using this extension) to the same transport address on that host. This mechanism leverages the synchronization source (SSRC) parameter of the RTP header to multiplex and demultiplex discrete RTP sessions that are sent to the same IP address and port. Multiplexing RTP for this purpose would yield little benefit if the Real-Time Control Protocol (RTCP) did not admit of a similar multiplexing scheme. Today, an RTCP session is paired with an RTP session (typically, though not always, RTCP runs on a port one port higher than RTP). This proposal continues to manage RTP and RTCP on separate ports, but only one port will be required for RTCP. RTP today is used to carry data associated with a number of common media types. These include real-time voice, video and text traffic. Since it desirable for firewall administrators to be able to implement policies that allow or disallow particular media types, this document requests that the IANA allocate separate standard RTP ports for each of the three common media types. The 'rtp-voice' port would also serve as a default port for all other media types, though if in the future other media types for RTP become popular, they might also warrant new media types. The motivations for the existing RTP lower-layer multiplexing decision are analyzed in Section 2, and current RTP operation is compared with the use of the proposed extension. The use of the SSRC to multiplex traffic is described in Section 4, and the problems with sending multiple RTP sessions to the same transport address described in Section 5.2 of RFC3550 are also examined. The use of this mechanism is confined to the domain of applicability described in Section 3, which provides a high-layer scheme for negotiating support of this mechanism and reverting back to standard RTP if it is Peterson & Rosenberg Expires January 10, 2005 [Page 3] Internet-Draft RTP SSRC Multiplexing July 2004 unsupported. 2. Multiple Ports vs. Single Port Multiplexing RTP runs over an existing transport protocol, such as UDP or DCCP [7]. All transport protocols by definition carry a port number - port numbers differentiate services or applications that are using a single Internet address on a device. Therefore, during the design of RTP, a decision was made that providing an indicator for handling multiplexing within RTP would be undesirable because the transport protocol under RTP already necessarily supports multiplexing through multiple ports - adding capability for multiplexing within RTP would be redundant. Accordingly, selection of a port for RTP is deferred to the application layer. Applications typically bind to a random available port to listen for RTP, and then inform their peers (through an out-of-band protocol like the Session Description Protocol (SDP [6]) the port to which media should be sent. However, carriage of RTP over multiple ports has created a number of obstacles to the widespread deployment of RTP. The most infamous of these is the interaction with firewalls and Network Address Translators (NATs). Typically, firewall administrators are reluctant to allow traffic on arbitrary ports to enter (and in some cases exit) their network. However, in order to allow the random ports selected by RTP, firewall administrators have little recourse. If RTP (and RTCP) ran over well-known assigned ports, firewall administrators could make a trivial decision to allow traffic over such ports into their network. NAT traversal presents an even more troublesome obstacle, since its impacts on RTP traffic are not necessarily side-effects of policy enforcement, but are innate in the deployment of many enterprises and residential networks. Since NATs are fielded in order to conserve IPv4 address resources by allowing multiple hosts to share a single IP address, many users that would like to connect an IP telephone to their existing residential network discover only inadvertently that their NAT blocks RTP traffic. In the absence of a single RTP port, a whole cottage industry of standard and proprietary protocols and devices have emerged that facilitate RTP's traversal through firewalls and NATs. The MIDCOM and NSIS protocols, ICE [4] and its components (STUN [5] and TURN [9]) are IETF standards that have been developed for this purpose. Specifying a standard-port variant of RTP will not obviate the need for mechanisms like ICE, but it does significantly simplify authorized firewall traversal (essentially eliminating the need for special-purpose ALGs or firewall controllers designed to permit VoIP Peterson & Rosenberg Expires January 10, 2005 [Page 4] Internet-Draft RTP SSRC Multiplexing July 2004 while maintaining network security), and it helps with some limited NAT cases. Given this problem space, there seems to be ample motivation for a way of consolidating all RTP traffic for a single IP address down to a single port that can easily be managed by middlebox administrators. Section 5.2 of RFC3550 anticipates that applications designers might want to multiplex several RTP streams over the same port, and normatively recommends against this practice. Five major points are raised against multiplexing in that section. The first three of these points, as RFC3550 notes, do not effect mechanisms that use the synchronization source (SSRC) for multiplexing. Of the remaining two, point 4 notes that an RTP mixer would not be able to combine streams of incompatible media into a single stream; however, since the mechanism presented in this document still uses different ports for different media types, this is not immediately applicable here. Similarly, point 5 establishes more problems with sending different varieties of media over the same port, and also notes that establishing different network paths or resource allocations for different sessions is rendered impossible. This last point is valid in networks where certain quality of service (QoS) mechanisms are used. In order for these mechanisms to work with a standard-port variant of RTP, resource allocation for RTP would need to evolve into a form similar to that used for TCP, where a 5-tuple is used to identify network resources rather than just the pairs of network addresses and ports. While this presents hurdles for the deployment of such QoS mechanisms with standard-port RTP, they are not insurmountable hurdles. On balance, the trade-off seems to favor the specification of standard-port RTP. 3. Applicability of this Mechanism If the mechanism proposed in this document is employed, but understood by only one of the parties in an RTP session, the consequences for the protocol could be very negative (i.e. in all likelihood, RTP would not function properly). In order to prevent this eventuality, implementations MUST NOT use this mechanism without a higher-layer negotiation mechanism that allows implementations to back off to traditional (unmodified) RTP. Specifically, implementations of this session MUST negotiate the use of the extension via SDP. Furthermore, implementations that use the Session Initiation Protocol (SIP [2]) to carry such SDP MUST supply a Require header field value with the 'sp-rtp' option-tag defined in Section 5. This mechanism is of primary value for traversing firewalls, in Peterson & Rosenberg Expires January 10, 2005 [Page 5] Internet-Draft RTP SSRC Multiplexing July 2004 keeping with the policies of firewall administrators, in the absence of Network Address Translators. When NATs are used, the applicability of this mechanism is more limited. The following scenarios are appropriate for use with standard-port RTP: If a single RTP implementation is behind a NAT, then the administrator of the NAT can use a simple packet-forwarding rule to forward all packets directed to standard RTP ports to the IP address of the RTP implementation. This could be useful in some residential deployments, for example. If multiple RTP implementations are behind a NAT, then there must be a single host which acts as a media relay for that network, effectively demultiplexing and reflecting traffic to the RTP implementations as appropriate. TURN servers could readily be adapted to this purpose, and furthermore, many enterprises effectively have such relays already, in the form of IP PBXs and various sorts of devices that manage call centers. However, even in these instances, this mechanism does not interact well with the usage of STUN as a means for obtaining an IP address and port to signal as the media destination. The problem is that the NAT will modify the source port of the outbound STUN request, and the source port it selected depends on the algorithms it implements, along with the state of the NAT itself. As a result, a client is likely to get back an IP address and a random port. This random port will not match any of the default ports for RTP traffic. This will make it impossible for the client to receive RTP traffic on the default ports. This problem is mitigated somewhat by NATs that provide a port preservation property. Port preservation is defined as a property whereby a NAT tries to preserve the source port in the outgoing packet. However, even in NATs that provide port preservation, there is a possibility that the port is already in use for another binding. In such a case, the NAT is forced to allocate a different port to the client. Thus, if a client sends its STUN messages from the default RTP port, port preservation makes it possible that the STUN results will indicate the same port, but there is no guarantee. Eventually, as NAT's become less transparent and more controllable, using techniques like MIDCOM and NSIS, a client could explicitly ask for a binding to the necessary RTP port. Fortunately, the mechanism described here is very compatible with ICE. ICE is based on the idea that a client might be able to receive RTP traffic at a multiplicity of IP addresses and ports. The default RTP port just becomes one other possibility, and ICE's peer-to-peer connectivity checks would be used to verify that RTP traffic could flow to the default RTP port. Peterson & Rosenberg Expires January 10, 2005 [Page 6] Internet-Draft RTP SSRC Multiplexing July 2004 Indeed, ICE provides a good transition mechanism to aid in the gradual adoption of the approach described here. ICE can be configured to prefer RTP traffic that connects to the default port, but would allow it to work to other ports when the default doesn't work (as in the STUN case above). As the STUN cases reduce in frequency (with the advent of more controllable devices and/or the usage of TURN servers when multiple clients behind a NAT require RTP services), ICE will discover, more and more frequently, that the default RTP port works. As this work progresses, it is expected that further work will be done on the interaction between standard-port RTP, STUN, TURN and ICE. An additional limitation of this mechanism is that the usage of RTP by multiple applications on a single host can be problematic, given common RTP implementations today. Any application that binds to an assigned port for RTP becomes the only application that can receive such RTP packets on a host. However, the authors believe that there are enough devices (like Internet telephones) that would only host a single RTP application that this extension would still have significant applicability without changes to existing RTP implementations. In environments where multiple applications would like to use RTP on a single host, RTP implementations would need to provide system-wide services. The applicability of this mechanism to multicast scenarios is a subject for further study. The intended use of this mechanism is in unicast scenarios, most likely those RTP sessions associated with the Session Initiation Protocol (SIP). 4. RTP and SSRC Multiplexing SSRC multiplexing does not require any extension to RTP. It reuses the 32-bit synchronization source (SSRC) header, which already exists in RFC3550, to differentiate discrete streams originating from a single source. The most obvious change to RTP behavior prescribed by this draft is that RTP server applications would no longer bind to ephemeral ports, but rather to one or more standard ports for various media types, depending on the capabilities and needs of the application. RTP implementations would also be required the multiplex and demultiplex traffic according to the SSRC, and render the results appropriately to higher level applications. This requires changes to existing RTP APIs. RFC3550 states that the SSRC is created randomly and unilaterally, Peterson & Rosenberg Expires January 10, 2005 [Page 7] Internet-Draft RTP SSRC Multiplexing July 2004 and that it must be globally unique within a particular RTP session (which is especially meaningful in ad-hoc conferences, or when multiple source devices are used to provide media for a single participant). In order to use the mechanism described in this document, the SSRC is negotiated collaboratively with other participants in a session using a higher-layer protocol like the Session Description Protocol (SDP). More information about negotiating the SSRC in SDP and SIP is given in Section 5. Without this higher-layer negotiation, this mechanism MUST NOT be used. Additionally, the SSRC negotiated by an RTP application MUST be unique across all RTP sessions on the host (or more specifically, associated with the same network address), rather than merely unique across participants in a particular RTP session. RTCP also uses the SSRC parameter. Like RTP, RTCP server applications would bind to standard ports rather than ephemeral ports, and similar multiplexing/demultiplexing operations are required to associate RTCP traffic with the proper multiplexed session. 5. Negotiating Usage in SDP The use of this mechanism with the Session Description Protocol (SDP) requires the addition of new attributes to SDP that communicate the values of the SSRC when using the offer/answer model (described in RFC3263). It also eliminates the need for RTP port selection in SDP. Thus, this mechanism defines two new attributes (a= lines) that can appear in SDP: 'ssrc-upper' and 'ssrc-lower'. Each of these attributes offers 16 bits of the SSRC that will be received by each participant in a RTP session. When an SDP offer is made, the offerer specifies the upper 16 bits of the SSRC in RTP that they will receive in the 'ssrc-upper' parameter, and specifies the lower 16 bits of the SSRC that the answerer will receive in the 'ssrc-lower' parameter. When the SDP answer is formulated, the answerer again specifies the upper 16 bits of the SSRC that they will receive in the 'ssrc-upper' parameter, and specifies the lower bits of the SSRC that the offerer will receive in the 'ssrc-lower' parameter. In both cases the generation of these bits MUST be random (following the guidance given in RFC3550 Appendix A) and MUST be unique across all RTP sessions supported by the host. So, for example, in an offer: a:ssrc-upper=0x6f12 a:ssrc-lower=0xaa9f Peterson & Rosenberg Expires January 10, 2005 [Page 8] Internet-Draft RTP SSRC Multiplexing July 2004 and in the answer: a:ssrc-upper=0x8b3b a:ssrc-lower=0x110c In this example, the RTP from the offerer to the answerer would have SSRC 0x8b3baa9f, and the SSRC from the answerer to offerer would be 0x6f12110c. The primary motivation for this collaborative agreement on SSRCs is to allow this mechanism to work with cases where SIP forking has occurred. Without this collaboration on SSRC, it would be difficult to distinguish media coming from different SIP user agents that were reached by an offer. Note that this mechanism does not eliminate the potential for collisions in SSRC selection described in RFC3550 Section 8.1. In fact, since each party to an offer/answer in a SIP forking case specifies only 16 bits of their SSRC, the potential for collisions may be higher. However, given a reasonable amount of randomness, the odds of a collision remain very low, and SDP could conceivably be used to renegotiate the SSRC in case of a collision. 5.1 Specifying a Port in SDP The presence of the 'ssrc-upper' and 'ssrc-lower' attributes in an SDP offer signals that this use of this mechanism is desired. SDP answerers MUST NOT supply 'ssrc-upper' and 'ssrc-lower' attributes in an SDP answer if they were not present in the offer; if the answerer requires the use of this extension, they SHOULD refuse the initial offer and formulate an appropriate counteroffer. SDP attributes that are not understood are ignored. Consequently, if an SDP offer containing 'ssrc-upper' and 'ssrc-lower' is answered with an SDP that does not contain these attributes, the offerer can determine that this extension is unsupported. However, this would not prevent the answerer from sending RTP media based on its understanding of the offer, which could have undesirable consequences, especially in SIP cases where the SDP offer is forked to multiple endpoints. When SIP INVITEs are used to carry SDP that contains the 'ssrc-upper' and 'ssrc-lower' attributes, those messages MUST have a SIP Require header field value containing the option-tag 'sp-rtp'. If this option is unsupported by recipients of such SIP request, a suitable SIP error code will be sent in the backwards direction, and the parties may subsequently attempt to renegotiate a session without Peterson & Rosenberg Expires January 10, 2005 [Page 9] Internet-Draft RTP SSRC Multiplexing July 2004 supporting this mechanism. SDP offers and answers use a field of the m= line to specify the port to which media should be sent. In the context of this mechanism, since standard port numbers are used, there is no need to signal a media port in the m= line. Moreover, it is undesirable, when this extension is used, to allow a port number to be specified (since this would allow applications potentially to use the voice port for video media, and the like). Therefore, the 'port' value of the m= line of SDP using this mechanism MUST be set to 99999. This is an invalid UDP port, and thus implementations which do not support this mechanism will be unable to send or receive media at this port. Implementations that support this mechanism MUST ignore the value 99999 in the port field of the m= line, and instead use the media value of the m= line to determine the port to which they will send media. In particular, if the media value of the m= line is 'audio', the port to which media will be sent MUST be the standard 'rtp-audio' port; similarly, 'video' MUST use the 'rtp-video' port, and 'text' MUST use the 'rtp-text' port. All other media values default to the 'rtp-audio' port, unless otherwise specified in a standards-track RFC that extends this specification. The IANA will assign port numbers for these ports as per the instructions in Section 7. 6. Security Considerations If the mechanism described in this document is used by RTP applications, firewall administrators will gain the ability to create firewall policies to control admission of RTP to their networks with a simple transport-layer filter. Like any other port-based policy, however, it is not a perfect instrument of security. Mischievous users have been known to send traffic over well-known ports (such as port 80) that is not appropriate for the IANA-registered application of that port. So while this document specifies, for example, separate RTP ports for voice and video, there is nothing that prevents a misbehaving application from accidentally or intentionally sending RTP video over the RTP voice port, and so on. For more information on the limitations of port-based security policies, see [10]. That much said, this approach does increase the firewall-friendliness of RTP significantly. In order to support an RTP implementation based entirely on ephemeral ports, firewall administrator today would have to open vast ranges of ephemeral ports to any applicable UDP traffic. If the mechanism described in this draft were widely deployed, firewall administrators would need to open only a handful of ports in order to allow RTP traffic. Since in many environments, Peterson & Rosenberg Expires January 10, 2005 [Page 10] Internet-Draft RTP SSRC Multiplexing July 2004 network administrators might have to remove firewalls in order to allow VoIP services on ephemeral ports, this mechanism improves the security of deployments. The best known practice for securing RTP is sRTP. Implementers should strongly consider the use of sRTP to authenticate the source of a media stream. The behavior suggested in this draft for constructing SSRCs is not a substitute for cryptographic authentication of a media source. The effects of this mechanism on sRTP are a subject for further study. 7. IANA Considerations This document requests that the IANA allocate three standard ports associated with RTP media types: one port for 'rtp-audio', one or 'rtp-video', and one for 'rtp-text.' This document also requests that the IANA allocate three standard ports for RTCP, one associated with each of the RTP ports described above: 'rtcp-audio, 'rtcp-video' and 'rtcp-text'. Further, this document requests that the assignment ports be ascending, and in the following order: rtp-audio, rtcp-audio, rtp-video, rtcp-video, rtp-text, rtcp-text. The first assigned port number must be an even number. Future standards-track specifications may request the assignment of additional ports that will be used by this mechanism. Such specifications MUST identify ports corresponding to the top-level media values that appear in the m= line of SDP. 7.1 Registration for SDP Attributes This document requests that the IANA allocate two new media-level attributes for SDP: 'ssrc-upper' and 'ssrc-lower'. [Ed Note: The formal registrations TBD] 7.2 Registration for SIP option-tag This document requests that the IANA allocate a new option-tag for SIP: 'sp-rtp'. [Ed Note: The formal registrations TBD] 8. References 8.1 Normative References [1] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC Peterson & Rosenberg Expires January 10, 2005 [Page 11] Internet-Draft RTP SSRC Multiplexing July 2004 3261, May 2002. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3550, July 2003. [3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [4] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-01 (work in progress), February 2004. [5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [6] Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-18 (work in progress), June 2004. [7] Kohler, E., Handley, M. and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", draft-ietf-dccp-spec-06 (work in progress), February 2004. 8.2 Informative References [8] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [9] Rosenberg, J., Huitema, C. and R. Mahy, "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress), February 2004. [10] St. Johns, M. and G. Huston, "Considerations on the use of a Service Identifier in Packet Headers", RFC 3639, October 2003. [11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Peterson & Rosenberg Expires January 10, 2005 [Page 12] Internet-Draft RTP SSRC Multiplexing July 2004 Authors' Addresses Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/ Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054-2711 US Phone: +1 973/952-5050 EMail: jdrosen@dynamicsoft.com URI: http://www.dynamicsoft.com/ Peterson & Rosenberg Expires January 10, 2005 [Page 13] Internet-Draft RTP SSRC Multiplexing July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). 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. Peterson & Rosenberg Expires January 10, 2005 [Page 14]