この文書はRFC3234の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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.
この文書は「中間装置」−ソースホストと宛先ホストの間にデータパス上に
ある、ＩＰルータの通常の標準的な機能以外の機能を実行している中間ボッ
クスと定義されてる−についてのＩＥＴＦ議論の一部を意図します。この文
書は中間装置の目録あるいは分類学を確立し、中間装置に関する前と現在の
ＩＥＴＦの仕事を引用し、ある予備の結論を識別しようと試みます。しかし
ながら、これが決定とは主張しません。
Table of Contents
目次
1. Introduction and Goals
1. 序説と目標
1.1. Terminology
1.1. 用語
1.2. The Hourglass Model, Past and Future
1.2. 砂時計モデル、過去と未来
1.4. Goals of this Document
1.4. この文書の目標
2. A catalogue of middleboxes
2. 中間装置一覧
2.1 NAT
2.1 ＮＡＴ
2.2 NAT-PT
2.2 ＮＡＴ−ＰＴ
2.3 SOCKS gateway
2.3 ＳＯＣＫＳゲートウェイ
2.4 IP Tunnel Endpoints
2.4 ＩＰトンネル終端
2.5. Packet classifiers, markers and schedulers
2.5. パケット分類、マークとスケジューラ
2.6 Transport relay
2.6 輸送リレー
2.7. TCP performance enhancing proxies
2.7. ＴＣＰ性能拡張プロキシ
2.8. Load balancers that divert/munge packets.
2.8. パケットの迂回や変更をする負荷分散装置
2.9. IP Firewalls
2.9. ＩＰファイアウォール
2.10. Application Firewalls
2.10. アプリケーションファイアウォール
2.11. Application-level gateways
2.11. アプリケーションレベルゲートウェイ
2.12. Gatekeepers/ session control boxes
2.12. 門番／セッション制御箱
2.13. Transcoders
2.13. トランスコーダ
2.14. Proxies
2.14. プロキシ
2.15. Caches
2.15. キャッシュ
2.16. Modified DNS servers
2.16. ＤＮＳサーバ修正
2.17. Content and applications distribution boxes
2.17. コンテンツとアプリケーション分散箱
2.18. Load balancers that divert/munge URLs
2.18. ＵＲＬの迂回や変更をする負荷分散装置
2.19. Application-level interceptors
2.19. アプリケーションレベル横取り
2.20. Application-level multicast
2.20. アプリケーションレベルマルチキャスト
2.21. Involuntary packet redirection
2.21. 何気ないパケット転送
2.22. Anonymisers
2.22. 匿名化
2.23. Not included
2.23. 含まれない
2.24. Summary of facets
2.24. 側面の要約
3. Ongoing work in the IETF and elsewhere
3. ＩＥＴＦと他のところの進行中の仕事
4. Comments and Issues
4. コメントと問題
4.1. The end to end principle under challenge
4.1. 挑戦の元でのエンドエンド原則
4.2. Failure handling
4.2. 障害の取り扱い
4.3. Failures at multiple layers
4.3. 多層に関わる失敗
4.4. Multihop application protocols
4.4. 多ホップアプリケーションプロトコル
4.5. Common features
4.5. 共通の特徴
5. Security Considerations
5. セキュリティの考察
6. Acknowledgements
6. 謝辞
7. References
7. 参考文献
Authors' Addresses
著者のアドレス
1. Introduction and Goals
1. 序説と目標
1.1. Terminology
1.1. 用語
The phrase "middlebox" was coined by Lixia Zhang as a graphic
description of a recent phenomenon in the Internet. A middlebox is
defined as any intermediary device performing functions other than
the normal, standard functions of an IP router on the datagram path
between a source host and destination host.
語句「中間箱」はインターネットの最近の現象の描写としてLixia Zhangによっ
て造り出されました。中間箱が、ソースホストと宛先ホストの間にデータパ
ス上にある、ＩＰルータの通常の標準的な機能以外の機能を実行している、
中間の装置と定義されます。
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.
ある論議、特にＨＴＴＰトラフィックに集中している議論で、単語「仲裁人」
は使われます。現在の文書で、我々はより写実的な語句の方が好きです。も
ちろん、中間箱がは架空で、何か他の箱の埋め込まれた機能であり得ます。
これは物理的な箱を示すと解釈されるべきではありません。これは１つのＩ
Ｐパケットの流れを終結し他の流れを創作する装置、あるいはＩＰパケット
フローをなんらかの方法でを転送や転換する装置や、その組合わせかもしれ
ません。いずれの場合でも、これは決してアプリケーションセッションの根
本的な末端システムではありません。
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.
標準的なＩＰルーティング機能（すなわち、[RFC 1812]で記述された経路発
見と選択機能とそのＩＰｖ６の同等物）は中間箱機能とは考えられません、
標準ＩＰルータがＩＰパケットに対し本質的に透過です。ＩＰ層の中で起き
ている他の機能が中間箱機能と考えられるかもしれませんが、ＩＰ層の下の
機能が定義から除外されます。
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."
共同体により単語「ルーティング」が使われる方法に相違があります。ある
人々がこれを狭い伝統的なＩＰアドレスに基づいたパス選択、すなわちＩＰ
ルータの決断行動、の意味で使います。他の人が（多分ＵＲＬや他のアプリ
ケーション層文字列に基づく）上位レイヤ決定の意味でこれを使います。い
ずれの場合でも、これは唯一の利用可能な方向へのパケット転送ではなく、
外行きの方向の選択を暗示します。この文書で、伝統的な意味は「ＩＰルー
ティング」として常に限定されています。
1.2. The Hourglass Model, Past and Future
1.2. 砂時計モデル、過去と未来
The classical description of the Internet architecture is based
around the hourglass model [HOURG] and the end-to-end principle
[Clark88, Saltzer]. The hourglass model depicts the protocol
architecture as a narrow-necked hourglass, with all upper layers
riding over a single IP protocol, which itself rides over a variety
of hardware layers.
インターネット体系の古典派の記述は砂時計モデル[HOURG]とエンドエンド原
則[Clark88, Saltzer]の周りに基礎を置かれます。砂時計モデルは一つのＩ
Ｐプロトコル上にすべての上位レイヤが乗り、ＩＰプロトコル自身いろいろ
なハードウェアレイヤの上に乗り、プロトコル体系を首の狭い砂時計と描写
するものです。
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.
この体系で、唯一の砂時計の首の箱はＩＰルータです、そしてそれらの唯一
の機能は経路を決定し、パケットを転送することです（その間に転送プロセ
スに必要なフィールドの更新もします）。これはルータが中間装置として分
類されない理由です。
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.
今日、我々は多数の中間装置がネットワークに挿入され、モデルからの逸脱
したＩＰ転送以外の機能を実行しているのに気付きます。一つの見方で、こ
れらの箱はネットワーク層の透過性への挑戦です[RFC 2775]。もう１つの見
方で、これらは砂時計モデルへの挑戦です：ＩＰ層が消え失せないけれども、
すべての通信セッションのひとつの必要な特徴であるＩＰの重要性を中間装
置が弱めます。末端システムでの多様性と機能の集中の代わりに、これらは
多様性と機能をネットワークに広めました。
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.
* 中間装置が新しい障害状態を導入します；壊れたルータの周りのＩＰパケッ
トのリルーティングは考慮すべき唯一の場合ではありません。壊れた中間
装置に伴うセッションの運命も同じく考慮されなくてはなりません。
* 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.
* 失敗と設定誤りの診断はより複雑です。
1.4. Goals of this Document
1.4. この文書の目標
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.
* ＩＥＴＦとＩＲＴＦでされるべき追加の仕事を識別するため。
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.
文書は初めに中間装置の一覧を確立し、そして論議と結論に進む前に、中間
装置に関する以前と現在のＩＥＴＦの仕事を引用します。
2. A catalogue of middleboxes
2. 中間装置一覧
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.
断り書き：これらの側面、異なる種類の中間箱の多数の相違点と、と特定の
種類の装置を含むか否かの決定は、ある程度主観的です。この文書のドラフ
トにコメントした皆が我々の分類の記述と意見が一致しているわけではあり
ません。我々は次の一覧が数学的に完全で一貫しているとは主張しません、
そしてある場合には純粋に恣意的な選択がされ、あるいは曖昧性が残ってい
ます。それで、この文書は決定的と宣言しません。
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. プロトコル層。箱はＩＰ層、輸送層、上位層、あるいはその混合のどこで
動作しますか？
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. 明示対暗黙。中間箱機能はＳＭＴＰリレーのような使用中のプロトコルの
明示的な設計特徴か？あるいはネットワークアドレス翻訳者のように、プ
ロトコル設計で予知されていない、恐らく見えない、付加物ですか？
3. Single hop versus multi-hop. Can there be only one box in the
path, or can there be several?
3. 単一ホップ対多ホップ。パスにただ１だけの箱があり得ますか、あるいは
いくつもあり得ますか？
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.
ノート：多くの種類の中間箱がＩＰパケット分割と組み立てを行う必要があ
るかもしれません。これはある特定の場合にだけ言及されます。
2.1 NAT
2.1 ＮＡＴ
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.
ネットワークアドレス翻訳。しばしばルータに作られ、グローバルユニーク
アドレスを持たないホストに、ホストの知識無しで、動的にグローバルユニー
クアドレスを割り当てる、機能です。結果として、すべてのそのホストに／
からのパケットの中の適切なアドレスフィールドはその場その場で翻訳され
ます。ＮＡＴがＩＰアドレス依存のアプリケーションプロトコルに不適合な
ので、ＮＡＴが実際には常にＡＬＧ（アプリケーションレベルゲートウェイ−
下記参照）を伴います。それはチェックサムを修正のため輸送層にも触れま
す。
NATs have been extensively analysed in the IETF [RFC 2663, RFC 2993,
RFC 3022, RFC 3027, etc.]
ＮＡＴはＩＥＴＦで広範囲に分析されました[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]。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart}
{1 ＩＰ層, 2 暗黙, 3 多ホップ, 4 インライン, 5 機能的, 6 処理,
7 ハード, 8 再起動}
2.2 NAT-PT
2.2 ＮＡＴ−ＰＴ
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-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.
ＮＡＴ−ＰＴ自身はそのプロトコル翻訳機能をステートレスＩＰ／ＩＣＭＰ
翻訳アルゴリズム（ＳＩＩＴ）メカニズム[RFC 2765]に依存します。実際は、
ＳＩＩＴとＮＡＴ−ＰＴは連携したＡＬＧを必要とするでしょう、そして輸
送チェックサムに触れる必要があるでしょう。ＩＰｖ４でＵＤＰチェックサ
ムの省略が認められてるので、ＩＰｖ４からＩＰｖ６へのチェックサムのな
い分割ＵＤＰの翻訳は絶望的です。ＮＡＴ−ＰＴとＳＩＩＴは、特にパスＭ
ＴＵ探索をしない端末を扱う時（あるいはパスＭＴＵ探索を絶ち切る他の中
間装置を通る時）、他の分裂／ＭＴＵ問題の可能性があります。ＩＣＭＰ翻
訳が同じくある手に負えない困難を持っています。
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].
ＮＡＴ−ＰＴはＮＧＴＲＡＮＳ作業班[RFC 2766]からの標準提案です。デュ
アルスタック移行メカニズムは２番目の類似の中間箱、ＤＳＴＭサーバを
加えます[DSTM]。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
processing, 7 hard, 8 restart}
{1 ＩＰ層, 2 暗黙, 3 多ホップ, 4 インライン, 5 機能的, 6 処理,
7 ハード, 8 再起動}
2.3 SOCKS gateway
2.3 ＳＯＣＫＳゲートウェイ
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.
ＳＯＣＳｖ５[RFC 1928]はクライアントホストが、ファイアウォールを通過
する前に、最初にファイアウォールのＳＯＣＫＳサーバと通信をする、認証
されたファイアウォール通過のためのステートフルなメカニズムです。ファ
イアウォールを出るときに、クライアントではなく、ＳＯＣＫＳサーバが、
ソースＩＰアドレスとポート番号を決定します。クライアントのスタックは
はこれを考慮するために「ＳＯＣＫＳ対応」に違いありません、そしてアド
レスに敏感なアプリケーションがＮＡＴ以上に困惑するかもしれません。し
かしながら、ＳＯＣＫＳゲートウェイはＡＬＧを必要としません。
SOCKS is maintained by the AFT (Authenticated Firewall Traversal) WG.
ＳＯＣＫＳはＡＦＴ（認証されたファイアウォール通過）作業班で維持され
ます。
{1 multi-layer, 2 explicit, 3 multihop, 4 in-line, 5 functional, 6
routing, 7 hard, 8 restart}
{1 多層, 2 明示, 3 多ホップ, 4 インライン, 5 機能的, 6 ルーティング,
7 ハード, 8 再起動}
2.4 IP Tunnel Endpoints
2.4 ＩＰトンネル終端
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.
仮想のプライベートのネットワーク終端を含めて、トンネル終端が、インター
ネットの任意の場所にあるトンネル終端相手とのトンネルを設定するために、
基本的なＩＰサービスを使います。トンネルがインターネットインフラに基
づいた完全に新しい「仮想」ネットワークとネットワークインタフェースを
つくり、これによって多くの新しいサービスを開発します。トンネル終端は
少なくとも部分的に自身のポリシをベースに、そして部分的に周囲のルータ
に見える情報で、転送決定を行います。
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].
トンネル終端がパケットの宛先に基づいてパケットを配達する限りにおいて、
トンネル終端が外のインターネットのエンドエンド原則に従うように思われ
ます。しかしながら、宛先は完全にトンネル入口の近くのルータが予想する
かもしれないことが異なっているかもしれません。同じく、受信トンネルパ
ケットのホップ毎の待遇、例えばＱｏＳの扱いは、トンネルなしで受取った
場合と異なるかもしれません[RFC2983]。
Tunnels also cause difficulties with MTU size (they reduce it) and
with ICMP replies (they may lack necessary diagnostic information).
トンネルがまたＭＴＵサイズ（減少する）とＩＣＭＰ応答で困難を起こしま
す（必要な診断情報が欠けるかもしれない）。
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.
トンネルが何らかの理由で失敗する時、これはユーザーセッションの中断を
起こすかもしれません、あるいは代わりのＩＰ経路が利用可能であるとが分
かるかもしれません、ある場合にはトンネルは自動的に再設立されるかもし
れません。
{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 再起動あるいは故障切替}
2.5. Packet classifiers, markers and schedulers
2.5. パケット分類、マークとスケジューラ
Packet classifiers classify packets flowing through them according to
policy and either select them for special treatment or mark them, in
particular for differentiated services [Clark95, RFC 2475]. They may
alter the sequence of packet flow through subsequent hops, since they
control the behaviour of traffic conditioners.
パケット分類がポリシに従ってパケットを分類し、特別な待遇をするかマー
ク、、特にディフサービスのマーク[Clark95, 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.
分類者やトラフィック調整機が故障する時、ユーザーセッションは接続性の
完全な損失（全パケットの廃棄）か、最良努力のサービス（すべてのパケッ
トはデフォルトＱｏＳに与えられる）か、元のサービスレベルへの自動修復
の、どれかの結果かもしれません。
{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 故障切替あるいは再起動}
2.6 Transport relay
2.6 輸送リレー
Transport relays are basically the transport layer equivalent of an
ALG; another (less common) name for them is a TLG. As with ALGs,
they're used for a variety of purposes, some well established and
meeting needs not otherwise met. Early examples of transport relays
were those that ran on MIT's ITS and TOPS-20 PDP-10s on the ARPANET
and allowed Chaosnet-only hosts to make outgoing connections from
Chaosnet onto TCP/IP. Later there were some uses of TCP-TP4 relays.
A transport relay between IPv6-only and IPv4-only hosts is one of the
tools of IPv6 transition [TRANS64]. TLGs are sometimes used in
combination with simple packet filtering firewalls to enforce
restrictions on which hosts can talk to the outside world or to
kludge around strange IP routing configurations. TLGs are also
sometimes used to gateway between two instances of the same transport
protocol with significantly different connection characteristics; it
is in this sense that a TLG may also be called a TCP or transport
spoofer. In this role, the TLG may shade into being an optimising
rather than a functional middlebox, but it is distinguished from
Transport Proxies (next section) by the fact that it makes its
optimisations only by creating back-to- back connections, and not by
modification or re-timing of TCP messages.
輸送リレーは基本的にＡＬＧの輸送層の同等物です；これらの（一般性が低
い）他の名前がＴＬＧです。ＡＬＧと同じように、これらはいろいろな目的
で使われ、いくつかは他の方法では出会えない場合に接続を確立し出会うた
めに使われます。初期の輸送リレーの例は、ＡＲＰＡＮＥＴでのＭＩＴのＩ
ＴＳやTOPS-20 PDP-10で動くので、カオスネットだけのホストがカオスネッ
トからＴＣＰ／ＩＰに出接続するのを許しました。後であるＴＣＰ−ＴＣ４
リレーの使用がありました。ＩＰｖ６だけとＩＰｖ４だけのホストの間の輸
送リレーはＩＰｖ６移行の道具の１つです[TRANS64]。ＴＬＧはホストが外の
世界や奇妙なＩＰルーティング設定の周りにいるクラッジと話をすることが
できる制限を実施するために、時々単純なパケットフィルタリングファイア
ウォールと共に使われます。ＴＬＧはしばしば異なる接続特性の同じ２つの
輸送プロトコルの間のゲートウェイでも使われます；ＴＬＧがＴＣＰあるい
は輸送スパイと呼ばれるかもしれないのはこの意味です。この役割で、ＴＬ
Ｇは機能的な中間箱というより少し最適化で、けれどもこれはただ連続した
接続を作りＴＣＰメッセージの修正やタイミング変更をしないので輸送プロ
キシ（次の章）と区別されます。
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.
１つのＴＣＰ接続を終了させることと、他の中間パスを始めることはＴＣＰ
チェックサムが送信者のデータをエンドエンドでカバーしないことを意味し
ます。データが初めから２番目の接続に転送される時、データ悪用や修正処
理があるかもしれません。あるＴＣＰリレーが分裂リレーであり、２つ以上
のＴＣＰ接続と多数のノードとネットワークパスが関係するので、、データ
完全性が失われる確立がより高いです。例外なく、送信者の期待できるデー
タ完全性の保障は、ＴＣＰ信頼バイト流サービスより低いです。この問題が
中間装置固有ではなく、例えば送信者のチェックサム検査をしないＴＣＰ実
装でも起きることに注意してください。
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.
このような場合のいくつかで、ＳＳＨやＨＴＴＰＳのような他のセッション
レイヤ機構がＴＣＰレベルでデータ完全性が失われた事を検出し、ＴＣＰの
再送は起こさないが、セッション失敗を起こすかもしれません。しかしなが
ら、ＴＣＰデータ完全性の欠如を検出するか、あるいは和らげることができ
るため、アプリケーションデータ完全性を加える一般的なセッションメカニ
ズムがありません。
{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 再起動}
2.7. TCP performance enhancing proxies
2.7. ＴＣＰ性能拡張プロキシ
"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.
「ＴＣＰスパイ」がしばしば性能拡張のためにＴＣＰプロトコルのタイミン
や動作を修正する中間装置の用語として用いられます。より正確な名前がＴ
ＣＰ性能拡張プロキシ（ＰＥＰ）です。多くのＴＣＰＰＥＰは専用技術であ
り、そしてそれらが標準ＴＣＰと互換性エラーを起こす時に主にオープンイ
ンターネットで述べられました。ＴＬＧと同じように、ＴＣＰＰＥＰは他の
方法では満たされない必要性を満たす状況があります。例えば、ＴＣＰＰＥ
ＰがバーストサービスリンクによってまとまったＡＣＫに再間隔を提供し、
望まないデータセグメントバーストを避けてもよいです。ＰＩＣＬ（リンク
特徴の性能暗示）作業班ははＴＣＰＰＥＰの種類とそれらの適用性を分析し
ました[PILCPEP]。ＴＣＰＰＥＰはＴＣＰエラーだけではなくＴＣＰ適応性行
動の思いがけない変更を導入することがあります。
{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.)
意図的なＩＰ宛先へのパケットの流れを変えるか、その宛先を曖昧にするい
ろいろな技法です。一般的な動機はサーバ間の負荷の均等化や、あるいは宛
先ポート番号に基づいたＩＰルーティングによってサーバのアプリケーショ
ンを分けることです。まれな１回だけのＵＤＰプロトコル以外、これらの技
法は、すべての同じアプリケーションセッションのパケットが同じ物理的な
サーバに向かう必要があるので、必然的にステートフルです。（しかしなが
ら、洗練された解決策は故障切替を処理することが可能であるでしょう。）
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 再起動}
2.9. IP Firewalls
2.9. ＩＰファイアウォール
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.)
ファイアウォールの最も単純な形式は純粋にＩＰと輸送ヘッダのフィールド
に基づいてパケットを検査し拒絶するルータです（例えば、ある特定のポー
ト番号に入ってくるトラフィックを拒絶して、ある特定のサブネットへはど
んなトラフィックも拒絶する、など）。
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.
純粋なＩＰファイアウォールが通過するパケットを変えないが、いくつかの
パケットを拒絶することによって、ユーザに理解と診断が非常に難しい接続
性問題を起こすかもしれません。
"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.
「ステートレス」ファイアウォールは、ＩＰ分割破片がフィルタ決定に必要
な十分な上位レイヤヘッダ情報を含んでいないので、典型的に全てのＩＰ分
割破片の通過を許します。従って多くの「ステートフル」ファイアウォール
が、特に終端受信者の組立て実装のバグを利用する破片の漏れを避けるため、
ＩＰ分割破片を組立て（そして必要なら再分割し）ます。
{1 IP layer, 2 implicit, 3 multihop, 4 in-line, 5 functional, 6
routing, 7 hard, 8 restart}
{1 ＩＰ層, 2 暗黙, 3 多ホップ, 4 インライン, 5 機能的,
6 ルーティング, 7 ハード, 8 再起動}
2.10. Application Firewalls
2.10. アプリケーションファイアウォール
Application-level firewalls act as a protocol end point and relay
(e.g., an SMTP client/server or a Web proxy agent). They may
アプリケーションレベルファイアウォールがプロトコル終端とリレーの役を
務めます（例えば、ＳＭＴＰクライアント／サーバあるいはウェブプロキ
シエージェント）。これらは、
(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]。ＨＴＴＰを使っているファイアウォール横断の問題は論じられ
ました[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 再起動}
2.11. Application-level gateways
2.11. アプリケーションレベルゲートウェイ
These come in many shapes and forms. NATs require ALGs for certain
address-dependent protocols such as FTP; these do not change the
semantics of the application protocol, but carry out mechanical
substitution of fields. At the other end of the scale, still using
FTP as an example, gateways have been constructed between FTP and
other file transfer protocols such as the OSI and DECnet (R)
equivalents. In any case, such gateways need to maintain state for
the sessions they are handling, and if this state is lost, the
session will normally break irrevocably.
これらは多くの形と形式であります。ＮＡＴはＦＴＰのようなある特定のア
ドレスに依存するプロトコルのためにＡＬＧを必要とします；これらはフィー
ルドの機械的操作をするだけで、アプリケーションプロトコルの意味を変え
ません。他の終端で、ＦＴＰを例として、ＦＴＰとＯＳＩやＤＥＣｎｅｔ(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).
あるＡＬＧが同じく、この場合問題が多分故意のレイヤ違反の結果であるが、
分割の問題を作る方法で実装されます（例えば、その場その場でＴＣＰ部分
をいじって、ＦＴＰ制御接続のアプリケーションデータ流を変えます）。
{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 再起動}
2.12. Gatekeepers/ session control boxes
2.12. 門番／セッション制御箱
Particularly with the rise of IP Telephony, the need to create and
manage sessions other than TCP connections has arisen. In a
multimedia environment that has to deal with name lookup,
authentication, authorization, accounting, firewall traversal, and
sometimes media conversion, the establishment and control of a
session by a third-party box seems to be the inevitable solution.
Examples include H.323 gatekeepers [H323], SIP servers [RFC 2543] and
MEGACO controllers [RFC 3015].
特にＩＰ電話で、ＴＣＰ接続以外のセッションを起こし、管理する必要が生
じました。マルチメディア環境でこれは名前検索と認証と認可と課金とファ
イアウォール通過としばしまメディア変換を扱わなければなりません、第三
者箱によるセッションの設立と管理が避けられない解決であるように思われ
ます。例えば、Ｈ．３２３門番[H323]とＩＰサーバ[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 再起動？}
2.13. Transcoders
2.13. トランスコーダ
Transcoders are boxes performing some type of on-the-fly conversion
of application level data. Examples include the transcoding of
existing web pages for display on hand-held wireless devices, and
transcoding between various audio formats for interconnecting digital
mobile phones with voice-over-IP services. In many cases, such
transcoding cannot be done by the end-systems, and at least in the
case of voice, it must be done in strict real time with extremely
rapid failure recovery.
トランスコーダはあるアプリケーションレベルデータをその場で変換する種
類の箱です。例えば、既存のウェブページを手持ち無線装置のディスプレイ
用に変換するのや、デジタル移動電話をＩＰ電話サービスと相互接続するた
めに種々な音声フォーマットに変換するのを含みます。多くの場合、このよ
うな変換は末端システムにでできません、そして少なくとも音声の場合、厳
密なリアルタイムで非常に速い失敗回復をするに違いありません。
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 Application layer, 2 explicit or implicit, 3 single hop, 4 in-
line, 5 functional, 6 processing, 7 hard?, 8 restart or failover}
{1 アプリケーション層, 2 暗黙あるいは明示, 3 単一ホップ, 4 インライン,
5 機能的, 6 処理, 7 ハード？, 8 再起動あるいは故障切替}
2.14. Proxies
2.14. プロキシ
HTTP1.1 [RFC 2616] defines a Web proxy as follows:
ＨＴＴＰ１．１[RFC 2616]が次のようにウェブプロキシを定義します：
"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.
ファイアウォールは外向のＨＴＴＰパケットを許さない時、ウェブプロキシ
がファイアウォールと結び付けられるかもしれません。しかしながら、ＨＴ
ＴＰはプロキシの使用を「故意」にします：クライアントはプロキシを使う
ように設定されなくてはなりません。
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.
ＨＴＴＰプロキシが実際ＩＰパケット流れを終端し、新しいものを生成しま
すが、実際のアプリケーションセッションがこれを横断するので、１.１章で
与えた「中間箱」の定義に合致することに注意してください。
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.)
ＳＩＰプロキシ[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.
ノート：あるいわゆるウェブプロクシがＨＴＴＰパケットを途中で捕えて、
自身のソースアドレスでそれらを再発行する「傍受」装置として実装されま
した；ＮＡＴとソックスのように、これはアドレスに敏感なアプリケーショ
ンを乱します。不幸にもあるベンダがこれらと「透明」プロキシを間違えて
描写することによって混乱を起こしました。傍受装置は透明でありません。
完全な論議は[WREC]を見てください。
2.15. Caches
2.15. キャッシュ
Caches are of course used in many shapes and forms in the Internet,
and are in principle distinct from proxies. Here we refer mainly to
content caches, intended to optimise user response times. HTTP makes
provision for proxies to act as caches, by providing for both
expiration and re-validation mechanisms for cached content. These
mechanisms may be used to guarantee that specific content is not
cached, which is a requirement for transient content, particularly in
transactional applications. HTTP caching is well described in
Section 13 of [RFC 2616], and in the HTTP case caches and proxies are
inextricably mixed.
キャッシュがもちろんインターネットで多くの形と形式で使われ、そして原
則としてプロキシと異なっています。ここで我々は主に、ユーザ応答時間を
最適化するように意図される、コンテンツキャッシュを言います。ＨＴＴＰ
は、キャッシュされた内容の期限と再確認メカニズムを提供することによっ
て、プロキシがキャッシュの役を務めるために規定をします。これらのメカ
ニズムは特定の内容がキャッシュされないことを保証するために使われるか
もしれず、そしてこれは特に対話アプリケーションの一時的内容のための必
要条件です。ＨＴＴＰキャッシュが[RFC 2616]の１３章で記述され、ＨＴＴ
Ｐの場合キャッシュとプロキシは複雑に入り混ざっています。
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]のような代わりの提案があった
けれども、インターネットキャッシュプロトコル（ＩＣＰ）[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.
キャッシュがアプリケーションセッションを終結するので、（ＳＭＴＰリレー
を含める以上に）中間箱に含むべきではないと論じることができます。しか
しながら、キャッシュがキャッシュミスの場合にクライアントのＨＴＴＰ要
求を再発行するので、我々は独断的にそれらを含めることに決めました、そ
してこれらはアプリケーションデータの根本的な情報源ではありません。
{1 Application layer, 2 explicit (if HTTP proxy caches), 3 multihop,
4 in-line, 5 functional, 6 processing, 7 soft, 8 restart}
{1 アプリケーション層, 2 明示(HTTPプロキシキャッシュ), 3 多ホップ,
4 インライン, 5 機能的, 6 処理, 7 ソフト, 8 再起動}
2.16. Modified DNS servers
2.16. ＤＮＳサーバ修正
DNS 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").
ＤＮＳサーバはゲームができます。すべての問合せ対する文法的に正しい回
答を届けるように思われる限り、それらは意味的に騙されます。例えば、ネッ
トワークの異なる部分の異なるＩＰアドレスを確認するように手配をするこ
とで名前を「エニキャスト」にできます。ローカルなＤＮＳサーバが順に異
なったサーバアドレスを返すようにすることにで、サーバ群の異なるメンバ
と負荷を共有できます。ＮＡＴ環境で、ＮＡＴの内外でＦＱＤＮとアドレス
の対応が異なるのは珍しくありません（「表裏ＤＮＳ」）。
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.
修正されたＤＮＳサーバは対象のアプリケーションデータ流の中間者ではあ
りません。それらは、同一レベルにおいける独立のセッションで一つのホス
トが関係すると思われるのが多数のホストに関係することを意味するので、
これは微妙な効果を持つことができます。あるセッションによりホスト
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.
もしこのようなＤＮＳサーバが故障するなら、ユーザが同じトリックを知ら
ない代わりのＤＮＳサーバに切替え、何らかの結果で失敗するかもしれませ
ん。
{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 インライン（ＤＮＳ問合
せパス上で）, 5 機能的または最適化, 6 処理, 7 ソフト, 8 故障切替}
2.17. Content and applications distribution boxes
2.17. コンテンツとアプリケーション分散箱
An emerging generalisation of caching is content distribution and
application distribution. In this model, content (such as static web
content or streaming multimedia content) is replicated in advance to
many widely distributed servers. Further, interactive or even
transactional applications may be remotely replicated, with some of
their associated data. Since this is a recent model, it cannot be
said that there is an industry standard practice in this area. Some
of the issues are discussed in [WREC] and several new IETF activities
have been proposed in this area.
キャッシュの発生の一般論はコンテンツ分散とアプリケーション分散です。
このモデルで、コンテンツ（静的ウェブの内容あるいはストリーミングマル
チメディア内容など）が多くの広く分散されたサーバに前もって複製されま
す。さらに、対話型や、あるいは処理アプリケーションでもが、それらの関
連づけられたデータのいくつかが、間接的に複製されるかもしれません。こ
れが最近のモデルなので、このエリアに工業的標準慣習があると言えません。
ある問題が[WREC]で論じられ、そしていくつかの新しいＩＥＴＦ活動がこの
エリアで提案されました。
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.COMへ
送られた要求をWWW.EXAMPLE.NETへＨＴＴＰ転送し、後者の名前が上記の通
り「エニキャスト」名であるかもしれなくて、コンテンツ分散箱の近い実体
を解決するでしょう。
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 再起動}
2.18. Load balancers that divert/munge URLs
2.18. ＵＲＬの迂回や変更をする負荷分散装置
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.
ＤＮＳトリックのように、ＵＲＬ転送はサーバ群の間で負荷分散に使われま
す−本質的にコンテンツのローカルなバージョンがネットワークに分散しま
す。代わりに、ＨＴＴＰプロキシがサーバ群の特定のサーバに向けてＨＴＴ
Ｐ要求を書き直すことができます。
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 再起動}
2.19. Application-level interceptors
2.19. アプリケーションレベル横取り
Some forms of pseudo-proxy intercept HTTP packets and deliver them to
a local proxy server instead of forwarding them to the intended
destination. Thus the destination IP address in the packet is
ignored. It is hard to state whether this is a functional box (i.e.,
a non-standard proxy) or an optimising box (i.e., a way of forcing
the user to use a cache). Like any non-standard proxy, it has
undefined consequences in the case of dynamic or non-cacheable
content.
ある疑似プロキシの設定は、ＨＴＴＰパケットを途中で捕えて、それらを本
来の宛先に転送する代わりにローカルなプロクシサーバに配達します。それ
でパケットの宛先ＩＰアドレスは無視されます。これが機能箱（すなわち、
非標準のプロキシ）なのか最適化箱（すなわち、ユーザにキャッシュを使う
ことを強いる方法）なのかを述べることは難しいです。非標準プロクシのよ
うに、これは動的あるいはキャッシュ不可能コンテンツの場合に不確定な結
果を生じます。
{1 Application layer, 2 implicit, 3 single hop, 4 in-line, 5
functional or optimising, 6 routing, 7 hard, 8 restart}
{1 アプリケーション層, 2 暗黙, 3 単一ホップ, 4 インライン,
5 機能的あるいは最適化, 6 ルーチング, 7 ハード, 8 再起動}
2.20. Application-level multicast
2.20. アプリケーションレベルマルチキャスト
Some (mainly proprietary) applications, including some approaches to
instant messaging, use an application-level mechanism to replicate
packets to multiple destinations.
ある（主に専用の）アプリケーションで、ある即時メッセージ交換の方法を
含めて、多数の宛先にパケットを複製するためにアプリケーションレベルメ
カニズムを使います。
An example is given in [CHU].
例えば[CHU]です。
{1 Application layer, 2 explicit, 3 multihop, 4 in-line, 5
functional, 6 routing, 7 hard, 8 restart}
{1 アプリケーション層, 2 明示, 3 多ホップ, 4 インライン,
5 機能的, 6 ルーチング, 7 ハード, 8 再起動}
2.21. Involuntary packet redirection
2.21. 何気ないパケット転送
There appear to be a few instances of boxes that (based on
application level content or other information above the network
layer) redirect packets for functional reasons. For example, more
than one "high speed Internet" service offered in hotel rooms
intercepts initial HTTP requests and diverts them to an HTTP server
that demands payment before opening access to the Internet. These
boxes usually also perform NAT functions.
（アプリケーションレベルの内容やネットワーク層の他の情報に基づいて）
機能的な理由でパケットを転送する少数の箱の例があるように思われます。
例えば、ホテルの部屋の「高速インターネット」サービスのいくつかはＨＴ
ＴＰ要求を途中で捕えて、インターネットアクセスを行う前に支払いを要求
するＨＴＴＰサーバに転送します。これらの箱は通常同じくＮＡＴ機能を実
行します。
{1 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 再起動}
2.22. Anonymisers
2.22. 匿名化
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.
匿名化箱がデータ送信者あるいは受信者のＩＰアドレスを隠す様々な方法を
実装します。実装は異なるが、これはＮＡＴとＡＬＧに非常に類似していま
す。
{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 再起動}
2.23. Not included
2.23. 含まれない
Some candidates suggested for the above list were excluded for the
reasons given below. In general, they do not fundamentally change
the architectural model of packet delivery from source to
destination.
上記のリストに勧められた候補のいくつかは、下記の理由で除外されました。
一般に、これらはソースから宛先までの基本的なパケット配達の体系モデル
を変えません。
Bridges and switches that snoop ARP, IGMP etc. These are below the
IP layer, but use a layer violation to emulate network layer
functions. They do not change IP layer functions.
ＡＲＰやＩＧＭＰなどを覗くブリッジやスイッチ。これらはＩＰレイヤの下
にありますが、ネットワーク層機能を模倣するためにレイヤ違反を使います。
これらはＩＰ層の機能を変えません。
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.
モバイルＩＰホームエージェントは本来望ましい宛先にパケット配達するの
を支援するように意図されます、それでこれらは標準ルータと同じ理由で除
外されます。
Relays in interplanetary networks - although these would certainly
appear to be middleboxes, they are not currently deployed.
惑星間ネットワークのリレー−これらが確かに中間装置であるように思われ
るが、現在配置されていません。
2.24. Summary of facets
2.24. 側面の要約
By tabulating the rough classifications above, we observe that of the
22 classes of middlebox described:
上におおざっぱな分類を表にすることによって、我々は記述された２２種類
の中間箱を観察します：
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.
我々は、現在の種類の中間箱は、主にアプリケーションレイヤ装置で、適切
なプロトコルの一部として計画されず、必要とされる機能を実行し、ハード
状態を維持し、故障時にユーザーセッションを中止する、と推論することが
できます。本当にこれはエンドエンド砂時計モデルに深い挑戦を表します。
3. Ongoing work in the IETF and elsewhere
3. ＩＥＴＦと他のところの進行中の仕事
Apart from work cited in references above, current or planned work in
the IETF includes:
上に参照で引合いに出された仕事以外で、ＩＥＴＦの現在か計画された仕事：
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].
ＭＩＤＣＯＭ−要求装置と中間箱の間のプロトコルの体系骨格と要求条件と、
中間箱とポリシエンティティ間のインターフェース体系骨格、を対象とした作
業班[MIDFRAME, MIDARCH]。これはセッション制御問題[SIPFIRE]と相互作用す
るかもしれません。
Work is also proceeding outside the MIDCOM group on middlebox
discovery [MIDDISC].
仕事が中間箱探索上のＭＩＤＣＯＭグループ外で同じく進んでいます[MIDDISC]。
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.
ＷＥＢＩ（ウェブ仲裁人）−いくつかのアプリケーション範囲（例えば、プ
ロキシ、コンテンツ配達代理）で有用な一般的な機構を供給することで、
（ＷＲＥＣ作業班で識別された）世界規模のくもの巣の基盤での特定の問題
を扱う作業班。特定の機構は中間探索と記述と資源更新プロトコルです。
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]が公表されました。
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.
ＯＰＥＳ（開放差込可能拡張サービス）−関連中間装置によってアプリケー
ションデータ上で実行するサービス構築が可能にするための、提案された作
業班。キャッシュは最も基本的な中間サービスで、キャッシュサーバによっ
てのアプリケーションの意味の基本的な了解を必要とします。
CDI (Content Distribution Internetworking) is a potential working
group for allowing cooperation between different Content Distribution
Networks and cache clusters [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.
ＲＳＷＲＰＯＯＬ（信頼サーバ群）は、多種のアプリケーションからの要求
や、構築ブロックとインターフェースや、異なる群の形や、セキュリティ要
件や、故障時間や混成遅延などの性能要件を含む、サーバ群の管理とアクセ
スの体系と要求条件を定義する作業班です。
4. Comments and Issues
4. コメントと問題
A review of the list in Section 2 suggests that middleboxes fit into
one or more of three broad categories:
２章のリストの評価から、中間装置が３つの広い区分に含まれることが示唆
されます：
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]の一般的な適用に疑問を投げかけます。中間装置がエンドエンド原則の
運命共有面を侵害する、依存と隠れた故障点を導入します。我々は中間装置
の存在下で、安定を保証する体系原則を定義することができますか？
4.1. The end to end principle under challenge
4.1. 挑戦の元でのエンドエンド原則
Many forms of middlebox are explicitly addressed at the IP level, and
terminate a transport connection (or act as a final destination for
UDP packets) in a normal way. Although they are potential single
points of failure, they do not otherwise interfere with the end to
end principle [RFC 1958]. (This statement does not apply to
transport relays or TCP spoofers; they do not terminate a transport
connection at the expected destination in the normal way.)
中間箱の多くの形式はＩＰレベルで明示的に扱われ、そして標準的な方法で
輸送接続を終えます（あるいはＵＤＰパケットの最終の宛先の役を務めます）。
それらが単一障害点である可能性があるけれども、それ以外はエンドエンド
原則[RFC 1958]を妨害しません。（この宣言は輸送リレーやＴＣＰスパイに
当てはまりません；これらは標準的な方法で期待された宛先で輸送接続を終
了させません。）
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.
しかしながら、その意図する宛先から転送し、あるいは実質的にその場その
場でその内容を修正する中間装置は、基本的に正確に輸送接続を終えて、ア
プリケーションレベルで取り扱いを実行する者とは異なっているという一般
的な感じがあります。このような転送あるいは修正が（寿命と品質関連の
フィールドを除き）パケットが本質的に変化していなでソースから宛先まで
流れるという基本的な体系の仮定に違反します。輸送とアプリケーションに
対するこのような変更の効果は一般的な場合に予想できません。ＮＡＴに適
用される分析の多く[RFC 2993, RFC 3027]が同じくＲＳＩＰやＮＡＴ−ＰＴ
やＤＳＴＭやＳＯＣＫＳや何気ないパケット転送に当てはまるでしょう。横
取りプロキシや匿名化やある種の負荷分散機が、アドレスに敏感なアプリケー
ションに対する微妙な効果を持ち、そしてその時には異なったアドレスにあ
るいはからパケットが配達されます。輸送リレーとＴＣＰスパイがＴＣＰソ
ケット上で当てにならないサービスを配達することによってアプリケーショ
ンをだますかもしれません。
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.
中間装置の存在がパケットレベルにおいてエンドエンド原則上に打撃的な
影響を持つが、これはアプリケーションプロトコル設計で有用か望ましい
原則なので無効にはしません。しかしながら、将来のアプリケーションプ
ロトコルは、データパスに沿って、ネットワークアドレス翻訳やパケット
迂回やパケットレベルファイアウォールの存在を承知で設計されるべきで
す。
4.2. Failure handling
4.2. 障害の取り扱い
If a middlebox fails, it is desirable that the effect on sessions
currently in progress should be inconvenient rather than
catastrophic. There appear to be three approaches to achieve this:
もし中間箱が故障するなら、現在進行中のセッションに対する効果が大惨事
となるより不便であることが望ましいです。これを成し遂げる３つの方法が
あるように思われます：
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:
多分「最適化」中間箱は、箱故障の結果がユーザの大惨事ではないので、ソフ
ト状態方法と非リアルタイムのデータ流で適当な候補であるように思われます。
（キャッシュとして設定されたＨＴＴＰプロキシは、その障害はクライアント
障害を起こします。）他方、「機能的」中間箱はセッションが継続するために
存在しているに違いなくて、速い故障切替か速い再開機構が適当です。我々は
これを終えます：
Middlebox design should include a clear mechanism for dealing with
failure.
中間箱設計が障害を扱うことに対して明確な機構を含むべきです。
4.3. Failures at multiple layers
4.3. 多層に関わる失敗
Difficulties occur when middlebox functions occur at different
layers, for example the following situation, where B and C are not in
the same physical box:
中間箱機能が異なる層に存在する場合に困った事が起こります、例えばＢと
Ｃが異なる物理的な箱の下記の状況です：
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
すべてがあれば、すなわちＡ・Ｂ・Ｃ・ＤのＩＰパスがありＢとＣの両方が
動作する時、これは実行可能に見えるかもしれません。けれども失敗状態は
非常に挑戦的です。例えば、もしＣとＤの間にネットワーク故障があるなら、
どのようにＢがＣに予備箱にセッション流を変えるよう指示しますか？Ｃと
Ｂが異なったプロトコル層で動作するので、失敗回復機構が協調しているで
あろうという期待がありません。これが一般的な方法で修復されないなら、
我々は以下の結論をします
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.
長期的な将来、我々は明確にそれぞれの中間箱機能が環境から何を期待しを
述べる事が可能であるべきで、そして中間箱機能が配置されるなら一緒にあ
るべきものの推薦をすることが可能であるべきです。
4.4. Multihop application protocols
4.4. 多ホップアプリケーションプロトコル
We can also observe that protocols such as SMTP, UUCP, and NNTP have
always worked hop-by-hop, i.e., via multiple middleboxes. Nobody
considers this to be an issue or a problem. Difficulties arise when
inserting a middlebox in an application protocol stream that was not
designed for it. We conclude that:
我々はＳＭＴＰやＵＵＣＰやＮＮＴＰのようなプロトコルが常にホップバイ
ホップと述べることができます、すなわち、多数の中間箱があります。誰も
これが問題であると考えません。中間箱を、中間箱を考慮していないアプリ
ケーションプロトコル流に挿入する時、困難が生じます。我々はこれを終え
ます：
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.
新しいアプリケーションプロトコル設計は中間装置の挿入の明白な機構を
含むべきで、デザインの一部として上記２章で識別された側面を考えるべ
きです。
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.
特定の挑戦は、中間装置上で対話型あるいはリアルタイムアプリケーション
をスムーズに動かす方法です。これは失敗扱の面に特定に重点があるでしょう。
4.5. Common features
4.5. 共通の特徴
Given that the IP layer - the neck of the hourglass - is no longer
alone in its role supporting end-to-end connectivity, it would be
desirable to define requirements and features that are common to
middlebox intermediaries. It would then be possible to implement
middleboxes, and in particular the protocols that communicate with
them, fully from the stance of supporting the end-to-end principle.
Conceptually, this would extend the neck of the hourglass upwards to
include a set of common features available to all (or many)
applications. In the context of middleboxes and multihop protocols,
this would require common features addressing at least:
ＩＰレイヤ−砂時計の首−はもうエンドエンド接続性をサポートする役割の
唯一ではないとすれば、中間箱に共通の必要条件と特徴を定義することは望
ましいでしょう。完全にエンドエンド原則を支援する姿勢で、中間装置と特
にそれらと通信するプロトコルを実装するためにのは、可能であるでしょう。
概念的にこれは、全て（あるいは多くの）アプリケーションに利用可能な共
通特長を含むように、砂時計の首を拡大するでしょう。中間装置と多ホップ
プロトコルの環境で、これは少なくとも以下を扱う共通の特徴を必要とする
でしょう：
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.
可能な限り、ＩＥＴＦとＷ３Ｃで発展しているこれらのエリアでの解決策は
あらゆる種類の中間箱をカバーするだけ十分に一般的であるべきです；もし
そうでなければ、仕事が数回されるでしょう。
5. Security Considerations
5. セキュリティの考察
Security risks are specific to each type of middlebox, so little can
be said in general. Of course, adding extra boxes in the
communication path creates extra points of attack, reduces or
eliminates the ability to perform end to end encryption, and
complicates trust models and key distribution models. Thus, every
middlebox design requires particular attention to security analysis.
A few general points can be made:
セキュリティリスクはそれぞれの種類の中間箱に固有で、わずかしか一般的
に言えません。もちろん、通信パスで余分の箱を加えることは余分の攻撃点
を作り、エンドエンド暗号化の能力の減少か排除をし、信頼モデルと鍵配布
モデルを複雑にします。それで、すべての中間箱設計はセキュリティ分析に
特定の注意を必要とします。少数の一般的な点は以下です：
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. 多くの種類の中間箱によるエンドエンドパケット転送の干渉は、現在の形
式のＩＰｓｅｃの一般化された使用に対する大きい障害であり、そして多
くのシナリオで同じく輸送レイヤセキュリティを無効にします。
2. Middleboxes require us to move definitively from a two-way to an
N-way approach to trust relationships and key sharing.
2. 中間装置は信頼関係と鍵共有で双方向からＮ方向の方法に決定的に動くよ
うに要求します。
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.
さらに、コンテンツキャッシュとコンテンツ分散メカニズムが著作権あるい
は他の権利の適用を受けているコンテンツのためにアクセス制御の問題を起
こします。分散認証と認可と課金が必要とされます。
6. Acknowledgements
6. 謝辞
Steve Bellovin, Jon Crowcroft, Steve Deering, Patrik Faltstrom,
Henning Schulzrinne, and Lixia Zhang all gave valuable feedback on
early versions of this document. Rob Austein and Allison Mankin
drafted the text on transport relays and TCP spoofers, and Rob
Austein made other substantial contributions. Participants in the
MIDTAX BOF at the 50th IETF and on the MIDTAX mailing list, including
Harald Alverstrand, Stanislav Shalunov, Michael Smirnov, Jeff Parker,
Sandy Murphy, David Martin, Phil Neumiller, Eric Travis, Ed Bowen,
Sally Floyd, Ian Cooper, Mike Fisk and Eric Fleischman gave
invaluable input. Mark Nottingham brought the W3C work to our
attention. Melinda Shore suggested using a facet-based
categorization. Patrik Faltstrom inspired section 4.3.
Steve BellovinとJon CrowcroftとSteve DeeringとPatrik Faltstromと
Henning SchulzrinneとLixia Zhangはこの文書の初期の版に貴重なフィード
バックをしました。Rob AusteinとAllison Mankinは輸送リレーとＴＣＰス
パイのテキストを立案し、Rob Austeinは他の相当な貢献をしました。第５
０回ＩＥＴＦのＭＩＤＴＡＸ ＢＯＦの関係者と、Harald Alverstrandと
Stanislav ShalunovとMichael SmirnovとJeff ParkerとSandy Murphyと
David MartinとPhil NeumillerとEric TravisとEd BowenとSally Floydと
Ian CooperとMike FiskとEric Fleischmanを含むＭＩＤＴＡＸメーリング
リストの関係者が貴重な入力を与えました。Mark Nottinghamが我々の注意
をＷ３Ｃの仕事に向けました。Melinda Shoreは側面ベースの分類を使うこ
とを提案しました。Patrik Faltstromは４.３章を触発しました。
7. References
7. 参考文献
[RFC 1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and
L. Jones, "SOCKS Protocol Version 5", March 1996.
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC 2186] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP),
version 2", RFC 2186, September 1997.
[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 2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 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, June 1999.
[RFC 2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC 2756] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol
(HTCP/0.0)", RFC 2756, January 2000.
[RFC 2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC 2775] Carpenter, B., "Internet Transparency", RFC 2775, February
2000.
[RFC 2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC 2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC 3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.
and J. Segers, "Megaco Protocol 1.0", RFC 3015, November
2000.
[RFC 3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC 3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027, January
2001.
[CHU] Y. Chu, S. Rao, and H. Zhang, A Case for End System
Multicast, SIGMETRICS, June 2000.
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).
[CLARK95] "Adding Service Discrimination to the Internet", D.D.
Clark, Proceedings of the 23rd Annual Telecommunications
Policy Research Conference (TPRC), Solomons, MD, October
1995.
[CDNP] M. Day, et al., "A Model for Content Internetworking
(CDI)", Work in Progress.
[DSTM] J. Bound, L. Toutain, F. Dupont, O. Medina, H. Afifi, A.
Durand, "Dual Stack Transition Mechanism (DSTM)", Work in
Progress.
[H323] ITU-T Recommendation H.323: "Packet Based Multimedia
Communication Systems".
[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.
[HTTPSUB] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, February 2002.
[MIDARCH] E. Lear, "A Middlebox Architectural Framework", Work in
Progress.
[MIDDISC] E. Lear, "Requirements for Discovering Middleboxes", Work
in Progress.
[MIDFRAME] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A.
Rayhan, "Middlebox Communication: Framework and
Requirements", Work in Progress.
[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.
[RSIP] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro,
"Realm Specific IP: Framework", RFC 3102, October 2001.
[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.
[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.
[SOCKS6] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
RFC 3089, April 2001.
[TRANS64] "Overview of Transition Techniques for IPv6-only to Talk
to IPv4-only Communication", Work in Progress.
[WREC] Cooper, I, Melve, I. and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[XMLPI] Intermediaries and XML Protocol, Mark Nottingham, Work in
Progress at 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
EMail: brian@hursley.ibm.com
Scott W. Brim
146 Honness Lane
Ithaca, NY 14850
USA
EMail: sbrim@cisco.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。