Network Working Group M. Petit-Huguenin Internet-Draft 8x8, Inc. Intended status: Standards Track March 5, 2007 Expires: September 6, 2007 Preventing Fragmentation for Client Initiated Connections in the Session Initiation Protocol (SIP) draft-petithuguenin-sip-outbound-fragmentation-02 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 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract There is cases when a Session Initiation Protocol (SIP) client can initiate a bidirectional UDP stream or a TCP connection to a SIP server but the SIP server cannot do the same in the other direction. The server can reuse the existing bidirectional UDP stream or TCP connection but cannot use a TCP connection if the client chose to use a bidirectional UDP stream. This document described a method to force the client to initiate a TCP connection to the server. Petit-Huguenin Expires September 6, 2007 [Page 1] Internet-Draft Outbound fragmentation March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 4. Client Discovery of Server . . . . . . . . . . . . . . . . . . 5 5. Server Determination of Usage . . . . . . . . . . . . . . . . 5 6. New Requests or Indications . . . . . . . . . . . . . . . . . 5 6.1. ForceTCP Method . . . . . . . . . . . . . . . . . . . . . 5 6.1.1. Server Behavior . . . . . . . . . . . . . . . . . . . 6 6.1.2. Client Behavior . . . . . . . . . . . . . . . . . . . 6 6.2. GetToken Method . . . . . . . . . . . . . . . . . . . . . 6 6.2.1. Server Behavior . . . . . . . . . . . . . . . . . . . 7 6.2.2. Client Behavior . . . . . . . . . . . . . . . . . . . 7 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. FLOW-TOKEN . . . . . . . . . . . . . . . . . . . . . . . . 8 8. New Error Response Codes . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9.1. New STUN methods . . . . . . . . . . . . . . . . . . . . . 8 9.2. New STUN Attributes . . . . . . . . . . . . . . . . . . . 8 9.3. New STUN response code . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Use with DTLS . . . . . . . . . . . . . . . . . . . . 11 A.1. STUN Keepalive Processing with DTLS . . . . . . . . . . . 11 A.2. Hybrid DTLS-TLS Transport . . . . . . . . . . . . . . . . 11 Appendix B. Delayed STUN Transaction . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1. Norminative References . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Petit-Huguenin Expires September 6, 2007 [Page 2] Internet-Draft Outbound fragmentation March 2007 1. Introduction The SIP specification [RFC3261] uses an hybrid TCP-UDP transport. All the messages exchanged on a specific SIP transaction must use the same transport but an implementation is free to use different transports for each transaction between two SIP elements. The SIP specification only mandates to use the TCP transport or another congestion controlled transport protocol if the size of the message to send is bigger than the MTU. Excepted for the case documented in [I-D.petithuguenin-sip-fragmentation-responses] and [I-D.gurbani-sip-large-udp-response], this mechanism works well on the open Internet. Unfortunately this is no longer the case if the two SIP elements are separated by one or more NATs or firewalls. Bidirectional UDP streams and TCP connections can only be initiated from inside the NAT/firewall and this prevents the outside SIP element to contact the SIP element inside the NAT or firewall. The Outbound [I-D.ietf-sip-outbound] specification fixes this problem by reusing a "flow" (i.e. a bidirectional UDP stream or TCP connection) initiated by the SIP element inside the NAT/firewall for transactions initiated in the reversed direction. The problem with Outbound is that there is only one flow created, either over an UDP or a congestion controlled transport and so the SIP elements no longer have the possibility to choose the best transport for each transaction. Even the SIP element inside the NAT/ firewall cannot easily change the transport as it will have to replace the existing flow by initiating a new REGISTER transaction. Creating two flows, one over UDP and the other over TCP, does not work either as the transport is encoded in the flow token and an edge proxy will have no way to find the TCP connection if the flow token contains the flow information for the UDP bidirectional stream. Because fragmentation must be prevented [I-D.heffner-frag-harmful] and because the Outbound specification prevents hybrid UDP-TCP transport to be used, it effectively changes the definition of SIP by removing the possibility of using UDP, which is mandatory in all SIP elements. There is multiples reasons why a SIP element should be able to choose between an hybrid TCP-UDP transport and a permanent TCP connection. For instance, maintaining thousands of permanent TCP connections uses more resources than using UDP for the same number of UA. A SIP endpoint in fact does not need very often to use TCP to send or receive messages; the SIP registration messages are generally smaller than the MTU; the SIP subscriptions [RFC3265] also generally does not Petit-Huguenin Expires September 6, 2007 [Page 3] Internet-Draft Outbound fragmentation March 2007 need TCP, as partial state update and URL indirection [RFC4483] can be used. It is interesting to note that there is existing research efforts to add hybrid TCP-UDP transport [DHTTP][HYBRID] to HTTP [RFC2616]. Also, it is possible with some kind of NATs to establish a direct bidirectional UDP stream between two UAs for the subsequent SIP requests in a dialog. This is useful when the SIP proxies does not need to be in the path after the creation of the dialog. It is not possible to establish a direct TCP connection between two UA behind NATs. 2. Terminology In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL are to be interpreted as described in [RFC2119] and indicate requirement levels for compliant implementations. 3. Overview of Operation An UA using this specification creates flows as defined in the Outbound specification. If the flow is created over TCP, the processing defined in Outbound is used. If the flow is created over UDP, the UA must be prepared to open a temporary TCP connection to the same destination than the destination used for the UDP flow, as described in section 18.1.1 of [RFC3261]. The UA must be able to associate the UDP flow with the TCP flow and its associated flow token. The flow token is an opaque value which is encoded by the SIP edge proxy. The UA that created a UDP flow can create at any time an additional TCP flow by opening a TCP connection to the same edge proxy, and sending a STUN GetToken request over this connection. The TCP connection is opened to the same IP address and port than the remote IP address and port used by the UDP flow. The edge proxy will respond with a STUN GetToken response with a FLOW-TOKEN attribute that contain a flow token generated as if a REGISTER was received over this TCP connection and the edge proxy had generated a flow token to store in the user part of the SIP URI in the Record-Route. The UA then associates the TCP connection and the flow token with the UDP flow. As long as the TCP connection is open, the UA can use it to send oversized SIP messages to the SIP edge proxy. The UA can close the connection after using it or can keep it open for a longer time. The UA must be ready to handle disconnection from the server. After a disconnection, the UA removes the association between the UDP Petit-Huguenin Expires September 6, 2007 [Page 4] Internet-Draft Outbound fragmentation March 2007 flow and the TCP connection and flow token. When an edge proxy receives a request that need to be forwarded to the UA, it uses the flow token to find the flow. If the flow is over TCP, or over UDP and the message size is lower than the MTU, the processing described in Outbound is used. If the flow is over UDP and the message size is higher than the MTU, then the edge proxy sends a STUN ForceTCP request to the UA over the UDP flow. The UA responds with a STUN ForceTCP response with a FLOW-TOKEN attribute that contains a flow token that can be used as if the edge proxy received it in the request to forward. The UA returns the flow token that is associated to the UDP flow from which it received the STUN ForceTCP request. If there is no flow token associated with the UDP flow, the UA creates a TCP connection and sends a STUN GetToken request to retrieve it from the edge proxy. 4. Client Discovery of Server STUN requires all usages to define the mechanism by which a client discovers the server [I-D.ietf-behave-rfc3489bis]. This STUN usage uses the same source and destination IP address and port than the SIP protocol. In fact it uses the same path than the NAT keepalives usage described in [I-D.ietf-behave-rfc3489bis]. 5. Server Determination of Usage STUN requires all usages to define the mechanism by which the server determines the usage [I-D.ietf-behave-rfc3489bis]. This usage is defined by a specific set of methods. 6. New Requests or Indications This usage defines two new methods: 0xXXX: ForceTCP 0xYYY: GetToken 6.1. ForceTCP Method The ForceTCP method is used by an edge proxy or a registrar when it needs to request the UA to open a TCP connection to the edge proxy or registrar. Petit-Huguenin Expires September 6, 2007 [Page 5] Internet-Draft Outbound fragmentation March 2007 6.1.1. Server Behavior The server first processes the request according to the general request processing rules in [I-D.ietf-behave-rfc3489bis]. The server SHOULD NOT authenticate or look for a MESSAGE-INTEGRITY attribute. If the request is not received over UDP, the server MUST reject the request with a 4XX (Operation for UDP Only) response error code. The server then checks if there is a TCP connection and a flow token associated with the UDP flow that received the request. If there is no existing TCP connection associated with the UDP flow, the server will use the procedures defined in Section 6.2 to create a TCP connection and retrieve a flow token. The newly created connection and the retrieved flow token are associated with the existing UDP flow. The server generates a ForceTCP response using the general procedures defines in [I-D.ietf-behave-rfc3489bis]. The flow token associated with the UDP flow MUST be included in the FLOW-TOKEN attribute in the response. 6.1.2. Client Behavior An edge proxy that receives a SIP request that, after been processed according to section 5.3 of [I-D.ietf-sip-outbound], will be forwarded over an UDP flow with a MTU smaller than the size of the SIP message MUST send a ForceTCP request to the UA over the UDP flow. This request is constructed and sent using the general procedures defined in [I-D.ietf-behave-rfc3489bis]. Processing of the response follows the general procedures of [I-D.ietf-behave-rfc3489bis]. A successful response will contain a FLOW-TOKEN attribute that contain a flow token for a TCP connection that can be used to send the oversized SIP message to the same destination than the flow token that was extracted from the received SIP request. If the edge proxy receives a 400 response, it knows that the UA does not support this specification and MUST reject the SIP request with a 430 (Flow Failed), as if the flow was not found. 6.2. GetToken Method The GetToken method is used by an UA to establish a TCP connection and request a flow token that can be used by the edge proxy. Petit-Huguenin Expires September 6, 2007 [Page 6] Internet-Draft Outbound fragmentation March 2007 6.2.1. Server Behavior The server first processes the request according to the general request processing rules in [I-D.ietf-behave-rfc3489bis]. The server SHOULD NOT authenticate or look for a MESSAGE-INTEGRITY attribute. If the request is not received over TCP, the server MUST reject the request with a 445 (Operation for TCP Only) response error code [I-D.ietf-behave-turn]. The server then generates a flow token as if a SIP REGISTER request was received over this TCP connection. The server can use any one of the algorithms listed in [I-D.ietf-sip-outbound] or any other algorithm. The server then generates a GetToken response using the procedures defined in [I-D.ietf-behave-rfc3489bis]. The flow token MUST be included in the FLOW-TOKEN attribute in the response. The server SHOULD NOT close the connection after the end of the SIP transaction. It MAY close the connection if it is a long lived connection and resources need to be reclaimed. 6.2.2. Client Behavior An UA can at any time, or when receiving a ForceTCP request without existing TCP connection, create a TCP connection and send a GetToken request over this connection. This request is constructed and sent using the general procedures defined in [I-D.ietf-behave-rfc3489bis]. Processing of the response follows the general procedures of [I-D.ietf-behave-rfc3489bis]. A successful response will contain a FLOW-TOKEN attribute that contain a flow token for the newly created TCP connection. This flow token can be associated with the UDP flow and the TCP connection to be used later when the UA will receive a ForceTCP request. The UA SHOULD NOT close the connection as soon it has received the STUN response and SHOULD keep it open until at least the end of the SIP transaction or 5 seconds if there is no SIP transaction on the connection. The UA can keep the connection open after the end of the SIP transaction but MUST be ready to process a disconnection from the server. 7. New Attributes This usage defines the following new attributes: Petit-Huguenin Expires September 6, 2007 [Page 7] Internet-Draft Outbound fragmentation March 2007 0xXXXX: FLOW-TOKEN 7.1. FLOW-TOKEN The FLOW-TOKEN attribute is present in the ForceTCP and GetToken responses and contains a flow token as defined by [I-D.ietf-sip-outbound]. The value of FLOW-TOKEN is a variable length opaque value and can be the result of one of the algorithms defined in section 5.2 of [I-D.ietf-sip-outbound] or any other algorithm. The base64 encoding step described in the algorithms can be skipped. If the FLOW-TOKEN is not a multiple of four bytes it is padded for encoding into the STUN message, in which case the attribute length represents the length of the FLOW-TOKEN prior to padding. 8. New Error Response Codes This usage defines the following new Error response code: 4XX (Operation for UDP Only): The client tried to send a request to perform a UDP-only operation. 9. IANA Considerations This specification defines two new STUN methods and one response code. This section directs IANA to add these protocol elements to the IANA registry of STUN protocol elements. 9.1. New STUN methods 0xXXX: ForceTCP 0xYYY: GetToken 9.2. New STUN Attributes 0xXXXX: FLOW-TOKEN 9.3. New STUN response code 4YY Operation for UDP Only 10. Security Considerations TBD Petit-Huguenin Expires September 6, 2007 [Page 8] Internet-Draft Outbound fragmentation March 2007 (Page intentionally left blank) Petit-Huguenin Expires September 6, 2007 [Page 9] Internet-Draft Outbound fragmentation March 2007 11. Example In Figure 1, The vertical line made of ":" characters represents a firewall or a NAT. The horizontal lines made of "-" characters represent the sending of messages over UDP and the horizontal lines made of "=" characters represent the sending of messages over TCP. Endpoint : Edge Registrar Home | : | | | | REGISTER : | | | F1 |-------------------->| REGISTER | | F2 | : |==========>| | | : | 200 R | | F3 | : 200 R |<==========| | F4 |<--------------------| | | | Binding Request | | | F5 |-------------------->| | | | Binding Response | | | F6 |<--------------------| | | : : : : : : : : : : | : | | | INVITE F7 | : | | INVITE |<======== F8 | ForceTCP Request |<======================| F9 |<--------------------| | | | GetToken Request | | | F10 |====================>| | | | GetToken Response | | | F11 |<====================| | | | ForceTCP Response | | | F12 |-------------------->| | | | : INVITE | | | F13 |<====================| | | | 200 I : | | | F14 |====================>| 200 I | | | : |======================>| 200 I | : | | |========> | : | | | ACK | : | | ACK |<======== | : ACK |<======================| F15 |<--------------------| | | | : | | | Figure 1 Petit-Huguenin Expires September 6, 2007 [Page 10] Internet-Draft Outbound fragmentation March 2007 F1: The UA sends a REGISTER request over UDP to the edge proxy. F2: The edge proxy proxies the REGISTER request to the registrar using TCP. The registrar sends a 200 OK response to the edge proxy. F4: The edge proxy forwards the 200 OK to the UA. F5: The UA sends a STUN Binding Request to the edge proxy to keep the binding alive. F6: The edge proxy responds by sending a Binding Response to the UA. F7: The home proxy receives an INVITE request. F8: The home proxy queries the registrar (not shown in the diagram), and proxies the request to the edge proxy. F9: The edge proxy finds that the request cannot be sent over the existing UDP flow because the packet size is higher that the MTU. The edge proxy uses the flow token to send a STUN ForceTCP request over the UDP flow. F10: The UA immediately open a TCP connection to the edge proxy and send a STUN GetToken request. F11: The edge proxy calculates a flow token for the TCP connection and send it back to the UA over the same TCP connection in a GetToken response. F12: The UA copies the flow token received on the TCP connection and send it to the edge proxy in a STUN ForceTCP response over the UDP flow. F13: The edge proxy now have a TCP token that can be used to send the INVITE to the UA over a TCP flow. F14: The UA responds to the INVITE request by sending a 200 OK response over the TCP flow and close the TCP connection. F15: The SIP ACK message is received by the edge proxy and sent over the UDP flow as it is smaller than the MTU. Appendix A. Use with DTLS The current version of Outbound does not describe the usage of SIP over DTLS [I-D.jennings-sip-dtls]. This section extends Outbound and this specification to support an hybrid DTLS-TLS transport. A.1. STUN Keepalive Processing with DTLS When STUN is used together with DTLS [RFC4347] the STUN messages are sent unprotected. This is consistent with the usage of STUN in DTLS in [I-D.fischl-sipping-media-dtls] and [I-D.mcgrew-tls-srtp] A.2. Hybrid DTLS-TLS Transport The mechanism to switch between DTLS and TLS is the same than for switching between UDP and TLS, with the following differences: Petit-Huguenin Expires September 6, 2007 [Page 11] Internet-Draft Outbound fragmentation March 2007 o A new STUN method, ForceTLS, is used instead of ForceTCP. If this method is not received over DTLS, the server rejects it with a 4ZZ (Operation for DTLS Only) response error code. o The GetToken method must be used over a TLS connection. To improve the performance, the TLS connection must use session resumption so the master_secret established in the DTLS connection can be reused. The TLS connection should also use [RFC4507] to store the TLS/DTLS state in the UA. Appendix B. Delayed STUN Transaction One of the problem with this specification is that the ForceTCP response will be sent only after the completion of the GetToken transaction in the opposite direction, which will trigger retransmissions and eventually a timeout. One solution would have been to send a 100 STUN response to stop the retransmission, but this left no way to reliably send the response. Another way to fix this problem is to use ForceTCP indications in both directions and to retransmit the ForceTCP indication from the proxy to the UA until a ForceTCP indication is received by the proxy from the UA, but at a slower pace than the normal STUN retransmission. There is other solutions that require modifications in the STUN specification. 12. References 12.1. Norminative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [I-D.ietf-behave-rfc3489bis] Rosenberg, J., "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 (work in progress), October 2006. [I-D.ietf-behave-turn] Rosenberg, J., "Obtaining Relay Addresses from Simple Petit-Huguenin Expires September 6, 2007 [Page 12] Internet-Draft Outbound fragmentation March 2007 Traversal Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in progress), October 2006. [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-07 (work in progress), January 2007. 12.2. Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 4507, May 2006. [I-D.fischl-sipping-media-dtls] Fischl, J., "Datagram Transport Layer Security (DTLS) Protocol for Protection of Media Traffic Established with the Session Initiation Protocol", draft-fischl-sipping-media-dtls-01 (work in progress), June 2006. [I-D.gurbani-sip-large-udp-response] Gurbani, V. and S. Lawrence, "Handling Large User Datagram Protocol (UDP) Responses in the Session Initiation Protocol (SIP)", draft-gurbani-sip-large-udp-response-00 (work in progress), October 2006. [I-D.heffner-frag-harmful] Heffner, J., "IPv4 Reassembly Errors at High Data Rates", draft-heffner-frag-harmful-04 (work in progress), January 2007. [I-D.jennings-sip-dtls] Jennings, C. and N. Modadugu, "Session Initiation Protocol (SIP) over Datagram Transport Layer Security (DTLS)", Petit-Huguenin Expires September 6, 2007 [Page 13] Internet-Draft Outbound fragmentation March 2007 draft-jennings-sip-dtls-03 (work in progress), February 2007. [I-D.mcgrew-tls-srtp] Rescorla, E. and D. McGrew, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", draft-mcgrew-tls-srtp-00 (work in progress), June 2006. [I-D.petithuguenin-sip-fragmentation-responses] Petit-Huguenin, M., "Preventing IP Fragmentation in Responses for the Session Initiation Protocol (SIP)", draft-petithuguenin-sip-fragmentation-responses-01 (work in progress), December 2006. [DHTTP] Rabinovich, M., "DHTTP: An Efficient and Cache-Friendly Transfer Protocol for the Web", in IEEE/ACM Transactions on Networking, Vol. 12, No 6, December 2004. [HYBRID] Cidon, I., Gupta, A., Rom, R., and C. Schuba, "Hybrid TCP- UDP Transport for Web Traffic", in Proc. IEEE Int. Performance, Computing and Communications Conf, pp 177- 184, January 1999. Author's Address Marc Petit-Huguenin 8x8, Inc. 3151 Jay Street Santa Clara, CA 95054 US Phone: +1 408 654 0875 Email: marc@8x8.com Petit-Huguenin Expires September 6, 2007 [Page 14] Internet-Draft Outbound fragmentation March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Petit-Huguenin Expires September 6, 2007 [Page 15]