RFC1383 日本語訳
1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. (Format: TXT=32680 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Huitema
Request for Comments: 1383 INRIA
December 1992
Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 1383 INRIA1992年12月
An Experiment in DNS Based IP Routing
DNSでの実験はIPルート設定を基礎づけました。
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Routing, scaling and hierarchies ...................... 1 2. Routing based on MX records ........................... 2 3. Evaluation of DNS routing ............................. 3 3.1 Loops and relays ..................................... 4 3.2 Performances and scaling ............................. 5 3.3 Tunneling or source routing .......................... 6 3.4 Choosing a gateway ................................... 6 3.5 Routing dynamics ..................................... 6 3.6 DNS connectivity ..................................... 7 3.7 On the way back ...................................... 8 3.8 Flirting with policy routing ......................... 8 4. Rationales for deployment ............................. 9 4.1 The good citizens .................................... 10 4.2 The commercial approach .............................. 10 5. The experimental development .......................... 11 5.1 DNS record ........................................... 11 5.2 Interface with the standard IP router ................ 12 5.3 The DNS query manager ................................ 12 5.4 The real time forwarder .............................. 12 5.5 Interaction with routing protocols ................... 13 6. Acknowledgments ....................................... 13 7. Conclusion ............................................ 13 8. References ............................................ 14 9. Security Considerations ............................... 14 10. Author's Address ..................................... 14
1. ルート設定、スケーリング、および階層構造… 1 2. ルート設定は記録をMXに基礎づけました… 2 3. DNSルーティングの評価… 3 3.1 輪にして、リレーします。 4 3.2のパフォーマンスとスケーリング… 5 3.3 トンネリングかソースルーティング… 6 3.4 ゲートウェイを選びます… 6 3.5 ルート設定力学… 6 3.6DNSの接続性… 7 3.7 逆、に途中… 8 3.8 方針ルーティングをもてあそびます… 8 4. 展開のための原理… 9 4.1 善良な市民… 10 4.2 商業アプローチ… 10 5. 実験的な開発… 11 5.1DNSが記録します… 11 5.2 標準のIPルータに連結してください… 12 5.3 DNSはマネージャについて質問します… 12 5.4 リアルタイムの混載業者… 12 ルーティング・プロトコルとの5.5相互作用… 13 6. 承認… 13 7. 結論… 13 8. 参照… 14 9. セキュリティ問題… 14 10. 作者のアドレス… 14
1. Routing, scaling and hierarchies
1. ルート設定、スケーリング、および階層構造
Several recent studies have outlined the risk of "routing explosion" in the current Internet: there are already more than 5000 networks announced in the NSFNET routing tables, more than 7000 in the EBONE
いくつかの最近の研究が現在のインターネットの「ルーティング爆発」の危険について概説しました: そこでは、既に5000以上のネットワークがNSFNET経路指定テーブルでEBONEの7000年よりもう少し発表されますか?
Huitema [Page 1] RFC 1383 DNS based IP routing December 1992
Huitema[1ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
routing tables. As these numbers are growing, several problems occur:
テーブルを発送します。 これらの数が成長しているとき、いくつかの問題が起こります:
* The size of the routing tables grows linearly with the
number of connected networks; handling this larger tables
requires more resources in all "intelligent" routers, in
particular in all "transit" and "external" routers that
cannot rely on default routes.
* 経路指定テーブルのサイズは接続ネットワークの数で直線的になります。 このより大きいテーブルを扱うのはすべての「知的な」ルータにおける、より多くのリソースを必要とします、特にデフォルトルートを当てにすることができないすべての「トランジット」と「外部」のルータで。
* The volume of information carried by the route exchange
protocols such as BGP grows with the number of networks,
using more network resources and making the reaction to
routing events slower.
* ネットワークの数に応じて、BGPなどのルート交換プロトコルによって運ばれた情報量は成長します、より多くのネットワーク資源を使用して、ルーティングイベントへの反応をより遅くして。
* Explicit administrative decisions have to be exercised by
all transit networks administrators which want to
implement "routing policies" for each and every
additional "multi-homed" network.
* どれがありとあらゆるも、追加している「ルーティング方針」を実行したがっているかという明白な管理決定がすべての輸送網の管理者によって運動させられなければならない、「マルチ、家へ帰り、」 ネットワークでつなぎます。
The current "textbook" solution to the routing explosion problem is to use "hierarchical routing" based on hierarchical addresses. This is largely documented in routing protocols such as IDRP, and is one of the rationales for deploying the CIDR [3] addressing structure in the Internet. This textbook solution, while often perfectly adequate, as a number of inconveniences, particularly in the presence of "multihomed stubs", e.g., customer networks that are connected to more than one service providers.
ルーティング爆発問題の現在の「教科書」解決は階層的なアドレスに基づく「階層型ルーティング」を使用することです。 これは、IDRPなどのルーティング・プロトコルで主に記録されて、インターネットの構造を記述しながらCIDR[3]を配備するための原理の1つです。 多くの不便で、特に「「マルチ-家へ帰」っているスタッブ」、例えば1つ以上のサービスプロバイダーに接続される顧客ネットワークがあるときしばしば完全に適切である間のこの教科書解決。
The current proposal presents a scheme that allows for simple routing. It is complementary with the classic "hierarchical routing" approach, but provides an easy to implement and low cost solution for "multi-homed" domains. The solution is a generalization of the "MX record" scheme currently used for mail routing.
現在の提案は簡単なルーティングを考慮する計画を提示します。 古典的な「階層型ルーティング」アプローチで補足的ですが、実行しやすくて低い費用解決法を提供する、「マルチ、家へ帰り、」 ドメイン。 解決策は現在メールルーティングに使用されている「MX記録」計画の一般化です。
2. Routing based on MX records
2. MX記録に基づくルート設定
The "MX records" are currently used by the mail routing application to introduce a level of decoupling between the "domain names" used for user registration and the mailbox addresses. They are particularly useful for sending mail to "non connected" domains: in that case, the MX record points to one or several Internet hosts that accept to relay mail towards the target domain.
「MX記録」は、現在、ユーザ登録とメールボックスアドレスに使用される「ドメイン名」の間のデカップリングのレベルを導入するのにメールルーティングアプリケーションで使用されます。 それらは特に「非接続された」ドメインにメールを送ることの役に立ちます: その場合、MX記録は1かターゲット・ドメインに向かってメールをリレーするために受け入れる数人のインターネット・ホストを示します。
We propose to generalize this scheme for packet routing. Suppose a routing domain D, containing several networks, subnetwork and hosts, and connected to the Internet through a couple of IP gateways. These gateways are dual homed: they each have an address within the domain D -- say D1 and D2 -- and an address within the Internet -- say I1
私たちは、パケットルーティングのこの計画を一般化するよう提案します。 経路ドメインがいくつかのネットワーク、サブネットワーク、およびホストを含んで、2、3のIPゲートウェイを通してインターネットに関連づけられたDであると仮定してください。 これらのゲートウェイがそうである、二元的である、家へ帰ります: 彼らはドメインDの中にそれぞれアドレスを持っています--D1とD2(インターネットの中のアドレス)がI1を言うと言ってください。
Huitema [Page 2] RFC 1383 DNS based IP routing December 1992
Huitema[2ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
and I2 --. These gateways also have a particularity: they retain information, and don't try to announce to the Internet any reachibility information on the networks contained within "D". These networks however have been properly registered; a name server accessible from the Internet contains the "in-addr.arpa" records that enable reverse "address to name" lookup, and also contains the network level equivalent of "MX records", say "RX records". Given any host address Dx within D, one can get "RX records" pointing to the Internet addresses of the gateways, I1 and I2.
そして、I2--. また、これらのゲートウェイには、特性があります: 彼らは、情報を保有して、ネットワークのどんなreachibility情報も「D」の中に含んだインターネットに知らせようとしません。 しかしながら、適切にこれらのネットワークを登録してあります。 インターネットからアクセスしやすいネームサーバは、「addr.arpa」での「命名するアドレス」逆のルックアップを可能にする記録を含んでいて、また、「MX記録」で同等なネットワークレベルを含んで、「RX記録」を言ってください。 Dの中のホスト・アドレスの与えられたいずれもDx、1つで、「RX記録」はゲートウェイ、I1、およびI2のインターネット・アドレスを示すことができます。
A standard Internet router Ix cannot in principle send a packet to the address Dx: it does not have any corresponding routing information. However, if the said Internet router has been modified to exploit our scheme, it will query the DNS with the name build up from "Dx" in the "in-addr.arpa" domain, obtain the RX records, and forward the packet towards I1 (or I2), using some form of "source routing". The gateway I1 (or I2) will receive the packet; its routing tables contain information on the domain D and it can relay the packet to the host Dx.
Ixが原則としてアドレスDxへのパケットを送ることができない標準のインターネットルータ: それには、少しの対応するルーティング情報もありません。 しかしながら、前述のインターネットルータが私たちの計画を利用するように変更されたなら、I1(または、I2)に向かって「addr.arpa」のドメインで確立という名前で"Dx"からDNSについて質問して、RX記録を得て、パケットを送るでしょう、何らかのフォームの「ソースルーティング」を使用して。 ゲートウェイI1(または、I2)はパケットを受けるでしょう。 経路指定テーブルはドメインDの情報を含んでいます、そして、それはホストDxにパケットをリレーできます。
At this stage, the readers should be convinced that we have presented a scheme that:
現在のところ、読者は私たちが計画にそれを提示したと確信するべきです:
* avoid changes in host IP addresses as topology changes,
without requiring extra overhead on routing (provided
that the routing employs some form of hierarchical
information aggregation/abstraction),
* トポロジーが変化するとき、ホストIPアドレスにおける変化を避けてください、ルーティングで余分なオーバーヘッドを必要としないで(ルーティングが何らかの形式の階層的な情報集合/抽象化を使えば)
* allow to support multihomed domains without requiring
additional overhead on routing and without requiring
hosts to have explicit knowledge of multiple addresses.
* ルーティングで追加オーバーヘッドを必要とすることなしでホストには複数のアドレスの形式知があるのが必要であるなしで「マルチ-家へ帰」っているドメインを支持するのを許容します。
They should also forcingly scratch their head, and mumble that things can't be so simple, and that one should perhaps carefully look at the details before assuming that the solution really works.
彼らは、また、彼らの頭を強制して引っ掻いて、いろいろなことがそれほど簡単であるはずがなく、解決策が本当に働くと仮定する前に恐らく注意深く詳細を見るべきであるとつぶやくべきです。
3. Evaluation of DNS routing
3. DNSルーティングの評価
Several questions come to mind immediately when confronted to such schemes:
すぐそのような計画に立ち向かわれていると、いくつかの質問が思い浮かびます:
- Should all relays access the DNS? What about possible
loops?
- すべてのリレーがDNSにアクセスするはずですか? 可能な輪はどうですか?
- Will the performances be adequate?
- 性能は適切になるでしょうか?
- How does one choose the best gateway when several are
announced? What happens if the gateway is overloaded, or
- 数個が発表されるとき、人はどのように最も良いゲートウェイを選びますか? またはゲートウェイが積みすぎられるならことが起こる。
Huitema [Page 3] RFC 1383 DNS based IP routing December 1992
Huitema[3ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
unreachable?
手が届きませんか?
- What if the directory cannot be accessed?
- ディレクトリにアクセスできないと、どうなるでしょうか?
- How does it work in the reverse direction?
- それはどのように反対の方向に取り組みますか?
- Should we use tunnelling or loose source routing?
- 私たちはトンネルかゆるいソースルーティングを使用するべきですか?
- Can we be more general?
- 私たちは、より一般的である場合がありますか?
There may indeed be more questions, but these ones, at least, have been taken into account in the setting of our experiment.
より多くの質問が本当にあるかもしれませんが、これらのものは私たちの実験の設定で少なくとも考慮に入れられました。
3.1. Loops and relays
3.1. 輪とリレー
In the introduction to DNS-IP routing, we mentioned that the packets would be directed towards the access gateway I1 or I2 by means of "source routing" or "tunnelling". This is not, stricto sensu, necessary. One could imagine that the packet would simply be routed "as if it was directed towards I1 or I2". The next relay would, in turn, also access the DNS to get routing information and forward the packet.
DNS-IPルーティングへの序論では、私たちは、パケットが「ソースルーティング」か「トンネル」によってアクセスゲートウェイのI1かI2に向けられると言及しました。 これは、なくて、扇子で、必要な状態でstrictoされます。 人は、パケットが「それはI1かI2"に向けられます」のように単に発送されると想像できました。 また、次のリレーは、ルーティング情報を得て、パケットを進めるために順番にDNSにアクセスするでしょう。
Such a strategy would have the advantage of leaving the header untouched and of letting the transit nodes choose the best routing towards the destination, based on their knowledge of the reachability status. It would however have two important disadvantages:
そのような戦略は触れない状態でヘッダーを残して、トランジットノードに最も良いルーティングを選ばせる利点を目的地に向かって持っているでしょう、可到達性状態に関するそれらの知識に基づいて。 しかしながら、それには、2回の重要な損失があるでしょう:
- It would oblige all intermediate relays to access the
DNS,
- それは、すべての中間的リレーがDNSにアクセスするのを強いるでしょう。
- It would oblige all these relays to exploit consistently
the DNS information.
- それは、これらのすべてのリレーが一貫してDNS情報を利用するのを強いるでしょう。
Obliging all intermediate gateways to access the DNS is impractical in the short term: it would mean that we would have to update each and every transit relay before deploying the scheme. It could also have an important performance impact: the "working set" of transit relays is typical much wider than that of stub gateways, and the argument presented previously on the efficiency of caches may not apply. This would perhaps remain impractical even in the long term, as it the volume of DNS traffic could well become excessive.
すべての中間ゲートウェイがDNSにアクセスするのを強いるのは短期で非実用的です: それは、計画を配備する前に私たちがありとあらゆるトランジットリレーをアップデートしなければならないことを意味するでしょう。 また、それには、重要な性能影響力があるかもしれません: トランジットリレーの「ワーキングセット」はスタッブゲートウェイのものよりはるかに広い状態で典型的です、そして、以前にキャッシュの効率に提示された議論は適用されないかもしれません。 これは恐らく長期でさえ非実用的なままであるだろう、それとして、DNS交通のボリュームはたぶん過度になるでしょう。
The second argument would apply even if the performance problem had been solved. Suppose that several RX records are registered for a given destination, such as I1 and I2 for Dx in our example, and that a "hop by hop routing" strategy is used. There would be a fair risk that some relays would choose to route the packet towards I1 and some
性能問題が解決されたとしても、2番目の議論は適用されるでしょう。 いくつかのRX記録が与えられた目的地に登録されると仮定してください、私たちの例のDxのためのI1やI2のように、そして、その「ホップルーティングによるホップ」戦略は使用されています。 いくつかのリレーが、I1といくつかに向かってパケットを発送するのを選ぶだろうという公正なリスクがあるでしょう。
Huitema [Page 4] RFC 1383 DNS based IP routing December 1992
Huitema[4ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
others towards I2, resulting in inefficient routing and the possibility of loops.
I2に向かった他のもの、効率の悪いルーティングをもたらして、および輪の可能性。
In order to ensure coherency, we propose that all routing decisions be made at the source, or by one of the first relays near the source.
一貫性を確実にするために、私たちは、ソースにおいて、または、ソースの近くの最初のリレーの1つですべてのルーティング決定をするよう提案します。
3.2. Performances and scaling
3.2. パフォーマンスとスケーリング
The performance impact of using the DNS for acquiring routing information is twofold:
ルーティング情報を取得するのにDNSを使用する性能衝撃は二つです:
* The initial DNS exchanges required for loading the
information may induce a response time penalty for the
users,
* 情報をロードするのに必要である初期のDNS交換はユーザのための応答時間刑罰を引き起こすかもしれません。
* The extra DNS traffic may contribute to overloading the
network.
* 余分なDNS交通はネットワークを積みすぎるのに貢献するかもしれません。
We already have some experience of DNS routing in the Internet for the "mail" application. After the introduction of the "MX record", the mail routing slowly evolved from a hardwired hierarchy, e.g., send all mail to the addresses in the ".FR" domain to the french gateway, towards a decoupling between a name hierarchy used for registration and the physical hierarchy used for delivery.
私たちには、DNSルーティングの「メール」アプリケーションのためのインターネットの何らかの経験が既にあります。 「MX記録」、組み込まれている階層構造からゆっくり発展されたメールルーティングの導入の後に、例えば、登録に使用される名前階層構造と配送に使用される物理的な階層構造の間のデカップリングに向かったフレンチゲートウェイへの".FR"ドメインのアドレスにすべてのメールを送ってください。
If we consider that the mail application represent about 1/4th of the Internet traffic, and that a mail message seldom include more than half a dozen packets, we come to the point that DNS access is already needed at least once for every 24 packets. The performances are not apocalyptic -- or someone would have complained! In fact, if we generalize this, we may suppose that a given host has a "working set" of IP destinations, and that some caching strategy should be sufficient to alleviate the performance effect.
メールアプリケーションがインターネットトラフィックのおよそ1/4番目を表して、メール・メッセージがめったに半ダースパケット以上を含んでいないと考えるなら、私たちはDNSアクセスが少なくとも一度既に24のパケット毎に必要であるというポイントに達します。 性能が終末論的でないか、またはだれかが不平を言いました! 事実上、これを一般化するなら、私たちは与えられたホストにはIPの目的地の「ワーキングセット」があって、何らかのキャッシュ戦略が性能効果を軽減するために十分であるべきであると思うかもしれません。
In the scheme that we propose, the DNS is only accessed once, either by the source host or by an intelligent router located near the source host. The routing decision is only made once, and consistent routing is pursued in the Internet until reaching an access router to the remote domain.
私たちが提案する計画では、送信元ホストか送信元ホストの近くに位置する知的なルータはDNSに一度アクセスするだけです。 一度ルーティング決定をするだけです、そして、インターネットでアクセスルータに遠く離れたドメインに達するまで一貫したルーティングを追求します。
The volume of DNS traffic through the NSFNET, as collected by MERIT, is currently about 9%. When a host wants to establish communication with a remote host it usually need to obtain the name - IP address mapping. Getting extra information (I1 or I2 in our example) should incur in most cases one more DNS lookup at the source. That lookup would at most double the volume of DNS traffic.
現在、MERITによって集められるNSFNETを通したDNS交通のボリュームはおよそ9%です。 ホストは名前を得るために通常、それがそうしなければならないリモートホストとのコミュニケーションを確立したがっています--IPアドレス・マッピングのときに その他の情報(私たちの例のI1かI2)を得ると、多くの場合、ソースのもうひとつのDNSルックアップが被られるべきです。 そのルックアップはDNS交通のボリュームを高々倍にするでしょう。
Huitema [Page 5] RFC 1383 DNS based IP routing December 1992
Huitema[5ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
3.3. Tunneling or source routing
3.3. トンネリングかソースルーティング
Source directed routing, as described above, can be implemented through one of two techniques: source routing, or a form of encapsulation protocol. For the sake of simplicity, we will use source routing, as defined in [1]: we don't have to define a particular tunnelling protocol, and we don't have to require hosts to implement a particular encapsulation protocol.
2つのテクニックの1つで上で説明されるソースの指示されたルーティングは実行できます: ソースルーティング、またはカプセル化プロトコルのフォーム。 簡単にするために、私たちは[1]で定義されるようにソースルーティングを使用するつもりです: 私たちは特定のトンネルプロトコルを定義する必要はありません、そして、ホストが特定のカプセル化プロトコルを実行するのを要求する必要はありません。
3.4. Choosing a gateway
3.4. ゲートウェイを選びます。
A simplification to the previous problem would be to allow only one RX record per destination, thus guaranteeing consistent decisions in the network. This would however have a number of draw-backs. A single access point would be a single point of failure, and would be connected to only one transit network thus keeping the "customer locking" effect of hierarchical routing.
前の問題への簡素化は1目的地あたり1つのRX記録だけを許すだろうことです、その結果、ネットワークで一貫した決定を保証します。 しかしながら、これには、多くのドロー後部があるでしょう。 シングルアクセスポイントは、1ポイントの失敗であるだろう、その結果階層型ルーティングの「顧客ロック」効果を保つ1つのトランジットネットワークだけに接続されるでしょう。
We propose that the RX records have a structure parallel to that of MX records, i.e., that they carry associated with each gateway address a preference identifier. The source host, when making the routing decision based on RX records, should do the following:
私たちは、構造が記録ですなわち、運ぶというMX記録のものに沿うRXがそれぞれのゲートウェイアドレスに好みの識別子を関連づけたよう提案します。 RX記録に基づくルーティング決定をするとき、送信元ホストは以下をするべきです:
- List all possible gateways,
- すべての可能なゲートウェイを記載してください。
- Prune all gateways in the list which are known as
"unreachable" from the local site,
- リストのローカル・サイトから「手の届かない」として知られているすべてのゲートウェイから余計なものを取り除いてください。
- If the local host is present in the list with a
preference index "x", prune all gateways whose preference
index are larger than "x" or equal to "x".
- ローカル・ホストがリストに好みのインデックス「x」について出席しているなら、好みのインデックスが「x」より大きいか、または「x」と等しいすべてのゲートウェイから余計なものを取り除いてください。
- Choose one of the gateway in the list. If the list is
empty, consider the destination as unreachable.
- リストでゲートウェイの1つを選んでください。 リストが空であるなら、目的地が手が届かないとみなしてください。
Indeed, these evaluations should not be repeated for each and every packet. The routers should maintain a cache of the most frequently used destinations, in order to speed up the processing.
本当に、ありとあらゆるパケットのためにこれらの評価を繰り返すべきではありません。 ルータは、処理を早くするために大部分のキャッシュが頻繁に目的地を使用したと主張するべきです。
3.5. Routing dynamics
3.5. ルート設定力学
In theory, one could hope to extract "distance" information from the local routing table and combine it with the preference index for choosing the "best" gateway. In practice, as shown in the mail context, it is extremely difficult to perform this kind of test, and one has to rely on more heuristical approaches. The easiest one is to always choose a "preferred gateway", i.e., the gateway which has the minimal preference index. One could also, alternatively, choose one
理論上、人は、地方の経路指定テーブルから「距離」情報を抜粋して、「最も良い」ゲートウェイを選ぶために好みのインデックスにそれを結合することを望むことができました。 実際には、この種類のテストを実行するのがメール文脈に示されるように非常に難しく、人は、より多くのheuristicalアプローチを当てにしなければなりません。 最も簡単な方はいつも「都合のよいゲートウェイ」、すなわち、最小量の好みのインデックスを持っているゲートウェイを選ぶことです。 また、あるいはまた、人は1つを選ぶことができました。
Huitema [Page 6] RFC 1383 DNS based IP routing December 1992
Huitema[6ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
gateway at random within the list: this would spread the traffic on several routes, which is known to introduce better load sharing and more redundancy in the network.
ゲートウェイ、無作為である、リストの中で: これは数個のルートにおける交通を広げるでしょう。(それは、ネットワークで、より良い負荷分割法と、より多くの冗長を導入するのが知られています)。
As this decision is done only once, the particular algorithm to use can be left as a purely local matter. One domain may make this decision based purely on the RX record, another based purely on the routing information to the gateways listed in the RX record, and yet the third one may employ some weighted combinations of both.
一度だけこの決定をするとき、純粋にローカルの件として使用する特定のアルゴリズムを残すことができます。 この決定はRX記録に1つのドメインで純粋に基づいているかもしれませんが、純粋にゲートウェイへのルーティング情報に基づく別ののはRX記録に記載しましたが、第3両方のいくつかの荷重している組み合わせを使うかもしれません。
Perhaps the most important feature is the ability to cope rapidly with network errors, i.e., to detect that one of the route has become "unreachable". This is clearly an area where we lack experience, and where the experiment will help. One can think of several possible solutions, e.g.,:
恐らく最も重要な特徴が急速にネットワーク誤りに対処する能力である、すなわち、それを検出するために、ルートの1つは「手が届きません」なりました。 これは明確に私たちが経験を欠いて、実験が助ける領域です。 人は例えばいくつかの可能な解決策を考えることができます:
* Let intermediate gateways rewrite the loose source route
in order to replace an unreachable access point by a
better alternative,
* 中間ゲートウェイに手の届かないアクセスポイントをより良い代替手段に取り替えるためにゆるい送信元経路を書き直させてください。
* Monitor the LSR options in the incoming packets, and use
the reverse LSR,
* 入って来るパケットでLSRオプションをモニターしてください、そして、逆のLSRを使用してください。
* Monitor the "ICMP Unreachable" messages received from
intermediate gateways, and react accordingly,
* 中間ゲートウェイから受け取られた「ICMP手の届かない」メッセージをモニターしてください、そして、それに従って、反応してください。
* Regularly probe the LSR, in order to check that it is
still useful.
* それがまだ役に立っているのをチェックするために定期的にLSRを調べてください。
A particularly interesting line would be to combine these connectivity checks with the transport control protocol acknowledgments; this would however require an important modification of the TCP codes, and is not practical in the short term. We will not try any such interaction in the early experiments.
特におもしろい線はこれらの接続性チェックを輸送制御プロトコル承認に結合するだろうことです。 これは、しかしながら、TCPコードの重要な変更を必要として、短期で実用的ではありません。 私たちは早めの実験におけるどんなそのような相互作用も試みるつもりではありません。
The management of these reachability informations should be taken into account when caching the results of the DNS queries.
DNS質問の結果をキャッシュするとき、これらの可到達性情報の管理は考慮に入れられるべきです。
3.6. DNS connectivity
3.6. DNSの接続性
It should be obvious that a scheme relying on RX records is only valid if these records can be accessed. By definition, this is not the case of the target domain itself, which is located at the outer fringes of the Internet.
これらの記録にアクセスできる場合にだけRX記録を当てにする計画が有効であることは、明白であるべきです。 定義上、これはターゲット・ドメイン自体のそうではありません。(それは、インターネットの外側の周囲で位置しています)。
A domain that want to obtain connectivity using the RX scheme will have to replicate its domain name service info, and in particular the RX records, so has to provide them through servers accessible from
RX計画を使用することで接続性を得たがっているドメインは、ドメイン名サービスインフォメーション、および特にRX記録を模写しなければならないので、サーバを通してアクセスしやすい状態でそれらを提供しなければなりません。
Huitema [Page 7] RFC 1383 DNS based IP routing December 1992
Huitema[7ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
the core of the Internet. A very obvious way to do so is to locate replicated name servers for the target domain in the access gateways "I1" and "I2".
インターネットのコア。 そうする非常に明白な方法がアクセスゲートウェイのターゲット・ドメインへの模写されたネームサーバの場所を見つけることである、「I1"と"I2""。
3.7. On the way back
3.7. 逆、に途中
A source located in the fringe domain, when accessing a core Internet host, will have to choose an access relay, I1 or I2 in our example.
コアインターネットホストにアクセスするとき、ソースはフリンジドメインで場所を見つけました、と私たちの例のアクセスリレー、I1またはI2が選ばなければならないでしょう。
A first approach to the problem is to let the access gateway relay the general routing information provided by the routing domains through the fringe network. The fringe hosts would thus have the same connectivity as the core hosts, and would not have to use source directed routing. This approach has the advantage of leaving the packets untouched, but may pose problems should the transit network need to send back a ICMP packet: it will have to specify a source route through the access gateway for the ICMP packet. This would be guaranteed if the IP packets are source routed, as the reverse source route would be automatically used for the ICMP packet. We are thus led to recommend that all IP packets leaving a fringe domain be explicitly source routed.
問題への最初のアプローチはアクセスゲートウェイにフリンジネットワークを通して経路ドメインによって提供された一般的なルーティング情報をリレーさせることです。 フリンジホストは、その結果、コアホストと同じ接続性を持って、ソースの指示されたルーティングを使用する必要はないでしょう。 パケットを触れない状態でおいて、利点を持っていますが、トランジットネットワークが、ICMPパケットを返送する必要があるなら、このアプローチは問題を引き起こすかもしれません: それはアクセスゲートウェイを通してICMPパケットに送信元経路を指定しなければならないでしょう。 これはIPパケットが逆の送信元経路がICMPパケットに自動的に使用されるでしょう、したがって、発送されたソースであるなら保証されるでしょう。 私たちはそうです、その結果、フリンジドメインを出るすべてのIPパケットが明らかにそうであることを推薦するように導かれて、ソースは掘りました。
The source route could be inserted by the access gateway when the packet exits the fringe domain, if the gateway has been made aware of our scheme. It can also be set by the source host, which would then have to explicitly choose the transit gateway, or by the first router in the path, usually the default router of the host sending the packets. As we expect that hosts will be easier to modify than routers, we will develop here suitable algorithms.
パケットがフリンジドメインを出るとき、アクセスゲートウェイで送信元経路を挿入できました、ゲートウェイを私たちの計画を意識するようにしたなら。 また、次に明らかにトランジットゲートウェイを選ばなければならないだろう送信元ホストか経路における最初のルータでそれを設定できます、通常ホストのデフォルトルータがパケットを送って。 ホストがルータよりさらに変更しやすいようになると予想するとき、私たちはここで適当なアルゴリズムを開発するつもりです。
The fringe hosts will have to know the set of available gateways, of which all temporarily unreachable gateways shall indeed be pruned. In the absence of more information, the gateway will be chosen according to some preference order, or possibly at random.
フリンジホストは利用可能なゲートウェイのセットを知らなければならないでしょう。(本当に、そこでは、すべての一時手の届かないゲートウェイ余計なものを取り除かれるものとします)。 詳しい情報がないとき、何らかの好みの命令によると、ゲートウェイはことによると無作為に選ばれるでしょう。
It is very clear that if a "fringe" host wants to communicate with another "fringe" host, it will have to insert two relays in the LSR, one for the domain that sources the packet, and one for the domain where the destination resides.
「フリンジ」ホストが別の「フリンジ」ホストとコミュニケートしたいなら、LSR、ドメインへのパケットの出典を明示するもの、およびドメインへの目的地が住んでいるものに2個のリレーを挿入しなければならないのは、非常に明確です。
3.8. Flirting with policy routing
3.8. 方針ルーティングをもてあそびます。
The current memo assumes that all gateways to a fringe domain are equivalent: the objective of the experiment is to test and evaluate a simple form of directory base routing, not to provide a particular "policy routing" solution. It should be pointed out, however, that some form of policy routing could be implemented as a simple extension to our RX scheme.
現在のメモは、フリンジドメインへのすべてのゲートウェイが同等であると仮定します: 実験の目的は、特定の「方針ルーティング」解決法を提供するのではなく、単純形のディレクトリベースルーティングをテストして、評価することです。 しかしながら、単純拡大として何らかのフォームの方針ルーティングを私たちのRX計画に実行できたと指摘されるべきです。
Huitema [Page 8] RFC 1383 DNS based IP routing December 1992
Huitema[8ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
In the proposed scheme, RX records are only qualified by an "order of preference". It would not be very difficult to also qualify them with a "supported policy" indication, e.g., the numeric identifier of a particular "policy". The impact on the choice of gateways will be obvious:
提案された計画では、「よく使われる順」はRX記録に資格があるだけです。 また、「支持された方針」指示でそれらに資格を与えるのはそれほど難しくないでしょう、例えば、特定の「方針」の数値識別子。 ゲートウェイの選択への影響は明白になるでしょう:
- When going towards a fringe network, one should prune
from the usable list all the gateways that do not support
at least one of the local policies,
- フリンジネットワークに向かうとき、使用可能なリストから少なくともローカルの方針の1つを支持しないすべてのゲートウェイから余計なものを取り除くべきです。
- When exiting a fringe network, one should try to assess
the policies supported by the target, and pick a
corresponding exit gateway,
- フリンジネットワークを出るとき、目標によって支持された方針を評価して、対応する出口ゲートウェイを選ぼうとするべきです。
- When going from a fringe network towards another fringe
network, one should pick a pair of exit and access
gateway that have matching policies.
- フリンジネットワークから別のフリンジネットワークに向かって行くとき、合っている方針を持っている1組の出口とアクセスゲートウェイを選ぶべきです。
In fact, a similar but more general approach has been proposed by Dave Clark under the title of "route fragments". The only problem here are that we don't know how to identify policies, that we don't know whether a simple numeric identifier is good enough and that we probably need to provide a way for end users to assess the policy on a packet per packet or flow per flow basis. In short, we should try to keep the initial experiment simple. If it is shown to be successful, we will have to let it evolve towards some standard service; it will be reasonable to provide policy hooks at this stage.
事実上、同様の、しかし、より一般的なアプローチは「ルート断片」のタイトルの下におけるデーブ・クラークによって提案されました。 私たちが方針を特定する方法を知らないで、私たちが、簡単な数値識別子が十分良いかどうかを知らないで、私たちが、たぶんエンドユーザがパケットに関する1パケットあたりの方針か流れ基礎あたりの流れを評価する方法を提供する必要があるという唯一の問題は、ここにあります。 要するに、私たちは初期の実験を簡単に保とうとするべきです。 それがうまくいくために示されると、私たちは何らかの標準のサービスに向かってそれを発展しなければならないでしょう。 現在のところ方針フックを提供するのは妥当でしょう。
4. Rationales for deployment
4. 展開のための原理
Readers should be convinced, after the previous section, that the DNS-IP routing scheme is sleek and safe. However, they also are probably convinced that a network which is only connected through our scheme will probably enjoy somewhat less services than if they add have full traditional connectivity. We can see two major reasons for inducing users into this kind of scheme:
読者は前項の後にDNS-IPルーティング計画が艶があって安全であると確信するべきです。 しかしながら、また、彼らが私たちの計画を通して接続されるだけであるネットワークがたぶんいくらか少ないサービスを楽しむとたぶん確信している、それらが加えるなら、完全な伝統的な接続性を持ってください。 私たちはこの種類の計画にユーザを引き起こす2つの主要な理由をわかることができます:
- Because they are good network citizen and want to suffer
their share in order to ease the general burden of the
Internet,
- 彼らがインターネットの一般的な負担をゆるめるために良いネットワーク市民であり、自分達のシェアを受けたがっているので
- Because they are financially induced to do so.
- 彼らがそうするのが財政上引き起こされているので。
We will examine these two rationales separately.
私たちは別々にこれらの2つの原理を調べるつもりです。
Huitema [Page 9] RFC 1383 DNS based IP routing December 1992
Huitema[9ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
4.1. The good citizens
4.1. 善良な市民
A strong tradition of the Internet is the display of cooperative spirit: individual users are ready to suffer a bit and "do the right thing" if this conduct can be demonstrated to improve the global state of the network -- and also is not overly painful.
インターネットの強い伝統はなれ合いムードの表示です: 少し苦しんで、ネットワークのグローバルな事情を改良するためにこの行為を示すことができるなら、個々のユーザは「正しいことをする準備ができています」--そして、また、ひどく苦痛ではありません。
Restraining to record your internal networks in the international connectivity tables is mainly an advantage for your Internet partners, and in particular for the backbone managers. The normal way to relieve this burden is to follow a hierarchical addressing plan, as suggested by CIDR. However, when for some reason the plan cannot be followed, e.g., when the topology just changed while the target hosts have not yet been renumbered, our scheme provides an alternative to "just announcing one more network number in the tables". Thus, it can help reducing the routing explosion problem.
国際的な接続性テーブルのあなたの内部のネットワークを記録する行動規制は主にあなたのインターネットパートナー、および特に背骨マネージャのための利点です。 この負担を軽減する正常な方法は階層的なアドレシングプランに従うことです、CIDRによって勧められるように。しかしながら、例えば、目標ホストがまだ番号を付け替えられていませんでしたが、トポロジーがただ変化したとき、ある理由でプランに従うことができないとき、私たちの計画は「ただ、テーブルのもうひとつのネットワーク・ナンバーを発表します」への代替手段を提供します。 したがって、それは、ルーティング爆発問題を減少させるのを助けることができます。
4.2. The commercial approach
4.2. 商業アプローチ
Announcing network numbers in connectivity tables does have a significant cost for network operators:
接続性テーブルでネットワーク・ナンバーを発表するのにおいて、ネットワーク・オペレータのための多大な費用があります:
- larger routing tables means more memory hence more
expensive routres,
- より大きいルーティングはしたがって、より多くの手段の、より多くのメモリの高価なroutresをテーブルの上に置きます。
- more networks means larger and more frequent routing
messages, hence consume more network resources,
- 以上が、より大きい状態で手段をネットワークでつないで、以上は、ルーティング・メッセージによく行って、したがって、より多くのネットワーク資源を消費します。
- more remote networks means more frequent administrative
decisions if policies have to be implemented.
- 政策が実施されなければならないなら、よりリモートなネットワークは、より頻繁な管理的意思決定を意味します。
These costs are very significant not only for regionals, but also for backbone networks. It would thus be very reasonable, from an economical point of view, for a backbone to charge regionals according to the number of networks that they announce. A similar line of reasoning can be applied by the regionals, which could thus give the choice to their customers between:
背骨ネットワークにも、これらのコストは地方版だけに重要であるのではなく、非常に重要です。 その結果、背骨に、彼らが発表するネットワークの数に従って地方版を請求するのは経済的な観点から非常に妥当でしょう。 地方版は推理の同様の線を適用できます。(その結果、地方版は、以下の間で彼らの顧客に選択を与えることができました)。
- being charged for announcing an address of their choice,
- 彼らの選択のアドレスを発表するために、請求されます。
- or being allocated at a lower cost a set of addresses in
an addressing space belonging to the regional.
- または、地方に属しながら、アドレシングスペースに低い費用における、アドレスのセットに割り当てること。
Our scheme may prove an interesting tool if the charge for individual addresses, which are necessary for "multi homed" clients, becomes too high.
「マルチ、は家へ帰った」というクライアントに必要な個々のアドレスのための料金が高くなり過ぎるなら、私たちの計画がおもしろいツールを立証するかもしれません。
Huitema [Page 10] RFC 1383 DNS based IP routing December 1992
Huitema[10ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
5. The experimental development
5. 実験的な開発
The experimental software, implemented under BSD Unix in a "socket" environment, contains two tasks:
BSD Unixの下で「ソケット」環境で実行された実験用ソフトウェアは2つのタスクを含んでいます:
- a real time forwarder, which is implemented inside the
kernel and handles the source demanded routes,
- リアルタイムの混載業者であり、どれがカーネルの中で実行されて、ソースを扱うかがルートを要求しました。
- a DNS query manager, which transmit to the real time
forwarder the source routing information.
- DNSはマネージャについて質問します(ソースルーティング情報をリアルタイムの混載業者に伝えます)。
In this section, we will describe the real time forwarder, the query manager, the format of the DNS record, and the interface with the standard IP routers.
このセクションで、私たちはリアルタイムの混載業者、質問マネージャ、DNS記録の形式、および標準のIPルータとのインタフェースについて説明するつもりです。
5.1. DNS record
5.1. DNS記録
In a definitive scheme, it would be necessary to define a DNS record type and the corresponding "RX" format. In order to deploy this scheme, we would then have to teach this new format to the domain name service software. While not very difficult to do, this would probably take a couple of month, and will not be used in the early experimentations, which will use the general purpose "TXT" record.
決定的な計画では、DNSレコード種類と対応する"RX"書式を定義するのが必要でしょう。 そして、この計画を配備するために、私たちはこの新しい書式をドメイン名サービスソフトウェアに教えなければならないでしょう。 するのがそれほど難しくない間、これは、たぶん月のカップルがかかって、早めの実験に使用されないでしょう。(実験は汎用の"TXT"記録を使用するでしょう)。
This record is designed for easy general purpose extensions in the DNS, and its content is a text string. The RX record will contain three fields:
この記録はDNSでの簡単な汎用の拡大のために設計されています、そして、内容はテキスト文字列です。 RX記録は3つの分野を含むでしょう:
- A record identifier composed of the two characters "RX".
This is used to disambiguate from other experimental uses
of the "TXT" record.
- レコード識別名は2つのキャラクタ"RX"で構成されました。 これは"TXT"記録の他の実験的な用途からあいまいさを除くのにおいて使用されています。
- A cost indicator, encoded on up to 3 numerical digits.
The corresponding positive integer value should be less
that 256, in order to preserve future evolutions.
- 数字の最大3ケタでコード化された費用インディケータ。 対応する正の整数値は、以下がその256であるなら将来のevolutionsを保存するためにそうするでしょうに。
- An IP address, encoded as a text string following the
"dot" notation.
- 「ドット」記法に従って、テキスト文字列としてコード化されたIPアドレス。
The three strings will be separated by a single comma. An example of record would thus be:
3個のストリングがただ一つのコンマによって分離されるでしょう。 その結果、記録に関する例は以下の通りでしょう。
___________________________________________________________________ | domain | type | record | value | | - | | | | |*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7| |_________________________|________|__________|___________________|
___________________________________________________________________ | ドメイン| タイプ| 記録| 値| | - | | | | |*.27.32.192.in-addr.arpa| IP| TXT| RX、10、10.0、.0、.7| |_________________________|________|__________|___________________|
Huitema [Page 11] RFC 1383 DNS based IP routing December 1992
Huitema[11ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
which means that for all hosts whose IP address starts by the three octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway, and that the preference value is 10.
どれがIPアドレスが3つの八重奏で始まるすべてのホストのためにそれを意味するか、「192.320.27インチIPが接待する、「10.0 .0 ゲートウェイとして0.7インチを使用できます、そして、好みの値は10です」
5.2. Interface with the standard IP router
5.2. 標準のIPルータに連結してください。
We have implemented our real time forwarder "on the side" of a standard IP router, as if it were a particular subnetwork connection: we simply indicate to the IP router that some destinations should be forwarded to a particular "interface", i.e., through our real time forwarder.
私たちは「側」で標準のIPルータについてリアルタイムの混載業者を実行しました、まるでそれが特定のサブネットワーク接続であるかのように: 私たちは、いくつかの目的地が特定の「インタフェース」に送られるべきであるのを単にIPルータに示します、すなわち、私たちのリアルタイムの混載業者を通して。
Of particular importance is indeed to know efficiently which destinations should be routed through our services. As the service would be useless for destinations which are directly reachable, we have to monitor the "unreachable" destinations. We do so by monitoring the "ICMP" messages which signal the unreachable destination networks, and copying them to the DNS query manager.
特定では、重要性は効率的にどれを知るかために、本当に、目的地が私たちのサービスで発送されるべきであるということです。 直接届いている目的地に、サービスは役に立たないでしょう、したがって、私たちが「手の届かない」目的地をモニターしなければなりません。 私たちは、手の届かない送信先ネットワークを示す"ICMP"メッセージをモニターして、DNS質問マネージャにそれらをコピーすることによって、そうします。
There are indeed situations, e.g., for fringe networks, where the router knows that destinations outside the local domain will have to be routed through the real time forwarder. In this case, it makes sense to declare the real time forwarder as the "default route" for the host.
本当に状況があります、例えば、フリンジネットワークのために。そこでは、ルータが、局所領域の外の目的地がリアルタイムの混載業者を通して発送されなければならないのを知っています。 この場合、それはホストのための「デフォルトルート」としてリアルタイムの混載業者を宣言する意味になります。
5.3. The DNS query manager
5.3. DNS質問マネージャ
Upon reception of the ICMP message, the query manager updates the local routing table, so that any new packet bound to the requested destination becomes routed through the real time forwarder.
ICMPメッセージのレセプションでは、質問マネージャは地方の経路指定テーブルをアップデートします、要求された目的地に縛られたどんな新しいパケットもリアルタイムの混載業者を通して発送されるようになるように。
At the same time, the query manager will send a DNS request, in order to read the RX records corresponding to the destination. After reception of the response, it will select a gateway, and pass the information to the real time forwarder.
同時に、質問マネージャはDNS要求を送るでしょう、目的地に対応するRX記録を読むために。 応答のレセプションの後に、それは、リアルタイムの混載業者にゲートウェイを選択して、情報を渡すでしょう。
5.4. The real time forwarder
5.4. リアルタイムの混載業者
When the real time forwarder receives a packet, it will check whether a gateway is known for the corresponding destination. If that is the case, it will look at the packet, and insert the necessary source routing information; it will then forward the packet, either by resending it through the general IP routing program, or by forwarding it directly to the network interface associated to the intermediate gateway.
リアルタイムの混載業者がパケットを受けるとき、それは、ゲートウェイが対応する目的地に知られているかどうかチェックするでしょう。 それがそうであるなら、パケットを見て、必要なソースルーティング情報を挿入するでしょう。 そして、それは、一般的なIPルーティングプログラムでそれを再送するか、または直接中間ゲートウェイに関連づけられたネットワーク・インターフェースにそれを送ることによって、パケットを進めるでしょう。
If the gateway is not yet known, the packet will be placed in a waiting queue. Each time the query manager will transmit to the real
ゲートウェイがまだ知られていないと、パケットは待ち待ち行列に置かれるでしょう。 その都度、質問マネージャは本当に伝わるでしょう。
Huitema [Page 12] RFC 1383 DNS based IP routing December 1992
Huitema[12ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
time forwarder new gateway information, the queue will be processed, and packets for which the information has become available will be forwarded. Packets in this waiting queue will "age"; their time to live counts will be decremented at regular intervals. If it become null, the packets will be destroyed; an ICMP message may be forwarded.
時間の混載業者の新しいゲートウェイ情報、待ち行列を処理するでしょう、そして、情報が利用可能になったパケットを進めるでしょう。 この待ち待ち行列におけるパケットは「年をとるでしょう」。 ライブカウントへの彼らの時間は一定の間隔を置いて減少するでしょう。 それであるなら、ヌルになってください、そして、パケットは破壊されるでしょう。 ICMPメッセージを転送するかもしれません。
The DNS query manager may be in some cases unable to find RX information for a particular destination. It will in that case signal to the real time forwarder that the destination is unreachable. The information will be kept in the destination table; queued packet for this destination will be destroyed, and new packets will not be forwarded.
いくつかの場合、DNS質問マネージャは、RXが特定の目的地のための情報であることがわかることができないかもしれません。 その場合、目的地が手が届かないのはリアルタイムの混載業者に合図するでしょう。 情報は目的地テーブルに保たれるでしょう。 この目的地への列に並ばせられたパケットは破壊されるでしょう、そして、新しいパケットは進められないでしょう。
The information in the destination table will not be permanent. A time to live will be associated to each line of the table, and the aging lines will be periodically removed.
目的地テーブルの情報は永久的にならないでしょう。 生きる時間はテーブルの各線に関連づけられるでしょう、そして、老朽化している線は定期的に取り外されるでしょう。
5.5. Interaction with routing protocols
5.5. ルーティング・プロトコルとの相互作用
The monitoring of the "destination unreachable" packets described above is mostly justified by a desire to leave standard IP routing, and the corresponding kernel code, untouched.
上で説明された「目的地手の届かない」パケットのモニターはルーティング、および対応するカーネルコードに標準のIPを出る願望によってほとんど正当化されます、触れません。
If the IP routing code can be modified, and if the local host has
full routing tables, it can take the decision to transmit the
packets to the real time forwarder more efficiently, e.g., as a
default action for the networks that are not announced in the
local tables. This procedure is better practice, as it avoids the
risk of loosing the first packet that would otherwise have
triggered the ICMP message.
IPルーティングコードを変更できて、ローカル・ホストが完全な経路指定テーブルを持っているなら、より効率的にリアルタイムの混載業者にパケットを伝えるという決定を取ることができます、例えば、地方のテーブルで発表されないネットワークのためのデフォルト動作として。 この手順は、より良い習慣です、そうでなければICMPメッセージの引き金となった最初のパケットを発射するという危険を避けるとき。
6. Acknowledgments
6. 承認
We would like to thank Yakov Rekhter, which contributed a number of very helpful comments.
ヤコフRekhterに感謝申し上げます。(Rekhterは多くの非常に役立っているコメントを寄付しました)。
7. Conclusion
7. 結論
This memo suggests an experiment in directory based routing. The author believes that this technique can be deployed in the current Internet infrastructure, and may help us to "buy time" before the probably painful migration towards IPv7.
このメモは、ディレクトリにおける実験がルーティングを基礎づけたと示唆します。 作者が、このテクニックが現在のインターネット基盤で配備できて、以前「時間を稼いでください」に私たちを助けるかもしれないと信じている、たぶん苦痛な移動、IPv7に向かって。
The corresponding code is under development at INRIA. It will be placed in the public domain. Interested parties are kindly asked to contact us for more details.
対応するコードはINRIAで開発中です。 それは公共の場に置かれるでしょう。 利害関係者がその他の詳細のために私たちに連絡するように親切に頼まれます。
Huitema [Page 13] RFC 1383 DNS based IP routing December 1992
Huitema[13ページ]RFC1383DNSは1992年12月にIPルーティングを基礎づけました。
8. References
8. 参照
[1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", STD 5, RFC 791, DARPA, September 1981.
[1] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。
[2] Clark, D., "Building routers for the routing of tomorrow",
Message to the "big-internet" mailing list, reference
<9207141905.AA06992@ginger.lcs.mit.edu>, Tue, 14 Jul 92.
[2] D. クラーク、「大きいインターネット」メーリングリストへの「明日のルーティングのためにルータを築き上げる」Message、 reference <9207141905.AA06992@ginger.lcs.mit.edu 、gt;、火曜日(1992年7月14日)
[3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
cisco, Merit, OARnet, June 1992.
[3] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 「Address AssignmentとAggregation Strategy」、RFC1338、BARRNet、コクチマス、Merit、OARnet、6月1992日
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
10. Author's Address
10. 作者のアドレス
Christian Huitema INRIA, Sophia-Antipolis 2004 Route des Lucioles BP 109 F-06561 Valbonne Cedex France
クリスチャンのHuitema INRIA、2004台のソフィア-Antipolis Route desルシオールBP109F-06561Valbonne Cedexフランス
Phone: +33 93 65 77 15 EMail: Christian.Huitema@MIRSA.INRIA.FR
以下に電話をしてください。 +33 93 65 77 15はメールされます: Christian.Huitema@MIRSA.INRIA.FR
Huitema [Page 14]
Huitema[14ページ]
一覧
スポンサーリンク
