RFC1710 日本語訳
1710 Simple Internet Protocol Plus White Paper. R. Hinden. October 1994. (Format: TXT=56910 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group: R. Hinden Request for Comments: 1710 Sun Microsystems Category: Informational October 1994
作業部会をネットワークでつないでください: R。 Hindenはコメントのために以下を要求します。 1710年のサン・マイクロシステムズカテゴリ: 情報の1994年10月
Simple Internet Protocol Plus White Paper
簡単なインターネットプロトコルと白書
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 作者、そして/または、 sipp@sunroof.eng.sun.com メーリングリストにコメントを提出するべきです。
1. Introduction
1. 序論
This white paper presents an overview of the Simple Internet Protocol plus (SIPP) which is one of the candidates being considered in the Internet Engineering Task Force (IETF) for the next version of the Internet Protocol (the current version is usually referred to as IPv4). This white paper is not intended to be a detailed presentation of all of the features and motivation for SIPP, but is intended to give the reader an overview of the proposal. It is also not intended that this be an implementation specification, but given the simplicity of the central core of SIPP, an implementor familiar with IPv4 could probably construct a basic working SIPP implementation from reading this overview.
この白書はインターネットプロトコルの次のバージョンのためにインターネット・エンジニアリング・タスク・フォース(IETF)で考えられる候補のひとりであるSimpleインターネットプロトコルと(SIPP)の概要を提示します(通常、最新版はIPv4と呼ばれます)。 この白書は、SIPPに関する特徴と動機のすべての詳細なプレゼンテーションであることを意図しませんが、提案の概要を読者に与えることを意図します。 また、これが実装仕様であることを意図しませんでしたが、SIPPの中央のコアの簡単さを考えて、IPv4に詳しい作成者は、この概要を読むので、たぶん基本的な働くSIPP実装を構成できました。
SIPP is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. It can be installed as a normal software upgrade in internet devices and is interoperable with the current IPv4. Its deployment strategy was designed to not have any "flag" days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future.
SIPPはIPv4からの進化論のステップになるように設計されているIPの新しいバージョンです。 それはIPv4への自然な増分です。 それは、通常のソフトウェアの更新としてインターネットデバイスにインストールできて、現在のIPv4と共に共同利用できます。 展開戦略は、どんな「旗」も何日も持たないように設計されました。 SIPPは高性能ネットワーク(例えば、ATM)で順調であるように設計されていて、低い帯域幅ネットワーク(例えば、ワイヤレス)には、同時に、まだ効率的です。 さらに、それは近い将来必要である新しいインターネットの機能性にプラットホームを提供します。
This white paper describes the work of IETF SIPP working group. Several individuals deserve specific recognition. These include Steve Deering, Paul Francis, Dave Crocker, Bob Gilligan, Bill
この白書はIETF SIPPワーキンググループの仕事について説明します。 何人かの個人が特定の認識に値します。 これらはスティーブ・デアリング、ポール・フランシス、デーヴ・クロッカー、ボブ・ギリガン、ビルを含んでいます。
Hinden [Page 1] RFC 1710 SIPP IPng White Paper October 1994
Hinden[1ページ]RFC1710SIPP IPng白書1994年10月
Simpson, Ran Atkinson, Bill Fink, Erik Nordmark, Christian Huitema, Sue Thompson, and Ramesh Govindan.
アトキンソン、ビルFink、エリックNordmark、クリスチャンのHuitemaは、シンプソンがトンプソン、およびRamesh Govindanを訴えると述べました。
2. Key Issues for the Next Generation of IP
2. IP次世代に、主要な問題
There are several key issues that should be used in the evaluation of any next generation internet protocol. Some are very straightforward. For example the new protocol must be able to support large global internetworks. Others are less obvious. There must be a clear way to transition the current installed base of IP systems. It doesn't matter how good a new protocol is if there isn't a practical way to transition the current operational systems running IPv4 to the new protocol.
どんな次世代インターネットプロトコルの評価にも使用されるべきであるいくつかの主要な問題があります。 或るものは非常に簡単です。 例えば、新しいプロトコルは大きいグローバルなインターネットワークをサポートすることができなければなりません。 他のものはそれほど明白ではありません。 変遷にはIPシステムの現在のインストールされたベースが明確な方法であるに違いありません。どれくらい良い新しいプロトコルが変遷への実用的な道がなければIPv4を実行する現在の基幹系システムが新しさに議定書を作るということであるかは重要ではありません。
2.1 Growth
2.1 成長
Growth is the basic issue which caused there to be a need for a next generation IP. If anything is to be learned from our experience with IPv4 it is that the addressing and routing must be capable of handling reasonable scenarios of future growth. It is important that we have an understanding of the past growth and where the future growth will come from.
成長は基本的が次世代の必要があったものにIPを発行するということです。 何かがIPv4の私たちの経験から学習されるつもりであるなら、アドレシングとルーティングが今後の成長の妥当なシナリオを扱うことができなければならないということです。 私たちには過去の成長と今後の成長がどこから来るかに関する理解があるのは、重要です。
Currently IPv4 serves what could be called the computer market. The computer market has been the driver of the growth of the Internet. It comprises the current Internet and countless other smaller internets which are not connected to the Internet. Its focus is to connect computers together in the large business, government, and university education markets. This market has been growing at an exponential rate. One measure of this is that the number of networks in current Internet (23,494 as of 1/28/94) is doubling approximately every 12 months. The computers which are used at the endpoints of internet communications range from PC's to Supercomputers. Most are attached to Local Area Networks (LANs) and the vast majority are not mobile.
現在の、IPv4はコンピュータ市場と呼ぶことができたものに役立ちます。 コンピュータ市場はインターネットの成長のドライバーです。 それはインターネットにつなげられない現在のインターネットと他の無数の、より小さいインターネットを包括します。 焦点は大企業、政府、および大学教育市場でコンピュータを一緒に接続することになっています。 この市場はネズミ算式の増加率で発展しています。 この1つの測定は現在のインターネット(1/28/94現在2万3494)のネットワークの数が12カ月毎に倍増しているということです。 インターネットコミュニケーションの終点で使用されるコンピュータはPCからSupercomputersまで及びます。 大部分はローカル・エリア・ネットワーク(LAN)に添付されます、そして、かなりの大部分モバイルではありません。
The next phase of growth will probably not be driven by the computer market. While the computer market will continue to grow at significant rates due to expansion into other areas such as schools (elementary through high school) and small businesses, it is doubtful it will continue to grow at an exponential rate. What is likely to happen is that other kinds of markets will develop. These markets will fall into several areas. They all have the characteristic that they are extremely large. They also bring with them a new set of requirements which were not as evident in the early stages of IPv4 deployment. The new markets are also likely to happen in parallel with other. It may turn out that we will look back on the last ten years of Internet growth as the time when the Internet was small and
成長の次のフェーズはたぶんコンピュータ市場によって追い立てられないでしょう。 コンピュータ市場は、学校(高校を通って基本の)や中小企業などの他の領域への拡張のためかなりの速度で成長し続けるでしょうが、それは疑わしいです。ネズミ算式の増加率で成長し続けるでしょう。 起こしそうなことは他の種類の市場が発展するということです。 これらの市場はいくつかの領域に落ちるでしょう。 特性ですが、それらは皆、非常に大きい状態でそうしました。 また、彼らはそれらと共に新しいセットのIPv4展開の初期段階に明白でなかった要件をもたらします。 また、新しい市場も他と平行して起こりそうです。 そして私たちがインターネットが小さかった時として最後の10年間のインターネットの成長を顧みるつもりであると判明するかもしれない。
Hinden [Page 2] RFC 1710 SIPP IPng White Paper October 1994
Hinden[2ページ]RFC1710SIPP IPng白書1994年10月
only doubling every year. The challenge for an IPng is to provide a solution which solves todays problems and is attractive in these emerging markets.
毎年、倍増することだけ。 IPngのための挑戦は今日の問題を解決している、これらの新興成長市場で魅力的な解決法を提供することです。
Nomadic personal computing devices seem certain to become ubiquitous as their prices drop and their capabilities increase. A key capability is that they will be networked. Unlike the majority of todays networked computers they will support a variety of types of network attachments. When disconnected they will use RF wireless networks, when used in networked facilities they will use infrared attachment, and when docked they will use physical wires. This makes them an ideal candidate for internetworking technology as they will need a common protocol which can work over a variety of physical networks. These types of devices will become consumer devices and will replace the current generation of cellular phones, pagers, and personal digital assistants. In addition to the obvious requirement of an internet protocol which can support large scale routing and addressing, they will require an internet protocol which imposes a low overhead and supports auto configuration and mobility as a basic element. The nature of nomadic computing requires an internet protocol to have built in authentication and confidentiality. It also goes without saying that these devices will need to communicate with the current generation of computers. The requirement for low overhead comes from the wireless media. Unlike LAN's which will be very high speed, the wireless media will be several orders of magnitude slower due to constraints on available frequencies, spectrum allocation, and power consumption.
遊牧民的な個人的なコンピュータ・デバイスはそれらの価格が低下して、彼らの能力が増加するのに応じて遍在するようになるのが確かに見えます。 主要な能力はそれらがネットワークでつながれるということです。 今日のネットワーク・コンピュータの大部分と異なって、それらはネットワーク付属のさまざまなタイプをサポートするでしょう。 切断されると、彼らはRFワイヤレス・ネットワークを使用するでしょう、そして、ネットワークでつながれた施設で使用されると、赤外線の付属を使用するでしょう、そして、ドッキングされると、それらは物理的なワイヤを使用するでしょう。 これは彼らがさまざまな物理ネットワークの上で働くことができる一般的なプロトコルを必要とするときそれらをインターネットワーキング技術の理想的な候補にします。 これらのタイプのデバイスは、民生品になって、携帯電話、ポケットベル、および携帯情報端末の現代を取り替えるでしょう。 大規模ルーティングとアドレシングをサポートすることができるインターネットプロトコルの明白な要件に加えて、彼らは基本要素として低いオーバーヘッドを課して、自動構成と移動性をサポートするインターネットプロトコルを必要とするでしょう。 遊牧民的なコンピューティングの本質は、認証と秘密性に建てたためにインターネットプロトコルを必要とします。 また..言うまでもない..デバイス..必要..コミュニケート..現在..コンピュータの世代 低いオーバーヘッドのための要件はワイヤレスのメディアから来ます。 非常に高い速度になるLANのものと異なって、ワイヤレスのメディアは有効な頻度、スペクトル配分、および電力消費量のときに規制で数桁より遅くなるでしょう。
Another market is networked entertainment. The first signs of this emerging market are the proposals being discussed for 500 channels of television, video on demand, etc. This is clearly a consumer market. The possibility is that every television set will become an Internet host. As the world of digital high definition television approaches, the differences between a computer and a television will diminish. As in the previous market, this market will require an Internet protocol which supports large scale routing and addressing, and auto configuration. This market also requires a protocol suite which imposes the minimum overhead to get the job done. Cost will be the major factor in the selection of a technology to use.
別の市場はネットワークでつながれたエンターテインメントです。 この新興成長市場の最初のサインはテレビ、ビデオオンデマンドなどの500個のチャンネルのために議論する提案です。 これは明確に消費市場です。 可能性はあらゆるテレビがインターネット・ホストになるということです。 デジタルハイビジョンの世界に近づくのに従って、コンピュータとテレビの違いは減少するでしょう。 前の市場のように、この市場は大規模ルーティングとアドレシングをサポートするインターネットプロトコル、および自動構成を必要とするでしょう。 また、この市場は仕事を完了させるために最小のオーバーヘッドを課すプロトコル群を必要とします。 費用は使用する技術の選択で重要な要因になるでしょう。
Another market which could use the next generation IP is device control. This consists of the control of everyday devices such as lighting equipment, heating and cooling equipment, motors, and other types of equipment which are currently controlled via analog switches and in aggregate consume considerable amounts of power. The size of this market is enormous and requires solutions which are simple, robust, easy to use, and very low cost.
次世代IPを使用できた別の市場は装置制御です。 これは現在、アナログ・スイッチを通して制御されて、集合でかなりの量のパワーを消費する照明器具、加熱、冷房装置、モーター、および他のタイプの設備などの日常のデバイスのコントロールから成ります。 この市場のサイズは、莫大であり、簡単で、強健で、使用しやすくて、非常に低い費用であるソリューションを必要とします。
Hinden [Page 3] RFC 1710 SIPP IPng White Paper October 1994
Hinden[3ページ]RFC1710SIPP IPng白書1994年10月
The challenge for the IETF in the selection of an IPng is to pick a protocol which meets today's requirements and also matches the requirements of these emerging markets. These markets will happen with or without an IETF IPng. If the IETF IPng is a good match for these new markets it is likely to be used. If not, these markets will develop something else. They will not wait for an IETF solution. If this should happen it is probable that because of the size and scale of the new markets the IETF protocol would be supplanted. If the IETF IPng is not appropriate for use in these markets, it is also probable that they will each develop their own protocols, perhaps proprietary. These new protocols would not interoperate with each other. The opportunity for the IETF is to select an IPng which has a reasonable chance to be used in these emerging markets. This would have the very desirable outcome of creating an immense, interoperable, world-wide information infrastructure created with open protocols. The alternative is a world of disjoint networks with protocols controlled by individual vendors.
IPngの選択におけるIETFのための挑戦は今日の必要条件とマッチにも触れるプロトコルにこれらの新興成長市場の要件を選ぶことです。 これらの市場はIETF IPngのあるなしにかかわらず起こるでしょう。 IETF IPngがこれらの新しい市場に、良いマッチであるなら、使用されそうです。 そうでなければ、これらの市場は他の何かを開発するでしょう。 彼らはIETFソリューションを待っていません。 これが起こるなら、新しい市場のサイズとスケールのために、IETFプロトコルが取って代わられるのは、ありえそうです。 また、これらの市場での使用には、IETF IPngが適切でないなら、それぞれそれら自身のプロトコルを開発するのも、ありえそうです、恐らく独占です。 これらの新しいプロトコルは互いと共に共同利用しないでしょう。 IETFの機会はこれらの新興成長市場で使用されるべき妥当な機会を持っているIPngを選択することです。 これで、オープン・プロトコルで莫大で、共同利用できて、世界的な情報インフラストラクチャを作成する非常に望ましい結果を作成するでしょう。 代替手段が世界である、プロトコルが個々のベンダーによって制御されているネットワークをばらばらにならせてください。
2.2. Transition
2.2. 変遷
At some point in the next three to seven years the Internet will require a deployed new version of the Internet protocol. Two factors are driving this: routing and addressing. Global internet routing based on the on 32-bit addresses of IPv4 is becoming increasingly strained. IPv4 address do not provide enough flexibility to construct efficient hierarchies which can be aggregated. The deployment of Classless Inter-Domain Routing [CIDR] is extending the life time of IPv4 routing routing by a number of years, the effort to manage the routing will continue to increase. Even if the IPv4 routing can be scaled to support a full IPv4 Internet, the Internet will eventually run out of network numbers. There is no question that an IPng is needed, but only a question of when.
次の3〜7年間で何らかのポイントでは、インターネットはインターネットプロトコルの配布している新しいバージョンを必要とするでしょう。 2つの要素がこれを運転しています: ルーティングとアドレシング。 オンに基づいてIPv4の32ビットのアドレスを発送するグローバルなインターネットがますます張りつめるようになっています。 IPv4アドレスは集めることができる効率的な階層構造を構成できるくらいの柔軟性を提供しません。 Classless Inter-ドメインルート設定[CIDR]の展開は何年もの、多くの取り組みによるIPv4ルーティングルーティングがルーティングを管理する時間が増強し続けている寿命を伸ばしています。 完全なIPv4インターネットをサポートするためにIPv4ルーティングをスケーリングできても、インターネットは結局、ネットワーク・ナンバーを使い果たすでしょう。 IPngが必要であるという疑問がない、しかし、いつに関する質問しかないか。
The challenge for an IPng is for its transition to be complete before IPv4 routing and addressing break. The transition will be much easier if IPv4 address are still globally unique. The two transition requirements which are the most important are flexibility of deployment and the ability for IPv4 hosts to communicate with IPng hosts. There will be IPng-only hosts, just as there will be IPv4- only hosts. The capability must exist for IPng-only hosts to communicate with IPv4-only hosts globally while IPv4 addresses are globally unique.
IPngのための挑戦はIPv4ルーティングとアドレシングが壊れる前に変遷が完全であることです。 IPv4アドレスがまだグローバルにユニークであるなら、変遷ははるかに簡単になるでしょう。 2つの最も重要な変遷要件が、展開の柔軟性とIPv4ホストがIPngホストとコミュニケートする能力です。 ちょうどIPv4ホストしかいないので、IPngだけホストがいるでしょう。 IPv4アドレスがグローバルにユニークである間、IPngだけホストがIPv4だけホストとグローバルにコミュニケートするように、能力は存在しなければなりません。
The deployment strategy for an IPng must be as flexible as possible. The Internet is too large for any kind of controlled rollout to be successful. The importance of flexibility in an IPng and the need for interoperability between IPv4 and IPng was well stated in a
IPngのための展開戦略はできるだけフレキシブルでなければなりません。 インターネットはどんな種類の制御初公開もうまくいっているように思えないほど大きいです。 IPngの柔軟性の重要性とIPv4とIPngの間の相互運用性の必要性はaによく述べられました。
Hinden [Page 4] RFC 1710 SIPP IPng White Paper October 1994
Hinden[4ページ]RFC1710SIPP IPng白書1994年10月
message to the sipp mailing list by Bill Fink, who is responsible for a portion of NASA's operational internet. In his message he said:
ビルFinkによるsippメーリングリストへのメッセージ。(FinkはNASAの操作上のインターネットの部分に責任があります)。 メッセージでは、彼は言いました:
"Being a network manager and thereby representing the interests of
a significant number of users, from my perspective it's safe to
say that the transition and interoperation aspects of any IPng is
*the* key first element, without which any other significant
advantages won't be able to be integrated into the user's network
environment. I also don't think it wise to think of the
transition as just a painful phase we'll have to endure en route
to a pure IPng environment, since the transition/coexistence
period undoubtedly will last at least a decade and may very well
continue for the entire lifetime of IPng, until it's replaced with
IPngng and a new transition. I might wish it was otherwise but I
fear they are facts of life given the immense installed base.
「ユーザのネットワーク環境と統合されるその結果、ネットワークマネージャであり、私の見解から、どんなIPngの変遷とinteroperation局面も*キー第1要素の、そして、重要な利点がいかなる他のもどれにならないかなしでできない*であると言うのが安全であって、多くのユーザの関心を表すということです。」 また、私は、まさしく私たちが純粋なIPng環境への途中で我慢しなければならない苦痛なフェーズとして変遷を考えるのが賢明であると思いません、変遷/共存の期間が確かに少なくとも10年間を持続して、IPngの全体の生涯非常によく続くかもしれないので、それをIPngngと新しい変遷に取り替えるまで。 私は、それがそうでなかったのですが、私が、広大なインストールされたベースを考えて、それらが現実であると恐れることを願うかもしれません。
"Given this situation, and the reality that it won't be feasible
to coordinate all the infrastructure changes even at the national
and regional levels, it is imperative that the transition
capabilities support the ability to deploy the IPng in the
piecemeal fashion... with no requirement to need to coordinate
local changes with other changes elsewhere in the Internet...
「この状況、および調整するのが可能でない現実を考えて、すべてのインフラストラクチャが国家の、そして、地方のレベルでさえ変化して、変遷能力がインターネットのほかの場所で他の変化で地域変化を調整するのが必要であるという要件なしでばらばらのファッションで…IPngを配布する能力をサポートするのは、必須です」…
"I realize that support for the transition and coexistence
capabilities may be a major part of the IPng effort and may cause
some headaches for the designers and developers, but I think it is
a duty that can't be shirked and the necessary price that must be
paid to provide as seamless an environment as possible to the end
user and his basic network services such as e-mail, ftp, gopher,
X-Window clients, etc...
「変遷と共存能力のサポートがIPng取り組みの大半であるかもしれなく、デザイナーと開発者のためにいくつかの頭痛を引き起こすかもしれないとわかりますが、私は、エンドユーザへのできるだけシームレスの環境とメール、ftp、リス、Xウィンドウクライアントなどの彼の基本的なネットワーク・サービスを提供するのが、回避できない義務と支払わなければならない必要な価格であると思います。」
"The bottom line for me is that we must have interoperability
during the extended transition period for the base IPv4
functionality..."
「私のための結論はベースIPv4の機能性のための拡張過渡期の間私たちには相互運用性がなければならないということです」…
Another way to think about the requirement for compatibility with IPv4 is to look at other product areas. In the product world, backwards compatability is very important. Vendors who do not provide backward compatibility for their customers usually find they do not have many customers left. For example, chip makers put considerable effort into making sure that new versions of their processor always run all of the software that ran on the previous model. It is unlikely that Intel would develop a new processor in the X86 family that did not run DOS and the tens of thousands of applications which run on the current versions of X86's.
IPv4との互換性のための要件について考える別の方法は他の製品領域を見ることです。 世界的と、後方に製品の中では、compatabilityは非常に重要です。 通常、後方の互換性を彼らの顧客に提供しないベンダーは、多くの顧客が彼らには残っていないのがわかります。 例えば、それらのプロセッサの新しいバージョンがいつも従来モデルで動いたソフトウェアのすべてを実行するのを確実にするのにチップメーカーはかなりの取り組みをそそぎます。 インテルがX86の最新版で動くDOSを実行しなかったX86ファミリーと何万ものアプリケーションで新しいプロセッサを開発するのは、ありそうもないです。
Operating system vendors go to great lengths to make sure new versions of their operating systems are binary compatible with their
オペレーティングシステムベンダーがそれらのオペレーティングシステムの新しいバージョンはバイナリー互換性があるのを確信するようにするかなりの長さまで行く、それら
Hinden [Page 5] RFC 1710 SIPP IPng White Paper October 1994
Hinden[5ページ]RFC1710SIPP IPng白書1994年10月
old version. For example the labels on most PC or MAC software usually indicate that they require OS version XX or greater. It would be foolish for Microsoft come out with a new version of Windows which did not run the applications which ran on the previous version. Microsoft even provides the ability for windows applications to run on their new OS NT. This is an important feature. They understand that it was very important to make sure that the applications which run on Windows also run on NT.
古いバージョン。 通常、例えば、ほとんどのPCかMACソフトウェアの上のラベルは、彼らがXXか、よりすばらしい状態でOSバージョンを必要とするのを示します。 マイクロソフトが旧バージョンで動いたアプリケーションを実行しなかったWindowsの新しいバージョンと共に出て来るので、それは愚かでしょう。 マイクロソフトは窓のアプリケーションがそれらの新しいOS NTの上で作業する能力を提供さえします。 これは重要な特徴です。 彼らは、また、Windowsで動くアプリケーションがNTの上で作業するのを確実にするのが非常に重要であったのを理解しています。
The same requirement is also true for IPng. The Internet has a large installed base. Features need to be designed into an IPng to make the transition as easy as possible. As with processors and operating systems, it must be backwards compatible with IPv4. Other protocols have tried to replace TCP/IP, for example XTP and OSI. One element in their failure to reach widespread acceptance was that neither had any transition strategy other than running in parallel (sometimes called dual stack). New features alone are not adequate to motivate users to deploy new protocols. IPng must have a great transition strategy and new features.
また、IPngに、同じ要件も本当です。 インターネットには、大きいインストールされたベースがあります。 特徴は、変遷をできるだけ簡単にするようにIPngに設計されている必要があります。 プロセッサとオペレーティングシステムなら、それは後方にIPv4と互換性があった状態であるに違いありません。 他のプロトコルはTCP/IP、例えば、XTP、およびOSIを置き換えようとしました。 広範囲の承認に達しないことにおける、ある要素はどちらもならし運転以外のどんな変遷戦略も平行にならなかったということ(時々デュアルスタックと呼ばれる)でした。 新機能だけが、新しいプロトコルを配布するためにユーザを動機づけるために適切ではありません。 IPngには、すばらしい変遷戦略と新機能がなければなりません。
3. History of the SIPP Effort
3. SIPP取り組みの歴史
The SIPP working group represents the evolution of three different IETF working groups focused on developing an IPng. The first was called IP Address Encapsulation (IPAE) and was chaired by Dave Crocker and Robert Hinden. It proposed extensions to IPv4 which would carry larger addresses. Much of its work was focused on developing transition mechanisms.
SIPPワーキンググループはIPngを開発するのに集中している3つの異なったIETFワーキンググループの発展を表します。 1番目は、IP Address Encapsulation(IPAE)と呼ばれて、デーヴ・クロッカーとロバートHindenによってまとめられました。 それは、より大きいアドレスを運ぶIPv4に拡大を提案しました。 仕事の多くが展開している変遷メカニズムに焦点を合わせられました。
Somewhat later Steve Deering proposed a new protocol evolved from IPv4 called the Simple Internet Protocol (SIP). A working group was formed to work on this proposal which was chaired by Steve Deering and Christian Huitema. SIP had 64-bit addresses, a simplified header, and options in separate extension headers. After lengthly interaction between the two working groups and the realization that IPAE and SIP had a number of common elements and the transition mechanisms developed for IPAE would apply to SIP, the groups decided to merge and concentrate their efforts. The chairs of the new SIP working group were Steve Deering and Robert Hinden.
いくらか遅いスティーブ・デアリングはSimpleインターネットプロトコル(SIP)と呼ばれるIPv4から発展された新しいプロトコルを提案しました。 ワーキンググループは、スティーブ・デアリングとクリスチャンのHuitemaによってまとめられたこの提案に取り組むために形成されました。 SIPは別々の拡張ヘッダーに64ビットのアドレス、簡易型のヘッダー、およびオプションを持っていました。 2つのワーキンググループとIPAEとSIPには多くの一般的な要素があって、IPAEのために開発された変遷メカニズムがSIPに適用されるだろうという認識との長さの相互作用の後に、グループは、それらの取り組みを合併して、結集すると決めました。 新しいSIPワーキンググループのいすは、スティーブ・デアリングとロバートHindenでした。
In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded a working group to develop the "P" Internet Protocol (Pip). Pip was a new internet protocol based on a new architecture. The motivation behind Pip was that the opportunity for introducing a new internet protocol does not come very often and given that opportunity important new features should be introduced. Pip supported variable length addressing in 16-bit units, separation of addresses from identifiers, support for provider selection, mobility, and efficient
SIPに平行です、ポール・フランシス(以前ポールTsuchiya)は「P」インターネットプロトコル(種)を開発するためにワーキンググループを設立しました。 種は新しいアーキテクチャに基づく新しいインターネットプロトコルでした。 Pipの後ろの動機は新しいインターネットプロトコルを紹介する機会が頻繁に来ないで、それを考えて、機会の重要な新機能を導入するべきであるということでした。 16ビットのユニットのアドレシング、識別子からのアドレスの分離が移動性の、そして、効率的なプロバイダー選択のためにサポートする可変長であるとサポートされた種
Hinden [Page 6] RFC 1710 SIPP IPng White Paper October 1994
Hinden[6ページ]RFC1710SIPP IPng白書1994年10月
forwarding. It included a transition scheme similar to IPAE.
推進。 それはIPAEと同様の変遷体系を含んでいました。
After considerable discussion among the leaders of the Pip and SIP working groups, they came to realize that the advanced features in Pip could be accomplished in SIP without changing the base SIP protocol as well as keeping the IPAE transition mechanisms. In essence it was possible to keep the best features of each protocol. Based on this the groups decided to merge their efforts. The new protocol was called Simple Internet Protocol Plus (SIPP). The chairs of the merged working group are Steve Deering, Paul Francis, and Robert Hinden.
PipとSIPワーキンググループのリーダーの中のかなりの議論の後に、それらはPipの高度な特徴がSIPでベースSIPプロトコルを変えて、IPAE変遷メカニズムを保たないで達成されるかもしれないとわかるようになりました。本質では、それぞれのプロトコルの最も良い特徴を保つのは可能でした。 これに基づいたグループは、それらの取り組みを合併すると決めました。 新しいプロトコルはSimpleインターネットプロトコルPlus(SIPP)と呼ばれました。 合併しているワーキンググループのいすは、スティーブ・デアリングと、ポール・フランシスと、ロバートHindenです。
4. SIPP Overview
4. SIPP概要
SIPP is a new version of the Internet Protocol, designed as a successor to IP version 4 [IPV4]. SIPP is assigned IP version number 6.
SIPPはIPバージョン4[IPV4]の後継者として設計されたインターネットプロトコルの新しいバージョンです。 IPバージョンNo.6はSIPPに割り当てられます。
SIPP was designed to take an evolutionary step from IPv4. It was not a design goal to take a radical step away from IPv4. Functions which work in IPv4 were kept in SIPP. Functions which didn't work were removed. The changes from IPv4 to SIPP fall primarily into the following categories:
SIPPは、IPv4から進化論の方法を採るように設計されました。 それはIPv4から遠くで急進的なステップで取るデザイン目標ではありませんでした。 IPv4で働いている機能はSIPPに保たれました。 働いていなかった機能を取り除きました。 IPv4からSIPPまでの変化は主として以下のカテゴリになります:
o Expanded Routing and Addressing Capabilities
o 能力を発送して、扱いながら、広げられます。
SIPP increases the IP address size from 32 bits to 64 bits, to
support more levels of addressing hierarchy and a much greater
number of addressable nodes. SIPP addressing can be further
extended, in units of 64 bits, by a facility equivalent to
IPv4's Loose Source and Record Route option, in combination
with a new address type called "cluster addresses" which
identify topological regions rather than individual nodes.
The scaleability of multicast routing is improved by adding
a "scope" field to multicast addresses.
SIPPは、階層構造とアドレス可能なノードのはるかに大きい数を扱うより多くのレベルをサポートするためにIPアドレスサイズを32ビットから64ビットまで増強します。 さらにSIPPアドレシングを広げることができます、64ビットの単位で、IPv4のLoose SourceとRecord Routeオプションに同等な施設のそばで、個々のノードよりむしろ位相的な領域を特定する「クラスタアドレス」と呼ばれる新しいアドレスタイプと組み合わせて。 マルチキャストルーティングのscaleabilityは、「範囲」分野をマルチキャストアドレスに追加することによって、改良されます。
o Header Format Simplification
o ヘッダー形式簡素化
Some IPv4 header fields have been dropped or made optional, to
reduce the common-case processing cost of packet handling and to
keep the bandwidth cost of the SIPP header almost as low as that
of IPv4, despite the increased size of the addresses. The basic
SIPP header is only four bytes longer than IPv4.
パケット取り扱いのよくある例加工費を下げて、SIPPヘッダーの帯域幅費用をIPv4のものとほとんど同じくらい低く保つためにいくつかのIPv4ヘッダーフィールドを下げるか、または任意にしました、アドレスの増強されたサイズにもかかわらず。 IPv4より何バイトも長い間、基本的なSIPPヘッダーは4歳にすぎません。
Hinden [Page 7] RFC 1710 SIPP IPng White Paper October 1994
Hinden[7ページ]RFC1710SIPP IPng白書1994年10月
o Improved Support for Options
o オプションの改良されたサポート
Changes in the way IP header options are encoded allows for more
efficient forwarding, less stringent limits on the length of
options, and greater flexibility for introducing new options in
the future.
IPヘッダーオプションがコード化される方法における変化は、より効率的な推進、オプションの長さにおけるそれほど厳しくない限界、および将来新しいオプションを紹介するための、より大きい柔軟性を考慮します。
o Quality-of-Service Capabilities
o サービスの質能力
A new capability is added to enable the labeling of packets
belonging to particular traffic "flows" for which the sender
requests special handling, such as non-default quality of
service or "real-time" service.
新しい能力は送付者が特別な取り扱いを要求する特定のトラフィック「流れ」に属すパケットのラベリングを可能にするために加えられます、非デフォルトサービスの質や「リアルタイムで」のサービスのように。
o Authentication and Privacy Capabilities
o 認証とプライバシー能力
SIPP includes the definition of extensions which provide support
for authentication, data integrity, and confidentiality. This
is included as a basic element of SIPP.
SIPPは認証、データ保全、および秘密性のサポートを提供する拡大の定義を含んでいます。 これはSIPPの基本要素として含まれています。
The SIPP protocol consists of two parts, the basic SIPP header and SIPP Options.
SIPPプロトコルは2つの部品、基本的なSIPPヘッダー、およびSIPP Optionsから成ります。
4.1 SIPP Header Format
4.1 SIPPヘッダー形式
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Payload Type | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| 流れラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ペイロード長| 有効搭載量タイプ| ホップ限界| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソースアドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 送付先アドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version 4-bit Internet Protocol version number = 6.
バージョンの4ビットのインターネットプロトコルバージョン番号=6。
Flow Label 28-bit field. See SIPP Quality of Service
section.
流れのLabelの28ビットの分野。 Service部のSIPP Qualityを見てください。
Payload Length 16-bit unsigned integer. Length of payload,
i.e., the rest of the packet following the
SIPP header, in octets.
有効搭載量Length、16ビットの符号のない整数。 すなわち、ペイロードの長さ、八重奏でSIPPヘッダーに続くパケットの残り。
Hinden [Page 8] RFC 1710 SIPP IPng White Paper October 1994
Hinden[8ページ]RFC1710SIPP IPng白書1994年10月
Payload Type 8-bit selector. Identifies the type of
header immediately following the SIPP
header. Uses the same values as the IPv4
Protocol field [STD 2, RFC 1700].
有効搭載量のTypeの8ビットのセレクタ。 すぐにSIPPヘッダーに続いて、ヘッダーのタイプを特定します。 同じくらいがIPv4プロトコルとして評価する用途は[STD2、RFC1700]をさばきます。
Hop Limit 8-bit unsigned integer. Decremented by 1
by each node that forwards the packet.
The packet is discarded if Hop Limit is
decremented to zero.
Limitを飛び越してください。8ビットの符号のない整数。 パケットを進める各ノードによって1つ減少されます。 Hop Limitがゼロまで減少するなら、パケットは捨てられます。
Source Address 64 bits. An address of the initial sender of
the packet. See [ROUT] for details.
ソースAddress64ビット。 パケットの初期の送付者のアドレス。 詳細に関して[ROUT]を見てください。
Destination Address 64 bits. An address of the intended
recipient of the packet (possibly not the
ultimate recipient, if an optional Routing
Header is present).
64ビットの目的地Address。 パケット(ことによるといずれの究極の受取人、任意のルート設定であるなら、Headerは存在していない)の意図している受取人のアドレス。
4.2 SIPP Options
4.2 SIPPオプション
SIPP includes an improved option mechanism over IPv4. SIPP options are placed in separate headers that are located between the SIPP header and the transport-layer header in a packet. Most SIPP option headers are not examined or processed by any router along a packet's delivery path until it arrives at its final destination. This facilitates a major improvement in router performance for packets containing options. In IPv4 the presence of any options requires the router to examine all options. The other improvement is that unlike IPv4, SIPP options can be of arbitrary length and the total amount of options carried in a packet is not limited to 40 bytes. This feature plus the manner in which they are processed, permits SIPP options to be used for functions which were not practical in IPv4. A good example of this is the SIPP Authentication and Security Encapsulation options.
SIPPはIPv4の上に改良されたオプションメカニズムを含んでいます。 SIPPオプションはパケットにSIPPヘッダーとトランスポート層ヘッダーの間に位置している別々のヘッダーに置かれます。 ほとんどのSIPPオプションヘッダーは、パケットの配送経路に沿ってどんなルータによっても最終的な目的地に到着するまで調べられもしませんし、処理もされません。 オプションを含んでいて、これはパケットのためにルータ性能で全面的な改良を容易にします。 IPv4では、どんなオプションの存在も、すべてのオプションを調べるためにルータを必要とします。 もう片方の改良はIPv4と異なった、SIPPオプションが任意の長さのものであることができるということです、そして、パケットで運ばれたオプションの総量は40バイトに制限されません。 それらが使用される処理許可証SIPPオプションであるこの特徴と方法は機能します(IPv4で実用的ではありませんでした)。 この好例は、SIPP AuthenticationとSecurity Encapsulationオプションです。
In order to improve the performance when handling subsequent option headers and the transport protocol which follows, SIPP options are always an integer multiple of 8 octets long, in order to retain this alignment for subsequent headers.
その後のオプションヘッダーと従うトランスポート・プロトコルを扱うとき、性能を向上させるために、長い間、いつもSIPPオプションは8つの八重奏の整数倍数です、その後のヘッダーのためのこの整列を保有するために。
Hinden [Page 9] RFC 1710 SIPP IPng White Paper October 1994
Hinden[9ページ]RFC1710SIPP IPng白書1994年10月
The SIPP option headers which are currently defined are:
現在定義されるSIPPオプションヘッダーは以下の通りです。
Option Function
--------------- ---------------------------------------
Routing Extended Routing (like IPv4 loose source
route)
Fragmentation Fragmentation and Reassembly
Authentication Integrity and Authentication
Security Encapsulation Confidentiality
Hop-by-Hop Option Special options which require hop by hop
processing
オプション機能--------------- --------------------------------------- ホップ処理でホップを必要とするルート設定Extendedルート設定(IPv4が送信元経路を発射するように)断片化Fragmentation、Reassembly Authentication Integrity、およびホップによるAuthentication Security Encapsulation Confidentiality Hop Option Specialオプション
4.3 SIPP Addressing
4.3 SIPPアドレシング
SIPP addresses are 64-bits long and are identifiers for individual nodes and sets of nodes. There are three types of SIPP addresses. These are unicast, cluster, and multicast. Unicast addresses identify a single node. Cluster addresses identify a group of nodes, that share a common address prefix, such that a packet sent to a cluster address will be delivered to one member of the group. Multicast addresses identify a group of nodes, such that a packet sent to a multicast address is delivered to all of the nodes in the group.
SIPPアドレスは、長い間64ビットであり、個々のノードとセットのノードのための識別子です。 3つのタイプのSIPPアドレスがあります。 これらは、ユニキャストと、クラスタと、マルチキャストです。 ユニキャストアドレスはただ一つのノードを特定します。 クラスタアドレスはノードのグループを特定して、そのシェアは一般的なアドレス接頭語です、クラスタアドレスに送られたパケットがグループの1人のメンバーに提供されるように。 マルチキャストアドレスはノードのグループを特定します、マルチキャストアドレスに送られたパケットがグループでノードのすべてに提供されるように。
SIPP supports addresses which are twice the number of bits as IPv4 addresses. These addresses support an address space which is four billion (2^^32) times the size of IPv4 addresses (2^^32). Another way to say this is that SIPP supports four billion internets each the size of the maximum IPv4 internet. That is enough to allow each person on the planet to have their own internet. Even with several layers of hierarchy (with assignment utilization similar to IPv4) this would allow for each person on the planet to have their own internet each holding several thousand hosts.
SIPPはIPv4アドレスとしてビットの数の2倍であるアドレスをサポートします。 これらのアドレスはIPv4アドレス(2^^32)のサイズの40億(2^^32)倍であるアドレス空間をサポートします。 これを言う別の方法はSIPPが最大のIPv4インターネットのサイズをそれぞれ40億のインターネットにサポートするということです。 それは、惑星の各人にはそれら自身のインターネットがあるのを許容するために十分です。 数個の層の階層構造(IPv4と同様の課題利用がある)があっても、これは、それぞれ数1,000人のホストを保持しながら、惑星の各人にはそれら自身のインターネットがあるのを許容するでしょう。
In addition, SIPP supports extended addresses using the routing option. This capability allows the address space to grow to 128- bits, 192-bits (or even larger) while still keeping the address units in manageable 64-bit units. This permits the addresses to grow while keeping the routing algorithms efficient because they continue to operate using 64- bit units.
さらに、SIPPは、ルーティングオプションを使用することで拡張アドレスをサポートします。 この能力で、アドレス空間は処理しやすい64ビットのユニットにまだアドレスユニットを保っている間、192ビットと(さらに大きいです)に128ビットまで成長します。 これは、それらが、64の噛み付いているユニットを使用することで作動し続けているのでルーティング・アルゴリズムを効率的に保っている間、アドレスが成長するのを許容します。
4.3.1 Unicast Addresses
4.3.1 ユニキャストアドレス
There are several forms of unicast address assignment in SIPP. These are global hierarchical unicast addresses, local-use addresses, and IPv4- only host addresses. The assignment plan for unicast addresses is described in [ADDR].
ユニキャストアドレス課題のいくつかのフォームがSIPPにあります。 これらは、グローバルな階層的なユニキャストアドレスと、地方の使用アドレスと、IPv4だけホスト・アドレスです。 ユニキャストアドレスのための課題プランは[ADDR]で説明されます。
Hinden [Page 10] RFC 1710 SIPP IPng White Paper October 1994
Hinden[10ページ]RFC1710SIPP IPng白書1994年10月
4.3.1.1 Global Unicast Addresses
4.3.1.1 グローバルなユニキャストアドレス
Global unicast addresses are used for global communication. They are the most common SIPP address and are similar in function to IPv4 addresses. Their format is:
グローバルなユニキャストアドレスはグローバルコミュニケーションに使用されます。 それらは、最も一般的なSIPPアドレスであり、機能においてIPv4アドレスと同様です。 それらの形式は以下の通りです。
|1| n bits | m bits | p bits | 63-n-m-p|
+-+-------------------+---------------------+-----------+---------+
|C| PROVIDER ID | SUBSCRIBER ID | SUBNET ID | NODE ID |
+-+-------------------+---------------------+-----------+---------+
|1| nビット| mビット| pビット| 63-n m p| +-+-------------------+---------------------+-----------+---------+ |C| プロバイダーID| 加入者ID| サブネットID| ノードID| +-+-------------------+---------------------+-----------+---------+
The first bit is the IPv4 compatibility bit, or C-bit. It indicates whether the node represented by the address is IPv4 or SIPP. SIPP addresses are provider-oriented. That is, the high-order part of the address is assigned to internet service providers, which then assign portions of the address space to subscribers, etc. This usage is similar to assignment of IP addresses under CIDR. The SUBSCRIBER ID distinguishes among multiple subscribers attached to the provider identified by the PROVIDER ID. The SUBNET ID identifies a topologically connected group of nodes within the subscriber network identified by the subscriber prefix. The NODE ID identifies a single node among the group of nodes identified by the subnet prefix.
最初のビットは、IPv4互換性ビット、またはC-ビットです。 それは、アドレスによって表されたノードがIPv4かそれともSIPPであるかを示します。 SIPPアドレスはプロバイダー指向です。 すなわち、アドレスの高位部分はインターネットサービスプロバイダーに配属されます。(次に、サービスプロバイダーはアドレス空間の部分を加入者などに割り当てます)。 この用法はCIDRの下でIPアドレスの課題と同様です。SUBSCRIBER IDはPROVIDER IDによって特定されたプロバイダーに付けられた複数の加入者の中で区別します。 SUBNET IDはaを特定します。加入者接頭語によって特定された加入者ネットワークの中でノードのグループを位相的に接続しました。 NODE IDはサブネット接頭語によって特定されたノードのグループでただ一つのノードを特定します。
4.3.1.2 Local-Use Address
4.3.1.2 地方の使用アドレス
A local-use address is a unicast address that has only local routability scope (within the subnet or within a subscriber network), and may have local or global uniqueness scope. They are intended for use inside of a site for "plug and play" local communication, for bootstrapping up to a single global addresses, and as part of an address sequence for global communication. Their format is:
地方の使用アドレスは、地方のroutability範囲(サブネットか加入者ネットワークの中の)しか持っていないユニキャストアドレスであり、地方の、または、グローバルなユニークさの範囲を持っているかもしれません。 彼らはただ一つのグローバルなアドレスへのサイトにおける「プラグアンドプレイ」ローカルのコミュニケーションにおける内面の、そして、ブートストラップ法において、上がっている使用と、グローバルコミュニケーションのためのアドレス系列の一部として意図します。 それらの形式は以下の通りです。
| 4 |
|bits| 12 bits | 48 bits |
+----+---------------+--------------------------------------------+
|0110| SUBNET ID | NODE ID |
+----+---------------+--------------------------------------------+
| 4 | |ビット| 12ビット| 48ビット| +----+---------------+--------------------------------------------+ |0110| サブネットID| ノードID| +----+---------------+--------------------------------------------+
The NODE ID is an identifier which much be unique in the domain in which it is being used. In most cases these will use a node's IEEE- 802 48bit address. The SUBNET ID identifies a specific subnet in a site. The combination of the SUBNET ID and the NODE ID to form a local use address allows a large private internet to be constructed without any other address allocation.
ユニークなコネがそれが使用されているドメインであったなら、NODE IDはどの多くに識別子であるか。 多くの場合これらはノードのIEEE802 48bit addressを使用するでしょう。 SUBNET IDはサイトで特定のサブネットを特定します。 アドレスがアドレス配分なしでいかなる他のも組み立てられるのを大きい個人的なインターネットを許容する地方の使用を形成するSUBNET IDとNODE IDの組み合わせ。
Local-use addresses have two primary benefits. First, for sites or organizations that are not (yet) connected to the global Internet, there is no need to request an address prefix from the global
地方の使用アドレスには、2つの主要便益があります。 まず最初に、(まだ)世界的なインターネットにつなげられていないサイトか組織のために、グローバルからアドレス接頭語を要求する必要は全くありません。
Hinden [Page 11] RFC 1710 SIPP IPng White Paper October 1994
Hinden[11ページ]RFC1710SIPP IPng白書1994年10月
Internet address space. Local-use addresses can be used instead. If the organization connects to the global Internet, it can use it's local use addresses to communicate with a server (e.g., using the Dynamic Host Configuration Protocol [DHCP]) to have a global address automatically assigned.
インターネット・アドレススペース。 代わりに地方の使用アドレスを使用できます。 組織が世界的なインターネットに接続するなら、それは使用がグローバルアドレスを自動的に割り当てさせるためにサーバ(例えば、Dynamic Host Configuration Protocol[DHCP]を使用する)とコミュニケートするために演説するローカルを使用できます。
The second benefit of local-use addresses is that they can hold much larger NODE IDs, which makes possible a very simple form of auto- configuration of addresses. In particular, a node may discover a SUBNET ID by listening to a Router Advertisement messages on its attached link(s), and then fabricating a SIPP address for itself by using its link-level address as the NODE ID on that subnet.
地方の使用アドレスの2番目の利益ははるかに大きいNODE IDを保持できるということです(アドレスの自動構成の非常に簡単なフォームを可能にします)。 特に、ノードは、NODE IDとしてそのサブネットでリンク・レベルアドレスを使用することによって付属リンクに関するRouter Advertisementメッセージを聞いて、次に、それ自体のためのSIPPアドレスを作ることによって、SUBNET IDを発見するかもしれません。
An auto-configured local-use address may be used by a node as its own identification for communication within the local domain, possibly including communication with a local address server to obtain a global SIPP address. The details of host auto-configuration are described in [DHCP].
自動構成された地方の使用アドレスは局所領域の中のコミュニケーションにそれ自身の識別としてノードによって使用されるかもしれません、グローバルなSIPPアドレスを得るためにことによるとローカルアドレスサーバとのコミュニケーションを含んでいて。 ホスト自動構成の詳細は[DHCP]で説明されます。
4.3.1.3 IPv4-Only Addresses
4.3.1.3 IPv4だけアドレス
SIPP unicast addresses are assigned to IPv4-only hosts as part of the IPAE scheme for transition from IPv4 to SIPP. Such addresses have the following form:
SIPPユニキャストアドレスはIPv4からSIPPまでの変遷のIPAE体系の一部としてIPv4だけホストに割り当てられます。 そのようなアドレスで、以下は形成されます:
|1| 31 bits | 32 bits |
+-+------------------------------+--------------------------------+
|1| HIGHER-ORDER SIPP PREFIX | IPv4 ADDRESS |
+-+------------------------------+--------------------------------+
|1| 31ビット| 32ビット| +-+------------------------------+--------------------------------+ |1| 高次なSIPP接頭語| IPv4アドレス| +-+------------------------------+--------------------------------+
The highest-order bit of a SIPP address is called the IPv4 compatibility bit or the C bit. A C bit value of 1 identifies an address as belonging to an IPv4-only node.
SIPPアドレスの最上位ビットはIPv4互換性ビットかCビットと呼ばれます。 1のCの噛み付いている値はIPv4だけノードに属すとしてアドレスを特定します。
The IPv4 node's 32-bit IPv4 address is carried in the low-order 32 bits of the SIPP address. The remaining 31 bits are used to carry HIGHER- ORDER SIPP PREFIX, such as a service-provider ID.
IPv4ノードの32ビットのIPv4アドレスはSIPPアドレスの下位の32ビットで運ばれます。 残っている31ビットは、サービスプロバイダーIDなどのHIGHER- ORDER SIPP PREFIXを運ぶのに使用されます。
4.3.2 Cluster Addresses
4.3.2 クラスタアドレス
Cluster addresses are unicast addresses that are used to reach the "nearest" one (according to unicast routing's notion of nearest) of the set of boundary routers of a cluster of nodes identified by a common prefix in the SIPP unicast routing hierarchy. These are used to identify a set of nodes. The cluster address, when used as part of an address sequence, permits a node to select which of several providers it wants to carry its traffic. A cluster address can only be used as a destination address. In this example there would be a
クラスタアドレスが“nearest"1に達するのに使用されるユニキャストアドレスである、(ユニキャストルーティングの概念、近さ、)、SIPPユニキャストルーティング階層構造の一般的な接頭語によって特定されたノードのクラスタの境界ルータのセットについて。 これらは、1セットのノードを特定するのに使用されます。 アドレス系列の一部として使用されると、クラスタアドレスは、ノードが、それがいくつかのプロバイダーのどれをトラフィックを運びたがっているかを選択することを許可します。 送付先アドレスとしてクラスタアドレスを使用できるだけです。 中では、そこのこの例はaでしょう。
Hinden [Page 12] RFC 1710 SIPP IPng White Paper October 1994
Hinden[12ページ]RFC1710SIPP IPng白書1994年10月
cluster address for each provider. This capability is sometimes called "source selected policies". Cluster addresses have the general form:
各プロバイダーのためのアドレスをクラスタリングさせてください。 この能力は時々「ソースの選択された方針」と呼ばれます。 クラスタアドレスには、一般的なフォームがあります:
| n bits | 64-n bits |
+---------------------------------+-------------------------------+
| CLUSTER PREFIX |0000000000000000000000000000000|
+---------------------------------+-------------------------------+
| nビット| 64-nビット| +---------------------------------+-------------------------------+ | クラスタ接頭語|0000000000000000000000000000000| +---------------------------------+-------------------------------+
4.3.3 Multicast Addresses
4.3.3 マルチキャストアドレス
A SIPP multicast address is an identifier for a group of nodes. A node may belong to any number of multicast groups. Multicast addresses have the following format:
SIPPマルチキャストアドレスはノードのグループのための識別子です。 ノードはいろいろなマルチキャストグループのもの、かもしれません。 マルチキャストアドレスには、以下の形式があります:
|1| 7 | 4 | 4 | 48 bits |
+-+-------+----+----+---------------------------------------------+
|C|1111111|FLGS|SCOP| GROUP ID |
+-+-------+----+----+---------------------------------------------+
|1| 7 | 4 | 4 | 48ビット| +-+-------+----+----+---------------------------------------------+ |C|1111111|FLGS|SCOP| グループID| +-+-------+----+----+---------------------------------------------+
Where:
どこ:
C = IPv4 compatibility bit.
CはIPv4互換性ビットと等しいです。
1111111 in the rest of the first octet identifies the address as
being a multicast address.
1111111 1つの番目ものの残りでは、八重奏はマルチキャストアドレスであるとしてアドレスを特定します。
+-+-+-+-+
FLGS is a set of 4 flags: |0|0|0|T|
+-+-+-+-+
+++++FLGSは4個の旗のセットです: |0|0|0|T| +-+-+-+-+
The high-order 3 flags are reserved, and must be initialized to 0.
高位3個の旗を予約されていて、0に初期化しなければなりません。
T = 0 indicates a permanently-assigned ("well-known") multicast
address, assigned by the global internet numbering authority.
T=0はグローバルなインターネット付番権威によって割り当てられた永久に割り当てられた(「よく知られる」)マルチキャストアドレスを示します。
T = 1 indicates a non-permanently-assigned ("transient") multicast
address.
T=1は非永久に割り当てられた(「一時的な」)マルチキャストアドレスを示します。
SCOP is a 4-bit multicast scope value used to limit the scope of
the multicast group. The values are:
SCOPはマルチキャストグループの範囲を制限するのに使用される4ビットのマルチキャスト範囲価値です。 値は以下の通りです。
0 reserved 8 intra-organization scope
1 intra-node scope 9 (unassigned)
2 intra-link scope 10 (unassigned)
3 (unassigned) 11 intra-community scope
4 (unassigned) 12 (unassigned)
0 予約された8 11イントラ共同体範囲4(割り当てられません)1つのイントラノードのイントラ組織範囲の範囲9の(割り当てられません)2イントラリンク範囲10(割り当てられません)3(割り当てられない)12(割り当てられません)
Hinden [Page 13] RFC 1710 SIPP IPng White Paper October 1994
Hinden[13ページ]RFC1710SIPP IPng白書1994年10月
5 intra-site scope 13 (unassigned)
6 (unassigned) 14 global scope
7 (unassigned) 15 reserved
5 グローバルな範囲7(割り当てられません)15が予約したイントラサイト範囲13(割り当てられません)6(割り当てられない)14
GROUP ID identifies the multicast group, either permanent or
transient, within the given scope.
GROUP IDは与えられた範囲の中で永久的であるか一時的なマルチキャストグループを特定します。
4.4 SIPP Routing
4.4 SIPPルート設定
Routing in SIPP is almost identical to IPv4 routing under CIDR except that the addresses are 64-bit SIPP addresses instead of 32-bit IPv4 addresses. This is true even when extended addresses are being used. With very straightforward extensions, all of IPv4's routing algorithms (OSPF, BGP, RIP, IDRP, etc.) can used to route SIPP [OSPF] [RIP2] [IDRP].
アドレスが32ビットのIPv4アドレスの代わりに64ビットのSIPPアドレスであるのを除いて、SIPPのルート設定はCIDRの下のIPv4ルーティングとほとんど同じです。 拡張アドレスが使用されてさえいるとき、これは本当です。 非常に簡単な拡大で、IPv4のルーティング・アルゴリズム(OSPF、BGP、リップ、IDRPなど)のすべてが以前は、よくSIPP[OSPF][RIP2][IDRP]を発送できました。
SIPP also includes simple routing extensions which support powerful new routing functionality. These capabilities include:
また、SIPPは強力な新しいルーティングが機能性であるとサポートする簡単なルーティング拡大を含んでいます。 これらの能力は:
Provider Selection (based on policy, performance, cost, etc.)
Host Mobility (route to current location)
Auto-Readdressing (route to new address)
Extended Addressing (route to "sub-cloud")
プロバイダーSelection(方針、性能、費用などに基づいています) ホストMobility(現在の位置に発送する)自動Readdressing(新しいアドレスに発送する)はAddressingを広げました。(「サブ雲」へのルート)
The new routing functionality is obtained by creating sequences of SIPP addresses using the SIPP Routing option. The routing option is used by a SIPP source to list one or more intermediate nodes (or topological clusters) to be "visited" on the way to a packet's destination. This function is very similar in function to IPv4's Loose Source and Record Route option. A node would publish its address sequence in the Domain Name System [DNS].
SIPPルート設定オプションを使用することでSIPPアドレスの系列を作成することによって、新しいルーティングの機能性を得ます。 ルーティングオプションは、パケットの目的地への途中を「訪問される」ために、1つ以上の中間的ノード(または、位相的なクラスタ)をリストアップするのにSIPPソースによって使用されます。 この機能は機能においてIPv4のLoose SourceとRecord Routeオプションと非常に同様です。 ノードはドメインネームシステム[DNS]におけるアドレス系列を発表するでしょう。
The identification of a specific transport connection is done by only using the first (source) and last (destination) address in the sequence. These identifying addresses (i.e., first and last addresses of a route sequence) are required to be unique within the scope over which they are used. This permits the middle addresses in the address sequence to change (in the cases of mobility, provider changes, site readdressing, etc.) without disrupting the transport connection.
系列における最初(ソース)と最後の(目的地)のアドレスを使用するだけで特定の輸送接続の識別をします。 アドレス(ルート系列のすなわち、1番目と最後のアドレス)を特定するこれらが、範囲で中それらが使用されている特有になるのに必要です。 これは、アドレス系列の中央アドレスが輸送接続を中断しないで変化するのを(移動性に関するケース、プロバイダー変化、サイトのあて名を書き直すことで)許容します。
In order to make address sequences a general function, SIPP hosts are required to reverse routes in a packet it receives containing address sequences in order to return the packet to its originator. This approach is taken to make SIPP host implementations from the start support the handling and reversal of source routes. This is the key for allowing them to work with hosts which implement the new features such as provider selection or extended addresses.
アドレス系列を一般的な機能にするように、パケットを創始者に返すためにアドレス系列を含んで、SIPPホストはそれが受けるパケットのルートを逆にしなければなりません。 スタートサポートからのSIPPホスト導入を送信元経路の取り扱いと反転にするようにこのアプローチを取ります。 これは、彼らがホストと共に働いているのを許容するためのキーです(プロバイダー選択か拡張アドレスなどの新機能を実装します)。
Hinden [Page 14] RFC 1710 SIPP IPng White Paper October 1994
Hinden[14ページ]RFC1710SIPP IPng白書1994年10月
Three examples show how the extended addressing can be used. In these examples, address sequences are shown by a list of individual addresses separated by commas. For example:
3つの例がどう拡張アドレシングを使用できるかを示しています。 これらの例では、アドレス系列はコンマによって切り離された個々のアドレスのリストによって示されます。 例えば:
SRC, I1, I2, I3, DST
SRC、I1、I2、I3、DST
Where the first address is the source address, the last address is the destination address, and the middle addresses are intermediate addresses.
最初のアドレスがソースアドレスであるところでは、最後のアドレスは送付先アドレスです、そして、中央アドレスは中間的アドレスです。
For these examples assume that two hosts, H1 and H2 wish to communicate. Assume that H1 and H2's sites are both connected to providers P1 and P2. A third wireless provider, PR, is connected to both providers P1 and P2.
これらの例に関しては、2人のホスト、H1とH2が交信したがっていると仮定してください。 H1とH2のサイトがともにプロバイダーのP1とP2につなげられると仮定してください。 3番目のワイヤレスのプロバイダー(PR)はプロバイダーP1とP2の両方に接続されます。
----- P1 ------
/ | \
/ | \
H1 PR H2
\ | /
\ | /
----- P2 ------
----- P1------ / | \ / | \H1PR H2\| / \ | / ----- P2------
The simplest case (no use of address sequences) is when H1 wants to send a packet to H2 containing the addresses:
最も簡単なケース(アドレス系列の無駄)はH1がアドレスを含むH2にパケットを送りたがっている時です:
H1, H2
H1、H2
When H2 replied it would reverse the addresses and construct a packet containing the addresses:
H2が返答したとき、アドレスを逆にして、アドレスを含むパケットを組み立てるでしょう:
H2, H1
H2、H1
In this example either provider could be used, and H1 and H2 would not be able to select which provider traffic would be sent to and received from.
この例では、どちらのプロバイダーも使用できました、そして、H1とH2はプロバイダートラフィックがどれであるかを選択できないでしょう。発信して、受け取ります。
If H1 decides that it wants to enforce a policy that all communication to/from H2 can only use provider P1, it would construct a packet containing the address sequence:
プロバイダーP1、H1が、H2からの/へのすべてのコミュニケーションが使用できるだけである方針を実施したがっていると決めるなら、アドレス系列を含むパケットを組み立てるでしょう:
H1, P1, H2
H1、P1、H2
This ensures that when H2 replies to H1, it will reverse the route and the reply it would also travel over P1. The addresses in H2's reply would look like:
これは、H2がH1に答えると、また、P1の上を旅行するルートと回答を逆にするのを確実にします。 H2の回答におけるアドレスに似ているでしょう:
H2, P1, H1
H2、P1、H1
Hinden [Page 15] RFC 1710 SIPP IPng White Paper October 1994
Hinden[15ページ]RFC1710SIPP IPng白書1994年10月
If H1 became mobile and moved to provider PR, it could maintain (not breaking any transport connections) communication with H2, by sending packets that contain the address sequence:
H1がモバイルになって、プロバイダーPRに移行するなら、H2とのコミュニケーションを維持するかもしれないでしょうに(少しの輸送の接続も調教しません)、アドレス系列を含むパケットを送ることによって:
H1, PR, P1, H2
H1、PR、P1、H2
This would ensure that when H2 replied it would enforce H1's policy of exclusive use of provider P1 and send the packet to H1 new location on provider PR. The reversed address sequence would be:
これは、H2が返答したとき、H1のプロバイダーP1の専用の方針を実施するのを確実にして、プロバイダーPRでH1の新しい位置にパケットを送るでしょう。 逆にされたアドレス系列は以下の通りでしょう。
H2, P1, PR, H1
H2、P1、PR、H1
The address extension facility of SIPP can be used for provider selection, mobility, readdressing, and extended addressing. It is a simple but powerful capability.
プロバイダー選択、移動性、あて名を書き直すこと、および拡張アドレシングにSIPPのアドレス拡大施設を使用できます。 それは簡単な、しかし、強力な能力です。
4.5 SIPP Quality-of-Service Capabilities
4.5 SIPPサービスの質能力
The Flow Label field in the SIPP header may be used by a host to label those packets for which it requests special handling by SIPP routers, such as non-default quality of service or "real-time" service. This labeling is important in order to support applications which require some degree of consistent throughput, delay, and/or jitter. The Flow Label is a 28-bit field, internally structured into three subfields as follows:
SIPPヘッダーのFlow Label分野はそれがSIPPルータから特別な取り扱いを要求するそれらのパケットをラベルするのにホストによって使用されるかもしれません、非デフォルトサービスの質や「リアルタイムで」のサービスのように。 このラベリングは、いくらかの一貫したスループット、遅れ、そして/または、ジターを必要とするアプリケーションをサポートするために重要です。 Flow Labelは内部的に以下の3つの部分体に構造化された28ビットの分野です:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| DP | Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| DP| 流れID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reserved) 1-bit subfield. Initialized to zero for
transmission; Ignored on reception.
R(予約される)1ビットの部分体。 トランスミッションのためにゼロに初期化されます。 レセプションでは、無視されます。
DP (Drop Priority) 3-bit unsigned integer. Specifies the
priority of the packet, relative to other
packets from the same source, for being
discarded by a router under conditions of
congestion. Larger values indicates a
greater willingness by the sender to allow
the packet to be discarded.
DP、(Priorityを下げます)3ビットの符号のない整数。 同じソースからの他のパケットに比例して混雑に関する条件のもとでルータによって捨てられるのにパケットの優先権を指定します。 より大きい値は、パケットが捨てられるのを許容するために送付者で、よりすごい意欲を示します。
Flow ID 24-bit subfield used to identify a
specific flow.
流れのIDの24ビットの部分体は以前はよく特定の流れを特定していました。
A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. There may be multiple active flows from a source to a destination, as well as
流れは特定のソースから特定(ユニキャストかマルチキャスト)のソースが介入しているルータで特別な取り扱いを望んでいる目的地に送られたパケットの系列です。 また、複数のアクティブなソースから目的地までの流れがあるかもしれません。
Hinden [Page 16] RFC 1710 SIPP IPng White Paper October 1994
Hinden[16ページ]RFC1710SIPP IPng白書1994年10月
traffic that is not associated with any flow. A flow is identified by the combination of a Source Address and a non-zero Flow ID. Packets that do not belong to a flow carry a Flow ID of zero.
どんな流れにも関連づけられないトラフィック。 流れはSource Addressの組み合わせと非ゼロFlow IDによって特定されます。 流れに属さないパケットがゼロのFlow IDを運びます。
A Flow ID is assigned to a flow by the flow's source node. New Flow IDs must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow ID suitable for use as a hash key by the routers, for looking up the special-handling state associated with the flow. A Flow ID must not be re-used by a source for a new flow while any state associated with the previous usage still exists in any router.
Flow IDは流れのソースノードによって流れに割り当てられます。 範囲1からFFFFFF十六進法まで無作為に一様に新しいFlow IDを選ばなければなりません(疑似な)。 無作為の配分の目的はナンバー記号のキーとしてルータで使用に適したFlow IDの中でどんなセットのビットも作ることです、流れに関連している特別な取り扱い状態を見上げるために。 前の用法に関連しているどんな状態もどんなルータでもまだ存在している間、Flow IDは新しい流れにソースによって再使用されてはいけません。
The Drop Priority subfield provides a means separate from the Flow ID for distinguishing among packets from the same source, to allow a source to specify which of its packets are to be discarded in preference to others when a router cannot forward them all. This is useful for applications like video where it is preferable to drop packets carrying screen updates rather than the packets carrying the video synchronization information.
Drop Priority部分体はソースが、ルータが彼らを皆、進めることができないとき、パケットのどれが他のものに優先して捨てられることになっていたらよいかを指定するのを許容するためにパケットの中で同じソースと区別するのに、Flow IDから別々の手段を提供します。 これはパケットを下げるのが望ましいビデオ同期情報を運びながらパケットよりむしろスクリーンアップデートを運ぶビデオのようなアプリケーションの役に立ちます。
4.6 SIPP Security
4.6 SIPPセキュリティ
The current Internet has a number of security problems and lacks effective privacy and authentication mechanisms below the application layer. SIPP remedies these shortcomings by having two integrated options that provide security services. These two options may be used singly or together to provide differing levels of security to different users. This is very important because different user communities have different security needs.
現在のインターネットは、多くの警備上の問題を持っていて、応用層の下に有効なプライバシーと認証機構を欠いています。 SIPPは、セキュリティー・サービスを提供する2つの統合オプションを持っていることによって、これらの短所を改善します。 これらの2つのオプションが、異なったレベルのセキュリティを異なったユーザに提供するのに単独か一緒に使用されるかもしれません。 異なったユーザーコミュニティには異なった安全要求があるので、これが非常に重要です。
The first mechanism, called the "SIPP Authentication Header", is an option which provides authentication and integrity (without confidentiality) to SIPP datagrams. While the option is algorithm- independent and will support many different authentication techniques, the use of keyed MD5 is proposed to help ensure interoperability within the worldwide Internet. This can be used to eliminate a significant class of network attacks, including host masquerading attacks. The use of the SIPP Authentication Header is particularly important when source routing is used with SIPP because of the known risks in IP source routing. Its placement at the internet layer can help provide host origin authentication to those upper layer protocols and services that currently lack meaningful protections. This mechanism should be exportable by vendors in the United States and other countries with similar export restrictions because it only provides authentication and integrity, and specifically does not provide confidentiality. The exportability of the SIPP Authentication Header encourages its widespread
「SIPP認証ヘッダー」と呼ばれる第1メカニズムは認証と保全(秘密性のない)をSIPPデータグラムに供給するオプションです。オプションがアルゴリズム独立者であり、多くの異なった認証のテクニックをサポートしている間、合わせられたMD5の使用は、世界的なインターネットの中で相互運用性を確実にするのを助けるために提案されます。 ホスト仮装攻撃を含む重要なクラスのネットワーク攻撃を排除するのにこれを使用できます。 ソースルーティングがIPソースルーティングにおける知られているリスクのためにSIPPと共に使用されるとき、SIPP Authentication Headerの使用は特に重要です。 インターネット層のプレースメントは、上側であることのそれらへのホスト発生源認証に層のプロトコルを提供して、現在欠けているサービスに重要な保護を提供するのを助けることができます。 認証と保全を提供するだけであり、明確に秘密性は提供しないので、このメカニズムは合衆国と他国におけるベンダーは同様の輸出制限で輸出向きであるべきです。 exportabilityに、SIPP Authentication Header督励では、それは広範囲です。
Hinden [Page 17] RFC 1710 SIPP IPng White Paper October 1994
Hinden[17ページ]RFC1710SIPP IPng白書1994年10月
implementation and use.
実装と使用。
The second security option provided with SIPP is the "SIPP Encapsulating Security Header". This mechanism provides integrity and confidentiality to SIPP datagrams. It is simpler than some similar security protocols (e.g., SP3D, ISO NLSP) but remains flexible and algorithm-independent. To achieve interoperability within the global Internet, the use of DES CBC is proposed as the standard algorithm for use with the SIPP Encapsulating Security Header.
SIPPが提供された2番目のセキュリティオプションは「セキュリティがヘッダーであるとカプセル化するSIPP」です。 このメカニズムは保全と秘密性をSIPPデータグラムに供給します。それは、いくつかの同様のセキュリティプロトコル(例えば、SP3D、ISO NLSP)より簡単ですが、フレキシブルであって、アルゴリズムから独立しているままです。 世界的なインターネットの中で相互運用性を達成するために、DES CBCの使用はSIPP Encapsulating Security Headerとの使用のための標準のアルゴリズムとして提案されます。
5. SIPP Transition Mechanisms
5. SIPP変遷メカニズム
The two key motivations in the SIPP transition mechanisms are to provide direct interoperability between IPv4 and SIPP hosts and to allow the user population to adopt SIPP in an a highly diffuse fashion. The transition must be incremental, with few or no critical interdependencies, if it is to succeed. The SIPP transition allows the users to upgrade their hosts to SIPP, and the network operators to deploy SIPP in routers, with very little coordination between the two.
SIPP変遷メカニズムの主要な動機が提供することになっている2はIPv4とSIPPホストの間の相互運用性を指示します、そして、ユーザ人口が中にSIPPを採用するのを許容するために、aはファッションを非常に拡散させます。 成功するつもりであるなら、変遷はわずかであるか重要でない相互依存性で増加であるに違いありません。 ユーザはルータでSIPPを配布するためにSIPP変遷で彼らのSIPPのホスト、およびネットワーク・オペレータをアップグレードさせることができます、2つの間には、非常に少ないコーディネートがある状態で。
The mechanisms and policies of the SIPP transition are called "IPAE". Having a separate term serves to highlight those features designed specifically for transition. Once an acronym for an encapsulation technique to facilitate transition, the term "IPAE" now is mostly historical.
SIPP変遷のメカニズムと方針は"IPAE"と呼ばれます。 別々の用語を過すのは、特に変遷のために設計されたそれらの特徴を目立たせるのに役立ちます。 かつて、変遷、現在の用語"IPAE"の間の促進するカプセル化技術のための頭文字語はほとんど歴史的です。
The IPAE transition is based on five key elements:
IPAE変遷は5つの主要な要素に基づいています:
1) A 64-bit SIPP addressing plan that encompasses the existing
32-bit IPv4 addressing plan. The 64-bit plan will be used to
assign addresses for both SIPP and IPv4 nodes at the beginning
of the transition. Existing IPv4 nodes will not need to change
their addresses, and IPv4 hosts being upgraded to SIPP keep their
existing IPv4 addresses as the low-order 32 bits of their SIPP
addresses. Since the SIPP addressing plan is a superset of the
existing IPv4 plan, SIPP hosts are assigned only a single 64-bit
address, which can be used to communicate with both SIPP and IPv4
hosts.
1) プランがそれであると扱う64ビットのSIPPは既存の32ビットのIPv4アドレシングプランを包含します。 64ビットのプランは、変遷の始めにSIPPとIPv4ノードの両方のためのアドレスを割り当てるのに使用されるでしょう。 既存のIPv4ノードは住所を変更する必要はないでしょう、そして、SIPPにアップグレードするIPv4ホストはそれらのSIPPアドレスの下位の32ビットとして彼らの既存のIPv4アドレスを保管します。 SIPPアドレシングプランが既存のIPv4プランのスーパーセットであるので、ただ一つの64ビットのアドレスだけをSIPPホストに割り当てます。(SIPPとIPv4ホストの両方で交信するのにそれを使用できます)。
2) A mechanism for encapsulating SIPP traffic within IPv4 packets so
that the IPv4 infrastructure can be leveraged early in the
transition. Most of the "SIPP within IPv4 tunnels" can be
automatically configured.
2) 早く変遷でIPv4インフラストラクチャを利用することができるようにIPv4パケットの中でSIPPがトラフィックであるとカプセル化するためのメカニズム。 自動的に「IPv4トンネルの中のSIPP」の大部分を構成できます。
Hinden [Page 18] RFC 1710 SIPP IPng White Paper October 1994
Hinden[18ページ]RFC1710SIPP IPng白書1994年10月
3) Algorithms in SIPP hosts that allow them to directly interoperate
with IPv4 hosts located on the same subnet and elsewhere in the
Internet.
3) 彼らをIPv4ホストと共に直接共同利用させるSIPPホストのアルゴリズムは同じサブネットの上とインターネットのほかの場所で場所を見つけられました。
4) A mechanism for translating between IPv4 and SIPP headers to
allow SIPP-only hosts to communicate with IPv4-only hosts and to
facilitate IPv4 hosts communicating over over a SIPP-only
backbone.
4) SIPPだけホストがIPv4だけホストとコミュニケートして、SIPPだけバックボーンの上で交信するIPv4ホストを容易にするのを許容するためにIPv4とSIPPヘッダーの間で翻訳するためのメカニズム。
5) An optional mechanism for mapping IPv4 addresses to SIPP address
to allow improved scaling of IPv4 routing. At the present time
given the success of CIDR, this does not look like it will be
needed in a transition to SIPP. If Internet growth should
continue beyond what CIDR can handle, it is available as an
optional mechanism.
5) 許容するSIPPアドレスにIPv4アドレスを写像するための任意のメカニズムはIPv4ルーティングのスケーリングを改良しました。 現在では、CIDRの成功を考えて、これは、それがSIPPへの変遷で必要であるように見えません。 インターネットの成長がそうするなら、CIDRが扱うことができることを超えて続いてください、そして、それは任意のメカニズムとして利用可能です。
IPAE ensures that SIPP hosts can interoperate with IPv4 hosts anywhere in the Internet up until the time when IPv4 addresses run out, and afterward allows SIPP and IPv4 hosts within a limited scope to interoperate indefinitely. This feature protects for a very long time the huge investment users have made in IPv4. Hosts that need only a limited connectivity range (e.g., printers) need never be upgraded to SIPP. This feature also allows SIPP-only hosts to interoperate with IPv4-only hosts.
IPAEは、ホストがIPv4アドレスがなくなる時までのインターネットと、その後IPv4ホストと共にどこでも共同利用できるSIPPが限られた範囲の中のSIPPとIPv4ホストを無期限に共同利用させるのを確実にします。 この特徴は巨大な投資ユーザがIPv4で作った非常に長い時間、保護されます。 限られた接続性範囲(例えば、プリンタ)だけを必要とするホストをSIPPに決してアップグレードさせてはいけません。 また、この特徴で、SIPPだけホストはIPv4だけホストと共に共同利用できます。
The incremental upgrade features of IPAE allow the host and router vendors to integrate SIPP into their product lines at their own pace, and allows the end users and network operators to deploy SIPP on their own schedules.
IPAEの増加のアップグレード機能は、それら自身のスケジュールにエンドユーザとネットワーク・オペレータがSIPPを配布するのをホストとルータベンダーがそれら自身ののそれらの製品ラインとSIPPを統合するのを許容して、許容します。
The interoperability between SIPP and IPv4 provided by IPAE also has the benefit of extending the lifetime of IPv4 hosts. Given the large installed base of IPv4, changes to IPv4 in hosts are nearly impossible. Once an IPng is chosen, most of the new feature development will be done on IPng. New features in IPng will increase the incentives to adopt and deploy it.
また、IPAEによって提供されたSIPPとIPv4の間の相互運用性には、IPv4ホストの生涯を広げる利益があります。 IPv4の大きいインストールされたベースを考えて、ホストのIPv4への変化はほとんど不可能です。 いったんIPngを選ぶと、IPngで新機能開発の大部分をするでしょう。 IPngの新機能はそれを採用して、配布する誘因を増強するでしょう。
6. Why SIPP?
6. なぜSIPP?
There are a number of reasons why SIPP should be selected as the IETF's IPng. It solves the Internet scaling problem, provides a flexible transition mechanism for the current Internet, and was designed to meet the needs of new markets such as nomadic personal computing devices, networked entertainment, and device control. It does this in a evolutionary way which reduces the risk of architectural problems.
SIPPがIETFのIPngとして選定されるべきである多くの理由があります。 それは、インターネットスケーリング問題を解決して、現在のインターネットへのフレキシブルな変遷メカニズムを提供して、遊牧民的な個人的なコンピュータ・デバイスや、ネットワークでつながれたエンターテインメントや、装置制御などの新しい市場の需要を満たすように設計されました。 それは建築問題の危険を減少させる進化論の方法でこれをします。
Hinden [Page 19] RFC 1710 SIPP IPng White Paper October 1994
Hinden[19ページ]RFC1710SIPP IPng白書1994年10月
Ease of transition is a key point in the design of SIPP. It is not something was was added in at the end. SIPP is designed to interoperate with IPv4. Specific mechanisms (C-bit, embedded IPv4 addresses, etc.) were built into SIPP to support transition and compatability with IPv4. It was designed to permit a gradual and piecemeal deployment without any dependencies.
変遷の容易さはSIPPのデザインで要所です。 何かがあったということではありません。終わりに加えられました。 SIPPは、IPv4と共に共同利用するように設計されています。 SIPPは、IPv4と共に変遷とcompatabilityをサポートするために特定のメカニズム(Cで噛み付いていて、埋め込まれたIPv4アドレスなど)に組み込まれました。 それは、少しも依存なしでゆるやかでばらばらの展開を可能にするように設計されました。
SIPP supports large hierarchical addresses which will allow the Internet to continue to grow and provide new routing capabilities not built into IPv4. It has cluster addresses which can be used for policy route selection and has scoped multicast addresses which provide improved scaleability over IPv4 multicast. It also has local use addresses which provide the ability for "plug and play" installation.
SIPPはインターネットが新しいIPv4が組み込まれなかったルーティング能力を育てて、提供し続けることができる大きい階層的なアドレスをサポートします。 それは、方針ルート選択に使用できるクラスタアドレスを持って、IPv4マルチキャストの上に改良されたscaleabilityを提供するマルチキャストアドレスを見ました。 また、それで、ローカルは「プラグアンドプレイ」インストールに能力を提供するアドレスを使用します。
SIPP is designed to have performance better than IPv4 and work well in low bandwidth applications like wireless. Its headers are less expensive to process than IPv4 and its 64-bit addresses are chosen to be well matched to the new generation of 64bit processors. Its compact header minimizes bandwidth overhead which makes it ideal for wireless use.
SIPPは、ワイヤレスのような低い帯域幅アプリケーションで上手に性能をIPv4と仕事より良くするように設計されています。 ヘッダーは、処理するためにIPv4とその64ビットのアドレスが64ビットのプロセッサの新しい世代によく匹敵されるために選ばれているほど高価ではありません。 コンパクトなヘッダーはそれをワイヤレスの使用に理想的にする帯域幅オーバーヘッドを最小にします。
SIPP provides a platform for new Internet functionality. This includes support for real-time flows, provider selection, host mobility, end-to- end security, auto-configuration, and auto- reconfiguration.
SIPPは新しいインターネットの機能性にプラットホームを提供します。 これはリアルタイムの流れ、プロバイダー選択、ホストの移動性、終わりから終わりへのセキュリティ、自動構成、および自動再構成のサポートを含んでいます。
In summary, SIPP is a new version of IP. It can be installed as a normal software upgrade in internet devices. It is interoperable with the current IPv4. Its deployment strategy was designed to not have any "flag" days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future.
概要では、SIPPはIPの新しいバージョンです。 通常のソフトウェアの更新としてインターネットデバイスにそれをインストールできます。 それは現在のIPv4と共に共同利用できます。 展開戦略は、どんな「旗」も何日も持たないように設計されました。 SIPPは高性能ネットワーク(例えば、ATM)で順調であるように設計されていて、低い帯域幅ネットワーク(例えば、ワイヤレス)には、同時に、まだ効率的です。 さらに、それは近い将来必要である新しいインターネットの機能性にプラットホームを提供します。
Hinden [Page 20] RFC 1710 SIPP IPng White Paper October 1994
Hinden[20ページ]RFC1710SIPP IPng白書1994年10月
7. Status of SIPP Effort
7. SIPP取り組みの状態
There are many active participants in the SIPP working group. Groups making active contributions include:
SIPPワーキンググループの多くの積極的な参加者がいます。 活発な貢献をするグループは:
Group Activity --------------------- ---------------------------------------- Beame & Whiteside Implementation (PC) Bellcore Implementation (SunOS), DNS and ICMP specs. Digital Equipment Corp. Implementation (Alpha/OSF, Open VMS) INRIA Implementation (BSD, BIND), DNS & OSPF specs. INESC Implementation (BSD/Mach/x-kernel) Intercon Implementation (MAC) MCI Phone Conferences Merit IDRP for SIPP Specification Naval Research Lab. Implementation (BSD) Security Design Network General Implementation (Sniffer) SGI Implementation (IRIX, NetVisulizer) Sun Implementation (Solaris 2.x, Snoop) TGV Implementation (Open VMS) Xerox PARC Protocol Design Bill Simpson Implementation (KA9Q)
グループ活動--------------------- ---------------------------------------- Beame、ホワイトサイドImplementation(PC)Bellcore Implementation(SunOS)、DNS、およびICMP眼鏡。 ディジタル・イクイップメント社Implementation INRIA Implementation(BSD、BIND)、DNS、およびOSPF(アルファー/OSF、オープンVMS)仕様。 INESC実装(x BSD/マッハ/カーネル)Intercon実装(MAC)MCI電話コンファレンスはSIPPの仕様の海軍の研究研究室へのIDRPに値します。 実装(BSD)のセキュリティのデザインのネットワークの司令官の実装(パケット盗聴プログラム)SGI実装(IRIX、NetVisulizer)Sun実装(Solaris2.x、スヌープ)TGV Implementation(開いているVMS)ゼロックスのPARCプロトコルデザインビル・シンプソンの実装(KA9Q)
As of the time this paper was written there were a number of SIPP and IPAE implementations. These include:
この論文が書かれた時点で、多くのSIPPとIPAE実装がありました。 これらは:
Implementation Status -------------- ------------------------------------ BSD/Mach Completed (telnet, NFS, AFS, UDP) BSD/Net/2 In Progress Bind Code done DOS &Windows Completed (telnet, ftp, tftp, ping) IRIX In progress (ping) KA9Q In progress (ping, TCP) Mac OS Completed (telnet, ftp, finger, ping) NetVisualizer Completed (SIP & IPAE) Open VMS Completed (telnet, ftp), In Progress OSF/1 In Progress (ping, ICMP) Sniffer Completed (SIP & IPAE) Snoop Completed (SIP & IPAE) Solaris Completed (telnet, ftp, tftp, ping) Sun OS In Progress
実装状態-------------- ------------------------------------ DOSが行われたBSD/マッハCompleted(telnet、NFS、AFS、UDP)BSD/ネット/2In Progress Bind CodeとWindows Completed(telnet、ftp、tftpは確認する)IRIX In進歩(ピング)KA9Q InはMac OS Completed(telnet、ftp、指は確認する)NetVisualizer Completed(SIP&IPAE)の開いているVMS Completed(telnet、ftp)を進行します(TCP、確認してください)、In Progress OSF/1In Progress(ピング、ICMP)パケット盗聴プログラムCompleted(SIP&IPAE)スヌープCompleted(SIP&IPAE)Solaris Completed(telnet、ftp、tftpは確認する)Sun OS In Progress
Hinden [Page 21] RFC 1710 SIPP IPng White Paper October 1994
Hinden[21ページ]RFC1710SIPP IPng白書1994年10月
8. Where to Get Additional Information
8. どこで、追加情報を得ますか。
The documentation listed in the reference sections can be found in one of the IETF internet draft directories or in the archive site for the SIPP working group. This is located at:
IETFインターネット草稿ディレクトリの1つかSIPPワーキンググループのためのアーカイブサイトで参照部で記載されたドキュメンテーションは見つけることができます。 これは以下に位置しています。
ftp.parc.xerox.com in the /pub/sipp directory.
/pub/sippディレクトリのftp.parc.xerox.com。
In addition other material relating to SIPP (such as postscript versions of presentations on SIPP) can also be found in the SIPP working group archive.
また、さらに、SIPPワーキンググループアーカイブでSIPP(SIPPにおけるプレゼンテーションの追伸バージョンなどの)に関連する他の材料は見つけることができます。
To join the SIPP working group, send electronic mail to
SIPPワーキンググループに加わって、電子メールを送ります。
sipp-request@sunroof.eng.sun.com
sipp-request@sunroof.eng.sun.com
An archive of mail sent to this mailing list can be found in the IETF directories at cnri.reston.va.us.
cnri.reston.va.usのIETFディレクトリでこのメーリングリストに送られたメールのアーカイブを見つけることができます。
9. Security Considerations
9. セキュリティ問題
Security issues are discussed in section 4.6.
セクション4.6で安全保障問題について議論します。
10. Author's Address
10. 作者のアドレス
Robert M. Hinden Manager, Internet Engineering Sun Microsystems, Inc. MS MTV5-44 2550 Garcia Ave. Mt. View, CA 94303
インターネット工学サン・マイクロシステムズ・インクMS MTV5-44 2550ガルシアAveのロバートM.Hindenマネージャ。 カリフォルニア View山、94303
Phone: (415) 336-2082 Fax: (415) 336-6016 EMail: hinden@eng.sun.com
以下に電話をしてください。 (415) 336-2082 Fax: (415) 336-6016 メールしてください: hinden@eng.sun.com
11. References
11. 参照
[ADDR] Francis, P., "Simple Internet Protocol Plus (SIPP): Unicast
Hierarchical Address Assignment", Work in Progress, January
1994.
[ADDR] フランシス、P.、「簡単なインターネットはそのうえ(SIPP)、以下について議定書の中で述べます」。 「ユニキャストの階層的なアドレス課題」、処理中の作業、1994年1月。
[AUTH] Atkinson, R., "SIPP Authentication Payload",
Work in Progress, January, 1994.
[AUTH] アトキンソン、R.、「SIPP認証有効搭載量」が進歩、1994年1月に働いています。
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:
an Address Assignment and Aggregation Strategy", RFC 1338,
BARRNet, cisco, Merit, OARnet, June 1992.
[CIDR] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 「Address AssignmentとAggregation Strategy」、RFC1338、BARRNet、コクチマス、Merit、OARnet、6月1992日
Hinden [Page 22] RFC 1710 SIPP IPng White Paper October 1994
Hinden[22ページ]RFC1710SIPP IPng白書1994年10月
[DISC] Simpson, W., "SIPP Neighbor Discovery", Work in Progress,
March 1994.
[ディスク] シンプソン、W.、「SIPP隣人発見」が進歩、1994年3月に働いています。
[DIS2] Simpson, W., "SIPP Neighbor Discovery -- ICMP Message
Formats", Work in Progress, March 1994.
[DIS2] シンプソン、w.、「SIPPは発見を近所付き合いさせます--ICMPは書式を通信する」処理中の作業が1994を行進させます。
[DHCP] Thomson, S., "Simple Internet Protocol Plus (SIPP): Automatic
Host Address Assignment", Work in Progress, March 1994.
[DHCP] トムソン、S.、「簡単なインターネットはそのうえ(SIPP)、以下について議定書の中で述べます」。 「自動ホスト・アドレス課題」、処理中の作業、1994年3月。
[DNS] Thomson, S., and C. Huitema, "DNS Extensions to Support
Simple Internet Protocol Plus (SIPP)", Work in Progress,
March 1994.
[DNS] トムソン、S.、C.Huitema、および「簡単なインターネットがプロトコルであるとサポートするDNS拡張子と(SIPP)」は進歩、1994年3月に働いています。
[ICMP] Govindan, R., and S. Deering, "ICMP and IGMP for the Simple
Internet Protocol Plus (SIPP)", Work in Progress, March 1994.
R.、S.デアリング、「簡単なインターネットへのICMPとIGMPはそのうえ、(SIPP)について議定書の中で述べる」という[ICMP]Govindanは進行中(1994年3月)で働いています。
[IDRP] Hares, S., "IDRP for SIP", Work in Progress, November 1993.
S.、「一口のためのIDRP」という[IDRP]野兎は進歩、1993年11月に働いています。
[IPAE] Gilligan, R., et al, "IPAE: The SIPP Interoperability and
Transition Mechanism", Work in Progress, March 1994.
[IPAE]ギリガン、R.、他、「IPAE:」 「SIPP相互運用性と変遷メカニズム」は進歩、1994年3月に働いています。
[IPV4] Postel, J., "Internet Protocol- DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA,
September 1981.
[IPV4] ポステル、J.、「インターネットプロトコルDARPAインターネットプログラムプロトコル仕様」、STD5、RFC791、DARPA、1981年9月。
[OSPF] Francis, P., "OSPF for SIPP", Work in Progress, February
1994.
[OSPF] フランシス、P.、「SIPPのためのOSPF」が進歩、1994年2月に働いています。
[RIP2] Malkin, G., and C. Huitema, "SIP-RIP", Work in Progress,
March 1993.
[RIP2] マルキン、G.、およびC.Huitema、「一口裂け目」が進歩、1993年3月に働いています。
[ROUT] Deering, S., et al, "Simple Internet Protocol Plus (SIPP):
Routing and Addressing", Work in Progress, February 1994.
[ROUT] デアリング、S.、他、「簡単なインターネットはそのうえ(SIPP)、以下について議定書の中で述べます」。 「ルート設定とアドレシング」は進歩、1994年2月に働いています。
[SARC] Atkinson, R., "SIPP Security Architecture", Work in Progress,
January 1994.
[SARC] アトキンソン、R.、「SIPPセキュリティー体系」が進歩、1994年1月に働いています。
[SECR] Atkinson, R., "SIPP Encapsulating Security Payload (ESP)",
Work in Progress, January 1994.
[SECR] アトキンソン、R.、「セキュリティが有効搭載量(超能力)であるとカプセル化するSIPP」が進歩、1994年1月に働いています。
[SIPP] Deering, S., "Simple Internet Protocol Plus (SIPP)
Specification", Work in Progress, February 1994.
[SIPP] デアリングと、S.と、「簡単なインターネットプロトコルと(SIPP)仕様」は進歩、1994年2月に働いています。
Hinden [Page 23]
Hinden[23ページ]
一覧
スポンサーリンク
