Network Working Group B. Carpenter
Request for Comments: 3234 IBM Zurich Research Laboratory
Category: Informational S. Brim
February 2002
Middleboxes: Taxonomy and Issues
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
ソースホストと宛先ホストとの間のデータ経路上のIPルータの通常の、標準的な機能とは別に機能を実行する任意の中間のボックスとして定義 - 本文書は、「中間装置」についてのIETF議論の一部として意図されます。この文書は、ミドルボックスのカタログまたは分類法を確立し、以前と現在のIETF仕事に関する中間箱を引き合いに出して、そしていくつかの予備の結論を識別しようとします。それは、しかし、決定的であることを主張しません。
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
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.
句「ミドル」は、インターネットでの最近の現象のグラフィック記述としてLixiaチャンで鋳造されました。ミドルは、ソースホストと宛先ホスト間のデータグラムの経路上の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トラフィックに集中特に、ワード「仲介者」が使用されます。現在のドキュメントのために、我々はより多くのグラフィックフレーズを好みます。もちろん、ミドルボックスは、すなわち、いくつかの他のボックスの埋め込み関数で仮想であることができます。必ずしも別々の物理ボックスを指すと解釈されるべきではありません。これは、1つのIPパケットフローを終了し、別の発信デバイス、又は変換するか、または何らかの方法で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ルーティング機能（[RFC 1812]に記載さ即ち、ルート発見および選択機能、およびIPv6のためのそれらの等価物）はミドルボックス機能とは見なされません。標準のIPルータは、IPパケットに対して本質的に透明です。 IPレイヤ内で行わその他の機能は、ミドルの機能であるとみなすことができるが、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ルーティング。」
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プロトコル上に乗るすべての上位層で、狭い口砂時計のようなプロトコル・アーキテクチャを示します。
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.
エンド・ツー・エンド原理は、（例えば、セキュリティや信頼性など）一部の機能のみを完全に実装すると、正しくエンドツーエンド、エンドポイントの助けを借りてできると主張しています。エンド・ツー・エンドの原則は、ネットワーク自体にこのような機能の不完全なバージョンを提供することは、時には、性能向上としてではなく、機能のエンドツーエンドの実装のための代替物として有用であり得ることを指摘しています。上記参照、および[RFC 1958]は、より詳細に入ります。
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ルータであり、その唯一の機能は、（また、転送処理のために必要なフィールドを更新しながら）経路およびフォワードパケットを決定することです。彼らはミドルボックスとして分類されていない理由です。
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フォワーディング以外の機能を実行する数多くのミドルボックスのネットワークでの挿入による、このモデルからの偏差を観察します。一方向から見た、これらのボックスは、ネットワーク層[RFC 2775]の透明性への挑戦です。別の見方をすれば、彼らは砂時計モデルへの挑戦です：IP層が離れていかないものの、ミドルボックスは、すべての通信セッションの単一必要な特徴として、その意義を薄めます。代わりに、エンドシステムの多様性と機能を集中させる、彼らはネットワーク全体の多様性と機能を広げます。
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 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パケットの再ルーティングは、周りのルータは、もはや考慮すべき唯一のケースでクラッシュしません。クラッシュしたミドルボックスを含むセッションの運命をも考慮しなければなりません。
* Configuration is no longer limited to the two ends of a session; middleboxes may also require configuration and management.
*設定は、もはやセッションの両端に制限されていません。ミドルボックスは、構成および管理が必要な場合があります。
* Diagnosis of failures and misconfigurations is more complex.
*障害や設定ミスの診断はより複雑です。
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.
この文書の原則の目標は、インターネットのアーキテクチャとその応用上のミドルボックスの現在の影響を説明し、分析することです。このことから、我々はいくつかの一般的な結論を特定しようとします。
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,
*アプリケーションプロトコルとミドル設計のためのアーキテクチャの指針を提案します、
* to identify requirements and dependencies for common functions in the middlebox environment,
*ミドル環境で共通機能の要件と依存関係を特定するために、
* 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].
暗黙の目標は、[RFC 1958]インターネットの建築の原則に必要な更新を識別することです。
The document initially establishes a catalogue of middleboxes, and cites previous or current IETF work concerning middleboxes, before proceeding to discussion and conclusions.
文書は、最初にミドルボックスのカタログを確立し、議論や結論に進む前に、以前または現在IETFの作業に関するミドルボックスを引用しています。
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.
このドキュメントのコアは、ミドルの種類の数のカタログです。階層や分類の他の簡単なフォームを形成するためにそれらを分類する明白な方法はありません。 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.
免責事項：これらの面、ミドルの異なる種類の区別の多くは、デバイスの特定のタイプを含めるか除外するかどうかは、ある程度主観的です。この文書の草稿についてコメントしていないすべての人は、私たちの分類と説明と一致しています。私たちは、次のカタログは、数学的に完全で一貫していると主張していない、といくつかのケースでは、純粋に任意の選択が行われている、または曖昧さが残ります。したがって、この文書はノークレームは決定的なことがないようになります。
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。ミドル機能は、SMTPリレーのように、使用するプロトコル（複数可）の明示的な設計上の特徴ですか？それとも、アドオン、おそらくネットワークアドレス変換器のように、目に見えないようにしようと、プロトコル設計によって予見ではないでしょうか？
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。ミドル機能は、データパス上にインラインで実行することができる、またはそれは、コールアウトの補助ボックスにを含むことができます。
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.
一つの可能な分類が意図的に除外されます。「悪」対「良いです」。分析は、ミドルのいくつかの種類が合併症と短所のホストが付属していることを示しているが、有用な目的は、単にそれらを廃止することにより、提供されないであろう。彼らは、説得力のある理由のために考案されており、それらの理由を理解することは有益です。
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.
注意：ミドルには多くの種類がIPパケットの断片化と再アセンブリを実行する必要があります。これは、特定の場合にのみ言及されています。
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 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.
ネットワークアドレス変換。動的にそのホストの知識がなくても、1を持っていないホストにグローバルにユニークなアドレスを割り当てることが多いルータに組み込まれた機能、。その結果、へとそのホストからのすべてのパケット内の適切なアドレスフィールドは、その場で翻訳されています。 NATは、IPアドレスの依存関係を持つアプリケーションプロトコルと互換性がないため、NATは、実際には常にALGを伴っている（アプリケーションレベルゲートウェイ - 下記参照します）。また、チェックサムを固定する程度にトランスポート層に触れます。
NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993, RFC 3022, RFC 3027, etc.]
NATは広範囲IETF [RFC 2663、RFC 2993、RFC 3022、RFC 3027、など]で分析されています
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]の代わりにステートフル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処理、7ハード、8再起動}
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-PT自体は、そのプロトコル変換機能のためのステートレスIP / ICMP翻訳アルゴリズム（SIIT）メカニズム[RFC 2765]に依存します。実際には、SIITとNAT-PTは、両方の関連するALGが必要になりますし、輸送チェックサムをタッチする必要があるでしょう。 IPv4のUDPチェックサムの許さないため、IPv4からIPv6への断片化unchecksummed UDPの翻訳は絶望的です。 NAT-PTとSIITも特に（パスMTUディスカバリを破る他のミドルボックスを通過するとき、または）パスMTUディスカバリをしないエンドポイントを扱うときに、他の潜在的なフラグメンテーション/ 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-PTはNGTRANS WG [RFC 2766]から提案された標準です。デュアルスタック遷移メカニズムは、第2の関連ミドル、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処理、7ハード、8再起動}
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 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.
SocksV5の[RFC 1928]は、ファイアウォールを通過することができる前に、クライアントホストがファイアウォールでSOCKSサーバと最初に通信する必要のある認証されたファイアウォールトラバーサルのためのステートフルなメカニズムです。これは、ファイアウォールの外側に使用されるソースIPアドレスとポート番号を決定しSOCKSサーバー、クライアントではなく、です。クライアントのスタックは、このを考慮して、「SOCKS化したの」でなければならない、とアドレスに敏感なアプリケーションではなく、NATと同様に、混乱することがあります。しかし、SOCKSゲートウェイはのALGを必要としません。
SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.
SOCKSは、AFT（認証されたファイアウォールトラバーサル）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、7ハード、8再起動}
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の観点から、例えば、受信ホップごとの処理は、パケットがuntunneled [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}
{1多層、2暗黙、3マルチホップ、4インライン、5機能、6処理、7ハード、8再起動またはフェールオーバー}
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、RFC 2475]のために、特に、それらをマークします。彼らは交通コンディショナーの動作を制御するので、彼らは、それ以降のホップを介してパケットフローの順序を変更することができます。
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}
{1多層、暗黙2、3マルチホップ、インライン4、5最適化、6処理、7ソフト、8フェイルオーバまたは再起動}
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です。 ALGと同じように、彼らはいくつかは十分に確立し、会議はそうでない場合は満たされないニーズ、様々な目的のために使用されています。輸送リレーの初期の例は、MITのITSに走ったとTOPS-20 ARPANET上のPDP-10SをしてChaosnetのみのTCP / IP上にChaosnetからの発信接続を行うためにホスト許されたものでした。その後、TCP-TP4リレーのいくつかの用途がありました。 IPv6のみとIPv4専用ホストとの間のトランスポートリレーはIPv6移行[TRANS64]のツールの一つです。 TLGSは時々外の世界に話すことができるか、不思議なIPルーティングの設定を中心にその場しのぎするホストを上の制限を適用するために、単純なパケットフィルタリングファイアウォールと組み合わせて使用されています。 TLGSはまた、時々有意に異なる接続特性を有する同じトランスポートプロトコルの2つのインスタンス間のゲートウェイするために使用されます。それはTLGもTCPまたは輸送スプーフィングと呼ばれることがあり、この意味です。この役割において、TLGてもよいことにシェード機能ミドルではなく最適化するが、それはだけでバックツーバック接続を作成することにより、その最適化を行い、ないという事実によってトランスポートプロキシ（次のセクション）から区別されます変更またはTCPメッセージのリタイミング。
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 this problem is not unique to middleboxes, but can also be caused by checksum offloading TCP implementations within the sender, for example.
1つのTCP接続を終了し、別の半ばにパスを開始すると、TCPチェックサムは、送信者のデータエンドツーエンドをカバーしていないことを意味します。データが第一から第二の接続に転送されたときにデータの破損や変形が処理中に導入することができます。いくつかのTCPリレーはスプリットのリレーであり、以上の2つのTCP接続があるかもしれないので、失われたデータの整合性の一層可能性があり、複数のノードとネットワークパスが関与します。すべての場合において、送信者はTCP信頼性の高いバイトストリームサービスでデータの整合性が期待される保証未満を持っています。この問題は、ミドルボックスに固有のものではありませんが、また、例えば、送信者内のチェックサムオフロードTCPの実装によって引き起こされる可能性があることに注意してください。
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、7ハード、8再起動}
"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のスプーフィングは、」多くの場合、パフォーマンスを向上させる目的で、飛行中にTCPプロトコルのタイミングや動作を変更する中間ボックスのための用語として使用されています。もう一つの、より正確な名前は、TCPの性能向上プロキシ（PEP）です。多くのTCPのPEPは独自のもので、彼らは標準のTCPとの相互運用性のエラーを導入する際、主にオープンなインターネットに特徴付けられています。 TLGSと同じように、TCP PEPは、それ以外の場合は満たされないニーズを満たすために見た状況があります。例えば、TCP PEPは、このように望ましくないデータセグメントバーストを避け、バーストサービスとのリンクによって一緒に束ねられてきたACKの再間隔を提供することができます。 PILC（リンク特性のパフォーマンスへの影響）ワーキンググループは、TCPのPEP及びその適用[PILCPEP]の種類を解析しました。 TCPののPEPは、TCPの誤りでなく、TCP適応行動の意図せぬ変化だけでなく導入することができます。
{1 Transport layer, 2 implicit, 3 multihop, 4 in-line, 5 optimising, 6 routing, 7 hard, 8 restart}
{1つのトランスポート層、2暗黙、3マルチホップ、インライン4、5最適化、6ルーティング、7ハード、8再起動}
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ルーティングによってサーバー間でアプリケーションを分割することが一般的です。同じアプリケーションセッションからのすべてのパケットが同じ物理サーバに向けられる必要があるとして、ワンショットUDPプロトコルのまれを除き、これらの技術は、必然的にステートフルです。 （ただし、洗練されたソリューションは、フェールオーバーを処理することができるだろう。）
To date these techniques are proprietary and can therefore only be applied in closely managed environments.
これまでにこれらの技術は、独自であり、それゆえにのみ密接に管理された環境で適用することができます。
{1 multi-layer, 2 implicit, 3 single hop, 4 in-line, 5 optimising, 6 routing, 7 hard, 8 restart}
{1多層、2暗黙の、3つのホップ、4インライン、5最適化、6ルーティング、7ハード、8再起動}
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とトランスポートヘッダ内のフィールドに純粋に基づいてパケットを拒否します
Although firewalls have not been the subject of standardisation, some analysis has been done [RFC 2979].
ファイアウォールは、標準化の対象とされていないが、いくつかの分析は、[RFC 2979]を行われてきました。
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フラグメントを通じことができます。 （必要に応じて、再断片）は、多くの「ステートフル」ファイアウォールは、したがって、フラグメント漏洩エンド受信機の再組立実装のバグを利用することができる特に断片を回避するために、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、7ハード、8再起動}
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クライアント/サーバまたはWebプロキシエージェント）として作用します。彼らかもしれません
(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）タンデムでのこれらの技術のいくつかの組み合わせを使用しています。
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].
ファイアウォールは、標準化の対象とされていないが、いくつかの分析は、[RFC 2979]を行われてきました。 HTTPを使用してファイアウォールトラバーサルの問題は、[HTTPSUB]で議論されてきました。
{1 Application layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6 processing, 7 hard, 8 restart}
{1つのアプリケーション層、2暗黙、3マルチホップ、インライン4、5機能、6処理、7ハード、8再起動}
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.
これらは多くの形状および形態で来ます。 NATはFTPなどの特定のアドレスに依存したプロトコル用のALGを必要とします。これらは、アプリケーションプロトコルのセマンティクスを変更するが、フィールドの機械的置換を行いません。スケールの他方の端部に、まだ例として、FTPを使用して、ゲートウェイは、FTPや、OSIとのDECnet（R）当量のような他のファイル転送プロトコルの間で構築されています。いずれにせよ、そのようなゲートウェイは、彼らが扱っているセッションの状態を維持する必要があり、この状態が失われた場合、セッションは通常、取消不能解除されます。
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).
この場合、問題はおそらく意図的層違反の結果であるが、いくつかのALGはまた、断片化の問題を作成する方法で実装されている（例えば、オンザフライでTCPセグメントをいじることによってFTP制御接続のアプリケーション・データ・ストリームといじくります）。
{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処理、7ハード、8再起動}
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テレフォニーの上昇に伴って、特に、TCPコネクション以外のセッションを作成して管理する必要性が生じてきました。名前の検索、認証、許可、アカウンティング、ファイアウォール越え、時にはメディア変換に対処しているマルチメディア環境では、サードパーティ製のボックスによってセッションの確立および制御が避けられない解決策であるように思われます。例としては、H.323ゲートキーパー[H323]、SIPサーバ[RFC 2543]とMEGACOコントローラ[RFC 3015]を含んでいます。
{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処理、7ハード、8再起動}？
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.
トランスコーダは、アプリケーションレベルのデータのオンザフライ変換のいくつかの種類を行うボックスです。例としては、手持ちのワイヤレスデバイス上に表示するための既存のWebページのトランスコーディング、およびボイスオーバーIPサービスとデジタル携帯電話を相互接続するためのさまざまなオーディオフォーマット間のトランスコーディングが含まれます。多くの場合、そのようなトランスコーディングは、エンドシステムによって行うことができず、少なくとも音声の場合には、それは非常に迅速な障害復旧を厳密リアルタイムに行われなければなりません。
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.
いないすべてのメディア翻訳者が必須です。彼らは単に最適かもしれません。すべての低帯域幅の受信機がネットワークの一つの「コーナー」に座っている場合、送信者は、2つのストリームを生成したり、すべての方法を、ネットワークを介して、両方のストリームを送信するために例えば、マルチキャストの場合には、それは非効率的であるかどう "薄い」1だけ遠く離れた送信者から必要とされています。 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の再起動またはフェールオーバー}
HTTP1.1 [RFC 2616] defines a Web proxy as follows:
次のようにHTTP 1.1 [RFC 2616] Webプロキシを定義します。
"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.
Webプロキシは、ファイアウォールが発信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で与えられた「ミドル」の定義に該当しない注意してください。
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プロキシ[RFC 2543]はまた、いくつかの興味深い問題を提起します。 （メディアはもはやエンドエンドではなく指定された中間のボックスに移動しないように、プロキシは、セッション記述を修正することができます。）
{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再起動}。
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.
注意：一部のいわゆるWebプロキシは、自分の送信元アドレスとHTTPパケットを傍受して再発行し、それら「傍受」デバイスとして実装されています。 NATや靴下のように、これはアドレスに敏感なアプリケーションを乱すことができます。残念ながら、いくつかのベンダーは、「透明」のプロキシとしてこれらの記述ミスによる混乱を引き起こしています。迎撃デバイスは何もなく、透明です。完全な議論のための[WREC]を参照してください。
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キャッシュは十分[RFC 2616]のセクション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].
最適化を向上させるために、キャッシングは一意にオリジンサーバと直接ユーザーにサービスを提供するプロキシキャッシュとの間で行われていません。キャッシュのネットワークがある場合は、必要なコンテンツの最寄りのコピーは、ピア・キャッシュであってもよいです。このためにキャッシュ間プロトコルが必要です。現時点で最も広く導入されているソリューションは、[RFC 2756]のような代替案がなされているものの、インターネットキャッシュプロトコル（ICP）[RFC 2186]です。
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.
キャッシュがアプリケーションのセッションを終了し、ミドルボックスとして（私たちは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再起動}
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 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").
DNSサーバは、ゲームをプレイすることができます。限り、彼らはすべてのクエリに構文的に正しい応答を提供するように見えるように、彼らは意味をいじることができます。たとえば、名前がネットワークのさまざまな部分で異なるIPアドレスに解決するために彼らのために配置することにより、「エニーキャスト」の名前にすることができます。または負荷は、ローカルDNSサーバが順番に異なるサーバのアドレスを返すことによって、サーバーファームの異なるメンバー間で共有することができます。 FQDNからアドレスへのマッピングは外とNAT（「2-顔DNS」）内はかなり異なるようにするためにNAT環境では、それは珍しいことではありません。
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つのレベルで単一のホストを巻き込むように見える独立したセッションは、実際に微妙な影響を持つことができ、複数のホストを伴うことを意味するので、彼らはここに含まれています。 DNSサーバが別の場所で第二のセッションを監督しているので、一つのセッションでホストA.FOR.EXAMPLEで作成された状態では、同じホストに明らかに第二のセッションが開始されたときには存在しないようになるかもしれません。
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官能インライン（DNSクエリー経路上の）マルチホップ、4、5又は最適化、6処理、7ソフト、8フェイルオーバ}
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.
キャッシングの新興一般化は、コンテンツ配信とアプリケーションの配布です。このモデルでは、（静的なWebコンテンツやストリーミングマルチメディアコンテンツなど）コンテンツは、多くの広く分散サーバに事前に複製されます。さらに、インタラクティブあるいはトランザクションのアプリケーションがリモートそれらに関連するデータの一部を用いて、複製することができます。これは、最近のモデルであるので、この領域で、業界標準の慣行があると言うことはできません。問題のいくつかは、[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.
WWW.EXAMPLE.NET、後者の名前月を切っWWW.EXAMPLE.COMの要求を送信するためにHTTPリダイレクトを使用して例えば - コンテンツ配信ソリューションは、一つの方法または別のURLで遊ぶ、そして多くの場合、ミドルボックスのシステムが関与する傾向があります前述したように、「エニーキャスト」名で、実際にコンテンツ配信ボックスの最寄りのインスタンスに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再起動}？
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.
彼らは、任意の方法でアプリケーションセッションをそらすため、これらのデバイスは、ミドルボックスとして含まれています。
{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再起動}
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再起動}
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、7ハード、8再起動}
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.
機能的な理由のためにパケットをリダイレクト（ネットワーク層以上のアプリケーション・レベルの内容、または他の情報に基づいて）ボックスの少数の例があるように見えます。例えば、ホテルの部屋で提供される複数の「高速インターネット」サービスは、最初のHTTPリクエストをインターセプトし、インターネットへのアクセスを開く前に支払いを要求するHTTPサーバに転送されます。これらのボックスには通常、NAT機能を実行します。
{1 multi-layer, 2 implicit, 3 single hop, 4 call-out, 5 functional, 6 routing, 7 hard, 8 restart}
{1は、多層、2暗黙の、3つのホップ、4コールアウト、5機能、ルーティング6、7ハード、8再起動}
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アドレスを隠す、さまざまな方法で実装することができます。実装が異なったかもしれないが、これは実際には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処理、7ハード、8再起動}
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.
スヌープARPは、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.
惑星間ネットワークのリレー - これらは確かにミドルボックスのように見えるだろうが、彼らは、現在配備されていません。
By tabulating the rough classifications above, we observe that of the 22 classes of middlebox described:
上記のラフな分類を集計することにより、我々は説明したミドルの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は、図17は、マルチホップ21は、インラインされているアプリケーションまたはマルチ層16は暗黙（明示的または暗黙などである）されています。コールアウトは18が機能している稀です。純粋な最適化は、16はハードステート21を持って均等に珍しいルーティング＆処理を分割され、失敗した場合に、セッションを再起動する必要があります
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.
我々は、ミドルボックスの現在の種類は、主に必要な機能を実行する関連プロトコルの一部として設計されていないアプリケーション層デバイスは、ハード状態を維持し、そしてそれらがクラッシュ時にユーザセッションを中断していることを推論することができます。確かにこれは、エンドツーエンドの砂時計モデルに深遠な挑戦を表します。
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 - アーキテクチャフレームワークと要求しているデバイスとミドルとミドルとポリシーエンティティとの間のインターフェースのためのアーキテクチャフレームワーク[ミッドフレーム、MIDARCH]との間のプロトコルのための要件に焦点を当てたワーキンググループ。これは、セッション制御の問題[SIPFIRE]と相互作用することができます。
Work is also proceeding outside the MIDCOM group on middlebox discovery [MIDDISC].
仕事はまた、[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（ウェブ仲介） - （WRECワーキンググループによって識別される）いくつかのアプリケーションドメイン（例えば、プロキシ、コンテンツ配信サロゲート）に有用である一般的なメカニズムを提供することで、ワールドワイドウェブインフラストラクチャ内の特定の問題に対処するワーキンググループ。具体的なメカニズムは、仲介ディスカバリーと説明し、リソースの更新プロトコルになります。
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].
仲介者はまた、興味深い分析[XMLPI]を公開しているワールドワイドウェブコンソーシアムによるXMLプロトコルの開発における重要な焦点です。
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.
OPES（オープンプラグイン可能な拡張サービス） - その出力トランジット仲介を参加して、アプリケーションデータ上で実行するサービスの構築を可能にする提案ワーキンググループ。キャッシュは最も基本的な仲介サービス、キャッシュサーバによって、アプリケーションのセマンティクスの基本的な理解を必要とするものです。
CDI (Content Distribution Internetworking) is a potential working group for allowing cooperation between different Content Distribution Networks and cache clusters [CDNP].
CDI（コンテンツ配信インターネットワーキング）は、異なるコンテンツ配信ネットワークおよびキャッシュ・クラスタ[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（信頼できるサーバプーリングは）のようなブロックやインタフェースを構築する様々なアプリケーションからの要件を含む、サーバープールにアーキテクチャと管理とアクセスのための要件を定義しますワーキンググループ、プール、セキュリティ要件と性能要件の異なるスタイルであり、フェイルオーバー時間と異質の待ち時間に対処します。
A review of the list in Section 2 suggests that middleboxes fit into one or more of three broad categories:
第2節では、リストの見直しは、ミドルボックスは3つの大きなカテゴリーの一つまたは複数に収まることを示唆しています：
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?
[RFC 2775]で観察されたように、ミドルボックスの上昇が問題にエンド・ツー・エンド原理[RFC 1958]の一般的な適用を置きます。 Middleboxesは、依存関係およびエンド・ツー・エンド原理の運命共有側面に違反し、障害の隠されたポイントを紹介します。私たちは、ミドルボックスの存在下での堅牢性を保証するアーキテクチャの原則を定義することはできますか？
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.)
ミドルボックスの多くの形態は、明示的にIPレベルでアドレス指定され、通常の方法で（UDPパケットの最終宛先として、またはACT）トランスポート接続を終了しています。彼らは失敗の可能性のある単一の点ではあるが、それ以外の場合は、原則[RFC 1958]エンド・ツー・エンドに干渉しません。 （この文は、リレーやTCPのスプーファを輸送するためには適用されません。彼らは通常の方法で予想される先のトランスポート接続を終了しません。）
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パケットをそらす、または実質的にその場でその内容を変更する中間ボックスは、正しくトランスポート接続を終了し、アプリケーション・レベルでその操作を行っているものとは根本的に異なっていることが一般的な感じがあります。そのような転換又は変更は（タイム・ツー・ライブおよびQoS関連フィールドを除いて）本質的に変化しないソースから宛先へのフローをパケットの基本的なアーキテクチャの仮定に違反します。トランスポート及びアプリケーションにこのような変化の影響は、一般的な場合に予測不可能です。 NAT [RFC 2993、RFC 3027]に適用される分析の多くもRSIPに適用される、NAT-PT、DSTM、SOCKS、および不随意パケットリダイレクタ。彼らはまたは別のアドレスから配信されるパケットを起こしたときに傍受プロキシ、anonymisers、およびロードバランサのいくつかのタイプも、アドレスに敏感なアプリケーションに微妙な影響を持つことができます。トランスポートリレーとTCPスプーファは、TCPソケット上の信頼性のないサービスを提供することで、アプリケーションを欺くことがあります。
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.
中間装置の上昇は、パケットレベルでの原理をエンドツーエンドに負の影響を有するが、それはアプリケーションプロトコル設計の有用なまたは望ましい原則としてそれを無効にしません。しかし、将来のアプリケーションプロトコルは、データパスに沿って、ネットワークアドレス変換、パケット転用、およびパケットレベルのファイアウォールのありそうな存在の認識に設計する必要があります。
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:
ミドルが失敗した場合、現在進行中のセッションに影響が不便ではなく、壊滅的であることが望ましいです。これを達成するための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.
迅速な再起動のメカニズム。セッションの両端には、速やかに障害を検出し、自身が外部にリダイレクトされることなく、予備の箱を経由してセッションを再開します。十分なセッション状態はグリッチから回復するために、各エンドに保たれています。
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:
箱の失敗の結果は、ユーザにとって壊滅的ではないので、「最適化」ミドルボックスは、柔らかい状態のアプローチのためおよび非リアルタイム・データ・ストリームのための適切な候補である可能性が表示されます。 （キャッシュが厄介な場合ですと、その障害がクライアントの故障の原因となるよう構成されたHTTPプロキシは、使用していました。）一方、セッションを継続するために、「機能的」ミドルボックスが存在しなければならないので、彼らは迅速なフェイルオーバーや迅速な再起動のメカニズムの候補です。我々はそれを結論します：
Middlebox design should include a clear mechanism for dealing with failure.
ミドルのデザインは、障害に対処するための明確なメカニズムを含むべきです。
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:
ミドルボックス機能は、例えば、異なる層でB及びCが同じ物理ボックスに含まれていない次のような状況を、発生したときに問題が発生します。
Apps layer: A ------------------------> C ------> D
Lower layer: 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
すべてがうまくである場合、すなわち、そこにBからCへのIPパスがDであり、そしてBおよびCの両方が動作している、これは非常に実用現れ得ます。しかし、故障モードは非常に困難です。 CとDとの間のネットワーク障害がある場合、例えば、方法BはCのバックアップボックスへのセッションを迂回するように指示されました？。異なるプロトコル層におけるC及びB機能するので、それらは障害回復機構を配位しているであろうという期待はありません。これは、いくつかの一般的な方法で改善されない限り、我々は、と結論します
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.
ミドル障害回復メカニズムは現在、彼らが他の層から任意の助けを得るだろうと想定することはできませんし、他の層の障害に対処する独自の手段を持っている必要があります。
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.
長期的な将来的には、我々はそれがその環境から期待するもの、各ミドル機能のために明確に述べると、展開されている場合ミドル機能が一緒に結合されるべきかについての提言を行うことができるはずです。
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などのプロトコルは常にホップバイホップを働いていることを観察することができます。誰もがこの問題や問題であると考えていません。それのために設計されていないアプリケーション・プロトコル・ストリームにおけるミドルボックスを挿入する際に困難が生じます。我々はそれを結論します：
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.
新しいアプリケーションプロトコルの設計は、ミドルボックスの挿入のための明示的なメカニズムを含める必要があり、そして上記の設計の一部として、第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.
具体的な課題は、対話型またはリアルタイム・アプリケーションは、ミドルボックスの上にスムーズに乗るようにする方法です。これは、障害処理の側面に、特定のストレスを入れます。
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 discovery and monitoring Middlebox configuration and control Call-out Routing preferences Failover and restart handling Security, including mutual authentication
ミドル発見と監視ミドル構成および制御コールアウトルーティングの好みのフェイルオーバーとは、相互認証など、セキュリティを扱う再始動します
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で開発され、これらの領域中の溶液がミドルボックスのすべてのタイプをカバーするのに十分に一般的であるべきです。ない場合は、作業が数回行われます。
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:
セキュリティ上のリスクがミドルの各タイプに固有なので、少しは、一般的に言うことができます。もちろん、通信パスに余分なボックスを追加すると、攻撃の余分なポイントを作成し、エンドの暗号化に終止符を実行する能力を低下させるかまたは排除し、信頼モデルと鍵配布モデルを複雑にします。このように、すべてのミドルデザインは、セキュリティ分析に特に注意が必要です。いくつかの一般的なポイントを行うことができます。
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.干渉は、その現在の形で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ウェイアプローチに2-wayから決定的に移動することを求めています。
3. The management and configuration mechanisms of middleboxes are a tempting point of attack, and must be strongly defended.
3.ミドルボックスの管理と設定メカニズムは、攻撃の魅力的なポイントであり、強く擁護しなければなりません。
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 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.
また、コンテンツのキャッシュおよびコンテンツ配信メカニズムは、著作権やその他の権利の対象となるコンテンツに対するアクセス制御の問題を提起します。分散型認証、許可、アカウンティングが必要とされています。
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のスプーファ上のテキストを起草し、ロブAusteinとは、他のかなりの貢献をしました。ハラルドAlverstrand、スタニスラフ・シャルノブ、マイケル・スミルノフ、ジェフ・パーカー、サンディマーフィー、デビッド・マーティン、フィル・Neumiller、エリック・トラヴィス、エド・ボーエン、サリー・フロイド、イアン・クーパー、を含む第50回IETFでとMIDTAXメーリングリスト上MIDTAX BOFの参加、マイク・フィスクとエリックFleischmanは、非常に貴重な入力を与えました。マーク・ノッティンガムは、私達の注意にW3Cの作業をもたらしました。メリンダ・ショアは、ファセットベースの分類を使用して提案しました。パトリックFaltstromは、セクション4.3に影響を与えました。
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC 1812]、RFC 1812、1995年6月ベイカー、F.、 "IPバージョン4つのルータのための要件"。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", March 1996.
[RFC 1928]リーチ、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.およびL.ジョーンズ、 "SOCKSプロトコルバージョン5"、1996年3月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997.
[RFC 2186]ウェッセル、D.及びK. Claffy、 "インターネットキャッシュプロトコル（ICP）、バージョン2"、RFC 2186、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.
[RFC 2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC 2543] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC 2543]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、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.
[RFC 2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC 2663] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000.
[RFC 2756]いるVixie、P.およびD.ウェッセル、 "ハイパーテキストのキャッシング・プロトコル（HTCP / 0.0）"、RFC 2756、2000年1月。
[RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC 2766] Tsirtsis、G.とP. Srisuresh、 "ネットワークアドレス変換 - プロトコル変換（NAT-PT）"、RFC 2766、2000年2月。
[RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[RFC 2775]大工、B.、 "インターネットの透明性"、RFC 2775、2000年2月。
[RFC 2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[RFC 2979]フリード、N.、 "の行動とインターネットファイアウォールの要件"、RFC 2979、2000年10月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC 2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、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.
[RFC 3015]クエルボ、F.、グリーン、N.、Rayhan、A.、のHuitema、C.、ローゼン、B.及びJ. Segers、 "Megacoのプロトコル1.0"、RFC 3015、2000年11月。
[RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC 3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC 3027]ホールドレッジ、M.とP. Srisuresh、 "IPネットワークアドレス変換とプロトコルの合併症"、RFC 3027、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] Y.チュー、S.ラオ、およびH.チャン、エンドシステムマルチキャスト用ケース、SIGMETRICS、2000年6月http://citeseer.nj.nec.com/chu00case.html
[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インターネットプロトコル、DDClarkのデザイン理念、PROCのSIGCOMM 88は、ACM CCRは、第18巻、ナンバー4、1988年8月、ページ106-114（ACM CCR巻25、ナンバー1、1995年1月、頁102に再版します-111）。
[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月。
[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. Toutain、F.デュポン、O.メディナ、H. Afifi、A.デュラン、 "デュアルスタック遷移メカニズム（DSTM）"、進行中で働いて結合しました。
[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]「情報未来を実現：インターネットとその先」、コンピュータ科学と電気通信委員会、国家研究評議会、ワシントンD.C.、ナショナル・アカデミー・プレス、1994年には、しかし、「砂時計」のメタファーは、まず1979年にジョン・Aschenbrennerで使用されていました、ISO開放型システム間相互接続モデルを基準としました。
[HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[HTTPSUB]ムーア、K.、BCP 56、RFC 3205、2002年2月 "基板としてのHTTPの使用について"。
[MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in Progress.
【MIDARCH】E.リア、「ミドルアーキテクチャフレームワーク」は、進行中の作業します。
[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.
【ミッドフレーム】P. Srisuresh、J. Kuthan、J.ローゼンバーグ、A.モリター、A. Rayhan、 "ミドルコミュニケーション：フレームワークおよび要件"、進行中で働いています。
[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.、古城、M.、Griner、J.、モンテネグロ、G.およびZ.シェルビーは、RFC 3135、2001年6月 "パフォーマンス強化プロキシはリンク関連の劣化を軽減することを目的と"。
[RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP]ボレッラ、M.、ロー、J.、Grabelsky、D.およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、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.
システム設計、J.H.で[SALTZER]エンドツーエンドの引数Saltzer、D.P.Reed、D.D.Clark、ACM TOCS、第2巻、ナンバー4、1984年11月、頁277-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. Marples、S.ツァン、J.カッツ、P.グルン、T.チェン、A. Duttaさん、H. Schulzrinneと、セッション開始プロトコルを使用するネットワーク家電用A. Roychowdhury、「フレームワークドラフト」、進行中の作業。
[SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
【SOCKS6]北村、H.、 "SOCKSベースのIPv6 / IPv4のゲートウェイ機構"、RFC 3089、2001年4月。
[TRANS64] "Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication", Work in Progress.
、進行中の作業[TRANS64]「IPv6のみIPv4のみのコミュニケーションに話をするための移行技術の概要」を参照してください。
[WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[WREC]クーパー、I、Melve、I.およびG.トムリンソン、 "インターネットのWebレプリケーションおよびキャッシング分類学"、RFC 3040、2001年1月。
[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-app/2001Mar/0045.html
Authors' Addresses
著者のアドレス
Brian E. Carpenter IBM Zurich Research Laboratory Saeumerstrasse 4 / Postfach 8803 Rueschlikon Switzerland
ブライアンE.カーペンターIBMチューリッヒ研究所Saeumerstrasse 4 / POSTFACH 8803リュシュリコンスイス
EMail: brian@hursley.ibm.com
メールアドレス：brian@hursley.ibm.com
Scott W. Brim 146 Honness Lane Ithaca, NY 14850 USA
スコットW.ブリム146 Honnessレーンイサカ、NY 14850 USA
EMail: sbrim@cisco.com
メールアドレス：sbrim@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。