idnits 2.17.1 draft-ietf-avt-rtp-and-rtcp-mux-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 483. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3550, updated by this document, for RFC5378 checks: 1998-04-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 29, 2006) is 6409 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2032 (ref. '3') (Obsoleted by RFC 4587) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-11 ** Obsolete normative reference: RFC 4566 (ref. '8') (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-10 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Perkins 3 Internet-Draft University of Glasgow 4 Updates: 3550 (if approved) M. Westerlund 5 Expires: April 2, 2007 Ericsson 6 September 29, 2006 8 Multiplexing RTP Data and Control Packets on a Single Port 9 draft-ietf-avt-rtp-and-rtcp-mux-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 2, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo discusses issues that arise when multiplexing RTP data 43 packets and RTP control protocol (RTCP) packets on a single UDP port. 44 It updates RFC 3550 to describe when such multiplexing is, and is 45 not, appropriate, and explains how the Session Description Protocol 46 (SDP) can be used to signal multiplexed sessions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4 54 5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5 55 5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6 56 5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 7 57 5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 7 58 6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 8 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 61 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 66 Intellectual Property and Copyright Statements . . . . . . . . . . 12 68 1. Introduction 70 The Real-time Transport Protocol (RTP) [1] comprises two components: 71 a data transfer protocol, and an associated control protocol (RTCP). 72 Historically, RTP and RTCP have been run on separate UDP ports. With 73 increased use of Network Address Translation (NAT) this has become 74 problematic, since opening multiple NAT pinholes can be costly. This 75 memo discusses how the RTP and RTCP flows for a single media type can 76 be run on a single port, to ease NAT traversal, and considers when 77 such multiplexing is appropriate. The multiplexing of several types 78 of media (e.g. audio and video) onto a single port is not considered 79 here (but see Section 5.2 of [1]). 81 This memo is structured as follows: in Section 2 we discuss the 82 design choices which led to the use of separate ports, and comment on 83 the applicability of those choices to current network environments. 84 We discuss terminology in Section 3, how to distinguish multiplexed 85 packets in Section 4, and then specify when and how RTP and RTCP 86 should be multiplexed in Section 5. Quality of service and bandwidth 87 issues are discussion in Section 6. We conclude with security 88 considerations in Section 7. 90 This memo updates Section 11 of [1]. 92 2. Background 94 An RTP session comprises data packets and periodic control (RTCP) 95 packets. RTCP packets are assumed to use "the same distribution 96 mechanism as the data packets" and the "underlying protocol MUST 97 provide multiplexing of the data and control packets, for example 98 using separate port numbers with UDP" [1]. Multiplexing was deferred 99 to the underlying transport protocol, rather than being provided 100 within RTP, for the following reasons: 102 1. Simplicity: an RTP implementation is simplified by moving the RTP 103 and RTCP demultiplexing to the transport layer, since it need not 104 concern itself with the separation of data and control packets. 105 This allows the implementation to be structured in a very natural 106 fashion, with a clean separation of data and control planes. 108 2. Efficiency: following the principle of integrated layer 109 processing [13] an implementation will be more efficient when 110 demultiplexing happens in a single place (e.g. according to UDP 111 port) than when split across multiple layers of the stack (e.g. 112 according to UDP port then according to packet type). 114 3. To enable third party monitors: while unicast voice-over-IP has 115 always been considered, RTP was also designed to support loosely 116 coupled multicast conferences [14] and very large-scale multicast 117 streaming media applications (such as the so-called "triple-play" 118 IPTV service). Accordingly, the design of RTP allows the RTCP 119 packets to be multicast using a separate IP multicast group and 120 UDP port to the data packets. This not only allows participants 121 in a session to get reception quality feedback, but also enables 122 deployment of third party monitors which listen to reception 123 quality without access to the data packets. This was intended to 124 provide manageability of multicast sessions, without compromising 125 privacy. 127 While these design choices are appropriate for many use of RTP, they 128 are problematic in some cases. There are many RTP deployments which 129 don't use IP multicast, and with the increased use of Network Address 130 Translation (NAT) the simplicity of multiplexing at the transport 131 layer has become a liability, since it requires complex signalling to 132 open multiple NAT pinholes. In environments such as these, it is 133 desirable to provide an alternative to demultiplexing RTP and RTCP 134 using separate UDP ports, instead using only a single UDP port and 135 demultiplexing within the application. 137 This memo provides such an alternative by multiplexing RTP and RTCP 138 packets on a single UDP port, distinguished by the RTP payload type 139 and RTCP packet type values. This pushes some additional work onto 140 the RTP implementation, in exchange for simplified NAT traversal. 142 3. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [2]. 148 4. Distinguishable RTP and RTCP Packets 150 When RTP and RTCP packets are multiplexed onto a single port, they 151 can be distinguished provided: 1) the RTP payload type (PT) values 152 used are distinct from the RTCP packet types used; and 2) for each 153 RTP payload type, PT+128 is distinct from the RTCP packet types used. 154 The first constraint precludes a direct conflict between RTP payload 155 type and RTCP packet type, the second constraint precludes a conflict 156 between an RTP data packet with marker bit set and an RTCP packet. 157 This demultiplexing method works because the RTP payload type and 158 RTCP packet type occupy the same position within the packet. 160 The following conflicts between RTP and RTCP packet types are known: 162 o RTP payload types 64-65 conflict with the RTCP FIR and NACK 163 packets defined in the RTP Payload Format for H.261 [3]. 165 o RTP payload types 72-76 conflict with the RTCP SR, RR, SDES, BYE 166 and APP packets defined in the RTP specification [1]. 168 o RTP payload types 77-78 conflict with the RTCP RTPFB and PSFB 169 packets defined in the RTP/AVPF profile [4]. 171 o RTP payload type 79 conflicts with RTCP Extended Report (XR) [5] 172 packets. 174 o RTP payload type 80 conflicts with Receiver Summary Information 175 (RSI) packets defined in the RTCP Extensions for Single-Source 176 Multicast Sessions with Unicast Feedback [6]. 178 New RTCP packet types may be registered in future, and will further 179 reduce the RTP payload types that are available when multiplexing RTP 180 and RTCP onto a single port. To allow this multiplexing, future RTCP 181 packet type assignments SHOULD be made after the current assignments 182 in the range 209-223, then in the range 194-199, so that only the RTP 183 payload types in the range 64-95 are blocked. 185 Given these constraints, it is RECOMMENDED to follow the guidelines 186 in the RTP/AVP profile [7] for the choice of RTP payload type values, 187 with the additional restriction that payload type values in the range 188 64-95 MUST NOT be used. Specifically, dynamic RTP payload types 189 SHOULD be chosen in the range 96-127 where possible. Values below 64 190 MAY be used if that is insufficient, in which case it is RECOMMENDED 191 that payload type numbers that are not statically assigned by [7] be 192 used first. 194 Note: since all RTCP packets MUST be sent as compound packets 195 beginning with an SR or an RR packet ([1] Section 6.1), one might 196 wonder why RTP payload types other than 72 and 73 are prohibited 197 when multiplexing RTP and RTCP. This is done to ensure robustness 198 against broken nodes which send non-compliant RTCP packets, which 199 might otherwise be confused with multiplexed RTP packets. 201 5. Multiplexing RTP and RTCP on a Single Port 203 The procedures for multiplexing RTP and RTCP on a single port depend 204 on whether the session is a unicast session or a multicast session. 205 For a multicast sessions, also depends whether ASM or SSM multicast 206 is to be used. 208 5.1. Unicast Sessions 210 It is acceptable to multiplex RTP and RTCP packets on a single UDP 211 port to ease NAT traversal for unicast sessions, provided the RTP 212 payload types used in the session are chosen according to the rules 213 in Section 4. 215 When the Session Description Protocol (SDP) [8] is used to negotiate 216 RTP sessions according to the offer/answer model [9], the "a=rtcp:" 217 attribute [10] is used to indicate the port chosen for RTCP traffic, 218 if the default of using an odd/even port pair is not desirable. If 219 RTP and RTCP are to be multiplexed on a single port, this attribute 220 MUST be included in the initial SDP offer, and MUST indicate the the 221 same port as included in the "m=" line. For example: 223 v=0 224 o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e 225 s=- 226 c=IN IP6 2001:DB8::211:24ff:fea3:7a2e 227 t=1153134164 1153137764 228 m=audio 49170 RTP/AVP 97 229 a=rtpmap:97 iLBC/8000 230 a=rtcp:49170 232 This offer denotes a unicast voice-over-IP session using the RTP/AVP 233 profile with iLBC coding. The answerer is requested to send both RTP 234 and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e. 236 If the answerer supports multiplexing of RTP and RTCP onto a single 237 port it MUST include an "a=rtcp:" attribute in the answer. The port 238 specified in that attribute MUST be the same as that used for RTP in 239 the "m=" line of the answer. The RTP payload types used MUST conform 240 to the rules in Section 4, and the answer MUST be rejected if there 241 is a conflict between the chosen RTP payload types and the expected 242 RTCP packet types. 244 If the answer does not contain an "a=rtcp:" attribute, the offerer 245 MUST NOT multiplex RTP and RTCP packets on a single port. Instead, 246 it must send and receive RTCP on a port allocated according to the 247 usual port pair rules. This will occur when talking to a peer that 248 does not understand the "a=rtcp:" attribute or this specification. 250 If the answer contains an "a=rtcp:" attribute, but that attribute 251 specifies a different port for RTCP than for RTP, then the answer 252 MUST be rejected, and the session re-negotiated using separate RTP 253 and RTCP ports. 255 Answerers which support the "a=rtcp:" attribute but do not understand 256 this memo should reject sessions where the RTP and RTCP ports are the 257 same (Section 11 of [1] prohibits such sessions unless the mechanisms 258 described in this memo are used). It is likely that this is a poorly 259 tested feature of older implementations, however, and implementations 260 should be robust to unexpected behaviour. If the offerer suspects a 261 session was rejected due to the presence of multiplexed RTP and RTCP, 262 it MAY retry the offer using separate ports for RTP and RTCP. 264 When using SIP with a forking proxy, it is possible that multiple 200 265 (OK) answers will be received, some supporting multiplexed RTP and 266 RTCP, some not. This is not an issue if a separate RTP session is 267 established with each answerer, since multiplexing occurs on a per 268 session basis, but does prevent a single RTP session being opened 269 between the offerer and all answerers. 271 TODO: expand this discussion. Does SIP define if this should be a 272 single RTP session or multiple sessions? 274 TODO: discuss interactions between multiplexed RTP and RTCP, and 275 Interactive Connectivity Establishment (ICE) [15]. 277 5.2. Any Source Multicast Sessions 279 The problem of NAT traversal is less severe for any source multicast 280 (ASM) RTP sessions than for unicast RTP sessions, and the benefit of 281 using separate ports for RTP and RTCP is greater, due to the ability 282 to support third party RTCP only monitors. Accordingly, RTP and RTCP 283 packets SHOULD NOT be multiplexed onto a single port when using ASM 284 multicast RTP sessions, and SHOULD instead use separate ports and 285 multicast groups. 287 5.3. Source Specific Multicast Sessions 289 RTP sessions running over Source Specific Multicast (SSM) send RTCP 290 packets from the source to receivers via the multicast channel, but 291 use a separate unicast feedback mechanism [6] to send RTCP from the 292 receivers back to the source, with the source either reflecting the 293 RTCP packets to the group, or sending aggregate summary reports. 295 Following the terminology of [6], we identify three RTP/RTCP flows in 296 an SSM session: 298 1. RTP and RTCP flows between media sender and distribution source. 299 In many scenarios, the media sender and distribution source are 300 collocated, so multiplexing is not a concern. If the media 301 sender and distribution source are connected by a unicast 302 connection, the rules in Section 5.1 of this memo apply to that 303 connection. If the media sender and distribution source are 304 connected by an Any Source Multicast connection, the rules in 305 Section 5.2 apply to that connection. If the media sender and 306 distribution source are connected by a Source Specific Multicast 307 connection, the RTP and RTCP packets MAY be multiplexed on a 308 single port, provided this is signalled (for example, using 309 "a=rtcp:" with the same port number as specified for RTP on the 310 "m=" line, if using SDP). 312 2. RTP and RTCP sent from the distribution source to the receivers. 313 The distribution source MAY multiplex RTP and RTCP onto a single 314 port to ease NAT traversal issues on the forward SSM path, since 315 this does not hinder third party monitoring. When using SDP, the 316 multiplexing MUST be signalled using the "a=rtcp:" attribute [10] 317 with the same port number as specified for RTP on the "m=" line. 319 3. RTCP sent from receivers to distribution source. This is an RTCP 320 only path, so multiplexing is not a concern. 322 Multiplexing RTP and RTCP onto a single port is more acceptable for 323 an SSM session than for an ASM session, since SSM sessions cannot 324 readily make use of third party reception quality monitoring devices 325 that listen to the multicast RTCP traffic but not the data traffic 326 (since the RTCP traffic is unicast to the distribution source, rather 327 than multicast, and since one cannot subscribe to only the RTCP 328 packets on the SSM channel, even if sent on a separate port). 330 6. Multiplexing, Bandwidth, and Quality of Service 332 Multiplexing RTP and RTCP has implications on the use of Quality of 333 Service (QoS) mechanism that handles flow that are determined by a 334 three or five tuple (protocol, port and address for source and/or 335 destination). In these cases the RTCP flow will be merged with the 336 RTP flow when multiplexing them together. Thus the RTCP bandwidth 337 requirement needs to be considered when doing QoS reservations for 338 the combinded RTP and RTCP flow. However from an RTCP perspective it 339 is beneficial to receive the same treatment of RTCP packets as for 340 RTP as it provides more accurate statistics for the measurements 341 performed by RTCP. 343 The bandwidth required for a multiplexed stream comprises the session 344 bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the 345 usual case, the RTP session bandwidth is signalled in the SDP "b=AS:" 346 line, and the RTCP traffic is limited to 5% of this value. Any QoS 347 reservation SHOULD therefore be made for 105% of the "b=AS:" value. 348 If a non-standard RTCP bandwidth fraction is used, signalled by the 349 SDP "b=RR:" and/or "b=RS:" lines [11], then any QoS reservation 350 SHOULD be made for bandwidth equal to (AS + RS + RR), taking the RS 351 and RR values from the SDP answer. 353 7. Security Considerations 355 The security considerations in the RTP specification [1] and any 356 applicable RTP profile (e.g. [7]) and payload format(s) apply. 358 If the Secure Real-time Transport Protocol (SRTP) [12] is to be used 359 in conjunction with multiplexed RTP and RTCP, then multiplexing MUST 360 be done below the SRTP layer. The sender generates SRTP and SRTCP 361 packets in the usual manner, based on their separate cryptographic 362 contexts, and multiplexes them onto a single port immediately before 363 transmission. At the receiver, the cryptographic context is derived 364 from the SSRC, destination network address and destination transport 365 port number in the usual manner, augmented using the RTP payload type 366 and RTCP packet type to demultiplex SRTP and SRTCP according to the 367 rules in Section 4 of this memo. After the SRTP and SRTCP packets 368 have been demultiplexed, cryptographic processing happens in the 369 usual manner. 371 8. IANA Considerations 373 No IANA actions are required. 375 9. Acknowledgements 377 We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar 378 Hellstrom, Randell Jesup, Hadriel Kaplan and Harikishan Desineni for 379 their comments on this memo. This work is supported in part by the 380 UK Engineering and Physical Sciences Research Council. 382 10. References 384 10.1. Normative References 386 [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 387 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 388 RFC 3550, July 2003. 390 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 391 Levels", BCP 14, RFC 2119, March 1997. 393 [3] Turletti, T., "RTP Payload Format for H.261 Video Streams", 394 RFC 2032, October 1996. 396 [4] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 397 "Extended RTP Profile for Real-time Transport Control Protocol 398 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 400 [5] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol 401 Extended Reports (RTCP XR)", RFC 3611, November 2003. 403 [6] Chesterfield, J., "RTCP Extensions for Single-Source Multicast 404 Sessions with Unicast Feedback", draft-ietf-avt-rtcpssm-11 405 (work in progress), March 2006. 407 [7] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video 408 Conferences with Minimal Control", STD 65, RFC 3551, July 2003. 410 [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 411 Description Protocol", RFC 4566, July 2006. 413 [9] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 414 Session Description Protocol (SDP)", RFC 3264, June 2002. 416 [10] Huitema, C., "Real Time Control Protocol (RTCP) attribute in 417 Session Description Protocol (SDP)", RFC 3605, October 2003. 419 [11] Casner, S., "Session Description Protocol (SDP) Bandwidth 420 Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, 421 July 2003. 423 [12] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 424 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 425 RFC 3711, March 2004. 427 10.2. Informative References 429 [13] Clark, D. and D. Tennenhouse, "Architectural Considerations for 430 a New Generation of Protocols", Proceedings of ACM 431 SIGCOMM 1990, September 1990. 433 [14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM 434 SIGCOMM Computer Communication Review, Volume 22, Number 3, 435 July 1992. 437 [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 438 Methodology for Network Address Translator (NAT) Traversal for 439 Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in 440 progress), August 2006. 442 Authors' Addresses 444 Colin Perkins 445 University of Glasgow 446 Department of Computing Science 447 17 Lilybank Gardens 448 Glasgow G12 8QQ 449 UK 451 Email: csp@csperkins.org 453 Magnus Westerlund 454 Ericsson 455 Torshamgatan 23 456 Stockholm SE-164 80 457 Sweden 459 Email: magnus.westerlund@ericsson.com 461 Intellectual Property Statement 463 The IETF takes no position regarding the validity or scope of any 464 Intellectual Property Rights or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; nor does it represent that it has 468 made any independent effort to identify any such rights. Information 469 on the procedures with respect to rights in RFC documents can be 470 found in BCP 78 and BCP 79. 472 Copies of IPR disclosures made to the IETF Secretariat and any 473 assurances of licenses to be made available, or the result of an 474 attempt made to obtain a general license or permission for the use of 475 such proprietary rights by implementers or users of this 476 specification can be obtained from the IETF on-line IPR repository at 477 http://www.ietf.org/ipr. 479 The IETF invites any interested party to bring to its attention any 480 copyrights, patents or patent applications, or other proprietary 481 rights that may cover technology that may be required to implement 482 this standard. Please address the information to the IETF at 483 ietf-ipr@ietf.org. 485 Disclaimer of Validity 487 This document and the information contained herein are provided on an 488 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 489 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 490 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 491 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 492 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 493 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 495 Copyright Statement 497 Copyright (C) The Internet Society (2006). This document is subject 498 to the rights, licenses and restrictions contained in BCP 78, and 499 except as set forth therein, the authors retain all their rights. 501 Acknowledgment 503 Funding for the RFC Editor function is currently provided by the 504 Internet Society.