RFC1454 日本語訳
1454 Comparison of Proposals for Next Version of IP. T. Dixon. May 1993. (Format: TXT=35064 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Dixon
Request for Comments: 1454 RARE
May 1993
コメントを求めるワーキンググループT.ディクソン要求をネットワークでつないでください: 1454 まれな1993年5月
Comparison of Proposals for Next Version of IP
IPの次のバージョンのための提案の比較
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.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This is a slightly edited reprint of RARE Technical Report (RTC(93)004).
これはRARE Technical Report(RTC(93)004)のわずかに編集された増刷です。
The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated by RARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting in Washington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated. Note that for a time the term "IPv7" was use to mean the eventual next version of IP, but that the same term was closely associated with a particilar proposal, so the term "IPng" is now used to identify the eventual next generation of IP.
↓これは現在のインターネットプロトコルを置き換えるための3つの主な提案の特性の簡潔な概要です。 徹底的であるか、または決定的であることを(終わりの簡潔な図書目録は詳しい情報の源を示します)意図するのではなく、それは、RAREとRIPEによって調整されるようにこれらの提案についてのヨーロッパの議論に入力されるように役立つように意図します。 提案が自分たちで「移動標的」であると認められるべきであり、この紙が全く正確である限り、それはワシントン(DC)における25番目のIETFミーティングで位置を反映します。 オリジナルの草稿でのロスCallonとポールTsuchiyaからのコメントは法人組織でした。 「IPv7"はIPの次の最後のバージョンを意味する使用でしたが、同じ用語が密接にparticilar提案に関連づけられたので、存在という用語"IPng"は今や、以前はよくIPの最後の次世代を特定した」用語のときに時間、それに注意してください。
The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually.
紙は問題を解決して、特定の目標を達成するためにメカニズムの「一般的な」議論で始まります、inviduallyに提案について議論する前に。
1. WHY IS THE CURRENT IP INADEQUATE?
1. 現在のIPはなぜ不十分ですか?
The problem has been investigated and formulated by the ROAD group, but briefly reduces to the following:
問題は、ROADグループによって調査されて、定式化されましたが、簡潔に以下に減少します:
- Exhaustion of IP Class B Address Space.
- IPクラスBアドレス空間の疲労困憊。
- Exhaustion of IP Address Space in General.
- 一般に、IPアドレス空間の疲労困憊。
- Non-hierarchical nature of address allocation leading to flat
routing space.
- 平坦なルーティングスペースにつながるアドレス配分の非階層的な本質。
Dixon [Page 1] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[1ページ]RFC1454比較
Although the IESG requirements for a new Internet Protocol go further than simply routing and addressing issues, it is these issues that make extension of the current protocol an impractical option. Consequently, most of the discussion and development of the various proposed protocols has concentrated on these specific problems.
新しいインターネットプロトコルのためのIESG要件は単に問題を発送して、記述するより遠くに行きますが、それは現在のプロトコルの拡大を非実用的なオプションにするこれらの問題です。 その結果、様々な提案されたプロトコルの議論と開発の大部分はこれらの特定の問題に集中しました。
Near term remedies for these problems include the CIDR proposals (which permit the aggregation of Class C networks for routing purposes) and assignment policies which will allocate Class C network numbers in a fashion which CIDR can take advantage of. Routing protocols supporting CIDR are OSPF and BGP4. None of these are pre- requisites for the new IP (IPng), but are necessary to prolong the life of the current Internet long enough to work on longer-term solutions. Ross Callon points out that there are other options for prolonging the life of IP and that some ideas have been distributed on the TUBA list.
これらの問題のための短期間療法はCIDR提案(ルーティング目的のためにClass Cネットワークの集合を可能にする)とCIDRが利用できるファッションでClass Cにネットワーク・ナンバーを割り当てる課題方針を含んでいます。 CIDRを支持するルーティング・プロトコルは、OSPFとBGP4です。 これらのいずれも、新しいIP(IPng)のためのプレ必需品ですが、より長い期間ソリューションに取り組むために十分長い現在のインターネットの人生を長引かせるのに必要ではありません。 ロスCallonは、IPの人生を長引かせるための別の選択肢があって、いくつかの考えがTUBAリストで分配されたと指摘します。
Longer term proposals are being sought which ultimately allow for further growth of the Internet. The timescale for considering these proposals is as follows:
結局インターネットのさらなる成長を考慮するより長い用語提案が求められています。 これらの提案を検討するためのスケールは以下の通りです:
- Dec 15 Issue selection criteria as RFC.
- RFCとしての12月15日のIssue選択評価基準。
- Feb 12 Two interoperable implementations available.
- 利用可能な2月12日のTwo共同利用できる実現。
- Feb 26 Second draft of proposal documents available.
- 提案ドキュメントの利用可能な2月26日のSecond草稿。
The (ambitious) target is for a decision to be made at the 26th IETF (Columbus, Ohio in March 1993) on which proposals to pursue.
(野心満々)の目標は第26IETF(1993年3月のコロンブス(オハイオ))でどの提案を追求したらよいかに関して作られているという決定のためのものです。
The current likely candidates for selection are:
選択の現在のありそうな候補は以下の通りです。
- PIP ('P' Internet Protocol - an entirely new protocol).
- PIP('P'インターネットプロトコル--完全に新しいプロトコル)。
- TUBA (TCP/UDP with Big Addresses - uses ISO CLNP).
- TUBA(Big AddressesとTCP/UDP--用途ISO CLNP)。
- SIP (Simple IP - IP with larger addresses and fewer options).
- SIP(簡単なIP--より大きいアドレスと、より少ないオプションがあるIP)。
There is a further proposal from Robert Ullman of which I don't claim to have much knowledge. Associated with each of the candidates are transition plans, but these are largely independent of the protocol itself and contain elements which could be adopted separately, even with IP v4, to further extend the life of current implementations and systems.
私が多くの知識を持っていると主張しないロバート・ウルマンからのさらなる提案があります。 候補各人に関連づけられているのが、変遷プランですが、これらは、さらに現在の実現とシステムの人生を伸ばすために、プロトコル自体から主に独立していて、別々に、IP v4があっても採用できた要素を含んでいます。
Dixon [Page 2] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[2ページ]RFC1454比較
2. WHAT THE PROPOSALS HAVE IN COMMON
2. 提案が共通であること
2.1 Larger Addresses
2.1 より大きいアドレス
All the proposals (of course) make provision for larger address fields which not only increase the number of addressable systems, but also permit the hierarchical allocation of addresses to facilitate route aggregation.
すべての提案が(もちろん)アドレス可能なシステムの数を増加させるだけではなく、アドレスの階層的な配分がルート集合を容易にすることを許可もするより大きいアドレス・フィールドに備えます。
2.2 Philosophy
2.2 哲学
The proposals also originate from a "routing implementation" view of the world - that is to say they focus on the internals of routing within the network and do not primarily look at the network service seen by the end-user, or by applications. This is perhaps inevitable, especially given the tight time constraints for producing interoperable implementations. However, the (few) representatives of real users at the 25th IETF, the people whose support is ultimately necessary to deploy new host implementations, were distinctly unhappy.
また、提案は「ルーティング実現」世界観から発します--すなわち、それらは、ネットワークの中でルーティングのインターナルに焦点を合わせて、主としてエンドユーザ、またはアプリケーションで見られたネットワーク・サービスを見ません。 共同利用できる実現を起こすきつい時間規制を特に考えて、これは恐らく必然です。 しかしながら、第25IETFのリアル・ユーザの(わずか)の代表(サポートが結局新しいホスト導入を配備するのに必要である人々)が明瞭に不幸でした。
There is an inbuilt assumption in the proposals that IPng is intended to be a universal protocol: that is, that the same network- layer protocol will be used between hosts on the same LAN, between hosts and routers, between routers in the same domain, and between routers in different domains. There are some advantages in defining separate "access" and "long-haul" protocols, and this is not precluded by the requirements. However, despite the few opportunities for major change of this sort within the Internet, the need for speed of development and low risk have led to the proposals being incremental, rather than radical, changes to well-proven existing technology.
IPngが普遍的なプロトコルであることを意図するという提案におけるinbuilt仮定があります: すなわち、そんなに同じネットワーク層のプロトコルは同じLANでホストの間で使用されるでしょう、ホストとルータの間で、同じドメインと、異なったドメインのルータの間のルータの間で。 別々の「アクセス」と「長期」プロトコルを定義するのにおいていくつかの利点があります、そして、これは要件によって排除されません。 しかしながら、少佐のわずかな機会にもかかわらず、インターネットの中のこの種類の変化、開発と低リスクの速度の必要性は増加であることが急進論者よりむしろよく立証された既存の技術に変化するという提案につながりました。
There is a further unstated assumption that the architecture is targeted at the singly-connected host. It is currently difficult to design IPv4 networks which permit hosts with more than one interface to benefit from increased bandwidth and reliability compared with singly-connected hosts (a consequence of the address belonging to the interface and not the host). It would be preferable if topological constraints such as these were documented. It has been asserted that this is not necessarily a constraint of either the PIP or TUBA proposals, but I believe it is an issue that has not emerged so far amongst the comparative criteria.
構造が単独で接続されたホストをターゲットにするというさらなる非論述された仮定があります。 1つ以上のインタフェースをもっているホストが単独で接続されたホスト(アドレスがホストではなく、インタフェースに属す結果)と比べて増加する帯域幅と信頼性の利益を得ることを許可するIPv4ネットワークを設計するのは現在、難しいです。 これらなどの位相的な規制が記録されるなら、望ましいでしょうに。 これが必ずPIPかTUBA提案の規制であるというわけではないと断言されましたが、私は、それが今までのところ比較評価基準の中に現れていない問題であると信じています。
Dixon [Page 3] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[3ページ]RFC1454比較
2.3 Source Routing
2.3 ソースルート設定
The existing IPv4 has provision for source-specified routes, though this is little used [would someone like to contradict me here?], partly because it requires knowledge of the internal structure of the network down to the router level. Source routes are usually required by users when there are policy requirements which make it preferable or imperative that traffic between a source and destination should pass through particular administrative domains. Source routes can also be used by routers within administrative domains to route via particular logical topologies. Source-specified routing requires a number of distinct components:
既存のIPv4には、ソースによって指定されたルートへの支給があります、これは少ししか使用されませんが[だれかがここで私に逆らいたがっていますか?]、一部ネットワークの内部の構造に関する知識をルータレベルまで必要とするので。 ソースと目的地の間の交通が特定の管理ドメインを通り抜けるべきであるのを望ましいか必須にする方針要件があるとき、通常、送信元経路はユーザによって必要とされます。 また、ルータは特定の論理的なtopologiesを通して発送する管理ドメインの中で送信元経路を使用できます。 ソースによって指定されたルーティングは多くの異なったコンポーネントを必要とします:
a. The specification by the source of the policy by which the
route should be selected.
a。 ルートが選択されるべきである方針の源による仕様。
b. The selection of a route appropriate to the policy.
b。 方針に適切なルートの選択。
c. Marking traffic with the identified route.
c。 特定されたルートを交通に付けます。
d. Routing marked traffic accordingly.
d。 ルート設定はそれに従って、交通を示しました。
These steps are not wholly independent. The way in which routes are identified in step (c) may constrain the kinds of route which can be selected in previous steps. The destination, inevitably, participates in the specification of source routes either by advertising the policies it is prepared to accept or, conceivably, by a negotiation process.
これらのステップは完全に独立していません。 ルートがステップ(c)で特定される方法は前のステップで選択できるルートの種類を抑制するかもしれません。 それが受け入れるように準備される方針の広告を出すか、多分交渉工程で目的地は必然的に送信元経路の仕様に参加します。
All of the proposals mark source routes by adding a chain of (perhaps partially-specified) intermediate addresses to each packet. None specifies the process by which a host might acquire the information needed to specify these intermediate addresses [not entirely unreasonably at this stage, but further information is expected]. The negative consequences of these decisions are:
提案のすべてが、(恐らく部分的に指定される)の中間的アドレスのチェーンを各パケットに加えることによって、送信元経路をマークします。 なにもホストがこれらの中間的アドレスを指定するのに必要である情報を取得するかもしれない過程を指定しません[無分別に完全に現在のところないときに、詳細だけが予想されます]。 これらの決定の否定的結果は以下の通りです。
- Packet headers can become quite long, depending on the number of
intermediate addresses that must be specified (although there are
mechanisms which are currently specified or which can be imagined
to specify only the significant portions of intermediate addresses).
- パケットのヘッダーはかなり長くなることができます、指定しなければならない中間的アドレスの数によって(現在、指定するか、または中間的アドレスの重要な部分だけを指定すると想像できるメカニズムがありますが)。
- The source route may have to be re-specified periodically if
particular intermediate addresses are no longer reachable.
- 特定の中間的アドレスがもう届かないなら、送信元経路は定期的に再指定されていなければならないかもしれません。
The positive consequences are:
肯定的結果は以下の通りです。
- Inter-domain routers do not have to understand policies, they
simply have to mechanically follow the source route.
- 相互ドメインルータは方針を理解する必要はなくて、それらは単に機械的に送信元経路に従わなければなりません。
Dixon [Page 4] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[4ページ]RFC1454比較
- Routers do not have to store context identifying routes, since
the information is specified in each packet header.
- ルータは情報が各パケットのヘッダーで指定されるのでルートを特定する文脈を格納する必要はありません。
- Route servers can be located anywhere in the network, provided
the hosts know how to find them.
- ホストが彼らを見つける方法を知っているなら、ルートサーバはネットワークでどこでも位置できます。
2.4 Encapsulation
2.4 カプセル化
Encapsulation is the ability to enclose a network-layer packet within another one so that the actual packet can be directed via a path it would not otherwise take to a router that can remove the outermost packet and direct the resultant packet to its destination. Encapsulation requires:
カプセル化はそうでなければそれが一番はずれのパケットを移して、結果のパケットを目的地に向けることができるルータに取らない経路を通して実際のパケットを指示できるように別の1つの中にネットワーク層パケットを同封する能力です。 カプセル化は以下を必要とします。
a. An indication in the packet that it contains another packet.
a。 別のパケットを含んでいるというパケットの指示。
b. A function in routers which, on receiving such a packet,
removes the encapsulation and re-enters the forwarding process.
b。 ルータにおけるそのようなパケットを受けるときカプセル化を取り除いて、推進の過程に再入する機能。
All the proposals support encapsulation. Note that it is possible to achieve the effect of source routing by suitable encapsulation by the source.
すべての提案がカプセル化を支持します。 ソースによる適当なカプセル化でソースルーティングの効果を達成するのが可能であることに注意してください。
2.5 Multicast
2.5 マルチキャスト
The specification of addresses to permit multicast with various scopes can be accomodated by all the proposals. Internet-wide multicast is, of course, for further study!
すべての提案で様々な範囲でマルチキャストを可能にするアドレスの仕様をaccomodatedされることができます。 さらなる研究にはインターネット全体のマルチキャストがもちろんあります!
2.6 Fragmentation
2.6 断片化
All the proposals support the fragmentation of packets by intermediate routers, though there has been some recent discussion of removing this mechanism from some of the proposals and requiring the use of an MTU-discovery process to avoid the need for fragmentation. Such a decision would effectively preclude the use of transport protocols which use message-count sequence numbering (such as OSI Transport) over the network, as only protocols with byte-count acknowledgement (such as TCP) can deal with MTU reductions during the lifetime of a connection. OSI Transport may not be particularly relevant to the IP community (though it may be of relevance to commercial suppliers providing multiprotocol services), however the consequences for the types of services which may be supported over IPng should be noted.
すべての提案が中間的ルータでパケットの断片化を支持します、断片化の必要性を避けるために提案のいくつかからこのメカニズムを取り外して、MTU-発見の過程の使用を必要とする何らかの最近の議論がありましたが。 事実上、そのような決定はネットワークに関してメッセージカウント系列付番を使用するトランスポート・プロトコル(OSI Transportなどの)の使用を排除するでしょう、バイト・カウント承認(TCPなどの)がある唯一のプロトコルが接続の生涯MTU減少に対処できるとき。 OSI Transportが特にIP共同体に関連していないかもしれない(それは「マルチ-プロトコル」サービスを提供する商業供給者への関連性のものであるかもしれませんが)、しかしながら、IPngの上で支持されるかもしれないサービスのタイプのための結果は注意されるべきです。
Dixon [Page 5] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[5ページ]RFC1454比較
2.7 The End of Lifetime as We Know It
2.7私たちがそれを知っているような生涯の終わり
The old IPv4 "Time to Live" field has been recast in every case as a simple hop count, largely on grounds of implementation convenience. Although the old TTL was largely implemented in this fashion anyway, it did serve an architectural purpose in putting an upper bound on the lifetime of a packet in the network. If this field is recast as a hop-count, there must be some other specification of the maximum lifetime of a packet in the network so that a source host can ensure that network-layer fragment ids and transport-layer sequence numbers are never in danger of re-use whilst there is a danger of confusion. There are, in fact, three separate issues here:
「生きる時間」古いIPv4分野はあらゆる場合に簡単なホップカウントで、主にオンであるとして実現便利の根拠を書き直すことです。 古いTTLはこんなやり方でとにかく主に実行されましたが、それはパケットの生涯に上限を置く際に建築目的にネットワークに役立ちました。 この分野がaとしてホップカウントを書き直すことであるなら、ネットワークにはパケットの最大の生涯のある他の仕様が、送信元ホストが、混乱という危険がありますが、ネットワーク層断片イドとトランスポート層一連番号では再使用という危険は決してないのを保証できるように、あるに違いありません。 事実上、3つの別個問題がここにあります:
1. Terminating routing loops (solved by hop count).
1. ルーティングを終えるのは輪にされます(ホップカウントで、解決されています)。
2. Bounding lifetime of network-layer packets (a necessity,
unspecified so far) to support assumptions by the transport
layer.
2. トランスポート層で仮定を支持するネットワーク層パケット(今までのところ不特定の必要性)の制限生涯。
3. Permitting the source to place further restrictions on packet
lifetime (for example so that "old" real-time traffic can be
discarded in favour of new traffic in the case of congestion
(an optional feature, unspecified so far).
3. ソースが入賞することを許可するのがパケット生存期間に制限を促進します。(混雑(今までのところ不特定のオプション機能)の場合における新しい交通を支持してリアルタイムのしたがって、そんなに「古い」例えば、交通は捨てることができます。
3. WHAT THE PROPOSALS ONLY HINT AT
3. 提案がほのめかすだけであること
3.1 Resource Reservation
3.1 資源予約
Increasingly, applications require a certain bandwidth or transit delay if they are to be at all useful (for example, real-time video and audio transport). Such applications need procedures to indicate their requirements to the network and to have the required resources reserved. This process is in some ways analogous to the selection of a source route:
ますます、少しでも役に立つつもりであるなら(例えば、レアルタイムビデオとオーディオの輸送)、アプリケーションはある一定の帯域幅かトランジット遅れを必要とします。 そのようなアプリケーションは、それらの要件をネットワークに示して、必要なリソースを予約させるために手順を必要とします。 この過程はある点では送信元経路の選択に類似しています:
a. The specification by the source of its requirements.
a。 要件の源による仕様。
b. The confirmation that the requirements can be met.
b。 確認、必要条件を満たすことができます。
c. Marking traffic with the requirement.
c。 要件を交通に付けます。
d. Routing marked traffic accordingly.
d。 ルート設定はそれに従って、交通を示しました。
Traffic which is routed according to the same set of resource requirements is sometimes called a "flow". The identification of flows requires a setup process, and it is tempting to suppose that the same process might also be used to set up source routes, however, there are a number of differences:
同じセットのリソース要件に応じて発送される交通は時々「流れ」と呼ばれます。 流れの識別はセットアップの過程を必要とします、そして、また、同じ過程が送信元経路をセットアップするのに使用されるかもしれないと思うのに誘惑しています、そして、しかしながら、多くの違いがあります:
Dixon [Page 6] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[6ページ]RFC1454比較
- All the routers on a path must participate in resource
reservation and agree to it.
- 経路のすべてのルータが、資源予約に参加して、それに同意しなければなりません。
- Consequently, it is relatively straightforward to maintain
context in each router and the identification for flows can be
short.
- その結果、各ルータにおける背景と流れのための識別が短い場合があると主張するのは比較的簡単です。
- The network can choose to reroute on failure.
- ネットワークは、失敗でコースを変更するのを選ぶことができます。
By various means, each proposal could carry flow-identification, though this is very much "for future study" at present. No setup mechansisms are defined. The process for actually reserving the resources is a higher-order problem. The interaction between source- routing and resource reservation needs further investigation: although the two are distinct and have different implementation constraints, the consequence of having two different mechanisms could be that it becomes difficult to select routes which meet both policy and performance goals.
あの手この手で、各提案は、現在のところこれがたいへん「今後の研究」であるので、流れ識別を運ぶかもしれません。 セットアップmechansismsは全く定義されません。 実際にリソースを予約するための過程は高次な問題です。 ソースルーティングと資源予約との相互作用はさらなる調査を必要とします: 2は、異なって、異なった実現規制を持っていますが、2つの異なったメカニズムを持つ結果は方針と性能目標の両方を満たすルートを選択するのが難しくなるということであるかもしれません。
3.2 Address-Assignment Policies
3.2 アドレス課題方針
In IPv4, addresses were bound to systems on a long-term basis and in many cases could be used interchangeably with DNS names. It is tacitly accepted that the association of an address with a particular system may be more volatile in IPng. Indeed, one of the proposals, PIP, makes a distinction between the identification of a system (a fixed quantity) and its address, and permits the binding to be altered on the fly. None of the proposals defines bounds for the lifetime of addresses, and the manner in which addresses are assigned is not necessarily bound to a particular proposal. For example, within the larger address space to be provided by IPng, there is a choice to be made of assigning the "higher order" part of the hierarchical address in a geographically-related fashion or by reference to service provider. Geographically-based addresses can be constant and easy to assign, but represent a renewed danger of degeneration to "flat" addresses within the region of assignment, unless certain topological restrictions are assumed. Provider-based address assignment results in a change of address (if providers are changed) or multiple addresses (if multiple providers are used). Mobile hosts (depending on the underlying technology) can present problems in both geographic and provider-based schemes.
IPv4では、アドレスを長期的にはシステムに縛って、多くの場合、DNS名と共に互換性を持って使用できました。 暗に、IPngでは、特定のシステムがあるアドレスの協会が、より不安定であるかもしれないと受け入れます。 本当に、提案のひとり(PIP)はシステム(定量)の識別とそのアドレスの間で区別をして、結合が急いで変更されることを許可します。 提案のいずれもアドレスの生涯と領域を定義しません、そして、アドレスが割り当てられる方法は必ず特定の提案に縛られるというわけではありません。 例えば、IPngによって提供されるより大きいアドレス空間の中に地理的に関連のファッションかサービスプロバイダーの参照で階層的なアドレスの「より高いオーダー」部分を割り当てることでされる選択があります。 地理的にベースのアドレスは、一定であって、割り当てるのは簡単である場合がありますが、課題の領域の中の「平坦な」アドレスに堕落という更新された危険を表してください、ある位相的な制限が想定されない場合。 プロバイダーベースのアドレス課題は住所の変更(プロバイダーを変えるなら)か複数のアドレスをもたらします(複数のプロバイダーが使用されているなら)。 モバイルホスト(基本的な技術によります)は地理的なものと同様にプロバイダーベースの計画における問題を提示できます。
Without firm proposals for address-assignment schemes and the consequences for likely address lifetimes, it is impossible to assume that the existing DNS model by which name-to-address bindings can be discovered remains valid.
アドレス課題計画とありそうなアドレスのための結果のための生涯であり、それが不可能であるという堅い提案がなければ、それを仮定するために、名前からアドレス結合を発見できる既存のDNSモデルは有効なままで残っています。
Dixon [Page 7] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[7ページ]RFC1454比較
Note that there is an interaction between the mechanism for assignment of addresses and way in which automatic configuration may be deployed.
アドレスの課題のためのメカニズムとずっとどの自動構成に相互作用があるかというメモは配備されるかもしれません。
3.3 Automatic Configuration
3.3 自動構成
Amongst the biggest (user) bugbears of current IP services is the administrative effort of maintaining basic configuration information, such as assigning names and addresses to hosts, ensuring these are refelected in the DNS, and keeping this information correct. Part of this results from poor implementation (or the blind belief that vi and awk are network management tools). However, a lot of the problems could be alleviated by making this process more automatic. Some of the possibilities (some mutually-exlusive) are:
最も大きい(ユーザ)の中では、IPが修理する電流の恐怖の原因は基本の設定情報を維持する管理努力です、名前とアドレスをホストに割り当てるのなどように、DNSでrefelectedされて、この情報を正しく保ちながらこれらを確実にして。 この一部が不十分な実現(または、viとawkがネットワークマネージメントツールであるという盲目の信念)から生じます。 しかしながら、この過程をより自動にすることによって、多くの問題を軽減できるでしょう。 可能性(或るものは互いにexlusiveされる)のいくつかは以下の通りです。
- Assigning host addresses from some (relative) invariant, such
as a LAN address.
- LANアドレスなどの何らかの(相対的)の不変式からのホスト・アドレスを割り当てます。
- Defining a protocol for dynamic assignment of addresses within a
subnetwork.
- アドレスのダイナミックな課題のためにサブネットワークの中でプロトコルを定義します。
- Defining "generic addresses" by which hosts can without
preconfiguration reach necessary local servers (DNS, route
servers, etc.).
- どのホストで「一般的なアドレス」を定義するかは前構成なしで必要なローカルサーバ(DNS、ルートサーバなど)に達することができます。
- Have hosts determine their name by DNS lookup.
- ホストにDNSルックアップで彼らの名前を決定させてください。
- Have hosts update their name/address bindings when their
configuration changes.
- それらの構成が変化したら、ホストに彼らの名前/アドレス結合をアップデートさせてください。
Whilst a number of the proposals make mention of some of these possibilities, the choice of appropriate solutions depends to some extent on address-assignment policies. Also, dynamic configuration results in some difficult philosopical and practical issues (what exactly is the role of an address?, In what sense is a host "the same host" when its address changes?, How do you handle dynamic changes to DNS mappings and how do you authenticate them?).
多くの提案がこれらの可能性のいくつかについて言及しますが、適切な解決策のこの選択はある程度、アドレス課題方針次第です。 また、動的設定がいくつかの難しいphilosopicalと実用的な問題をもたらす、(いったい何、In、アドレスの役割がそうであるか、アドレスが変化するとき、ホストが「同じホスト」であるという何という感覚(HowはDNSマッピングへのハンドルのダイナミックな変化をあなたにして、あなたはどのようにそれらを認証するか))
The groups involved in the proposals would, I think, see most of these questions outside their scope. It would seem to be a failure in the process of defining and selecting candidates for IPng that "systemness" issues like these will probably not be much discussed. This is recognised by the participants, and it is likely that, even when a decision is made, some of these ideas will be revisited by a wider audience.
私は、提案にかかわるグループがそれらの範囲の外でこれらの質問の大部分を見ると思います。 それはたぶんあまりこれらについて議論しないように、"システム"が発行するIPngの候補を定義して、選ぶことの途中に失敗であるように思えるでしょう。 関係者はこれを認識します、そして、決定をしさえするとき、より広い聴衆はこれらの考えのいくつかを再訪させそうでしょう。
It is, however, unlikely that IP will make an impact on proprietary networking systems for the non-technical environment (e.g., Netware,
しかしながら、IPが非技術系の環境の独占ネットワークシステムの上で衝撃を与えるのが、ありそうもない、(例えば、Netware
Dixon [Page 8] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[8ページ]RFC1454比較
Appletalk), without automatic configuration being taken seriously either in the architecture, or by suppliers. I believe that there are ideas on people's heads of how to address these issues - they simply have not made it onto paper yet.
Appletalk)、構造、または供給者によって自動構成なしで真剣に取られます。 私は、どうこれらの問題を記述するかに関する人々の頭に関する考えがあると信じています--それらはまだそれを紙に絶対にしていません。
3.4 Application Interface/Application Protocol Changes
3.4 HTTPサーバとNETSCAPE間のインタフェース/アプリケーション・プロトコル変化
A number of common application protocols (FTP, RPC, etc.) have been identified which specifically transfer 32-bit IPv4 addresses, and there are doubtless others, both standard and proprietary. There are also many applications which treat IPv4 addresses as simple 32-bit integers. Even applications which use BSD sockets and try to handle addresses opaquely will not understand how to parse or print longer addresses (even if the socket structure is big enough to accommodate them).
多くの一般的なアプリケーション・プロトコル(FTP、RPCなど)が特定されました、そして、(明確に32ビットのIPv4アドレスを移します)標準のものと同様に独占である他のものが確かにいます。 また、簡単な32ビットの整数としてIPv4アドレスを扱う多くの利用があります。 BSDソケットを使用して、アドレスを扱おうとするアプリケーションさえ、より長いアドレスを分析するか、または印刷する方法を不透明に理解しないでしょう(ソケット構造がそれらを収容できるくらい大きくても)。
Each proposal, therefore, needs to specify mechanisms to permit existing applications and interfaces to operate in the new environment whilst conversion takes place. It would be useful also, to have (one) specification of a reference programming interface for (TCP and) IPng (which would also operate on IPv4), to allow developers to begin changing applications now. All the proposals specify transition mechansisms from which existing application- compatibility can be inferred. There is no sign yet of a new interface specification independent of chosen protocol.
したがって、各提案は、変換が行われている間、既存のアプリケーションとインタフェースが新しい環境で作動することを許可するためにメカニズムを指定する必要があります。 そして、また、それもプログラミングが連結する参照の(ある)の仕様を持つために役に立つだろう、(TCP、)、IPng(また、IPv4を作動させる)、開発者が現在アプリケーションを変え始めるのを許容するために。 すべての提案が既存のアプリケーションの互換性を推論できる変遷mechansismsを指定します。 選ばれたプロトコルの如何にかかわらずまだ新しいインターフェース仕様のサインが全くありません。
3.5 DNS Changes
3.5DNSが変化します。
It is obvious that there has to be a name to address mapping service which supports the new, longer, addresses. All the proposals assume that this service will be provided by DNS, with some suitably-defined new resource record. There is some discussion ongoing about the appropriateness of returning this information along with "A" record information in response to certain enquiries, and which information should be requested first. There is a potential tradeoff between the number of queries needed to establish the correct address to use and the potential for breaking existing implementations by returning information that they do not expect.
新しくて、より長いアドレスをサポートするサービスを写像する記述する名前がなければならないのは、明白です。 すべての提案が、このサービスがDNSによって何らかの適当に定義された新しいリソース記録に提供されると仮定します。 記録的な情報と共にある調査に対応してこの情報を返す適切さとどの情報が最初に要求されるべきであるかに関する進行中の何らかの議論があります。 使用する正しいアドレスを確立するのに必要である質問の数と壊れている既存の実現の可能性の間の彼らが予想しない返品情報による潜在的見返りがあります。
There has been heat, but not light, generated by discussion of the use of DNS for auto-configuration and the scaling (or otherwise) of reverse translations for certain addressing schemes.
光ではなく、計画を記述しながらDNSの自動構成の使用と逆の翻訳のスケーリング(そうでなければ)の議論で確かに発生する熱がありました。
Dixon [Page 9] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[9ページ]RFC1454比較
4. WHAT THE PROPOSALS DON'T REALLY MENTION
4. 提案が本当に言及しないこと
4.1 Congestion Avoidance
4.1 輻輳回避
IPv4 offers "Source Quench" control messages which may be used by routers to indicate to a source that it is congested and has or may shortly drop packets. TUBA/PIP have a "congestion encountered" bit which provides similar information to the destination. None of these specifications offers detailed instructions on how to use these facilities. However, there has been a substantial body of analysis over recent years that suggests that such facilities can be used (by providing information to the transport protocol) not only to signal congestion, but also to minimise delay through the network layer. Each proposal can offer some form of congestion signalling, but none specifies a mechanism for its use (or an analysis of whether the mechanism is in fact useful).
IPv4はパケットをルータによって使用されて、それが混雑しているのをソースに示して、持つか、またはまもなく落とすかもしれない「ソース焼き入れ」コントロールメッセージを提供します。 TUBA/PIPには、同様の情報を目的地に提供する「遭遇する混雑」ビットがあります。 これらの仕様申し出のいずれもどうこれらの施設を使用するかに関する指示を詳しく述べませんでした。 しかしながら、近年の間の単に混雑に合図するのではなく、ネットワーク層を通して遅れを最小とならせもするのにそのような施設を使用できるのを(情報をトランスポート・プロトコルに提供することによって)示す分析のかなりのボディーがありました。 各提案は何らかのフォームの混雑合図を提供できますが、使用(または、事実上、メカニズムが役に立つかどうかに関する分析)にメカニズムをなにも指定しません。
As a user of a network service which currently has a discard rate of around 30% and a round-trip-time of up to 2 seconds for a distance of only 500 miles I would be most interested in some proposals for a more graceful degradation of the network service under excess load.
破棄が現在評価するおよそ30%のネットワーク・サービスのユーザと500マイルだけの距離への最大2秒の往復の時間として、余分な負荷の下で私はネットワーク・サービスの、より優雅な退行のためのいくつかの提案に最も興味を持っているでしょう。
4.2 Mobile Hosts
4.2 モバイルホスト
A characteristic of mobile hosts is that they (relatively) rapidly move their physical location and point of attachment to the network topology. This obviously has signficance for addressing (whether geographical or topological) and routing. There seems to be an understanding of the problem, but so far no detailed specification of a solution.
モバイルホストの特性がそれである、彼ら、(比較的、)、急速に彼らの物理的な位置と接着点をネットワーク形態に動かしてください。 これには、アドレシング(地理的であるか、または位相的であることにかかわらず)とルーティングのためのsignficanceが明らかにあります。 解決策の問題の、しかし、そのように詳しく詳しく述べられなかった仕様の理解はあるように思えます。
4.3 Accounting
4.3 会計
The IESG selection criteria require only that proposals do not have the effect of preventing the collection of information that may be of interest for audit or billing purposes. Consequently, none of the proposals consider potential accounting mechanisms.
IESG選択評価基準は、提案には監査か支払い目的のために興味があるかもしれない情報の収集を防ぐという効果があるだけではないのを必要とします。 その結果、提案のいずれも潜在的会計機構を考えません。
4.4 Security
4.4 セキュリティ
"Network Layer Security Issues are For Further Study". Or secret.
「ネットワークLayer Security IssuesはFor Further Studyです。」 または、秘密です。
However, it would be useful to have it demonstrated that each candidate could be extended to provide a level of security, for example against address-spoofing. This will be particularly important if resource-allocation features will permit certain hosts to claim large chunks of available bandwidth for specialised applications.
しかしながら、セキュリティのレベルを提供するために各候補者を広げることができたのを示させるのは役に立つでしょう、例えば、アドレススプーフィングに対して。 資源配分機能が、確信しているホストが利用可能な帯域幅の大きい塊の専門化しているアプリケーションに代金を請求するのを許容するなら、これは特に重要になるでしょう。
Dixon [Page 10] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[10ページ]RFC1454比較
Note that providing some level of security implies manual configuration of security information within the network and must be considered in relationship to auto-configuration goals.
何らかのレベルのセキュリティを提供するのをネットワークの中でセキュリティ情報の手動の構成を含意して、自動構成目標との関係で考えなければならないことに注意してください。
5. WHAT MAKES THE PROPOSALS DIFFERENT?
5. 何が提案を異なるようにしますか?
Each proposal is about as different to the others as it is to IPv4 - that is the differences are small in principle, but may have significant effects (extending the size of addresses is only a small difference in principle!). The main distinct characteristics are:
他のものにとって、それぞれの提案はIPv4にはそれがあるのとほぼ同じくらい異なっています--すなわち、違いでは、原則として小さいのですが、重要な効果があるかもしれません(アドレスのサイズを広げるのが、原則として小さい違いにすぎません!)。 主なはっきりした性格は以下の通りです。
PIP:
種:
PIP has an innovative header format that facilitates hierarchical,
policy and virtual-circuit routing. It also has "opaque" fields in
the header whose semantics can be defined differently in different
administrative domains and whose use and translation can be
negotiated across domain boundaries. No control protocol is yet
specified.
PIPには、階層的な方針と仮想のサーキットルーティングを容易にする革新的なヘッダー形式があります。 また、それは異なった管理ドメインで意味論を異なって定義できて、ドメイン境界の向こう側に使用と翻訳を交渉できるヘッダーに「不透明な」分野を持っています。 制御プロトコルは全くまだ指定されていません。
SIP:
一口:
SIP offers a "minimalist" approach - removing all little-used
fields from the IPv4 header and extending the size of addresses to
(only) 64 bits. The control protocol is based on modifications to
ICMP. This proposal has the advantages of processing efficiency
and familiarity.
SIPは「ミニマリスト」アプローチを提供します--すべてを取り除くのは少ししかIPv4ヘッダーとアドレスのサイズを広げるのからの(単に)64ビットへの分野を使用しませんでした。 制御プロトコルはICMPへの変更に基づいています。 この提案には、処理効率と親しみの利点があります。
TUBA:
チューバ:
TUBA is based on CLNP (ISO 8473) and the ES-IS (ISO 9542) control
protocol. TUBA provides for the operation of TCP transport and UDP
over a CLNP network. The main arguments in favour of TUBA are that
routers already exist which can handle the network-layer protocol,
that the extensible addresses offer a wide margin of "future-
proofing" and that there is an opportunity for convergence of
standards and products.
そして、TUBAがCLNP(ISO8473)に基づいている、ES存在(ISO9542)、制御プロトコル。 TUBAはCLNPネットワークの上にTCP輸送とUDPの操作に備えます。 TUBAを支持して主な議論はネットワーク層プロトコルを扱うことができるルータが既に存在していて、広げることができるアドレスが「未来の証」の広いマージンを提供して、規格と製品の集合の機会があるということです。
5.1 PIP
5.1 種
PIP packet headers contain a set of instructions to the router's forwarding processor to perform certain actions on the packet. In traditional protocols, the contents of certain fields imply certain actions; PIP gives the source the flexibility to write small "programs" which direct the routing of packets through the network.
PIPパケットのヘッダーは、パケットへのある動作を実行するためにルータの推進プロセッサに1セットの指示を含みます。 伝統的なプロトコルで、ある一定の分野の内容はある動作を含意します。 PIPは、ネットワークを通してパケットのルーティングを指示する小さい「プログラム」を書くために柔軟性をソースに与えます。
PIP addresses have an effectively unlimited length: each level in the topological hierarchy of the network contributes part of the address
PIPアドレスには、事実上無制限な長さがあります: ネットワークの位相的な階層構造の各レベルはアドレスの一部を寄付します。
Dixon [Page 11] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[11ページ]RFC1454比較
and addresses change as the network topology changes. In a completely hierarchical network topology, the amount of routing information required at each level could be very small. However, in practice, levels of hierarchy will be determined more by commercial and practical factors than by the constraints of any particular routing protocol. A greater advantage is that higher-order parts of the address may be omitted in local exchanges and that lower-order parts may be omitted in source routes, reducing the amount of topological information that host systems are required to know.
そして、ネットワーク形態が変化するのに応じて、アドレスは変化します。 完全に階層的なネットワーク形態では、各レベルで必要であるルーティング情報の量は非常に少であるかもしれません。 しかしながら、実際には、階層構造のレベルはどんな特定のルーティング・プロトコルの規制より商業的、そして、実際的な要素でも決定するでしょう。 より大きい利点はアドレスの高次な部分が市内交換で省略されるかもしれなくて、下層階級の部品が送信元経路で省略されるかもしれないということです、ホストシステムが知るのに必要であるという位相的な情報の量を減少させて。
There is an assumption that PIP addresses are liable to change, so a further quantity, the PIP ID, is assigned to systems for the purposes of identification. It isn't clear that this quantity has any purpose which could not equally be served by a DNS name [it is more compact, but equally it does not need to be carried in every packet and requires an additional lookup]. However, the problem does arise of how two potentially-communicating host systems find the correct addresses to use.
PIPアドレスが変化しやすいという仮定があるので、さらなる量(PIP ID)は識別の目的のシステムに割り当てられます。 この量にはDNS名で等しく役立つことができない少しの目的もあるのは[よりコンパクトですが、等しく、あらゆるパケットで運ばれる必要はなくて、追加ルックアップを必要とします]、明確ではありません。 しかしながら、問題は2台の潜在的に交信しているホストシステムがどう使用する正しいアドレスに当たるかを生じます。
The most complex part of PIP is that the meaning of some of the header fields is determined by mutual agreement within a particular domain. The semantics of specific processing facilities (for example, queuing priority) are registered globally, but the actual use and encoding of requests for these facilities in the packet header can be different in different domains. Border routers between two domains which use different encodings must map from one encoding to another. Since routers may not only be adjacent physically to other domains, but also via "tunnels", the number of different encoding rules a router may need to understand is potentially quite large. Although there is a saving in header space by using such a scheme as opposed to the more familiar "options", the cost in the complexity of negotiating the use and encoding of these facilities, together with re-coding the packets at each domain border, is a subject of some concern. Although it may be possible for hosts to "precompile" the encoding rules for their local domain, there are many potential implementaion difficulties.
PIPの最も複雑な部分はいくつかのヘッダーフィールドの意味が特定のドメインの中で相談ずくに決定しているということです。 特定の処理施設(例えば、優先権を列に並ばせる)の意味論はグローバルに登録されていますが、パケットのヘッダーのこれらの施設を求める要求の実際の使用とコード化は異なったドメインにおいて異なっている場合があります。 異なったencodingsを使用する2つのドメインの間の境界ルータは1から別のものへのコード化を写像しなければなりません。 ルータが肉体的に単に他のドメインに隣接しているのではなく、「トンネル」を通して隣接もするかもしれないので、ルータが分かるために必要とするかもしれない異なった符号化規則の数は潜在的にかなり大きいです。 節約が、よりなじみ深い「オプション」と対照的にそのような計画を使用するのによるヘッダースペースにありますが、それぞれのドメイン境界でパケットを再コード化すると共にこれらの施設の使用とコード化を交渉する複雑さにおける費用は何らかの関心の対象です。 ホストにとって、コード化が彼らの局所領域に統治されるのが、「プリコンパイル」に可能であるかもしれませんが、多くの潜在的implementaion困難があります。
Although PIP offers the most flexibility of the three proposals, more work needs to be done on "likely use" scenarios which make the potential advantages and disadvantages more concrete.
PIPは3つの提案の最も多くの柔軟性を提供しますが、されるより多くの仕事の必要性が潜在的利点と損失をより具体的にするシナリオを「おそらく、使用します」。
5.2 SIP
5.2 一口
SIP is simply IP with larger addresses and fewer options. Its main advantage is that it is even simpler that IPv4 to process. Its main disadvantages are:
SIPは単により大きいアドレスと、より少ないオプションがあるIPです。 主な利点はそれがさらに簡単であるということです。処理するそのIPv4。 主な損失は以下の通りです。
Dixon [Page 12] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[12ページ]RFC1454比較
- It is far from clear that, if 32 bits of address are
insufficient, 64 will be enough for the forseeable future;
- 十分であるのはアドレスの32ビットが不十分であるなら64がforseeable未来になる全く明確ではありません。
- although there are a few "reserved" bits in the header, the
extension of SIP to support new features is not obvious.
- 「予約された」数ビットがヘッダーにありますが、新機能を支持するSIPの拡大は明白ではありません。
There's really very little else to say!
本当にほとんど、言うために、ほかにありません!
5.3 TUBA
5.3 チューバ
The characteristics of ISO CLNS are reasonably well known: the protocol bears a strong cultural resemblance to IPv4, though with 20-byte network-layer addressing. Apart from a spurious "Not Invented Here" prejudice, the main argument againt TUBA is that it is rather too like IPv4, offering nothing other than larger, more flexible, addresses. There is proof-by-example that routers are capable of handling the (very) long addresses efficiently, rather less that the longer headers do not adversely impact network bandwidth.
ISO CLNSの特性は合理的によく知られています: 20バイトのネットワーク層アドレシングで持っていますが、プロトコルはIPv4との強い文化的な類似を持っています。 「ここで、発明されなかったこと」の偽りの偏見は別として、主な議論againt TUBAは、より大きいのを除いた何も提供しないで、それがIPv4のようにかなりフレキシブル過ぎるということです、アドレス。 ルータは(まさしくその)のロングが効率的に記述する取り扱いができるという例による証拠があって、むしろより長いヘッダーがする以下は逆にネットワーク回線容量に影響を与えません。
There are a number of objections to the proposed control protocol (ISO 9542):
提案された制御プロトコル(ISO9542)への多くの反論があります:
- My early experience is that the process by which routers
discover hosts is inefficient and resource consuming for
routers - and requires quite fine timer resolution on hosts -
if large LANs are to be accomodated reasonably. Proponents of
TUBA suggest that recent experience suggests that ARP is no
better, but I think this issue needs examination.
- 私の早めの経験はルータがホストを発見する過程がルータのための効率の悪い、そして、リソース消費であり、大きいLANが合理的にaccomodatedされることであるならホストの上でかなりよいタイマ解決を必要とするということです。 TUBAの提案者は、最近の経験が、ARPが、より良くないと示唆することを提案しますが、私は、この問題が試験を必要とすると思います。
- The "redirect" mechanism is based on (effectively) LAN
addresses and not network addresses, meaning that local routers
can only "hand-off" complex routing decisions to other routers
on the same LAN. Equally, redirection schemes (such as that of
IPv4) which redirect to network addresses can result in
unnecessary extra hops. Analysis of which solution is better
is rather dependent on the scenarios which are constructed.
- 「再直接」のメカニズムはネットワーク・アドレスではなく、LANアドレスに基づいています(事実上)、ローカルルータは同じLANに関する他のルータとの「ハンドオフ」複雑なルーティング決定しかそうすることができないことを意味して 等しく、アドレスをネットワークに転送するリダイレクション計画(IPv4のものなどの)は不要な余分なホップをもたらすことができます。 解決策が、より良い分析は構成されるシナリオにかなり依存しています。
To be fair, however, the part of the protocol which provides for router-discovery provides a mechanism, absent from other proposals, by which hosts can locate nearby gateways and potentially automatically configure their addresses.
ルータ発見に備えるプロトコルの部分はしかしながら、公正に、なるようにメカニズムを提供します、他の提案によって、休みます。(ホストは、近くのゲートウェイの場所を見つけて、提案で潜在的に自動的にそれらのアドレスを構成できます)。
6. Transition Plans
6. 変遷プラン
It should be obvious that a transition which permits "old" hosts to talk to "new" hosts requires:
「古い」ホストが「新しい」ホストと話すことを許可する変遷が以下を必要とするのは、明白であるべきです。
Dixon [Page 13] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[13ページ]RFC1454比較
Either:
どちらか:
(a) That IPng hosts can also use IPv4 or
(b) There is translation by an intermediate system
(a) (b) また、IPngホストがIPv4を使用できますか、または中間システムによる翻訳があります。
and either:
どちらか:
(c) The infrastructure between systems is capable of carrying both
IPng and IPv4 or (d) Tunneling or translation is used to carry
one protocol within another in parts of the network
(c) システムの間のインフラストラクチャがIPngとIPv4の両方を運ぶことができますか、または(d) トンネリングか翻訳が、ネットワークの部分で別のものの中で1つのプロトコルを運ぶのに使用されます。
The transition plans espoused by the various proposals are simply different combinations of the above. Experience would tend to show that all these things will in fact happen, regardless of which protocol is chosen.
様々な提案で信奉された変遷プランは上記の単に異なった組み合わせです。 経験は、どのプロトコルが選ばれているかにかかわらず事実上、これらのすべてのことが起こるのを示す傾向があるでしょう。
One problem of the tunneling/translation process is that there is additional information (the extra address parts) which must be carried across IPv4 tunnels in the network. This can either be carried by adding an extra "header" to the data before encapsulation in the IPv4 packet, or by encoding the information as new IPv4 option types. In the former case, it may be difficult to map error messages correctly, since the original packet is truncated before return; in the latter case there is a danger of the packet being discarded (IPv4 options are not self-describing and new ones may not pass through IPv4 routers). There is thus the possibility of having to introduce a "new" version of IPv4 in order to support IPng tunneling.
トンネリング/翻訳の過程の1つの問題はIPv4トンネルの向こう側にネットワークで運ばなければならない追加情報(余分なアドレス部)があるということです。 IPv4パケットのカプセル化の、前か新しいIPv4オプションとして情報をコード化するのによるデータへの余分な「ヘッダー」がタイプすると言い足すことによって、これを運ぶことができます。 前の場合では、正しくエラーメッセージを写像するのは難しいかもしれません、オリジナルのパケットがリターンの前に先端を切られるので。 後者の場合には、捨てられて、パケットの危険があります(IPv4オプションは自己説明ではありません、そして、新しいIPv4ルータを通り抜けないかもしれません)。 その結果、IPngトンネリングを支持するためにIPv4の「新しい」バージョンを紹介しなければならない可能性があります。
The alternative (in which IPng hosts have two stacks and the infrastructure may or may not support IPng or IPv4) of course requires a mechanism for resolving which protocols to try.
代替手段(そこでIPngホストは2つのスタックを持って、インフラストラクチャはIPngかIPv4を支持するかもしれない)は、試みるためにどのプロトコルを決議するかためにもちろんメカニズムを必要とします。
7. Random Comments
7. 無作為のコメント
This is the first fundamental change in the Internet protocols that has occurred since the Internet was manageable as an entity and its development was tied to US government contracts. It was perhaps inevitable that the IETF/IESG/IAB structure would not have evolved to manage a change of this magnitude and it is to be hoped that the new structures that are proposed will be more successful in promoting a (useful) consensus. It is interesting to see that many of the perceived problems of the OSI process (slow progress, factional infighting over trivia, convergence on the lowest-common denominator solution, lack of consideration for the end-user) are in danger of attaching themselves to IPng and it will be interesting to see to what extent these difficulties are an inevitable consequence of wide representation and participation in network design.
これはインターネットプロトコルで実体とその開発が米国政府契約に結ばれたときインターネットが処理しやすい時から起こっている最初の根本的変化です。 IETF/IESG/IAB構造がこの大きさの変化を管理するために発展していないのが、恐らく必然であり、願わくは提案される新しい構造は(役に立つ)のコンセンサスを促進するのにより成功するようになるでしょう。 OSIの過程(進歩を遅くしてください、小事の上の派閥抗争、最小公分母ソリューションにおける集合、エンドユーザのための考慮の不足)の知覚された問題の多くにはIPngに愛着を持つという危険があって、これらの困難がネットワークデザインへの広い表現と参加の必然の結果であるというどんな範囲まで見るかがおもしろいのがわかるのはおもしろいです。
Dixon [Page 14] RFC 1454 Comparison of Next Version IP Proposals May 1993
次のバージョンIP提案1993年5月のディクソン[14ページ]RFC1454比較
It could be regarded either as a sign of success or failure of the competitive process for the selection of IPng that the three main proposals have few really significant differences. In this respect, the result of the selection process is not of particular significance, but the process itself is perhaps necessary to repair the social and technical cohesion of the Internet Engineering process.
それを3つの主な提案にはわずかな本当に重要な違いしかないというIPngの選択のための競争力がある過程の成否の兆候と見なすことができました。 この点で、選択の過程の結果は特定の意味のものではありませんが、過程自体が、インターネットEngineeringの過程の社会的で技術的な結合を修理するのに恐らく必要です。
8. Further Information
8. 詳細
The main discussion lists for the proposals listed are:
提案が記載したので、本論リストは以下の通りです。
TUBA: tuba@lanl.gov
PIP: pip@thumper.bellcore.com
SIP: sip@caldera.usc.edu
General: big-internet@munnari.oz.au
チューバ: tuba@lanl.gov 種: pip@thumper.bellcore.com 一口: sip@caldera.usc.edu 一般: big-internet@munnari.oz.au
(Requests to: <list name>-request@<host>)
(@: <リスト名前>-要求<ホスト>への要求)
Internet-Drafts and RFCs for the various proposals can be found in the usual places.
普通の場所で様々な提案のためのインターネット草稿とRFCsを見つけることができます。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Tim Dixon RARE Secretariat Singel 466-468 NL-1017AW Amsterdam (Netherlands)
ティム・ディクソン・まれな事務局Singel466-468NL-1017AWアムステルダム(オランダ)
Phone: +31 20 639 1131 or + 44 91 232 0936 EMail: dixon@rare.nl or Tim.Dixon@newcastle.ac.uk
以下に電話をしてください。 +31 20 639 + 1131か0936年の44 91 232メール: dixon@rare.nl かTim.Dixon@newcastle.ac.uk
Dixon [Page 15]
ディクソン[15ページ]
一覧
スポンサーリンク
