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）IETFトラスト（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.
フィルタリングしたり、それが運ぶデータを変換しないネットワークは、パケットの内容に「透明」または「忘れ」であると言うことができます。忘れ輸送を提供するネットワークはコアへの変更を必要とせずに、新たなサービスの展開を可能にします。それは、おそらくインターネットの最も本質的な特徴だけでなく、その成功に最も重要な貢献の一つでもあるこの柔軟性です。
"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.
ネットワークの現在の指数関数的な成長は、接続が独自の報酬であり、そのようなメールやワールド・ワイド・ウェブなどの任意の個々のアプリケーションよりも貴重であることを示しているようです。この接続は、サービスプロバイダ間の技術協力を必要とし、ますますリベラルと競争力の商用通信環境で繁栄します。
"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.
エンド・ツー・エンド原理の一つの望ましい結果は、技術革新の保護です。新しいサービスを展開するために、ネットワークの変更を要求することは一般的に、まだエンド・ノードを変更するよりも困難です。反論 - 多くのエンド・ノードは、現在、本質的に更新可能ではなく、ほとんどのユーザーは、とにかくそれらを更新したくないというボックスを閉じていることは - すべてのノードとすべてのユーザーには適用されません。多くのエンド・ノードは、まだユーザーが設定され、ユーザーのかなりの割合は、新しいアイデアを試すために、技術悲しみの一定量を我慢して喜んでいる「アーリーアダプター」です。そして、さえクローズボックスと無関係のユーザーのために、エンド・ツー・エンド原理を遵守ダウンロードコードは、迅速なサービスのイノベーションを提供することができます。自社のネットワークを変更するには、ISPや企業のネットワーク管理者の束を説得するためのサービスのための新しいアイデアを持つ人を必要とすることははるかに困難単にサービスを実装するいくつかのダウンロード可能なソフトウェアを使用して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）を分割し、ロードバランサなど[RFC2775]にもつながる可能性がある潜在的な将来の方向性を分析透明性の回復に。第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のを使用することなく、様々なシナリオは、すべての乱雑され、最終的に1種類または別の行き止まりにつながるように見えます。完全な展開への道に必要なステップである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.
また、IPv6インターネットでの役割を果たしている可能性がIPv4インターネットの透明性の低下につながっている基本的な力の多くは、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.
インターネットアーキテクチャの美徳の一つは、新しいアプリケーションを展開することができる容易さであるので、新しいアプリケーションを展開する能力を制限する慣行は、イノベーションを削減する可能性があります。
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つ以上のアプリケーションに関連付けられているトラフィックをブロックまたは制限するために設計されたアプリケーションレイヤフィルタリングを含んでいます。
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]で言及開示と同意義務は、第4節はまた、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クラスは、このような「保証転送」[RFC2597]のように他より高いランダム損失率が発生することがあります。彼らは、割り当てられた帯域幅を超えた場合逆に、「優先転送」[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）に注目を注いできました。しかし、時間の経過とともに、それは（頻繁にファイアウォールやNATを実行するデバイスの中に埋め込まれた）アプリケーションレイヤゲートウェイ（ALG）の展開に固有の問題があることが明らかになりました。
[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）またはプロキシと結合しなければなりません。新しいアドレスに依存するアプリケーションがやって来るたびさらに、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は、透明性に追加の障壁を表すことが明らかになりました。まだのALGでサポートされていない新しいアプリケーションの導入への障壁を装ったことに加えて、の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.
かなり貧弱な実装の単なるアーティファクトよりも、これらの困難はのALGのアーキテクチャに固有のものであることが強調されるべきです。 「透明ALG」の概念は点では矛盾があるように、どんなにALGが実装されているかだけでなく、透明性への障壁は、時間をかけて出てくるんだろう。
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のALGは、すべてのエンドポイントがアップグレードされた場合でも、安全な命名インフラの展開を防ぐDNSSECとの非互換性などの問題のホストを提示します。 [RFC4966]、セクション3 - 詳細については、「プロトコル変換（NAT-PT）歴史的な状態にネットワークアドレス変換を移動する理由」を参照してください。
[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ネットワークは、そのネットワーク内のすべてのホストとのリンクのアドレスとサブネットワークの割り当てを可能にするのに十分な接頭辞を供給することが重要です。初期アドレス割り当てポリシーは、一般的な要件に対処すべきである「小さな」のサイトに/ 48のプレフィックスを割り当てる示唆しました。割り当てポリシーへの変更を考慮にさらに制限からなり、透明性の減少を取る必要があります。例えば、プレフィックス委譲又はためのサポートなし単一/ 64のプロバイダのプロビジョニングは、（さらに悪い）より長い接頭利用可能性に制限を表すことになる（[RFC4291]、非000/3ユニキャストプレフィクスのセクション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ステートレス自動設定またはルータ広告メッセージが使用されていません。どちらも近隣探索ではありません。
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のはINTERNAL_IP6_ADDRESS属性を使用して、単一のIPv6アドレスの割り当てのために用意されています。これは、IPv6アドレスの割り当てのためにサポートされている唯一の属性である場合には、ただ一つの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.
しかし、これは委任することができるプレフィックスを取得するためにホストを有効にしません。 INTERNAL_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.
[RFC2826]「ユニークなDNS根のIAB技術コメント」では、独自のルートのための技術的な引数が発表されました。
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つの一意のルートが使用されているときやドメインが単一の所有者やメンテナによって維持されている場合、この原則にのみ満たすことができると主張しています。
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]の出版以来、名前が名前と、そのWebサービスをホストアドレスレコードを持つ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.
特に、[RFC4035]「DNSセキュリティ拡張のためのプロトコル変更」で説明し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は、リダイレクトすることができる「取得します」。または特定のパケットは、オーバーレイネットワーク上に流用することができます。
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]エニーキャストの使用は慎重にルーティング変更の面になるようにサービスを維持することができて考えることが必要です。
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]クラーク、D.ら、 "新アーチ：次世代インターネットアーキテクチャ"。、http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、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]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "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.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、RFC 2597、1999年6月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、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]インターネットアーキテクチャ委員会、 "ユニークなDNS根のIAB技術コメント"、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.、フォード、P.、ムーア、T.、ヘルツォーク、S.、およびR.ヘス、 "RSVPのID表現"、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.、Charny、A.、ベネット、J.、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[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、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003.
[RFC3662]祝福、R.、ニコルズ、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]ケンプ、J.、エド、Austeinと、R.、エド、および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.ボルペ、 "IKEにおけるNATトラバーサルのネゴシエーション"、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4084] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005.
[RFC4084] Klensin、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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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：ネットワークアドレス変換を通じてUDP経由トンネリングのIPv6器（NAT）"、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.ホフマン、 "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]アウン、C.およびE.デイヴィス、 "ネットワークアドレス変換に移動する理由 - 歴史的な状態にプロトコル変換（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.
作者はこのドキュメントへの貢献のためにヤリArkko、ステファンBortzmeyer、ブライアン・カーペンター、スペンサードーキンス、スティーブン・ケント、カール・マラマッド、ダニー・マクファーソン、フィル・ロバーツとペッカ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
バーナードAbobaロア・アンダーソン、ブライアン・カーペンターレスリーDaigle氏エルウィン・デイビスケビン秋オラフKolkmanカーティスLindqvistデビッド・マイヤーデヴィッドオランエリックレスコラデーブターラーLixiaチャン
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
エルウィンB.デイヴィスコンサルタントソーハム、Cambsの英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。