Network Working Group L. Daigle, Ed.
Request for Comments: 3424 Internet Architecture Board
Category: Informational IAB
November 2002
IAB Considerations for UNilateral Self-Address Fixing (UNSAF)
Across Network Address Translation
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
As a result of the nature of Network Address Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-Address Fixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
ネットワークアドレス変換（NAT）のMiddleboxesの性質の結果として、一の以上のNATにより分離されている通信エンドポイントは、その（現在および将来）のアドレス範囲で有効なアドレスピアを使用して自分自身を参照する方法がわかりません。様々な提案が「一方的な自己アドレス固定（UNSAF）」のプロセスのために作られてきました。いくつかの発信エンドポイントが決定するか、別のエンドポイントに認識されているアドレス（およびポート）を固定しようとすることにより、これらのプロセスである - 例えばプロトコル交換でアドレスデータを使用することができるようにする、またはそれが接続を受信する元のパブリックアドレスを広告します。
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal.
この文書では、これらの提案は、最高の状態で特定の問題と慎重UNSAF提案を作成する前に評価されるべき具体的な問題への短期フィックスとして考えることができるの理由を概説します。
As a result of the nature of Network Address (and port) Translation (NAT) Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers - the address translation is locked within the NAT box. For some purposes, endpoints need to know the addresses (and/or ports) by which they are known to their peers. There are two cases: 1) when the client initiates communication, starting the communication has the side effect of creating an address binding in the NAT device and allocating an address in the realm that is external to the NAT box; and 2) a server will be accepting connections from outside, but because it does not initiate communication, no NAT binding is created. In such cases, a mechanism is needed to fix such a binding before communication can take place.
ネットワークアドレス（およびポート）変換（NAT）のMiddleboxesの性質の結果として、一の以上のNATにより分離されている通信エンドポイントは、彼らの（現在のアドレス範囲で有効なアドレスを使用して自分自身を参照する方法がわかりませんそして将来の）ピアは - アドレス変換はNAT箱の中にロックされています。いくつかの目的のために、エンドポイントは、彼らが彼らの仲間に知られていることにより、アドレス（および/またはポート）を知っている必要があります。 2つのケースがあります：クライアントが通信を開始するとき1）、通信を開始すると、NATデバイスにバインディングアドレスを作成し、NATボックスの外部にある領域内のアドレスを割り当てるの副作用を有します。 2）サーバが外部からの接続を受け入れるであろうが、それは通信を開始しないので、何のNATバインディングが作成されません。このような場合には、この機構は、通信前に、結合が起こることができるように修正するために必要とされています。
"UNilateral Self-Address Fixing (UNSAF)" is a process whereby some originating process attempts to determine or fix the address (and port) by which it is known - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
例えば - 「一方的な自己アドレス固定（UNSAF）」は、それが認識されているいくつかの発信処理がアドレス（およびポート）を決定または修正しようとするプロセスでありますプロトコル交換でアドレスデータを使用することができるようにする、またはそれが接続を受信する元のパブリックアドレスを広告します。
There are only heuristics and workarounds to attempt to achieve this effect; there is no 100% solution. Since NATs may also dynamically reclaim or readjust translations, "keep-alive" and periodic re-polling may be required. Use of these workarounds MUST be considered transitional in IETF protocols, and a better architectural solution is being sought. The explicit intention is to deprecate any such workarounds when sound technical approaches are available.
この効果を達成しようとする唯一の経験則や回避策があります。全く100％の解決策はありません。 NATのは、動的翻訳を再利用または再調整もあるので、「キープアライブ」と定期的な再ポーリングが必要になることがあります。これらの回避策の使用は、IETFプロトコルに移行考えなければなりません、そして、より良い建築ソリューションが求められています。明示的な意図は、音の技術的なアプローチが用意されていたときに、そのような回避策を廃止しています。
Generally speaking, the proposed workarounds are for cases where a standard protocol communication is to take place between two endpoints, but in order for this to occur, a separate step of determining (or fixing) the perceived address of an endpoint in the other endpoint's addressing realm is required. Proposals require that an endpoint seeking to "fix" its address contact a participating service (in a different address realm) to determine (reflect) its address. Thus, there is an "UNSAF client" partnering with some form of "UNSAF service" that may or may not be associated with the target endpoint of the actual desired communication session. Throughout this memo, the terms "UNSAF server" and "UNSAF service" should be understood to generically refer to whatever process is participating in the UNSAF address determination for the originating process (the UNSAF client).
一般的に言えば、提案された回避策が標準プロトコル通信は、2つのエンドポイント間で行われるようになる場合のためのものであるが、これが発生するために、他のエンドポイントのアドレッシングエンドポイントの知覚されるアドレスを決定する（または固定）の別のステップレルムが必要です。提案は、エンドポイントがそのアドレスを（反映）を決定するためにそのアドレスの連絡先（別のアドレスレルム内）参加サービスを「修正」しようとしていることが必要です。従って、又は実際の所望の通信セッションのターゲット・エンドポイントに関連付けられてもしなくてもよい「UNSAFサービス」の何らかの形で提携「UNSAFクライアント」があります。このメモ全体を通して、用語「UNSAFサーバ」および「UNSAFサービスは」総称発信処理のためのUNSAFアドレス決意（UNSAFクライアント）に参加しているどのようなプロセスを指すことが理解されるべきです。
Any users of these workarounds should be aware that specific technical issues that impede the creation of a general solution include:
これらの回避策のすべてのユーザーは、一般的なソリューションの創出を妨げる特定の技術的な問題が含まれていることを知っておく必要があります。
o there *is* no unique "outside" to a NAT - it may be impossible to tell where the target endpoint is with respect to the initiator; how does an UNSAF client find an appropriate UNSAF server to reflect its address? (See Appendix C).
そこにO *である* NATにノー独特の「外」 - それは、ターゲットエンドポイントがイニシエータに関してどこにいるか伝えることは不可能であってもよく、どのようUNSAFクライアントはそのアドレスを反映するための適切なUNSAFサーバを見つけるのですか？ （付録Cを参照してください）。
o specifically because it is impossible to tell where address realms are bounded ("inside" or "outside", "private" or "public", or several "private" realms routing traffic), an address can only be determined relative to one specific point in the network. If the UNSAF service that reflected an UNSAF client's address is in a different NAT-masqueraded subnet from some other service X that the client wishes to use, there is _no_ guarantee that the client's "perceived" address from the UNSAF partner would be the same as the address viewed from the perspective of X. (See Appendix C).
それは（「プライベート」または「パブリック」、またはトラフィックをルーティングする複数の「プライベート」領域、「内部」または「外部」）アドレスレルムが囲まれる場合伝えることは不可能であるため、O具体的に、アドレスは、1つの特定に対して決定することができますネットワーク内のポイント。 UNSAFクライアントのアドレスを反映UNSAFサービスは、クライアントが使用したいいくつかの他のサービスXは異なるNAT-マスカレードサブネットにある場合は、UNSAFパートナーからクライアントの「認知」のアドレスが同じになること_no_を保証するものではありX.の観点から見たアドレス（付録Cを参照してください）。
o absent "middlebox communication (midcom)", there is no usable way to let incoming communications make their way through a middlebox (NAT, firewall) under proper supervision. By circumventing the NAT, UNSAF mechanisms may also (inadvertently) circumvent security mechanisms. The particular danger is that internal machines are unwittingly exposed to all the malicious communications from the external side that the firewall is intended to block. This is particularly unacceptable if the UNSAF process is running on one machine which is acting on behalf of several.
存在しない「ミドル通信（MIDCOM）」O、着信通信が適切な監督の下でミドル（NATファイアウォール）を介して自分の道を作るようにするいかなる使用可能な方法は存在しません。 NATを回避することによって、UNSAFメカニズムは、（誤って）セキュリティメカニズムを回避することができます。特に危険なのは内部のマシンは、知らず知らずのうちにファイアウォールがブロックするように意図されて外部からのすべての悪意のある通信にさらされているということです。 UNSAFプロセスは、いくつかの代理として行動している一台のマシン上で実行されている場合、これは特に受け入れられません。
o proposed workarounds include the use of "ping"-like address discovery requests sent from the UNSAF client (initiator) to the UNSAF server (listener), to which the listener responds with the transport address of the initiator - in the address realm of the listener. However, with connection-less transports, e.g. UDP, IPsec ESP, etc., an UNSAF process must take care to react to changes in NAT bindings for a given application flow, since it may change unpredictably.
のアドレスレルムで - Oの回避策は、リスナーがイニシエータのトランスポートアドレスで応答するにUNSAFサーバ（リスナー）にUNSAFクライアント（イニシエータ）から送信されたアドレスディスカバリ要求、様「ピング」の使用を含む提案リスナー。しかし、コネクションレス型トランスポートと、例えばそれは予測不能に変更される可能性があるため、UDPなどのIPsec ESPは、UNSAFプロセスは、特定のアプリケーションフローのためのNATバインディングの変化に反応するように注意しなければなりません。
o if the UNSAF client uses periodic retries to refresh/reevaluate the address translation state, both the UNSAF client and the UNSAF server are required to maintain information about the presumed state of the communication in order to manage the address illusion.
O UNSAFクライアントはUNSAFクライアントとUNSAFサーバの両方がアドレス錯覚を管理するために、通信の推定状態に関する情報を維持するために必要とされ、/リフレッシュアドレス変換状態を再評価するために定期的に再試行を使用している場合。
o since the UNSAF server is not integrated with the middlebox, it can only operate on the assumption that past behavior is a predictor of future behavior. It has no special knowledge of the address translation heuristic or affecting factors.
UNSAFサーバはミドルと統合されていないので、O、それだけで過去の行動が将来の行動の予測因子であることを前提に操作することができます。これは、アドレス変換ヒューリスティックや影響を与える要因の特別な知識を持っていません。
o the communication exchange is made more "brittle" by the introduction of other servers (UNSAF servers) that need to be reachable in order for the communication to succeed - more boxes that are "fate sharing" in the communication.
コミュニケーションにおける「運命の共有」している以上のボックス - O通信交換が成功するための通信ために到達する必要があり、他のサーバー（UNSAFサーバ）の導入によって、より「脆性」行われます。
Workarounds may mitigate some of these problems through tight scoping of applicability and specific fixes. For example:
回避策は、適用性と具体的な修正のタイトなスコープを通じて、これらの問題のいくつかを軽減することがあります。例えば：
o rather than finding the address from "the" outside of the NAT, the applicability of the approach may be limited to finding the "self-address" from a specific service, for use exclusively with that service.
OではなくNATの「」外部からのアドレスを見つけることよりも、アプローチの適用性は、そのサービスを独占的に使用するため、特定のサービスから「自己アドレスを」見つけるに限定することができます。
o limiting the scope to outbound requests for service (or service initiation) in order to prevent unacceptable security exposures.
容認できない機密漏れを防止するために、サービス（またはサービス開始）のためのアウトバウンド要求に範囲を限定し、O。
From observations of deployed networks, it is clear that different NAT box implementations vary widely in terms of how they handle different traffic and addressing cases.
展開されたネットワークの観察から、別のNATボックスの実装は、彼らが異なるトラフィックおよびアドレッシングケースを処理する方法の面で大きく異なることは明らかです。
Some of the specific types of observed behaviors have included:
観測された行動の特定の種類のいくつかが含まれています：
o NATs may drop fragments in either direction: without complete TCP/UDP headers, the NAT may not make the address translation mapping, simply dropping the packet.
O NATはどちらの方向にフラグメントをドロップすることがあります。完全なTCP / UDPヘッダーなし、NATは、単にパケットをドロップし、アドレス変換のマッピングを加えることはできません。
o Shipping NATs often contain Application Layer Gateways (ALGs) which attempt to be context-sensitive, depending on the source or destination port number. The behavior of the ALGs can be hard to anticipate and these behaviors have not always been documented.
O配送NATは、多くの場合、送信元または宛先ポート番号に応じて、コンテキスト依存であることを試みアプリケーションレイヤゲートウェイ（ALG）を含有します。 ALGの挙動は予測しにくいことができ、これらの行動は常に文書化されていません。
o Most NAT implementations with ALGs that attempt to translate TCP application protocols do not perform their functions correctly when the substrings they must translate span across multiple TCP segments; some of them are also known to fail on flows that use TCP option headers, e.g. timestamps.
部分文字列は、彼らが複数のTCPセグメントにまたがるを翻訳しなければならないときにO TCPアプリケーションプロトコルを変換しようとするのALGとほとんどのNATの実装では正しくその機能を実行しません。それらのいくつかは、また、例えば、TCPオプションヘッダを使用するフローに失敗することが知られていますタイムスタンプ。
o NAT implementations differ markedly in their handling of packets. Quite a few only really work reliably with TCP packets, not UDP. Of the ones that do make any attempt to handle UDP packets, the timers aging out flows can vary widely making it challenging to predict behavior.
O NATの実装は、パケットの彼らの取扱いが著しく異なります。かなりの数のだけは本当にTCPパケット、UDPないで確実に動作。 UDPパケットを処理しようとする試みを作るのですかもののうち、フローをエージングアウトタイマーは、それが問題行動を予測すること広く変えることができます。
o Variation in address and port assignments can be quite frequent - on NATs, port numbers always change, and change unpredictably; there may be multiple NATs in parallel for load-sharing, making IP address variations quite likely as well.
Oアドレスとポート割り当ての変動は非常に頻繁にすることができます - NATの上で、ポート番号は常に変化し、予測できない変更します。同様に、非常にありそうなIPアドレスの変化を作り、負荷分散のために並列に複数のNATが存在してもよいです。
By distinguishing these approaches as short term fixes, the IAB believes the following considerations must be explicitly addressed in any proposal:
短期フィックスとしてこれらのアプローチを区別することで、IABは、次の考慮事項が明示的に任意の提案で取り組まなければならないと考えています。
1. 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. Such generalizations lead to the the prolonged dependence on and usage of the supposed short term fix -- meaning that it is no longer accurate to call it "short term".
UNSAF提案で解決されるべき特定の、限定されたスコープの問題の1の正確な定義。短期的な修正は、他の問題を解決するために一般化すべきではありません。このような一般化は、長期の依存となっ短期修正の利用につながる - 「短期」、それを呼び出すことはもはや正確であることを意味しません。
2. 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.
出口戦略/移行計画の0002。より良い短期間フィックスは、適切な技術が展開されると自然に減って使用が表示されますものです。
3. 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.
システムより「脆い」レンダリングすることがあり、特定の問題の3議論。たとえば、複数のネットワーク層でデータを使用することを含むアプローチは、デバッグの課題を高め、移行することが難しく、より多くの依存関係を作成します。
4. Identify requirements for longer term, sound technical solutions; contribute to the process of finding the right longer term solution.
4.、長期の要件を特定する技術的な解決策を鳴らします。右の長期的な解決策を見つけるプロセスに貢献します。
5. Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
既存の展開のNATと経験の報告と述べた実用的な問題の影響5.議論。
As a general class of workarounds, UNSAF proposals may introduce security holes because, in the absence of "middlebox communication (midcom)", there is no feasible way to let incoming communications make their way through a firewall under proper supervision: respecting the firewall policies as opposed to circumventing security mechanisms.
、「ミドルコミュニケーション（MIDCOM）」が存在しない場合には、入ってくる通信が適切な監督の下でファイアウォールを介して自分の道を作るようにする実現可能な方法はありませんので、回避策の一般的なクラスとして、UNSAF提案は、セキュリティホールを導入することができる：ファイアウォールポリシーを尊重しますセキュリティメカニズムを回避するとは対照的です。
Appendix A. IAB Members at the time of this writing:
この記事の執筆時点では、付録A. IABメンバー：
Harald Alvestrand Ran Atkinson Rob Austein Fred Baker Leslie Daigle Steve Deering Sally Floyd Ted Hardie Geoff Huston Charlie Kaufman James Kempf Eric Rescorla Mike St. Johns
ハラルドAlvestrandはアトキンソンロブAusteinとフレッド・ベイカーレスリーDaigle氏スティーブデアリングサリーフロイドテッドハーディージェフ・ヒューストンチャーリー・カウフマンジェームス・ケンプ、エリックレスコラマイク・セントジョンズ蘭
Appendix B. Acknowledgements
付録B.謝辞
This document has benefited greatly from detailed comments and suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James Woodyatt.
この文書では、トーマスNarten氏、バーナードAboba、キースムーア、そしてジェームズWoodyattから詳細なコメントや提案から大きな恩恵を受けています。
This document was originally drafted when the following people were part of the IAB: Steve Bellovin, Brian Carpenter, Jon Crowcroft, John Klensin and Henning Schulzrinne; it has benefited considerably from their contributions and review.
次の人はIABの一部であったときに、この文書は、もともと起草されました：スティーブBellovin氏、ブライアン・カーペンター、ジョンクロウクロフト、ジョン・クレンシンおよびヘニングSchulzrinneと。それは彼らの貢献とレビューから大幅に恩恵を受けています。
Appendix C. Example NAT Configuration Scenario
付録C.例NATの設定のシナリオ
C.1 Generic NATed Network Configuration
C.1一般的なNAT処理ネットワーク設定
Here is one sample scenario wherein it is difficult to describe a single "outside" to a given address realm (bridged by NAPTs). This sort of configuration might arise in an enterprise environment where different divisions have their own subnets (each using the same private address space); the divisions are connected so that they can pass traffic on each others' networks, but to access the global Internet, each uses a different NAPT/firewall:
ここでは、（NAPTsによって架橋）指定されたアドレス領域に単一の「外部」を記述することは困難であるつのサンプルシナリオがあります。設定のこの種の異なる部門が独自のサブネット（各同じプライベートアドレス空間を使用して）を持っているエンタープライズ環境で発生する可能性があります。部門は、それらが互いのネットワーク上のトラフィックを渡すことができますが、グローバルなインターネットにアクセスするように接続され、それぞれが異なるNAPT /ファイアウォールを使用しています。
+---------+
| Box C | (192.168.4.5)
+---+-----+
|
---------------------------------+-------
|
| 192.168.3.0/24
+----+----+
| NAT 2 |
+----+----+
| 10.1.0.0/32
|
-----+-------------------------+------------+----
| |
| +----+----+
| | Box B | (10.1.1.100)
| +---------+
|
+----+----+
| NAPT 1 | (10.1.2.27)
+----+----+
| 10.1.0.0/32
|
----+-----+--
|
|
+----+----+
| Box A | (10.1.1.100)
+---------+
From the perspective of Box B, Box A's address is (some port on) 10.1.2.27. From the perspective of Box C, however, Box A's address is some address in the space 192.168.3.0/24.
ボックスBの観点から、ボックスAのアドレスは10.1.2.27（上のいくつかのポート）です。ボックスCの観点からは、しかし、ボックスAのアドレスは、スペース192.168.3.0/24でいくつかのアドレスです。
C.2 Real World Home Network Example
C.2実世界のホームネットワークの例
James Woodyatt provided the following scenario, based on current examples of home networking products:
ジェームズWoodyattは、ホームネットワーク製品の現在の例に基づいて、次のシナリオを提供します：
o the customer has existing Internet service from some broadband service provider, using e.g. a DSL line connected to an appliance that integrates a DSL modem with a NAT router/firewall.
O顧客は、例えば使用して、いくつかのブロードバンドサービスプロバイダからインターネットサービスを既存ましたNATルータ/ファイアウォールでDSLモデムを統合アプライアンスに接続されているDSL回線。
o these devices are sometimes packaged with automated provisioning firmware, so the customer may view them as part of what their ISP provides them.
Oこれらのデバイスは、時には自動プロビジョニングのファームウェアに同梱されていますので、お客様は自分のISPがそれらを提供するものの一部としてそれらを見ることができます。
o later, the customer wants to use a host with only a wireless LAN interface, so they install a wireless access point that ships in its default configuration with NAT and a DHCP server enabled.
O後に、顧客が唯一の無線LANインタフェースを持つホストを使用したいので、彼らはそのNATとデフォルトの設定とDHCPサーバで船が対応無線アクセスポイントを設置します。
o after this, the customer has a wired LAN in one private address realm and a wireless LAN in another private address realm.
Oこの後、顧客が別のプライベートアドレス領域で1つのプライベートアドレスレルム内の有線LANと無線LANを持っています。
Furthermore, most customers probably have no idea what the phrase "address realm" means and shouldn't have to learn it. All they often know is that the printer server is inaccessible to the wireless laptop computer. (Why? Because the discovery protocol uses UDP multicast with TTL=1, but that's okay because any response would just be dropped by the NAT anyway, because there's no ALG.)
さらに、ほとんどの顧客は、おそらくどのようなフレーズ「アドレスレルム」を意味し、それを習得する必要はありませんわかりません。彼らはしばしば知っているすべては、プリンタサーバは、無線ラップトップコンピュータにアクセスできないことです。 （なぜ？ディスカバリプロトコルは、TTL = 1でUDPマルチキャストを使用しますが、何のALGはありませんので、任意の応答はちょうど、とにかくNATによって廃棄されますので、それは大丈夫だから。）
Authors' Addresses
著者のアドレス
Leslie Daigle Editor
レスリーDaigle氏エディタ
Internet Architecture Board IAB EMail: iab@iab.org
インターネットアーキテクチャ委員会IAB Eメール：iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。