One document matched: draft-petithuguenin-sip-outbound-fragmentation-02.txt
Differences from draft-petithuguenin-sip-outbound-fragmentation-01.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 16:07:57 |