[要約] RFC 3234は、ミドルボックスの分類と問題に関する情報を提供するものです。その目的は、ネットワークの中間に配置されるミドルボックスの役割と課題を理解し、ネットワークの設計と運用に役立つことです。
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.
Copyright（c）The Internet Society（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.
「ミドルボックス」というフレーズは、リクシア・チャンによって、最近のインターネットの現象のグラフィック説明として造られました。ミドルボックスは、ソースホストと宛先ホストの間のデータグラムパス上の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パケットフローを終了するデバイス、または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.
* ミドルボックスは新しい障害モードを導入します。クラッシュしたルーターの周りの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.
このドキュメントのコアは、多くのタイプのミドルボックスのカタログです。それらを分類して階層やその他の単純な形式の分類法を形成する明白な方法はありません。ミドルボックスには、多次元分類法に分類するために使用される可能性のある多くのファセットがあります。
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.
免責事項：これらのファセット、異なるタイプのミドルボックスの区別の多く、および特定のタイプのデバイスを含めるまたは除外する決定は、ある程度主観的です。このドキュメントのドラフトについてコメントしたすべての人が、私たちの分類や説明に同意するわけではありません。次のカタログが数学的に完全かつ一貫しているとは主張しておらず、場合によっては純粋にarbitrary意的な選択が行われているか、あいまいさが残っています。したがって、このドキュメントは決定的であると主張しません。
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. インライン対コールアウト。Middlebox関数は、データパスでインラインで実行される場合があります。または、補助ボックスへの呼び出しが含まれる場合があります。
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.
ネットワークアドレス翻訳者。多くの場合、ルーターに組み込まれている関数は、そのホストの知識なしに、グローバルにユニークなアドレスをホストにないホストに動的に割り当てます。その結果、そのホストとの間のすべてのパケットの適切なアドレスフィールドは、その場で翻訳されます。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を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ネットワークの間でNATを実行し、IPv6形式とIPv4形式の間でIPヘッダー全体を翻訳します。
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はどちらも関連するアルグが必要であり、輸送チェックサムに触れる必要があります。IPv4にUDPチェックサムが許可されていないため、IPv4からIPv6への断片化されたUnchecummed UDPの翻訳は絶望的です。NAT-PTおよびSIITには、特にPATH MTU発見をしないエンドポイントを扱う場合（またはPATH 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]は、認証されたファイアウォールトラバーサルのステートフルメカニズムであり、クライアントホストはファイアウォールをトラバースする前にファイアウォールのソックスサーバーと最初に通信する必要があります。ファイアウォールの外で使用されるソースIPアドレスとポート番号を決定するのは、クライアントではなくソックスサーバーです。これを考慮に入れるには、クライアントのスタックを「ソックシファイ」する必要があり、住所に敏感なアプリケーションは、NATと同様に混乱する可能性があります。ただし、Socks GatewaysはALGSを必要としません。
SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.
靴下は、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の観点から、トンネルパケットが受けるホップごとの処理は、パケットが先に進んだ場合、受け取ったものではない可能性があります[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.
輸送リレーは、基本的にアルグに相当する輸送層です。それらの別の（あまり一般的ではない）名前はTLGです。ALGSと同様に、それらはさまざまな目的に使用されます。トランスポートリレーの初期の例は、ARPANETでMITのITSおよびTOPS-20 PDP-10で実行され、ChaosNetのみのホストがChaosNetからTCP/IPへの出力接続を行うことを許可したものでした。その後、TCP-TP4リレーのいくつかの用途がありました。IPv6のみとIPv4のみのホスト間のトランスポートリレーは、IPv6遷移のツールの1つです[Trans64]。TLGは、ホストが外の世界と通信したり、奇妙なIPルーティング構成の周りでKludgeでできるように制限を実施するために、単純なパケットフィルタリングファイアウォールと組み合わせて使用される場合があります。TLGは、接続特性が大幅に異なる同じ輸送プロトコルの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チェックサムが送信者のデータエンドツーエンドをカバーしないことを意味します。データが最初の接続から2番目の接続に転送されると、データの破損または変更が処理に導入される場合があります。一部の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やHTTPなどの他のセッション層メカニズムは、TCPレベルでのデータの整合性の損失を検出し、TCPと同様に再送信するのではなく、セッションの障害につながります。ただし、アプリケーションデータの整合性を追加する一般的なセッションメカニズムはないため、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 Spoofer」は、パフォーマンスを向上させる目的で、フライトでのTCPプロトコルのタイミングまたはアクションを変更するミドルボックスの用語としてよく使用されます。もう1つのより正確な名前は、TCPパフォーマンスを向上させるプロキシ（PEP）です。多くのTCP PEPは独自であり、主に標準のTCPを使用して相互運用性エラーを導入するときに、オープンインターネットで特徴付けられています。TLGと同様に、TCP PEPがニーズを満たしていると見られる状況があります。たとえば、TCP PEPは、バーストサービスとのリンクによって一緒に束ねられたACKの再スペースを提供する場合があり、したがって、望ましくないデータセグメントバーストを回避できます。PILC（リンク特性のパフォーマンスへの影響）ワーキンググループは、TCP PEPのタイプとその適用性を分析しました[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インライン、5つの最適化、6ルーティング、7ハード、8再起動}
2.8. Load balancers that divert/munge packets.
2.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ルーティングによってサーバー全体でアプリケーションを分割することです。One-Shot 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).
一部のアルグは、フラグメンテーションの問題を引き起こす方法でも実装されていますが、この場合、問題は間違いなく意図的なレイヤー違反の結果です（たとえば、TCPセグメントをその場で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]、およびメガココントローラー[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ページのトランスコーディング、およびデジタル携帯電話をVoice-over-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.
すべてのメディア翻訳者が必須ではありません。それらは単に最適化かもしれません。たとえば、マルチキャストの場合、すべての低帯域幅レシーバーがネットワークの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再起動またはフェールオーバー}
HTTP1.1 [RFC 2616] defines a Web proxy as follows:
HTTP1.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.
ファイアウォールで発信HTTPパケットが許可されていない場合、Webプロキシはファイアウォールに関連付けられている場合があります。ただし、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].
最適化を改善するために、キャッシュは、Origin Serverとユーザーに直接サービスを提供するプロキシキャッシュの間で一意に実行されません。キャッシュのネットワークがある場合、必要なコンテンツの最も近いコピーはピアキャッシュにある場合があります。これには、キャッシュ間プロトコルが必要です。現在、最も広く展開されているソリューションはインターネットキャッシュプロトコル（ICP）[RFC 2186]ですが、[RFC 2756]などの代替提案がありました。
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リクエストを再発行するため、それらが実際に再発行されるため、それらを含めるようにarbitrarily意的に選択されています。
{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アドレスに解決するように手配することにより、名前を「aycast」名前にすることができます。または、ローカルDNSサーバーに異なるサーバーのアドレスを順番に返すことにより、サーバーファームのさまざまなメンバー間で負荷を共有できます。NAT環境では、FQDNからアドレスへのマッピングがNAT（「2フェイス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で作成された状態は、DNSサーバーが他の場所で2番目のセッションを監督したため、同じホストの2番目のセッションが開始されるように見える場合、1つのセッションごとに行われないことが判明する場合があります。
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サーバーが失敗した場合、ユーザーは同じトリックを知らない代替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フェイルオーバー}
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.
コンテンツ配信ソリューションは、何らかの形でURLを使用する傾向があり、多くの場合、ミドルボックスのシステムが含まれます。たとえば、HTTPリダイレクトを使用してwww.example.comのリクエストをwww.example.netに送信します。上記の「Anycast」の名前になり、実際に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プラスアルグに非常に似ています。
{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.
Snoop 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 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.
17はアプリケーションまたは多層16は暗黙的である（およびその他は明示的または暗黙的です）17はマルチホップ21です。コールアウトはまれです18は機能的です。純粋な最適化はまれなルーティングと処理が均等に分割されます16ハードステート21は失敗時に再起動セッションを再開する必要があります。ユーザーセッションがクラッシュしたときに中止します。実際、これはエンドツーエンドの砂時計モデルに対する深い挑戦を表しています。
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-アーキテクチャのフレームワークと要求デバイスとミドルボックス間のプロトコルの要件に焦点を当てたワーキンググループ、およびミドルボックスとポリシーエンティティ[Midframe、Midark]のインターフェースのアーキテクチャフレームワーク。これは、セッション制御の問題[Sipfire]と相互作用する場合があります。
Work is also proceeding outside the MIDCOM group on middlebox discovery [MIDDISC].
また、Midcom Discovery [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（Web仲介業者） - いくつかのアプリケーションドメイン（プロキシ、コンテンツ配信サロゴなど）で役立つ一般的なメカニズムを提供することにより、World Wide Webインフラストラクチャ（WEBワーキンググループによって識別されている）の特定の問題に対処するワーキンググループ。特定のメカニズムは、仲介者の発見と説明、およびリソース更新プロトコルです。
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]を公開した世界的なWebコンソーシアムによる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（Open 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（コンテンツ配信インターネットワーク）は、異なるコンテンツ配信ネットワークとキャッシュクラスター間の協力を可能にするための潜在的なワーキンググループです[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つ以上に適合することを示唆しています。
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]の一般的な適用性に疑問を投げかけます。ミドルボックスは、エンドツーエンドの原則の運命共有の側面に違反する依存関係と隠された失敗ポイントを導入します。ミドルボックスの存在下で堅牢性を保証するアーキテクチャの原則を定義できますか？
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パケットの最終宛先として機能する）を終了します。それらは潜在的な単一の故障ポイントですが、それ以外の場合は、終了原則[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、ソックス、および非自発的なパケットリダイレクターにも適用されます。インターセプトプロキシ、匿名、およびいくつかのタイプのロードバランサーは、パケットを別のアドレスに出入りさせると、住所に敏感なアプリケーションに微妙な影響を与える可能性があります。トランスポートリレーと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
すべてが順調である場合、つまり、AからBからC、D、D、DのIPパスがあり、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.
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.
長期的には、各ミドルボックス関数について、環境から予想されることを明確に述べ、展開した場合はどのミドルボックス関数を結び付けられるかについての推奨事項を作成できるはずです。
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仲介業者に共通する要件と機能を定義することが望ましいでしょう。その場合、エンドツーエンドの原則をサポートするというスタンスから、ミドルボックス、特にそれらと通信するプロトコルを実装することが可能になります。概念的には、これにより、砂時計の首を上向きに拡張して、すべての（または多くの）アプリケーションで利用可能な一連の一般的な機能を含めます。ミドルボックスとマルチホッププロトコルのコンテキストでは、これには少なくとも対処する一般的な機能が必要です。
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. ミドルボックスは、関係とキー共有を信頼するために、双方向からn-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.
Steve Bellovin、Jon Crowcroft、Steve Deering、Patrik Faltstrom、Henning Schulzrinne、およびLixia Zhangはすべて、この文書の初期バージョンについて貴重なフィードバックを提供しました。ロブ・アウスタインとアリソン・マンキンは、トランスポートリレーとTCPスプーファーに関するテキストを起草し、ロブ・オーストインは他のかなりの貢献をしました。50番目のIETFのMidTax BOFおよびHarald Alverstrand、Stanislav Shalunov、Michael Smirnov、Jeff Parker、Sandy Murphy、David Martin、Phil Neumiller、Eric Travis、Ed Bowen、Sally Floyd、Ian Cooper、Ian Cooperを含むMidTaxメーリングリストの参加者マイク・フィスクとエリック・フライシュマンは非常に貴重な入力を与えました。マーク・ノッティンガムは、W3Cの仕事を私たちの注意を引き付けました。メリンダショアは、ファセットベースの分類を使用することを提案しました。Patrik Faltstromにインスパイアされたセクション4.3。
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC 1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", March 1996.
[RFC 1928] Leech、M.、Ganis、M.、Lee、Y.、Kuris、R.、Koblas、D。、およびL. Jones、「Socks Protocolバージョン5」、1996年3月。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958] Carpenter、B。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), version 2", RFC 2186, September 1997.
[RFC 2186] Wessels、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「Hypertext Transfer Protocol-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. Holdrege、「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. Wessels、「Hyper Text Caching Protocol（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] Freed、N。、「インターネットファイアウォールの行動と要件」、RFC 2979、2000年10月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC 2993] Hain、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] Cuervo、F.、Greene、N.、Rayhan、A.、Huitema、C.、Rosen、B。およびJ. Segers、「Megaco Protocol 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] Holdrege、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. Chu、S。Rao、およびH. Zhang、エンドシステムマルチキャストのケース、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インターネットプロトコルの設計哲学、D.D。クラーク、Proc Sigcomm 88、ACM CCR Vol 18、Number 4、1988年8月、106〜114ページ（ACM CCR Vol 25、Number 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。クラーク、1995年10月、MD、ソロモンズ、ソロモンズ、第23回通信政策研究会議（TPRC）の議事録。
[CDNP] M. Day, et al., "A Model for Content Internetworking (CDI)", Work in Progress.
[CDNP] M. Day、et al。、「コンテンツインターネットワーク（CDI）のモデル」、進行中の作業。
[DSTM] J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A. Durand, "Dual Stack Transition Mechanism (DSTM)", Work in Progress.
[DSTM] J. Bound、L。Toutain、F。Dupont、O。Medina、H。Afifi、A。Durand、「デュアルスタック遷移メカニズム（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年。、ISOオープンシステムの相互接続モデルを参照してください。
[HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[httpsub]ムーア、K。、「基質としてのHTTPの使用について」、BCP 56、RFC 3205、2002年2月。
[MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in Progress.
[Midarch] E. Lear、「ミドルボックスアーキテクチャフレームワーク」、進行中の作業。
[MIDDISC] E. Lear, "Requirements for Discovering Middleboxes", Work in Progress.
[中ディスク] E.リア、「ミドルボックスを発見するための要件」は、進行中の作業。
[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。Rosenberg、A。Molitor、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] Border、J.、Kojo、M.、Griner、J.、Montenegro、G。、およびZ. Shelby、「リンク関連の劣化を緩和することを目的としたプロキシのパフォーマンス向上」、RFC 3135、2001年6月。
[RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP] Borella、M.、Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有の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.
[Saltzer]システム設計におけるエンドツーエンドの引数、J.H。Saltzer、D.P.Reed、D.D.Clark、ACM TOCS、Vol 2、Number 4、1984年11月、pp 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. Moyer、D。Marples、S。Tsang、J。Katz、P。Gurung、T。Cheng、A。Dutta、H。Schulzrinne、A。Roychowdhury、 "セッション開始プロトコルを使用したネットワーク化された電化製品のフレームワークドラフト「、進行中の作業。
[SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[Socks6] Kitamura、H。、「ソックスベースの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のみの通信と通信するためのIPv6のみの移行手法の概要」、進行中の作業。
[WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[WREC] Cooper、I、Melve、I。およびG. Tomlinson、「インターネット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 Rueschlikon Switzerland
EMail: brian@hursley.ibm.com
Scott W. Brim 146 Honness Lane Ithaca, NY 14850 USA
スコット・W・ブリム146ホンネスレーンイサカ、ニューヨーク14850 USA
EMail: sbrim@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。