RFC3581 日本語訳
3581 An Extension to the Session Initiation Protocol (SIP) forSymmetric Response Routing. J. Rosenberg, H. Schulzrinne. August 2003. (Format: TXT=66133 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 3581 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia University
August 2003
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3581dynamicsoft Category: 標準化過程H.Schulzrinneコロンビア大学2003年8月
An Extension to the Session Initiation Protocol (SIP) for
Symmetric Response Routing
左右対称の応答ルート設定のためのセッション開始プロトコル(一口)への拡大
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.
Session Initiationプロトコル(SIP)は特にUDPとTCPの上で作動します。 UDPと共に使用すると、要求が来たソースアドレスと、そして、要求の最上のViaヘッダーフィールド価値に書かれたポートに要求への応答を返します。 クライアントがNetwork Address Translator(NAT)の後ろにいるとき、多くの場合、この振舞いは最も著しく望ましくはありません。 この拡大はクライアントが、サーバが要求が起因したソースIPアドレスとポートに応答を送り返すよう要求できる"rport"と呼ばれるViaヘッダーフィールドのための新しいパラメタを定義します。
Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[1ページ]RFC3581
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
4. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . 8
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . 8
9.3. Brittleness Introduced by this Specification . . . . . . 9
9.4. Requirements for a Long Term Solution . . . . . . . . . 10
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11
12. Intellectual Property and Copyright Statements . . . . . . . . 11
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 クライアントの振舞い. . . . . . . . . . . . . . . . . . . . . . . 3 4。 サーバの振舞い. . . . . . . . . . . . . . . . . . . . . . . 4 5。 構文. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 6 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 6 9。 IAB問題. . . . . . . . . . . . . . . . . . . . . . 6 9.1。 問題定義. . . . . . . . . . . . . . . . . . . 8 9.2。 撤退戦略. . . . . . . . . . . . . . . . . . . . . 8 9.3。 このSpecification. . . . . . 9 9.4によるもろさIntroduced。 長期ソリューション. . . . . . . . . 10 9.5のための要件。 既存のNAPT箱. . . . . . . . . . . . 10 10の問題。 承認. . . . . . . . . . . . . . . . . . . . . . . 10 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1。 引用規格. . . . . . . . . . . . . . . . . . 11 11.2。 有益な参照. . . . . . . . . . . . . . . . . 11 12。 知的所有権と著作権宣言文. . . . . . . . 11 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 12 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
The Session Initiation Protocol (SIP) [1] operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This results in a "hybrid" way of computing the destination of the response. Half of the information (specifically, the IP address) is taken from the IP packet headers, and the other half (specifically, the port) from the SIP message headers. SIP operates in this manner so that a server can listen for all messages, both requests and responses, on a single IP address and port. This helps improve scalability. However, this behavior is not desirable in many cases, most notably, when the client is behind a NAT. In that case, the response will not properly traverse the NAT, since it will not match the binding established with the request.
Session Initiationプロトコル(SIP)[1]はUDPとTCPの上で作動します。 UDPと共に使用すると、要求が来たソースアドレスと、そして、要求の最上のViaヘッダーフィールド価値に書かれたポートに要求への応答を返します。 これは応答の目的地を計算する「ハイブリッド」の方法をもたらします。 IPパケットのヘッダー、およびSIPメッセージヘッダーからの他の半分(明確にポート)から半分の情報(明確にIPアドレス)を取ります。 SIPはサーバがメッセージ、要求と応答のすべての両方の聞こうとすることができるように、この様に作動します、ただ一つのIPアドレスとポートの上で。 これは、スケーラビリティを改良するのを助けます。 しかしながら、クライアントがNATの後ろにいるとき、多くの場合、この振舞いは最も著しく望ましくはありません。 その場合、応答は適切にNATを横断しないでしょう、要求で確立された結合に合わないので。
Furthermore, there is currently no way for a client to examine a response and determine the source port that the server saw in the corresponding request. Currently, SIP provides the client with the source IP address that the server saw in the request, but not the port. The source IP address is conveyed in the "received" parameter in the topmost Via header field value of the response. This information has proved useful for basic NAT traversal, debugging
その上、現在、クライアントが応答を調べて、ソースポートを決定するサーバが対応する要求で見た方法が全くありません。 現在、SIPはサーバがポートではなく、要求で見たソースIPアドレスをクライアントに提供します。 ソースIPアドレスは応答の最上のViaヘッダーフィールド価値における「受け取られていている」パラメタで伝えられます。 この情報は基本的なNAT縦断の役に立って、デバッグしていると判明しました。
Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[2ページ]RFC3581
purposes, and support of multi-homed hosts. However, it is incomplete without the port information.
目的、およびサポート、マルチ、家へ帰り、ホスト。 しかしながら、それはポート情報なしで不完全です。
This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port where the request came from. The "rport" parameter is analogous to the "received" parameter, except "rport" contains a port number, not the IP address.
この拡大はクライアントが、サーバが要求が来たソースIPアドレスとポートに応答を送り返すよう要求できる"rport"と呼ばれるViaヘッダーフィールドのための新しいパラメタを定義します。 "rport"パラメタは、「受け取られていている」パラメタに類似していて、"rport"を除いて、IPアドレスではなく、ポートナンバーを含んでいます。
2. Terminology
2. 用語
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 BCP 14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[2]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Client Behavior
3. クライアントの振舞い
The client behavior specified here affects the transport processing defined in Section 18.1 of SIP (RFC 3261) [1].
ここで指定されたクライアントの振舞いはSIP(RFC3261)[1]のセクション18.1で定義された輸送処理に影響します。
A client, compliant to this specification (clients include UACs and proxies), MAY include an "rport" parameter in the top Via header field value of requests it generates. This parameter MUST have no value; it serves as a flag to indicate to the server that this extension is supported and requested for the transaction.
この仕様(クライアントはUACsとプロキシを入れる)に言いなりになっているクライアントはそれが生成する要求の最高Viaヘッダーフィールド価値で"rport"パラメタを入れるかもしれません。 このパラメタには、値が全くあってはいけません。 サーバに示す旗として、この拡大がトランザクションのためにサポートされて、要求されているのは機能します。
When the client sends the request, if the request is sent using UDP, the client MUST be prepared to receive the response on the same IP address and port it used to populate the source IP address and source port of the request. For backwards compatibility, the client MUST still be prepared to receive a response on the port indicated in the sent-by field of the topmost Via header field value, as specified in Section 18.1.1 of SIP [1].
要求にUDPを使用させるならクライアントが要求を送るとき、クライアントは、要求のソースIPアドレスとソースポートに居住するために同じIPアドレスとそれが使用したポートの上で応答を受ける用意ができていなければなりません。 遅れている互換性のために、クライアントはそうしなければなりませんでした、それでも、準備されていて、ポートの上で応答を受けるのが発信しているところで最上のViaヘッダーフィールド価値の分野を示しました、.1セクション18.1SIP[1]で指定されるように。
When there is a NAT between the client and server, the request will create (or refresh) a binding in the NAT. This binding must remain in existence for the duration of the transaction in order for the client to receive the response. Most UDP NAT bindings appear to have a timeout of about one minute. This exceeds the duration of non- INVITE transactions. Therefore, responses to a non-INVITE request will be received while the binding is still in existence. INVITE transactions can take an arbitrarily long amount of time to complete. As a result, the binding may expire before a final response is received. To keep the binding fresh, the client SHOULD retransmit its INVITE every 20 seconds or so. These retransmissions will need to take place even after receiving a provisional response.
クライアントとサーバの間にNATがあるとき、要求はNATにおける結合を作成するでしょう(リフレッシュしてください)。 この結合はクライアントにとって、整然としているトランザクションの持続時間が応答を受けるように現存していたままで残らなければなりません。 ほとんどのUDP NAT結合がおよそ1分のタイムアウトを持っているように見えます。 これは非INVITEのトランザクションの持続時間を超えています。 したがって、結合がまだ現存している間、非INVITE要求への応答を受けるでしょう。 トランザクションが完成するには任意に長い時かかるかもしれないINVITE。 その結果、最終的な応答が受け取られている前に結合は期限が切れるかもしれません。 結合を新鮮に保つために、クライアントSHOULDはおよそ20秒毎にINVITEを再送します。 これらの「再-トランスミッション」は、暫定的な応答を受けた後にさえ行われる必要があるでしょう。
Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[3ページ]RFC3581
A UA MAY execute the binding lifetime discovery algorithm in Section 10.2 of RFC 3489 [4] to determine the actual binding lifetime in the NAT. If it is longer than 1 minute, the client SHOULD increase the interval for request retransmissions up to half of the discovered lifetime. If it is shorter than one minute, it SHOULD decrease the interval for request retransmissions to half of the discovered lifetime. Note that discovery of binding lifetimes can be unreliable. See Section 14.3 of RFC 3489 [4].
UA MAYは、NATにおける実際の拘束力がある生涯を決定するためにRFC3489[4]のセクション10.2の拘束力がある生涯発見アルゴリズムを実行します。 それが1分より長いなら、クライアントSHOULDは要求「再-トランスミッション」のために間隔を発見された生涯の半分まで増強します。 それは1分より短いです、それ。SHOULDは要求「再-トランスミッション」のために発見された生涯の半分と間隔を減少させます。 拘束力がある生涯の発見が頼り無い場合があることに注意してください。 RFC3489[4]のセクション14.3を見てください。
4. Server Behavior
4. サーバの振舞い
The server behavior specified here affects the transport processing defined in Section 18.2 of SIP [1].
ここで指定されたサーバの振舞いはSIP[1]のセクション18.2で定義された輸送処理に影響します。
When a server compliant to this specification (which can be a proxy or UAS) receives a request, it examines the topmost Via header field value. If this Via header field value contains an "rport" parameter with no value, it MUST set the value of the parameter to the source port of the request. This is analogous to the way in which a server will insert the "received" parameter into the topmost Via header field value. In fact, the server MUST insert a "received" parameter containing the source IP address that the request came from, even if it is identical to the value of the "sent-by" component. Note that this processing takes place independent of the transport protocol.
この仕様(プロキシかUASであるかもしれない)への対応することのサーバが要求を受け取るとき、それは最上のViaヘッダーフィールド価値を調べます。 このViaヘッダーフィールド価値が値なしで"rport"パラメタを含んでいるなら、それは要求のソースポートにパラメタの値を設定しなければなりません。 これはサーバが「受け取られていている」パラメタを最上のViaヘッダーフィールド価値に挿入する方法に類似しています。 事実上、サーバは要求が来たソースIPアドレスを含む「受け取られていている」パラメタを挿入しなければなりません、それが「送って」コンポーネントの値と同じであっても。 この処理がトランスポート・プロトコルの如何にかかわらず行われることに注意してください。
When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter. The response MUST be sent from the same address and port that the corresponding request was received on. This effectively adds a new processing step between bullets two and three in Section 18.2.2 of SIP [1].
サーバが、応答を送るのを試みるとき、それはその応答の最上のViaヘッダーフィールド価値を調べます。 「送られたプロトコル」コンポーネントがUDPなどのように頼り無いユニキャストトランスポート・プロトコルを示して、"maddr"パラメタが全くありませんが、「受け取られていている」パラメタと"rport"パラメタの両方があれば、"rport"パラメタで「受け取られていている」パラメタに記載されたIPアドレス、およびポートに応答を送らなければなりません。 同じアドレスと対応が受け取られたよう要求するポートから応答を送らなければなりません。 事実上、これは.2セクション18.2SIP[1]の弾丸2とthreeの間の新しい処理ステップを加えます。
The response must be sent from the same address and port that the request was received on in order to traverse symmetric NATs. When a server is listening for requests on multiple ports or interfaces, it will need to remember the one on which the request was received. For a stateful proxy, storing this information for the duration of the transaction is not an issue. However, a stateless proxy does not store state between a request and its response, and therefore cannot remember the address and port on which a request was received. To properly implement this specification, a stateless proxy can encode the destination address and port of a request into the Via header field value that it inserts. When the response arrives, it can extract this information and use it to forward the response.
要求が左右対称のNATsを横断するために受け取られた同じアドレスとポートから応答を送らなければなりません。 サーバが複数のポートかインタフェースに関する要求の聞こうとしているとき、それは、要求が受け取られたものを覚えている必要があるでしょう。 statefulプロキシにおいて、トランザクションの持続時間のためのこの情報を保存するのは、問題ではありません。 しかしながら、状態がないプロキシは、要求とその応答の間の状態を保存しないで、したがって、要求が受け取られたアドレスとポートを思い出すことができません。 適切にこの仕様を履行するために、状態がないプロキシはそれが挿入するViaヘッダーフィールド価値に要求の送付先アドレスとポートをコード化できます。 応答が到着するとき、それは、この情報を抜粋して、応答を進めるのにそれを使用できます。
Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[4ページ]RFC3581
5. Syntax
5. 構文
The syntax for the "rport" parameter is:
"rport"パラメタのための構文は以下の通りです。
response-port = "rport" [EQUAL 1*DIGIT]
応答ポートは"rport"と等しいです。[等しい1*ケタ]
This extends the existing definition of the Via header field parameters, so that its BNF now looks like:
これがViaヘッダーフィールドパラメタの既存の定義を広げているので、BNFは現在、似ています:
via-params = via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension
を通してmaddrのttlのparamsの=//、-、受け取られている、支店の//応答ポート/、拡大
6. Example
6. 例
A client sends an INVITE to a proxy server which looks like, in part:
クライアントは一部似ているプロキシサーバにINVITEを送ります:
INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
INVITE一口: user@example.com SIP/2.0Via: 一口/2.0/UDP10.1.1.1: 4540; rport; ブランチ=z9hG4bKkjshdyff
This INVITE is sent with a source port of 4540 and a source IP address of 10.1.1.1. The proxy is at 192.0.2.2 (proxy.example.com), listening on both port 5060 and 5070. The client sends the request to port 5060. The request passes through a NAT on the way to the proxy, so that the source IP address appears as 192.0.2.1 and the source port as 9988. The proxy forwards the request, but not before appending a value to the "rport" parameter in the proxied request:
4540年のソースポートと.1がIPが.1に10.1を扱うソースと共にこのINVITEを送ります。 プロキシは192.0でそうです。.2 ポート5060と5070年の両方で聴かれる.2(proxy.example.com)。 クライアントは5060を移植するという要求を送ります。 要求はプロキシへの途中にNATを通り抜けます、ソースIPアドレスが192.0として現れるように。.2 9988としての.1とソースポート。 プロキシは、proxied要求で要求を転送しますが、"rport"パラメタに値を追加する前に、転送するというわけではありません:
INVITE sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
INVITE一口: user@example.com SIP/2.0Via: 一口/2.0/UDP proxy.example.com; ブランチは以下を通ってz9hG4bKkjsh77と等しいです。 一口/2.0/UDP、10.1、.1、.1:4540、;容認された=192.0.2.1; rport=9988;ブランチがz9hG4bKkjshdyffと等しい
This request generates a response which arrives at the proxy:
この要求はプロキシに到着する応答を生成します:
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKkjsh77
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
以下を通って一口/2.0 200OK 一口/2.0/UDP proxy.example.com; ブランチは以下を通ってz9hG4bKkjsh77と等しいです。 一口/2.0/UDP、10.1、.1、.1:4540、;容認された=192.0.2.1; rport=9988;ブランチがz9hG4bKkjshdyffと等しい
The proxy strips its top Via header field value, and then examines the next one. It contains both a "received" parameter and an "rport" parameter. The server follows the rules specified in Section 4 and sends the response to IP address 192.0.2.1, port 9988, and sends it from port 5060 on 192.0.2.2:
プロキシは、最高Viaヘッダーフィールド価値を剥取って、次に、次のものを調べます。 それは「受け取られていている」パラメタと"rport"パラメタの両方を含んでいます。 サーバがセクション4で指定された規則に従って、IPアドレスに応答を送る、192.0、.2、.1、192.0のポート5060から9988を移植して、それを送る、.2、.2:
Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[5ページ]RFC3581
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.1.1:4540;received=192.0.2.1;rport=9988
;branch=z9hG4bKkjshdyff
以下を通って一口/2.0 200OK 一口/2.0/UDP、10.1、.1、.1:4540、;容認された=192.0.2.1; rport=9988;ブランチがz9hG4bKkjshdyffと等しい
This packet matches the binding created by the initial request. Therefore, the NAT rewrites the destination address of this packet back to 10.1.1.1, and the destination port back to 4540. It forwards this response to the client, which is listening for the response on that address and port. The client properly receives the response.
このパケットは初期の要求で作成された結合に合っています。 したがって、NATはこのパケットの送付先アドレスを10.1に書き直して戻します。.1 .1、および4540への仕向港。 それはクライアントへのこの応答を進めます。(そのクライアントは、そのアドレスとポートの上で応答の聞こうとしています)。 クライアントは適切に応答を受けます。
7. Security Considerations
7. セキュリティ問題
When a server uses this specification, responses that it sends will now include the source port where the request came from. In some instances, the source address and port of a request are sensitive information. If they are sensitive, requests SHOULD be protected by using SIP over TLS [1]. In such a case, this specification does not provide any response routing functions (as these only work with TCP); it merely provides the client with information about the source port as seen by the server.
サーバが現在この仕様を使用するとき、それが送る応答は要求が来たソースポートを含むでしょう。 ある場合に、要求のソースアドレスとポートは機密情報です。 それらが敏感な要求SHOULDであるなら、TLS[1]の上でSIPを使用することによって、保護されてください。 このような場合には、この仕様は少しの応答経路選択機能も提供しません(これらがTCPと共に働いているだけであるので)。 それは単にサーバによって見られるソースポートの情報をクライアントに提供します。
It is possible that an attacker might try to disrupt service to a client by acting as a man-in-the-middle, modifying the "rport" parameter in a Via header in a request sent by a client. Removal of this parameter will prevent clients from behind NATs from receiving service. The addition of the parameter will generally have no impact. Of course, if an attacker is capable of launching a man-in- the-middle attack, there are many other ways of denying service, such as merely discarding the request. Therefore, this attack does not seem significant.
攻撃者が中央の男性として機能することによってクライアントに対するサービスを中断しようとするのは、可能です、クライアントによって送られた要求におけるViaヘッダーで"rport"パラメタを変更して。 このパラメタの取り外しによって、NATsの後ろからのクライアントはサービスを受けることができないでしょう。 一般に、パラメタの追加には、影響力が全くないでしょう。 もちろん、攻撃者が中の男性を送り出すことができるなら-、-、中央、攻撃、サービスを否定する他の多くの方法があります、単に要求を捨てるのなどように。 したがって、この攻撃は重要に見えません。
8. IANA Considerations
8. IANA問題
There are no IANA considerations associated with this specification.
この仕様に関連しているどんなIANA問題もありません。
9. IAB Considerations
9. IAB問題
The IAB has studied a class of protocols referred to as Unilateral Self Address Fixing (UNSAF) protocols [5]. These protocols allow a client behind a NAT to learn the IP address and port that a NAT will allocate for a particular request, in order to use this information in application layer protocols. An example of an UNSAF protocol is the Simple Traversal of UDP Through NATs (STUN) [4].
IABはUnilateral Self Address Fixing(UNSAF)プロトコル[5]と呼ばれるプロトコルのクラスを研究しました。 NATの後ろのクライアントはこれらのプロトコルで、NATが特定の要求のために割り当てるIPアドレスとポートを学ぶことができます、応用層プロトコルにこの情報を使用するために。 UNSAFプロトコルに関する例はUDP Through NATs(STUN)[4]のSimple Traversalです。
Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[6ページ]RFC3581
Any protocol is an UNSAF protocol if it reveals, to a client, the source IP address and port of a packet sent through that NAT. Although not designed for that purpose, this specification can be used as an UNSAF protocol. Using the "rport" parameter (defined here) and the "received" parameter (defined in RFC 3261 [1]) in the topmost Via header field value of a response, a client sending a request can learn its address as it was seen by the server which sent the response.
パケットのアドレスとポートがそのNATを通して送ったソースIPをクライアントに明らかにするなら、どんなプロトコルもUNSAFプロトコルです。 そのために設計されていませんが、UNSAFプロトコルとしてこの仕様を使用できます。 "rport"パラメタ(ここで、定義される)と「受け取られていている」パラメタを使用する、(応答の最上のViaヘッダーフィールド価値でRFC3261[1])で定義されています、サーバによってどれが応答を送ったかが見られたとき、要求を送るクライアントはアドレスを学ぶことができます。
There are two uses of this information. The first is for registrations. Consider a client behind a NAT wishing to register with a proxy/registrar on the other side of the NAT. The client must provide, in its registration, the address at which it should receive incoming SIP requests from the proxy. However, since the client is located behind a NAT, none of the addresses on any of its interfaces will be reachable from the proxy. If the client can provide the proxy with an address that the proxy can reach, the client can receive incoming requests. Using this specification, a client behind a NAT can learn its address and port as seen by the proxy which receives a REGISTER request. The client can then perform an additional registration, using this address in a Contact header. This would allow a client to receive incoming requests, such as INVITE, on the IP address and port it used to populate the source IP address and port of the registration it sent. This approach will only work when servers send requests to a UA from the same address and port on which the REGISTER itself was received.
この情報の2つの用途があります。 1番目は登録証明書のためのものです。 NATの反対側の上にプロキシ/記録係とともに記名することを願っていて、NATの後ろでクライアントを考えてください。 クライアントはそれがプロキシから入って来るSIP要求を受け取るべきであるアドレスを登録に提供しなければなりません。 しかしながら、クライアントがNATの後ろに位置しているので、インタフェースのどれかに関するアドレスのいずれもプロキシから届かないでしょう。 クライアントがプロキシが達することができるアドレスをプロキシに提供できるなら、クライアントは入って来る要求を受け取ることができます。 この仕様を使用して、NATの後ろのクライアントはプロキシによって見られるそのアドレスとポートを学ぶことができます(REGISTER要求を受け取ります)。 そして、Contactヘッダーでこのアドレスを使用して、クライアントは追加登録を実行できます。 これで、クライアントは入って来る要求を受け取ることができるでしょう、INVITEなどのように、それがそれが送った登録のソースIPアドレスとポートに居住するのに使用したIPアドレスとポートの上で。 サーバが要求をREGISTER自身が受け取られた同じアドレスとポートからUAに送るときだけ、このアプローチは働くでしょう。
In many cases, the server to whom the registration is sent won't be the registrar itself, but rather a proxy which then sends the request to the registrar. In such a case, any incoming requests for the client must traverse the proxy to whom the registration was directly sent. The Path header extension to SIP [3] allows the proxy to indicate that it must be on the path of such requests.
多くの場合、登録が送られるサーバは記録係自身ではなく、むしろプロキシになるでしょう(次に、要求を記録係に送ります)。 このような場合には、クライアントを求めるどんな入って来る要求も登録が直接送られたプロキシを横断しなければなりません。 SIP[3]へのPathヘッダー拡張子で、プロキシは、それがそのような要求の経路にあるに違いないのを示すことができます。
The second usage is for record routing, to address the same problem as above, but between two proxies. A proxy behind a NAT which forwards a request to a server can use OPTIONS, for example, to learn its address as seen by that server. This address can be placed into the Record-Route header field of requests sent to that server. This would allow the proxy to receive requests from that server on the same IP address and port it used to populate the source IP address and port of the OPTIONS request.
2番目の用法は、上の同じその問題を訴えるために掘られる記録のためにありますが、2つのプロキシの間には、あります。 例えば、要求をサーバに転送するNATの後ろのプロキシは、そのサーバによって見られるようにアドレスを学ぶのにOPTIONSを使用できます。そのサーバに送られた要求のRecord-ルートヘッダーフィールドにこのアドレスは置くことができます。これは、OPTIONS要求のソースIPアドレスとポートに居住するためにプロキシが同じIPアドレスとそれが使用したポートの上にそのサーバから要求を受け取るのを許容するでしょう。
Because of this potential usage, this document must consider the issues raised in [5].
この潜在的用法のために、このドキュメントは[5]で提起された問題を考えなければなりません。
Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[7ページ]RFC3581
9.1. Problem Definition
9.1. 問題定義
From [5], any UNSAF proposal must provide:
[5]から、どんなUNSAF提案も提供されなければなりません:
Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems; this is why "short term fixes
usually aren't".
UNSAF提案で解決されることになっている特定の、そして、限られた範囲の問題の厳密な定義。 他の問題を解決するために短期間フィックスを一般化するべきではありません。 これは「通常、短期間フィックスがない」理由です。
This specification is primarily aimed at allowing SIP responses to be received when a request is sent through a NAT. In this primary application, this specification is not an UNSAF proposal. However, as a side effect of this capability, this specification can be used as an UNSAF protocol. In that usage, it would address two issues:
NATを通して要求を送るときSIP応答が受けられるのを許容するのをこの仕様は主として目的とされます。 このプライマリアプリケーションでは、この仕様はUNSAF提案ではありません。 しかしながら、この能力の副作用として、UNSAFプロトコルとしてこの仕様を使用できます。 その用法で、2冊を扱うでしょう:
o Provide a client with an address that it could use in the Contact
header of a REGISTER request when it is behind a NAT.
o NATの後ろにそれがあるときにはそれがREGISTER要求のContactヘッダーで使用できたアドレスをクライアントに提供してください。
o Provide a proxy with an address that it could use in a Record-
Route header in a request, when it is behind a NAT.
o それが要求でRecordルートヘッダーで使用できたアドレスをプロキシに提供してください、NATの後ろにそれがあるとき。
9.2. Exit Strategy
9.2. 撤退戦略
From [5], any UNSAF proposal must provide:
[5]から、どんなUNSAF提案も提供されなければなりません:
Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed.
撤退戦略/変遷プランの記述。 より良い短期間フィックスは適正技術が配布されるとき自然にますます少ない使用を見るものです。
The SIP working group has recognized that the usage of this specification to support registrations and record-routing through NATs is not appropriate. It has a number of known problems which are documented below. The way to eliminate potential usage of this specification for address fixing is to provide a proper solution to the problems that might motivate the usage of this specification for address fixing. Specifically, appropriate solutions for registrations and record-routing in the presence of NATs need to be developed. These solutions would not rely on address fixing.
SIPワーキンググループは、NATsを通して登録証明書と記録的なルーティングをサポートするこの仕様の用法が適切でないと認めました。 それには、以下に記録される多くの既知の問題があります。 アドレス修理のためのこの仕様の潜在的用法を排除する方法は修理することにおけるアドレスのためのこの仕様の用法を動機づけるかもしれない問題に適切な解決法を提供することです。 明確に、登録証明書のための適切な解決とNATsの面前で記録的なルーティングは、開発される必要があります。 これらのソリューションはアドレス修理を当てにしないでしょう。
Requirements for such solutions are already under development [6].
そのようなソリューションのための要件は既に展開[6]しています。
Implementors of this specification are encouraged to follow this work for better solutions for registrations and record-routing through NAT.
この仕様の作成者がNATを通して登録証明書のための、より良い解決と記録的なルーティングのためのこの仕事に続くよう奨励されます。
Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[8ページ]RFC3581
9.3. Brittleness Introduced by this Specification
9.3. このSpecificationによるもろさIntroduced
From [5], any UNSAF proposal must provide:
[5]から、どんなUNSAF提案も提供されなければなりません:
Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition.
より「もろく」システムを表すかもしれない特定の問題の議論。 例えば、複数のネットワーク層にデータを使用することを伴うアプローチで、より多くの依存を引き起こして、デバッグ挑戦を増強して、それは変遷により困難になります。
This specification, if used for address fixing, introduces several points of brittleness into a SIP system:
アドレス修理に使用されるなら、この仕様は数ポイントのもろさをSIPシステムに取り入れます:
o If used for UDP registrations, a client will need to frequently
re-register in order to keep the NAT bindings fresh. In many
cases, these registrations will need to take place nearly one
hundred times more frequently than the typical refresh interval of
a registration. This introduces load into the system and hampers
scalability.
o UDP登録証明書に使用されると、クライアントは、NAT結合を新鮮に保つために頻繁に再登録する必要があるでしょう。 多くの場合、これらの登録証明書は、典型的が登録の間隔をリフレッシュするよりおよそ100倍頻繁に行われる必要があるでしょう。 これは、システムに負荷を取り入れて、スケーラビリティを妨げます。
o A client cannot accurately determine the binding lifetime of a NAT
it is registering (or record-routing) through. Therefore, there
may be periods of unreachability that occur between the time a
binding expires and the next registration or OPTIONS refresh is
sent. This may result in missed calls, messages, or other
information.
o クライアントは正確にそれが登録している(または、記録的なルーティング)NATの拘束力がある生涯を決定できません。 したがって、結合が期限が切れる時、次の登録の間に起こってください。さもないと、OPTIONSがリフレッシュするという「非-可到達性」の期間を送るというそこでは、ことであるかもしれません。 これは逃された呼び出し、メッセージ、または他の情報をもたらすかもしれません。
o If the NAT is of the symmetric variety [4], a client will only be
able to use its address to receive requests from the server it has
sent the request to. If that server is one of many servers in a
cluster, the client may not be able to receive requests from other
servers in the cluster. This may result in missed calls,
messages, or other information.
o NATが左右対称のバラエティー[4]のものであるなら、クライアントは、それが要求を送ったサーバから要求を受け取るのにアドレスを使用できるだけでしょう。 そのサーバがひとかたまりになって多くのサーバの1つであるなら、クライアントはクラスタの他のサーバから要求を受け取ることができないかもしれません。 これは逃された呼び出し、メッセージ、または他の情報をもたらすかもしれません。
o If the NAT is of the symmetric variety [4], a client will only be
able to use its address to receive requests if the server sends
requests to the client from the same address and port the server
received the registrations on. This server behavior is not
mandated by RFC 3261 [1], although it appears to be common in
practice.
o NATが左右対称のバラエティー[4]のものであるなら、サーバが要求をサーバが登録証明書を受けた同じアドレスとポートからクライアントに送る場合にだけ、クライアントは、要求を受け取るのにアドレスを使用できるでしょう。 実際には一般的であるように見えますが、このサーバの振舞いはRFC3261[1]によって強制されません。
o If the registrar and the server to whom the client sent its
REGISTER request are not the same, the approach will only work if
the server uses the Path header field [3]. There is not an easy
and reliable way for the server to determine that the Path header
should be used for a registration. Using Path when the address in
the topmost Via header field is a private address will usually
work, but may result in usage of Path when it is not actually
needed.
o サーバがPathヘッダーフィールド[3]を使用して、クライアントがREGISTER要求を送った記録係とサーバが同じでないなら、アプローチは働くだけでしょう。 サーバが、Pathヘッダーが登録に使用されるべきであることを決定する簡単で信頼できる方法がありません。 最上のViaヘッダーフィールドにおけるアドレスがプライベート・アドレスであるときにPathを使用するのは、通常働きますが、それは実際に必要でないときに、Pathの使用法をもたらすかもしれません。
Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[9ページ]RFC3581
9.4. Requirements for a Long Term Solution
9.4. 長期ソリューションのための要件
From [5], any UNSAF proposal must provide:
[5]から、どんなUNSAF提案も提供されなければなりません:
Identify requirements for longer term, sound technical solutions
-- contribute to the process of finding the right longer term
solution.
より長い期間、健全な技術的解決法のための要件を特定してください--ソリューションという正しいより長い期間を見つけるプロセスに貢献してください。
The brittleness described in Section 9.3 has led us to the following requirements for a long term solution:
セクション9.3で説明されたもろさは長期ソリューションのために私たちを以下の要件に導きました:
The client should not need to specify its address. Registrations and
record routing require the client to specify the address at which
it should receive requests. A sound technical solution should
allow a client to explicitly specify that it wants to receive
incoming requests on the connection over which the outgoing
request was sent. In this way, the client does not need to
specify its address.
クライアントはアドレスを指定する必要はないはずです。 登録証明書と記録的なルーティングは、クライアントがそれが要求を受け取るべきであるアドレスを指定するのを必要とします。 健全な技術的解決法で、クライアントは、送信する要求が送られた接続に関する入って来る要求を受け取りたがっていると明らかに指定できるべきです。 このように、クライアントはアドレスを指定する必要はありません。
The solution must deal with clusters of servers. In many
commercially deployed SIP systems, there will be multiple servers,
each at different addresses and ports, handling incoming requests
for a client. The solution must explicitly consider this case.
ソリューションはサーバのクラスタに対処しなければなりません。 多くの商業的に配布しているSIPシステムには、複数のサーバがあるでしょう、それぞれ異なったアドレスとポートで、クライアントを求める入って来る要求を扱って。 ソリューションは明らかに本件を考えなければなりません。
The solution must not require increases in network load. There
cannot be a penalty for a sound technical solution.
ソリューションはネットワーク負荷の増加を必要としてはいけません。 健全な技術的解決法のための刑罰があるはずがありません。
9.5. Issues with Existing NAPT Boxes
9.5. 既存のNAPT箱の問題
From [5], any UNSAF proposal must provide:
[5]から、どんなUNSAF提案も提供されなければなりません:
Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports.
有名な実用的な問題の影響の議論は存在、配布しているNA[P]t、および経験で報告します。
To our knowledge, at the time of writing, there is only very limited usage of this specification for address fixing. Therefore, no specific practical issues have been raised.
私たちが知っている限り、これを書いている時点で、アドレス修理のためのこの仕様の非常に限られた用法しかありません。 したがって、どんな特定の実用的な問題も提起されていません。
10. Acknowledgements
10. 承認
The authors would like to thank Rohan Mahy and Allison Mankin for their comments and contributions to this work.
作者はこの仕事への彼らのコメントと貢献についてRohanマーイとアリソン・マンキンに感謝したがっています。
Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[10ページ]RFC3581
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] 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.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[3] ウィリス、D.とB.Hoeneisen、「非隣接している接触を登録するためのセッション開始プロトコル(一口)拡大ヘッダーフィールド」RFC3327(2002年12月)。
[4] 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.
[4] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
11.2. Informative References
11.2. 有益な参照
[5] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Translation",
RFC 3424, November 2002.
[5] Daigle、L.、エドIAB、「ネットワークの向こう側に(UNSAF)を修理する一方的な自己アドレスのためのIAB問題は翻訳を記述します」、RFC3424、2002年11月。
[6] Mahy, R., "Requirements for Connection Reuse in the Session
Initiation Protocol (SIP)", Work in Progress.
[6] マーイ、R.、「接続のための要件はセッションのときに開始プロトコル(一口)を再利用すること」が進行中で働いています。
12. Intellectual Property Statement
12. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[11ページ]RFC3581
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
13. Authors' Addresses
13. 作者のアドレス
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグdynamicsoft600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@dynamicsoft.com ユリ: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027 US
ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027米国
EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
メール: schulzrinne@cs.columbia.edu ユリ: http://www.cs.columbia.edu/~hgs
Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3581 Symmetric Response Routing August 2003
応答ルート設定2003年8月に左右対称のローゼンバーグとSchulzrinne標準化過程[12ページ]RFC3581
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg & Schulzrinne Standards Track [Page 13]
ローゼンバーグとSchulzrinne標準化過程[13ページ]
一覧
スポンサーリンク
