RFC1385 日本語訳
1385 EIP: The Extended Internet Protocol. Z. Wang. November 1992. (Format: TXT=39123 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Z. Wang
Request for Comments: 1385 University College London
November 1992
コメントを求めるワーキンググループZ.ワングの要求をネットワークでつないでください: 1385 ユニバーシティ・カレッジロンドン1992年11月
EIP: The Extended Internet Protocol
A Framework for Maintaining Backward Compatibility
EIP: 拡張インターネットは、後方の互換性を維持するためにフレームワークについて議定書の中で述べます。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Summary
概要
The Extended Internet Protocol (EIP) provides a framework for solving the problem of address space exhaustion with a new addressing and routing scheme, yet maintaining maximum backward compatibility with current IP. EIP can substantially reduce the amount of modifications needed to the current Internet systems and greatly ease the difficulties of transition. This is an "idea" paper and discussion is strongly encouraged on Big-Internet@munnari.oz.au.
Extendedインターネットプロトコル(EIP)は新しいアドレシングとルーティング体系でアドレス空間疲労困憊の問題を解決するのにフレームワークを提供します、まだ現在のIPとの最大の後方の互換性を維持していて。 EIPは現在のインターネット・システムに必要である変更の量をかなり減少させて、変遷の困難を大いに緩和できます。 これは「考え」論文です、そして、議論は Big-Internet@munnari.oz.au で強く奨励されます。
Introduction
序論
The Internet faces two serious scaling problems: address exhaustion and routing explosion [1-2]. The Internet will run out of Class B numbers soon and the 32-bit IP address space will be exhausted altogether in a few years time. The total number of IP networks will also grow to a point where routing algorithms will not be able to perform routing based a flat network number.
インターネットは2つの重大なスケーリング問題に直面しています: 疲労困憊とルーティングが爆発[1-2]であると扱ってください。 インターネットはすぐClass B番号を使い果たすでしょう、そして、32ビットのIPアドレス空間はいくつかの何年もの時間、全体で消耗するでしょう。 また、IPネットワークの総数はアルゴリズムが掘るのにおいて実行できないルーティングが平坦なネットワーク・ナンバーを基礎づけたポイントまで成長するでしょう。
A number of short-term solutions have been proposed recently which attempt to make more efficient use of the the remaining address space and to ease the immediate difficulties [3-5]. However, it is important that a long term solution be developed and deployed before the 32-bit address space runs out.
多くの残っているアドレス空間の、より効率的な使用をして、即座の困難[3-5]を緩和するのを試みる短期的なソリューションが、最近、提案されました。 しかしながら、32ビットのアドレスのスペースがなくなる前に、長期解決策が見いだされて、配布されるのは、重要です。
An obvious approach to this problem is to replace the current IP with a new internet protocol that has no backward compatibility with the current IP. A number of proposals have been put forward: Pip[7], Nimrod [8], TUBA [6] and SIP [14]. However, as IP is really the cornerstone of the current Internet, replacing it with a new "IP" requires fundamental changes to many aspects of the Internet system (e.g., routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP).
この問題への明白なアプローチは現在のIPを現在のIPとのどんな後方の互換性も持っていない新しいインターネットプロトコルに取り替えることです。 多くの提案が提唱されました: [7]、ニムロデ[8]、チューバ[6]、および一口[14]に種をとってください。 しかしながら、IPが本当に現在のインターネットの礎石であるので、それを新しい「IP」に取り替えるのはインターネット・システム(例えば、ルーティング、ルータ、ホスト、アルプ、RARP、ICMP、TCP、UDP、DNS、FTP)の多くの局面への根本的変化を必要とします。
Migrating to a new "IP" in effect creates a new "Internet". The
事実上、新しい「IP」にわたるのは新しい「インターネット」を作成します。 The
Wang [Page 1] RFC 1385 EIP November 1992
ワング[1ページ]RFC1385EIP1992年11月
development and deployment of such a new "Internet" would take a very large amount of time and effort. In particular, in order to maintain interoperability between the old and new systems during the transition period, almost all upgraded systems have to run both the new and old versions in parallel and also have to determine which version to use depending on whether the other side is upgraded or not.
そのような新しい「インターネット」の開発と展開は非常に大きい時間と取り組みがかかるでしょう。 ほとんどすべてのアップグレードしたシステムが、過渡期の間、古くて新しいシステムの間の相互運用性を維持するために特に、平行な両方の新しくて古いバージョンを述べなければならなくて、また、反対側がアップグレードするかどうかによって、どのバージョンを使用したらよいかを決定しなければなりません。
Let us now have a look at the detailed changes that will be required to replace the current IP with a completely new "IP" and to maintain the interoperability between the new and the old systems.
今、現在のIPを完全に新しい「IP」に取り替えて、新しいシステムと古いシステムの間の相互運用性を維持しなければならない詳細な変化を、見ましょう。
1) Border Routers: Border routers have to be upgraded and to provide
address translation service for IP packets across the boundaries.
Note that the translation has to be done on the outgoing IP
packets as well as the in-coming packets to IP hosts.
1) ルータに接してください: 境界ルータは、アップグレードして、IPパケットのためのアドレス変換サービスを境界の向こう側に提供しなければなりません。 IPホストへの入って来るパケットと同様に出発しているIPパケットで翻訳をしなければならないことに注意してください。
2) Subnet Routers: Subnet Routers have to be upgraded and have to
deal with both the new and the old packet formats.
2) サブネットルータ: サブネットRoutersはアップグレードしなければならなくて、新しさと古いパケット・フォーマットの両方に対処しなければなりません。
3) Hosts: Hosts have to be upgraded and run both the new and the
old protocols in parallel. Upgraded hosts also have to determine
whether the other side is upgraded or not in order to choose the
correct protocol to use.
3) ホスト: ホストは、アップグレードして、新しさと古いプロトコルの平行な両方を実行しなければなりません。 アップグレードしたホストも、使用する正しいプロトコルを選ぶために反対側がアップグレードするかどうかと決心しなければなりません。
4) DNS: The DNS has to be modified to provide mapping for domain
names and new addresses.
4) DNS: DNSは、ドメイン名と新しいアドレスにマッピングを提供するように変更されなければなりません。
5) ARP/RARP: ARP/RARP have to be modified, and upgraded hosts and
routers have to deal with both the old and new ARP/RARP packets.
5) アルプ/RARP: アルプ/RARPは変更されなければなりません、そして、アップグレードしたホストとルータは両方の古くて新しいアルプ/RARPパケットに対処しなければなりません。
6) ICMP: ICMP has to be modified, and the upgraded routers have to
be able to generate both both old and new ICMP packets. However,
it may be impossible for a backbone router to determine
whether the packet comes from an upgraded host or an IP host but
translated by the border router.
6) ICMP: ICMPは変更されなければなりません、そして、アップグレードしたルータは古いものと両方が同様に新しいICMPパケットであると生成することができなければなりません。 しかしながら、それは、バックボーンルータが、パケットがアップグレードしたホストかIPホストから来るかどうか決定するのが、不可能であり、境界ルータによって翻訳されるかもしれません。
7) TCP/UDP Checksum: The pseudo headers may have to be modified to
use the new addresses.
7) TCP/UDPチェックサム: 疑似ヘッダーは、新しいアドレスを使用するように変更されなければならないかもしれません。
8) FTP: The DATA PORT (PORT) command has to be changed to pass new
addresses.
8) FTP: 新しいアドレスを通過するためにDATA PORT(PORT)コマンドを変えなければなりません。
In this paper, we argue that an evolutionary approach can extend the addressing space yet maintain backward compatibility. The Extended Internet Protocol (EIP) we present here can be used as a framework by which a new routing and addressing scheme may solve the problem of address exhaustion yet maintain maximum backward compatibility to
この紙では、私たちは、進化論のアプローチがアドレシングスペースを広げていますが、後方の互換性を維持できると主張します。 新しいルーティングとアドレシング体系がどれにアドレス疲労困憊の問題を解決しますが、最大の後方の互換性を維持するかもしれないかによって、フレームワークとして私たちがここに提示するExtendedインターネットプロトコル(EIP)を使用できます。
Wang [Page 2] RFC 1385 EIP November 1992
ワング[2ページ]RFC1385EIP1992年11月
current IP.
現在のIP。
EIP has a number of very desirable features:
EIPには、多くの非常に望ましい特徴があります:
1) EIP allows the Internet to have virtually unlimited number of
network numbers and over 10**9 hosts in each network.
1) インターネットには、各ネットワークにEIPが実際には無制限な数のネットワーク・ナンバーと10以上**9ホストをあります。
2) EIP is flexible to accommodate most routing and addressing
schemes, such as those proposed in Nimrod [8], Pip [7], NSAP [9]
and CityCodes [10]. EIP also allows new fields such as Handling
Directive [7] or CI [11] to be added.
2) EIPはほとんどのルーティングに対応するのにおいてフレキシブルです、そして、それらなどの体系を扱うのはニムロデ[8]、Pip[7]、NSAP[9]、およびCityCodes[10]で提案しました。 また、EIPはHandling Directive[7]かCI[11]などの新しい分野を加えさせます。
3) EIP can substantially reduce the amount of modifications to
current systems and greatly ease the difficulties in transition.
In particular, it does not require the upgraded hosts and subnet
routers to run two set of protocols in parallel.
3) EIPは現在のシステムへの変更の量をかなり減少させて、変遷における困難を大いに緩和できます。 特に、平行なプロトコルの2セットを経営しているのがアップグレードしたホストとサブネットルータを必要としません。
4) EIP requires no changes to all assigned IP addresses and subnet
structures in local are networks. and requires no modifications
to ARP/RARP, ICMP, TCP/UDP checksum.
4) EIPはすべての割り当てられたIPアドレスへの変化を全く必要としません、そして、地方のサブネット構造が必要です。ネットワークアルプ/RARP、ICMP、TCP/UDPチェックサムへの変更は全く必要としません。
5) EIP can greatly ease the difficulties of transition. During the
transition period, no upgrade is required to the subnet routers.
EIP hosts maintain full compatibility with IP hosts within the
same network, even after the transition period. During the
transition period, IP hosts can communicate with any hosts in
other networks via a simple translation service.
5) EIPは変遷の困難を大いに緩和できます。 過渡期の間、アップグレードは全くサブネットルータに必要ではありません。 EIPホストは過渡期の後にさえ同じネットワークの中でIPホストとの完全な互換性を維持します。 過渡期の間、IPホストは簡単な翻訳サービスで他のネットワークのどんなホストともコミュニケートできます。
In the rest of the paper, IP refers to the current Internet Protocol and EIP refers to the Extended Internet Protocol (EIP is pronounced as "ape" - a step forward in the evolution :-).
紙の残りでは、IPは現在のインターネットプロトコルを示します、そして、EIPはExtendedインターネットプロトコルを示します。(EIPは「サル」--先取りとして発展で発音されます(^o^)
Extended Internet Protocol (EIP)
拡張インターネットプロトコル(EIP)
The EIP header format is shown in Figure 1 and the contents of the header follows.
EIPヘッダー形式は図1に示されます、そして、ヘッダーのコンテンツは続きます。
Wang [Page 3] RFC 1385 EIP November 1992
ワング[3ページ]RFC1385EIP1992年11月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Host Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Host Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EIP ID | EIP Ext Length| EIP Extension (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| IHL|サービスのタイプ| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別|旗| 断片オフセット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 生きる時間| プロトコル| ヘッダーチェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送信元ホスト番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | あて先ホスト番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EIP ID| EIP Extの長さ| EIP拡張子(可変)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EIP Header Format
図1: EIPヘッダー形式
Version: 4 bits
バージョン: 4ビット
The Version field is identical to that of IP. This field is set
purely for compatibility with IP hosts. It is not checked by EIP
hosts.
バージョン分野はIPのものと同じです。 この分野は純粋にIPホストとの互換性に設定されます。 それはEIPホストによってチェックされません。
IHL: 4 bits
IHL: 4ビット
Internet Header Length is identical to that of IP. IHL is set to
the length of EIP header purely for compatibility with IP. This
field is not checked by EIP hosts. see below the EIP Extension
Length field for more details)
インターネットHeader LengthはIPのものと同じです。 IHLはIPとの互換性のために純粋にEIPヘッダーの長さに用意ができています。 この分野はEIPホストによってチェックされません。EIP Extension Length分野の下でその他の詳細に関して見てください)
Type of Service: 8 bits
サービスのタイプ: 8ビット
The ToS field is identical to that of IP.
ToS分野はIPのものと同じです。
Total Length: 16 bits
全長: 16ビット
The Total Length field is identical to that of IP.
Total Length分野はIPのものと同じです。
Identification: 16 bits
識別: 16ビット
The Identification field is identical to that of IP.
Identification分野はIPのものと同じです。
Flags: 3 bits
旗: 3ビット
The Flags field is identical to that of IP.
Flags分野はIPのものと同じです。
Wang [Page 4] RFC 1385 EIP November 1992
ワング[4ページ]RFC1385EIP1992年11月
Fragment Offset: 13 bits
断片は相殺されました: 13ビット
The Fragment Offset field is identical to that of IP.
Fragment Offset分野はIPのものと同じです。
Time to Live: 8 bits
生きる時間: 8ビット
The Time to Live field is identical to that of IP.
Live分野へのTimeはIPのものと同じです。
Protocol: 8 bits
プロトコル: 8ビット
The Protocol field is identical to that of IP.
プロトコル分野はIPのものと同じです。
Header Checksum: 16 bits
ヘッダーチェックサム: 16ビット
The Header Checksum field is identical to that of IP.
Header Checksum分野はIPのものと同じです。
Source Host Number: 32 bits
送信元ホスト番号: 32ビット
The Source Host Number field is used for identifying the
source host but is unique only within the source network
(the equivalent of the host portion of the source IP address).
Source Host Number分野は、送信元ホストを特定するのに使用されますが、ソースネットワーク(ソースIPアドレスのホスト部分の同等物)だけの中でユニークです。
Destination Host Number: 32 bits
あて先ホスト番号: 32ビット
The Destination Host Number field is used for identifying the
destination host but is unique only within the destination network
(the equivalent of the host portion of the destination IP address).
Destination Host Number分野は、あて先ホストを特定するのに使用されますが、送信先ネットワーク(送付先IPアドレスのホスト部分の同等物)だけの中でユニークです。
EIP ID: 8 bits
EIP ID: 8ビット
The EIP ID field equals to 0x8A. The EIP ID value is chosen
in such a way that, to IP hosts and IP routers, an EIP appears
to be an IP packet with a new IP option of following parameters:
EIP IDは0x8Aの同輩をさばきます。 EIP ID値はEIPがIPホストとIPルータにパラメタに従う新しいIPオプションがあるIPパケットに見えるそのような方法で選ばれています:
COPY CLASS NUMBER LENGTH DESCRIPTION
---- ----- ------ ------ -----------
1 0 TBD var
コピークラス番号長さの記述---- ----- ------ ------ ----------- 1 0TBD var
Option: Type=TBD
オプション: =TBDをタイプしてください。
EIP Extension Length: 8 bits
EIP拡大の長さ: 8ビット
The EIP Extension Length field indicates the total length
of the EIP ID field, EIP Extension Length field and the
EIP Extension field in octets. The maximum length that the
IHL field above can specify is 60 bytes, which is considered
too short in future. EIP hosts actually use the EIP Extension
Length field to calculate the total header length:
EIP Extension Length分野は八重奏におけるEIP ID分野、EIP Extension Length分野、およびEIP Extension分野の全長を示します。 上のIHL分野が指定できる最大の長さは60バイトです。(そのバイトはこれから、あまりに急に考えられます)。 EIPホストは総ヘッダ長について計算するのに実際にEIP Extension Length分野を使用します:
Wang [Page 5] RFC 1385 EIP November 1992
ワング[5ページ]RFC1385EIP1992年11月
The total header length = EIP Extension Length + 20.
総ヘッダ長=EIP Extension Length+20。
The maximum header length of an EIP packet is then 276 bytes.
そして、EIPパケットの最大のヘッダ長は276バイトです。
EIP Extension: variable
EIP拡張子: 変数
The EIP Extension field holds the Source Network Number,
Destination Network Number and other fields. The format
of the Extension field is not specified here. In its simplest
form, it can be used to hold two fixed size fields as the
Source Network Number and Destination Network Number as the
extension to the addressing space. Since the Extension
field is variable in length, it can accommodate almost any
routing and addressing schemes. For example, the Extension
field can be used to hold "Routing Directive" etc specified
in Pip [7] or "Endpoint IDs" suggested in Nimrod [8], or the
"CityCode" [10]. It can also hold other fields such as the
"Handling Directive" [7] or "Connectionless ID" [11].
EIP Extension分野はSource Network Number、Destination Network Number、および他の分野を持っています。 Extension分野の形式はここで指定されません。 最も簡単なフォームでは、拡大としてアドレシングスペースにサイズ分野がSource Network NumberとDestination Network Numberとして2に固定されているままにするのにそれを使用できます。 Extension分野が長さで可変であるので、それはほとんどどんなルーティングとアドレシング体系にも対応できます。 例えば、「ルート設定指示」などがPip[7]、ニムロデ[8]に示された「終点ID」、または"CityCode"[10]で指定されるままにするのにExtension分野を使用できます。 また、それは「取り扱い指示」[7]か「コネクションレスなID」[11]などの他の分野を保持できます。
EIP achieves maximum backward compatibility with IP by making the extended space appear to be an IP option to the IP hosts and routers.
拡張スペースをIPオプションであるようにIPホストとルータに見えさせることによって、EIPはIPとの最大の後方の互換性を獲得します。
When an IP host receives an EIP packets, the EIP Extension field is safely ignored as it appears to the IP hosts as an new, therefore an unknown, IP option. As a result, there is no need for translation for in-coming EIP packets destined to IP hosts and there is also no need for subnet routers to be upgraded during the transition period see later section for more details).
いつとしてIPホストがEIPパケットを受けて、EIP Extension分野がIPホストにとって現れるように安全に無視されるか、したがって、新しいのと、未知(IPオプション) その結果、IPホストに運命づけられた入って来るEIPパケットのための翻訳の必要は全くなくて、またあって、また、サブネットルータが過渡期の間にアップグレードする必要性も、全く後のセクションがその他の詳細に関して認めない、)
EIP hosts or routers can, however, determine whether a packet is an IP packet or an EIP packet by examining the EIP ID field, whose position is fixed in the header.
しかしながら、EIPホストかルータが、位置がヘッダーで修理されているEIP ID分野を調べることによって、パケットがIPパケットかそれともEIPパケットであるかを決心できます。
The EIP Extension field holds the Source and Destination Network Numbers, which are only used for communications between different networks. For communications within the same network, the Network Numbers may be omitted. When the Extension field is omitted, there is little difference between an IP packet and an EIP packet. Therefore, EIP hosts can maintain completely compatibility with IP hosts within one network.
EIP Extension分野はSourceとDestination Network民数記を保持します。(それは、異なったネットワークのコミュニケーションに使用されるだけです)。 同じネットワークの中のコミュニケーションに関しては、Network民数記は省略されるかもしれません。 Extension分野が省略されるとき、IPパケットとEIPパケットの間には、少しの違いがあります。 したがって、EIPホストは1つのネットワークの中でIPホストとの互換性を完全に維持できます。
In EIP, the Network Numbers and Host Numbers are separate and the IP address field is used for the Host Number in EIP. There are a number of advantages:
EIPでは、Network民数記とHost民数記は別々です、そして、IPアドレス・フィールドはEIPのHost Numberに使用されます。 多くの利点があります:
1) It maintains full compatibility between IP hosts and EIP hosts
for communications within one network. Note that the Network
Number is not needed for communications within one network. A
1) それはコミュニケーションのために1つのネットワークの中でIPホストとEIPホストとの完全な互換性を維持します。 Network Numberは1つのネットワークの中でコミュニケーションに必要でないことに注意してください。 A
Wang [Page 6] RFC 1385 EIP November 1992
ワング[6ページ]RFC1385EIP1992年11月
host can omit the Extension field if it does not need any other
information in the Extension field, when it communicates with
another host within the same network.
Extension分野で他の情報を必要としないなら、ホストはExtension分野を省略できます、同じネットワークの中で別のホストとコミュニケートするとき。
2) It allows the IP subnet routers to route EIP packet by treating
the Host Number as the IP address during the transition period,
therefore the subnet routers are not required to be updated
along the border routers.
2) それで、IPサブネットルータは過渡期の間、IPアドレスとしてHost Numberを扱うことによって、EIPパケットを発送できます、したがって、サブネットルータが境界ルータに沿ってアップデートするのに必要ではありません。
3) It allows ARP/RARP to work with both EIP and IP hosts without
any modifications.
3) それで、アルプ/RARPはEIPとIPホストの両方で少しも変更なしで働くことができます。
4) It allows the translation at the border routers much easier.
During the transition period when the IP addresses are still
unique, the network portion of the IP addresses can be directly
extracted and mapped to EIP Network Numbers.
4) それは境界ルータではるかに簡単な状態で翻訳を許容します。 IPアドレスがまだユニークであるときに、過渡期の間、IPアドレスのネットワーク部分は、直接抽出していてEIP Network民数記に写像できます。
Modifications to IP Systems
IPシステムへの変更
In this section, we outline the modifications to the IP systems that are needed for transition to EIP. Because of the similarity between the EIP and IP, the amount of modifications needed to current systems are substantially reduced.
このセクションで、私たちはEIPへの変遷に必要であるIPシステムへの変更について概説します。 EIPとIPの間の類似性のために、現在のシステムに必要である変更の量はかなり減少します。
1) Network Numbers: Each network has to be assigned a new EIP Network
Number based on the addressing scheme used. The mapping
between the IP network numbers and the EIP Network Numbers can
be used for translation service (see below).
1) 数をネットワークでつないでください: 使用されるアドレシング体系に基づく新しいEIP Network Numberは各ネットワークに配属されなければなりません。 翻訳サービスにIPネットワーク・ナンバーとEIP Network民数記の間のマッピングを使用できます(以下を見てください)。
2) Host Numbers: There is no need for assigning EIP Host Numbers.
All existing hosts can use their current IP addresses as their
EIP Host Numbers. New machines may be allocated any number from
the 32-bit Host Number space since the structure posed on IP
addressing is no longer necessary. However, during the transition,
allocation of EIP Host Numbers should still follow the IP
addressing rule, so that the EIP Host Numbers are still globally
unique and can still be interpreted as IP addresses. This will
allow a more gradual transition to EIP (see below).
2) 数を接待してください: 民数記をEIP Hostに割り当てる必要は全くありません。 すべての既存のホストがそれらのEIP Host民数記として彼らの現在のIPアドレスを使用できます。 IPアドレシングで引き起こされた構造はもう必要でないので、どんな数も32ビットのHost Numberスペースから新しいマシンに割り当てるかもしれません。 しかしながら、変遷の間、EIP Host民数記の配分はまだIPアドレスとして解釈されていた状態でしたがって規則を扱うEIP Host民数記がまだグローバルにユニークであり、まだあることができるIPに続いているべきです。 これはEIPへの、よりゆるやかな変遷を許容するでしょう(以下を見てください)。
3) Translation Service: During the transition period when the EIP
Host Numbers are still unique, an address translation service
can be provided to IP hosts that need communicate with hosts in
other networks cross the upgraded backbone networks. The
translation service can be provided by the border routers. When a
border router receives an IP packet, it obtains the Destination
Network Number by looking up in the mapping table between IP
network numbers and EIP Network Numbers. The border router then
adds the Extension field with the Source and Destination Network
3) 翻訳サービス: EIP Host民数記がまだユニークであるときに、過渡期の間、アドレス変換サービスはIPに、他のネットワークでホストとコミュニケートしなければならないホストがアップグレードしたバックボーンネットワークを横断するかどうかということであるかもしれません。 境界ルータは翻訳サービスを提供できます。 境界ルータがIPパケットを受けるとき、それは、マッピングテーブルを調べることによって、IPネットワーク・ナンバーとEIP Network民数記の間にDestination Network Numberを入手します。 そして、境界ルータはSourceとDestination Networkと共にExtension分野を加えます。
Wang [Page 7] RFC 1385 EIP November 1992
ワング[7ページ]RFC1385EIP1992年11月
Numbers into the packet, and forwards to the backbone networks.
It is only necessary to translate the out-going IP packets to
the EIP packets. There is no need to translate the EIP packets
back to IP packets even when they are destined to IP hosts.
This is because that the Extension field in the EIP packets
appears to IP hosts just an unknown IP option and is ignored by
the IP hosts during the processing.
パケットへの数、およびバックボーンネットワークへのフォワード。 単に外向的なIPパケットをEIPパケットに翻訳するのが必要です。 それらがIPホストに運命づけられるときさえEIPパケットをIPパケットに翻訳して戻す必要は全くありません。 これがそう、EIPパケットのExtension野原がIPにおいて現れるのは、まさしく未知のIPオプションを主催して、処理の間、IPホストによって無視されます。
4) Border Routers: The new EIP Extension has to be implemented and
routing has to be done based on the Network Number in the EIP
Extension field. The border routers may have to provide the
translation service for out-going IP packets during the transition
period.
4) ルータに接してください: 新しいEIP Extensionを実装しなければなりません、そして、EIP Extension分野のNetwork Numberに基づいた状態でルーティングしなければなりません。 境界ルータは過渡期の間、外向的なIPパケットのための翻訳サービスを提供しなければならないかもしれません。
5) Subnet Routers: No modifications are required during the transition
period when EIP Host Numbers (which equals to the IP
addresses) are still globally unique. The subnet routing is carried
out based on the EIP Host Numbers and when the EIP Host
IDs are still unique, subnet routers can determine, by treating
the EIP Host Number as the IP addresses, whether a packet is
destined to remote networks or not and forward correctly. The
Extension field in the EIP packets also appear to the IP subnet
routers an unknown IP option and is ignored in the processing.
However, subnet routers eventually have to implement the EIP
Extension and carry out routing based on Network Numbers when
EIP Host Numbers are no longer globally unique.
5) サブネットルータ: (IPアドレスへのそれの同輩)がまだグローバルにユニークであるEIP Host民数記であるときに、変更は全く過渡期の間、必要ではありません。 サブネットルーティングがEIP Host民数記、EIP Host IDがいつまだユニークであるか、そして、ルータがパケットがリモートネットワークに運命づけられているか否かに関係なく、IPアドレスとしてEIP Host Numberを扱うことによって決定できるサブネット、およびフォワードに基づいて正しく行われます。 EIPパケットのExtension分野も、IPサブネットルータへの未知のIPオプションに見えて、処理で無視されます。 しかしながら、サブネットルータは、結局、EIP Extensionを実装して、EIP Host民数記がもうグローバルにユニークでないときにNetwork民数記に基づくルーティングを行わなければなりません。
6) Hosts: The EIP Extension has to be implemented. routing has to
be done based on the Network Number in the EIP Extension field,
and also based on the Host Number and subnet mask if subnetting
is used. IP hosts may communication with any hosts within the
same network at any time. During the transition period when the
EIP Host Numbers are still unique, IP hosts can communicate with
any hosts in other network via the translation service.
6) ホスト: EIP Extensionを実装しなければなりません。サブネッティングが使用されているなら、EIP Extension分野、Host Numberとサブネットマスクおよびに基づいてもNetwork Numberに基づいた状態でルーティングしなければなりません。 IPホストはいつでも同じネットワークの中のどんなホストとのコミュニケーションもそうするかもしれません。 EIP Host民数記がまだユニークであるときに、過渡期の間、IPホストは翻訳サービスで他のネットワークのどんなホストともコミュニケートできます。
7) DNS: A new resource record (RR) type "N" has to be added for EIP
Network Numbers. The RR type "A", currently used for IP
addresses, can still be used for EIP Host Numbers. RR type "N"
entries have to be added and RR type "PTR" to be updated. All
other entries remain unchanged.
7) DNS: 新しいリソース記録(RR)タイプ「N」はEIPネットワーク・ナンバーのために加えられなければなりません。 EIPホスト番号にまだ現在IPアドレスに使用されているRRタイプ「A」は使用できます。 RRタイプ「N」エントリーは加えられなければなりません、そして、RRはアップデートするために"PTR"をタイプします。 他のすべてのエントリーが変わりがあるというわけではありません。
8) ARP/RARP: No modifications are required. The ARP and RARP are
used for mapping between EIP Host Numbers and physical
addresses.
8) アルプ/RARP: 変更は全く必要ではありません。 ARPとRARPはEIP Host民数記と物理アドレスの間のマッピングに使用されます。
9) ICMP: No modifications are required.
9) ICMP: 変更は全く必要ではありません。
10) TCP/UDP Checksum: No modifications are required. The pseudo
10) TCP/UDPチェックサム: 変更は全く必要ではありません。 疑似
Wang [Page 8] RFC 1385 EIP November 1992
ワング[8ページ]RFC1385EIP1992年11月
header includes the EIP Source and Destination IDs instead of
the source and destination IP addresses.
ヘッダーはIPが演説するソースと目的地の代わりにEIP SourceとDestination IDを入れます。
11) FTP: No modifications are required during the transition period
when the IP hosts can still communicate with hosts in other
networks via the translation service. After the transition period,
however, the "DATA Port (Port)" command has to be modified to
pass the port number only and ignore the IP address. A new FTP
command may be created to pass both the port number and the EIP
address to allow a third party to be involved in the file
transfer.
11) FTP: IPホストが他のネットワークでまだホストと翻訳サービスでコミュニケートできるとき、変更は全く過渡期の間、必要ではありません。 しかしながら、過渡期の後に、「データポート(ポート)」コマンドは、ポートナンバーだけを通過して、IPアドレスを無視するように変更されなければなりません。 新しいFTPコマンドは、第三者がファイル転送にかかわるのを許容するためにポートナンバーとEIPアドレスの両方を通過するために作成されるかもしれません。
Transition to EIP
EIPへの変遷
In this section, we outline a plan for transition to EIP.
このセクションで、私たちはEIPへの変遷のためのプランについて概説します。
EIP can greatly reduce the complexity of transition. In particular, there is no need for the updated hosts and subnet routers to run two protocols in parallel in order to achieve interoperability between old and new systems. During the transition, IP hosts can still communicate with any machines in the same network without any changes. When the EIP Host Numbers (i.e., the 32-bit IP addresses) are still globally unique, IP hosts can contact hosts in other networks via translation service provided in the border routers.
EIPは変遷の複雑さを大いに減少させることができます。 古くて新しいシステムの間には、特に、アップデートされたホストとサブネットルータが相互運用性を達成するために平行な2つのプロトコルを実行する必要は全くありません。変遷の間、IPホストは少しも変化なしで同じネットワークにおけるどんなマシンともまだコミュニケートできます。 EIP Host民数記であるときに、(すなわち、32ビットのIPアドレス)がまだグローバルにユニークである、他のネットワークで境界ルータに提供された翻訳サービスでIPホストはホストに連絡できます。
The transition goes as follows:
変遷は以下の通り行きます:
Phase 0:
a) Choose an addressing and routing scheme for the Internet.
b) Implement the routing protocol.
c) Assign new Network Numbers to existing networks.
フェーズ0: a) インターネットのアドレシングとルーティング体系に. b)を選んでください。 プロトコルルーティングがc)であると実装してください。 新しいNetwork民数記を既存のネットワークに配属してください。
Phase 1:
a) Update all backbone routers and border routers.
b) Update DNS servers.
c) Start translation service.
フェーズ1: a) 境界ルータすべてのバックボーンルータとb)をアップデートしてください。 アップデートDNSサーバc) 翻訳サービスを始めてください。
Phase 2:
a) Update first the key hosts such as mail servers, DNS servers,
FTP servers and central machines.
b) Update gradually the rest of the hosts.
フェーズ2: a) 最初に、キーが中央のマシンメールサーバや、DNSサーバや、FTPサーバやb)などのように主催するアップデート 徐々にホストの残りをアップデートしてください。
Phase 3:
a) Update subnet routers
b) Withdraw the translation service.
フェーズ3: a) アップデートサブネットルータb) 翻訳サービスを引き下がらせてください。
The translation service can be provided as long as the Host IDs (i.e., the 32-bit IP address) are still globally unique. When the IP
Host ID(すなわち、32ビットのIPアドレス)がまだグローバルにユニークである限り、翻訳サービスを提供できます。 いつIP
Wang [Page 9] RFC 1385 EIP November 1992
ワング[9ページ]RFC1385EIP1992年11月
address space is exhausted, the translation service will be withdrawn and the remaining IP hosts can only communicate with hosts within the the same network. At the same time, networks can use any numbers in the 32-bit space for addressing their hosts.
アドレス空間は疲れ果てています、そして、翻訳サービスは引き下がるでしょう、そして、残っているIPホストは同じネットワークの中でホストとコミュニケートできるだけです。 同時に、ネットワークは32ビットのスペースの彼らのホストに演説するどんな数も使用できます。
Related Work
関連仕事
A recent proposal called IPAE by Hinden and Crocker also attempts to minimize the modifications to the current IP system yet to extend the addressing space [12]. IPAE uses encapsulation so that the extended space is carried as IP data. However, it has been found that the 64 bits IP data returned by an ICMP packet is too small to hold the Global IP addresses. Thus, when a router receives an ICMP generated by an old IP host, it is not able to convert it into a proper ICMP packet. More details can be found in [13].
また、HindenとクロッカーによってIPAEと呼ばれた最近の提案は、まだアドレシングスペース[12]を広げていないように現在のIPシステムへの変更を最小にするのを試みます。 IPAEがカプセル化を使用するので、拡張スペースはIPデータとして運ばれます。 しかしながら、ICMPパケットによって返された64ビットのIPデータがGlobal IPアドレスを保持できないくらい小さいのが見つけられました。 ルータが年取ったIPホストによって生成されたICMPを受けるとき、したがって、それは適切なICMPパケットにそれを変換できません。 [13]でその他の詳細を見つけることができます。
Discussions
議論
EIP does not necessary increase the header length significantly as most of the fields in the current IP will be still needed in the new internet protocol. There are debates as to whether fragmentation and header checksum are necessary in the new internet protocol but no consensus has been reached.
それでも、現在のIPにおける分野の大部分が新しいインターネットプロトコルで必要であるようにEIPはかなりどんな必要な増加にもヘッダ長をしません。 断片化とヘッダーチェックサムが新しいインターネットプロトコルで必要であるかどうかに関して討論がありますが、コンセンサスに全く達していません。
EIP assumes that IP hosts and routers ignore unknown IP option silently as required by [15,16]. Some people have expressed some concerns as to whether current IP routers and hosts in the Internet can deal with unknown IP options properly.
EIPは、IPホストとルータが必要に応じて[15、16]で静かに未知のIPオプションを無視すると仮定します。 人々の中にはインターネットの現在のIPルータとホストが適切に未知のIPオプションに対処できるかどうかに関していくつかの関心を述べた人もいました。
In order to look into the issues further, we carried out a number of experiments over the use of IP option. We selected 35 hosts over 30 countries across the Internet. A TCP test program (based on ttcp.c) then transmitted data to the echo port (tcp port 7) of each of the hosts. Two tests were carried out for each host, one with an unknown option (type 0x8A, length 40 bytes) and the other without any options.
さらに問題を調べるために、私たちはIPオプションの使用の上に多くの実験を行いました。 私たちはインターネットの向こう側に30の国の上で35人のホストを選びました。 そして、TCPテストプログラム(ttcp.cに基づいている)はホスト各人のエコーポート(tcpポート7)にデータを送りました。 2つのテストが各1歳のホストのために未知のオプション(0x8Aをタイプしてください、40バイトの長さ)ともう片方で少しもオプションなしで行われました。
It is difficult to ensure that the conditions under which the two tests run are identical but we tried to make them as close as possible. The two tests (test-opt and test-noopt) run on the same machine a Sun4) in parallel, i.e., "test-opt& ; test-noopt&" and then again in the reverse order, i.e., "test-noopt& ; test-opt&", so each test pair actually run twice. Each host was ping'ed before the tests so that the domain name information was cached before the name lookup.
2つのテストが稼働する状態が同じですが、私たちができるだけ近くでそれらを作ろうとしたのを保証するのは難しいです。 すなわち、2つのテスト(試しに選んで、試しにnooptする)が平行に同じマシンa Sun4) コネで動く、「試しに選んでください、」、。 「」 試nooptと再び次にすなわち逆が注文するコネ、「試noopt、」、。 「試しに選んでください、」、それで、それぞれのテスト組は実際に二度走ります。 各ホストがテストの前のping'edであったので、ドメイン名情報はルックアップという名前の前にキャッシュされました。
The experiments were carried out at three sites: UCL, Bellcore and Cambridge University. The tcp echo throughput (KB/Sec) results are
実験が3つのサイトで行われました: UCL、Bellcore、およびケンブリッジ大学。 tcpエコースループット(KB/秒)結果はそうです。
Wang [Page 10] RFC 1385 EIP November 1992
ワング[10ページ]RFC1385EIP1992年11月
listed in Appendix.
Appendixでは、記載されています。
The results show that the IP option was dealt with properly and there is no visible performance difference under the test setup.
結果はIPオプションが適切に対処されて、どんな目に見える性能差もテストセットアップでないのを示します。
References
参照
[1] Chiappa, N., "The IP Addressing Issue", Work in Progress, October
1990.
[1] N.、「IPアドレシング問題」というChiappaは進歩、1990年10月に働いています。
[2] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
"Towards the Future Architecture", RFC 1287, MIT, BBN, CNRI, ISI,
UCDavis , December 1991.
[2] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「将来のアーキテクチャ」RFC1287、MIT、BBN、CNRI、ISI、UCDavis(1991年12月)。
[3] Solensky, F. and F. Kastenholz, "A Revision to IP Address
Classifications", Work in Progress, March 1992.
[3] 「IPアドレス分類への改正」というSolensky、F.、およびF.Kastenholzは進歩、1992年3月に働いています。
[4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
cisco, Merit, OARnet, June 1992.
[4] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 「Address AssignmentとAggregation Strategy」、RFC1338、BARRNet、コクチマス、Merit、OARnet、6月1992日
[5] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the
Internet: a solution to the problem of address space exhaustion",
RFC 1335, University College London, May 1992.
[5] ワング、Z.、およびJ.クロウクロフト、「2層がインターネットに構造を扱います」。 RFC1335、ユニバーシティ・カレッジロンドン1992年5月の「アドレス空間疲労困憊の問題への解決。」
[6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple
Proposal for Internet Addressing and Routing", RFC 1347, DEC,
June 1992.
[6] Callon、R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を扱います」、RFC1347、1992年12月、6月。
[7] Tsuchiya, P., "Pip: The 'P' Internet Protocol", Work in Progress,
May 1992
[7] Tsuchiya(P.)は「以下に種をとります」。 P'インターネットプロトコル」、処理中の作業、1992年5月
[8] Chiappa N., "A New IP Routing and Addressing Architecture", Work
in Progress, 1992.
[8] 「新しいIPルート設定とアドレッシング体系」というChiappa N.は進歩、1992年に働いています。
[9] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP
Allocation in the Internet" RFC 1237, NIST, Mitre, DEC, July
1991.
[9]Colella、R.、ガードナー、E.、およびR.Callon、「インターネットのオウシNSAP Allocationのためのガイドライン」RFC1237、NIST、斜め継ぎ、12月(1991年7月)。
[10] Deering, S., "City Codes: An Alternative Scheme for OSI NSAP
Allocation in the Internet", Work in Progress, January 1992.
[10] デアリング、S.、「市は以下をコード化します」。 「インターネットのオウシNSAP Allocationの代替の体系」、処理中の作業、1992年1月。
[11] Clark, D., "Building routers for the routing of tomorrow", in his
message to Big-Interent@munnari.oz.au, 14 July 1992.
[11] クラーク、D.、彼の Big-Interent@munnari.oz.au 、1992年7月14日までのメッセージの「明日のルーティングのためのビルルータ。」
[12] Hinden, R., and D. Crocker, "A Proposal for IP Address
Encapsulation (IPAE): A Compatible Version of IP with Large
Addresses", Work in Progress, July 1992.
[12] Hinden、R.、およびD.クロッカー、「IPのための提案はカプセル化(IPAE)を扱います」。 「大きいアドレスがあるIPのコンパチブルバージョン」、処理中の作業、1992年7月。
Wang [Page 11] RFC 1385 EIP November 1992
ワング[11ページ]RFC1385EIP1992年11月
[13] Partridge, C., "Re: Note on implementing IPAE", in his message to
Big-Interent@munnari.oz.au, 17 July 1992.
[13] ヤマウズラ、C.、「Re:」 彼のメッセージで Big-Interent@munnari.oz.au 、1992年7月17日まで「IPAEを実装するとき、注意します」。
[14] Deering, S., "SIP: Simple Internet Protocol", Work in Progress,
September 1992.
[14] デアリング、S.は「以下をちびちび飲みます」。 「簡単なインターネットプロトコル」、進行中の仕事、1992年9月。
[15] Braden, R., Editor, "Requirements for Internet Hosts
-- Communication Layers", RFC 1122, ISI, October 1989.
[15] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、RFC1122、ISI、10月1989日
[16] Almquist, P., Editor, "Requirements for IP Routers", Work in
Progress, October 1991.
[16] P.、エディタ、「IPルータのための要件」というAlmquistは進歩、1991年10月に働いています。
Appendix
付録
Throughput Test from UCL (sartre.cs.ucl.ac.uk)
UCLからのスループットテスト(sartre.cs.ucl.ac.uk)
Destination Host test-noopt test-opt
------------------- ---------- ---------
oliver.cs.mcgill.ca 1.128756 1.285345
oliver.cs.mcgill.ca 1.063096 1.239709
bertha.cc.und.ac.za 0.094336 0.043917
bertha.cc.und.ac.za 0.075681 0.057120
vnet3.vub.ac.be 2.090622 2.228181
vnet3.vub.ac.be 1.781374 1.692740
itdsrv1.ul.ie 1.937596 2.062579
itdsrv1.ul.ie 1.928313 1.936784
sunic.sunet.se 11.064797 11.724055
sunic.sunet.se 10.861720 10.840306
pascal.acm.org 2.463790 0.810133
pascal.acm.org 1.619088 0.860198
iti.gov.sg 1.565320 1.983795
iti.gov.sg 1.564788 1.921803
rzusuntk.unizh.ch 9.903805 11.335920
rzusuntk.unizh.ch 9.597806 10.678098
funet.fi 9.897876 9.382925
funet.fi 10.487118 11.023745
odin.diku.dk 5.851407 5.482946
odin.diku.dk 5.992257 6.243283
cphkvx.cphk.hk 0.758044 0.844406
cphkvx.cphk.hk 0.784532 0.745606
bootes.cus.cam.ac.uk 28.341705 29.655824
bootes.cus.cam.ac.uk 24.804125 23.240990
pesach.jct.ac.il 1.045922 1.115802
pesach.jct.ac.il 1.330429 0.978184
sun1.sara.nl 10.546733 11.500778
sun1.sara.nl 9.624833 10.214136
cocos.fuw.edu.pl 1.747777 1.702324
cocos.fuw.edu.pl 1.676151 1.716435
目的地Host試nooptは試しに選びます。------------------- ---------- --------- oliver.cs.mcgill.ca1.128756 1.285345oliver.cs.mcgill.ca1.063096 1.239709bertha.cc.und.ac.za0.094336 0.043917bertha.cc.und.ac.za0.075681 0.057120vnet3.vub.ac.be2.090622 2.228181vnet3.vub.ac.be1.781374 1.692740itdsrv1.ul.ie1.937596 2.062579itdsrv1.ul.ie1.928313 1.936784sunic.sunet.se11.064797 11.724055sunic.sunet.se10.861720 10.840306pascal.acm.org2.463790 0.810133pascal.acm.org1.619088 0.860198iti.gov.sg1.565320 1.983795iti.gov.sg1.564788 1.921803rzusuntk.unizh.ch9.903805 11; 335920 rzusuntk.unizh.ch9.597806 10.678098funet.fi9.897876 9.382925funet.fi10.487118 11.023745odin.diku.dk5.851407 5.482946odin.diku.dk5.992257 6.243283cphkvx.cphk.hk0.758044 0.844406cphkvx.cphk.hk0.784532 0.745606bootes.cus.cam.ac.uk28.341705 29; 655824 bootes.cus.cam.ac.uk24.804125 23.240990pesach.jct.ac.il1.045922 1.115802pesach.jct.ac.il1.330429 0.978184sun1.sara.nl10.546733 11.500778sun1.sara.nl9.624833 10.214136cocos.fuw.edu.pl1.747777 1.702324cocos.fuw.edu.pl1.676151 1.716435
Wang [Page 12] RFC 1385 EIP November 1992
ワング[12ページ]RFC1385EIP1992年11月
apple.com 4.449559 4.145081
apple.com 6.431675 5.520443
gorgon.tf.tele.no 1.199810 1.374546
gorgon.tf.tele.no 0.508642 0.993261
kogwy.cc.keio.ac.jp 3.626448 3.249590
kogwy.cc.keio.ac.jp 3.913777 4.094849
exu.inf.puc-rio.br 1.913925 1.795235
exu.inf.puc-rio.br 1.154936 1.114775
inria.inria.fr 2.299561 0.599665
inria.inria.fr 1.219282 0.873672
kum.kaist.ac.kr 0.252704 0.254199
kum.kaist.ac.kr 0.236196 0.172367
sunipc1.labein.es 1.398777 1.243588
sunipc1.labein.es 0.876177 0.602964
wifosv.wsr.ac.at 0.531153 0.803387
wifosv.wsr.ac.at 0.773935 0.557798
uunet.uu.net 7.813556 6.764543
uunet.uu.net 7.969203 6.657325
infnsun.aquila.infn.it 2.321197 2.402477
infnsun.aquila.infn.it 2.400196 2.695016
muttley.fc.ul.pt 0.545775 0.434672
muttley.fc.ul.pt 0.284124 0.266017
dmssyd.syd.dms.csiro.au 2.734685 2.857545
dmssyd.syd.dms.csiro.au 1.168154 1.462789
hamlet.caltech.edu 2.552804 2.897286
hamlet.caltech.edu 3.839141 2.407945
sztaki.hu 0.294196 0.403697
sztaki.hu 0.236260 0.388755
menvax.restena.lu 0.465066 0.515361
menvax.restena.lu 0.358646 0.511985
nctu.edu.tw 0.484372 0.816722
nctu.edu.tw 0.705733 1.109228
xalapa.lania.mx 0.899529 0.822544
xalapa.lania.mx 1.150058 0.881713
truth.waikato.ac.nz 1.438481 1.993749
truth.waikato.ac.nz 1.325041 1.833999
apple.com4.449559 4.145081apple.com6.431675 5.520443gorgon.tf.tele.no1.199810 1.374546gorgon.tf.tele.no0.508642 0.993261kogwy.cc.keio.ac.jp3.626448 3.249590kogwy.cc.keio.ac.jp3.913777 4.094849exu.inf.puc-rio.br1.913925 1.795235exu.inf.puc-rio.br1.154936 1.114775inria.inria.fr2.299561 0.599665inria.inria.fr1.219282 0.873672kum.kaist.ac.kr0.252704 0.254199kum.kaist.ac.kr0.236196 0.172367sunipc1.labein.es1.398777 1.243588sunipc1.labein.es0.876177 0.602964wifosv.wsr.ac.at、0.531153、0; 803387 wifosv.wsr.ac.at0.773935 0.557798uunet.uu.net7.813556 6.764543uunet.uu.net7.969203 6.657325infnsun.aquila.infn.it2.321197 2.402477infnsun.aquila.infn.it2.400196 2.695016muttley.fc.ul.pt0.545775 0.434672muttley.fc.ul.pt0.284124 0.266017dmssyd.syd.dms.csiro.au2.734685 2.857545dmssyd.syd.dms.csiro.au1.168154 1.462789hamlet.caltech.edu2.552804 2.897286hamlet.caltech.edu3.839141 2.407945sztaki.hu0.294196 0.403697sztaki.hu0.236260 0.388755menvax.restena.lu0.465066 0.515361 menvax.restena.lu0.358646 0.511985nctu.edu.tw0.484372 0.816722nctu.edu.tw0.705733 1.109228xalapa.lania.mx0.899529 0.822544xalapa.lania.mx1.150058 0.881713truth.waikato.ac.nz1.438481 1.993749truth.waikato.ac.nz1.325041 1.833999
Wang [Page 13] RFC 1385 EIP November 1992
ワング[13ページ]RFC1385EIP1992年11月
Throughput Test from Bellcore (latour.bellcore.com)
Bellcoreからのスループットテスト(latour.bellcore.com)
Destination Host test-noopt test-opt
------------------ ---------- ---------
oliver.cs.mcgill.ca 1.820014 2.128104
oliver.cs.mcgill.ca 1.979981 1.866815
bertha.cc.und.ac.za 0.099289 0.035877
bertha.cc.und.ac.za 0.118627 0.103763
vnet3.vub.ac.be 0.368476 0.694463
vnet3.vub.ac.be 0.443269 0.644050
itdsrv1.ul.ie 0.721444 0.960068
itdsrv1.ul.ie 0.713952 0.953275
sunic.sunet.se 2.989907 2.956766
sunic.sunet.se 2.100563 2.010292
pascal.acm.org 2.487185 3.896253
pascal.acm.org 1.944085 4.269323
iti.gov.sg 2.401733 2.735445
iti.gov.sg 2.950990 2.793121
rzusuntk.unizh.ch 4.094820 3.618023
rzusuntk.unizh.ch 2.952650 2.245001
funet.fi 6.703408 5.928008
funet.fi 7.389722 5.815122
odin.diku.dk 2.094152 2.450695
odin.diku.dk 5.362362 4.690722
cphkvx.cphk.hk 0.092698 0.106880
cphkvx.cphk.hk 0.496394 0.681994
bootes.cus.cam.ac.uk 2.632951 2.631322
bootes.cus.cam.ac.uk 3.717170 1.335914
pesach.jct.ac.il 0.684029 0.921621
pesach.jct.ac.il 0.390263 1.095265
sun1.sara.nl 3.186035 2.325166
sun1.sara.nl 3.053797 3.081236
cocos.fuw.edu.pl 0.154405 0.124795
cocos.fuw.edu.pl 0.120283 0.105825
apple.com 12.588979 12.957880
apple.com 13.861733 12.211125
gorgon.tf.tele.no 1.280217 1.112675
gorgon.tf.tele.no 0.243205 0.631096
kogwy.cc.keio.ac.jp 6.249789 5.075968
kogwy.cc.keio.ac.jp 3.387490 4.583511
exu.inf.puc-rio.br 2.089536 2.233711
exu.inf.puc-rio.br 2.476758 2.249439
inria.inria.fr 0.653974 0.866246
inria.inria.fr 0.739127 1.130521
kum.kaist.ac.kr 1.541682 1.312546
kum.kaist.ac.kr 0.906632 1.042793
sunipc1.labein.es 0.101496 0.091456
sunipc1.labein.es 0.054245 0.101585
目的地Host試nooptは試しに選びます。------------------ ---------- --------- oliver.cs.mcgill.ca1.820014 2.128104oliver.cs.mcgill.ca1.979981 1.866815bertha.cc.und.ac.za0.099289 0.035877bertha.cc.und.ac.za0.118627 0.103763vnet3.vub.ac.be0.368476 0.694463vnet3.vub.ac.be0.443269 0.644050itdsrv1.ul.ie0.721444 0.960068itdsrv1; ul.ie0.713952 0.953275sunic.sunet.se2.989907 2.956766sunic.sunet.se2.100563 2.010292pascal.acm.org2.487185 3.896253pascal.acm.org1.944085 4.269323iti.gov.sg2.401733 2.735445iti.gov.sg2.950990 2.793121rzusuntk.unizh.ch4.094820 3.618023rzusuntk; unizh.ch2.952650 2.245001funet.fi6.703408 5.928008funet.fi7.389722 5.815122odin.diku.dk2.094152 2.450695odin.diku.dk5.362362 4.690722cphkvx.cphk.hk0.092698 0.106880cphkvx.cphk.hk0.496394 0.681994bootes.cus.cam.ac.uk2.632951 2.631322bootes.cus.cam.ac.uk3.717170 1.335914pesach.jct.ac.il0.684029 0.921621pesach.jct.ac.il0.390263 1.095265sun1.sara.nl3.186035 2.325166sun1.sara.nl3.053797 3.081236cocos.fuw.edu.pl0.154405 0.124795cocos.fuw.edu.pl0.120283 0.105825apple.com12.588979 12.957880apple.com13.861733 12.211125gorgon.tf.tele.no1.280217 1.112675gorgon.tf.tele.no0.243205 0.631096kogwy.cc.keio.ac.jp6.249789 5.075968kogwy.cc.keio.ac.jp3.387490 4.583511exu.inf.puc-rio.br2.089536 2.233711exu.inf.puc-rio.br2.476758 2.249439inria.inria.fr0.653974 0.866246inria.inria.fr0.739127 1.130521kum.kaist.ac.kr1.541682 1.312546kum.kaist.ac.kr0.906632 1.042793sunipc1.labein.es0.101496 0.091456sunipc1.labein.es0.054245 0.101585
Wang [Page 14] RFC 1385 EIP November 1992
ワング[14ページ]RFC1385EIP1992年11月
wifosv.wsr.ac.at 1.044443 0.369528
wifosv.wsr.ac.at 0.596935 0.870377
uunet.uu.net 9.530348 8.999789
uunet.uu.net 8.941888 6.075660
infnsun.aquila.infn.it 1.619418 1.569645
infnsun.aquila.infn.it 1.156780 1.158000
muttley.fc.ul.pt 0.353632 0.416126
muttley.fc.ul.pt 0.221522 0.155505
dmssyd.syd.dms.csiro.au 3.433901 3.272839
dmssyd.syd.dms.csiro.au 3.408975 3.130188
hamlet.caltech.edu 5.367756 6.325031
hamlet.caltech.edu 4.828718 5.676571
sztaki.hu 0.301120 0.362481
sztaki.hu 0.253222 0.519892
menvax.restena.lu 0.364221 0.480789
menvax.restena.lu 0.456882 0.580778
nctu.edu.tw 0.246523 1.199412
nctu.edu.tw 0.423476 0.630833
xalapa.lania.mx 0.748642 0.607284
xalapa.lania.mx 0.716781 0.643030
truth.waikato.ac.nz 2.197595 2.072601
truth.waikato.ac.nz 2.489748 2.186684
wifosv.wsr.ac.at1.044443 0.369528wifosv.wsr.ac.at0.596935 0.870377uunet.uu.net9.530348 8.999789uunet.uu.net8.941888 6.075660infnsun.aquila.infn.it1.619418 1.569645infnsun.aquila.infn.it1.156780 1.158000muttley.fc.ul.pt0.353632 0.416126muttley.fc.ul.pt0.221522 0.155505dmssyd.syd.dms.csiro.au3.433901 3.272839dmssyd.syd.dms.csiro.au3.408975 3.130188hamlet.caltech.edu5; 367756 6.325031 hamlet.caltech.edu4.828718 5.676571sztaki.hu0.301120 0.362481sztaki.hu0.253222 0.519892menvax.restena.lu0.364221 0.480789menvax.restena.lu0.456882 0.580778nctu.edu.tw0.246523 1.199412nctu.edu.tw0.423476 0.630833xalapa.lania.mx0.748642 0.607284xalapa.lania.mx0.716781 0.643030truth.waikato.ac.nz2.197595 2.072601truth.waikato.ac.nz2.489748 2.186684
Wang [Page 15] RFC 1385 EIP November 1992
ワング[15ページ]RFC1385EIP1992年11月
Throughput Test from Cam U (cus.cam.ac.uk)
カムUからのスループットテスト(cus.cam.ac.uk)
Destination Host test-noopt test-opt
------------------ ---------- ---------
oliver.cs.mcgill.ca 1.128756 1.285345
oliver.cs.mcgill.ca 1.063096 1.239709
bertha.cc.und.ac.za 0.031218 0.031221
bertha.cc.und.ac.za 0.034405 0.034925
vnet3.vub.ac.be 0.568487 0.731320
vnet3.vub.ac.be 0.558238 0.581415
itdsrv1.ul.ie 1.064302 1.284707
itdsrv1.ul.ie 0.852089 1.025779
sunic.sunet.se 7.179942 6.270326
sunic.sunet.se 5.772485 6.689160
pascal.acm.org 1.661248 1.726725
pascal.acm.org 1.557839 1.428193
iti.gov.sg 0.600616 0.926690
iti.gov.sg 0.772887 0.956636
rzusuntk.unizh.ch 3.645913 4.504969
rzusuntk.unizh.ch 1.853503 2.671272
funet.fi 4.190147 3.421110
funet.fi 2.270988 3.789678
odin.diku.dk 1.361227 0.993901
odin.diku.dk 1.977774 2.415716
cphkvx.cphk.hk 1.173451 1.298421
cphkvx.cphk.hk 1.151376 1.184210
bootes.cus.cam.ac.uk 269.589141 238.920081
bootes.cus.cam.ac.uk 331.203020 293.556436
pesach.jct.ac.il 0.343598 0.492202
pesach.jct.ac.il 0.582809 0.930958
sun1.sara.nl 1.529277 1.470571
sun1.sara.nl 0.896041 0.894923
cocos.fuw.edu.pl 0.131180 0.142239
cocos.fuw.edu.pl 0.137697 0.148895
apple.com 1.330794 0.453590
apple.com 0.856476 0.714661
gorgon.tf.tele.no 0.094793 0.099981
gorgon.tf.tele.no 0.167257 0.151625
kogwy.cc.keio.ac.jp 0.154681 0.178868
kogwy.cc.keio.ac.jp 1.095814 0.871496
exu.inf.puc-rio.br 0.454272 0.384484
exu.inf.puc-rio.br 0.705198 0.690708
inria.inria.fr 0.149511 0.150021
inria.inria.fr 0.071125 0.077257
kum.kaist.ac.kr 0.721184 0.549511
kum.kaist.ac.kr 0.250285 0.296195
sunipc1.labein.es 0.519284 0.491745
sunipc1.labein.es 0.990174 1.009475
目的地Host試nooptは試しに選びます。------------------ ---------- --------- oliver.cs.mcgill.ca1.128756 1.285345oliver.cs.mcgill.ca1.063096 1.239709bertha.cc.und.ac.za0.031218 0.031221bertha.cc.und.ac.za0.034405 0.034925vnet3.vub.ac.be0.568487 0.731320vnet3.vub.ac.be0.558238 0.581415itdsrv1.ul.ie1.064302 1.284707itdsrv1; ul.ie0.852089 1.025779sunic.sunet.se7.179942 6.270326sunic.sunet.se5.772485 6.689160pascal.acm.org1.661248 1.726725pascal.acm.org1.557839 1.428193iti.gov.sg0.600616 0.926690iti.gov.sg0.772887 0.956636rzusuntk.unizh.ch3.645913 4.504969rzusuntk; unizh.ch1.853503 2.671272funet.fi4.190147 3.421110funet.fi2.270988 3.789678odin.diku.dk1.361227 0.993901odin.diku.dk1.977774 2.415716cphkvx.cphk.hk1.173451 1.298421cphkvx.cphk.hk1.151376 1.184210bootes.cus.cam.ac.uk269.589141 238.920081bootes.cus.cam.ac.uk331.203020 293.556436pesach.jct.ac.il0.343598 0.492202pesach.jct.ac.il0.582809 0.930958sun1.sara.nl1.529277 1.470571sun1.sara.nl0.896041 0.894923cocos.fuw.edu.pl0.131180 0.142239cocos.fuw.edu.pl0.137697 0.148895apple.com1.330794 0.453590apple.com0.856476 0.714661gorgon.tf.tele.no0.094793 0.099981gorgon.tf.tele.no0.167257 0.151625kogwy.cc.keio.ac.jp0.154681 0.178868kogwy.cc.keio.ac.jp1.095814 0.871496exu.inf.puc-rio.br0.454272 0.384484exu.inf.puc-rio.br0.705198 0.690708inria.inria.fr0.149511 0.150021inria.inria.fr0.071125 0.077257kum.kaist.ac.kr0.721184 0.549511kum.kaist.ac.kr0.250285 0.296195sunipc1.labein.es0.519284 0.491745sunipc1.labein.es0.990174 1.009475
Wang [Page 16] RFC 1385 EIP November 1992
ワング[16ページ]RFC1385EIP1992年11月
wifosv.wsr.ac.at 0.360751 0.418554
wifosv.wsr.ac.at 0.344268 0.326605
uunet.uu.net 4.247430 3.305592
uunet.uu.net 3.139251 2.945469
infnsun.aquila.infn.it 0.480731 0.782631
infnsun.aquila.infn.it 0.230471 0.292273
muttley.fc.ul.pt 0.239624 0.334286
muttley.fc.ul.pt 0.586156 0.419485
dmssyd.syd.dms.csiro.au 3.630623 3.607504
dmssyd.syd.dms.csiro.au 1.743162 2.994665
hamlet.caltech.edu 5.897946 4.650703
hamlet.caltech.edu 5.118200 5.622022
sztaki.hu 0.338358 0.225206
sztaki.hu 0.113328 0.112637
menvax.restena.lu 0.224967 0.359237
menvax.restena.lu 0.452945 0.472345
nctu.edu.tw 2.549709 2.037245
nctu.edu.tw 2.229093 2.469851
xalapa.lania.mx 0.713586 0.810107
xalapa.lania.mx 0.612278 0.731705
truth.waikato.ac.nz 1.438481 1.993749
truth.waikato.ac.nz 1.325041 1.833999
wifosv.wsr.ac.at0.360751 0.418554wifosv.wsr.ac.at0.344268 0.326605uunet.uu.net4.247430 3.305592uunet.uu.net3.139251 2.945469infnsun.aquila.infn.it0.480731 0.782631infnsun.aquila.infn.it0.230471 0.292273muttley.fc.ul.pt0.239624 0.334286muttley.fc.ul.pt0.586156 0.419485dmssyd.syd.dms.csiro.au3.630623 3.607504dmssyd.syd.dms.csiro.au1.743162 2.994665hamlet.caltech.edu5; 897946 4.650703 hamlet.caltech.edu5.118200 5.622022sztaki.hu0.338358 0.225206sztaki.hu0.113328 0.112637menvax.restena.lu0.224967 0.359237menvax.restena.lu0.452945 0.472345nctu.edu.tw2.549709 2.037245nctu.edu.tw2.229093 2.469851xalapa.lania.mx0.713586 0.810107xalapa.lania.mx0.612278 0.731705truth.waikato.ac.nz1.438481 1.993749truth.waikato.ac.nz1.325041 1.833999
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Zheng Wang Dept of Computer Science University College London London WC1E 6BT, UK
ツェンワングコンピュータサイエンス大学部大学ロンドンロンドンWC1E 6BT、イギリス
EMail: z.wang@cs.ucl.ac.uk
メール: z.wang@cs.ucl.ac.uk
Wang [Page 17]
ワング[17ページ]
一覧
スポンサーリンク
