RFC1620 日本語訳
1620 Internet Architecture Extensions for Shared Media. B. Braden, J.Postel, Y. Rekhter. May 1994. (Format: TXT=44999 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Braden
Request for Comments: 1620 ISI
Category: Informational J. Postel
ISI
Y. Rekhter
IBM Research
May 1994
コメントを求めるワーキンググループB.ブレーデン要求をネットワークでつないでください: 1620年のISIカテゴリ: 情報のJ.のISI Y.Rekhter IBM研究ポステル1994年5月
Internet Architecture Extensions for Shared Media
共有されたメディアのためのインターネットアーキテクチャ拡大
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
要約
The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption may be violated for shared media, including "large public data networks" (LPDNs). The architecture still works if this assumption is violated, but it does not have a means to prevent multiple host- router and router-router hops through the shared medium. This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops.
オリジナルのインターネットアーキテクチャは、各ネットワークがただ一つのIPネットワーク・ナンバーでラベルされると仮定しました。 この仮定は「大きい公衆データネットワーク」(LPDNs)を含む共有されたメディアのために違反されるかもしれません。 この仮定が違反されるなら、アーキテクチャはまだ働いていますが、それは共有された媒体を通して複数のホストルータを防ぐ手段とルータルータホップを持っていません。 このメモはいくつかかすべての不要なホップを排除するためにインターネットアーキテクチャを広げることへの代替的アプローチについて議論します。
Table of Contents
目次
1. INTRODUCTION .................................................. 2
2. THE ORIGINAL INTERNET ARCHITECTURE ............................ 2
3. THE PROBLEMS INTRODUCED BY SHARED MEDIA ....................... 4
4. SOME SOLUTIONS TO THE SM PROBLEMS ............................. 7
4.1 Hop-by-Hop Redirection ................................... 7
4.2 Extended Routing ......................................... 11
4.3 Extended Proxy ARP ....................................... 13
4.4 Routing Query Messages ................................... 14
4.5 Stale Routing Information ................................ 14
4.6 Implications of Filtering (Firewalls) .................... 15
5. SECURITY CONSIDERATIONS ....................................... 16
6. CONCLUSIONS ................................................... 17
7. ACKNOWLEDGMENTS ............................................... 17
8. REFERENCES .................................................... 18
Authors' Addresses ............................................... 19
1. 序論… 2 2. オリジナルのインターネットアーキテクチャ… 2 3. 共有されたメディアによって紹介された問題… 4 4. Sm問題への何らかの解決法… 7 ホップごとの4.1リダイレクション… 7 4.2 ルート設定を広げています… 11 4.3 プロキシARPを広げています… 13 4.4 ルート設定質問メッセージ… 14 4.5 経路情報は聞き古したになってください… 14 フィルタリング(ファイアウォール)の4.6の含意… 15 5. セキュリティ問題… 16 6. 結論… 17 7. 承認… 17 8. 参照… 18人の作者のアドレス… 19
Braden, Postel & Rekhter [Page 1] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[1ページ]RFC1620
1. INTRODUCTION
1. 序論
This memo concerns the implications of shared medium networks for the architecture of the TCP/IP protocol suite. General familiarity with the TCP/IP architecture and the IP protocol is assumed.
このメモはTCP/IPプロトコル群のアーキテクチャのための共有された中型のネットワークの含意に関係があります。 TCP/IPアーキテクチャとIPプロトコルへの一般親しみは想定されます。
The Internet architecture is founded upon what was originally called the "Catenet model" [PSC81]. Under this model, the Internet (originally dubbed "the Catenet") is formed using routers (originally called "gateways") to interconnect distinct and perhaps diverse networks. An IP host address (more correctly characterized as a network interface address) is formed of the pair (net#,host#). Here "net#" is a unique IP number assigned to the network (or subnet) to which the host is attached, and "host#" identifies the host on that network (or subnet).
インターネットアーキテクチャは元々「Catenetモデル」[PSC81]と呼ばれたものに設立されます。 このモデルの下では、インターネット(元々、「Catenet」と呼ばれる)は、内部連絡に異なったルータ(元々、「ゲートウェイ」と呼ばれる)と恐らくさまざまのネットワークを使用することで形成されます。 IPホスト・アドレス(ネットワークインターフェース・アドレスとして正しくより特徴付けられた)は組(ネット#、ホスト#)に形成されます。 ここで、「ネット#」はホストが付けているネットワーク(または、サブネット)に配属されたユニークなIP番号です、そして、「ホスト#」はそのネットワーク(または、サブネット)でホストを特定します。
The original Internet model made the implicit assumptions that each network has a single IP network number and that networks with different numbers may interchange packets only through routers. These assumptions may be violated for networks implemented using a common "shared medium" (SM) at the link layer (LL). For example, network managers sometimes configure multiple IP network numbers (usually subnet numbers) on a single broadcast-type LAN such as an Ethernet. The large (switched) public data networks (LPDNs), such as SMDS and B-ISDN, form a potentially more important example of shared medium networks. Any two systems connected to the same shared medium network are capable of communicating directly at the LL, without IP layer switching by routers. This presents an opportunity to optimize performance and perhaps lower cost by eliminating unnecessary LL hops through the medium.
オリジナルのインターネットモデルは各ネットワークにはただ一つのIPネットワーク・ナンバーがあって、異なった数があるネットワークがルータだけを通してパケットを交換するかもしれないという暗黙の仮定をしました。 これらの仮定は(LL)リンクレイヤで一般的な「共有された媒体」(SM)を使用することで実装されたネットワークのために違反されるかもしれません。 例えば、ネットワークマネージャは時々イーサネットなどのただ一つの放送タイプLANの複数のIPネットワーク・ナンバー(通常サブネット番号)を構成します。 SMDSやB-ISDNなどの大きい(切り換えられる)公衆データネットワーク(LPDNs)は共有された中型のネットワークの潜在的により重要な例を形成します。 同じ共有された中型のネットワークに接続されたどんな2台のシステムもLLで直接伝達できます、ルータによるIP層の切り換えなしで。 これは、媒体を通して不要なLLホップを排除することによって、性能を最適化する機会と恐らく低い費用を提示します。
This memo discusses how unnecessary hops can be eliminated in a shared medium, while retaining the coherence of the existing Internet architecture. This issue has arisen in a number of IETF Working Groups concerned with LPDNs, including IPLPDN, IP over ATM, IDRP for IP, and BGP. It is time to take a careful look at the architectural issues to be solved. This memo first summarizes the relevant aspects of the original Internet architecture (Section 2), and then it explains the extra-hop problems created by shared media networks (Section 3). Finally, it discusses some possible solutions (Section 4).
このメモは既存のインターネットアーキテクチャの首尾一貫性を保有している間、共有された媒体でどう不要なホップを排除できるかについて議論します。 この問題はLPDNsに関する多くのIETF Working Groupsに起こりました、IPLPDN、ATMの上のIP、IPのためのIDRP、およびBGPを含んでいて。 解決されるためにもう構造的な問題への慎重な表情を取るべき時間です。 このメモは最初にオリジナルのインターネットアーキテクチャ(セクション2)の関連局面をまとめます、そして、次に、それで、共有されたマスメディア網(セクション3)が生じさせた付加的なホップ問題がわかります。 最終的に、それはいくつかの可能なソリューション(セクション4)について議論します。
2. THE ORIGINAL INTERNET ARCHITECTURE
2. オリジナルのインターネットアーキテクチャ
We very briefly review the original architecture, to introduce the terminology and concepts. Figure 1 illustrates a typical set of four networks A, ... D, represented traditionally as clouds, interconnected by routers R2, R3, and R4. Routers R1 and R5 connect
私たちは、用語と概念を紹介するために非常に簡潔にオリジナルのアーキテクチャを見直します。 図1は4つのネットワークAの典型的なセットを例証します… 雲として伝統的に表されたDはルータのR2、R3、およびR4によって内部連絡されました。 ルータのR1とR5は接続します。
Braden, Postel & Rekhter [Page 2] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[2ページ]RFC1620
to other parts of the Internet. Ha, ... Hd represent hosts connected to these networks.
インターネットの他の地域に。 ハ… Hdはこれらのネットワークに接続されたホストの代理をします。
It is not necessary to distinguish between network and subnet in this memo. We may assume that there is some address mask associated with each "network" in Figure 1, allowing a host or router to divide the 32 bits of an IP address into an address for the cloud and a host number that is defined uniquely only within that cloud.
このメモでネットワークとサブネットを見分けるのは必要ではありません。 私たちは、図1には各「ネットワーク」に関連しているいくつかのアドレスマスクがあると思うかもしれません、ホストかルータがIPアドレスの32ビットをその雲だけの中で唯一定義される雲のためのアドレスとホスト番号に分割するのを許容して。
Ha Hb Hc Hd
ハ、Hb Hc Hd
| | | |
| | | |
_|_ _|_ _|_ _|_
( ) ( ) ( ) ( )
(Net) (Net) (Net) (Net)
( A ) ( B ) ( C ) ( D )
- R1 --( )-- R2 --( )-- R3 --( )-- R4 --( )-- R5 --
( ) ( ) ( ) ( )
(___) (___) (___) (___)
| | | | | | | | _|_ _|_ _|_ _|_ ( ) ( ) ( ) ( ) (ネット) (ネット) (ネット) (ネット) (A) (B) (C) (D) - R1--( )--R2--( )--R3--( )--R4--( )--R5--( ) ( )( )( )(___)(___)(___)(___)
Figure 1. Example Internet Fragment
図1。 例のインターネット断片
An Internet router is connected to local network(s) as a special kind of host. Indeed, for network management purposes, a router plays the role of a host by originating and terminating datagrams. However, there is an important difference between a host and a router: the routing function is mostly centralized in the routers, allowing hosts to be "dumb" about routing. Internet hosts are required [RFC-1122] to make only one simple routing decision: is the destination address local to the connected network? If the address is not local, we say it is "foreign" (relative to the connected network or to the host).
インターネットルータは特別な種類のホストとして企業内情報通信網に関連づけられます。 本当に、ネットワークマネージメント目的のために、ルータはデータグラムを溯源して、終えることによって、ホストの役割を果たします。しかしながら、ホストとルータの間には、重要な違いがあります: ホストがルーティングに関して「馬鹿であること」を許容して、経路選択機能はルータにほとんど集結されます。 インターネット・ホストは1つの簡単なルーティング決定だけをしなければなりません[RFC-1122]: 送付先アドレスは接続ネットワークにローカルですか? アドレスがローカルでないなら、私たちは、それが「外国である」と(接続ネットワークに比例したホストへの)言います。
A host sends a datagram directly to a local destination address or (for a foreign destination) to a first-hop router. The host initially uses some "default" router for any new destination address. If the default is the wrong choice, that router returns a Redirect message and forwards the datagram. The Redirect message specifies the preferred first-hop router for the given destination address. The host uses this information, which it maintains in a "routing cache" [RFC-1122], to determine the first-hop address for subsequent datagrams to the same destination.
または、ホストが直接ローカルの送付先アドレスにデータグラムを送る、(外国目的地への) 最初に、ホップルータに。 ホストは初めは、どんな新しい送付先アドレスにも何らかの「デフォルト」ルータを使用します。 デフォルトが間違った選択であるなら、そのルータは、Redirectメッセージを返して、データグラムを進めます。 Redirectメッセージは都合のよい最初に、ホップルータを与えられた送付先アドレスに指定します。 ホストは、その後のデータグラムのための最初に、ホップアドレスを同じ目的地に決定するのに、この情報を使用します。(それは「ルーティングキャッシュ」[RFC-1122]でそれを保守します)。
To actually forward an IP datagram across a network hop, the sender must have the link layer (LL) address of the target. Therefore, each host and router must have some "address resolution" procedure to map IP address to an LL address. ARP, used for networks with broadcast capability, is the most common address resolution procedure
実際にネットワークホップの向こう側にIPデータグラムを進めるために、送付者には、目標のリンクレイヤ(LL)アドレスがなければなりません。 したがって、各ホストとルータには、IPアドレスをLLアドレスに写像する何らかの「アドレス解決」手順がなければなりません。 放送能力があるネットワークに使用されるARPは最も一般的なアドレス解決手順です。
Braden, Postel & Rekhter [Page 3] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[3ページ]RFC1620
[Plummer82]. If there is no LL broadcast capability (or if it is too expensive), then there are two other approaches to address resolution: local configuration tables, and "address-resolution servers" (AR Servers).
[Plummer82。] LL放送能力が全くなければ(それが高価過ぎるなら)、解決を扱うために、他の2つのアプローチがあります: 地方の構成テーブル、および「アドレス解決サーバ。」(AR Servers)
If AR Servers are used for address resolution, hosts must be configured with the LL address(es) of one or more nearby servers. The mapping information provided by AR Servers might itself be collected using a protocol that allows systems to register their LL addresses, or from static configuration tables. The ARP packet format and the overall ARP protocol structure (ARP Request/ARP Reply) may be suitable for the communications between a host and an AR server, even in the absence of the LL broadcast capabilities; this would ease conversion of hosts to using AR Servers.
AR Serversがアドレス解決に使用されるなら、1つ以上の近いサーバのLLアドレス(es)でホストを構成しなければなりません。 集まっている使用がそれらのLLが扱うレジスタ、または、静的な構成テーブルからシステムを許容するプロトコルであったならAR Servers力自体によって提供されたマッピング情報。 ARPパケット・フォーマットと総合的なARPプロトコル構造(ARP Request/ARP Reply)はホストとARサーバとのコミュニケーションに適するかもしれません、LL放送能力がないときでさえ。 これはホストの変換をAR Serversを使用するのに緩和するでしょう。
The examples in this memo use ARP for address resolution. At least some of the LPDN's that are planned will provide sufficient broadcast capability to support ARP. It is important to note that ARP operates at the link layer, while the Redirect and routing cache mechanisms operate at the IP layer of the protocol stack.
このメモによる例はアドレス解決にARPを使用します。 少なくとも計画されているLPDNのもののいくつかがARPをサポートすることができるくらいの放送能力を提供するでしょう。 ARPがリンクレイヤで作動することに注意するのは重要です、Redirectとルーティングキャッシュメカニズムはプロトコル・スタックのIP層で動作しますが。
3. THE PROBLEMS INTRODUCED BY SHARED MEDIA
3. 共有されたメディアによって紹介された問題
Figure 2 shows the same configuration as Figure 1, but now networks A, B, C, and D are all within the same shared medium (SM), shown by the dashed box enclosing the clouds. Networks A, ... D are now logical IP networks (called LIS's in [Laubach93]) rather than physical networks. Each of these logical networks may (or may not) be administratively distinct. The SM allows direct connectivity between any two hosts or routers connected to it. For example, host Ha can interchange datagrams directly with host Hd or with router R4. A router that has some but not all of its interfaces connected to the shared medium is called a "border router"; R1 and R5 are examples.
図2は、図1と同じ構成を示していますが、現在Aをネットワークでつないで、雲を同封する投げつけられた箱によって見せられた同じ共有された媒体(SM)の中にB、C、およびDがあります。 ネットワークA… 現在論理的なIPネットワークが(であるという物理的であるよりむしろ[Laubach93)の呼ばれたLIS Dネットワーク。 または、それぞれのこれらの論理的なネットワークがそうするかもしれない、()、行政上異なるかもしれなくなってください。 SMはそれに接されたどんな2人のホストやルータの間のダイレクト接続性を許容します。 例えば、ホストHaは直接ホストHdかルータR4と共にデータグラムを交換できます。 すべてではなく、インタフェースのいくつかに共有された媒体に接するルータは「境界ルータ」と呼ばれます。 R1とR5は例です。
Figure 2 illustrates the "classical" model [Laubach93] for use of the Internet architecture within a shared medium, i.e., simply applying the original Internet architecture described earlier. This will provide correct but not optimal operation. For example, in the case of two hosts on the same logical network (not shown in Figure 2), the original rules will clearly work; the source host will forward a datagram directly in a single hop to a host on the same logical network. The original architectural rules will also work for communication between any pair of hosts shown in Figure 2; for example, host Ha would send a datagram to host Hd via the four-hop path Ha -> R2 -> R3 -> R4 -> Hd. However, the classical model does not take advantage of the direct connectivity Ha -> Hd allowed by the shared medium.
すなわち、図2は、インターネットアーキテクチャの使用のために、単により早く説明されたオリジナルのインターネットアーキテクチャを適用しながら、共有された媒体の中で「古典的な」モデル[Laubach93]を例証します。 これは正しい、しかし、最適でない操作を提供するでしょう。 例えば、同じ論理的なネットワーク(図2では、目立たない)の2人のホストの場合では、オリジナルの規則は明確に利くでしょう。 送信元ホストは同じ論理的なネットワークで直接単一のホップでデータグラムをホストに送るでしょう。 また、オリジナルの建築規則は図2で見せられたどんな組のホストのコミュニケーションのためにも利くでしょう。 例えば、ホストHaは4ホップの経路Ha->R2->R3->R4->Hdを通してホストHdにデータグラムを送るでしょう。 しかしながら、古典派モデルはHa->Hdが共有された媒体で許容したダイレクト接続性を利用しません。
Braden, Postel & Rekhter [Page 4] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[4ページ]RFC1620
Ha Hb Hc Hd
ハ、Hb Hc Hd
| | | |
---- | ---------- | ---------- | ---------- | ----
| __|__ __|__ __|__ __|__ |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
( Net ) ( Net ) ( Net ) ( Net )
| ( A ) ( B ) ( C ) ( D ) |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
(_____) (_____) (_____) ( ____)
| | | | | | | | | |
--- | | -------- | | -------- | | -------- | | ---
| | | | | | | |
- R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 ---
| | | | ---- | ---------- | ---------- | ---------- | ---- | __|__ __|__ __|__ __|__ | ( ) ( ) ( ) ( ) | ( ) ( ) ( ) ( ) | (ネット) (ネット) (ネット) (ネット) | (A) (B) (C) (D) | ( ) ( ) ( ) ( ) | ( ) ( ) ( ) ( ) | (_____) (_____) (_____) ( ____) | | | | | | | | | | --- | | -------- | | -------- | | -------- | | --- | | | | | | | | - R1、---- R2--- --- R3--- --- R4--- --- R5---
Figure 2. Logical IP Networks in Shared Medium
図2。 共有された媒体の論理的なIPネットワーク
This memo concerns mechanisms to achieve minimal-hop connectivity when it is desired. We should note that is may not always be desirable to achieve minimal-hop connectivity in a shared medium. For example, the "extra" hops may be needed to allow the routers to act as administrative firewalls. On the other hand, when such firewall protection is not required, it should be possible to take advantage of the shared medium to allow this datagram to use shorter paths. In general, it should be possible to choose between firewall security and efficient connectivity. This is discussed further in Section 4.6 below.
それが望まれているとき、このメモは、メカニズムが最小量のホップの接続性を実現するのが関係があります。 私たちは、共有された媒体の最小量のホップの接続性を達成するためにそれによるいつも望ましいかもしれないというわけではないということであることに注意するべきです。 例えば、「付加的な」ホップが、ルータが管理ファイアウォールとして機能するのを許容するのが必要であるかもしれません。 他方では、そのようなファイアウォール保護は必要でないときに、このデータグラムが、より短い経路を使用するのを許容するのに共有された媒体を利用するのが可能であるべきです。 一般に、ファイアウォールセキュリティと効率的な接続性を選ぶのは可能であるべきです。 以下のセクション4.6で、より詳しくこれについて議論します。
We also note that the mechanisms described here can only optimize the path within the local SM. When the SM is only one segment of the path between source and receiver, removing hops locally may limit the ability to switch to globally more optimal paths that may become available as the result of routing changes. Thus, consider Ha- >...Hx, where host Hx is outside the SM to which host Ha is attached. Suppose that the shortest global path to Hx is via some border router Rb1. Local optimization using the techniques described below will remove extra hops in the SM and allow Ha->Rb1->...Hx. Now suppose that a later route change outside the SM makes the path Ha->Rb2- >...Hx more globally optimum, where Rb2 is another border router. Since Ha does not participate in the routing protocol, it does not know that it should switch to Rb2. It is possible that Rb2 may not realize it either; this is the situation:
また、私たちは、ここで説明されたメカニズムが地方のSMの中で経路を最適化できるだけであることに注意します。 SMがソースと受信機の間の経路の1つのセグメントにすぎないときに、局所的にホップを取り除くと、切り替わる能力はルーティングの結果が変化するのに応じて利用可能になるかもしれないグローバルに最適の経路に制限されるかもしれません。 したがって、Haが>であると考えてください…Hx、SMの外にどのホストHaにはホストHxがどこにあるかは、付属しています。 何らかの境界ルータRb1を通してHxへの最も短いグローバルな経路があると仮定してください。 以下で説明されたテクニックを使用するローカル最適化が、SMで付加的なホップを移して、Ha->にRb1->を許容するでしょう…Hx。 今度は、SMの外の後のルート変化が経路Ha->をRb2->にすると仮定してください…Hxによりグローバルに最適であることで、Rb2が別のものであるところでルータに接してください。 Haがルーティング・プロトコルに参加しないので、それは、Rb2に切り替わるべきであるのを知りません。 Rb2がそれがわからないのは、可能です。 これは状況です:
GC(Ha->Rb2->...Hx) < GC(Ha->Rb1->Rb2->...Hx) < GC(Ha->Rb1->...Hx)
GC、(ハ、-、>Rb2、-、>…Hx) <GC、(ハ、-、>Rb1->、Rb2、-、>…Hx) <GC(ハ、-、>Rb1>、…Hx)
Braden, Postel & Rekhter [Page 5] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[5ページ]RFC1620
where GC() represents some global cost function of the specified path.
GC()が指定された経路の何らかのグローバルな費用関数を表すところ。
Note that ARP requires LL broadcast. Even if the SM supports broadcast, it is likely that administrators will erect firewalls to keep broadcasts local to their LIS.
ARPがLL放送を必要とすることに注意してください。 SMサポートが放送されても、管理者は、それらのLISに地方に放送を保つためにファイアウォールを建設しそうでしょう。
There are three cases to be optimized. Suppose H and H' are hosts and Rb and Rb' are border routers connected to the same same SM. Then the following one-hop paths should be possible:
最適化されるために、3つのケースがあります。 'HとH'はホストであるかどうか、そして、RbとRb'は同じ同じSMに接続された境界ルータです。 次に、以下のワンバウンドの経路は可能であるべきです:
H -> H': Host to host within the SM
'H->H': SMの中で接待するホスト
H -> Rb: Host to exit router
H->Rb: ルータを出るホスト
Rb -> Rb': Entry border router to exit border router,
for transit traffic.
'Rb->Rb': トランジットトラフィックのために境界ルータを出るエントリー境界ルータ。
We may or not be able to remove the extra hop implicit in Rb -> R -> H, where Rb, R, and H are within the same SM, but the ultimate source is outside the SM. To remove this hop would require distribution of host routes, not just network routes, between the two routers R and Rb; this would adversely impact routing scalability.
私たちが取り除くかもしれない、Rb->R->Hに内在している余分なホップを取り除くことができません。同じSMの中にRb、R、およびHがありますが、そこに、究極の源はSMの外にいます。 このホップを取り除くのはネットワークルートだけではなく、ホストルートの分配を必要とするでしょう、2つのルータRとRbの間で。 これは逆にルーティングスケーラビリティに影響を与えるでしょう。
There are a number of important requirements for any architectural solution to these problems.
これらの問題のどんな建築溶液のための多くの重要な要件もあります。
* Interoperability
* 相互運用性
Modified hosts and routers must interoperate with unmodified
nodes.
変更されたホストとルータは変更されていないノードで共同利用しなければなりません。
* Practicality
* 実用性
Minimal software changes should be required.
最小量のソフトウェア変化が必要であるべきです。
* Robustness
* 丈夫さ
The new scheme must be at least as robust against errors in
software, configuration, or transmission as the existing
architecture.
新しい計画はソフトウェア、構成、またはトランスミッションにおける誤りに対して既存の構造と少なくとも同じくらい強健であるに違いありません。
* Security
* セキュリティ
The new scheme must be at least as securable against subversion
as the existing architecture.
新しい計画は転覆に対して既存の構造と少なくとも同じくらい手に入れられるに違いありません。
Braden, Postel & Rekhter [Page 6] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[6ページ]RFC1620
The distinction between host and router is very significant from an engineering viewpoint. It is considered to be much harder to make a global change in host software than to change router software, because there are many more hosts and host vendors than routers and router vendors, and because hosts are less centrally administered than routers. If it is necessary to change the specification of what a host does (and it is), then we must minimize the extent of this change.
ホストとルータの区別は工学観点から非常に重要です。 ルータソフトウェアを変えるよりはるかにホストソフトウェアのグローバルな変更を行いにくいのは考えられます、ずっと多くのホストとホスト業者がルータとルータ業者よりあって、ホストがルータほど中心で管理されていないので。 ホストがすることに関する仕様を変えるのが必要であるなら(それはそうです)、私たちはこの変化の範囲を最小にしなければなりません。
4. SOME SOLUTIONS TO THE SM PROBLEMS
4. Sm問題への何らかの解決法
Four different approaches have been suggested for solving these SM problems.
4つの異なるアプローチが、これらのSM問題を解決するために示されました。
(1) Hop-by-Hop Redirection
(1) ホップごとのリダイレクション
In this approach, the host Redirect mechanism is extended to
collapse multiple-hop paths within the same shared medium, hop-
by-hop. A router is to be allowed to send, and a host allowed
to accept, a Redirect message that specifies a foreign IP
address within the same SM. We refer to this as a "foreign
Redirect". Section 4.1 analyzes this approach in some detail.
このアプローチでは、ホストRedirectメカニズムは、同じ共有された媒体、ホップの中で複数のホップ経路を潰すためにホップによって広げられます。 ルータが発信するのが許容されることであり、ホストは、受け入れるのを許しました、同じSMの中で外国IPアドレスを指定するRedirectメッセージ。 私たちは「外国Redirect」にこれについて言及します。 セクション4.1は何らかの詳細にこのアプローチを分析します。
(2) Extended Routing
(2) 拡張ルート設定
Routing protocols can be modified to know about the SM and to
provide LL addresses.
SMに関して知って、アドレスをLLに供給するようにルーティング・プロトコルを変更できます。
(3) Extended Proxy ARP
(3) 拡張プロキシARP
This is a form of the proxy ARP approach, in which the routing
problem is solved implicitly by an extended address resolution
mechanism at the LL. This approach has been described by
Heinanen [Heinanen93] and by Garrett et al [Garratt93].
これはプロキシARPアプローチのフォームです。(ルーティング問題はLLの拡張アドレス解決メカニズムによってそれでそれとなく解決されています)。 このアプローチはHeinanen[Heinanen93]とギャレット他[Garratt93]によって説明されます。
(4) Route Query Messages
(4) ルート質問メッセージ
This approach has been suggested by Halpern [Halpern93]. Rather
than adding additional information to routing, this approach
would add a new IP-layer mechanism using end-to-end query and
reply datagrams.
このアプローチはアルペルン[Halpern93]によって提案されました。 追加情報をルーティングに追加するよりむしろ、このアプローチは、終わりから終わりへの質問と応答データグラムを使用することで新しいIP-層のメカニズムを加えるでしょう。
These four are discussed in the following four subsections.
以下の4つの小区分でこれらの4について議論します。
4.1 Hop-by-Hop Redirection
4.1 ホップごとのリダイレクション
The first scheme we consider would operate at the IP layer. It
would cut out extra hops one by one, with each router in the path
私たちが考える最初の計画はIP層で作動するでしょう。 各ルータが経路にある状態で、それは余分なホップをひとつずつ切り取るでしょう。
Braden, Postel & Rekhter [Page 7] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[7ページ]RFC1620
operating on local information only. This approach requires both
host and router changes but no routing protocol changes.
ローカルの情報だけを作動させます。 ホストとルータ変化の両方を必要としますが、このアプローチはどんなルーティング・プロトコル変化も必要としません。
The basic idea is that the first-hop router, upon observing that
the next hop is within the same SM, sends a foreign Redirect to
the source, redirecting it to the next hop. Successive
application of this algorithm at each intermediate router will
eventually result in a direct path from source host to destination
host, if both are within the same SM.
基本的な考え方は同じSMの中に次のホップがあるのを観測するとき最初に、ホップルータが外国Redirectをソースに送るということです、次のホップにそれを向け直して。 それぞれの中間的ルータにおけるこのアルゴリズムの連続した適用は結局送信元ホストからあて先ホストまでの直接路をもたらすでしょう、同じSMの中に両方があるなら。
Suppose that Ha wants to send a datagram to Hd. We use the
notation IP.a for the IP address of entity a, and LL.a for the
corresponding LL address. Each line in the following shows an IP
datagram and the path that datagram will follow, separated by a
colon. The notation "Redirect( h, IP.a)" means a Redirect
specifying IP.a as the best next hop to reach host h.
HaがデータグラムをHdに送りたがっていると仮定してください。 私たちは対応するLLアドレスに実体のa、およびLL.aのIPアドレスのための記法IP.aを使用します。 コロンによって切り離されて、以下の各線は、そのデータグラムが続くのをIPデータグラムと経路に案内します。 記法、「再直接、(h、IP.a)、」 次の最も良いホップとしてIP.aを指定するRedirectがホストhに届くことを意味します。
(1) Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd
(1) データグラム1: ハ、->R2->R3->R4->Hd
(2) Redirect(Hd, IP.R3): R2 -> Ha
(2) (Hd、IP.R3)を向け直してください: R2->、ハ。
(3) Datagram 2: Ha -> R3 -> R4 -> Hd
(3) データグラム2: ハ、->R3->R4->Hd
(4) Redirect(Hd, IP.R4): R3 -> Ha
(4) (Hd、IP.R4)を向け直してください: R3->、ハ。
(5) Datagram 3: Ha -> R4 -> Hd
(5) データグラム3: ハ、->R4->Hd
(6) Redirect(Hd, IP.Hd): R4 -> Ha
(6) (Hd、IP.Hd)を向け直してください: R4->、ハ。
(7) Datagram 4: Ha -> Hd
(7) データグラム4: ハ、->Hd
There are three problems to be solved to make hop-by-hop
redirection work; we label them HH1, HH2, and HH3.
ホップごとのリダイレクション仕事をするように解決されるために、3つの問題があります。 私たちはHH1、HH2、およびHH3とそれらをラベルします。
HH1: Each router must be able to resolve the LL address of the
source Ha, to send a (foreign) Redirect.
HH1: それぞれのルータは、再直接でa(外国)を送るためにLLが記述するソースHaの決心にできなければなりません。
Let us assume that the link layer provides the source LL
address when an IP datagram arrives. If the router
determines that a Redirect should be sent, then it will be
sent to the source LL address of the received datagram.
IPデータグラムが届くとき、リンクレイヤがソースLLアドレスを提供すると仮定しましょう。 ルータが、Redirectが送られるべきであることを決定すると、容認されたデータグラムのソースLLアドレスにそれを送るでしょう。
HH2: A source host must be able to perform address resolution to
obtain the LL address of each router to which it is
redirected.
HH2: 送信元ホストはそれが向け直されるそれぞれのルータのLLアドレスを得るアドレス解決を実行できなければなりません。
It would be possible for each router R, upon sending a
Redirect to Ha, to also send an unsolicited ARP Reply point-
各ルータRに、それは可能でしょう、また、求められていないARP Replyポイントを送るためにRedirectをHaに送ることに関して
Braden, Postel & Rekhter [Page 8] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[8ページ]RFC1620
to-point to LL.Ha, updating Ha's ARP cache with LL.R.
However, there is not guarantee that this unsolicited ARP
Reply would be delivered. If it was lost, there would be a
forwarding black hole. The host could recover by starting
over from the original default router; however, this may be
too inefficient a solution.
LL.Haにポイントです、LL.R. Howeverと共にHaのARPキャッシュをアップデートして、この求められていないARP Replyを届けるだろうという保証がありません。 それが失われているなら、推進ブラックホールがあるでしょうに。 ホストはオリジナルのデフォルトルータからやり直すことによって、回復できるでしょう。 しかしながら、これは効率の悪過ぎる解決策であるかもしれません。
A much more direct and efficient solution would introduce an
extended ICMP Redirect message (call it XRedirect) that
carries the LL address as well as the IP address of the
target. This would remove the issue of reliable delivery of
the unsolicited ARP described earlier, because the fate of
the LL address would be shared with the IP target address;
both would be delivered or neither would. (An XRedirect is
essentially the same as a Redirect in the OSI ES-IS
protocol).
はるかにダイレクトで効率的な解決策は目標のIPアドレスと同様にLLアドレスを運ぶ拡張ICMP Redirectメッセージ(それをXRedirectと呼ぶ)を紹介するでしょう。 これは、より早く説明された求められていないARPの信頼できる配信の問題を取り除くでしょう、LLアドレスの運命がIPあて先アドレスと共有されるでしょう、したがって。 両方を渡すだろうか、またはどちらも渡すでしょう。 (XRedirectが中のRedirectと本質的には同じである、OSI ES存在、プロトコル)
Using XRedirect, the previous example becomes:
XRedirectを使用して、前の例はなります:
(1) Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd
(1) データグラム1: ハ、->R2->R3->R4->Hd
(2) XRedirect(Hd, IP.R3, LL.R3): R2 -> Ha
(2)XRedirect(Hd、IP.R3、LL.R3): R2->、ハ。
(3) Datagram 2: Ha -> R3 -> R4 -> Hd
(3) データグラム2: ハ、->R3->R4->Hd
(4) XRedirect(Hd, IP.R4, LL.R4): R3 -> Ha
(4)XRedirect(Hd、IP.R4、LL.R4): R3->、ハ。
(5) Datagram 3: Ha -> R4 -> Hd
(5) データグラム3: ハ、->R4->Hd
(6) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha
(6)XRedirect(Hd、IP.Hd、LL.Hd): R4->、ハ。
(7) Datagram 4: Ha -> Hd
(7) データグラム4: ハ、->Hd
HH3: Each router should be able to recognize when it is the first
hop in the path, since a Redirect should be sent only by the
first hop router. Unfortunately this will be possible only
if the LL address corresponding to the IP source address has
been cached from an earlier event; a router in this chain
determines the LL address of the source from the arriving
datagram (see HH1 above). If it cannot determine whether it
is the first hop, a router must always send an [X]Redirect,
which will be spurious if the router is not the first hop.
HH3: それぞれのルータは、それが1番目であるときには経路を跳ぶように認めることができるべきです、最初のホップルータだけでRedirectを送るべきであるので。 残念ながら、IPソースアドレスに対応するLLアドレスが以前の出来事からキャッシュされた場合にだけ、これは可能になるでしょう。 このチェーンにおけるルータは到着データグラムからのソースのLLアドレスを決定します(HH1が上であることを見てください)。 ルータがそれが最初のホップであるか否かに関係なく、いつも再直接で[X]を送らなければならないことを決定できないなら(ルータが最初のホップでないなら偽りになるでしょう)。
Such spurious [X]Redirects will be sent to the IP address of
the source host, but using the LL address of the previous-hop
router. The propagation scope of [X]Redirects can be limited
to a single IP hop (see below), so they will go no further
than the previous-hop router, where they will be discarded.
偽りの[X]が向け直すそのようなものは、送信元ホストのIPアドレスに送りますが、前のホップルータのLLアドレスを使用するでしょう。 彼らは[X]の範囲が向け直す伝播を単一のIPホップに制限できるので(以下を見てください)、前のホップルータより遠くに行かないでしょう、それらが捨てられるところで。
Braden, Postel & Rekhter [Page 9] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[9ページ]RFC1620
However, there will be some router overhead to process these
useless [X]Redirects
しかしながら、何らかの役に立たない[X]が向け直すこれらを処理するために頭上であることのルータがあるでしょう。
Next, we discuss the changes in hosts and in routers required for
hop-by-hop redirection.
次に、私たちはホストとホップごとのリダイレクションに必要であるルータにおける変化について議論します。
o Host Changes
o ホスト変化
The Host Requirements RFC [RFC-1122] specifies the host
mechanism for routing an outbound datagram in terms of
sending the datagram directly to a local destination or else
to the first hop router (to reach a foreign destination)
[RFC-1122 3.3.1]. Although this mechanism assumes a local
address, a foreign address for a first-hop router should work
equally well.
Host Requirements RFC[RFC-1122]が直接地方の目的地、または、最初のホップルータにデータグラムを送ることに関して(外国目的地に達する)外国行きのデータグラムを発送するのにホストメカニズムを指定する、[RFC-1122、3.3、.1、] このメカニズムはローカルアドレスを仮定しますが、最初に、ホップルータのための外国アドレスは等しくうまくいくべきです。
The target address contained in the routing cache is updated
by Redirect messages. There is currently a restriction on
what target addresses may be accepted in Redirect messages
[RFC-1122 3.2.2.2], which would prevent foreign Redirects
from working:
Redirectメッセージはルーティングキャッシュに含まれたあて先アドレスをアップデートします。 現在、Redirectメッセージでどんなあて先アドレスを受け入れるかもしれないかに関する制限がある、[RFC-1122、3.2、.2、.2、]、どれが、外国Redirectsが以下を扱うのを防ぐだろうか。
A Redirect message SHOULD be silently discarded if the
new router address it specifies is not on the same
connected (sub-) net through which the Redirect arrived,
or if the source of the Redirect is not the current
first-hop router for the specified destination.
どれのためにRedirectが到着したか、または電流がRedirectの源がそうでないなら最初にルータを飛び越すかを通して網状になってください。それが指定する新しいルータアドレスが同じくらいで接続されないなら捨てられて、A RedirectメッセージSHOULDが静かにそうである、(サブ、)、指定された目的地。
To support foreign Redirects requires simply removing the
first validity check. The second check, which requires an
acceptable Redirect to come from the node to which the
datagram that triggered the Redirect was sent, is retained.
The same validity check would be used for XRedirects.
外国Redirectsを支持するのは、単に最初のバリディティチェックを取り除くのを必要とします。 2番目のチェック(許容できるRedirectがRedirectの引き金となったデータグラムが送られたノードから来るのを必要とする)は保有されます。 同じバリディティチェックはXRedirectsに使用されるでしょう。
In order to send a datagram to the target address found in
the routing cache, a host must resolve the IP address into a
LL address. No change should be necessary in the host's IP-
to-LL resolution mechanism to handle a foreign rather than a
local address.
ルーティングキャッシュで見つけられたあて先アドレスにデータグラムを送るために、ホストはIPアドレスにLLアドレスに変えなければなりません。 いいえは必要なコネがLLへのホストIPのハンドルへのa外国の解決メカニズムであったならローカルアドレスよりむしろ変化します。
The Hop-by-Hop redirection requires changes to the semantics
of the IP address that an ICMP Redirect is allowed to carry.
Under the present definition [Postel81b], an ICMP Redirect
message is only allowed to carry an IP address of a router.
In order for the hop-by-hop redirection mechanism to
eliminate all router hops, allowing two hosts connected to
the same SM to communicate directly, a [X]Redirect message
must be able to carry the IP address of the destination host.
ホップによるHopリダイレクションはICMP Redirectが運ぶことができるIPアドレスの意味論に釣り銭がいます。 現在の定義[Postel81b]で、ICMP RedirectメッセージはルータのIPアドレスを運ぶことができるだけです。 同じSMに接続された2人のホストが直接伝達するのを許容して、ホップごとのリダイレクションメカニズムがすべてのルータホップを排除するように、[X]の再直接のメッセージはあて先ホストのIPアドレスを運ぶことができなければなりません。
Braden, Postel & Rekhter [Page 10] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[10ページ]RFC1620
o Router Changes
o ルータ変化
The router changes required for hop-by-hop redirection are
much more extensive than the host changes. The examples
given earlier showed the additional router functions that
would be needed.
ホップごとのリダイレクションに必要であるルータ変化はホストが変えるよりはるかに大規模な状態で多いです。 より早く出された例は必要である追加ルータ機能を示しました。
Consider a router that is connected to an SM. When it
receives a datagram from the SM, it tests whether the next
hop is on the same SM, and if so, it sends a foreign
XRedirect to the source host, using the link layer address
with which the datagram arrived.
SMに接続されるルータを考えてください。 SMからデータグラムを受けるとき、そうだとすれば、次のホップが同じSMにあって、外国XRedirectを送信元ホストに送るか否かに関係なく、テストします、データグラムが届いたリンクレイヤアドレスを使用して。
A router should avoid sending more than a limited number of
successive foreign Redirects to the same host. This is
necessary because an unmodified host may legitimately ignore
a Redirect to a foreign network and continue to forward
datagrams to the same router. A router can accomplish this
limitation by keeping a cache of foreign Redirects sent.
ルータは、連続した外国Redirectsの限られた数より同じホストに発信するのを避けるべきです。 変更されていないホストが、合法的に外国ネットワークにRedirectを無視して、同じルータにデータグラムを送り続けるかもしれないので、これが必要です。 外国Redirectsのキャッシュを送り続けることによって、ルータはこの制限を実行できます。
Note that foreign Redirects generated by routers according to
these rules, like the current local Redirects, may travel
exactly one link-layer hop. It is therefore reasonable and
desirable to set their TTL to 1, to ensure they cannot stray
outside the SM.
これらの規則に従って現在の地方のRedirectsのようにルータで発生する外国Redirectsがちょうど1つのリンクレイヤホップを旅行するかもしれないことに注意してください。 それらのTTLを1に設定するのは、彼らがSMの外をさ迷うことができないのを保証するためにしたがって、妥当であって、望ましいです。
The extra check needed to determine whether to generate a
Redirect may incur additional processing and thus result in a
performance degradation; to avoid this, a router may not
perform the check at all but just forward the packet. The
scheme with [X]Redirects is not applicable to such a router.
Redirectを発生させるかどうか決定するのに必要である余分なチェックは性能退行で追加処理とその結果結果を被るかもしれません。 これを避けるために、ルータはパケットだけでチェックを実行しないかもしれません。 [X]がある計画が向け直す、そのようなルータに適切ではありません。
Finally, note that the hop-by-hop redirection scheme is only
applicable when the source host is connected to an SM, since
routers do not listen to Redirects. To optimize the
forwarding of transit traffic between entry and exit border
routers, an extension to routing is required, as discussed in
the following section. Conversely, an extension to the
routing protocol cannot be used to optimize forwarding
traffic from a host connected to the SM, since a host should
not listen to routing protocols.
最終的に、送信元ホストがSMに接続されるときだけ、ホップごとのリダイレクション計画が適切であることに注意してください、ルータがRedirectsを聞かないので。 エントリーと出口境界ルータの間のトランジット交通の推進を最適化するのに、ルーティングへの拡大が必要です、以下のセクションで議論するように。 逆に、SMに接続されたホストからの推進交通を最適化するのにルーティング・プロトコルへの拡張子を使用できません、ホストがルーティング・プロトコルを聞くべきでないので。
4.2 Extended Routing
4.2 拡張ルート設定
The routing protocols may be modified to carry additional
information that is specific to the SM. The router could use the
attribute "SameSM" for a route to deduce the shortest path to be
reported to its neighbors. It could also carry the LL addresses
ルーティング・プロトコルは、SMに特定の追加情報を運ぶように変更されるかもしれません。 ルートが隣人に報告されるために最短パスを推論するのにルータは属性"SameSM"を使用するかもしれません。 また、それはLLアドレスを運ぶかもしれません。
Braden, Postel & Rekhter [Page 11] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[11ページ]RFC1620
with each router IP address.
それぞれのルータIPアドレスで。
For example, the extended routing protocol would allow R2 to know
that R4 is the best next-hop to reach the destination network in
the same SM, and to know both IP.R4 and LL.R4, leading to the path
Ha->R2->R4->Hb. Further optimization cannot be done with extended
routing alone, since the host does not participate in routing, and
because we want the routing protocol to handle only per-network
information, not per-host information. Hop-by-hop redirection
could then be used to eliminate all router hops, as in the
following sequence:
例えば、R2は拡張ルーティング・プロトコルでR4が同じSMの送信先ネットワークに達して、両方を知る最も良い次のホップIP.R4であり、>R2->を経路Haに導いているLL.R4がR4->であることを知ることができるでしょう。Hb。 拡張ルーティングが単独の状態でさらなる最適化ができません、ホストがルーティングに参加しないで、私たちが、ルーティング・プロトコルにホストではなく、ネットワーク情報だけあたりの情報を扱って欲しいと思うので。 次に、すべてのルータホップを排除するのに以下の系列のようにホップごとのリダイレクションを使用できました:
(1) Datagram 1: Ha -> R2 -> R4 -> Hd
(1) データグラム1: ハ、->R2->R4->Hd
(2) XRedirect(Hd, IP.R4, LL.R4): R2 -> Ha
(2)XRedirect(Hd、IP.R4、LL.R4): R2->、ハ。
(3) Datagram 2: Ha -> R4 -> Hd
(3) データグラム2: ハ、->R4->Hd
(4) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha
(4)XRedirect(Hd、IP.Hd、LL.Hd): R4->、ハ。
(5) Datagram 3: Ha -> Hd
(5) データグラム3: ハ、->Hd
There are three aspects to the routing protocol extension:
ルーティング・プロトコル拡大への3つの局面があります:
(1) the ability to pass "third-party" information -- a router
should be able to specify the address (IP address and perhaps
LL address) of some other router as the next-hop;
(1) ルータが次のホップとしてある他のルータのアドレス(IPアドレスと恐らくLLアドレス)を指定できるべきであるという「第三者」情報を通過する能力
(2) knowledge of the "SameSM" attribute for routes; and
(2) ルートへの"SameSM"属性に関する知識。 そして
(3) knowledge of LL addresses corresponding to IP addresses of
routers within the same SM.
(3) LLに関する知識は同じSMの中にルータのIPアドレスとの対応を記述します。
A router must be able to determine that a particular IP address
(e.g., the source address) is in the same SM. There are several
possible ways to make this information available to a router in
the SM.
ルータは、特定のIPアドレス(例えば、ソースアドレス)が同じSMにあることを決定できなければなりません。 SMでこの情報をルータに利用可能にするいくつかの可能な方法があります。
(1) A router may use a single physical interface to an SM; this
implies that all its logical interfaces lie within the same
SM.
(1) ルータは単一の物理インターフェースをSMに使用するかもしれません。 これは、すべての論理的なインタフェースが同じSMに属すのを含意します。
(3) There might be some administrative structure in the IP
addresses, e.g., all IP addresses within a particular
national SM might have a common prefix string.
(3) IPアドレスには何らかの運営機構があるかもしれません、例えば、特定の国家のSMの中のすべてのIPアドレスでは、一般的な接頭語ストリングがあるかもしれません。
(3) There might be configuration information, either local to the
router or available from some centralized server (e.g, the
(3) 何らかの集結されたサーバからルータへのローカルの、または、利用可能な設定情報があるかもしれない、(e.g
Braden, Postel & Rekhter [Page 12] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[12ページ]RFC1620
DNS). Note that a router could consult this server in the
background while continuing to forward datagrams without
delay. The only consequence of a delay in obtaining the
"SameSM" information would be some unnecessary (but
temporary) hops.
DNS) 即刻データグラムを進め続けている間ルータがバックグラウンドにおけるこのサーバに相談するかもしれないことに注意してください。 "SameSM"情報を得ることにおける、遅れの唯一の結果がいくつかの不要で(一時的)のホップでしょう。
4.3 Extended Proxy ARP
4.3 拡張プロキシARP
The approach of Heinanen [Heinanen93] was intended to solve the
problem of address resolution in a shared medium with no broadcast
mechanism ("Non-Broadcast, MultiAccess" or NBMA). Imagine that
the shared medium has a single IP network number, i.e., it is one
network "cloud". Heinanen envisions a set of AR Servers within
this medium. These AR Servers run some routing protocol among
themselves. A source host issues an ARP Request (via a point-to-
point LL transmission) to an AR Server with which it is
associated. This ARP Request is forwarded hop-by-hop at the link
layer through the AR Servers, towards the AR Server that is
associated with the destination host. That AR Server resolves the
address (using information learned from either host advertisement
or a configuration file), and returns an ARP Reply back through
the AR Servers to the source host.
Heinanen[Heinanen93]のアプローチが放送メカニズムなしで共有された媒体におけるアドレス解決の問題を解決することを意図した、(「」 非放送、多重処理NBMA、) 共有された媒体にはただ一つのIPネットワーク・ナンバーがあると想像してください、そして、すなわち、それは1ネットワーク「雲」です。 Heinanenはこの媒体の中でAR Serversの1セットを思い描きます。 これらのAR Serversは自分たちの中の何らかのルーティング・プロトコルを実行します。 送信元ホストはARP Request(ポイントからポイントへのLLトランスミッションを通した)をそれが関連しているAR Serverに発行します。 ホップごとにAR Serversを通してリンクレイヤでこのARP Requestを進めます、あて先ホストに関連しているAR Serverに向かって。 そのAR Serverはアドレス(ホスト広告か構成ファイルのどちらかから学習された情報を使用する)を決議して、AR Serversを通してARP Replyを送信元ホストに返します。
Ha Hb Hc Hd
ハ、Hb Hc Hd
| | | |
---- | ---------- | ---------- | ---------- | ----
( )
( Shared Medium (One Logical Network) )
( )
----|--|---------|------------|----------|----|---
| | | | | |
- R1 - | | | | --- R5 ---
____|__ __|____ __|____ _|_____
| AR Sa | | AR Sb | | AR Sc | | AR Sd |
|_______| |_______| |_______| |_______|
| | | | ---- | ---------- | ---------- | ---------- | ---- ( ) (共有された媒体(1つの論理的なネットワーク)) ( ) ----|--|---------|------------|----------|----|--- | | | | | | - R1、-| | | | --- R5--- ____|__ __|____ __|____ _|_____ | AR Sa| | AR Sb| | AR Sc| | AR Sd| |_______| |_______| |_______| |_______|
Figure 3. Single-Cloud Shared Medium
図3。 単一の雲は媒体を共有しました。
Figure 3 suggests that each of the hosts Ha, ... Hd is associated
with a corresponding AR Server "AR Sa", ..."AR Sd".
図3はホストHaについてそれぞれそれを勧めます… 「Hdは対応するAR Server"AR Sa"に関連しています」…"AR Sd"。
This same scheme could be applied to the LIS model of Figure 2.
The AR Servers would be implemented in the routers, and if the
medium supports broadcast then the hosts would be configured for
proxy ARP. That is, the host would be told that all destinations
図2のLISモデルにこの同じ体系を適用できました。 AR Serversはルータで実装されるでしょう、そして、中型のサポートが放送されるなら、ホストはプロキシARPのために構成されるでしょう。 それがすなわち、ホストに言われるだろう、すべての目的地
Braden, Postel & Rekhter [Page 13] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[13ページ]RFC1620
are local, so it will always issue an ARP request for the final
destination. The set of AR Servers would resolve this request.
最終的な目的地を求めてローカル、それがいつも発行するそうはARP要求ですか? AR Serversのセットはこの要求を決議するでしょう。
Since routing loops are a constant possibility, Heinanen's
proposal includes the addition of a hop count to ARP requests and
replies.
ルーティング輪が一定の可能性であるので、Heinanenの提案はARP要求と回答にホップカウントの追加を含んでいます。
Like all proxy ARP schemes, this one has a seductive simplicity.
However, solving the SM problem at the LL has several costs. It
requires a complete round-trip time before the first datagram can
flow. It requires a hop count in the ARP packet. This seems like
a tip-off that the link layer may not be the most appropriate
place to solve the SM problem.
すべてのプロキシARP体系のように、これには、色っぽい簡単さがあります。 しかしながら、LLでSM問題を解決するのにおいて、いくつかのコストがあります。 最初のデータグラムが流れることができる前にそれは完全な往復の時間を必要とします。 それはARPパケットでホップカウントを必要とします。 これはリンクレイヤがSM問題を解決する最も適切な場所でないかもしれないという情報のように見えます。
4.4 Routing Query Messages
4.4 ルート設定質問メッセージ
This scheme [Halpern93] introduces a new IP level mechanism: SM
routing query and reply messages. These messages are forwarded as
IP datagrams hop-by-hop in the direction of the destination
address. The exit router can return a reply, again hop-by-hop,
that finally reaches the source host as an XRedirect. It would
also be possible (but not necessary) to modify hosts to initiate
these queries.
この体系[Halpern93]は新しいIP平らなメカニズムを紹介します: SMルーティング質問と応答メッセージ。 IPデータグラムが送付先アドレスの向きにホップで跳ぶとき、これらのメッセージを転送します。 出口ルータは回答を返すことができて、XRedirectとしての送信元ホストはホップごとのそんなに最終的に再び達します。 また、これらの質問を開始するようにホストを変更するのも、可能、そして、(必要でない。)でしょう。
The query/reply pair is supplying the same information that we
would add to routing protocols under Extended Routing. However,
the Query/Reply messages would allow us to keep the current
routing protocols unchanged, and would also provide the extra
information only for the routes that are actually needed, thus
reducing the routing overhead. Note that the Query/Reply sequence
can happen in parallel with forwarding the initial datagram hop-
by-hop, so it does not add an extra round-trip delay.
質問/回答組は私たちが加えるだろうという同じ情報をルーティング・プロトコルにExtendedルート設定で供給しています。 しかしながら、Query/応答メッセージは、私たちが現在のルーティング・プロトコルを変わりがなく保つのを許容して、また、実際に必要であるルートのためだけのその他の情報を前提とするでしょう、その結果、ルーティングオーバーヘッドを下げます。 付加的な往復の遅れを加えないようにホップで初期のデータグラムホップを進めることと平行してQuery/回答系列が起こることができることに注意してください。
4.5 Stale Routing Information
4.5 聞き古した経路情報
We must consider what happens when the network topology changes.
The technique of extended routing (Section 4.2) is capable of
providing sufficient assurances that stale information will be
purged from the system within the convergence time associated with
a particular routing protocol being used.
私たちは、ネットワーク形態が変化すると何が起こるかを考えなければなりません。 拡張ルーティング(セクション4.2)のテクニックはシステムが使用される特定のルーティング・プロトコルに関連している集合時間中に聞き古した情報から追放されるという十分な保証を提供できます。
However, the three other techniques (hop-by-hop redirection,
extended Proxy ARP, and routing query messages) may be expected to
provide minimal-hop forwarding only as long as the network
topology remains unchanged since the time such information was
acquired. Changes in the topology may result in a change in the
minimal-hop path, so that the first-hop router may no longer be
the correct choice. If the host that is using this first-hop
しかしながら、単にそのような情報を取得したときネットワーク形態は以来変わりがない限り、他の3つのテクニック(ホップごとのリダイレクション、拡張Proxy ARP、およびルーティング質問メッセージ)が最小量のホップ推進を提供すると予想されるかもしれません。 トポロジーの変化は最小量のホップ経路の変化をもたらすかもしれません、最初に、ホップルータがもう正しい選択でないように。 ホストであるなら、それは最初に、このホップを使用しています。
Braden, Postel & Rekhter [Page 14] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[14ページ]RFC1620
router is not aware of the changes, then instead of a minimal-hop
path the host could be using a path that is now suboptimal,
perhaps highly sub-optimal, with respect to the number of hops.
ルータが変化を意識していない、次に、最小量のホップ経路の代わりにホストは現在準最適であることの経路を使用できました、恐らく非常にサブ最適です、ホップの数に関して。
Futhermore, use of the information acquired via either extended
Proxy ARP or routing query messages to optimize routing between
routers attached to the same SM is highly problematic, because
presence of stale information on routers could result in
forwarding loops that might persist as long as the information
isn't purged; neither approach provides suitable handling of stale
information.
Futhermore、ルーティングを最適化する拡張Proxy ARPかルーティング質問メッセージのどちらかで同じSMに付けられたルータの間に取得された情報の使用は非常に問題が多いです、ルータの聞き古した情報の存在が情報が掃除されない限り、持続するかもしれない推進輪をもたらすかもしれないので。 どちらのアプローチも聞き古した情報の適当な取り扱いを提供しません。
4.6 Implications of Filtering (Firewalls)
4.6 フィルタリングの含意(ファイアウォール)
For a variety of reasons an administrator of a LIS may erect IP
Layer firewalls (perform IP-layer filtering) to constrain LL
connectivity between the hosts/routers within the LIS and
hosts/routers in other LISs within the same SM. To avoid
disruption in forwarding, the mechanisms described in this
document need to take into account such firewalls.
さまざまな理由で、LISの管理者は、同じSMの中の他のLISsのLISとホスト/ルータの中でホスト/ルータの間のLLの接続性を抑制するために、IP Layerファイアウォール(IP-層のフィルタリングを実行する)を建設するかもしれません。 推進における分裂を避けるために、本書では説明されたメカニズムは、そのようなファイアウォールを考慮に入れる必要があります。
Using [X]Redirects requires a router that generates an [X]Redirect
to be cognizant of possible Link Layer connectivity constraints
between the router that is specified as the Next Hop in the
Redirect and the host that is the target of the Redirect.
[X]が向け直す使用は、再直接で[X]を生成するルータがNext HopとしてRedirectで指定されるルータとRedirectの目標であるホストの間の可能なLink Layer接続性規制を認識しているのを必要とします。
Using extended routing requires a router that originates and/or
propagates "third-party" information be cognizant of the possible
Link Layer connectivity constraints. Specifically, a router should
not propagate "third-party" information when there is a lack of
Link Layer connectivity between the router depicted by the
information and the router which is the immediate recipient of
that information.
使用している拡張ルーティングは「第三者」情報を溯源する、そして/または、伝播するルータを必要とします。可能なLink Layer接続性規制では、認識力があってください。 明確に、ルータはいつ、情報によって表現されたルータとその情報の即座の受取人であるルータの間には、Link Layerの接続性の不足があるかという「第三者」情報を伝播するべきではありません。
Using extended proxy ARP requires an ARP Server not to propagate
an ARP Request to another ARP server if there are Link Layer
connectivity constraints between the originator of the ARP Request
and the other ARP server.
ARP Requestの創始者と他のARPサーバの間には、Link Layer接続性規制があれば、拡張プロキシARPを使用するのは、ARP Serverが別のARPサーバにARP Requestを伝播しないのを必要とします。
Using SM routing query and reply messages requires the routers
that pass the messages to be aware of the possible Link Layer
connectivity constraints. The flow of messages need to reflect
these constraints.
SMルーティング質問と応答メッセージを使用するのは可能なLink Layer接続性規制を意識しているメッセージを通過するルータを必要とします。 これらの規制を反映するメッセージの必要性の流れ。
Braden, Postel & Rekhter [Page 15] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[15ページ]RFC1620
5. SECURITY CONSIDERATIONS
5. セキュリティ問題
We should discuss the security issues raised by our suggested changes. We should note that we are not talking about "real" security here; real Internet security will require cryptographic techniques on an end-to-end basis. However, it should not be easy to subvert the basic delivery mechanism of IP to cause datagrams to flow to unexpected places.
私たちは私たちの提案された変化によって提起された安全保障問題について議論するべきです。 私たちは、ここで「本当」のセキュリティに関して話していないことに注意するべきです。 本当のインターネットセキュリティは終わりから終わりへのベースで暗号のテクニックを必要とするでしょう。 しかしながら、データグラムが予期していなかった場所に注ぐことを引き起こすためにIPの基本的な排紙機構を打倒するのは簡単であるはずがありません。
With this understanding, the security problems arise in two places: the ICMP Redirect messages and the ARP replies.
このことを了解した上で、警備上の問題は2つの場所で起こります: ICMP RedirectメッセージとARP回答。
* ICMP Redirect Security
* ICMPの再直接のセキュリティ
We may reasonably require that the routers be secure. They are
generally under centralized administrative control, and we may
assume that the routing protocols will contain sufficient
authentication mechanisms (even if it is not currently true).
Therefore, a host will reasonably be able to trust a Redirect
that comes from a router.
私たちは、ルータが安全であることを合理的に必要とするかもしれません。 彼らが一般に集結された運営管理コントロールの下にいます、そして、私たちはルーティング・プロトコルが十分な認証機構を含むと思うかもしれません(それが現在本当でなくても)。 したがって、ホストは合理的にルータから来るRedirectを信じることができるでしょう。
However, it will NOT be reasonable for a host to trust another
host. Suppose that the target host in the examples of Section
4.1 is untrustworthy; there is no way to prevent its issuing a
new Redirect to some other destination, anywhere in the
Internet. On the other hand, this exposure is no worse than it
was; the target host, once subverted, could always act as a
hidden router to forward traffic elsewhere.
しかしながら、ホストが別のホストを信じるのは、妥当でないでしょう。 セクション4.1に関する例の目標ホストが信頼できないと仮定してください。 それがある他の目的地へのインターネットでどこでも新しいRedirectを発行するのを防ぐ方法が全くありません。 他方では、この暴露はそれほど悪くはありません。 一度打倒された目標ホストは、トラフィックをほかの場所に送るために隠されたルータとしていつも務めることができました。
* ARP Security
* ARPセキュリティ
Currently, an ARP Reply can come only from the local network,
and a physically isolated network can be administrative secured
from subversion of ARP. However, an ARP Reply can come from
anywhere within the SM, and an evil-doer can use this fact to
divert the traffic flow from any host within the SM
[Bellovin89].
現在、ARP Replyは単に企業内情報通信網から来ることができます、そして、肉体的に孤立しているネットワークはARPの転覆から機密保護された状態で管理である場合があります。 しかしながら、ARP ReplyはSMの中でどこからでも来ることができます、そして、悪人はSM[Bellovin89]の中のどんなホストからの交通の流れも紛らすのにこの事実を使用できます。
The XRedirect closes this security hole. Validating the
XRedirect (as coming from the node to which the last datagram
was sent) will also validate the LL address.
XRedirectはこのセキュリティーホールを閉じます。 また、XRedirect(最後のデータグラムが送られたノードから来るとしての)を有効にすると、LLアドレスは有効にされるでしょう。
Another approach is to validate the source address from which
the ARP Reply was received (assuming the link layer protocol
carries the source address and the driver supplies it). An
acceptable ARP reply for destination IP address D can only come
from LL address x, where the routing cache maps D -> E and the
ARP cache gives x as the translation of E. This validation,
別のアプローチはARP Replyが受け取られたソースアドレスを有効にする(リンクレイヤプロトコルがソースアドレスとドライバーを運ぶと仮定するのがそれを供給します)ことです。 送付先IPアドレスDのための許容できるARP回答はLLアドレスxから来ることができるだけです。そこでは、ルーティングキャッシュがD->Eを写像して、ARPキャッシュはE.This合法化に関する翻訳としてxを与えます。
Braden, Postel & Rekhter [Page 16] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[16ページ]RFC1620
involving both routing and ARP caches, might be ugly to
implement in a strictly-layered implementation. It would be
natural if layering were already violated by combining the ARP
cache and routing cache.
ルーティングとARPキャッシュの両方にかかわるのは、厳密に層にされた実装で実装するために醜いかもしれません。 ARPキャッシュとルーティングキャッシュを結合することによってレイヤリングが既に違反されるなら、当然でしょうに。
It is possible for the link layer to have security mechanisms that could interfere with IP-layer connectivity. In particular, there could possible be non-transitivity of logical interconnection within a shared medium. In particular, some large public data networks may include configuration options that could allow Net A to talk to Net B and Net B to talk to Net C, but prevent A from talking directly to C. In this case, the routing protocols have to be sophisticated enough to handle such anomalies.
リンクレイヤにはIP-層の接続性を妨げることができたセキュリティー対策があるのは、可能です。 コネそこで特定である、可能であるのは、共有された媒体の中の論理的なインタコネクトの非推移性であるかもしれません。 特に、いくつかの大きい公衆データネットワークがネットAがネットCと話すためにネットBとネットBと話すことができた設定オプションを含むかもしれませんが、Aが直接C.と話すのを防いでください。In本件、ルーティング・プロトコルはそのような例外を扱うほど精巧でなければなりません。
6. CONCLUSIONS
6. 結論
We have discussed four possible extensions to the Internet architecture to allow hop-efficient forwarding of IP datagrams within shared media, when this optimization is allowed by IP-layer firewalls. We do not draw any conclusions in this paper about the best mechanisms.
私たちは共有されたメディアの中でIPデータグラムのホップ効率的な推進を許すために4つの可能な拡大についてインターネットアーキテクチャと議論しました、この最適化がIP-層のファイアウォールによって許容されているとき。 私たちは最も良いメカニズムでこの紙でどんな結論にも達しません。
Our suggested extensions are evolutionary, leaving intact the basic ideas of the current Internet architecture. It would be possible to make (and some have suggested) much more radical changes to accommodate shared media. In the extreme, one could entirely abolish the inner clouds in Figure 2, so that there would be no logical network structure within the SM. The IP addresses would then be logical, and some mechanism of distributed servers would be needed to find routes within this random haze. We think this approach ignores all the requirements for management and security in today's Internet. It might make a good research paper, but it would not be good Internet design strategy.
現在のインターネットアーキテクチャの基本的な考え方を完全なままにして、私たちの提案された拡大は進化論です。 共有されたメディアに対応するためにずっと多くの根本的な変更を作るのは(或るものは示されました)可能でしょう。 極端では、1つは図2における内側の雲を完全に撤廃するかもしれません、SMの中にどんな論理的なネットワーク構造もないように。 IPアドレスはその時論理的でしょう、そして、分配されたサーバの何らかのメカニズムが、この無作為のもやの中でルートを見つけるのに必要でしょう。 私たちは、このアプローチが今日のインターネットにおける管理とセキュリティのためのすべての要件を無視すると思います。 良い研究を紙にするかもしれませんが、それは良いインターネットデザイン戦略でないでしょう。
7. ACKNOWLEDGMENTS
7. 承認
We are grateful to Keith McGloghrie, Joel Halpern, and others who rubbed our noses in this problem. We also acknowledge Tony Li (cisco), Greg Minshall (Novell), and John Garrett (AT&T) for their review and constructive comments. We are also grateful to Gerri Gilliland who supplied the paper tablecloth, colored crayons, and fine food that allowed these ideas to be assembled initially.
私たちはこの問題で鼻をこすったキースMcGloghrie、ジョエル・アルペルン、および他のものに感謝しています。 また、私たちは彼らのレビューと建設的なコメントのために、トニー・李(コクチマス)、グレッグMinshall(ノベル)、およびジョン・ギャレット(AT&T)を承認します。 また、私たちもクレヨンに着色された紙のテーブルクロスを供給したGerriギリランドとこれらの考えが初めは組み立てられるのを許容した高付加価値食品に感謝しています。
Braden, Postel & Rekhter [Page 17] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIPアーキテクチャ1994年5月に共有されたRekhter[17ページ]RFC1620
8. REFERENCES
8. 参照
[Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol
Suite", ACM CCR, v. 19. no. 2, April 1989.
[Bellovin89] Bellovin、S.、「TCP/IPプロトコル群の警備上の問題」、ACM CCR、v。 19. 1989年4月、No.2。
[Garrett93] Garrett, J., Hagan, J. and J. Wong, "Directed ARP", RFC
1433, AT&T Bell Laboratories, University of Pennsylvania, March
1993.
[Garrett93] ギャレットとJ.とハーガンとJ.とJ.ウォン、「指示されたARP」、RFC1433、AT&Tベル研究所、ペンシルバニア大学、1993年3月。
[Plummer82] Plummer, D., "An Ethernet Address Resolution Protocol",
STD 37, RFC 826, MIT, November 1982.
[Plummer82] プラマー、D.、「イーサネットアドレス解決プロトコル」、STD37、RFC826、MIT、1982年11月。
[Halpern93] Halpern, J., Private Communication, July 1993.
[Halpern93]アルペルン、J.、私信、1993年7月。
[Heinanen93] Heinanen, J., "NBMA Address Resolution Protocol (NBMA
ARP)", Work in Progress, June 1993.
J.、「NBMAアドレス解決プロトコル(NBMA ARP)」という[Heinanen93]Heinanenは進歩、1993年6月に働いています。
[Laubach93] Laubach, M., "Classical IP and ARP over ATM", RFC 1577,
Hewlett-Packard Laboratories, January 1994.
[Laubach93] Laubachと、M.と、「気圧での古典的なIPとARP」、RFC1577、ヒューレット・パッカード研究所、1月1994
[Postel81a] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
[Postel81a] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。
[Postel81b] Postel, J., "Internet Control Message Protocol- DARPA
Internet Program Protocol Specification", STD 5, RFC 792, ISI,
September 1981.
[Postel81b] ポステル、J.、「インターネット規制メッセージプロトコルDARPAインターネットプログラムプロトコル仕様」、STD5、RFC792、ISI、1981年9月。
[PSC81] Postel, J., Sunshine, C., and D. Cohen, "The ARPA Internet
Protocol", Computer Networks 5, pp. 261-271, 1983.
[PSC81]ポステルとJ.とサンシャイン、C.とD.コーエン、「アルパインターネットプロトコル」コンピュータNetworks5、ページ 261-271, 1983.
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
Institutue, October 1989.
[RFC-1122] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、USC/情報科学Institutue、10月1989日
Braden, Postel & Rekhter [Page 18] RFC 1620 Shared Media IP Architecture May 1994
ブレーデン、ポステル、およびメディアIP構造1994年5月に共有されたRekhter[18ページ]RFC1620
Authors' Addresses
作者のアドレス
Bob Braden
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, CA 90292
ボブブレーデン情報Sciences Institute南カリフォルニア大学4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511
EMail: Braden@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Braden@ISI.EDU
Jon Postel
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, CA 90292
ジョンポステル情報Sciences Institute南カリフォルニア大学4676海軍本部Wayマリナデルレイ、カリフォルニア 90292
Phone: (310) 822-1511
EMail: Postel@ISI.EDU
以下に電話をしてください。 (310) 822-1511 メールしてください: Postel@ISI.EDU
Yakov Rekhter
Office 32-017
T.J. Watson Research Center, IBM Corp.
P.O. Box 218,
Yorktown Heights, NY 10598
ニューヨーク ヤコフRekhterオフィス32-017T.J.ワトソン研究所、IBM社の私書箱218、ヨークタウンの高さ、10598
Phone: (914) 945-3896
EMail: Yakov@WATSON.IBM.COM
以下に電話をしてください。 (914) 945-3896 メールしてください: Yakov@WATSON.IBM.COM
Braden, Postel & Rekhter [Page 19]
ブレーデン、ポステル、およびRekhter[19ページ]
一覧
スポンサーリンク
