RFC1955 日本語訳
1955 New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG.R. Hinden. June 1996. (Format: TXT=10115 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden Request for Comments: 1955 Ipsilon Networks, Inc. Category: Informational June 1996
Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1955IpsilonはInc.カテゴリをネットワークでつなぎます: 情報の1996年6月
New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG
インターネットルート設定の新しい計画とIPNGのために(ENCAPS)を記述すること。
Status of This 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 big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
This memo describes a proposal made to to the Routing and Addressing group [ROAD] January 1992 by Robert Hinden. It was originally sent as an email message. It proposes a medium term solution to the Internet's routing and addressing problems.
このメモは1992年1月にロバートHindenでルート設定とAddressingに分類するのがされた提案[ROAD]について説明します。 元々、メールメッセージとしてそれを送りました。 それはインターネットのルーティングとその問題を訴える中期ソリューションを提案します。
INTRODUCTION
序論
I would like to propose a new scheme which I believe is a good medium term solution to the routing and address problems of the internet. It has the following positive attributes:
私がインターネットのルーティングとアドレス問題の良い中期ソリューションであると信じている新しい計画を提案したいと思います。 それには、以下の上向きの属性があります:
- No Changes to Hosts - No Changes to Most Routers - No New Routing Protocols - No New Internet Protocols - No Translation of Addresses in Packets - Reduces the Routing Table Size in All Routers - Uses the Current Internet Address Structure
- ホストへの変化がありません--ほとんどのルータへの変化がありません--新しいルーティング・プロトコルがありません--どんな新しいインターネットプロトコル(パケットでアドレスに関する翻訳がない)もすべてのルータにおけるルート設定テーブル・サイズを減少させません--現在のインターネットアドレス構造を使用します。
It is not a solution good for all time, because it does impose some size limits and does not support new internet services such as guaranteed bandwidth, delay, etc. It does require border routers to do additional processing, but does not require any packet translation. I believe that this scheme will give us enough time to put into place a long term solution (i.e. pick one or more of CLNP, *NAT, IDPR, IDRP, Nimrod, Unified, NewIP, etc.)
それは時間中に良い解決策ではありません、帯域幅、遅れなどが保証されるように、いくつかのサイズ限界を課して、新しいインターネットサービスを支持しないので それは、追加処理をするために境界ルータを必要としますが、少しのパケット翻訳も必要としません。 私は、この計画が長期解決策を場所に入れることができるくらいの時間を私たちに与えると信じています。(すなわち、CLNPの1つ以上、*NAT、IDPR、IDRP、ニムロデ、Unified、NewIPなどを選びます)
Hinden Informational [Page 1] RFC 1955 IP Encaps June 1996
[1ページ]RFC1955IP Encaps1996年6月の情報のHinden
This scheme is based on the ideas presented by Deborah Estrin (route on ADs), Martha Steenstrup (encapsulation), and probably steals from ideas put forward by Noel Chiappa, Van Jacobson , Ross Callon, Dave Oran, and everyone else in the ROAD group.
この計画はデボラEstrin(ADsでは、発送する)、マーサ・ステーンストルプ(カプセル化)、およびたぶんもうけ物によってROADグループでクリスマスChiappa、ヴァン・ジェーコブソン、ロスCallon、デーヴ・オラン、および他の人皆によって提唱された考えから提示された考えに基づいています。
CONTEXT
文脈
I think that we (the ROAD group) agree that in the short term we need to make better use of the IP address space. I think we also (mostly) agree that in the long term we need a solution that can deal with a very large number of end points and routes, as well as support new services such as guarantees of service, source selected routes, etc. We do not agree on any of the details of this but do agree that we can not figure out a long term solution before March. We do agree that we should start working on a long term solution(s).
私は、私たち(ROADグループ)が、短期で私たちが、有効にIPアドレス空間を利用する必要であるのに同意すると思います。 私たちも、長期で私たちがエンドポイントと非常に多くのルートに対処できる解決策を必要として、サービスの保証、ソースの選択されたルートなどの新種業務を支持するのに同意すると思います。 私たちは、この詳細のいずれにも同意しませんが、3月以前長期解決策を理解できないのに同意します。 私たちは、長期解決策で就業するべきであるのに同意します。
What this leaves is the need for a good medium term solution which can keep the Internet going until we can design and deploy a long term solution. The medium term solution wants to be the most "cost effective". It should buy us the most time to develop a long term solution and do it with as little change to the existing Internet as possible.
これが残すものは私たちが長期解決策を設計して、配備できるまでインターネットを行かせ続けることができる良い中期ソリューションの必要性です。 解決策という中型の用語は最も「費用効率がよくしたがっています」。 それは長期解決策を見いだして、既存のインターネットへのできるだけ小さい変化でそれをする最も多くの時間を私たちに買うべきです。
I propose this scheme as a new medium term solution.
私は新しい中期ソリューションとしてこの計画を提案します。
NEW SCHEME
新しい計画
The basic idea is that inter-domain routing be done by routing on autonomous domains (AD). The key is how this is done. The mechanism to do this is for the border routers to encapsulate the original IP datagrams with another IP header. The source and destination addresses in the new header (I will call it the AD-Header from here on) represent the source and destination ADs.
基本的な考え方は自治のドメイン(AD)でルーティングで相互ドメインルーティングをするということです。 キーはこれがどう完了しているかということです。 これをするメカニズムは境界ルータが別のIPヘッダーと共にオリジナルのIPデータグラムを要約することです。 新しいヘッダー(私は、これからそれをADヘッダーと呼ぶつもりである)の情報筋と送付先アドレスはソースと目的地ADsの代理をします。
When the first (entrance) border router receives a datagram from a host or router without an AD-Header it looks at the source and destination address and does a DNS lookup to get the addresses for the AD-Header. It then adds an AD-Header and forwards the encapsulated datagram to its proper destination AD.
最初(入り口)の境界ルータがホストかルータからADヘッダーなしでデータグラムを受けるとき、ADヘッダーにアドレスを届けると、ソースと送付先アドレスが見て、DNSルックアップはします。 それは、次に、ADヘッダーを加えて、要約のデータグラムを適切な目的地に送ります。西暦。
The border routers would compute AD routes by running a routing protocol between themselves. BGP or even IS-IS or OSPF for that matter, would work fine. As you will see later, they might even be better.
境界ルータは、自分たちの間のルーティング・プロトコルを走らせることによって、ADルートを計算するでしょう。 BGPか同等である、-、OSPF、さらに言えば、きめ細かに、働いているでしょう。 あなたが後で見るように、彼らはさらに良いかもしれません。
The addresses I propose to use for the AD addresses are plain old IP addresses. A small number of Class A and Class B addresses would be reserved for this purpose. The network number of the address would
私がADアドレスに使用するよう提案するアドレスは明瞭な古いIPアドレスです。 少ない数のClass AとClass Bアドレスがこのために予約されるでしょう。 アドレスのネットワーク・ナンバーはそうするでしょう。
Hinden Informational [Page 2] RFC 1955 IP Encaps June 1996
[2ページ]RFC1955IP Encaps1996年6月の情報のHinden
indicate that it was an AD identifier. The local part of the address would indicate the actual AD. This would allow for many ADs to be supported. For example, 10 Class-A and 10 Class-B addresses could accommodate (10*2^24 + 10*2^16) 168,427,500 ADs. We clearly don't need that many for a long time.
それがAD識別子であったのを示してください。 アドレスの地方の部分は実際のADを示すでしょう。 これは、多くのADsが支持されるのを許容するでしょう。 例えば、10Class-Aと10のClass-Bアドレスが1億6842万7500ADsを収容するかもしれません(10*2^24+10*2^16)。 私たちは長い間、明確に多くそれを必要としません。
The reason why I would chose to get more than one network number to use to represent the AD address is I would use them to organize the ADs. Let's call them commonwealths. Each commonwealth would only have to know the detail of it's own ADs.
私がそうする理由は、ADアドレスを表すのに使用する1つのネットワーク・ナンバーが私がADsを組織化するのにそれらを使用するだろうということであるより以上を得るのを選びました。 それらを共和国と呼びましょう。 各共和国は、それの詳細が自身のADsであることを知るだけでよいでしょう。
Next I would have the border routers inject these AD addresses into the Intra-AD routing of transit ADs. They would tell the routers inside of the transit AD that they (the border routers) were the route to each appropriate AD network. Commonwealths that have multiple interconnects (probably the common case) could by the use of careful assignment of the AD addresses use subnetting to support reasonable routing between the commonwealths. This is where OSPF or IS-IS might be better than BGP. Also, IS-IS, with its ability to route on actual end points might be the best.
次に、私は境界ルータにトランジットADsのIntra-西暦のルーティングにこれらのADアドレスを注がせるでしょう。 彼らは、それら(境界ルータ)がルートであったADのときにそれぞれADネットワークを当てるようにトランジットのルータ内部に言うでしょう。 複数の内部連絡(たぶんよくある例)を持っている英連邦は、共和国の間の合理的なルーティングを支持するのにADアドレスの慎重な課題の使用でサブネッティングを使用できるでしょう。 または、これがどこOSPFであるか、-、BGPより良くいるかもしれなくなってください。 また、-、ベストは実際のエンドポイントで発送する性能がある、そうです。
The motivation behind injecting the AD addresses into the Intra-AD routing of the transit ADs, is that the routers in these ADs can forward the AD-Headers without knowing that they are special. Only the entrance and exit border routers are required to do anything different.
トランジットADsのIntra-西暦のルーティングにADアドレスを注ぐ後ろの動機は彼らが特別であることを知らないこれらのADsのルータがADヘッダーを進めることができるということです。 入り口と出口境界ルータだけが、何か異なったことをするのに必要です。
Finally when a AD-Header is received at the last (exit) border router it strips off the AD-Header and sends the datagram to the final destination.
最終的に、最後の(出口)境界ルータでADヘッダーを受け取るとき、それは、ADヘッダーを全部はぎ取って、最終的な目的地にデータグラムを送ります。
This scheme is based around the idea that IP addresses are globally unique. I think that we will not actually run out of IP addresses for a long time and that we can live with the current addressing until we can deploy a long term solution.
この計画はIPアドレスがグローバルにユニークであるという考えの周りに基づいています。 私たちが実際に長い間IPアドレスを使い果たすつもりでなくて、長期解決策を配備できるまで現在のアドレシングを受け入れることができると思います。
This scheme could be extended to not require globally unique IP address. Effectively the combination of AD-Address and IP-Address is the globally unique address. To use this scheme without globally unique IP-Addresses and without changing in the hosts would require a NAT mechanism in the border routers. I think it would be preferable to change the hosts to have them do the DNS query and add the AD- header. This could be the basis for the long term solution.
グローバルにユニークなIPアドレスを必要としないようにこの計画を広げることができました。 事実上、ADアドレスとIP-アドレスの組み合わせはグローバルにユニークなアドレスです。 グローバルにユニークなIP-アドレスなしでホストで変化することなしでこの計画を使用するのは境界ルータでNATメカニズムを必要とするでしょう。 私は、彼らがDNS質問をして、ADヘッダーを加えるのを持つためにホストを変えるのが望ましいと思います。 これは長期解決策の基礎であるかもしれません。
Another interesting aspect of this scheme is that if we were to relax the current architecture where one IP-Address is always in only one AD, to allow an IP-Address to be in more than one AD, it would provide a solution to the issue of allowing a IP entity to get
この計画の別のおもしろい局面は私たちが西暦1以上年に、IP-アドレスがあるのを許容するために、あるADの中にいつも1つのIP-アドレスがある現在の建築だけを弛緩するなら、得るIP実体を許容する問題の解決法を提供するだろうということです。
Hinden Informational [Page 3] RFC 1955 IP Encaps June 1996
[3ページ]RFC1955IP Encaps1996年6月の情報のHinden
service from more than one service provider.
1つ以上のサービスプロバイダーからのサービス。
SUMMARY OF CHANGES REQUIRED
変化の概要が必要です。
The DNS needs to be extended to add an AD-Address entry for each name. These will be used by the entry and exit border routers to get the AD-Addresses to use when building the AD-Headers.
DNSは、各名前のためのADアドレスエントリーを加えるために広げられる必要があります。 これらはADヘッダーを造るときADアドレスに使用させるエントリーと出口境界ルータによって使用されるでしょう。
Border routers need to be extended to do the DNS lookup, perform AD- Header encapsulation, run an inter-AD routing algorithm using AD- Addresses, and be able to AD-Header de-encapsulation.
境界ルータは、DNSルックアップをして、ADヘッダーカプセル化を実行して、ADアドレスを使用することで相互ADルーティング・アルゴリズムを走らせて、ADヘッダー反-カプセル化にできるために広げられる必要があります。
CONCLUSION
結論
I believe that this scheme has may advantages. These are:
私は、この計画がそうしたと信じています。利点はそうするかもしれません。 これらは以下の通りです。
- Only border routers and the DNS need change. No changes are required in hosts or non-border routers.
- 境界ルータとDNSだけが変化を必要とします。 変化は全くホストか非境界ルータで必要ではありません。
- No performance impact on datagram forwarding except at entry and exit border routers.
- エントリー以外のデータグラム推進と出口境界ルータへの性能影響がありません。
- Only a small impact on bandwidth utilization on transit networks due the addition of a 20 byte IP header to each datagram.
- トランジットの帯域幅利用への小さい影響は支払われるべきものをネットワークでつなぐだけです。20バイトIPヘッダーの各データグラムへの追加。
- Removes the Inter-AD routing from Intra-AD routing and as a result solves the routing load (table size and computation) problem for the foreseeable future.
- Intra-西暦のルーティングからInter-西暦のルーティングを移して、その結果ルーティング負荷(テーブル・サイズと計算)問題を予見できる未来に解決します。
- The routing load on the border routers is manageable because border routers only need to know the detail of the routing commonwealth they are a member of. Other commonwealths appear as single addresses.
- 境界ルータが、彼らがメンバーであるというルーティング共和国の細部を知る必要があるだけであるので境界ルータに関する負荷が処理しやすいルーティング。 他の共和国はただ一つのアドレスとして現れます。
- No requirement for new routing protocols to be designed or deployed.
- 新しいルーティング・プロトコルが設計されているか、または配備されるという要件がありません。
- No translation of packets from one address scheme to another.
- パケットに関する1つのアドレス計画から別の計画までの翻訳がありません。
- Uses the current IP addressing structure.
- 構造を記述する現在のIPを使用します。
- It scales well even if there is on the order of one AD per IP network, because the AD-Addresses can be assigned logically.
- 1IPあたりの西暦1年の注文にネットワークがあっても、それはよく比例します、ADアドレスを論理的に割り当てることができるので。
Hinden Informational [Page 4] RFC 1955 IP Encaps June 1996
[4ページ]RFC1955IP Encaps1996年6月の情報のHinden
It does have some disadvantages. These are (at least):
それには、いくつかの損失があります。 これらは(少なくとも)以下の通りです。
- It is not a long term solution in its initial form.
- それは初期のフォームでの長くはない期間ソリューションです。
- It assumes that the current IP-Addresses can remain globally unique for a long time.
- それは、現在のIP-アドレスが長い間グローバルにユニークなままであることができると仮定します。
REFERENCES
参照
[ROAD] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, ANS, Stanford University, November 1992.
[道路] グロス、P.とP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」RFC1380、ANS、スタンフォード大学、1992年11月。
SECURITY CONSIDERATIONS
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
AUTHOR'S ADDRESS
作者のアドレス
Robert M. Hinden Ipsilon Networks, Inc. 2191 East Bayshore Road Suite 100 Palo Alto, CA 94303 USA
ロバートM.Hinden IpsilonはInc.2191東Bayshore道路Suite100カリフォルニア94303パロアルト(米国)をネットワークでつなぎます。
EMail: hinden@ipsilon.com Phone: +1 (415) 846-4604
メール: hinden@ipsilon.com 電話: +1 (415) 846-4604
Hinden Informational [Page 5]
Hinden情報です。[5ページ]
一覧
スポンサーリンク