RFC2775 日本語訳
2775 Internet Transparency. B. Carpenter. February 2000. (Format: TXT=42956 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Carpenter Request for Comments: 2775 IBM Category: Informational February 2000
コメントを求めるワーキンググループB.大工要求をネットワークでつないでください: 2775年のIBMカテゴリ: 情報の2000年2月
Internet Transparency
インターネット透明
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.
このドキュメントは建築観点からインターネットの現状について説明します、終わりから終わりへの接続性と透明の問題に集中して。 それは、インターネットネットワーク層に直面しながら、いくつかの主要な建築選択肢の概要で締めくくります。
This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations.
このドキュメントは1999年7月に開催されたネットワーク層の未来のIABワークショップに入力されるように使用されました。 この理由で、完全であって、決定的であると主張しません、そして、推薦状をするのを控えます。
Table of Contents
目次
1. Introduction.................................................2 2. Aspects of end-to-end connectivity...........................3 2.1 The end-to-end argument.....................................3 2.2 End-to-end performance......................................4 2.3 End-to-end address transparency.............................4 3. Multiple causes of loss of transparency......................5 3.1 The Intranet model..........................................6 3.2 Dynamic address allocation..................................6 3.2.1 SLIP and PPP..............................................6 3.2.2 DHCP......................................................6 3.3 Firewalls...................................................6 3.3.1 Basic firewalls...........................................6 3.3.2 SOCKS.....................................................7 3.4 Private addresses...........................................7 3.5 Network address translators.................................7 3.6 Application level gateways, relays, proxies, and caches.....8 3.7 Voluntary isolation and peer networks.......................8
1. 序論…2 2. 終わりから終わりへの接続性の局面…3 2.1 終わりから終わりへの議論…3 2.2 終わりから終わりへの性能…4 2.3 終わりから終わりへのアドレス透明…4 3. 透明の損失の複数の原因…5 3.1 イントラネットモデル…6 3.2 ダイナミックなアドレス配分…6 3.2 .1のメモ用紙とppp…6 3.2 .2DHCP…6 3.3個のファイアウォール…6 3.3 .1個の基本的なファイアウォール…6 3.3 .2個のソックス…7 3.4 個人的なアドレス…7 3.5 アドレス変換機構をネットワークでつないでください…7 3.6のアプリケーションレベルゲートウェイ、リレー、プロキシ、およびキャッシュ…8 3.7の自発的の分離と同輩ネットワーク…8
Carpenter Informational [Page 1] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[1ページ]のRFC2775の大工仕事をしてください。
3.8 Split DNS...................................................9 3.9 Various load-sharing tricks.................................9 4. Summary of current status and impact.........................9 5. Possible future directions..................................11 5.1 Successful migration to IPv6...............................11 5.2 Complete failure of IPv6...................................12 5.2.1 Re-allocating the IPv4 address space.....................12 5.2.2 Exhaustion...............................................13 5.3 Partial deployment of IPv6.................................13 6. Conclusion..................................................13 7. Security Considerations.....................................13 Acknowledgements...............................................14 References.....................................................14 Author's Address...............................................17 Full Copyright Statement.......................................18
3.8 DNSを分割してください…9 3.9 様々な負荷分割法トリック…9 4. 現在の状態と影響の概要…9 5. 可能な将来の方向…11 IPv6への5.1のうまくいっている移行…11 5.2 IPv6の失敗を完成してください…12 5.2 .1 IPv4アドレス空間を再割当てします…12 5.2 .2疲労困憊…13 5.3 IPv6の部分的な展開…13 6. 結論…13 7. セキュリティ問題…13の承認…14の参照箇所…14作者のアドレス…17 完全な著作権宣言文…18
1. Introduction
1. 序論
"There's a freedom about the Internet: As long as we accept the
rules of sending packets around, we can send packets containing
anything to anywhere." [Berners-Lee]
「インターネットに関して自由があります」 「パケットを回す規則を受け入れる限り、私たちはどこでも何でも含むパケットを送ることができます。」 [バーナーズ・リー]
The Internet is experiencing growing pains which are often referred to as "the end-to-end problem". This document attempts to analyse those growing pains by reviewing the current state of the network layer, especially its progressive loss of transparency. For the purposes of this document, "transparency" refers to the original Internet concept of a single universal logical addressing scheme, and the mechanisms by which packets may flow from source to destination essentially unaltered.
インターネットはしばしば「終わりから終わりへの問題」と呼ばれる情緒不安定になっています。 このドキュメントは、ネットワーク層(特に透明の進行性消失)の現状について調査することによってそれらの情緒不安定を分析するのを試みます。 このドキュメントの目的について、「透明」はただ一つの普遍的な論理的なアドレシング体系のオリジナルのインターネット概念を示します、そして、パケットがソースから目的地まで本質的には流れるかもしれないメカニズムは非変更されました。
The causes of this loss of transparency are partly artefacts of parsimonious allocation of the limited address space available to IPv4, and partly the result of broader issues resulting from the widespread use of TCP/IP technology by businesses and consumers. For example, network address translation is an artefact, but Intranets are not.
透明のこの損失の原因は、一部IPv4に利用可能な限られたアドレス空間のけちな配分の人工物と、一部広範な問題がビジネスと消費者によるTCP/IP技術の普及使用から生じるという結果です。 例えば、ネットワークアドレス変換は人工物ですが、イントラネットは人工物であるというわけではありません。
Thus the way forward must recognise the fundamental changes in the usage of TCP/IP that are driving current Internet growth. In one scenario, a complete migration to IPv6 potentially allows the restoration of global address transparency, but without removing firewalls and proxies from the picture. At the other extreme, a total failure of IPv6 leads to complete fragmentation of the network layer, with global connectivity depending on endless patchwork.
したがって、ずっと前進はTCP/IPの用法における運転する現在のインターネットの成長である根本的変化を認識しなければなりません。 1つのシナリオでは、グローバルアドレス透明にもかかわらず、画像からファイアウォールとプロキシを免職しないで、IPv6への完全な移行は潜在的に回復を許容します。 それとは正反対に、IPv6の大失敗はネットワーク層の完全な断片化につながります、グローバルな接続性を無限のパッチワークに依存していて。
Carpenter Informational [Page 2] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[2ページ]のRFC2775の大工仕事をしてください。
This document does not discuss the routing implications of address space, nor the implications of quality of service management on router state, although both these matters interact with transparency to some extent. It also does not substantively discuss namespace issues.
このドキュメントはルータ状態でアドレス空間のルーティング含意、およびサービスの質管理の含意について議論しません、これらの件の両方が透明とある程度対話しますが。 また、それは名前空間問題について実質的に議論しません。
2. Aspects of end-to-end connectivity
2. 終わりから終わりへの接続性の局面
The phrase "end to end", often abbreviated as "e2e", is widely used in architectural discussions of the Internet. For the purposes of this paper, we first present three distinct aspects of end-to- endness.
「終わらせる終わり」というしばしば"e2e"が簡略化された句はインターネットの建築議論に広く使用されます。 この紙の目的のために、私たちは最初に、終わりからendnessの3つの異なった局面を提示します。
2.1 The end-to-end argument
2.1 終わりから終わりへの議論
This is an argument first described in [Saltzer] and reviewed in [RFC 1958], from which an extended quotation follows:
これは最初に、[Saltzer]で説明されて、[RFC1958]で見直された議論です:(拡張引用はそれから続きます)。
"The basic argument is that, as a first principle, certain
required end-to-end functions can only be performed correctly by
the end-systems themselves. A specific case is that any network,
however carefully designed, will be subject to failures of
transmission at some statistically determined rate. The best way
to cope with this is to accept it, and give responsibility for the
integrity of communication to the end systems. Another specific
case is end-to-end security.
「基本的な議論は原則としてエンドシステム自体で正しく終わりから終わりへのある必要な機能を実行できるだけであるということです。」 特定のケースはどんなしかしながら、入念に設計されたネットワークも何らかの統計的に決定しているレートでのトランスミッションの失敗を被りやすくなるということです。 これに対処する最も良い方法は、コミュニケーションの保全のためにエンドシステムにそれを受け入れて、責任を与えることです。別の特定のケースは終わりから終わりへの保証です。
"To quote from [Saltzer], 'The function in question can completely
and correctly be implemented only with the knowledge and help of
the application standing at the endpoints of the communication
system. Therefore, providing that questioned function as a
feature of the communication system itself is not possible.
(Sometimes an incomplete version of the function provided by the
communication system may be useful as a performance enhancement.)'
「[Saltzer]から'アプリケーションの知識と助けだけが通信系の終点に立っていて、完全に正しく問題の機能を実装することができます'と引用するために。」 したがって、質問されるなら、通信系自体の特徴としての機能は可能ではありません。 (時々、通信系によって提供された機能の不完全なバージョンはパフォーマンス強化として役に立つかもしれません。)'
"This principle has important consequences if we require
applications to survive partial network failures. An end-to-end
protocol design should not rely on the maintenance of state (i.e.
information about the state of the end-to-end communication)
inside the network. Such state should be maintained only in the
endpoints, in such a way that the state can only be destroyed when
the endpoint itself breaks (known as fate-sharing). An immediate
consequence of this is that datagrams are better than classical
virtual circuits. The network's job is to transmit datagrams as
efficiently and flexibly as possible. Everything else should be
done at the fringes."
「この原則には、私たちが部分的なネットワーク失敗を乗り切るためにアプリケーションを必要とするなら、重要な結果があります。」 終わりから終わりへのプロトコルデザインはネットワークの中で状態(すなわち、エンド・ツー・エンド通信の状態の情報)のメインテナンスに依存するべきではありません。 そのような状態は終点だけで維持されるべきです、終点自体が壊れると(運命を共有しているとして、知られています)状態を破壊できるだけであるような方法で。 この即座の結果はデータグラムが古典的な仮想の回路より良いということです。 ネットワークの仕事はできるだけ効率的に柔軟にデータグラムを送ることです。 「フリンジで他の何もかもをするべきです。」
Carpenter Informational [Page 3] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[3ページ]のRFC2775の大工仕事をしてください。
Thus this first aspect of end-to-endness limits what the network is expected to do, and clarifies what the end-system is expected to do. The end-to-end argument underlies the rest of this document.
したがって、終わりからendnessのこの最初の局面は、ネットワークがすると予想されることを制限して、エンドシステムがすると予想されることをはっきりさせます。 終わりから終わりへの議論はこのドキュメントの残りの基礎となります。
2.2 End-to-end performance
2.2 終わりから終わりへの性能
Another aspect, in which the behaviour of the network and that of the end-systems interact in a complex way, is performance, in a generalised sense. This is not a primary focus of the present document, but it is mentioned briefly since it is often referred to when discussing end-to-end issues.
もう一つの側面(ネットワークのふるまいとエンドシステムのものは複雑な方法で相互作用する)は性能です、一般化された意味で。 これは現在のドキュメントの焦点ではありませんが、それは、終わりから終わりへの問題について議論するとき、しばしば言及されるので、簡潔に言及されます。
Much work has been done over many years to improve and optimise the performance of TCP. Interestingly, this has led to comparatively minor changes to TCP itself; [STD 7] is still valid apart from minor additions [RFC 1323, RFC 2581, RFC 2018]. However a great deal of knowledge about good practice in TCP implementations has built up, and the queuing and discard mechanisms in routers have been fine- tuned to improve system performance in congested conditions.
TCPの性能を改良して、最適化するために何年間もにわたっても多くの仕事をしています。 おもしろく、これが通じた、比較的、TCP自身へのマイナーチェンジ。 小さい方の追加[RFC1323、RFC2581、RFC2018]は別として、[STD7]はまだ有効です。 利益に関する多くの知識が実装が確立したTCP、および列を作りで練習し、どのように捨てられても、ルータにおけるメカニズムは、混雑している状態のシステム性能を改良するために調整されていた状態ですばらしいです。
Unfortunately all this experience in TCP performance does not help with transport protocols that do not exhibit TCP-like response to congestion [RFC 2309]. Also, the requirement for specified quality of service for different applications and/or customers has led to much new development, especially the Integrated Services [RFC 1633, RFC 2210] and Differentiated Services [RFC 2475] models. At the same time new transport-related protocols have appeared [RFC 1889, RFC 2326] or are in discussion in the IETF. It should also be noted that since the speed of light is not set by an IETF standard, our current notions of end-to-end performance will be largely irrelevant to interplanetary networking.
残念ながらTCP性能のこのすべての経験が混雑[RFC2309]へのTCPのような応答を示さないトランスポート・プロトコルで助けるというわけではありません。 また、異なったアプリケーション、そして/または、顧客のための指定されたサービスの質のための要件は多くの新開発(特にIntegrated Services[RFC1633、RFC2210]とDifferentiated Services[RFC2475]モデル)につながりました。 同時に、新しい輸送関連のプロトコルは、[RFC1889、RFC2326]に見えたか、または議論IETFで中です。 また、光速がIETF規格によって設定されないので終わりから終わりへの性能に関する私たちの現在の概念が惑星間のネットワークと主に無関係になることに注意されるべきです。
Thus, despite the fact that performance and congestion issues for TCP are now quite well understood, the arrival of QOS mechanisms and of new transport protocols raise new questions about end-to-end performance, but these are not further discussed here.
したがって、事実にもかかわらず、TCPのためのその性能と混雑問題は現在全くよく理解されて、QOSメカニズムと新しいトランスポート・プロトコル昇給の到着は終わりから終わりへの性能に関する新しい質問です、しかし、ここでさらにこれらについて議論しません。
2.3 End-to-end address transparency
2.3 終わりから終わりへのアドレス透明
When the catenet concept (a network of networks) was first described by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 1974 [CATENET], a clear assumption was that a single logical address space would cover the whole catenet (or Internet as we now know it). This applied not only to the early TCP/IP Internet, but also to the Xerox PUP design, the OSI connectionless network design, XNS, and numerous other proprietary network architectures.
catenet概念(ネットワークのネットワーク)が最初に1978年[IEN48]の1974年[CATENET]にPouzinによる以前の勧めの後をつけるサーフによって説明されたとき、明確な仮定は単一の論理アドレス空間が全体のcatenet(または、私たちが今それを知っているようなインターネット)をカバーしているだろうということでした。 これは早めのTCP/IPインターネットに適用しただけではなく、ゼロックスPUPデザイン、OSIのコネクションレスなネットワークデザイン、XNS、および他の多数の独占ネットワークアーキテクチャにも適用されました。
Carpenter Informational [Page 4] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[4ページ]のRFC2775の大工仕事をしてください。
This concept had two clear consequences - packets could flow essentially unaltered throughout the network, and their source and destination addresses could be used as unique labels for the end systems.
この概念には、2つの明確な結果がありました--パケットはネットワーク中で本質的には非変更されていた状態で流れることができました、そして、エンドシステムにユニークなラベルとして彼らのソースと送付先アドレスは使用できました。
The first of these consequences is not absolute. In practice changes can be made to packets in transit. Some of these are reversible at the destination (such as fragmentation and compression). Others may be irreversible (such as changing type of service bits or decrementing a hop limit), but do not seriously obstruct the end-to- end principle of Section 2.1. However, any change made to a packet in transit that requires per-flow state information to be kept at an intermediate point would violate the fate-sharing aspect of the end- to-end principle.
これらの結果の第1は絶対ではありません。 実際には、トランジットで変更をパケットにすることができます。 これらの或るものは目的地(断片化や圧縮などの)でリバーシブルです。 他のものは逆にできないかもしれませんが(サービス・ビットのタイプを変えるか、またはホップ限界を減少などにさせることなどの)、真剣に終わりから終わりへのセクション2.1の原則を妨げないでください。 しかしながら、1流れあたりの州の情報が中間的ポイントに保たれるのを必要とするトランジットでパケットにされたどんな変更も終わりまでの終わりの原則の運命を共有する局面に違反するでしょう。
The second consequence, using addresses as unique labels, was in a sense a side-effect of the catenet concept. However, it was a side- effect that came to be highly significant. The uniqueness and durability of addresses have been exploited in many ways, in particular by incorporating them in transport identifiers. Thus they have been built into transport checksums, cryptographic signatures, Web documents, and proprietary software licence servers. [RFC 2101] explores this topic in some detail. Its main conclusion is that IPv4 addresses can no longer be assumed to be either globally unique or invariant, and any protocol or applications design that assumes these properties will fail unpredictably. Work in the IAB and the NAT working group [NAT-ARCH] has analysed the impact of one specific cause of non-uniqueness and non-invariance, i.e., network address translators. Again the conclusion is that many applications will fail, unless they are specifically adapted to avoid the assumption of address transparency. One form of adaptation is the insertion of some form of application level gateway, and another form is for the NAT to modify payloads on the fly, but in either case the adaptation is application-specific.
ユニークなラベルとしてアドレスを使用して、2番目の結果はある意味でcatenet概念の副作用でした。 しかしながら、それは非常に重要であることを来たサイド効果でした。 アドレスのユニークさと耐久性は、様々な意味で特に輸送識別子にそれらを取り入れることによって、利用されました。 したがって、輸送チェックサム、暗号の署名、ウェブドキュメント、および独占的ソフトウェアライセンスサーバをそれらに組み込んであります。 [RFC2101]は何らかの詳細にこの話題を探ります。 主な結論はもうグローバルにユニークであるか、またはIPv4アドレスが不変であると思うことができないということです、そして、これらの特性を仮定するどんなプロトコルやアプリケーションデザインも予想外に失敗するでしょう。 IABで働いてください。そうすれば、NATワーキンググループ[NAT-ARCH]は非のユニークさと非不変性(すなわち、ネットワークアドレス変換機構)の1つの特異的原因の影響を分析しました。 一方、結論は多くのアプリケーションが失敗するということです、それらがアドレス透明の仮定を避けるために明確に適合させられない場合。 1つの形式の適合は何らかの形式のアプリケーションレベルゲートウェイの挿入です、そして、別のフォームがNATが急いでペイロードを変更することですが、どちらかの場合では、適合はアプリケーション特有です。
Non-transparency of addresses is part of a more general phenomenon. We have to recognise that the Internet has lost end-to-end transparency, and this requires further analysis.
アドレスの非透明は、より一般的な現象の一部です。 私たちは、インターネットが終わりから終わりへの透明を失ったと認めなければなりません、そして、これはさらなる分析を必要とします。
3. Multiple causes of loss of transparency
3. 透明の損失の複数の原因
This section describes various recent inventions that have led to the loss of end-to-end transparency in the Internet.
このセクションはインターネットの終わりから終わりへの透明の損失を出した様々な最近の発明品について説明します。
Carpenter Informational [Page 5] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[5ページ]のRFC2775の大工仕事をしてください。
3.1 The Intranet model
3.1 イントラネットモデル
Underlying a number of the specific developments mentioned below is the concept of an "Intranet", loosely defined as a private corporate network using TCP/IP technology, and connected to the Internet at large in a carefully controlled manner. The Intranet is presumed to be used by corporate employees for business purposes, and to interconnect hosts that carry sensitive or confidential information. It is also held to a higher standard of operational availability than the Internet at large. Its usage can be monitored and controlled, and its resources can be better planned and tuned than those of the public network. These arguments of security and resource management have ensured the dominance of the Intranet model in most corporations and campuses.
多くの特定の開発の基礎となるのは、慎重に制御された方法で、TCP/IP技術を使用することで緩く私設の企業ネットワークと定義された「イントラネット」の概念が以下にあると言及して、全体のインターネットに接続しました。 ビジネス目的に会社員によって使用されて、敏感であるか秘密の情報を運ぶホストがあえてイントラネットとインタコネクトされます。 また、それは操作上の有用性の全体のインターネットより高い規格に保たれます。 用法をモニターして、制御できて、公衆通信回線のものよりリソースを計画するほうがよくて、調整できます。 セキュリティと資源管理のこれらの議論はほとんどの会社とキャンパスでのイントラネットモデルの支配を確実にしました。
The emergence of the Intranet model has had a profound effect on the notion of application transparency. Many corporate network managers feel it is for them alone to determine which applications can traverse the Internet/Intranet boundary. In this world view, address transparency may seem to be an unimportant consideration.
イントラネットモデルの出現はアプリケーション透明の概念で絶大な効果がありました。 多くの企業ネットワークのマネージャが、どのアプリケーションがインターネット/イントラネット限界を横断できるかを決定するためにそれが単独で彼らのためのものであると感じます。 この世界観では、アドレス透明は重要でない考慮すべき事柄であるように思えるかもしれません。
3.2 Dynamic address allocation
3.2 ダイナミックなアドレス配分
3.2.1 SLIP and PPP
3.2.1 メモ用紙とppp
It is to be noted that with the advent of vast numbers of dial-up Internet users, whose addresses are allocated at dial-up time, and whose traffic may be tunneled back to their home ISP, the actual IP addresses of such users are purely transient. During their period of validity they can be relied on end-to-end, but they must be forgotten at the end of every session. In particular they can have no permanent association with the domain name of the host borrowing them.
アドレスがダイヤルアップ時に割り当てられて、トラフィックがそれらのホームISPにトンネルを堀って戻されるかもしれない膨大な数のダイヤルアップインターネットユーザの到来で、そのようなユーザの実際のIPアドレスが純粋に一時的であることに注意されることになっています。 彼らの正当性の期間、それらは終わらせる終わりで当てにします、あらゆるセッションの終わりにそれらだけを忘れなければならないということであるかもしれません。 特に、彼らはそれらを借りるホストのドメイン名とのどんな永久的な協会も持つことができません。
3.2.2 DHCP
3.2.2 DHCP
Similarly, LAN-based users of the Internet today frequently use DHCP to acquire a new address at system restart, so here again the actual value of the address is potentially transient and must not be stored between sessions.
同様に、インターネットのLANベースのユーザが今日システムリスタートで新しいアドレスを習得するのに頻繁にDHCPを使用するので、一方、アドレスの実価は、ここに、潜在的に一時的であり、セッションの間に保存されてはいけません。
3.3 Firewalls
3.3 ファイアウォール
3.3.1 Basic firewalls
3.3.1 基本的なファイアウォール
Intranet managers have a major concern about security: unauthorised traffic must be kept out of the Intranet at all costs. This concern led directly to the firewall concept (a system that intercepts all traffic between the Internet and the Intranet, and only lets through
イントラネットのマネージャには、セキュリティに関する主要な関心事があります: 権限のないトラフィックにどんなことをしてもイントラネットを入れないようにしなければなりません。 この関心が直接ファイアウォール概念につながった、(トラフィックが通じてさせるだけであるすべてを妨害するシステム
Carpenter Informational [Page 6] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[6ページ]のRFC2775の大工仕事をしてください。
selected traffic, usually belonging to a very limited set of applications). Firewalls, by their nature, fundamentally limit transparency.
通常、非常に限られたセットのアプリケーションに属す選択されたトラフィック 基本的に彼らの自然、限界透明であるのによるファイアウォール。
3.3.2 SOCKS
3.3.2 ソックス
A footnote to the effect of firewalls is the SOCKS mechanism [RFC 1928] by which untrusted applications such as telnet and ftp can punch through a firewall. SOCKS requires a shim library in the Intranet client, and a server in the firewall which is essentially an application level relay. As a result, the remote server does not see the real client; it believes that the firewall is the client.
ファイアウォールの効果への脚注はtelnetやftpなどの信頼されていないアプリケーションがファイアウォールを通してパンチできるSOCKSメカニズム[RFC1928]です。 SOCKSはイントラネットクライアントで詰め物のライブラリを必要として、本質的にはアプリケーションレベルリレーであるファイアウォールでサーバを必要とします。 その結果、リモートサーバは本当のクライアントを見ません。 ファイアウォールがクライアントであることは信じています。
3.4 Private addresses
3.4 個人的なアドレス
When the threat of IPv4 address exhaustion first arose, and in some cases user sites were known to be "pirating" addresses for private use, a set of official private addresses were hurriedly allocated [RFC 1597] and later more carefully defined [BCP 5]. The legitimate existence of such an address allocation proved to very appealing, so Intranets with large numbers of non-global addresses came into existence. Unfortunately, such addresses by their nature cannot be used for communication across the public Internet; without special measures, hosts using private addresses are cut off from the world.
IPv4アドレス疲労困憊の脅威は最初に起こって、後でいくつかのケースユーザの現場で私的使用目的でアドレスを「略奪していること」を知っていたとき、1セットの公式のプライベート・アドレスを大急ぎで[RFC1597]を割り当てて、より慎重に定義しました[BCP5]。 まさしくその上告に立証されたそのようなアドレス配分の正統の存在のために、多くの非グローバルなアドレスがあるイントラネットは生まれました。 残念ながら、コミュニケーションに公共のインターネットの向こう側に本質的にそのようなアドレスを使用できません。 特別な測定がなければ、プライベート・アドレスを使用しているホストが世界から解雇されます。
Note that private address space is sometimes asserted to be a security feature, based on the notion that outside knowledge of internal addresses might help intruders. This is a false argument, since it is trivial to hide addresses by suitable access control lists, even if they are globally unique - indeed that is a basic feature of a filtering router, the simplest form of firewall. A system with a hidden address is just as private as a system with a private address. There is of course no possible point in hiding the addresses of servers to which outside access is required.
内部のアドレスに関する外の知識が侵入者を助けるかもしれないという概念に基づいてプライベート・アドレススペースがセキュリティ機能であると時々断言されることに注意してください。 これは誤った論拠です、適当なアクセスコントロールリストでアドレスを隠すのが些細であるので、彼らがグローバルにユニークであっても--本当に、それはフィルタリングルータ(最も簡単な形式のファイアウォール)に関する基本的特徴です。 隠しアドレスがあるシステムはプライベート・アドレスがあるシステムとちょうど同じくらい個人的です。 もちろん、どれがアクセスの外で必要かにサーバのアドレスを隠すどんな可能な意味もありません。
It is also worth noting that the IPv6 equivalent of private addresses, i.e. site-local addresses, have similar characteristics to BCP 5 addresses, but their use will not be forced by a lack of globally unique IPv6 addresses.
また、すなわち、プライベート・アドレスのIPv6同等物、サイトローカルのアドレスがBCP5アドレスに同様の特性を持っていますが、彼らの使用がグローバルにユニークなIPv6アドレスの不足によって強制されないことに注意する価値があります。
3.5 Network address translators
3.5 ネットワークアドレス変換機構
Network address translators (NATs) are an almost inevitable consequence of the existence of Intranets using private addresses yet needing to communicate with the Internet at large. Their architectural implications are discussed at length in [NAT-ARCH], the fundamental point being that address translation on the fly destroys end-to-end address transparency and breaks any middleware or
ネットワーク・アドレス翻訳者(NATs)はイントラネットの存在がまだインターネットが全体で交信する必要があるプライベート・アドレスを使用するほとんど必然の結果です。 または十分[NAT-ARCH]でそれらの建築含意について議論します、基本的なポイントがアドレス変換が急いで終わりから終わりへのアドレス透明を破壊して、どんなミドルウェアも壊すということであり。
Carpenter Informational [Page 7] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[7ページ]のRFC2775の大工仕事をしてください。
applications that depend on it. Numerous protocols, for example H.323, carry IP addresses at application level and fail to traverse a simple NAT box correctly. If the full range of Internet applications is to be used, NATs have to be coupled with application level gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be updated whenever a new address-dependent application comes along. In practice, NAT functionality is built into many firewall products, and all useful NATs have associated ALGs, so it is difficult to disentangle their various impacts.
それによるアプリケーション。 多数のプロトコル(例えば、H.323)は、アプリケーションレベルでIPアドレスを運んで、正しく簡単なNAT箱を横断しません。 最大限の範囲のインターネットアプリケーションが使用されていることであるなら、NATsはアプリケーションレベルゲートウェイ(ALGs)かプロキシに結びつけられなければなりません。 その上、新しいアドレス依存するアプリケーションがやって来るときはいつも、ALGかプロキシをアップデートしなければなりません。 実際には、多くのファイアウォール製品がNATの機能性に組み込まれて、すべての役に立つNATsがALGsを関連づけたので、彼らの様々な影響を解きほぐすのは難しいです。
3.6 Application level gateways, relays, proxies, and caches
3.6 アプリケーションレベルゲートウェイ、リレー、プロキシ、およびキャッシュ
It is reasonable to position application level gateways, relays, proxies, and caches at certain critical topological points, especially the Intranet/Internet boundary. For example, if an Intranet does not use SMTP as its mail protocol, an SMTP gateway is needed. Even in the normal case, an SMTP relay is common, and can perform useful mail routing functions, spam filtering, etc. (It may be observed that spam filtering is in some ways a firewall function, but the store-and-forward nature of electronic mail and the availability of MX records allow it to be a distinct and separate function.)
ある一定の重要な位相的なポイントでアプリケーションレベルゲートウェイ、リレー、プロキシ、およびキャッシュを置くのは妥当です、特にイントラネット/インターネット境界。 例えば、イントラネットがメールプロトコルとしてSMTPを使用しないなら、SMTPゲートウェイが必要です。 正常な場合ではさえ、SMTPリレーは、一般的であり、役に立つメール経路選択機能、スパムフィルタリングなどを実行できます。 (スパムフィルタリングがある点ではファイアウォール機能であることが観測されるかもしれませんが、電子メールの店とフォワード自然とMX記録の有用性は、それが異なって別々の機能であることを許容します。)
Similarly, for a protocol such as HTTP with a well-defined voluntary proxy mechanism, application proxies also serving as caches are very useful. Although these devices interfere with transparency, they do so in a precise way, correctly terminating network, transport and application protocols on both sides. They can however exhibit some shortfalls in ease of configuration and failover.
同様に、明確な自発的のプロキシメカニズムがあるHTTPなどのプロトコルの、また、キャッシュとして勤めているアプリケーションプロキシは非常に役に立ちます。 これらのデバイスは透明を妨げますが、それらは両側の正確なずっと、正しく終わっているネットワーク、輸送、およびアプリケーション・プロトコルでそうします。 しかしながら、彼らは構成とフェイルオーバーの容易さでいくつかの不足分を示すことができます。
However, there appear to be cases of "involuntary" applications level devices such as proxies that grab and modify HTTP traffic without using the appropriate mechanisms, sometimes known as "transparent caches", or mail relays that purport to remove undesirable words. These devices are by definition not transparent, and may have totally unforeseeable side effects. (A possible conclusion is that even for non-store-and-forward protocols, a generic diversion mechanism analogous to the MX record would be of benefit. The SRV record [RFC 2052] is a step in this direction.)
しかしながら、望ましくない単語を取り除くことを意味する「透明なキャッシュ」として時々知られている適切な手段を使用しないでHTTPトラフィックをつかんで、変更するプロキシか郵便配達人などの平らなデバイスがリレーする「不本意な」アプリケーションに関するケースはあるように見えます。 これらのデバイスは、定義上透明でなく、完全に「非-予見でき」な副作用を持っているかもしれません。 (可能な結論は非店の、そして、前進のプロトコルにさえ、MX記録への類似のジェネリック転換メカニズムが有益であるだろうということです。 SRV記録[RFC2052]はこの方向へのステップです。)
3.7 Voluntary isolation and peer networks
3.7 自発的の分離と同輩ネットワーク
There are communities that think of themselves as being so different that they require isolation via an explicit proxy, and even by using proprietary protocols and addressing schemes within their network. An example is the WAP Forum which targets very small phone-like devices with some capabilities for Internet connectivity. However, it's not
それらのネットワークの中で明白なプロキシを通して彼らが分離を必要とするほど異なって、固有のプロトコルを使用して、体系を扱いさえすることによって自分たちを思う共同体があります。 例はインターネットの接続性のためにいくつかの能力で非常に小さい電話のようなデバイスを狙うWAP Forumです。 しかしながら、それはそうではありません。
Carpenter Informational [Page 8] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[8ページ]のRFC2775の大工仕事をしてください。
the Internet they're connecting directly to. They have to go through a proxy. This could potentially mean that millions of devices will never know the benefits of end-to-end connectivity to the Internet.
彼らが直接接続しているインターネット。 彼らはプロキシを通らなければなりません。 これは、何百万台ものデバイスが終わりから終わりへの接続性の利益をインターネットに決して知らないことを潜在的に意味するかもしれません。
A similar effect arises when applications such as telephony span both an IP network and a peer network layer using a different technology. Although the application may work end-to-end, there is no possibility of end-to-end packet transmission.
異なった技術を使用することで電話などのアプリケーションがIPネットワークと同輩ネットワーク層の両方にかかるとき、同様の効果は起こります。 アプリケーションは終わらせる終わりを扱うかもしれませんが、終わりから終わりへのパケット伝送の可能性が全くありません。
3.8 Split DNS
3.8 分裂DNS
Another consequence of the Intranet/Internet split is "split DNS" or "two faced DNS", where a corporate network serves up partly or completely different DNS inside and outside its firewall. There are many possible variants on this; the basic point is that the correspondence between a given FQDN (fully qualified domain name) and a given IPv4 address is no longer universal and stable over long periods.
イントラネット/インターネット分裂の別の結果は、企業ネットワークがファイアウォールの中と、そして、そのファイアウォールの外で一部か完全に異なったDNSを供給する「分裂DNS」か「2顔のDNS」です。 多くの可能な異形がこれにあります。 基本的なポイントは与えられたFQDN(完全修飾ドメイン名)と与えられたIPv4アドレスとの通信が長期の間もう普遍的であって、安定していないということです。
3.9 Various load-sharing tricks
3.9 様々な負荷分割法トリック
IPv4 was not designed to support anycast [RFC 1546], so there is no natural approach to load-sharing when one server cannot do the job. Various tricks have been used to resolve this (multicast to find a free server, the DNS returns different addresses for the same FQDN in a round-robin, a router actually routes packets sent to the same address automatically to different servers, etc.). While these tricks are not particularly harmful in the overall picture, they can be implemented in such a way as to interfere with name or address transparency.
IPv4がanycastが[RFC1546]であるとサポートするように設計されなかったので、1つのサーバが仕事できないとき、負荷分割法へのどんな自然なアプローチもありません。 様々なトリックは、これを決議するのに使用されました(無料のサーバを見つけるマルチキャスト、DNSが連続で同じFQDNのための異なったアドレスを返して、ルータは実際に自動的に同じアドレスに送られたパケットを異なったサーバなどに発送します)。 これらのトリックが全体像で特に有害でない間、それらを名前かアドレス透明を妨げるほどそのような方法で実装することができます。
4. Summary of current status and impact
4. 現在の状態と影響の概要
It is impossible to estimate with any numerical reliability how widely the above inventions have been deployed. Since many of them preserve the illusion of transparency while actually interfering with it, they are extremely difficult to measure.
どんな数字の信頼性でも上の発明品がどれくらい広く配布されたかと見積もっているのは不可能です。 彼らの多くが実際にそれを妨げている間、透明の幻想を保存するので、それらは測定するのが非常に難しいです。
However it is certain that all the mechanisms just described are in very widespread use; they are not a marginal phenomenon. In corporate networks, many of them are the norm. Some of them (firewalls, relays, proxies and caches) clearly have intrinsic value given the Intranet concept. The others are largely artefacts and pragmatic responses to various pressures in the operational Internet, and they must be costing the industry very dearly in constant administration and complex fault diagnosis.
しかしながら、ただ説明されたすべてのメカニズムが非常に広範囲に使用中であるのは、確かです。 それらはマージンの現象ではありません。 企業ネットワークでは、それらの多くが標準です。 イントラネット概念を考えて、それら(ファイアウォール、リレー、プロキシ、およびキャッシュ)のいくつかが明確に本質的な価値が高いです。 それらは、他のものが、主に人工物と操作上のインターネットの様々な圧力への実践的な応答であり、一定の管理で非常に心から産業かかって、複雑な欠点診断であるに違いありません。
Carpenter Informational [Page 9] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[9ページ]のRFC2775の大工仕事をしてください。
In particular, the decline of transparency is having a severe effect on deployment of end-to-end IP security. The Internet security model [SECMECH] calls for security at several levels (roughly, network, applications, and object levels). The current network level security model [RFC 2401] was constructed prior to the recognition that end- to-end address transparency was under severe threat. Although alternative proposals have begun to emerge [HIP] the current reality is that IPSEC cannot be deployed end-to-end in the general case. Tunnel-mode IPSEC can be deployed between corporate gateways or firewalls. Transport-mode IPSEC can be deployed within a corporate network in some cases, but it cannot span from Intranet to Internet and back to another Intranet if there is any chance of a NAT along the way.
特に、透明の衰退は終わりから終わりへのIPセキュリティの展開に厳しい影響を与えています。 インターネット機密保護モデル[SECMECH]はいくつかのレベル(およそネットワーク、アプリケーション、およびオブジェクトレベル)におけるセキュリティのために電話をします。 平らなセキュリティがモデル化する現在のネットワーク[RFC2401]は終わりまでの終わりのアドレス透明が厳しい脅威にさらされていたという認識の前に構成されました。 代案は[HIP]として現れ始めましたが、現在の現実は一般的な場合で終わらせる終わりをIPSECに配布することができないということです。 法人のゲートウェイかファイアウォールの間でトンネルモードIPSECを配布することができます。 いくつかの場合企業ネットワークの中で交通機関IPSECを配布することができますが、道に沿って何かNATの見込みがあれば、それは別のイントラネットに行き帰りイントラネットからインターネットまでわたることができません。
Indeed, NAT breaks other security mechanisms as well, such as DNSSEC and Kerberos, since they rely on address values.
本当に、彼らがアドレス値を当てにするので、NATはまた、DNSSECやケルベロスなどの他のセキュリティー対策を壊します。
The loss of transparency brought about by private addresses and NATs affects many applications protocols to a greater or lesser extent. This is explored in detail in [NAT-PROT]. A more subtle effect is that the prevalence of dynamic addresses (from DHCP, SLIP and PPP) has fed upon the trend towards client/server computing. Today it is largely true that servers have fixed addresses, clients have dynamic addresses, and servers can in no way assume that a client's IP address identifies the client. On the other hand, clients rely on servers having stable addresses since a DNS lookup is the only generally deployed mechanism by which a client can find a server and solicit service. In this environment, there is little scope for true peer-to-peer applications protocols, and no easy solution for mobile servers. Indeed, the very limited demand for Mobile IP might be partly attributed to the market dominance of client/server applications in which the client's address is of transient significance. We also see a trend towards single points of failure such as media gateways, again resulting from the difficulty of implementing peer-to-peer solutions directly between clients with no fixed address.
プライベート・アドレスとNATsによって引き起こされた透明の損失は多かれ少なかれ多くのアプリケーションプロトコルに影響します。 これは[NAT-PROT]で詳細に探検されます。 より微妙な効果はダイナミックなアドレス(DHCP、SLIP、およびPPPからの)の普及に傾向でクライアント/サーバコンピューティングに向かって入れられたということです。 クライアントには、ダイナミックなアドレスがあります、そして、今日、サーバがアドレスを修理したのが、主に本当であり、サーバはクライアントのIPアドレスがクライアントを特定すると決して仮定できません。 他方では、クライアントはDNSルックアップがクライアントがサーバを見つけて、サービスに請求できる唯一の一般に、配布しているメカニズムであるので安定したアドレスを持っているサーバを当てにします。 この環境には、正しいピアツーピアアプリケーションプロトコルにもかかわらず、モバイルサーバの容易な解決でない範囲がほとんどありません。 本当に、モバイルIPの非常に限られた要求は一部クライアントのアドレスが一時的な意味のものであるクライアント/サーバ・アプリケーションの市場の独占の結果と考えられるかもしれません。 また、私たちは単一のポイントの失敗に向かったメディアゲートウェイなどの傾向を見ます、再び、定番地なしでピアツーピアがクライアントの直接間のソリューションであると実装するという困難から生じて。
The notion that servers can use precious globally unique addresses from a small pool, because there will always be fewer servers than clients, may become anachronistic when most electrical devices become network-manageable and thus become servers for a management protocol. Similarly, if every PC becomes a telephone (or the converse), capable of receiving unsolicited incoming calls, the lack of stable IP addresses for PCs will be an issue. Another impending paradigm shift is when domestic and small-office subscribers move from dial-up to always-on Internet connectivity, at which point transient address assignment from a pool becomes much less appropriate.
ほとんどの電気装置がネットワーク処理しやすくなって、その結果、管理プロトコルのためのサーバになると、クライアントより少ないサーバがいつもあるのでサーバが小さいプールからの貴重なグローバルにユニークなアドレスを使用できるという概念は時代錯誤になるかもしれません。 同様に、あらゆるPCが電話(または、逆)になるなら、求められていないかかってきた電話を受けることができます、PCのための安定したIPアドレスの不足は問題になるでしょう。 別の差し迫っているパラダイム・シフトはドメスティックで小さいオフィスの加入者がダイヤルアップからいつもオンなプールからのポイント一時アドレス課題がはるかに適切でなくなるインターネットの接続性まで移行する時です。
Carpenter Informational [Page 10] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[10ページ]のRFC2775の大工仕事をしてください。
Many of the inventions described in the previous section lead to the datagram traffic between two hosts being directly or indirectly mediated by at least one other host. For example a client may depend on a DHCP server, a server may depend on a NAT, and any host may depend on a firewall. This violates the fate-sharing principle of [Saltzer] and introduces single points of failure. Worse, most of these points of failure require configuration data, yet another source of operational risk. The original notion that datagrams would find their way around failures, especially around failed routers, has been lost; indeed the overloading of border routers with additional functions has turned them into critical rather than redundant components, even for multihomed sites.
前項で説明された発明品の多くが他の少なくとも1人のホストによって直接か間接的に調停される2人のホストの間のデータグラムトラフィックにつながります。 例えば、クライアントはDHCPサーバを当てにするかもしれません、そして、サーバはNATを当てにされるかもしれません、そして、どんなホストもファイアウォールを当てにするかもしれません。 これは、[Saltzer]の運命を共有する原則に違反して、単一のポイントの失敗を導入します。 よりひどく、失敗のこれらのポイントの大部分はコンフィギュレーション・データ、しかし、操作上のリスクの別の源を必要とします。 データグラムが失敗したルータの特に周りで失敗の道がわかるだろうという独創的な概念は失われました。 本当に、追加機能がある境界ルータの積みすぎはそれらを余分であるというよりむしろ重要なコンポーネントに変えました、「マルチ-家へ帰」っているサイトにさえ。
The loss of address transparency has other negative effects. For example, large scale servers may use heuristics or even formal policies that assign different priorities to service for different clients, based on their addresses. As addresses lose their global meaning, this mechanism will fail. Similarly, any anti-spam or anti- spoofing techniques that rely on reverse DNS lookup of address values can be confused by translated addresses. (Uncoordinated renumbering can have similar disadvantages.)
アドレス透明の損失には、他のマイナスの効果があります。 例えば、大規模サーバは発見的教授法か異なったクライアントのために異なったプライオリティをサービスに割り当てる正式な方針さえ使用するかもしれません、彼らのアドレスに基づいて。 アドレスがそれらのグローバルな意味を失うとき、このメカニズムは失敗するでしょう。 同様に、アドレス値の逆のDNSルックアップを当てにするどんな反スパムの、または、反スプーフィングのテクニックも変換されたアドレスで混乱できます。 (Uncoordinated番号を付け替えるのは同様の損失を持つことができます。)
The above issues are not academic. They add up to complexity in applications design, complexity in network configuration, complexity in security mechanisms, and complexity in network management. Specifically, they make fault diagnosis much harder, and by introducing more single points of failure, they make faults more likely to occur.
上記の問題はアカデミックではありません。 彼らはアプリケーションデザインにおける複雑さ、ネットワーク・コンフィギュレーションにおける複雑さ、セキュリティー対策における複雑さ、およびネットワークマネージメントにおける複雑さを意味します。 明確に、彼らで欠点診断ははるかに困難になります、そして、より単一のポイントの失敗を導入することによって、それらは欠点をより起こりそうにします。
5. Possible future directions
5. 可能な将来の方向
5.1 Successful migration to IPv6
5.1 IPv6へのうまくいっている移行
In this scenario, IPv6 becomes fully implemented on all hosts and routers, including the adaptation of middleware, applications, and management systems. Since the address space then becomes big enough for all conceivable needs, address transparency can be restored. Transport-mode IPSEC can in principle deploy, given adequate security policy tools and a key infrastructure. However, it is widely believed that the Intranet/firewall model will certainly persist.
このシナリオでは、IPv6はすべてのホストとルータで完全に実装されるようになります、ミドルウェア、アプリケーション、およびマネージメントシステムの適合を含んでいて。次に、アドレス空間が想像できるすべての必要性には十分大きくなるので、アドレス透明は回復できます。 十分な安全性政策手段と主要なインフラストラクチャを考えて、交通機関IPSECは原則として展開できます。 しかしながら、確かに、イントラネット/ファイアウォールモデルが固執すると広く信じられています。
Note that it is a basic assumption of IPv6 that no artificial constraints will be placed on the supply of addresses, given that there are so many of them. Current practices by which some ISPs strongly limit the number of IPv4 addresses per client will have no reason to exist for IPv6. (However, addresses will still be assigned prudently, according to guidelines designed to favour hierarchical routing.)
それが人工拘束が全くアドレスの供給に置かれないというIPv6の基本仮定であることに注意してください、とても多いそれらがあれば。 いくつかのISPが強く1クライアントあたりのIPv4アドレスの数を制限する現在の実務はIPv6のために存在する理由を全く持たないでしょう。 (しかしながら、それでも、階層型ルーティングを支持するように設計されたガイドラインによると、アドレスは用心深く割り当てられるでしょう。)
Carpenter Informational [Page 11] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[11ページ]のRFC2775の大工仕事をしてください。
Clearly this is in any case a very long term scenario, since it assumes that IPv4 has declined to the point where IPv6 is required for universal connectivity. Thus, a viable version of Scenario 5.3 is a prerequisite for Scenario 5.1.
明確に、どのような場合でも、これは非常に長い用語シナリオです、IPv4がIPv6が普遍的な接続性に必要であるポイントに減退したと仮定するので。 したがって、Scenario5.3の実行可能なバージョンはScenario5.1のための前提条件です。
5.2 Complete failure of IPv6
5.2 IPv6の完全な失敗
In this scenario, IPv6 fails to reach any significant level of operational deployment, IPv4 addressing is the only available mechanism, and address transparency cannot be restored. IPSEC cannot be deployed globally in its current form. In the very long term, the pool of globally unique IPv4 addresses will be nearly totally allocated, and new addresses will generally not be available for any purpose.
このシナリオでは、IPv6はどんな有意水準の操作上の展開にも達しません、そして、IPv4アドレシングは唯一の利用可能なメカニズムです、そして、アドレス透明は回復できません。 現在のフォームでIPSECをグローバルに配布することができません。 非常に長い期間で、グローバルにユニークなIPv4アドレスのプールを完全にほとんど割り当てるでしょう、そして、一般に、新しいアドレスはどんな目的にも利用可能にならないでしょう。
It is unclear exactly what is likely to happen if the Internet continues to rely exclusively on IPv4, because in that eventuality a variety of schemes are likely to promulgated, with a view toward providing an acceptable evolutionary path for the network. However, we can examine two of the more simplistic sub-scenarios which are possible, while realising that the future would be unlikely to match either one exactly:
インターネットが、排他的にIPv4を当てにし続けているならまさに何が起こりそうであるかは、不明瞭です、その不測の事態において、さまざまな体系が公表されることの傾向があるので、許容できる進化の道筋をネットワークに提供することに向かった視点で。 しかしながら、私たちは2つの未来がまさにどちらかに合っていそうにないとわかっている間可能なより安易なサブシナリオを調べることができます:
5.2.1 Re-allocating the IPv4 address space
5.2.1 IPv4アドレス空間を再割当てすること。
Suppose that a mechanism is created to continuously recover and re- allocate IPv4 addresses. A single global address space is maintained, with all sites progressively moving to an Intranet private address model, with global addresses being assigned temporarily from a pool of several billion.
メカニズムが絶え間なく回復して、アドレスをIPv4に再割り当てるために作成されると仮定してください。 ただ一つのグローバルアドレススペースは維持されます、すべてのサイトが次第にイントラネットプライベート・アドレスモデルに移行している状態で、グローバルなアドレスが数10億のプールから一時割り当てられている状態で。
5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT
(NAT with port number translation). This has the disadvantage
that the host is unaware of the unique address being used for
its traffic, being aware only of its ambiguous private
address, with all the problems that this generates. See
[NAT-ARCH].
5.2.1.1 このサブサブシナリオはNATとNAPT(ポートナンバー翻訳があるNAT)の一般化された使用です。 これには、ホストがそうである不都合がユニークなアドレスに気づかない状態でトラフィックに使用されることであります、あいまいなプライベート・アドレスだけを意識していて、これが生成するすべての問題で。 [ナット-アーチ]を見てください。
5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP
addressing implemented at the host rather than by a NAT box.
See [RSIP]. In this case the host is aware of its unique
address, allowing for substantial restoration of the end-to-
end usefulness of addresses, e.g. for TCP or cryptographic
checksums.
5.2.1.2 別のサブサブシナリオはNAT箱でというよりむしろホストで実装された分野特有のIPアドレシングの使用です。 [RSIP]を見てください。 この場合、ホストはユニークなアドレスを意識しています、終わりから終わりへのアドレスの有用性のかなりの回復を考慮して、例えば、TCPか暗号のチェックサムのために。
Carpenter Informational [Page 12] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[12ページ]のRFC2775の大工仕事をしてください。
5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model
in which address translation is replaced by systematic
encapsulation of all packets for wide-area transport. This
model has never been fully developed, although it is
completely compatible with end-to-end addressing.
5.2.1.3 最終的なサブサブシナリオがそう、アドレス変換が広い領域輸送のためにすべてのパケットの系統的なカプセル化に取り替えられるモデルを「写像して、カプセル化します」。 それは終わりから終わりへのアドレシングと完全に互換性がありますが、このモデルは完全に一度も開発されたことがありません。
5.2.2 Exhaustion
5.2.2 疲労困憊
Suppose that no mechanism is created to recover addresses (except perhaps black or open market trading). Sites with large address blocks keep them. All the scenarios of 5.2.1 appear but are insufficient. Eventually the global address space is no longer adequate. This is a nightmare scenario - NATs appear within the "global" address space, for example at ISP-ISP boundaries. It is unclear how a global routing system and a global DNS system can be maintained; the Internet is permanently fragmented.
メカニズムが全くアドレス(恐らく黒いか開いている市場取り引きを除いた)を回復するために作成されないと仮定してください。 大きいあて先ブロックがあるサイトはそれらを保ちます。 すべてのシナリオ、5.2では、.1は、現れますが、不十分です。 結局、グローバルアドレススペースはもう適切ではありません。 これは悪夢のシナリオです--NATsは例えば、「グローバルな」アドレス空間、ISP ISP境界に現れます。 どうしたらグローバルなルーティングシステムとグローバルなDNSシステムを維持できるかは不明瞭です。 インターネットは永久に、断片化されます。
5.3 Partial deployment of IPv6
5.3 IPv6の部分的な展開
In this scenario, IPv6 is completely implemented but only deploys in certain segments of the network (e.g. in certain countries, or in certain areas of application such as mobile hand-held devices). Instead of being transitional in nature, some of the IPv6 transition techniques become permanent features of the landscape. Sometimes addresses are 32 bits, sometimes they are 128 bits. DNS lookups may return either or both. In the 32 bit world, the scenarios 5.2.1 and 5.2.2 may occur. IPSEC can only deploy partially.
このシナリオでは、IPv6は完全に実装されますが、ネットワーク(例えば、ある一定の国、またはアプリケーションのモバイル携帯端末などのある一定の領域の)のある区分で展開するだけです。 現実に過渡的であることの代わりに、IPv6変遷のテクニックのいくつかが風景の永久的な特徴になります。 時々、アドレスが32ビットである、時々、それらは128ビットです。 DNSルックアップはどちらかか両方を返すかもしれません。 32ビットの世界、シナリオ5.2.1に5.2に、.2は起こるかもしれません。 IPSECは部分的に展開できるだけです。
6. Conclusion
6. 結論
None of the above scenarios is clean, simple and straightforward. Although the pure IPv6 scenario is the cleanest and simplest, it is not straightforward to reach it. The various scenarios without use of IPv6 are all messy and ultimately seem to lead to dead ends of one kind or another. Partial deployment of IPv6, which is a required step on the road to full deployment, is also messy but avoids the dead ends.
上のシナリオのいずれも、清潔で、簡単で簡単ではありません。 純粋なIPv6シナリオは、最も清潔であって、最も簡単ですが、それに達するのは簡単ではありません。 IPv6の使用のない様々なシナリオは、すべて乱雑であり、結局、何らかの種類の行き止まりに通じるように思えます。 IPv6の部分的な展開は、また、乱雑ですが、行き止まりを避けます。(IPv6は完全な展開への道路における必要なステップです)。
7. Security Considerations
7. セキュリティ問題
The loss of transparency is both a bug and a feature from the security viewpoint. To the extent that it prevents the end-to-end deployment of IPSEC, it damages security and creates vulnerabilities. For example, if a standard NAT box is in the path, then the best that can be done is to decrypt and re-encrypt IP traffic in the NAT. The traffic will therefore be momentarily in clear text and potentially vulnerable. Furthermore, the NAT will possess many keys and will be a prime target of attack. In environments where this is unacceptable,
透明の損失はセキュリティ観点からのバグと特徴の両方です。 終わりから終わりへのIPSECの展開を防ぐという範囲に、それは、セキュリティを破損して、脆弱性を作成します。 例えば、尽くすことができるベストは、標準のNAT箱が経路にあるなら、NATにおけるIPトラフィックを解読して、再暗号化することです。 トラフィックは、したがって、しばらくクリアテキストにあって、潜在的に被害を受け易いでしょう。 その上、NATは、多くのキーを所有して、攻撃の主要な目標になるでしょう。 これが容認できない環境で
Carpenter Informational [Page 13] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[13ページ]のRFC2775の大工仕事をしてください。
encryption must be applied above the network layer instead, of course with no usage whatever of IP addresses in data that is cryptographically protected. See section 4 for further discussion.
用法がなければ、代わりにネットワーク層を超えて暗号化を適用しなければならなくて、もちろん、IPの何でもデータでそれを扱うかは暗号で保護されます。 さらなる議論に関してセクション4を見てください。
In certain scenarios, i.e. 5.1 (full IPv6) and 5.2.1.2 (RSIP), end- to-end IPSEC would become possible, especially using the "distributed firewalls" model advocated in [Bellovin].
そして、すなわち、あるシナリオ、5.1(完全なIPv6)、5.2 .1 .2 (RSIP)、終わりまでの終わりのIPSECは可能になるでしょう、[Bellovin]で弁護された「分配されたファイアウォール」モデルを特に使用して。
The loss of transparency at the Intranet/Internet boundary may be considered a security feature, since it provides a well defined point at which to apply restrictions. This form of security is subject to the "crunchy outside, soft inside" risk, whereby any successful penetration of the boundary exposes the entire Intranet to trivial attack. The lack of end-to-end security applied within the Intranet also ignores insider threats.
イントラネット/インターネット境界における透明の損失はセキュリティ機能であると考えられるかもしれません、制限を適用するよく定義されたポイントを提供するので。 このフォームのセキュリティは「中で柔らかいボリボリ音を立てている外部」リスクを受けることがあります。(境界のどんなうまくいっている侵入もそれで些細な攻撃に全体のイントラネットを暴露します)。 また、終わりから終わりへのイントラネットの中で適用されたセキュリティの不足はインサイダーの脅威を無視します。
It should be noted that security applied above the transport level, such as SSL, SSH, PGP or S/MIME, is not affected by network layer transparency issues.
輸送レベルを超えて適用されたSSLなどのセキュリティ(SSH、PGPまたはS/MIME)がネットワーク層透明問題で影響を受けないことに注意されるべきです。
Acknowledgements
承認
This document and the related issues have been discussed extensively by the IAB. Special thanks to Steve Deering for a detailed review and to Noel Chiappa. Useful comments or ideas were also received from Rob Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf, Spencer Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne, Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark, Vern Paxson, Michael Quinlan, Eric Rosen, Daniel Senie, Henning Schulzrinne, Bill Sommerfeld, and George Tsirtsis.
このドキュメントと関連する問題はIABによって手広く議論されました。 詳細なレビューのためのスティーブ・デアリングおかげとクリスマスChiappaに特別です。 また、ロブAustein、ジョン・バルタス、ジムBound、スコット・ブラドナー、Vintサーフ、スペンサー・ダウキンズ、Anoop Ghanwani、エリック・グットマン、エリックA.Hall、グラハムKlyne、ダン・コーン、ガブリエル・モンテネグロ、トーマスNarten、エリックNordmark、バーン・パクソン、マイケル・クィンラン、エリック・ローゼン、ダニエルSenie、ヘニングSchulzrinne、ビル・ゾンマーフェルト、およびジョージTsirtsisから役に立つコメントか考えを受け取りました。
References
参照
[Bellovin] Distributed Firewalls, S. Bellovin, available at
http://www.research.att.com/~smb/papers/distfw.pdf or
http://www.research.att.com/~smb/papers/distfw.ps (work
in progress).
[Bellovin]はFirewalls、 http://www.research.att.com/~smb/papers/distfw.pdf か http://www.research.att.com/~smb/papers/distfw.ps (処理中の作業)で利用可能なS.Bellovinを分配しました。
[Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti,
HarperCollins, 1999, p 208.
[バーナーズ・リー] ウェブ、M.Fischetti、HarperCollins、1999、208歳のT.pバーナーズ・リーを作り上げます。
[Saltzer] End-To-End Arguments in System Design, J.H. Saltzer,
D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4,
November 1984, pp 277-288.
System Designの[Saltzer]終わりから終わりへのArguments、J.H.Saltzer、D.P.リード、D.D.クラーク、ACM TOCS Vol2、Number4、1984年11月、pp277-288。
[IEN 48] Cerf, V., "The Catenet Model for Internetworking,"
Information Processing Techniques Office, Defense
Advanced Research Projects Agency, IEN 48, July 1978.
[IEN48] サーフ、V.、「Catenetはインターネットワーキングのためにモデル化します」、情報処理テクニックオフィス、国防高等研究計画庁、IEN48、1978年7月。
Carpenter Informational [Page 14] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[14ページ]のRFC2775の大工仕事をしてください。
[CATENET] Pouzin, L., "A Proposal for Interconnecting Packet
Switching Networks," Proceedings of EUROCOMP, Brunel
University, May 1974, pp. 1023-36.
[CATENET] Pouzin、L.、「パケット交換網とインタコネクトするための提案」、EUROCOMP、Brunel大学、1974年5月、ページのProceedings 1023-36.
[STD 7] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[STD7] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
[RFC 1546] Partridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993.
[RFC1546] ヤマウズラとC.とメンデスとT.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[RFC 1597] Rekhter, Y., Moskowitz, B., Karrenberg, D. and G. de
Groot, "Address Allocation for Private Internets", RFC
1597, March 1994.
[RFC1597] Rekhter、Y.、マスコウィッツ、B.、Karrenberg、D.、およびG.deグルートは「個人的なインターネットのための配分を扱います」、RFC1597、1994年3月。
[RFC 1633] Braden, R., Clark, D. and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview",
RFC 1633, June 1994.
[RFC1633] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネットアーキテクチャにおける統合サービス:」 「概要」、RFC1633、1994年6月。
[RFC 1889] Schulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC1889] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[BCP 5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G. and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[BCP5] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[RFC 1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.
and L. Jones, "SOCKS Protocol Version 5", RFC 1928,
March 1996.
[RFC1928]のヒル、M.、Ganis、M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはバージョン5インチについて議定書の中で述べます、RFC1928、1996年3月。」
[RFC 1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1958] 1996年6月の大工、B.、「インターネットの建築プリンシプルズ」RFC1958。
[RFC 2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgement Options", RFC 2018, October
1996.
[RFC2018] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
[RFC 2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
the location of services (DNS SRV)", RFC 2052, October
1996.
[RFC2052] GulbrandsenとA.とP.Vixie、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2052、1996年10月。
[RFC 2101] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC2101] 大工とB.とクロウクロフトとJ.とY.Rekhter、「IPv4は今日ふるまいを扱う」RFC2101、1997年2月。
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、「IETFの統合サービスとのRSVPの使用」、RFC2210、1997年9月。
Carpenter Informational [Page 15] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[15ページ]のRFC2775の大工仕事をしてください。
[RFC 2309] Braden, B., Clark, D., Crowcroft, J., Davie, B.,
Deering, S., Estrin, D., Floyd, S., Jacobson, V.,
Minshall, G., Partridge, C., Peterson, L.,
Ramakrishnan, K., Shenker, S., Wroclawski, J. and L.
Zhang, "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April
1998.
[RFC2309] ブレーデンとB.とクラークとD.とクロウクロフトとJ.とデイビーとB.とデアリングとS.とEstrinとD.とフロイドとS.とジェーコブソンとV.とMinshallとG.とヤマウズラとC.とピーターソンとL.とRamakrishnanとK.、ShenkerとS.とWroclawskiとJ.とL.チャン、「インターネットの待ち行列管理と輻輳回避の推薦」RFC2309(1998年4月)。
[RFC 2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[RFC 2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[NAT-ARCH] Hain, T., "Architectural Implications of NAT", Work in
Progress.
[ナット-アーチ] ハイン、T.、「NATの建築含意」が進行中で働いています。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator (NAT)", Work in
Progress.
[NAT-PROT] 「IPネットワークアドレス変換機構(NAT)とのプロトコル複雑さ」というHoldrege、M.、およびP.Srisureshは進行中で働いています。
[SECMECH] Bellovin, S., "Security Mechanisms for the Internet",
Work in Progress.
S.、「インターネットへのセキュリティー対策」という[SECMECH]Bellovinは進行中で働いています。
[RSIP] Lo, J., Borella, M. and D. Grabelsky, "Realm Specific
IP: A Framework", Work in Progress.
[RSIP] 見よ、J.、Borella、M.、およびD.Grabelsky、「分野の特定のIP:」 「フレームワーク」、処理中の作業。
[HIP] Moskowitz, R., "The Host Identity Payload", Work in
Progress.
[クールな] マスコウィッツ、R.、「ホストアイデンティティ有効搭載量」が進行中で働いています。
Carpenter Informational [Page 16] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[16ページ]のRFC2775の大工仕事をしてください。
Author's Address
作者のアドレス
Brian E. Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
ブライアンE.大工IBM気付iCAIRスイート150 1890カエデAvenue IL60201エバンストン(米国)
EMail: brian@icair.org
メール: brian@icair.org
Carpenter Informational [Page 17] RFC 2775 Internet Transparency February 2000
インターネット透明2000年2月に情報[17ページ]のRFC2775の大工仕事をしてください。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Carpenter Informational [Page 18]
大工情報です。[18ページ]
一覧
スポンサーリンク
