[要約] RFC 3424は、ネットワークアドレス変換を介した一方的な自己アドレス修正（UNSAF）に関するIABの考慮事項をまとめたものです。このRFCの目的は、ネットワークアドレス変換による通信の問題を解決するためのガイドラインを提供することです。
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
ネットワークアドレスの翻訳全体の一方的な自己アドレス修正（UNSAF）のためのIABの考慮事項
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.
Copyright（c）The Internet Society（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）の性質の結果として、1つ以上の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）ミドルボックスの性質の結果として、1つまたは複数の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 具体的には、住所の領域が境界を搭載している場所（「内部」または「外部」、「プライベート」または「パブリック」、またはトラフィックをルーティングするいくつかの「プライベート」レルム）を知ることが不可能であるため、アドレスは特定のポイントに対してのみ決定できます。ネットワーク内。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.
o 「Middlebox Communication（Midcom）」がない場合、着信通信が適切な監督の下でミドルボックス（NAT、ファイアウォール）を通過できるようにするための使用可能な方法はありません。NATを回避することにより、UNSAFメカニズムは（不注意に）セキュリティメカニズムを回避する場合があります。特定の危険は、内部マシンが、ファイアウォールがブロックすることを意図している外部側からのすべての悪意のある通信に無意識のうちにさらされていることです。これは、UNSAFプロセスがいくつかのために作用している1つのマシンで実行されている場合、特に受け入れられません。
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サーバー（リスナー）に送信された「Ping」のようなアドレス発見発見要求の使用が含まれます。。ただし、接続のないトランスポート、例えば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.
o UNSAFサーバーはミドルボックスと統合されていないため、過去の動作は将来の動作の予測因子であるという仮定でのみ動作できます。アドレス翻訳のヒューリスティックまたは影響力の要因に関する特別な知識はありません。
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 Natsの配送には、ソースまたは宛先ポート番号に応じて、コンテキストに敏感であることを試みるアプリケーションレイヤーゲートウェイ（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.
o TCPアプリケーションプロトコルを翻訳しようとするALGSを使用したほとんどのNAT実装は、複数のTCPセグメントにまたがるサブストリングがスパンを翻訳する必要がある場合、機能を正しく実行しません。それらのいくつかは、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の実装は、パケットの処理が著しく異なります。かなりの数は、UDPではなく、TCPパケットで実際に確実に動作します。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では、ポート番号は常に変化し、予測不可能に変化します。負荷シェアリングには複数のNATが並行している可能性があり、IPアドレスのバリエーションも非常に可能性が高くなります。
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".
1. UNSAF提案で解決される特定の限られたスコープ問題の正確な定義。他の問題を解決するために、短期的な修正を一般化しないでください。このような一般化は、想定される短期的な修正への長期依存と使用につながります。つまり、「短期」と呼ぶことはもはや正確ではありません。
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.
2. 出口戦略/移行計画の説明。より良い短期的な修正は、適切なテクノロジーが展開されるにつれて、自然に使用が少なく使用されるものです。
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.
5. 既存の展開されたNATおよび経験レポートに関する有名な実用的な問題の影響に関する議論。
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.
一般クラスの回避策として、UNSAFの提案はセキュリティホールを導入する可能性があります。「Middlebox Communication（MIDCOM）」がない場合、着信通信が適切な監督の下でファイアウォールを通過できるようにするための実行可能な方法はありません。ファイアウォールポリシーを尊重するセキュリティメカニズムを回避するのとは対照的に。
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
ハラルド・アルベスランド・ラン・アトキンソン・ロブ・オーストイン・フレッド・ベイカー・レスリー・デイグル・ディー・ディアリング・サリー・フロイド・テッド・ハーディ・ジェフ・ヒューリー・カウフマン・ジェームズ・ケンプフ・エリック・レスカルラ・マイク・セント・ジョンズ
This document has benefited greatly from detailed comments and suggestions from Thomas Narten, Bernard Aboba, Keith Moore, and James 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の一部であったときにドラフトされていました。スティーブベロビン、ブライアンカーペンター、ジョンクロッククロフト、ジョンクレンシン、ヘニングシュルツリンヌ。それは彼らの貢献とレビューからかなり恩恵を受けました。
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:
1つのサンプルシナリオでは、特定のアドレスの領域に単一の「外側」を記述することが困難です（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のアドレスです。
James Woodyatt provided the following scenario, based on current examples of home networking products:
James 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 顧客は、いくつかのブロードバンドサービスプロバイダーから既存のインターネットサービスを持っています。DSLモデムをNATルーター/ファイアウォールと統合するアプライアンスに接続された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
レスリー・デイグルの編集者
Internet Architecture Board IAB EMail: iab@iab.org
インターネットアーキテクチャボードIABメール：iab@iab.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。