Network Working Group D. New
Request for Comments: 3620 October 2003
Category: Standards Track
The TUNNEL Profile
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.
このメモは、BEEPピアは、アプリケーション層プロキシとして機能することを可能にするブロック拡張交換プロトコル（BEEP）プロファイルを記述する。これは、許可されたユーザーがファイアウォールを介してサービスにアクセスできるようになります。
Table of Contents
目次
1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 One-Hop Example. . . . . . . . . . . . . . . . . . . . . . 3
2.2 Two-Hop Example. . . . . . . . . . . . . . . . . . . . . . 4
2.3 Failed Set-Up Example. . . . . . . . . . . . . . . . . . . 5
2.4 Non-BEEP Example . . . . . . . . . . . . . . . . . . . . . 5
2.5 Profile Example. . . . . . . . . . . . . . . . . . . . . . 6
2.6 Endpoint Example . . . . . . . . . . . . . . . . . . . . . 8
3. Message Syntax. . . . . . . . . . . . . . . . . . . . . . . . 9
4. Message Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Reply Codes. . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
A.1 Registration: BEEP Profile . . . . . . . . . . . . . . . . 16
A.2 Registration: A System (Well-Known) TCP
port number for TUNNEL . . . . . . . . . . . . . . . . . . 16
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
The TUNNEL profile provides a mechanism for cooperating BEEP peers to form an application-layer tunnel. The peers exchange "tunnel" elements that specify a source route, with the outermost element being stripped off and used to decide the next hop. The innermost, empty "tunnel" element tells the final destination that it is, indeed, the final destination. The term "proxy" is used to refer any of the BEEP peers other than the initiator and the final destination.
TUNNELプロファイルは、アプリケーション層のトンネルを形成するBEEPピア協働するための機構を提供します。ピアは、最も外側の要素を剥離し、次のホップを決定するために使用されると、ソースルートを指定し「トンネル」の要素を交換します。最も内側の、空の「トンネル」要素は、それが、実際に、最終目的地である最終的な宛先に伝えます。用語「代理」は、イニシエータと最終目的地以外のBEEPピアのいずれかを指すために使用されます。
In one use of this profile, a BEEP peer implementing the TUNNEL profile is co-resident with a firewall. An initiating machine inside the firewall makes a connection to the proxy, then ask that proxy to make a connection to an endpoint outside the firewall. Once this connection is established, the proxy tells the outside endpoint that it will be tunneling. If the outside machine agrees, the proxy "gets out of the way," simply passing octets transparently, and both the initiating and terminating machines perform a "tuning reset," not unlike the way starting a TLS negotiation discards cached session state and starts anew.
このプロファイルのいずれかの使用では、トンネルプロファイルを実装するBEEPピアは、ファイアウォールとの共存です。ファイアウォールの内側に開始するマシンがプロキシへの接続を行い、その後、ファイアウォールの外側のエンドポイントへの接続を行うためにそのプロキシをお願いします。この接続が確立されると、プロキシはそれがトンネルになります外のエンドポイントを伝えます。外部のマシンが同意した場合、プロキシは単に透過的にオクテットを渡す「道を外れ」、および、開始と終了のマシンの両方を行う「チューニングのリセットを、」ないTLS交渉を破棄し、キャッシュされたセッション状態を開始する方法とは異なり、そして新たに開始します。
Another use for this profile is to limit connections to outside servers based on the user identity negotiated via SASL. For example, a manager may connect to a proxy, authenticate herself with SASL, then instruct the proxy to tunnel to an information service restricted to managers. Since each proxy knows the identity of the next proxy being requested, it can refuse to tunnel connections if inadequate levels of authorization have been established. It is also possible to use the TUNNEL profile to anonymize the true source of a BEEP connection, in much the way a NAT translates IP addresses. However, detailed discussion of such uses is beyond the scope of this document.
このプロファイルの別の用途は、SASL経由で交渉したユーザIDに基づいて外部のサーバへの接続を制限することです。例えば、管理者は、次に、管理者に制限された情報サービスへのトンネルにプロキシを指示する、SASLで自分自身を認証し、プロキシに接続することができます。各プロキシは、要求されている次のプロキシの身元を知っているので、許可の不十分なレベルが確立されている場合、それはトンネル接続を拒否することができます。あまりで、NATはIPアドレスを変換する方法をBEEP接続の真のソースを匿名化するためのトンネルプロファイルを使用することも可能です。しかし、そのような用途の詳細な議論は、この文書の範囲を超えています。
Once both endpoint machines are connected, the tunneling proxy machine does no further interpretation of the data. In particular, it does not look for any BEEP framing. The two endpoint machines may therefore negotiate TLS between them, passing certificates appropriate to the endpoints rather than the proxy, with the assurance that even the proxy cannot access the information exchanged.
両方のエンドポイントマシンが接続されると、トンネリングプロキシマシンは、データのさらなる解釈しません。特に、それは、任意のBEEPフレーミングを探していません。 2台のエンドポイントマシンは、そのためにもプロキシが交換される情報にアクセスできないことを保証して、エンドポイントではなく、プロキシへの適切な証明書を渡し、それらの間のTLSを交渉することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
While the semantics described in Section 4 may seem complex, the results are actually relatively simple. A few examples will show the operation and use of this profile. In these examples, the machine attempting to establish the connection is named "initial", while the intermediate proxies are "proxy1" or "proxy2", and the machine with the service that "initial" wishes to access is called "final". The examples also assume that the BEEP framework [2] is implemented on top of TCP [3], or some other mapping where one transport connection carries all channels.
第4節で説明セマンティクスは複雑に見えるかもしれませんが、結果は実際には比較的簡単です。いくつかの例は、このプロファイルの操作や使用が表示されます。中間プロキシが「最終」と呼ばれる「PROXY1」または「PROXY2」、および「初期」は、アクセスしたいというサービスを持つマシンですしながら、これらの例では、接続を確立しようとするマシンは、「初期」と命名されます。実施例はまた、BEEPフレームワーク[2] [3] TCP、または1つのトランスポート接続は、全てのチャンネルを搬送するいくつかの他のマッピングの上に実装されているものとします。
A simple one-hop connection through a single proxy is illustrated first.
単一のプロキシを介して単純なホップ接続が最初に示されています。
initial proxy1 final
----- xport connect ----->
<------- greeting -------->
--- start TUNNEL [1] ---->
----- xport connect ------>
<-------- greeting -------->
---- start TUNNEL [2] ---->
<---------- ok ------------
<------- ok -------------- [3]
<------------- greeting [4]-------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel fqdn='final.example.com' port='604'> <tunnel/> </tunnel>
[1] TUNNEL要素は次のようになります。<トンネルFQDN = 'final.example.com' ポート= '604'> <トンネル/> </トンネル>
[2] The TUNNEL element looks like this: <tunnel/>
[2] TUNNEL要素は、このようになります。<トンネル/>
[3] At this point, immediately after sending the <ok/> element, proxy1 starts passing octets transparently. It continues to do so until either transport connection is closed, after which it closes the other.
[3]この時点で、すぐに<OK />要素を送った後、PROXY1は透過的にオクテットを渡して起動します。それは他を閉じた後、いずれかのトランスポート接続がクローズされるまでそうし続けています。
[4] This greeting may include the TLS profile, allowing initial and final to communicate without proxy1 understanding or interfering without being caught.
[4]この挨拶は、最初と最後は、PROXY1理解または引っ掛かることなく干渉することなく通信することを可能にする、TLSのプロファイルを含むことができます。
The second example shows the initiator connecting to its proxy, that proxy connecting to another, and finally that second proxy finding a service outside.
第二の例では、プロキシ、相互に接続そのプロキシへの接続開始を示し、最後に、第2のプロキシは、外部サービスを見つけます。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel fqdn='proxy2.example.com' port='604'> <tunnel fqdn='final.example.com' port='10290'> <tunnel/> </tunnel> </tunnel>
<トンネルFQDN = 'proxy2.example.com' ポート= '604'> <トンネルFQDN = 'final.example.com' ポート= '10290'> <トンネル/> </：[1] TUNNEL要素は、このようになりますトンネル> </トンネル>
[2] The TUNNEL element looks like this: <tunnel fqdn='final.example.com' port='10290'> <tunnel/> </tunnel>
[2] TUNNEL要素は次のようになります。<トンネルFQDN = 'final.example.com' ポート= '10290'> <トンネル/> </トンネル>
[3] The TUNNEL element looks like this: <tunnel/>
[3]トンネル素子は、このようになります。<トンネル/>
[4] Proxy2 starts passing octets transparently after sending the <ok/>.
[4] PROXY2は、<OK />送信した後に透過的にオクテットを渡して起動します。
[5] Proxy1 starts passing octets transparently after sending the <ok/>.
[5] PROXY1は、<OK />送信した後に透過的にオクテットを渡して起動します。
The third example shows the initiator connecting through two proxys, the second proxy attempting to connect to the specified service and finding the destination is not a BEEP server. (Of course, specifying the telnet service can be expected to lead to this error.) The same would result if the destination did not support the TUNNEL profile.
第三の例では、2つのproxys介して接続開始を示し、第二プロキシ指定されたサービスに接続しようと先を見つけるには、BEEPサーバありません。 （もちろん、telnetサービスを指定すると、このエラーにつながることが期待できます。）先がトンネルプロファイルをサポートしていませんでした場合と同じになります。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
----- xport close ---->
<---- <error> -------
--- xport close ---->
<---- <error> ------
--- xport close ---> [3]
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel fqdn='proxy2.example.com' port='604'> <tunnel fqdn='final.example.com' srv='_telnet._tcp'> <tunnel/> </tunnel> </tunnel>
[1] TUNNEL要素は次のようになります。<トンネルFQDN = 'proxy2.example.com' ポート= '604'> <トンネルFQDN = 'final.example.com' SRV = '_ telnet._tcp'> <トンネル/> </トンネル> </トンネル>
[2] The TUNNEL element looks like this: <tunnel fqdn='final.example.com' srv='_telnet._tcp'> <tunnel/> </tunnel>
[2] TUNNEL要素は次のようになります。<トンネルFQDN = 'final.example.com' SRV = '_ telnet._tcp'> <トンネル/> </トンネル>
[3] This close is optional. "Initial" may also send another <tunnel> element, attempting to contact a different server, for example.
[3]この近隣は任意です。 「初期」はまた、例えば、異なるサーバーに接続しようと、別の<トンネル>要素を送信することができます。
This example shows the initiator connecting through two proxys, the second proxy attempting to connect to the specified service and accepting that the destination is not a BEEP server. The difference at the protocol level is two-fold: The "initial" machine does not include the innermost "tunnel" element, and the final proxy ("proxy2") therefore does not expect a BEEP greeting.
この例では、2つのproxys、指定されたサービスに接続しようと宛先がBEEPサーバではないことを受け入れる第二のプロキシを介して接続開始を示します。プロトコルレベルでの差は二重である：「初期」機械は、したがって、BEEPグリーティングを期待していない最も内側の「トンネル」要素、及び最終的なプロキシ（「PROXY2」）を含んでいません。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
<------ <ok> ------- [3]
<----- login: ------ [4]
<------ <ok> --------- [3]
<----- login: -------- [4] [5]
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel fqdn='proxy2.example.com' port='604'> <tunnel fqdn='final.example.com' svc='_telnet._tcp'> </tunnel> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[1] TUNNEL要素は、このようになります。<トンネルFQDN = 'proxy2.example.com' ポート= '604'> <トンネルFQDN = 'final.example.com' SVC = '_ telnet._tcp'> </トンネル> </トンネル>最も内側の無属性<トンネル>要素の欠如に注意してください。
[2] The TUNNEL element looks like this: <tunnel fqdn='final.example.com' srv='_telnet._tcp'> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
[2] TUNNEL要素は次のようになります。<トンネルFQDN = 'final.example.com' SRV = '_ telnet._tcp'> </トンネル>最も内側の無属性<トンネル>要素の欠如に注意してください。
[3] Each proxy starts transparently forwarding octets after this <ok>.
[3]各プロキシは透過的に、<OK>この後のオクテットの転送を開始します。
[4] Each proxy forwards any data it received from the final host, even if that data arrived before the <ok> was sent.
[4]各プロキシは、<OK>送信される前にデータが到着した場合でも、それは最終的なホストから受信したデータを転送します。
[5] After receiving the "ok" message, the "initial" peer can expect raw, non-BEEP data to be sent to and received from the "final" machine.
[5]「OK」メッセージを受信した後、「初期の」ピアは生、非BEEPデータに送信され、「最終的な」マシンから受信することを期待することができます。
This example shows the initiator connecting through two proxys. The initial machine knows there is a server offering the SEP2 profile somewhere beyond proxy1, but it need not know where. Proxy1 has been locally configured to know that all SEP2 servers are beyond proxy2. Proxy2 has been locally configured to chose "final" as the server of choice for SEP2 services. Note that "final" does not necessarily need to offer the requested profile in its initial greeting.
この例では、2つのproxys介して接続開始を示します。最初のマシンはPROXY1を超えてどこかSEP2プロファイルを提供するサーバがある知っているが、それはどこを知っている必要はありません。 PROXY1は、ローカルのすべてのSEP2サーバがPROXY2を超えていることを知っているように設定されています。 PROXY2は、ローカルSEP2サービスのための選択のサーバとして「最終」を選んだように設定されています。 「最終」は、必ずしも、その最初の挨拶で要求されたプロファイルを提供する必要はないことに注意してください。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel profile="http://xml.resource/org/profiles/SEP2"/> Note the lack of an innermost no-attribute <tunnel> element.
[1] TUNNEL要素は、このようになります。<トンネルプロフィール= "HTTP：//xml.resource/org/profiles/SEP2を" />は、最も内側の無属性<トンネル>要素の欠如に注意してください。
[2] Proxy1 maps this to <tunnel fqdn="proxy2.example.com" port="604"> <tunnel profile="http://xml.resource/org/profiles/SEP2"/> </tunnel> based on local configuration, then processes the new element, stripping off the outer element and routing <tunnel profile="http://xml.resource/org/profiles/SEP2"/> to proxy2.
</トンネル>基づく：[2] PROXY1は<トンネルFQDN = "proxy2.example.com" ポート= "604"> </トンネルプロフィール= "//xml.resource/org/profiles/SEP2 HTTP">これをマッピングしますPROXY2にローカル構成、その後</ =「//xml.resource/org/profiles/SEP2 HTTP」トンネルプロファイル>外側の要素及びルーティングを剥離、新たな要素を処理します。
[3] Proxy2 receives the TUNNEL element with simply the SEP2 URI specified. Local provisioning maps this to <tunnel fqdn='final.example.com' srv='_beep._tcp'> <tunnel/> </tunnel> Note the presence of an innermost no-attribute <tunnel> element. Proxy2 then strips the outermost element, looking up the appropriate address and port, and forwards the <tunnel/> element to the final machine.
[3] PROXY2は単にSEP2 URIが指定されたとのトンネル要素を受け取ります。ローカルプロビジョニングにこれをマッピングする<トンネルFQDN =「final.example.com」SRV =「_ beep._tcp」> <トンネル/> </トンネル>最も内側の無属性<トンネル>要素が存在することに留意されたいです。 PROXY2は、適切なアドレスおよびポートを検索、最も外側の要素を取り除き、最終的なマシンに<トンネル/>要素を転送します。
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[4] PROXY2は、<OK>この後に透過的に転送オクテットを開始します。
[5] Proxy1 starts transparently forwarding octets after this <ok>.
[5] PROXY1は、<OK>この後に透過的に転送オクテットを開始します。
This example shows the initiator connecting through two proxys. The initial machine knows there is a server known as "operator console" somewhere beyond proxy1, but it needs not know where. Proxy1 has been locally configured to know that "operator console" is beyond proxy2. Proxy2 has been locally configured to use "final" as "operator console". This example is almost identical to the previous example, except that "endpoint" is intended to route to a particular server, while "profile" is intended to route to a particular service. Otherwise, these two attributes are very similar.
この例では、2つのproxys介して接続開始を示します。最初のマシンはどこかPROXY1を超えた「オペレータ・コンソール」として知られているサーバがある知っているが、それはどこか分からない必要があります。 PROXY1は、ローカルに「オペレータ・コンソールは、」PROXY2を超えていることを知っているように設定されています。 PROXY2は、ローカルに「オペレータ・コンソール」と「最終」を使用するように設定されています。この例では、「プロファイル」は、特定のサービスにルーティングするように意図されている間、「エンドポイント」は、特定のサーバにルーティングすることを意図していることを除いて、前の例とほぼ同じです。それ以外の場合は、これら2つの属性が非常に似ています。
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
ノート：
[1] The TUNNEL element looks like this: <tunnel endpoint="operator console"> </tunnel> Note the lack of an innermost no-attribute <tunnel> element.
<トンネルエンドポイント=「オペレータコンソール」> </トンネル>最も内側の無属性<トンネル>要素の欠如に注意してください[1] TUNNEL要素は、このようになります。
[2] Proxy1 maps this to <tunnel fqdn="proxy2.example.com" port="604"> <tunnel endpoint="operator console"> </tunnel> </tunnel> based on local configuration, then processes the new element, stripping off the outer element and routing <tunnel endpoint="operator console"> </tunnel> to proxy2.
[2] PROXY1は<トンネルFQDN = "proxy2.example.com" ポート= "604"> <トンネルエンドポイント= "オペレータコンソール"> </トンネル> </トンネル>ローカル設定に基づいて、新しいのプロセスにこのマップ要素、PROXY2に外側要素およびルーティング<トンネル終点=「オペレータコンソール」> </トンネル>を剥離。
[3] Proxy2 receives the TUNNEL element with simply the endpoint specified. Local provisioning maps this to <tunnel fqdn='final.example.com' srv='_beep._tcp'> <tunnel/> </tunnel> Note the presence of an innermost no-attribute <tunnel> element. Proxy2 then strips the outermost element, looking up the appropriate address and port, and forwards the <tunnel/> element to the final machine.
[3] PROXY2は、指定された単にエンドポイントとトンネル素子を受信します。ローカルプロビジョニングにこれをマッピングする<トンネルFQDN =「final.example.com」SRV =「_ beep._tcp」> <トンネル/> </トンネル>最も内側の無属性<トンネル>要素が存在することに留意されたいです。 PROXY2は、適切なアドレスおよびポートを検索、最も外側の要素を取り除き、最終的なマシンに<トンネル/>要素を転送します。
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[4] PROXY2は、<OK>この後に透過的に転送オクテットを開始します。
[5] Proxy1 starts transparently forwarding octets after this <ok>.
[5] PROXY1は、<OK>この後に透過的に転送オクテットを開始します。
The only element defined in this profile is the "tunnel" element. It is described in the following DTD, with additional limitations as described afterwards.
このプロファイルで定義されている唯一の要素は、「トンネル」要素です。後述のようにこれは、追加の制限付きで、以下のDTDで記述されています。
<!-- DTD for the TUNNEL Profile, as of 2001-02-03
<！ - DTD TUNNELのプロフィール、2001年2月3日のように
Refer to this DTD as:
このDTDとしてご参照ください：
<!ENTITY % TUNNEL PUBLIC "-//IETF//DTD TUNNEL//EN" ""> %TUNNEL; -->
<！ENTITY％のトンネルPUBLIC " - // IETF // DTDトンネル// EN" "">％トンネル。 - >
<!-- TUNNEL messages
<！ - TUNNELメッセージ
role MSG RPY ====== === === I or L TUNNEL +: ok -: error -->
役割MSG RPY ====== === === IまたはLトンネル+：OK - ：エラー - >
<!ELEMENT tunnel (tunnel?)> <!ATTLIST tunnel fqdn CDATA #IMPLIED ip4 CDATA #IMPLIED ip6 CDATA #IMPLIED port CDATA #IMPLIED srv CDATA #IMPLIED profile CDATA #IMPLIED endpoint CDATA #IMPLIED >
<！ELEMENTトンネル（トンネル？）> <！ATTLISTトンネルFQDN CDATA #IMPLIED IP4 CDATA #IMPLIED IP6 CDATA #IMPLIEDポートCDATA #IMPLIED SRV CDATA #IMPLIEDプロファイルCDATA #IMPLIEDのエンドポイントCDATA #IMPLIED>
The format of the "fqdn" attribute is a fully qualified domain name, such as "proxy.example.com". The format of the "ip4" attribute is four sets of decimal numbers separated by periods, such as "10.23.34.45". The format of the "ip6" attribute is as specified in RFC2373 [4]. The format of the "port" attribute is a decimal number between one and 65535, inclusive. The format of the "srv" attribute is a pair of identifiers each starting with an underline and separated by a period, such as "_sep._tcp". The format of the "profile" attribute is a URI [5]. The format of the "endpoint" attribute is any string that may appear as an attribute value.
「FQDN」属性の形式は、このような「proxy.example.com」として、完全修飾ドメイン名です。 「IP4」属性の形式は、「10.23.34.45」としてピリオドで区切られた十進数4組、です。 「IP6」属性のフォーマットはRFC2373で指定されている[4]。 「ポート」属性の形式は、包括1と65535の間の10進数です。 「SRV」属性のフォーマットはそれぞれ下線で始まる識別子の組であり、そのような「_sep._tcp」としてピリオドで区切ら。 「プロファイル」属性の形式は、URIである[5]。 「エンドポイント」属性の形式は、属性値として表示されることがあります任意の文字列です。
The only allowable combinations of attributes are as follows:
次のような属性の唯一の許容組み合わせは以下のとおりです。
o fqdn + port;
O FQDN +ポート。
o fqdn + srv;
O FQDN + SRV。
o fqdn + srv + port;
OのFQDN + SRV +ポート。
o ip4 + port;
お いｐ４ ＋ ぽｒｔ；
o ip6 + port;
OのIP6 +ポート。
o profile, but only on the innermost element;
Oプロファイルが、唯一の最も内側の要素に。
o endpoint, but only on the innermost element; or,
Oエンドポイントが、唯一の最も内側の要素に。または、
o no attributes, but only on the innermost element.
Oがないが、唯一の最も内側の要素の属性。
When a TUNNEL channel is started, the listener expects a "tunnel" element from the initiator, either in the "start" element on channel zero or on the new channel created. As usual, if it arrives on channel zero, it is processed before the reply is returned.
TUNNELチャンネルが開始されると、リスナーはチャネルゼロの「スタート」要素または作成された新しいチャネルのいずれかで、イニシエータからの「トンネル」の要素を期待しています。それはチャネルゼロに到達した場合の応答が返される前に、いつものように、それが処理されます。
In either case, the outermost "tunnel" element is examined. If it has no attributes, then this peer is hosting the BEEP service that the initiator wishes to use. In this case, the listener performs a tuning reset:
いずれの場合においても、最も外側の「トンネル」要素が検査されます。それは属性がありません場合は、このピアは、開始剤が使用したいBEEPサービスをホストしています。この場合、リスナーは、チューニングリセットを実行します。
o All channels, including channel zero, are implicitly closed.
Oチャネルゼロを含むすべてのチャンネルは、暗黙的にクローズされています。
o Any previously cached information about the BEEP session is discarded.
O BEEPセッションに関する以前にキャッシュされた情報は破棄されます。
o A new plaintext greeting is sent.
O新しい平文挨拶が送信されます。
If the outermost element has a "port" attribute and an "fqdn" attribute but no "srv" attribute, then "fqdn" is looked up as an A record via DNS for translation to an IP number. An "ip4" attribute is interpreted as the dotted-quad representation of an IPv4 address. An "ip6" attribute is interpreted as a text representation of an IPv6 address. In each of these cases, a transport connection is established to the so-identified server. If the outermost element has a "srv" attribute, the concatenation of the "srv" attribute and the "fqdn" attribute (with a period between) is looked up in the DNS for a SRV record [6], and the appropriate server is contacted; if that lookup fails and a "port" attribute is present, the connection is attempted as if the "srv" attribute were not specified.
最も外側の要素は、「ポート」属性と「FQDN」属性が、ノー「SRV」属性を持っている場合は、「FQDNは、」IP番号に変換するためにDNS経由でレコードとして検索されます。 「IP4」属性は、IPv4アドレスのドット付きクワッド表現として解釈されます。 「IP6」属性は、IPv6アドレスのテキスト表現として解釈されます。これらの場合の各々において、トランスポート・コネクションは、いわゆる識別されたサーバに確立されています。最も外側の要素が「SRV」属性を持っている場合、「SRV」属性と（間の期間で）「FQDN」属性の連結は、[6] SRVレコードのDNSで調べ、適切なサーバであるれます連絡;そのルックアップが失敗し、「ポート」属性が存在する場合、「SRV」属性が指定されていなかったかのように、接続が試行されます。
Alternately, if the outermost element has a "profile" attribute, then it must have no nested elements. The proxy processing this element is responsible for determining the appropriate routing to reach a peer serving the BEEP profile indicated by the URI in the attribute's value. Rather than source routing, this provides a hop-by-hop routing mechanism to a desired service.
最も外側の要素は、「プロファイル」属性を持っている場合は、交互に、それは何のネストされた要素を持っていない必要があります。プロキシ処理この要素は、属性の値にURIで示さBEEPプロファイルにサービスを提供するピアに到達するために適切なルーティングを決定する責任があります。むしろソースルーティングよりも、これは、所望のサービスへのホップバイホップルーティングメカニズムを提供します。
Similarly, if the outermost element has an "endpoint" attribute, then it must have no nested elements. The proxy processing this element is responsible for determining the appropriate routing to reach a peer indicated by the value of the "endpoint" attribute. Rather than source routing, this provides a hop-by-hop routing mechanism to a desired machine. There are no restrictions on how machines are identified.
最も外側の要素は、「エンドポイント」属性を持っている場合同様に、それは何のネストされた要素を持っていない必要があります。この要素を処理するプロキシは、「エンドポイント」属性の値によって示されるピアに到達するために適切なルーティングを決定する責任があります。むしろソースルーティングよりも、これは、所望の機械へのホップバイホップルーティングメカニズムを提供します。マシンが識別される方法に制限はありません。
Then, if the outermost element has no nested elements, but it does have attributes other than "profile" or "endpoint", then this peer is the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP" example above.) In this case, as soon as the final underlying transport connection is established, an "ok" element is returned over the listening session, and the tunneling of data starts. No BEEP greeting (or indeed any data) from the final hop is expected. Starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more=".") of the RPY carrying the "ok" element, the proxy begins copying octets directly and without any interpretation between the two underlying transport connections.
最も外側の要素にはネストされた要素を有していないが、それは「プロファイル」または「エンドポイント」以外の属性を持っている場合、このピアは、最終的なBEEPホップです。 （これは、上記「非BEEP」の例では「PROXY2」に相当する。）この場合、最終的な基礎となるトランスポート接続が確立されるとすぐに、「OK」エレメントが聴取セッションにわたって戻し、データのトンネリングされます開始。最終ホップからビープグリーティング（または実際には任意のデータ）が期待されていません。完了フラグを設定してフレームの終わり（CR）（LF）トレーラーを次のオクテットから始まる（より=「」） 『OK』要素を運ぶRPYの、プロキシは直接との間の任意の解釈なしオクテットのコピーを開始します2つの基本的な交通機関の接続。
If the identified server cannot be contacted, an "error" element is returned over the listening channel and any connection established as an initiator is closed. If there is a nested "tunnel" element, and the server that has been contacted does not offer a BEEP greeting, or the BEEP greeting offered does not include the TUNNEL profile, then this too is treated as an error: the initiating transport connection is closed, and an error is returned.
識別されたサーバに接続できない場合は、「エラー」の要素は、リスニングのチャネルを介して返され、開始剤として確立任意の接続が閉じられています。ネストされた「トンネル」要素、およびBEEPの挨拶を提供していません接触したサーバー、またはトンネルプロファイルが含まれていない提供BEEPあいさつがある場合、これはあまりにもエラーとして扱われます：開始トランスポート接続があります閉じられた、とエラーが返されます。
If there is a nested "tunnel" element, and the identified server is contacted and offers a BEEP greeting including the TUNNEL profile, then the outermost element from the "tunnel" element received is stripped off, a new TUNNEL channel is started on the initiating session, and the stripped (inner) element is sent to start the next hop. In this case, the peer is considered a "proxy" (meaning that the next paragraph is applicable).
そこにネストされた「トンネル」要素があり、かつ識別されたサーバが接触し、TUNNELプロファイルを含むBEEPの挨拶を提供しています受信した「トンネル」要素から最も外側の要素が取り除かれ、その後、新しいトンネルチャネルは、開始で開始された場合セッション、およびストリッピング（内側の）要素は、次のホップを開始するために送信されます。この場合、ピアは、（次の段落は適用可能であることを意味する）「プロキシ」と考えられています。
Once the proxy has passed the "tunnel" element on the TUNNEL channel, it awaits an "error" or an "ok" element in response. If it receives an "error" element, it closes the initiated session and its underlying transport connection. It then passes the "error" element unchanged back on the listening session. If, on the other hand, it receives an "ok" element, it passes the "ok" element back on the listening session. Starting with the octet following the END(CR)(LF) trailer of the frame with the completion flag set (more=".") of the RPY carrying the "ok" element, the proxy begins copying octets directly and without any interpretation between the two underlying transport connections.
プロキシトンネルチャンネルの「トンネル」の要素を経過すると、それは「エラー」または応答で「OK」要素をお待ちしております。それは「エラー」の要素を受信した場合、それが開始されたセッションおよびその基礎となるトランスポート接続を閉じます。その後、リスニングセッションの「エラー」の要素そのままバックを渡します。一方、それは「OK」要素を受信した場合、それはバックリスニングセッションの「OK」の要素を渡します。完了フラグを設定してフレームの終わり（CR）（LF）トレーラーを次のオクテットから始まる（より=「」） 『OK』要素を運ぶRPYの、プロキシは直接との間の任意の解釈なしオクテットのコピーを開始します2つの基本的な交通機関の接続。
While the BEEP Framework [2] is used, the attributes described are sufficient for the TCP mapping [3] of BEEP. The attributes on the "tunnel" element may need to be extended to handle other transport layers.
BEEPフレームワークは[2]を用いているが、説明されている属性は、BEEPのTCPマッピング[3]のために十分です。 「トンネル」要素の属性は、他のトランスポート層を処理するために拡張する必要があるかもしれません。
In a mapping where multiple underlying transport connections are used, once the "ok" element is passed, all channels are closed, including channel zero. Thus, only the underlying transport connection initially established remains, and all other underlying transport connections for the session should be closed as well.
「OK」要素が渡されると、複数の基礎となるトランスポート接続が使用されるマッピングでは、すべてのチャネルは、チャネルゼロを含む、閉じています。したがって、唯一の基礎となるトランスポート接続は、最初に遺体を確立し、セッションの他のすべての基礎となる交通機関の接続も同様に閉じる必要があります。
If a transport security layer (such as TLS) has been negotiated over the session, the semantics for the TUNNEL profile are ill-defined. The TUNNEL profile MUST NOT be advertised in any greetings after transport security has been negotiated.
（TLSなど）トランスポート・セキュリティ層がセッションを介して交渉されている場合は、トンネルプロファイルのセマンティクスは不明確です。トランスポート・セキュリティがネゴシエートされた後TUNNELプロファイルは、任意の挨拶で広告してはなりません。
An SRV identifier of "_tunnel" is reserved by IANA for use with this profile. Hence, the "srv" attribute "_tunnel._tcp" MAY be used as a default for finding the appropriate address for tunneling into a particular domain.
「_tunnel」のSRV識別子は、このプロファイルで使用するためにIANAによって予約されています。したがって、「SRV」属性「_tunnel._tcp」は、特定のドメインにトンネリングのための適切なアドレスを見つけるためのデフォルトとして使用されるかもしれません。
System port number 604 has been allocated by the IANA for TUNNEL.
システムのポート番号604は、トンネルのIANAによって割り当てられています。
This section lists the three-digit error codes the TUNNEL profile may generate.
このセクションでは、TUNNELプロファイルが生成する3桁のエラーコードを示します。
code meaning ==== ======= 421 Service not available (E.g., the proxy does not have sufficient resources.)
コードの意味==== ======= 421サービスは利用できません（例えば、プロキシは、十分なリソースを持っていません。）
450 Requested action not taken (E.g., DNS lookup failed or connection could not be established. See too 550.)
取られていない450要求されたアクション（例えば、DNSルックアップが失敗したか、接続が確立できませんでした。あまりにも550を参照してください）
500 General syntax error (E.g., poorly-formed XML)
500一般的な構文エラー（例えば、不完全に形成されたXML）
501 Syntax error in parameters (E.g., non-valid XML, letters in "ip4" attribute, etc.)
パラメータの501構文エラー（例えば、非有効なXML、「IP4」属性の文字、など）
504 Parameter not implemented
504パラメータ実装されていません
530 Authentication required
530認証が必要
534 Authentication mechanism insufficient (E.g., too weak, sequence exhausted, etc.)
534認証機構不足（例えば、弱すぎる、配列排気等）
537 Action not authorized for user
537アクションユーザに対して権限がありません
538 Encryption already enabled (E.g., TLS already negotiated, or a SASL that provides encryption already negotiated.)
538は、暗号化はすでに有効（例えば、TLSはすでに交渉し、または暗号化を提供SASLはすでに交渉しました。）
550 Requested action not taken (E.g., next hop could be contacted, but malformed greeting or no TUNNEL profile advertised.)
550要求されたアクションが取られ（例えば、ネクストホップを接触させることができるが、不正な形式の挨拶または全くTUNNELプロファイルがアドバタイズ。）ではありません
553 Parameter invalid
無効なパラメータ553
554 Transaction failed (E.g., policy violation)
554トランザクションが失敗した（例えば、ポリシー違反）
Note that the 450 error code is appropriate when the destination machine could not be contacted, while the 550 error code is appropriate when the destination machine could be contacted but the next phase of the protocol could not be negotiated. It is suggested that the beginning of any reply from the destination machine be included as part of the CDATA text of the error element, for debugging purposes.
宛先マシンに接続できない場合、宛先マシンが接触することができるが、プロトコルの次の段階をネゴシエートすることができなかった場合に550エラーコードが適切であるが450エラーコードは、適切であることに留意されたいです。デバッグ目的のために、先のマシンからの任意の応答の始まりは、エラー要素のCDATAテキストの一部として含まれることが示唆されています。
The TUNNEL profile is a profile of BEEP. In BEEP, transport security, user authentication, and data exchange are orthogonal. Refer to Section 8 of [2] for a discussion of this.
TUNNELプロファイルは、BEEPのプロファイルです。 BEEPでは、トランスポート・セキュリティ、ユーザ認証、およびデータ交換が直交しています。この議論のための[2]のセクション8を参照。
However, the intent of the TUNNEL profile is to allow bidirectional contact between two machines normally separated by a firewall. Since TUNNEL allows this connection between BEEP peers, and BEEP peers can offer a range of services with appropriate greetings, the TUNNEL profile should be configured with care. It is reasonable to strictly limit the hosts and services that a proxy is allowed to contact. It is also reasonable to limit the use of the TUNNEL profile to authorized users, as identified by a SASL profile.
しかし、トンネルプロファイルの意図は、通常のファイアウォールで区切られた2台のマシン間の双方向の接触を可能にすることです。トンネルがBEEPピア間のこの接続を可能にし、BEEPピアは、適切な挨拶とサービスの範囲を提供することができますので、TUNNELプロファイルは注意して設定する必要があります。厳密にプロキシが連絡することを許可されたホストとサービスを制限することが合理的です。 SASLプロファイルによって識別されるように、許可されたユーザへのトンネルプロファイルの使用を制限することも合理的です。
Negotiation of a TLS profile in an end-to-end manner after a TUNNEL has been established will prevent intermediate proxies from observing or modifying the cleartext information exchanged, but only if TLS certificates are properly configured during the negotiation. The proxy could mount a "man in the middle" attack if public key infrastructure is not deployed.
トンネルが確立された後、エンドツーエンドの方法でTLSプロファイルのネゴシエーションが交換平文情報を観察または変更から中間プロキシを防止するが、TLS証明書が正しくネゴシエーション時に設定されている場合のみ。公開鍵インフラストラクチャが展開されていない場合、プロキシは、「男真ん中に」攻撃を仕掛けることができます。
In some environments, it is undesirable to expose the names of machines on one side of a firewall in unencrypted messages on the other side of that firewall. In this case, source routing (using the "fqdn", "ip4", "ip6", "port" and "srv" attributes) can route a connection to the firewall proxy, with an innermost "profile" or "endpoint" attribute which the firewall proxy understands. Local provisioning can allow a proxy to translate a particular "profile" or "endpoint" element into a new source route to reach the desired service. This can prevents two attacks:
一部の環境では、そのファイアウォールの向こう側には、暗号化されていないメッセージには、ファイアウォールの片側にマシンの名前を公開することは望ましくありません。最も内側の「プロファイル」または「エンドポイント」属性で、ルートファイアウォール、プロキシへの接続をすることができる（「FQDN」、「IP4」、「IP6」、「ポート」と「SRV」は、属性を使用して）この場合、ソースルーティングこれは、ファイアウォール、プロキシが理解しています。ローカルプロビジョニングは、プロキシが必要なサービスに到達するために、新たなソースルートに特定の「プロファイル」または「エンドポイント」の要素を翻訳できるようにすることができます。これは、二つの攻撃を防ぐことができます。
o Attackers sniffing packets on one side of the firewall cannot see IP addresses or FQDNs of machines on the other side of the firewall; and,
Oファイアウォールの一方の側でパケットを盗聴攻撃者は、ファイアウォールの反対側にあるマシンのIPアドレスまたはFQDNを見ることができません。そして、
o Attackers cannot exhaustively attempt to connect to many FQDNs or IP addresses via source routing and use the error messages as an indication of whether the queried machine exists. For this attack to be prevented, the proxy must allow only "profile" or "endpoint" connections, always refusing to even attempt source-routed connections. This latter attack can also be thwarted by requiring a SASL identification before allowing a TUNNEL channel to be started, but this can have higher overhead.
O攻撃者は徹底的にソースルーティングを介して多くのFQDNまたはIPアドレスに接続し、照会機が存在するかどうかの指標として、エラーメッセージを使用しようとすることはできません。この攻撃を防止するためには、プロキシは常に偶数ソースルートの接続を試みることを拒否し、唯一の「プロファイル」または「エンドポイント」の接続を許可する必要があります。この後者の攻撃は、トンネルチャネルが開始されることを可能にする前にSASL識別情報を要求することによって阻止することができ、これは、より高いオーバーヘッドを有していてもよいです。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[2]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[3]ローズ、M.、RFC 3081、 "TCP上にBEEPコアのマッピング" を、2001年3月。
[4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[4] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[6] Gulbrandsenの、A.、いるVixie、P.及びL. Esibov、 "（DNSのSRV）サービスの位置を特定するためのDNS RR"、RFC 2782、2000年2月。
Appendix A. IANA Considerations
付録A. IANAの考慮事項
A.1 Registration: BEEP Profile
A.1登録：BEEPプロフィール
The IANA has registered the profiles specified in this section and has selected an IANA-specific URI: "http://iana.org/beep/TUNNEL".
IANAは、このセクションで指定されたプロファイルを登録したとIANA固有のURIを選択している：「http://iana.org/beep/TUNNEL」。
Profile identification: http://iana.org/beep/TUNNEL
プロフィール識別：http://iana.org/beep/TUNNEL
Message exchanged during channel creation: "tunnel"
メッセージには、チャネルの作成中に交換：「トンネル」
Messages starting one-to-one exchanges: "tunnel"
メッセージは、1対1の交換を開始する：「トンネル」
Messages in positive replies: "ok"
正の返信でメッセージ：「OK」
Messages in negative replies: "error"
負の返信でメッセージ：「エラー」
Messages in one-to-many exchanges: None.
1対多の交換におけるメッセージ：なし。
Message syntax: See Section 3 of this document.
メッセージ構文：このドキュメントのセクション3を参照してください。
Message semantics: See Section 4 of this document.
メッセージの意味：このドキュメントのセクション4を参照してください。
Contact information: See the Author's Address appendix of this document.
連絡先情報：この文書の著者のアドレスの付録を参照してください。
Any extensions to this protocol MUST be documented in a Standards track RFC.
このプロトコルへの任意の拡張機能は、標準トラックRFCに文書化されなければなりません。
A.2 Registration: The System (Well-Known) TCP port number for TUNNEL
A.2登録：（ウェルノウン）システムトンネルのTCPポート番号
A single well-known port, 604, is allocated by the IANA to the TUNNEL profile.
単一の周知のポート、604は、TUNNELプロファイルにIANAによって割り当てられます。
Protocol Number: TCP
プロトコル番号：TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.
メッセージフォーマット、タイプ、オペコード、およびシーケンス：第3節を参照してください。
Functions: See Section 4.
機能：第4章を参照してください。
Use of Broadcast/Multicast: none
ブロードキャスト/マルチキャストの利用：なし
Proposed Name: TUNNEL Profile
提案名：TUNNELプロフィール
Short name: tunnel
ショート名：トンネル
Contact Information: See the "Authors' Addresses" section of this memo
お問い合わせ先：このメモの「著者のアドレス」を参照してください
Appendix B. Acknowledgements
付録B.謝辞
The author gratefully acknowledges the contributions of Marshall Rose, Greg Matthews, and Ben Feinstein.
作者は感謝マーシャルローズ、グレッグ・マシューズ、そしてベン・ファインスタインの貢献を認めています。
Inspiration for this profile comes from the Intrusion Detection Working Group of the IETF.
このプロファイルのためのインスピレーションは、IETFの侵入検知ワーキンググループから来ています。
Author's Address
著者のアドレス
Darren New 5390 Caminito Exquisito San Diego, CA 92130 US
ダレン新5390カミニートExquisitoサンディエゴ、CA 92130米国
Phone: +1 858 350 9733 EMail: dnew@san.rr.com
電話：+1 858 350 9733 Eメール：dnew@san.rr.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。