RFC3234 日本語訳
3234 Middleboxes: Taxonomy and Issues. B. Carpenter, S. Brim. February 2002. (Format: TXT=62329 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Carpenter
Request for Comments: 3234 IBM Zurich Research Laboratory
Category: Informational S. Brim
February 2002
コメントを求めるワーキンググループB.大工要求をネットワークでつないでください: 3234年のIBMチューリッヒ研究所カテゴリ: 情報のS.縁の2002年2月
Middleboxes: Taxonomy and Issues
Middleboxes: 分類学と問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive.
このドキュメントは"middleboxes"についてのIETF議論の一部として意図します--IPルータの正常で、標準の機能は別として、送信元ホストとあて先ホストの間のデータ経路でどんな仲介者箱の実行機能とも定義されます。 このドキュメントは、middleboxesのカタログか分類学を確立して、middleboxesに関して前の、そして、現在のIETF仕事を引用して、いくつかの予備の結論を特定するのを試みます。 しかしながら、それは、決定的であると主張しません。
Carpenter & Brim Informational [Page 1] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[1ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
Table of Contents
目次
1. Introduction and Goals......................................... 3 1.1. Terminology.................................................. 3 1.2. The Hourglass Model, Past and Future......................... 3 1.4. Goals of this Document....................................... 4 2. A catalogue of middleboxes..................................... 5 2.1 NAT........................................................... 6 2.2 NAT-PT........................................................ 7 2.3 SOCKS gateway................................................. 7 2.4 IP Tunnel Endpoints........................................... 8 2.5. Packet classifiers, markers and schedulers................... 8 2.6 Transport relay............................................... 9 2.7. TCP performance enhancing proxies............................ 10 2.8. Load balancers that divert/munge packets..................... 10 2.9. IP Firewalls................................................. 11 2.10. Application Firewalls....................................... 11 2.11. Application-level gateways.................................. 12 2.12. Gatekeepers/ session control boxes.......................... 12 2.13. Transcoders................................................. 12 2.14. Proxies..................................................... 13 2.15. Caches...................................................... 14 2.16. Modified DNS servers........................................ 14 2.17. Content and applications distribution boxes................. 15 2.18. Load balancers that divert/munge URLs....................... 16 2.19. Application-level interceptors.............................. 16 2.20. Application-level multicast................................. 16 2.21. Involuntary packet redirection.............................. 16 2.22. Anonymisers................................................. 17 2.23. Not included................................................ 17 2.24. Summary of facets........................................... 17 3. Ongoing work in the IETF and elsewhere......................... 18 4. Comments and Issues............................................ 19 4.1. The end to end principle under challenge..................... 19 4.2. Failure handling............................................. 20 4.3. Failures at multiple layers.................................. 21 4.4. Multihop application protocols............................... 21 4.5. Common features.............................................. 22 5. Security Considerations........................................ 22 6. Acknowledgements............................................... 23 7. References..................................................... 23 Authors' Addresses................................................ 26 Acknowledgement................................................... 26 Full Copyright Statement.......................................... 27
1. 序論と目標… 3 1.1. 用語… 3 1.2. 砂時計モデル、過去、および未来… 3 1.4. このDocumentの目標… 4 2. middleboxesに関するカタログ… 5 2.1NAT… 6 2.2 太平洋標準時のNAT… 7 2.3SOCKSゲートウェイ… 7 2.4 IPトンネル終点… 8 2.5. パケットクラシファイア、マーカー、およびスケジューラ… 8 2.6 リレーを輸送してください… 9 2.7. プロキシを高めるTCP性能… 10 2.8. /mungeパケットを紛らす負荷分散装置… 10 2.9. IPファイアウォール… 11 2.10. アプリケーションファイアウォール… 11 2.11. アプリケーションレベルゲートウェイ… 12 2.12. 門番/セッションは箱を制御します… 12 2.13. トランスコーダ… 12 2.14. プロキシ… 13 2.15. キャッシュします。 14 2.16. DNSサーバを変更します… 14 2.17. 内容とアプリケーション給水分散皿… 15 2.18. /munge URLを紛らす負荷分散装置… 16 2.19. アプリケーションレベル迎撃戦闘機… 16 2.20. アプリケーションレベルマルチキャスト… 16 2.21. 不本意なパケットリダイレクション… 16 2.22. Anonymisers… 17 2.23. 含まれていません… 17 2.24. 一面の概要… 17 3. IETFとほかの場所での進行中の仕事… 18 4. コメントと問題… 19 4.1. 挑戦で原則を終わらせる終わり… 19 4.2. 失敗取り扱い… 20 4.3. 複数の層での失敗… 21 4.4. マルチホップアプリケーション・プロトコル… 21 4.5. 一般的な特徴… 22 5. セキュリティ問題… 22 6. 承認… 23 7. 参照… 23人の作者のアドレス… 26承認… 26 完全な著作権宣言文… 27
Carpenter & Brim Informational [Page 2] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[2ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
1. Introduction and Goals
1. 序論と目標
1.1. Terminology
1.1. 用語
The phrase "middlebox" was coined by Lixia Zhang as a graphic description of a recent phenomenon in the Internet. A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host.
句の"middlebox"はインターネットの最近の現象の生々しい描写としてLixiaチャンによって鋳造されました。 middleboxは送信元ホストとあて先ホストの間のデータグラム経路でIPルータの正常で、標準の機能以外のどんな媒介装置実行機能とも定義されます。
In some discussions, especially those concentrating on HTTP traffic, the word "intermediary" is used. For the present document, we prefer the more graphic phrase. Of course, a middlebox can be virtual, i.e., an embedded function of some other box. It should not be interpreted as necessarily referring to a separate physical box. It may be a device that terminates one IP packet flow and originates another, or a device that transforms or diverts an IP packet flow in some way, or a combination. In any case it is never the ultimate end-system of an applications session.
いくつかの議論、特にHTTP交通に集中するものでは、「仲介者」という言葉は使用されています。 現在のドキュメントに関しては、私たちは、よりグラフィックの句を好みます。 もちろん、middleboxがそうであることができる、仮想である、すなわち、ある他の箱の埋め込まれた機能。 必ず別々の物理的な箱について言及しながら、それを解釈するべきではありません。 何らかの道、または組み合わせにおけるIPパケット流動を変えるか、または紛らすのが、1つのIPパケット流動を終えて、別のもの、または装置を溯源する装置であるかもしれません。 どのような場合でも、それは決してアプリケーションセッションの究極のエンドシステムではありません。
Normal, standard IP routing functions (i.e., the route discovery and selection functions described in [RFC 1812], and their equivalent for IPv6) are not considered to be middlebox functions; a standard IP router is essentially transparent to IP packets. Other functions taking place within the IP layer may be considered to be middlebox functions, but functions below the IP layer are excluded from the definition.
正常で、標準のIP経路選択機能(すなわち、IPv6のために[RFC1812]、およびそれらの同等物で説明されたルート発見と選択機能)はmiddlebox機能であると考えられません。 標準のIPルータは本質的にはIPパケットに透明です。 IP層の中で行われる他の機能はmiddlebox機能であると考えられるかもしれませんが、IP層の下における機能は定義から除かれます。
There is some discrepancy in the way the word "routing" is used in the community. Some people use it in the narrow, traditional sense of path selection based on IP address, i.e., the decision-making action of an IP router. Others use it in the sense of higher layer decision-making (based perhaps on a URL or other applications layer string). In either case it implies a choice of outbound direction, not the mere forwarding of a packet in the only direction available. In this document, the traditional sense is always qualified as "IP routing."
何らかの食い違いが「ルーティング」という言葉が共同体で使用される方法であります。 人々の中にはIPアドレス(すなわち、IPルータの意志決定の動作)に基づく経路選択の狭くて、伝統的な意味でそれを使用する人もいます。 他のものは、より高い層の意志決定の意味でそれを使用します(恐らくURLに基づくか他のアプリケーションはストリングを層にします)。 どちらの場合ではも、それはパケットの単なる推進ではなく、外国行きの指示の一方向のみに利用可能な選択を含意します。 本書では、伝統的な感覚は「IPルーティング」としていつも資格があります。
1.2. The Hourglass Model, Past and Future
1.2. 砂時計モデル、過去、および未来
The classical description of the Internet architecture is based around the hourglass model [HOURG] and the end-to-end principle [Clark88, Saltzer]. The hourglass model depicts the protocol architecture as a narrow-necked hourglass, with all upper layers riding over a single IP protocol, which itself rides over a variety of hardware layers.
インターネット構造の古典的な記述は砂時計モデル[HOURG]と終わりから終わりへの原則[Clark88、Saltzer]の周りに基づいています。 砂時計モデルは狭い首をした砂時計としてプロトコル構造について表現します、すべての上側の層がただ一つのIPプロトコルを通り過ぎていて。(プロトコル自体はさまざまなハードウェア層を通り過ぎます)。
Carpenter & Brim Informational [Page 3] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[3ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
The end-to-end principle asserts that some functions (such as security and reliability) can only be implemented completely and correctly end-to-end, with the help of the end points. The end-to- end principle notes that providing an incomplete version of such functions in the network itself can sometimes be useful as a performance enhancement, but not as a substitute for the end-to-end implementation of the function. The references above, and [RFC 1958], go into more detail.
終わりから終わりへの原則は、いくつかの機能(セキュリティや信頼性などの)が実行された終わるために終わりの助けで完全に正しく終わっているポイントであるにすぎないかもしれないと断言します。 終わりから終わりへの原則は、そのような機能の不完全なバージョンをネットワーク自体に提供するのがパフォーマンス強化として時々役に立ちますが、終わりから終わりへの機能の実現の代用品として役に立つことができないことに注意します。 上記の参照、および[RFC1958]はその他の詳細に入ります。
In this architecture, the only boxes in the neck of the hourglass are IP routers, and their only function is to determine routes and forward packets (while also updating fields necessary for the forwarding process). This is why they are not classed as middleboxes.
この構造では、砂時計の首における唯一の箱がIPルータです、そして、それらの唯一の機能はルートと前進のパケットを決定する(また、推進の過程に必要な分野をアップデートしている間)ことです。 これはそれらがmiddleboxesとして分類されない理由です。
Today, we observe deviations from this model, caused by the insertion in the network of numerous middleboxes performing functions other than IP forwarding. Viewed in one way, these boxes are a challenge to the transparency of the network layer [RFC 2775]. Viewed another way, they are a challenge to the hourglass model: although the IP layer does not go away, middleboxes dilute its significance as the single necessary feature of all communications sessions. Instead of concentrating diversity and function at the end systems, they spread diversity and function throughout the network.
今日、私たちはIP推進以外の多数のmiddleboxes実行機能のネットワークへの挿入で引き起こされたこのモデルからの逸脱を観測します。 ある意味では見られて、これらの箱はネットワーク層[RFC2775]の透明への挑戦です。 別の方法で見られて、それらは砂時計モデルへの挑戦です: IP層は遠ざかりませんが、middleboxesはすべてのコミュニケーションセッションのただ一つの必要な特徴として意味を希釈します。 エンドシステムに多様性と機能を集結することの代わりに、それらは、多様性を広げて、ネットワーク中で機能します。
This is a matter of concern for several reasons:
これはいくつかの理由で重要な問題です:
* New middleboxes challenge old protocols. Protocols designed
without consideration of middleboxes may fail, predictably or
unpredictably, in the presence of middleboxes.
* 新しいmiddleboxesは古いプロトコルに挑戦します。 無償でmiddleboxesについて設計されたプロトコルはmiddleboxesがあるとき予想どおりにか予想外に失敗するかもしれません。
* Middleboxes introduce new failure modes; rerouting of IP packets
around crashed routers is no longer the only case to consider.
The fate of sessions involving crashed middleboxes must also be
considered.
* Middleboxesは新しい故障モードを導入します。 墜落しているルータの周りのIPパケットについてコースを変更するのはもう考える唯一のケースではありません。 また、墜落しているmiddleboxesにかかわるセッションの運命を考えなければなりません。
* Configuration is no longer limited to the two ends of a session;
middleboxes may also require configuration and management.
* 構成はもうセッションの2つの終わりまで制限されません。 また、middleboxesは構成と管理を必要とするかもしれません。
* Diagnosis of failures and misconfigurations is more complex.
* 失敗とmisconfigurationsの診断は、より複雑です。
1.4. Goals of this Document
1.4. このDocumentの目標
The principle goal of this document is to describe and analyse the current impact of middleboxes on the architecture of the Internet and its applications. From this, we attempt to identify some general conclusions.
このドキュメントの原則目標は、インターネットとそのアプリケーションの構造でmiddleboxesの現在の衝撃を説明して、分析することです。 これから、私たちは、いくつかの一般的な結論を特定するのを試みます。
Carpenter & Brim Informational [Page 4] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[4ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
Goals that might follow on from this work are:
それがこの仕事から続くかもしれない目標は以下の通りです。
* to identify harmful and harmless practices,
* 有害で無害な習慣を特定するために
* to suggest architectural guidelines for application protocol and
middlebox design,
* アプリケーション・プロトコルとmiddleboxデザインのための建築ガイドラインを示すために
* to identify requirements and dependencies for common functions in
the middlebox environment,
* middlebox環境における一般的な機能のために要件と依存を特定するために
* to derive a system design for standardisation of these functions,
* これらの規格化のためのシステム設計を引き出すのは機能します。
* to identify additional work that should be done in the IETF and
IRTF.
* 追加仕事を特定するために、IETFとIRTFでそれをするべきです。
An implied goal is to identify any necessary updates to the Architectural Principles of the Internet [RFC 1958].
暗示している目標はインターネット[RFC1958]のArchitecturalプリンシプルズにどんな必要なアップデートも特定することです。
The document initially establishes a catalogue of middleboxes, and cites previous or current IETF work concerning middleboxes, before proceeding to discussion and conclusions.
ドキュメントは、初めはmiddleboxesに関するカタログを確立して、middleboxesに関して前の、または、現在のIETF仕事を引用します、議論と結論に続く前に。
2. A catalogue of middleboxes
2. middleboxesに関するカタログ
The core of this document is a catalogue of a number of types of middlebox. There is no obvious way of classifying them to form a hierarchy or other simple form of taxonomy. Middleboxes have a number of facets that might be used to classify them in a multidimensional taxonomy.
このドキュメントのコアはmiddleboxの多くのタイプに関するカタログです。 階層構造か他の単純形の分類学を形成するそれらを分類する当たり前の方法が全くありません。 Middleboxesには、多次元の分類学でそれらを分類するのに使用されるかもしれない多くの一面があります。
DISCLAIMER: These facets, many of distinctions between different types of middlebox, and the decision to include or exclude a particular type of device, are to some extent subjective. Not everyone who commented on drafts of this document agrees with our classifications and descriptions. We do not claim that the following catalogue is mathematically complete and consistent, and in some cases purely arbitrary choices have been made, or ambiguity remains. Thus, this document makes no claim to be definitive.
注意書き: これらの一面(middleboxの異なったタイプと、特定のタイプの装置を含んでいるか、または除くという決定の区別の多く)はある程度主観的です。 このドキュメントの草稿を批評したというわけではない皆が私たちの分類と記述に同意します。 私たちは、以下のカタログが数学的に完全であって、一貫していると主張しません、そして、いくつかの場合、純粋に任意の選択をしたか、またはあいまいさは残っています。 したがって、このドキュメントは、決定的になるようにノークレームをします。
The facets considered are:
考えられた一面は以下の通りです。
1. Protocol layer. Does the box act at the IP layer, the transport
layer, the upper layers, or a mixture?
1. 層について議定書の中で述べてください。 箱はIP層、トランスポート層、上側の層、または混合物で作用しますか?
2. Explicit versus implicit. Is the middlebox function an explicit
design feature of the protocol(s) in use, like an SMTP relay? Or
is it an add-on not foreseen by the protocol design, probably
attempting to be invisible, like a network address translator?
2. 暗黙に対して明白です。 middlebox機能はSMTPリレーのように使用中のプロトコルの明白な設計上の特徴ですか? または、それはたぶんネットワークアドレス変換機構のように目に見えないのを試みて、プロトコルデザインによって見通されなかった付加物ですか?
Carpenter & Brim Informational [Page 5] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[5ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
3. Single hop versus multi-hop. Can there be only one box in the
path, or can there be several?
3. 単一のホップ対マルチホップ 1個の箱しか経路にあることができませんか、または数個があることができますか?
4. In-line versus call-out. The middlebox function may be executed
in-line on the datapath, or it may involve a call-out to an
ancillary box.
4. 外に呼ぶことに対してインラインです。 middlebox機能がdatapathでインラインで実行されるかもしれませんか、またはそれは、外に付属の箱に呼ぶことを伴うかもしれません。
5. Functional versus optimising. Does the box perform a function
without which the application session cannot run, or is the
function only an optimisation?
5. 最適化に対して機能的です。 箱が機能をアプリケーションセッションが行われることができない実行しますか、または唯一の機能は最適化ですか?
6. Routing versus processing. Does the box simply choose which way
to send the packets of a session, or does it actually process them
in some way (i.e., change them or create a side-effect)?
6. 処理に対して掘ります。 箱が単にセッションのパケットを送るどの方法を選ぶか、そして、またはそれは実際に何らかの方法でそれらを処理しますか?(すなわち、それらを変えるか、または副作用を引き起こしてください)
7. Soft state versus hard state. If the box loses its state
information, does the session continue to run in a degraded mode
while reconstructing necessary state (soft state), or does it
simply fail (hard state)?
7. 軟性国家対固い状態 箱が州の情報を失うなら、セッションが、必要な状態(軟性国家)を再建している間、降格しているモードに立候補し続けていますか、またはそれは単に(固い状態)に失敗しますか?
8. Failover versus restart. In the event that a hard state box
fails, is the session redirected to an alternative box that has a
copy of the state information, or is it forced to abort and
restart?
8. フェイルオーバー対再開 固い州の箱が失敗する場合、セッションが州の情報のコピーを持っている代替の箱に向け直されますか、またはそれは中止になって、再開するのが強制されますか?
One possible classification is deliberately excluded: "good" versus "evil". While analysis shows that some types of middlebox come with a host of complications and disadvantages, no useful purpose would be served by simply deprecating them. They have been invented for compelling reasons, and it is instructive to understand those reasons.
1つの可能な分類が故意に除かれます: 「悪」に対する「いいぞ。」 分析が、middleboxの何人かのタイプが多くの複雑さと損失と共に来るのを示している間、単にそれらを非難することによって、どんな役に立つ目的も役立たれないでしょう。 やむにやまれない理由によってそれらを発明してあります、そして、それらの理由を理解しているのはためになっています。
The types of box listed below are in an arbitrary order, although adjacent entries may have some affinity. At the end of each entry is an attempt to characterise it in terms of the facets identified above. These characterisations should not be interpreted as rigid; in many cases they are a gross simplification.
隣接しているエントリーには、何らかの親近感があるかもしれませんが、以下に記載された箱のタイプが任意のオーダーにあります。 それぞれの終わりに、エントリーは上で特定された一面に関してそれを特徴付ける試みです。 堅いとこれらの特殊化を解釈するべきではありません。 多くの場合、それらは総計の簡素化です。
Note: many types of middlebox may need to perform IP packet fragmentation and re-assembly. This is mentioned only in certain cases.
以下に注意してください。 middleboxの多くのタイプが、IPパケット断片化と再アセンブリを実行する必要があるかもしれません。 ある場合にはだけ、これは言及されます。
2.1 NAT
2.1 NAT
Network Address Translator. A function, often built into a router, that dynamically assigns a globally unique address to a host that doesn't have one, without that host's knowledge. As a result, the appropriate address field in all packets to and from that host is
アドレス変換機構をネットワークでつないでください。 ダイナミックにそのホストの知識なしで1つを持っていないホストにグローバルにユニークなアドレスを割り当てるルータがしばしば組み込まれた機能。 その結果、ホストとそのホストからのすべてのパケットの適切なアドレス・フィールドはそうです。
Carpenter & Brim Informational [Page 6] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[6ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
translated on the fly. Because NAT is incompatible with application protocols with IP address dependencies, a NAT is in practice always accompanied by an ALG (Application Level Gateway - see below). It also touches the transport layer to the extent of fixing up checksums.
急いで翻訳されます。 NATがIPアドレスの依存についてアプリケーション・プロトコルと両立しないので、NATが実際にはいつもALGによって伴われたあります(アプリケーションLevelゲートウェイ--以下を見てください)。 また、それはトランスポート層にチェックサムを修理する範囲まで触れています。
NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993, RFC 3022, RFC 3027, etc.]
NATsはIETFで手広く分析されました。[RFC2663、RFC2993、RFC3022、RFC3027など]
The experimental RSIP proposal complements NAT with a dynamic tunnel mechanism inserting a stateful RSIP server in place of the NAT [RSIP].
実験的なRSIP提案は、NAT[RSIP]に代わってstateful RSIPサーバを挿入しながら、ダイナミックなトンネルメカニズムにNATを補います。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart}
1つのIP層、2、暗黙、3マルチホップ、4、インライン、5、機能的である、6処理、一生懸命、8が再開する7
2.2 NAT-PT
2.2 太平洋標準時のNAT
NAT with Protocol Translator. A function, normally built into a router, that performs NAT between an IPv6 host and an IPv4 network, additionally translating the entire IP header between IPv6 and IPv4 formats.
プロトコル翻訳者がいるNAT。 さらに、IPv6とIPv4形式の間の全体のIPヘッダーを翻訳して、IPv6ホストとIPv4ネットワークの間のNATを実行する通常、ルータが組み込まれた機能。
NAT-PT itself depends on the Stateless IP/ICMP Translation Algorithm (SIIT) mechanism [RFC 2765] for its protocol translation function. In practice, SIIT and NAT-PT will both need an associated ALG and will need to touch transport checksums. Due to the permitted absence of a UDP checksum in IPv4, translation of fragmented unchecksummed UDP from IPv4 to IPv6 is hopeless. NAT-PT and SIIT also have other potential fragmentation/MTU problems, particularly when dealing with endpoints that don't do path MTU discovery (or when transiting other middleboxes that break path MTU discovery). ICMP translation also has some intractable difficulties.
太平洋標準時のNAT自体はプロトコル変換機能のためにStateless IP/ICMP Translation Algorithm(SIIT)メカニズム[RFC2765]によります。 実際には、SIITと太平洋標準時のNATは、輸送チェックサムに触れる必要があるでしょう関連ALGが必要があって。IPv4でのUDPチェックサムの受入れられた欠如のために、断片化しているunchecksummed UDPのIPv4からIPv6までの翻訳は絶望的です。 また、特に経路MTU探索をしない終点に対処するとき(経路MTU探索を壊す他のmiddleboxesを通過するとき)、太平洋標準時のNATとSIITには他の潜在的断片化/MTU問題があります。 また、ICMP翻訳はいくつかの手に負えない苦労をします。
NAT-PT is a Proposed Standard from the NGTRANS WG [RFC 2766]. The Dual Stack Transition Mechanism adds a second related middlebox, the DSTM server [DSTM].
太平洋標準時のNATはNGTRANS WG[RFC2766]からのProposed Standardです。 Dual Stack Transition Mechanismは、1秒がmiddlebox、DSTMサーバ[DSTM]を関係づけたと言い足します。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart}
1つのIP層、2、暗黙、3マルチホップ、4、インライン、5、機能的である、6処理、一生懸命、8が再開する7
2.3 SOCKS gateway
2.3 SOCKSゲートウェイ
SOCKSv5 [RFC 1928] is a stateful mechanism for authenticated firewall traversal, in which the client host must communicate first with the SOCKS server in the firewall before it is able to traverse the firewall. It is the SOCKS server, not the client, that determines the source IP address and port number used outside the firewall. The
SOCKSv5[RFC1928]は認証されたファイアウォール縦断のためのstatefulメカニズムです。(ファイアウォールを横断できる前に、クライアントホストはそれで最初にSOCKSサーバとファイアウォールでコミュニケートしなければなりません)。 それはクライアントではなく、アドレスとポートナンバーがファイアウォールの外で使用したソースIPを決定するSOCKSサーバです。 The
Carpenter & Brim Informational [Page 7] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[7ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
client's stack must be "SOCKSified" to take account of this, and address-sensitive applications may get confused, rather as with NAT. However, SOCKS gateways do not require ALGs.
クライアントのスタックはこれを考慮に入れるためには"SOCKSified"でなければなりません、そして、アドレス敏感なアプリケーションはむしろNATなら面食らうかもしれません。 しかしながら、SOCKSゲートウェイはALGsを必要としません。
SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.
SOCKSはAFT(Firewall Traversalを認証する)WGによって維持されます。
{1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6
routing, 7 hard, 8 restart}
1つのマルチ層、2、明白である、3マルチホップ、4、インライン、5、機能的である、6が掘られる一生懸命、8が再開する7
2.4 IP Tunnel Endpoints
2.4 IPトンネル終点
Tunnel endpoints, including virtual private network endpoints, use basic IP services to set up tunnels with their peer tunnel endpoints which might be anywhere in the Internet. Tunnels create entirely new "virtual" networks and network interfaces based on the Internet infrastructure, and thereby open up a number of new services. Tunnel endpoints base their forwarding decisions at least partly on their own policies, and only partly if at all on information visible to surrounding routers.
仮想私設網終点を含むトンネル終点は、インターネットでどこでもあるかもしれないそれらの同輩トンネル終点があるトンネルを設立するのに基本的なIPサービスを利用します。 トンネルはインターネット基盤に基づいて、その結果、多くの新種業務に開かれていた状態で完全に新しい「仮想」のネットワークとネットワーク・インターフェースを創設します。 トンネル終点は、周囲のルータに目に見える情報でそれら自身の方針に、一部だけせいぜい決定を少なくとも一部進めるのを基礎づけます。
To the extent that they deliver packets intact to their destinations, tunnel endpoints appear to follow the end-to-end principle in the outer Internet. However, the destination may be completely different from what a router near the tunnel entrance might expect. Also, the per-hop treatment a tunneled packet receives, for example in terms of QoS, may not be what it would have received had the packet traveled untunneled [RFC2983].
彼らがそれらの目的地に完全なパケットを届けるという範囲まで、トンネル終点は外側のインターネットで終わりから終わりへの原則に従うように見えます。 しかしながら、目的地はトンネル入り口の近くのルータが予想するかもしれないことと完全に異なっているかもしれません。 また、トンネルを堀られたパケットが例えば、QoSに関して受ける1ホップあたりの処理は旅行されたパケットが「非-トンネル」であったならそれが受けたものでないかもしれません[RFC2983]。
Tunnels also cause difficulties with MTU size (they reduce it) and with ICMP replies (they may lack necessary diagnostic information).
また、トンネルはMTUサイズ(それらはそれを減少させる)とICMP回答における困難を引き起こします(それらは必要な診断情報を欠くかもしれません)。
When a tunnel fails for some reason, this may cause the user session to abort, or an alternative IP route may prove to be available, or in some cases the tunnel may be re-established automatically.
いくつかの場合、トンネルがある理由で失敗すると、ユーザセッションがこれで中止になるかもしれませんか、代替のIPルートが利用可能であると判明するかもしれませんか、またはトンネルは自動的に復職するかもしれません。
{1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart or failover}
8の7つの困難なフェイルオーバー、5つの機能的なフェイルオーバー、4つのインラインフェイルオーバー、2つの暗黙のフェイルオーバー、1つのマルチ層、3マルチホップ、6処理、再開またはフェイルオーバー
2.5. Packet classifiers, markers and schedulers
2.5. パケットクラシファイア、マーカー、およびスケジューラ
Packet classifiers classify packets flowing through them according to policy and either select them for special treatment or mark them, in particular for differentiated services [Clark95, RFC 2475]. They may alter the sequence of packet flow through subsequent hops, since they control the behaviour of traffic conditioners.
パケットクラシファイアは、方針によると、それらを通して流れるパケットを分類して、特別な処理のためにそれらを選択するか、またはそれらをマークします、特に微分されたサービス[Clark95、RFC2475]のために。 交通コンディショナーのふるまいを制御するので、彼らはその後のホップを通したパケット流動の系列を変更するかもしれません。
Carpenter & Brim Informational [Page 8] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[8ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
Schedulers or traffic conditioners (in routers, hosts, or specialist boxes inserted in the data path) may alter the time sequence of packet flow, the order in which packets are sent, and which packets are dropped. This can significantly impact end-to-end performance. It does not, however, fundamentally change the unreliable datagram model of the Internet.
スケジューラか交通コンディショナー(データ経路に挿入されたルータ、ホスト、または専門家箱の中の)がどのパケットを送るか、そして、どのパケットを落とすかでパケット流動、オーダーの時間系列を変更するかもしれません。 これは終わりから終わりへの性能にかなり影響を与えることができます。 しかしながら、それは基本的にインターネットの頼り無いデータグラムモデルを変えません。
When a classifier or traffic conditioner fails, the user session may see any result between complete loss of connectivity (all packets are dropped), through best-effort service (all packets are given default QOS), up to automatic restoration of the original service level.
クラシファイアか交通コンディショナーが失敗すると、ユーザセッションは接続性の全損の間のどんな結果も見るかもしれません(すべてのパケットが落とされます)、ベストエフォート型サービスで(デフォルトQOSをすべてのパケットに与えます)、元のサービスレベルの自動回復まで。
{1 multi-layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6
processing, 7 soft, 8 failover or restart}
8の7つの柔らかい再開、4つのインライン再開、2つの暗黙の再開、1つのマルチ層、3マルチホップ、5最適化、6処理、フェイルオーバーまたは再開
2.6 Transport relay
2.6 輸送リレー
Transport relays are basically the transport layer equivalent of an ALG; another (less common) name for them is a TLG. As with ALGs, they're used for a variety of purposes, some well established and meeting needs not otherwise met. Early examples of transport relays were those that ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET and allowed Chaosnet-only hosts to make outgoing connections from Chaosnet onto TCP/IP. Later there were some uses of TCP-TP4 relays. A transport relay between IPv6-only and IPv4-only hosts is one of the tools of IPv6 transition [TRANS64]. TLGs are sometimes used in combination with simple packet filtering firewalls to enforce restrictions on which hosts can talk to the outside world or to kludge around strange IP routing configurations. TLGs are also sometimes used to gateway between two instances of the same transport protocol with significantly different connection characteristics; it is in this sense that a TLG may also be called a TCP or transport spoofer. In this role, the TLG may shade into being an optimising rather than a functional middlebox, but it is distinguished from Transport Proxies (next section) by the fact that it makes its optimisations only by creating back-to- back connections, and not by modification or re-timing of TCP messages.
輸送リレーは基本的にALGのトランスポート層同等物です。 それらのための別の(それほど一般的でない)の名前はTLGです。 彼らがさまざまな目的にALGsと共に使用されるので、そうでなければ、いくつかの確固としていて会っている需要は満たされませんでした。 輸送リレーの早めの例はアルパネットでMITのITSとTOPS-20 PDP10-年代の上で作業して、Chaosnetだけホストが外向的な接続をChaosnetからTCP/IPにするのを許容したものでした。 その後、TCP-TP4リレーのいくつかの用途がありました。 IPv6だけとIPv4だけホストの間の輸送リレーはIPv6変遷[TRANS64]のツールの1つです。 TLGsは、簡単なパケットフィルタリングファイアウォールと組み合わせてホストが奇妙なIPルーティング設定の周りで外の世界、または、クラッジと話すことができる制限を実施するのに時々使用されます。 また、TLGsは時々かなり異なった接続の特性で同じトランスポート・プロトコルの2つの例の間のゲートウェイに使用されます。 また、この意味で、TLGがTCPか輸送spooferと呼ばれるかもしれないということです。 この役割では、TLGは機能的なmiddleboxよりむしろ最適化に陰影をつけるかもしれませんが、単に後部から戻っている接続を創造することによって最適化をするという事実によってそれはTCPメッセージの変更か再タイミングによって区別されるのではなく、Transport Proxies(次のセクション)と区別されます。
Terminating one TCP connection and starting another mid-path means that the TCP checksum does not cover the sender's data end-to-end. Data corruptions or modifications may be introduced in the processing when the data is transferred from the first to the second connection. Some TCP relays are split relays and have even more possibility of lost data integrity, because the there may be more than two TCP connections, and multiple nodes and network paths involved. In all cases, the sender has less than the expected assurance of data integrity that is the TCP reliable byte stream service. Note that
1つのTCP接続を終えて、別の中間の経路を始めるのは、TCPチェックサムが送付者のデータの終わりから終わりをカバーしないことを意味します。 1日から2番目の接続までデータを移すとき、処理でデータ贈収賄か変更を導入するかもしれません。 いくつかのTCPリレーが分裂リレーであり、ロストデータ保全のさらに多くの可能性を持っている、経路がかかわった2つ以上のTCP接続、複数のノード、およびネットワークがあるかもしれません。 すべての場合では、送付者はTCPの信頼できるバイト・ストリームサービスであるデータ保全の予想された保証以下を持っています。 それに注意してください。
Carpenter & Brim Informational [Page 9] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[9ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
this problem is not unique to middleboxes, but can also be caused by checksum offloading TCP implementations within the sender, for example.
また、例えば、送付者の中でTCP実現を積み下ろすチェックサムによって引き起こされる場合がある以外に、この問題はmiddleboxesにユニークではありません。
In some such cases, other session layer mechanisms such as SSH or HTTPS would detect any loss of data integrity at the TCP level, leading not to retransmission as with TCP, but to session failure. However, there is no general session mechanism to add application data integrity so one can detect or mitigate possible lack of TCP data integrity.
そのようないくつかの場合では、SSHかHTTPSなどの他のセッション層メカニズムはTCPレベルでどんなデータの喪失保全も検出するでしょう、TCPにもかかわらず、セッション失敗へのどんな「再-トランスミッション」にも導かないで。 しかしながら、1つがTCPデータ保全の可能な不足を検出するか、または緩和できるようにアプリケーションデータ保全を加えるために、どんな一般的なセッションメカニズムもありません。
{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 functional
(mainly), 6 routing, 7 hard, 8 restart}
1個のトランスポート層、2、暗黙、3マルチホップ、4、インライン、5、機能的である、(主に)6が掘られる一生懸命、8が再開する7
2.7. TCP performance enhancing proxies
2.7. プロキシを高めるTCP性能
"TCP spoofer" is often used as a term for middleboxes that modify the timing or action of the TCP protocol in flight for the purposes of enhancing performance. Another, more accurate name is TCP performance enhancing proxy (PEP). Many TCP PEPs are proprietary and have been characterised in the open Internet primarily when they introduce interoperability errors with standard TCP. As with TLGs, there are circumstances in which a TCP PEP is seen to meet needs not otherwise met. For example, a TCP PEP may provide re-spacing of ACKs that have been bunched together by a link with bursty service, thus avoiding undesireable data segment bursts. The PILC (Performance Implications of Link Characteristics) working group has analyzed types of TCP PEPs and their applicability [PILCPEP]. TCP PEPs can introduce not only TCP errors, but also unintended changes in TCP adaptive behavior.
"TCP spoofer"は性能を高める目的へのフライトにおける、TCPプロトコルのタイミングか動作を変更するmiddleboxesに用語としてしばしば使用されます。 別のもの、より正確な名前はプロキシ(PEP)を高めるTCP性能です。 多くのTCP PEPsが独占であり、主として彼らが標準のTCPとの相互運用性誤りを導入するとき、開いているインターネットで特徴付けられました。 TLGsのように、TCP PEPが別の方法で満たされなかった需要を満たすのを見られる事情があります。 例えば、TCP PEPはburstyサービスとのリンクによって一緒に束ねられたACKsの再スペースを提供するかもしれません、その結果、「非-望-可能」データ・セグメント炸裂を避けます。 PILC(Link CharacteristicsのパフォーマンスImplications)ワーキンググループはTCP PEPsのタイプと彼らの適用性[PILCPEP]を分析しました。 TCP PEPsはTCP適応行動でTCP誤りだけではなく、故意でない変化も導入できます。
{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising,
6 routing, 7 hard, 8 restart}
1個のトランスポート層、2、暗黙、3マルチホップ、4、インラインであり、一生懸命6が掘られる7を最適化する5、8は再開します。
2.8. Load balancers that divert/munge packets.
2.8. /mungeパケットを紛らす負荷分散装置。
There is a variety of techniques that divert packets from their intended IP destination, or make that destination ambiguous. The motivation is typically to balance load across servers, or even to split applications across servers by IP routing based on the destination port number. Except for rare instances of one-shot UDP protocols, these techniques are inevitably stateful as all packets from the same application session need to be directed to the same physical server. (However, a sophisticated solution would also be able to handle failover.)
それらの意図しているIPの目的地からパケットを紛らすか、またはその目的地をあいまいにするさまざまなテクニックがあります。 通常、サーバの向こう側のバランス負荷、または、目的地ポートナンバーに基づくIPルーティングによるサーバの向こう側の分施にさえ動機があります。 1回限りのUDPプロトコルのまれな例を除いて、同じアプリケーションセッションからのすべてのパケットが、同じ物理的なサーバに向けられる必要があるとき、これらのテクニックは必然的にstatefulです。(しかしながら、また、精巧な解決策はフェイルオーバーを扱うことができるでしょう。)
To date these techniques are proprietary and can therefore only be applied in closely managed environments.
これまで、これらのテクニックは、独占であり、したがって、密接に管理された環境で適用できるだけです。
Carpenter & Brim Informational [Page 10] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[10ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
{1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6
routing, 7 hard, 8 restart}
1つのマルチ層、2、暗黙であり、5が一生懸命6が掘られる7を最適化して、3はインラインでホップ、4人を選抜して、8は再開します。
2.9. IP Firewalls
2.9. IPファイアウォール
The simplest form of firewall is a router that screens and rejects packets based purely on fields in the IP and Transport headers (e.g., disallow incoming traffic to certain port numbers, disallow any traffic to certain subnets, etc.)
最も簡単な形式のファイアウォールはIPで純粋に分野に基づくパケットとTransportヘッダーをスクリーニングして、拒絶するルータです。(例えば、あるポートナンバーへの入って来る交通を禁じてください、そして、あるサブネットなどへのあらゆる交通を禁じてください)
Although firewalls have not been the subject of standardisation, some analysis has been done [RFC 2979].
ファイアウォールは規格化の対象ではありませんが、[RFC2979]を何らかの分析にしました。
Although a pure IP firewall does not alter the packets flowing through it, by rejecting some of them it may cause connectivity problems that are very hard for a user to understand and diagnose.
純粋なIPファイアウォールはそれを通して流れるパケットを変更しませんが、それらのいくつかを拒絶することによって、それはユーザが理解している、非常に診断しにくい接続性問題を引き起こすかもしれません。
"Stateless" firewalls typically allow all IP fragments through since they do not contain enough upper-layer header information to make a filtering decision. Many "stateful" firewalls therefore reassemble IP fragments (and re-fragment if necessary) in order to avoid leaking fragments, particularly fragments that may exploit bugs in the reassembly implementations of end receivers.
フィルタリング決定をすることができるくらいの上側の層のヘッダー情報を含んでいないので、「状態がない」ファイアウォールは通常すべてのIP断片の通ることを許します。 したがって、多くの"stateful"ファイアウォールが、断片(特に終わりの受信機の再アセンブリ実装でバグを利用するかもしれない断片)を漏らすのを避けるために、IP断片(必要なら、再断片化する)を組み立て直します。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
routing, 7 hard, 8 restart}
1つのIP層、2、暗黙、3マルチホップ、4、インライン、5、機能的である、6が掘られる一生懸命、8が再開する7
2.10. Application Firewalls
2.10. アプリケーションファイアウォール
Application-level firewalls act as a protocol end point and relay (e.g., an SMTP client/server or a Web proxy agent). They may
アプリケーションレベルファイアウォールはプロトコルエンドポイントとリレー(例えば、SMTPクライアント/サーバかウェブプロキシエージェント)として作動します。 それらはそうするかもしれません。
(1) implement a "safe" subset of the protocol,
(1) プロトコルの「安全な」部分集合を実装してください。
(2) perform extensive protocol validity checks,
(2) 大規模なプロトコルバリディティチェックを実行してください。
(3) use an implementation methodology designed to minimize the
likelihood of bugs,
(3) バグの見込みを最小にするように設計された実装方法論を使用してください。
(4) run in an insulated, "safe" environment, or
または(4) 絶縁されて、「安全な」環境に立候補してください。
(5) use some combination of these techniques in tandem.
(5) 2人乗り自転車のこれらのテクニックの何らかの組み合わせを使用してください。
Although firewalls have not been the subject of standardisation, some analysis has been done [RFC 2979]. The issue of firewall traversal using HTTP has been discussed [HTTPSUB].
ファイアウォールは規格化の対象ではありませんが、[RFC2979]を何らかの分析にしました。 HTTPを使用するファイアウォール縦断の問題について議論しました[HTTPSUB]。
Carpenter & Brim Informational [Page 11] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[11ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
{1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5
functional, 6 processing, 7 hard, 8 restart}
1個の応用層、2、暗黙、3マルチホップ、4、インライン、5、機能的である、6処理、一生懸命、8が再開する7
2.11. Application-level gateways
2.11. アプリケーションレベルゲートウェイ
These come in many shapes and forms. NATs require ALGs for certain address-dependent protocols such as FTP; these do not change the semantics of the application protocol, but carry out mechanical substitution of fields. At the other end of the scale, still using FTP as an example, gateways have been constructed between FTP and other file transfer protocols such as the OSI and DECnet (R) equivalents. In any case, such gateways need to maintain state for the sessions they are handling, and if this state is lost, the session will normally break irrevocably.
これらは多くの形とフォームに入ります。NATsはFTPなどのあるアドレス依存するプロトコルのためにALGsを必要とします。 これらはアプリケーション・プロトコルの意味論を変えませんが、分野の機械的な代替を行ってください。 スケールのもう一方の端では、例としてまだFTPを使用していて、ゲートウェイはOSIやDECnet(R)同等物などのFTPの、そして、他のファイル転送プロトコルの間に建築されました。 どのような場合でも、そのようなゲートウェイは、それらが扱っているセッションのために状態を維持する必要があります、そして、この状態が無くなると、通常、セッションは取消不能に壊れるでしょう。
Some ALGs are also implemented in ways that create fragmentation problems, although in this case the problem is arguably the result of a deliberate layer violation (e.g., mucking with the application data stream of an FTP control connection by twiddling TCP segments on the fly).
また、いくつかのALGsが断片化問題を生じさせる方法で実装されます、この場合問題は論証上慎重な層の違反(例えば、震えるのによるFTPコントロール接続のアプリケーションデータストリームで、急いでTCPセグメントに肥料を施す)の結果ですが。
{1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line,
5 functional, 6 processing, 7 hard, 8 restart}
1個の応用層、2、暗黙か明白である、3マルチホップ、4、インライン、5、機能的である、6処理、一生懸命、8が再開する7
2.12. Gatekeepers/ session control boxes
2.12. 門番/セッションコントロールボックス
Particularly with the rise of IP Telephony, the need to create and manage sessions other than TCP connections has arisen. In a multimedia environment that has to deal with name lookup, authentication, authorization, accounting, firewall traversal, and sometimes media conversion, the establishment and control of a session by a third-party box seems to be the inevitable solution. Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and MEGACO controllers [RFC 3015].
特にIP Telephonyの上昇で、TCP接続以外のセッションを作成して、管理する必要性は起こりました。 名前ルックアップ、認証、承認、会計、ファイアウォール縦断、および時々メディア変換に対処しなければならないマルチメディア環境で、第三者箱によるセッションの設立とコントロールは必然のソリューションであるように思えます。 例はH.323門番[H323]、SIPサーバ[RFC2543]、およびMEGACOコントローラ[RFC3015]を含んでいます。
{1 Application layer, 2 explicit, 3 multihop, 4 in-line or call-out,
5 functional, 6 processing, 7 hard, 8 restart?}
1個の応用層、2、明白である、3マルチホップ、4 インラインか大声で叫ぶ、5、機能的である、6が処理される一生懸命、8が再開する7--
2.13. Transcoders
2.13. トランスコーダ
Transcoders are boxes performing some type of on-the-fly conversion of application level data. Examples include the transcoding of existing web pages for display on hand-held wireless devices, and transcoding between various audio formats for interconnecting digital mobile phones with voice-over-IP services. In many cases, such transcoding cannot be done by the end-systems, and at least in the case of voice, it must be done in strict real time with extremely rapid failure recovery.
トランスコーダはタイプのアプリケーションレベルデータの飛行中の変換を実行する箱です。 例はディスプレイのための携帯用ワイヤレス機器の上の既存のウェブページ、およびナレーターの声IPサービスでデジタル携帯電話とインタコネクトするための様々なオーディオ形式の間のコード変換のコード変換を含んでいます。 多くの場合、エンドシステムでそのようなコード変換ができません、そして、少なくとも声の場合では、厳しいリアルタイムで非常に急速な失敗回復でそれをしなければなりません。
Carpenter & Brim Informational [Page 12] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[12ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
Not all media translators are mandatory. They may simply be an optimisation. For example, in the case of multicast, if all the low-bandwidth receivers sit in one "corner" of the network, it would be inefficient for the sender to generate two streams or send both stream all the way across the network if the "thin" one is only needed far away from the sender. Generally, media translators are only useful if the two end systems don't have overlapping codecs or if the overlapping set is not a good network match.
すべてのメディア翻訳者がどんな義務的であるというわけではありません。 それらは単に最適化であるかもしれません。 例えば、マルチキャストの場合では、すべての低バンド幅受信機がネットワークの1「角」にあるなら、「薄い」ものが送付者から遠くに必要であるだけであるなら、送付者がネットワークの向こう側のいっぱいに2つのストリームを生成するか、またはストリームを両方に送るのが、効率が悪いでしょう。 一般に、メディア翻訳者は2台のエンドシステムでは重なっているコーデックがないか、重なっているセットが良いネットワークマッチでない場合にだけ役に立ちます。
{1 Application layer, 2 explicit or implicit, 3 single hop, 4 in-
line, 5 functional, 6 processing, 7 hard?, 8 restart or failover}
1 応用層、2 明白であるか、または暗黙です、3は機能的にホップ、4コネ系列、5人を選抜します、6処理、7 困難であるか、8の再開かフェイルオーバー
2.14. Proxies
2.14. プロキシ
HTTP1.1 [RFC 2616] defines a Web proxy as follows:
HTTP1.1[RFC2616]は以下のウェブプロキシを定義します:
"An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy MUST implement
both the client and server requirements of this specification. A
"transparent proxy" is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification. A "non-transparent proxy" is a proxy that
modifies the request or response in order to provide some added
service to the user agent, such as group annotation services,
media type transformation, protocol reduction, or anonymity
filtering."
「作成の目的のためのサーバとクライアントの両方として作動する仲介者プログラムは他を代表してクライアントを要求します。」 要求は、内部的か可能な翻訳で他のサーバにそれらを伝えることによって、修理されます。 プロキシは、両方がこの仕様のクライアントとサーバ要件であると実装しなければなりません。 「透明なプロキシ」はプロキシ認証と識別に必要であることで要求か応答を変更しないプロキシです。 「「非透過のプロキシ」はユーザエージェントに対する何らかの加えられたサービスを提供するように要求か応答を変更するプロキシです、グループ注釈サービスなどのようにメディアは変換、プロトコル減少、または匿名フィルタリングをタイプします。」
A Web proxy may be associated with a firewall, when the firewall does not allow outgoing HTTP packets. However, HTTP makes the use of a proxy "voluntary": the client must be configured to use the proxy.
ファイアウォールが出発しているHTTPパケットを許容しないとき、ウェブプロキシはファイアウォールに関連しているかもしれません。 しかしながら、HTTPはプロキシの使用を「自発的に」します: プロキシを使用するためにクライアントを構成しなければなりません。
Note that HTTP proxies do in fact terminate an IP packet flow and recreate another one, but they fall under the definition of "middlebox" given in Section 1.1 because the actual applications sessions traverse them.
HTTPプロキシが事実上、IPパケット流動を終えて、別の1つを休養させますが、彼らが本番適用セッションがそれらを横断するのでセクション1.1で与えられた"middlebox"の定義で低下することに注意してください。
SIP proxies [RFC 2543] also raise some interesting issues, since they can "bend" the media pipe to also serve as media translators. (A proxy can modify the session description so that media no longer travel end-to-end but to a designated intermediate box.)
また、SIPプロキシ[RFC2543]はいくつかのおもしろい問題を提起します、また、メディア翻訳者として勤めるためにメディアパイプを「曲げることができる」ので。 (プロキシがセッション記述を変更できるので、メディアはもう終わりから終わりにもかかわらず、指定された中間的箱に旅行しません。)
{1 Application layer, 2 explicit (HTTP) or implicit (interception), 3
multihop, 4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}.
1個の応用層、2明白な(HTTP)か暗黙の(妨害)、3マルチホップ、4、インライン、5、機能的である、6処理、7、柔らかいです、8は再開します。
Carpenter & Brim Informational [Page 13] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[13ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
Note: Some so-called Web proxies have been implemented as "interception" devices that intercept HTTP packets and re-issue them with their own source address; like NAT and SOCKs, this can disturb address-sensitive applications. Unfortunately some vendors have caused confusion by mis-describing these as "transparent" proxies. Interception devices are anything but transparent. See [WREC] for a full discussion.
以下に注意してください。 何人かのいわゆるウェブプロキシがHTTPパケットを妨害して、それら自身のソースアドレスでそれらを再発行する「妨害」デバイスとして実装されました。 NATとSOCKsのように、これはアドレス敏感なアプリケーションを擾乱できます。 残念ながらいくつかのベンダーが「透明な」プロキシとして誤説明しているこれらで混乱を引き起こしました。 妨害デバイスは決して透明ではありません。 十分な議論に関して[WREC]を見てください。
2.15. Caches
2.15. キャッシュ
Caches are of course used in many shapes and forms in the Internet, and are in principle distinct from proxies. Here we refer mainly to content caches, intended to optimise user response times. HTTP makes provision for proxies to act as caches, by providing for both expiration and re-validation mechanisms for cached content. These mechanisms may be used to guarantee that specific content is not cached, which is a requirement for transient content, particularly in transactional applications. HTTP caching is well described in Section 13 of [RFC 2616], and in the HTTP case caches and proxies are inextricably mixed.
キャッシュは、もちろんインターネットで多くの形とフォームで使用されて、原則としてプロキシと異なっています。 ここと、私たちは主にユーザ応答回数を最適化することを意図する満足しているキャッシュを呼びます。 HTTPは、キャッシュとしてキャッシュされた内容のために満了と再合法化メカニズムの両方に備えることによって機能するようにプロキシに備えます。 これらのメカニズムは特定の内容(一時的な内容のための要件である)がキャッシュされないのを保証するのに使用されるかもしれません、特に取引のアプリケーションで。 HTTPキャッシュは[RFC2616]のセクション13、およびHTTPケースキャッシュでよく説明されます、そして、プロキシは解決できなく混ぜられます。
To improve optimisation, caching is not uniquely conducted between the origin server and the proxy cache directly serving the user. If there is a network of caches, the nearest copy of the required content may be in a peer cache. For this an inter-cache protocol is required. At present the most widely deployed solution is Internet Cache Protocol (ICP) [RFC 2186] although there have been alternative proposals such as [RFC 2756].
最適化を改良するために、キャッシュが唯一直接ユーザに役立つ発生源サーバとプロキシキャッシュの間に行われません。 キャッシュのネットワークがあれば、ピアキャッシュには必要な内容の最も近いコピーがあるかもしれません。 これに関しては、相互キャッシュプロトコルが必要です。 [RFC2756]などの代案がありましたが、現在のところ最も広く配布しているソリューションはインターネットCacheプロトコル(ICP)[RFC2186]です。
It can be argued that caches terminate the applications sessions, and should not be counted as middleboxes (any more than we count SMTP relays). However, we have arbitrarily chosen to include them since they do in practice re-issue the client's HTTP request in the case of a cache miss, and they are not the ultimate source of the application data.
キャッシュがアプリケーションセッションを終えて、middleboxesにみなされるべきでない(私たちがSMTPリレーを数えるよりそれ以上)と主張できます。 しかしながら、私たちは、彼らがキャッシュミスの場合でクライアントのHTTP要求を習慣再発行でするのでそれらを含んでいるのを任意に選びました、そして、彼らはアプリケーションデータの究極の源ではありません。
{1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop,
4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}
1 応用層、2 明白である、(HTTPプロキシキャッシュであるなら)3マルチホップ、4、インライン、5、機能的である、6処理、7、柔らかいです、8は再開します。
2.16. Modified DNS servers
2.16. 変更されたDNSサーバ
DNS servers can play games. As long as they appear to deliver a syntactically correct response to every query, they can fiddle the semantics. For example, names can be made into "anycast" names by arranging for them to resolve to different IP addresses in different parts of the network. Or load can be shared among different members of a server farm by having the local DNS server return the address of
DNSサーバはゲームをすることができます。 あらゆる質問へのシンタクス上正しい応答を提供するように見える限り、彼らは意味論をバイオリンで弾くことができます。 例えば、彼らがネットワークの異なった部分で異なったIPにアドレスを決議するように手配することによって、名前を"anycast"名にすることができます。 または、サーバー・ファームの異なったメンバーの中でサーバがアドレスを返す地方のDNSを持っていることによって、負荷を共有できます。
Carpenter & Brim Informational [Page 14] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[14ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
different servers in turn. In a NAT environment, it is not uncommon
for the FQDN-to-address mapping to be quite different outside and
inside the NAT ("two-faced DNS").
異なったサーバ、順番に。 NAT環境で、FQDNからアドレス・マッピングがNATとNAT(「偽善的なDNS」)において全く異なるのは、珍しくはありません。
Modified DNS servers are not intermediaries in the application data flow of interest. They are included here because they mean that independent sessions that at one level appear to involve a single host actually involve multiple hosts, which can have subtle effects. State created in host A.FOR.EXAMPLE by one session may turn out not to be there when a second session apparently to the same host is started, because the DNS server has directed the second session elsewhere.
変更されたDNSサーバは興味があるアプリケーションデータフローの仲介者ではありません。 彼らが、1つのレベルで独身のホストにかかわるように見える独立しているセッションが実際に微妙な効果を持つことができる複数のホストにかかわることを意味するので、それらはここに含まれています。 ホストA. FOR.EXAMPLEに1つのセッションで創設された状態は明らかに同じホストへの2番目のセッションが始められるとき、そこにないように判明するかもしれません、DNSサーバがほかの場所で2番目のセッションを指示したので。
If such a DNS server fails, users may fail over to an alternate DNS server that doesn't know the same tricks, with unpredicatble results.
そのようなDNSサーバが失敗するなら、ユーザはunpredicatble結果がある同じトリックを知らない代替のDNSサーバへのフェイルオーバーに失敗します。
{1 Application layer, 2 implicit, 3 multihop, 4 in-line (on DNS query
path), 5 functional or optimising, 6 processing, 7 soft, 8 failover}
1個の応用層、2、暗黙である、3マルチホップ、4 インラインである、(DNS照会経路の)5、機能的である、6が処理される7を最適化する、柔らかさ、8フェイルオーバー
2.17. Content and applications distribution boxes
2.17. 内容とアプリケーション給水分散皿
An emerging generalisation of caching is content distribution and application distribution. In this model, content (such as static web content or streaming multimedia content) is replicated in advance to many widely distributed servers. Further, interactive or even transactional applications may be remotely replicated, with some of their associated data. Since this is a recent model, it cannot be said that there is an industry standard practice in this area. Some of the issues are discussed in [WREC] and several new IETF activities have been proposed in this area.
キャッシュの現れている一般化は、満足している分配とアプリケーション配布です。 このモデルでは、内容(静的なウェブ内容かストリーミングのマルチメディアコンテントなどの)はあらかじめ、多くの広く分配されたサーバに模写されます。 さらに、対話的であるか取引のアプリケーションさえそれらの関連データのいくつかで離れて模写されるかもしれません。 これが最近のモデルであるので、産業標準的技法がこの領域であると言うことができません。 [WREC]で問題のいくつかについて議論します、そして、いくつかの新しいIETF活動がこの領域で提案されました。
Content distribution solutions tend to play with URLs in one way or another, and often involve a system of middleboxes - for example using HTTP redirects to send a request for WWW.EXAMPLE.COM off to WWW.EXAMPLE.NET, where the latter name may be an "anycast" name as mentioned above, and will actually resolve in DNS to the nearest instance of a content distribution box.
満足している分配対策は、URLでどうかしてプレーする傾向があって、しばしばmiddleboxesのシステムを伴います--例えば、HTTPが後者の名前が以上のようの"anycast"名であるかもしれないWWW.EXAMPLE.NETにWWW.EXAMPLE.COMを求める要求を送るために向け直して、実際にDNSで満足している給水分散皿の最も近いインスタンスに決議する使用。
As with caches, it is an arbitrary choice to include these devices, on the grounds that although they terminate the client session, they are not the ultimate origin of the applications data.
キャッシュのように、これらのデバイスを含むのは、任意の選択です、クライアントセッションを終えますが、それらがアプリケーションデータの究極の発生源でないので。
{1 Application layer, 2 implicit or explicit, 3 multihop, 4 in-line
or call-out, 5 optimising, 6 routing or processing, 7 soft, 8
restart?}
または、1個の応用層、2、暗黙か明白である、3マルチホップ、4、インライン、柔らかい状態で5最適化、6が掘るか、または処理される7を呼び出してください、8再開?
Carpenter & Brim Informational [Page 15] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[15ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
2.18. Load balancers that divert/munge URLs
2.18. /munge URLを紛らす負荷分散装置
Like DNS tricks, URL redirects can be used to balance load among a pool of servers - essentially a local version of a content distribution network. Alternatively, an HTTP proxy can rewrite HTTP requests to direct them to a particular member of a pool of servers.
DNSトリックのように、URLは缶を向け直します。使用されて、サーバのプールの中で負荷のバランスをとってください--本質的には内容流通機構のローカルのバージョン。 あるいはまた、HTTPプロキシはサーバのプールの特定の部材にそれらを向けるというHTTP要求を書き直すことができます。
These devices are included as middleboxes because they divert an applications session in an arbitrary way.
任意の方法でアプリケーションセッションを紛らすので、これらのデバイスはmiddleboxesとして含まれています。
{1 Application layer, 2 explicit, 3 single hop, 4 in-line, 5
functional, 6 routing, 7 soft, 8 restart}
1 応用層、2 明白であることで、3がインラインでホップ、4人を選抜する、5、機能的である、6が掘られる7、柔らかくて、8は再開します。
2.19. Application-level interceptors
2.19. アプリケーションレベル迎撃戦闘機
Some forms of pseudo-proxy intercept HTTP packets and deliver them to a local proxy server instead of forwarding them to the intended destination. Thus the destination IP address in the packet is ignored. It is hard to state whether this is a functional box (i.e., a non-standard proxy) or an optimising box (i.e., a way of forcing the user to use a cache). Like any non-standard proxy, it has undefined consequences in the case of dynamic or non-cacheable content.
疑似プロキシのいくつかのフォームが、意図している目的地にそれらを送ることの代わりにローカルのプロキシサーバにHTTPパケットを妨害して、それらを提供します。 したがって、パケットの送付先IPアドレスは無視されます。 これが機能的な箱(すなわち、標準的でないプロキシ)かそれとも最適化箱(すなわち、ユーザにキャッシュを使用させる方法)であるかを述べにくいです。 どんな標準的でないプロキシのようにも、それはダイナミックであるか非「キャッシュ-可能」な内容の場合で未定義の結果を持っています。
{1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5
functional or optimising, 6 routing, 7 hard, 8 restart}
1 応用層、2 暗黙であり、3がインラインでホップ、4人を選抜する、5、機能的である、一生懸命6が掘られる7を最適化して、8は再開します。
2.20. Application-level multicast
2.20. アプリケーションレベルマルチキャスト
Some (mainly proprietary) applications, including some approaches to instant messaging, use an application-level mechanism to replicate packets to multiple destinations.
インスタントメッセージングへのいくつかのアプローチを含むいくつかの(主に独占)のアプリケーションが、複数の目的地にパケットを模写するのにアプリケーションレベルメカニズムを使用します。
An example is given in [CHU].
例は[CHU]で出されます。
{1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5
functional, 6 routing, 7 hard, 8 restart}
1個の応用層、2、明白である、3マルチホップ、4、インライン、5、機能的である、6が掘られる一生懸命、8が再開する7
2.21. Involuntary packet redirection
2.21. 不本意なパケットリダイレクション
There appear to be a few instances of boxes that (based on application level content or other information above the network layer) redirect packets for functional reasons. For example, more than one "high speed Internet" service offered in hotel rooms intercepts initial HTTP requests and diverts them to an HTTP server that demands payment before opening access to the Internet. These boxes usually also perform NAT functions.
機能的な理由でパケットを向け直す(ネットワーク層を超えてアプリケーションレベル内容か他の情報に基づいています)箱のいくつかのインスタンスがあるように見えます。 例えば、ホテルの部屋で提供された1つ以上の「高速インターネット」サービスが、インターネットへの初めのアクセスの前に支払いを要求するHTTPサーバに、初期のHTTP要求を妨害して、それらを紛らします。 また、通常、これらの箱はNAT機能を実行します。
Carpenter & Brim Informational [Page 16] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[16ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
{1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6
routing, 7 hard, 8 restart}
1 マルチ層である、2 暗黙であり、6が掘られて、3が機能的にホップ、外での4呼び出し、5人を選抜する、一生懸命、8が再開する7
2.22. Anonymisers
2.22. Anonymisers
Anonymiser boxes can be implemented in various ways that hide the IP address of the data sender or receiver. Although the implementation may be distinct, this is in practice very similar to a NAT plus ALG.
データ送付者か受信機のIPアドレスを隠す様々な方法でAnonymiser箱を実装することができます。実装は異なるかもしれませんが、これは実際にはNATとALGと非常に同様のあります。
{1 multi-layer, 2 implicit or explicit, 3 multihop, 4 in-line, 5
functional, 6 processing, 7 hard, 8 restart}
1つのマルチ層、2、暗黙か明白である、3マルチホップ、4、インライン、5、機能的である、6処理、一生懸命、8が再開する7
2.23. Not included
2.23. 含まれていません。
Some candidates suggested for the above list were excluded for the reasons given below. In general, they do not fundamentally change the architectural model of packet delivery from source to destination.
上記のリストのために示された候補の中には以下にあげられた理由で除かれた人もいました。 一般に、彼らは基本的にソースから目的地までのパケット配信の建築モデルを変えません。
Bridges and switches that snoop ARP, IGMP etc. These are below the IP layer, but use a layer violation to emulate network layer functions. They do not change IP layer functions.
IGMPアルプなどについて詮索するブリッジとスイッチ これらがIP層の下にありますが、層の違反を使用して、ネットワーク層機能を見習ってください。 彼らはIP層の機能を変えません。
Wiretaps and snoopers in general - if they are working correctly, they have no impact on traffic, so do not require analysis.
盗聴と一般に、詮索好き--正しく働いているなら、トラフィックに影響力を全く持っていないので、分析を必要としないでください。
Mobile IP home agents are intended to assist packet delivery to the originally desired destination, so they are excluded on the same grounds as standard routers.
モバイルIPホームのエージェントが元々必要な目的地にパケット配信を促進することを意図するので、彼らは標準のルータと同じ根拠で除かれます。
Relays in interplanetary networks - although these would certainly appear to be middleboxes, they are not currently deployed.
惑星間のネットワークにおけるリレー--これらはmiddleboxesであるように確かに見えるでしょうが、それらは現在、配布されません。
2.24. Summary of facets
2.24. 一面の概要
By tabulating the rough classifications above, we observe that of the 22 classes of middlebox described:
荒い分類について表にすることによって、上では、私たちが、middleboxの22のクラスのものが説明したのを観測します:
17 are application or multi-layer 16 are implicit (and others are explicit OR implicit) 17 are multi-hop 21 are in-line; call-out is rare 18 are functional; pure optimisation is rare Routing & processing are evenly split 16 have hard state 21 must restart session on failure
17はアプリケーションであるかマルチ層の16は暗黙(他のものは明白なOR内在している)の17がマルチホップ21がインラインであるということであるということです。 外での呼び出しはまれな18が機能的であるということです。 純粋な最適化はまれなルート設定と処理が均等に、16には強くある分裂が、21が失敗のセッションを再開しなければならないと述べるということであるということです。
Carpenter & Brim Informational [Page 17] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[17ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
We can deduce that current types of middlebox are predominantly application layer devices not designed as part of the relevant protocol, performing required functions, maintaining hard state, and aborting user sessions when they crash. Indeed this represents a profound challenge to the end-to-end hourglass model.
私たちは、middleboxの現在のタイプが支配的に関連プロトコルの一部として設計されなかった応用層デバイスであると推論できます、必要な機能を実行して、固い状態を維持して、それらがダウンするユーザセッションを中止して。 本当に、これは終わりから終わりへの砂時計モデルへの深遠な挑戦を表します。
3. Ongoing work in the IETF and elsewhere
3. IETFとほかの場所での進行中の仕事
Apart from work cited in references above, current or planned work in the IETF includes:
参照で引用された仕事は別として上では、IETFでの現在の、または、計画された仕事は:
MIDCOM - a working group with focus on the architectural framework and the requirements for the protocol between a requesting device and a middlebox and the architectural framework for the interface between a middlebox and a policy entity [MIDFRAME, MIDARCH]. This may interact with session control issues [SIPFIRE].
MIDCOM--要求デバイスとmiddleboxの間には、建築フレームワークの焦点とプロトコルのための要件があって、middleboxと方針実体[MIDFRAME、MIDARCH]の間には、インタフェースへの建築フレームワークがあるワーキンググループ。 これはセッション制御問題[SIPFIRE]と対話するかもしれません。
Work is also proceeding outside the MIDCOM group on middlebox discovery [MIDDISC].
また、仕事はmiddlebox発見[MIDDISC]に関するMIDCOMグループの外で続いています。
WEBI (Web Intermediaries) - a working group that addresses specific issues in the world wide web infrastructure (as identified by the WREC working group), by providing generic mechanisms which are useful in several application domains (e.g., proxies, content delivery surrogates). Specific mechanisms will be Intermediary Discovery and Description and a Resource Update Protocol.
WEBI(ウェブIntermediaries)--いくつかのアプリケーションドメイン(例えば、プロキシ、内容物配送代理)で役に立つジェネリックメカニズムを提供することによって世界的なウェブインフラストラクチャ(WRECワーキンググループによって特定されるように)における特定の問題を扱うワーキンググループ。 特定のメカニズムは、Intermediaryディスカバリーと、記述とResource Updateプロトコルになるでしょう。
Intermediaries are also an important focus in the development of XML Protocol by the World-Wide Web Consortium, who have published an interesting analysis [XMLPI].
また、仲介者はWorld Wide Web ConsortiumによるXMLプロトコルの開発で重要な焦点です。(Consortiumはおもしろい分析[XMLPI]を発表しました)。
OPES (Open Pluggable Extension Services) - a proposed working group whose output will enable construction of services executed on application data by participating transit intermediaries. Caching is the most basic intermediary service, one that requires a basic understanding of application semantics by the cache server.
作品(開いているPluggable Extension Services)--出力がアプリケーションデータで参加しているトランジット仲介者によって実行されたサービスの工事を可能にする提案されたワーキンググループ。 キャッシュは最も基本的な仲介、キャッシュサーバでアプリケーション意味論の基本的了解事項を必要とするものです。
CDI (Content Distribution Internetworking) is a potential working group for allowing cooperation between different Content Distribution Networks and cache clusters [CDNP].
CDI(内容Distribution Internetworking)は、異なったContent Distribution Networksとキャッシュクラスタ[CDNP]との協力を許容するための潜在的ワーキンググループです。
RSERPOOL (Reliable Server Pooling) is a working group that will define architecture and requirements for management and access to server pools, including requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements and performance requirements, such as failover times and coping with heterogeneous latencies.
RSERPOOL(信頼できるServer Pooling)は管理のためのアーキテクチャと要件とサーバプールへのアクセスを定義するワーキンググループです、さまざまなアプリケーション、ブロック、およびインタフェースからの要件、異なったスタイルのプーリング、セキュリティ要件、および性能要件を含んでいて、異種の潜在のフェイルオーバー回や対処のように。
Carpenter & Brim Informational [Page 18] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[18ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
4. Comments and Issues
4. コメントと問題
A review of the list in Section 2 suggests that middleboxes fit into one or more of three broad categories:
セクション2でのリストのレビューは、middleboxesが3つの広いカテゴリの1つ以上に収まるのを示します:
1) mechanisms to connect dissimilar networks to enable cross-protocol
interoperability;
交差しているプロトコル相互運用性を可能にするために異種のネットワークを結合する1)のメカニズム。
2) mechanisms to separate similar networks into zones, especially
security zones;
ゾーン、特にセキュリティーゾーンに同様のネットワークを切り離す2)のメカニズム。
3) performance enhancement.
3) パフォーマンス強化。
As observed in [RFC 2775], the rise of middleboxes puts into question the general applicability of the end-to-end principle [RFC 1958]. Middleboxes introduce dependencies and hidden points of failure that violate the fate-sharing aspect of the end-to-end principle. Can we define architectural principles that guarantee robustness in the presence of middleboxes?
[RFC2775]で観測されるように、middleboxesの上昇は終わりから終わりへの原則[RFC1958]の一般的な適用性に疑問を投げかけます。 Middleboxesは終わりから終わりへの原則の運命を共有する局面に違反する依存と隠されたポイントの失敗を導入します。 私たちはmiddleboxesがあるとき丈夫さを保証する建築原則を定義できますか?
4.1. The end to end principle under challenge
4.1. 挑戦で原則を終わらせる終わり
Many forms of middlebox are explicitly addressed at the IP level, and terminate a transport connection (or act as a final destination for UDP packets) in a normal way. Although they are potential single points of failure, they do not otherwise interfere with the end to end principle [RFC 1958]. (This statement does not apply to transport relays or TCP spoofers; they do not terminate a transport connection at the expected destination in the normal way.)
middleboxの多くのフォームが、正常な方法でIPレベルで明らかに宛てられて、輸送接続を終えます(UDPパケットのための最終的な目的地として、機能してください)。 潜在的単一のポイントの失敗ですが、そうでなければ、それらは、原則[RFC1958]を終わらせるために終わりを妨げません。 (この声明は、リレーかTCP spoofersを輸送するのに当てはまりません; 彼らは予想された目的地で正常な方法で輸送接続を終えません。)
However, there is a general feeling that middleboxes that divert an IP packet from its intended destination, or substantively modify its content on the fly, are fundamentally different from those that correctly terminate a transport connection and carry out their manipulations at applications level. Such diversion or modification violates the basic architectural assumption that packets flow from source to destination essentially unchanged (except for time-to-live and QOS-related fields). The effects of such changes on transport and applications is unpredictable in the general case. Much of the analysis that applies to NAT [RFC 2993, RFC 3027] will also apply to RSIP, NAT-PT, DSTM, SOCKS, and involuntary packet redirectors. Interception proxies, anonymisers, and some types of load balancer can also have subtle effects on address-sensitive applications, when they cause packets to be delivered to or from a different address. Transport relays and TCP spoofers may deceive applications by delivering an unreliable service on a TCP socket.
しかしながら、意図している目的地からIPパケットを紛らすか、または急いで内容を実質的に変更するmiddleboxesが正しく輸送接続を終えて、アプリケーションレベルで彼らの操作を行うものと基本的に異なっているという一般的な感じがあります。 そのような転換か変更がパケットがソースから目的地まで本質的には変わりがない状態で(生きる時間とQOS関連の分野を除いた)流れるという基本的な建築仮定に違反します。 輸送とアプリケーションへのそのような変化の効果は一般的な場合で予測できません。 分析では、たくさん、それはNATに適用されます。[RFC2993、また、RFC3027]はRSIPに適用するでしょう、太平洋標準時のNAT、DSTM、SOCKSの、そして、不本意なパケットリダイレクタ。 また、妨害プロキシ(anonymisers)と何人かのタイプの負荷分散装置はアドレス敏感なアプリケーションに微妙な影響を与えることができます、それらがアドレス、または、異なったアドレスからパケットを提供させると。 輸送リレーとTCP spoofersは、TCPソケットの上に頼り無いサービスを提供することによって、アプリケーションをごまかすかもしれません。
Carpenter & Brim Informational [Page 19] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[19ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
We conclude that:
私たちは、以下のことと結論を下します。
Although the rise of middleboxes has negative impact on the end to
end principle at the packet level, it does not nullify it as a
useful or desirable principle of applications protocol design.
However, future application protocols should be designed in
recognition of the likely presence of network address translation,
packet diversion, and packet level firewalls, along the data path.
middleboxesの上昇はパケット・レベルで原則を終わらせるために終わりに負の衝撃を持っていますが、アプリケーションの役に立つか望ましい原則がデザインについて議定書の中で述べるとき、それはそれを無効にしません。 しかしながら、将来のアプリケーション・プロトコルはネットワーク・アドレス翻訳、パケット転換、およびパケット・レベルファイアウォールのありそうな存在の認識で設計されるべきです、データ経路に沿って。
4.2. Failure handling
4.2. 失敗取り扱い
If a middlebox fails, it is desirable that the effect on sessions currently in progress should be inconvenient rather than catastrophic. There appear to be three approaches to achieve this:
middleboxが失敗するなら、壊滅的であるというよりむしろ現在進行中のセッションへの効果が不便であることは、望ましいです。 3つのアプローチがこれを達成するためにあるように見えます:
Soft state mechanisms. The session continues in the absence of
the box, probably with reduced performance, until the necessary
session state is recreated automatically in an alternative box (or
the original one, restarted). In other words the state
information optimises the user session but is not essential. An
example might be a true caching mechanism, whose temporary failure
only reduces performance.
軟性国家メカニズムセッションは箱がないとき続きます、たぶん減少している性能で、必要なセッション状態が代替の箱(または、オリジナルのものであって、再開にされる)の中に自動的に休養させられるまで。 言い換えれば、州の情報は、ユーザセッションを最適化しますが、不可欠ではありません。 例は正しいキャッシュメカニズムであるかもしれません。その一時障害は性能を抑えるだけです。
Rapid failover mechanisms. The session is promptly redirected to
a hot spare box, which already has a copy of the necessary session
state.
急速なフェイルオーバーメカニズムセッションは即座にホットスペア箱に向け直されます。(既に、それは、必要なセッション状態のコピーを持っています)。
Rapid restart mechanisms. The two ends of the session promptly
detect the failure and themselves restart the session via a spare
box, without being externally redirected. Enough session state is
kept at each end to recover from the glitch.
急速な再開メカニズムセッションの2つの終わりが即座に予備箱を通してセッションを再開して、存在なしで外部的に向け直された状態で失敗と自分たちを検出します。 十分なセッション状態が、各端のときに不調から回復するために維持されます。
It appears likely that "optimising" middleboxes are suitable candidates for the soft state approach and for non-real-time data streams, since the consequence of failure of the box is not catastrophic for the user. (Configured HTTP proxies used as caches are an awkward case, as their failure causes client failure.) On the other hand, "functional" middleboxes must be present for the session to continue, so they are candidates for rapid failover or rapid restart mechanisms. We conclude that:
その「最適化」middleboxesが軟性国家アプローチと非リアルタイムデータストリームの適当な候補であることがありそうに見えます、ユーザには、箱の失敗の結果が壊滅的でないので。 (それらの失敗がクライアントに失敗を引き起こすとき、キャッシュとして使用される構成されたHTTPプロキシは扱いにくいケースです。) 他方では、「機能的な」middleboxesがセッションが続くように存在していなければならないので、彼らは急速なフェイルオーバーか急速な再開メカニズムの候補です。私たちはそれを結論づけます:
Middlebox design should include a clear mechanism for dealing with
failure.
Middleboxデザインは失敗に対処するための明確なメカニズムを含むべきです。
Carpenter & Brim Informational [Page 20] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[20ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
4.3. Failures at multiple layers
4.3. 複数の層での失敗
Difficulties occur when middlebox functions occur at different layers, for example the following situation, where B and C are not in the same physical box:
middlebox機能が異なった層、例えば、同じ物理的な箱の中にBとCがない以下の状況で起こると、困難は起こります:
Apps layer: A ------------------------> C ------> D
アプリケーションは層にされます: A------------------------>C------>D
Lower layer: A -----> B -------------------------> D
より低く、層にしてください: A----->B------------------------->D
When all is well, i.e., there is an IP path from A to B to C to D and both B and C are working, this may appear quite workable. But the failure modes are very challenging. For example, if there is a network failure between C and D, how is B instructed to divert the session to a backup box for C?. Since C and B function at different protocol layers, there is no expectation that they will have coordinated failure recovery mechanisms. Unless this is remedied in some general way, we conclude that
すべてが順調であり、すなわち、DにはCへのAからBまでのIP経路があって、BとCの両方が働いているとき、これはかなり実行可能に見えるかもしれません。 しかし、故障モードは非常にやりがいがあります。 彼らが持っていない期待は全く失敗回収機構を調整しました。例えば、異なったプロトコルにおける機能がそこで層にするCとBによるこれが何らかの一般的な方法で治されない場合、私たちがそれを結論づけるということであるので、CとDの間には、ネットワーク失敗があれば、BがC?のためにバックアップ箱にセッションを紛らすようどのように命令されるか。
Middlebox failure recovery mechanisms cannot currently assume they
will get any help from other layers, and must have their own means
of dealing with failures in other layers.
Middlebox失敗回収機構は現在、他の層からどんな助けも得て、それら自身の他の層で失敗に対処する手段を持たなければならないと仮定できません。
In the long term future, we should be able to state clearly for
each middlebox function what it expects from its environment, and
make recommendations about which middlebox functions should be
bound together if deployed.
長期未来に、私たちは、それぞれのmiddlebox機能のためにそれが環境から何を予想するかを明確に述べて、配布されるならmiddlebox機能が制限されているべきである推薦状を一緒に、するはずであることができます。
4.4. Multihop application protocols
4.4. マルチホップアプリケーション・プロトコル
We can also observe that protocols such as SMTP, UUCP, and NNTP have always worked hop-by-hop, i.e., via multiple middleboxes. Nobody considers this to be an issue or a problem. Difficulties arise when inserting a middlebox in an application protocol stream that was not designed for it. We conclude that:
また、私たちは、SMTPや、UUCPや、NNTPなどのプロトコルがホップごとにすなわち、複数のmiddleboxesを通していつも働いていたのを観測できます。 だれも、これが問題か問題であると考えません。 それのために設計されなかったアプリケーション・プロトコルの流れにmiddleboxを挿入するとき、困難は起こります。 私たちは、以下のことと結論を下します。
New application protocol designs should include explicit
mechanisms for the insertion of middleboxes, and should consider
the facets identified in Section 2 above as part of the design.
新しいアプリケーション・プロトコルデザインは、middleboxesの挿入のために明白なメカニズムを含むべきであり、デザインの一部としてセクション2で特定された一面が上であると考えるべきです。
A specific challenge is how to make interactive or real-time applications ride smoothly over middleboxes. This will put particular stress on the failure handling aspects.
特定の挑戦は対話的であるかリアルタイムのアプリケーションにmiddleboxesをどうスムーズに通り過ぎさせるかということです。 これは失敗取り扱い局面に特別の圧力を置くでしょう。
Carpenter & Brim Informational [Page 21] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[21ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
4.5. Common features
4.5. 共通点
Given that the IP layer - the neck of the hourglass - is no longer alone in its role supporting end-to-end connectivity, it would be desirable to define requirements and features that are common to middlebox intermediaries. It would then be possible to implement middleboxes, and in particular the protocols that communicate with them, fully from the stance of supporting the end-to-end principle. Conceptually, this would extend the neck of the hourglass upwards to include a set of common features available to all (or many) applications. In the context of middleboxes and multihop protocols, this would require common features addressing at least:
IP層(砂時計の首)がもう終わりから終わりへの接続性を支持する役割で単独でないなら、middlebox仲介者にとって、一般的な要件と特徴を定義するのは望ましいでしょう。 middleboxes、および特に終わりから終わりへの原則を支持する姿勢から彼らと完全にコミュニケートするプロトコルを実行するのはその時、可能でしょう。 概念的に、これは、アプリケーションに利用可能な共通点のセットを含むように上向きに砂時計の首を広げているでしょう。 middleboxesとマルチホッププロトコルの文脈では、これは少なくとも共通点アドレシングを必要とするでしょう:
Middlebox discovery and monitoring
Middlebox configuration and control
Call-out
Routing preferences
Failover and restart handling
Security, including mutual authentication
互いの認証を含むコントロール外のCallルート設定好みのMiddlebox発見、モニターしているMiddlebox構成、Failover、および再開取り扱いSecurity
As far as possible, the solutions in these areas being developed in the IETF and W3C should be sufficiently general to cover all types of middlebox; if not, the work will be done several times.
できるだけ、IETFとW3Cで開発されるこれらの領域の解決策はmiddleboxのすべてのタイプをカバーできるくらい一般的であるべきです。 そうでなければ、何度か仕事をするでしょう。
5. Security Considerations
5. セキュリティ問題
Security risks are specific to each type of middlebox, so little can be said in general. Of course, adding extra boxes in the communication path creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models and key distribution models. Thus, every middlebox design requires particular attention to security analysis. A few general points can be made:
middleboxの各タイプに、セキュリティリスクが特定であるので、少ししか一般に言うことができません。 もちろん、通信路で余分な箱を加えるのは攻撃のエキストラポイントを作成して、暗号化を終わらせるために終わりを実行する能力を減少するか、または根絶して、信用モデルと主要な分配モデルを複雑にします。 したがって、あらゆるmiddleboxデザインが証券分析に関する特別の注意を必要とします。 一般的な数ポイントを指摘できます:
1. The interference with end-to-end packet transmission by many types
of middlebox is a crippling impediment to generalised use of IPSEC
in its present form, and also invalidates transport layer security
in many scenarios.
1. middleboxの多くのタイプによる終わりから終わりへのパケット伝送の干渉は、現行様式におけるIPSECの一般化された使用の無力にしている障害であり、また、多くのシナリオでトランスポート層セキュリティを無効にします。
2. Middleboxes require us to move definitively from a two-way to an
N-way approach to trust relationships and key sharing.
2. Middleboxesは、私たちが関係と主要な共有を信じるためにツーウェイからN-道のアプローチまで決定的に動くのを必要とします。
3. The management and configuration mechanisms of middleboxes are a
tempting point of attack, and must be strongly defended.
3. middleboxesの管理と構成メカニズムを攻撃の魅力的なポイントであり、強く防御しなければなりません。
These points suggest that we need a whole new approach to security solutions as the middlebox paradigm ends up being deployed in lots of different technologies, if only to avoid each new technology
これらのポイントは、結局多くの異なった技術でmiddleboxパラダイムが配備されるとき私たちがセキュリティ解決策への真新しいアプローチを必要とするのを示します、各新技術を避けるために唯一なら
Carpenter & Brim Informational [Page 22] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[22ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
designing a end-to-end security solution appropriate to its particular impact on the data stream.
終わりから終わりへのセキュリティデータ・ストリームへの特定の影響に適切な解決策を設計します。
Additionally, content caches and content distribution mechanisms raise the issue of access control for content that is subject to copyright or other rights. Distributed authentication, authorisation and accounting are required.
さらに、満足しているキャッシュと満足している分配メカニズムは著作権か他の権利を受けることがある内容のためのアクセス管理の問題を提起します。 分配された認証、認可、および会計が必要です。
6. Acknowledgements
6. 承認
Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom, Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on early versions of this document. Rob Austein and Allison Mankin drafted the text on transport relays and TCP spoofers, and Rob Austein made other substantial contributions. Participants in the MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker, Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen, Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave invaluable input. Mark Nottingham brought the W3C work to our attention. Melinda Shore suggested using a facet-based categorization. Patrik Faltstrom inspired section 4.3.
スティーブBellovin、ジョン・クロウクロフト、スティーブ・デアリング、パトリクFaltstrom、ヘニングSchulzrinne、およびLixiaチャンはこのドキュメントの早めのバージョンの有益なフィードバックをすべて与えました。 ロブAusteinとアリソン・マンキンは輸送リレーとTCP spoofersに関するテキストを作成しました、そして、ロブAusteinは他の多大な貢献をしました。 第50IETFのMIDTAX BOFとMIDTAXメーリングリストの上の関係者、ハラルドAlverstrand、スタニスラフShalunov、マイケル・スミルノフ、ジェフ・パーカー、サンディー・マーフィー、デヴィッド・マーチン、フィルNeumiller、エリック・トラヴィス、エド・ボーエン、サリー・フロイド、イアン・クーパー、マイク・フィスク、およびエリック・フライシュマンを含んでいると、非常に貴重な入力は与えられました。 マーク・ノッティンガムはW3C仕事を私たちに注目していただきました。 メリンダShoreは、一面ベースの分類を使用するのを示しました。 パトリクFaltstromはセクション4.3を奮い立たせました。
7. References
7. 参照
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
L. Jones, "SOCKS Protocol Version 5", March 1996.
[RFC1928]のヒル、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、1996年3月。」
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
version 2", RFC 2186, September 1997.
[RFC2186] ウェセルズとD.とK.Claffy、「インターネットCacheプロトコル(ICP)、バージョン2インチ、RFC2186、1997年9月。」
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[RFC2543] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
Carpenter & Brim Informational [Page 23] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[23ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2663] SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
(HTCP/0.0)", RFC 2756, January 2000.
[RFC2756] VixieとP.とD.ウェセルズ、「プロトコル(HTCP/0.0)をキャッシュする超-テキスト」、RFC2756、2000年1月。
[RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC2766] TsirtsisとG.とP.Srisuresh、「アドレス変換をネットワークでつないでください--翻訳(太平洋標準時のNAT)について議定書の中で述べてください」、RFC2766、2000年2月。
[RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February
2000.
[RFC2775] 大工、B.、「インターネット透明」、RFC2775、2000年2月。
[RFC 2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
解放された[RFC2979]、N.、「インターネットのための振舞いと要件ファイアウォール」、RFC2979、2000年10月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983] 黒(D.)が「サービスとトンネルを微分した」、RFC2983、10月2000日
[RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC2993] ハイン、T.、「NATの建築含意」、RFC2993、2000年11月。
[RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
and J. Segers, "Megaco Protocol 1.0", RFC 3015, November
2000.
[RFC3015] CuervoとF.とグリーン、N.とRayhanとA.とHuitemaとC.とローゼン、B.とJ.Segers、「Megacoは1インチについて議定書の中で述べます、RFC3015、2000年11月。」
[RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC3022] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
[RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027, January
2001.
[RFC3027] HoldregeとM.とP.Srisuresh、「IPネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
[CHU] Y. Chu, S. Rao, and H. Zhang, A Case for End System
Multicast, SIGMETRICS, June 2000.
http://citeseer.nj.nec.com/chu00case.html
[CHU] 終わりのシステムマルチキャスト、SIGMETRICS、6月2000日の http://citeseer.nj.nec.com/chu00case.html のためのY.チュウ、S.ラオとH.チャン、ケース
[CLARK88] The Design Philosophy of the DARPA Internet Protocols,
D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4,
August 1988, pages 106-114 (reprinted in ACM CCR Vol 25,
Number 1, January 1995, pages 102-111).
[CLARK88] DARPAインターネットプロトコル(Proc SIGCOMM88、ACM CCR Vol18、Number4、1988年8月、106-114ページ(ACM CCR Vol25、Number1、1995年1月、102-111ページでは、翻刻します)のD.D.クラーク)のDesign Philosophy。
[CLARK95] "Adding Service Discrimination to the Internet", D.D.
Clark, Proceedings of the 23rd Annual Telecommunications
Policy Research Conference (TPRC), Solomons, MD, October
1995.
[CLARK95] 「加えて、インターネットに区別を修理してください」、D.D.クラーク、第23例年の電気通信政策研究会議(TPRC)の議事、ソロモン、Md、1995年10月。
Carpenter & Brim Informational [Page 24] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[24ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
[CDNP] M. Day, et al., "A Model for Content Internetworking
(CDI)", Work in Progress.
[CDNP] M.デー、他、「満足しているインターネットワーキング(CDI)のためのモデル」、ProgressのWork。
[DSTM] J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A.
Durand, "Dual Stack Transition Mechanism (DSTM)", Work in
Progress.
[DSTM]J.はバウンドしています、L.トゥータン、F.デュポン、メディナ、H.Afifi、A.ジュランド「デュアルスタック変遷メカニズム(DSTM)」が進行中で扱うO.。
[H323] ITU-T Recommendation H.323: "Packet Based Multimedia
Communication Systems".
[H323]ITU-T推薦H.323: 「パケットはマルチメディア通信システムを基礎づけました。」
[HOURG] "Realizing the Information Future: The Internet and
Beyond", Computer Science and Telecommunications Board,
National Research Council, Washington, D.C., National
Academy Press, 1994. However, the "hourglass" metaphor was
first used by John Aschenbrenner in 1979, with reference
to the ISO Open Systems Interconnection model.
[HOURG]、「情報未来がわかります:」 コンピュータサイエンスとテレコミュニケーション板、調査評議会、ワシントンDC、国家のアカデミーは、「インターネットと以遠」と1994に押します。 しかしながら、「砂時計」比喩は1979年に最初にジョンAschenbrennerによって使用されました、ISOオープン・システム・インターコネクションモデルに関して。
[HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, February 2002.
[HTTPSUB]ムーア、K. 「SubstrateとしてのHTTPの使用」のBCP56、RFC3205、2002年2月。
[MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in
Progress.
[MIDARCH]E.リア、「Middleboxの建築枠組み」は進行中で働いています。
[MIDDISC] E. Lear, "Requirements for Discovering Middleboxes", Work
in Progress.
[MIDDISC]E.リア、「Middleboxesを発見するための要件」は進行中で働いています。
[MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
Rayhan, "Middlebox Communication: Framework and
Requirements", Work in Progress.
[MIDFRAME]P.Srisuresh、J.Kuthan、J.ローゼンバーグ、A.モリトル、A.Rayhan、「Middleboxコミュニケーション:」 「枠組みと要件」は進行中で働いています。
[PILCPEP] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[PILCPEP]は接しています、J.、Kojo、M.、Griner、モンテネグロ、G.、およびZ.シエルビイ、J.、「パフォーマンスはリンク関連の転落を緩和することを意図するプロキシを高め」て、RFC3135、2001年6月。
[RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP] Borella、M.、最低気温、J.、Grabelsky、D.、およびG.モンテネグロ、「分野の特定のIP:」 「枠組み」、RFC3102、2001年10月。
[SALTZER] End-To-End Arguments in System Design, J.H. Saltzer,
D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November
1984, pp 277-288.
System Designの[SALTZER]終わりから終わりへのArguments、J.H.Saltzer、D.P.リード、D.D.クラーク、ACM TOCS Vol2、Number4、1984年11月、pp277-288。
[SIPFIRE] S. Moyer, D. Marples, S. Tsang, J. Katz, P. Gurung, T.
Cheng, A. Dutta, H. Schulzrinne, A. Roychowdhury,
"Framework Draft for Networked Appliances Using the
Session Initiation Protocol", Work in Progress.
[SIPFIRE]S.モイヤー、D.マープルズ、S.Tsang、J.キャッツ、P.Gurung、T.チェン、A.ドゥッタ、H.Schulzrinne、「セッション開始プロトコルを使用するネットワークでつながれた器具のための枠組みの草稿」というA.Roychowdhuryは進行中で働いています。
Carpenter & Brim Informational [Page 25] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[25ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
[SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
RFC 3089, April 2001.
[SOCKS6] 喜田村、H.、「ソックスベースのIPv6/IPv4ゲートウェイメカニズム」、RFC3089、2001年4月。
[TRANS64] "Overview of Transition Techniques for IPv6-only to Talk
to IPv4-only Communication", Work in Progress.
[TRANS64] 「IPv4だけコミュニケーションと話すIPv6だけのための変遷のテクニックの概観」、処理中の作業。
[WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[WREC] クーパー、私、Melve、I.、G.トムリンスン、「インターネットウェブ模写、分類学をキャッシュする」、RFC3040、1月2001日
[XMLPI] Intermediaries and XML Protocol, Mark Nottingham, Work in
Progress at http://lists.w3.org/Archives/Public/xml-dist-
app/2001Mar/0045.html
[XMLPI]仲介者とXMLプロトコル、マークノッティンガムは http://lists.w3.org/Archives/Public/xml-dist- 装置/2001Mar/0045.htmlで進行中で働いています。
Authors' Addresses
作者のアドレス
Brian E. Carpenter IBM Zurich Research Laboratory Saeumerstrasse 4 / Postfach 8803 Rueschlikon Switzerland
ブライアン・E.大工IBMチューリッヒ研究所Saeumerstrasse4 / Postfach8803Rueschlikonスイス
EMail: brian@hursley.ibm.com
メール: brian@hursley.ibm.com
Scott W. Brim 146 Honness Lane Ithaca, NY 14850 USA
スコットW.縁146のHonness Laneニューヨーク14850イタケー(米国)
EMail: sbrim@cisco.com
メール: sbrim@cisco.com
Carpenter & Brim Informational [Page 26] RFC 3234 Middleboxes: Taxonomy and Issues February 2002
大工と縁の情報[26ページ]のRFC3234Middleboxes: 分類学と問題2002年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Carpenter & Brim Informational [Page 27]
大工と縁の情報です。[27ページ]
一覧
スポンサーリンク
