[要約] RFC 4924は、インターネットの透明性に関する考察をまとめたものであり、その目的はインターネットの運用と管理における透明性の重要性を強調し、透明性を向上させるための提案を行うことです。
Network Working Group B. Aboba, Ed.
Request for Comment: 4924 E. Davies
Category: Informational Internet Architecture Board
July 2007
Reflections on Internet Transparency
インターネットの透明性に関する反省
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document provides a review of previous IAB statements on Internet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts.
このドキュメントは、インターネットの透明性に関する以前のIABステートメントのレビューと、新しい透明性の問題についての議論を提供します。関連性が低下するとはほど遠く、意図的または誤って衝突するネットワークの透明性の技術的意味は、イノベーションとグローバルコミュニケーションをサポートするインターネットの能力に重要な役割を果たします。このドキュメントは、これらの潜在的な影響の特定のイラストを提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Additional Transparency Issues ..................................4
2.1. Application Restriction ....................................4
2.2. Quality of Service (QoS) ...................................6
2.3. Application Layer Gateways (ALGs) ..........................7
2.4. IPv6 Address Restrictions ..................................8
2.4.1. Allocation of IPv6 Addresses by Providers ...........8
2.4.2. IKEv2 ...............................................8
2.5. DNS Issues .................................................9
2.5.1. Unique Root .........................................9
2.5.2. Namespace Mangling ..................................9
2.6. Load Balancing and Redirection ............................10
3. Security Considerations ........................................11
4. References .....................................................11
4.1. Informative References ....................................11
Acknowledgments ...................................................13
Appendix A - IAB Members at the Time of Approval ..................14
In the past, the IAB has published a number of documents relating to Internet transparency and the end-to-end principle, and other IETF documents have also touched on these issues as well. These documents articulate the general principles on which the Internet architecture is based, as well as the core values that the Internet community seeks to protect going forward. This document reaffirms those principles, describes the concept of "oblivious transport" as developed in the DARPA NewArch project [NewArch], and addresses a number of new transparency issues.
過去に、IABは、インターネットの透明性とエンドツーエンドの原則に関する多くのドキュメントを公開しており、他のIETFドキュメントもこれらの問題にも触れています。これらの文書は、インターネットアーキテクチャの基礎となる一般原則と、インターネットコミュニティが今後保護しようとするコアバリューを明確にしています。この文書は、これらの原則を再確認し、DARPA Newarchプロジェクト[Newarch]で開発された「忘却の輸送」の概念を説明し、多くの新しい透明性の問題に対処します。
A network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.
それが運ぶデータをフィルタリングまたは変換しないネットワークは、パケットのコンテンツに対して「透明」または「忘れられない」と言えるかもしれません。忘却の輸送を提供するネットワークは、コアの変更を必要とせずに新しいサービスの展開を可能にします。この柔軟性は、おそらくインターネットの最も本質的な特徴であり、その成功の最も重要な貢献者の1つであることです。
"Architectural Principles of the Internet" [RFC1958], Section 2 describes the core tenets of the Internet architecture:
「インターネットの建築原則」[RFC1958]、セクション2では、インターネットアーキテクチャの主な教義について説明しています。
However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.
ただし、非常に一般的な用語では、コミュニティは目標が接続性であり、ツールはインターネットプロトコルであり、インテリジェンスはネットワークに隠されるのではなく、終わりから終了すると考えています。
The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web. This connectivity requires technical cooperation between service providers, and flourishes in the increasingly liberal and competitive commercial telecommunications environment.
ネットワークの現在の指数関数的な成長は、接続性が独自の報酬であり、メールや世界中のWebなどの個々のアプリケーションよりも価値があることを示しているようです。この接続性には、サービスプロバイダー間の技術的協力が必要であり、ますますリベラルで競争の激しい商業的な通信環境で繁栄します。
"The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture" [RFC3724], Section 4.1.1 describes some of the desirable consequences of this approach:
「エンドツーエンドの中央と未来の台頭：インターネットアーキテクチャの進化に関する反省」[RFC3724]、セクション4.1.1では、このアプローチの望ましい結果のいくつかについて説明します。
One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes. The counterargument - that many end nodes are now essentially closed boxes which are not updatable and that most users don't want to update them anyway - does not apply to all nodes and all users. Many end nodes are still user configurable and a sizable percentage of users are "early adopters," who are willing to put up with a certain amount of technological grief in order to try out a new idea. And, even for the closed boxes and uninvolved users, downloadable code that abides by the end-to-end principle can provide fast service innovation. Requiring someone with a new idea for a service to convince a bunch of ISPs or corporate network administrators to modify their networks is much more difficult than simply putting up a Web page with some downloadable software implementing the service.
エンドツーエンドの原則の望ましい結果の1つは、イノベーションの保護です。新しいサービスを展開するためにネットワークの変更を必要とすることは、通常、エンドノードを変更するよりも依然として困難です。反論 - 多くのエンドノードは、現在、更新できない本質的に閉じたボックスであり、ほとんどのユーザーがとにかく更新したくないということは、すべてのノードとすべてのユーザーには適用されません。多くのエンドノードはまだユーザーの構成可能であり、ユーザーのかなりの割合が「アーリーアダプター」であり、新しいアイデアを試すためにある程度の技術的な悲しみに喜んで我慢しています。また、閉じたボックスや関与していないユーザーであっても、エンドツーエンドの原則を順守するダウンロード可能なコードは、高速サービスの革新を提供できます。サービスの新しいアイデアを持っている人に、多数のISPSまたはコーポレートネットワーク管理者にネットワークを変更するよう説得することは、サービスを実装するいくつかのダウンロード可能なソフトウェアでWebページを作成するよりもはるかに困難です。
Yet, even while the Internet has greatly expanded both in size and in application diversity, the degree of transparency has diminished. "Internet Transparency" [RFC2775] notes some of the causes for the loss of Internet transparency and analyzes their impact. This includes discussion of Network Address Translators (NATs), firewalls, application level gateways (ALGs), relays, proxies, caches, split Domain Name Service (DNS), load balancers, etc. [RFC2775] also analyzes potential future directions that could lead to the restoration of transparency. Section 6 summarizes the conclusions:
しかし、インターネットのサイズとアプリケーションの多様性の両方が大幅に拡大していても、透明性の程度は低下しています。「インターネットの透明性」[RFC2775]は、インターネットの透明性の喪失の原因のいくつかを指摘し、その影響を分析しています。これには、ネットワークアドレス翻訳者（NAT）、ファイアウォール、アプリケーションレベルゲートウェイ（ALG）、リレー、プロキシ、キャッシュ、スプリットドメイン名サービス（DNS）、ロードバランサーなどの議論が含まれます。透明性の回復へ。セクション6には、結論をまとめます。
Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends of one kind or another. Partial deployment of IPv6, which is a required step on the road to full deployment, is also messy but avoids the dead ends.
純粋なIPv6シナリオは最もクリーンでシンプルですが、到達するのは簡単ではありません。IPv6を使用せずにさまざまなシナリオはすべて乱雑であり、最終的には何らかの種類の行き止まりにつながるようです。IPv6の部分的な展開は、完全な展開への道の必要なステップであるが、乱雑ですが、行き止まりを回避します。
While full restoration of Internet transparency through the deployment of IPv6 remains a goal, the Internet's growing role in society, the increasing diversity of applications, and the continued growth in security threats has altered the balance between transparency and security, and the disparate goals of interested parties make these tradeoffs inherently complex.
IPv6の展開によるインターネットの透明性の完全な回復は依然として目標であり、社会におけるインターネットの成長の役割、アプリケーションの多様性の増加、およびセキュリティの脅威の継続的な成長により、透明性とセキュリティのバランスが変わり、関心の異なる目標が変化しました。当事者はこれらのトレードオフを本質的に複雑にします。
While transparency provides great flexibility, it also makes it easier to deliver unwanted as well as wanted traffic. Unwanted traffic is increasingly cited as a justification for limiting transparency. If taken to its logical conclusion, this argument will lead to the development of ever more complex transparency barriers to counter increasingly sophisticated security threats. Transparency, once lost, is hard to regain, so that such an approach, if unsuccessful, would lead to an Internet that is both insecure and lacking in transparency. The alternative is to develop increasingly sophisticated host-based security mechanisms; while such an approach may also fail to keep up with increasingly sophisticated security threats, it is less likely to sacrifice transparency in the process.
透明性は優れた柔軟性を提供しますが、不要なトラフィックと希望のトラフィックを簡単に提供することもできます。不要なトラフィックは、透明性を制限する正当化としてますます引用されています。論理的な結論に達した場合、この議論は、ますます洗練されたセキュリティの脅威に対抗するために、これまで以上に複雑な透明性の障壁の開発につながります。透明性は、一度失われると回復するのが難しいため、このようなアプローチは、失敗したとしても、不安定で透明性が欠けているインターネットにつながります。別の方法は、ますます洗練されたホストベースのセキュリティメカニズムを開発することです。このようなアプローチは、ますます洗練されたセキュリティの脅威に追いつくことができない可能性がありますが、その過程で透明性を犠牲にする可能性は低くなります。
Since many of the fundamental forces that have led to a reduction in the transparency of the IPv4 Internet also may play a role in the IPv6 Internet, the transparency of the IPv6 Internet is not pre- ordained, but rather represents an ideal whose maintenance will require significant ongoing effort.
IPv4インターネットの透明性の低下につながった基本的な力の多くは、IPv6インターネットでも役割を果たす可能性があるため、IPv6インターネットの透明性は事前に定められていませんが、メンテナンスが必要とする理想を表しています。かなりの継続的な努力。
As noted in [NewArch], the technical cooperation that once characterized the development of the Internet has increasingly given way to a tussle between the interests of subscribers, vendors, providers, and society at large. Oblivious transport may be desired by developers seeking to deploy new services; providers may desire to block unwanted traffic in the core before it impacts subscribers; vendors and providers may wish to enable delivery of "value added" services in the network that enable them to differentiate their offerings; subscribers may be sympathetic to either point of view, depending on their interests; society at large may wish to block "offensive" material and monitor traffic that shows malicious intent.
[Newarch]で述べたように、かつてインターネットの開発を特徴付ける技術協力は、加入者、ベンダー、プロバイダー、社会全体の利益の間の争いにますます道を与えられています。新しいサービスを展開しようとする開発者は、忘却の輸送が望まれる場合があります。プロバイダーは、加入者に影響を与える前に、コアの不要なトラフィックをブロックすることを望む場合があります。ベンダーとプロバイダーは、ネットワーク内の「付加価値」サービスの配信を可能にすることを希望する場合があります。加入者は、自分の関心に応じて、どちらの視点にも同情的である可能性があります。社会全体は、「攻撃的な」資料をブロックし、悪意のある意図を示すトラフィックを監視することを望んでいるかもしれません。
While there is no architectural "fix" that can restore oblivious transport while satisfying the interests of all parties, it is possible for providers to provide subscribers with information about the nature of the services being provided. Subscribers need to be aware of whether they are receiving oblivious transport, and if not, how the service affects their traffic.
すべての関係者の利益を満たしながら忘却の輸送を回復できる建築「修正」はありませんが、プロバイダーは、提供されているサービスの性質に関する情報を加入者に提供することができます。加入者は、気づかない輸送を受けているかどうか、そうでない場合は、サービスがトラフィックにどのように影響するかを認識する必要があります。
Since the publication of the previously cited IAB statements, new technologies have been developed, and views on existing technology have changed. In some cases, these new technologies impact oblivious transport, and subscribers need to be aware of the implications for their service.
以前に引用されたIABステートメントの公開以来、新しいテクノロジーが開発され、既存の技術に関する意見が変わりました。場合によっては、これらの新しいテクノロジーは忘却の輸送に影響を与え、加入者はサービスの影響を認識する必要があります。
Since one of the virtues of the Internet architecture is the ease with which new applications can be deployed, practices that restrict the ability to deploy new applications have the potential to reduce innovation.
インターネットアーキテクチャの美徳の1つは、新しいアプリケーションを展開できる容易さであるため、新しいアプリケーションを展開する能力を制限するプラクティスは、イノベーションを減らす可能性があります。
One such practice is filtering designed to block or restrict application usage, implemented without customer consent. This includes Internet, Transport, and Application layer filtering designed to block or restrict traffic associated with one or more applications.
そのようなプラクティスの1つは、顧客の同意なしに実装されたアプリケーションの使用をブロックまたは制限するように設計されたフィルタリングです。これには、1つ以上のアプリケーションに関連するトラフィックをブロックまたは制限するように設計されたインターネット、トランスポート、およびアプリケーションレイヤーフィルタリングが含まれます。
While provider filtering may be useful to address security issues such as attacks on provider infrastructure or denial of service attacks, greater flexibility is provided by allowing filtering to be determined by the customer. Typically, this would be implemented at the edges, such as within provider access routers (e.g., outsourced firewall services), customer premise equipment (e.g., access firewalls), or on hosts (e.g., host firewalls). Deployment of filtering at the edges provides customers with the flexibility to choose which applications they wish to block or restrict, whereas filtering in the core may not permit hosts to communicate, even when the communication would conform to the appropriate use policies of the administrative domains to which those hosts belong.
プロバイダーのフィルタリングは、プロバイダーインフラストラクチャへの攻撃やサービス攻撃の拒否などのセキュリティの問題に対処するのに役立つ場合がありますが、顧客がフィルタリングを決定できるようにすることにより、より大きな柔軟性が提供されます。通常、これは、プロバイダーアクセスルーター（アウトソーシングファイアウォールサービスなど）、顧客の前提装備（アクセスファイアウォールなど）、またはホスト（ホストファイアウォールなど）などのエッジで実装されます。エッジでのフィルタリングの展開により、顧客はブロックまたは制限するアプリケーションを選択できる柔軟性を提供しますが、コアでのフィルタリングは、通信が管理ドメインの適切な使用ポリシーに準拠している場合でも、ホストが通信を許可しない場合があります。それらのホストが属するもの。
In practice, filtering intended to block or restrict application usage is difficult to successfully implement without customer consent, since over time developers will tend to re-engineer filtered protocols so as to avoid the filters. Thus over time, filtering is likely to result in interoperability issues or unnecessary complexity. These costs come without the benefit of effective filtering since many application protocols began to use HTTP as a transport protocol after application developers observed that firewalls allow HTTP traffic while dropping packets for unknown protocols.
実際には、アプリケーションの使用量をブロックまたは制限することを目的としたフィルタリングは、顧客の同意なしに正常に実装することは困難です。これは、開発者がフィルターを回避するためにフィルター処理されたプロトコルを再設計する傾向があるためです。したがって、時間の経過とともに、フィルタリングは相互運用性の問題または不必要な複雑さをもたらす可能性があります。多くのアプリケーションプロトコルは、アプリケーション開発者がファイアウォールが未知のプロトコルのパケットをドロップしながらHTTPトラフィックを許可することを観察した後、多くのアプリケーションプロトコルが輸送プロトコルとしてHTTPを使用し始めたため、効果的なフィルタリングの利点なしで発生します。
In addition to architectural concerns, filtering to block or restrict application usage also raises issues of disclosure and end-user consent. As pointed out in "Terminology for Describing Internet Connectivity" [RFC4084], services advertised as providing "Internet connectivity" differ considerably in their capabilities, leading to confusion. The document defines terminology relating to Internet connectivity, including "Web connectivity", "Client connectivity only, without a public address", "Client only, public address", "Firewalled Internet Connectivity", and "Full Internet Connectivity". With respect to "Full Internet Connectivity" [RFC4084], Section 2 notes:
アーキテクチャの懸念に加えて、アプリケーションの使用をブロックまたは制限するためのフィルタリングは、開示とエンドユーザーの同意の問題も生じます。「インターネット接続を説明するための用語」[RFC4084]で指摘されているように、「インターネット接続」を提供すると宣伝されているサービスは、その機能が大きく異なり、混乱につながります。このドキュメントは、「Web接続性」、「クライアント接続のみ、パブリックアドレスなし」、「クライアントのみ、パブリックアドレス」、「ファイアウォールインターネット接続」、「完全なインターネット接続」、「完全なインターネット接続」など、インターネット接続に関連する用語を定義しています。「完全なインターネット接続」[RFC4084]に関しては、セクション2注：
Filtering Web proxies, interception proxies, NAT, and other provider-imposed restrictions on inbound or outbound ports and traffic are incompatible with this type of service. Servers ... are typically considered normal. The only compatible restrictions are bandwidth limitations and prohibitions against network abuse or illegal activities.
Webプロキシ、インターセプトプロキシ、NAT、およびその他のプロバイダーが課したインバウンドポートまたはアウトバウンドポートとトラフィックのフィルタリングは、このタイプのサービスと互換性がありません。サーバー...通常は正常と見なされます。唯一の互換性のある制限は、帯域幅の制限とネットワーク乱用または違法行為に対する禁止です。
[RFC4084], Section 4 describes disclosure obligations that apply to all forms of service limitation, whether applied on outbound or inbound traffic:
[RFC4084]、セクション4では、アウトバウンドトラフィックまたはインバウンドトラフィックに適用されるかどうかにかかわらず、あらゆる形態のサービス制限に適用される開示義務について説明します。
More generally, the provider should identify any actions of the service to block, restrict, or alter the destination of, the outbound use (i.e., the use of services not supplied by the provider or on the provider's network) of applications services.
より一般的には、プロバイダーは、アプリケーションサービスのアウトバウンド使用（つまり、プロバイダーまたはプロバイダーのネットワーク上で提供されないサービスの使用）をブロック、制限、または変更するためのサービスのアクションを特定する必要があります。
In essence, [RFC4084] calls for providers to declare the ways in which the service provided departs from oblivious transport. Since the lack of oblivious transport within transit networks will also affect transparency, this also applies to providers over whose network the subscriber's traffic may travel.
本質的に、[RFC4084]は、提供されたサービスが忘却の輸送から離れる方法を宣言するようにプロバイダーに求めています。トランジットネットワーク内の忘れられない輸送が不足していることも透明性に影響するため、これはサブスクライバーのトラフィックが移動する可能性のあるネットワーク上のプロバイダーにも適用されます。
While [RFC4084] notes that bandwidth limitations are compatible with "Full Internet Connectivity", in some cases QoS restrictions may go beyond simple average or peak bandwidth limitations. When used to restrict the ability to deploy new applications, QoS mechanisms are incompatible with "Full Internet Connectivity" as defined in [RFC4084]. The disclosure and consent obligations referred to in [RFC4084], Section 4 also apply to QoS mechanisms.
[RFC4084]は、帯域幅の制限は「完全なインターネット接続」と互換性があることを指摘していますが、場合によってはQoSの制限は、単純な平均またはピーク帯域幅の制限を超える可能性があります。新しいアプリケーションを展開する機能を制限するために使用すると、QoSメカニズムは[RFC4084]で定義されている「完全なインターネット接続」と互換性がありません。[RFC4084]で言及されている開示および同意の義務も、QoSメカニズムにも適用されます。
Deployment of QoS technology has potential implications for Internet transparency, since the QoS experienced by a flow can make the Internet more or less oblivious to that flow. While QoS support is highly desirable in order for real-time services to coexist with elastic services, it is not without impact on packet delivery.
QoSテクノロジーの展開は、インターネットの透明性に潜在的な影響を及ぼします。これは、フローが経験したQoSがインターネットを多かれ少なかれそのフローを忘れてしまう可能性があるためです。QoSサポートは、リアルタイムサービスが弾性サービスと共存するために非常に望ましいものですが、パケット配信に影響を与えないわけではありません。
Specifically, QoS classes such as "default" [RFC2474] or "lower effort" [RFC3662] may experience higher random-loss rates than others such as "assured forwarding" [RFC2597]. Conversely, bandwidth-limited QoS classes such as "expedited forwarding" [RFC3246] may experience systematic packet loss if they exceed their assigned bandwidth. Other QoS mechanisms such as load balancing may have side-effects such as re-ordering of packets, which may have a serious impact on perceived performance.
具体的には、「デフォルト」[RFC2474]や「低い努力」[RFC3662]などのQOSクラスは、「Assured Forwarding」[RFC2597]などの他のクラスよりもランダム減速率が高い場合があります。逆に、「Expedited Forwarding」[RFC3246]などの帯域幅が制限されたQoSクラスは、割り当てられた帯域幅を超えた場合、体系的なパケット損失を経験する可能性があります。負荷分散などの他のQoSメカニズムには、パケットの再注文などの副作用がある場合があり、これは知覚されたパフォーマンスに深刻な影響を与える可能性があります。
QoS implementations that reduce the ability to deploy new applications on the Internet are similar in effect to other transparency barriers. Since arbitrary or severe bandwidth limitations can make an application unusable, the introduction of application-specific bandwidth limitations is equivalent to application blocking or restriction from a user's standpoint.
インターネット上に新しいアプリケーションを展開する機能を減らすQoS実装は、他の透明性障壁と有効です。任意の帯域幅の制限または厳しい帯域幅の制限により、アプリケーションが使用できなくなるため、アプリケーション固有の帯域幅の制限の導入は、アプリケーションのブロッキングまたはユーザーの観点からの制限と同等です。
Using QoS mechanisms to discriminate against traffic not matching a set of services or addresses has a similar effect to deployment of a highly restrictive firewall. Requiring an authenticated RSVP reservation [RFC2747][RFC3182] for a flow to avoid severe packet loss has a similar effect to deployment of authenticated firewall traversal.
QoSメカニズムを使用して、サービスや住所のセットと一致しないトラフィックを区別することは、非常に制限的なファイアウォールの展開に同様の効果があります。重度のパケット損失を回避するために、認証されたRSVP予約[RFC2747] [RFC3182]を必要とすることは、認証されたファイアウォールトラバーサルの展開に同様の効果があります。
As with filtering, there may be valid uses for customer-imposed QoS restrictions. For example, a customer may wish to limit the bandwidth consumed by peer-to-peer file sharing services, so as to limit the impact on mission-critical applications.
フィルタリングと同様に、顧客が課したQoS制限には有効な用途がある場合があります。たとえば、顧客は、ミッションクリティカルアプリケーションへの影響を制限するために、ピアツーピアファイル共有サービスによって消費される帯域幅を制限したい場合があります。
The IAB has devoted considerable attention to Network Address Translation (NAT), so that there is little need to repeat that discussion here. However, with the passage of time, it has become apparent that there are problems inherent in the deployment of Application Layer Gateways (ALGs) (frequently embedded within firewalls and devices implementing NAT).
IABは、ネットワークアドレス変換（NAT）にかなりの注意を払っているため、ここでその議論を繰り返す必要はほとんどありません。ただし、時間の経過とともに、アプリケーションレイヤーゲートウェイ（ALG）の展開に固有の問題があることが明らかになりました（頻繁にNATを実装するファイアウォールとデバイスに埋め込まれています）。
[RFC2775], Section 3.5 states:
[RFC2775]、セクション3.5の状態：
If the full range of Internet applications is to be used, NATs have to be coupled with application level gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be updated whenever a new address-dependent application comes along. In practice, NAT functionality is built into many firewall products, and all useful NATs have associated ALGs, so it is difficult to disentangle their various impacts.
インターネットアプリケーションの全範囲を使用する場合、NATはアプリケーションレベルゲートウェイ（ALG）またはプロキシと組み合わせる必要があります。さらに、新しいアドレス依存アプリケーションが登場するたびに、アルグまたはプロキシを更新する必要があります。実際には、NAT機能は多くのファイアウォール製品に組み込まれており、すべての有用なNATに関連するALGがあるため、さまざまな影響を解くことは困難です。
With the passage of time and development of NAT traversal technologies such as IKE NAT-T [RFC3947], Teredo [RFC4380], and STUN [RFC3489], it has become apparent that ALGs represent an additional barrier to transparency. In addition to posing barriers to the deployment of new applications not yet supported by ALGs, ALGs may create difficulties in the deployment of existing applications as well as updated versions. For example, in the development of IKE NAT-T, additional difficulties were presented by "IPsec Helper" ALGs embedded within NATs.
Ike Nat-T [RFC3947]、Teredo [RFC4380]、Stun [RFC3489]などのNATトラバーサル技術の時間の経過と開発により、ALGが透明性への追加の障壁を表していることが明らかになりました。ALGSによってまだサポートされていない新しいアプリケーションの展開に対する障壁を提起することに加えて、ALGは既存のアプリケーションの展開と更新バージョンの展開に困難をもたらす可能性があります。たとえば、Ike Nat-Tの開発では、NATに埋め込まれた「IPSECヘルパー」ALGによって追加の困難が提示されました。
It should be stressed that these difficulties are inherent in the architecture of ALGs, rather than merely an artifact of poor implementations. No matter how well an ALG is implemented, barriers to transparency will emerge over time, so that the notion of a "transparent ALG" is a contradiction in terms.
これらの困難は、単に貧弱な実装のアーチファクトではなく、アルグのアーキテクチャに固有のものであることを強調する必要があります。アルグがどれほどうまく実装されていても、透明性への障壁は時間とともに出現するため、「透明アルグ」の概念は矛盾です。
In particular, DNS ALGs present a host of issues, including incompatibilities with DNSSEC that prevent deployment of a secure naming infrastructure even if all the endpoints are upgraded. For details, see "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status" [RFC4966], Section 3.
特に、DNS ALGSは、すべてのエンドポイントがアップグレードされた場合でも、安全な命名インフラストラクチャの展開を妨げるDNSSECとの非互換性を含む多くの問題を提示します。詳細については、「ネットワークアドレス翻訳者 - プロトコル翻訳者（NAT -PT）を歴史的ステータスに移動する理由」[RFC4966]、セクション3を参照してください。
[RFC2775], Section 5.1 states:
[RFC2775]、セクション5.1は次のように述べています。
Note that it is a basic assumption of IPv6 that no artificial constraints will be placed on the supply of addresses, given that there are so many of them. Current practices by which some ISPs strongly limit the number of IPv4 addresses per client will have no reason to exist for IPv6.
IPv6の基本的な仮定であることに注意してください。それは、それらの多くがあることを考えると、住所の供給に人為的な制約が置かれないことに注意してください。一部のISPがクライアントあたりのIPv4アドレスの数を強く制限する現在のプラクティスは、IPv6に存在する理由はありません。
Constraints on the supply of IPv6 addresses provide an incentive for the deployment of NAT with IPv6. The introduction of NAT for IPv6 would represent a barrier to transparency, and therefore is to be avoided if at all possible.
IPv6アドレスの供給に対する制約は、IPv6によるNATの展開のインセンティブを提供します。IPv6のNATの導入は、透明性の障壁を表しているため、可能であれば避けるべきです。
In order to encourage deployments of IPv6 to provide oblivious transport, it is important that IPv6 networks of all sizes be supplied with a prefix sufficient to enable allocation of addresses and sub-networks for all the hosts and links within their network. Initial address allocation policy suggested allocating a /48 prefix to "small" sites, which should handle typical requirements. Any changes to allocation policy should take into account the transparency reduction that will result from further restriction. For example, provider provisioning of a single /64 without support for prefix delegation or (worse still) a longer prefix (prohibited by [RFC4291], Section 2.5.4 for non-000/3 unicast prefixes) would represent a restriction on the availability of IPv6 addresses that could represent a barrier to transparency.
IPv6の展開が忘れられない輸送を提供するよう奨励するために、すべてのサイズのIPv6ネットワークに、ネットワーク内のすべてのホストとリンクにアドレスとサブネットワークの割り当てを有効にするのに十分なプレフィックスを提供することが重要です。初期アドレス割り当てポリシーは、a /48プレフィックスを「小さな」サイトに割り当てることを提案しました。これは、典型的な要件を処理する必要があります。割り当てポリシーへの変更は、さらなる制限から生じる透明性の低下を考慮に入れる必要があります。たとえば、プレフィックス委任のサポートなしでシングル /64のプロバイダープロビジョニング、または（さらに悪いことに）プレフィックス（[RFC4291]で禁止されています）、セクション2.5.4以外のユニキャストプレフィックスのセクション2.5.4）は、可用性の制限を表しています透明性の障壁を表す可能性のあるIPv6アドレスの。
Issues with IPv6 address assignment mechanisms in IKEv2 [RFC4306] are described in [RFC4718]:
IKEV2 [RFC4306]のIPv6アドレス割り当てメカニズムの問題は、[RFC4718]で説明されています。
IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads, and do not fully follow the "normal IPv6 way of doing things"... In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
IKEV2は、IPv6の構成ペイロードも定義します。ただし、それらは対応するIPv4ペイロードに基づいており、「通常のIPv6の方法」に完全に従うことはありません...特に、IPv6 Stateless AutoconfigurationまたはRouter Advertisementメッセージは使用されません。隣人の発見もありません。
IKEv2 provides for the assignment of a single IPv6 address, using the INTERNAL_IP6_ADDRESS attribute. If this is the only attribute supported for IPv6 address assignment, then only a single IPv6 address will be available. The INTERNAL_IP6_SUBNET attribute enables the host to determine the sub-networks accessible directly through the secure tunnel created; it could potentially be used to assign one or more prefixes to the IKEv2 initiator that could be used for address creation.
IKEV2は、内部_IP6_ADDRESS属性を使用して、単一のIPv6アドレスの割り当てを提供します。これがIPv6アドレスの割り当てでサポートされている唯一の属性である場合、1つのIPv6アドレスのみが利用可能になります。Internal_IP6_Subnet属性により、ホストは作成された安全なトンネルから直接アクセス可能なサブネットワークを決定できます。アドレス作成に使用できるIKEV2イニシエーターに1つ以上のプレフィックスを割り当てるために使用できます。
However, this does not enable the host to obtain prefixes that can be delegated. The INTERNAL_IP6_DHCP attribute provides the address of a DHCPv6 server, potentially enabling use of DHCPv6 prefix delegation [RFC3633] to obtain additional prefixes. However, in order for implementers to utilize these options in an interoperable way, clarifications to the IKEv2 specification appear to be needed.
ただし、これにより、ホストが委任できる接頭辞を取得することはできません。内部_IP6_DHCP属性は、DHCPV6サーバーのアドレスを提供し、DHCPV6プレフィックス委任[RFC3633]の使用を可能にして追加のプレフィックスを取得できます。ただし、実装者がこれらのオプションを相互運用可能な方法で利用するためには、IKEV2仕様の明確化が必要であると思われます。
In "IAB Technical Comment on the Unique DNS Root" [RFC2826], the technical arguments for a unique root were presented.
「一意のDNSルートに関するIAB技術的コメント」[RFC2826]では、一意のルートの技術的議論が提示されました。
One of the premises in [RFC2826] is that a common namespace and common semantics applied to these names is needed for effective communication between two parties. The document argues that this principle can only be met when one unique root is being used and when the domains are maintained by single owners or maintainers.
[RFC2826]の施設の1つは、これらの名前に適用される一般的な名前空間と2つの関係者間の効果的な通信に必要であることです。この文書は、この原則は、1つの一意のルートが使用されている場合と、ドメインが単一の所有者またはメンテナーによって維持されている場合にのみ満たすことができると主張しています。
Because [RFC4084] targets only IP service terms and does not talk about namespace issues, it does not refer to [RFC2826]. We stress that the use of a unique root for the DNS namespace is essential for proper IP service.
[RFC4084]はIPサービスの用語のみをターゲットにしており、名前空間の問題について話しないため、[RFC2826]を参照していません。DNSネームスペースに一意のルートを使用することが、適切なIPサービスに不可欠であることを強調しています。
Since the publication of [RFC2826], there have been reports of providers implementing recursive nameservers and/or DNS forwarders that replace answers that indicate that a name does not exist in the DNS hierarchy with a name and an address record that hosts a Web service that is supposed to be useful for end-users.
[RFC2826]の公開以来、DNS階層に名前が存在しないことを示す回答を置き換える再帰的な名前アーバーおよび/またはDNSフォワーダーを実装しているプロバイダーの報告があり、名前とアドレスレコードがあることを示しています。エンドユーザーに役立つはずです。
The effect of this modification is similar to placement of a wildcard in top-level domains. Although wildcard labels in top-level domains lead to problems that are described elsewhere (such as "The Role of Wildcards in the Domain Name System" [RFC4592]), they do not strictly violate the DNS protocol. This is not the case where modification of answers takes place in the middle of the path between authoritative servers and the stub resolvers that provide the answers to applications.
この変更の効果は、トップレベルのドメインにワイルドカードを配置することに似ています。トップレベルのドメインのワイルドカードラベルは、他の場所で説明されている問題（「ドメイン名システムにおけるワイルドカードの役割」[RFC4592]など）につながりますが、DNSプロトコルに厳密に違反していません。これは、信頼できるサーバーとアプリケーションへの回答を提供するスタブリゾルバーの間のパスの中央で回答の変更が行われる場合ではありません。
[RFC2826] section 1.3 states:
[RFC2826]セクション1.3は次のとおりです。
Both the design and implementations of the DNS protocol are heavily based on the assumption that there is a single owner or maintainer for every domain, and that any set of resources records associated with a domain is modified in a single-copy serializable fashion.
DNSプロトコルの設計と実装の両方は、すべてのドメインに単一の所有者またはメンテナーが存在するという仮定に大きく基づいており、ドメインに関連付けられているリソースレコードのセットは、単一コピーシリアル化可能な方法で変更されています。
In particular, the DNSSEC protocol described in "Protocol Modifications for the DNS Security Extensions" [RFC4035] has been designed to verify that DNS information has not been modified between the moment they have been published on an authoritative server and the moment the validation takes place. Since that verification can take place at the application level, any modification by a recursive forwarder or other intermediary will cause validation failures, disabling the improved security that DNSSEC is intended to provide.
特に、「DNSセキュリティ拡張機能のプロトコル変更」[RFC4035]で説明されているDNSSECプロトコルは、DNS情報が権威あるサーバーで公開された瞬間と検証が行われる瞬間の間に変更されていないことを確認するために設計されています。。その検証はアプリケーションレベルで行われる可能性があるため、再帰転送業者または他の仲介者による変更は検証障害を引き起こし、DNSSECが提供することを目的としたセキュリティの改善を無効にします。
In order to provide information that is adapted to the locale from which a request is made or to provide a speedier service, techniques have been deployed that result in packets being redirected or taking a different path depending on where the request originates. For example, requests may be distributed among servers using "reverse NAT" (which modifies the destination rather than the source address); responses to DNS requests may be altered; HTTP "gets" may be re-directed; or specific packets may be diverted onto overlay networks.
リクエストが行われたロケールに適合した情報を提供したり、より迅速なサービスを提供したりするために、リクエストが発生する場所に応じて、パケットがリダイレクトされるか、別のパスを取得するテクニックが展開されています。たとえば、「リバースNAT」（ソースアドレスではなく宛先を変更する）を使用して、サーバー間でリクエストを配布できます。DNSリクエストへの応答が変更される場合があります。http "gets"が再監督される場合があります。または、特定のパケットがオーバーレイネットワークに転用される場合があります。
Provided that these services are well-implemented, they can provide value; however, transparency reduction or service disruption can also result:
これらのサービスが十分に実装されている場合は、価値を提供できます。ただし、透明性の低下やサービスの中断も生じる可能性があります。
[1] The use of "reverse NAT" to balance load among servers supporting IPv6 would adversely affect the transparency of the IPv6 Internet.
[1] IPv6をサポートするサーバー間の負荷のバランスをとる「リバースNAT」の使用は、IPv6インターネットの透明性に悪影響を及ぼします。
[2] DNS re-direction is typically based on the source address of the query, which may not provide information on the location of the host originating the query. As a result, a host configured with the address of a distant DNS server could find itself pointed to a server near the DNS server, rather than a server near the host. HTTP re-direction does not encounter this issue.
[2] DNSの再方向は、通常、クエリのソースアドレスに基づいており、クエリを発信するホストの場所に関する情報を提供しない場合があります。その結果、遠くのDNSサーバーのアドレスで構成されたホストは、ホストの近くのサーバーではなく、DNSサーバーの近くのサーバーを指すことができます。HTTPの再方向は、この問題に遭遇しません。
[3] If the packet filters that divert packets onto overlay networks are misconfigured, this can lead to packets being misdirected onto the overlay and delayed or lost if the far end cannot return them to the global Internet.
[3] パケットをオーバーレイネットワークに転用するパケットフィルターが誤解されている場合、これによりパケットがオーバーレイに誤った方向に向けられ、遠端がグローバルインターネットに戻すことができない場合に遅延または失われる可能性があります。
[4] The use of anycast needs to be carefully thought out so that service can be maintained in the face of routing changes.
[4] Anycastの使用は、ルーティングの変更に直面してサービスを維持できるように慎重に検討する必要があります。
Several transparency issues discussed in this document (NATs, transparent proxies, DNS namespace mangling) weaken existing end-to-end security guarantees and interfere with the deployment of protocols that would strengthen end-to-end security.
このドキュメントで議論されているいくつかの透明性の問題（NAT、透明なプロキシ、DNSネームスペースのマングリング）は、既存のエンドツーエンドのセキュリティ保証を弱め、エンドツーエンドのセキュリティを強化するプロトコルの展開を妨害します。
[RFC2775], Section 7 states:
[RFC2775]、セクション7は次のように述べています。
The loss of transparency at the Intranet/Internet boundary may be considered a security feature, since it provides a well defined point at which to apply restrictions. This form of security is subject to the "crunchy outside, soft inside" risk, whereby any successful penetration of the boundary exposes the entire Intranet to trivial attack. The lack of end-to-end security applied within the Intranet also ignores insider threats.
イントラネット/インターネットの境界での透明性の喪失は、制限を適用するための明確に定義されたポイントを提供するため、セキュリティ機能と見なされる場合があります。この形式のセキュリティは、「屋外のカリカリ、柔らかい内側」のリスクの対象となります。これにより、境界の浸透が成功すると、イントラネット全体が些細な攻撃にさらされます。イントラネット内に適用されるエンドツーエンドのセキュリティの欠如も、インサイダーの脅威を無視します。
Today, malware has evolved to increasingly take advantage of the application-layer as a rich and financially attractive source of security vulnerabilities, as well as a mechanism for penetration of the Intranet/Internet boundary. This has lessened the security value of existing transparency barriers and made it increasingly difficult to prevent the propagation of malware without imposing restrictions on application behavior. However, as with other approaches to application restriction (see Section 2.1), these limitations are most flexibly imposed at the edge.
今日、マルウェアは、アプリケーションレイヤーをより豊富で経済的に魅力的なセキュリティの脆弱性、およびイントラネット/インターネット境界の浸透メカニズムとしてますます活用するように進化しています。これにより、既存の透明性障壁のセキュリティ価値が低下し、アプリケーションの動作に制限を課すことなく、マルウェアの伝播を防ぐことがますます困難になりました。ただし、アプリケーション制限に対する他のアプローチと同様に（セクション2.1を参照）、これらの制限はエッジに最も柔軟に課されます。
[NewArch] Clark, D. et al., "New Arch: Future Generation Internet Architecture", http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf
[Newarch] Clark、D。et al。、「New Arch：Future Generation Internet Architecture」、http：//www.isi.edu/newarch/idocs/final.finalReport.pdf
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker、F.、Lindell、B。、およびM. Talwar、「RSVP暗号認証」、RFC 2747、2000年1月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC2775]大工、B。、「インターネット透明性」、RFC 2775、2000年2月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000.
[RFC2826]インターネットアーキテクチャボード、「IABユニークなDNSルートに関する技術的なコメント」、RFC 2826、2000年5月。
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.
[RFC3182] Yadav、S.、Yavatkar、R.、Pabbati、R.、Ford、P.、Moore、T.、Herzog、S。、およびR. Hess、「RSVPのアイデンティティ表現」、RFC 3182、2001年10月。
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[RFC3246]デイビー、B。、チャーニー、A。、ベネット、J。、ベンソン、K。、ル・ブーデック、J。、コートニー、W。、ダバリ、S。、フィロウ、V。、およびD.スティリアディス、 "迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[RFC3489] 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.
[RFC3489] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「スタン - ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662] Bless、R.、Nichols、K。、およびK. Wehrle、「差別化されたサービスのドメインごとの挙動（PDB）の低い」、RFC 3662、2003年12月。
[RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
[RFC3724] Kempf、J.、ed。、ed。、Austein、R.、ed。、and Iab、「中央とエンドツーエンドの未来：インターネットアーキテクチャの進化に関する反省」、RFC 3724、2004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947] Kivinen、T.、Swander、B.、Huttunen、A。、およびV. Volpe、「IKEにおけるNat-Traversalの交渉」、RFC 3947、2005年1月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル変更」、RFC 4035、2005年3月。
[RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005.
[RFC4084]クレンシン、J。、「インターネット接続を説明するための用語」、BCP 104、RFC 4084、2005年5月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介してIPv6をトンネル化する」、RFC 4380、2006年2月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006.
[RFC4592]ルイス、E。、「ドメイン名システムにおけるワイルドカードの役割」、RFC 4592、2006年7月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] Eronen、P。およびP. Hoffman、「IKEV2の説明と実装ガイドライン」、RFC 4718、2006年10月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966] Aoun、C。およびE. Davies、「ネットワークアドレス翻訳者を移動する理由 - プロトコル翻訳者（NAT -PT）、RFC 4966、2007年7月。
Acknowledgments
謝辞
The authors would like to acknowledge Jari Arkko, Stephane Bortzmeyer, Brian Carpenter, Spencer Dawkins, Stephen Kent, Carl Malamud, Danny McPherson, Phil Roberts and Pekka Savola for contributions to this document.
著者は、この文書への貢献について、Jari Arkko、Stephane Bortzmeyer、Brian Carpenter、Spencer Dawkins、Stephen Kent、Carl Malamud、Danny McPherson、Phil Roberts、Pekka Savolaに感謝します。
Appendix A - IAB Members at the Time of Approval
付録A -承認時のIABメンバー
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
バーナード・アボバ・ロア・アンダーソン・ブライアン・カーペンター・レスリー・デイグル・エルウィン・デイヴィス・ケビン・フォール・フォール・オラフ・コルクマン・カルティス・リンドクヴィスト
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
Elwyn B. DaviesコンサルタントSoham、Cambs UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。