RFC4924 日本語訳
4924 Reflections on Internet Transparency. B. Aboba, Ed., E. Davies. July 2007. (Format: TXT=35040 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Aboba, Ed.
Request for Comment: 4924 E. Davies
Category: Informational Internet Architecture Board
July 2007
ワーキンググループB.Aboba、エドをネットワークでつないでください。コメントのために以下を要求してください。 4924年のE.デイヴィースカテゴリ: 情報のインターネット・アーキテクチャ委員会2007年7月
Reflections on Internet Transparency
インターネット透明に関するReflections
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).
IETFが信じる著作権(C)(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
1. 序論…2 2. 追加透明問題…4 2.1. アプリケーション制限…4 2.2. サービスの質(QoS)…6 2.3. 応用層ゲートウェイ(ALGs)…7 2.4. IPv6は制限を扱います…8 2.4.1. プロバイダーによるIPv6アドレスの配分…8 2.4.2. IKEv2…8 2.5. DNS問題…9 2.5.1. ユニークな根…9 2.5.2. 名前空間の台無しにすること…9 2.6. ロードバランシングとリダイレクション…10 3. セキュリティ問題…11 4. 参照…11 4.1. 有益な参照…11の承認…13 付録A--承認時点のIABメンバー…14
Aboba & Davies Informational [Page 1] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[1ページ]のRFC4924Reflections
1. Introduction
1. 序論
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.
ネットワークの現在の急激な増加はその接続性を示しているのがそれ自身の報酬であり、メールかWWWなどのどんな個々のアプリケーションよりも貴重であるように思えます。 この接続性は、サービスプロバイダーの間で技術協力を必要として、ますます寛容で競争力がある商業テレコミュニケーション環境で派手な振る舞いを必要とします。
"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:
「中央の上昇と終わらせる終わりの未来:」 「インターネットArchitectureのEvolutionの上のReflections」[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
終わりから終わりへの原則の1つの望ましい結果は革新の保護です。 それでも、新種業務を配布するためにネットワークで変更を必要とするのは、終わりを変更するより通常難しいノードです。 そんなに多くのエンドノードがアップデート可能でなく、ほとんどのユーザがとにかく彼らをアップデートしたがっていない現在本質的には閉じている箱であるという反論はすべてのノードとすべてのユーザに適用されません。 多くのエンドノードはそれでも、構成可能なユーザとユーザのかなり大きい百分率が「初期採用者」であるということです。(」は新しいアイデアを十分に試すためにある量の技術的な深い悲しみを我慢しても構わないと思っています)。 そして、同等
Aboba & Davies Informational [Page 2] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[2ページ]のRFC4924Reflections
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か企業ネットワークの管理者を説得するように新しいアイデアでだれかを必要とするのは単に何らかのダウンローダブルなソフトウェアがサービスを実装しているウェブページを提供するよりはるかに難しいです。
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:
しかし、インターネットはサイズとアプリケーションの多様性で大いに広がりさえしましたが、透明度は減少しました。 「インターネットTransparency」[RFC2775]は、インターネット透明の損失の原因のいくつかに注意して、それらの影響を分析します。 これはNetwork Address Translators(NATs)、ファイアウォール、アプリケーションレベルゲートウェイ(ALGs)、リレー、プロキシ、キャッシュ、分裂Domain Name Service(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の使用のない様々なシナリオは、すべて乱雑であり、結局、何らかの種類の行き止まりに通じるように思えます。 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-
中のIPv6インターネット、IPv6インターネットの透明におけるプレーaの役割プレないまたIPv4インターネットの透明がそうする減少に通じた基本力の多く以来
Aboba & Davies Informational [Page 3] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[3ページ]のRFC4924Reflections
ordained, but rather represents an ideal whose maintenance will require significant ongoing effort.
定めますが、むしろ、メインテナンスが重要な進行中の取り組みを必要とする理想を表します。
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声明の公表以来、新技術は開発されています、そして、既存の技術に関する意見は変化しました。 いくつかの場合、これらの新技術は忘れっぽい輸送に影響を与えます、そして、加入者は彼らのサービスにおいて含意を意識している必要があります。
2. Additional Transparency Issues
2. 追加透明問題
2.1. Application Restriction
2.1. アプリケーション制限
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つは顧客同意なしで実装されたアプリケーション用法を妨げるか、または制限するように設計されたフィルタリングです。 これはインターネット、Transport、および1つ以上のアプリケーションに関連しているトラフィックを妨げるか、または制限するように設計されたApplication層のフィルタリングを含んでいます。
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
プロバイダーフィルタリングがセキュリティがプロバイダーインフラストラクチャに対する攻撃かサービス不能攻撃などの問題であると扱うために役に立つかもしれない間、顧客によって決定されるようにフィルターにかけるのを許容することによって、より大きい柔軟性を提供します。 通常、これがプロバイダーアクセスルータなどの縁で実装されるだろう、(例えば、社外調達
Aboba & Davies Informational [Page 4] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[4ページ]のRFC4924Reflections
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]で指摘されるように、「インターネットの接続性」を提供するとして広告に掲載されたサービスは彼らの能力においてかなり異なります、混乱に通じて。 ドキュメントは「Firewalledインターネットの接続性と、完全なインターネットの接続性」と「ウェブの接続性」、「場内放送のないクライアントの接続性専用」を含んでいる「クライアントの唯一の、そして、公共のアドレス」というインターネットの接続性に話す用語を定義します。 「完全なインターネットの接続性」[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.
ウェブプロキシをフィルターにかけて、妨害プロキシ、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.
より一般に、プロバイダーはどんな目的地を妨げるか、制限するか、または変更するサービスの動作も特定するべきであり、アプリケーションの外国行きの使用(すなわち、プロバイダーの近く、または、プロバイダーのネットワークの上で供給されなかったサービスの使用)はサービスです。
Aboba & Davies Informational [Page 5] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[5ページ]のRFC4924Reflections
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]は、プロバイダーが提供されたサービスが忘れっぽい輸送から出発する方法を宣言するように求めます。 また、輸送網の中の忘れっぽい輸送の不足が透明に影響するので、また、これは加入者のトラフィックがネットワークの上を移動するかもしれないプロバイダーに適用されます。
2.2. Quality of Service (QoS)
2.2. サービスの質(QoS)
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.
1セットのサービスかアドレスに合っていないトラフィックを差別するのにQoSメカニズムを使用すると、同様の影響は非常に制限しているファイアウォールの展開に与えられます。 流れが厳しいパケット損失を避けるように、認証されたRSVP条件[RFC2747][RFC3182]を必要とすると、同様の影響は認証されたファイアウォール縦断の展開に与えられます。
Aboba & Davies Informational [Page 6] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[6ページ]のRFC4924Reflections
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制限への有効な用途があるかもしれません。 例えば、顧客はピアツーピアのファイル共有サービスで消費された帯域幅を制限したがっているかもしれません、必要不可欠なアプリケーションで影響を制限するために。
2.3. Application Layer Gateways (ALGs)
2.3. 応用層ゲートウェイ(ALGs)
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はNetwork Address Translation(NAT)にかなりの注意をささげました、ここでその議論を繰り返す必要がほとんどないように。 しかしながら、時がたつにつれて、Application Layer Gateways(ALGs)の展開の固有である問題(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.
最大限の範囲のインターネットアプリケーションが使用されていることであるなら、NATsはアプリケーションレベルゲートウェイ(ALGs)かプロキシに結びつけられなければなりません。 その上、新しいアドレス依存するアプリケーションがやって来るときはいつも、ALGかプロキシをアップデートしなければなりません。 実際には、多くのファイアウォール製品がNATの機能性に組み込まれて、すべての役に立つNATsがALGsを関連づけたので、彼らの様々な影響を解きほぐすのは難しいです。
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縦断技術の開発によると、ALGsが追加バリアを透明に表すのは明らかになりました。 ALGsによってまだサポートされていなかった新しいアプリケーションの展開にバリアにポーズをとらせることに加えて、ALGsはアップデートされたバージョンと同様に既存のアプリケーションの展開における困難を作成するかもしれません。 例えば、IKE NAT-Tの開発では、追加困難はNATsの中で埋め込まれた「IPsecアシスタント」ALGsによって提示されました。
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.
これらの困難が単に貧しい実装の人工物よりむしろALGsのアーキテクチャに固有であると強調されるべきです。 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 ALGsは多くの問題を提示します、すべての終点がアップグレードしても安全な命名インフラストラクチャの展開を防ぐDNSSECがある非互換性を含んでいて。 詳細に関しては、「ネットワーク・アドレス翻訳者を動かす理由--翻訳者(太平洋標準時のNAT)について歴史的な状態に議定書の中で述べる」[RFC4966]セクション3を見てください。
Aboba & Davies Informational [Page 7] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[7ページ]のRFC4924Reflections
2.4. IPv6 Address Restrictions
2.4. IPv6アドレス制限
[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が強く1クライアントあたりの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の導入は、バリアを透明に表して、したがって、できれば、避けられることです。
2.4.1. Allocation of IPv6 Addresses by Providers
2.4.1. プロバイダーによるIPv6アドレスの配分
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接頭語を/に割り当てるのを示しました。 配分方針へのどんな変化もさらなる制限から生じる透明減少を考慮に入れるはずです。 例えば、接頭語委譲のサポートも(よりひどく静かな)より長い接頭語([RFC4291]、非000/3ユニキャスト接頭語のためのセクション2.5.4で、禁止される)のないaシングル/64のプロバイダーの食糧を供給するのはバリアを透明に表すことができたIPv6アドレスの有用性に制限を表すでしょう。
2.4.2. IKEv2
2.4.2. IKEv2
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
INTERNAL_IP6_ADDRESS属性を使用して、IKEv2はただ一つのIPv6アドレスの課題に備えます。 これがIPv6アドレス課題のためにサポートされた唯一の属性であるなら、ただ一つのIPv6アドレスだけが利用可能になるでしょう。 INTERNAL_IP6_SUBNET属性は、ホストが作成された安全なトンネル直接を通ってアクセスしやすいサブネットワークを決定するのを可能にします。 1つを割り当てるのに潜在的にそれを使用できました。
Aboba & Davies Informational [Page 8] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[8ページ]のRFC4924Reflections
or more prefixes to the IKEv2 initiator that could be used for address creation.
または、アドレス作成に使用できたIKEv2創始者への、より多くの接頭語。
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]の使用が追加接頭語を得るのを潜在的に可能にして。 しかしながら、implementersが共同利用できる方法でこれらのオプションを利用するように、IKEv2仕様への明確化は必要であるように見えます。
2.5. DNS Issues
2.5. DNS問題
2.5.1. Unique Root
2.5.1. ユニークな根
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]について言及しません。 私たちは、適切なIPサービスに、ユニークな根のDNS名前空間の使用が不可欠であると強調します。
2.5.2. Namespace Mangling
2.5.2. 名前空間の台無しにすること
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プロトコルに違反しません。 こちらは、答えの変更が正式のサーバの間の経路の中央で行われるそうとまたはアプリケーションの答えを提供するスタッブレゾルバではありません。
Aboba & Davies Informational [Page 9] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[9ページ]のRFC4924Reflections
[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が提供することを意図する向上したセキュリティを無効にして。
2.6. Load Balancing and Redirection
2.6. ロードバランシングとリダイレクション
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] オーバレイネットワークにパケットを紛らすパケットフィルタがmisconfiguredされるなら、これは遠端がそれらを世界的なインターネットに返すことができないなら、オーバレイに的外れであり、遅らせられるか、または失われたパケットに通じることができます。
Aboba & Davies Informational [Page 10] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[10ページ]のRFC4924Reflections
[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の使用は、ルーティング変化に直面してサービスを維持できるように慎重に考え抜かれる必要があります。
3. Security Considerations
3. セキュリティ問題
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.
本書では議論したいくつかの透明問題(NATs、透明なプロキシ、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を見る)への他のアプローチのように、これらの制限は縁で最も柔軟に課されます。
4. References
4. 参照
4.1. Informative References
4.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.、エド、「インターネットの建築プリンシプルズ」、RFC1958、6月1996日
[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分野)の定義」、RFC2474(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は分類する」RFC2597、1999年6月。
Aboba & Davies Informational [Page 11] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[11ページ]のRFC4924Reflections
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、2000年1月。
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February
2000.
[RFC2775] 大工、B.、「インターネット透明」、RFC2775、2000年2月。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[RFC2826]インターネット・アーキテクチャ委員会(「ユニークなDNS根のIABの技術的なコメント」、RFC2826)は2000がそうするかもしれません。
[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のアイデンティティ表現」RFC3182(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.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[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.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、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、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、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]が祝福する、R.、ニコルズ、K.、およびK.ウェールレ、「差別化されたサービスのための1ドメインあたり1つの下側の取り組みの振舞い(PDB)」、RFC3662(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、「中央の上昇と終わらせる終わりの未来:」 「インターネットアーキテクチャの発展のReflections」、RFC3724、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縦断の交渉」、RFC3947、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.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[RFC4084] Klensin, J., "Terminology for Describing Internet
Connectivity", BCP 104, RFC 4084, May 2005.
[RFC4084]Klensin(J.、「インターネットの接続性について説明するための用語」、BCP104、RFC4084)は2005がそうするかもしれません。
Aboba & Davies Informational [Page 12] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[12ページ]のRFC4924Reflections
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February
2006.
[RFC4380]Huitema、C.、「船食虫:」 「ネットワークアドレス変換(NATs)でUDPの上でIPv6にトンネルを堀る」RFC4380、2006年2月。
[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name
System", RFC 4592, July 2006.
[RFC4592] ルイス、E.、「ドメインネームシステムにおけるワイルドカードの役割」、RFC4592、2006年7月。
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
[RFC4718] EronenとP.とP.ホフマン、「IKEv2明確化と実装ガイドライン」、RFC4718、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.デイヴィース、「ネットワークアドレス変換機構を動かす理由--翻訳者(太平洋標準時のNAT)について歴史的な状態に議定書の中で述べてください」、RFC4966、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、ブライアンCarpenter、スペンサー・ダウキンズ、スティーブン・ケント、カール・マラマッド、ダニーMcPherson、フィル・ロバーツ、およびペッカSavolaを承認したがっています。
Aboba & Davies Informational [Page 13] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[13ページ]のRFC4924Reflections
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 Loaアンデションブライアン大工レスリーDaigle ElwynデイヴィースケビンFallオラフ・Kolkmanカーティス・リンクヴィスト・デヴィッド・マイヤー・デヴィッド・オラン・エリック・レスコラ・デーヴ・ターレル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、6605Fax: +1 425 936 7329
Elwyn B. Davies Consultant Soham, Cambs UK
CambsイギリスのElwyn B.デイヴィースコンサルタントSoham
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
以下に電話をしてください。 +44 7889 488 335はメールされます: elwynd@dial.pipex.com
Aboba & Davies Informational [Page 14] RFC 4924 Reflections on Internet Transparency July 2007
インターネット透明2007年7月に関するAbobaとデイヴィース情報[14ページ]のRFC4924Reflections
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Aboba & Davies Informational [Page 15]
AbobaとデイヴィースInformationalです。[15ページ]
一覧
スポンサーリンク
