RFC1705 日本語訳
1705 Six Virtual Inches to the Left: The Problem with IPng. R.Carlson, D. Ficarella. October 1994. (Format: TXT=65222 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group: R. Carlson
Request for Comments: 1705 ANL
Category: Informational D. Ficarella
Motorola
October 1994
作業部会をネットワークでつないでください: R。 コメントを求めるカールソンRequest: 1705年のANLカテゴリ: 情報のD.Ficarellaモトローラ1994年10月
Six Virtual Inches to the Left:
The Problem with IPng
左への仮想の6インチ: IPngに関する問題
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
Overview
概観
This RFC suggests that a new version of TCP (TCPng), and UDP, be developed and deployed. It proposes that a globally unique address (TA) be assigned to Transport layer protocol (TCP/UDP). The purpose of this TA is to uniquely identify an Internet node without specifying any routing information. A new version of TCP, and UDP, will need to be developed describing the new header fields and formats. This new version of TCP would contain support for high bandwidth-delay networks. Support for multiple network layer (Internet Protocol) protocols is also possible with this new TCP. Assigning an address to TCP/UDP would allow for the support of multiple network layer protocols (IPng's). The TA would identify the location of an Internet node. The IPng layer would provide routing information to the Internet. Separating the location and routing functions will greatly increase the versatility of the Internet.
このRFCはTCP(TCPng)、およびUDPの新しいバージョンが開発されて、展開したと示唆します。 グローバルにユニークなアドレス(TA)がTransport層のプロトコル(TCP/UDP)に割り当てられるのは提案します。 このTAの目的は唯一どんなルーティング情報も指定しないでインターネット接続装置を特定することです。 TCP、およびUDPの新しいバージョンは、新しいヘッダーフィールドと形式について説明しながら開発される必要があるでしょう。 TCPのこの新しいバージョンは高帯域遅れネットワークのサポートを含んでいるでしょう。 また、複数のネットワーク層(インターネットプロトコル)プロトコルのサポートもこの新しいTCPで可能です。 アドレスをTCP/UDPに割り当てると、複数のネットワーク層プロトコル(IPngのもの)のサポートは考慮されるでしょう。 TAはインターネット接続装置の位置を特定するでしょう。 IPng層はルーティング情報をインターネットに提供するでしょう。 位置と経路選択機能を切り離すと、インターネットの多才は大いに増加するでしょう。
Carlson & Ficarella [Page 1] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[1ページ]RFC1705 6インチ: IPng問題1994年10月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Historical perspective . . . . . . . . . . . . . . . . . . . . 3
2.1 OSI and the 7 layer model . . . . . . . . . . . . . . . 3
2.2 Internet Evolution . . . . . . . . . . . . . . . . . . . 4
2.3 The Reasons for Change . . . . . . . . . . . . . . . . . 4
2.3.1 Class-B Address Exhaustion . . . . . . . . . . . 4
2.3.2 Routing Table Growth . . . . . . . . . . . . . . 5
3. The Problems with Change . . . . . . . . . . . . . . . . . . . 5
3.1 TCP/UDP Implementations . . . . . . . . . . . . . . . . 6
3.2 User Applications . . . . . . . . . . . . . . . . . . . 6
3.3 The Entrenched Masses . . . . . . . . . . . . . . . . . 6
4. Making TCP & UDP Protocol Independent . . . . . . . . . . . . 7
4.1 Transport Addressing . . . . . . . . . . . . . . . . . . 7
4.2 TCPng . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Mandatory Options . . . . . . . . . . . . . . . . . . . 15
4.4 Optional Options . . . . . . . . . . . . . . . . . . . . 16
4.5 Compatibility Issues . . . . . . . . . . . . . . . . . . 16
4.5.1 Backward Compatibility . . . . . . . . . . . . . 17
4.6 Level 4 Gateways . . . . . . . . . . . . . . . . . . . . 17
4.7 Error Conditions . . . . . . . . . . . . . . . . . . . . 18
5. Advantages and Disadvantages of this approach . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Security Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 Change. . . . . . . . . . . . . . . . . 4 2.3.1Class-B Address Exhaustion. . . . . . . . . . . 4 2.3.2ルート設定Table Growth. . . . . . . . . . . . . . 5 3のための歴史観.32.1OSIと7階層モデル. . . . . . . . . . . . . . . 3 2.2インターネットEvolution. . . . . . . . . . . . . . . . . . . 4 2.3Reasons。 強固が.6 4に一かたまりにする.53.1の変化TCP/UDP実現. . . . . . . . . . . . . . . . 6 3.2ユーザアプリケーション. . . . . . . . . . . . . . . . . . . 6 3.3に関する問題。 作成TCP&UDPは独立している.74.1輸送アドレシング. . . . . . . . . . . . . . . . . . 7 4.2TCPng. . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3の義務的なオプション. . . . . . . . . . . . . . . . . . . 15 4.4の任意のオプションについて議定書の中で述べます…; .164.5 互換性は.164.5.1後方の互換性. . . . . . . . . . . . . 17 4.6レベル4 ゲートウェイ. . . . . . . . . . . . . . . . . . . . 17 4.7にエラー条件. . . . . . . . . . . . . . . . . . . . 18 5を発行します。 この利点とDisadvantagesは.186にアプローチします。 結論. . . . . . . . . . . . . . . . . . . . . . . . . 19参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 19図書目録. . . . . . . . . . . . . . . . . . . . . . . . . . . 20付録A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 21付録B…; .21 付録C. . . . . . . . . . . . . . . . . . . . . . . . . . . . 22付録D. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24セキュリティ問題. . . . . . . . . . . . . . . . . . . . . 27作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
1. 序論
For more than a decade, network engineers have understood the benefits of a multi-layer protocol stack. However, during its development, the Transmission Control Protocol (TCP) was strongly linked to the Internet Protocol (IP) [Postel, 1981a]. When the TCP/IP protocol suite was developed, two important ideas were implemented. The first was that each host would be uniquely identified by a network layer number (i.e., IP number = 192.0.2.1). The second was to identify an application with a transport layer port number (i.e., TCP DNS number = 53). For host-to-host communications, the IP and port numbers would be concatenated to form a socket (i.e., 192.0.2.1.53). While this has lead to a very efficient and streamlined TCP layer, it has tightly coupled the TCP and IP layers. So much so, in fact, that it is nearly impossible to run TCP over any network layer except for
10年間以上の間、ネットワーク・デザイナーはマルチ層のプロトコル・スタックの利益を理解していました。 しかしながら、開発の間、通信制御プロトコル(TCP)は強くインターネットプロトコル(IP)[ポステル、1981a]にリンクされました。 TCP/IPプロトコル群が開発されたとき、2つの重要な考えが実行されました。 すなわち、IP番号は192.0と等しいです。1番目が各ホストがネットワーク層番号によって唯一特定されるだろうということであった、(.2 .1)。 2番目はトランスポート層ポートナンバー(すなわち、TCP DNS番号=53)とアプリケーションを同一視することでした。 すなわち、ホスト間通信に関して、IPとポートナンバーがソケットを形成するために連結されるだろう、(192.0 .2 .1 .53)。 これは非常に効率的で流線型のTCP層にリードを持っていますが、それはしっかりTCPとIP層を結合しました。 事実上とても多くのそう、それはどんなネットワーク層の上でもTCPを走らせるのがほとんど不可能です。
Carlson & Ficarella [Page 2] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[2ページ]RFC1705 6インチ: IPng問題1994年10月
IP.
IP。
The motivation for writing this paper resulted from research into the various Internet Protocol Next Generation (IPng) proposals put forth by various IETF working groups. Each of the IPng proposals strives to solve the impending IP address exhaustion problem by increasing the size of the address field. They all allude to modifications to TCP and User Datagram Protocol (UDP) to make them capable of supporting a new network layer IPng protocol. The authors of this paper feel that this points to an inherent TCP/IP design flaw. The flaw is namely that the transport (TCP) and network (IP) layers are not protocol independent. In this paper, we will propose a new TCP and UDP implementation that will make the transport and protocol layers independent and thus allow for any of the IPng protocols to operate on the same internet without any further modification to the higher layer protocols. TCP, and UDP would become extremely powerful Application Programming Interfaces (APIs) that operate effectively over multiple network layer technologies.
この論文を書くことに関する動機は様々なIETFワーキンググループによって差し出された様々なインターネットプロトコルNext Generation(IPng)提案の研究から生じました。 それぞれのIPng提案は、アドレス・フィールドのサイズを増加させることによって差し迫っているIPアドレス疲労困憊問題を解決するように努力します。 彼らは皆、それらを新しいネットワーク層IPngプロトコルをサポートできるようにするように、TCPへの変更とユーザー・データグラム・プロトコル(UDP)について暗示します。 この紙の作者は、これが固有のTCP/IP設計上の欠陥を示すと感じます。 欠点はすなわち、輸送(TCP)とネットワーク(IP)層がプロトコル独立者でないということです。 この紙では、私たちは、より高い層のプロトコルへの少しもさらなる変更なしで輸送とプロトコル層を独立するようにして、その結果IPngプロトコルのどれかが同じインターネットを作動させるのを許容する新しいTCPとUDP実現を提案するつもりです。 TCP、およびUDPはなるでしょう。複数のネットワーク層技術の上で有効に作動する非常に強力なApplication Programming Interfaces(API)になってください。
2. Historical perspective
2. 歴史観
2.1 OSI and the 7 layer model
2.1 OSIと7階層モデル
Present day computer and communication systems have become increasingly heterogeneous in both their software and hardware complexity, as well as their intended functionality. Prior to the establishment of computer communications industry standards, proprietary standards followed by particular software and hardware manufacturers prevented communication and information exchange between different manufacturers products and therefore lead to many "closed systems" [Halsal, 1992] incapable of readily sharing information. With the proliferation of these types of systems in the mid 1970s, the potential advantages of "open systems" where recognized by the computer industry and a range of standards started to be introduced [Halsal, 1992].
近代のコンピュータと通信系はますますそれらのソフトウェアとハードウェアの複雑さの両方で異種になりました、それらの意図している機能性と同様に。 コンピュータコミュニケーション業界基準の設立の前に、特定のソフトウェアとハードウェアメーカーによって後をつけられた独占規格は、異なったメーカー製品の間のコミュニケーションと情報交換を防いで、したがって、容易に情報を共有できない多くの「クローズドシステム」[Halsal、1992]に通じます。 1970年代の半ばこれらのタイプのシステムの増殖から、コンピュータ産業とさまざまな規格によって認識されるところで「オープンシステム」の潜在的利点によって導入され始めました[Halsal、1992]。
The first and perhaps most important of these standards was the International Standards Organization (ISO) reference model for Open Systems Interconnection standard (OSI), describing the complete communication subsystem within each computer. The goal of this standard model was to "allow an application process in any computer that supports a particular set of standards to communicate freely with an application process in any other computer that supports the same standards, irrespective of its origin of manufacture" [Halsal, 1992]. The last statement above describes the OSI 7-layer model which has now, in concept, become the fundamental building block of computer networks. Though there are arguably no present day computers and networks completely compliant to all 7 layers of the
1番目でこれらの規格で恐らく最も重要であるのは、オープン・システム・インターコネクション規格(OSI)のための国際Standards Organization(ISO)規範モデルでした、各コンピュータの中に完全なコミュニケーションサブシステムを説明して。 「このスタンダード・モデルの目標は特定のセットの規格を支持するどんなコンピュータのアプリケーション・プロセスも製造の起源の如何にかかわらず同じ規格を支持するいかなる他のコンピュータのアプリケーション・プロセスでも自由に交信するのを許容する」[Halsal、1992]ことでした。 上の最後の声明は7階層モデルでOSIについて説明します(概念では、現在、コンピュータネットワークの基本的なブロックになりました)。 論証上、すべての7に完全に言いなりになっているコンピュータとネットワークが層にする近代が全くありません。
Carlson & Ficarella [Page 3] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[3ページ]RFC1705 6インチ: IPng問題1994年10月
OSI protocol stack, most protocol stacks do embrace the fundamental concept of independent layers, thus allowing the flexibility for computers operating with dissimilar protocol stacks to communicate with one another.
OSIプロトコル・スタック、ほとんどのプロトコル・スタックが独立している層に関する基本概念を受け入れます、その結果、お互いにコミュニケートするために異なったプロトコル・スタックで動作するコンピュータのための柔軟性を許容します。
Take for example, the datalink layers as supported by TCP/IP. TCP/IP will run equally well in either the local area network (LAN) or wide area network (WAN) environments. Even though the LAN may use Ethernet 802.3 and the WAN may use T1 serial links. This function was designed to present a "standardized set of network functions (i.e., a logical network)", to the upper network layer, "regardless of the exact details of the lower level implementations" [Meyer, Zobrist, 1990].
例えば、取ってください、そして、データリンクはTCP/IPによって支持されるように層にされます。 TCP/IPはローカル・エリア・ネットワーク(LAN)か広域ネットワーク(WAN)環境で等しく順調でしょう。 LANはイーサネット802.3を使用するかもしれません、そして、WANはT1を使用するかもしれませんが、シリーズはリンクされます。 この機能は「標準化されたセットのネットワーク機能(すなわち、論理的なネットワーク)」を提示するように設計されました、上側のネットワーク層に、「下のレベル実現の正確な詳細にかかわらず」[マイヤー、Zobrist、1990]。
2.2 Internet Evolution
2.2 インターネット発展
"The internet architecture, the grand plan behind the TCP/IP protocol suite" was developed and tested in the late 1970s, [Braden, et al, 1991] and but for the addition of subnetting, autonomous systems, and the domain name system in the early 1980s and the more recent IP multicasting implementation, stands today essentially unchanged. Even with the understood benefits of a multi-layer protocol stack, all steps taken to enhance the internet and its services have been very incremental and narrowly focused.
「インターネット構造、TCP/IPプロトコル群の後ろの大計画」は、1970年代、後半[ブレーデン、他、1991]に開発されて、テストされました、そして、サブネッティングの添加がなければ、自律システム、1980年代前半のドメイン名システム、および、より最近のIPマルチキャスティング実現は今日、本質的には変わりがない状態で立ちます。 インターネットを高めるために取られたすべての方法とそのサービスは、マルチ層のプロトコル・スタックの理解されている利益があっても、非常に増加であって狭く集中しています。
2.3 The Reasons for Change
2.3 変化の理由
The reasons for change from IP to IPng can be described in terms of problems for which the current IP will simply become inadequate and unusable in the near future (~2-4 years). These problems are the exhaustion of IP class B address space, the exhaustion of IP address space in general, and the non-hierarchical nature of address allocation leading to a flat routing space [Dixon, 1993].
現在のIPが(~2-4年)近い将来単に不十分で使用不可能になる問題でIPからIPngまでの変化の理由について説明できます。 これらの問題は、平坦なルーティングスペース[ディクソン、1993]につながるIPクラスBアドレス空間の疲労困憊と、一般に、IPアドレス空間の疲労困憊と、アドレス配分の非階層的な本質です。
2.3.1 Class-B Address Exhaustion
2.3.1 クラスBアドレス疲労困憊
One of the fundamental causes of this problem is the lack of a class of network address appropriate for a mid-sized organization. The class-C address, with a maximum of 254 unique host addresses is to small, while class-B, with a maximum of in excess of 65 thousand unique host addresses is to large [Fuller, et al, 1992]. As a result, class-B addresses get assigned even though nowhere near the number of available addresses will ever get used. This fact, combined with a doubling of class-B address allocation on a yearly basis lead the Internet Engineering Steering Group (IESG) to conclude in November, 1992 that the class-B address space would be completely exhausted within 2 years time. At that point, class-C addresses would have to be assigned, sometimes in multiples, to organizations needing more than the 254 possible host addresses from a single
この問題の根本的要因の1つは中型の組織に、適切なネットワーク・アドレスのクラスの不足です。 クラスCアドレス、大きく最大1,000のユニークなホストが記述する65以上があるクラスBがありますが、最大254のユニークなホスト・アドレスと共に、小さく[フラー、他、1992]があります。 その結果、アドレスは今までに、利用可能の数の近くのどこにも使用されないでしょうが、クラスBアドレスは割り当てられます。 クラスBアドレス空間が2年間の回以内に完全に消耗するだろうという1992年11月に終える年立てにおける配分がインターネットEngineering Steering Group(IESG)を導くクラスB演説の倍増に結合されたこの事実。 その時、クラスCアドレスは割り当てられなければならないでしょう、時々倍数で、254の可能なホストがシングルから記述する以上を必要とする組織に
Carlson & Ficarella [Page 4] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[4ページ]RFC1705 6インチ: IPng問題1994年10月
class-C address [Almquist, Gross, 1992].
クラスCアドレス[Almquist、Gross、1992]。
2.3.2 Routing Table Growth
2.3.2 経路指定テーブルの成長
Based on research conducted by the IESG in November 1992, definite routing table size explosion problems were identified. Namely, it was determined that current router technology at that point could support a maximum of 16,000 routes, which in turn could support the internet for an additional 12 to 18 months (~May, 1994) at the then twofold annual network growth rate. However, vendor router maximum capabilities were in the process of being increased to 64,000 routes, which at the two-fold annual network growth rate, could bring us an additional 2 years of lead time, (at best bringing us to May, 1996, and at worst to November, 1995) assuming the class-B address exhaustion problem mentioned above could be solved in the interim [Almquist, Gross, 1992].
1992年11月にIESGによって行われた研究に基づいて、明確な経路指定テーブルサイズ爆発問題は特定されました。 すなわち、現在のルータ技術がその時最大1万6000のルートを支えるかもしれないのは、決定していました。(順番に、ルートは追加12〜18カ月(~1994年5月)当時の二つの年に一度のネットワーク成長率でインターネットを支持できました)。 しかしながら、その間前記のようにクラスBアドレス疲労困憊問題を解決できたと仮定しながら二面の年に一度のネットワーク成長率で先行時間の追加2年を私たちにもたらすことができた6万4000のルート(1996年5月、最悪で1995年11月に私たちをせいぜい連れて来る)まで増加すること[Almquist、Gross、1992]の途中に業者のルータの最大の能力がありました。
As a short term, incremental solution to this routing table growth problem, and to aid in the class-B address exhaustion problem the IESG endorsed the CIDR supernetting strategy proposal (see RFC-1338 for full details of this proposal). However, this strategy was estimated to have a viability of approximately 3 years, at which point the internet would run out of all classes of IP addresses in general. Hence, it is clear that even CIDR only offers temporary relief. However, if implemented immediately, CIDR can afford the Internet community time to develop and deploy an approach to addressing and routing which allows scaling to orders of magnitude larger than the current architecture (IPng).
短期間、この経路指定テーブル成長問題、およびIESGがCIDRスーパーネッティング戦略提案を是認したことにおける(この提案の一部始終に関してRFC-1338を見てください)クラスBアドレス疲労困憊問題における援助の増加の解決策として。 しかしながら、この戦略は、インターネットがそのポイントで一般に、すべてのクラスのIPアドレスを使い果たすだろうおよそ3年の生存力を持つために見積もられていました。 したがって、CIDRさえ一時的救済を提供するだけであるのは、明確です。 しかしながら、すぐに実行されるなら、CIDRは現在の建築(IPng)より大きい桁に比例するのを許容するアドレシングとルーティングへのアプローチを開発して、配備するインターネットコミュニティ時間を提供できます。
3. The Problems with Change
3. 変化に関する問題
There are many problems, both philosophical and technical, which greatly contribute to the difficulties associated with a large scale change such as the one proposed in the conversion from IP to IPng. These problems range from having to rewrite highly utilized and entrenched user applications, such as NFS, RPC, etc, to potentially having to invest additional capital to purchase hardware that supports the new protocol(s). This proposal solves the urgent internet problems listed above, while simultaneously limiting the amounts of retraining and re- investing that the user community would have to undertake. The TCP layer will once and for all be changed to support a multiprotocol internet. The net affect is that while administrators will necessarily be trained in the operations and details of this new TCP, the much larger operator and end user community will experience no perceptible change in service and network usage.
哲学的なものと多くのIPからIPngまでの変換で提案されたものなどの大規模変化に関連している困難に大いに貢献する同様に技術的な問題があります。 これらの問題は、NFS、RPCなどの非常に利用されて、強固なユーザアプリケーションを書き直さなければならないので、新しいプロトコルをサポートするハードウェアを購入するために潜在的に増加資本を投資しなければならないために及びます。 この提案は同時に再教育とユーザーコミュニティが引き受けなければならない再投資の量を制限する間に上に記載された緊急のインターネット問題を解決します。 「マルチ-プロトコル」インターネットを支持するためにきっぱりTCP層を変えるでしょう。 ネットの感情は管理者が必ずこの新しいTCPの操作に細部に訓練されている間はるかに大きいオペレータとエンドユーザ社会がサービスとネットワーク用法における目に見える変化を全く経験しないということです。
Carlson & Ficarella [Page 5] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[5ページ]RFC1705 6インチ: IPng問題1994年10月
3.1 TCP/UDP Implementations
3.1 TCP/UDP実現
Both TCP and UDP are highly dependent on the IPv4 network layer for 2 very low level reasons. 1) a TCP/UDP socket is formed by concatenating a network layer address (IP address) and the transport layer TCP/UDP port number. 2) included in the TCP/UDP checksum calculation are the IP layer source and destination addresses mentioned above which are transferred across the TCP/IP [Postel, 1981b] or UDP/IP [Postel, 1980] interfaces as procedure call arguments. It should be noted at this point that the reason for such strong dependence between the transport and network layers in TCP/IP or UDP/IP is to insure a globally unique TCP/UDP layer address, such that a unique connection could be identified by a pair of sockets. The authors of this paper propose that the IP address requirement with TCP and UDP be replaced with a globally unique transport address (TA) concatenated with a transport layer port address. This solution offers the capability to still maintain a globally unique address and host unique port number with the added benefit of eliminating the transport and network layer dependence on one another.
TCPとUDPの両方が2つの非常に低い平らな理由でIPv4ネットワーク層に非常に依存しています。 1) TCP/UDPソケットは、ネットワーク層アドレス(IPアドレス)とトランスポート層TCP/UDPポートナンバーを連結することによって、形成されます。 2) TCP/UDPチェックサム計算に含まれているのは、前記のように手順呼び出し議論としてTCP/IP[ポステル、1981b]かUDP/IP[ポステル、1980]インタフェースの向こう側に移されるIP層のソースと送付先アドレスです。 ここにTCP/IPかUDP/IPにおける輸送とネットワーク層の間のそのような強い依存の理由がグローバルにユニークなTCP/UDP層のアドレスを保障することであることに注意されるべきです、1組のソケットでユニークな接続を特定できるように。 この紙の作者は、TCPとUDPがあるIPアドレス要件がトランスポート層ポートアドレスで連結されるグローバルにユニークな輸送アドレス(TA)に取り替えられるよう提案します。 このソリューションはお互いに輸送とネットワーク層の依存を根絶する付加利益でまだグローバルにユニークなアドレスを維持していて、ユニークなポートナンバーを接待する能力を提供します。
3.2 User Applications
3.2 ユーザアプリケーション
In addition to TCP and UDP, there are a large number of firmly entrenched higher level applications that use the IP network layer address embedded internally, and would therefore require modification for use with the proposed IPng network layer schemes. These applications include, but are not limited to Network File System (NFS), Remote Procedure Call (RPC), and File Transfer Protocol (FTP). All of these applications should be modified to use the Internet Domain name to identify the remote node, and not an embedded, protocol dependent IP address.
TCPとUDPに加えて、内部的に埋め込まれたIPネットワーク層アドレスを使用する多くのしっかり確立されたより高い平らな利用があります、そして、したがって、提案されたIPngネットワーク層体系で使用のための変更を必要とするでしょう。 ネットワークファイルシステム(NFS)、Remote Procedure Call(RPC)、およびFile Transferプロトコル(FTP)に含んでいますが、これらのアプリケーションは限られていません。 これらのアプリケーションのすべてが、埋め込まれて、プロトコルに依存するIPアドレスではなく、遠隔ノードを特定するのにインターネットDomain名を使用するように変更されるべきです。
3.3 The Entrenched Masses
3.3 強固なミサ
Will users voluntarily give up their IPv4 systems to move to IPng? It seems likely that many users will resist the change. They will perceive no benefit and will not install the new software. Making the local Internet contact responsible may not be feasible or practical in all cases. Another issue is backward compatibility issues. If a host needs to run IPng and IPv4 to support old hosts, then 1) where is the address savings IPng promised. 2) Why change if the host you are talking to has IPv4 anyway?
ユーザは、IPngに移行するために自発的に彼らのIPv4システムをあきらめるでしょうか? 多くのユーザが変化が抵抗しそうでしょう。 彼らは、利益を全く知覚しないで、また新しいソフトウェアをインストールしないでしょう。 地方のインターネット接触を責任があるようにするのはすべての場合で可能であるか、または実用的でないかもしれません。 別の問題は後方の互換性の問題です。 ホストは、IPngを実行する必要があるかどうか、そして、当時年取った1歳のホストをサポートするIPv4) どこで、アドレス貯蓄IPngは約束されますか? 2) なぜあなたが話しているホストがとにかくIPv4を持っているかどうかを変えますか?
On the other hand, replacing the existing TCP (TCPv6) with this new version (TCPng) will benefit users in several ways. 1) Users will be able to connect to unmodified TCPv6 hosts. 2) As nodes upgrade to TCPng, new features will be enabled allowing TCP to communicate effectively over high bandwidth*delay network links. 3) System
他方では、既存のTCP(TCPv6)をこの新しいバージョン(TCPng)に取り替えると、ユーザはいくつかの方法でためになるでしょう。 1) ユーザは変更されていないTCPv6ホストに接できるでしょう。 2) ノードがTCPngにアップグレードするとき、TCPが高帯域*遅れネットワークリンクの上に有効に交信するのを許容しながら、新機能は可能にされるでしょう。 3) システム
Carlson & Ficarella [Page 6] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[6ページ]RFC1705 6インチ: IPng問題1994年10月
administrators will be able to incrementally upgrade nodes as needed or as local conditions demand. 4) Upgraded nodes may return their IPv4 address and use an IPng address and TCP transporter function, described later, to communicate with IPv4 hosts.
必要に応じてか現地の状況が要求するように管理者はノードを増加してアップグレードさせることができるでしょう。 4) アップグレードしたノードは、それらのIPv4アドレスを返して、IPv4ホストとコミュニケートするのに後で説明されたIPngアドレスとTCP運送者機能を使用するかもしれません。
4. Making TCP & UDP Protocol Independent
4. TCP&UDPプロトコルを独立するようにします。
The OSI 7 layer model specifies that each layer be independent of the adjacent layers. What is specified is the interface between layers. This allows layers to be replaced and/or modified without making changes to the other layers. As was pointed out previously, the TCP and UDP transport layers violate this precept. In the following discussion, when we refer to TCP we mean both the TCP and UDP protocols. The generic term transport layer and TCP will be used interchangeably.
OSI7階層モデルは、それぞれの層が隣接している層から独立していると指定します。 指定されることは層の間のインタフェースです。 これは、層がもう片方への変更を層にしないで取り替える、そして/または、変更されるのを許容します。 以前に指摘されたように、TCPとUDPトランスポート層はこの教訓に違反します。 以下の議論では、TCPについて言及するとき、私たちはTCPとUDPプロトコルの両方を言っています。 総称のトランスポート層とTCPは互換性を持って使用されるでしょう。
Overcoming TCP's dependence on IP will require changes to the structure of the TCP header. The developers and implementors will also have to change the way they think about TCP and IP. End users will also have to change the way they view the Internet. Gone will be the days when Internet node names and IP addresses can be used interchangeably. The goal of this change is to allow end users to migrate from the current IPv4 network layer to an IPng layer. What this IPng protocol is will be left to the Internet Architecture Board/Internet Engineering Steering Group/Internet Engineering Task Force (IAB/IESG/IETF) to decide. By adopting this proposal, the migration will be greatly enhanced.
IPへのTCPの依存に打ち勝つのはTCPヘッダーの構造に釣り銭がいるでしょう。 また、開発者と作成者は彼らがTCPとIPについて考える方法を変えなければならないでしょう。 また、エンドユーザは彼らがインターネットを見る方法を変えなければならないでしょう。 過ぎ去るのは、インターネット接続装置名とIPアドレスを互換性を持って使用できる数日でしょう。 この変化の目標はエンドユーザが現在のIPv4ネットワーク層からIPng層まで移行するのを許容することです。 このIPngプロトコルが何であるかが決めるのがインターネット・アーキテクチャ委員会/インターネットEngineering Steering Group/インターネット・エンジニアリング・タスク・フォース(IAB/IESG/IETF)に残されるでしょう。 この提案を採用することによって、移行は大いに高められるでしょう。
One of the stated goals of the IAB is to promote a single Internet protocol suite [Leiner, Rekhter, 1993]. While this is a laudable goal, we should not be blinded by it. The addition of a Transport layer address (TA) does not invalidate the IAB's stated goals. It merely brings the implementation into compliance with standard networking practices. The historical reasons for concatenating TCP port numbers to IP numbers has long since passed. The increasing throughput of transmission lines and the negligible effect of packet overhead (see appendix A) prove this. The details of assigning and using TA's are discussed in the next few sections.
IABの述べられた目標の1つは単一のインターネット・プロトコル群[Leiner、Rekhter、1993]を促進することです。 これが称賛に値する目標である間、それは私たちの目をくらますべきではありません。 Transportアドレス(TA)層の追加はIABの述べられた目標を無効にしません。 それは単に一般的なネットワーク練習への承諾に実装を運び込みます。 IP番号にTCPポートナンバーを連結する歴史的な理由は以来、長い間、終わっています。 伝送路の増加するスループットとパケットオーバーヘッドのごくわずかな影響(付録Aを見る)はこれを立証します。 次の数セクションでTAを割り当てて、使用する詳細について議論します。
4.1 Transport Addressing
4.1 輸送アドレシング
A Transport Address (TA) will be assigned to the TCP transport layer on each Internet node. The purpose of this address is to allow a TCP on one node to communicate with a TCP on a remote node. Some of the goals defined in developing this address are:
Transport Address(TA)は各インターネット接続装置の上のTCPトランスポート層に割り当てられるでしょう。 このアドレスの目的は1つのノードの上のTCPが遠隔ノードの上でTCPとコミュニケートするのを許容することです。 このアドレスを開発する際に定義された目標のいくつかは以下の通りです。
1. Fixed size -- A fixed size will make parsing easier for
decoding stations.
1. 固定サイズ--固定サイズで、構文解析はステーションを解読するには、より簡単になるでしょう。
Carlson & Ficarella [Page 7] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[7ページ]RFC1705 6インチ: IPng問題1994年10月
2. Minimum impact on TCP packet size -- This information
will need to be carried each TCP packet.
2. 最小限にTCPパケットサイズで影響を与えます--この情報は、運ばれる必要があるでしょう。それぞれのTCPパケット。
3. Global Uniqueness -- It is desirable (required) to have a
globally unique Transport Address.
3. グローバルなUniqueness--グローバルにユニークなTransport Addressを持っているのは望ましいです(必要です)。
4. Automatic Registration -- To reduce implementation
problems, an automatic registration of the TA is
desirable.
4. 自動Registration--実装問題を減少させるために、TAの自動登録は望ましいです。
The TA will be used when an Internet node attempts to communicate with another Internet node. Conceptually you can view the TA as replacing the IP number in every instance it now appears in the transport layer (i.e., a socket would change from IP#.Port# to TA#.Port#). A connection setup would thus be:
インターネット接続装置が、別のインターネット接続装置とコミュニケートするのを試みると、TAは使用されるでしょう。 概念的に、あなたはあらゆる場合にそれが今トランスポート層の中で見えるIP番号を置き換えるとTAをみなすことができます(すなわち、ソケットはIP#.Port#からTA#.Port#に変化するでしょう)。 その結果、接続設定は以下の通りでしょう。
1. A user starts an application on Node-A and requests
service from Node-B. The user identifies Node-B by
referencing it's Internet Domain Name.
1. ユーザは、アプリケーションをNode-Aに始めて、Node-Bからサービスを要求します。 ユーザは、それのインターネットDomain Nameに参照をつけることによって、Node-Bを特定します。
2. The TCP on Node-A makes a Domain Name Service (DNS) call
to determine the TA of Node-B.
2. Node-Aの上のTCPは、Domain Name Service(DNS)にNode-BのTAを決定するために呼ばせます。
3. Node-A constructs a TCP packet using the header Src = TA-
A.port and Dest = TA-B.port and passes this packet down to
the network layer.
3. ノードAがヘッダーSrc=TA A.ポートとDest=を使用することでTCPパケットを組み立てる、TA-B.が移植する、そして、このパケットがネットワーク層に倒すパス。
4. The IP on Node-A makes a DNS call to determine the IP
address of Node-B. The IP will cache this TA/IP pair for
later use.
4. Node-Aの上のIPは、DNSにNode-BのIPアドレスを決定するために呼ばせます。 IPは後の使用のためにこのTA/IP組をキャッシュするでしょう。
5. Node-A constructs an IP packet using the header Src = IP-A
and Dest = IP-B and passes this packet down to the Media
Access layer.
5. ノードAがIPヘッダーSrc=Aを使用することでIPパケットを組み立てて、DestはIP-Bと等しく、このパケットをAccessが層にするメディアまで通過します。
6. Delivery of the packet is identical to the delivery of an
existing Internet IP packet.
6. パケットの配送は既存のインターネットIPパケットの配送と同じです。
7. The IP on Node-B examines the IP Dest address and if it
matches it's own, strips off the header and passes the
data portion up to the TCP. (Note: the packet may have
passed through several IP routers between the source and
destination hosts.)
7. Node-Bの上のIPがIP Destアドレスを調べて、合っているなら、それは、自己であり、ヘッダーを全部はぎ取って、データ部をTCPまで通過します。 (注意: パケットはソースとあて先ホストの間のいくつかのIPルータを通り抜けたかもしれません。)
8. The TCP on Node-B examines the header to determine if the
Dest TA is it's own, if so it passes the data to the
application specified by the port address. If not it
determines if it should perform the transporter function.
8. Node-Bの上のTCPはDest TAがそうなら自己であることを決定するためにヘッダーを調べます、したがって、ポートアドレスによって指定されたアプリケーションにデータを通過するなら。 そうでなければ、それは、運送者機能を実行するべきであるかどうか決定します。
Carlson & Ficarella [Page 8] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[8ページ]RFC1705 6インチ: IPng問題1994年10月
The packet will be forwarded toward the destination or an
error message will be returned.
目的地に向かってパケットを送るだろうか、またはエラーメッセージを返すでしょう。
The above steps represent a quick synopsis of how user applications may pass data between different Internet nodes. The exact structure of the network is hidden from the application, allowing the network to be modified and improved as needed. Using the transporter function, several different network layers may be traversed when moving from source to destination (several examples are provided in appendix D).
上のステップはユーザアプリケーションが異なったインターネット接続装置の間でどうデータを通過するかもしれないかに関する迅速な構文を表します。 アプリケーションネットワークの正確な構造を隠されます、ネットワークが必要に応じて変更されて、改良されるのを許容して。 ソースから目的地まで移行するとき、運送者機能を使用して、いくつかの異なったネットワーク層が横断されるかもしれません(いくつかの例を付録Dに提供します)。
One of the underlying assumptions is that the user application must refrain from making assumptions about the network structure. As pointed out in section 3, this is not the case for the current Internet network. User applications that are deployed with this new TCP must be capable of making this assumption. This means that the user application should store the Internet Domain Name in it's internal structure instead of the IPng network number. The domain name is globally unique and provides enough information to the system to find the transport and network layer addresses. The user application must pass the following parameters down to TCP:
基本的な仮定の1つはユーザアプリケーションが、ネットワーク構造に関する仮定をするのを控えなければならないということです。 セクション3で指摘されるように、これは現在のインターネット網のためのそうではありません。 この新しいTCPと共に配布されるユーザアプリケーションはこの仮定をすることができなければなりません。 これは、ユーザアプリケーションがIPngネットワーク・ナンバーの代わりにそれの内部の構造にインターネットDomain Nameを保存するべきであることを意味します。 ドメイン名は、グローバルにユニークであり、システムへの輸送とネットワーク層にアドレスを見つけることができるくらいの情報を提供します。 ユーザアプリケーションは以下のパラメタをTCPまで通過しなければなりません:
1. Destination domain name (Text string)
2. Pointer to data buffer
3. Quality of service indicators
4. Options
1. 目的地ドメイン名(テキスト文字列)2。 データバッファ3への指針。 サービスの質インディケータ4。 オプション
When the user application writes data to the network, TCP will return a nonzero integer to indicate an error condition, or a zero integer to indicate success. When the user application reads data from the network, TCP will deliver a pointer to a data buffer back to the application.
ユーザアプリケーションがネットワークにデータを書くとき、TCPは、成功を示すためにエラー条件を示す非零整数をリターンに望んでいるか、または整数を全くaに望んでいません。 ユーザアプリケーションがネットワークからデータを読むとき、TCPはアプリケーションへのデータバッファに指針を提供するでしょう。
TCP will receive the users request and it will make a DNS call to determine the destination nodes TA. If DNS returns a TA, TCP will build a Transmission Control Block (TCB) (see the paragraph below) and call the network layer. Otherwise, TCP will make a DNS call looking for the destination nodes IPv4 address. If an address is returned, TCP will takes the steps listed below in building a TCB, and call the proper network layer. If DNS returns a host unknown indication, exit back to the user with a "host unknown" error. TCP should maintain a cache of domain names and addresses in lieu of making repeated DNS calls. This feature is highly recommended, but not required.
TCPはユーザ要求を受け取るでしょう、そして、それで、DNSは目的地ノードTAを決定するために呼ぶでしょう。 DNSがTAを返すと、TCPはTransmission Control Block(TCB)(以下のパラグラフを見る)を造って、ネットワーク層を呼ぶでしょう。 さもなければ、TCPは、DNSに送付先ノードIPv4アドレスを探しながら、呼ばせるでしょう。 アドレスを返すと、TCPはTCBを造りながら以下に記載されたステップを見て取って、適切なネットワーク層を呼ぶでしょう。 DNSがホストの未知の指示を返すなら、「ホスト未知」誤りと共にユーザに出て戻ってください。 TCPは、繰り返されたDNSを作ることの代わりにドメイン名とアドレスのキャッシュが呼ぶと主張するはずです。 この特徴は、強く推薦されますが、必要ではありません。
The state information needed to keep track of a TCP connection is kept in the Transmission Control Block (TCB). Currently this structure has fields for the TCP parameters, source port, destination
情報がTCP接続の動向をおさえる必要があった状態はTransmission Control Block(TCB)に維持されます。 現在の、この構造には、TCPパラメタ、ソースポート、目的地への分野があります。
Carlson & Ficarella [Page 9] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[9ページ]RFC1705 6インチ: IPng問題1994年10月
port, window size, sequence number, acknowledgment number, and any TCP options. The network layer source and destination IP numbers are also stored here. Finally, the status of the connection (LISTEN, ESTABLISHED, CLOSING, of the TCP parameters and include the new source and destination Transport addresses. The existing space for the IPv4 addresses will be left in place to allow for backward compatibility. The IPv4 fields will be used if the source is communicating directly with an unmodified TCP/IP host.
ポート、ウィンドウサイズ、一連番号、確認応答番号、およびどんなTCPオプション。 また、ネットワーク層ソースと目的地IP番号はここに保存されます。 LISTEN、ESTABLISHED、CLOSING、TCPパラメタとインクルードでは、送付先Transportアドレス新しいソースとIPv4アドレスのための既存のスペースは適所から後方のために互換性を許容するのが外されるでしょう。最終的に接続の状態、(ソースが変更されていないTCP/IPホストと共に直接伝達していると、IPv4分野は使用されるでしょう。
The existing status indicators will remain with their meaning unchanged. Connection setup will retain the current 3-way handshake. When performing transporter functions, TCP will NOT build a TCB, unless the destination is an unmodified IPv4 host (see appendix D). The TCP connection remains an end-to-end reliable transport service, regardless of the number of intermediate transporter nodes.
それらの意味が変わりがないままで既存の自動運転表示灯は残るでしょう。 接続設定は現在の3ウェイ握手を保有するでしょう。 運送者機能を実行するとき、TCPはTCBを造らないでしょう、目的地が変更されていないIPv4ホスト(付録Dを見る)でないなら。 TCP接続は中間的運送者ノードの数にかかわらず終わりから終わりへの信頼できる輸送サービスのままで残っています。
TCP will build an old or new header (defined below) placing the user application data in the data field. If TCP is communicating directly with an unmodified IPv4 host, the existing TCP header (STD 7, RFC 793) will be used for comparability reasons. If the destination host is an unmodified host, and an intermediate transporter node is being used, this new TCP header must be used with the 'C' bit set to 1. The destination TA will be set to the IPv4 address, and the packet will be delivered to the transporter node. If the destination host is modified with this new TCP, the destination address will be set to the TA and the packet will be delivered, possibly through a transporter, to the remote host.
TCPは、ユーザアプリケーションデータをデータ・フィールドに置きながら、古いか新しいヘッダー(以下では、定義される)を造るでしょう。 TCPが変更されていないIPv4ホストと共に直接伝達する予定であると、既存のTCPヘッダー(STD7、RFC793)は比較可能性理由に使用されるでしょう。 あて先ホストが変更されていないホストであり、中間的運送者ノードが使用されているなら、1に設定された'C'ビットと共にこの新しいTCPヘッダーを使用しなければなりません。 目的地TAはIPv4アドレスに用意ができるでしょう、そして、パケットは運送者ノードに提供されるでしょう。 あて先ホストがこの新しいTCPと共に変更されると、送付先アドレスはTAに設定されるでしょう、そして、パケットは提供されるでしょう、ことによると運送者を通して、リモートホストに。
TCP will communicate with it's underlying network layer(s) to deliver packets to remote hosts. The Internet Assigned Number Authority (IANA) will assign unique identifiers to each network layer TCP will support. TCP will maintain a cache of TA's and IANA network layers numbers, to allow support of multiple network layers. When TCP wishes to send data, it will consult this cache to determine which network to send the packet to. If the destination TA is not in this cache, TCP will send a request to each of it's network layer(s) asking if they know how to deliver data to this TA. All of the network layers supported by the sending host will be probed, in an order defined by the system administrator, until one responds 'yes' or they all have said 'no'. The first layer to say 'yes' will be used. If no path exists, an error message will be returned to the user application. Once a network layer is identified, TCP will communicate with it by passing the following parameters:
TCPは、リモートホストにパケットを提供するためにそれの基本的なネットワーク層で交信するでしょう。 ISOCの機関の一つで(IANA)はTCPがサポートする各ネットワーク層にユニークな識別子を割り当てるでしょう。 TCPは、複数のネットワーク層のサポートを許すためにTAとIANAネットワーク層番号のキャッシュを維持するでしょう。 TCPがデータを送りたがっているとき、それは、どのネットワークにパケットを送るかを決定するためにこのキャッシュに相談するでしょう。 彼らがこのTAにデータを提供する方法を知って、このキャッシュに目的地TAがないと、TCPはそれぞれをそれのネットワーク層の尋ねるのに要求を送るでしょう。 送付ホストによってサポートされたネットワーク層のすべてが調べられるでしょう、システム管理者によって定義されたオーダーで、人が'はい'について応答するか、または'いいえ'と言うまで。 'はい'と言う最初の層は使用されるでしょう。 経路が全く存在していないと、ユーザアプリケーションにエラーメッセージを返すでしょう。 TCPは、一度、ネットワーク層が特定されるとそれと以下のパラメタを通過することによって、伝えるでしょう:
1) Destination address (TA or IPv4).
2) A pointer to the data buffer.
3) Options.
1) 送付先アドレス(TAかIPv4)。 2) データバッファへの指針。 3) オプション。
Carlson & Ficarella [Page 10] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[10ページ]RFC1705 6インチ: IPng問題1994年10月
The network layer will use the destination address as an index into a cache to determine the network address to send to. In the entry is not in the cache, it will make a DNS call to determine the network address and a cache entry will be build (see appendix D). It is mandatory that a cache be maintained. If a host is attached to several different networks (i.e., a transporter) each layer will maintain it's own cache.
ネットワーク層はインデックスとしてネットワーク・アドレスが発信することを決定するキャッシュに送付先アドレスを使用するでしょう。 エントリーには、中にキャッシュがなくて、DNSは、ネットワーク・アドレスとキャッシュエントリーが体格(付録Dを見る)であることを決定するためにそれで呼ぶでしょう。 キャッシュが維持されるのは、義務的です。 ホストがいくつかの異なったネットワーク(すなわち、運送者)に配属されると、各層は、それが自己のキャッシュであることを支持するでしょう。
When IP receives a data packet from a remote node, it will strip off the IP header and pass a pointer to the data buffer up to TCP. IP will also supply TCP with it's IANA network layer number. TCP may use the source TA and the IANA number to update it's cache.
IPが遠隔ノードからデータ・パケットを受けるとき、それは、IPヘッダーを全部はぎ取って、データバッファに指針をTCPまで通過するでしょう。 また、IPはそれのIANAネットワーク層番号をTCPに供給するでしょう。 TCPはソースTAを使用するかもしれません、そして、それをアップデートするIANA番号によるキャッシュです。
The structure of a TA is to concatenate a unique manufacture code with a manufacturer defined variable to form a unique 64 bit number. The unique manufacture code will be a 24 bit number, possibly the same code as the IEEE 802.3 MAC address code. The remaining 40 bits will be supplied by the manufacture to uniquely identify the TCP. It is recommended that this field be built by encoding the manufacturer's serial number. An integer serial number will be viewed as an integer number and converted into it's hexadecimal equivalent, left padded with 00 octets if necessary. If a serial number contains Alpha characters, these alpha characters will be converted into octets using the international standard ASCII code. The integer values will then be converted to their hexadecimal equivalent and the 2 values will be concatenated to form the unique identifier. These structure will allow 2^24 (16,777,216) manufactures to build 2^40 (1,099,511,627,776) transport addressable entities. Each of these entities may have 1 or more network interfaces using IPv4, IPng, or any other network layer protocol.
TAの構造は64ビットのユニークな数を形成するためにメーカー被定義変数でユニークな製造コードを連結することです。 ユニークな製造コードは24ビットの数、ことによるとIEEE802.3MACアドレスコードと同じコードになるでしょう。 唯一TCPを特定するために製造で残っている40ビットを供給するでしょう。 この分野が製造番号をコード化することによって造られるのは、お勧めです。 整数通し番号は整数として見なされて、それに変換されているのが、必要なら、00の八重奏でそっと歩くように残っている16進同等物であるということでしょう。 通し番号がアルファーキャラクタを含んでいると、これらのアルファキャラクタは、世界規格ASCIIコードを使用することで八重奏に変換されるでしょう。 次に、整数値はそれらの16進同等物に変換されるでしょう、そして、2つの値が、ユニークな識別子を形成するために連結されるでしょう。 これらの構造は、2^40(1,099,511,627,776)輸送にアドレス可能な実体を築き上げるために2^24個の(16,777,216)製作物を許容するでしょう。 それぞれのこれらの実体には、1があるかもしれませんか、またはIPv4、IPng、またはいかなる他のネットワーク層も使用するより多くのネットワーク・インターフェースが議定書を作ります。
The current growth of the Internet may indicate that this amount of address space is inadequate. A larger fixed space (i.e., 96 or 128 bits) or a variable length field may be required. The disadvantage is that this address must be transmitted in every packet.
インターネットの現在の成長は、この量のアドレス空間が不十分であることを示すかもしれません。 より大きい固定スペース(すなわち、96ビットか128ビット)か可変長フィールドが必要であるかもしれません。 不都合はあらゆるパケットでこのアドレスを伝えなければならないということです。
Carlson & Ficarella [Page 11] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[11ページ]RFC1705 6インチ: IPng問題1994年10月
4.2 TCPng
4.2 TCPng
The new TCP header is as shown.
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
示されるとして新しいTCPヘッダーがあります。 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination TA + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source TA + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Port Number | ver | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | QoS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Sequence Number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Acknowledgment Number + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data offset |X|X|C|A|P|R|S|F| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Variable length option 1 / \ : \ / : / \ Variable length Option n \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 目的地、バイバイ、+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソース、バイバイ、+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 仕向港番号| ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート番号| QoS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ウィンドウサイズ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 一連番号+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 確認応答番号+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データは相殺されます。|X|X|C|A|P|R|S|F| チェックサム| +++++++++++++++++++++++++++++++++/可変長オプション1/\: \ / : /\可変な長さOption n\+++++++++++++++++++++++++++++++++
Figure 1
図1
Destination TA: 64 bits.
The Destination Transport Address. The concatenation of
the 24 bit IEEE assigned Ethernet address and the 40 bit
representation of the machines serial number for the
remote node.
目的地、バイバイ: 64ビット。 送付先輸送アドレス。 24のものの連結は遠隔ノードのためのマシン通し番号のイーサネット・アドレスと40ビットの表現が割り当てられたIEEEに噛み付きました。
Carlson & Ficarella [Page 12] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[12ページ]RFC1705 6インチ: IPng問題1994年10月
Source TA: 64 Bits.
The Source Transport Address. The concatenation of the
24 bit IEEE assigned Ethernet address and the 40 bit
representation of the machines serial number for the
local node.
ソース、バイバイ: 64ビット。 ソース輸送アドレス。 24のものの連結はローカルのノードのためのマシン通し番号のイーサネット・アドレスと40ビットの表現が割り当てられたIEEEに噛み付きました。
Destination Port Number: 28 Bits.
Identifies the specific application on the remote node.
仕向港番号: 28ビット。 遠隔ノードにおける特定のアプリケーションを特定します。
Ver: 4 bits.
Version number. This is TCPng. RFC 793
references 9 earlier editions of ARPA TCP. The current
TCP is version 10.
Ver: 4ビット。 バージョン番号。 これはTCPngです。 ARPA TCPのRFC793参照9の以前の版。 現在のTCPはバージョン10です。
Source Port Number: 28 Bits.
Identifies the specific application on the local node.
ソースポート番号: 28ビット。 ローカルのノードにおける特定のアプリケーションを特定します。
QoS: 4 bits.
The Quality of Service parameter may be set by the user
application and passed down to a network layer that
supports different levels of service.
QoS: 4ビット。 ServiceパラメタのQualityはユーザアプリケーションで用意ができて、異なったレベルのサービスをサポートするネットワーク層まで渡されるかもしれません。
Window: 32 Bits.
The number of data octets beginning with the one
indicated in the acknowledgment field which the sender
of this segment is willing to accept.
窓: 32ビット。 もので始まるデータ八重奏の数は、承認分野でどれを受け入れるかを構わないこのセグメントの送付者が、思っている示しました。
Sequence Number: 64 Bits.
The sequence number of the first data octet in this segment
(accept when the S bit is present). If S bit is on, the
sequence number is the initial sequence number (ISN) and
the first data octet is ISN+1. (The ISN is computed using
the existing algorithm).
一連番号: 64ビット。 このセグメント(Sビットが存在しているとき、受け入れる)の最初のデータ八重奏の一連番号。 Sビットがオンであるなら、一連番号は初期シーケンス番号(ISN)です、そして、最初のデータ八重奏はISN+1です。 (ISNは既存のアルゴリズムを使用することで計算されます。)
Acknowledgment Number: 64 Bits.
If the A bit is set, this field contains the value of
the next sequence number the sender of this segment is
expecting to receive. Once a connection is established,
this is always sent.
確認応答番号: 64ビット。 Aビットが設定されるなら、この分野はこのセグメントの送付者が受けると予想している次の一連番号の値を含んでいます。 いったん接続を確立すると、いつもこれを送ります。
Data Offset: 8 Bits.
This is the number of 32 bit words in the TCP header. This
indicates where the data begins. The TCP header is an
integral number of 32 bit words long. The minimum value is
12 and the maximum is 256. If options are used, they must
pad out to a 32 bit boundary.
データは相殺されます: 8ビット。 これはTCPヘッダーの32ビットの単語の数です。 これは、データがどこで始まるかを示します。 長い間、TCPヘッダーは整数の32ビットの単語です。 最小値は12です、そして、最大は256です。 オプションが使用されているなら、それらは32ビット境界への外でそっと歩かなければなりません。
Carlson & Ficarella [Page 13] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[13ページ]RFC1705 6インチ: IPng問題1994年10月
Flags: 8 Bits.
The A, P, R, S, and F flags carry the same meaning as in
the current version of TCP. They are:
旗: 8ビット。 A、P、R、S、およびF旗は、TCPの最新版のように意味しながら、同じくらい運びます。 それらは以下の通りです。
1. A = Ack, and acknowledgment field significant
2. P = Push, the push function
3. R = Reset, reset the connection
4. S = Sync, synchronize sequence numbers
5. F = Fin, No more data from sender
1. =Ack、および承認分野かなりの2。 Pはプッシュ、プッシュ機能3と等しいです。 Rはリセットと等しく、リセットは接続4です。 Sは同時性と等しく、一連番号5を同期させてください。 Fは送付者からのフィン、それ以上のデータと等しくはありません。
The C bit, C = Compatibility, is used to indicate that one
end of the connection is an unmodified TCP/IP host. When
the C bit is set, all header values must conform to the
TCPv6 specifications. The source port, destination port,
and window size must be 16 bits and the Sequence and
Acknowledgment numbers must be 32 bits. These values are
stored in the lower half of the proper area with null octet
pads filling out the rest of the field.
Cビット(C=互換性)は、接続の片端が変更されていないTCP/IPホストであることを示すのに使用されます。 Cビットが設定されるとき、すべてのヘッダー値がTCPv6仕様に従わなければなりません。 ソースポート、仕向港、およびウィンドウサイズは、16ビットとSequenceであるに違いありません、そして、Acknowledgment番号は32ビットでなければなりません。 ヌル八重奏パッドが分野の残りに書き込んでいて、これらの値は適切な領域の下半分に保存されます。
The 2 X bits, X = Reserved, are not defined and must be
ignored by a receiving TCP.
X=を2Xビット、予約されて、定義されないで、受信TCPは無視しなければなりません。
Checksum: 16 Bits.
The checksum field has the same meaning as in the current
version of TCP. The current 96 bit pseudo header is NOT
used in calculating the checksum. The checksum covers only
the information present in this header. The checksum field
itself is set to zero for the calculation.
チェックサム: 16ビット。 チェックサム分野には、同じくらいが、TCPの最新版のように意味しながら、あります。 96ビットの現在の疑似ヘッダーはチェックサムについて計算する際に使用されません。 チェックサムはこのヘッダーの現在の情報だけをカバーしています。 チェックサム分野自体は計算のためにゼロに設定されます。
Variable Length Options:
There are two types of options, mandatory and optional. A
TCP must implement all known mandatory options. It must
also be capable of ignoring all optional options it does
not know about. This will allow new options to be
introduced without the fear of damage caused by unknown
options. An option field must end on a 32 bit boundary.
If not, null octet pad characters will be appended to the
right of the option. The structure of an option is shown
in figure 2 below:
可変長オプション: 2つのタイプの義務的で任意のオプションがあります。 TCPはすべての知られている義務的なオプションを実装しなければなりません。 また、それは知らないすべての任意のオプションを無視できなければなりません。 これは、新しいオプションが未知のオプションでもたらされた損害への恐怖なしで紹介されるのを許容するでしょう。 オプション・フィールドは32ビット境界で終わらなければなりません。 そうでなければ、ヌル八重奏パッド文字をオプションの右に追加するでしょう。 オプションの構造は2未満が中で計算するのが示されます:
Carlson & Ficarella [Page 14] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[14ページ]RFC1705 6インチ: IPng問題1994年10月
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option data | pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションデータ| パッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
図2
4.3 Mandatory Options
4.3 義務的なオプション
There are three mandatory options defined by this implementation of TCP. Each of these options is implemented using the structure pictured in figure 2 above.
TCPのこの実装によって定義された3つの義務的なオプションがあります。 それぞれのこれらのオプションは構造が描写した使用が実装されて、上の2が中で計算するということです。
A description of each field follows:
それぞれの分野の記述は続きます:
Type: 16 bits
The type field identifies the particular option.
以下をタイプしてください。 タイプがさばく16ビットは特定のオプションを特定します。
Length: 16 bits
The length field represents the size of the option
data to follow, in octets.
長さ: 16ビット、長さの分野は、八重奏で続くようにオプションデータのサイズを表します。
Option Data: Variable Length
The option data is of variable length specified by
the length field, plus 0-3 bytes of zeros to pad to a
32-bit boundary.
オプションデータ: 可変Length、オプションデータは長さの分野によって指定された可変長、および32ビットの境界に水増しする0-3バイトのゼロのものです。
The following are the 3 mandatory options that must be implemented:
↓これは実装しなければならない3つの義務的なオプションです:
Null: 8 bits
The null option, (type=0) is represented by the bit
sequence [00000000], preceded by an additional 8, zero
padding bits to fill out the full 16-bit type field. The
data may be of any size, including 0 bytes. The option may
be used to force an option to be ignored.
ヌル: 8ビットヌルオプション、(タイプ=0)は追加8、どんな詰め物ビットも先行した、完全な16ビットのタイプ分野に書き込むことがない噛み付いている系列[00000000]によって表されます。 データは0バイトを含むどんなサイズのものであるかもしれません。 オプションは、オプションが無視させられるのに使用されるかもしれません。
Maximum Segment Size: 8 bits
The maximum segment size option, (type=1) is represented by
the bit sequence [00000001] preceded by an additional 8,
zero padding bits to fill out the full 16-bit type field.
If this option is present, then it communicates the maximum
receive segment size at the TCP which sends this segment.
This potion is mandatory if sent in the initial connection
request (SYN). If it is sent on any other segment it is
advisory. The data is a 32-bit word specifying the segment
最大のセグメントサイズ: 8ビット最大のセグメントサイズオプション、(タイプ=1)は追加8、詰め物ビットがないのに従って系列[00000001]が完全な16ビットのタイプ分野に書き込むために先行したビットによって表されます。 このオプションが存在しているなら、それは交信します。最大はこのセグメントを送るTCPでセグメントサイズを受けます。 初期の接続要求(SYN)で送るなら、この一杯は義務的です。 いかなる他のセグメントでもそれを送るなら、顧問です。 データはセグメントを指定する32ビットの単語です。
Carlson & Ficarella [Page 15] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[15ページ]RFC1705 6インチ: IPng問題1994年10月
size in octets [Ullmann, 1993].
八重奏[ウルマン、1993]におけるサイズ。
Urgent Pointer: 8 bits
The urgent pointer, (type=2) is represented by the bit
sequence [00000010] preceded by an additional 8, zero
padding bits to fill out the full 16-bit type field. This
option emulates the urgent field in TCPv6. The data is a
64-bit sequence number identifying the last octet of urgent
data within the segment.
緊急の指針: 8ビット緊急の指針、(タイプ=2)は追加8、詰め物ビットがないのに従って系列[00000010]が完全な16ビットのタイプ分野に書き込むために先行したビットによって表されます。 このオプションはTCPv6の緊急の分野を見習います。 データはセグメントの中で緊急のデータの最後の八重奏を特定する64ビットの一連番号です。
4.4 Optional Options
4.4 任意のオプション
This version of TCP must be capable of accepting any unknown options. This is to guarantee that when presented with an unrecognized option, TCP will not crash, however it must not reject or ignore any option.
TCPのこのバージョンはどんな未知のオプションも受け入れることができなければなりません。 これは、認識されていないオプションを与えるとき、TCPがダウンしないで、しかしながら、少しのオプションも拒絶してはいけないか、無視してはいけないのを保証するためのものです。
4.5 Compatibility Issues
4.5 互換性問題
The Internet community has a large installed base of IP users. The resources required to operate this network, both people and machine, is enormous. These resources will need to be preserved. The last time a change like this took place, moving from NCP to TCP, there were a few 100 nodes to deal with [Postel, 1981c]. A small close knit group of engineers managed the network and mandated a one year migration strategy. Today there are millions of nodes and thousands of administrators. It will be impossible to convert any portion of the Internet to a new protocol without effecting the rest of the community.
インターネットコミュニティには、IPユーザの大きいインストールされたベースがあります。 リソースがこのネットワーク、両方の人々を手術するのが必要であり、マシンは巨大です。 これらのリソースは、保存される必要があるでしょう。 このような変化は起こりました、NCPからTCPまで移行して前回対処するいくつかの100ノード[ポステル、1981c]がありました。 技術者の小さい密接なグループは、ネットワークを経営して、1年間の移行戦略を強制しました。 今日、何百万ものノードと何千人もの管理者がいます。 共同体の残りに作用しないでインターネットのどんな部分も新しいプロトコルに変換するのは不可能でしょう。
In the worst case, users will lose communications with their peers as some systems upgrade and others do not. In the current global environment, this will not be tolerated. Any attempt to simply replace the current IPv4 protocol with a new IPng protocol that does not address compatibility issues is doomed to failure. This reasoning has recently been realized by Ullmann (CATNIP) and he attempts to use translators to convert from one protocol to another (i.e., CATNIP to IPv4). The problem is what to do when incompatible parameters are encountered. Also CATNIP would need to be replaced every time a new network layer protocol was developed.
最悪の場合には、ユーザは何人かのシステムアップグレードと他のものが失わないように彼らの同輩とのコミュニケーションを失うでしょう。 現在の地球環境では、これは許容されないでしょう。 単に現在のIPv4プロトコルを互換性が問題であると扱わない新しいIPngプロトコルに取り替えるどんな試みも失敗に運命づけられます。 この推理は最近ウルマン(CATNIP)によって実現されました、そして、彼は1つのプロトコルから別のもの(すなわち、IPv4へのCATNIP)まで変換するのに翻訳者を使用するのを試みます。 両立しないパラメタが遭遇するとき、問題はするべきことです。 また、CATNIPは、新しいネットワーク層プロトコルが開発されたときはいつも、取り替えられる必要があるでしょう。
This proposal attempts to solve these problems by decoupling the transport and network protocols. By allowing TCP to operate over different network layer protocols, we will create a more stable environment. New network layer protocols could be developed and implemented without requiring changes that are visible to the user community. As TCP packets flow from host-to-host they may use several different network layers, allowing users to communicate without having to worry about how the data is moved across the
この提案は、輸送とネットワーク・プロトコルの衝撃を吸収することによってこれらの問題を解決するのを試みます。 TCPが異なったネットワーク層プロトコルの上で作動するのを許容することによって、私たちは、より安定した環境を作成するつもりです。 ユーザーコミュニティに目に見える変化を必要としないで、新しいネットワーク層プロトコルを開発して、実装することができました。 ホストによってTCPパケットが流れるとき、いくつかの異なったネットワーク層を使用するかもしれません、ユーザがデータがどう横切って動かされるかを心配する必要はなくて交信するのを許容して
Carlson & Ficarella [Page 16] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[16ページ]RFC1705 6インチ: IPng問題1994年10月
underlying network.
ネットワークの基礎となります。
4.5.1 Backward Compatibility
4.5.1 後方の互換性
It may be said that the maturity of a software package can be determined by how much code is required to maintain compatibility with previous versions. With the current growth of the Internet, backward compatibility issues can not be dismissed or added in as an after thought. This version of TCP was designed with backward compatibility in mind. When the TCP communicates with an unmodified IPv4 TCP/IP, it takes steps to insure compatibility. First off it sets a bit in the header indicating that the TCP parameters (ack, seq, port numbers, and window size) use the TCPv6 values. When communicating directly with an unmodified host the existing TCP/IP header is used. Only existing TCP options may be sent as well.
どのくらいのコードが旧バージョンとの互換性を維持するのに必要であるかによってソフトウェアパッケージの円熟が決定できると言われているかもしれません。 インターネットの現在の成長で、後考えとして後方の互換性の問題を捨てることができないか、加えることができません。 TCPのこのバージョンは念頭に後方の互換性で設計されました。 TCPが変更されていないIPv4TCP/IPで交信するとき、それは、互換性を保障するために手を打ちます。 それの1番目はTCPパラメタ(ack、seq、ポートナンバー、およびウィンドウサイズ)がTCPv6値を使用するのを示すヘッダーに少しセットします。 変更されていないホストと共に直接伝達するとき、既存のTCP/IPヘッダーは使用されています。 また、既存のTCPオプションだけを送るかもしれません。
The advantage of this approach is that TCP transporter nodes will not have to make decisions about how to modify packets just passing through. It is up to the source node to build a header that is compatible before sending it. This approach will allow any new TCP to contact and communicate with any unmodified IPv4 host. The source host may have an IPv4 address, or it may send data to a transporter for delivery. The decision will be made based on the source and destination addresses. During connection setup, the location of the destination node is determined and the proper network layer is used to send data.
このアプローチの利点はTCP運送者ノードがどうただ通り抜けるパケットを変更するかに関する決定をする必要はないということです。 それを送る前に互換性があるヘッダーを造るのはソースノードまで達しています。 このアプローチで、どんな新しいTCPにもどんな変更されていないIPv4ホストにも連絡して、コミュニケートするでしょう。 送信元ホストには、IPv4アドレスがあるかもしれませんか、またはそれは配送のための運送者にデータを送るかもしれません。 ソースと送付先アドレスに基づいて決定をするでしょう。 接続設定の間、目的地ノードの位置は断固としています、そして、適切なネットワーク層は、データを送るのに使用されます。
An existing IPv4 host will be capable of opening a connection to any new TCPng host that is directly connected to the network with an IPv4 protocol stack. If the TCPng host only has an IPng stack, the connection attempt will fail. Some existing batch style services (i.e., Simple Mail Transfer Protocol - SMTP) will continue to work with the help of transporters. Interactive sessions (i.e., Telnet) will fail. Thus, our new TCP is backward compatible, but the existing IPv4 hosts are not forward compatible.
既存のIPv4ホストはIPv4プロトコル・スタックで直接ネットワークに接続されるどんな新しいTCPngホストにも接続を公開できるでしょう。 TCPngホストがIPngスタックを持っているだけであると、接続試みは失敗するでしょう。 いくつかの既存のバッチスタイルサービス(すなわち、シンプルメールトランスファプロトコル--SMTP)が、運送者の助けで働き続けるでしょう。 対話的なセッション(すなわち、Telnet)は失敗するでしょう。 その結果、私たちの新しいTCPが後方にあります。互換性があるので、IPv4が接待する存在だけがフォワード互換性がありません。
4.6 Level 4 Gateways
4.6レベル4 ゲートウェイ
The ability to allow hosts with differing network layer protocols to communicate will be accomplished by using a transport layer gateway (called transporter in this paper). The transporter works just like an IP router, receiving TCP packets from one network layer and transporting them over to another. This switching is done by examining the packets source and destination TA's. If a TCP packet arrives with a destination TA that differs from this hosts TA, and the transporter functionality is enabled, the packet should be transported to another network layer. In some cases, the receiving node is a host and not a transporter (i.e., transporter functionality
異なったネットワーク層プロトコルをもっているホストが交信するのを許容する能力は、トランスポート層ゲートウェイ(この紙に運送者と呼ばれる)を使用することによって、達成されるでしょう。 運送者はまさしくIPルータのように動作します、1つのネットワーク層からTCPパケットを受けて、別のものにそれらを輸送して。 パケットソースと目的地TAを調べることによって、この切り換えをします。 TCPパケットが目的地と共に到着するなら、これと異なっているTAがTAを接待します、そして、運送者の機能性は可能にされます、そして、パケットは別のネットワーク層に輸送されるべきです。 いくつかの場合、受信ノードが運送者ではなく、ホストである、(すなわち、運送者の機能性
Carlson & Ficarella [Page 17] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[17ページ]RFC1705 6インチ: IPng問題1994年10月
disabled). In this case the host will discard the packet and return a TCMP (see below) error message.
身体障害者) この場合、ホストは、パケットを捨てて、TCMP(以下を見る)エラーメッセージを返すでしょう。
A transporter is not responsible for reading or formatting the TCP header of packets it receives. The header is simply examined to determine where to deliver the packet. When forwarding, the packet is sent to any of the network layers the transporter supports. The exception is that the packet may not be presented back to the network it was received from. It is the responsibility of the network layer to destroy undeliverable packets. If a transporter is unable to determine which network the packet should be forwarded to, the packet is discarded and a TCMP message is generated and returned to the original source host. Several examples of how transporting works are presented in appendix D.
運送者はそれが受けるパケットのTCPヘッダーを読むか、またはフォーマットするのに原因となりません。 ヘッダーは、パケットをどこに提供するかを決定するために単に調べられます。 進めるとき、運送者がサポートするネットワーク層のいずれにもパケットを送ります。 例外はパケットがそれが受け取られたネットワークに提示して戻されないかもしれないということです。 「非-提出物」パケットを破壊するのは、ネットワーク層の責任です。 運送者が、パケットがどのネットワークに送られるべきであるかを決定できないなら、パケットが捨てられて、TCMPメッセージを一次資料ホストに生成して、返します。 輸送がどう働くかに関するいくつかの例が付録Dに提示されます。
4.7 Error Conditions
4.7 エラー条件
It is recognized that from time to time certain error conditions will occur at some intermediate transporter that will need to be communicated back to the source host. To accomplish this a Transport Control Message Protocol (TCMP) service facility will need to be developed. This protocol will model itself after the Internet Control Message Protocol (ICMP). The operational details are discussed in a separate TCMP document.
時々、あるエラー条件が送信元ホストとコミュニケートして戻る必要があるある中間的運送者に起こると認められます。 これを達成するために、Transport Control Messageプロトコル(TCMP)サービス施設は、開発される必要があるでしょう。 このプロトコルはインターネット・コントロール・メッセージ・プロトコル(ICMP)にそれ自体に倣うでしょう。 別々のTCMPドキュメントで操作上の詳細について議論します。
5. Advantages and Disadvantages of this approach
5. このアプローチの利点とDisadvantages
This proposal offers the Internet community several advantages. First, TCPng will operate over multiple network layer protocol stacks. Users will be able to select the stack(s) that meets their needs. The problem of IPv4 address exhaustion will be postponed as sites move from IPv4 to IPng protocol stacks. Future IP3g protocol stacks may be designed and deployed without major service disruptions. The increased size of the sequence, acknowledge, and window fields will allow applications to run effectively over high bandwidth-delay network links. Lastly, TCPng will allow applications to specify certain Quality of Service (QoS) parameters which may be used by some network layer protocols (i.e., Asynchronous Transfer Mode - ATM).
この提案はいくつかの利点をインターネットコミュニティに示します。 まず最初に、TCPngは複数のネットワーク層プロトコル・スタックの上で作動するでしょう。 ユーザは彼らの需要を満たすスタックを選択できるでしょう。 サイトがIPv4からIPngプロトコル・スタックまで移行するとき、IPv4アドレス疲労困憊の問題は延期されるでしょう。 将来のIP3gプロトコル・スタックは、主要サービス分裂なしで設計されていて、配布されるかもしれません。 増強されたサイズ、系列では、アプリケーションが高帯域遅れネットワークリンクの上に意志で有効に実行できる分野を承認して、窓を付けてください。 最後に、TCPngはアプリケーションにいくつかのネットワーク層プロトコル(すなわち、Asynchronous Transfer Mode--ATM)によって使用されるかもしれないService(QoS)パラメタのあるQualityを指定させるでしょう。
This protocol is not without it's share of design compromises. Among these are a large packet header increased in size from 5 to 12 long words. The addition of a TA means that network administrators must deal with yet another network number that must be globally maintained. Multiple network protocols may add to the complexity of a site's network. Lastly, is the TA address space large enough so we will not have to rebuild TCP.
このプロトコルはそれのデザイン感染のシェアと共にあります。 このうち、5〜12までロング・ワードが大きいパケットのヘッダー増やされたサイズにあります。 TAの追加は、ネットワーク管理者がグローバルに維持しなければならないさらに別のネットワーク・ナンバーに対処しなければならないことを意味します。 複数のネットワーク・プロトコルがサイトのネットワークの複雑さに加えるかもしれません。 最後にTAアドレス空間が十分大きいので、私たちはTCPを再建する必要はないでしょう。
Carlson & Ficarella [Page 18] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[18ページ]RFC1705 6インチ: IPng問題1994年10月
6. Conclusions
6. 結論
In this paper, we have reviewed the current status of the Internet society s IPng initiative. We were struck by the enormity of the changes required by those proposals. We felt that a different approach was needed to allow change to occur in a controlled manner. This approach calls for replacing the current TCP protocol with one that does not require a specific IP layer protocol. Once this is in place, various IPng protocols may be developed and deployed as sites require them. Communications between IPv4 and IPng hosts will be maintained throughout the transition period. Modified hosts will be able to remove their IPv4 protocol stacks, while maintaining communications with unmodified hosts by using a TCP transporter.
この紙では、私たちはインターネット社会s IPngイニシアチブの現在の状態について調査しました。 私たちはそれらの提案で必要である変化の無法で強い印象を受けました。 私たちは、異なるアプローチが変化が制御方法で起こるのを許容するのに必要であったと感じました。 このアプローチは、現在のTCPプロトコルを特定のIP層のプロトコルを必要としないものに取り替えるように求めます。 これが適所にいったんあると、サイトがそれらを必要とするとき、様々なIPngプロトコルは、開発されて、配布されるかもしれません。 IPv4とIPngホストとのコミュニケーションは過渡期中で維持されるでしょう。 変更されたホストはTCP運送者を使用することによって変更されていないホストとのコミュニケーションを維持している間、彼らのIPv4プロトコル・スタックを取り除くことができるでしょう。
The title of this paper "Six Virtual Inches to the Left" comes from a talk the author once heard. In this talk an engineer from Control Data Corporation (CDC) told a story of CDC's attempt to build a cryogenically cooled super computer. The idea being that the power consumption of such a computer would be far lower then that of a conventional super computer. As the story goes, everyone thought this was a great idea until someone pointed out what the power requirements of the cryo system were. The result was that all the assumed power savings were consumed by the cryo system. The implication being that all the power requirements were not saved but simply moved 6 feet from the CPU to the support equipment. The moral being that the entire system should be analyzed instead of just one small piece.
「左への仮想の6インチ」というこの紙のタイトルは作者が一度聞いた話から来ます。 この話では、コントロール・データ社(CDC)からの技術者は、極低温に冷やされたスーパーコンピュータを建てるようにCDCの試みの話に言いました。 そのようなコンピュータの電力消費量が遠いだろうということであることがその時従来のスーパーコンピュータのものを下ろすという考え。 その話によると、皆は、だれかが、cryoシステムに関する所要電力が何であるかを指摘するまでこれがすばらしい考えであると考えました。 結果はすべての想定されたパワー貯蓄がcryoシステムによって消費されたということでした。 すべての所要電力がCPUから支援機材まで保存していませんが、単に動く6フィートであったということである含意。 全体のシステムがちょうど1つの小さい断片の代わりに分析されるべきであるということである教訓。
References
参照
[Postel, 1981a] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, DARPA, September 1981.
[ポステル、1981a] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、DARPA、1981年9月。
[Halsal, 1992] Data Communications, Computer Networks, and Open Systems.
[Halsal、1992] データコミュニケーション、コンピュータネットワーク、およびオープンシステム。
[Meyer, Zobrist, 1990] TCP/IP versus OSI, The Battle of the Network Standards, IEEE Potentials.
[マイヤー、Zobrist、1990] TCP/IP、対OSIネットワーク規格の戦い、IEEEの可能性。
[Braden, et al, 1991] Clark, D., Chapin, L., Cer, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[ブレーデン、他、1991] クラークとD.とチェーピンとL.とCerとV.とブレーデン、R.とR.Hobby、「将来のインターネットアーキテクチャ」、RFC1287、MIT、BBN、CNRI、ISI、UCDavis(1991年12月)。
[Dixon, 1993] Dixon, T., "Comparison of Proposals for Next Version of IP", RFC 1454, RARE, May 1993.
[ディクソン、1993]ディクソン、T.、「IPの次のバージョンのための提案の比較」、まれなRFC1454は1993がそうするかもしれません。
Carlson & Ficarella [Page 19] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[19ページ]RFC1705 6インチ: IPng問題1994年10月
[Fuller, et al, 1992] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.
[フラー、他、1992] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 Merit、OARnet、「Address AssignmentとAggregation Strategy」(RFC1338、BARRNet)がcicsoする、6月1992日
[Almquist, Gross, 1992] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", RFC 1380, IESG Chair, IESG Internet AD, November 1992.
[Almquist、グロス、1992] グロス、P.とP.Almquist、「ルート設定とアドレシングにおけるIESG熟考」RFC1380、IESG議長、IESGインターネット西暦(1992年11月)。
[Postel, 1981b] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, DARPA, September 1981.
[ポステル、1981b] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD7、RFC793、DARPA、1981年9月。
[Postel, 1980] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.
[ポステル、1980]ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[Postel, 1981c] Postel, J., "NCP/TCP Transition Plan", RFC 801, USC/Information Sciences Institute, November 1981.
[ポステル、1981c] ポステル、J.、「NCP/TCP変遷プラン」、RFC801、科学が1981年11月に設けるUSC/情報。
[Leiner, Rekhter, 1993] Leiner, B., and Y. Rekhter, "The Multi-Protocol Internet" RFC 1560, USRA, IBM, December 1993.
[Leiner、Rekhter、1993] Leiner、B.、およびY.Rekhter、「マルチプロトコルインターネット」RFC1560、USRA、IBM、1993年12月。
[Ullmann, 1993] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993.
[ウルマン、1993]ウルマン、R.、「TP/IX:」 「次のインターネット」、RFC1475は1993年6月にソフトウェア社を処理します。
Bibliography
図書目録
Gilligan, Nordmark, and Hinden, "The SIPP Interoperability and Transition Mechanism", IPAE, 1993.
ギリガン、Nordmark、Hinden、および「SIPP相互運用性と変遷メカニズム」、IPAE、1993
Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths", RFC 1072, LBL, USC/Information Sciences Institute, October 1988.
ジェーコブソン、V.、およびR.ブレーデン、「長時間の遅延経路のためのTCP拡張子」、RFC1072、LBL、科学が1988年10月に任命するUSC/情報。
Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, LBL, USC/Information Sciences Institute, Cray Research, May 1992.
ジェーコブソンとV.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323、LBL、科学が設けるUSC/情報(クレイリサーチ)は1992がそうするかもしれません。
Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, LBL, USC/Information Sciences Institute, PARC, October 1990.
ジェーコブソンとV.とブレーデン、R.とL.チャン、「高速経路のためのTCP拡張子」RFC1185、LBL、科学が設けるUSC/情報、PARC(1990年10月)。
Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC 1560, USRA, IBM, December 1993.
Leiner、B.、およびY.Rekhter、「Multiprotocolインターネット」、RFC1560、USRA、IBM、1993年12月。
O'Malley, S., and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, University of Arizona, October 1991.
オマリー、S.、およびL.ピーターソン、「有害であると考えられたTCP拡張子」、RFC1263、アリゾナ大学、1991年10月。
Westine, A., Smallberg, D., and J. Postel, "Summary of Smallberg Surveys", RFC 847, USC/Information Sciences Institute, February 1983.
WestineとA.とSmallberg、D.とJ.ポステル、「Smallberg調査の概要」RFC847、科学が1983年2月に設けるUSC/情報。
Carlson & Ficarella [Page 20] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[20ページ]RFC1705 6インチ: IPng問題1994年10月
Appendix A
付録A
The minimum size of an ethernet frame is 64 bytes. With the existing TCP/IP protocol, a minimum size frame is 18 bytes (ethernet header & trailer) + 20 bytes (IP header) + 20 bytes (TCP header) for a total of 58 bytes. The transmitting station must add 6 null pad characters to this frame to make it conform to the 64 byte minimum. This new TCP will increase the size of the TCP header to 48 bytes. Subtracting 26 bytes (the old header and pad characters) we are left with 22 bytes or 176 bits. The time it takes to transmit these additional bits is the impact of this new TCP. The transmission time for several types of media currently used is shown in the table below. You will note that the increased times are all under 20 micro-seconds for anything over T1 speeds. User traffic patterns vary of course but it is generally agreed that 80% of the traffic stays at the local site. If this is true then the increased header size has a negligible impact on communications.
イーサネットフレームの最小規模は64バイトです。 既存のTCP/IPプロトコルで、最小規模フレームは合計58バイト18バイト(イーサネットヘッダーとトレーラ)+20バイト(IPヘッダー)+20バイト(TCPヘッダー)です。 送信所は、64バイトの最小限に従わせるために6つのヌルパッド文字をこのフレームに加えなければなりません。 この新しいTCPはTCPヘッダーのサイズを48バイトまで増強するでしょう。 26バイト(年取ったヘッダーとパッド文字)を引き算して、私たちは22バイトか176ビットと共に置き去りにされます。 それがこれらの追加ビットを伝えるわざわざはこの新しいTCPの影響です。 現在使用されているいくつかのタイプのメディアのためのトランスミッション時間は以下のテーブルに示されます。 あなたは、増強された回がすべてT1速度の上何のための20マイクロセカンド未満であることにも注意するでしょう。 ユーザトラフィック・パターンはもちろん異なりますが、一般に、トラフィックの80%がローカル・サイトにいるのに同意されます。 これが本当であるなら、増強されたヘッダーサイズはコミュニケーションに取るにたらない影響力を持っています。
Media Speed (Mbps) Rate (nsec/bit) time (usec)
------ ------------ --------------- ----------
T1 1.544 647.7 144.00
T3 44.736 22.4 3.91
Enet 10.00 100.0 17.60
FDDI 100.00 10.0 1.76
OC-1 51.84 19.3 3.40
OC-3 155.52 6.4 1.13
メディアSpeed(Mbps)レート(nsec/ビット)時間(usec)------ ------------ --------------- ---------- T1 1.544 647.7 144.00T3 44.736 22.4 3.91は1.13に10.00 100.0 17.60FDDI100.00 10.0 1.76OC-1 51.84 19.3 3.40OC-3 155.52 6.4をEnetします。
Appendix B
付録B
In order to support the TA, new DNS entries will need to be created. It is hoped that this function will be accomplished automatically. When a station is installed, the local DNS server is defined. On power up, the station will contact this server and send it it's TA and domain name. A server process will be listening for this type of information, and it will collect the data, run an authorization check, and install the TA into the DNS server. The following entry will be made.
TAをサポートするために、新しいDNSエントリーは、作成される必要があるでしょう。 この機能が自動的に達成されることが望まれています。 ステーションがインストールされるとき、ローカルのDNSサーバは定義されます。 パワーアップでは、ステーションは、このサーバに連絡して、それのTAとドメイン名をそれに送るでしょう。 サーバプロセスがこの情報の種類の聞こうとして、それは、データを集めて、許可検査を実行して、DNSサーバにTAをインストールするでしょう。以下のエントリーをするでしょう。
node.sub.domain.name IN TA xx.yy.zz.aa.bb.cc.dd.ee
node.sub.domain.name IN TA xx.yy.zz.aa.bb.cc.dd.ee
ee.dd.cc.bb.aa.zz.yy.aa.in-addr.tcp IN PTR node.sub.domain.name.
ee.dd.cc.bb.aa.zz.yy.aa.in-addr.tcp IN PTR node.sub.domain.name。
Using these entries, along with the existing DNS A records, a requesting node can determine where the remote node is located. The format xx.yy.zz is the IEEE assigned portion and aa.bb.cc.dd.ee is the encoded machine serial number as described in section 4.1.
これらのエントリーを使用して、既存のDNS A記録と共に、要求ノードは、遠隔ノードがどこに位置しているかを決定できます。 形式xx.yy.zzは部分が割り当てられたIEEEです、そして、aa.bb.cc.dd.eeはセクション4.1で説明されるようにコード化されたマシン通し番号です。
Carlson & Ficarella [Page 21] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[21ページ]RFC1705 6インチ: IPng問題1994年10月
Appendix C
付録C
Proposed UDP Header
提案されたUDPヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port Number | ver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ : \
/ : /
\ : \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 目的地、バイバイ、+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソース、バイバイ、+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 仕向港番号| ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート番号| QoS| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 長さ| チェックサム| +++++++++++++++++++++++++++++++++/データ/\: \ / : / \ : \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination TA: 64 bits.
The Destination Transport Address. The concatenation of
the 24 bit IEEE assigned Ethernet address and the 40 bit
representation of the machines serial number for the remote
node.
目的地、バイバイ: 64ビット。 送付先輸送アドレス。 24のものの連結は遠隔ノードのためのマシン通し番号のイーサネット・アドレスと40ビットの表現が割り当てられたIEEEに噛み付きました。
Source TA: 64 Bits.
The Source Transport Address. The concatenation of the 24
bit IEEE assigned Ethernet address and the 40 bit
representation of the machines serial number for the local
node.
ソース、バイバイ: 64ビット。 ソース輸送アドレス。 24のものの連結はローカルのノードのためのマシン通し番号のイーサネット・アドレスと40ビットの表現が割り当てられたIEEEに噛み付きました。
Destination Port Number: 28 Bits.
Identifies the specific application on the remote node.
仕向港番号: 28ビット。 遠隔ノードにおける特定のアプリケーションを特定します。
Ver: 4 bits.
Ver: 4ビット。
This parameter the UDP version number in use within this
packet.
UDPバージョン番号がこのパケットの中で中で使用するこのパラメタ。
Carlson & Ficarella [Page 22] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[22ページ]RFC1705 6インチ: IPng問題1994年10月
Source Port Number: 28 Bits.
Identifies the specific application on the local node.
ソースポート番号: 28ビット。 ローカルのノードにおける特定のアプリケーションを特定します。
QoS: 4 bits.
The Quality of Service parameter may be set by the user
application and passed down to a network layer that
supports different levels of service.
QoS: 4ビット。 ServiceパラメタのQualityはユーザアプリケーションで用意ができて、異なったレベルのサービスをサポートするネットワーク層まで渡されるかもしれません。
Length: 16 bits
The length parameter represents the length of the data area
in octets. This value will be set to zero if no data is
sent within this packet.
長さ: 16ビット、長さのパラメタは八重奏における、データ領域の長さを表します。 このパケットの中でデータを全く送らないなら、この値をゼロに設定するでしょう。
Checksum: 16 bits
The checksum parameter has the same meaning as in the
current version of UDP. The current 96 bit pseudo header
is NOT used in calculating the checksum. The checksum
covers only the information present in this header. The
checksum field itself is set to zero for the calculation.
チェックサム: チェックサムパラメタには16ビット、同じくらいが、UDPの最新版のように意味しながら、あります。 96ビットの現在の疑似ヘッダーはチェックサムについて計算する際に使用されません。 チェックサムはこのヘッダーの現在の情報だけをカバーしています。 チェックサム分野自体は計算のためにゼロに設定されます。
Data: Variable
This is the area in which the data for the datagram will be
sent. The length of this data in octets is specified by
the length parameter above.
データ: 可変Thisはデータグラムのためのデータが送られる領域です。 八重奏における、このデータの長さは上記の長さのパラメタによって指定されます。
Carlson & Ficarella [Page 23] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[23ページ]RFC1705 6インチ: IPng問題1994年10月
Appendix D
付録D
______ ______
| | | |
| H1 | | H2 |
| | | |
|______| |______|
\ / \
\ / \
========================= / \
" "/ |
" (SIPP) " |
" " |
"=========================" |
|
====================
______ " "
| | " CLNP "
| H4 | " "
| | "===================="
|______| |
\ |
\ |
=================== ___|___
" " | |
" "-------| H3 |
" IPv4 " | |
" " |_______|
"=================="
______ ______ | | | | | H1| | H2| | | | | |______| |______| \ / \ \ / \ ========================= / \ " "/ | 「(SIPP)」| " " | "=========================" | | ==================== ______ " " | | "CLNP"| H4| " " | | "====================" |______| | \ | \ | =================== ___|___ " " | | " "-------| H3| "IPv4"| | " " |_______| "=================="
Example 1: H1 Wishes to Establish Communication with H4 (Refer to the figure above.)
例1: H1はH4とのコミュニケーションを確立したがっています。(上の図形を参照してください。)
1. A user on host H1 attempts to communicate with a user
on host H4 by referencing H4 s fully qualified domain name.
1. ホストH1の上のユーザは、ホストH4でH4 s完全修飾ドメイン名に参照をつけることによってユーザとコミュニケートするのを試みます。
2. The TCP on H1 makes a DNS call to determine the TA
address of H4.
2. H1の上のTCPは、DNSにH4のTAアドレスを決定するために呼ばせます。
3. The DNS call returns only the IPv4 address since H4 is
determined to be an IPv4 only host.
3. DNSは、ホストだけにH4がIPv4であると決心しているのでIPv4だけが扱うリターンに電話をします。
4. The H1 TCP builds a transmission control block (TCB)
setting the C-Bit (compatibility) "ON" since H4 is an IPv4
host. Included in the TCB will also be DA = IP-H4, SA =
TA1, DP = 1234, SP = 5000 and any state parameters
4. H1 TCPは、H4がIPv4ホストであるのでC-ビット(互換性)“ON"を設定しながら、トランスミッション制御ブロック(TCB)を築き上げます。 含まれていて、また、DA=IP-H4、SA=TA1、1234、DP=SP=5000がTCBに、あるでしょう、そして、いずれもパラメタを述べます。
Carlson & Ficarella [Page 24] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[24ページ]RFC1705 6インチ: IPng問題1994年10月
describing the connection (port numbers are for example
purposes only).
接続(例えば、ポートナンバーは目的専用である)について説明します。
5. The IP on H1 makes a DNS call to determine the network
IP address of H4 and correspondingly caches both the TA
address from the TCP as well as the network IP address for
later use.
5. H1の上のIPはDNSにH4のネットワークIPアドレスを決定するために呼ばせて、TCPからのTAアドレスと後の使用のためのネットワークIPアドレスの両方を対応するキャッシュします。
6. The packet is now routed using standard SIPP procedures
to H2 this is the only path H1 has to H4.
6. パケットによる現在標準のSIPP手順をH2に用いることで発送されて、これがH1がH4に持っている唯一の経路であるということです。
7. H2 receives the packet from H1. The TCP on H2 checks
the destination TA of the packet and compares it to its
own. In this case it does not match, therefore the packet
should be forwarded.
7. H2はH1からパケットを受けます。 H2の上のTCPはパケットの目的地TAをチェックして、それ自身のものとそれを比較します。 この場合、合っていません、したがって、パケットを進めるべきです。
8. H2 s TCP will interrogate the supported network
layer(s) and determines the packet must be forwarded to H3.
8. H2 s TCPは、サポートしているネットワーク層について査問して、パケットをH3に送らなければならないことを決定します。
9. The TCP must now pass the packet the CLNP network
layer. The network layer checks its cache to determine if
there is a route specified for DA = IP-H4 already in the
cache. If so the cache entry is used, if not an entry is
created. H2 then routes the packet to H3 via NA3a, which
is the network layer address for IP-H4.
9. TCPは今、CLNPネットワーク層をパケットに通過しなければなりません。 ネットワーク層は、既にキャッシュでDA=IP-H4に指定されたルートがあるかを決定するためにキャッシュをチェックします。 そうだとすれば、キャッシュエントリーが使用されているか、またはエントリーは作成されます。 そして、H2はNA3aを通してパケットをH3に発送します。NA3aはIP-H4のためのネットワーク層アドレスです。
10. H3 receives the packet from H2. The TCP on H3 checks
the destination TA of the packet and compares it to its
own. Once again, it does not match.
10. H3はH2からパケットを受けます。 H3の上のTCPはパケットの目的地TAをチェックして、それ自身のものとそれを比較します。 もう一度、それは合っていません。
11. H3, realizing that the destination address is an IPv4
host, and knowing that it itself is directly connected to
the IPv4 network constructs an IPv4 compatible header. H3
also constructs a TCB to manage the IPv4 connection.
11. 送付先アドレスがIPv4ホストであり、それ自体が直接IPv4ネットワークに関連づけられるのを知っているのがIPv4コンパチブルヘッダーを組み立てるとわかるH3。 また、H3は、IPv4接続を管理するためにTCBを組み立てます。
12. The packet is sent down to be routed to the IP using
standard IP routing procedures.
12. パケットによって標準のIPルーティング手順を用いることでIPに発送されるのが下に降ろされます。
13. H4 receives the packet at which point the IP on it
determines that the destination address is its own and thus
proceeds to strip off the IP header and pass the packet up
to the TCP layer.
13. H4は送付先アドレスがそれ自身であるというそれのIPが決定するどのポイントでパケットを受けるか、そして、IPヘッダーを全部はぎ取って、その結果、パケットをTCP層まで通過しかけます。
14. The TCP layer than opens the corresponding IPV4_DP
port (2311) which forms the first half of the connection to
the application.
14. TCPは接続の前半を形成する対応するIPV4_DPポート(2311)をアプリケーションに開けるより層にします。
Carlson & Ficarella [Page 25] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[25ページ]RFC1705 6インチ: IPng問題1994年10月
15. H4 will now reply with a connection accept message,
sending the packet back to H3.
15. 接続がメッセージを受け入れて、パケットを送って、H4は現在、H3に返答して戻るでしょう。
16. H3 s TCP receives the packet and based on information
in the TCB determines the packet should be delivered to H1.
H3 uses the steps outlined above to route the packet back
through the network structure.
16. H3 s TCPは、パケットを受けて、TCBの情報に基づいてパケットがH1に提供されるべきであることを決定します。 H3はネットワーク構造を通してパケットを発送するために上に概説されたステップを使用します。
Example 2: H2 Wishes to Establish Communication with H3 (Refer to the figure above.)
例2: H2はH3とのコミュニケーションを確立したがっています。(上の図形を参照してください。)
1. A user on host H2 attempts to communicate with a user
on host H3 by referencing H3 s fully qualified domain name.
1. ホストH2の上のユーザは、ホストH3でH3 s完全修飾ドメイン名に参照をつけることによってユーザとコミュニケートするのを試みます。
2. The TCP on H2 makes a DNS call to determine the TA
address of H3.
2. H2の上のTCPは、DNSにH3のTAアドレスを決定するために呼ばせます。
3. The DNS call returns the TA address for H3.
3. DNSは、リターンをH3のためのTAアドレスと呼びます。
4. The H2 TCP builds a transmission control block (TCB)
setting the C-Bit (compatibility) "OFF" since H3 is an IPng
host. Included in the TCB will also be DA = TA3, SA = TA2,
DP = 1111, SP = 2222 and any state parameters describing
the connection (port numbers are for example purposes
only).
4. H2 TCPは、H3がIPngホストであるのでC-ビット(互換性)“OFF"を設定しながら、トランスミッション制御ブロック(TCB)を築き上げます。 含まれていて、また、DA=TA3、SA=TA2、1111、DP=SP=2222がTCBに、あるでしょう、そして、いずれも接続について説明するパラメタを述べます(例えば、ポートナンバーは目的専用です)。
5. The IPng on H2 makes a DNS call to determine the
network IPng address of H3 and correspondingly caches both
the TA address from the TCP as well as the network IPng
address for later use.
5. H2の上のIPngはDNSにH3のネットワークIPngアドレスを決定するために呼ばせて、TCPからのTAアドレスと後の使用のためのネットワークIPngアドレスの両方を対応するキャッシュします。
6. The packet is now routed to H3 over the IPng supported
on that network.
6. パケットは現在、そのネットワークでサポートされたIPngの上でH3に発送されます。
7. H3 receives the packet from H2. The TCP on H3 checks
the destination TA of the packet and compares it to its
own. In this case it matches.
7. H3はH2からパケットを受けます。 H3の上のTCPはパケットの目的地TAをチェックして、それ自身のものとそれを比較します。 この場合、それは合っています。
8. H3 s TCP will construct a TCB and respond with an open
accept message.
8. H3 s TCPはTCBを組み立てて、戸外で応じるでしょう。メッセージを受け入れてください。
9. H3 s TCP will interrogate the supported network
layer(s) to determine the packet must be delivered to H2
using NA2b which is specified in its cache.
9. H3 s TCPは、キャッシュで指定されるNA2bを使用することでパケットをH2に提供しなければならないことを決定するためにサポートしているネットワーク層について査問するでしょう。
Carlson & Ficarella [Page 26] RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
左への仮想のカールソンとFicarella[26ページ]RFC1705 6インチ: IPng問題1994年10月
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Richard Carlson Argonne National Laboratory Electronics and Computing Technologies Argonne, IL 60439
イリノイ リチャードカールソンアルゴンヌ国立研究所Electronicsとコンピューティング技術アルゴンヌ、60439
Phone: (708) 252-7289 EMail: RACarlson@anl.gov
以下に電話をしてください。 (708) 252-7289 メールしてください: RACarlson@anl.gov
Domenic Ficarella Motorola
ドムニック・Ficarellaモトローラ
Phone: (708) 632-4029 EMail: ficarell@cpdmfg.cig.mot.com
以下に電話をしてください。 (708) 632-4029 メールしてください: ficarell@cpdmfg.cig.mot.com
Carlson & Ficarella [Page 27]
カールソンとFicarella[27ページ]
一覧
スポンサーリンク
